【問題解決管理】問題解決作業の開始

問題の登録、分析、影響調査、そして評価をおこない、「解決する」と決定したら、あとは問題を解決するために活動を開始するだけです。ですが、『問題解決する』とひとくちに言っても、

　「どんな対策を講じるのか」

について、その妥当性が確認されないまま、担当者の気ままに対応するのはより大きな問題を生み出しかねません。対策内容のレビューを含む適切な活動を開始しなくてはなりません。

妥当性確認

問題解決管理責任者（および関係者）は、解決担当者が対策素案を作成の後、その内容についてレビューします。レビューの方法はなんでもかまいませんが、可能であれば"インスペクション"方式の方が良いでしょう。品質面、関係者間の連携、レビュー負荷、諸々を考慮しても、一番バランスが取れていると思います。

確認するポイントは次のようなものがあります。

　・「問題自身の解決」について明確か
　・対策内容は「分類」を本質的に解決できる内容になっているか
　・対策による影響範囲と影響は特定できているか
　・影響範囲が広範囲の場合、「影響範囲の解決」について明確か
　・類似箇所とその解決要否の判定は特定できているか
　・「類似箇所の解決」について明確か
　・対策工数は算出できているか

「問題自身の解決」「影響範囲の解決」「類似箇所の解決」はそれぞれ独立していなければなりません。これらがごちゃ混ぜになっていると、担当者が１人で対応する場合はなんとかなるかもしれませんが、複数人の作業者にわかれて対応せざるを得ない場合、一人ひとりの対策内容に誤差が出てしまう可能性があります。そのため、複雑度は極力低い状態を維持しなければなりません。

また、「影響範囲の解決」については、担当者および関係者の特定や、影響をあたえる作業や内容の特定ができていなければなりません。プログラム的な影響だけを見ればいいわけではないのです。

さらに、「類似箇所の解決」においては、問題が次の要因で特定された場合、それぞれ確認する内容が異なることを忘れないようにしましょう。

承認

問題解決管理責任者（および関係者）は、先述の（妥当性確認）の内容を確認し、承認します。承認されていない問題を勝手に対策することは許されません。もしも、勝手に対策してしまった場合、「影響箇所」や「類似箇所」が明確になっておらず、より深い問題に発展してしまう可能性があるからです。

また、（妥当性確認）においていずれか１つでも確認できなかった場合は、否認または差戻しを行います。

変更依頼

解決担当者は、対策実施の承認を受けると、次に〔変更依頼管理手順〕に従って、対策開始前に変更依頼を行います。変更依頼時点で、〔問題記録〕のステータスも『変更依頼』へ更新することになります。

ちょっと面倒くさいかも知れませんね。

実際、こう言う手続きをしっかりするような開発プロジェクトと言うのはあまり見かけません。私が知る限りでも、よほど大きな規模のトラブルプロジェクトくらいでしょうか。

また、こうしたワークフローをメールやEXCELなどでやり取りするのは非常に負担が大きいものです。個人的には、プロジェクトマネジメントだけではなく、『開発』以外のプロジェクト進行に必要な間接業務すべてに対してフォローできるマネジメントツールを作りたいんですよね（まぁ、今となってはそこまでの技術力も根気もないので、案だけはあっても作れはしないのですが）。

SaaS（Software as a Service）として月額/年額ライセンス化すれば、絶対売れると思います。

対策

変更依頼の承認後、〔問題記録〕に記載した"実施計画"に従って対策を実施していきます。対策に着手する時点で、〔問題記録〕のステータスも"対策"へと更新することになります。

対策およびその動作確認については、原則としてローカルの開発環境内で行い、結合テストレベルの確認については、変更管理委員会から指示されたリポジトリ（テスト環境下）を用いることになります。

本番環境、あるいは全体開発環境へマージするのは、確認が取れ、

　「問題そのものが解決されていること」
　「影響範囲に、問題が派生していないこと」
　「類似箇所の対策も完了していること」

それぞれの安全性が確保されたのちと言うことになります。