先日Twitterを見ていたらこんなつぶやきを見つけました。
筋トレを一年続けられる人って0.3%しかいないらしい。これは日本の富裕層の割合と近くて、成功者は継続し続けた者だけって言う証明。続けられる人だけが勝つ。筋トレに限らず何事も。
https://twitter.com/_sunny_fit_/status/1199123876011134977?s=20
最近ジムに行っていない自分には耳が痛いですが、今回はクライアントワークにおいて極めてその重要性が高く、継続こそが肝である変更管理について書いてみました。
#変更管理とは何か？
変更管理とはその名の如く「変更を管理する仕組み」のことです。PMBOKにおいても、統合マネジメント知識エリアの中の統合変更管理として定義されているぐらい、プロマネの仕事のど真ん中です。教科書的な説明は下記のサイトも参考にしていただければと思います。
プロジェクトマネジメントの中核！PMBOK統合マネジメントに必要な基礎知識と実施作業を徹底解説！
https://www.innopm.com/blog/2018/03/20/Integration_Management/
一応「1分でわかる変更管理」を文字にするとこんな感じでしょうか。
- 開発計画（納期や費用）の前提となるスコープやその要件仕様を合意する（「ベースラインの確定」と呼ぶ）
- ベースラインに変更が発生する場合は、その大小に関わらず必ず変更依頼起票を行う（弊社では「Change Request：CR」と呼ぶ）
- CRが発生したら、事前にクライアントと合意した手続きで、PJとして対応を決定する（各担当者で対応可否を判断しない）
#変更管理の重要性
変更管理の重要性は、これがなかった時のことを考えるとわかりやすいです。
変更管理がなければ、声の大きいステークホルダーに変更要求を押し込まれ、当初計画にないタスクが縦横無尽に追加される可能性が最大化されます。結果的にメンバーの稼働が上がったり、無理をして品質を劣化させる原因にもなります。PMとしては予期せぬ納期遅延や工数増は全力で防がなくてはならないわけですから、変更管理はいわば「守りの要」なのです。
ただこれらの仕組みを必須化する最も重要な目的は、メンバーの心理的安全性を高めるということではないかと思っています。
顧客の個別の変更要望を、PMの腕力でそれぞれねじ伏せるやり方もありますが、すべてを防ぎ切ることは不可能です。プロジェクトメンバーにとって、予定された期間内で予定されたタスクに集中できるという安心感は、成果をコミットするためには何事にも代えがたいことであることを、PMは改めて思い出さなくてはなりません。（PM自身も現場の担当者だった時代はきっとそうだったはず）
もちろんプロジェクトには何らかの変更はつきものです。
ただその場合は必ず納期や追加費用を併せて検討するという前提さえあれば、PMもメンバーもみんな前向きに対応できます。変更管理は一度決めたことから変更しにくくするための仕組みということではなく、本当に必要な変更を適切に対応するための仕組みだと理解してもらえると良いかと思います。それを関係者がお互いに気持ちよくするためには、事前に合意したルールが必要なのです。
#プロジェクト品質の肝は変更管理にあり
弊社で全社PMOの活動を開始した時、各PJに対して最初に訴えかけたのが、顧客MTGでの議事録作成＆確認の徹底と、この変更管理でした。
ちなみに全社PMOの活動については、先日JBUG東京#13にてLTをさせていただいた時の資料をご笑覧ください。
https://speakerdeck.com/yasuoyasuo/12-jbug-dong-jing-number-13-ltzi-liao
議事録は「言った/言わない」という不毛なやり取りを無くすための唯一にして最高の道具です。議事録の有効性について異論を唱える人はいないはずだが、顧客や他ベンダーなど関係者全員で合意するところまで含めると、ちょっと手間が掛かるのは間違いありません。そのため全ての打ち合わせで関係者承認まで徹底されないことが少なくないと感じている。
この解決策だが、一言で言えば最初が肝心ということです。そしてそれを習慣化できるかどうかだけの話であって、特別なノウハウは特にないと思っています。ちなみに私が好むのはやり方は、ステークホルダー間でBacklogのようなチケット管理システムを導入させてもらい、議事録チケットを切り、確認したことを確認すべき人がその旨をコメントに残してもらう方法です。（社内では事前にレビューは済ませておきます）
プロジェクト開始時から習慣化できていれば何の抵抗もなく継続できますが、途中から開始するのは案外腰が重いです。またやったりやらなかったりというのも問題です。歯抜けになってしまうと、ほぼやってないに等しいからです。全ての顧客打ち合わせで取ることが大切です。
変更管理を徹底するのも、これと同じような難しさがあると考えています。
#変更管理の実装のポイント
ではどうやれば変更管理が習慣化しやすいのでしょうか。実際のクライアントワークで変更管理の仕組みを運用する上でのポイントを５つほどあげてみたいと思います。
###1. 事前の合意
PMBOK的には当たり前だが、プロジェクト計画時に変更管理計画を関係者一同で合意を得ておくことです。弊社では提案段階で必ず変更管理を行う旨を宣言し、そのプロセス案を提示するようにしています。（提案書に標準添付を義務付け）
とにかく、始めが肝心です。
###2. スコープベースライン合意のエビデンス
変更管理を開始するには、その入口となるスコープベースラインを明確に確定することが不可欠です。
これも本来はプロジェクト計画時点でベースラインに対するレビュー計画が合意されている必要があります。作業対象範囲と仕様の合意を、どの資料で誰がどういうやり方で合意するかを決めておくということになります。もちろんこのレビュー計画の立て方は、顧客の組織内力学なども踏まえた戦略性が求められるプロジェクトの重要成功要因の１つですが、ここについては割愛します。
ここで言いたいのは、ベースラインを合意したというエビデンスのとり方です。私が好むやり方は、これもチケット管理システムを利用している前提ですが、ベースラインチケットを切る方法である。
このチケットにスコープを合意した成果物を直接添付または格納場所のパスを記載します。もちろんレビュー会議の議事録を取り交わす形でもよいのですが、私はこの方法を推します。なぜならレビュー会議での指摘事項も含めて、本当の最終フィックス版の資料が皆にアクセス可能な状態であり、重ねてステークホルダー全員が認めたという証跡が常にプロジェクト全体に公開されていることこそが、その後の変更要求チケット管理を当たり前に習慣化するための場の空気づくりに大きな影響があると考えているからです。
###3. 変更要求チケットの運用
ベースラインが合意できた後は、要求変更に対して必ず変更要求票（我々はCRチケットと呼びます）を、変更を依頼する側が発行します。顧客の要望によるCRであれば、必ず顧客自身に起票してもらうというのが大切です。
ここでもチケット管理システムが有効です。弊社では顧客とのやり取りにチケット管理システムを使うことが多く、そのツールとして標準でBacklogを採用しています。全社PMOでそのBacklogの雛形（各種属性をARI標準に独自設定したもの）を用意し、各プロジェクトに提供しています。（顧客側都合でBacklogが使えない場合は、利用できるシステムに合わせています）
下記は弊社標準で定義しているCRチケットの雛形です。
###4. 徹底した運用継続
3．の仕組みを愚直に運用していくことが大切です。どんなに小さな変更要求もCRチケットを起票してもらうように顧客側に粘り強く理解を求めていきます。
なお当然CRを実行するには影響範囲の調査や工数見積が不可欠です。結果追加費用が掛かる場合もあるし、納期にも影響する可能性があるので、その結果も踏まえて両社でやる/やらないを判断していくことになります。
私のお勧めは、ベースラインが確定した以降の定例会で、毎回このCRチケットの確認をアジェンダに入れるようにする方式です。こうしてCRとその対応は特別なことではなく、重要かつ公明正大なマネジメントタスクであることを関係者に理解してもらうように務めています。
###5.有償時の確実なご請求
実際にプロジェクト進行中に有償CRの実行が決まり、実施スコープに追加されていく場合は、追加工数を請求するための追加発注を確実に要求しなくてはなりません。きちんと有償化まで合意したにも関わらず、その後の事務手続きを嫌うが故にうやむやにするのは最悪です。
もちろん小さなCRが複数発生する場合は、都度では事務負担が大きなら一定量をまとめて発注してもらっても良いです。結局最終的に追加契約が手間になって泣き寝入ることは絶対にNGです。有償CRとして合意したものは、少額でも必ずご請求するという約束を守ることが何より大切です。
#まず守りを固めることが勝利を掴むための基本
プロジェクトを戦争に例えるのは適切ではないかもしれませんが、戦場で防御壁や盾がない中、飛んでくる弾丸や槍矢を各自でかわせというのは、各兵士にとってはあまりにも過酷です。防御が万全に整ってこそ、攻めに注力できるんだと思います。PMやPL陣にとってまず大切なことは、プロジェクトの守りを固めることではないかと思います。
ちなみに「変更管理を徹底する」と言うと、顧客に対して柔軟性のない融通の効かない対応になると思う人がいるかもしれないが、それは誤解です。チームを守りたいのはより継続的に価値あるシステムを創るためであって、決して「自分たちだけ助かろう」という利己主義的なものではありません。
文中にも述べましたが、変更管理は一度決めたことは絶対変更を許さないということではなく、逆に本当に必要な変更を適切に対応するための仕組みなのです。イテレーショナルな案件が多くなってきている中、短期的一時的にではなく、中長期的かつ継続的に勝つための、複数の制約のトレードオフの中で有限なリソースを最適分配するための戦略的な手法なのですね。
プロジェクトマネージャーは、顧客にとって本当に価値あるシステムやアウトプットを提供するために、まずチームが精神的に安心して作業に専念できる環境を整備し、より継続的に顧客の成功に貢献できるようにしたいですね。