属人化解消・ナレッジ共有

判断の背景が残っていないことが原因です。「なぜこの設定なのか」「障害時にどの条件で切り分けるのか」「どこまで影響したら誰へ連絡するのか」までは手順書に残りにくいためです。手順に加えて、対象環境、適用条件、前提、例外、判断理由、確認者、更新日を一緒に残します。残し方の実例は、守るだけの情シスから、活用と改善を進める情シスへで解説しています。

できます。要件定義書、設計書、ソースコード、テスト仕様書、運用手順書、チケット、障害記録を許可された範囲で整理し、類似する設計、過去の判断理由、障害時の注意点、レビュー観点を共有できる形にします。共有できる形に整える手順は、チームで育てられる開発資産へにまとめています。

使えます。プロジェクト管理では、設計資料、業務ルール、運用手順、障害記録、承認に関する規程を参照し、進捗・リスク・体制の整理を共通の情報をもとに行えます。サポート業務では対応履歴と判断理由を次の担当者が使える形で残せます。管理業務の例はチームで成功を再現できるプロジェクト運営へ、サポート業務の例は対応のたびにナレッジが育つ組織へで紹介しています。

登録時の区別が必要です。対象システム、対象環境、版、更新日、所有者、確認者を明記し、現行手順と旧手順、正式情報と検討中情報を区別します。古い資料の更新、利用停止、削除の運用もあわせて決めてください。登録時の注意点は、情報システム部門の活用事例で解説しています。

取り組み事例があります。株式会社カプコン様では、担当者の入れ替わりや退職で開発経緯やインフラのノウハウが失われやすい課題に対し、既存コードのリバースエンジニアリング、仕様書や不具合対応の経緯を含むコンテキスト整理、IaCコードのドキュメント化を進めています（公開事例）。同様の進め方は、ゲーム開発でのJitera活用ガイドで確認できます。