システム開発の工程とは？要件定義や設計、テストなどの作業内容を解説

• 1. システム開発工程とは
• 2. システム開発の9つの工程と求められる人材・スキル
• 3. システム開発ではすべての工程を担当するの？
• 4. ウォーターフォールモデルとアジャイルモデル
• 5. 他のシステム開発手法について
• 6. システム開発工程で使われる略語
• 7. まとめ

1. システム開発工程とは

システム開発工程とは、システムを開発するために決められた手順のことです。要件定義に関わる工程に近ければ上流工程、保守や運用に近ければ下流工程と呼ばれています。
システム開発をどのように進めるかは、そのプロジェクトの規模（期間や人数）や、採用されている開発手法によって異なります。例えばウォーターフォール型と呼ばれる開発手法の場合は、工程ごとに期限や品質の基準などが設けられている一方、アジャイル型の場合は期限や品質の基準が設けられています。

工程を分けて作業する（分業する）理由とは

分業とは、システム開発の過程を工程ごとに分け、異なるエンジニアやプログラマーが各作業に従事すること。分業するのは、品質の高いシステムを開発するためです。

大規模なプロジェクトになると、数年を要する長期にわたることもあります。そのようなプロジェクトでは各メンバーの担当工程を分けることで、一人ひとりの責任範囲が明確になり、自分の担当箇所に集中できることがメリットです。また、工程ごとに管理者を決めておけば、タスク管理も簡単になるでしょう。

2.  システム開発の9つの工程と求められる人材・スキル

ここでは、受託開発を例に取り、システム開発の工程について解説します。システムにはWebシステムや基幹システムなどさまざまな種類がありますが、開発工程はおおむね同じです。また、自社サービスを開発する場合、クライアントが存在しないため、社内で進んでいる開発プロジェクトを進めることになります。

要件定義

要件定義とは、簡単に言うと「何を作るのかを決める」ことです。

システムを開発する場合、必ず「成し遂げたいこと」があります。たとえば、製造業向けシステムの開発であれば、「原料や製品の在庫数をリアルタイムに把握し、経営を安定させたい」という目標や課題です。

成し遂げたい目標を明確にし、システムでどのように課題を解決するのかを決めることが要件定義のキモといえます。

要件定義のフェーズでは、クライアントとのやり取りが重要です。希望をしっかりとヒアリングし、それに対して明確な答えを提示しなくてはなりません。

そのためには、クライアントの業務内容を理解しておくことも大切です。製造業向けシステムであれば、「どこにどのような工場があり、どのような製品群がどのような生産過程を経て製品になるのか、部品点数はどの程度あるのか」を把握しておかなくては、要件定義は難しくなります。

要件定義では、洞察力も重視されるでしょう。たとえば、クライアントが「工作機器の稼働状況をチェックできるシステムが欲しい」という要望を出したとします。この場合、額面通りのシステムを提供することも可能ですが、その裏にある思いを想像してさらに良い提案をすることが望ましいです。

クライアントは、「不良品の発生率が高いので、その原因を探るために稼働状況をチェックしたい」と考えている可能性があります。あるいは、「生産の効率化のために現状を把握したい」と思っている場合もあるでしょう。

ケースによっては、別の方向からアプローチする方がリーズナブルで高い効果を得られることがあります。

クライアントと密なコミュニケーションを取れると、相手が抱える真の問題が見えてきます。それを解決する提案ができれば、信頼関係の向上につながり、今後の仕事におけるスムーズなコミュニケーションにつながるでしょう。

さらに、要件定義では、工数や予算を見積もる能力も重視されます。「この機能を実現すれば●●万円で、このオプションを付けるにはさらに●●万円かかります」と明確に提案しなくては、クライアントは決済ができないためです。

この見積もりを間違えると大変です。「全く儲からないうえに残業続き」…という事態を招くことになりかねません。

基本設計

要件定義が終わると、実際にプロジェクトを進めるため基本設計のフェーズに入ります。基本設計とは「どのようなモノを作るのか」の具体的なイメージを形にする作業です。
「在庫数をカウントする機能」「緊急時にアラートを出す機能」「画面上に表示する機能」など、具体的な機能を整理します。

