システム開発の目的を開発のスタート前からゴールまで常に意識しよう【2024年最新版】

システム開発の役割は、ITを活用して日々の社内業務や顧客向けのサービスを提供することにあります。
既存システムのリプレイスなどを別とすれば、ほとんどの開発プロジェクトは、発注者（発注側）の頭のなかにある、目に見えない仕組みを具体化していく過程となります。

この目に見えない仕組みを具体化していく過程では、さまざまな問題が浮上してくることが知られていますが、特にシステム開発の指標であるQCD（クオリティ、コスト、デリバリー）が達成できなくなる「品質の低下」「工数の増大による追加コスト」「納期の遅れ」は開発プロジェクトが成功するか失敗するかの分かれ道ともなる黄色信号です。

こうした黄色信号を無視すれば、やがては赤信号に至ります。
しかし「品質の低下」「工数の増大による追加コスト」「納期の遅れ」については、明確で効果の高い対処方法があります。
それは、開発プロジェクトの「目的」を再認識し、「目的」に照らし合わせて、「品質」「コスト」「納期」を最適化することです。

この記事では、システム開発のスタート前からゴールまで常にプロジェクトの「目的」を意識することによって、システム開発を成功に導くノウハウを整理します。

プロジェクト開発で常に目的を意識することのメリットを確認する前に、目的を忘れることがいかに高くつくか、そのデメリットについて確認しておきましょう。
目的を忘れることによって、発注者と開発会社が裁判で争うなどということも起こり得るのです。

（東京地方裁判所 平成22年12月28日判決より）

発注側は、基幹システムの構築を開発会社に依頼したが、最終的に満足の行く納品物が提出されなかったため、発注側が原告となって裁判で争うことになった。

1. 販売・購買業務の効率アップ
2. CRM基盤づくり
3. 経営マネジメント層が会社のすべての業務が正確に見えるようになる「見える経営」を実現する

発注側は、上記3点をシステム開発の目的として契約を締結したが、でき上がってきた納品物では「システム導入の目的実現が不可能」と判断し、債務不履行又は瑕疵担保責任を根拠として約1,800万円の損害賠償を請求。

本プロジェクトの目的は「業務の効率アップ」「CRMの基盤づくり」「見える経営を行う」など抽象的なものであり、目標値も「顧客との接点を増やす」「事務職の労力を内部統制・営業支援に振り分ける」「売上予想がより正確にできる」「過度な売上値引きを抑制する」など抽象的なものにとどまっている。
したがって、システム開発会社がその達成を請け負うことができる性質のものではない。

判決では、発注側は開発会社に対して法的な責任を求めることはできないというのが結論ですが、ここで注目すべきは、その根拠の部分です。
裁判所は、抽象的な目的や目標をいくら契約書に明記したとしても、そうした抽象的な目的や目標では、納品物が満たすべき要件を定義したことにはならない、よって、債務不履行あるいは瑕疵担保責任は発生しない、ということを述べています。

つまり、目的や目標が曖昧であれば、発注側からすると完成品として認められないような納品物があがってくることがあるし、そうした納品物に対して法的な責任を問うこともできないということです。

せっかく契約書を作っても、目的が曖昧では、契約自体が意味をなしていないというわけです。

今見てきたようにシステム開発において目的が曖昧だと、裁判で争うことにもなり、加えて開発者側の責任も問えないという最悪の事態を招きかねないということが分かりました。
それではなぜ、このような目的が曖昧なままプロジェクトがスタートしてしまったのでしょうか。
それは、プロジェクトの要件定義の曖昧さに原因があります。

先程の、裁判所に責任が問えないと判断された曖昧で抽象的な目的をもう一度見てみましょう。

1. 販売・購買業務の効率アップ
2. CRM基盤づくり
3. 経営マネジメント層が会社のすべての業務が正確に見えるようになる「見える経営」を実現する

