システム開発に失敗しないためのポイント｜事例から学ぶ対策と成功への道筋

システム開発の「失敗」とQCDの重要性

システム開発における失敗とは、QCDが遵守されていないとも言い換えることができます。QCDは、それぞれの頭文字をとって「Quality(品質)」「Cost(コスト)」「Delivery（納期）」のことを指します。

このバランスを保つことは難しく、品質が高くても誰も使わないシステムや、業務上で使う機会が少ないシステムでは、開発成功とは言えません。

複数の人が絡むプロジェクトとなると、認識のズレが生じてしまうのが、システム開発に失敗が多い理由です。この項目では、システム開発におけるズレについて紹介していきます。

求める内容に対して予算が不足している

システム開発では、どのような機能を組み込むかをあらかじめ考えて、予算を立てる必要があります。しかし、開発の途中で機能を追加したいなど、新たな要望が出たことによって、実際の費用が変動するケースもあるでしょう。

その結果、予算が足りなくなってしまい、人員や設備の投資ができず、プロジェクトが遂行できなくなることがあります。

開発途中で予算が不足する事態に陥らないためにも、システム完成までを逆算して、正確な見積もりをすることが重要となります。

完成したシステムが目的と異なっている

システム開発の目的が曖昧なまま着手してしまうと、完成したものがイメージしていたシステムと異なってしまうことがあります。

多くのケースで、システム開発案件は外部に委託して行われています。開発案件を受託した業者は要件定義を行い、開発側の目線で発注側の要望を整理し、業務フローを構築していきます。

しかし、案件情報が不十分であると、プロジェクトの途中での仕様変更が起こりやすく、最終的に完成したシステムと当初の目的とのズレが生じます。

要件定義は、システム開発のなかで課題や要望を把握するために重要な工程です。途中で大幅な変更を防ぐために、発注者と受注者とともにコミュニケーションをとることが重要です。

納期までに完成の目途が立たない

システムの開発要件の情報が不十分で、途中から機能が追加される状態が増えると、計画どおりにプロジェクトを進めることが難しく、納期が遅れる原因となります。

また、システム開発途中で技術的な問題点が見つかると、大掛かりな手直しが発生します。こうして納期が遅れてしまい、完成の目処が立たなくなってしまいます。

システム開発の失敗事例集

システム開発が失敗してしまう原因は、どういう部分にあるのでしょうか。実際に起こってしまった失敗事例を紹介していきます。

使用者の要望に振り回され迷走してしまった

システム開発要件を決める際に、現場使用者の要望に振り回されてしまうケースは少なくありません。結果として、無駄な機能が増えたり、現場が右往左往したりすることによって、納期が遅れて品質が下がってしまいます。

システム開発では、使用者の要望を聞くことも大切ですが、使用者が新規事業の全体像を把握しているとは限りません。

使用者の要望だけを重視することは、他機能との兼ね合いで必要がない機能や、役に立たないシステムが完成するなど、迷走の原因となります。

必要なコストが割り当てられなかった

システム開発での要件定義が曖昧になると、必要コストの算出が不十分なまま開発が進行するために、途中でコストが不足し、失敗に陥ることがあります。

現在エンジニアは深刻な人手不足であり、エンジニアの人件費が高額となることも考えられます。また、開発に必要なエンジニア数がコスト面から不足している場合、品質の低下や納期遅れのリスクが高まるでしょう。

そのため、発注時には可能な限り正確な見積もりを取り、十分な予算を用意しなければなりません。

技術力を持った人材が不足していた

システム開発は、毎回決まったものを作るとは限りません。システム開発要件を読み込み、技術的に実現の可否を判断できるエンジニアが必要です。

人員数こそ確保したものの、専門的な知識を持った優秀なエンジニアがいないなど、技術力の高い人手が不足していると、納得できるシステム開発は困難を極めるでしょう。

納期を厳守するために低品質なものしか作れなかった

急な仕様変更を繰り返すほか、現実的ではないタイトなスケジュールでの納期を設定するなど、時間的リソースが足りない状況に陥ると、しわ寄せがいくのがQCDのなかの「品質」です。

予算や納期は簡単に変更できるものではないため、短い納期のなか、限られた予算内で稼働できるシステムを構築した結果、低品質なシステムしか作れないといった状況に陥ってしまいます。

不必要な機能の作成に注力してしまった

曖昧なシステム開発案件を受注してしまうと、発注元の業務や実際の現場の内容まで理解できないまま、漠然とシステム開発を行うことになります。

曖昧な情報だけでは、開発側も向かうべき方向性や着地点がわからず、スムーズに開発が進まないことが多いです。実際に使用する現場の情報や要望が不透明なままでは、本当に必要かどうかわからない機能を作り込んでしまうこともあるでしょう。

市場調査・検証を行わなかった

新規事業の場合は、現場の意見がなくてもシステム要件を立案することはできます。しかし、企画者が市場調査や検証を行わず立案している場合、およそ現実的ではないシステムができてしまう場合があります。

市場調査や検証は、システム構築をするうえで重要な要素です。実際に誰を相手に検証しているのか、新規事業の本質を突いての意見なのか、十分な確認が必要です。確認のうえ、もし仮説の段階での話であれば、システム開発前に市場調査・検証を進めましょう。

