プロジェクトが止まった時に、経営者がまず確認すること

プロジェクトは、ある日突然止まるわけではありません。少しずつ、次のような状態になっていきます。

• 予定より大幅に遅れているのに、いつ終わるのか誰も答えられない
• 担当者に聞いても、話が要領を得ない
• 当初の担当者がいなくなり、なぜ今こうなっているのか経緯が分からない
• IT企業と話がかみ合わず、打ち合わせのたびに同じ話をしている
• 要件が決まらず、作業が進まない
• 費用だけが膨らみ、続けるべきか判断できない

どれか1つでも当てはまるなら、そのプロジェクトはもう止まりかけていると考えた方がいいと思います。「もう少し様子を見よう」と思った時点で、手を打つ時期は来ています。

私が途中から入ったプロジェクトでも、入った時点の状態はさまざまでした。エネルギー業の会社の案件では、最初の関係者がいなくなり、要件と約束事、メーカー（ツールを作っている会社）の説明が食い違ったまま進んでいました。総合重工業の会社の案件では、別の会社が入れたツールはあったのに、レポートの開発が止まっていました。エネルギー業の案件では、開発は追加の見積もりで続いていました。それでも、工数とスケジュールは、もう合わなくなっていました。作業が続いていることと、プロジェクトが前に進んでいることは、別のことです。

止まったプロジェクトを前にすると、原因をすぐに1つに決めたくなります。人が足りないから。担当者の力が足りないから。IT企業が悪いから。

でも、私が見てきた現場では、原因が1つだけだったことはほとんどありません。いくつもの要因が絡み合って、今の状態になっています。最初に原因を決めつけてしまうと、その原因に合う情報ばかりを集めてしまい、本当の問題が見えなくなります。

だから最初は、思い込みを外して、事実を集めるところから始めます。

私が途中から入る時は、人に話を聞きに行く前に、まずプロジェクトの資料を自分で読みます。目的とゴール、要件定義の仕様書（何を作るかを決めた資料）、詳細設計書（どう作るかを細かく決めた資料）。何も分からないまま「教えてください」と聞くのと、資料を読んだうえで「ここまでは分かったので、この先を教えてください」と聞くのとでは、相手の受け取り方がまったく違うからです。資料が古いまま、あるいは無いのなら、「どこまでが資料に残っていて、どこからが残っていないか」が分かること自体が、大事な情報になります。

この入り方は、別の記事で詳しく書いています。

関連する記事：混乱したプロジェクトに入って最初にやる3つのこと

今の状態は、次の4つの視点で確かめます。

視点	確かめること
進み具合	計画と資料が、今の状態を表しているか
体制と決める人	誰が何を決め、どこからどこまでが誰の仕事か
関係者の認識	経営、現場、IT企業が、同じものを見ているか
作る範囲	今作ろうとしているものが、本当に今必要か

進み具合を確かめる

最初に見るのは、計画と資料です。

• 作業を分解した計画表（WBS）があり、更新されているか
• 仕様書や設計書が、今の状態を反映しているか
• 課題の一覧がつけられているか、放置されていないか
• 進み具合が、誰が見ても分かる形になっているか
• これらの資料が1か所にまとまっているか、あちこちに散らばっているか

見落とされやすいのが、最後の「資料が1か所にまとまっているか」です。止まっているプロジェクトでは、「確認したくても、最新の資料がどこにあるか分からない」ということがよく起きます。情報がばらばらな状態では、今の状態を正確につかむこと自体ができません。

体制と決める人を確かめる

次に見るのは、体制です。

• 業務の流れの全体を、誰かが把握しているか
• 最後に決める人は誰か。現場のキーマン（話をまとめる中心の人）と混同していないか
• どこからどこまでが誰の仕事か、線が引かれているか
• 責任者と各メンバーの役割が、文書になっているか

複数のIT企業が関わる案件では、ここが特に大事です。発注する側が全体をつかめていないと、どこで問題が起きているのか、誰の仕事なのかがあいまいになり、対応が後手に回ります。下請けが何層にも重なっている場合は、実際の作業がどの階層で止まっているのかまで確かめる必要があります。

