【PMBOK】意味ないのか？統合マネジメント実務への活用方法

このシリーズは、私がこれまで経験したプロジェクトで培ったマネジメントノウハウをPMBOKの知識体系に沿って、駆け出しPMの方々や新入社員向けの読み物的な位置づけでノウハウや考え方をまとめています。ぜひご覧ください。

統合マネジメントにおける各プロセスは以下の通りです。

統合マネジメントは他の知識エリアを統合する知識エリアであり、プロジェクトの横断的な取り組みに位置づけられる領域です。その中で、３つの観点に焦点を当てて解説したいと思います。

プロジェクト憲章
統合変更管理
終結
まとめ

プロジェクト憲章

プロジェクト憲章とは、プロジェクトオーナから発行される文書でプロジェクトを公式に認可する役割があるものです。この文書によってプロジェクトマネージャーは費用や要員などのリソースを使用できるようになります。

プロジェクト憲章には主に以下のことを記載するようにしましょう。

・プロジェクト概要、目的、目標、主要要求事項

・成果物

・前提条件、制約事項

・主要マイルストーン

・予算

・主要リスク

・体制

・変更管理方法

これら以外にも記載しておくことはありますが、私が経験した中ではこれらが重要であり、大概どのプロジェクトでも記載されている、もしくは記載しておらず後々困った事項です。

特に、前提条件、制約事項は、このプロジェクトの特性、特徴に大きく関わってくるため、関係者全員がしっかりと共通認識をもって取り組む必要があります。

統合変更管理

変更管理とは、仕様変更や要件追加に代表されるようなプロジェクト計画を変更するような事態が発生した際の対処方法を管理するものです。

教科書的な位置づけでは、変更管理委員会（CCB）を設立して、そこにすべての変更事案が吸い上げられ、変更の是非、当該変更の発生責任の所在などを明らかにしていきます。しかし、実際の現場で変更管理委員会が設けられるプロジェクトは稀であるというのが私の感覚です。実際にはベンダーと顧客といった当事者間の”調整”によって判断がされることが多いです。

そして、最も重要でめんどくさいことがこの変更管理の議題として挙がった事案が、ベンダー責によるものか、顧客責によるものかという区別をつけることです。

図解で表すと以下のようなイメージです。

しかし、実際にはこの切り分けがとにかく難しく、ベンダーと顧客との関係性が悪いと泥沼化します。

追加・変更要件となれば、顧客は追加工数（お金）を支払う必要があり、プロジェクト期間も延ばす必要があります。修正・是正要件となれば、ベンダーは身を削って、対応する必要が出てきます。

以下ベンダー目線での対応方法について整理したいと思います。

変更管理　責任の所在に関する協議

実際に変更管理の事案が発生した場合は、ベンダーと顧客との間で協議することになりますが、この際注意すべき事項があります。

それは、不具合か要望かを切り分けするための作業や、要望を対応するためにかかる工数の算定にも工数がかかることです。したがって、むやみやたらに変更事案に対応してはいけません。

そのため、どのようなルートで変更管理の事案を対応するか、事前のルール決めが重要です。

以下にその一例を示します。

ぜひ、以下のフローチャートを参考に変更管理を円滑に捌けるようになっていただければと思います。

変更管理　発生前の予防策

変更管理にて発生する事案がベンダー責にならないようにするための対策と発生に備えた事前の影響度軽減対策として考えられるものは以下です。

①とにかく良好な関係を築く

身もふたもないですがこれが一番大事であるといっても過言ではありません。顧客との良好な関係があれば、こちらが出した不具合についてもとやかく言われることはあまりありません。また、追加の要望事項があったとしても、顧客側も低姿勢で”お願い”してくる恰好になりやすいです。

日ごろのメールのやり取り、顧客を思いやる姿勢、顧客の言いたいことを汲み取る、挙げればきりがないですがとにかく良い印象をもっておいてもらうことは重要です。

日々の積み重ねが、最後には大きな差となって顕著に表れます。

②ベンダーとして最低限のシステム品質を担保する

ユーザテスト・受入テスト工程で顧客から新たな要望が挙がることは日常茶飯事です。むしろ挙がらない方が顧客が真剣にテストしていないのでは？と疑いを持つべきです。

そうした際に、そもそもシステムとして全く動かない（ボタンを押したらエラー、画面遷移できないなど）ようなシステム屋として恥ずべき状況では、ベンダーとして立場が悪くなり、明らかな要望事項も「不具合是正と一緒に治してくださいよ」と言われる始末になります。

