見出し画像

プロジェクトの心理的安全性を高める変更管理の話

中野ヤスオ｜ARI

先日Twitterを見ていたらこんなつぶやきを見つけた。

最近ジムに行っていない自分には耳が痛いが、今回はクライアントワークにおいて極めてその重要性が高く、継続こそが肝である変更管理について書きたい。

＊なおこのコンテンツはBacklog Advent Calendar 2019の 12/18分としてお送りします。

■変更管理とは何か？

変更管理とはその名の如く「変更を管理する仕組み」のことだ。PMBOKにおいても、統合マネジメント知識エリアの中の統合変更管理として定義されているぐらい、プロマネの仕事のど真ん中である。教科書的な説明は下記のサイトも参考にしていただければと思う。

一応「1分でわかる変更管理」を文字にするとこんな感じだろうか。

・開発計画（納期や費用）の前提となるスコープやその要件仕様を合意する（「ベースラインの確定」と呼ぶ）
・ベースラインに変更が発生する場合は、その大小に関わらず必ず変更依頼起票を行う（弊社では「Change Request：CR」と呼ぶ）
・CRが発生したら、事前にクライアントと合意した手続きで、PJとして対応を決定する（各担当者で対応可否を判断しない）

■変更管理の重要性

変更管理は、不確実性の高いプロジェクトという仕事を計画的に進めるための仕組みだと私は考えている。変更管理がなければ、声の大きいステークホルダーに変更要求を押し込まれ、当初計画にないタスクが追加される可能性が最大化される。結果的にメンバーの稼働が上がったり、無理をして品質を劣化させる原因にもなる。PMとしては、予期せぬ納期遅延や工数増は全力で防がなくてはならないわけで、守りの要となる施策である。

ただこれらの仕組みを必須化する最も重要な目的は、メンバーの心理的安全性を高めるということではないかと思っている。顧客の個別の変更要望を、PMの腕力でそれぞれねじ伏せるやり方もあるが、すべてを防ぎ切ることは不可能だ。プロジェクトメンバーにとって、予定された期間内で予定されたタスクに集中できるという安心感は、成果をコミットするためには何事にも代えがたいことであることを、PMは改めて思い出さなくてはならない。（自身もメンバー時代はきっとそうだったはず）

もちろんプロジェクトには何らかの変更はつきものだが、その場合は必ず納期や追加費用を併せて検討するという前提があれば、メンバーは皆前向きに対応できる。一度決めたことは絶対変更を許さないということではなく、逆に本当に必要な変更を適切に対応するための仕組みだと理解してもらえると良いかと思う。

■プロジェクト品質の肝は変更管理にあり

弊社で全社PMOの活動を開始した時、各PJに対して最初に訴えかけたのが、顧客MTGでの議事録作成＆確認の徹底と、この変更管理だった。

ちなみに全社PMOの活動については、先日JBUG東京#13にてLTをさせていただいた時の資料をご笑覧いただけるとありがたい。

議事録は「言った/言わない」という不毛なやり取りを無くすための唯一にして最高の道具だ。議事録の有効性について異論を唱える人はいないはずだが、顧客や他ベンダーなど関係者全員で合意するところまで含めると、ちょっと手間が掛かるのは間違いない。そのため作成および関係者確認までを全ての打ち合わせで行うことは徹底されないことは、恥ずかしながら少なくないと感じている。
この解決策だが、一言で言えば最初が肝心ということだ。そしてその後習慣化できるかどうかだけの話であって、特別なノウハウは特にないと思っている。ちなみに私が好むのはやり方は、ステークホルダー間でBacklogのようなチケット管理システムを導入させてもらい、議事録チケットを切って確認したことを確認すべき人がその旨をコメントに残してもらう方法である。（社内では事前にレビューは済ませておく）

プロジェクト開始時から習慣化できていれば何の抵抗もなく継続できるのだが、途中から開始するのは案外腰が重い。またやったりやらなかったりというのも問題だ。歯抜けになってしまうと、ほぼやってないに等しい。全ての顧客打ち合わせで取ることが大切だ。
変更管理を徹底するのも、これと同じような難しさがあると考えている。

■変更管理の実装のポイント

ではどうやれば変更管理が習慣化しやすいのか。実際のクライアントワークで変更管理の仕組みを運用する上でのポイントを５つほどあげてみたい。

１．事前の合意
PMBOK的には当たり前だが、プロジェクト計画時に変更管理計画を設計合意を得ておく。弊社では提案段階で必ず変更管理を行う旨を宣言し、そのプロセス案を提示するようにしている。（提案書に標準添付を義務付け）
とにかく、始めが肝心である。

