プロジェクトリカバリのコツとヒント（５）

サイクル・リズムを再構築する

リプランを行い、キックオフを実施すると、プロジェクトの再始動となります。効いている実感、自己効力感向上の素地を作るために、１週間の過ごし方を定義すると良いです。アジャイル開発でも、スプリントの長さは１週間程度とされることが多いのと、大抵の場合、お客様や上長への報告は週次で行われるので、それに合わせる意味でも１週間が妥当かと思います。

朝会や夕会、課題検討会、進捗確認会などのイベントや作業を、前後の関係、議題、出席者なども含めて整理します。朝会や夕会は、日次で開催してくのが良いです。この頻度を下げると、軌道修正の打ち手をタイムリーに打てなくなり、後手に回ってしまいます。

（1週間サイクルの例）

習慣化の21日ルール

ここで決めたサイクルで、まずは３週間継続してください。
その理由として、「習慣化の21日ルール」というものがあります。Maxwell Maltzという方の研究結果ですが、「習慣化（新しい行動が無理なく実行できるようになること）には21日間が必要」だそうです。別の本では、「ルールが定着したかどうか、3日、3週間、3ヶ月の時点におけるチェックが必要」と書かれていたので、3週間＝21日間が一つの目安になりそうです。新しいプロジェクトルールは、少なくとも3週間は我慢して継続すると、習慣化ができると言えそうです。

プロジェクトリカバリのコツとヒント（４）

プロジェクト診断後、リプラン

特にトラブルプロジェクトでは、当初計画と実態は乖離していることがほとんどです。以後のリカバリのために、リプラン、リスケジュールをする必要があります。なお、「リスケ」は便利な言葉なので、多用するとプロジェクト内外に対して、計画的に進めていない印象を与える可能性が高まります。計画を立て直す「リプラン」の方が建設的に受け止められると思います。

特にトラブルプロジェクトの場合は、すでに計画が破綻していることがあります。リプランにあたっては、まずゴールを再設定するところから始める必要があります。

最低限守らなくてはいけないゴールは？

QCDで言えば、納期が必達なのか、すべての要求事項を満足することが至上命題なのか、品質を落とすことが許されないのか。QCDすべてを実現することは難しい状況だと考えられますので、優先順を再定義して、到達すべきゴールを再設定してから、全体のスケジュールを決めていく方法が良いです。

1. ゴールとマイルストーンの設定
2. ゴールから逆算したスケジュールの設定
3. 枠をはみ出さないようにスケジュールをブレークダウンする
4. 全員で共有する（貼り出す、いつも見せる）

プロジェクト計画時点、開始時点では、タスクの積み上げ式でスケジュールが作成されていると思います。WBSに分解され、個々のタスクに納期が割り当てられています。積み上げ式の注意点は、各メンバーが見積もった場合、バッファが組み込まれているかどうかが不明瞭になりがちなことです。

「クリティカルチェーン（エリヤフ・ゴールドラット著）」によれば、

• 自分の経験に基づいて設定されるバッファは、長くなる傾向
• フェーズごと、階層ごとにかかるマネジメント時間は、見過ごされる傾向がある
• メンバーは、バッファがカットされるのを見越して水増しする。

という特徴があるそうです。

また、バッファは往々にして無駄遣いされがちで、その理由としては

• 学生症候群(最後まで取りかからない)
• 作業の掛け持ち
• ステップ間のプラスマイナスで消えてしまう（早く完了したステップがあっても、全体として短縮されない）

があるとのことです。

したがって、バッファはタスクごとに設定するのではなく、スケジュールの最後にまとめて確保するようにした方が良いです。想定外の事象は必ず起きると想定しておいた方が無難です。

プロジェクト運営ルールを見直す

リプランにおいては、同時に、プロジェクトの運営方法について見直すべきところを改善します。特に会議体はプロジェクト活動に占める割合も多いので、必要性、目的や主催者、出席者、議題、開催頻度などを再考した方がよいでしょう。
機能していない定例会議は廃止しましょう。例えば、以下のような会議には無駄が含まれています。

