はじめに

皆さんは「更新されておらず、作成された背景がわからないドキュメント」に遭遇したことはありますか？
遭遇した時、どのように対処していますか？

最新情報に更新しますか？
それとも更新せずに放置しますか？
古い情報だから削除するという手段もあるかもしれません。

私は、新卒１年目の駆け出しエンジニアなのですが、新卒で初めにアサインされたプロジェクトでまさに「更新されておらず、作成された背景がわからないドキュメント」に出会いました。
この記事では、私がそのようなドキュメントにどう向き合ったかをまとめていきます。
拙い文章ではありますが、最後まで読んでいただけると幸いです。

ドキュメントの情報を分類する

「更新されていない」と言っても、その情報が現状と一致しているのか、一致していないのかで対応方法が変わると思います。
そのため、まずは情報と現状が一致しているのかを泥臭く調査しました。
ここの調査は、特筆すべき点はありません。ひたすらドキュメントに書いてある内容を見ながらコードを見たり、システムを検証したりするだけです（結構つらい）。

その上で、それらのドキュメントの中にある情報が、有効期限が短く、更新頻度が高い情報（フロー情報）なのか、有効期限が長く、更新頻度の低い情報（ストック情報）なのかを分析しました。
フロー情報とストック情報は、以下の記事から知り、とても有用な考え方だと思い、採用しました。

一部、上記記事から抜粋します：

フロー情報は、詳細な議事録やフィードバック、思考ログなど、情報の有効期限が短く、更新頻度が高い情報を指します。例えば、あるミーティングのアジェンダを参加者に共有した場合、そのミーティングの前後ではアジェンダは参加者にとって価値のある情報ですが、時間が経つにつれてその価値は失われていきます。
一方で、ストック情報は、PRDやDesign Docsなど、有効期限が長く、更新頻度の低い情報を指します。

今思うと、「作成日が１か月前にもかかわらず現状と合っていない」のように、分類の際に基準を設ければよかったのですが、当時は「このドキュメントあまり更新されていないな」という感覚で分類していきました。

フロー情報を整理する

こうして、ドキュメントの中の情報をフロー情報とストック情報に分類することができました。
ストック情報は、現状と合っている情報ですので、そのままで構いません。しかし、フロー情報の方は現状と合っていないので対応を考えなければなりません。
ここで、考えられる対応は次の２通りでした：

現在の情報に更新する
情報を削除する

ここの情報の判断は上長に確認をし、これからも運用していかなければいけない情報なのかをすり合わせました。
しかし、上長もプロジェクトにアサインしていなかった時に作成されたドキュメントは判断が難しいものもありました。

そういったドキュメントの場合、「削除する」はかなりリスクがありました。
例えば、私の勝手な判断で削除し、その情報が後ほど参照したい情報だった時に大変なことになるのが想像できます。
そのため、私は「完全に削除する」のではなく、「アーカイブ済み」というディレクトリを作ってそこに削除したい情報を入れることにしました。
これにより、リスクを避けることができました。

ドキュメントの分類方法をドキュメント化する

最後に、これまで行ったドキュメントの分類方法をドキュメント化しました。
ドキュメント化することで、今後も「その分類方法にしたがってドキュメントを作成する文化」ができ、継続的に運用することを期待しています。
今回の記事で行ったことが、どのくらいの効果があったのかも将来的に記事にしようと思います。
（何事も継続することが大事ですからね。継続は力なり。）

まとめ

私は「更新されておらず、作成された背景がわからないドキュメント」に以下のような工夫をして向き合いました：

ドキュメントの情報を分類する
フロー情報を整理する
ドキュメントの分類方法をドキュメント化する

また、今回私はConfluenceというドキュメント管理ツールでこの記事に記載していることを実施しましたが、この知見はConfluence以外にも様々なところで活かせると思います。

他にも、ドキュメント管理のノウハウ等あればコメントしていただけますと幸いです

参考

社内ドキュメントはなぜ更新されないのか？情報の鮮度を最小限の運用負荷で維持する「イミュータブルドキュメントモデル」のススメ