プロジェクトの失敗とは

営業会議、経営報告では、主に金銭的な情報提示が求められるため、どうしてもプロジェクト活動の成功／失敗を、

　「黒字か、赤字か」

という側面でのみしか判断しようとしない企業が多いようですが、企業経営を直接的な収益だけですべてわかったような気になっていると、必ずどこかで後悔することになります。

収益をあげるのは「人」です。
ですから、「人」を取り巻く環境を踏まえたうえで、

　「適切な形で収益につなげられているのか？」

という見方をしなくては、プロジェクト活動が正しく遂行されることはありません。なぜなら「収益さえ上げれば、何したっていいんだろ？」という空気が管理職やマネージャーの心理に潜在的に刷り込まれてしまい、適切性のないマネジメントが横行してしまうからです。

たとえば、そこそこ右肩上がりの収益構造をしている企業のなかで、

　「待遇は良いはずなのに離職率が一向に下がらない」

なんて課題があるようであれば、ＱＣＤバランスの重要性を理解していない経営陣が組織を骨太にする邪魔になっている可能性があります。結果として収益につなげなければなりませんが、それしか見ない、そればかり評価対象になっているから、ラインの管理職や上昇志向の高い社員はそこばかりどうにかしようとして、部下たちを道具のように扱ってしまいます。

数字を出すことばかりで視野が狭くなると、育成ができなくなります。

なぜなら、収益というのは先にも書いたように、結果の事象でしかないからです。収益を上げる「プロセス」は幾通りも方法があって、人を潰す方法（目先の欲求のみ）もあれば、人を活かす方法（中長期的な視点）もありますし、非効率な方法（利益率が低い）もあれば、効率的な方法（利益率が高い）もあります。

収益だけしか見なければどれも実現可能で、経営者にとってみればどれでもいいということになります。

すると、経営者に認められたいラインの管理職や野心の強い社員は、「自分にとって最も楽で収益が上がる方法」を選び、「組織にとっての最適解」を模索しようとはしなくなります。

そんな最適解を模索したところで、経営者は認めようとしません。いえ、本当に見つけることができれば認めてはくれるのでしょうけど、そうしている間に他のライバルたちが部下を潰してでも収益を上げさえすれば認められていくのかと思うと「やるだけ無駄」と思ってしまうことでしょう。

一番わかりやすいたとえで

　マネジメント経験のない社員しか空いてなかったので
　とりあえずマネージャーやらせた。フォローはしてない。

といったケースがあります。意外と多いんです、こういう現場。実際に、私が見たことのある実例を紹介します。これは…たしか大手SIerのグループ企業の話だったかな？あ、もちろん今もあると思います。

私が20代後半の頃に派遣ＳＥとして経験したとある現場では、外注３社合同で取り掛かるような中～大規模プロジェクトであるにもかかわらず、プロジェクトマネージャーは元請の平社員でした。

その平社員（Ｓくん）は、上司から「このプロジェクトを成功させたら主任に昇格させてやる」と言われていました。そのせいもあってＳくんは張り切っていました。

しかし、当たり前ですけどマネジメント経験はゼロです。
その手伝いもロクにしたことがありません。

それまで何をしてきたのかはわかりませんが学歴もいいみたいだし、頭の回転が速そうではありました。でも、システム開発…しかも３社合同でサブプロジェクトが３つ平行に動いているような規模・状況を、何一つ知識も経験も無い子がコントロールできるわけがありません。

案の定、ただの伝言係のようなことしかできず、顧客との調整はままならず、毎日のように外注各社からクレームを受けていました。

資源管理もロクにしていなかったので、バージョン管理ツールも使っていませんでしたし、ただ共有サーバーに直置きするだけだったのですが、ある日ファイルサーバーのルートから間違って全削除してしまったそうです。もちろん「バックアップ？なにそれ？美味しいの？」みたいな状況だったので、３ヶ月ほどの進捗はリセットです。しかも翌週には顧客レビューが待ち構えて…。

普通なら、お客さまにお話ししてレビューの日程を再調整するところですが、Ｓくんにとっては昇進がかかった大一番です。この大事件を秘匿し、「予定通りレビューする」と。当然、私たちエンジニアは全員そこから10日ほどほぼ連徹で３ヶ月分の遅延を取り戻すことに奔走させられました。