• 開催スケジュールが決まっていない
• 参加者が多すぎる
• 会議の時間が長すぎる
• 議題が決まっていない
• 会議が終わった時に何も決まっていない

日本人は開始時間に厳しいが、終了時間にルーズ、という特徴があるそうです。ファシリテーター、タイムキーパー役を準備しておくと効果があります。

一方、やると決めた定例会議は絶対にやり切ることが重要です。よくある欠席理由が「お客様との会議が入った」というもの。お客様優先と考えてのことかもしれませんが、プロジェクトの会議活動もお客様のためのもの。なぜその時間に別の設定したのか、よく確認する必要があります。ただ、どうしても時間が合わないのなら、定例会議の時間を柔軟に変更することも必要です。

そのほか、プロジェクトのルールを見直し、正しいと思われる新しいルールを決めます。メリットのないルールは無くしましょう。例えば、社内報告用の資料をわざわざ作ることや、ビジネスチャットに「お疲れ様です」「承知しました」は不要として、いいね！ボタンなどで代用することです。

トラブルプロジェクトは勤務時間がルーズになりがち。統制が取れていない状況は即時、正さなくてはなりません。朝会を再設定してリズムを作り直しましょう。（リズムについては次章で再掲）

ルールの例

• 出社時間、退社時間、遅刻または早退時の連絡ルール
• 座席表、連絡先（電話、メールアドレスなど）
• 成果物のネーミングルールおよび格納場所
• 会議体のルール（時間、場所、議事録など）

テンプレートの例

• 進捗確認シート
• 成果物テンプレート（要件定義書、設計図など）
• 問題発生時の管理ルール（データベースなど）
• プロジェクト辞書（用語説明など）

ところで、キックオフミーティングはどんな状況であっても重要なイベントです。

通常のプロジェクトを開始時点はもちろん、途中でプロジェクトを引き継いだを場合であっても、プロジェクトチームの心理的ダメージを軽減して、モチベーションを切り替えるきっかけになります。

通常のキックオフミーティングでは、計画、スケジュール、体制、会議体、ルールなど事務的・形式的な内容が中心になりますが、トラブルプロジェクトでは、プロジェクトの本来の意義、目標を再認識したり、「こうすればできる」という前向き、未来形、私たち（We）を主語にしたメッセージがとても重要になります。

プロジェクトチームの自己効力感を高めていきましょう。

プロジェクトリカバリのコツとヒント（３）

体制と役割の再定義 

　チームに役割と責任があるように、チームメンバー一人ひとりにも役割と責任があります。正しく取り組めばその役割と責任を果たすことができるように、プロジェクトマネージャやリーダは適切に権限を配分する必要があります。そのために、体制と役割を再定義しましょう。同じ結果になっても問題ありません。点検することが必要です。

「役割」を示した図はあるか

プロジェクト実行計画書などに、「体制図」は必ず準備されていると思いますが、「役割」を明記した資料まで準備しているでしょうか。リーダーとサブリーダーはどのように役割と責任が分担されているのか、各サブチームはそれぞれどのような役割を果たせばよいのか、サブチームのリーダーにはどんな責任があるのか。こうしたことが曖昧なまま進めてしまうと、「任せたつもり」「そこまでやるつもりはない」などと責任の押しつけとなり、せっかくの主体性が他責の精神に逆戻りしてしまいます。これは避けなければいけません。

「正しく取り組めばその役割と責任を果たすことができるように」と書きました。役割と責任を明確にして、メンバーにそれを果たしてもらうために、適切な権限を設定しましょう。言い換えれば、リーダーとしての期待を明確にすることでもあります。これを体制図や役割分担表などに整理してます。場合によっては、プロジェクトメンバーの相関図を書いて、（手描きでも良いと思います。必ず残しておき、共有してください）、誰が誰に対してどのような責任を持つのか、を示してもよいかもしれません。RACIチャートという手法もあります。

asana.com

正しい状態を診る

プロジェクトの中途段階で引き継いだ場合、特にトラブルプロジェクトの場合、作成・メンテナンスすべきドキュメントが放置されている場合があります。実態を正しく示している資料がないことも多いです。まず、以下の4点について、(1) 作成されているか、(2) 適切にメンテナンスされているか、(3) 実態と乖離していないか、を点検しましょう。