２．スコープベースライン合意のエビデンス
変更管理を開始するには、その入口となるスコープベースラインが明確に確定することが不可欠だ。これも本来はプロジェクト計画時点でベースラインに対するレビュー計画が合意されている必要がある。作業対象範囲と仕様の合意を、どの資料で誰がどういうやり方で合意するかを決めておくということである。もちろんこのレビュー計画の立て方は、顧客の組織内力学なども踏まえた戦略性が求められるプロジェクトの重要成功要因の１つであるが、ここについては今回は触れない。
ここで言いたいのは、ベースラインを合意したというエビデンスのとり方である。私が好むやり方は、これもチケット管理システムを利用している前提だが、ベースラインチケットを切る方法である。このチケットにスコープを合意した成果物を直接添付または格納場所のパスを記載する。もちろんレビュー会議の議事録を取り交わす形でもよいのだが、私はこの方法を推したい。なぜならレビュー会議での指摘事項も含めて、本当の最終フィックス版の資料がアクセス可能な状態で、ステークホルダー全員が認めたという証跡そのものが常にプロジェクト全体に公開されているという事実こそが、その後の変更要求チケット管理を当たり前のように習慣化していくための場の空気醸成に、非常に重要だと考えているからだ。

３．変更要求チケットの運用
ベースラインが合意できた後は、要求変更に対して必ず変更要求票（我々はCRチケットと呼ぶ）を、変更を依頼する側が発行する。顧客の要望によるCRであれば、必ず顧客自身に起票してもらうのが大切である。
ここでもチケット管理システムが有効だ。弊社では顧客とのやり取りにチケット管理システムを使うことが多く、そのツールとして標準でBacklogを採用している。全社PMOでそのBacklogの雛形（各種属性をARI標準に独自設定したもの）を用意し各プロジェクトに提供している。（顧客側都合でBacklogが使えない場合は、利用できるシステムに合わせている）
下記は弊社標準で定義しているCRチケットである。

４．徹底した運用継続
３．の仕組みを愚直に運用していくことが大切だ。どんなに小さな変更要求もCRチケットを起票してもらうように顧客側に粘り強く理解を求めていく。
なお当然CRを実行するには影響範囲の調査や工数見積が不可欠だ。結果追加費用が掛かる場合もあるし、納期にも影響する可能性があるので、その結果も踏まえて両社でやる/やらないを判断していくことになる。
私のお勧めは、ベースラインが確定した以降の定例会で、毎回このCRチケットの確認をアジェンダに入れるようにする方式である。こうしてCRとその対応は特別なことではなく、重要かつ公明正大なマネジメントタスクであることを関係者に理解してもらうことが大切だと考えている。

５．有償時の確実な請求
また実際に開発中に有償CRの実行が決まり、実施スコープに追加されていく場合は、有償工数の請求のための追加発注を確実に要求しなくてはならない。きちんと有償化まで合意下にも関わらず、その後の事務手続きを嫌うが故にうやむやにするのは最悪である。もちろん小さなCRが複数発生する場合は、都度では負担が大きすぎる一定量をまとめて発注してもらっても良い。結局最終的に追加契約が手間になってなどと泣き寝入ることは絶対にだめだ。有償CRとして合意したものは、少額でも必ずご請求するという約束を守ることが何より大切である。

■まず守りを固めることが勝利を掴むための基本

プロジェクトを戦争に例えるのは適切ではないかもしれないが、戦場で防御壁や盾がない中、飛んでくる弾丸や槍矢を各自でかわせというのは、各兵士にとってはあまりにも過酷である。防御が万全に整ってこそ、攻めに注力できるはずだ。PMやPL陣にとってまず大切なことは、プロジェクトの守りを固めることではないだろうか。

ちなみに「変更管理を徹底する」と言うと、柔軟性のない融通の効かない対応で顧客により添えなくなると思う人がいるかもしれないが、それは誤解である。チームを守りたいのは、より継続的に価値あるシステムを創るためであって、決して「自分たちだけ助かろう」という利己主義的なものではない。

冒頭にも述べたが、変更管理は一度決めたことは絶対変更を許さないということではなく、逆に本当に必要な変更を適切に対応するための仕組みなのだ。イテレーショナルな案件が多くなってきている中、短期的一時的にではなく、中長期的かつ継続的に勝つための、トレードオフの中で有限なリソースを最適分配するための戦略的な施策である。
顧客にとって本当に価値あるシステムやアウトプットを提供するために、まずチームが安心して作業に専念できる環境を整備し、より継続的に顧客の成功に貢献できるようにしたい。

この記事が気に入ったらサポートをしてみませんか？