内容
プロジェクト
プロジェクトとは、ＰＭＢＯＫでは「独自性」と「有期性」という言葉を用いて定義されています。
プロジェクトに「独自性」があるということは、「初めてやる」ものである、ということです。
つまり、プロジェクトマネジメントというのは、「初めてやる」プロジェクトを「問題ないよう」にマネジメントする。
重要資料4点セット
最初は、大まかな概要を理解し、プロジェクトの現時点での概況を捉えることにポイントを絞ります。
そのために必要な最初の資料は次の４つです。
・プロジェクト計画書
・体制図
・課題管理表
・進捗報告資料
プロジェクトが炎上してしまっている以上、そのプロジェクトには人の問題、チームの問題が必ずあります。
体制図からだけではそれらの問題まではわかりませんが、まずはプロジェクト体制を知っておくことが重要です。
体制図から知りたい情報は次の項目です。
・人数、チーム数
・リーダー、キーマン
・指揮命令系統
懐刀
どんなにあなたが優秀であっても、１人で局面を変えていくことは極めて難しいミッションなのです。
そこで必要となるのが「懐刀」です。
「懐刀」とは懐や帯に挟む守り刀のことで、自分が信頼するメンバーであり、参謀ともなるメンバーです。
私が火消しをスタートする時は、必ず優秀なメンバーを連れてきて一緒にプロジェクトを進めます。
それは社内のメンバーの場合もありますし、過去に一緒にプロジェクトをやった社外のパートナー会社の優秀なメンバーを引き込むこともあります。
懐刀には置き場所があります。
自分の直下です。
プロジェクト横断で動けるポジションで、特定の領域を持たせずに、自分と同じ範囲でプロジェクトを見られるようにします。
課題管理表
課題管理プロセスのよくある欠陥のパターンは、
・課題を吸い上げるプロセスが決まっていないので、メンバーが見つけた課題が計上されない
・課題確認のサイクルが回っておらず、期限切れの課題が放置される
・そもそも、課題の担当者や期限日が設定されていない
などです。
プロジェクトの立て直しでは、課題管理の強化を行なうことがほとんどですので、現場に入ったら必ず管理レベルを確認しておきましょう。
失敗する課題管理の特徴は次の４つです。
①課題内容がわからない
②担当者がブランク、もしくは複数名書かれている
③期限が設定されていない
④課題提起した人を担当者にしてしまう
ヒアリング
ヒアリング相手の話した内容が事実かどうかを深掘りして確認するステップを踏みましょう。
方法としては、
・なぜそう思ったのか？
・定量的な評価指標はあるか？
・それはあなたの推測なのか、何か判断材料があるのか？
・その時に何が起きたのか？起きた事象を教えてほしい
といった質問をしていくと、だんだんその人の主観的な意見を剝ぎ取っていくことができ、事実に近づけていくことができます。
課題の評価指標
優先課題を決めるには、課題の評価指標を決めます。
よく使う指標は重要度、緊急度、難易度、効果、コスト、時間です。
整理するには、縦軸に課題一覧を書き出し、横軸にこれらの評価指標を並べます。
こうしてできたマトリクスに、評価を５段階で書き入れます。
評価は、すべての課題対応について効果を算出して評価をするなど、過度に厳密にする必要はありません。
その作業の投資時間対効果が見合わないからです。
ただし、なぜそれが５でなく４なのか、といった質問には答えられるようなロジックを、自分のなかでは作っておきましょう。
火消しスケジュール
火消しスケジュールを立てるには３つのステップがあります。
新しいゴールとその過程のマイルストーンを定めます。
ゴール設定とは、このプロジェクトの完了日を決めることです。
もとの計画のままの場合もあれば、完了日を後ろ倒しに変更することもあります。
そして、ゴールを決めたら次はそこまでの中間地点のマイルストーンを設定します。
マイルストーンは細かすぎず、スケジュール上の制約となるようなものを設定します。
システム開発であれば、対外システムとの機能接続テストや、外部機関の認証テストなどです。
ゴールが決まったら、次は大きなフェーズ単位でのスケジュールを組み立てます。
システム開発であれば、「概要設計」「詳細設計」「開発」「テスト」といったフェーズです。
通常であれば、概要設計→詳細設計というように手前のスケジュールから組み立てていきますが、トラブルリカバリの時は、ゴールから逆算してスケジュールを組み立てます。
次のステップはスケジュールの詳細化です。
先ほどのフェーズ単位では計画が粗いので、もう１～２段階ほどブレークダウンします。
この作業自体は通常のスケジュール計画と同じですが、炎上時ではStep2で決めたフェーズの枠をはみ出さないように計画します。
計画
結論からいうと、「見積り通りに計画を立てる」から失敗するのです。
見積りというもの自体に「完璧」というのはありません。
見積りには必ずモレがあったり、ズレが生じたりするものなのです。
そもそもプロジェクトとは、定常業務とは違い、固有の目的（独自性）を持った一時的な（有期性）仕事です。
そのようなプロジェクトに必要な仕事、起こりうることをすべて予測しておくことは不可能です。
プロジェクトでは「想定外のことが起きる」ということを「想定しておく」ことが重要です。
会議
会議は課題を拾い上げ、対策を決め、進捗や品質に問題が出ればすぐに対処方針を決める場です。
そうなっていない機能不全の会議に費やす時間はありません。
時にはばっさりとリセットする必要があります。
トラブルプロジェクトにおいては、「統制がとれていない」という状況が、何よりもまずいのです。
無意味な質問
この無意味な質問を食らった時、私は、「できます」とも「できるかわかりません」とも答えません。
厳しいプロジェクトであるほど「できる」とは断言できませんし、「わかりません」といって宿題が増えるのも嫌だからです。
そこで、「原因は○○なので、このような再計画に沿ってプロジェクトの火消しを進めます。リスクは、○○と○○です」というように答えることにしています。
だって、本当にできるかどうかなんて誰にもわからないのですから。
炎上中のプロジェクト管理
プロジェクト管理の仕事は「間接工数」といわれていて、プロジェクト全体の工数の10～15％の工数が必要とされます。
炎上している時は、すべてをやる必要はありません。
というより、管理する工数を必要最小限にして、できるだけプロジェクトの「直接工数」に注力すべきなのです。
管理すべきは、作業計画、進捗管理、そして課題管理の３つです。
作業管理
基本的には、「１タスク５営業日以内」にします。
１週間分の作業です。
１週間以内に設定すれば、週次の定例でも完了か未完了かを確認できます。
タスクが長いと、途中の進捗で「順調です」と報告があっても、最後の報告で「全然終わりません」ということが起こりえます。
タスクに遅延が発生した時、「遅延しました」という報告だけをさせてはいけません。
必ず、「遅延の理由」「対策」「リカバリ予定日」の３点セットで報告をさせてください。
クリティカルパス
森を見ながら木を見る時にクリティカルパスの遅延だけは絶対に見落とさないようにしましょう。
クリティカルパスとは、プロジェクトにおいて一番時間がかかりうる作業ルートのことです。
つまり、このクリティカルパスの遅延はプロジェクト全体の遅延へと直結するのです。
弱いチームの戦い方
ビジネスでも、弱いチームの戦い方というものがあります。
そのポイントは「均質化」と「効率化」です。
この「均質化」「効率化」をプロジェクトで実現するために行なうことは、次の３つです。
・手順やプロセスの確立
・雛形やテンプレートの作成、活用
・ツールによる自動化
チームを強くする
チームを強くするために行なうことは３つです。
・規律やプロセスの遵守を徹底する
・メンバーを育成する
・リーダーが変わる、リーダーを替える
たとえば、２００人の開発グループを受け持つことになった時に、毎日朝会で少しずつ座学のレクチャーを始めました。
座学は３ヶ月くらいかかりましたが、プロジェクトの実務を通じてそのスキルをさらに説明しました。
その時は、プロジェクトの中断期間で朝会のテーマが少なかったので、30分のうち15～20分を使ってレクチャーしていました。
１日１テーマ、パワポで１～２ページを作っていました。
ただ、毎回資料を作る必要はなく、ありものの資料やテキストの活用でもＯＫです。
ポイントは、我流を教えるのではなく、必ず、教科書的な基礎を教えることです。
基礎を教え、トラブルという実務を通して、その基礎の使い方を教えていく、という感じです。
こうしてきちんと育成していけば、早ければ１ヶ月、遅くても３ヶ月くらいすると、メンバーのスキルが目に見えて上がってくるのがわかります。
私が受け持った時は、４つのグループの中でシンガリだった２００人のグループが、２年後には一番優秀なグループになりました。
期限を守らせるテクニック
メンバーに期限を守らせるテクニックが３つあります。
１つ目は、期限の数日前に状況報告をするように予め決めておくことです。
これをしておくと、メンバーはゼロ報告はできないので、ある程度進めた状態で報告をするようになります。
逆に、本当に進んでいない場合はその時点で対策を検討できるので期限に向けたキャッチアップが可能です。
２つ目は、タスクが遅れる場合はそれが「わかった時点で報告する」ルールを作ることです。
遅れる場合のほとんどは、期限の日に「間に合いませんでした」という報告がきます。
それを事前に報告させるようにします。
すると、事前に報告はしにくいので、なんとしても期限に間に合わせようとする心理が働きます。
３つ目は、仕事が期限に遅れた時には、なぜ遅れたのか、と毎回問い質すことです。
期限に遅れた時、リーダーがそれを放置していると、メンバーも「遅れても怒られないんだ」と気が緩みます。
期限を守らなければいけない、という雰囲気を醸成しましょう。
コミュニケーションロスを防ぐ
コミュニケーションミスをなくすためには、書くことです。
図や表、作業プロセスなどを紙に書き、イメージを可視化・共有しながらディスカッションをすると、イメージの共有ができるので間違いが生まれにくくなります。
まさに「百聞は一見に如かず」です。
PDCA
ＰＤＣＡで重要なのは、PlanとDoに対してそれぞれCheckすることです。
計画が良かったのか悪かったのか、その実行方法が良かったのか悪かったのか、ということです。
そのために、サークルではなく、マトリクスでＰＤＣＡを実践します。
凡事徹底
私がプロジェクトルームに行くと、「凡事徹底」と書かれたホワイトボードシートが壁に貼られていました。
そこには一緒に、
・約束・ルールを守る
・期日・締め切りを守る
・課題・問題を解決する
と書かれていました。
リーダー
リーダーとして「成果を出す」ということは、「リーダーとして正しいと思うことを貫く」ということです。
そのためにどうしても必要になるのが、嫌われてもいいという覚悟です。
成功体験
なぜ「成功体験」とすることが必要かというと、それがメンバーの成長につながるからです。
失敗から学ぶこともありますが、成功体験の積み重ねは大きな成長となります。
成功体験は、自己肯定感を醸成します。
そして、この経験をやり遂げられたから、次に同じ状況となってもやり遂げられる、という自信になります。
一度やりきったことは、「今回できた、だから次もできる」という実績になります。
面白かったポイント
経験豊富な筆者によるプロジェクトのトラブル解決の原則集。
結局は、多くのプレッシャーがある中でも冷静になり、基本に忠実に、メンバーとコミュニケーションをしっかりとり、コツコツと課題を潰していくしかないという結論。
魔法はないということ。
初めてやることに対して、QCDを守るのはかなり難しいが、逆にワクワクすることでもある。
このワクワクとプレッシャーを楽しむことができる人が、プロジェクトマネージャーに向いているのだと思う。
とは言え、プロジェクトの型を理解し、徹底させる能力、そして、場数を踏むことがプロジェクトマネージャーとして成長する道。
満足感を五段階評価
☆☆☆☆☆