ケンブリッジには、このPMBOKの考え方をさらに一歩踏み込んで解釈して、プロジェクト推進に応用する一派がいます。彼らは、この考え方を火消しの現場に持ち込み、鎮火に成功しています。
彼らの持論は「PMBOKの10の知識エリアは並列ではない。そこには因果関係がある」です。
具体的には、
(1)まず「品質」と「スコープ」にメスを入れろ。
(2)次に「リソース」「コミュニケーション」「ステークホルダー」「リスク」「調達」を考えろ。
(3)そうすれば「タイム」と「コスト」はおのずと分かる。
(4)今どこに注力すべきか、を考えてバランスよく「統合」管理せよ。完璧に管理しようと思うな。
通常、プロジェクトが炎上すると、関係者(特にオーナークラス)の関心は(3)の「タイム」と「コスト」に集中します(「いったいいつ終わるんだ」「あといくらかかるんだ」)。しかし(1)(2)をしっかり見極めなければ、正確な「タイム」と「コスト」はわからないし、管理もできません。「スケジュールを引き直せ」と言われて、決められた期日から逆算して引いただけのWBSに意味はないのです。
また、(2)を実施するためには、品質とスコープの見極めは必須です。品質が低い、あるいは、スコープが緩い状態で、闇雲に(2)に手を出しても、それが妥当であるかどうか、判断がつきません。
例えば「あぁ、もっと人を追加投入すべきだった」という話はよくあります。これは、どれだけ品質をリカバリする必要があるのか、どのスコープまでやればいいのか、を見極めないまま「とりあえず」リソースを追加投入することに起因します。追加リソースには、既存メンバーからの教育が必要です。品質が上がらず、あれもこれも手を付けねばならず、何度もリソースを追加投入し、そのつど教育コストがかかり、結果、プロジェクトはどんどん遅れていき、最悪の場合、プロジェクトは崩壊するのです。
特にシステム導入プロジェクトにおいて品質は最重要です。品質の低いシステムは、いくらコストをかけたものでも誰も使わないからです。主な品質の着眼点としては、以下が挙げられます。
a.主要なビジネスロジックはきちんと実現できているか。
b.データベース(特にマスタ)はどのように構築されているか。
c.システム運用はできそうか(業務が回りそうか、運用・保守できそうか)。
d.データ移行は考慮されているか。
e.システム間連携は大丈夫か。
f.性能はパフォーマンス要件を満たしているか。
特にa.~c.の品質が満たされていなければ、お話しになりません。
品質やスコープの状態を明らかにするには、前回お伝えした「炎上アセスメント」が有効です。炎上プロジェクトにおいては、既存メンバーは、その責任感から客観的にプロジェクトの品質やスコープの妥当性を評価できない(「大丈夫です」「やり切れます」)と見てよいでしょう。
以上のことから、炎上プロジェクトを管理する際には、周囲からの「いつ終わるんだ」「いくらかかるんだ」をいったん受け止めつつも、優先的に品質とスコープを立て直す施策を打っていく必要があるのがお分かりいただけるでしょうか。
2. 火消し心得7か条と「火消し川柳」
前回と今回の内容(プラスアルファ)をベースに、ケンブリッジの有志が作った「火消し心得7か条」があります。各条の解説が川柳形式になっており、「火消しといえど、ケンブリッジメンバーならHave Fun!してみせろ」という気概が感じられ、大変味わい深いので、最後にご紹介します。
第1条「間違いなく品質が悪い」
(1)完了しているタスクも疑え。どこまで戻るか考えよ。
終わってます 品質悪けりゃ 終わってない
モノを見て アタリをつけろ やりなおし
全体像 進捗だけでは 分からない
(2)自分の目で確かめろ。言われたことを疑ってかかれ。
「できてます」 「やってますから」 「じゃあ見せて」
第2条「既存メンバーの判断は信用するな」
(1)火消し前のPMの判断は信用しない
火消しでの 計画と管理は 新PM
前PM 火消しになっても 「まだやれる」
「あと3人 いればいけます」 信じるな
(2)メンバーの判断も疑え
「できます」の 気合はいいが それはそれ
(3)ベンダーの判断も・・・
聞くでなく 足を運んで ブツを見よ
第3条「ステークホルダーは火事を認識していない」
(1)深刻さは、現場とマネジメントで乖離する。状況を正しく共有するための仕組みを作れ
現状把握 時間かかると 合意せよ
現場の火事 気づかぬ「上」に 知らしめる
分からぬなら 数字で示せ 低レベル
(2)覚悟を共有すべし
やってやるぞと 思えるゴールで 再出発
巻き取るな オーナーシップが なくなるぞ
第4条「お客さんからの信頼も、PJの雰囲気も↓」
(1)雰囲気を良くする仕組みを作る
余裕のない 時ほど 「らしさ」を サボらない
おしゃべりも できなきゃすでに 死んでいる
火消しでも HaveFunできない わけがない
(2)基本的人権の尊重
寝なければ できやしないぞ いい仕事
第5条「既存メンバーが必ずボトルネッカーになる」
(1)火消し隊は、既存メンバーからタスクをはがせ
火消し隊 「ここは任せて 先に行け」
(2)既存メンバーは、任せる勇気を持て
「やる」でなく 任せる事が 火事を消す
(3)既存メンバーは、ナレッジ提供者になれ
火事場では 手を動かさず 口を出せ
暗黙知 伝わらないなら 書き起こせ
第6条「今までやってきたことを否定しなければならない」
(1)「捨てるゴール」を決める、やることのメリハリをつける
火事前の 常識もはや 非常識
決断は やることよりも 捨てること
捨てたとて 大事なものは 後でやる
第7条「二度目の火消しはないと思え」
(1)計画に次はない
キックオフ 次はないぞと 腹くくれ
再計画 達成可能な 線を引け
前提と リスクも全て 挙げておけ
リ「ソース」は 一度につけろ 二度づけ禁止
(2)ヤバイものを早く検出する仕組みを作る
ヤバゲなら 再テストも 計画に
イエローを 早めに出させる マイルストーン
「できます」と 言うなら明日 見せに来い
一度でも火消しの現場に居合わせたことのある方なら、中には共感できる川柳があるのではないでしょうか。
このメルマガも今回が最終回です。
一貫して申し上げたいのは、
・プロジェクトを成功させるには、企画の質と態勢の質が極めて重要である
・後々に炎上しないよう、きちんと実行可能なゴールを掲げてプロジェクトを立ち上げる
・ゴールに照らしながらタスクの優先順位を決めて、ワンチームでやりきる
ということです。
プロジェクト立ち上げの際は、ぜひケンブリッジにご相談ください。
ここまでお読みいただいた皆様に感謝します。ありがとうございました。