開発工程とは
開発工程とは、システム開発を行ううえで必要なプロセスの集まりのことです。要件定義や設計、運用テストなどが開発工程に該当します。
料理に例えると分かりやすいでしょう。たとえば、カレーであれば「野菜、肉を切る」「切った材料を炒める」などの工程が該当します。「カレーのルーを作る」工程は「調味料を入れる」「一晩寝かす」などの細かなプロセスを含みます。
開発工程に沿って作業する目的は、計画通りに開発をするためです。一連の開発プロセスを工程に分割することで、進捗や品質を管理しやすくなります。具体的な工程の分け方に厳密なルールはなく、企業ごとに異なります。
実際は下記のような名前で呼びます！
- 要件定義
- 詳細設計
- プログラム設計
- プログラミング
- プログラムテスト
- 結合テスト
- 運用テスト
開発工程のモデル
細かい部分は企業によって異なるものの、開発工程には基本となる２種類のモデルが存在するんです！
ウォーターフォールモデル：工程に沿って進める
ウォーターフォールとは、上流から下流へ一方的に流れる水のことです。つまり、ウォーターフォールモデルは、一方通行の工程に沿って進める開発方法のことです。シンプルで分かりやすく、チーム内での状況共有も容易なため、世界中で広く利用されています。
ウォーターフォールモデルの特徴は、工程の後戻りがないことです。工程を決められた順で進めるため前の工程を終えずに次の工程に進むことがありません。この特徴から、ウォーターフォールモデルでは最初の計画が肝心です。
後戻りしなければならない事態を生じさせてはなりません。
後戻りできない、これが期限に追われたりする原因ですね（笑）
皆さんはバッファを積んでしっかりと残業しないようにしましょうね！
また、前半の設計における各工程と後半のテストにおける各工程がそれぞれ対応しているため、別名V字モデルともいわれます。以下に例をあげると、４を中心に３と５、２と６、１と７がそれぞれ対応しています。
アジャイル開発モデル：工程を繰り返して進める
アジャイル開発モデルではウォーターフォールモデルとは逆に、後戻りすることを前提に工程を進めます。この開発モデルで重視されるのはスピードです。アジャイルは「機敏な」という意味で、とにかく各工程をスピーディに進行させます。
ウォーターフォールモデルのように、設計段階で工程の進行を詳細に決めません。設計とテストを行き来しながら完成を目指します。
工程や成果物のイメージがつきにくい新規事業などに適しているといえるでしょう。途中の不具合や要件定義の変更にも柔軟に対応できます。逆に、臨機応変さが求められる以上、工程の進捗や状況をチーム内で安定的に共有するのは大変です。
新しいものを作ったりするときは試行錯誤して作っていきますよね！そんな感じです！
十分に見通しを立てられる開発においては、メリットが少ない方法といえます。
具体的な開発工程
続いて、具体的な開発工程を見ていきましょう。
１．要件定義（RD）
要件定義は、システムに盛り込むべき顧客の要望を明らかにする工程です。英語の頭文字を取った略称で、RD（Requirements Definition）とも呼ばれます。
この工程の成果物は、すべての要件を記載した要件定義書です。要件定義が明確でないと、開発段階で何を盛り込むべきか分からなくなるため、慎重に作成する必要があります。顧客の要望をよく確認したうえで作成しなければ、後々トラブルの原因となるため気をつけましょう。
作成した要件定義書は、開発会社と顧客の双方が責任を持つことになります。
２．基本設計（BD）
基本設計は、具体的に搭載すべき機能や特徴を設計する工程です。BD（Basic Design）や外部設計、インタフェース設計とも呼ばれます。ハードウェア設計やレイアウト、セキュリティ機能など、要件をもとに機能を決めていきます。
この工程における成果物の例は以下のとおりです。
- 基本設計書
- システム構成図
- インタフェース設計書
- 外部設計書
- 方式設計書
- テーブル定義書
- ファイル定義書
また、開発に要する期間や費用について、顧客とすり合わせを行います。
３．詳細設計（DD）
詳細設計は、基本設計で定めた機能を、具体的にプログラムでどう実現するか設計する工程です。DD（Detail Design）やプログラム設計とも呼ばれます。
プログラミングのルールの策定や独自フレームワークのマニュアルなどを制作します。また、単体テストを行うことを想定した単体テスト仕様書もこの段階で作成しておきましょう。この設計をもとに、実際にプログラミングを行うことになります。
４．単体テスト（UT）
単体テストはUT（Unit Test）とも呼ばれ、作成したプログラムが正しく動作するか確認する工程です。詳細設計の工程で作成した単体テスト仕様書をもとに実施します。この工程における成果物は、単体テスト成績書と、そのテストに合格したプログラムです。
単体テストでは多くの人手が必要になります。自動テストプログラムや外注を利用することも少なくありません。不備が見つかり次第、プログラマーが修正を行います。
５．結合テスト（IT）
結合テストは、単体テストで動作確認したプログラム同士が正しく連携するか確認する工程です。IT（Integration Test）とも呼ばれます。この工程の成果物は、結合テスト成績書や実行プログラムです。
結合テストは、基本設計書で定めた機能が実現できているか確認する工程ともいえます。プログラミングや単体テストを外注した場合、受け入れテストを行わなければなりません。専用のテスト環境を整備するため、基本設計の段階でテスト仕様書を作成しておきます。
６．システムテスト（ST）
システムテストは、要件定義の工程で定めた要件が実現しているか確認する工程です。ST（System Test）とも呼ばれます。この工程での成果物はテスト成績書とシステムです。
システムテストでは、テスト環境も実環境に近いものを用意する必要があります。早めに環境を整備するために、この工程も基本設計が終わり次第、進めておかなければなりません。
また、この段階では最終テストを行うことになるため、システムが利用される中で起こりうる、ありとあらゆる状況や出来事を検証する必要があります。それには、システムを実際に利用する現場での知識や経験が欠かせません。
したがって、顧客担当者の協力のうえでテストするのが一般的です。
７．システム移行
多くの場合、顧客は既存のシステムを使っています。したがって、そのシステムから開発したシステムに移行する作業が必要になります。システム移行に失敗しないために、移行手順書を作成しましょう。一斉に移行する場合のほか、段階的に移行する方法があります。
慎重にシステム移行を行っても、万が一の不具合が発生して顧客の業務に支障をきたす可能性があります。その際は、元のシステムに至急戻す必要があるため、その手順も確認しておきましょう。
８．システム運用
移行を終え次第、運用を始めることになります。この段階でうまくいかず、元のシステムに一旦戻すケースもあります。ログ解析などを行い、復旧と安定稼働に努めましょう。なかなか復旧しないようだと、元の開発者が呼び出されたり、損害賠償を請求されたりする恐れがあります。
無事に移行を終え、運用を開始しても、それで終わりではありません。異常が発生すれば対応する必要があるうえ、アップデートなどの対応も継続的に必要になります。
開発工程を理解し、適切な計画でシステムを開発しよう
開発工程とは、システム開発を行ううえで必要なプロセスの集合です。開発工程の例として、ウォーターフォールモデルとアジャイル開発モデルがあります。一般的に開発工程の各区分は以下のとおりです。
これで開発工程の流れは完璧ですね！
- 要件定義
- 基本設計
- 詳細設計
- 単体テスト
- 結合テスト
- システムテスト
- システム移行
- システム運用
以上を踏まえ、計画的なシステム開発を目指しましょう。
コメント