• HOME >
  • ZAC BLOG >
  • プロジェクトが遅延する6つの理由と遅れを取り戻す方法

プロジェクトが遅延する6つの理由と遅れを取り戻す方法

プロジェクトが遅延する6つの理由と遅れを取り戻す方法
  • このエントリーをはてなブックマークに追加
  • RSS2.0
  • ATOM

2020/10/28公開

プロジェクトに関わったことがある人なら、それがどんな関わり方であろうとも、プロジェクトの失敗がどんなに辛いものかわかるでしょう。プロジェクトが遅れていく焦燥感、迫りくるデッドラインそして納期、積み重なる疲労。焦りや疲労は確実に正常な判断力までも蝕んでいき、悪い方に転がり始めたプロジェクトはますます悪い方向に転がります。

筆者はエンジニアからキャリアを始め、システムエンジニアや数千万円~数億円規模のプロジェクトマネージャを経験してきました。そして、本ブログを運営する株式会社オロが提供する基幹業務システム「ZAC」の工程管理モジュールのプロダクトオーナーを経て、現在は様々なZAC導入プロジェクト支援とコンサルティングに従事しています。
20年に渡る様々なプロジェクトマネジメントの経験を踏まえ、本記事は「プロジェクトが遅延する理由と遅れを取り戻す方法」を詳しく紹介します。

