システム開発の代表的方式のメリット・デメリットを徹底比較！【2024年最新版】

システム開発を発注する場合、開発会社がどんな開発方法を採用するのかについて事前にチェックしておくことは大切です。

餅は餅屋と言うように、何事においても、それぞれの専門家に任せるのが一番、開発のことは開発会社に任せればよいのだ、という考え方もあります。

組織的なシステム開発のノウハウが確立され始めた1960年代には、今日ほど市場の変化も速くなく、汎用機で一度作ったシステムは何十年も使うことが前提とされていました。
確かにそうした時代には、最初に簡単な打ち合わせをして、あとは専門家に任せておけば納品時にチェックするだけ、というスタイルでも開発プロジェクトを成功させることができました。

しかし、現在のシステム開発を巡る環境は当時とはまったく違います。
１年間かけてシステム開発が完了したけれど、完成した頃にはすっかりそのシステム自体が時代遅れになっていた、という笑えない話も多々あります。

また、とにかく手作業を自動化するコンピューターシステムを導入することに意義があった、という時代では、他社に納品されたものと同じようなシステムであっても、何も問題はありませんでした。
しかし現在では、システム開発を行う目的はライバル他社とは違った自社の強みを実現するためといった側面が強くなっているのです。

自社の抱える課題を解決し、同業他社との差別化も図ることがシステムに求められているので、システム開発を成功させるためには、開発会社だけに任せておくわけにはいきません。

この記事では、開発会社が採用する開発方式についてそのメリット・デメリットを整理してから、自社にとって最適な開発方式はどのタイプなのかを明らかにし、その開発方式を得意とする外注先選びのお手伝いをいたします。

システム開発の手法とは、プロジェクトを計画・制御するためのフレームワークです。
このフレームワークは開発会社で行われるコーディング作業を効率化することに使われるだけでなく、開発工程を標準化し、発注者の目的とする製品（自社の抱える課題を解決し、同業他社との差別化を図ること）を間違いなく作り出すために発注者と開発会社が共有する枠組みといった性格も持っています。

システム開発手法は、今日までにさまざまなものが考案されてきましたが、それぞれにメリット・デメリットがあり、プロジェクトの種類や目的に応じてそのつど最適な開発手法を選択する必要があります。
発注側からすると、システム開発会社という看板を掲げているからにはどんな開発パターンでも対応できるだろう、と考えがちですが実際にはそんなことはありません。
開発会社によっては対応できない開発方式もありますし、発注側が望む開発方式でもできることはできるが、あまり実績もなく得意でもない、というケースもあります。

まずは発注側担当者が代表的な開発パターンを知っておき、自社の案件にどれがフィットするかというところまで整理した上で、最適な開発会社を探し始めることが肝心です。

以下、システム開発手法のなかでも特に有名な「ウォーターフォール型開発モデル」「プロトタイピング型開発モデル」「アジャイル型開発モデル」の３種についてご紹介します。

ウォーターフォール型開発では、滝が高い所から低い所に流れるように、上流工程から下流工程へと流れに従って順次プロジェクトを進行させていきます。
具体的には「システム企画」「要件定義」「概要設計」「詳細設計」「プログラム設計」「プログラミング」「プログラムテスト、結合テスト、システムテスト、運用テスト」という工程を経て製品が納品され、納品後は「運用、保守」サービス提供でシステムを稼働させます。

システム企画では、その開発プロジェクトの目的をはっきりさせます。
「目的」とは、例えば「古い汎用機を使った顧客データベースをリプレイスし、ライバル他社と差別化できる最新の顧客管理の仕組みを導入する」などになります。
その他、システム企画の段階でプロジェクトの目標とすべき成果、予算の上限、概算スケジュールなども社内でオーソライズしておきましょう。

システム企画ができた段階で、普段付き合いのあるシステム開発会社などに声をかけて、以下の「要件定義」からの作業を進めてもかまいません。
また、広く開発会社から提案や見積もりを取って比較検討しながら進めたいという場合には、この時点でRFP＝Request For Proposal（提案依頼書）を作成して、業者に配布することから始めましょう。

＊RFPへシステム企画を落とし込む際の注意点についてはこちらの記事などをご参照ください。

要件定義とは、発注側のシステム開発の目的を実現するためにどのようなシステムを完成させるべきかについて、具体的に必要な機能を洗い出すことです。
ここで注意すべき点は、そのシステム開発で行う作業が現状の業務プロセスの効率化を主な目的としているのか、それとも業務プロセスそのものを刷新するような新しいシステムを作ることを目的としているか明確に区別しておくことです。

