フラストレーション駆動開発：苛立ちを根本解決のエネルギーに変える
概要¶
繰り返し依頼される同じ作業に苛立ちを感じたとき、良いエンジニアはこなして次に進む。優秀なエンジニアは腹を立て、悪態をつき、その上で根本解決する。 フラストレーションは最大の財産であり、ロードマップに載っていなくても現場の摩擦をなくすものを作ることが永続的な価値を生む。
詳細¶
良いエンジニア vs 優秀なエンジニア¶
良いエンジニア：
同じことを何度も頼まれる → こなして次に進む
優秀なエンジニア：
同じことを何度も頼まれる → 腹が立つ → 悪態をつく
→ 「なぜ毎回これを手動でやっているのか？」と問う
→ 根本解決する
摩擦の種類別・根本解決のパターン¶
| 繰り返しの摩擦 | 根本解決 |
|---|---|
| 文言の修正依頼が何度も来る | CMSを作る |
| データベースのデータ操作が続く | 管理UIを作る |
| 同じ質問が止まらない | ダッシュボードを作る |
| 同じ手順を繰り返す | スクリプトを書く |
| 処理が遅い | お金を払って解決する |
| 手動テストばかりしている | テストコードを書く |
実例1：CI/CDの速度問題¶
問題:
エンジニアたちが「CI/CDが遅い」問題について何時間も議論
→ 議論に費やす人件費が増え続ける
解決:
議論の空転に苛立ち、会社のカードで高性能なGitHubワーカーを契約
結果:
CI/CD待ち時間: 10分 → 2分
議論に費やした人件費より遥かに安価に解決
実例2：Webサイトの権限管理¶
問題:
新人が入るたびに手動で権限設定を行っていた
→ 嫌気がさした
解決1（5分）:
会社のメールアドレスでサインアップすれば自動で権限付与
さらに:
細かい役割設定を依頼されるようになった
→ AIを使ってマネージャーが自分で操作できるUIを構築
→ 自分の仕事をゼロにした
実例3：請求書の計算ロジック¶
問題:
古い契約条件が複雑に絡み合う請求計算
ミスが許されないがエッジケースが多い
解決:
AIを使って複雑なエッジケースをテストケースとして記述
20秒ですべてのテストを実行できる環境を整備
結果:
ミスが許されない業務での安心感を手に入れた
フラストレーション駆動開発の原則¶
1. 退屈な作業への苛立ちを感じる感性を大切にする
→ 「また来た」と感じたら解決のシグナル
2. ロードマップに載っていなくても作る
→ 現場の摩擦をなくすものは常に価値がある
3. 作業ではなく成果に注目する
→ 「何をやったか」より「何をなくしたか」
4. 自分をクビにするようにコードを書く
→ 自動化・仕組み化で自分が不要になるように設計する
→ これが永続的な価値を生む
「自分をクビにする」という発想¶
なぜ重要か / いつ使うか¶
- 「またこれか」と思ったときに自動化・仕組み化に踏み切る判断軸として
- スプリントのバックログに自己申告で改善タスクを追加する根拠として
- チームの DX（Developer Experience）改善を提案するときの説得材料として
- 「ロードマップにないからやらない」という思考パターンを壊すきっかけとして