懸案管理台帳を作成する意味と一覧に必要な項目について

システムの開発中のみならず、運用・保守対応をしていても発生する懸案事項。元はといえばシステム構築時のつくり込みが足りないばかりに生まれてるため、いつかは対応しなければなりません。

エンジニアにとっては喜ばしくない懸案事項ですが、懸案管理台帳のような一覧表にまとめて、必ず対応ステータスを記載するようにしましょう。

懸案管理台帳を作成する意味

まず懸案管理台帳とも呼ばれる懸案一覧表を作成する意味ですが、SEの対応漏れを防止するためです。

現場でよくあるトラブルが、担当SEがお客様から不具合連絡を受けたにもかかわらず、懸案として情報共有できずに放置されたままになり、クレームに発展するケース。こうした場合も懸案一覧に情報を残しておきさえすれば、本人のみならずマネージャーがフォローする形で、放置するようなことは防げたはずです。

自分たちにとっても、お客様にとっても「あってよかった」となるのが懸案一覧表。担当SEはお客様から不具合連絡を受けたら、すぐに懸案一覧に転記するようなクセをつけるようにしておくとよいでしょう。

懸案一覧表に必要な項目

懸案一覧表にはどのような項目を持たせておくべきなのかについて。あくまで一例ですので、参考までですが・・。

• 項番
• 懸案名
• 内容
• 画面名
• 分類
• 発生日
• 提示者
• 対応者
• 対応策
• 状態
• 完了予定日
• 完了日

項目としては上記のようなところでしょうか。それぞれの説明は以下の通り。

【項番】

不具合管理表だろうと、懸案管理表だろうと、一覧表に項番は必要不可欠な項目です。項番をつけることで、情報共有がスマートに行えます。

【懸案名】

簡潔に懸案内容が分かる名称をつけます。

【内容】

懸案事項の詳細を記載します。より具体的に、かつ簡潔に書くことが大事です。

【画面名】

もし画面操作のあるシステムの場合、不具合を起こしている画面名を記載します。バッチ処理なら「画面名」ではなく「バッチ名」でもよいかもしれません。

【分類】

「外部設計」「内部設計」「詳細設計」「製造」「単体テスト」など、どの工程が不具合を引き起こす原因となったのかを記載します。

【発生日】

不具合の連絡を受けた日付を記載します。

【提示者】

不具合を見つけた人を記載します。たいていの場合はお客様の部署や氏名となります。

【対応者】

懸案対応を行うエンジニアを記載します。懸案が発生した時点で対応予定者を記載するようにしておけば、その後のフォローも容易になります。

【対応策】

懸案を解決するために実際に取った対応策を時系列で記載していきます。

（例）
2017.07.03
懸案の原因調査（画面内の引数受け渡しが不具合の原因）。
2017.07.07
モジュール「P-1001」にて変数「x」の初期値を0に設定しておくことで対応。
2017.07.10
お客様説明を行い完了とする。

【状態】

「未着手」なのか「対応中」なのか「完了」なのか、懸案のステータスを記載します。

【完了予定日】

懸案事項を記入する際に、完了予定日についても設定しておきます。予定日を設定しておくことで、マネージャーがフォローしやすくなります。

【完了日】

ステータスが完了のものは完了日を記載します。

常時ステータスを更新して生きた懸案台帳にしよう

懸案一覧表を管理していく上で重要なことは、対応ステータスを常時更新して、生きたドキュメントとすることです。

そうすることで、完了予定日が過ぎているにもかかわらず、ステータスが「未着手」になっていれば、マネージャーが担当SEに状況を確認し、対応が手遅れになる前に何かしらの手を打っておくことができます。

対応ステータスを常時更新していくことで、メンバー間でも情報の共有ができ、メンバーを管理するマネージャーもフォローしやすくなるのです。マネージャーはメンバーがステータスの更新忘れをすることがないよう、徹底して指示を出しておきましょう。

 

おわりに

懸案管理台帳のようなドキュメントは地味な存在ではありますが、システム開発の現場や、保守対応作業においても、非常に重要な役割を果たしてくれます。お客様との約束事を漏らして大問題になることを防ぐためにも、必ず懸案一覧表は用意しておくようにしましょう。