一般的にシステムへは、パソコンやタブレット端末の画面からアクセスすることになるでしょう。そのため、「どのような画面からどのような情報がチェックできて、どの画面に遷移できるのか」を明確にしなくてはなりません。

クライアントはそのイメージを見ながら「この画面には●●も表示して欲しい」「この情報は不要かな」などと考えます。

基本設計のゴールは、クライアントにシステムの完成イメージを提示して、納得してもらうことです。そのため、基本設計のフェーズでは、クライアントに伝わりやすいドキュメントを作成する能力が求められます。クライアントが納得し、「GO！」と言わない限り、基本設計が終わらないためです。

システム開発というと、プログラミングや理系的な能力が重要と思われがちですが、文章力やコミュニケーション能力などの文系的な要素も重要です。そのため、多くのシステム開発現場では文系出身の人も活躍しています。

要件定義から基本設計までの工程で、そのシステムに必要な機能が洗い出されている状態になっていることが一般的です。

詳細設計

基本設計が終了すると、次は詳細設計のフェーズに進みます。詳細設計はプログラムの設計図を作成する工程です。これまでの工程で整理された機能ごとに、「どのようにプログラミングするのか」を決めます。

基本設計がクライアントに説明するための資料作りだったのに対し、詳細設計は開発の内部で作業をする人向けの資料作りとなります。

詳細設計のフェーズで重要なのは、ドキュメントから曖昧さを排除すること。曖昧な設計図では、プログラムも曖昧になってしまうためです。「Aのケースでは正確な答えが出るけどBのケースだと間違った答えが出る」というプログラムでは、使いものになりません。

担当者が優秀なプログラマーであれば、「この設計書だとミスが出ますよ」と指摘してくれることもあるでしょう。しかし、必ずプログラマーが気づいてくれるとは限りません。

詳細設計のミスが原因で、プログラムにバグが紛れ込むケースは少なからずあります。曖昧さを排除して、誰が見ても確実に機能を実装できる所まで作り込める正確さが求められます。

プログラミング

続いての作業はプログラミングです。IT業界やシステム開発の仕事と聞くと「プログラミング」を想像する人が多いでしょう。しかし、プログラミングは数あるシステム開発の工程の1つに過ぎません。

また、プログラミングを外注している企業も多く存在します。「IT業界に就職したけど、プログラムは研修のときに書いたきり」という人もいるほどです。

単体テスト

プログラミングが終わると、単体テストの工程に入ります。単体テストとは、作成されたプログラムが詳細設計通りに動くことをプログラム単体で確認する作業です。プログラムを書いた人がそのまま担当することもあります。

単体テストで問題が見つかれば、その場でプログラムを修正するケースも少なくありません。ここで重要なのは、「どのようなケースでどのようなバグが見つかり、どのような修正をしたのか」をドキュメントに残しておくことです。

バグと聞くと、ダメなモノというイメージを持たれますが、人の手でプログラムを組む以上、バグは必ず発生します。

「単体テストの結果、●件のバグが見つかり、修正しました」と正確な数字を言えてこそクライアントが納得できるというワケです。

逆に「単体テストでバグは出なかったです」なんて言われると「本当にテスト実施したの？」と不安を与えてしまいます。

結合テスト

単体テストが終わり、システムに関わるプログラムがある程度出そろうと、結合テストの工程に移行します。複数のプログラムを組み合わせ（結合）、問題なく動くかを確認するためのテストです。

結合テストでは、単体テストでは見えなかった不具合が見えてきます。たとえば、「とある処理の実施に時間がかかりすぎ、次の処理がタイムアウトエラーになってしまう」といったことが挙げられます。

結合テストの実施には、システム全体を俯瞰し、モレなくテストケースを考える能力が求められます。また、効率的にテストを実施するための企画力も重要です。

総合テストのフェーズでは発想力も欠かせません。というのも、開発者の手を離れてクライアントに渡ったシステムは、想定外の使われ方をすることがあるためです。

そのため、総合テストでは想定外の使い方をあえて想定し、適切な処理が行われるか、システムがダウンしないかなども確認します。

実際、「えっ！そんなことしちゃったの？」と開発現場が驚くような使い方をされることは少なくありません。そのようなときに復旧まで数日かかるとなってしまうと、開発者にとってもクライアントにとっても大変です。

