Mark Richards , Neal Ford (著)
オライリージャパン (2022/3/8)

すべてはトレードオフ？

さて、次は『ソフトウェアアーキテクチャの基礎 』。

この本を読もうと思ったのは、開発における代表的なパターンを最低限掴んでおきたかったからだ。ただ同時に、ソフトウェア領域の知見が、組織やBIMそのものを考えるためのヒントになるのではないか、という期待もあった。

本書は、システムにはどのような指標や特性があり、どのようなアーキテクチャスタイルが存在するのかを整理してくれる。その中で繰り返し強調されているのが、「すべてはトレードオフである」という主張だ。

ここで、以前から感じていた大きな疑問が頭に浮かんだ。

「すべてはトレードオフである」という考え方自体は、建築設計をしていれば日常そのものだ。むしろ、建築設計者ほどトレードオフ判断に揉まれている人はいないはずだと思う。

それなのに、ソフトウェアや組織の話になると、なぜこんなにもアンチパターンに陥りやすいのだろうか。
これは能力や経験の問題なのか。それとも、そもそも前提にしている考え方が違っているのか。

同じトレードオフなのに、なぜ結果が変わるのか？

トレードオフ判断が求められる、という点だけを見れば、建築設計も、組織やソフトウェアの設計も大きくは変わらないように思える。どちらも複数の要件を同時に満たすことはできず、何かを選び、何かを捨て続ける仕事だ。

それにもかかわらず、同じ人間が、建築設計の場面では比較的うまく判断できているのに、組織やソフトウェアの文脈に移った途端、アンチパターンに陥ってしまう例を何度も目にしてきた。自分自身も、その例外ではない。

これは本当に、個人の能力や経験の問題なのだろうか。
それよりも、扱っている対象が変わることで、トレードオフの前提そのものが変化しているのではないだろうか。

『ソフトウェアアーキテクチャの基礎』では、アーキテクチャにはさまざまな特性があり、それらを理解し、どれを優先し、どれを犠牲にするのかを意図的に選び取ることが重要だと繰り返し述べられている。

そう考えると、建築設計と、組織やソフトウェアの設計とでは、そもそも重視されるアーキテクチャ特性が異なっている可能性が高い。

つまり、問題は「トレードオフ判断ができるかどうか」ではなく、どの特性の間でトレードオフが発生しているのかを、正しく捉えられているかどうかにあるのではないか。

前提が違えば、求められる特性も違うはず

ここまで考えてくると、一つの仮説が浮かび上がってくる。

建築設計と、組織やソフトウェアの設計とでは、トレードオフ判断が求められる点では共通しているものの、そもそも前提にしている状況が違うのではないか、という仮説だ。

少し乱暴に整理すれば、建築設計は、複雑な条件を引き受けながらも、最終的には一つの状態へと収束させていくことが求められる。一方で、組織やソフトウェアは、完成することよりも、変わり続けることそのものが前提になっているように見える。

もしこの認識が大きく外れていないとすれば、両者において重視されるべき「良さ」や「強さ」は、同じであるはずがない。

本書では、こうした「良さ」や「強さ」を、アーキテクチャ特性として整理している。特性とは、性能や規模といった単純な数値だけではなく、変更のしやすさや理解のしやすさといった、設計判断に直結する性質のことだ。

もし、優先すべき特性の見立てを誤れば、行為や組織に対する設計判断もまた誤った方向に進みやすい。
ここは重要なポイントだと思うので、いったん立ち止まって、特性を言葉にして整理してみたい。

建築設計が、無意識に最適化してきた特性

まずは、建築設計について考えてみたい。

建築設計の現場では、「どの特性を優先するか」を明示的に定義することはあまりない。しかし実際には、設計者は常に複数の要件のあいだでトレードオフ判断を重ねている。

建築設計には、建物の完成という一つの時間的ゴールがある。そのため、構造・法規・コスト・施工性・使われ方・空間的な質といった、めちゃめちゃに絡み合った条件を、経験や直感も含めて総合的に判断する、というやり方が成立する。
むしろ、そのような判断でなければ解けない問題も多い。

このとき設計者は、個々の条件を一つずつ最適化するというよりも、多少の歪みや矛盾を引き受けながら、最終的に一つの状態として成立させることを目指す。判断は不可逆であり、その重さを引き受けるのも設計者自身だ。

結果として、建築設計では、

• 全体として破綻なくまとまっていること
• 一貫した構成や意図が感じられること
• 例外的な条件も飲み込んだ上で成立していること

といった特性が、暗黙のうちに強く最適化されてきたように思う。

こうした設計のあり方は、建築という文脈においては極めて合理的であり、実際に多くの場面でうまく機能してきた。設計経験のある人であれば、この感覚には少なからず覚えがあるのではないだろうか。

