Hope is NOT a Strategy

Hope is NOT a Strategy.
ADR for Strategy, VUCA era.
There is NO era VUCAesque.
It's Myth.

Transcript

1. Hope is not a strategy 技術選定カンファレンスの知見から、意思決定を構造化する 社内LT / 10min / y.s. 2026/02/26 Findy主催「技術選定を突き詰める Online Conference」 参加レポート: zenn.dev/coconala/articles/747d6717c5d818 1
2. そもそも、なぜ「意思決定」が重要なのか "Choose an Architecture (Before It Chooses You)" — Michael Keeling『Design It!』 意図的に選択しなければ、なし崩しにアーキテクチャが決まってしまう。 ソフトウェア開発のほとんどの失敗は 知識の不足ではなく、判断力の不足 から起きる。 （島田） マイクロサービス化の失敗 — 技術は知っていたが、組織の運用能力を見誤った 全面リプレースの失敗 — 設計はできたが、見えていなかった制約が続出した 技術選定とは「どの技術を選ぶか」ではなく 「不確実性の中でどう賭けを設計するか」 という行為。 意思決定とは、情報が全部揃ってから選ぶ行為ではなく、限られた情報で賭けを置いて、リスクを取 る行為である。 — 島田 浩二 2
3. 判断と決断は違う 曽根さんが明確に区別していた。 判断 決断 定義 情報に基づく選択 不確実性下での選択 必要なもの データ、基準、比較 覚悟、撤退条件、失敗設計 標準化 できる（手順化・自動化可能） できない（人がやるしかない） リーダーに求められるのは — こっち 判断は標準化すれば誰でもできる。 決断は標準化できない。だからこそ 「なぜその賭けを選んだのか」を記録する 必要がある。 3
4. リスクのないプロジェクトに価値はない "If a project has no risks, don't do it." （リスクのないプロジェクトには手を出すな） — Tom DeMarco & Timothy Lister『Waltzing with Bears（熊とワルツを） 』 リスクのないプロジェクトに価値はない。 価値あるプロジェクトには必ずリスクがある。 意思決定とは リスクを避けることではなく、取るリスクを選ぶこと 。 その選択の記録がADR。 4
5. 弊社のシステム課題 25リポジトリ、複数言語 — Rails, PHP, Go, Java, Node.js, Swift, Kotlin CakePHP → Rails → Nuxt 3 の移行が並走中 coconala-web と csm-web が共存 マイクロサービス間のgRPC通信、BQ連携、データパイプライン 技術的意思決定のスコープが サービス横断 になりやすい 弊社の組織課題 技術選定の経緯が 人の記憶に依存 している 「あの時なぜこう決めたか」がわからず、同じ検討を繰り返す レビューで何往復もする — 書き手と読み手の期待値がずれている 意思決定の質が 個人のスキルに依存 している → 個人の決断力を鍛えるのは長期戦。 仕組みで底上げする のがADRの役割。 5
6. カンファレンスの知見 — ADRの各セクションに効く 7人の登壇者が別々の角度から語った知見は、ADRの各セクションに直接効く。 登壇者 核心 ADRで効くセクション 米久保 暗黙知・認知バイアスを形式知にする コンテキスト、評価軸 曽根 正解はない。失敗できる賭けを設計する 決定理由 島田 材料を増やす。代替案と学習の経過を残す 代替案、参考 川島 決めないことを決める。閉鎖の遅延 今決めないこと 藤原 変更頻度で切る。トレードオフと境界の設計 結果・影響、統制 松木 データ構造の理解は不変。定量的な分析 前提（定量データ） ryoppippi・曽根 ゆっくり考え、素早く出す ステータス（書いて終わりじゃない） → カンファレンスの知見は ADRの具体的なセクションの書き方 に落とせる。 6
7. Good Example — なぜ読みやすいのか #55593 トップページのパーソナライズレコメンドのキャッシュ構成 前提に 定量データ — ユーザー数、サービス数、ピークreq/s。SQLクエリ付き 評価軸が明確 — 費用・レイテンシ・スケール上限・障害時影響 4案を 同一の軸で横並び比較 — 構成比較表 棄却理由が 事実ベースで1文 — 「メモリ使用率最大88%でタイト」 「月$515で高い」 統制セクションが 運用ルール — 書き込み順序、TTL設計、監視アラート → カンファレンスの知見が自然に反映されているから読みやすい。 7
8. なぜ出来ていないのか (1/2) #55644 当日のデバイス別流通高をリアルタイムに確認 のレビューで繰り返された指摘 1. 意見と事実が分離されていない 「無視しても良いというのは意見であり事実ではないのでは」 → 島田: 材料を増やし、賭けの根拠を分けて書く 2. 棄却理由が読み手を説得していない 「デメリットを上回るメリットがあるように見える。棄却した理由がわからない」 → 米久保: 評価軸を先に定めることで認知バイアスを低減する 8
9. なぜ出来ていないのか (2/2) 3. 論拠の出典がない 「論拠を構築する上で参照したドキュメントはありませんか？」 → 島田: 代替案と経過も残す。学習を追記する 4. 検討スコープの抜けに気づけない 「コンテンツは？」 「オプションは？」 「アソシエーションを貼るならtransactionの考慮は？」 → 米久保: 未知の既知 — 実は知っているのに気づいていない死角 9
10. 根本原因 — テンプレートの誘導不足 個人のスキル不足ではなく、 テンプレートの誘導が十分でない 。 現行テンプレートには「決定理由」 「棄却理由」 「参考」のセクション自体はある。 #55593が上手くいったのは 書き手が行間を読めたから であって、テンプレートの力ではない。 レビュー指摘 現行テンプレートの状態 改善案 意見と事実が混在 分離構造はあるが「評価軸」が独立項目でない 評価軸を追加 棄却理由が弱い 欄はあるが何を書くかのガイドがない 記載ガイドを強化 論拠がない 欄はあるが何を載せるかが曖昧 記載ガイドを強化 スコープ抜け 「今決めないこと」の欄がない 新規追加 → ADRテンプレートは 判断の標準化ツール。欄の有無だけでなく、何をどう書くかの誘導が必要。 10
11. ADRテンプレート リバイス案 セクション 変更点 コンテキスト 定量データ・推計根拠を含む（ガイド強化） 決定理由 「〜と思われる」を避け根拠を示す（ガイド強化） 決定理由 「評価軸」を新規追加 — 比較基準・ノックアウトファクター 代替案 > 構成比較表 軸は「評価軸」と一致させる（ガイド強化） 代替案 > 棄却理由 比較表のどの軸が決め手か明記（ガイド強化） 今決めないこと 新規追加 — 先送り事項と決定トリガー 参考 口頭確認も記録（誰に・いつ・何を） （ガイド強化） 11
12. 変更点サマリー 変更 種別 解決する問題 カンファレンス知見 「評価軸」を追加 新規追加 棄却が恣意的に見える 米久保: 評価軸を先に定める 「今決めないこと」を追加 新規追加 スコープ抜け 川島: 決めないことを決める 決定理由の記載ガイド ガイド強化 意見と事実が混在 島田: 材料と賭けを分ける 比較表の軸の揃え方 ガイド強化 横並び比較ができない 島田: 選択肢を構造化 棄却理由の書き方 ガイド強化 なぜ選ばなかったか不明 川島: 両方を記録 参考の記載内容 ガイド強化 論拠が追跡できない 島田: 学習の経過を残す 12
13. ADRは判断を標準化し、決断に集中するためのツール 意思決定 ─┬─ 判断（標準化できる）→ ADRテンプレートで仕組み化 │ データを集め、軸で比較し、事実に基づいて選ぶ │ └─ 決断（標準化できない）→ 人がやる 不確実性下で賭けを選び、リスクを取り、覚悟する テンプレートを整備することで 判断にかかるコストを下げ 、 本来人がやるべき 決断に集中できる 状態を作る。 25リポジトリ、複数言語、移行並走のシステムで、 意思決定の経緯が人の記憶に閉じたままでは回らない。 13
14. まとめ 1. 意思決定の失敗は知識不足ではなく判断力不足 から起きる 2. 判断と決断は違う。 判断は標準化できる。決断は人がやる 3. 弊社の課題: 意思決定の質が個人に依存し、経緯が記憶に閉じている 4. ADRは 判断を標準化し、決断に集中するためのツール 5. テンプレートに 「評価軸」 「今決めないこと」を新規追加 し、既存項目の 記載ガイドを強化 する "Choose an Architecture (Before It Chooses You)" — Michael Keeling 「組織は意思決定しない、人がする」 — 曽根 壮大 アーキテクチャに選ばれる前に、選ぼう。 そして選んだ理由を、未来の自分たちに伝わるように残そう。 14