「とんでもないケースもしっかりと想定し、確認しておく」。これが強固なシステムになるか否かのカギを握るといえるでしょう。

なお、テストの実施件数・エラーの発生件数・修正状況などはしっかりと記録しておきましょう。「テストをしっかりと実施しました」というエビデンスになるためです。

運用テスト

結合テストが終わると、続いては運用テストです。システムが実際に使われる現場に運び、実際に使われるサーバーを稼働し、実際の画面で使ってみます。

いきなり運用して思わぬ事態が発生すると大変なことになってしまうため、最終確認を実施しておくというイメージです。

基本的には総合テストで問題点を洗い出し修正しているため、運用テスト段階での問題は出ないケースがほとんどです。しかし、まれに運用テストで問題が発見され、担当者が青くなることもあります。

小さなミスであれば、数日で修正が可能です。致命的なミスが見つかってしまった場合は、リリースの予定を変更し、慌てて修正作業に入ることもあります。

リリース

運用テストも問題なく済ませたら、いよいよリリースです。担当者にとっては緊張すると同時に、仕事にやっと一区切りがつく記念すべき日でもあります。

総合テスト・運用テストをしっかりと実施しておけば、基本的に問題が起こることはありません。それだけに、問題が起こったときは、リリースを中止して元のシステムに戻し、仕事に支障がでないようにしなくてはならないため大変です。そのため、リリース前には、リリースの手順とともに、緊急時の手順も用意しておきます。

運用・保守

リリースしたらシステム開発は終了と思われがちですが、この後も問題なくシステムが稼働するように運用・保守をする必要があります。

システムリリース直後は、クライアントから「●●機能を使うにはどうすれば？」という質問が出がちです。そういった疑問・質問に対し、サポートセンター的な役割を果たします。

また、システムを利用し続けていると、新たな問題が見つかることもあります。実際に使ってみたからこそ気付く「●●が使いにくい」のような意見も出てくるものです。そのような場合に、小さな修正を加えてより使いやすくサポートすることもあります。

システムを安定的に稼働させるためには、定期的なチェックも欠かせません。あるいは思いがけないトラブルが発生し、システムが使えなくなってしまうこともあります。多様な要望に丁寧に対応してこそ、クライアントの満足感が得られ、次の仕事につながります。

なお、運用・保守の仕事は深夜・早朝に作業をすることも少なくありません。「システムを停止できる時間帯が夜中だけ」というケースもあるためです。

運用・保守作業は大変ですが、クライアントと直接やり取りをして直接感謝される、やりがいを感じやすい仕事でもあります。

以上9つが一般的なシステム開発の工程です。基本的に開発は上から順に実施するウォーターフォールモデルで進みますが、まれに工程を省略するアジャイルモデルで開発することもあります。ウォーターフォールモデル・アジャイルモデルに関しては後ほど詳しく説明します。

3. システム開発ではすべての工程を担当するの？

システム開発の9つの工程について解説してきましたが、「就職したら開発工程すべてを担当するの？」という疑問を持つ人もいるでしょう。

全工程に携わってみたいと思う方もいれば、要件定義と基本設計を主に担当したい、あるいは機能のテストを担当したい方もいると考えられます。

全工程に関わるのか、一部の工程のみに関わるのかは、会社のスタイルやプロジェクトの規模によります。会社やプロジェクトの規模が小さいほど、全行程に関わる傾向が強いようです。

大きな会社で巨大なシステム開発を行う場合は、それだけ開発に携わる人の数も多くなるため、一部の工程だけを担当することが予想されます。

就職先を考える場合には、上記も踏まえ、自分がどのような工程に関わりたいか、どのような働き方をしたいかについても考えておきましょう。

ITコンサル系のように主に上流の工程だけを担当する会社や、開発を専門に行う企業、テストをメインで実施する企業など、さまざまなスタイルが存在しています。

4. ウォーターフォールモデルとアジャイルモデル

システム開発で重要な工程は先にご紹介したとおりですが、開発手法には上から順に工程をこなすウォーターフォールモデルと、工程の順番に決まりのないアジャイルモデルが存在しています。それぞれのメリットやデメリットについてチェックしましょう。

ウォーターフォールモデル