組織やソフトウェアで、強く求められているもの

次に、組織やソフトウェアの開発分野について考えてみたい。

この領域では、建築設計とは異なり、明確な「完成」という一点に向かって設計が収束していくことはあまりない。多くの場合、コードや組織は、継続と更新、そして進化そのものを前提として存在している。

要求は固定されず、途中で前提が変わる。関わる人も入れ替わり、設計や実装の判断が、常に同じ人の手に集約され続けることもない。むしろ、そうならないことの方が健全だとされる場面も多い。

このような状況では、「一度きれいに完成させる」ことよりも、「変わり続けられる状態を保つ」ことの方が重要になる。設計とは、何かを完成させるための行為というよりも、変更や更新が繰り返される中で、破綻せずに持ちこたえるための条件を整える行為に近い。

その結果、組織やソフトウェアの設計では、建築設計とは異なるアーキテクチャ特性が優先されやすくなる。たとえば、多少の非効率や重複があったとしても、それが変更や修正を容易にするのであれば、許容される。整っていることや美しくまとまっていることよりも、壊しやすく、直しやすいことが価値になる。

こうした前提の違いを意識しないまま、建築設計で有効だった判断の仕方をそのまま持ち込むと、意図とは裏腹に、アンチパターンに突っ込んでいってしまう。多くのコードや組織で同じような問題が繰り返されるのは、このあたりに原因があるのではないかと感じている。

同じトレードオフでも、軸が違っていた

ここまでを並べてみると、少し見え方が変わってくる。

建築設計と、組織やソフトウェアの設計は、どちらもトレードオフ判断の連続であることに違いはない。しかし、そのトレードオフが発生している「軸」は、実はかなり違っているのではないか。

建築設計では、建物の完成という一つの時間的ゴールに向かって、複雑に絡み合った要件を同時に引き受け、総合的に判断し、まとめ上げることが求められる。多少の矛盾や歪みがあったとしても、それらを飲み込みながら、最終的に一つの状態として成立させる力が重要になる。

この文脈では、判断を一箇所に集めた方が合理的だ。経験や直感を持った人が全体を引き受けることで、設計は前に進み、品質も担保しやすい。属人化は、この状況においては必ずしも問題ではなく、むしろ自然で、有効な戦略でもある。

一方で、多くのコードや組織は、完成に向かって収束することを前提としていない。継続と更新、そして進化そのものが主軸となり、状況は変わり続ける。関わる人も入れ替わり、すべての判断を同じ人が引き受け続けることは、現実的でも健全でもない。

この文脈では、すべてを同時にまとめ切ることよりも、変更し続けられる状態を保つことが優先される。

判断が集まる設計、判断が分かれる設計

組織やソフトウエアアーキテクチャの文脈では、判断は分散され、役割や境界が明確であること、引き継ぎやすいこと、壊して直せることが価値になる。多少の非効率や重複があっても、それが変更容易性につながるのであれば、許容される。

（※厳密にはこれらの判断は優先順位によって変わる。あるアーキテクチャスタイルでは許容は致命傷だが、他のスタイルだと別の価値とトレードオフとして許容される）

実際の組織を少し引いて観察していると、もう一つ興味深い傾向が見えてくる。
建築設計出身のメンバーが多い場合、建築設計における判断の集約性を前提として、無意識のうちに自分を「ボス」ではない「スタッフ」として位置づけてしまう人が少なくないように感じる。

建築設計の文脈では、これは極めて自然な振る舞いだ。最終的な判断を引き受ける人が明確に存在し、他のスタッフはその判断を支える役割に回る。その構造の中で培われた感覚が、そのまま組織や開発の場に持ち込まれている。

しかし、継続と進化が前提となる組織では、それぞれの「メンバー」が組織的な文脈を踏まえてトレードオフを判断し、自律的に行動すること自体が、重要なアーキテクチャ特性になる。にもかかわらず、「スタッフ」として振る舞うことで、意識的に判断を手放し、行動を抑制してしまう場面が生まれているように見える。

ここでも起きているのは、姿勢や意欲の問題ではない。

判断を集約する設計に最適化された経験が、判断を分散させる設計においては、別の振る舞いとして現れているだけなのだ。

完成を前提とした設計では合理的だった属人化や判断の集約は、継続と進化が前提の世界では、仕組み化の遅れや人海戦術を招く。判断が人に紐づくことで、スケールすればするほど調整コストが増え、慢性的なリソース不足が生まれる。結果として、本来顧客に提供する価値を高めるための仕事に時間やエネルギーを割けず、「対応」に追われ続ける構造が固定化されてしまう。

