なぜITプロジェクトとは失敗するのか?

 おそらくこの命題は、ずっと多くのIT関連雑誌などで語られてきたことでしょう。
 それは、簡単です。失敗したほうが開発ベンダーが儲かるからです。
 以前にも「現在の人×月で計算するITプロジェクトの費用はSIベンダーにとって
効率よく早くプロジェクトを完遂させれば損をしてしまう。
 逆になるべくダラダラと人を増やしながら対応するのが一番儲かる」と、お話しました。
 この異常な価値観。「質が良いほど評価されない」問題点はそのまま「お客様」の不利益につながっていきます。


 「顧客のため」を心から歌う信頼できるSEが貴方の担当だったとしましょう。
 しかし、究極的に彼らの献身に報いるためには、ITプロジェクトは失敗ぎりぎりの
線で十分な追加コストを稼がさせてあげるのが最善でしょう。
 顧客の納得の上で、期間と費用を積み増し、利益を確保したSEは会社から褒められ、
場合によっては昇進し、貴方に心から感謝するでしょう。
 勿論、このSEが悪いわけでもありません。貴方が悪いわけでもありません。
 仕組みが間違っているのです。
 逆に、貴方のためとして、社内でも最適のリソースを集めて予定の半分の工期で
終わらせて、その分の請求をしてきたSEは確実に社内での営業評価を下げることになってしまいます。「せっかくお客が用意してくれた予算の半分だけ持って帰るとはどういうことだ?顧客満足度は最高?自社の幹部満足度は最低だぞ!!」と怒鳴られることになるでしょう。
 本来早く効率よく仕上げれば、顧客のシステムの利用開始が早まり、効率化は早く
訪れて、バランスシートに良い影響を与えるでしょう。
 あるいは、多めに確保できたテスト期間は大きく貴方のビジネスのITリスクを低減させるでしょう。
 にも関わらず「早く良い物を仕上げたら損をする」のです。
 例えば弊社は、質のよいリソースによって「20%以上」他社より効率よくシステムを構築する自信があります。本当は2倍とか言いたいのですが、現実的に20%を語りましょう。 しかし、我々はその力を発揮してしまっては、かえって売り上げを20%下げてしまうのです。少ない人数で早くできたのですから。当然人月は下がり、支払われる金額という意味の評価は低下するでしょう。
 あるいは、早く終わればただ単に「見積もりが間違っていましたね」という形になってしまいます。
 そこで、弊社はこの「仕組み」を何とかして変えたいと思っています。
 我々が他社より早く品質の良いものを提供した場合に、何ヶ月も早く納品に漕ぎ着けた場合には、貴方の得た、ビジネスメリットを我々にも享受させてください。
 もしその仕組みが可能なら、SIベンダーは御客様と利益享受の方向性が一致し、本心からプロジェクトを効率よく、確実に進めようとするでしょう。
 「プロジェクトの成功」の定義は需要側と共有側で一致し、おそらくこの業界に強い「新しい良い風」を吹かせることになるでしょう。
 ゴールが互いに真逆にあるのに、二人三脚でプロジェクトを進めていくのは無理があります。御客様自身のためにもこの「ゴールの一致」を目指させてください。
 そういう勇気ある契約を結べる顧客を弊社は探しています(笑)
 多分、貴方にも我々にも最善のプロジェクトになると思います。
 アジャイル宣言の中で「我々を信頼してください」とあります。が、アジャイルも多くの場合、フェーズ単位で人月契約することにより、ビジネス的なリスクは結局顧客に押し付けている場面を良く見ます。開発側もリスクをとることにより「早くいいものを作ることで双方が利益を得る」道を探るべきです。
 例えば、6ヶ月のプロジェクトがあったとしましょう。このシステムの機能を満たすための見積もりはきちんと開発側が責任を持って行います。しかも、その見積もりはあくまで、一般的な効率水準で構いません。
 そして、納期までに予定より早く仕上がれば、開発側は、早く仕上がった分、多めに報酬を受け取ります。逆に遅れれば顧客のビジネスチャンスを減らしていくわけですから報酬も減っていきます。なんと、工数が伸びたのに金額は減っていくのです。
 無論、このリスクに耐えられる開発ベンダーは、そう多くはありません。しかし、我々のように、その自信をもつベンダーも沢山いるのです。
 少なくとも、今の方法ではITプロジェクトは失敗しつづけるでしょう。「元々向いている方向」が違うのですから。

オープントーンリクルート 奨学金代理返済制度