ウォーターフォールモデルとは、要件定義⇒基本設計⇒（中略）⇒リリース⇒運用・保守と順を追って開発する方法です。

各工程を順に行うことで、やるべきことが明確になり、ミスやバグが発生しにくくなるというメリットがあります。

一方で、ウォーターフォールモデルを着実に実施することはそれなりに時間がかかります。詳細設計のフェーズに入ったにもかかわらず、「どうしても新たな機能を追加して欲しい」との要望を受ける場合があるためです。

この場合、影響が出る箇所すべてのドキュメントをチェックして、アップデートするのが正しいやり方です。しかし、実際にはそこまで手が回らないというケースも少なくありません。

着実に工程をこなすことでミスが発生しにくいというメリットがある代わりに、作業は大変になりがちというデメリットもあります。

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

ここでは、ウォーターフォールモデルのメリットとデメリットをさらに紹介します。

スケジュール管理がしやすい

ウォーターフォールモデルの大きなメリットは、納期の見通しやスケジュールの管理がしやすいことです。

ウォーターフォールモデルでは、システム開発の工程を計画し、その内容を手順通りに進めます。そのため、作業前の段階で工数を割り振れ、工程ごとに納期を設定可能です。後戻りも少なく済むため、納期に遅れる危険性を下げられます。

ウォーターフォールモデルは、開発するシステムの内容が決まっており、納期や導入の時期が決まっているプロジェクトに向く方法です。

予算を確保しやすい

ウォーターフォールモデルでの開発は見通しが立てやすく、予算を確保しやすいのがメリット。工数を割り振ることで、どの作業に何人のエンジニアやプログラマーが必要になるかが分かるためです。

作業前に見通しが立つため、エンジニアやプログラマーの人員が不足していれば人材を募集したり、下請けに依頼したりできます。その際にも、どれ程度のコストがかかるかを算出できるため、開発に必要な予算を立ててから作業が始められるでしょう。

トラブルが発生しにくい

全体のスケジュールについて見通しが立てやすい分、納期に遅れるリスクも減らせます。。

加えて、各工程を専門家が担うため、作業に不慣れなことが原因となるトラブルも起きにくいでしょう。

開発に時間がかかる

ウォーターフォールモデルでの開発は、各工程を丁寧に作業し、工程が終わるごとに問題はないかを確認します。開発期間を長めに見積もるため、リリースまでに時間がかかります。

また、柔軟性が低いため、仕様が変更された際には大幅なスケジュール変更や予算の見直しをしなければなりません。ウォーターフォールモデルでは、作業の開始前に計画を立て、手順通りに開発を進めるため、仕様が変更になると計画からやり直しになります。素早い開発が求められるシステムや、利用者の声を受けて柔軟に軌道修正することが求められがちなtoC向けのプロダクトの開発には向かないでしょう。

アジャイルモデル

アジャイルモデルは、ウォーターフォールモデルのように工程の順を追うことはありません。良い意味で適当に工程を端折りながら進んでいきます。

たとえば、3人程度のスタートアップ企業で、自社開発のWebサービスを提供したいと考えていたとします。

3人の頭には共通した完成イメージがあります。それなら、基本設計や詳細設計などはザックリとしたモノだけを作り、プログラミングを始めても良いはずです。この方法では、着想からリリースまでの時間を大幅に短縮できます。

リリース後には、ユーザーの反応を見ながら、サービスの修正や機能の拡充をはかります。これはある種、要件定義や基本設計的な工程といえるでしょう。

サービスが安定的に稼働して収益を得られるようになれば、スタッフを増やせる可能性もあります。
3人程度であれば共通認識とされていたことも、人数が増えると、明確なドキュメントを用意しておいたほうが仕事を進めやすくなるため、詳細な設計書を用意しておくことが望ましいでしょう。

このように、アジャイルモデルではウォーターフォールモデルとは大きく異なる開発手順で進みます。基本的には、比較的小規模で試験的な開発に向いているモデルです。

スピーディーなシステム開発ができる一方で、しっかりと意思疎通がはかられていないと方向を見失うことがあること、大規模開発には不向きなことがデメリットといえます。

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

ここでは、アジャイルモデルのメリットとデメリットをさらに紹介します。

仕様の変更に対応しやすい

