なぜ製品に関する決定が何度も蒸し返されるのか

あるプロダクトチームが、ネイティブのモバイルアプリを構築すべきか、それともプログレッシブウェブアプリ（PWA）にすべきかを評価するために2週間を費やします。彼らは選択肢を調査し、エンジニアリングチームに実現可能性を相談し、ユーザーデータを分析した上で、特定の制約事項に基づいてPWAのアプローチを採用することを決定します。この決定はいくつかのSlackスレッドで議論され、ミーティングでディベートが行われ、フォローアップメッセージで確定されます。そして開発が始まります。

3か月後、新しいVP（副社長）が着任します。彼は尋ねます。「なぜネイティブアプリではなく、PWAにしているのですか？」誰もすぐにその理由を説明できません。Slackのスレッドは過去に流れてしまっています。ミーティングは録画されていませんでした。フォローアップメッセージは、数千件のメッセージが埋もれるチャンネルの奥深くに沈んでいます。そのため、議論は一からやり直しになります。同じ議論が繰り返され、同じ分析が行われます。そして2週間後、以前と同じ人々（すでに退職した人を除く）と、再検討のきっかけを作った新しいVPの時間を浪費した末に、まったく同じ結論に達します。

この「再審議（リリティゲーション）パターン」は、プロダクト開発組織において最も一般的であり、最もコストのかかる非効率性の一つです。時間を無駄にし、チームを失望させ、その決定が確定していることを前提とする後続の作業を遅らせることになります。

なぜこれが起こるのか

意思決定自体は通常優れています。その理由付けも通常は妥当です。問題は、その理由が、後から疑問が生じたときに見つけられるような形で保存されていなかったことです。

プロダクトに関する決定は通常、Slackでの議論、ミーティング、そしてインフォーマルな会話の組み合わせによって行われます。それぞれのチャネルが理由の一部を捉えていますが、全体像を検索可能で永続的な形で保存しているものは一つもありません。決定事項は、3つのSlackスレッド、2つのミーティング、そして共有されたもののどこにも整理されて保管されていない1つのGoogleドキュメントに分散してしまいます。

「なぜこれを決定したのか？」と誰かが尋ねたとき、チームがすぐに回答を出せないのは、複数のチャネルを検索し、タイムラインを再構築し、どの議論がどこで行われたかを思い出す必要があるからです。理由を見つけ出す手間の大きさから、調べるよりも再び議論し直した方が簡単になってしまうことがよくあります。

解決策としての「決定ログ」

それぞれの重要なプロダクトの決定を、その理由、代替案、制約事項とともに記録する決定ログは、回答を即座に検索可能にすることで、再審議を防ぎます。

フォーマットはシンプルです。問いは何だったか、どのような選択肢が検討されたか、何が決定されたか、その理由は何か、そして決定を再検討するために何が変わる必要があるか、です。新しいVPが「なぜネイティブではなくPWAなのか？」と尋ねたとき、チームは彼に決定ログを示します。VPはその理由を読み、制約事項を理解し、決定を受け入れるか、あるいは元のチームが持っていなかった新しい考慮事項を提示します。どちらにしても、本来であれば2週間を費やしていたはずの再審議の議論は、15分の読書時間に凝縮されます。

課題は、決定ログを一貫して作成することですが、ここで自己執筆型ドキュメンテーション（self-writing documentation）が重要になります。システムが、PWAの決定が議論されたSlackスレッドや、それが確定されたミーティングをキャプチャし、それらの情報源から構造化された決定ログを自動生成する場合、誰も個別のドキュメントを作成することなくログが作成されます。決定はチームの通常のワークフローの中で行われ、ドキュメントはそのワークフローから自動的に生成されたのです。

複利的な効果

決定ログは、蓄積されるほど価値が高まります。半年後、チームは決定とその理由の検索可能なアーカイブを持つことになります。1年後には、プロダクトがどのように進化してきたか、そしてその理由を示す包括的な記録が完成します。新しいチームメンバーは、決定の履歴を読むことで、プロダクトが現在どのようになっているかだけでなく、なぜそうなったのかを理解できます。これこそが、すでに解決済みの領域を蒸し返すような提案を防ぐために必要な文脈です。

また、決定ログは意思決定の質を長期的に向上させます。なぜなら、意思決定の理由に対する説明責任が生まれるからです。根拠とともに文書化された決定は、後から振り返って評価することができます。その理由は妥当だったか？制約事項は正確だったか？今日同じ決定を下すだろうか？このような内省的な実践は、決定とその理由が決定後数週間で失われてしまう状況では不可能です。

よくある質問

どのような決定をログに記録すべき「重要な」決定とみなしますか？ プロダクトの方向性、アーキテクチャ、優先順位付け、またはスコープに影響を与え、後から誰かが質問することが予想される決定全般です。新しいチームメンバーが「なぜこのような仕様になっているのか？」と尋ねる可能性が高い場合は、その理由を文書化しておくべきです。日常的な実装レベルの決定にログは必要ありません。

これによって意思決定のスピードが遅くなりませんか？ 決定ログが既存の議論から自動的に生成される場合、追加の時間コストは発生しません。チームはこれまで通り意思決定（Slack、ミーティング、ドキュメント）を行います。ログの作成は、その副産物として行われます。

状況が変化したために再検討が必要な決定についてはどうですか？ 決定ログには、「この決定を再検討するために何が変わる必要があるか」を含めるべきです。それらの条件が満たされたとき、決定を再開することは適切であり、そのログが起点となります。これは、新しい情報がないまま決定を蒸し返す「再審議」とは異なります。

関連記事：プロダクトナレッジベースの構築方法、コードベースは文書化されているのに意思決定はされていない理由、ドキュメンテーション負債。 関連ページ：決定ログ、自己執筆ドキュメント、プロダクトマネージャー向け。