ITプロジェクトの不具合管理が機能しない本当の理由──記録はあるのに分析できない可視化崩壊

不具合管理（障害管理）プロセスは多くの現場で定義されており、テンプレートや選択式の分類も一般的に整備されています。しかし現実には、「記録はあるが分析に使えない」「傾向がつかめない」「そもそも入力されていない」といった問題が発生します。

この問題の本質は、不具合管理が単なる記録作業ではなく、意思決定や改善に結びつく情報設計として成立していないことにあります。

---

不具合管理には一般的な型があるが、そのままでは機能しない

不具合管理のテンプレートやプロセスは、すでに存在している（情報の器はある）

不具合管理には、標準的な構成要素があります。ITパートナには、たいてい様々なプロジェクトの経験を詰め込んだ不具合管理のテンプレートや、基本的なプロセスがあります。

つまり、どんなプロジェクトでも、必要な形式は揃っていることがほとんどです。

テンプレートはプロジェクトに合わせて調整されて初めて意味を持つ

しかし同じテンプレートでも、うまく機能する現場と機能しない現場があります。

その違いは次のような、不具合管理の運用に関する設計要素にあります。

• 何を分析したいのかが明確か
• 分類粒度が実態に合っているか
• 集計・分析を前提にしているか
• 改善につながっているか

システムテスト以降の実際の不具合対応を通じて設計は調整される

不具合管理は机上で完成するものではなく、実際の不具合対応を通じて初めて改善されます。どんな不具合が生じ使は、プロジェクトによって違いがあります。難しい機能を多く作っていれば、設計やプログラムの不具合が。データ定義を大々的に見直したプロジェクトでは、データに問題が多くなります。

• 分類は妥当か
• 記録粒度は足りているか
• どこが欠けているか

このプロセスを通じて、情報設計が現実に最適化されていきます。

---

不具合管理は設計ではなく「改善ループを持つ運用」である

情報が循環するかどうかで品質は決まる

不具合管理の本質は以下の流れです。

不具合発生 ➡ 原因分析 ➡ 不具合対応 ➡ 集計 ➡ 傾向把握 ➡ 改善策

この循環がなければ、データは蓄積されても意味を持ちません。特に、後半の「集計 ➡ 傾向把握 ➡ 改善策」が、全体的な品質の底上げに不可欠です。

不具合対応を実際に経験することを通じてしか、傾向把握の精度は上がらない

一般的な分類軸や記録項目は、予め置くことができます。しかし、実際には、それだけでは、プロジェクトの実態を把握するには、足りないことが多いです。

• 特定分類の不具合が多発し、より深掘りして状況把握する必要がある
• 分類が合わないケースが頻出して、その他分類が多くなってしまう
• 暫定対応が多くなり、暫定対応に関しても、詳細を記録する必要が出てきた

こういった事項は、実際に不具合対応をしはじめた後でしか補正できません。

---

「後で書く運用」が機能しない構造

スピード優先は誠実さから生まれる自然な行動である

不具合対応では復旧が最優先となり、記録は後回しになることがあります。特に、フェーズの終わりが近づいているときなどは、頻発しがちです。プロジェクトの管理標準でも、即時での記録が求められており、悪いと分かっていても、時間を優先してしまいます。

多くの場合、その背景には次のような心理があります。

• 早く復旧して影響を止めたい
• 周囲に迷惑をかけたくない
• 問題を自分の手で早く収束させたい

つまりスピード優先は、真面目さ・責任感の結果として自然に発生する行動です。

そのため、自主性に任せていても、改善されることはありません。同じ問題が、繰り返されることになります。

コンテキスト消失により後からの記録は必ず劣化する

時間が経つと以下の情報は失われます。

• 判断の前提
• 切り分けの仮説
• 当時の制約条件

その結果、後から書かれた記録は分析に耐える品質を維持することが難しくなりがちです。

記録しても使われないと認識されると、品質は崩壊していく

データが分析や改善に使われない状態が続くと、現場では次のような行動変化が起きます。