アジャイルモデルの大きなメリットは、仕様変更に柔軟に対応しやすいこと。要件定義や設計、運用・保守など一連の手順を工程ごとに時間をかけて作業するのではなく、一巡するペースが速いためです。

開発の途中でクライアントから仕様変更を要求されても、ウォーターフォールモデルのように計画からやり直さなくても良く、変更が出た工程に戻るだけで済みます。

そのため、アジャイルモデルでの開発はクライアントの意見を素早くシステムに反映させやすく、顧客満足度の向上にもつなげやすいと考えられます。

開発期間が短縮できる

アジャイルモデルでの開発では、工程が終わるたびに問題がないかをクライアントに確認し、要望や修正を加えながら工程を繰り返します。

そのため、数回の修正でクライアントから問題がないと言われた際には、ウォーターフォールモデルよりも短い開発期間でリリース可能です。

納期の見通しが立てにくい

クライアントの要望に応じて問題個所の修正のために何度も開発を繰り返すため、納期の見通しが立てにくいのがデメリットです。リリースできる時期、システム開発にかかる予算の想定もしにくいでしょう。

また、何度も修正することで方向性にずれが生じ、大幅な変更が発生する可能性も。当初のコンセプトと大きな差が発生すると、開発期間が長くなり、予算がかかり過ぎてしまいます。

5. 他のシステム開発手法について

システム開発手法は、ウォーターフォールモデルとアジャイルモデルだけではありません。ここからは、それ以外の開発手法として「プロトタイプモデル」「スパイラルモデル」を紹介します。

プロトタイプモデル

プロトタイプモデルは、クライアントに機能や開発の目的を聞いたうえで試作品を確認してもらい、その後で開発を始める手法です。クライアントとのすり合わせ後は、ウォーターフォールモデルの開発工程に移行します。

試作段階でクライアントからの意見を聞けるため、方向性のずれが生じにくいのがプロトタイプモデルのメリットです。

ただし、大規模なプロジェクトでは、プロトタイプを作成するだけで時間と費用がかかってしまいます。小規模なシステム開発に向くでしょう。

スパイラルモデル

スパイラルモデルは、要件定義からテストまでをフェーズ分けし、フェーズごとにプロトタイプを作成する開発手法です。

スパイラルモデルの特徴は、フェーズごとの開発をウォータフォールモデルで進めることです。作成したプロトタイプをクライアントに確認してもらい、修正箇所や要望があれば再び要件定義からテストの工程を繰り返します。クライアントとの認識のズレが発生しにくいのがメリットです。

ただし、フェーズ数が多く、作成するプロトタイプが多くなれば、その分開発期間や費用が多くなります。

6. システム開発工程で使われる略語

システム開発では、多種多様な略語が使われています。略語を知っておけば、現場でのコミュニケーションが円滑になるでしょう。

よく使用される略語は、以下のとおりです。

「SP」…システム企画・企画
「RD」…要件定義
「CD」…コーディング
「SA・RA」…要求分析
「UI・BD」…基本設計
「PS・DD」…詳細設計
「SS」…構造設計
「PD」…プログラム設計
「FD」…機能設計
「ED」…外部設計
「ID」…内部設計
「ST」…システムテスト
「UT」…単体テスト
「OT」…運用テスト
「IT・PT」…結合テスト

7. まとめ

システムを開発する一連の作業は、複数の工程に分けられるのが一般的です。具体的な工程や進め方は、そのプロジェクトで選択されている開発手法によって異なります。有名な開発手法として、ウォーターフォールモデルとアジャイルモデルが挙げられ、プロジェクトの規模や開発する対象によって、向いている手法は異なります。開発手法ごとの特徴や進め方、開発工程でよく使われる用語などは、覚えておくと就職後にも役立つでしょう。

ITエンジニアを目指す新卒学生向け就活エージェントならレバテックルーキー

レバテックルーキーは、レバテックが運営するITエンジニア専門の就活エージェントです。多数のITエンジニアのキャリア支援経験のあるアドバイザーが、あなたのスキルと希望に合わせた企業の紹介から、人事目線での面接対策など、就職までを一貫してサポートします。ES添削、面接対策、ポートフォリオ作成サポートなども実施していますので、まずは一度カウンセリングにお越しください。

就活アドバイザーに相談してみる