今回は先日読んでめちゃくちゃ勉強になった「プロジェクトのトラブル解決大全」について紹介したいと思います。
これまで炎上プロジェクトに参画したことがある人、炎上プロジェクトを招いたことがある人、炎上プロジェクトに絶対に参画したくない人、すべてのシステム開発プロジェクトに携わる方が参考になる内容ですのでぜひご覧ください。
この本は、下手に知識を体系立てしたものではなく、現場ですぐに使える手法を86個挙げているので、明日からの実務に早速活かすことができます。
本書は、日本IBMにて数々の炎上プロジェクトをサービスインに導く「火消し屋」として活躍された木部智之さんの著書となります。
本書の内容を実践することで炎上プロジェクトを沈下させることができるだけではなく、平時のプロジェクト運営においても炎上させないためのノウハウとして存分に活用できるかと思いますので、これまで運良く炎上プロジェクトとは無縁だったという方にも是非ご覧いただければと思います。
ぜひ書店でもお手に取ってみてはいかかがでしょうか。
重要ポイント
今回は86個の手法やコラムの中から、ちゃき的に厳選した７つの内容について、本書を引用しつつ、これらのポイントについて私の経験と共にその重要性について解説していきたいと思います。
〇最初に読むべき４点セット
〇炎上プロジェクトは仮設検証型で進める
〇むやみに人を増やさない
〇静かすぎるプロジェクトは危険
〇炎上中に管理するべき資料は３つだけ
〇課題管理の鉄則
〇進捗管理の鉄則
他にもたくさんノウハウがありますし、やや精神論的な内容ですが、絶対に外せないことも丁寧に記載されています。これらについてはぜひ本書にてご確認ください。
最初に読むべき４点セット
本書では、以下の資料をプロジェクト参画時に読むように示唆されています。
・プロジェクト計画書
・体制図
・課題管理表
・進捗報告資料
引用：プロジェクトトラブル解決大全 木部智之著
すべてその通り！というものばかりです。最低でも抑えておきましょうというよりは、これらだけを抑えておくべきと言っても良いと思っています。
炎上プロジェクトは大抵、これらの４つの資料が更新されていなかったり、互いに矛盾しあっていたり、実態とずれていることが多いです。そのため、これらを抑えるだけでも精一杯だと思います。これらを抑えてうえで、プロジェクトに参画し、冷静にプロジェクトの状況を捉える必要があります。
逆にいえば、これら４つの資料がしっかり整備されていれば、プロジェクトは炎上しにくいとも言えるかと思いますので、平時の時であってもこられら４つの資料はしっかりメンテする習慣をつけておくと”強いプロジェクト”になると思います。
私は過去にそもそもプロジェクト計画書が存在しないという案件に遭遇したこともあります。また、経験上よく見かけたのは、以下のように体制図が実態とかけ離れているケースでした。
体制図上、PMからPLへ、PLからTL、そしてTLからメンバへ情報が連携されるようなコミュニケーションラインになっているにもかかわらず、実態はほぼすべてPMからの発信となっており、PLやTLが機能していないということが多いです。この場合、複数会社が携わっている場合、契約形態によっては偽装請負にもなり兼ねない事態ですので、直ぐに立て直しが必要です。
炎上プロジェクトは仮設検証型で進める
続いて、炎上プロジェクトの進め方について、本書では、以下のように記されています。
現場に入る前に質問を洗い出しておく
（中略）
事前に質問を洗い出しておくことが必要です。そして、その質問は、100個は洗い出しておきましょう。
（中略）
PMとしてのフレームワークであるPMBOKにある10の知識エリア（序章参照）を使います。
引用：プロジェクトトラブル解決大全 木部智之著
ここで来ました！PMBOK！10の知識エリア！
10の知識エリアはPMを勉強し始めた人であればだれもが通ります。ただ、なかなか実践に繋げることができないと思っています。
10の知識エリアは炎上プロジェクトといった過酷な状況下での拠り所になると思います。
平時においても、10の知識エリアを意識しながらプロジェクトを推進するということは、プロジェクト全体のバランスが取れ、何かの観点や検討が漏れることを防ぐことに繋がります。
炎上プロジェクトは１日でも早く終息させなければいけないため、仮設検証型でなければスピード感がありません。そのため、仮説と思考を繰り返すことで、プロジェクトを正確に、そして速く捉え、手中に抑えることができます。
むやみに人を増やさない
プロジェクトが炎上した時の対処方法として真っ先に思い浮かぶのが「増員」だと思います。
私もこれまで何度も増員をするプロジェクトに携わってきましたし、私自身も増員の一員としてプロジェクトに参画したこともあります。時には東京を離れ、関西圏で実施しているプロジェクトに増員要員として参画したこともあります。（この時の話もいつかできればと思います。）
しかし、増員は慎重になるべきです。
本書でも増員が混乱をもたらすと説明しており、その理由として３つ挙げています。
コミュニケーション量が増えることで、プロジェクト内に余計なワークロードが増えてしまう
仕事レベルのバラツキが増える
追加したメンバーがプロジェクトの仕事を理解してパフォーマンスを発揮するまでに時間がかかる
引用：プロジェクトトラブル解決大全 木部智之著
その通りと言わざるを得ません。
増員要員として参画した経験のある立場から言うと、３つ目に関しては、特にPMや受入をする担当者に理解しておいていただきたいと心の底から思います。
少しだけ、私が増員要員（応援要員）として参画した時の話をします。本書の話とはズレるので興味のない方は飛ばしていただいて結構です。
これは私が社会人１年目の時です。
私がプロジェクトに参画した時、午前中に15分ほどプロジェクトリーダーからプロジェクトの内容について説明を受けました。ただ、どんなシステムを開発しているのか、いまどのような工程をしているのか、体制上誰に頼ったらよいかなどの説明は特にありませんでした。
開発環境構築を半日で済ませ、翌日からは言われるがままに作業をこなしました。しかし、どんなシステムを開発しているのかなど手探り状態での作業だったので当然全くといっていいほど進捗が出せず、私自身もその状況に絶望する日々を送っていました。
ましてや自分のことを棚に上げるようですが、社会人１年目のペーペーだったので余計に立ち上がりに時間がかかり、かなり苦労したことを昨日のことのように覚えています。
それからというもの私は、自分が増員要員を受け入れたり、平時の際の新規参画メンバを受け入れたりする際には、しっかりと彼ら彼女らに対して時間を使うことを意識しています。できる限り予定表をブロックして時間を作るようにしています。最初に自分の時間を使ってでも、しっかり案件の背景や、現在の状況などを伝えることで、後々の新規参画者の作業効率も上がってきやすくなると思いますし、何よりも彼ら彼女らのプロジェクトに対するコミット度合いが全く異なります。それは、時間が経つにつれ、大きな差となり、プロジェクトにとって欠かせないパワーになります。
そのため、私は新規参画メンバを大切にする、ということを意識して仕事しています。
少し話はそれましたが、増員は慎重に。プロジェクトを進行する中で肝に銘じておきたい言葉です。
静かすぎるプロジェクトは危険
こちらは、火消し術の１つとしてではなく、コラムに記載されている内容となりますが、読んでいる最中に頷きが止まらなかったので取り上げさせていただきます。
まず、プロジェクトというのは大前提として「想定外の連続である」と私は思っています。熟練のPMからすると、想定外が起きる時点でプロジェクトマネジメントとして失敗していると怒られてしまいそうです。私もこれには同意します。ただ、小さなことから挙げれば、すべてを想定しきるということに限界があるというのもまた真であると思います。
”オンスケです”、”品質に問題ありません”という報告を真に受けてはいけないと思います。PMであれば必ずその言葉にある根拠を確認しにいくべきです。なぜ、メンバはオンスケだと言っているのか、オンスケといっているレベル感は合っているのか、こちらが期待した品質も伴ったうえでのオンスケなのか、実態を必ず確認すべきだと思います。品質についても同様です。もし本当に問題なければ、問題がないなりにもプロジェクトはバタついていると思います。
本書でも以下のように記されています。
プロジェクトが小さくても、プロジェクトというものは想定外のことが起きるので、必ずバタバタします。
引用：プロジェクトトラブル解決大全 木部智之著
問題がなければないなりに誰かがその分頑張っている姿が伺い知れます。そういう目線でプロジェクトと対峙すべきです。
炎上中に管理するべき資料は３つだけ
炎上中はプロジェクト管理をよりシンプルにするために、以下の３つに注力すべきだと述べられています。
管理すべきは、作業計画、進捗管理、そして課題管理の３つです。
（中略）
なぜこの３つなのでしょうか。
プロジェクトは、計画を立てて進め、予定通りにいかなくなったら是正します。予定通りにいかなくなる理由は、課題が発生するからです。よって、その課題をタイムリーに解決し、遅れの出た進捗をすぐに戻せば、計画に沿って進めることができるのです。
引用：プロジェクトトラブル解決大全 木部智之著
作業管理は、所謂、タスク管理になります。
私はプロジェクト管理において、WBS進捗管理表をよく使います。（※WBSとは、作業を細分化したタスクのことですが、これをもとに進捗管理していくツールがWBS進捗管理表です。PMBOKではWBS＝進捗管理ではないので、言葉の定義にご注意ください。ここでは、あくまでタスク管理と進捗管理の両方を担うツールとしてWBS進捗管理表を挙げています。）
そのため、私の場合は実質、WBS進捗管理表と課題管理表の２つのみ管理することになります。
なお、私はよく課題管理表の中で、課題、QA、ToDoを区分を付けて管理しています。
そのため、この２つのドキュメントを毎日しっかり更新していくことでプロジェクトの実態を捉え続けることに繋がると思っています。
WBS進捗管理表からは、誰が今どんなタスクを実施しており、その進捗はどうかがわかります。過去の実績から未来の見立てをすることができ、タスクが漏れていないかの検討にも繋がります。もし、進捗管理の粒度とタスク（作業）管理の粒度が異なれば、そこは進捗管理とタスク（作業）管理を別々にした方がよいでしょう。
課題管理からは、そのプロジェクトが抱えているリアルな問題がわかります。また、QAからはその質やレベル（細かい内容まで検討できているか、調査できているかなど）から品質も見て取れますし、ToDoからはプロジェクトの活発状況がわかります。
本書でもこの３つ（作業管理,進捗管理,課題管理）の管理に８割の力を注ぐイメージだと述べられており、その重要性が伺い知れます。
課題管理の鉄則
前述したように課題管理はプロジェクト管理において重要な要素の１つです。そんな課題管理について、良くない課題管理の特徴が４つ挙げられています。
①課題内容がわからない
②担当者がブランク、もしくは複数名書かれている
③期限が設定されていない
④課題提起した人を担当者にしてしまう
引用：プロジェクトトラブル解決大全 木部智之著
順に詳細を説明したいと思います。
①課題内容がわからない
つまり、記載内容がよくわからない、何が課題で、検討しなければいけないことがわからない、具体性がないということです。
そのため、誰が読んでもわかる、どのようなアクションをしなければいけないかが明確になっている必要があるといえます。
②担当者がブランク、もしくは複数名書かれている
これは、課題の担当者がわからない、現在誰が課題担当者なのかわからない状態だといえます。
この課題の責任者が誰で、今ボールを持っているのは誰なのかをはっきりさせる管理が求められます。
③期限が設定されていない
期限があいまい、決まっていない状態です。期限がブランクは論外ですし、単にキリが良い日付でいったん置いているだけのものも意思が籠っていないため、意味がありません。必ず、PMが課題表に意思を籠める作業が必要です。
④課題提起した人を担当者にしてしまう
このような状態では、課題を挙げた人だけが忙しくなって損してしまいます。
すると、誰も課題を挙げたくなくなり、プロジェクトは負の方向に進み始めます。PMは真面目にやってくれている人が損するような仕組みには絶対にしてはいけません。
実際に課題管理というものは、厳格にやろうと思えば思うほど、毎日、下手したら半日に１回更新するほど、重要な管理対象だと思います。
課題管理が杜撰だと、顧客との認識のズレが発生し、将来いま以上に大きな問題となって返ってきます。逆に、課題管理がしっかりできているプロジェクトの多くは大概うまくいっている印象があります。
課題管理は必要以上に力を入れてやっていく価値があります。
進捗管理の鉄則
最後は、進捗管理についてです。進捗管理はそれだけで１つの記事にしたいくらいの内容です。
本書では、以下のように述べられています。
進捗は、まずは森を見て、さらに必ず木も見なければいけません。
引用：プロジェクトトラブル解決大全 木部智之著
つまり、全部見なければいけません。
では、どうやったら全部を見ることができるのでしょうか。
私が進捗管理する際は、以下のことに気を付けて実施しています。
・１つのタスクが長くても５営業日以内になること。
・進捗確認の粒度としては５営業日以上になる場合は、タスク管理としてさらに細分化して確認する。（例：受注登録画面の開発状況。これだけでは10人日以上かかる。そこで、登録ボタン押下処理の状況は？削除ボタン処理の状況は？画面表示処理の状況は？とイベントごとに聞いたりなど）
・作業者との完了基準を明確にする。どこまでやることがゴールなのか基準の認識を合わせる。
・目で見て評価可能なアウトプットを出させる
また、遅延が発生したときは、その作業がクリティカルパス上の作業かどうかを確認します。そして、遅延の理由、対策、リカバリ予定日を報告させ、進捗管理、作業管理を徹底させます。
最低限上記で挙げた内容の進捗管理ができれば、下手はこかないと思います。PMは進捗管理を通じて、誰よりもプロジェクトを体感し続けることが必要です。
まとめ
以上、木部智之さんの著書である「プロジェクトのトラブル解決大全」に関する解説と、私の経験を交えたプロジェクト管理手法の紹介でした。
どれも明日から現場で使えるものばかりだと思いますし、今回紹介したもの以外にもたくさんの手法がまだまだ説明されています。
また、今回はマインドに関連する内容は省きました。しかし、実際、プロジェクトマネジメントで一番重要なことはマインドだと思います。
本書でも１つの目の手法として「９割の人が怠るファーストステップ「腹をくくる」」とマインドに関する説明がされています。
ぜひ、テクニカルな面、メンタル面、双方からマネジメントスキルを上げていき、トラブルプロジェクトが１つでも火消しされ、そして１つでも多くのトラブルプロジェクトが発生しないように頑張っていきたいです。
コメント