【失敗しない】システム開発の進め方で理解しておくべき開発手法とは？

最終更新日：2023.11.15

ベトナム情報

中垣圭嗣

SHARE ON

みなさんこんにちは。Wakka Inc.ラボマネージャーの中垣です。
国の働き方改革やIT補助金などの背景もあり、自社のシステムをリニューアルしたいというご要望を最近多くいただきます。

とはいえ、製造業や大手企業のシステムは十数年程度使われているケースが多く、
社内に過去の担当者がいなかったり、自社システム開発のノウハウがあまり溜まっていないのではないでしょうか。

そこで今回は、システム開発の進め方についてご紹介したいと思います。

基礎編として、代表的なもの2種類の進め方をそれぞれご紹介し、
あわせてどのようなシステム開発プロジェクトではどのような進め方がベストなのかなどについても解説していきます。

Wakka Inc.のラボ型開発では最適な開発手法で開発可能な優秀な人材を低コストで確保するラボ型開発サービスを提供しています。
ラボ型開発に興味がある方は「【保存版】成長企業が導入するWakkaのラボ型開発」に詳しいサービス内容を掲載しているのでご覧ください。

●開発リソースの不足にお悩みなら●

＞＞＞Wakka.Inc独自の海外子会社設立サービスがおすすめ！
無料でサービス資料をダウンロードできますのでぜひご覧ください。

2種類の開発の進め方（概要）

冒頭で挙げた2種類の開発手法は以下です。

・ウォーターフォールモデル
上流工程から順に進めていく

・アジャイルモデル
機能ごとに開発していく

これらに該当しないものもありますが、ほとんどの開発プロジェクトでは上記2種類のどちらかの開発モデルになっています。
またウォーターフォールモデルとアジャイルモデルの中間的な手法で進められる場合もあります。

それぞれのモデルの詳細や工程については後述しますが、まずはざっくりと把握しておいてください。

システム開発の工程

システム開発の工程自体は、どの開発モデルでも同じです。開発工程の切り分けは複数ありますが、シンプルな区分をご紹介します。以下の順番でシステム開発の工程は進んでいきます。

1.要件定義
2.設計
3.プログラミング
4.テスト
5.リリース

以上のシンプルな開発工程の順番です。より細分化した場合、たとえば設計が基本設計と詳細設計に分かれる、テストが単体テスト、結合テスト、総合テストに分かれるといったことがあります。

また工程の区分はプロジェクトによって微妙に異なります。とはいえ概ね上記の大枠を把握しておけば問題ないでしょう。それでは、それぞれの工程について解説していきます。

1.要件定義

要件定義は、その名の通りシステムの要件を話し合う工程です。システム開発プロジェクトにおいて最上流の工程になります。要件定義は開発者側と顧客側で行うのが一般的です。

この要件定義で認識をすり合わせておくことが非常に重要で、曖昧なまま後の工程に進むとプロジェクトの手戻りが多くなります。要件定義はプロジェクトの中でもプロジェクトマネージャーなど責任ある立場の人が担当することが多いです。

小規模なプロジェクトの場合は開発メンバー自体が少ないので、開発者全員が参加する場合もあるでしょう。顧客側はシステムに詳しいIT部門などの担当者が参加することもあれば、システムには詳しくない経営陣などが参加する場合もあります。
そのため、顧客に合わせた提案、資料作成、プレゼンテーションを行う必要があります。

弊社では外部の開発企業に要件定義をしてもらうために必要な、RFPテンプレートをご用意しています。
システム開発の外注を検討されている方は、ぜひ『こちらのフォームから』ダウンロードしてみてください。

2.設計

設計とは、どのようなシステムを作るのか、そのためにどのようなプログラミングが必要か、といったことを記載するものです。
要件定義では概要を決めますが、設計は機能ごとに細かく記載していきます。

設計の中でも基本設計や詳細設計に分かれていて、基本設計は比較的全体の流れを記載します。
これに対し、詳細設計は細かく記載するのが一般的で、ソースコードをべた書きする場合もあるほどです。

基本設計を外部設計、詳細設計を内部設計などと呼ぶ場合もあります。
設計がしっかりできていれば後のプログラミングの工程が楽になります。逆に設計に問題があるとプログラミング工程から手戻りが生じます。

