プロジェクトの自分化を

ＱＣＤマネジメントの品質に続く取り組みは、デリバリーマネジメントです。
あなたが責任者で赴任した場合、もしくは、これまで現地人だけで運営されていた組織に顧問や研修生として派遣された場合、真っ先に社長から言われることの一つに「情報部門が何やっているか、よく見えない。見えるようにしてくれ。」ということでしょう。あなたの赴任した会社にしっかりとしたデリバリーマネジメントシステムがあれば、この見える化はレポーティング含めたコミュニケーションマネジメント上の課題であり、常識的な努力を重ねればいずれ解決できる課題だと思います。
見える化に至るありふれたシナリオを予想してみましょう。
一、上司としての権威をバックにして直属のマネジャーに命じ、開発案件のスケジュール表を作らせて、毎週内部レビュー後、関係者に配布する。
二、自分には権限がないので、一生懸命全員が何をやっているのか人間関係を頼りに聞き出して、自分で一覧表にまとめて関係者に配布する。
いかがでしょうか。とにかく「見えない」という問いに対して「見せる」ための最初のスタートとしては、こんなところから始まるものでしょう。私は、この二つとも別々の組織で経験しました。この二つを経験して、今思うことは、このような見える化はデリバリーマネジメントの出口付近の「報告」の類の話しであり、本質的にはデリバリーマネジメントでも何でもない、ということです。
デリバリーマネジメントの本質とは何かと言えば、

「約束をし、それを守ること」です。

人材育成の観点から見れば、
目標を設定し、それを守ることを通じて主体性を育てることです。あなたがどのようなやり方にせよ、スケジュール表をとりまとめてそれを対外に公開することは、あなたがそれを約束し、それを守ることをコミットすることです。もしあなたが、これを達成することをコミットできないならば、即刻そのような見える化は止めて、本質的なデリバリーマネジメントシステムを組織に確立することに全力を捧げるべきでしょう。社長や関係者ともじっくり話しをしながら、見える化については、例えば「三ヶ月時間をください」と最初にお願いすべきでしょう。また、「毎週、毎週部下から上がってくる、各案件の納期が大きく変更され、プロジェクトがいつも納期より遅れている。」「納期の遅れの理由を部下に問いただしても、返事がのらりくらりで原因がよく分からないし、外に対しても説明ができない。」という悩みをお持ちの方にも、これから述べるデリバリーマネジメントシステムの確立方法を参考にしてみてください。

まず、約束を守るということがどういう意味を持つのか、考えてみましょう。

著書「七つの習慣」で、スティーブン・Ｒ・コヴィーは、次のように述べています。

「私たちの影響の輪の最も中心にあるものは約束をし、それを守る力である。自分自身や人に対してする約束とそれに対する誠実さが、私たちの主体性の本質であり、その最も明確な表現だろう。それは人間の成長の基礎でもある。」

約束を守ることが主体性の発揮である、という彼の見方、考え方はすごい。この場合の約束とは、上司のあなたからの業務命令ではなく、それぞれのメンバーの主体性に基づく約束です。人材育成という表現よりも、私は人間育成と呼びたい。
私が考えるデリバリーマネジメントシステムの確立とは、以下のような内容です。

それぞれのメンバーに求める行動は、
一、それぞれのメンバーが主体的な約束（いつ、何をデリバリーするのか）を行い、それを守ること
二、達成すべき目標に対して、どのように進めるかをすべて自分で考え、決めること
三、約束を守るために自分で完結して出来ることと、自分では出来ないことを理解し、マネジメントと共有し、出来ない部分について助けを求めること

マネジメントが成すべき役割は、
一、必要なリソースを確保すること
二、実行する上での守るべきガイドラインを提示すること（個々の進め方には干渉しないこと）
三、メンバーが解決できない課題をすぐに解決すること
四、リスク管理
五、組織としての結果責任を引き受けること

具体的な進め方ですが、プロジェクト一件について、一枚の管理シートを作成。毎週の進捗確認会議で、プロジェクトのリーダー自ら、もしくはその管理者が状況を説明します。
管理シートのフォームは自由ですが、必要な項目は左記の通り。

一、表題部分
プロジェクト名、リーダー、作成週、プロジェクト全体の進捗評価
二、進捗状況
マイルストーンとなるイベント内容、納期、進捗度合い（％）、遅れの期間、遅れがクリティカルかどうかの判断
三、活動内容
先週の活動実績、今週の活動予定
四、課題内容
リスク（予見される将来課題）とイシュー（現在発生している課題）の内容、それに対する対応内容

