テクニカルPMが知っておくべき「アーキテクチャレビューの本質」

テクニカルPMが知っておくべき「アーキテクチャレビューの本質」
── 技術に"どこまで"踏み込むべきか

導入：アーキテクチャは PM の領域か？

テクニカルPMにアーキテクチャ理解が求められる理由は単純だ。
品質・スケジュール・コスト──すべてがアーキテクチャに直結しているから。

スケールしない構成は、後で性能問題として跳ね返る

運用を考えていない設計は、リリース後に人と金を食い潰す

過剰な構成は、初期コストと開発速度を奪う

しかし、ここに一つの罠がある。

PMが「設計を決める人」になってしまうことだ。

設計はエンジニアの仕事。
PMの役割は、設計の是非を"判断できる状態"を作ること。

この記事の目的は明確だ。

• PMはどこまで把握すべきか

• どこからエンジニアに任せるべきか

• その境界線を、実務レベルで言語化する。

1. テクニカルPMが押さえるべき「アーキテクチャ理解の4レイヤー」

アーキテクチャ理解は、コードではなく構造から始まる。

① 機能構成（Functional Architecture）

どの機能がどのコンポーネントで実現されているか
「この箱は何の責務を持つのか」を説明できるか

責務が曖昧な構成は、必ず破綻する。

② 非機能要件との整合性（NFR Alignment）

性能・可用性・拡張性・セキュリティ。
これらは「後から足す」ものではない。

"この構成で、なぜ満たせると言えるのか"

ここを説明できるかが PM の最低ライン。

③ データフローと依存関係（Flow & Dependency）

どこからどこへデータが流れるのか
同期か非同期か
依存が集中している場所はどこか

依存の偏りは、将来の技術負債の温床になる。

④ 運用・保守フロー（Ops & Lifecycle）

監視は何を見ているのか
リリースとロールバックはどう行うのか
障害時に誰が何を判断するのか

運用が語れないアーキテクチャは、未完成だ。

2. PMが到達すべき「理解のアウトプット」

理解しているかどうかは、アウトプットで測れる。

✔ 自分の手で簡易な構成図を描けるか

四角と矢印で十分。
それを使って、非エンジニアにも説明できるか。

✔ 「なぜこの構成なのか」を会話できるか

技術用語の正確さより、理由の説明が重要だ。
理由が語れない構成は、危険信号。

3. アーキテクチャレビューの目的は"設計発表会"ではない

レビューの目的は3つだけだ。

① ビジネス要件・制約を満たしているか

想定スケール
SLA
規制
顧客要件

「動くか」ではなく「成立するか」を見る。

② 将来の変更を過度に阻害しないか

すべてを予測する必要はない。
ただし、"変えにくい場所"は把握しておく。

③ チームのスキルと運用体制に合っているか

理論上美しい構成でも、運用できなければ失敗だ。

4. PMが"踏み込まない"領域

逆に、PMが踏み込むべきでない領域も明確にする。

クラス設計
SQLの細部
コードの最適化手法
インフラ設定の細部
ベストプラクティスの細かい是非

ここに口を出すと、責任の境界が崩れる。
PMは「判断のレイヤー」に集中すべきだ。

5. レビュー前の準備：良いレビューは準備で8割決まる

必要なインプット

要件定義・ユースケース・非機能要件（1〜数枚に圧縮）
現状案のアーキテクチャ図
技術選定の理由メモ
想定トラフィック・データ量・外部連携先

これらが曖昧なままレビューすると、議論は必ず迷走する。

観点リストを事前に共有する

性能
スケール
信頼性
セキュリティ
運用保守
コスト

さらに「今回特に重視する観点」に★を付ける。
これだけで議論の深さが変わる。

6. レビューの進め方：90分の黄金アジェンダ

0〜10分：目的と前提の共有
ビジネスゴールと制約条件を確認。

10〜30分：エンジニアからの説明
PMは聞きながら論点を整理する。

30〜70分：観点リストに沿った質疑
「何が決まっていて、何が未確定か」を炙り出す。

70〜90分：決定事項とTODOの整理
オーナーを必ず決める。

7. PMのファシリテーション：答えではなく"問い"を出す

PMは答えを出す人ではない。
問いを投げる人だ。

「ピークトラフィックが○倍になったらどうなりますか」
「障害時、最初に見る指標は何ですか」

議論が詳細実装に潜り始めたら、即座に切る。

「ここは別途Tech MTGで詰めましょう。」

これを言えるかどうかが、PMの腕だ。

8. どこまで技術に踏み込むべきか

PMが責任を持つべきレイヤー

トレードオフの理解
リスクの把握
ビジネス要件との整合性
致命的リスク（単一障害点・規制違反）の検知

エンジニアに任せるべきレイヤー

実装
最適化
フレームワーク選定の細部
インフラ設定の細部

PMがここに踏み込むほど、プロジェクトは歪む。

9. 良いレビューと悪いレビューの違い

❌ 悪いレビュー

「早く・安く」で押し切る
用語講座になってしまう
要件が曖昧なまま構成だけレビューする

✔ 良いレビュー

事前資料は1〜2ページ
論点整理に集中
トレードオフを引き出す
決定事項が即ドキュメント化される

派手さはないが、炎上もしない。

10. 明日から使えるチェックリスト

非機能要件ごとに根拠が説明できるか
単一障害点と対策が明示されているか
運用・監視・障害対応が1枚で説明できるか
PMの責任範囲がチームで共有されているか

結論：アーキテクチャレビューは"判断力"の場である

アーキテクチャレビューは、技術力を見せる場ではない。
判断力を整える場だ。

テクニカルPMがやるべきことは、

設計を描くことではなく、

設計が正しく判断される環境を作ること。

その環境が整ったとき、
レビューは初めて、プロジェクトを前に進める武器になる。