まぁ実際には完全にリカバリできませんでしたからお客さまの心証は悪くなりましたし、その間の10日は進捗ゼロになって、より厳しい状況になったのは言うまでもありません。

もしもこのプロジェクトで多くの社員、多くのパートナーが疲弊し、何人もつぶれ、離れていったとして、それでも黒字で完遂できたとしたら、みなさんは『成功！』と手放しで喜び、このＳくんを主任に昇格させてあげますか？

これで手放しで喜んで昇進させようなんて管理職や経営者がいたら、もう会社つぶした方がいいかもしれません。世のため人のためになりませんし。

プロジェクトマネジメントの側面で考えると、「金銭的な目標達成」は評価の１要素でしかありません。

確かに赤字であれば、あらかじめ赤字であることが承認されれているプロジェクトでない限り、間違いなく"失敗プロジェクト"と呼べるでしょう。

では逆に、黒字であれば、

　ほかの要素は何がどうなっていても成功か？

と言うともちろんそんなことはありません。

・見込みよりも売上が少ない
・計画よりもコストがかかっている（利益が少ない
・納期が遅れた
・期日に間に合わせるため、仕様や機能が削られた
・利用者の評価が低い（ＣＳが低い
・納品後に不具合が発生した
・メンバーの満足度が低い
・メンバーに故障者が出た
・メンバーが耐えきれず退職してしまった
・外注離れが頻出した　　　　　　　　　　　　etc.

これらはすべて"失敗プロジェクト"です。

実際、私はこれ以降、この元請SIerの仕事は一切行っておりません。当時いた会社としても、私が在籍中には一切請けていなかったと思います。やればやるだけこちらは赤字化（価格交渉等にも応じず）し、社員はつぶされていくだけですからね。

　Q（品質）
　C（コスト）
　D（期限）

それぞれがバランスよく成功して、はじめて成功プロジェクトと呼べるのです。また、ここでいうQ（品質）とは少なくともソフトウェア開発に限って言えば

　顧客満足の度合いで測定する

ことが絶対条件です。製品品質で測定するものではありません。

ソフトウェアにも「JISマーク」が付く時代の到来——あなたの知らない「品質モデル」の基礎知識

意外と知られていないことですが、「ソフトウェア品質」のあり方については日本が主導して国際的に訴えかけているものなんですよね。正直、すべてのソフトウェア開発に対して適用できるか微妙な点もありますが、少なくとも個々のエンジニアやプロジェクトが適当に決めているモノよりははるかにまともであることはわかります。

ＱＣＤのほかに、特に目に見えなくて怖いのが従業員の不満や疲弊です（品質の中にＣＳが加わるなら、ＥＳも加えていいような気はしますが…）。お客さまの不評を被ると機会損失を誘発しかねませんが、従業員の不評を被ると生産性の低下や従業員の離職率増加などを誘発し、将来的に機会損失と同等かそれ以上の爪痕を残すことにつながります。

特に、ソフトウェア開発の現場というのは基本的に労働集約型ビジネスで成り立っています。しかもただ人がいればいいというものではなく、優秀であればあるほど、チームワークが得意であればあるほど、重宝する人材たちとなります。

彼ら企業を構成しうる資源たちを得るも失うも、すべては経営者と管理職の腕と意識次第です。

彼らを疲弊させ、失望させるような企業、マネージャーに誰がついていきたいと思うでしょうか。誰が一緒に仕事をしたいと思うでしょうか。

この従業員満足度の低下は、要するに会社に対する愛着心そのものを低下させることにつながるうえに、対策として即効性の高いものが存在しないため、実は最も注意すべき"失敗要素"の１つだったりします。何よりも回避すべき失敗要素ということです。

上手のように、プロジェクトの失敗要因には様々な点が挙げられますが、こうしたポイントについて、少なくともプロジェクトメンバーを巻き込まなくていいように、リーダーやマネージャーは責任を持って取り組むことが要求されています。

そしてなによりも、メンバーはそういうリーダーやマネージャーをこそ、待ち望んでいます（今、リーダーやマネージャーをしている人たちも、若手の頃はそうではありませんでしたか？）

ちょっと順番は食い違っていますが、以下も参考にしていただければと思います。