ITシステム開発の中で変更管理は非常に重要な役割を持っています。
特に、テスト工程の終盤になって、システムベンダーが開発したシステムを、発注者側に納品し、発注者が受入テストを実施する際には、様々な変更管理案件が発生します。
その中では、発注者側の「これは不具合だ！」と、ベンダー側の「いや仕様通り！」の言い合いが活発となってきます。最悪の場合、トラブルにも繋がり、訴訟なんて話もあります。
では、こうした事態が起きないようにするためには、どういった変更管理のプロセスを踏み、どういった判断基準を抑えておけばよいのでしょうか。
今回は、中小規模のプロジェクトでも活用できる、変更管理のフローについて解説します。
変更管理とは
変更管理とは、仕様変更や要件追加に代表されるようなプロジェクト計画を変更するような事態が発生した際の対処方法を管理するものです。
教科書的な位置づけでは、変更管理委員会（CCB）を設立して、そこにすべての変更事案が吸い上げられ、変更の是非、当該変更の発生責任の所在などを明らかにしていきます。しかし、実際の現場で変更管理委員会が設けられるプロジェクトは稀であるというのが私の感覚です。実際にはベンダーと顧客といった当事者間の”調整”によって判断がされることが多いです。
そして、最も重要で難しいのがこの変更管理の議題として挙がった事案が、ベンダー責によるものか、顧客責によるものかという区別をつけることです。
図解で表すと以下のようなイメージです。
スポンサーリンク
しかし、実際にはこの切り分けがとにかく難しく、ベンダーと顧客との関係性が悪いと泥沼化します。
追加・変更要件となれば、顧客は追加工数（お金）を支払う必要があり、プロジェクト期間も延ばす必要があります。修正・是正要件となれば、ベンダーは身を削って、対応する必要が出てきます。
変更管理フローと判断基準
変更管理フロー
実際に変更管理の事案が発生した場合は、ベンダーと顧客との間で協議することになりますが、この際注意すべき事項があります。
それは、不具合か要望かを切り分けするための作業や、要望を対応するためにかかる工数の算定にも工数がかかることです。したがって、むやみやたらに変更事案に対応してはいけません。
そのため、どのようなルートで変更管理の事案を対応するか、事前のルール決め、フローを定めておくことが重要です。
以下にその一例を示します。
ぜひ、以下のプロセスを参考に変更管理を円滑に捌けるようになっていただければと思います。
スポンサーリンク
判断基準
では、ベンダー責か、顧客（発注者）責かの判断基準について考えます。
判断基準は、明確にいえば、「要件定義や設計書、メールといったドキュメントに明記されているかどうか」です。
記述がされているにもかかわらず実現できていなければ、ベンダーの責任になります。一方で、記述がないことに対する事案であれば、それは顧客の責任です。
結局は言った言わないの水掛け論になってしまうため、このようにドキュメントとして残っているかどうかが重要というわけです。
しかし難しい点があり、それは、システムとして当たり前なこと、行間を読む部分についての線引きです。発注者側としては記載はされていないが、当たり前のようにシステムとして実現されると思っていたという内容がある場合、その内容を顧客責とするか、ベンダー責とするかは非常に悩ましく、難しいです。
ただ、まずは判断基準としては、「ドキュメントへの記述」、これを判断基準としてみるとよいです。
そのうえで、いくつかの事案が上がった場合には、優先度を決めておき、順番に対応するようにします。優先度の付け方は、事業や業務への影響度、対応による費用対効果（業務工数削減）といった指標を事前に決めておき、その優先度に沿って点数化して判断すると良いでしょう。
スポンサーリンク
PMBOK 統合マネジメント
今回は、変更管理について、そのプロセスと判断基準について解説しました。変更管理とは、PMBOKの中でも定義されており、統合マネジメントのという知識エリアの中で定義されています。
もし、変更管理についてもっと知りたいという方や、変更管理で問題が発生しないようにするための事前対策や、問題が発生してしまった後の対応策について知りたいという方はこちらも合わせてご覧ください。
スポンサーリンク
変更管理は非常に難しい局面が多く、プロジェクトマネージャーの腕の見せ所でもあります。今回の内容が少しでも参考になり、ベンダーも発注者もwin-winに幸せになれるプロジェクト遂行のヒントになれば嬉しいです。
コメント