• プロジェクト計画書
• 体制図・役割定義
• 課題管理表
• 進捗報告資料

点検の結果、(1)〜(3) のポイントを満たせていない場合は、まず実態と合うように作成や改定をします。ドキュメントの作成やメンテナンスを漏らさないようにするために、テンプレート化することやメンテナンスルールを作ることを試してみてください。

実態と乖離していないか、特に「課題管理表のレベル」を評価するとプロジェクト状況がわかります。管理表の更新頻度が低かったり、担当者と期限が設定されていない、起票〜完了までのプロセスが定義されていない、などの状況であれば要注意です。

体制と役割を再定義したら、プロジェクトチームへ説明し、浸透させます。プロジェクトマネージャ・リーダは、メンバーへ役割やタスクを振ることを恐れてはいけません。マネージャ・リーダが権限委譲できないチームでは、マネージャ・リーダ自身がボトルネックとなりますので注意が必要です。

体制強化、増員の誘惑

なお、トラブルプロジェクトでは、「体制強化」策がとられることが多いと思います。しかし、無闇に人を増やさないほうが得策です。メンバーを増やすと、どんなに優秀な要員を追加したとしても、以下のロスが発生します。

• コミュニケーション量が増え、プロジェクト内に余計なワークロードが増えてしまう
• 仕事レベルのばらつきが増える。属人的な要素は少なからずあるので、増幅してしまう。
• 追加したメンバーがパフォーマンスを発揮するまでに時間がかかる

類似した話題として、チームの成長曲線に「タックマン・モデル」という概念があります。どんなに経験豊富で優秀なメンバーを揃えても、この4つの段階は必ず通っていくというものです。体制強化・増員をするにあたって、理解しておくとよいでしょう。

プロジェクトリカバリのコツとヒント（２）

プロジェクトを診る

まずはプロジェクトに対する理解を深める必要があります。

プロジェクト開始段階からプロジェクトマネージャを担っている場合はともかくとして、途中で引き継いだ場合は特に、プロジェクトを「診る＝診断する」ことが必要になってきます。トラブルプロジェクトでは、実態がよくわからない状態になっていることが少なくありません。資料と実態が乖離している場合もあります。資料だけを「見て」、それが真実だと理解してしまっては、プロジェクトを「診て」いることにはなりません。

前任者やプロジェクトメンバーに現状を尋ねるとき、その経緯や背景を掘り下げてみてください。「それはなぜですか？」の問いかけで真実に近づいていくことができると思います。また、事実のように語られる内容も、言い方は悪いですが信憑性に疑問を持つことが必要です。

• それは誰が言ったのですか？
• それはあなたの意見ですか？
• その原因は何だと思いますか？
• それは何の資料を見ればわかりますか？

上記のように尋ねていくと、実は「みんながそう言っているからそういうものだと思っていた」「原因は把握していない」「どこの資料だったかな・・（あるいは資料には載っていない）」などという答えが返ってきたりします。ただしここで、メンバーを責めることは禁物です。そのように考えるに至った背景を探っているので、プロジェクト全体の問題と考えるのが正しい姿勢です。

課題管理台帳を診る

また、プロジェクト状況の実態を探る手段として、「課題管理台帳の記載レベル」を評価するやり方があります。以下のような点をチェックします。

• そもそも管理台帳がない
• 台帳はあるが更新頻度が低い（通常、課題は日々発生するもの）
• 担当者と期限の設定がない
• 起票〜完了のプロセスが定義されていない（誰が起票するか、誰が承認するか、誰がクローズするか）

進捗資料はその時点のスナップショットですが、課題管理台帳は生きているプロジェクトを映すべき資料ですので、この鮮度が低そうであれば、プロジェクト状況は良くないと言わざるを得ません。

メンバーの立場から見れば、通常の作業のほかに記入すべきドキュメントが増えるので、面倒と感じるかもしれません。しかし、課題を提起することで、その課題は個人のものではなくプロジェクトの課題となるので、抱え込まないためにも記録してもらうことが重要です。タイムリーに記載をしておかないと、プロジェクトを「見えなくしている」過失となります。

