見出し画像

失敗プロジェクト

hiro

　



初めて転職した企業Yでの体験談


　私は企業Yに転職してすぐ請負いの仕事に携わりました。

請負いは以下のような関係です。
顧客　<=>　企業YのプロジェクトZ（顧客から発注された成果物を作成して顧客に納品。以下、このプロジェクトをZと呼びます）

顧客：企業Yに対して、要求、入力の提供。企業Yが納める納品物の評価（クライテリアの明確化）
企業Y：要求、入力に基づいて納品物を作成し、顧客に納品

　プロジェクトZは、プロジェクト責任者のIさん（部長、マネジメントはPMに権限移譲）、PMのAさん、エンジニアBさん、そしてエンジニアの私の4人で構成される小規模なプロジェクトでした。プロジェクトZは、前任のPMが転職で退職したため、私たち（Aさん、Bさんと私に）引き継がれました。

　プロジェクト責任者のIさんは、プロジェクトZの立ち上げから関与し、顧客の要求も把握していました。ただし、退職した前任者にPMのAさんに十分な引継ぎの指示をしていませんでした。
　PMのAさんは、前任者から引継ぎをうけておらず、プロジェクトZの状況を知りませんでした。彼は他のプロジェクトのPMも兼務していました。マネージャというよりシステム設計の専門家でした。彼はプロジェクトに必要な技術にも精通していました。Aさんは別のプロジェクトにも時間を割かなければならず、PMの仕事に十分な時間を割くことができませんでした。ケアレスミスが多く、お客様へのメールやプレゼン資料に誤字脱字が何度か見られました。
　Bさんはソフトウェアのエンジニアで、このプロジェクトZに必要な知識は持っていませんでしたが、ソフトウェア・アーキテクチャと開発プロセスについて詳しい人でした。たとえば、入力がないと出力が作成できないと頑な考えを持っていました。顧客からの要求と入力情報が不足しているため、仕事が進まないとよく愚痴っていました。Bさんは顧客から入力を得るように何度もPMのAさんに頼んでいました。
　私はハードウェアのエンジニアで、その当時、プロセスについてほとんど知識がありませんでした。PMの仕事についても理解が不足していました。

　PMのAさんが作成したWBS（Work Breakdown Structure）は大まかで、そのWBSに基づいたスケジュールで1ヶ月開発を進めたところ、納品物の作成が進まず、納期通り納品が行えるのか全く見通せませんでした。顧客からは、納期までに納品物が本当に完成するのかどうか問い詰められました。その結果、WBSを再作成する必要が生じました。
　Aさんは顧客の詰問にのため開き直って、プロジェクトZのPMの仕事を私とBさんに押し付けました。例えば、WBSをBさんと私に作成するように依頼しました。Bさんは自身は担当であり、PMではないと主張し、さらに顧客からの入力が得られないため（初めて行う仕事のため、何をすべきかわからなかった）、これまでのやり方で仕事を進めようとしましたが、顧客との関係がうまくいきませんでした。結果として、Bさんと私が作成したWBSはPMのAさんが作成したものとほとんど変わらなかったため、顧客から非難を受けました。
　その後、プロジェクトZの責任者のIさんからは、WBSと納品物、入力を関連づけて記述するよう指示がありました。具体的には、入力がいつまでに提供されないと、納品物が納期までに作成できないことが明確にわかるようなスケジュールを立てるように言われました。指示通りにWBSとスケジュール表を変更して開発を進めたものの、最終的には顧客から十分な入力が得られませんでした。顧客も納品物のクライテリアをよく理解していないようで、プロジェクトZ側に対してほしい入力を要求してほしいというばかりです。その一方で、プロジェクトZ側も納品物が、どのようなものかを顧客に提示していませんでした。

　Bさんが作成した納品物は顧客の要求を満たせませんでした。結局、納品はしたものの、Bさんは納品月の月末に退職しました。私は入力不足で作成できない一部を除き、顧客の要求通りの物を作成し納品することができました。
　このプロジェクトは破綻していました。顧客とプロジェクトZの間で、何をどの程度作成するのか合意が取れていなかったからです。