目次

    プロジェクトの遅延とは?

    プロジェクトが失敗する原因や要因はいくつかあります。 また、プロジェクトが失敗であるとみなされる観点もいくつかあります。

    プロジェクトが失敗であるとみなされる観点として、QCDと呼ばれる、品質(Quality)、コスト(Cost)、納期(Delivery)に対する失敗があります。

    今回は特に、納期(Delivery)に対する失敗、つまりプロジェクトの遅延について詳しく紐解いてみたいと思います。 そのためにまずプロジェクトの概要と複数人が関わるプロジェクトに欠かせない、プロジェクトマネージャについて解説します。

    プロジェクトの概要

    プロジェクトとは、ある一定期間で一定の(人的・資金的・物質的)リソースを投資して目的の成果物(製品・サービス)を作り上げる活動です。一人で実施するプロジェクトもあれば、何十人何百人と携わる大きなプロジェクトもあります。 システム開発関連で有名なのは、ある大銀行の基幹システム統合刷新プロジェクトでしょう。 また、プロジェクトとはシステム開発、WEB制作、IT業に限った話ではなく、イベント業や広告業、コンサルティング業や建設業など、非常に幅広い業種において一般的な概念です。

    プロジェクトがいかに身近なものであるかを再確認していただくために極端な話を出しますと、学生時代の文化祭イベントなども運営委員会にとっては立派なプロジェクトです。文化祭というイベント成果物を成し遂げるために、運営委員会というリソースがまず投資され、その中で予算管理され、文化祭実施までの一定期間運営されるのです。

    それをプロジェクトだと認識していなかったとしても、誰しもプロジェクトを経験したことがあると言っても過言ではありません。自分一人でやること、テスト勉強や資格取得ですらそれはその方にとってのプロジェクトになるのですから。

    プロジェクトマネージャ(PM)

    このように誰しも関わりのあるプロジェクトに関して、それを良い成果で終わらせるためには、管理活動が必要です。この管理活動をプロジェクトマネジメントといい、これを専門的に行うのがプロジェクトマネージャ(PM)という職種です。国家資格や国際資格もあります。

    プロジェクトマネージャの仕事とは何でしょう?それは、プロジェクトを良い成果で終わらせるというミッションを遂行することであり、そのためには何でもします。

    プロジェクトマネージャはなぜ必要なのでしょう?プロジェクトの規模が大きくなればなるほど、関わるメンバーが多くなればなるほど、プロジェクトを遂行することが難しくなるからです。簡単に言えば、プロジェクトが計画より遅れ、プロジェクトが炎上し、プロジェクトが失敗します。

    プロジェクトが遅延する6つの理由

    プロジェクトの概要とプロジェクトマネージャの重要性が分かったところで、本題に入っていきます。先述したようにプロジェクトの失敗は様々な観点で語られますが、一番の典型で一番最初に綻びが生じるのが、「進捗の遅れ」です。

    「1日で終わる予定の仕事が、見積りが甘くて1日で終わらない。」

    「1週間の仕事の3日目でアクシデントがあった。その対処のために1週間で終わる予定のことが1週間で終わらない。」...

    わかったでしょう。立てた計画がそのとおりに終わらないので、プロジェクトは遅延するのです。

    ではここからは「プロジェクトの遅延」をより深堀りするために、数人以上が関わり、数ヶ月かかる10人月以上の規模感のプロジェクトを想定し、下記の6つの遅れる理由やリカバリの方法を記載することとします。

    まず、遅れる理由は様々です。計画側の問題、実行側の問題、またはその両者です。

    1. 見積りのミス
    2. アサインのミス
    3. 不慮の事故・アクシデント
    4. 進捗管理のミス
    5. 外注管理のミス
    6. ミスしたときのリカバリのミス

    筆者が以前に工程管理の記事でも述べたことですが、計画の変更は当たり前のことなのです。最初に立てた計画通りに全てがうまくいくプロジェクトなんてないのです。

    ミスは誰にでもありますし、計画が完璧であることなどはありません。むしろ、ミスした時に、速やかにリカバリするための計画変更・軌道修正をすることが重要です。

    プロジェクトの遅延をリカバリするために知っておきたいこと

    以下の項目では、上述した遅延理由を掘り下げるとともに、それを防ぐ工夫や起きてしまった時の対処法を提案します。

    ①見積りのミス

    見積りの技法や前提条件が明らかになっていない

    システム開発業であれば見積りの技法は色々あります。使う想定の技術によっても、そこにライブラリがあるか否かで、パーツを1から作らなければならないのか、ライブラリを利用できるのかで見積り額自体が全く異なってくるでしょう。

    対策としては使う技術や前提条件を明確にすることです。これらが明確であれば、ミスが発覚した際に原因の究明が速やかになります。その分だけ対策を早く打つことができるでしょう。

    作業分解時の作業項目のモレ

    ある程度以上大きい作業の見積りであれば、ある程度作業・工程を分解します。そしてそれら毎の見積りを算出しますが、作業分解時の作業項目の漏れも見積りのミスを生み出します。工程の分解は、プロジェクトマネージャ(以下PM)の仕事の一部です。見積り作業自体がPMの仕事と言っても良いでしょう。プロジェクト全体の収支は、見積りの精度の高さにかかっているのです。

    大きいプロジェクトになると、PMは実作業を担うエンジニアではない場合がほとんどです。PMはPMとして、プロジェクト成功(無事完了)のために実作業以外のすべてをしますし、エンジニアとしては第一線を退いている場合も多いです。 こうした場合、自分の見積りだけでは決定的に不安です。決して自分だけで見積りを完結しないようにしましょう。他者のレビューや、上級エンジニア自身にも見積りをしてもらう、実作業予定者にも見積りをしてもらい多重チェックする、などの対策を取りましょう。

    見積り者の力量によるブレ

    見積り者の力量により、見積りの精度が大きく左右されることも見逃せません。真の力量不足は経験して成長してもらうよりありませんが、上述の対策をとった上でも、見積り規模を見誤る可能性はあるのです。大規模案件ほど、見積り難度は必然的に上がります。相対的に見積り者に求められるものも高くなります。

    見積り者の力量を上げるためや見積の精度を上げるために、もう一つの重要な見積り手法を知っておくと良いでしょう。それは、人月積み上げ手法です。

    技術的な工数見積とは別に、どのランクの人を何人何ヶ月アサインするのか、自分(PM)を含めた総人月工数をざっくり見積る方法です。

    するとまず、

    技術的な工数見積 < 総人月工数見積

    上述のような関係になるはずです。少なくともコミュニケーションコスト(技術者間の分担、PMによるステークホルダー・マネジメント)とマネジメントコストが技術見積りの上に大きくのしかかるからです。

    この不等式の関係の中で適度なバランス感覚を持って見積りましょう。PMは様々なシーンでバランス感覚を求められます。ただ大きい見積りを出せばいい話ではありません。金銭感覚、人月感覚も、より上級者が見れば、すぐボッタクリだと悟られます。

    ②アサインのミス

    求められるレベルのメンバーをアサインできない

    求められている技術・職能・レベルに達していないメンバーをアサインすることで、遅延は発生します。現場の人員不足などにより、わかっていてやむなくそうせざるを得ない場合も往々にしてあるにせよ、見積り前提とのギャップが発生します。

    このケースは、気づいた時点でアサイン交代できるものならすぐに交代しましょう。やむを得ない場合には、上級者のサポート、レビュアとしてつける、その上でさらに個別の進捗管理が重要になるでしょう。

    ③不慮の事故・アクシデント

    アサインメンバーの病欠などの現象

    ある程度仕方がない状況ではありますが、プロジェクトマネジメントの世界では想定できないことではありません。リスクマネジメントとしてある程度想定すべきものとして考えておきます。

    見積りに対して工期(工程の期間)にある程度の余裕を持っておきましょう。 最初からギリギリの工程表を作っても、すぐに作り直す羽目になります。8時間の見積りに対して、1日の工期だけではギリギリです。2日の工期を取っておいても良いくらいです。ただし見積もりに対して倍の工期を予備にとっていいわけではありません。 24時間の見積りであったとしても、工期は3日ではなく倍の6日でもなく4日程度でしょう。ここもバランス感覚です。

    納期が初めから厳しいとわかりきっているプロジェクトもありますが、それはまた別の話です。例えば、Aさんのスキルなら1人月でできることだから1ヶ月の工程を引いたとします。 ですが、クライアントの要求が0.5ヶ月での納品だったとすると、Aさんだけでは実現できません。では同じスキルを持ったBさんが加入して2人で0.5ヶ月で納品できるでしょうか?

    答えは、できません。

    Aさん一人であれば、すべて自分の中で完結できます。会話も不要です。Bさんと2人の共同作業となった途端、分担・棲み分け・インターフェースと様々なコミュニケーションが発生します。コミュニケーションコストは馬鹿になりません。

    コミュニケーションコストを考えた上でのアサインの重要性

    実際このケースの納期要求を満たすためには、フルアサインではないにしろ、4人(3人のエンジニアとPM)は必要になるでしょう。1人の作業を2人に分業すると、トータルでは元の作業の1.5倍のコストがかかると言っても過言ではありません。

    ④進捗管理のミス

    メンバーからPMへの進捗報告の有無や方法があいまいになっている

    メンバーが自分の遅延をPMへ報告自体しない、もしくは正しい報告をしないこともあります。遅れているのは自分の能力不足が原因だと思いこみやすかったり、責任感の強いメンバーは特にその傾向があります。自分のオーバーワークによって遅れを取り戻そうとして空回りします。また、有識者に聞かずに、不要に悩むことで時間を浪費します。

    PMにとって、プロジェクトを無事完了させるというミッションの遂行が全てです。

    上述のとおり見積り自体が誤っている可能性も大いにあるのです。 PMはメンバーに対して、日々、正直に進捗を報告する重要性について啓蒙活動をしましょう。 予定に対する遅延は悪ではありません。メンバーが報告しに来ないことが悪いのでもありません。甘えや非効率による遅延は徹底して改善するにしても、PMがこういう問題を感知するためには、メンバーとの日々のコミュニケーションは非常に大切です。

    この場合は、PM自身が自分に報告しにくい雰囲気を作っているのかもしれません。PMはミッション遂行のために、報告がないなら自分から行くしかないのです。

    PMがステークホルダーへの遅延報告をおろそかにしている

    PMはプロジェクトに関する全ての責任を背負っていますが、その中の一つに進捗管理責任を負っています。大きいプロジェクトであれば、サブプロジェクト毎にプロジェクトリーダーに実務は分担するかもしれませんが責任はPMにあります。 一方で、PMは、社内のステークホルダー(社長等)や、社外のステークホルダー(クライアント)に対して、適宜、プロジェクト状況を報告する必要があるでしょう。PMが自分のプロジェクトの遅延状況を上司に報告しないことは、メンバーがPMに遅延報告しないこととは、全く次元の異なる問題です。こちらは大問題です。

    社内の報告会などの制度のあるなしに関わらず、全体納期を守れないリスク・懸念が少しでもあるのでしたら、まずは上長報告の準備をしましょう。もはやリカバリの効かない報告は、上司でなくとも誰も聞きたくありません。

    プロジェクトが遅延している、または遅延が予想されるという報告の際には少なくとも以下の情報は必要でしょう。

    • プロジェクトの全体概況
    • 問題の要点
    • 問題の原因
    • 問題のインパクト、このままだとどの程度の遅延の可能性があるのか
    • 問題に対するリカバリ案を複数
    • PM自身はどうしたいのか

    どうしたいのかわからない場合もあるでしょう。そうであればまずは報告・相談ベースでも良いでしょう。そこで悩んで報告が遅れるほうが問題になります。

    ⑤外注管理のミス

    外注業者がリカバリできない状況になってから遅延を報告する

    外注業者に一括発注したことで、その分の進捗が把握できなくなり、手遅れになってから業者から遅延を報告される。これは非常に根が深い問題です。 ただ、外注業者で発生している問題は上述したふたつの進捗管理ミスと同じことなのです。

    手遅れになってから遅延報告されてはおしまいですので、

    • 実力のわからない外注業者には委託しない
    • 何度か小さい案件から依頼して着実な実績を作っていく
    • 作業進捗がわかるように一緒に作業をしてもらう

    といった手遅れにならないための施策を先に打つしかありません。

    ⑥ミスした時のリカバリのミス

    リカバリは必ずできるわけではない

    ミスがあれば、プロジェクトを運営していく過程のどこかで、遅かれ早かれプロジェクトの進捗の異常には気づきますし、そのリカバリを図ろうと試みます。ですが、必ずしもリカバリできるわけではありません。冒頭に述べたように、プロジェクトが一度悪い方向に回り始めると、どんどん悪化の一途を辿ることは往々にしてあります。 それにはいくつかの要因があります。

    • 元の計画通りに完全に戻そうと無茶な対策をする。
    • ミスの原因分析に誤りがある。
    • プロジェクトメンバー全員が焦っている。

    うまくいっていないプロジェクトには共通して疲労と焦りが全体に蔓延しています。

    これまで述べてきた内容の組合せになりますが、リカバリのミスを防ぐためには下記の3点が重要です。

    • PMがまず落ち着く。落ち着くために、PMO(プロジェクトマネジメントオフィス)等の第三者を巻き込む。
    • ミスの原因分析を正確に実施する。そのために、上司や上級エンジニアを巻き込む。
    • すべてを完全に挽回する必要などない。ミスと対策の度合いに応じて、計画の修正を実施する。

    全体の納期延長が軽々しくできるわけは当然ありませんが、計画の修正は最終の納期延長だけに限りません。全体の工程表に対する工程ごとに調整を入れることで、全体納期は変えなくて済む可能性もあります。

    進捗管理の重要性

    一口に遅延といってもその原因や理由は千差万別です。 ただ、その前提には、遅延を遅延と把握できるための進捗管理方法が確立されている必要があります。 それには筆者の工程管理の記事が参考になるでしょう。

    例えば、弊社のクラウドERP「ZAC」による進捗管理であれば、原価進捗、工数進捗、成果物進捗の3つの指標で管理でき、メンバーは対象の案件や工程に日々かけた工数を登録するだけでよいのです。

    そこからPMはまず少なくとも原価進捗と工数進捗を把握できます。 この2つの日々の進捗具合から、PMは問題の有無の目安は把握できます。 次に成果物進捗ですが、この運用はいくつか手法があります。 まずはメンバーに直接申告させて、本当にそうなのかをPMが直接メンバーとのコミュニケーションをもって確認する、 もしくはPMが直接、進捗ミーティングを開催し、状況を各自報告してもらいながら、自分で直接成果物進捗を更新するという手法があります。

    ZACはERPであることから、プロジェクト収支情報や勤怠工数情報など非常に多くの情報を一元化し、詳細に把握することが可能です。PMは、それらの情報を元に、自分の案件・プロジェクトの健全性のチェック、違和感の有無を確認し続けることがまずは大切です。メンバーの工数の入力漏れなどは、すぐにZACのデータチェックにより異常や違和感として現れてくるでしょう。

    また、進捗ミーティングなどは、案件や各工程の状況によって頻度を変えたり、開催時間を変えるのも良いでしょう。

    案件の序盤や、各大工程の序盤から、大きく進捗に問題があるということはさほどありません。進捗が半分までは見積りミスやアサインミスを洗い出すレベルの週次での簡易なミーティング。終盤に差し掛かるほど、日々の進捗は重要になるため、朝会や夕会を実施するなどして日々の着実な成果を明確にし、問題を早期に発見できる運用を構築しましょう。

    「この作業・工程が、もう少しで終わるはずのに、なぜかなかなか終わらない、終われない」こともよくあります。 2:8の法則とよく言われますが、成果の8割は最初の2割の力で出せるのです。逆を言えば、残り2割の完成度を高めクロージングすることにこそ難しさがあり、進捗管理の実践上の肝になりますので、クロージングできない理由を突き詰めることも重要です。

    2:8の法則の図解

    おわりに

    ここまでプロジェクトの遅延理由とともに、その予防策やリカバリ策を述べてきました。同時に、正確な進捗管理の重要性とともに必ずしも進捗管理ツールをただ使っているだけでは、「本当の遅延」が見えてこないリスクも感じていただけたのではないでしょうか? メンバーが進捗率を遅れなく更新しているように見せて、(その実、その申告は悪意による嘘でないにしても)事実でないことはザラにあります。「問題はない」と担当メンバーは心からそう信じていても、より上位のエンジニアやプロジェクトマネージャが見れば「それではまずい」という事態も起こるのです。

    ツール管理は便利ですし、実際、必ず使うべきだと思いますが、ツールを過信しすぎても危険です。ツールを使っているのはプロジェクトメンバーという一人一人の人間なのです。

    ミスは誰しも犯します。ミスした時のリカバリも重要ですが、そのミスを軽微な状態で早く気づけるほどリカバリも簡単です。そのためには、予防こそが重要なのです。 本記事が、ミスしても炎上しない健全なプロジェクト運営のための参考になれば何よりです。

    工数見積改善マニュアル

    工数見積もりの精度を上げる。それはシンプルなように見えて、難しい課題です。この資料では、工数見積もりがうまくいかない原因をタイプ別に分類。改善に必要な9つのステップをチャート形式でまとめました。

    無料ダウンロード
    • このエントリーをはてなブックマークに追加
    • RSS2.0
    • ATOM
    藤原 勲

    この記事の筆者

    株式会社オロ ZAC導入コンサルタント

    藤原 勲

    大手電機メーカー、中堅ITベンダーを経て、2009年に株式会社オロへ入社。プロジェクトマネジメント実績、50名規模の開発・制作グループマネジメント実績、ZACの導入支援・コンサルティング実績に富み、最大で4億円規模の案件を統括PMとして成功に導く。現在では、管理会計、ZAC導入、PMを軸としプリセールスを含めたコンサルタントとして活躍中。迅速果断と顧客満足がモットー。

    ページ先頭へ戻る