Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
完璧主義にこだわり続けるとシステム開発は不幸になると思った
Search
Sponsored
·
Ship Features Fearlessly
Turn features on and off without deploys. Used by thousands of Ruby developers.
→
5hun
November 13, 2025
Programming
48
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
完璧主義にこだわり続けると システム開発は不幸になると思った
Roppongi.rb #36 / Omotesando.rb #115
で発表しました。
5hun
November 13, 2025
More Decks by 5hun
See All by 5hun
Sine Wave By Ruby
5hun
1
49
Rubyと演奏したい〜その第一歩〜.pdf
5hun
1
47
Array#forty_two
5hun
0
66
与信管理を形にする: Ruby の柔軟性が支える高速データ収集・自動化基盤
5hun
1
310
ぼっちが秘める可能性〜孤高のRubyistが語る交流会サバイバル術〜
5hun
1
44
君もRailsもアップグレード!
5hun
1
21
OSSコントリビュート初体験:Rubocopのバグを修正した話
5hun
0
52
地道なリファクタを続けてRspec高速化した話
5hun
0
66
“技術カンファレンスで何か変わる?” ──RubyKaigi後の自分とチームを振り返る
5hun
0
260
Other Decks in Programming
See All in Programming
ローカルLLMでどこまでコードが書けるか -拡張版 / How much code can be written on a local LLM Extended
kishida
12
4.4k
Contextとはなにか
chiroruxx
1
370
Strategic Design in the Frontend: Moduliths & Micro Frontends @DDDEurope
manfredsteyer
PRO
0
130
ふつうのFeature Flag実践入門
irof
8
4.2k
The ROI of Quarkus for Spring Boot Applications
hollycummins
0
140
技術的負債解消で開発者の未来を開く- AIの力でコード刷新
kmd2kmd
0
120
その問い、本当に正しいですか?AI時代のエンジニアに必要な哲学と認知科学 / ai-philosophy-cognitive-science
minodriven
13
6.2k
コンテキストの使い捨てをやめる — ビジネスルール駆動開発と miko —
ioki
0
230
はてなアカウント基盤 State of the Union
cockscomb
0
520
AIだと陥りがちなJakarta EE最新技術への移行時の落とし穴と解決策
tnagao7
0
120
New "Type" system on PicoRuby
pocke
1
1k
軽量Java基盤の設計 DIコンテナに頼らない、長期保守と1秒起動の実現 JJUG CCC 2026 Spring
macha64
0
570
Featured
See All Featured
Darren the Foodie - Storyboard
khoart
PRO
3
3.4k
Between Models and Reality
mayunak
4
350
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
230
23k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
49
10k
The Limits of Empathy - UXLibs8
cassininazir
1
370
技術選定の審美眼(2025年版) / Understanding the Spiral of Technologies 2025 edition
twada
PRO
118
120k
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
21
1.5k
Fireside Chat
paigeccino
42
4k
Building a A Zero-Code AI SEO Workflow
portentint
PRO
0
610
Hiding What from Whom? A Critical Review of the History of Programming languages for Music
tomoyanonymous
2
870
How People are Using Generative and Agentic AI to Supercharge Their Products, Projects, Services and Value Streams Today
helenjbeal
1
220
A better future with KSS
kneath
240
18k
Transcript
完璧主義にこだわり続けると システム開発は不幸になると思った Roppongi.rb #36 / Omotesando.rb #115
自己紹介 5hun @5hun_s アラームボックスという会社でRuby on Railsを書いています。 Ruby歴は2年くらい。 趣味は音楽です。
None
None
ここから本題
今回の話とは 業務システムを自社内開発していて、、 • ビジネスサイドから開発要望が都度上がってきて • それをエンジニアが確認、要件を整理、設計して実装 • その中で感じた学びの話
とある開発要望 (前提)顧客からの会社を調査してほしいという審査依頼が上がってきた時、 • 担当者を決めて処理 • 担当者の決定はリーダーが手動で割り振っている →これをいい感じに自動化したい!!
とある開発要望 要件1 金額とお客さん(依頼主)単位で自動で振り分けるようにしたい →設定画面と新規テーブルを作成すれば良さそう
とある開発要望 要件2 特定の人に偏らないようにパーセンテージでうまいこと配分してほしい
とある開発要望 要件3 特殊なお客さんの場合は田中さんに優先に配分してほしい。 (でも田中さんの担当する審査が多い時はサブ担の佐藤さんに回してほしい)
とある開発要望 要件4 難しい案件は山田さんか佐藤さん(ベテラン社員たち)に優先して欲しい
etc、、、
None
複雑すぎて色々無理なので却下
何が問題? 審査の担当者を割り振るにあたり考えなければいけないことが非常に多い • 金額 • 現在のその人が担当している審査の数 • どのお客さんからの依頼 • 審査の難易度(この判別方法によっては更なる分岐も発生しうる)
何が問題? 審査の担当者を割り振るにあたり考えなければいけないことが非常に多い • 金額 • 現在のその人が担当している審査の数 • どのお客さんからの依頼 • 審査の難易度(この判別方法によっては更なる分岐も発生しうる)
システムが人間を『支援』するのか『代替』 するのか、認識がズレていることが問題! (だと思った)
(説得してもなかなか伝わらなかったので) なんでこうなるのか考えてみた
幻想 システム化すれば人の業務は全て自動化できてなんか色々うまくいく(はず) • ぷろぐらみんぐとかふれーむわーくってなんでもできるんでしょ?という誤解 • 人間の複雑な思考も全部代替することが可能、と思われている(気がする) (いわゆる「技術的には可能です」の言葉の意味とか解釈の話にも繋がるかなと思っている)
現実 人間が作るものである以上、限界はあると思っている 業務システムは所詮ただの道具、ツールに過ぎないのではないか • 複雑な道具は誰も使いこなせない ◦ 業務側:仕様を把握しきれず、使いこなせない ◦ エンジニア側:メンテで疲弊。最悪システムが機能不全になる
システムの機能は大きく分けて2種類 • 確実に仕事してほしい機能 ◦ ボタン(保存ボタンとか。押した通りのことが起きる) ◦ 一覧画面 ◦ 詳細画面 ◦
バッチ • 大体仕事してくれればいい機能 ◦ 複雑なビジネスロジックをプログラミングで表現した機能 ◦ 人力でやっている作業のうち、単純でよくある処理を担当 ◦ 多少の取りこぼしは運用でカバーする
機能の守備範囲の線引きをきちんと行う 人間が行っている作業をどこまでシステム化するか考える • 時には割り切りが必要(ここまでやってくれればあとは人力でなんとか、!) • メンテコストと運用コストを考えた上で折衷案が理想 確実に動かないといけない範囲 なんとなく業務をカバー してくれたら嬉しい範囲
エンジニアの役割 • ただ要望通りにコードを書くことではない。 • ソフトウェア開発の原則(KISSとかDRYとか色々)などの専門知識を持ち ビジネスサイドと違った視点から提案、議論するようもっていくのが重要 →(だと思ったので、色々勉強中、、、)