　プロジェクトZの落としどころは複雑でした。顧客は、Bさんが作成した納品物は要求を満たしていないものの納品物を受け取り契約書にある金額の支払いました。ただし＋アルファの仕事をすることになりました。
　Bさんはすでに退職しており成果物を作り直すことが難しい。そのため、納品後は、私が関係する不足分の納品と、さらにハードウェアに関連する仕事を1か月追加で行い、追加納品物を作成し納品しました。
　顧客がBさんの仕事に関する入力情報を提供してこなかった、さらにBさんが、顧客に必要な入力情報の提供を要求できなかったことも原因です。
　プロジェクトZは１人月分を＋したため予算に対して赤字でした。ただ、この顧客からは単発ながらその後も仕事を頂きました。

プロジェクトZに関係するステークホルダーの問題点

　請負いプロジェクトの成功は、下請けはもちろんのこと顧客（発注側に）にも責任があります。お互いが責務を明確にして責任を果たすことが必要です。以下、ステークホルダーが抱える問題点を記載します。


 プロジェクト責任者 ：Iさん

  1. 不十分な引継ぎ: 前任のPMから、PMのAさんに適切な引継ぎを実施していませんでした（引継ぎ指示とその引き継ぎ内容の確認）。

  2. プロジェクトの監視不足: プロジェクトZの進捗状況や問題点に対する適切な監視を行っておらず、問題がエスカレートする前に適切な対応ができませんでした。

PM ：Aさん

  1. 多重業務: Aさんは他のプロジェクトのPMも兼務しており、時間的な制約がありました。これがプロジェクトの適切な管理や問題の解決を妨げました。

  2. プロジェクト責任者への報告遅延: 顧客の要求に基づきWBSを再作成するとき、プロジェクト責任者のIさんにに問題点を報告せず、プロジェクト内で解決しようとしました。その結果、再作成したWBSも顧客から非難されて初めてプロジェクト責任者が動きました。

  3. 適切な指示不足: チームに対して十分な指導や指示が行わず、各メンバーがどのような役割を果たすべきかを明確にして納得がいくまで説得しませんでした。

エンジニア ：Bさん

  1. 要求事項の不足: 顧客からの要求事項が不足しており、必要な情報が得られなかったため、適切な作業が行えませんでした。

  2. コミュニケーションの不足: Bさんは顧客からの情報を得るために積極的にコミュニケーションを取ろうとせず、問題が解決されないまま不完全な納品物を作成しました。

エンジニア ：私

  1. 入力情報に関する要求不足: 顧客提示入力情報の受け取り時期が遅れ、納品物が一部作成できませんでした。

  2. WBSの問題: Ｂさんと私で作成したWBSは不十分で曖昧さがあり、プロジェクトが円滑に進行しませんでした。

顧客：

  1. 要求事項の不明確さ: 顧客はY社のプロジェクトZに適切な要求と入力を提供できませんでした。これがプロジェクトZの方向性を不確かにしました。

  2. 入力情報の提供の遅延: 必要な情報がプロジェクトZのチームに提供されなかったり、入力情報をプロジェクトZに提供するのが遅れ、作業が適切に進行しませんでした。これがプロジェクトZのスケジュール遅延と納品物の品質に問題を引き起こしました。

  3. コミュニケーション不足: 顧客とプロジェクトチームとのコミュニケーションが不十分で、要求事項と成果物とそのクライテリアに関する明確な対話が不足していました。これが誤解や期待値の不一致を生む原因でした。

  4. 問題の適切な報告: 顧客は問題が発生したときにそれをY社（プロジェクト責任者のI）に適切に報告し、プロジェクトZのPMのAさんに対応を要求する機会を逃しました。これが問題の早期解決を妨げました。






この記事が気に入ったらサポートをしてみませんか？