設計とは全体を部分に分割することである

そして設計の本質は
「不確実性を、意図的に選んだ場所に閉じ込めようとすること」だ

以上、言いたいことは言った
後の内容はここまで言ったことに、ただ補足を入れてるだけのようなものである

その前になぜこんなものを書いているか(どこで分割するか)

今、あるいは以前は、「不確実性を閉じ込める場所」の多くがコードやドキュメント、人間の担当者にあった
生成AIが進歩しても設計の本質は変わらないと確信しているが、人がどのくらいまで設計するのか？
また、巨大なコンテキストウィンドを持つAIにとっては分割せずただ記述するだけのほうが合理的になるかもしれない

生成AIによって設計の概念が変わるかもしれない最後の世代で、私はこんなことを考えて設計していたというのを備忘録として残すためである

補足開始

では補足として、「設計」とは何か？
もう少し言葉を尽くして言う
「設計」をするとは、「複数の視点」から、「全体」を、「部分」に、「適切な粒度まで」、「分割」する
ことである

そして、「全体を部分に分割する」という概念は再帰的に適用できる

また「計画」も私の考えでは、設計することに内包すると考える
「計画」においても「設計」と統一的な定義で説明可能と考えているが、単純化のためにここでは分割し、別途説明する

なぜ分割するか

「不確実性を、意図的に選んだ場所に閉じ込めようとすること」だが、
あえて即物的に設計をする事の効能を言うなら以下のようなものである

• 複雑な抽象的概念を、理解可能な具体的な部分まで分割することができる
• 必要な知識の範囲が狭まり難易度を下げることができ、自分や他人が理解しやすくなる
• 複数人で分担して作業をすることができる
• 人数に応じて作業の全体期間を短くすることができる可能性が上がる
• 状況、状態のコントロール可能性が上がる
• 何か前提条件に変化があっても、全体を壊さず部分を変更できる

どのように分割するか

では全体はどのような概念であれば分割しえるか？
端的に分割のフレームワークを示すならそれは5W2Hである
以下のように5W2Hのそれぞれに繋がる言葉は「XXXに分割する」である

設計七徳ナイフ

• When（いつ）に分割する　→　スケジューリング、タイムライン、フェーズ分割
• Where（どこで）に分割する　→　ロケーション、拠点、場所ごとの分割
• Who（誰が）に分割する　→　担当者やチームごと
• What（何を, 何に）分割する　→　タスクや構成要素ごと
• Why（なぜ）分割する　→　目的ごとの分割、または優先順位付け
• How（どのように）分割する　→　方法論や手順による分割
• How much（いくらで, どのくらいまで）分割する　→　予算、コスト配分、資源配分

全体に対してこのようなフレームを適用することで、部分を漏れなく分割することができる
あえて漏れなくかぶり無く（MECE）とは言わない、漏れなくかぶり有り、だ
これについては後程補足する
（MECEを否定する意図はない、MECEは情報の整理のために大変役立つ思考のフレームワークである）

以下の部分は設計が内包する部分の中で、計画の要素が強い部分である

• When（いつ）
• Who（誰が）
• How much（いくらで）

何に分割するか

この5W2Hの単一の写像を具現化したものはすでに現実に名前をもって存在する
それが、設計書である

写像ってなんすか

現場でよく用いられる設計書の例を以下に示す

• When（いつ）に分割する
  • スケジュール／フェーズ／タイムライン
  • プロジェクト計画書、WBS＋スケジュール、リリース計画
• Where（どこで）に分割する
  • 拠点・環境・配置
    • 環境構成図、サーバ構成図、拠点別作業一覧、ネットワーク構成図
• Who（誰が）に分割する
  • 体制・役割・担当者
    • 体制図、役割定義書、担当アサイン表、スキルマップ
• What（何を, 何に）分割する
  • タスク・機能・業務・構成要素
    • WBS、要件定義書、業務フロー、画面一覧・API一覧、データ定義書
• Why（なぜ）分割する
  • 目的・背景・優先順位
    • 企画書、KPI/KGI、優先順位マトリクス、プロダクト原則
• How（どのように）分割する
  • 手順・方法・技法
    • 作業手順書、テスト計画／手順書、運用手順書、技術設計書、コード規約
• How much（いくらで, どのくらいまで）分割する
  • コスト・工数・予算・資源配分・粒度の上限
    • 見積書、予算管理表、リソース配分計画書、スコープ境界の定義

これらはそれぞれ5W2Hの視点による情報投影の写像だったことが理解できる

どのくらいまで分割するか

ここがMECEのくだりの補足である

なぜあえて漏れなくかぶり無く（MECE）とは言わないなかったか
それは、5W2Hのうち1つでは単一の写像、射影であり、これから作ろうとしている全体が球なのか円筒なのか、写像ではわからないためである

