Jiraで意思決定ログを残す：この方法を選んだ理由を覚えておく

リリースから6週間後、なぜ日次ダイジェストではなくメール通知を選んだのか聞かれます。Jiraチケットには作ったものが書かれ、コメントには「計画時に合意」とあります。議論を覚えている人は忙しく、どの制約が決め手だったかはっきりしません。

意思決定ログはその不足を補います。状況、選択肢、決定、影響を、チームが見つけられる場所に記録します。Power PackのDecision Logなら、説明対象の仕事に近いJira課題のそばに置けます。

このガイドでは架空の顧客ポータルチームが一つの有用な記録を作り、実装に結び付け、顧客のニーズが変わったときに見直す流れをたどります。

何を記録する価値があるか決める

すべての会話を残す必要はありません。実装方針、依存先、リリースの境界、小さな一作業を超えて影響する意図的な妥協など、将来の仲間が理由を知りたくなる選択から始めます。

このチームでは通知の届け方が該当します。即時メールの選択は実装、テスト、サポート案内、顧客の期待を左右します。代替案も検討しており、メッセージ量が増えたら再検討する予定です。

一方、ボタンラベルの誤字修正には専用の決定記録はおそらく不要です。区別は実用的に考えます。理由を知ることで、後から結果を保守、変更、説明する人が助かるかどうかです。

アーキテクチャ上の決定記録、いわゆるADRが参考になります。Michael Nygardの原文は、背景、決定、状態、影響を短く残し、置き換えられた決定も新しい選択への参照とともに保存する方法を説明しています。出典は末尾にあります。この例では、その軽量な考え方をJira上の実装判断に適用します。

決定の置き場所を明確にする

影響する仕事を最もよく代表するJira課題を選びます。この例では顧客ポータルの通知を調整する課題を使います。そこからすでに実装やテストの作業へ進めます。

置き場所をチームに伝えます。Power PackのDecision Logは課題単位なので、探すための簡単な習慣を決めます。通知の決定はここで管理すると調整用課題に書けます。別のプロジェクト索引を使う場合は、通常の運用でそこにも課題を登録します。

複数の課題にコピーを置き、勝手に一致し続けると考えるのは避けます。他のチケットからは決めた場所へ誘導できます。出力したコピーは議論に便利ですが、現在の立場を確認する原本は明確にします。

結論より先に背景を書く

背景は、なぜその問いが生まれたかを説明します。事実、制約、仮定を区別し、後の読者が変化した部分を見分けられるようにします。

チームはこう書きます。「顧客はサポート依頼が大きく変わったことを知る必要がある。現在のサービスにはメール送信がある。ポータルの初回リリースには受信箱を含めない。大部分の依頼では顧客に見える状態変更は少ないと予想しているが、公開後の通知量はまだ測定していない。」

これは「メールが最も簡単」より有用です。出発点を説明し、仮定を明示しています。メールが常に正しい経路だとも主張していません。

必要に応じて調査への参照を加えます。技術的な試作が判断材料なら、結果のあるJira課題を示します。顧客の声が重要なら、私的な情報を不要にコピーせず、関連する傾向を要約します。

新しい同僚が会議を丸ごと再現せずに状況を理解できる背景を目指します。選択に影響する詳細を残し、無関係な議論は元の場所に置きます。

本当に検討した代替案を比較する

役立つ記録は、他に何ができたかも示します。真剣に検討した案を挙げ、それぞれの利点と欠点を率直に書きます。

これは架空のシステムに対する説明用の評価です。別のチームに受信箱やダイジェスト機能がすでにあれば、比較は大きく変わります。良い記録は背景への依存を見えるようにします。

選んだ案が必然に見えるよう、却下した案を不当に弱く書かないでください。ダイジェストには個別のメールを減らす本当の利点があります。今回は現在の前提の下で、速さと実装範囲をより重視したため選びません。

選択肢と別の決定も区別します。顧客の全文をメールに載せるかどうかは、独自の確認が必要かもしれません。通知のあらゆる問いを一つに詰め込むと、何を合意したか分かりにくくなります。

選択と影響を明記する

完全な文で書きます。「ポータルの初回リリースでは、サポート依頼に意味のある顧客可視の状態変更があればメールを送る。内部編集では送らない。」