現場初日に見るべき「現場検証10のポイント」

何となく違和感を感じる項目がある場合は、そこに問題が潜んでいる可能性があります。

1. ホワイトボード：あるか？活用されている形跡はあるか？
2. 机の上の状態：片付いているか？乱雑でないか？
3. 会議室の数と広さ：プロジェクトに十分な物量があるか？
4. 座席の配置：物理的に離れていてコミュニケーションを阻害していることはないか？
5. 会議の内容：必要な内容で、必要なときに、必要なメンバーで行われているか？
6. メンバーの年齢構成：発言機会に偏りがある場合も
7. 服装：身だしなみは整っているか、疲弊感はないか？
8. 昼食時間の行動：会話があるか、別々の方向を向いていないか？
9. 会話の量：指示と報告のような、必要最低限の会話だけになっていないか？
10. 勤務時間：ルーズになっていないか？残業が常態化していないか？

プロジェクトリカバリのコツとヒント（１）

プロジェクトを任されたときの心構え

唐突ですが、Responsibility（責任）の単語は、”Response” + ”ability” に分解することができます。”ability” は能力、性能、力量の意味です。一方の “Response” は応答、反応、手応えといった意味ですが、その語源は「約束を返す」だそうです。 責任を取る立場になることは、「約束を果たす」役割を持つことです。

プロジェクトの初期段階からプロジェクトマネージャを担っているとき、あるいはプロジェクトの途中でプロジェクトマネージャを引き継いだとき、その時点でプロジェクトの責任はマネージャに求められるようになります。任命されたら、「約束を果たす役割を得た」と考えることによって、プロジェクトを「自分ゴト」として捉えることができるようになります。

約束を果たすための4つの覚悟

まず、他責にならないこと。

特にプロジェクトを引き継いだとき、状況が芳しくないこともあります。原因を探る必要はありますが、人を責める気持ち＝他責にならず、事実を洗い出すことに注力するべきです。指を自分に向けてください。この状況を、あなたはどうしたいですか。

二つ目は、被害者意識を捨てること。

プロジェクトは簡単なものばかりではありません。むしろ簡単なほうが稀です。「たいへんなプロジェクトを引き継がされた。重い責任を追わされた」など受動態の被害者意識が役に立つことはありません。プロジェクトチームにもそれは伝播してしまい、まるで自分たちが加害者のような感覚を持ってしまいます。まったく建設的ではありません。

ここでも自分に指を向け、自分ならどうしていきたいのか、どう変化させていきたいのか、にフォーカスします。

三つ目は、腹を決めること。

「腹を決める」というのは具体的な行動ではないので、行動の例を一つあげると、「自分がリーダーであること」を知らしめ、「リーダーにふさわしいこと」を示すことです。虚勢をはったり、背伸びをする必要はありません。「これから私が指揮を執りますよ」「矢面に立つのは私ですよ」ということを伝えればよいのです。

物理的にメンバーの前に立ち、一歩前に出る、先頭に立って話をすることです。オンラインの会議では、カメラをONにして存在感を強調すると良いです。メンバーの目を、自分の方へ向けることです。そうすれば、メンバーはリーダーの相談に乗ってくれることでしょう。

そして最後に、「主語を自分にする」こと。

前述の3点でも繰り返し述べていますが、思考も言動も、主語を自分にすることで、主体的にプロジェクトに取り組むことができます。同時に、有形無形でメンバーにも伝わります。

プロジェクトマネージャやリーダーは、ポジティブを心がけましょう。「きっと、うまくいく」と信じることは、自己効力感を増し、建設的に前進する手助けとなります。ただし同時に、プロジェクトの状況が危機的であるとか、状況は事実として共通認識を持つことも必要です。

また、プロジェクトマネージャやリーダーは「役割」と割り切りましょう。どんなにひどい状況であっても命を取られることはないし、人間性を否定されるような物言いをされても、リーダーという「役割」に対しての評価と捉え、必要以上に影響されないことです。