「システム開発は、どのようなプロセスで進めればいい？」
「システム開発の各プロセスでは、具体的にどんなことが行われる？」
業務改善の多Mシステム開発を考えている企業には、そのような疑問を持っている方も多いでしょう。
システム開発のプロセスは、基本的には以下の流れで行われます。
1）要件定義
2）外部設計
3）内部設計
4）コーディング
5）テスト
6）リリース
7）運用・保守
さらに、開発手法にはいくつかの種類があり、それによってプロセスも異なってきます。
・ウォーターフォール型：上流工程から下流工程まで順に進める
・アジャイル型：機能ごとに「開発→リリース」の小さなサイクルを繰り返す
・プロトタイプ型：早い段階で試作品を作り、発注者のレビューを受けて修正する
・スパイラル型：機能ごとに開発の小さなサイクルを繰り返し、完成後にリリースする
これらの特性を知って、案件ごとに適した開発プロセスで進める必要があります。
そこでこの記事では、システム開発のプロセスについてくわしく説明していきます。
まず最初に、「各プロセスで何が行われるか」です。
◎システム開発のプロセス
・要件定義
・外部設計
・内部設計
・コーディング
・テスト
・リリース
・運用・保守
◎システム開発プロセスの種類
・ウォーターフォール型
・アジャイル型
・プロトタイプ型
・スパイラル型
さらに、開発プロセスを決める際に知っておきたい以下のことについても解説します。
◎ウォーターフォール型のメリット・デメリット、向いているケース
◎アジャイル型のメリット・デメリット、向いているケース
◎システム開発でプロセスが重要な理由
◎システム開発プロセスで用いられる略語
最後まで読めば、システム開発がどのようなプロセスで行われるかがわかるでしょう。
この記事で、あなたの会社が適切なプロセスによってシステム開発できるよう願っています。
1.システム開発のプロセス
システム開発には、一般的な開発プロセス＝工程の流れがあります。
個々の案件によって詳細は異なりますが、おおむね以下の77ステップのプロセスで行われると考えてよいでしょう。
1）要件定義
2）外部設計
3）内部設計
4）コーディング
5）テスト
6）リリース
7）運用・保守
そこでまず、それぞれのプロセスについてくわしく説明していきましょう。
1-1.要件定義
システム開発の最初のプロセスは、「要件定義」です。
以下の項目を詳細に定めて、「要件定義書」を作成します。
・システムの性能
・必要な機能
・運用方法
・テスト内容
・開発予算
・プロジェクトチームの人員
・開発期間
・どのようにシステムを構築していくか など
要件定義書の内容は、個々の開発案件によって異なりますが、独立行政法人情報処理推進機構（IPA）による「失敗しない要件定義とリスク対策」に、主な要件定義書の内容が例示されていますので、以下に引用しておきましょう。
| 【主要な要件定義成果物一覧と作成時の役割分担】
・ビジネスプロセス関連図 出典：独立行政法人情報処理推進機構（IPA）「失敗しない要件定義とリスク対策」 |
ちなみにIPAからは、「ユーザのための要件定義ガイド 第2版」も公開されています。
要件定義に関してさらにくわしく知りたい方は、そちらも参照してください。
1-2.外部設計
次に、要件定義書に沿って「設計」に入ります。
この設計プロセスは、「外部設計」と「内部設計」の2つのプロセスに分かれ、まずは、システムの外観であるUI（ユーザーインターフェース）を設計する「外部設計」を行います。
UIはシステムを利用するユーザーが直接触れる部分なので、見た目はもちろん使いやすさ、わかりやすさ、見やすさを意識して設計される部分です。
外部設計では、「基本設計書」と呼ばれる設計書を作成します。
1-3.内部設計
続いて「内部設計」です。
外部設計で決められた基本設計に従い、「詳細設計書」を作成します。
必要な機能を分割してそれぞれ設計した「機能仕様書」、データを整理した「データベース物理設計書」などを設計したり、情報を入力した際の画面遷移なども決めていきます。
この後の工程ではこれらの細かい資料をもとにプログラミングが行われるので、必要な機能が正しく実現されるように入念に設計しなければならない重要な工程です。
1-4.コーディング
設計書ができたら、いよいよここからは開発フェーズです。
SEやプログラマーが、詳細設計書にもとづいて所定のプログラミング言語でコーティングを行い、プログラムを作成します。
1-5.テスト
プログラムが作成できたら、テストが必要です。
設計通りに作成したプログラムが、要件定義で定めたように稼働し機能するかをチェックします。
このテストは一般的に以下の4段階で進められるのが通例です。
・単体テスト：分割してつくったプログラムそれぞれ正しく動くかどうかのテスト
・結合テスト：分割してつくった複数のプログラムを結合させて、正しく機能するかのテスト
・総合テスト：すべてのプログラムが要件定義通りに機能するかのテスト
・運用テスト：実際にシステムが運用される環境下で、業務に支障なく使用できるかを確認するテスト
1-6.リリース
4段階のテストすべてをクリアすれば、システムは完成ですのでリリースします。
この際に、すでに稼働している旧システムがあれば、そこからデータなどを新システムに移行しなければなりません。
この移行が問題なくでき、新システムが正しく動作すれば、リリースは成功です。
1-7.運用・保守
システムがリリースされたら、その後は運用と保守を続けます。
新しいシステムが正しく稼働するよう定期的にチェックし、もし不具合や障害などのトラブルが発生すれば対応します。
さらに、よりユーザーのニーズに合った機能を提供するために、アップデートをする必要もあるでしょう。
この運用・保守は、システムを利用している限り続くプロセスです。
2.システム開発プロセスの種類
以上が、一般的なシステム開発のプロセスでした。
が、実際の開発は、このように各工程を上から下に順番に行っていくケースだけではありません。
必要な工程をどのように組み合わせて進めていくか、いくつかの方法があります。
その主なものは、以下の4種類です。
・ウォーターフォール型
・アジャイル型
・プロトタイプ型
・スパイラル型
この章では、これらのプロセスの種類についても説明しましょう。
2-1.ウォーターフォール型
まず、システム開発においてもっとも歴史が古く、多数の開発が行われているのが「ウォーターフォール型」です。
これは前章で挙げた各工程を、上流工程から下流工程までひとつの流れで順番に進めていくシンプルな方法で、その様子が「流れる滝＝waterfall」のようであることから「ウォーターフォール型」と呼ばれます。
ウォーターフォール型は、ひとつの工程が要件や仕様通りに100％完了できたことを確認してから次の工程に進みます。
そのため、進捗管理やコスト管理がしやすいのが特徴です。
ただ、このように進めるためには、最初の工程で要件定義や仕様書を詳細に定める必要があります。
基本的には前の工程に手戻りすることを想定しないので、開発途中での仕様変更や修正には対応しづらい方法です。
2-2.アジャイル型
「アジャイル型」とは、各機能ごとに小さな開発サイクルを何度も行う方法で、ウォーターフォール型と並んでよく採用されるものです。
まず必要な機能に優先順位をつけ、機能ごとに「設計」「開発」「テスト」「リリース」を繰り返すことで、システムの機能を充実させ完成に近づけていくのが特徴です。
すべての機能が完成してからリリースするウォーターフォール型とは異なり、基本機能でのリリースまでは短期間でたどり着けるのがメリットで、そのため「agile＝俊敏な、素早い」と呼ばれます。
アジャイル型は、最初の要件定義の段階で要件や仕様を詳細に定める必要はありません。
小さな開発サイクル＝「イテレーション」ごとにレビューとフィードバックを行い、必要な機能を追加することでシステムを完成させていきます。
そのため、仕様変更や修正にも柔軟に対応でき、クオリティの高い開発が可能です。
ただ、要件定義や仕様が厳密でないということは、進捗やコストの管理が難しいということでもあるので、プロジェクトのマネジメントはウォーターフォール型より難しいと言えるでしょう。
2-3.プロトタイプ型
「プロトタイプ型」は、ウォーターフォール型の弱点を改善した開発プロセスです。
ウォーターフォール型は、最初の時点で要件や仕様が詳細に決定されていなければならず、開発途中での仕様変更や修正には柔軟に対応できないのが難点となっています。
一方、プロトタイプ型の特徴は、開発の早い段階でまずプロトタイプ＝試作品を作成し、発注者側のレビューを受けて修正を加えながらシステムを完成させていく方法です。
つまり、途中で仕様変更や修正があることを前提としているという点が、ウォーターフォール型との大きな違いだと言えます。
この方法は、要件や仕様をくわしく決める必要がないため、発注者がどのようなシステムを作りたいかについて明確なイメージを持っていない場合でも開発を始められるという利点があります。
実際に試作品を見て触れて稼働させることで、欲しい機能やUIのイメージを明確化することができるので、それをもとに発注者の要望を随時反映させながら開発を進めていきます。
2-4.スパイラル型
「スパイラル型」は、ウォーターフォール型とアジャイル型両方の長所を取り込んだ開発プロセスです。
要件と仕様を詳細に定め、それに従って開発がすべて完了してからリリースする点は、ウォーターフォール型と同様です。
一方、開発工程を機能ごとに分けて「設計」「開発」「テスト」「評価・改良」を繰り返すフローは、アジャイル型の特徴を取り入れています。
このように小さな開発サイクルをぐるぐる回しながら、システムの完成度を高める様子が「spiral＝らせん」に似ていることから、スパイラル型と呼ばれるようになりました。
ただ、アジャイル型と異なるのは以下の点です。
・アジャイル型は、ひとつの機能が完成するごとにリリースする
・スパイラル型は、ひとつの機能が完成してもそのたびにリリースせず、システム全体が完成してはじめてリリースする
・アジャイル型は、完成してから発注者に提示する
・スパイラル型は、ひとつのサイクルが完了するごとに発注者側のレビューを受け、その結果を次の開発サイクルに活かす
→ 未完成品を発注者側に提示して改良していくやり方は、アジャイル型にはなくプロトタイプ型に近い
複数の開発プロセスの長所を併せ持っているため、仕様変更や修正への対応は柔軟でありながら、進捗管理やコスト管理もしやすい開発プロセスです。
このように、システム開発にはさまざまなプロセスの流れがあり、案件ごとに最適な方法を選んで開発を進める必要があります。
そこで次章からは、特に多く用いられるウォーターフォール型とアジャイル型について、どちらを選べばいいか選択しやすいよう、それぞれのメリット・デメリットと向いているケースを挙げていきましょう。
3.ウォーターフォール型のメリット・デメリット
まず、ウォーターフォール型のメリット・デメリットとは何でしょうか？
3-1.ウォーターフォール型のメリット・デメリット
ウォーターフォール型のメリット・デメリットとしては、主に以下のような点が挙げられます。
＜メリット＞
・計画を立てやすく、進捗管理やコスト管理やしやすい
・幅広い開発案件に対応できる
・人材の確保がしやすい
・成果物のクオリティが担保されやすい
・手戻りを最小限にできる
＜デメリット＞
・仕様変更に対応しにくい
・開発期間が長期化しやすい
・コストオーバーや納期遅れのリスクがある
・ユーザーの意見が反映されにくい
3-2.ウォーターフォール型が向いているケース
また、ウォーターフォール型に向いている開発は、以下のようなケースです。
・どのようなシステムを作りたいかが明確で、要件定義を詳細に行える場合
・業務要件が定まっていて、変更の可能性がない業務システム開発
・開発工数が多く多数のエンジニアが必要な大規模開発 →管理がしやすいため
・クオリティを重視したい場合
4.アジャイル型のメリット・デメリット
一方、アジャイル型はどうでしょうか？
4-1.アジャイル型のメリット・デメリット
アジャイル型のメリット・デメリットとしては、以下の点が挙げられます。
＜メリット＞
・短期間でリリースできる
・仕様変更や不具合に柔軟に対応できる
・ユーザーの要望を反映しやすい
＜デメリット＞
・方向性がブレやすい
・スケジュールや進捗、コストの管理がしにくい
4-2.アジャイル型が向いているケース
これを踏まえて、アジャイル型は以下のようなケースに向いていると言えるでしょう。
・開発の目的はあるが、要件や仕様が細かく定まっていない場合
・市場の動向や顧客の反応などによって、システムに変更や修正が生じる可能性が高い開発
→ECサイト、SNSなどのWEBサービス、アプリケーション、ゲームなど
・短期間でサービスをローンチしたい場合
これらの開発手法ごとの特徴やメリット・デメリットをもっとくわしく知りたい方は、別記事「システム開発の4手法｜ウォーターフォール型、アジャイル型など解説」もぜひ読んでみてください。
5.システム開発でプロセスが重要な理由
ここまで、システム開発の「プロセス＝工程を分けて流れに沿って進めること」について説明してきました。
が、そもそもなぜシステム開発はこのように工程を分け、一定の流れに沿って行う必要があるのでしょうか？
特にプロセスを決めず、自由に開発を進めてはいけないのでしょうか？
そのような疑問に答えるためにも、ここであらためてシステム開発におけるプロセスの重要性を考えておきましょう。
5-1.プロダクトの品質確保
まず第一に、システムをプロセスに沿って開発することで、成果物のクオリティを確保することができます。
ウォーターフォール型であれば各工程ごと、アジャイル型であれば各機能の開発サイクルごとに確認やレビューを行うため、品質が細かくチェックされます。
その繰り返しがあることによって、システムのクオリティを保つ、あるいは高めることが可能になります。
5-2.プロジェクト内での認識統一
開発の流れや各工程ですべきことがあらかじめ決まっていれば、プロジェクトチームのメンバーが共通の認識で開発を進めることができます。
どの段階でどんな作業をするのか、今どこまで進んでいるのかを全員が把握することで、齟齬がなくスムーズに分担作業が可能になるのです。
また、開発を外注する場合は、発注者側と開発会社側の認識統一も必要です。
プロセスが決められていれば、それをもとに「今どこまで進んでいるのか」「これから何をするのか」「この機能開発はどの段階で行われるのか」といった進捗やスケジュールを共有できるため、コミュニケーションもとりやすく、結果として発注者の満足度を高めることにもつながります。
5-3.納期の遵守
システム開発を自由度高く進めていると、変更や修正がたびたび発生することで開発期間が延長されやすく、納期遅れにつながるリスクがあります。
その点プロセスが決まっていれば、それに沿ってスケジュールも立てやすく、進捗管理がしやすいというメリットがあります。
納期遅れを未然に防ぎ、予定通りのリリースを目指せるのです。
5-4.コスト削減
納期の順守と同時に、コストコントロールがしやすくなるのもメリットです。
開発がどのように進められるか、どこで誰が何をするか、どの程度の工数と期間がかかるかといったことが把握できれば、それに対して最少のコストで対応する方法を考えることも可能です。
無駄なコストが発生させず、全体の開発費用削減につながります。
5-5.経験値の活用
あらかじめ決められたプロセスにのっとって開発すると、それはプロジェクトメンバーにとって経験値として蓄積されます。
となると、次に同じプロセスで開発をする際に、その知見を活かしてよりよい成果があげられるようになるでしょう。
たとえば、同じウォーターフォール型の開発でも、回数を重ねれば失敗は少なくなり、成功するためのポイントが身についていきます。
これが毎回プロセスを決めずに自由な進め方で開発していると、そこで得た経験や知識を体系的に積み上げることは難しいでしょう。
システム開発を成功させる要因はさまざまですが、そのひとつがエンジニアのスキルと経験です。
それらを高めるためにも、プロセスに従って開発を進める必要があるのです。
6.システム開発プロセスで用いられる略語
さて、システム開発のプロセスについて、基本的なことはひと通り理解していただけたかと思います。
ただ、最後にもうひとつ知っておきたいことがあります。
それは、システム開発のプロセスでよく用いられる略語とその意味です。
主な略語を表にまとめましたので、以下を見てください。
これらを知っておくことで、開発に携わるメンバー同士、または発注者と開発企業との間でコミュニケーションがとりやすくなり、プロセスをスムーズに進捗させることができるでしょう。
| 略語 | 意味 | 英語表記 |
| SP | 企画、システム企画 | System Planning |
| SA | 要求分析 | System Architectural design、 System Analysis |
| RD | 要件定義 | Requirement Definition |
| ED | 外部設計 | External Design |
| BD | 基本設計 | Basic Design |
| ID | 内部設計 | Internal Design |
| DD | 詳細設計 | Detail Design |
| FD | 機能設計 | Function Design |
| SS | 構造設計 | System Structure Design |
| UI | UI基本設計 | User Interface |
| PD | プログラム設計 | Program Design |
| PG | プログラミング | Programing |
| CD | コーディング | Coding |
| UT | 単体テスト | Unit Test |
| IT | 結合テスト | Integration Test |
| ST | システムテスト | System Test |
| OT | 運用テスト | Operation Test |
| PT | 総合テスト | Product Test |
7.まとめ
いかがでしたか？
システム開発のプロセスについて、よく理解できたかと思います。
では最後にあらためて、記事の内容を振り返りましょう。
◎システム開発のプロセスは、以下の7ステップ
1）要件定義
2）外部設計
3）内部設計
4）コーディング
5）テスト
6）リリース
7）運用・保守
◎システム開発プロセスの主な種類は、
・ウォーターフォール型
・アジャイル型
・プロトタイプ型
・スパイラル型
◎システム開発でプロセスが重要な理由は、
・プロダクトの品質確保
・プロジェクト内での認識統一
・納期の遵守
・コスト削減
・経験値の活用
これを踏まえて、あなたの会社のシステム開発が適切なプロセスで行われるよう願っています。
