納期まで、あと１か月なのに、潰しても潰してもバグが湧いてくる・・・、「この要件も、取り込んでくれないと困るよ」と、平然と追加仕様をタダで押し込んでくるユーザー・・・、よくある話です。
この記事はシステム開発が失敗する理由についての経験談です。プロジェクトマネージャー（以下、プロマネ）を目指している方の参考になれば幸いです。
システム開発が失敗する理由
ユーザーが大変
システム開発って、実は開発ベンダーが頑張るだけでは成功しないんです。ユーザー側の多大な協力があって初めて成功への道筋が見えてきます。
よくある失敗パターンとして、要件・要望が、後からころころ変わるケースがあります。仕様変更多発！ってやつです。
システム開発は、建築の仕事に似ています。例えば、家を建てることを想像してみて下さい。３LDKで間取りを決めました。基礎工事終わりました。そして一階部分を建てている時に、突然、「ごめん。やっぱこの間取り止めるわ。こっちに変えて。」って言われても、「もう半分、作っちゃったし」ってなりますよね。
システム開発も同じで、設計終わりました。製造完了しました。さあテストするぞって時に、「やっぱこっちに変えて」と言われると、それまでにやった作業は全て一からやり直しになります。でも、これってよくある話です。
さらに、「じゃあやり直しになるので、費用と納期を見直して頂けますか」とお願いすると、「（ごにょごにょ）の理由で、それはできん！！」とか言われたりすることも、これまたよくあります。。。( ´:ω:` )
この種の仕様変更は、複数ユーザーの意見集約に失敗して後から考慮漏れが分かったという、ユーザー取り纏め者の能力に起因するケースだけでなく、法律が変わったとかの外部要因で業務フローが変更になるといった止むを得ないケースもあるので、一概にユーザーが全て悪いとは限らないのですが。
プロマネのコミュニケーション能力（コミュ力）が低い
この記事はプロマネの卵の方向けに書いているので、これは自業自得の理由となりますが、コミュ力が低いうちはプロマネを目指さない方がよいです。ここでいうコミュ力とは、ユーザーと交渉する能力、開発メンバーにリーダーシップを発揮する能力のことを言っています。
「ユーザーと交渉する能力」とは、要件定義を円滑に進める能力だけではありません。ユーザーはシステム開発については素人ですので、「そんなのできるか！」と叫びたくなる異次元な要求をしてくることもありますし、そもそもシステム開発をどう進めるかも知りません。
プロとして、ユーザーの要求を可能な限り叶えるスタンスは大事ですが、プロマネは、できないことはできないとはっきり伝える胆力、落としどころを探る交渉力、開発プロセスの要所でユーザー主導となる作業（要件整理・仕様確認、ユーザー受入テスト、移行に向けた準備・社内調整）を支援するマネジメント能力が必要となります。
開発対象の難易度が高く、メンバーの総戦闘力では力不足
業務要件、必要技術、開発規模などの総合的な難易度が、開発メンバーの能力では力不足で、開発が失敗することもしばしばあります。例えば、新技術を採用したが、想定外トラブルが起きて原因究明に時間がかかったといったケースや、若手メンバーばかりでバグだらけのプログラムができてしまい、テスト工程で品質劣化が顕在化したといったケースなどです。
システム開発の成功率を上げるにはどうするか
上述したリスクを潰しこんでいけば、システム開発の成功率が上がります。例えば、以下の対策を取ります。
ユーザー対応
まず、ユーザーの人となりをよく見極めましょう。ユーザーは、取り纏めの立場で開発ベンダーの窓口担当者となっている人と、実際のシステム利用者（エンドユーザー）に分かれます。ここでいうユーザーは取り纏めの立場の方です。
開発成功の鍵は、この取り纏めの方に懸かっています。この人がエンドユーザーの意見集約をちゃんとやれそうか（コミュ力が高い優秀な人）かを、最初１，２回の打ち合わせの段階で見極めます。
（あっ、この人、やばそう）と思ってしまったら、開発側でできること（「仕様変更したら、費用と納期は守れませんからね」とちゃんと説明して議事録作成しておくとか、仕様提示などユーザー側ですべき作業のスケジュール期限をしっかり伝えるとか）を可能な範囲で行ないます。その後、問題が顕在化したタイミングで、上司に相談して、会社同士で交渉できる状態に持っていきましょう。最悪、法的な訴訟になる覚悟も必要です。
もちろん、開発側でやれることはやって丸く収めるよう尽力はすべきですが、取り纏めユーザーがヤバい人だと、どうにもならないことも多いので覚悟はしておきましょう。例えば、エンドユーザーが多い場合は発注先の会社内の関係部署間の意見調整が必要ですが、こういった仕事は開発ベンダー側では手が出しづらい領域です。また、ヤバすぎる取り纏めユーザーになると、うまくいっていない理由を「こいつらのせいです」と、開発ベンダーに全責任を押し付けてくるパターンもあります。当事者以外は真相なんてわかりませんからね。
ユーザー体制については、こちらにまとめていますので、参考にして下さい。
プロマネのコミュ力
これは言いにくいのですが、まず、自分のコミュ力に自信がないのであれば、プロマネをするのは止めましょう。ただし、ある程度であれば後天的に習得できるスキルですので、優秀なプロマネの動きをよく見るなどしてスキルアップすることはできます。
開発メンバーに対してのコミュニケーションですが、忙しくなると、自然と無意識のうちに冷たい態度をとってしまうこともあるとは思うのですが、人間って誰しも「もっと自分を知ってほしい生き物」なんだと思うんですよね。できるだけ、一人一人のSEとマンツーマンで話す時間をとって、不満・ストレス度合いを細目にチェックできる心遣いが大事な気がします。
コミュニケーションについては、こちらにもまとめていますので、参考にして下さい。
開発メンバーの要員調達
PMBOKでいうところの人的資源マネジメント(Human Resource Management)の領域ですね。
採用する開発技術が決まっているなら、そこに強い人材を投入するのはもちろんですが、優秀な人材は希少ですし費用も高いので、どうしても半人前の若手をそこそこ参画させることになります。となると、技術力がそれほどなくても、若手の面倒を見てくれる中堅SEの存在も大きいです。
私は開発の成功条件の一つとして「開発メンバー同士の仲がよいこと」が挙げられると思います。チャットなどのツール利用でも構わないのですが、気軽に話しかけられる状況がないと、仕様の細かいところの確認とか再鑑とかうまくいかないですよね。従って、初対面のSEをたくさん投入せず、ある程度は、過去の開発プロジェクトで組んだことのあるSE同士を参画させる方が成功率は上がります。
まとめ
システム開発の失敗原因とその対策についてまとめましたが、一番大事なのは、臨機応変な「プロマネの対応力」だと思います。プロマネが優秀だったら、成功確率はかなり上がりますし、ユーザーがアカン人だったとしてもうまく交渉して無難に着地させることもできるはずなので。