また、単一の視点では何か一つを意図せず間違えたときに、それが本当に間違っているのか判断がつかない

昨今たまに言われるドキュメントが無いプロジェクトで、生成AIにコードから設計書を作らせればいいじゃんと言う発想には警鐘をならす
叩き台を作るためにはいいとしても、コードという単一の実体をもとにいくら写像を作ってもコードの間違った部分もそのまま間違ったまま設計書になる
仮に複数の視点の設計書を作ったとしても全て間違った無いようになる、これでは本当に何が正しいのかわからない

5W2Hの分割をもれなく行わなければ、設計をしていなかったり、サボっているというわけでもない
現場のレベル感に合わせて適切なレベルまで分割されていれば十分である

リソースは有限である、分割することにも有限のリソースを割くことになる
それに分割はしすぎると全体が見えづらくなる

ではどのくらいまで分割すれば適切なのか？という声が聞こえてきそうだが、汎化した概念の粒度で答えるならば、
分割された部分を割り当てられた、組織または個人が遂行可能な粒度まで
と答えるだろう
そういう意味では、世間でいうところのコンウェイの法則、逆コンウェイの法則は経験上真に迫ったものと感じる

いつ分割するか

リソース設計としての「計画」

ここでようやく計画に関する所見を述べる
設計のうち、最も早期に分化する要素のひと塊が一般的に言うところの「計画」の要素が強い部分だと捉えている

計画は実は製品そのものに対する設計ではなく製品に使えるリソースに対する設計である
そのため計画をしなくても、製品を作ることはできる

計画をしない事で成し得なくなる事は製品を作れなくなる事ではなく、製品を作るための人、お金、期間をコントロールできなくなる事である
このコントロールできなくなるとは必要リソースが無限になるとか、作れないと言うことを意味しない

むしろコントロールしない事でコントロールコストが不要になり早く安く製品が作れることもある
計画とは製品が計画したようにできる確率を上下させるものだからである

プロジェクト内の計画しなくても成立するような小さな単位まで計画してコントロールする事はリソースを圧迫する可能性がある

しかし、一定の規模を超えると計画しないメリットは計画するメリットをはるかに下回る
そしてリソースが不明確なプロジェクトは基本的に許可されない
（極度にチャレンジングなプロジェクトではリソースが不明確でもコンセプトが認められれば承認されることはある、生成AIの開発などはそれこそどのくらいの時間、どのくらいの金額がかかるかは誰もわからないが実際にプロジェクトが動いている）

誰が分割するか

設計のフラクタル性 新人も設計者

プロセスにかかわる人間すべてが、割り当てられた部分において設計者足り得る
10年選手のベテランアーキテクトでなく、新人であっても設計者になりえる

少し回りくどくなるが、
「設計=全体を部分に分割することである」は、「設計」という自分自身を説明することができる
設計という行為そのものもまた「全体を部分に分割する」という構造を内包している
設計とは自分自身を説明できる自己言及的なプロセスであり、階層を下っても上っても同じ構造が現れる点でフラクタルである

なぜそのような性質が生まれるかと言えば、設計は本質的に「どの粒度で、どの視点で、どの順序で分割するか」という複数の意思決定としての写像を伴い、その写像もまた分割しうる

つまり、誰かに仕事を割り当てられた新人であっても、割り当てられた部分をさらに分割=設計をすることになる

ここで、「誰が分割するか」だけでなく、「誰がどの不確実性を引き受けるのか」という問いもある。
設計とはコードやドキュメントだけでなく、人の時間と感情の上に不確実性を配置する行為でもある。
ただ、ここから先は組織設計や倫理の話になっていくので、本稿では踏み込まない。

最後に不確実性について

人間は有限の認知能力しか持たない、完全な設計を行うことはできない
未来のことは誰にもわからない、「A」が決まってないから「B」を決められない
そのように言っていると何も決められなくなりたちまちプロジェクトはコントロールを失う

設計者は限られたリソースのなかで、あらゆる不確実性と対峙しなければならない

• 顧客が満足しないかもしれないという不確実性
• プロジェクトが完了しないかもしれないという不確実性
• 品質が基準を満たさないかもしれないという不確実性
• 機能が動かないかもしれないという不確実性
• 顧客に要件を変更される不確実性
• 誰かにそんなこと言ってないって言われる不確実性
• 依頼した仕事が全然締め切り間近で全然終わってませんと言われる不確実性

「A」が最適かどうかはわからないが、ひとまず、「A」が合理的だと皆で信じることにして、「B」を決めよう。結局は、その積み重ねでしか前に進まない

だから設計は永遠に終わらない
無限の不確実性を持つこの世界では、設計は「今この瞬間に許容できる不確実性の量と場所を決める行為」にすぎないから

以上から、人が設計をする本質は「不確実性を、意図的に選んだ場所に閉じ込めようとすること」と結論する