既存のシステムをベースにする場合には、現場レベルから意見を集約すること（上流工程）で必要な要件は見えてきますが、現在の業務フローを改善してシステムに落とし込むという場合には、新しい業務フローについての青写真が必要です（超上流工程）。
新しい業務フローを新しいシステム開発で実現したい、という場合には現在行われているビジネスプロセスそのものの見直しも必要になってきます。現場の意見だけでなく会社の業務フローはどういう方向で改善されるべきなのか、ということについて意思決定ができる権限を持ったトップマネジメント層の協力も必要になってきます。

*「超上流工程」「上流工程」についての詳しい解説は、こちらの記事もぜひご参照ください。

この段階ではUI（ユーザーインタフェース）設計のイメージを発注側と開発会社がすり合わせ、システムを稼働させるためのプログラムの設計を行っていきます。

「プログラム設計書」にしたがって、実際にコーディングを行い、必要なテストを実施します。
このステップでは発注者側は特に積極的に関わることはありません。
この記事の最初に書きました「餅は餅屋」、専門家として開発会社に任せてしまってよい部分です。

実際にシステム稼働領域にプログラムをインストールして、納品物が当初の目的に合致した機能を実現しているかどうかを確認します。

開発、納品が終了したあとに、開発会社は納品先のエンドユーザーがシステムを使いこなせるように指導したり、細かな不具合を直したり、正常にシステムが作動し続けるようにメンテナンスをしたりします。

上流工程から下流工程へと流れに従って順次プロジェクトを進行させていくウォーターフォール型開発で、発注者側の役割が極めて高いのは、いわゆる上流工程の「システム企画」と「要件定義」です。
要するに何を作りたいのかということが明らかであれば、滝が流れるようにスムーズに進められるのがウォーターフォール型開発の特徴です。

例えば、現在稼働中の汎用機システムをオープンシステムにそのまま移行したいとか、凝った仕組みは要らないからとにかく本店と支店の営業データを共有したいなど、プロジェクトを始める段階でどのようなシステムを組みたいかが明確になっている場合には、それを開発会社と共有して一気に進めていくウォーターフォール型開発が適しています。
途中で仕様確認や仕様変更がない、という条件が付くもののプロジェクト管理の容易さ、納期の短さなどの点ではおすすめです。

プロトタイピング型開発はウォーターフォール型開発の改良版です。
システムの最終的な完成形に至るまでの途中段階で、試作品（プロトタイプ）を作成して発注者に、これで間違いがないか？ と確認を取りながら開発を進めるところに特徴があります。

試作品の種類としては、実際には動かないもののユーザーインタフェースをきちんと作り込んでいくデザイン重視のタイプのものと、デザインは完成形になっていなくても、ECシステムの商品購入手続きのように、一連の流れを体験してもらうなどの機能重視タイプのものがあります。

ウォーターフォール型開発に比べて、途中段階で何度もUIや機能の試作品を作ってユーザーに検証してもらうという手順を踏みますので、大きな手戻り（ウォーターフォール型では本来ご法度の前の工程に戻ること）が生じにくいという点に特徴があります。
もう１つ重要な特徴として、発注者が実際のユーザー体験をすることによって「もっとこうして欲しい」という隠れた要求が顕在化するということがあります。
もちろん、大幅な仕様変更は、もともとウォーターフォール型開発の改良版であるプロトタイピング型開発でも歓迎はされません。しかし、開発が終盤にかかって完成形ができ始めてから追加要求を出されるよりも、もっと前の工程で追加要求に対応した方が開発会社も対処しやすいのは当然です。

社内の業務で使うことが目的ではなく、一般消費者などに向けたシステム開発では洗練されたユーザーインタフェースデザインや、使いやすくいろいろとキメの細かい対応が可能なシステムが重要です。
例えばECサイトの構築では、「商品紹介」「ショッピングカート」「決済」など、基本的な作りはどれも似たようなメニューになります。

こうした既存のサービスに新規参入するときに差別化のメインとなるのは、デザイン的な洗練、無理のない画面遷移、分かりやすい操作性などです。
一般公開されるwebサービスなどは、こうした違いができ上がったシステムそのものの価値を左右します。
したがって段階的にイメージがずれていないか、もっと良いデザインや機能性はないのか？ をプロジェクト途中で確認できるプロトタイピング型開発がおすすめです。