システム開発の「目的」についてきちんと考えたことがない場合には、目的としてこのような記述をしてしまうことが、多々あります。
本来システム構築で言う「目的」とは、そもそもなぜその開発投資を行うことになったのか、その課題について一文でズバッと答えたものです。

例えば、上記の例で言えばこうなります。

1. 販売・購買業務の効率アップ
⇒ 現在手作業で1案件2営業日かかっている受発注業務の非効率性を、受発注システムの導入によって即日対応できるようにする

2. CRM基盤づくり
⇒ 顧客満足度の向上のために現在未整備の顧客データベースを構築し、最初のソリューションとしてWebから訪問してくれる見込み客をナーチャリングするシステムを導入する

3. 経営マネジメント層が会社のすべての業務が正確に見えるようになる「見える経営」を実現する
⇒ 現在経営マネジメント層が紙ベースのドキュメントで確認している営業データを、オンライン上にて各種レポートとして閲覧できるようにする

このように、現状の解決の方向性を示し、その具体的な方法にも言及しておけば、目的が曖昧であることを根拠に、開発会社に責任が問えないということはなくなります。

要件定義の段階で目的をここまで具体的にすることで、プロジェクトの方向性や、何かトラブルになりそうなときに参照すべきガイドラインとして目的は機能してきます。
逆に言えば、単に曖昧で抽象的な言葉を並べただけでは、プロジェクトが開始された途端に「目的」は忘れ去られ、納品物がその要件を満たしているかどうかの判定基準にもならず、契約そのものが意味をなさないと裁判所に判断されてしまうことになるでしょう。

システム開発で「目的」をきちんと意識しておかないと生じてしまうネガティブな面について確認しましたので、今度は常に「目的」を意識することでどんなポジティブな面があるかについて整理します。

システム開発が実際にスタートしたあとも、開発現場では常に品質の高い製品を仕上げる努力が求められます。

例えば先程の裁判例のケースでも、下記のように常に当初の目的を意識しながら検証することで、より望ましい品質を達成するための方針が確認できます。

また、機能的な品質を確保する上では下記のような指標が用いられますが、これらの品質評価指標についても、プロジェクトの目的に沿って具体的にその指標が達成できているかどうかを検証することで、品質の向上を図ることが可能です。
単に、「理解可能性」「完全性」「簡潔性」といった言葉を開発の現場で振り回しても何の意味もないのですが、プロジェクトの目的と照らし合わせることで、品質指標の達成度合いが見えてきます。

■ 理解可能性（Understandability）
■ 完全性（Completeness）
■ 簡潔性（Conciseness）
■ 移植性（Portability）
■ 保守性（Maintainability）
■ 試験性（Testability）
■ ユーザビリティ（Usability）
■ 信頼性（Reliability）
■ 構造化の度合い（Structuredness）
■ 効率性（Efficiency）
■ セキュリティ（Security）

システム開発プロジェクトの見積もり手法には大きく分けて「類推」「係数モデル」「ボトムアップ」の３種類がありますが、いずれも必要な工数を洗い出してそれを見積金額に反映させます。
つまり、無駄な工数を省き、目的に沿った過不足のない工数を算出することこそが、適正な価格を決定するわけです。

大は小を兼ねる的な発想では、目的から外れた無駄な機能が多くなり、使い勝手（品質）は悪くなり、見積もり（コスト）も無駄に上昇してしまいます。
また、安い金額で仕上げてもらおうという意識ばかりが先行すると、今度は必要な機能が実装されていない意味のないシステムができ上がってしまいます。

こうした無駄な機能、必要な機能はプロジェクトの目的ごとにまったく異なってきます。

例えば、同じ「CRM基盤づくり」であったとしても、「とにかく営業マンが自分の担当している顧客データを自分のノートパソコンのエクセルで管理していて、情報共有がまったく進んでいない状況を解消したい」という場合には、高度なCRMのマーケティング分析の仕組みは必須ではないと判断できるでしょう。

