Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Sign up for free
Menu
Search
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Pricing
Search
Sign in
Sign up for free
完璧主義にこだわり続けるとシステム開発は不幸になると思った
Search
5hun
November 13, 2025
Programming
53
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
Rubyで理解する音響信号処理 音をふわっと立ち上げる編 / Audio Signal Processing in Ruby, Part: Soft Attack Envelopes
5hun
1
47
Rubyで理解する音響信号処理 ADSR編 / Audio Signal Processing in Ruby, Part: ADSR
5hun
1
53
2026年、OSSコントリビュート初心者の歩き方 〜軽い一歩を、軽いままにしないために〜 / oss-contribution-for-beginners-2026
5hun
0
1.6k
Sine Wave By Ruby
5hun
1
80
Rubyと演奏したい〜その第一歩〜.pdf
5hun
1
90
Array#forty_two
5hun
0
95
与信管理を形にする: Ruby の柔軟性が支える高速データ収集・自動化基盤
5hun
1
430
ぼっちが秘める可能性〜孤高のRubyistが語る交流会サバイバル術〜
5hun
1
70
君もRailsもアップグレード!
5hun
1
30
Other Decks in Programming
See All in Programming
AIがコードを書いてくれる時代、我々は何を確かめるのか
yosuke_furukawa
PRO
13
5k
3回つくってわかった、 定期実行ジョブ基盤の本質情報
takai
4
3.4k
When benchmarks go bad - what I learned from measuring performance wrong
hollycummins
0
250
エージェントを使い続けるためのメタワーク / Meta-work for keeping using the agent
rkaga
6
2k
Zero-Tap Sign-In対応、結局何をすればいいの?
mitohato14
0
1k
動画プレイヤーはなぜカクつくのか 〜Flutterのレンダリングとネイティブの境界を解剖する〜
naruogram
0
190
PyConTW 2026 - AI Coding 不只是工具升級, 區域醫院醫療資訊系統協作開發與資訊團隊轉型實踐
cclai999
0
210
graphql-ruby を Spinel で速くしようとした話
mtsmfm
0
130
[Dev Group Paris Octobre 26] Agentforce, SIforce, Claudeforce, Slackbot… on s'y retrouve ?
nabondance
0
120
dotNET_vulnclicker_intro.pdf
deka_morita
0
160
続・コーディングルールの鮮度を保ちたい / keep-fresh-go-internal-conventions-again
handlename
0
140
JIS keyboard support in Omarchy
lef237
0
170
Featured
See All Featured
Build your cross-platform service in a week with App Engine
jlugia
234
19k
The Curse of the Amulet
leimatthew05
3
16k
Leadership Guide Workshop - DevTernity 2021
reverentgeek
1
410
State of Search Keynote: SEO is Dead Long Live SEO
ryanjones
0
330
AI Search: Where Are We & What Can We Do About It?
aleyda
0
8.1k
How to Think Like a Performance Engineer
csswizardry
28
2.9k
Sam Torres - BigQuery for SEOs
techseoconnect
PRO
0
590
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
659
62k
Facilitating Awesome Meetings
lara
57
7.2k
Taking LLMs out of the black box: A practical guide to human-in-the-loop distillation
inesmontani
PRO
3
2.5k
brightonSEO & MeasureFest 2025 - Winning Strategies for Black Friday CRO & PPC - Christian Goodrich
cargoodrich
3
880
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とか色々)などの専門知識を持ち ビジネスサイドと違った視点から提案、議論するようもっていくのが重要 →(だと思ったので、色々勉強中、、、)