[ITmedia エンタープライズ] アーキテクチャの比較表で勝った案を本当に選ぶべきか AIに任せきれない検証と合意のプロセス

生成AIによってシステムの設計案を作ることは容易になったが、何を優先し何を諦めるかを決める責任は人間に残されている。アーキテクチャに正解はなく、重要なのは「なぜその選択をしたか」を説明できることだ。本連載ではケーススタディーを通じ、トレードオフの可視化や意思決定の考え方を掘り下げ、良い設計を目指すだけでなく、良い意思決定を目指す。

　前回は、設計判断の4ステップのうちStep1「要件を定量的に定義」とStep2「評価軸を決める（重みづけ）」を解説した。メッセージ基盤として「Amazon SQS」（Simple Queue Service）と「Apache Kafka」のどちらを選ぶかを例に、要件を必須／任意に分類して比較候補を絞り込み、5つの評価軸と重みを整理するところまで進めた。

　重みまで決まれば、各案に点数を付けて合計するだけで結論が出る。そう考えがちだが、合計点の差が意味のある差だとは限らない。そこで今回はStep3として、各案に根拠付きの点数を付ける「スコアリング」、その結論が前提次第で変わらないかを確かめる「感度分析」、判断を確定させる「アーキテクチャレビュー」の3つの作業を順に解説する。

Step3．案を比較し意思決定

　3つの作業は独立した手順ではない。スコアリングで出した結論を感度分析で検証し、その結果をアーキテクチャレビューの判断材料にする。

a.スコアリングで案を比較する

　重み設定を適用して、各案を評価軸ごとにスコアリングし、加重合計を算出する。スコアは1～5の5段階で、5が「その評価軸において最も優れている」、1が「最も劣っている」を意味する。このとき、スコアには「運用負荷の低さ＝5（マネージドサービスのため）」のように、必ず1行で根拠を添える。根拠を書き添えられないスコアは、実際には印象で付けた値の場合が多い。

　ただし、ここで算出された合計値をそのまま結論にしてはいけない。合計値の差だけを見ても、それが実質的な差なのか、たまたまの重み配分による差なのかは判別できないからだ。この判別をするのが、次節で扱う感度分析だ。

b.感度分析　「本当に鍵となる論点」をあぶり出す

　感度分析は、重みを意図的に変動させて、結論が変わるかどうかを検証する手法だ。本稿のSQS vs Kafkaの事例で、「メッセージ順序保証の重みが35％に達するとKafkaが逆転する」と示したのが感度分析の一例だ。

　感度分析の目的は、判断の頑健性（ロバストネス）を確認することにある。重みを少し変えただけで結論が逆転するなら、その判断は「たまたまの重み配分で決まっている」に過ぎず、追加の議論が必要だ。

感度分析の進め方

　以下の手順で、簡易な感度分析をする。表計算ソフトでも手計算でもよい。重要なのは値の正確さではなく、重みを動かしたときに結論が変わるかどうかを確認することだ。

1．ベースラインの評価表を作成する

　以下の形式で加重スコアリング表を作成する。

図3　ベースライン評価表　SQS vs Kafka 加重スコアリング（作成：アクセンチュア）

2．各軸の重みを±10ポイント変動させる

　1つの軸の重みを+10ポイントにし、他の軸の重みを比例配分で調整して合計100％を維持する。逆に-10ポイントも実施する。

3．結果を一覧化する

図4　感度分析の結果　メッセージ順序保証がスイングファクター（作成：アクセンチュア）

　この表から、メッセージ順序保証の重みが35％（+10ポイント）に達するとKafkaが逆転して上回ることが分かる。つまり、チームが合意すべき最重要論点は「順序保証がどこまで厳密に必要か」だ。このように、重みを動かしたときに結論を逆転させる評価軸を「スイングファクター」（判断の鍵）と呼ぶ。

図5　感度分析　スイングファクターの可視化（メッセージ順序保証+10ポイントでKafkaが逆転）（作成：アクセンチュア）

感度分析の読み方

• どの軸を動かしても結論が変わらない場合：判断は安定しており（頑健）、変動させた範囲の前提では自信を持って決定してよい
• 特定の軸を動かすと結論が逆転する場合：その軸がスイングファクター（判断の鍵）だ。チームでその軸の重みを集中的に議論する
• 複数の軸で逆転が起きる場合：候補間の差が小さく、どちらを選んでも大きな失敗にはならない可能性がある。その場合は、変更容易性（後から切り替えられるか）を加味して判断する

