■ 1. 発表概要
- タイトル：ソフトウェアアーキテクトのための意思決定術（Create Decision Readiness—The Real Skill Behind Architectural Decision）
- 発表者：島田浩二（@snoozer05 / ENISHI TECH INC.）
- 発表日時：2026年2月26日 技術選定を突き詰めるOnline Conference
- 対象：影響範囲の大きい設計や決定を担う人々（ソフトウェアアーキテクト・リーダー・上級技術専門職など）
- 主題：意思決定する際に重要だと考えること（自身の経験を通じた知見）
■ 2. ソフトウェア開発における意思決定の難しさ（失敗事例）
- マイクロサービス採用の失敗:
- 開発速度向上・スケーリング対応などのメリットを狙いマイクロサービスアーキテクチャで構築
- 求められる運用能力・技術力に体制や運用が追いつかずメリットが出る前に疲弊して負債化
- 全面リプレースの失敗:
- 技術的負債の解消で事業推進を加速できると見込み既存システムを捨てて全面リプレースを決定
- 開発進行とともに見えていなかった制約や運用ルールが続出しリリース遅れ・並行稼働長期化・障害が発生し当初の狙いを果たせない結果に
■ 3. 失敗の根本原因：判断力の不足
- ソフトウェアアーキテクチャの失敗の多くは知識不足ではなく判断力不足で起きている（Srinath Perera『ソフトウェアアーキテクトのための意思決定術』）
- 判断力の不足の内訳:
- 判断の材料となる前提や制約を十分にとらえきれていない
- 判断の際に考慮すべき観点を十分に網羅できていない
- そもそも「判断」をしていない（流行に流される・願望に基づいて決定する・組織の要請に考えなしに従う・AIに任せてしまうなど）
■ 4. ソフトウェア開発における意思決定の本質
- 意思決定は「情報が十分に揃ってから正解を選ぶ行為」ではない
- 意思決定とは「限られた情報で賭けを置いてリスクを取る行為」である（リスクを取る＝結果が不確実で損失の可能性がある行動に挑戦すること）
- すぐれた意思決定とはリスクの取り方が上手いことと同義である
- 判断力とは「判断できる（リスクを取れる）状態を作っていける力」である
■ 5. ソフトウェア開発における意思決定の誤謬
- 誤謬①「前提条件はすべて揃っている」:
- 前提の不確実性：ビジネス・技術・組織の状況は変化し続ける
- 目標の不確実性：本当に作りたいものが何かは不明確
- 方法の不確実性：どうやって作ればいいかが不明確
- 結果の不確実性：期待する価値を生むかどうかが不明確
- 既知の知・既知の未知に加えて「未知の未知」が存在する（ドナルド・ラムズフェルド）
- 結論：ソフトウェア開発には不確実性そして未知の未知がある
- 誤謬②「選択肢はすべて揃っている」:
- 設計上の選択肢は「与えられるもの」ではなく「作るもの」である
- 選択肢を作るには探索コストがかかり能力にも制約される
- 選択肢が同時に得られることは稀であり通常は五月雨式に得られる
- 選択後により良い選択肢を得られることも普通に起きる
- 結論：選択肢は作り出すものであり大抵は五月雨式に現れる
- 誤謬③「決定には『正解』がある」:
- ソフトウェア開発における意思決定はビジネス・技術・組織といった相反するさまざまな要素に影響を受ける
- それらすべてを考慮した上でもっとも妥当な選択をする必要がある
- 結論：現実の意思決定はトレードオフの判断である
■ 6. リスクを上手く取るための3つの基本戦略
- 戦略①「タイミングが来るまで決定を先送りする」:
- 考え方：最終責任時点（Last Responsible Moment）と最大責任時点（Most Responsible Moment）
- 重要な選択肢を失うのを避けるために判断を下さなければならない時期まで決定を遅らせる
- ソフトウェアシステムに最も良い前向きな影響を与えるタイミングで設計判断を下すことを目指す
- 意思決定するタイミングを意識的にコントロールする
- 実践（インセプションデッキ/やらないことリスト）：プロジェクトでやりたいことと同じかそれ以上に「やらないこと」「あとで決めること」をはっきりさせる
- 実践上の課題：実際はなかなか上手く運用できないことも多い
- 必要な能力（ネガティブケイパビリティ）：すぐに結論や解決策を求めず答えの出ない不確実な状況や曖昧な状態に耐え留まり続ける能力
- 戦略②「決定を可逆的にする」:
- 考え方：可逆的な決定（Two-Way Door）と不可逆的な決定（One-Way Door）の区別
- 意思決定では一度通ったら戻れないドアではなくいつでも戻ってこられるドアを選ぶ
- できるだけ決定を可逆的な方向に寄せる
- 不可逆的な決定の特性：広範囲に影響・決定を変更するコストが高い／変更できない
- 可逆的な決定の特性：より局所的・意思決定をやり直すコストが低い
- 実践（ストラングラーフィグアプリケーションパターン）：古いシステムと新しいシステムを共存させ段階的に移行しながら一時中断や完全中止を可能にする
- 戦略③「決定の材料を増やす」:
- 考え方：探索—検知—対応アプローチ
- 複雑系での意思決定には実験が必要であり1回の実験で十分な情報が得られることは稀
- イテレーティブな開発プロセスで探索—検知—対応サイクルを回しながら不確実性を減らしていく
- 失敗を学習プロセスの本質的な部分として受け入れる必要がある
- 実践の手段：PoC（概念実証）・オブザーバビリティを高め実システムを観察する・コンカレント開発（LLMによって今後やりやすくなる領域）
- 実践のアイデア（ADRに「学習」の経過を残す）:
- ADR（アーキテクチャデシジョンレコード）はテキストベースの軽量テンプレートでアーキテクチャ上の設計判断を記録するもの
- 基本フォーマット：タイトル・ステータス・コンテキスト・決定・影響
- 拡張フォーマット：代替案（捨てた選択肢・迷った選択肢・どう迷ったか）と経過（決定後に何がわかったか・どうなったか）を追加
- 将来同じことで迷わないように「迷い」や「試行錯誤」を記録する
- 定期的に日時・状況・観測・評価を記録し意思決定を「点」から「学習のプロセス」にする
■ 7. 結論
- 3つの戦略を取りながら判断できる（リスクを取れる）状態を作っていくことがすぐれた意思決定の本質である
- ソフトウェアアーキテクトの意思決定術の核心：「負えないリスク」を未来の誰かに負わせないために粘り強く判断できる状態を作っていく
- 厳しい現実の中でも判断を諦めないことが求められる