このように書きますと、大変な内容に思えますが、フォーマットとしては簡単なものです。このフォームは私の担当したプロジェクトでコンサルの方と共同で作成したフォーマットで、非常に簡単ですが、プロジェクトマネジメントのポイントをおさえたものになっています。

小改善の案件から比較的大きなプロジェクトまで一枚で管理できる便利なシートです。
まず、推進リーダーは、自分でこのプロジェクトをどのように進めるのか、ストーリーを作り各マイルストーンに落とし込みます。このマイルストーンについては、最初は各人の自由に任せて作らせましょう。おそらく、このようなフォームがない会社には、品質面でのチェックポイントやアシュアランスがきっちり仕組みとして出来ていないでしょう。自由に作らせる理由は、それを見れば、各人の実力がだいたい見て取れるからでもあります。企画書立案時にプロジェクトオーナーのサインオフをマイルストーンにおいてくるツワモノであれば、もはやあれこれ口出しする必要はありません。重要なポイントは、そのプロジェクトを成功させるために、自分なりにしっかりとしたシナリオを考え、しかも納期をきっちりコミットしているかどうかです。納期未定が多いメンバーは、シナリオを考える力が弱いか、コミットする勇気と経験、実力が伴わないメンバーでしょう。納期がコミットできなくても、なぜ納期が今現在明確に出来ないか、その外部要因と対策をしっかり下段の課題欄に書いていれば、合格です。

いくつかのパターン毎に指導方法を記述していきます。
■ マイルストーンの設定そのものに抜けや不整合がある
実際に最初の会議であったケースですが、Ａさんは「テスト」の次に「本番稼動」。Ｂさんは「システムテスト」「ＵＡＴ（ユーザーによるアクセプタンステスト）」「本番稼動」。Ｃさんは、「テスト」「ユーザー教育」「本番稼動」と書いてきましたので、この３つを机に並べて、それぞれのメンバーに他のメンバーが書いて自分が書いていないマイルストーンについてどう考えているのか聞いて見ました。すると、Ａさんは「システムテスト」と「ＵＡＴ」をひっくるめて「テスト」とし、ユーザートレーニングについては考えていなかった。Ｂさんは、ＵＡＴを通して教育は行なわれるので、別段それをマイルストーンとすることはない、と考えていた。Ｃさんは、「ユーザー教育」と書いている意味は、実は「ＵＡＴ」と「オペレーション教育」の両方を意味していました。言葉の定義と、どういうマイルストーンを標準として定義すべきかを全員で話し合いを行い、標準形について全員で合意しました。最初から日本で行なうような、フルセットでのレビューステップを全部導入、実行しないこと。まずは、そこのメンバーの実力値を測り、その実力範囲内での調整によって簡単にできる幅寄せを行い、その運用定着を図ること。その後、例えば企画書完了段階でどのようなレビューを行なうか、本番切替前の判定はどのようなプロセスで行なうか、といった全体のガイドライン整備を組織の成熟度に合わせて進めていきましょう。
■ プロジェクトに問題があるのに課題内容欄が空白
プロジェクトが遅れてくると、まず全体の評価が黄色信号のはずですが、全体評価を青信号、課題内容欄が空白で提出してきている場合が最も危険なパターンです。いくつかの質問が必要です。例えばＵＡＴが遅れた場合によくある説明ですが、「私は準備していたが、ユーザーが忙しくて時間が取れなかったので来週に延びた。」という回答が返ってきたとしましょう。この回答をそのまま流してしまうのはマネジメントのエラーです。あなたは、間違いなく今後三週間ほど、同じ報告を聞くはめになるでしょう。指導方法としては、課題のところに、「キーユーザーの○○さんが忙しくてＵＡＴが実行できなかった」と書かせて、対応のところに何を書くべきであったか話しあって行きます。キーユーザーの上司へのリソース確保依頼が必要かもしれません。別のキーユーザーのアサインを依頼しなければならないかもしれません。キーユーザー自身が怠けている場合や、こちらからのアプローチやフォローが十分でなかったかもしれません。またキーユーザー自身が、いつまでに何を終了するのか、といったプロジェクトのマイルストーンを共有していないケースも考えられます。いかにしてこの事態に対処すべきかを、穏やかに話しあって行き、回答を合意します。そして、課題と対応欄を埋めてもらいます。何を書くかは、最終的に担当者が決めることです。「こう書け」という指示はしないように。あなたに必要なものは、コーチングの技術と忍耐力です。
課題と対応欄に上がったタスクはあなた（マネジメント）にアサインされた仕事です。マネジメントはすぐにアクションを起こし、課題を解決しなければなりません。課題欄に書く、ということは、自分で解決できない課題を明確にし、そのタスクをマネジメントへにデリゲーションするということです。上司をうまく使う、そのための連絡欄なのです。最初は上手く書けないメンバーがほとんどです。そういう場合は、課題をとにかく認識させ、書かせて、対応欄には「HELP ME!」とでも書くよう指導します。どのようにヘルプするかは会議でみんなでディスカッションできます。一連のやり取りは会議の参加者全員が聞いていますので、全員で学ぶことができます。また、このプロセスを通じてチームで働くことの重要さと面白さ、他人のために献身することの尊さや、周りからの支援に感謝する心が育まれます。
部下の視点から見てこのデリバリーマネジメントシステムが意味あるものとなるかどうかは、課題欄に上げた項目がマネジメントによって速やかに解決されるかどうかにかかっています。このエスカレーションと問題解決のプロセスが機能する、と実感できれば、毎週書かされるメンバーにも緊張感と高いモチベーションが働きます。また、このシステムが機能することが担保されているからこそ、メンバーにプロジェクトへのオーナーシップ感と責任感を持たせることが可能となるのです。

