システム開発失敗の原因と対策を、主に発注者側の視点で検証する

弊社では様々な業界、業種のお客様のWebサイト・ホームページシステム・アプリ開発を請け負っています。システム開発においてはプロジェクトが失敗するリスクは常にあり、世の中はシステム開発の失敗であふれています。

弊社には実はWebサイト・システム開発がうまくいっていないので何とかしてくれないか、というお仕事のご相談を良く頂きますが、システム開発の半分くらいは作り直しやフルリニューアルのご相談です。

今回私達が経験、見聞きしている範囲でシステム開発の失敗事例と、その対策についてまとめてみました。Webサイト・ホームページシステム開発がうまくいくかどうか心配だ、今既に上手くいっていない、というシステム開発ご担当者様は是非ご一読下さい。

システム開発における失敗とは？状態＝原因

システム開発の失敗の原因と対策を語る上で、まずそもそも「失敗」とは何か？ということを定義したいと思います。弊社ではシステム開発における失敗は以下の三つのいずれか、あるいは全てに当てはまる事だと定義しています。

1　納期が守られない

2　品質が低い

3　コストが超過する

この三つは実は「失敗の状態の定義」であると共に「失敗の原因」でもあります。そしてこの三つは実は相互に深く関連しています。そしてこの三つのいずれか、又は全てが極限まで失敗すると、

• Z会が日立ソリューションズに勝訴したが認められた金額は請求額の約半分に。 | システム開発失敗.com

のように、普段我々が見るような表沙汰のニュースになったり、裁判になったりする訳です。それではシステム開発を失敗しないためにはどうしたらいいのかを、順番に考察していきましょう。

システム開発失敗の原因と対策

1　納期が守られない

当然ですがプロジェクトはスタート時点でまず予定を策定します。しかし、その予定、納期が守られない事は良く起こります。なぜそのような事が起こるのでしょう。これには以下の事が理由として上げられます。

（1）そもそも最初から予定に無理があった

（2）上流部の要件定義・設計に想定外に時間がかかり、実装の予定がタイトになってしまった。

（1）については「そもそもなんでそんな予定を引いたんだ」という事になるのですが、経営目標が最初にありきでリリース日が前提として決まってしまっているケースは少なくありません。この場合は上層部が意図的・又は意図せず現場と調整していない事によって起こります。

（2）についても実にありがちで、体感的に半分以上はこれに起因しています。当初はそれなりに現実的な予定を引いていたものの、何をどう作るべきかという仕様検討をしているうちに当初想定の2倍、3倍と検討に期間を使ってしまい、なのに納期は変更出来ず、結果実装開発の時間が圧縮されてしまう、という状態です。

「圧縮」と言っても本当にその短くなった期間で実装をやれればいいですが、たいていの場合はやれません。せいぜいテスト期間を短縮する位です。

発注段階でシステム開発会社が「やれます」と言っても、それは単に受注側の弱い立場で出来ると言っている場合があります。常識的に引いて見て、こんなの無理だよね、と発注者の貴方が思ったことは大体あってます。

