ADRならぬxDRであらゆる意思決定の記録をすぐに確認できるようにしている話

こんにちは、さたかです。今日は私が所属しているインフラ部署で実施している、Div技術向上というワーキンググループ(以下、WG)に関する記事の第2弾になります。
(第1弾はこちらです。)
今回は最近取り組みを開始したxDRというドキュメントについてお話したいと思います。

xDRとは

xDRとは【x Decision Record】の略になります。【x】は【何かしらの】という意味で、日本語言うと【何かしらの決定記録】のようなニュアンスになります。
元々はADR【Architecture Decision Record】というものを参考にしています。

ADRとは

ADRは重要なアーキテクチャー決定を、そのコンテキストおよび結果と共に取り込むための技法でその名の通り、システムアーキテクチャに関する話をまとめたものです。
(引用元のサイトはこちら)

xDRの詳細

xDRでは以下のような事項を記載対象としています。

  • 意思決定の結果が長期に渡るもの
    • 方針やポリシーの決定
      • 例: 子会社の〜は本社と全く同じ権限を与える
      • 例: エンジニアセグメントから外向きのxx通信は許可する
    • 導入製品を選んだとき
      • なぜXXを採用し、標準的なYYを採用しなかったのか
        • 例: スイッチの購入をA社ではなくB社にした
        • 例: アンチウィルスソフトにはCツールを使う
  • 同様の意思決定が反復されることが想定されるもの
  • その他、重要と思われる事項
    • 意思決定の背景や経緯の共有が重要な内容

Decision Recordと書くと難しそうに聞こえますが、そういったことはなく日々発生するであろう決定事項を記載するイメージです。

期待している効果

xDRを活用することで以下の効果を期待しています。

  • 意思決定についてその場に居合わせない人も詳細を知ることができる
  • 意思決定速度が上がる
  • 意思決定のバラツキが減る
  • 意思決定を委譲することができる
  • 業務引き継ぎ時の負担減少

効果の実例については後述します。

テンプレート

ドキュメント作成において課題に上がりやすいのは「どういう風に書いたらいいか分からない」という点です。
この点について対応すべく、ドキュメントテンプレートを用意しました。

  • テンプレート内容
    • コンテキスト
    • 決定を必要とする項目
    • 決定内容
    • 決定を適用した後の結果
      • 「プラス」の結果
      • 「マイナス」の結果
      • 「中立」の結果

作成ガイドライン

また、作成ガイドラインを整備することで、タイトルの統一性やドキュメントステータスの明示化を図っています。

(当社が使用しているドキュメントツールは各ドキュメントにラベルを付けることが可能です)

  • 作成ガイドライン内容
    • ページ作成時にテンプレートを適用する
    • タイトルは xDR-xxxx-決定内容(xは通し番号)
    • ステータスは、 提案 承認 却下 廃止 の4ステータス
    • ステータスに応じてドキュメントにラベルを追加する

フロー

ドキュメントリリースまでのフローは概ね以下の通りです。

  1. 作成者がドキュメントを作成し、「提案」ラベルを付加しレビューを依頼する
  2. レビュアーはドキュメントをレビューし、内容がOKであれば「承認」ラベルを、指摘事項があれば「却下」ラベルを付与する
  3. 「却下」の場合は指摘事項について、作成者が適宜修正を実施し再度レビューを依頼する
  4. 「承認」の場合はドキュメントリリースとなる

具体例

ここで具体例を紹介したいと思います。

タイトル

検証用AWSアカウントのリソースは定期削除する

具体的な例

f:id:AdwaysEngineerBlog:20220304124914p:plain

xDR導入までの道のり

ここからはxDRを導入するまでに実施したことについて説明していきます。

背景

当WGではインフラ部署のエンジニアのスキル向上のための施策を検討・展開していく役割を担っています。
その中でドキュメントアウトプット文化やレビュー文化の浸透を目的とした活動を行っていましたが、以下のような課題がありました。

  • システム導入時の決定記録がなく、担当者しか詳細が分からないシステムがある。
  • それにより、トラブルなどがあった際対応方針の決定が遅れたり、対応できる人が限られる場合がある。

上記のような状況を回避すべく、システムアーキテクチャに関する決定記録であるADRを残していこうという動きをとることになりました。

ADR時代

ADRについては2021年4月よりインフラ部署内に展開を開始しました。四半期ごとに目標数を設定し、毎月の部署内会議で作成の奨励、作成状況の共有を行っていきました。
作成数推移は以下の通りです。

  • 2021/4 - 2021/6
    • 目標数10件 / 作成数19件
  • 2021/7 - 2021/9
    • 目標数20件 / 作成数5件
  • 2021/10 - 2021/12
    • 目標数20件 / 作成数1件

結果的に作成数は徐々に下がっているものの、計25本ものADRが作成されたことで確実に記録が残っていきました。

xDR化

ADR作成を展開・奨励し始めて少し経った頃、とある会話が交わされました。
「アーキテクチャ以外にも決定事項ってあるよねー」「たしかに!」
よくよく考えてみると世の中は決定事項に溢れています。何かしらの意思決定が日々行われています。
インフラ部署の業務においても、運用管理業務や他部署との協業など業務において何かしらの約束事が存在します。
その中で数年前に決定されたことが記録として残っておらず、何となく慣習としてやっている業務などが少なからず存在します。
そういった状況を解消するためにもシステムアーキテクチャにこだわらず、何かしらの意思決定を記録に残していこうとなりました。
そうして出来上がったのがxDRです。

xDRの効果

社内ツールのプラットフォームをクラウド環境に移行しようとした時です。
移行方法の候補が複数あったため、細かくレビュー・実装を繰り返していました。そういった状況が続くとついつい大枠の方針などを忘れがちです。
それにより毎回のレビューで大枠を思い出すところから始めないといけないといったケースがあり、予想以上に作業時間がかかっていました。
そこでxDRの出番です。xDRを活用することにより、決定事項やそれに至ったプロセスが明確なので担当者間の意思統一スピードが上がりました。
また、プロジェクトに後から人が加わった際に、決定事項だけじゃなく、決定のプロセスも分かるため共有がスムーズに進みました。
まさに狙い通りの効果があったと言えます。

xDRの今後について

xDRの活用推進はまだまだこれからといったところではありますが、効果のある取り組みだと感じています。
文化として浸透を図っていく上で、私自身xDRを実際に作成してみて、以下の点が難しいなと感じました。

  • 誰が読んでも同じように理解してもらえる文章であること
  • あくまで意思決定に関する事実を残すのであって、物事の良し悪しを記載するものではないこと
  • ついつい決定事項のみ記載してしまい、採用しなかった案についての記載を忘れてしまう

中々パワーのかかる作業でしたが、作成した後は「そのルールについてはこのドキュメント見たらわかりますよ!」と言える安心感を手に出来ました。
ADRを展開した際には記事の作成数や記事を書いた人数などを数値指標として浸透度合いを見ていたので、同じような動きが取れればいいなぁと思っています。
インフラ部署では業務によってはアーキテクチャの設計にあまり関わらないメンバーもおりますが、xDRであればルールなどでも残すことが出来るのが良い点です。

おわりに

ADRにしてもxDRにしても、記録を残すというのはとても大事です。
特に自分にしか分からない状態になっていると、自分にしか対応できず周囲に迷惑をかけてしまうこともあり得ます。
何かしらの意思決定に関わっている方は是非記録を残してみてください。