プロジェクトが毎週のように遅れていく最大の原因は、担当者自身では解決できない問題を、その担当者は「他人の責任」と認識し、結果として放置されることが組織内で正当化されている風土とマネジメントシステムにあります。
　とはいっても、すべて「君の責任だ」と全てのボールを担当者やローカルのマネジメントに渡したところで、問題は解決しません。いくつかの課題解決の方法を実際に体験することで、これまで他責として放置してきた問題には解決方法があり、上司を使って、組織を使って自分で主体的に問題を解決していく爽快感を各メンバーに味わせることができれば、組織の風土は大きく変わっていくでしょう。

個々のプロジェクトの報告資料は、その後のディスカッションの内容を受けて、会議の当日中に全てアップデートを完了し、全体の資料を翌日にはイントラネットや共有ドライブで公開しましょう。理想は会社の誰もがいつでもプロジェクトの状況について閲覧できることです。このことを通じて、組織としての説明責任を果たすとともに、担当者に緊張感とやる気を促します。

会議運営において重要なことがもう一点。議事録を書き、残すことです。
簡単な表形式で構いませんが、次の内容を網羅してください。
一、 その日全員で決めた内容。全員で合意したルールやガイドラインは書き物に残します。以後、全員の行動基準となります。
二、 会議で発生したタスクを記します。タスクのオーナー、納期、ステータス、今週の状況を書く欄を設けます。
三、 会議の最後に、必ず前週のタスクをレビューします。そのタスクが完了したか、完了していないとすれば、どういう状況なのか、どういうアクションを今後行なう予定なのか、担当者が発表し、その内容で議事録もアップデートします。タスクはクローズするまで、毎週、毎週レビューが続きます。

　議事録は、最初三週間ほどはあなたが書いて、ルーティーンと様式を確立した後に、ローカルメンバーに引き継いでください。

品質管理の面から各フェーズレビューのやり方を改めたり、新たな標準マイルストーンを設定する場合でも、「日本の標準だから」「これがスタンダードだから」というような指示、命令でなく、みんなで話し合った結果としての全員の決意（コミットメント）という形に誘導してください。決まったことは議事録に明記します。そうすれば、みんなの行動がすぐに変化して行きます。例えば次回の会議で、それに反した言動があれば、自然と周りのメンバーから注意を促すようなコメントが出てくるでしょう。決意に参加することが重要なのです。

以上がデリバリーマネジメント導入の方法例ですが、私はこのようなデリバリーマネジメントのあり方を、組織運営の面からは、次のような絵で表現しています。

逆ピラミッドのマネジメントモデルは、ジャック・ウェルチに発想を得たものです。お客様に直接対応する現場にデリバリーマネジメントをエンパワメントし、バックのマネジメントはそれを支える。得点はすべて現場が稼ぐものだし、それを賞賛する仕組みを作る。そして、責任者である私の最大の役割はリスクマネジメント。どんなボールが来ても、絶対にゴールは守る。絶対に失点はしない。また、「失点はすべて自分が責任を取る」と言い切り、全員を勇気づけ、みんなが前を向いてプレーできるよう常に後ろから声をかけチームを鼓舞する。また、自分の部下をチームメイトとして扱い、気さくに接する。

このような毎日のプレーを通じてチームのみんなが自己重要感を感じ、また他者への自己献身を通して「生きがい」や、より大きな「人生の目標」を見つけて欲しい、と願っています。