設計の正体：認知負荷を制御し、チームの判断力を最大化する境界設計の極意

現場でコードを書いていて、ふと立ち止まる瞬間がある。「この関数は本当に分けるべきか？」「このテーブルは正規化すべきか、それともパフォーマンスのために非正規化すべきか？」といった問いだ。世の中にはDDD、マイクロサービス、クリーンアーキテクチャといった煌びやかな設計原則が溢れているが、それらを適用してもなお、現場の変更コストが下がらないという現実に直面するエンジニアは多い。なぜなら、多くの設計原則は「手段」であって「目的」ではないからだ。私は、設計の本質とはコードの分割そのものではなく、「誰が、何を、どこまで一度に考えなければならないか」という認知負荷の制御にあると確信している。

例えば、関数を細かく分けたとしても、その関数を理解するために引数と戻り値を頭の中でパズルし続けなければならないなら、それは設計の失敗だ。クラスを責務ごとに分割しても、仕様変更のたびに10個のクラスを同時に開かなければならないなら、それは「分けたつもり」になっているだけである。変数名一つとっても、それが単なるラベルではなく、読み手が意味を再ロードするコストを削減するための「認知の圧縮」であると捉え直す必要がある。良い設計とは、必要な情報を必要なときにだけ頭に載せ、それ以外を一時的に忘れることができる状態を作ることだ。この「認知の境界」という視点を持つだけで、変数名からマイクロサービスの境界設計まで、すべての設計原則が同じ文脈で語れるようになる。

我々エンジニアが陥りがちな罠は、設計を「コードの構造」という静的なものとして捉えてしまうことだ。しかし、設計とは動的な「判断のプロセス」である。ある変更を行う際、どの情報を同時に参照し、どの判断をどこで下すのか。この「判断の単位」をチームの認知容量に合わせることこそが、持続可能なシステムを作る唯一の道だ。熟練したエンジニアが個人の記憶力でカバーしている設計は、一見すると美しく見えるが、それは設計が優れているのではなく、単にその人の認知負荷が異常に高いだけである。チーム全体が、通常の運用の中で無理なく扱える大きさへ境界を合わせる。これこそが、シニアエンジニアとして私が最も重視する設計の要諦である。

コンウェイの法則を単なる「組織とシステムが似る」という現象論として片付けてはならない。これは、組織が持つ「認知の境界」がソフトウェアの構造に強制的に投影されるという、極めて現実的な制約の話だ。チームの境界を越えるたびに、意味を相手の認知へ載せ直すコスト、つまり「翻訳コスト」が発生する。このコストが積み重なると、システムは分断され、変更は困難になる。逆コンウェイ戦略が有効なのは、単に組織図を書き換えるからではなく、ソフトウェアが要求する認知の単位に合わせて、組織が情報を保持し、判断できる単位を再構築するからだ。

ここで重要なのは、設計の順序である。多くの現場では、まず実装の形（マイクロサービスにするか、モノリスにするか）から議論が始まる。しかし、本来の順序は「業務上の意味 → 一緒に行う判断 → 誰が扱うか → 認知境界 → 実装」であるべきだ。この順序を無視して、流行りのアーキテクチャを導入しても、認知負荷が分散されるどころか、サービス間通信や分散トランザクションという新たな認知負荷が加わるだけである。マイクロサービス化は、認知負荷を消す魔法ではなく、一つの大きな認知負荷を、複数の局所的な負荷と、境界をつなぐ負荷へ「分け直す」作業に過ぎない。

以下の表は、設計原則を「認知境界」という観点から再定義したものである。これらは個別の暗記項目ではなく、すべて「認知負荷の調整」という一つの目的のために存在している。

設計において、認知容量は万能な正解ではない。性能、トランザクション、法規制、予算といった「認知以外の制約」は常に存在する。しかし、認知容量を「設計の入口」として使うことは、極めて強力な武器になる。まず、人やチームが扱える大きさを考え、その上で現実的な制約を重ねていく。この折り合いをつける作業こそが、エンジニアの腕の見せ所だ。あなたが明日から取り組むべきは、コードの行数を減らすことではなく、チームが「何を考えなくてよいか」を明確に定義することである。あなたの設計は、チームの認知容量を圧迫していないだろうか？ 熟練者の記憶力に依存した「脆い設計」を、チーム全体で共有可能な「強い境界」へと昇華させる準備はできているだろうか？