逆に、先程挙げた例のように「顧客満足度の向上のために現在未整備の顧客データベースを構築し、最初のソリューションとしてWebから訪問してくれる見込み客をナーチャリングするシステムを導入する」ことが目的の場合には、見込み客を半自動で育てていくためのマーケティングオートメーションツール的な機能の実現が必須になるので、必要な工数（コスト）も増加します。

納期が遅れる原因というのは、開発の現場でプログラマの生産性が落ちるといったことではありません。
プログラマの生産性そのものは、システム開発会社がプログラマの能力をきちんとランク付けして、１人月いくらというコスト管理を行っていますので、発注者があまり意識する必要もありません。

システム開発プロジェクトにおいて納期がずれ込む理由は、「要件仕様の決定の遅れ」「要件分析作業不十分でやり直し」「提出されていたRFPの内容が理解しにくい、矛盾がたくさんある」「追加仕様の増大で開発規模が膨れ上がる」など、発注者も関係のある主に上流工程部分のプロジェクトマネジメントにあることが大半です。

上流工程部分で目的が曖昧で抽象的なままプロジェクトを前に進めてしまうと、いわゆる「手戻り・手直し・手待ち」の開発ロスが発生します。
手戻りとは、せっかく先に進めた工程に不備があって、前の工程に戻らないといけないことを指します。
手直しとは、手戻りよりはまだマシですが、工程内でのやり直し作業を指します。
手待ちというのは、詳細の要件が決まらないので、エンジニアが遊んでいる状態です。

こうした状態は、常にプロジェクトの「目的」を意識し確認することで、基本的に防ぐことができます。

これまで見てきたとおり、本来システム開発のプロジェクトマネジメントとは狭い意味での開発現場の進捗管理だけを指すものではありません。
プロジェクトが正しい方向を向いているかどうかを常に「目的」に照らし合わせて、システムのQCDの高レベルな達成を実現していくことが重要です。
QCDの達成がプロジェクト管理の基本となっている場合には、関係者にとって下記のような価値をもたらしてくれます。

最後に、システム開発を外注した際にかかる費用相場をご紹介します。

システム開発の費用相場をご紹介しました。より正確な費用を知りたい方は料金シミュレーターをご利用ください。

以上、システム開発のスタート前からゴールまで常にプロジェクトの「目的」を意識することによってもたらされるさまざまなメリットについて整理しました。
また併せて、「目的」が忘れられてしまったプロジェクトでどんなネガティブなことが起きるかについても解説しましたが、この記事で例に出した「品質の低下」「工数の増大による追加コスト」「納期の遅れ」などは、システム開発においては決して珍しい話ではありません。
さすがに訴訟問題が常態化しているようなシステム会社は少ないとは言え、QCDの達成に失敗しているプロジェクトはたくさんあります。

その原因の１つは、この記事で取り上げた訴訟例のように、発注側でプロジェクトの目的を曖昧かつ抽象的なまま、要件定義工程を通過させてしまって気が付かないでいるということにあります。

また、もう１つの大きな原因としては、本来、訴訟事例のような要求定義ではきちんとした開発設計図もかけないはずなのに、そのままコーディングなどの作業に移行してしまう開発会社のいいかげんさがあります。

つまり、システム開発において、目的を明確化してプロジェクトのQCDを高めることの大切さを認識した発注者がやるべきことは、実際の開発前から、開発、開発終了後の運用保守の段階まで、常にプロジェクトの「目的」をしっかりと認識している信頼のおける開発会社をパートナーとして選ぶことです。

残念ながらすべての開発会社が、そうした認識を持っているわけではありません。
そうした評価の部分は、システム開発会社のホームページやパンフレットからはなかなか読み取れないものです。
パートナー選びでお困りのときは、ぜひ「アイミツ」にお声をおかけください。
システム開発会社の事情に精通した「アイミツ」に相談していただければ、システム開発における「目的」の大切さを理解した優良会社をご紹介いたします。