今やITシステムは企業活動に重要かつ不可欠な存在です。しかし、システム開発は意外と一筋縄では行きません。常にシステム投資を繰り返している大企業なら豊富な実績や人材を抱えているかも知れませんが、これまで痛い目を見てきた企業も多いでしょう。
そこで、この記事では、システム開発のありがちな失敗例を紹介して、その改善の方向性を考えます。
※この記事は、企業システム向けバックエンドクラウドサービスHexabase 向けに書いたコラムの転載です。
システム開発における失敗とは
システム開発のプロジェクト管理においては、QCDを重視する必要があると言われています。QCDとは「Quality（品質）」「Cost（コスト）」「Delivery（納期）」を意味します。
逆にいうと、品質・コスト・納期を満たせない開発プロジェクトは、失敗と見なされてもおかしくありません。
では、実際のところはどうなのでしょうか。
一般社団法人日本情報システム・ユーザー協会(JUAS)のレポート「企業IT動向調査報告書 2021」によると、システム開発プロジェクトの工期や予算の遵守状況、品質満足度は次のようになっています。
グラフ：システム開発における 工期や予算の遵守状況・品質満足度（クリックで拡大）
表：「予定通り完了」と「ある程度予定通り完了」、「満足」と「ある程度は満足」の割合を合計
| 工期の尊守状況 | 予算の尊守状況 | 品質の満足度 | |
|---|---|---|---|
| 100人月未満 | 82.5% | 90.6% | 91.5% |
| 100～500人月未満 | 66.8% | 79.1% | 86.7% |
| 500人月以上 | 49.3% | 58.9% | 74.4% |
「予定通り完了」＋「ある程度予定通り完了」、「満足」＋「ある程度は満足」の割合 は、いずれも開発規模が大きくなるほど小さくなっていますが決して悪くないレベルだと感じるのは筆者だけでしょうか。特に品質については、500人月以上の開発プロジェクトでも74.4%と多くのプロジェクトで満足しています。
でも、品質・コスト・納期を満たせるだけでシステム開発は成功と言えません。品質は悪くないけれど、業務に合致しないシステムや誰も使わないシステムは役に立ちません。せっかくコストと人手をかけてシステム開発をおこなっても、これでは成功と言えないでしょう。
では、どうしてシステム開発において、品質・コスト・納期を満たせなかったり、役に立たないシステムができてしまうのでしょうか。
そこで、どこかで聞いたような情景をまとめてみました。もちろん、すべての失敗プロジェクトがこんな具合という訳ではありませんが、どこか腑に落ちるところもあるのではないでしょうか。
失敗01. 現場が、アレが欲しいコレが欲しいと言うだけ
どのようなシステムを作るのか、実際に使う人の意見を聞くことは重要です。どんな場面でどんな作業をしているのか現在の様子を把握しなければ、そこで使われるシステムは開発できません。
しかし、実際に使っている人が全体像を把握しているとは限りません。自分が知っている範囲のことしか説明できませんし、人によって内容が違っていることもよくあります。
ありがたいことに「こういう機能があれば、きっと便利になる」と斬新なアイデアを提案してくれる人もいます。ですが、他の機能との兼ね合いで不要なこともありますし、本当に役に立つか試してみないと分からない場合もあります。実際に作ってみたら、まったく役に立たないこともしばしばです。
こういう人に限って、自分のアイデアに固執することがあります。声の大きな人が自分の想いにこだわると面倒なことになります。
これを機会に、本来の開発範囲外の機能をねじ込もうと暗躍されると、開発プロジェクトは迷走します。
失敗02. IT部門が、要件をまとめられない
続いて要求を整理して「要件定義」を行います。システム化の目的はなにか。そのシステムでどのような機能や性能を実現するか。主に利用者側の視点から過不足なくまとめます。個々の機能についても、実際の業務プロセスや役割をもとにしてあるべき姿を定義します。
そして、こうして定義した要件を「要件定義書」というドキュメントにまとめます。言語化しなければ、何を依頼したのか分からなくなってしまうからです。
でも、IT部門やシステム開発コンサルタントが要件を十分に定義できていないと、精度の低い要件定義書ができあがります。機能や業務プロセスに漏れやだぶりがあっても、それがそのままシステムに反映されてしまいます。
何よりむずかしいのは、できあがった要件を、実際に使う現場の人たちに合意をしてもらうことです。
とはいえ、システムが実際にできていない段階で、どんなシステムになるのか業務がどのように変化するのか、ドキュメントだけで想像してもらうのは簡単ではありません。自分のアイデアに固執している人に、それをシステムに盛り込まないことを納得してもらうのも容易ではありません。
失敗03. 経営者が、やれと言うだけで調整しない
現場とIT部門のあいだで調整が付かない場合、経営者がリーダーシップを発揮する必要があります。
業務効率やお客様への提供価値が向上するなら「どんどんやれ！」と言ってくれるでしょう。でも、それによって現場の抵抗があるとき、経営者は「それでもやれ、現場が変われ」と言ってくれるでしょうか？
あるいは、現場の要求を実現するには、予算の増加や開発期間の延長が必要になる場合、経営者はそれ承認してくれるでしょうか？
もちろんお金も時間も人的リソースも無限にはないので限度はあります。システム開発にどれだけのコストと時間がかかるのか不明なのはビジネス的にもリスクになります。
そこをジャッジするのは経営者の重要な役割なはずです。
失敗04. 新規事業企画で、市場検証せずにシステム開発を始める
新規事業企画の場合は、現場の意見を聞かなくても要件定義できます。でもそれが企画者の仮説・願望・妄想をもとにしていると、実際に作っても役に立たないことがよくあります。
「頭のなかでは、もう要件は整理できています！」という企画者がいても、それがただの仮説なのか実際に市場検証をした企画なのかで、作る物の精度は大きく違ってきます。
「市場検証も済んでいます！」という場合も、実際に誰を相手に検証したのか、その検証内容が新規事業の本質を突いたものなのか、確認したほうがいいでしょう。
まだ仮説の段階であれば、システム開発をはじめる前にやることがあるはずです。ごく小さな規模で手売りでもいいので本当に買い手があらわれるか実験するのが有効でしょう。
失敗05. 要件定義があいまいなまま、開発会社にマル投げする
結局あいまいな要件定義のままシステム開発がスタートするとどうなるでしょうか。
ウォータフォール型開発では、この要件定義書を元にシステムを開発します。IT部門は、十分に調整できていない要件定義書をシステム開発会社にマル投げします。
システム開発を依頼する側にしてみれば、プロに任せればあいまいな要件定義書でも立派なシステムを開発してくれるに違いない、と期待してのことでしょう。だって、プロフェッショナルですから。オーダーメードで背広を仕立てれば身体にピッタリで欠点の目立たないスーツができあがります。高い寿司屋で「お任せで」と言えば、とびきり美味しいものが食べられます。システム開発会社に任せておけば、きっと使いやすくて現場も経営者も納得するシステムを実現してくれるに違いありません。
そして、ユーザー部門との調整もマル投げしてきて、現場が納得できる夢のような機能を限られた予算と納期のなかで実現しろとせまるのです！場合によっては、現場や担当者の思い付きを後から追加してくることもあります。
失敗06. 必要な機能か見極められず、無駄な機能を作り込む
要件定義書を受け取ってシステム開発案件を受注したシステム開発企業は、そこからシステム要件定義をおこないます。利用者側の視点から整理された要件定義書をシステムの視点で整理し直すのです。利用者視点の要件定義書があいまいな場合、そこからやり直して新たな機能追加してシステム要件定義までおこなうよう迫られることもあります。
でも、システム開発企業は、開発依頼元の現場や業務について、あまり分かっていません。
もともと曖昧な要件定義書やあとから機能が追加されるような状況では、システム開発プロジェクトを計画通りに進めるのは簡単ではありません。現場や責任者・新規事業きかくしゃを納得させようと、本当に必要かどうか分からない無駄な機能を作り込んでしまうことも少なくありません。
失敗07. 開発スケジュールが間に合わず、開発者が疲弊する
こうして開発スケジュールが遅れ始めます。品質を作り込む工数が取れなくなり、状況を把握していない無駄な人員が投入されます。
曖昧な要件定義書から技術的な問題点が見つかると、大きな手戻りが発生して、これがさらに開発スケジュールを遅延させます。
失敗08. 開発プロジェクトの人手不足
要件定義があいまいで機能の見積りが甘いと、当初のスケジュール見積りも甘くなり、それが人手不足につながります。採用市場においてエンジニア不足が続いているため、最初から必要な人員が揃えられないこともあるでしょう。
失敗09. 開発スケジュールを厳守するため、品質にしわ寄せ
こうしたプレッシャーからしわ寄せが行くのは、「Quality（品質）」「Cost（コスト）」「Delivery（納期）」のうちの品質です。予算も納期も、簡単には変えてもらえないからです。その結果、手っ取り早く硬直的なプログラミングをおこない、とりあえず動くものを完成させようとします。
失敗10. 技術力不足
とはいえ、こうした組織力だけが失敗の要因ではないでしょう。
システム開発は、毎回同じようなものを作るとは限りません。エンジニアの役割は、むずかしい課題をテクノロジーを活用して解決することです。新しく登場したテクノロジーが、これまで難しかった問題をエレガントに解決することもあります。
でも、課題が必ず解決できる訳ではないでしょう。技術的にむずかしい問題というものも存在しているのです。
こういう場合、システム開発の失敗は「技術力不足」「優秀なエンジニアの不足」が原因と言えるでしょう。
失敗要因を分析する
ここまで、システム開発で失敗する様子を少し詳しく説明してきました。これをまとめると次のような流れになります。
これは誰かが悪い訳ではありません。本当に難しいのは、最初から正しい完成形を描き出すこと。それを理解しないまま、皆がそれぞれの役割に沿って最善を尽くした結果、部分最適の集合体ができあがるのだと思います。
システム開発は失敗してもいい
では、システム開発で失敗を避けるにはどうすればいいのでしょうか。
システム開発で要件を高い精度でまとめることは簡単ではありませんが、まずは全員が全体を良くしようと一体になることは不可欠です。
そのうえで、実のところ失敗には、良い失敗と悪い失敗があると思います。
良い失敗とは、そこから学習して少しずつでも改善につながる失敗です。
悪い失敗とは、そこから何も学習せず、ただ状況が悪くなる失敗です。
だから、失敗しないシステム開発を目指すのではなく、失敗から学習するシステム開発を目指すのです。
そのためにアジャイル型開発の考え方が重要になります。いきなり大きな成果を目指さず、素早く小さく作って、実際のユーザーに使ってもらって市場検証するプロセスを繰り返すのです。ここで、ついつい実際のユーザーに使ってもらって検証するところを忘れがちになりますが、そうするとミニ・ウォーターフォールになってしまいます。
まとめ. ユーザーが本当に本当に欲しかったもの
システム開発の難しさについて、次の図を見たことがある人も多いでしょう。「顧客が本当に必要だったもの」という有名な図です。システム開発において要望を伝える難しさをあらわしています。
ちなみに、この図の源流はEarly Tree Swing Cartoons – BusinessBalls.comで確認できます。
この図の右下に「顧客が本当に必要だった物」がありますが、左上にあるように顧客自身も自分が欲しいものを説明できていないところが、こうしたコミュニケーションの難しさだと思います。
でも、本当に伝えるべきだったのは次の図ような「顧客が本当に本当にやりたかったこと」つまり体験や課題だったのだと思います。
木からぶら下げたタイヤのブランコであれば、それをただ作ろうとするのではなく、この図のようにそこで遊ぶ人たちの姿を伝えるのです。だとすれば、本当に作るべきだったのはタイヤのブランコでなくてもよかったはずです。ロープだけでもいいし、木に登りやすくするハシゴでもいいのです。そういう意味では「運用された実装」を15分で提供できるなら第1歩としては悪くないと思います。
何を作りたいかではなく、「どんな課題にフォーカスしてどんな体験を実現したいか」、それを共有することでシステム開発の失敗は大いに改善できるのではないでしょうか。