■ 1. 本質的な複雑性と偶有的な複雑性の定義
- 概念の出典: フレデリック・ブルックスの論文『銀の弾丸はない』で提唱された区別
- 本質的な複雑性:
- 問題領域に内包された、回避不可能な複雑性
- 例: 医療における麻薬処方の管理ルール（麻薬施用免許保持者による処方、鍵付き保管、処方箋の参照管理など）
- 偶有的な複雑性:
- 実装方法、技術的制約、または誤った解決領域の選択による複雑性
- 例: バッチ処理機能が存在しないために、ユーザーが一件ずつ手動でデータを登録しなければならない手間
■ 2. 模範解答とその前提
- 一般的な指針: 本質的な複雑性に向き合い、偶有的な複雑性を削減することが正解とされる
- 仮説としての区別の重要性:
- ふたつの複雑性を区別しなければ、既存業務の偶有的複雑性を維持するだけの不要な機能を作り込むリスクがある
- 本質的な複雑性を偶有的だと読み誤ると、業務上重要な仕様が満たされない事態が発生する
- 間主観的に削り出した区別があるかないかで、問題解決の筋の良さが大きく異なる
■ 3. 「本質性」の主観性という問題
- 「本質」はア・プリオリに存在しない:
- 問題そのものも、誰かが問題視することで初めて生じる
- 「問題の本質」は問題に内在せず、問題と対峙する人間の観察の中に存在する
- 本質性は観察者によって変化する:
- 誰が問題に向き合うかによって、何が本質的に見えるかは容易に変わる
- 議論参加者の間主観の中に生まれる「本質」は、問題に対してア・プリオリに存在するわけではない
■ 4. 実際の運用によって初めて明らかになる本質的複雑性
- 頭の中での検討は想像に過ぎない:
- 実際に動くシステムで実際の業務を行わなければ、何がどの程度解決できたか、どんな偶有的複雑性を持ち込んでしまったかは分からない
- 「ないものでないことをやっていても気づけない」という本質的な限界がある
- 本質的複雑性は実際の使用を通じて立ち現れる:
- ユーザーが実際のシステムを使ったとき、ユーザーと開発者の間主観の中に初めて形が見えてくる
- ア・プリオリに存在するものではない
■ 5. ふたつの結論
- 区別は仮説として立てるしかない:
- 何が本質的で何が偶有的かは自明ではなく、チームで知恵を絞って仮説を立てながらサービスを構築する必要がある
- 仮説の精度を高めることは重要
- 「本物の本質的複雑性」は実際の運用からしか発見できない:
- いくら仮説の精度が高くても、現実の運用を通じた学びなしには真の本質的複雑性は見出せない
■ 6. 技術的負債とドメインの蒸留
- 学びをシステムにフィードバックする重要性:
- 「本質的複雑性だと思ったものが偶有的だった（またはその逆）」という学びをシステムに反映し続けることで、チームの能力が育ちサービスは改善され続ける
- 学びとコードの乖離が技術的負債を生む:
- 学びは得られてもコードが変わらなければ、システムの現状と「学習された本質的・偶有的複雑性の分離」がどんどん乖離する
- これが本来の意味での技術的負債であり、「ドメインの蒸留」が示すのも学びをソフトウェア設計に再投資し続けることの重要性
- 本番環境のサービスは最大の学習の場:
- 最も学びが多く、最も負債が蓄積される場所でもある
■ 7. 著者のビジョン
- 本番の学びを軸とした継続的改善:
- 本番で得た学びをもとに技術的負債を解消し（新しい学びにマッチする構造へのソフトウェアの変更）、ソフトウェアを進化させ続ける
- 現場の偶有的複雑性をシステムが肩代わりすることで、現場が本質的複雑性に集中できる新機能を積極的に作り上げる
- この営みは新たな学びと負債を生み出し続ける、世界をよくするための永続的なサイクルを形成する
- 課題解決に従事するすべての人へのメッセージ:
- このビジョンを共有し、共に日々を過ごしていくことへの呼びかけ