伝統的なスタイルであるウォーターフォール型だけしか知らなかった方は、「プロトタイピング型開発」というのは、途中段階で開発会社と密にコミュニケーションを取りながら進められる斬新な手法に映ったことと思います。

この開発会社との密なコミュニケーションをさらに推し進めた開発手法が「アジャイル型開発」だと言えます。
アジャイル型開発は下記のようなプロセスで開発を行っていきます。

先程のウォーターフォール型開発、さらにウォーターフォール型開発のバリエーションであるプロトタイピング型開発と比べて、最初から最後まで発注者が積極的にプロジェクトに関与していることが分かります。

なかでも５の「発注側と開発側とで完成品を評価し、次に着手する優先すべき区分を決める」というは、ウォーターフォール型にもプロトタイピング型開発にもない、アジャイル型開発ならではの特徴です。
つまり、最終的に目指すべき目的は決まっていても、それをどういう順番で実現していくかについては、初期段階では明らかになっていない（しなくてもよい）というのが、アジャイル型開発の最大の特徴なのです。

先程、webサービスでは他社との差別化を実現するために、デザイン面の洗練や機能面の充実などで他のサービスにはない特色を出すのに「プロトタイピング型開発」が適していると書きました。
アジャイル型開発では、さらに開発の優先順位そのものを途中で見直していくプロジェクトに適しています。

例えば、「同業他社のどこよりも洗練されて使い勝手の良いECサイトを作る」というプロジェクトを、試作品を作りながらプロトタイピング型開発で作り上げて目的を達成したあと、「月間60万アクセス、１万コンバージョン」という目標を掲げて、それに対してできることをすべてやってみるという開発プロジェクトを立ち上げたケースを考えてみましょう。

「月間60万アクセス、１万コンバージョン」のために必要な機能は何なのかを共同チームで洗い出し、最初に「JavaScriptを多用したインタフェースの実現」を優先したとします。
そこで、商品購入プロセスに関する画面遷移でJavaScriptを多用したインタフェースを２週間程度でリリースしたあと、実際に「月間60万アクセス、１万コンバージョン」に近づいたかどうかを検証します。

結果として大きく目標に近づいたのであれば、次に商品購入プロセスに関する画面遷移以外の、商品の詳細をJavaScriptで吹き出しにして提示するなど、別の部分にJavaScript対応を拡大していきます。
もし、コンバージョンにJavaScriptを使ってもそれほど効果がないということが分かったら、JavaScriptのアイデアにはこだわらず、見込み客をじっくり育てていくリードナーチャリングを導入するなど、他の手段で「１万コンバージョン」に近づけるかどうかを評価していきます。

こうして、次々と市場の反応を見ながら最適な戦略をアップデートしたいという場合にはアジャイル型開発が適しています。

ここまでで、「ウォーターフォール型開発」「プロトタイピング型開発」「アジャイル型開発」の特徴と、どんなプロジェクトに適しているのかのイメージがはっきりしたと思います。
どのタイプを選ぶかで、開発のプロセスはもちろん、最終納品物のクオリティまで変わってくることがお分かりいただけたと思います。

次に、各開発型のメリット・デメリットを比較して、さらにその特徴を明らかにしていきます。

原則として上流工程で決定した内容を間違いなくコーディングしていく、というのがウォーターフォール型開発の特徴です。
したがって、予定通り進むならば各工程成果物の品質を担保し、工程間の後戻りを最小限に抑え、納期もブレることが少ない安定した開発手法です。

逆に、前工程での成果物を引き継いで次の工程に入りますので、「開発会社側で以前の工程に誤りがあった」「途中で発注者側から大きな仕様変更のリクエストがあった」などの場合、「手戻り」の問題が生じます。

「手戻り」とはある作業工程の途中で大きな問題が発見され、前の段階に戻ってやり直すことを指しますが、ウォーターフォール型はこうした作業には適していません。
どうしても必要な場合には、ウォーターフォール型の原則を壊して前の段階に戻って開発をやり直すこともありますが、それが発注者都合であれば追加料金が発生しますし、納期も遅れることになります。

プロトタイピング型開発では試作品を工程ごとに確認していくので、発注側と開発側のズレが初期段階で修正できるという点が最大のメリットとなります。
また、ウォーターフォール型開発では頭のなかでしか完成品をイメージできないため、システム開発の終盤になって、「やはり同業他社もやっているこういう機能が欲しい」などの機能追加のリクエストが出てきがちです。
プロトタイピング型開発では試作品を見ることで「こういう機能も欲しい」というリクエストが早い段階で出てきますので、そうした追加機能を吸収してプロジェクトを進めていくことができます。

