1 導入
前回の記事では、『ソフトウェアアーキテクチャの基礎』第1章を手がかりに、
- 問い① ソフトウェアアーキテクチャとは何か？
- 問い② ソフトウェアアーキテクトの役割は何か？
の二つを整理した。
この本では、ソフトウェアアーキテクチャは4つの側面で定義され、ソフトウェアアーキテクトの役割は8つの期待として説明されている。さらに「すべてはトレードオフである」、「How より Why が重要」という2つの法則が、アーキテクチャ判断に共通する前提として示されている。前回の記事では、この枠組みを自分が理解しやすいように整理し直し、問い①・②に答えた。
ただ、ここまで押さえてもなお、次の問いが残る。
問い③ 「アーキテクトのように考える」とはどういうことか？
（＝アーキテクチャ観点で物事を見るには、どんな考え方・視点が必要か？）
これら三つの問いを抽象レベルで並べると、次のようになる。
| 問い | 中身 | 抽象化 |
|---|---|---|
| 問い① | ソフトウェアアーキテクチャとは何か？ | 対象の定義 |
| 問い② | ソフトウェアアーキテクトの役割とは何か？ | 担い手の役割 |
| 問い③（今回） | 「アーキテクトのように考える」とは何か？ | 考え方・視点 |
本記事は、『ソフトウェアアーキテクチャの基礎』第2章「アーキテクチャ思考」を読みながら、
この問い③についての自分の理解を言葉にしたものだ。
ここでは、アーキテクチャ思考を次の4つの観点から捉える。
- アーキテクチャと設計の関係と、開発チームとの協働
- 技術的な幅と深さ
- トレードオフの分析
- ビジネスドライバーの理解と、それをアーキテクチャ上の関心事に落とし込むこと
これらは第2章で提示されている整理を土台にしている。この記事では、その4つの観点を自分の言葉で噛み砕きながら、アーキテクトの考え方・視点を見直していく。
2 アーキテクチャ思考
ここからは、問い③「アーキテクトのように考えるとはどういうことか？」を扱う。
前回見たように、ソフトウェアアーキテクチャは4つの側面で定義され、
ソフトウェアアーキテクトの役割は8つの期待として説明されている。
さらに「すべてはトレードオフである」、「How より Why が重要」という2つの法則が、
アーキテクチャ判断に共通する前提として示されている。
これらの枠組みは、「何をアーキテクチャと呼ぶか」「アーキテクトに何が期待されるか」を整理するには十分役に立つ。
一方で、実際の判断の場面ではたとえば次のようなことが起きる。
- 同じようなテーマでも、プロダクトのフェーズやチームのスキル、制約によって「妥当な答え」が変わる
- 「A か B か」という二択ではなく、「どこまで A に寄せるか／どこまで B を妥協するか」を決めることが多い
つまり、アーキテクチャの多くの判断は、白黒の正解を当てるというより、
そのときの文脈の中でトレードオフの落とし所を選ぶ作業になる。
つまり、アーキテクチャの多くの判断は、白黒の正解を当てるというより、
そのときの文脈の中でトレードオフの落とし所を選ぶ作業になる。
『ソフトウェアアーキテクチャの基礎』第2章では、アーキテクチャ思考というテーマが扱われており、
アーキテクトらしく考え、アーキテクチャの観点で物事を見るための四つの側面として
- アーキテクチャと設計の関係と、開発チームとの協働
- 技術的な幅と深さのバランス
- トレードオフの分析
- ビジネスドライバーの理解と、それをアーキテクチャ上の関心事に落とし込むこと
が挙げられている。
ここでは、アーキテクチャ思考を
アーキテクトとしてどう物事を見て、どう判断するかを支える四つの力
- アーキテクチャと設計の違いを理解し、開発チームと協働してアーキテクチャを機能させる力
- 技術の幅と十分な深さを持ち、他の人が見落とす選択肢や可能性に気づく力
- 複数の案についてトレードオフを洗い出し、分析し、折り合いをつける力
- ビジネスドライバーを理解し、それをアーキテクチャ上の関心事に翻訳する力
として扱う。
この四つの力のうち、最初に扱うのは「アーキテクチャと設計の関係」と「開発チームとの協働」だ。
アーキテクトと開発者の間にどういう線が引かれているかで、そもそもの日々の会話や判断の前提が変わってしまうからである。
2.1 アーキテクチャと設計の関係と、開発チームとの協働
まずは一つ目の力である「アーキテクチャと設計の関係と、開発チームとの協働」から見ていく。
この関係性が現場でどう表れるかをはっきりさせるために、先に、よくある「上流から下流へ渡す」進め方を振り返り、
そのあとで、それと対照的な「双方向のコラボレーション」を見ていく。
2.1.1 従来の進め方：アーキテクチャと設計を分けて、上から下へ流す
最初に、アーキテクチャと設計をきれいに分けて「上流から下流へ渡す」従来のモデルを整理する。
このモデルでは、アーキテクトがアーキテクチャ特性やパターン、主要コンポーネントを決めて成果物にまとめ、それを開発チームに渡す。開発チームはその成果物を前提に、詳細設計と実装を進める。
この進め方では、アーキテクトから開発チームへの流れが一方向になりやすい。
その結果、
- アーキテクトの意図と、実際のコードや設計のあいだにズレが生まれやすい
- 実装の中で見つかった学びや制約が、アーキテクチャ側に戻りにくい
という問題が起きる。
アーキテクチャとコードのあいだに「壁」ができてしまい、時間がたつほど両者が離れていく。いったん離れ始めると、後から変化に追随させるのがどんどん難しくなる。
2.1.2 双方向のコラボレーションでアーキテクチャを機能させる
従来の「上から下へ渡す」進め方と対照的に、アーキテクチャをきちんと機能させるには、アーキテクトと開発チームのあいだの壁をなくす必要がある。アーキテクチャを「設計して渡すもの」としてではなく、同じチームのメンバーとして一緒につくっていく前提に変える。
アーキテクトと開発者が一つのチームとして動き、決定やフィードバックを双方向にやり取りし続ける。
そうすることで、
- アーキテクチャ上の意図と、日々の詳細設計やコードを常に合わせ続けられる
-
実装の中で見つかった学びや制約を、アーキテクチャ側の判断にも反映できるようになる。
アーキテクチャとコードが一体となって進化していくことで、変化にも対応しやすくなる。
こうしてアーキテクトと開発者が一つのチームとしてやり取りできるようになると、次に効いてくるのは「その会話の場に、どんな選択肢や見方を持ち込めるか」だ。
そこで次は、アーキテクトに求められる「技術的な幅と深さ」について考えていく。
2.2 技術的な幅と深さのバランス
アーキテクトの強みは、手を動かす力だけではなく、「この制約と目的なら、どんな選択肢があり、それぞれ何に向いているか」をチームに示せることにある。そのためには、特定の技術に深く詳しいだけでは足りず、複数の技術やパターンを並べて話せるだけの「幅」も必要になる。
では、アーキテクトは、技術の幅と深さをどうバランスさせればよいのか。ここでは、開発者とアーキテクトの役割の違いという視点から、「深さ」と「幅」の置き方を見ていく。
2.2.1 開発者の深さからアーキテクトの幅へ
開発者は、特定の言語やフレームワークを深く掘り下げる「技術的な深さ」が求められるのに対し、アーキテクトには、多様な技術・フレームワーク・ツールを横断的に把握する「技術的な幅」が求められる。
この違いを説明するために「知識ピラミッド」が使われており、キャリアのステージによって、ピラミッドのどの層の知識（深さ／幅）を重視すべきかが変わる、と示している。開発者からアーキテクトへと役割が変わるとき、どの層を厚くし、どの層を意識的に広げていくかが変わってくる。
そのイメージをつかむために、次にこの「知識ピラミッド」自体をもう少し詳しく見ていく。
2.2.1.1 知識ピラミッド
知識ピラミッドは、自分の技術的な知識がどのあたりに偏っているかを見直すためのシンプルな地図である。自分の知識は、常に次の3つのレベルのどれかに分類できると考える。
知識の三角形における知識の3つのレベル
-
「わかっていること（Stuff you know）」
- 日々の仕事で実際に使いこなしている技術・フレームワーク・言語・ツール。
-
例：普段から業務でコードを書いているプログラミング言語や、常用しているフレームワーク
（文献では Java や .NET, DDD, Agile など が例として挙げられている）。
-
「わかっていないとわかっていること（Stuff you know you don’t know）」
- 名前や概要・用途は知っているが、自分ではほとんど使えない・説明できない技術や概念。
- 例：「機械学習」という分野の名前と用途は知っているが、自分でモデル設計や実装ができるほどではない技術
-
「わかっていないとわかっていないこと（Stuff you don’t know you don’t know）」
- 存在自体を知らないため、意識の外にある技術・ツール・フレームワーク・言語。
- 知識の三角形の中で最も大きな部分であり、本当は自分の問題に最適かもしれない解決策もここに含まれる。
- 例：まだ名前すら聞いたことがない新しいミドルウェアやデータベースなど（具体名を挙げた瞬間に「知っているもの」へ移ってしまうため、文献でも「例：Don’t know ;-)」としか書けないとされている）。
アーキテクトにとっては、この三角形のうち「実際に使えるもの（1）」「名前と用途だけは知っているもの（2）」の層を広げ、「存在すら知らないもの（3）」を少しずつ減らしていくことで、技術的な幅が広がっていく。
では、なぜそこまでして「技術の幅」を広げる必要があるのか。次の節では、その理由を改めて整理する。
2.2.2 なぜアーキテクトには「技術の幅」が必要なのか
アーキテクトの仕事は、自分が得意な1つの技術を使いこなすことよりも、多様な技術・パターン・プラットフォームを俯瞰し、制約やビジネス要件に合う選択肢を組み合わせて意思決定することに価値があるからだ。そのためアーキテクトは、1つの技術の専門家であることよりも、「この問題には少なくとも複数の解き方があり、それぞれ何が得意か」を知っている方が有用であり、以前に築いた専門性の一部をあえて薄くしてでも、 **「知っていること」「名前だけ知っていること」の層を横方向に広げること（知識ピラミッドの上段・中段の拡張）**が求められる。
こうして技術の幅を広げておくことで、一つの問題に対して複数の選択肢を並べて見比べることができるようになる。これは、次に扱う「トレードオフの分析」を行うための前提にもなる。
2.3 トレードオフの分析
技術の幅と深さがあると、一つの問題に対していくつもの設計案や技術選択肢が見えてくる。次に必要になるのは、その中から「今の文脈にいちばん合う折り合い」を決める力だ。
この章では、アーキテクチャにおけるトレードオフの考え方と、実際にトレードオフ分析を行うときの基本的な手順を整理する。
2.3.1 アーキテクチャには正解がなくトレードオフしかない
ソフトウェアアーキテクチャにおいて、どんな選択肢にも必ず長所と短所がある。アーキテクトの仕事は、普遍的な「唯一の正しい設」を見つけることではなく、トレードオフを比較し、そのときの文脈に適したものを選ぶことだ。
したがって、アーキテクチャには時代を超えた唯一の正解は存在せず、あるのはトレードオフだけである。ほとんどの問いに対して答えが「状況による」になってしまうのは、最適な選択がビジネス目標、環境、予算、納期、組織文化、チームのスキルといった要因によって変化するからだ。
このように、「全てはトレードオフであり、答えは状況による」という前提を受け入れるだけでは、まだ日々の設計やレビューの場でどう振る舞えばよいかは見えてこない。次の節では、各選択肢の「得るもの」と「失うもの」を書き出しながら、具体的にトレードオフ分析を行うときの考え方を見ていく。
2.3.2 トレードオフ分析の実践：得るものと失うものを明らかにする
トレードオフ分析を実際に行うときの基本は、各選択肢について
- 何が得られるのか
- 何を失うのか
の両方を書き出すことだ。そのうえで、「このシステム、この環境、このビジネスゴールにとって、どの妥協が許容できるか」を選んでいく。
例として、入札システムのサービス間通信で「トピック（Pub/Sub）」を使うか「キュー（P2P）」を使うかという選択では、
| 方式 | 得るもの | 失うもの |
|---|---|---|
| トピック（Topic / Pub-Sub） | - 拡張性が高い（新しいサービスを後から追加しやすい） - サービス間が疎結合になる（送信側は「誰が読むか」を意識しなくて良い） |
- 誰でもメッセージを購読しやすく、データアクセス／セキュリティの懸念が増えやすい - すべてのサービスが同じメッセージ形式（契約）に縛られやすい - 個別の監視やプログラムによる負荷分散・オートスケールがやりにくい |
| キュー（Queue / Point-to-Point） | - コンシューマごとに異なる契約を持てる（サービスごとに必要なデータだけ受け取れる） - セキュリティや監視、スケーリング（キュー単位のオートスケール）がやりやすい |
- 送信側が「どのキューに送るか」を知る必要があり、サービス間の結合度が高くなりがち - 新しい機能やサービスを追加するたびに、キューや配線の変更が必要になりやすい |
トレードオフ分析とは、必要なメリットを得るために、与えられた状況や制約の中でどのデメリットまでなら許容できるかを選び取る行為」だと言い換えられる。重要なのは、「どの 得るもの/失うもの を重く見るか」は技術だけでは決められない、という点だ。同じ選択肢でも、あるプロダクトではスケーラビリティの得るものが決め手になり、別のプロダクトではコストや納期に対する失うものの方が致命的になるかもしれない。
この「何を優先し、何をあきらめるか」を決めているのがビジネス側の動きや判断軸（ビジネスドライバー）だ。アーキテクチャ思考の四つめの力は、そのビジネスドライバーをアーキテクチャの側にどう持ち込むか、という話になる。
2.4 ビジネスドライバーの理解と、それをアーキテクチャ上の関心事に落とし込むこと
アーキテクチャ思考の四つめの力について、自分のメモには次のように書いている。
ビジネスドライバー：ビジネス上の動機・目標をアーキテクチャ特性に落とし込む。
「ビジネスドライバーを理解し、それをアーキテクチャ上の関心事に落とし込む力」というラベルだけは見えているが、現時点ではまだ、この内容を自分の言葉で説明できるほど整理できていない。本書でも、このテーマは第4〜6章（アーキテクチャ特性の定義・抽出・計測）の中で詳しく扱われている。このノートでは、アーキテクチャ思考の構成要素として「ビジネスドライバーとアーキテクチャを結びつける力が四つめにある」という事実だけを残し、具体的な中身の整理は今後の TODO とする。
ビジネスドライバーまで含めてアーキテクチャ思考の四つの力を一通り眺めたところで、もう一つ気になるのが「アーキテクトがコードとどう関わるか」という実務上のバランスだ。
2.5 アーキテクティングとコーディングのバランス
アーキテクトは、設計と実装の「どこまで」に関わるべきか？
アーキテクトは、現場の感覚と技術的な深さを失わないように、ある程度コードに関わり続ける必要がある。ただし、チームのボトルネックになってはいけない。コードにまったく触れないと、アーキテクトとしての判断から現場の手触りが抜け落ちてしまう。逆に、フレームワークやクリティカルパスの実装を抱え込みすぎると、今度は自分自身がチームのボトルネックになる。では、実際のところアーキテクトはどんなコードの持ち方をすればよいのか。次の節では、「ボトルネックにならずにコードを書く」ための関わり方をもう少し具体的に見ていく。
2.5.1 アーキテクトがボトルネックにならずにコードを書くには
アーキテクトが実装に関わるときに避けたいのが、フレームワークやクリティカルパスのコードを自分一人で抱え込んでしまい、チーム全体のボトルネックになる「ボトルネックの罠」**を避けなければならない。そのために、クリティカルパスの実装は開発チームに任せ、アーキテクト自身は「非クリティカルだが意味のあるコーディング」に時間を使うことが勧められている。具体的には、次のようなタスクが例として挙げられている。
- 1〜3イテレーションで終わる小さな機能開発
- PoC（概念実証）のコード
- 技術的負債やアーキテクチャ改善に関わるストーリー
- バグ修正や小さな自動化スクリプト
- 定期的なコードレビュー
このような関わり方をすることで、アーキテクトはチームの足を引っ張ることなくコードに貢献できる。実際のコードに触れることで技術的な深さを保ちつつ、クリティカルな実装に縛られない分だけ、全体の構造やトレードオフに目を向ける「幅」も守ることができる。
結論
5. 結論：問い③へのいまの自分の答え
この記事では、問い③「アーキテクトのように考えるとはどういうことか？」に対して、
『ソフトウェアアーキテクチャの基礎』第2章を手がかりに、自分なりの整理を試みた。
いまの自分の答えを一文でまとめると、
「アーキテクトのように考える」とは、
- 第1章で見た 4つの側面・8つの期待・2つの法則という枠組みを土台にしながら、
- 次の4つの力（＋コードとのバランス）を通じて、具体的な設計判断に落としていくこと
だと言える。
本文で見てきたように、その4つの力は次のように整理できる。
-
アーキテクチャと設計の違いを理解し、開発チームと協働してアーキテクチャを機能させる力（2.1）
一方向の「上から下へのハンドオフ」ではなく、アーキテクトと開発者が一つのチームとして
双方向にやり取りし続けることで、アーキテクチャとコードを同期させていく視点。 -
技術の幅と十分な深さを持ち、複数の選択肢や可能性に気づける力（2.2）
特定のスタックの深さだけでなく、「知識ピラミッド」を意識しながら「実際に使えるもの」と「名前だけ知っているもの」を広げていくことで、問題に対して複数の解き方を並べて考えられるようにする視点。 -
複数の案についてトレードオフを洗い出し、分析し、折り合いをつける力（2.3）
普遍的な正解を探すのではなく、各案の「得るもの」と「失うもの」を書き出し、このシステム／この環境／このビジネスゴールにとって、どの妥協なら受け入れられるかを選ぶ視点。 -
ビジネスドライバーを理解し、それをアーキテクチャ上の関心事に翻訳する力（2.4）
ビジネス側の動機や優先順位が、どのアーキテクチャ特性を重く見るかに影響する。その橋渡しをする力が四つめとして位置づけられているが、現時点ではラベルを押さえたところまでで、具体的な中身はまだ整理できていない。
あわせて、第2章では、これらの力を支える前提として、
アーキテクティングとコーディングのバランスについても触れられていた（2.5）。
- コードから完全に離れてしまうと、現場の手触りや技術的な深さを失ってしまう。
- かといって、フレームワークやクリティカルパスのコードを抱え込みすぎると、今度はアーキテクト自身がチームのボトルネックになってしまう。
クリティカルな実装はチームに任せつつ、PoCや小さな機能、技術的負債の返済、バグ修正やスクリプトなど、「非クリティカルだが意味のあるコーディング」を通じてコードに触れ続ける。その関わり方によって、「十分な深さ」を維持しつつ、全体を見渡す「幅」も守る——というのが、ここで示されていたバランス感覚だと理解した。
ここまでで、自分の中では
- 第1章で整理した 4つの側面・8つの期待・2つの法則 というフレームワークと、
- 第2章で扱われた 4つの力＋コードとの距離感 というアーキテクチャ思考の枠組み
を、ひとまずひと続きのものとして結びつけることができた。
一方で、
- ビジネスドライバーから具体的なアーキテクチャ特性をどう洗い出すか（第4〜6章の内容）
- 自分のプロジェクトで、実際にどんなトレードオフ分析や知識ピラミッドの使い方があるか
といった部分は、まだ自分の言葉で整理できていない。これらは、本の後半や実務での経験を踏まえて、別のノート（TODO）として掘り下げていきたい。
TODO
- 「ビジネスドライバーを理解し、それをアーキテクチャ上の関心事に落とし込む力」自分の言葉で説明できるように整理
- アーキテクチャ特性の定義・抽出・計測
- 自分のプロジェクトで、実際にどんなトレードオフ分析や知識ピラミッドの使い方があるか