ここで強調しておきたいのは、どちらの判断も、その置かれた文脈では合理的だったという点だ。
判断が間違っていたのではない。トレードオフを取っていた軸が違っていただけなのだ。

この軸の違いを意識しないままでは、善意と努力にもかかわらず、アンチパターンに陥り続けてしまう。その理由は、個人の能力や姿勢ではなく、設計が前提としている世界の違いにあるように思える。

特性として整理してみると、何が起きているのか

ここまでを踏まえた上で、本書にならい、建築設計と組織・ソフトウェアの設計で重視されがちな特性を、それぞれ整理してみたい。

あくまで一般的な傾向としてのラフな整理ではあるが、建築設計では次のような特性が強く最適化されてきたように思う。

• 統合性（全体として一つにまとまっていること）
• 判断の集約性（設計判断が一箇所に集まっていること）
• 完結性（完成時点で破綻なく成立させる）
• 一貫性（意図や構成がぶれていないこと）
• 例外処理能力（矛盾や無理を引き受けて成立させる力）

一方で、組織やソフトウェアの設計では、次のような特性が優先されやすい。

• 分離性（影響範囲を限定できること）
• 判断の分散性（誰か一人に依存しないこと）
• 進化継続性（使われながら継続的に変わり続ける）
• 変更容易性（後から直せること）
• 引き継ぎやすさ（矛盾や無理を抑えて人が変わっても回ること）

重要なのは、これらが単なる違いではなく、多くの場合トレードオフの関係にあるという点だ。
統合性を高めれば高めるほど分離性は下がり、一貫性を強く求めれば変更容易性は犠牲になりやすい。

この整理で見えてくるのは、建築設計が優秀な人、すなわち「まとめ上げる」成功体験を強く持っている人ほど、無意識のうちに前者の特性を最大化しようとし、その結果として後者の特性を損なってしまいやすい、という構造だ。

これは能力の問題ではない。
むしろ、成功体験があるからこそ、アンチパターンに深く入り込んでしまう。

では、どう考えればよいのだろうか。

ここで重要なのは、建築設計者が持っている強みを捨てることではない。
「まとめる力」や「全体を引き受ける力」を、そのまま組織やソフトウェアに適用するのではなく、反転させて使うことはできないだろうか。

たとえば、自らが判断を引き受けるのではなく、判断が分散されるための条件を設計する。
一つにまとめ上げるのではなく、壊れても直せる境界を先に定める。
完成度を高めるのではなく、未完成のまま動き続けられる状態を成立させる。

そう考えると、組織やソフトウェアにおいて設計者に求められている役割は、「完成させる人」ではなく、変わり続けられる前提を整える人なのだろう。

建築設計的性向の強い組織では、これはなかなか難しいかもしれない。
それでも、まずは前提を整え、変化そのものを起こすしかない。

「場合による」から逃げずに、立ち向かうために

ここまで、建築設計と、組織・ソフトウェアの設計において、重視されがちな特性の違いを整理してきた。ただし、ここで強調しておきたいのは、どの特性を優先すべきかに、あらかじめ決まった正解があるわけではない、という点だ。

本書でも、「場合による（It depends）」という言葉が、繰り返し登場する。
これは判断を放棄するための言葉ではなく、文脈を無視した最適解は存在しないという、極めて厳しい前提を示している。

完成を急ぐべき局面もあれば、変更容易性を最優先すべき局面もある。
判断を集約した方が前に進む場合もあれば、あえて分散させた方が持続する場合もある。
重要なのは、どの特性を選び、どの特性を犠牲にしているのかを、意図的に引き受けているかどうかだ。

ここで、建築設計者の経験は決して不利ではない。
むしろ、トレードオフ判断に日常的に揉まれてきた設計者だからこそ、「場合による」という言葉の重さを、感覚として理解しているはずだ。

建築設計では、常に不完全な条件の中で、何かを選び、何かを捨て、それでも成立させる判断を積み重ねてきた。
その経験は、組織やソフトウェアにおいても、特性を選び取る行為そのものには、確実に活きる。

必要なのは、「完成させる力」をそのまま持ち込むことではなく、
どの特性を優先するべき局面なのかを見極め、その選択がもたらす結果を引き受ける姿勢なのだと思う。
そして、完成の一点を見つめるのではなく、継続する時間の流れの先へ目線を少し上げる。

属人化も、仕組み化も、リソース不足も、すべてはトレードオフの結果として現れる。
だからこそ、それらを単なる失敗として切り捨てるのではなく、「何を優先してきた結果なのか」を問い直すところから、次の一手が見えてくる。

建築設計という厳しいトレードオフの世界で揉まれてきた設計者だからこそ、この「場合による」という前提から逃げずに、組織やソフトウェアに立ち向かうことができるはずだ。