関係者の認識を確かめる

3つ目は、人と情報の流れです。

• 誰が誰に、何を、どう報告しているか
• 現場のキーマンは誰か
• 現場のメンバーまで、具体的な指示が届いているか

以前、あるプロジェクトに途中から入った時のことです。責任者は「ベテランのPMOがいるから大丈夫」と任せきりにしていました。一方のPMO（プロジェクトの管理を支える役割）は、システムの細かい仕様の話ばかりで、プロジェクト全体の状態をつかめていませんでした。開発リーダーに聞くと「そもそも今回の範囲が決まっていない」と言い、開発メンバーに聞くと「具体的な指示が降りてきていない」と言う。

関係者それぞれの認識が、まったくかみ合っていなかったんです。止まっている原因は、誰か一人の力不足ではありませんでした。この認識のずれでした。

実例：説明の食い違いから止まりかけたプロジェクト

エネルギー業の会社の案件も、根っこは認識のずれでした。私が途中から入ったプロジェクトです。順を追って書きます。

最初の食い違いは、お客様とメーカーの間で起きていました。営業の段階でお客様が聞いていた話と、プロジェクトが始まってからの説明が違っていたんです。

当時の私の会社は、要件どおりに開発を終えていました。ところが、その後お客様がやりたいことを形にしていく中で、ツールの仕様ではできない内容があると分かります。メーカーから聞いていた話と違う、ということで、仕様の変更と、開発スケジュールの組み直しが必要になりました。私の会社からメーカーに修正の開発を相談し、追加の見積もりで対応できると返事をもらい、お客様にも追加の見積もりで了承をいただいて、開発を進めていました。

私が入ったのは、ここからです。担当者が変わることになり、このプロジェクトのPM（プロジェクトマネージャー）と営業を任されました。

計画を見て、すぐに2つのことに気づきました。開発の工数が足りていないこと、そして開発スケジュールに無理があることです。現場に確かめると、どちらもそのとおりでした。

私はまず、お客様に今の状況をそのまま説明しました。そのうえで、なぜこうなったのかを伺う場と、これからどうするかを相談する場を設けています。話を聞いていくと、当時の担当者の間で、言った、言わない、という話がいくつも出てきました。だから、3社それぞれに話を聞き、何が約束されていて、何が約束されていなかったのかを整理し直しました。

3社の状況と、それぞれが取れる対応が見えたところで、落としどころを探りました。まず、作業を一度止めています。そのうえで、優先して開発したい内容を棚卸しし、範囲を絞って、期間を区切って進めることにしました。区切った期間が終わったら、状況を見て、もう一度話し合う。範囲と期間と費用を、関わる会社がそれぞれ受け入れられる形に組み直したんです。

落としどころは、どこか1社だけ、あるいは自分たちの会社だけが得をする形では長続きしません。それぞれが何を譲れて、何を譲れないのかを聞き、その間を探すことが大事だと考えています。

落としどころが決まってからは、お客様と一緒に、まず優先順位を決めました。課題の一覧で課題を棚卸しし、計画表（WBS）を作り直して、スケジュールを管理しながら進めています。週に1回、進み具合と状況をお客様に報告し、共有しました。

立て直した後、お客様の責任者に経緯を説明したところ、同じツールを導入していた親会社と関連会社の情報システムの責任者を紹介していただきました。

作る範囲を確かめる

4つ目は、作る範囲です。

• 今の要件の範囲は、本当に今必要なものか
• 「あったら良いもの」と「なくてはならないもの」が混ざっていないか

止まっているプロジェクトでは、進めているうちに、本当に必要な機能が見えなくなっていることがよくあります。一度、要件を整理し直して、優先順位をはっきりさせる。場合によっては、最低限必要な範囲だけを先に進める、という判断も有効です。

今の状態が分かったら、次は「そもそも、このプロジェクトのゴールは何だったか」に戻ります。目の前の遅れや問題に追われているうちに、本来のゴールを見失っていることがよくあるからです。

確かめることは、3つです。

