ほとんどのプロジェクトは、コードが悪いから失敗するのではありません。
失敗する理由は：
実装が始まる前に、システムが明確に定義されていなかったからです。
そして、一度実装が始まってしまうと：
曖昧さを解消するためのコストは非常に高くなります。
実際に起きていること
オーナーは次のような要望を持ってやってきます：
「私たちのビジネスのためのシステムが必要です。」
表面上は、妥当な出発点のように聞こえます。
しかし実際には、そこにあるのは：
- 断片化されたワークフロー
- 一貫性のないデータ処理
- 文書化されていない意思決定ルール
- 「仕組み」に対する複数の解釈
- そして、何が正しいかという共通定義の欠如
そして、期待はこうなります：
「エンジニアリングが何とかしてくれるだろう」
そこが失敗の始まりです。
誰も名付けない「入力」の問題
彼らは手ぶらで来るわけではありません。
彼らは次のようなものを抱えてやってきます：
- 経験
- 直感
- 緊急性
- 資金
これらは一見、強みのように見えます。
その上に何かを築こうとするまでは。
なぜなら：
直感はシステムではない 経験は「過去にうまくいったこと」に偏っている 緊急性は「未解決の課題」を時間軸で圧縮したものに過ぎない 資金は「権威」を装ったプレッシャーである
これらはいずれも現実を定義しません。
むしろ、現実を歪めます。
そして、構築前に構造を強制しなければ：
あなたはシステムをエンジニアリングしているのではなく 誰かの混乱を形式化しているに過ぎません
なぜこれがエンジニアリングを壊すのか
エンジニアは通常、こう答えます：
「まずはシンプルに始めて、反復（イテレーション）しましょう」
それが機能するのは、課題が安定している時だけです。
しかし、ここでは：
- 構築の途中で要件が変わる
- 前提条件が後になって覆される
- 「シンプル」の定義が絶えず書き換えられる
- 実装後にエッジケースが次々と現れる
つまり、反復のように見えるものは実際には：
未定義の課題空間の中を漂流しているだけなのです
「システム診断」が強制するもの
アーキテクチャやコードに向き合う前に、次の5つの事項について明確にさせます：
1. 現状（Current State）
今日、実際に存在しているものは何か。
ドキュメントや意図ではなく、現実を見ます：
- 実際のワークフロー
- 実際のシステム
- 実際のデータフロー
2. 真の課題（Real Problems）
意見ではなく、具体的な失敗に焦点を当てます：
- どこでシステムが壊れるか
- どこでデータが乖離するか
- どこでユーザーが迷うか
- どこで手作業による補填が発生しているか
明確に述べることができないのであれば：
それはまだ理解できていないということです
3. 未知の事項（Unknowns）
ほとんどのプロジェクトが既に不安定なのはここです：
- 定義の欠落
- 文書化されていないロジック
- 暗黙的な人間による判断
- 「人によってやり方が違う」という振る舞い
最後の項目は極めて重要です。
「ケースバイケース」は、システムが存在しないことを意味します
4. 制約（Constraints）
願望ではなく、制約を直視します：
- 時間
- チームの規模
- 技術的負債
- 運用上の依存関係
- レガシーシステム
これらがなければ：
アーキテクチャは空想に過ぎません
5. リスク（Risks）
前提が崩れた時、実際に何が壊れるか：
- データの破損
- 誤った意思決定
- 目に見えない不整合
- システムの逸脱
これらをマッピングしておかなければ：
本番環境でそれらを発見することになります
診断の後に変わること
これらが適切に行われれば：
- 要求されたシステムの半分は不要になります
- 複雑さのほとんどが、実は不要なものだったと判明します
- 真の優先順位が明白になります
- スコープは縮小しますが、明快さは増します
そしてしばしば：
最初に思い描いていたものとは違うものが構築されます
それは失敗ではありません。
それこそが「修正」なのです。
なぜこのステップが飛ばされるのか
目に見えるアウトプットがないからです。
UIもありません。
デモもできません。
即時の報酬がないのです。
だから、人々はこれを飛ばします。
そして、後になってその代償を払うことになります：
- 書き直し
- 遅延
- 裏切られた期待
- 不安定なシステム
真実
システムが混沌としていると感じるなら：
それはエンジニアリングの課題ではありません
エンジニアリングが始まる前に解決されるべきだった「明快さ」の課題です。
そして、どれだけコードを書いても、それは解決できません。
代わりにすべきこと
何も書く前に：
- 実際の現状をマッピングする
- 具体的な課題を定義する
- 未知の事項を明示的にリストアップする
- 制約を正直に定義する
- フィルターをかけずにリスクを特定する
もしこれができないのであれば：
そのシステムは構築する準備ができていません
結論
エンジニアリングは明快さを生み出すものではありません。
既に存在しているものを増幅させるものです。
ですから、混乱から始めれば：
システムは手に入りません 手に入るのは、構造化された混乱だけです