本来の目的である完成品を作るための前提として試作品を作っていくために、開発時間がかかってしまい、全体工数が肥大化する傾向があります。
とは言え、コストや時間を切り詰めて中途半端な試作品を作ってしまうと、十分なテストができません。
おざなりの試作品では、単なる進捗状況の報告と大した差はなく、ウォーターフォール型開発と同じようなことになってしまいます。
ですから、どのレベルのプロトタイプを作っていくのかについて明確にして発注側と開発側で共有しておくことが大切です。

いずれにしても注者に確認・評価してもらえるだけの機能を作り込む必要があるので、費用や納期の余裕がない場合には向かない開発形式であると言えます。

アジャイル型開発では、市場などの変化にいち早く俊敏に対応するということを基本に開発が進められます。
しがたって、発注者からの修正要求や、技術的な革新への対応が容易であるという点が最大のメリットとなります。
また、実際に使う人の反応を見ながら細かいバージョンアップを繰り返すことで、開発作業を通じて品質を高めたり、より効率的なシステムにしたりしていくことができます。
例えば、ゲームアプリを開発するときなどは、ダウンロード数や離脱ポイントを計測しながら重視すべき点を最優先で開発し、評価の低い部分は後回しにしたり、場合によっては実現目標から外したりすることができます。

アジャイル型開発は、小さな反復を繰り返すという性質上、大規模なシステム開発には向かず、工程の進捗管理も困難だというデメリットは押さえておく必要があります。
また、メンバー間の意思疎通が悪かったり、問題解決を主導するリーダーが不在だったり、そもそもアジャイル型開発の経験があまりないといった場合には、プロジェクトそのものが混乱する恐れもあります。

以上が、代表的な開発方式のメリット・デメリットです。
案件によって向き不向きがかなりはっきりしていることがお分かりいただけたと思います。
次にデメリットを回避するために、「ウォーターフォール型開発」「プロトタイピング型開発」「アジャイル型開発」、それぞれの方式でおすすめの契約方法についてまとめておきます。

「請負契約」とは、完成品を納品することに対して対価が発生する契約であり、「業務委託契約」とは、業務遂行に対して支払い対価が発生する契約です。

「請負契約」では、完成品の定義を厳密に行う必要があります。
完成品の定義をはっきりさせることで、最終納品のときにその納品物が最初に仕様書に落とし込んだとおりの「完成品」に相当するのか、それともどこか欠けるところがあるのかが判別できます。

したがって、初期の上流工程の段階で完成品を使用書に落とし込むタイプの「ウォーターフォール型開発」では「請負契約」を結ぶことに何のハードルもありません。

しかし、「プロトタイピング型開発」と「アジャイル型開発」では完成品の定義が「ウォーターフォール型開発」のように厳密ではありません。
このため、システムとしての最終完成形に対価を払うのではなく、必要な機能ごとに「業務委託契約」を結ぶことが向いているケースもあります。

また、「請負契約」と「業務委託契約」とを組み合わせて契約を結ぶテクニックもありますので、開発内容に応じてこれらのタイプから一番適したものを選ぶとよいでしょう。

このあたりのシステム開発における契約書作成のポイントについてはこちらの記事もぜひご参照ください。

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

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

以上、「ウォーターフォール型開発」「プロトタイピング型開発」「アジャイル型開発」それぞれの特徴とメリット・デメリットを見てきました。

開発方式ごとに一長一短があるので、プロジェクトの内容によって最適な開発方式を選ぶことがポイントです。
この記事を読んでいる発注担当の方のなかには、「ウォーターフォール型開発はもう古い」「プロトタイピング型開発は無駄な時間と費用がかかる」「アジャイル型開発はプロジェクトが空中分解する」などという話を聞いたことがあるかもしれません。
しかし、そのどれもそれぞれの特徴を一面的に見たに過ぎないということがお分かりいただけたと思います。

もし、自社の案件がどのタイプの開発方式に合致するのか、よく分からなかったり、自社にあっている開発方式は分かったけど、実際にその開発方式に対応できる評判の高い開発会社を見つけられなかったりという場合には、ぜひ「アイミツ」にご相談ください。
「アイミツ」に相談していただければ、各方式で実績と経験のある開発会社を複数ご紹介します。