次に理由を書きます。「既存の配信経路を利用し、リリース範囲を扱いやすく保ちながら、顧客に進展を迅速に伝えられるため。」この例の判断理由であり、メールが普遍的に安価または高信頼だという主張ではありません。

影響にも同じだけ注意を払います。意味のある変更の共通定義が必要です。テストは連続した更新と重複処理を扱う必要があります。サポートはどの事象でメールが出るかを説明する必要があります。活発な依頼を持つ顧客には、望む以上のメールがなお届くかもしれません。

有用な影響の記述は、自然に次の仕事につながります。ここには必要性を記録し、実際のタスクはJiraで管理します。決定記録は仕事の理由を見つける助けにし、状態や担当者が競合する2つ目のバックログにはしません。

Power Packに記録を作る

対象のJira課題でPower Packを開き、Decision Log (ADR Lite)を使います。「通常のポータル状態更新に即時メールを使う」のように、実際の選択が分かるタイトルで追加します。

チームの用途に合う分類を選び、議論中はProposedから始めます。決定者を入れ、選択が固まったら決定日を記載します。決定者欄は責任者を記録するもので、名前を入れるだけで承認手続きが済むわけではありません。

背景を埋め、各案の賛否を追加し、選んだ案を指定し、影響を書きます。会話に参加しなかった人にも理解できる内容にします。

必要なら影響するJiraキーを加えます。編集画面ではカンマ区切りの課題参照を入力でき、影響する実装やテストのチケットを示せます。これは参照の記録です。課題間の関係を作る必要がある場合は、通常のJiraリンク機能を別に使います。

関係者と完成した記録を確認します。選択欄と文章が一致するか確かめます。特にローカルやオフライン表示の場合は、同僚に最新版を頼りにしてもらう前に保存状態を確認します。

状態で現在の立場を明確にする

Power PackにはProposed、Accepted、Rejected、Supersededがあります。未決の案と実装を導いている決定を読者が区別できるよう、使い方を合意します。

プロダクトオーナーのMayaが通知方式を決めたら、日付を記録してAcceptedにします。これは決定の位置付けです。実装完了、テスト合格、リリース許可を示すものではありません。

Rejectedでも同じ区別が大切です。採用しない理由を短く残すと、すでに行ったと知らずに次の人が調査を繰り返すのを防げます。実装チケットにつながらない場合も、有用な理由は残します。

前提が変わったら見直す

公開後、多くの依頼を同時に持つ顧客にもポータルが広がったとします。サポートから、毎日複数の通常メールを受け取る人がいると報告されます。これは当初の少ない通知量という仮定に直結する新しい背景です。

変更を提案する前に古い記録を開きます。以前は妥当だったトレードオフと、現在の製品が直面する問いを分けられます。既存の決定は即時メールを選んだ理由を説明しますが、別の条件でより良い方法を選ぶことを禁じません。

日次ダイジェストについて新しいProposedの記録を作ります。Power Packでは既存項目をProposedとして複製でき、出発点にできます。古い仮定、日付、影響は今は当てはまらないかもしれないので、すべてのコピーした欄を見直します。

新案が採用されたら以前の記録をSupersededにし、置き換え欄で新しい決定を参照します。最初からダイジェストを考えていたように書き直すのではなく、当時の理由を読めるように残します。

これはチームの文書化の習慣です。記録は編集可能なので、本質的な変更は置き換え用の新しい項目にし、通常編集は訂正や明確化に使うと合意します。不変の監査証跡とは扱わないでください。

日常の仕事で使える記録にする

新しい人の参加、再設計の提案、特殊な要件の理由を聞かれた場面で使います。課題のログ内では検索や絞り込みが役立ちます。Power PackはADR形式のMarkdownに出力でき、レビューや別の文書フローでも利用できます。

出力を共有する前に最新版を反映しているか確認し、チームが管理する課題を示します。ダウンロード文書はその時点の写しです。後で課題を編集しても、すでに送ったコピーは更新されません。

最近の決定で、また見直しそうなものを一つ選びます。背景、本当の代替案、選んだ方針、影響を書きます。Power PackでJiraの仕事のそばに置き、議論にいなかった同僚に読んでもらいます。なぜその選択が妥当で、何が変われば見直すべきか説明できたら、ログは役に立っています。

• Michael Nygard：アーキテクチャ上の決定を文書化する