はじめに
こんにちは、情報システム部で社内ITの運用や改善に取り組んでいる斉藤です。
情報システム部（以下、情シス）では日々さまざまな判断が求められますが、その判断理由が記録に残らず困ることが増えていました。
今回は、ADR（Architecture Decision Record） という開発現場のプラクティスを、情シスの意思決定ログに応用した事例をご紹介します。
ADRとは
開発現場での使われ方
ADR（Architecture Decision Record）は、ソフトウェア開発の現場で使われている軽量なドキュメント形式です。
「アーキテクチャに関する重要な意思決定を、理由とともに1ファイル1決定で記録する」
というシンプルなコンセプト。
例えば
- なぜAというフレームワークを選んだのか
- なぜこの構成を採用したのか
といった記録を残すことで、時間が経っても開発経緯をたどれるようにします。
なぜ情シスでも取り入れようと思ったのか
開発チームで使われているこのプラクティスを見て、「これ、部署運営でも使えるんじゃないか？」と思ったのがきっかけです。
- ツール導入の経緯を残しておきたい
- 当時何を考えて判断したのか忘れないようにしたい
- 後任や異動者に経緯を引き継ぎたい
そういったニーズを満たす方法として、ADRのスタイルは非常に相性が良いと感じました。
アーキテクチャに限定されないため、私たちは意思決定ログという名前で運用を始めています。
このように、各チームで馴染みやすい名称に変えるのもおすすめです。
運用事例
レギュレーション
以下テンプレートで実施しています。
私達は部署内のタスク管理にBacklog（タスク・Wiki管理ツール）を使っていたため、Backlog上で意思決定ログを蓄積しています。
日々触るツール上にMarkDown形式で記載すれば、どのようなツールでも良いと思います。
意思決定サンプル
具体的には、以下のような内容が日々蓄積されています。
導入してよかったこと・変化
会話の中でも「これはADRに残そう」と自然に言える雰囲気ができた
完璧を目指さず、フォーマットやルールは最低限にすることを意識したため
- 同僚に対し「この件、意思決定ログ書いておいてくれますか？」
- 自分から「意思決定ログ書いておきますね」
といった会話が自然と出るようになりました。
新しいメンバーのキャッチアップがスムーズになった
「なぜそうなっているか」は、どうしても当時の業務担当者のみが詳しかったりします。
新しい情シスメンバーが過去の意思決定を検索すれば、議論にもすぐ入れたり、他部署にも説明できるようになりました。
業務ルールを変えやすくなった
会社や世の中は変化していくもの。
「当時はその判断で正しかった」「今は正解とは限らない」といった状況は頻繁に発生します。
この際、現在の業務内容を変える人には、エネルギーも慎重さも求められます。
当時の決定のコンテキストが残っていることは資産であり、安心して過去の決定を覆しやすい仕組み作りの一つになったと思います。
まとめ
意思決定に関する記録を残す運用を導入した結果、以下のような効果が得られました。
- 過去の判断経緯を部内で再確認しやすくなった
- 新規メンバーのキャッチアップが効率化された
- 業務ルールの見直し時に、根拠や背景が明確化された
この取り組みで現在の業務ルールを壊しやすくしたように、私達は常に変化し続ける組織でありたいと考えています。
このような日常に共感頂き、一緒に文化を作り続けてくれる方を募集しております。
以下の情シス求人よりお問い合わせ頂けると幸いです。
