リスクストーミングでアーキテクチャの懸念を対策につなげる

アーキテクチャ上のリスクを個別に評価し、異なる見解をすり合わせ、追跡可能な軽減策へつなげる手順を実例とともに紹介します。

Takahiro Iwasa

2026-08-29

11 min read

システム障害は、誰も危険に気づかなかったから起きるとは限りません。誰かが抱いていた懸念が、設計に反映されないまま残っていたということもあります。運用担当者は過去の障害を、開発者は実装上の制約を、セキュリティ担当者は信頼境界の弱点を知っています。1人のレビューだけで、こうした知識をすべて拾い上げるのは困難です。

リスクストーミングでは、異なる立場の参加者がアーキテクチャ図を囲み、まず個別にリスクを評価してから、判断の根拠と対応方針を話し合います。影響度と発生可能性を共通の尺度にするため、漠然とした不安の列挙で終わらず、具体的な設計変更や継続的な計測へつなげられます。

リスクストーミングの3段階

リスクストーミングとは

最初に、可用性、性能、スケーラビリティ、データ損失、単一障害点、セキュリティ、未実証技術などから、今回評価するリスクの観点を1つ選びます。最新のアーキテクチャ図を用意したら、次の3段階で進めます。

特定（Identification）: 各参加者が他の人と相談せず、危険だと思う箇所とリスク値を記録する
合意（Consensus）: 全員の結果を図上に集め、評価が異なる箇所や1人だけが見つけた懸念を議論する
軽減（Mitigation）: 合意したリスクについて、設計変更、運用対策、計測、受容のどれを選ぶか決める

最初の特定を個人作業にすることが重要です。最初から会話を始めると、発言力の強い人や最初に示された評価に判断が引っ張られます。 独立した視点を先に残すことで、チームの知識の幅を保ったまま議論を始められます。

リスクマトリクスで評価軸をそろえる

「危なそう」という感覚だけでは、参加者ごとに高・中・低の意味が変わります。そこで、各リスクを次の2軸で評価します。

影響度: 問題が起きたとき、利用者、事業、データ、運用へどれほど影響するか
発生可能性: 現在の設計と運用条件で、その問題がどれほど起こりやすいか

それぞれを低（1）、中（2）、高（3）で評価し、積をリスク値とします。

発生可能性 \ 影響度	低（1）	中（2）	高（3）
高（3）	3: 中	6: 高	9: 高
中（2）	2: 低	4: 中	6: 高
低（1）	1: 低	2: 低	3: 中

評価するときは、先に影響度を考え、その後で発生可能性を考えます。例えば、データベース停止の影響度が高くても、冗長化や復旧手順によって発生可能性が低ければ、総合値は3です。反対に、ほとんど知られていない技術は、障害の起こりやすさ自体を判断できません。この場合は低く見積もらず、検証が終わるまで高リスクとして扱います。

数値は客観的な真実ではなく、評価理由を比較するための共通言語です。平均値を取って議論を終えるのではなく、「なぜ6で、なぜ3ではないのか」を話すことに価値があります。

実施前に準備すること

進行役は、共同セッションの1〜2日前までに次の情報を共有します。

評価対象のシステムまたは変更範囲
今回扱うリスクの観点
最新のアーキテクチャ図
リスクマトリクスと記入方法
個人評価の期限と共同セッションの日時

参加者はアーキテクトだけに限定しません。シニア開発者、テックリード、SRE、セキュリティ担当者に加え、影響や費用の判断が必要ならプロダクト責任者も含めます。全体を評価するなら俯瞰図を、特定機能を評価するなら周辺の依存先まで含むコンテキスト図を使います。

複数の観点を一度に扱うと、同じ付箋の「6」が可用性なのかセキュリティなのか分からなくなります。原則として、1回のセッションでは1つの観点に絞ります。

3段階の進め方

1. 個人でリスクを特定する

各参加者は図を確認し、リスクがある要素や通信経路に付箋を置きます。付箋には最低限、対象、リスク値、評価理由を記載します。対面なら低・中・高で色分けし、オンラインなら共同ホワイトボードを使えます。

この段階では相談も既存の評価の閲覧もしません。誰も付箋を置いていない場所も「リスクなし」という投票ではなく、単にその人の注意に入らなかった可能性があります。

2. チームで合意する

すべての付箋をアーキテクチャ図上に集め、次の順に確認します。

評価値が大きく異なる箇所
1人だけがリスクを指摘した箇所
複数人の評価が一致した高リスク箇所

少数意見はノイズとは限りません。特定コンポーネントの障害履歴を知っている人や、採用技術を扱ったことがない実装担当者が、他の参加者には見えていないリスクを示している場合があります。多数決ではなく、前提と根拠を共有し、チームとしてリスク値と説明に合意します。

3. 軽減策を決める

高リスクから順に、発生可能性を下げる方法、発生時の影響を小さくする方法、検知と復旧を早める方法を検討します。選択肢には、冗長化、分離、非同期化、流量制御、キャッシュ、権限境界の見直し、監視や復旧訓練などがあります。

すべてのリスクを消す必要はありません。対策費用が期待損失を上回るなら、根拠を残して受容する判断もあります。 各リスクには、対応方針、担当者、期限、再評価の条件を記録します。対策後は同じマトリクスで残存リスクを再評価すると、設計変更の効果を比較できます。

形骸化を防ぐポイント

リスクストーミングを単なる付箋の会にしないため、次の点に注意します。

対象を広げすぎない: 1つの観点と判断可能な範囲に絞る
図を正解として扱わない: 図と実装の差自体もリスクとして記録する
色だけで終わらせない: リスクには理由と対応方針を付ける
軽減策を即決しすぎない: 費用、複雑性、新たに生まれるリスクも比較する
一度で終わらせない: 大きな機能追加、アーキテクチャ変更、イテレーションの節目で再実施する

監視指標やアーキテクチャ適応度関数でリスクの変化を継続的に測れば、評価はスナップショットから改善サイクルへ変わります。高リスクだけを抽出した一覧と前回からの増減を共有すると、意思決定者にも状況を伝えやすくなります。

実施後に残すもの

リスクストーミングで、あらゆる障害を予測できるわけではありません。実施後に残るのは、チームがどこにリスクを見いだし、なぜ問題だと判断し、誰が対応するのかを記録したものです。

設計変更の節目で評価を繰り返せば、その記録を現状に合わせて更新できます。目指すのは、障害が一度も起きないシステムではなく、未知の問題を早く見つけ、影響を抑え、回復できるシステムです。

参考: Mark Richards, Neal Ford, Fundamentals of Software Architecture, 2nd Edition, Chapter 20, “Analyzing Architecture Risk.”

記事一覧に戻る

About the author