「システムに欠陥が多すぎて使えない！」
「開発や保守・運用費用が高すぎる！」
「なぜか社員が協力してくれない……」
「経営者がシステムのことを全然わかってない……」
ホームページ、ＥＣサイト、Ｗｅｂマーケティングシステム、ＡＩ、ビッグデータ、ＩＯＴなど、ＩＴシステムが企業の経営を左右する時代。にもかかわらず、ほんの数年前まで、日本のＩＴシステム開発は3分の2が失敗しており、今もなお、システム開発は他のプロジェクトと比べると成功率の低いのが現状です。
そこで、かつてない「発注者のための入門書」として、発売即連続重版が決まった『システムを「外注」するときに読む本』。本連載では、そのエッセンスを公開。70以上のトラブルプロジェクトを解決に導き、紛争解決率9割を超えた「トラブル解決請負人」が、システム開発プロセスに潜む「地雷」を紹介しながら、成功のポイントを伝えます。
どうすれば、会社が幸せになる「本当に役に立つシステム」が作れるのか？
経営者・ＣＩＯ・システム担当者・プロジェクトマネージャーの必須知識！
「気合い」を見せてくれるのはいいのだが……。
発注者側の人事異動やベンダー側のメンバーの病気など、一見すると、それぞれが内部で解決すべき問題のように見えても、それはプロジェクト全体のリスクです。
最終的には、発注者内部、ベンダー内部で解決すべき問題であったとしても、最低限、お互いがリスクの存在を知って、その解決策に納得してプロジェクトを進める必要があります。
私は現在、どちらかというと発注者側に近い立場で、いくつかのシステム開発プロジェクトに参加しています。そのときは必ず、ベンダー側の方に、「自社内のリスクもできる限り開示してほしい」と頼んでいます。
つい先日も、ベンダー側が「主要メンバーが病気で1週間ほど休むので、スケジュールが遅れる危険がある」というリスクを教えてくれました。加えて、このベンダーは、「でも、この程度の遅れなら、休日出勤と残業でカバーできます！」と「気合い」を見せてくれました。
しかし、客観的にみれば、そのメンバーが本当に1週間で復帰するかなどわかりませんし、復帰したとしても、病み上がりの人がこれまで通りの生産性で仕事ができるかもわかりません。そもそも、そんな人に長時間残業を強いるような解決策は、現実的でないと言えます。
「気合いで何とかします！」という言葉を真に受けてはいけない
そのため、私はベンダーに対して「いや、それよりも、新たにメンバーを追加していただき、新しいメンバーの能力に応じたスケジュールを組み直してください」とお願いしました。
また、「必要であれば、新しいメンバーに対する発注者側の業務に関する教育を、こちらが行ないます」とも申し添えました。
なんだか、発注者が損をしているように見えるかもしれません。しかし、もし発注者側の人間が何かの理由で離脱するようなことがあれば、今度はベンダーにあれこれとお願いをしなければなりません。お互い様なのです。
もし、あまりに発注者側の負担が大きくなるようなら、後で費用の減額を申し入れることになりますし、逆にベンダー側の負担が増えるようなら、追加見積もりが必要になります。
『システムを「外注」するときに読む本』で、私がもっとも伝えたかったことの１つである「プロジェクトに入ったら、立場を超えて1つのチームとして協力しあうもの」というのは、そういうことです。
「それは、おたくの問題でしょ」と突き放してしまっては、プロジェクトの成功率を下げることにつながってしまうのです。