1. 最初に決めたゴールは、今も変わらず生きているか
2. 残っている予算で、今の状態から何ができるか
3. 契約の形（準委任か、請負かなど）で、取れる手がどう変わるか

見落とされやすいのが、1つ目の「ゴールが今も生きているか」です。プロジェクトを始めた時と今とで、会社を取り巻く状況が変わっていることは珍しくありません。市場が変わった。担当者が変わった。最初の見込みが甘かった。こうした変化があるのに、最初のゴールにこだわり続けると、そのこだわり自体が無理を生みます。

予算も、「あといくら残っているか」だけでは足りません。「その予算で、今の状態から何が実現できるのか」を、現実的に見積もり直します。楽観的な見積もりのまま進むと、予算が尽きた時点で、中途半端な状態のまま止まってしまいます。

契約と見積もりで、見落としやすいこと

3つ目の「契約の形」は、経営者の方が一番見落としやすい所です。

ITの開発の契約には、大きく請負と準委任があります。請負は、決めたものを完成させることを約束する契約です。準委任は、決めた作業をすることを約束する契約で、完成までは約束していません。2020年4月に施行された民法の改正で、準委任でも、できあがったものに対して支払う形を選べるようになりました（出典：法務省「民法の一部を改正する法律（債権法改正）について」、2026年11月2日に確認）。同じ「止まった」でも、どちらの契約かで、相手に求められることと、こちらが取れる手が変わります。

私が特に見落とされやすいと感じているのは、次の3つです。

項目	確かめること
納品物	何を納めてもらう約束か。設計書や手順書、作った途中の資料まで含まれているか
作成物	作業の中で作ったもの（資料、プログラム、設定など）を、こちらに渡してもらえるか
契約不適合責任（以前の瑕疵担保責任）	納めたものが約束と違った時に、いつまで、どこまで直してもらえるか

このほかに、次の点も確かめておくと、立て直しの時に困りません。

項目	確かめること
仕様の変更	変更を誰が決め、追加の費用と期間をどう決めるか
途中でやめた時の精算	それまでに進んだ分の費用を、どう扱うか
完了の条件	何をもって完了とし、どう検収（納品されたものを確かめて受け取ること）するか
見積もりの前提	見積もりがどんな前提で出されていて、前提が崩れたらどうなるか
成果物の権利	作ったものの権利（著作権など）を、どちらが持つか
再委託	作業を下請けに出せるか、出せるならどこまでか

上の2つは、止まったプロジェクトで特にもめやすい所です。仕様が何度も変わるのに変更の決め方が無いと、エネルギー業の案件のように、工数とスケジュールが合わなくなります。やめる、仕切り直すと決めた時に精算の決まりが無いと、そこでまた話が止まります。

契約書を最後に確かめる時は、弁護士などの専門家と一緒に見ることをおすすめします。私が手伝えるのは、契約書の条文の手前にある、「実際の作業で何が起きていて、何を決めておく必要があるか」を整理するところです。

ゴールに戻ると、何から手をつけるべきかが見えてきます。総合重工業の案件では、親会社がやりたかったのは、レポートを充実させることでした。ツールは、もう入っていました。足りなかったのは、そのツールで、求めるレポートを形にするところまで進めることです。だから、止まっていた開発を動かすところから始め、データの整備、レポートの開発、データの分析、社内への引き継ぎまでを進めています。

ここまでを確かめたうえで、経営者が向き合う一番大事な判断があります。

このプロジェクトを、今のまま続けるのか。一度立ち止まって仕切り直すのか。それとも、やめるのか。

多くの現場で、この判断は先送りにされます。ここまでかけた時間とお金がもったいない、という気持ちが働くからです。けれど、状況が変わらないまま惰性で続けても、かかるお金が増えていくだけです。

判断	選ぶ時
続ける	ゴールが今も生きていて、計画と体制を直せば、残りの予算と期間で届く見込みがある
仕切り直す	ゴールは生きているが、今の進め方や体制のままでは届かない。要件や仕様が決まらないまま変わり続けている
やめる	ゴールが変わった、または残りの予算と期間では意味のある所まで届かない