そのような事態にならないためにも、システム屋として最低限の品質（動くものを担保する）ということは死守すべきラインです。

③スコープを明確にしておく

①②は心理的な側面が強いですが、③は契約を盾にすることです。

要件定義書や設計書に可能な限り細かく要件、仕様を記載しておくことです。

言ってしまえばドキュメントに書いてあり、そのドキュメントの顧客レビューを受けていれば、ドキュメントに記載のない事項はすべて追加・変更要件になるという建付けです。

”書いてないのでやらない”というのが最後の砦です。あまりにこれを突き通すと角が立ち、関係を悪化することに繋がりますが、最後の最後にベンダーを守ってくれるということは覚えておきましょう。

したがって、逆にいえば、ベンダーとしては要件定義や設計工程にて詰めた要件、仕様はしっかりとドキュメントとして残しておくことが重要です。

また、要件や仕様に限らず、ベンダーとして面倒を見るシステムの範囲、作業範囲についてもはっきりしておく必要があります。

例えば、対象システム以外の別システムからデータを受信し、そのデータをもとに処理する際、受信データがおかしい場合には、受信データの解析はベンダーの作業範囲としないなどです。

今回のシステム改修でシステム運用を変更しなければいけない場合にその運用要件のとりまとめは顧客にて実施してもらうことも当てはまります。

また、旧システムと新システムのデータ移行における項目マッピングがずれていてもベンダーでは是正しないといった具合です。

④予備工数を事前に確保しておく

予め追加・変更要件が発生しても対応できるように準委任契約を締結しておくことです。そして、その工数内であれば要望も受け付けるという建付けで契約をしておきます。

注意点としては当該工数は要望を出さなくても時間と共に消化されていくことを顧客にも理解しておいてもらうことです。

一方で、ベンダーとしては修正・是正工数を予め盛り込んでおく必要はあります。本来であれば、これらの工数はベンダーが身を削って対応することにはなります。しかし、杓子定規にベンダーが身を削る計画ではベンダーの身も持ちません。したがって、最初から不具合が発生することを予め見越した計画、工数試算をしておくことが重要です。この時、顧客への見積の提示の仕方がかなり面倒なことになるので最新の注意が必要です。

あからさまに不具合を見越した工数最初から見込んでおくと、「それはベンダーの責任ですよね、工数に含めないでください。」と言われてしまいます。良心的な顧客であれば、突っ込みを入れてくることも少ないと思いますが、あからさまな工数の積み増しは揉め事を生むだけですので、注意しましょう。

変更管理　発生後の対策

前述した予防策を講じても変更管理は必ずといっていいほど発生します。その際は、以下のような対策を講じてプロジェクトを前に進めなければいけません。

①対応要件を別タスク（工程）とする

追加で発生した要望を対応していると当初計画内でシステム稼働ができないような場合には、次期開発にその要望を回すということも一案です。当該要件を対応しなければ、業務が回らないような場合であればプロジェクト期間を延ばしてでも対応する必要がありますが、そうでなければ、別契約に切り出します。

②プロジェクト期間の延伸

どうしても対応しなければいけないような場合にはプロジェクト期間を延伸するしか手がないことも多いです。しかし、これはプロジェクトに与える影響が大きいので一番避けるべきです。

仮にベンダー責任であれば、易々と延伸はできません。仮に顧客責任であってもベンダー側の体制維持、追加コストの発生など想像以上に労力がかかります。その覚悟をもってプロジェクトの延伸を決断する必要があります。

終結

最後はプロジェクトの終結、クロージングです。正直、うまくいっているプロジェクトの場合正直あまり終結は力を入れることは少ないというのが実情かなと思います。というのも、中小規模の案件であれば、あるプロジェクトが終結フェーズに向かっている時には既に、次の案件の立ち上げ期間になっているため、あまり労力を割けなくなっているというのが実情かなと思います。

社内的には、次のプロジェクトに向けて実績工数の収集やプロジェクト運営における反省、組織へのフィードバックなどを行います。

実際に最も多いのは、運用への引継ぎであったり、次期開発のための準備であったりが挙げられます。

プロジェクトにて反省点があれば、次回以降に向けてチェックリストを作成することもあるでしょう。（形骸化しないように注意は必要）