技術の意思決定ログに何を残すか。結論だけでは引き継げません
半年ぶりに基盤の見直しが議題になり、経営者が「なぜ今の方式を選んだのですか」と尋ねます。前任者は退職していて、議事録には「A案を採用しました」としか残っていません。採用理由を知る人がいなければ、継続にも変更にも自信を持てません。
技術の意思決定ログに必要なのは、決定事項の一覧ではありません。目的、比べた選択肢、見送った理由、当時の前提、見直す条件です。僕なら、会議の発言をすべて保存せず、後任者が同じ材料から次の投資を選べる情報だけを短く残します。
開発チームだけが読める設計メモでも足りません。開発の決定記録が月額費用、公開時期、顧客への影響、運用を担う人までつながって初めて、経営者も過去の決定を評価できます。
技術の意思決定ログは、結論より選んだ理由を残します
結論だけを読むと、過去の選択が永久に正しい規則に見えます。しかし、技術上の選択は当時の予算、期限、利用人数、扱うデータ、社内で運用できる範囲の中で決まります。前提が変われば、同じ結論を守る理由も変わります。
たとえば、外部サービスを採用した記録にサービス名しかなければ、料金が上がった時に移行すべきか判断できません。短い納期を守るためだったのか、社内に保守できる人がいなかったのか、監査で必要な機能が用意されていたのかによって、見直す条件が変わります。
経営者が知りたいのは、技術名の人気ではありません。何を守るために費用を使い、どの危険を受け入れ、代わりに何を諦めたかです。判断の材料が残れば、担当者が交代しても、追加費用を払うか、別案へ移るか、現状を維持するかを話せます。
僕は以前、改善要望には解決方法より目的を書く理由をnoteに書きました。技術選定も同じで、採用した手段だけでは後から評価できません。達成したかった業務や顧客への約束を先に残す必要があります。
CTO代行を入れた後の意思決定を確かめる方法でも、会議回数より、持ち越し、決裁待ち、手戻りが減ったかを見ています。意思決定ログは選ぶ時点で作り、将来の再確認に使う資料です。
技術の意思決定ログへ残す六つの項目を決めます
書式を豪華にする必要はありません。一件の決定について、次の六項目を読めれば十分です。
- 決定内容、日付、状態を残します。 検討中、採用、廃止、別の記録へ置き換え済みなど、現在も有効かを先頭で示します。
- 目的を業務の言葉で書きます。 「新しい技術を導入するため」ではなく、公開日を守る、復旧時間を短くする、個人情報へ触れる人を減らすなど、達成したい状態を書きます。
- 比較した選択肢と比較軸をそろえます。 初期費用だけでなく、毎月の請求、移行作業、障害時の復旧、採用や外注のしやすさなど、決定に使った軸を示します。
- 見送った理由を人の評価から離して書きます。 「担当者が反対しました。」ではなく、期限内に検証できない、運用担当を置けない、必要な契約条件を満たさないなど、後から確かめられる理由へ直します。
- 前提と未確認事項を分けます。 想定する利用量、予算枠、公開期限、担当人数、外部サービスの契約期間を残し、数字を確かめていない項目には未確認と書きます。
- 見直す条件と確認する人を置きます。 請求額が承認済みの予算を超えた時、必要な復旧水準が変わった時、提供会社が契約条件を変えた時など、再検討を始める合図を具体化します。
決定者の名前だけでなく、技術案を作った人と、予算や顧客影響を承認した人も残します。技術責任者だけでは月額予算を決められず、経営者だけでは復旧方法を評価できない場合があるからです。両者が読んだ資料へのリンクも付けます。
見積書、課題、検証結果、契約条件、請求画面を本文へ複製する必要はありません。意思決定ログには参照先と確認日を置きます。元資料が更新される場合は、決定時に読んだ版を特定できるようにします。
設計判断を短く残す方法を、経営者が追える意思決定ログへ広げます
設計上の重要な決定を短い文書へ残す方法を、Architecture Decision Record（ADR）と呼びます。Michael Nygard氏のADRに関する原典では、前提（Context）、決定（Decision）、状態（Status）、結果（Consequences）という項目を使い、過去の記録を消さずに置き換え後の記録へつなぐ形式が示されています。
原典の対象は、構造、品質特性、依存関係、接続方法などに影響する設計上の決定です。日本企業の取締役会資料や、法令で定められた記録様式ではありません。僕はADRの短さと履歴を残す考え方を借り、予算、顧客への約束、外部契約、運用担当まで読める範囲を広げます。
たとえば、注文データの保存先を決める場面を考えます。決定欄には「注文データは、運用を提供会社へ任せられるデータベースサービスへ保存する」と書きます。目的は公開期限を守りながら、障害時に社内担当者が復旧状況を確認できるようにすることです。
比較した案には、外部サービスを使う案と自社で運用する案があります。自社運用を見送った理由は、技術的に劣るからではなく、公開期限までに監視と復旧の担当を置けないからです。前提には利用量の見積もり、承認済みの予算、保存するデータの種類を置きます。
見直す条件は、請求画面の金額が予算を超えた時、復旧に求める時間が変わった時、保存地域や契約条件の要件が変わった時です。次の担当者は、当時の案を盲目的に守らず、変化した前提だけを比べ直せます。
説明用に一件を埋めると、次の形になります。特定企業の実績を示すものではありません。社内で記入項目を確認するための例です。
状態と決定: 採用します。注文データには、運用を提供会社へ任せられるデータベースサービスを使います。
目的: 公開期限を守り、障害時に社内担当者が復旧状況を確認できるようにします。
候補: 外部サービスを使う案と、自社で監視・復旧まで行う案です。
見送った理由: 自社運用では、公開期限までに監視と復旧の担当者を置けないためです。
当時の前提: 利用量の見積もり、承認済みの予算、保存するデータの種類を、決定日の資料へ固定します。
見直す条件: 月額が承認済み予算を超える、必要な復旧時間が変わる、保存地域や契約条件の要件が変わる場合です。
後継記録: 条件が動いたら元の記録を「置き換え済み」にし、新しい比較と決定を記したADRへリンクします。
技術名と費用の間を埋める人がいなければ、経営者は記録を読んでも判断できません。経営と技術をつなぐ人が会議前に整える論点と合わせ、現在の構成と将来の追加投資を同じ根拠から説明できる状態を作ります。
技術の意思決定ログを会議録にしない運用を作ります
会議の録画や文字起こしを保存しても、決定の根拠を探すには会議と同じ長さがかかります。全発言を公平に残す作業より、提案者が会議前に六項目の下書きを作り、承認者が会議後に差分を確認する運用のほうが続きます。
一件の文書には一件の決定だけを置きます。複数の決定を一つの議事録へ混ぜると、片方だけを見直した時に状態が分からなくなります。古い記録を書き換えて現在の理由に合わせず、廃止や置き換えの状態を付け、新しい記録へのリンクを追加します。
保存先は、開発者が更新でき、経営者もリンクから読める場所を選びます。ソースコードを保管する場所へ置く場合でも、共有文書に題名、決定日、状態、担当者、リンクを並べた索引を用意します。同じ本文を二か所へ複製せず、正しい版を一つに決めます。
会議で口頭説明した事実を、記録の代わりにしてはいけません。「言った」だけでは伝わらない理由でも書いたように、受け手は流れてくる情報をすべて同じ重要度では覚えられません。後から探せる題名と保存先まで渡して、初めて再利用できます。
記録作業を担当者の善意へ預ける運用も続きません。重要な技術案は、意思決定ログの承認までを課題の完了条件に入れます。開発予定から作成時間を確保し、文書数を個人評価へ使わないようにします。
担当者の退職が決まってから過去の会議を掘り起こすと、確認できない前提が増えます。平時から別の人が一件を読み、採用理由と見直す条件を説明できるか確かめてください。
次の技術判断を一件だけ記録します
明日は過去の会議を全部整理せず、次の公開や契約更新に影響する決定を一件だけ選んでください。候補が二つ以上あり、変更に費用がかかり、半年後にも理由を尋ねられる可能性がある一件が向いています。
課題管理画面で対象の課題を開き、題名、日付、状態を書きます。達成したい業務、比較した案、見送る案、現在の予算と期限、再検討を始める条件を一文ずつ足します。予算の承認記録、外部サービスの契約画面、検証結果へのリンクも置きます。
下書きを、会議へ参加していない経営者かエンジニアに読んでもらいます。「前提が変わった時、継続と変更のどちらを検討すべきか説明できますか」と尋ねてください。答えに必要な情報が抜けていたら、会議録を増やさず、六項目の該当箇所だけを直します。
完成の基準は、文章の長さではありません。担当者へ連絡しなくても、同じ資料から現状維持、再検討、廃止のどれへ進むか選べることです。次の一件から短く残し、見直す条件が動いた日に記録を開いてください。
次に読む