大規模プロジェクトの場合、設計はシステムエンジニアが担当する場合が多いです。

3.プログラミング

プログラミングと言えば、システム開発の中心というイメージがあるかと思います。実際、最終的に稼働しているシステムはプログラミングによって動いています。
しかしここまで見てきた通り、プログラミングの上に要件定義と設計があります。

そして、これらの上流工程の方が開発現場においては重要視される傾向にあります。
プログラミングの工程で試行錯誤するのではなく、上流工程の段階でなるべく詳細に記載するプログラムを決めておくということです。

そのため、設計はプロジェクトにおける上位職であるシステムエンジニアが担当し、プログラミングはプログラマーが担当します。指示系統としては、設計書を作成したシステムエンジニアにプログラミング担当者のプログラマーが従うイメージです。

4.テスト

プログラミングの工程が完了したら、完成したシステムのテストを行います。テストは機能単位でレベルが分かれています。
多くのプロジェクトでは、単体テスト、結合テスト、総合テスト、と分かれています。

最終的に実際の環境で動かすことを運用テストと位置付ける場合もあります。
まず単体テストは最初に行うテストで、各機能ごとにテストを行います。各機能がうまく動いていないと当然システム全体の動きとして不具合が生じるので、最初に単体テストを行います。

単体テストで問題ないことが確認できたら、次に結合テストを行います。
結合テストは複数の機能を組み合わせてテストすることです。機能間のデータの受け渡しや、機能間の接続を主に確認します。

結合テストでも問題ないことが確認できたら、総合テストを実施します。
総合テストはシステム全体が意図通りに機能しているかどうかを確認するテストです。

最後の運用テストは、総合テストで動かしたシステムをそのまま本番環境に移行してテストします。
運用テストは開発者側が様子を見ながら、顧客側が動かす場合が多いです。顧客に動かしてもらって、不都合がないか、不足している機能はないかなどの確認を行います。

ちなみに、要件定義がしっかりできていないとこの段階になって認識のズレに気づくような場合もあります。
運用テストの段階で顧客側との認識のズレに気づくと、手戻り工程が非常に大変になるので注意が必要です。

5.リリース

リリースは、システムを顧客側に渡すことです。渡すと言ってもリリース後に開発者がどこまで運用に関与するかはケースバイケースです。
開発した企業が運用も担当し、必要に応じて修正や不具合対応を行うプロジェクトも多々あります。

ただ、新しいシステムは運用してみて気付く課題も多くあります。
そのため、システムリニュアールに慣れていない方は、開発から運用保守までトータルサポートしてくれる企業を選ぶと良いでしょう。

弊社は、お客さまのビジネス理解から要件定義、開発、運用保守までをトータルサポートしています。
さらに、あなたの会社の専属チームが継続して開発する、『ラボ型オフショアサービス』もございます。気になる方はリンクからサービスページをチェックしてみてください。

ウォーターフォールモデルのメリット・デメリット

ウォーターフォールモデルは名前の通り水が上から下に流れるように、上流工程から順にきっちりとシステム開発を進めていくモデルです。
ウォーターフォールモデルはシステム開発のもっともオーソドックスな開発の進め方と言えるでしょう。

ウォーターフォールモデルのメリット

ウォーターフォールモデルは安定的な開発モデルで、以下のようなメリットがあります。

・スケジュールを管理しやすい
・予算を立てやすい
・連携ミスが生じにくい

以上のようなメリットがあります。ウォーターフォールモデルはシンプルに上流工程から下流工程に作業を進めていくので、スケジュールを立てやすく、また管理もしやすいです。

作業の流れが明確になりやすいので、予算も立てやすくなります。
ちなみにシステム開発の予算の大部分は人件費で、人件費は月単位で計算されるのが一般的です。つまりスケジュールを把握しやすいということは、予算の立てやすさにもつながります。

またウォーターフォールモデルは各担当者の作業を把握しやすいので、連携もしやすいです。
システム開発を役割分担して進める場合は連携が非常に重要で、連携ミスによって手戻りが生じることがあります。ウォーターフォールモデルではこのようなトラブルが少ないです。

ウォーターフォールモデルのデメリット