社内事情でリリース日を動かせないと言っても、間に合わない事実も動かせまん。無理をすればテストが甘くなるので、必ずひずみが起こり後で大炎上するリスクは極めて高いです。もはや間に合わないという現実を冷徹に見つめて、受け入れて(責任はまた別のお話です）現実的なリリース日に引きなすことが急がば回れな現実的な解決策です。

また差分リリース、というのも現実的な選択肢になり得ます。既にフライヤーを印刷している等の場合は、サイトを見に来てNot Foundではシャレになりませんので、場合によってはランディングページを一枚作って「間もなくオープン！」とやるのも現実解でしょう。システム開発会社に提案して欲しいと打診をして下さい。

2　品質が低い

そもそも品質とは何でしょう。システム開発における品質とは。そうであって欲しい機能性、操作性がきちんと開発できたかどうかです。なので当然ですが「こんなん使いにくくてしょうがないよ」「やりたい事が出来ない」「バグが多い」という事であれば当然それは失敗という事になります。

またこの手の問題は下流工程（実装開発やテストフェーズ）にいけばいくほど修正コストが乗数的に膨れ上がります。つまり要件定義・設計フェーズでいかに問題の目を潰せるかが決定的に重要になりますし、下流工程ほど結果的に無駄な手戻りが発生します。どうしてこのような問題が起こるのでしょうか。これには以下の事が起因しています。

（1）頼んだ開発会社をそもそも間違えた。

（2）開発会社との意思疎通に問題がある。

（3）姿勢に気をつける。

（4）仕様書をそもそもよく読んでいない。

「（1）頼んだ開発会社をそもそも間違えた」というのは意外に思われる方もいらっしゃるかも知れませんが、実はこれ意外と少なくありません。

例えばそもそもホームページ制作会社がすべからくシステム開発が出来るとは限りません。むしろホームページ制作会社はデザイナーやディレクターはいますが、プログラマーがいないことが多く、規模の小さい会社ほどほとんどプログラマーはいません。

つまりデザインは分かるが、ホームページを動かすシステムやサーバにはめっきり弱い、というのは実に良くある事なのです。

ただ発注企業側から見るとわかりにくいかも知れません。入り口で間違えると戦う前から負け戦確定ですので、まず前提として依頼する相手を間違えないようにしましょう。

「（2）開発会社との意思疎通に問題がある」というのはそのとおりでシステム開発会社は提供された情報を元に仕様や工数を想定します。「ここまで言わなくても分かるよね」という事がシステム開発会社にはほとんど通じません。

これを解決するためにはシステム開発会社ととにかく意思疎通、コミュニケーションを密にするにつきます。ちょっとでも気になったことはバンバン相手に投げかけて確認をする事が重要です。

通常システム開発は一般的にはウォーターフォール方式にて進められる事がほとんどです。そこで上流の要件定義、設計フェーズで詰めが甘い事が品質が不十分になる原因です。

「そもそもどうしてその機能が必要なのか」「その機能の実現方法は適切か」というところの検証が不十分な事によって品質低下は起こります。勿論いざ開発をしてみたら、気づいてない課題があった、ということはしばしば起こります。しかし、ほとんどの問題は「もう少しちゃんと詰めていたら事前に分かっていたよね」という事がかなりあります。

「（3）姿勢に気をつける」。これはどういう事かと言いますと発注企業側の開発姿勢、本気度というのは実は相手に結構伝わります。適当に片手間にやってると、実はそれもうっすらと開発会社にも伝わりますし、そうすると開発会社の姿勢も甘くなりがちです。発注主として覚悟を持って、ガチで詰めてくると、「あ、このお客様本気だな」という事が肌感覚として伝わってきますし「これは気が抜けないぞ」と身構えます。

「ビジネスなんだから発注主の姿勢に関係なくちゃんとするのが当たり前だろ！」というお話はその通りなのですが、実際にこういうことは（開発会社が言わないだけで）良くあることなのです。なので良いシステムを開発するためには、発注主である貴方の「気迫」も結構大事な要素だということは覚えておいて下さい。時々するどい質問をして開発会社をビビらせることも重要です。

「（4）仕様書をそもそもよく読んでいない」ですが、これはどういう事か言うと、ITとかシステムなど難しいことはよく分からない、と言って開発会社に丸投げしてしまい、開発会社が出してきた概要ご提案書や仕様書をよく読んでいないということは良くあり、大体において失敗するシステム開発事例の場合、ほとんどの発注企業がこれに該当しています。とにかく目をよく通し、少しでも分からない事があれば、ガンガン質問しましょう。こちらはお金を払う側なのです。初歩的な内容だろうが遠慮する必要は一切ありません。そんな分かりにくい資料を作ってきた開発会社が悪いのです。気にせず質問しまくってください。それで嫌がられるようであれば、最初からそんな開発会社に発注してはいけませんし、それが分かってむしろ好都合です。

3　コストが超過する

当初100万円、1千万でお願いしていたのに、途中で追加費用を開発会社から要求された。これも良くあることです。当然のことながら当初予定していた予算を超過してしまうと、それは失敗という事になります。どうしてこのような事が起こるのでしょうか。この原因が主に以下に起因しています。

（1）そもそも開発会社の工数積算が甘かった
（2）開発会社に値切りすぎた

（1）については基本システム開発会社は作るべきシステムの機能を元に工数を積算し、それに単価を掛けて金額を算出します。その想定している機能の詳細が甘いほど、工数は後で上振れします。

こうならないためには自分達が作りたいシステムの機能をよく開発会社に伝える事が極めて大切になってきます。開発会社の能力が低ければどうしようもない部分は確かにあるのですが、意思疎通を徹底する事が重要です。

（2）についてですが、システム開発会社が上げてきた見積もりを「値切る」発注企業はしばしばいらっしゃるかと思います。

当然ですがどこの企業もプロジェクトに投資できる予算には限りがあり、その中で出来るだけ良いシステムを低コストで開発したいと考えるのは当然の心理ですので「値切る」という行為自体が必ずしも「悪」ではないかと思います。

しかし、過剰な値切りは事後の追加費用の要請の確率が爆上がりします。当然の事ながら値切られた開発会社は内部で｢何か」を削減してつじつまを合わせようとします。それが開発の後半になって「そこまでは仕様とては想定していませんのでそれは別途ご発注になります」と言われてしまう原因になってしまいます。

それはシステム開発会社が勝手な言い分でしょ？というのはその通りです。しかし結局のところシステム開発のプロジェクトというのは同じ船に乗っている同じ船員と同じなのです。船が沈めが結局両方とも溺死します。

なので、過剰な値切りは仕様のブレに対するバッファが著しくない状態となり、仕様のブレに対する調整余力がほとんど無い状態となります。これを防ぐには「基本値切らない」事が重要です。むしろ値切るのでは無く、その予算で出来る最大限の事を開発会社に開発してもらう事が極めて重要になってきます。これなら強気でものが言えます。値切っていると、どうしても開発会社のエクスキューズを許すことになります。

どうしても予算が足りないため値切りたい、という事であれば、仕様として何を諦めるのか、という事をシステム開発会社と事前に明確にしておく必要があります。ここをきちんと握っておく事によって、後で「なんでこの機能が無いんだ。仕様外だろ」「そもそも仕様の範囲ではありません」という問題を避ける事が出来ます。

最後にーシステム開発プロジェクトを成功に導くために

今回はシステム開発の失敗の定義、そしてその原因と対処法についてまとめました。システム開発の失敗は大なり小なりどのプロジェクトでも発生します。理想は100％問題無くリリース出来る事ですが、現実的な問題として、100％要望を完璧に満たしたシステム開発というのはありません。しかし、80％、95％の成功というのは普通にあることです。その前提に経ってシステム開発プロジェクトを進めて行くことが大事になって来ます。

そのためにはやはりパートナーであるシステム開発会社の先行を間違えないこと、これまで取り上げた問題を一つ一つ丁寧に潰していくことです。スタジオジブリの宮崎駿監督も「大事な事って大抵面倒臭いんだよ」「面倒臭い自分との戦いなんだ」と言っています。地道に対処していきましょう。