残念ながら、受託開発という言葉を聞くと、『うまくいかないリスクが高い』、『担当者が大変』、などあまり良くないイメージも多いと思います。現実としてはそうだと思います、いわゆる炎上してしまうようなプロジェクト少なくないと思います。ではなぜ、炎上してしまうプロジェクトが多いのでしょうか？

プロジェクトメンバーの目標設定の違い

一般的に、ご担当者から、受託開発会社に、お問い合わせや相談をするところ、プロジェクトがスタートします。プロジェクトのご担当者は、初期システム開発の完成を最終目的として考えているでしょうか。ご担当者が考えているのは、システムを初期構築した後、達成したい売上や利益、会員登録数など、を考えているはずです。ただし、受託開発会社は、初期システム開発の完了をゴールと設定することが多いのです。それは、納品した対価としてお金をいただける、場合によってはその後の保守は発生しない、という収益構造を考えると仕方がないことなのかもしれません。

初期開発だけで完成ではありません。

新規WEBサービスを立ち上げる時、初期システム開発時点で100％のシステムをつくれることはありません。 WEBサービスはユーザーに利用してもらって初めて使いやすいかどうかがわかると思います。いま世の中で多く使われているWEBサービスも初期リリース時はいまとは全く違った形だったと思います。サービスを運用する中で、ユーザーからのフィードバックを継続的にサイトに反映させてきた結果、いまのサイトが存在しています。
ですので、ユーザーに利用してもらわない段階で、サイトをリリースする前の段階で、100％のものがつくれるはずがありません。WEBサービスを成功させるためには、無理をして100％のシステムを初期でつくるのではなく、可能な限り早くプロトタイプとなるサービスをリリースし、できるだけ早い段階で、多くのユーザーに利用してもらい、そのフィードバックをもとに、システム改善を継続的に行っていくことが、ベストだと考えています。ユーザーからのフィードバックを即座にシステム改善に反映していく仕組みが必要スピーディーにシステム改善を継続的に行っていく上で、多くの場合、開発スピードがネックになることが多いです。ですから、そこが極力ネックにならないように、可能な限りスピード感をもって、開発を進められる体制を組むことが重要です。
現在であれば、
・Ruby on rails　や　CakePHPのような高速開発が可能となるフレームワークを用いる
・GitHubを利用して、ソースコード管理を効率化
・Slack、Hipchatなど、プロジェクト間のコミュニケーションを効率化
などにより、徹底的にスピードを重視した開発を行っていきます。ユーザーに使ってもらわなければ、100％システムに近づけていくことはできません。机上の空論で正解を出すのではなく、まずはリリースして、素早く改善していくことが重要だと考えます。

開発途中で要件は変わるもの。

初期開発と保守を合わせて考えることが重要

ウォーターフォール型の受託開発の場合、ご担当者と開発会社にて要件定義を行って、ドキュメントを作成し、要件をFIXしていきます。しかし、いくら議論して、精緻にドキュメントを作成しても、開発を進める中で、仕様は変更になってしまうものです。それをすべて初期開発フェーズで対応しようとすると、スケジュール的にも厳しくなり、開発会社側も疲弊し、ご担当者もイライラが募る、、、という悪循環に入っていってしまいます。同じゴールを共有していたとしても、すべて初期開発に盛り込もうとすると、厳しいプロジェクトになってしまうことが多いです。要件が変更・追加になる際は、まず目的・目標を整理し、初期開発フェーズにて対応すべきかどうかを両者にて検討、必要に応じて、他の機能を保守フェーズにまわしたり、議論の上、柔軟な対応をしていくことが理想だと考えています。そのためにも、事業の成功は何なのか、ということを全メンバーが理解することが改めて重要だと考えています。

多くの場合、ご担当者はシステムやサーバーなど、細かい技術の内容等に関しては、明るくないことが多いです。それは当たり前のこと。だからこそ、プロジェクトがうまくいくためには、ご担当者が考える、こういう事業を展開したい、こういう収益を生み出したい、ユーザーにこういうサービスを提供したい、という想いをプロジェクトメンバーがまず理解し、それを技術的にどう実現していくのがベストなのか、という問いに対して、全員でアプローチしていくという方針をとらないといけません。しかし、多くの場合は、ご担当者の想いを理解しないままに、プロジェクトがスタートしてしまいます。新規WEBサービスのスタート地点である、受託開発がうまくいかない理由のほとんどは、上記のようなゴール設定の違いからくる、コミュニケーションのずれにあると考えています。システム開発・納品をゴールにして、提案・作業を行う人たちと、事業の成功を考えて取り組む人たちでは、おなじプロジェクトにいながら、見ているゴールが微妙にずれてしまいます。そのゴールのずれが、コミュニケーションのずれやアウトプットのずれなどに繋がってしまい、結果として、むだな作業が増え、むだなコミュニケーションが増え、お互いの作業工数が膨れ上がってしまい、疲弊感漂うプロジェクトになってしまう可能性が高いのです。