要求仕様書・要件定義書が作りこまれていなかった

システム開発では、発注者の要望を盛り込んだ「要求仕様書」と、システム開発を受注する開発会社が作成する「要件定義書」があります。

この要求仕様書が作り込まれていない状態で発注してしまうと、要件定義書の作成においても、実業務でどのような機能が必要なのかわからないまま漠然と進んでしまうおそれがあるでしょう。

また、システム開発の途中で必要な機能が大きく変わった場合には、技術的に実装できるか確認が必要となり、作業に遅延が生じます。

最悪の場合、システムが完成しないまま頓挫となるケースもあるため、要求仕様書・要件定義書はしっかりと作りこむことが重要です。

システム開発の失敗を防ぐ効果的な対策

システム開発を失敗に終わらせないために、効果的な対策について紹介していきます。

プロフェッショナルへ開発を依頼する

システム開発は、開発会社によって専門性も違います。たとえ発注者と受注者でコミュニケーションが取れていたとしても、ノウハウがない開発会社であれば、十分な機能の実装は技術的に困難でしょう。

そのような事態が起こらないために、依頼先の開発企業の実績や、専門分野の経験の有無について確認しておく必要があります。

取り入れたい機能が専門的な場合は、専門性が高いプロフェッショナルにシステム開発を依頼することで、開発失敗を避けることが可能です。

リーガルチェックを受けた契約書を作成する

契約書についても確認しておきたいポイントがあります。まずは、開発するシステムの内容を明確にし、双方の認識のズレがないか確認しましょう。

また、納品時に、取り交わしどおりの完成物であるか精査するうえで、実施するテスト項目とその方法を決めておきます。

さらに、契約不適合の抵触がないか、知的財産権の帰属に関する折り合いなど、重要なポイントは多岐にわたります。

こうしたリーガルチェックを受けていないと、システム開発が失敗に終わったとしても、それに対する補償がなく終わってしまうといったケースも存在します。システム開発を失敗しないためにも、リーガルチェックを受けた契約書を作成することが大切です。

要求仕様書・要件定義書を精査する

システム開発において、どのような機能が必要であるのかを記載された書類が、要求仕様書と要件定義書です。この要求仕様書と要件定義書を作り込んでいれば、その内容を発注と受注でスマートにすり合わせていけるでしょう。

システムの設計書の役割をしている要求仕様書と要件定義書の精査によって、プロジェクトの最終的なゴールを明確化することが可能です。

また、この2つを精査することで、発注者と受注者との認識のズレを減らすことができ、失敗しないシステム開発につながります。

要求仕様書に記載すべき項目

発注者側が要求仕様書に記載すべき項目は、以下のとおりです。

• 背景・現状の課題
• システム開発の目的
• 盛り込みたい機能
• 開発体制
• 開発スケジュール

要求仕様書は、発注者の背景や現状の課題について詳しく伝える役割を担っています。これにより、開発企業がなぜシステム開発が必要になったかを知ることができ、開発途中のズレを減らすことにつながります。

課題や目的がわかると、盛り込みたい機能について、受注者も理解しやすくなります。そのなかで、必要な優先度となぜ必要なのかを記載しましょう。機能の優先順位をつけることで、開発途中で変更があったとしても、大幅なズレを減らすことができるでしょう。

納期やコスト面、開発体制やスケジュールについて把握することも重要です。これらの内容を作り込んでいると、システム開発を円滑に進めることができます。

要件定義書に記載すべき項目

受注者側が要件定義書に記載すべき項目は、以下のとおりです。

• システム要件
• 機能要件
• 非機能要件

システム要件は、概要や開発目的、開発環境、導入後の流れなどの記載をします。

機能要件とは、プロジェクトの中心となる必須機能のことです。発注者と合意形成を行い、開発プロジェクトを承認してもらうために重要なものです。

非機能要件はシステムの質のことを指し、機能要件が決まった後に決定します。操作性やセキュリティー、保守・運用に関する内容を記載するため、完成物に対する満足度を左右する重要な項目といえます。

十分なすり合わせを行う

よいシステム開発には、十分なすり合わせを行うことが重要となります。要件定義書は、システム開発のニーズや、具体的に取り入れたい機能などの要件をまとめた書類であり、話し合うほど精度は高まります。

また、発注側も受注側も想定し得なかったトラブルが発生した際には、速やかに双方が連携を取りながら、有効な対策案を練らなくてはなりません。

システム開発には何度も打ち合わせを設定し、受注者と発注者の認識を合わせながら進めていくことが重要です。

まとめ

システム開発は簡単なものではなく、さまざまなリスクが存在し、繰り返し失敗してしまうことが多いものです。システム開発を失敗に終わらせないためには、受注者と発注者が十分に打ち合わせをして、ニーズや認識をすり合わせることが必要となります。

株式会社テクノデジタルでは、正確な現状把握が可能な事業支援と、高度なノウハウを持ってビジネスをサポートしています。システム開発会社を探している場合は、テクノデジタルまでお気軽にお問い合わせください。