　感度分析の計算自体は、表計算ソフトでも生成AIでも実行できる。しかし、「どの評価軸の重みを揺らすべきか」「結論が逆転した場合、何を深掘りすべきか」という問いの設計は人間の仕事だ。感度分析の本質は計算ではなく、どの前提に議論を集中すべきかを見極めることにある。

c.アーキテクチャレビュー　整理した判断材料を基に方針を確定させる場

　スコアリングと感度分析がそろったら、アーキテクチャレビューに持ち込む前に以下を整理しておく。

• 推奨案と、次点以下の案との差
• 重み設定と、各軸の重みを決めた根拠
• 前提条件（フェーズ、期限、運用体制、要員スキル）
• 逆転条件と、それに連動する見直しのトリガー

　整理した内容は、アーキテクチャレビューを経て確定する。ここでのアーキテクチャレビューは、重みを一から決め直す場ではなく、整理された判断材料を前提に議論し、方針を確定する場だ。重みの根拠やスコアの前提に異論があればその場で深掘りし、必要に応じて修正した上で合意する。

参加メンバーの選定

　アーキテクチャレビューのメンバー選定は、評価表の作り込み以上に判断の質を左右する。その場で方針を決められる責任者が不在だと、どれだけ材料を整理しても結論は出ない。方針を最終確定できる権限者と、アーキテクチャに責任を持つ有識者は参加必須と考えるべきだ。プロダクトオーナーやプロジェクトマネジャーが前者を、アーキテクトリードが後者を担うことが多いが、誰がその役割を担うかはプロジェクトの体制によって異なる。加えて、参加者の領域が偏ると、評価軸そのものが偏る。実装観点だけで構成されたメンバーでは、運用負荷やセキュリティ、業務影響といった軸の評価が甘くなり、後工程で手戻りが発生しやすい。

　逆に、関係者を広く集め過ぎると論点が発散し、誰も決められないまま次回への持ち越しになりやすい。説明を受けるだけの参加者を増やすのではなく、判断に責任を持つ人と、評価軸ごとに根拠を示せる有識者で構成することが重要だ。

　なお、システム開発ベンダーがお客さまにシステムをデリバリーする形態では、お客さま側の意思決定者がアーキテクチャレビューで最終方針を確定することもある。

アーキテクチャレビューはプロジェクト体制に応じて段階を分ける

　アーキテクチャレビューは、プロジェクトの体制に応じて複数回に分けて実施すると効果的だ。参加者によって求められる議論の深さと前提知識が異なるためで、同じ場で全員を対象にしようとすると、論点が発散しやすく合意が取りにくくなる。例えばシステム開発チーム（ベンダー）とプロダクトオーナーが分かれる体制では、まず開発チーム内でレビューしてチーム内合意を得た上で、プロダクトオーナーレビューをする2段階構成が典型的だ。

　開発チーム内レビューでは、実装方式や運用設計まで踏み込んだ深いアーキテクチャ議論をする。一方でプロダクトオーナーレビューでは、アーキテクチャの専門知識を前提としないメンバーにも理解できるよう、業務影響・コスト・リスク・逆転条件といった判断に直結する論点に翻訳して説明する配慮が必要になる。

　ただし、これは論点の分担ではない点に注意したい。プロダクトオーナーレビューで説明する業務観点やコスト観点は、アーキテクトとしても当然考慮すべき重要な評価軸であり、開発チーム内レビューの段階から評価軸に含めて検討しておく必要がある。段階を分けるのはあくまで説明の粒度と深さを変えるためであって、開発チーム内レビューを技術論だけに閉じてよいという意味ではない。

図6　アーキテクチャレビューの段階分けの例　開発チーム内レビューとプロダクトオーナーレビュー（作成：アクセンチュア）

実践例

　本稿のSQS vs Kafkaの事例で、次の重み設定をアーキテクチャレビューに提示したとする。

図7　アーキテクチャレビューでの重み確定　整理時から確定値への変化（作成：アクセンチュア）

　このように、重み設定・スコアリング・感度分析を先に整理しておけば、アーキテクチャレビューでの議論を意思決定に直結する論点に集中させやすくなる。整理の質が、そのまま合意のスピードと納得度を左右する。