• 最低限だけ埋める
• 詳細を省略する
• 分類を適当に選ぶ

結果として情報の質は徐々に低下します。

---

情報が活かされない現象の例

例①：原因分類があるのに傾向分析に使えない

選択式の分類があっても、次のような状態になることがあります。

• 原因分類が未入力のまま
• 原因分類で「その他」が増える
• 適当に選ばれる

例②：データはあるが傾向が見えない

もう一つの典型は以下です。プロジェクトの運営が難しくなり、PMOや開発管理チーム、テスト事務局なども、対外的な説明などに追われていると、陥りがちな状況です。本質的な改善には、不具合の傾向分析➡改善が必要ですが、忙殺されているときに起きがちです。

• データは蓄積されている
• しかし分析されていない
• 改善に繋がっていない

これは「せっかく情報はあるのに、意味が生まれていない状態」です。

---

不具合管理の実務的な運用イメージ──点から面への改善（俯瞰的に見る）

原因分類を集計し局所対応から構造改善へ

不具合管理の要諦は、単発対応ではなく傾向把握にあります。

例えば：

• 同じ原因をまとめて対策する
• 発生傾向を構造として捉える
• 再発パターンを横断的に潰す

傾向分析を改善計画へ反映する

傾向分析を行うことで、それまで点での対応（個別の不具合対応）に留まっていたところから、面での対応（同種問題をまとめて対応、潜在的な・将来の問題を網羅的に対応）することができるようになります。

こういった面での対応ができるようになると、一気に品質は上がっていきます。

改善計画があることで、不具合管理表の情報品質が改善する

そして、そういった活動に使われるようになると、自然と、不具合管理表の情報品質も上がっていきます。自分だけしか使わない情報は、自分の仕事がするのに十分な情報があれば良いと思いがちです。しかし、上司や仲間が使うとなれば、違います。他の人が見て分かる粒度・品質で書く意識が芽生えてきます。

使われる ➡ 丁寧に記録される
意味がある ➡ 正しく分類される
フィードバックが返ってくる ➡ 改善される

---

不具合管理の成否を分けるのは「俯瞰できる人材」である

点ではなく、面（構造）で捉える役割が必要

重要なのは個別対応ではなく全体構造の把握です。

当然ながら、点で対応するよりも、難易度は上がります。様々な情報から傾向を見つけていく訳ですから、それなりのスキル・経験が必要になります。

• 傾向を読む
• 偏りを見つける
• 原因構造を特定する

この役割がないと仕組みは形骸化する

しかし、前述のように、個々の不具合対応を点で行っている限りは、不具合管理の質は上がっていきません。

結果として、傾向分析に耐えないデータが積み上がり、いざ対策を打つことが喫緊の課題になったときには、まずは不具合管理表の品質を上げるところから始めなくてはいけないことになります。

• 個別対応の積み上げになる
• 分類が入力作業になる
• 分析が行われない

単なる管理ではなく構造設計が必要

不具合管理の管理者というと、個々の不具合チケットを迅速につぶし込めるよう、追い込んでいく人というイメージがあるかもしれません。そういった特性も重要ではありますが、より重要なのは、構造的に問題事象を捉えて、大きく改善活動につなげていける人材です。

意外に、この重要性は認知されていないように見受けます。

---

ここまで、不具合管理とは、個々のチケットをつぶし込んでいくことだけでなく、改善ループを回していくことだとお話してきました。

そして、不具合管理表の記載粒度や品質が非常に重要であること。粒度や品質を維持・改善していくためには、より大きな改善ループ（不具合チケットの情報を集計して、改善活動につなげていくこと）が大切であることもご理解頂けたかと思います。

また、そのためには、その循環を回せる人材も必要です。皆さまのプロジェクトでも、人材確保を確実にされることをお勧めします。

最後まで読んで頂き、ありがとうございました。ご意見・ご感想を頂けますと幸いです。

ITプロジェクト研究会

---