小屋を建てろと言われたのに、要塞が必要だった話
小屋を建てろと言われたのに、要塞が必要だった話
はじめに
「シンプルなアプリでいいんです」
クライアントからそう言われて受けた案件が、気づいたら基幹システム級の開発になっていた。建築で例えるなら、「小屋を建ててほしい」と言われたのに、実際に必要だったのは要塞だったという話。
これは自分にとっての失敗事例であり、同時に一番学びが多かったプロジェクトの記録でもある。
何が起きたか
最初の認識
クライアントの要望はこうだった。
- 「今あるデータを見やすくしたい」
- 「そんなに複雑なものは求めてない」
- 「まずは使えるものを」
これを聞いて、自分はこう判断した。
よし、軽めのWebアプリで十分だ。フレームワーク選定もライトにいこう。
この判断が、すべての始まりだった。
見えてきた現実
開発を進めるうちに、次々と「隠れた要件」が出てきた。
- セキュリティ要件が想定の3倍厳しかった
- 外部システムとの連携が必要だった
- データ量が「数百件」ではなく「数万件」だった
- ユーザーの業務フローが複雑で、単純なCRUDでは収まらなかった
- 法令・コンプライアンス対応が必要だった
クライアントが「シンプルでいい」と言ったのは、クライアントの要望がシンプルだったからではない。クライアントが技術的な複雑さを把握していなかっただけだった。
途中から要塞に切り替える地獄
小屋の設計で始めた基礎の上に、要塞を建てようとした。当然、設計の根本からやり直しになった。
- フレームワークの選定をやり直し
- データベース設計を一からやり直し
- セキュリティ層を後付けで追加
- テスト計画の全面見直し
途中から要件が変わるのは、どんなプロジェクトでも起きる。でも「小屋 → 要塞」は、途中から変わるのではなく、最初の見積もりが根本的に間違っていた。
なぜ見誤ったのか
振り返ると、原因は3つに集約される。
1. クライアントの言葉を額面通り受け取った
「シンプルでいい」はクライアントの願望であって、事実ではなかった。
クライアントは自分の業務を毎日やっているから、その複雑さが「当たり前」になっている。当たり前のことは説明されない。だから「シンプルでいい」と本心から言う。でも、掘り下げると「当たり前」の中に巨大な要件が埋まっている。
教訓：クライアントの「シンプル」は、クライアントにとってのシンプルであって、システムにとってのシンプルではない。
2. 調査フェーズを省略した
うまくいった別のプロジェクトでは、技術選定に時間をかけた。1000ページ超のリファレンスをAIに取り込んで、ドメインの全体像を把握してから設計に入った。
このプロジェクトでは、「シンプルだから」という理由で調査フェーズを省略した。
教訓：調査に時間をかけたプロジェクトは成功する。軽く入ったプロジェクトは地獄になる。例外はない。
3. スコープの「深さ」を見なかった
スコープの「広さ」（画面数、機能数）は見えやすい。でも「深さ」は見えにくい。
- ユーザー認証が必要 → 「ログイン画面1つ」に見えるが、実際は権限管理、セッション管理、多要素認証、パスワードリセットフロー...
- データを表示する → 「一覧画面」に見えるが、実際はフィルタリング、ソート、ページネーション、エクスポート、アクセス権限...
- 外部連携する → 「API1本」に見えるが、実際はエラーハンドリング、リトライ、タイムアウト、データ変換、ログ、監視...
1つの機能の「深さ」を掘ると、そこに別の要塞がある。
今後のプロジェクトで実践すること
この失敗から、新しいプロジェクトを始めるときのチェックリストを作った。
スコープ検証チェックリスト
1. クライアントの「シンプル」を疑う
-
- 「データはどこから来ますか？」
- 「誰がどんな権限で使いますか？」
- 「法令やコンプライアンスで守るべきことはありますか？」
- 「将来的にどう拡張したいですか？」
2. 建物の規模感を最初に見極める
| 規模 | 特徴 | 期間目安 |
|---|---|---|
| 小屋 | 1人で使う、データ少量、セキュリティ低 | 1-2週間 |
| 家 | 数人で使う、外部連携なし | 1-2ヶ月 |
| ビル | 部署横断、外部連携あり、権限管理 | 3-6ヶ月 |
| 要塞 | 基幹業務、法令対応、大量データ、複数システム連携 | 6ヶ月-1年 |
小屋と要塞では、設計の根本が違う。途中からの切り替えは新規開発より高コスト。
3. 調査フェーズを絶対に省略しない
建築の比喩がなぜしっくり来るのか
小屋と要塞の違いは、単に大きさの問題ではない。
- 小屋は、基礎がなくても建てられる。壁を立てて屋根を載せればいい
- 要塞は、基礎がすべて。基礎が間違っていたら、上に何を建てても崩れる
ソフトウェアも同じで、小屋の基礎に要塞は載らない。
データベース設計、認証基盤、API設計、エラーハンドリング、ログ設計——これらの「基礎」は、最初に正しく作らないと、後から差し替えるのは全面改修に等しい。
だから「最初の見極め」がすべてを決める。
この失敗が教えてくれたこと
正直、このプロジェクトは今でも苦しい。でも、ここから得た学びは他のどのプロジェクトよりも大きかった。
設計に時間をかけたプロジェクトは成功する。軽く入ったプロジェクトは地獄になる。
これは自分のプロジェクト群を横断して、例外なく確認されたパターンだった。
成功したプロジェクトでは、1000ページ超のPDFをAIに食わせて技術選定を行った。別のプロジェクトでは、データ分析と設計に2週間をかけた。どちらも順調に進んでいる。
最初の「面倒くさい」を引き受けた者だけが、後の「地獄」を回避できる。
そして今、この失敗を含めた全プロジェクトの知見を蓄積して、次のプロジェクトの「立ち上げ工数」を劇的に下げる仕組みを作っている。
その話は、また別の記事で。