システムを実際に作る開発会社だけではなく、システムを使用するユーザー側もシステム開発・ソフトウェア開発に携わることになります。すでにシステム開発プロジェクトに参画している人でも、「システム開発の全体像が分からない」という人は少なくないと思います。システム開発プロジェクトを成功に導くためにも、開発工程や開発手法への理解は必要になります。この記事では、基本的なシステム開発の工程や、代表的な開発手法であるウォーターフォールモデルやアジャイルモデルなどについて解説します。
システム開発工程とは
システム開発における各工程でどのようなことが行われているのかを詳しく解説します。開発工程の各工程は、要件定義、設計、開発、テスト、リリース、運用・保守が大まかな流れとなります。一般的には、要件定義に近いほど上流工程と呼ばれ、保守や運用に近いほど下流工程と呼ばれます。これを把握することで自分が現在どの工程を担当しているのか、実際にシステムが使えるのはいつなのかなどがわかります。
要件定義
まず一番初めに行うのが要件定義です。要件定義の工程ではユーザーとベンダーがシステムの開発内容、開発手法、導入や運用方法、予算、リリース期間など、システム開発に必要な要件を決めていきます。「どのようなシステムが必要」といったイメージや業務上の課題点を開発者に伝えます。要件定義が疎かだと希望しているシステムと異なったものが出来上がってしまいかねませんので、しっかりと要望を伝えて認識を合わせる必要があります。システム開発は、要件定義で決めた内容に基づいて次工程に進んでいくので、開発工程における設計図を作る“最上流工程”であり、もっとも重要なフェーズです。
基本設計(外部設計)
システム開発者は要件定義に基づきシステムを設計します。基本設計では、要件定義の工程で決めた内容を基に、「ユーザーから見える部分」を決定する工程です。実際にユーザーが使う画面などが含まれますので、ユーザーの使い勝手や効率に直結する工程となります。また、この工程で作成される基本設計書はユーザーが確認する成果物であるため、専門用語や複雑なデータが記載されることは少ないです。
詳細設計(内部設計)
基本設計が完了したら、その内容を基に詳細設計を行います。詳細設計はユーザー視点ではなく、開発者の視点で設計する必要があります。実装予定の機能をモジュールごとに分割し、具体的な実装を想定した「機能仕様書」「データフロー図」「データベース物理設計書」など、より専門的な資料を作成しながら、プログラミング工程に進むための設計書を確定していきます。
開発(プログラミング)
詳細設計が完了したら開発に移ります。各ベンダーのSEやプログラマーが詳細設計書の内容に基づき、プログラミングを行い、システムを作成していきます。
単体テスト
プログラミングが終わってシステムが出来上がったらテストを行います。作成したプログラムが要件定義で決めた通りの動きをするかを確認していきます。単体でテストではプログラムを構成する単位ごとに正しく機能しているかをチェックするテストです。モジュール結合前の段階でエラーチェックができるため、工程後半でのバグ修正の負担を減らすことができます。
結合テスト
単体テストで各モジュールに不具合がないことを確認したら、各モジュールを組み合わせて実際に動作する状態に近い状態で結合テストを行います。データの受け渡しやタイミング、インターフェースに問題がないかどうか確認します。
システムテスト
結合テストでシステム間の連携に問題がないことを確認したら、いよいよシステム全体に不具合がないかの確認をするシステムテストを行います。すべてのプログラムが要件定義で決めた通りの動きをするかを確認するのはもちろん、アクセス過多時の耐久性や処理速度の速さなどあらゆる角度からテストを行います。ここで問題なく作動すれば、システムをユーザーに引き渡されます。
運用テスト
運用テストとは、実際にユーザーにリリースし、稼働してもらうテストとなります。実際にユーザーが使う時に起こりうるトラブルや不具合などを想像しながら細かくチェックしていきます。これ以前のテストは開発者が行いますが、このテストではユーザー視点で動作チェックをするのが大きな違いです。運用テストはリリース前の最終テストとなるため、システムのクオリティーに直結する重要な工程といえます。
システム移行
テストの結果問題がなければ、旧システムから新システムに移行します。新システムにデータを移行しても想定通りの動作をするよう、さまざまな懸念点を考慮しながら移行手順書を作成し、システム移行がスムーズに進むようにしておくことが求められます。システム移行をする方法としては、旧システムから新システムに一気に切り替える一斉移行という方法と、機能ごとに徐々に切り替えていく順次移行があります。
運用・保守
リリースしたシステムを問題なく稼働し続けるには保守・運用業務が必要になります。運用とは、システムが正常に作動するかを定期的に確認し、トラブルが起きないようにすることを指します。一方保守とは、システムにトラブルや不具合が発生した際に対応することに加え、アップデートなどシステム変更の必要が発生した場合の変更作業も含まれます。リリース後にユーザーがシステムを使っていく中でバグあるいは改善点が見つかることもあります。ユーザー側は実際にシステムを使ってみて「問題点が見つかった」「使いにくい」といった要望が出てきたらしっかりと開発者に伝える必要があります。
開発工程モデルとは
開発工程モデルとは、開発プロセスのことです。開発工程モデルは、前述した開発フェーズをどのように進めていくかによって分類されます。「ウォーターフォール型」と「アジャイル型」という代表的な2種類の開発工程モデルを解説します。
ウォーターフォール型
「ウォーターフォール」は、「滝」という意味です。つまりウォーターフォール型とは、滝のように上流から下流に向かって進んでいき、戻ることのない一方通行の開発プロセスのことを表しています。つまり「要件定義」から「運用・保守」まで基本的に前工程に戻らずに開発を進めていきます。
ウォーターフォール型のメリット
ウォーターフォール型のメリットは、事前に決めた計画に従って工程を進めていくため後戻りも少なく、納期やスケジュール管理がしやすいことです。そのため希望するシステムの内容が決まっている、明確に導入時期が決まっているというケースに向いています。
ウォーターフォール型のデメリット
ウォーターフォール型のデメリットは、仕様変更や大きな問題などが発生すると一からやり直しになってしまうため、大幅な納期遅延が発生する危険性があることです。特に要件定義や基本設計などの上流工程にミスがあった場合は、多大な時間やコストが掛かります。納期まで時間がない、スピード感を重視したいのであれば、後述するアジャイル型のほうが向いているかもしれません。
アジャイル型
「アジャイル」は「俊敏な」という意味です。その名の通りスピードが求められるプロジェクトと相性がいい開発工程モデルです。ウォーターフォール型とは逆に、後戻り前提で工程を進めていくため、設計段階ではあえて詳細まで決めず、全体を作りながら随時修正を行っていきます。そのためアジャイル型の工程の場合、モジュールごとに「要件定義」から「リリース」の小サイクルが発生します。
アジャイル型のメリット
アジャイル型のメリットは開発スピードが速いことです。新規事業などで工程や成果物のイメージがつきにくい場合でも、とりあえず開発をスタートできる柔軟さもあります。急な仕様変更やユーザーからの要求に対応可能なことも大きなメリットです。そのためリリースまでの期間が短い、あるいは比較的規模が小さいプロジェクトに向いています。
アジャイル型のデメリット
アジャイル型のデメリットは工程の進捗や状況を把握するのが難しいため、管理しづらいことです。アジャイル型は大枠の方向性を決めて各工程においてすり合わせていくという流れのため、綿密に計画を立てた上で開発を進めるウォーターフォール型と違い、当初の計画との乖離が生じるリスクもあります。
まとめ
この記事では、基本的なシステム開発の工程や、代表的な開発手法であるウォーターフォールモデルやアジャイルモデルなどについて解説しました。自分が担当している工程や、これからチャレンジしてみたい工程を理解することで、今後プロジェクト開発を進めていくための助けになると思います。この記事を参考にして、システム開発の全体像や開発手法について理解を深めていただければと思います。
コメント