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
5hun
November 13, 2025
Programming
51
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
2026年、OSSコントリビュート初心者の歩き方 〜軽い一歩を、軽いままにしないために〜 / oss-contribution-for-beginners-2026
5hun
0
1.2k
Sine Wave By Ruby
5hun
1
60
Rubyと演奏したい〜その第一歩〜.pdf
5hun
1
68
Array#forty_two
5hun
0
75
与信管理を形にする: Ruby の柔軟性が支える高速データ収集・自動化基盤
5hun
1
360
ぼっちが秘める可能性〜孤高のRubyistが語る交流会サバイバル術〜
5hun
1
47
君もRailsもアップグレード!
5hun
1
23
OSSコントリビュート初体験:Rubocopのバグを修正した話
5hun
0
53
地道なリファクタを続けてRspec高速化した話
5hun
0
86
Other Decks in Programming
See All in Programming
Apache Hive: そしてCloud Native Lakehouseへ
okumin
1
210
Cloudflare is Agents
chimame
0
150
AIが無かった頃の素敵な出会いの話
codmoninc
1
390
自動化したのに回らないテスト運用の壁ーAI時代の品質責任と生産性
mfunaki
0
130
FDEが実現するAI駆動経営の現在地
gonta
2
270
Lean は証明の正しさを確認するためだけのツールって思ってませんか?
inoueasei
1
150
今さら聞けない .NET CLI
htkym
0
180
【QA Test Talk Vol.8】AI-DLC による Whole Team Approach の加速
pkshadeck
PRO
0
120
ビデオ通話が繋がる0.2秒で何が起きているのか
supurazako
2
180
琵琶湖の水は止められてもNet--HTTPのリトライは止められない / You might be able to stop the water flow of Lake Biwa but you can't stop Net::HTTP retries
luccafort
PRO
0
610
ドリフトを絶対に許さない(?)CDK運用 / CDK Ops with Zero Tolerance for Drifts (?)
akihisaikeda
1
180
仕様駆動開発の消費期限
watany
16
7.3k
Featured
See All Featured
Being A Developer After 40
akosma
91
590k
How to Talk to Developers About Accessibility
jct
2
490
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
49
3.5k
Game over? The fight for quality and originality in the time of robots
wayneb77
1
240
Rebuilding a faster, lazier Slack
samanthasiow
85
9.6k
Lightning Talk: Beautiful Slides for Beginners
inesmontani
PRO
2
630
Claude Code のすすめ
schroneko
67
230k
Designing for humans not robots
tammielis
254
26k
30 Presentation Tips
portentint
PRO
1
360
How to build an LLM SEO readiness audit: a practical framework
nmsamuel
1
840
Typedesign – Prime Four
hannesfritz
42
3.1k
Design in an AI World
tapps
1
280
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とか色々)などの専門知識を持ち ビジネスサイドと違った視点から提案、議論するようもっていくのが重要 →(だと思ったので、色々勉強中、、、)