やめる、仕切り直すという判断は、悪いことばかりではありません。お金を積み増す前に損を確定できる。疲れ切った現場を解放できる。プロジェクト全体を、正しい方向に切り替えられる。関わる全員にとって、合理的な選択肢になりえます。

私自身、このままでは無理だと判断して、やめることと、一度仕切り直すことを提案したことがあります。相手は、お客様の経営者や管理者、先方のPMです。現場の状況を確かめていくと、要件や仕様が何度も変わり、こちらだけでは受け止めきれない要求も重なっていました。このまま続けても、プロジェクトとしてはもたない。そう判断しました。

自社のメンバーや後輩を守るのも、私の仕事です。それに、混乱している現場は、一度リセットした方がうまくいくことがあります。仕切り直して、もう一度課題を棚卸しし、状況を整理し直すんです。

ただ、やめる、仕切り直すと提案するなら、落としどころもあわせて考える必要があります。

決めるのは、経営者

もう1つ大事なのが、この判断を経営者にどう伝えるかです。

今の状態、リスク、立て直しの案、決めてほしいこと。これを整理して、判断しやすい形で並べます。私がやるのは、選択肢と根拠をそろえて、どれを選ぶべきかまで言うところまでです。最後に決めるのは、経営者です。

立て直しと並行して、避けるべき対応もはっきりさせておきます。大きく3つの形があります。

人の関係を悪くする

• 犯人を探す
• 責任を押し付け合う

誰が悪いかを追いかけても、プロジェクトは少しも前に進みません。それどころか、メンバーが安心して話せなくなり、必要な情報が上がってこなくなります。

私は途中から入る時、否定しない、犯人探しをしない、ということだけは崩さないようにしています。入った時点で起きてしまったことは、もう変えられません。変えられるのは、これからです。きれいごとではなく、そうしないと必要な情報が集まらない、という実務の理由です。

受け身になる

• 言われたことだけをやる
• お客様やIT企業に、相談も提案もしない
• 誰にも相談しない

止まっている時ほど、当事者は「余計なことを言って、これ以上問題を増やしたくない」と受け身になります。けれど、その姿勢が問題を隠し、事態を悪くしていきます。

その場しのぎで動く

• 理由のない人の増減
• 休まずに働き続ける
• 計画表を見直さない
• 全部を一度に立て直そうとする

原因を特定しないまま「とにかく人を増やす」「気合いで乗り切る」という対応は、忙しさを一時的にまぎらわせるだけです。すべての問題を同時に解決しようとすると、どれも中途半端に終わります。優先順位をつけて、1つずつ立て直していきます。

ここまでの確認は、社内でもできます。社内にプロジェクトをまとめられる人がいて、関係者の間に立てるなら、まずは社内で進めるのがいいと思います。

一方で、外の力を借りた方が早い場面もあります。

• 社内に、PMを担える人がいない
• 当初の担当者がいなくなり、経緯を知る人がいない
• IT企業との話がかみ合わず、技術の話を経営の言葉に置き換えられる人がいない
• 社内の関係が絡み合っていて、誰が言っても角が立つ

社内の担当者は、日々の仕事に追われながら、同じ組織の人間関係の中で動いています。だから、どうしても見えにくくなる所があります。外から入る人は、社内の関係から一歩離れた所で、状態を整理できます。社内の担当者を否定するのではなく、一緒に立て直す形で関わるのが基本です。

Mac-bcに頼む場合の進め方

Mac-bcでは、まず30分の無料相談で、今の状況と困っていることを伺います。そのうえで、次の順で進めます。

段階	期間の目安	やること
現状の整理	約2週	課題、経緯、約束事を洗い出し、続けるか、どう立て直すかの判断材料を出す
調整と立て直し	約2〜4週	関係者の認識をそろえ、範囲・費用・スケジュールの落としどころを提案し、計画を見直す
その後の推進	状況に応じて	PM・PMOとして、立て直した計画を前に進め、引き継ぎの形を整える

期間は、関係者の数や状況によって変わります。議事録や資料の整理には、AIを使って時間を短くします。社外秘の資料は、お客様ご自身の環境でAIを使って処理していただきます。