問題解決管理プロセスと変更依頼管理プロセスを両立させるために
はじめに
システム開発／ソフトウェア開発は、一度作って終わりであることはまずありません。
日々発生する不具合やトラブルへの対応と、顧客からの変更要求の対応や将来を見据えた改修の積み重ねによって支えられています。
その中核を担うのが「問題解決管理プロセス」と「変更依頼管理プロセス」です。
Automotive SPICEでは、支援プロセス「SUP.9」と「SUP.10」として定義されています。
似ているようで役割の異なるこの2つを正しく理解し、連携させることが、システム開発／ソフトウェア開発プロジェクトの混乱と疲弊を避ける鍵となります。
今回は「SUP.9」と「SUP.10」を両立させるヒントをお伝えします。
問題解決管理プロセスと変更依頼管理プロセスのおさらい
問題解決管理プロセス：再発を防ぐための“根本治療”
問題解決管理プロセスの目的は、単なる不具合対処や障害復旧ではありません。
表面化した不具合や障害の背後にある真の原因（根本原因）を特定し、再発を防止することにあります。
場当たり的な対応を繰り返していると、「同じ不具合が何度も起きる」「現場が疲弊する」といった悪循環に陥りがちです。
問題解決管理は、なぜ起きたのかを構造的に分析し、恒久対策を設計するためのプロセスと言えるでしょう。
それゆえ、SUP.9：問題解決管理プロセスでは、「問題が他のシステムや関係者に影響がある場合に通知」して、類似問題の発生を抑制したり、「データを収集＆分析し、傾向」を把握することで再発防止策を講じることが期待されています。
変更依頼管理プロセス：リスクを制御しながら前に進む
一方、変更依頼管理プロセスは、システムやソフトウェアの変更を秩序立てて、安全に、確実に実施するための仕組みです。
変更は、改修や価値創出に不可欠ですが、同時に新たなリスクも伴います。
影響範囲の評価、承認フロー、実施計画、リリース後の確認といったステップを踏むことで、「適切に変更を実装する」と同時に「良かれと思った変更が別の問題を生む」事態を防ぎます。
それゆえ、SUP.10：変更依頼管理プロセスでは、「変更する作業成果物や他の変更依頼との関連を含めて分析」し、「実装前に、分析結果とリソースの利用可能性に基づいて優先順位を付け、承認」することが期待されています。
混同されがちな2つのプロセス
開発現場では、「問題が起きたから変更する」「変更したら問題が起きた」という事象が発生すること、また、「どうせ変更するなら手続きは共通化したい」という理由から、両者が混同されることがあります。
しかし本来は役割が異なります。
- 問題解決管理：なぜ問題が起きたのかを突き止める
- 変更依頼管理：対策や改善を、リスク管理しながら実装する
つまり、問題解決管理の“アウトプット”として検討された対策が、変更依頼管理プロセスに引き渡される、という関係が理想です。
仮に、両プロセスを共通の手続きに押し込んでしまった場合、原因分析や再発防止策の検討が、変更内容の検討と混同され、本来、問題解決管理でやるべき目的が希薄になる可能性が高まります。
その結果、「問題」が「単に、作業成果物を変更するイベントの１つ」という誤解が生じ、「再発を防ぐための“根本治療”」ができなくなってしまいます。
成熟した組織が実践していること
SUP.9とSUP.10をSUP.8：構成管理プロセスと合わせた関係図は以下になります。
不具合や障害などの問題が発生した場合、その情報を問題管理データベースに登録後、内容を調査し、原因や影響を分析します。
原因が、自分たちの開発対象であれば、変更する必要がありますが、テスト環境や関連する他システムに起因する場合もありますので、変更の必要がないケースもあります。
原因＆影響分析の結果、変更が必要な問題であった場合、変更依頼管理票を起票し、その情報を変更管理データベースに登録し、変更管理していきます。
問題管理と変更依頼管理を別々のデータベースとして管理していきたいのは、繰り返しになりますが、その役割が異なるからです。
- 問題解決管理：なぜ問題が起きたのかを突き止める
- 変更依頼管理：対策や改善を、リスク管理しながら実装する
例えば、JIRAのようなチケット管理システムで両者を実現する場合でも、登録したい情報（フィールド）は異なりますので、チケットタイプは別々に定義して管理していきます。
これらの情報は、単に、今起きている問題や変更への対応だけを考えると、「面倒だから記録したくない」「修正すれば良いので、適当な文章で書いておけば良い」など、疎かな活動になりがちです。
しかしながら、我々のお客様でも「情報が正しく書けていないため、後になってみても、状況を理解できない」というような声を聞きます。
特に、問題対処に変更を重ね、変更した箇所に更に問題対処を加えるソフトウェア開発では、記録する情報の正確性が重要となります。
これら両プロセスをデータは、関連づけること、どの問題が、どの変更によって解消されたのか。逆に、どの変更が新たな問題を生んだのかを明らかにしておきます。
こうした可視化が、組織の学習速度を高めます。
変更依頼管理に基づき、実際に作業成果物に変更を加えていく場合は、SUP.8：構成管理プロセスの仕組みを利用することになるのです。
おわりに
車載開発に限らず、システム／ソフトウェア開発では、問題解決管理プロセスは“守り”、変更依頼管理プロセスは“攻め”と表現されることがあります。
しかし実際には、どちらも組織を前進させるために欠かせない車の両輪です。
トラブルに強く、かつ変化を恐れない組織を目指すために、今一度この2つのプロセスの関係性を見直してみてはいかがでしょうか。
内山 哲三