「意思決定」を「記録」することの重要性
最近はチームマネジメントもそうですが、全社エンジニア組織の体制や制度まわりのIssueに取り組むことが多くなりました。
いきなりですがみなさんはADR(Architecture Decision Record)をご存知ですか？
誤解を恐れずに言ってしまうと、ソフトウェア開発・システム設計における重要なアーキテクチャ上の意思決定を記録するための文書です。どのような技術選択をしたのか、その選択理由や背景、そしてその影響を明確に残しておくための形式化がなされています。
弊社でもエンジニアが技術的な意思決定をする際に書く文化が根付いていると思います。
私は同じようなことをエンジニアリングマネジメントの「意思決定」においてもした方がよいと考えているのです。
「意思決定」は下記の考えに私も同意しています。
費用対効果が合う施策「だけ」を行なうのは、意思決定とは言いません。メリット・デメリット、リスク・リターンを天秤にかけ、「やる方がいい未来がくる」と自分の責任で下す決定を意思決定と呼びます。判断に迷ったときは、この定義に戻って考えましょう。
費用対効果が合う施策「だけ」を行なうのは、意思決定とは言いません。メリット・デメリット、リスク・リターンを天秤にかけ、「やる方がいい未来がくる」と自分の責任で下す決定を意思決定と呼びます。判断に迷ったときは、この定義に戻って考えましょう。 pic.twitter.com/j9d0SiqEr7
— 澤山モッツァレラ / unname / PRとコンサル (@diceK_sawayama) October 10, 2024
加えて、私はこの「決定」は下記の「決断」に近いことも同意しています。
「情報を集めれば理屈で答えが出せるのが判断、今は情報を集めることができない中で答えを出さないといけないのが決断、リーダーがやらなければならないのは決断」
つまり、エンジニアリングマネジメントの「意思決定」は事業及び組織の不確実性・制約条件がある中で対象とする短期ないしは中長期の未来を据えたうえで、ものごとを「決断」することだと私は考えているのです。
この「意思決定」が積み重なったものが組織のいまです。
ただし事業の経営方針・戦略変更や組織の人事変更などにより、その「意思決定」によって生まれた制度やとりきめは、表層的な事実しか理解されないことが多くあります。いわば氷山の一角です。
例えば、その制度を決めたEMがすでに辞めていて意図が理解できなかったり、未だ在籍していたとしても当時の制約条件や考慮しなければいけないことを思い出せないなどです。
最悪のケースはその事実が曲解され別の見方をされてしまっていることも考えられるでしょう。
そのため、なおさらエンジニアリングマネジメントにおいても「意思決定」の「記録」が必要だと考えています。
それでは、最近私がどのような記録をしているか簡単に説明しようと思います。
ベースはMarkdown ADR light(MADR)としています。詳しくは参照のリンクをみてください。
そのうえで私が作っているフォーマットは以下の通りです。
タイトル: 決定したことを簡単に表す名前
ステータス: 提案中/採用/廃止
どの段階にいるのかを明確にすることで、関係者がどのタイミングで関与すべきかがわかりやすくします
コンテキスト: その時の状況(制約条件)や課題、背景となる情報
意思決定を下す際、組織のいまを明確にすることが必須です。例えば、リソースや技術的な制約（既存のアーキテクチャとの互換性やスケーラビリティ要件）・当時の人事制度など、何が意思決定に影響を与えているのか、解決しだい課題とともに記録します。これにより、将来的に同じ状況が再び発生した場合に、過去の判断を参照する際に役立ちます。
決定内容: 何を決定したか、対象とする時期感と影響範囲も記述する
その決定がいつから有効になるのか、どの部分に影響を与えるのかを明確にすることが重要です。例えば、特定の制度・運用方針を決定した場合、その影響範囲（どのチームが関与するのか、システム全体への影響度）も合わせて示すことで、他のチームやメンバーとの連携を容易にします。
理由: その決定をした理由
意思決定には必ずその理由が存在します。それは技術的な優位性かもしれませんし、コスト効率やチームのスキルセットの影響も考慮されるかもしれません。ここでは、その決定がなぜベストな選択であったのかを記録します。これは、将来その決定を振り返った際に、当時の意思決定の背景や判断基準を理解するために重要です。
代替案: 他に検討した案や、それを採用しなかった理由
常に一つの選択肢だけではありません。他にどのような案が検討されたのか、そしてそれらを採用しなかった理由を記録することも重要です。これを明確にすることで、他のメンバーが同じ疑問を抱くことを防げます。
結果: 決定が与える影響や期待される結果
今回の意思決定によりどのような影響を与えるか、そしてその決定によって期待される結果を具体的に記述します。これを明確にすることで、決定の正当性を支えることができます。逆に、予期されるリスクや課題も記載しておくことで、将来的な振り返りがしやすくなります。
補足情報: 追加で必要な情報
意思決定に関連する追加の情報や参照すべきドキュメントを提供します。関連する技術ドキュメントや議論の記録、関係者のフィードバックなどが対象です。この情報があることで、将来の意思決定に対する理解がさらに深まり、必要に応じて他のメンバーが追加のインプットを得ることが可能になります。
エンジニアリングマネジメントにおける意思決定は、慎重なプロセスを経て透明性を持って行われるべきだと考えています。上記の項目を整理し記録することで、意思決定の質を高めるとともにチームやプロジェクト全体に持続的な効果をもたらすことができると考えています。
この取り組みをはじめることで、これまでの意思決定においてどういった制約があり・その結果どうなったのか証跡が残ることで、いまの意思決定の助けになることを期待しています。
まだ実践したばかりなので、振り返った際にこの取り組みについてどうだったか改めて書きたいと思います。
この記事が気に入ったらサポートをしてみませんか？