システム開発の失敗はいつ起きるのか?パターンを知ってリスクを最小限にしよう

パソコン

更新日:2017年09月20日 | 公開日:2016年09月09日

プロジェクトが途中で頓挫してしまう「製品製造の失敗」はなぜ起きるか

登山をする男性

最初にシステム構築以外の「登山」の例から話を始めましょう。

ある山を麓から見上げて「この山にはこう登ろう」とプランを立てたとします。
必要な予算やスケジュールを洗い出し、それに必要な道具を集めチームを結成して山に登り始めます。
しかし、最初想定していた道具では対処できなかったり、チームの力量不足で途中から起きた天候不良に対処できなかった、というケースがありえます。

これがすなわちシステム開発における「製品製造の失敗」です。

山登りの話の内容と、実際の現場の物事は次のように対応します。

1. 登山計画書 = 仕様書
2. 登山予算、スケジュール = システム開発予算、スケジュール
3. 必要な道具 = サーバや各種ネットワーク機器など
4. 登山チーム = 開発チーム

登山もシステム開発における失敗も、出てくる言葉を一言でいうと、たいていのプロジェクトで「計画が甘かった」という反省の言葉が出てきます。

システム開発における「計画」とは、ウォーターフォール型の開発方法の場合には、最初に集中します。

1. システム企画
2. 要件定義
3. 概要設計
4. 詳細設計
5. プログラミング
6. 単体テスト
7. 結合テスト
8. 運用テスト
9. 運用保守

という流れにおける最初の「システム企画」「要件定義」「概要設計」「詳細設計」がしっかりしていれば「計画が甘かった」という反省の言葉は出てきません。

そして「詳細設計」は開発側が開発詳細について計画をたてる部分ですが、それ以外の「システム企画」「要件定義」「概要設計」については、「どんなシステムを作りたいのか」という部分を計画するので、クライアントが自分自身のやりたいことをしっかりと伝える主役なのです。

この部分がしっかり伝わっていない状態、たとえば、想定ユーザー数1日1万アクセスとしていたのに、途中から「やっぱりもっと欲を出して1日50万アクセスでいきたい」というような要求が出てくるような状態は、いわば「当初は冬山登山をするつもりはなかったけど、やっぱりそれもやってみたいので、下山せずに雪山を楽しみたい」とリクエストするようなものと言えます。

これでは、プロジェクトが途中で頓挫してしまう「製品製造の失敗」が起きるのも当然でしょう。
「製品製造の失敗」というと、もっぱら開発側の責任というイメージを持ちがちですが、最初の「システム企画」「要件定義」「概要設計」については、「どんなシステムを作りたいのか」という部分を計画するので、クライアントが自分自身のやりたいことをしっかりと伝える主役だということを肝に銘じてプロジェクトをスタートさせることが大切です。

「製品として認められない」という失敗はなぜ起きるか

鍵とキーボード

再び山登りの例で説明します。

これは、ゴールを目指して山登りをして頂上まで登頂が完了したけど、ついてみたらそこは目指していた山ではなく、目的の山は自分たちの登った山の向こう側にそびえていた…という状態です。
「この山は登りたい山ではなかった」という信じられない状態なわけですが、システム構築においてこうした悲劇は大なり小なり起こるのが実際です。

この失敗には3つの失敗のきっかけがあります。

1. 発注側が自分自身のやりたいことをしっかりと伝えることに失敗していた
2. 開発側がは中側のやりたいことを聞き損なっていた
3. 製品を投入すべき市場環境が変わってしまった

最初の2つについては、これは先ほどみた「プロジェクトが途中で頓挫してしまう製品製造の失敗はなぜ起きるか」と似ています。
頓挫してもおかしくなかったのに、頓挫せずになんとか山頂まで登れた、しかし結局登った山は違っていた、という最悪のケースです。

しかし、この悲劇は先ほど解説したように「システム企画」「要件定義」「概要設計」については、「どんなシステムを作りたいのか」という部分を計画するので、クライアントが自分自身のやりたいことをしっかりと伝える主役だということを肝に銘じてプロジェクトをスタートさせることで、かなりの部分防ぐことが可能です。

問題は3つ目の製品を投入すべき市場環境が変わってしまったということが、最近のシステム開発では十分に起こりえるということです。

再び山登りの例でいえば、最初に登山口を間違って登り始めてしまい、山頂に到着して初めて「どうも違うらしい」ということはありえても、途中で目的の山がすり替わってしまうことはありえません。
しかしシステム開発においては、「当初は単純な顧客管理データベース構築」がゴールだったのに「やっぱりマーケティングオートメーション機能がないと今後使えないのではないか…」というようなことはありえます。

もちろん、すでにマーケティングオートメーションという概念が十分よく知られており、将来的に自社にとってもそうした仕組みが必須になることがある程度想定できているのにそれをしなかった、という場合には結局「計画が甘かった」という事になるわけですが、マーケティングオートメーションを例にすればこの仕組みはここ数年で一気に認知されてきた「顧客育成方法」です。

2015年に「マーケティングオートメーション元年」と言われて、わずか1年で主要な海外プロダクトのほとんどが日本にも上陸し、国産ベンダーも次々と登場して大手企業などのマーケティングオートメーション採用もぞくぞくと決定しました。

この状況を最初に完全に予見するのは難しいという面があるのは事実です。
つまり、最初目指していた山では「登ってもしょうがない」という状態が、変化の激しい昨今のシステム開発の現場では起こりえます。

こうした失敗を防ぐためには、できる限り最初の計画を慎重にするとともに、スピードも重視して、開発手法をウォーターフォール型ではなく、アジャイル型などの変化に適応しやすい方法にするなどの工夫が必要です。

【まとめ】

以上、登山を例にしながらシステム開発の失敗の本質を2パターンに分けて考察しました。

ウォーターフォール型では「事前の計画」をきちんとすることが失敗を回避するための唯一の方法です。
そして、市場環境の変化をある程度想定しながら、まだその具体的な変化が見えていない…という場合にはアジャイル型などの開発で対応してくれる会社を探すことも大切になってきます。

日本最大級の発注業者比較サイト『アイミツ』では、複雑・多様化するシステム構築に関する専門知識を持ったコンシェルジュが、信頼のおける会社を完全無料で紹介することができます。

すぐれたコンシェルジュが、あなたの会社に合った企業選びを全力でお手伝いさせていただきます。
まずはお気軽にお問い合わせください。

いま知りたいこと
コンシェルジュが解決します!

コンシェルジュサービスは
3万社以上が利用している無料の相談サービスです。

コンシェルジュ

発注は時間も手間もかかりますよね?

コンシェルジュが解決します!

コンシェルジュに相談、あなたにあった業者を提案、発注の手間を削減!

完全無料

まずはお気軽にご相談ください