ウォーターフォールモデルのデメリットは、リリースに時間がかかることや、臨機応変さに欠けることです。上流工程からきっちりと進めていくため、たとえば一部の機能の下流工程から着手した方が効率的だと思ったとしても自由に着手することはできません。またトラブルが発生した際に大幅な手戻りが生じやすいです。

しっかりと要件を固めてから開発したり、要件定義の際に顧客のニーズを汲んでくれる外注企業を選ぶことをお勧めします。

アジャイルモデルのメリット・デメリット

アジャイルモデルはシステムを構成する機能ごとに開発を進め、最終的に一つのシステムとしてリリースする開発モデルです。

アジャイルモデルのメリット

アジャイルモデルは機能単位で開発を進めていくので、全体で進めるウォーターフォールモデルよりも臨機応変に動きやすく、
また必要なものに限定して開発を進めやすいので納期も早い傾向があります。

このようなメリットから、近年はIT系企業を中心にアジャイルモデルで開発を進めるプロジェクトも増えています。
というのも新規事業や新しいサービスなどでは、システム開発に予期せぬトラブルはつきもので、開発途中での仕様変更なども発生します。

アジャイルモデルはこういったトラブルや仕様変更に対応することを前提に動いているので、
要件が見えにくいプロジェクトではウォーターフォールモデルよりもアジャイルモデルが適していると言えます。

アジャイルモデルのデメリット

アジャイルモデルには、臨機応変が故に当初の計画とズレてしまう、予算が膨らむ可能性がある、といったデメリットがあります。
臨機応変に動くためにあえて自由度を残したモデルなので、その都度考えて開発を進めないとトラブルにつながります。

その他の開発の進め方

今回、基礎編として多くの開発プロジェクトで取り入れられているウォーターフォールモデルとアジャイルモデルについてご説明しましたが、いかがでしたでしょうか。
システム開発においてはこの2種類を把握しておけば問題ありませんが、参考までに他の開発モデルもあるので、補足としてご紹介しておきます。

プロトタイプモデル

プロトタイプモデルは、ウォーターフォールモデルに試作品作成が追加されたモデルです。
ウォーターフォールモデルでは上流工程で上からきっちり固めていくような流れで開発が進みますが、開発者側と顧客側で認識にズレがあると手戻りが大変というデメリットがあります。

そこで、要件定義の後に試作品を作る工程を追加したのがプロトタイプモデルです。
最初に試作品を作って顧客に見てもらうことで、認識のズレを防げます。これによって手戻りを防げるというメリットがありますが、当然試作品を作る労力が発生します。

試作品とはいえある程度完成形に近い形でないとイメージできません。
試作品で作った機能はそのまま本番用に使いまわせることもあるのですが、すべて流用できるわけではありません。

また、試作品の段階で認識合わせをしたものの、本番システムの開発時に結局認識のズレや修正が発生してしまう、といったこともあります。
プロトタイプモデルは適切に運用しないと、認識のズレを防げるというメリットがなくなり、手間がかかることや結局認識のズレを防げないこともあるといったリスクがあります。

スパイラルモデル

スパイラルモデルはアジャイルモデル同様に、機能ごとに開発工程を反復します。
アジャイルモデルと混同されることが多く、実際開発手法として重複している部分も多いです。

ではスパイラルモデルとアジャイルモデルは何が異なるのでしょうか。
この2つの大きな違いは、重要視するポイントとリリースのタイミングです。

まず基本的な思想の違いとして、スパイラルモデルでは品質重視、アジャイルモデルではスケジュール重視です。
これはリリースするタイミングとも関係するのですが、スパイラルモデルの場合機能ごとに開発を進めるものの、リリースはすべての機能の品質が担保されたタイミングになります。
そのため、仮にスケジュールが遅れていたとしても品質を担保するために納期を延ばす傾向があります。

一方で、アジャイルモデルでは機能ごとに順次リリースしていきます。機能ごとにいったんリリースし、必要があれば次の機能開発と並行して修正を行います。

ひとことで分かりやすくまとめるなら、スパイラルモデルは完璧主義に近く、アジャイルモデルは完了主義に近いです。
ただ、完璧主義に近い思想のため、コストが高くなりやすいという点には注意が必要です。