本記事の目的

業務の都合でプロジェクトマネジメントについて改めて調べる機会があったので、基本からざっくりと勉強し直すことにしました。
また、私（長野）はエンジニア歴5年目になります。この5年間で、いくつかの炎上案件も経験してきました。
この記事では、その炎上案件の原因を自分なりに振り返り、事例を交えながら「何が問題だったのか」「どうすれば防げたのか」といった対策について考察していきます！

プロジェクトマネジメントの目的

プロジェクトマネジメントは、主にプロジェクトマネージャー（PM）が担当します。プロジェクトマネージャーは、プロジェクト全体の責任者として、計画の立案から進捗管理、リソースの調整、課題解決、関係者とのコミュニケーションまで幅広い役割を担います。

ただし、プロジェクトの規模や組織の形態によっては、チームリーダーや各分野の責任者がマネジメントを分担しながら行うこともあります。
チームリーダーとの違いがたまによくわからなくなるので、少しまとめてみました。

簡単にまとめると、

• PMは、「プロジェクト全体を管理する責任者」


• PLは、「現場チームをまとめ実務を進めるリーダー」

といった感じです。PMは全体戦略や管理が中心なのに対し、PLは現場のタスク管理やメンバーサポートなど、より現場寄りの役割を担います。

PMがいないとどうなる？

現場のメンバーとPMの業務内容は大きく異なるため、正直PMの重要性や恩恵は分かりづらいかもしれません。
そこで、「PMがいないとどうなるのか？」という観点から見ていきたいと思います。

1.プロジェクトの方向性が定まらない

プロジェクト全体のビジョンや目標が不明確になり、チームや関係者が迷走しがちです。
ゴールが曖昧になり、タスクの優先順位がバラバラになってしまいます。

2. 進捗管理ができず、遅延が発生する

スケジュール統制する人もいなくなるので、各タスクの進捗が把握できなくなります。
よって、納期遅れのリスクが生じます。（タスクが溜まっていることにも気づかず、大幅にPJが遅れることも。。）

3. リソースの配分が不適切になる

誰がどのタスクを担当するか、リソースの最適化ができなくなります。
タスクがある人に偏ったり、スキル的にミスマッチなタスクを振ってしまうなど、、

4. クライアントとのコミュニケーションが不十分になる

クライアントとのコミュニケーションは主にPMが担当します。
そのため、PMが不在だと認識の齟齬が生じる可能性があり、最悪の場合、作業が無駄になることも考えられます。

5. 品質低下

全体の品質を管理・保証する役割が不在のため、成果物の品質が担保されなくなります。

このように、PMが不在だと「計画」「管理」「統制」が不十分になりプロジェクトが円滑に回らなくなります。
※ 形だけのPMがいる場合でも同様ですね。。

優秀なPMがいることで、プロジェクトが円滑に進行し、現場のメンバーも開発に集中できる環境が整うのは非常に助かりますね:)

過去の炎上事例

①仕様の認識齟齬

この場合、クライアントと開発チームの間で要求や仕様について十分な確認が行われず、途中で大きなミスや修正が必要になりました。その結果、納期が遅れ、プロジェクトの進行が大きく遅延しました。

また、「回っていないから」という理由でエンジニアが大量に増員されましたが、適切な統制が取れていなかったため、エンジニアごとに仕様の理解が異なり、混乱が生じる場面もありました。人員を追加すれば問題が解決するわけではなく、むしろ適切な管理と統制がなければ逆に混乱を招くことがあります。特に、仕様の認識や作業の進行が統一されていないと、コミュニケーションの負担が増し、作業の重複やミスが起こりやすくなります。人を増やすことよりも、既存メンバーへの適切なサポートと調整が重要であると、実際に経験しました。

②工数が足りなさすぎる

一度、テストに対して非常に工数が少ない案件にアサインしました。
開発期間が約3ヶ月である一方、テスト期間が数週間と指定されていました。
その時、開発チームは機能の実装に集中し、テストは後回しにされる傾向にありました。しかし、テストが1ヶ月というのは非常に短く、バグや不具合が発見されるリスクが高かったため、後になって修正作業に追われることになりました。

このような状況では、テストの重要性が軽視されがちですが、十分なテストを行わないと、最終的には品質が担保できず、納期を守るためにさらに多くのリソースが割かれることになります。また、テスト期間の短縮は、後の手戻りやトラブルを引き起こし、プロジェクト全体の遅延につながるリスクを高めます。

③エンジニアの技量不足（人員不足？）

開発期間が1年近くあった案件にアサインされたエンジニアの半数が経験1年未満でした。
そのため、プロジェクトの初期段階では、基本的な技術やフレームワークの理解が不足しているメンバーが多く、作業が進むにつれて問題が多発しました。特に、要件定義や設計段階で十分な理解が得られなかったため、実装後に大きな修正が必要となることがありました。

また、経験の浅いエンジニアには予期せぬトラブルや問題に迅速に対応することが難しく、納期が迫る中で焦りが生じ、品質を犠牲にしてでも進めなければならない状況に陥ることが多かったです。結果として、後半で多くのバグが発生し、修正作業に追われることになりました。

④技術選定のミス

「新しい技術を使ってみよう」と開発メンバーがそこまで馴染みのない技術を使って大炎上したことがあります。
当初、チームは「新しい技術を導入すれば、効率的に開発が進み、将来的なメンテナンス性も向上するだろう」と考えていました。しかし、実際にはその技術の理解が不十分であったため、開発が進むにつれて問題が次々に発生しました。

新しい技術が当初予想していたほどスケーラビリティやパフォーマンスに優れていなかったことが後になって判明したり、一つ一つの実装に時間を要してしまうなど、進捗が非常に遅くなりました。その結果、開発チームは期限を守るために無理に作業を進めざるを得なくなり、最終的には品質が非常に悪化しました。バグが頻発し、動作が不安定になったり、最終リリース直前に大規模な修正が必要になるなど、最悪の状況に陥ってしまいました。技術的な選定が不十分であったため、結果として時間とリソースが無駄になり、プロジェクト全体が炎上する形となりました。

終わり

炎上の要因は様々ですが、プロジェクトマネジメントの重要性を改めて深く実感しています。一方で、炎上そのものを一概に悪いと決めつけるのは難しいと個人的には感じています。

私自身、これまで数々の炎上案件を経験する中で、多くのスキルを磨き、成長してきたと感じています。もちろん、会社としてはコストが増大し、状況が厳しくなるのは事実です。しかし、あくまでもクライアントに迷惑をかけないという前提が守られていれば、炎上案件におけるプレッシャーや予期せぬ課題への対応は、開発者としての問題解決能力やスキルを大きく向上させる貴重な機会でもあります。こうした経験は、今後のキャリアにおいても大きな財産になると確信しています。

もちろん、炎上が続けば会社やチーム全体にとって深刻な課題となりますが、そこから学び、反省し、適切な改善を図ることで、次のプロジェクトに生かせる貴重な経験となります。最終的には、炎上を避けるための対策を講じることや、問題が発生した際にいかに迅速かつ的確に対応できるかが重要であると強く感じています。

※体にも良くないので、ほどほどにが大事ですが。。私は血圧がかなり上がりました。

それでは、ここまでお付き合いいただきありがとうございました:)