プロジェクトが失敗する理由
まずは自己紹介
私は経営者ではありますが、現場のプレイヤーでもあります。
職種はキャリア20年のITエンジニアです。プログラマでもあり、SEでもありアーキテクトでもあります。能力的にはフルスタックエンジニアというやつだと思います。 200人月程度であればPMも担当していました。
プレイング経営者として会社のために何でもやっていたので20年経つと全職種出来るようになりました。
自分のジョブタイトルや呼ばれ方にはこだわっていないため人に尋ねられたら現場ファーストの意味を込めて「プログラマです」と言っています。
20年のキャリアの中で特にこだわっているのが受託開発です。
プロジェクトによっては成功もあればもちろん失敗もありました。
せっかく経験したことですので、 今回はシステム開発プロジェクトの成功/失敗について書こうかと思います。
成功と失敗の定義
書くと言っておきならが成功/失敗を意識すると成功/失敗の定義が難しいと思いました。
他人がなんと言おうと、自分たちで成功と思えば成功だし、失敗と思えば失敗になります。
成功/失敗の考え方は当事者の主観によって変わるということです。
また、立場によっても変わりますし、開発対象や開発フェーズによっても考え方が変わります。
よって今回は「開発会社」の立場に立って次の条件のもと話を進めていこうと思います。
[ クライアント ]
民間企業
[ 契約形態 ]
契約形態は請負契約（成果物作成業務委託契約）
[ 構築対象 ]
業務システム
[ 開発フェーズ ]
初期開発
発注側だったり、自社サービスを自社で開発している方は、適宜自分で立場を入れ替え、 そして成功か失敗の条件は各自思い描いてお読みください。
失敗の原因
肝心な失敗の原因ですが「システム要件と成果物が異なる」に尽きると思います。
では、なぜこのような事が起きるのか、それが最も重要な要素かと思います。
まずは大まかに以下に分類出来ると思います。
営業的原因
技術的原因
マネージメント的原因
１つひとつ見ていきます。
[ 営業的原因 ]
わかりやすい例がパッケージ販売（ソリューション販売）でしょうか。
要件に合わないのにパッケージ（カスタム込）を契約してしまうパターンです。
実際、プレゼンや契約交渉を行っているクライアント側の担当者と開発側の営業では、
予算を抑えるため業務をシステム側に合わせる必要がある
変更できない業務については機能カスタマイズはできるが費用とお金が必要
ということは話していると思います。
では、なぜ問題になるくらいのミスマッチがおきるのか。
それは、交渉時に合意した内容がクライアント側の現場まで落ちていないのが原因です。
現場とは、実際にシステムを利用する一般従業員です。
結局、現場は「使いやすいさ」しか評価しないため安易に「使えない」と言いがちなのが現実です。
したがって営業的原因とは、
このように営業フェーズで理解・合意した内容が現場に伝わっていない事
になります。
[ 技術的原因 ]
要件が明確になり理解もした。しかし、難易度が高すぎてそれが実装できないという状態です。
もう少し具体的に解説すると、技術的難易度を理解できずに見積もりを失敗しており工程が進んだ後に始めて気づくというパターンです。
例えば、検索エンジンが良い例でしょうか。
検索とは、 鮮度 / 速度 / 正確性 が求められます。
現代人はGoogleに慣れすぎているため、暗黙的に世界最高の検索エンジンが当たり前になっていますが相当難易度は高い分野です。
誤字脱字を吸収する「ゆらぎ」や「入力予測」、文章を単語に分解する形態素解析、検索するためのインデクシング等、多くの高難易度技術が組み合わさって検索エンジンは出来ています。
検索エンジンを見積もるためには検索エンジンに必要な技術要素をすべて知っている必要があります。
言い換えると、検索エンジンに必要な技術要素を知らなければ見積もる事ができず、見積もり失敗の原因になります。
ジャンルは違いますが「車」と同じでしょうか。車を見ても誰も驚きませんが、車を製造するための見積もりを行おうとすると途端に難しくなるのは想像しやすいと思います。
でも仕事のプレッシャーから「見積もれません」とは言えないため、予算に合わせた曖昧な見積りをしてしまうもの現実だったりします。
したがって技術的原因とは、
具体的に実装するイメージがないまま曖昧な見積もりを行う事
になります。
[ マネージメント的原因 ]
民間の開発案件には納期、予算に余裕があるということはほぼ100%あり得ないでしょう。
契約前の概算見積り、要件定義後の詳細見積りを行っても予算、納期オーバーは日本中どこでも見る光景です。
機能の取捨選択だったり、フェージングを行うことで予算に関しては条件に近づけることは出来きると思いますが、スケジュールに関してはオーバーしていることが多かったりします。
そうすると実際開発することのないクライアントや開発側のPM、PL層のメンバーは、スケジュールを縮めるために
増員して並行開発
テスト工程を縮める
クライアント側のメンバーも作業を手伝う
というような場当たり的な願望ともいえる発想で無理やりスケジュールを縮めることを行います。
しかし、実際は
予定通りメンバーを集めることが出来ない
テスト工程が短すぎてバグが収束しない
クライアント側の手伝いは役に立たない
というのが現実だったりします。
したがってマネージメント的原因とは、
上層部が具体的なアクションも想定せず願望だけで計画を立てる事
になります。
プロジェクトの成功確率を上げるためにはどうすればよいか
プロジェクトが失敗する原因は上記以外にももちろん存在しますが、
私が見たり経験した請負開発における失敗原因は概ね上記の３つに分類できます。
上記の原因は発生するタイミングや登場人物は違えど、根本的に共通しているものがあります。
それは、
臭いものには蓋をする
です。
言い換えると、
「伝えるべき内容を具体的に伝えていない」
です。
見栄や隠蔽、気まずいなどの気持ちが先行し、雰囲気で事を進めている現場が多いです。
上記の問題も、
人員整理するから協力してほしい
予算が無いから不都合があるけど我慢してほしい
実装できるイメージが沸かない
都合よく工程を縮めることはできない
短期間で優秀な人材の獲得は現実的に無理
貴社が片手間で手伝っても役に立たない
というような事をはっきりと然るべき関係者に報告すれば被害を最小限に抑えられます。
組織人の会話でよく聞くのが
○○さんに△△とは言えないよなぁ
俺（私）が責任を取るから大丈夫だ
というお決まりのセリフがありますよね。
まさにこれが失敗の原因のマインドになります。
このセリフ、無責任なのは皆さんお気づきでしょうか？
経営的に見ると以下になります。
(1) ○○さんに△△とは言えないよなぁ
正確には、
✓これを報告したら自分が悪者になるじゃん、無理
✓いずれ知ることになるから自分が発言しなくても良いよな
ではないでしょうか？
本当に相手のためや組織、プロジェクトのためを思うならイチ早くデメリットを把握し事態の収束をしたほうが損失を小さく抑えられます。
「恥ずかしい」や「保身」の気持ちの価値は、会社が負う損害額にくれべればチリみたいなものです。
自分の恥ずかしいという気持ちに値段をつければわかりやすいと思います。
(2) 俺（私）が責任を取るから大丈夫だ
取締役以上が発言しているなら本当に責任を取る可能性はありますが、
従業員が発言している場合、確実に嘘かカッコつけです。
なぜなら、従業員は責任を取れないからです。
何をどうやって責任をとるのでしょう。
降格や減給したって、収入の10%以上減給すること法律で禁止されているため、
減給額 > 損害額
になることはおそらくならないでしょう。
退職してもその人は再就職するので責任をとるのではなく、逃げているだけです。本当に責任を取るのであれば、事態を収束させかかった損害を補填することです。
それができるのか考えてみれば責任を取れるかわかると思います。
では、結局何をすればよいか？
それは、 臭いものに蓋をしたくなったら、
「その気持を金額換算した金額」 と 「損害額」を比較
してみてください。
自分の気持が数百万円、数千万円の価値があるということを周りのメンバーが同意してくれれば言いにくいことは言わなくて良いと思います。
もしそうでなければちょっと我慢して言いにくいことでも発言したほうが価値のある行動になります。
価値のある行動をするほうが必ず評価されます。
価値ある人には必ずお金は付いてきます。
自分の言動の価値というものを考えるだけでも面白いので一度やってみてはいかがでしょうか？
それでは。