実例！炎上プロジェクトから学ぶ 頑張っているのに成果が出にくい行動とは？
せっかく頑張っているのに成果が出ないと、落ち込んだり、焦ったりしてしまいます。
過去、スケジュールが遅延していて、リカバリをしようと頑張っているにもかかわらず、成果が出なかった事例を基に解説していきます。
今回の記事は、以下の方にぴったりです✨
☑️実際に炎上プロジェクトを経験された方
☑️頑張っているのに思ったような成果が出ていない方
例えば、要件定義から基本設計まで4カ月の予定にもかからず、5カ月かかって1ヵ月遅れになったケースです。
やりがちなパターン１：次工程以降でリカバリしようと、すぐに次の工程に入ってしまう
遅れているので「すぐに次のことをしたい」という心理が働きますが、立ち止まって振り返り分析をする方が、結果的に上手くいきます。
なぜでしょうか？
それは、現状や原因に合わせた対策でないと成果が出にくためです。
例えば、現状が、100点満点中何点か答えられるでしょうか？
答えられないのであれば、まず現状分析を行うことをお勧めします。
目標に対して大きく下回っている場合は、このまま頑張り続けるより、方向転換をした方が良い場合があります。
そのため、まずは目標に対して現状がどのレベルなのかを把握することをお勧めします。
やりがちなパターン２：とりあえず、人を投入する
「あのプロジェクトが大変だから、ちょっと手伝ってくれないか？」
そんな依頼が来た場合、自分に期待されている役割を確認しましょう。
期待内容が曖昧だったり、自分のスキルとずれていた場合、すぐに引き受けることはお勧めできません。
本来は、現状を正確に把握して課題点を洗い出し、原因分析をした上で対策を検討します。ところが炎上プロジェクトだと、とにかく急いで手を打たなければならないという心理状況のため、必要工程を飛ばして対策を検討してしまうことがあります。
例えば、基本設計の遅れの原因が下記の場合、
「お客様はどんな課題を抱えており、システム化によって何を改善することを期待されているか？ システムをどのように使われるか？」が設計に反映されていない
対策の一つとして、
「お客様の要件や運用イメージを理解して、開発メンバーに伝えて落とし込める人の補強」
が考えられます。
しかし、原因分析をしていないと、お客様と直接やり取りするのが苦手な技術者が投入されてしまうかもしれません。その場合、お互い不幸な結果になるので、現状把握の後は必ず原因分析を行いましょう。
ミスマッチがひどい場合はマイナスになる恐れも
人の投入は、必ずしもメリットだけとは限りません。
人が増えると、コミュニケーションロスが増える
どちらが実施するのか、お見合いが増える
独自のやり方、ルールが生まれやすい
指示系統が乱れやすい
導入教育、アカウントや設備の手配が増える
そのため期待されているスキル、役割は何か？、その人の保有するスキルや経験はマッチしているのか？を十分に確認した上で、人を補強することをお勧めします。
余談ですが、「足を引っ張るエンジニアが一人でもいるとチーム全体のパフォーマンスが下がるため、プロジェクトから外してチームの機能を向上させる」という事例もあります。
まとめ
頑張っているのに成果が出ない場合、
①現状把握：目標と実態にどれだけの乖離があるか？
乖離が大きい場合は、方向転換も検討する。
②原因分析：なぜ上手くいっていないのか？
原因がわかるまでは闇雲に動かず、動くとしても最小限にとどめる。
この記事の内容に関連して、セミナーを開催予定です。
下記で、内容の一部を公開しております。
ご興味がございましたら、サンプル資料1：「炎上プロジェクトでやりがちなことは何？実例から学ぶ火消し方法」からPDFをご覧ください。
いいなと思ったら応援しよう！