　もう一つのメリットは、技術に詳しくないプロダクトオーナーでも判断に参加しやすくなることだ。「SQSとKafkaのどちらがよいか」という問いに答えるのは難しくても、「決済処理でメッセージ順序保証はどこまで必要か」であれば、業務の知見から答えられる。評価軸を起点に議論を設計することで、技術的な詳細を知らなくても判断に貢献できる場を作れる。

　確定後は、採用方針や修正理由、前提条件、見直し条件をセットで残す。この記録をどう構造化し、どう運用するかは、後続のアーキテクチャ決定記録（ADR：Architecture Decision Record）を扱う回で詳しく示す。

アーキテクチャレビューは経験の浅いアーキテクトにとって絶好の学習の場

　アーキテクチャレビューは、確定のための場であると同時に、経験の浅いアーキテクトにとって絶好の学習の場でもある。アーキテクチャの意思決定がなされるこの場には、実装・運用・セキュリティ・業務などさまざまな領域の有識者が集まり、それぞれの角度から活発な議論が交わされる。各領域の有識者がどのような観点で考え、何を根拠に意思決定するか。プロダクトオーナーが技術的な論点を業務やコストの目線でどのように受け止め、何を判断材料にするか。これらは、自分がアーキテクチャを検討する上でそのまま学びになる。

　中でも見逃せないのが、経験豊富なアーキテクトリードの思考そのものだ。逆転条件に直結する論点をどう見極めるか、異論をどう整理して方針に反映するか、曖昧な状況でどこまで許容しどこから譲れないと判断するか――アーキテクトリードの発言や判断の中には、書籍や研修だけでは得にくい実践知が詰まっている。その思考の過程を間近で観察できることこそ、アーキテクチャレビューが学びの場として特に価値を持つ理由だ。

　技術そのものの学習は、書籍や実装経験を通じて本人の努力次第でいくらでも積み上げられる。しかし、その技術知識を実際のアーキテクチャ判断にどう結び付けるかという段階になると、経験の浅いアーキテクトほど手が止まりやすい。生成AIが情報収集から比較資料やドキュメントの作成まで肩代わりしてくれるようになった今も、この壁は変わらない。むしろAIが提示する選択肢や論点はどれも「もっともらしく」見えるため、その中から自分のプロジェクトの前提に照らして正しい判断を下すことは、以前にも増して難しくなっている。アーキテクチャレビューは、有識者やアーキテクトリードの議論を通じて「知識を判断にどう変換するか」を実地で観察できる、数少ない機会になる。

　だからこそ、経験の浅いアーキテクトやエンジニアには、単なる説明者・傍観者としてではなく、議論の進み方そのものに注意を向けてアーキテクチャレビューに参加することを勧めたい。

本稿の整理と次回予告

　今回は、第2回で整理した評価軸と重みを使ってStep3について解説した。スコアリングで候補案に根拠付きの数値を与え、感度分析でその結論がどの前提に依存しているかを明確にし、アーキテクチャレビューで意思決定を確定させるという流れだ。

　スコアリングは根拠を添えてこそ意味を持つ。感度分析はスイングファクターを見つけることが目的であり、値の精度より結論の変化を確認することが重要だ。そしてアーキテクチャレビューは一から議論する場ではなく、整理された材料を前提に方針を確定させる場として機能する。

　本稿のスコアリング表（図3）と感度分析結果表（図4）の構成をそのままひな型として、評価軸・重み・根拠・前提条件を自分のプロジェクトの内容に置き換えて活用してほしい。

図8　スコアリングシートの作成イメージ（作成：アクセンチュア）

　次回は、こうした判断プロセス全体に影響する「認知バイアス」を取り上げる。知識や経験の量では防ぎにくいバイアスが、スコアリングや重みの議論にどう忍び込むか。各バイアスとその対策、セルフチェックリストを解説する。

著者プロフィール：前出 祐吾（まえで ゆうご）

アクセンチュア デジタルコア シニア・マネジャー。SIerでアプリケーション基盤の構築・プロジェクト展開などの経験を経て2023年アクセンチュア入社。金融系システムを軸としたアーキテクトとしてプロジェクトに参画する傍ら、昨今は生成AIを使ったソリューション開発などにも携わっている。