はじめに
システム開発プロジェクトのプロマネやリーダーを担う若手向けに、私の経験をもとにシステム開発のプロセス面を中心にお伝えしていこうと思います。
当記事では、システム開発工程の全体的な流れを整理しました。
前提
システム開発工程については、お客様やベンダーによって名称や定義が異なることが多々あります。そのため、参画するプロジェクトに応じて工程毎の定義の認識合わせをするようにしてください。
とはいっても、基本的なパターンが頭に入っていると、「ああこのプロジェクトではこういう定義にすればいいのね」と、頭をすぐに切り替えることができると思います。
システム開発工程の流れ
システム開発に携わっている方ならば一度は目にしているであろうシステム開発のV字型モデルと言われるやつです。左側の工程でシステムを開発し、右側の工程で検証・評価するような流れになっています。
それでは詳しくみてみましょう。
IT戦略立案
システム開発工程というと、要件定義から始まる図が多いと思いますが、ここではIT戦略策定から記載しています。
私たちITベンダーが携わるのは、要件定義工程からが多いのですが、顧客企業の情報システム部門では、経営戦略・事業戦略に合わせたIT戦略を立案しています。内容によっては、コンサル企業が支援に入る場合もあります。
システム開発をすることだけがIT戦略ではなく、「IT人材育成」や「セキュリティ対策」などもIT戦略の検討要素には含まれます。
これらのIT戦略と方向性を合わせた「IT施策」、すなわち「システム企画」を立案するのが次の工程となります。
システム企画立案
システム企画では、事業課題に対してのIT施策を検討し、費用対効果を評価した上で、「いいね、進めよう」とGOとなるか、「この企画はやめといた方がよくない？」とSTOPとなるかを判断します。
単純にGO、STOPがかかるというよりかは、優先順位がつけられて「今年度はこのIT施策を実施する」と決まります。なお、企画の内容に応じて、コンサル企業や大手ITベンダーが支援に入ります。
シンプルな例でいえば、「サーバ保守切れに伴ってオンプレ環境からクラウド環境に移行する企画」でしょうか。
コスト面では、初期コストやランニングコストを算出しますが、これも運用によっては「オンプレのまま更新した方がよくない？」となったりします。（以下サンプル）
ただ、災害対策を考えると、オンプレは設備構築が大変なのでクラウドの方が楽で安全では、という評価もできたりします。では、運用はオンプレ環境、バックアップはクラウド環境、といった「ハイブリッド構成」はどうか。といった方向性になったりするわけですね。
もちろん、対象サーバの役割（事業上の重要性）によって評価が変わってくるので、一概にクラウドが良いとかオンプレが良い、いやハイブリッド構成だ、といったような評価はできません。
前述のようなサーバ更新の企画はシンプルですが、「需要予測を用いた在庫管理の実現」といったような企画に対しては、それをどのように実現するのか技術面の検証が必要になったりもします。そうなると、「本格的な開発に入る前に、まずはPoCをやってみて評価しようか」という流れになったりします。
また、開発するシステムによっては、アーキテクチャ（方式）もこの工程で決めます。画面機能をつくるにしても従来のモノリシックなアーキテクチャで良いのか、マイクロサービスアーキテクチャにするのかによって開発の難易度が変わるため。
いずれにしても、企画工程でシステム化の方向性を決定した上で、次工程の要件定義へと移っていきます。
なお、システム企画工程では、「この企画をどの会社にやってもらうのか？」というITベンダーの選定も行われます。元請けITベンダー側の仕事「RFP受領〜システム提案」はこのタイミングで行われるわけですね。
要件定義
前工程で決まったシステム化の方針を受けて、具体的にどのようなシステムを作るのかを要件に落とし込んでいきます。
要件定義では、システム機能に目が行きがちですが、定義する要件は「業務要件」「機能要件」「非機能要件」の３つに分かれます。
１）業務要件
２）機能要件
３）非機能要件
１つ目の業務要件の定義では、現行業務や現行システムを整理した上で、現行の課題箇所を特定して、その箇所に対して、新システムの本番化後には、どのような形になるのかを定義します。（成果物例：新業務フロー）
２つ目の機能要件の定義では、新業務フローを受けて、そのフローの中でどのような機能が必要かを定義していきます。画面帳票・バッチなどを列挙し、その実現に必要な主たるテーブル・ファイル群も整理していきます。
３つ目の非機能要件の定義では、画面の応答性などの性能面や耐障害性、セキュリティ要件等を決めていきます。
なお、要件定義からはITベンダーが本格的に参画してプロジェクトを推進します。要件定義は顧客主体の契約（準委任契約）となりますが、私の経験上、ITベンダー側が旗振りをしながら進めることになります。
基本設計
要件定義で定義された要件にもとづいて、システム機能の外部仕様を中心に決定していきます。ちなみに、外部仕様とはエンドユーザーに見える仕様のことです。
基本設計では、大きく「方式設計」「機能設計」「その他の設計」に分けることができます。
方式設計は、インフラやアプリケーションのアーキテクチャを決める作業です。例えば、ハードウェア・ミドルウェア・フレームワークといったシステム基盤やアプリケーション全体の構造、テスト方式などです。
機能設計では、画面・帳票・バッチの入出力設計に加えて、テーブル設計を行います。また、他システムとのデータ授受がある場合は外部インターフェース設計を行います。
その他の設計要素として、非機能要件で定義された性能設計やセキュリティ設計、新システムへの移行方法を定義する移行設計、業務とシステムの両面から運用方法を決定する運用設計なども実施します。
詳細設計
基本設計の内容にもとづいて、インフラやアプリケーションの実現内容に必要な詳細な仕様を決定していきます。
インフラでは、サーバやミドルウェアの各種設定情報を記載する「パラメータシート」作成し、アプリケーションでは各機能個別の詳細設計書と、機能共通の詳細設計書をそれぞれ整理します。
実装
言わずもがな、ソフトウェアの実装を行う工程です。
コーディング、製造、製作など会社によって様々な呼び方があります。
後述の「ユニットテスト」も同じ工程で行います。
ユニットテスト
ユニットテストは、クラスやモジュール単位のテストを指しています。
主にホワイトボックス手法を用いて、ソースコードの条件分岐を網羅する（C1カバレッジ）をテストを行います。
ユニットテストは、実装と同じ工程にて実施します。
実装→ユニットテスト→次の実装・・・といったように、個別の実装が終わったタイミングでユニットテストが開始できるためですね（全ての実装が完了するまで待つ必要が無い）
なお、会社によってはクラス・モジュール単位のテストのことを「単体テスト」と呼ぶ場合もあります。
（システム機能）単体テスト
システム機能の単体テストです。
基本設計書や詳細設計書の単一機能レベルでのテストであり、個々の画面やバッチ機能の動作を確認します。
こちらも基本的にはホワイトボックス手法を用いますが、基本設計や詳細設計書の条件分岐を網羅するようにテスト仕様書を作成してテストを行います。
実装者の思い込みを防ぐ目的で、実装者とテスト設計者は別人格（別の人）をアサインすることが望ましいとされます。
会社によっては、こちらのテスト工程を「ソフトウェア結合テスト」と呼ぶ場合もあります。
（システム機能）結合テスト
ここはどの会社でもおおよそ同じ定義な気がしますが、システム機能を結合して動作を確認します。
自社開発範囲を「システム内部」、自社開発範囲外を「システム外部」と定義して、それぞれ「内部結合テスト」と「外部結合テスト
に工程を分けて実施することがほとんどです。
内部結合テストでは、機能結合（画面間、バッチ機能間）、データ結合（登録・参照・更新・削除）、その他の結合（自社開発担当のシステム基盤等）といったような要素から検証を行います。
外部結合テストでは、前述の通り、自社開発範囲外のシステムと結合したテストを行います。現行システムとの結合テストが多いと思いますが、並行して開発している他ベンダーとのテストを行う場合もあります。
基本的に結合テストを終えたタイミングで「システム機能」の検証は終えている状態となります。
システムテスト（総合テスト）
関連した全てのシステムを結合して、新業務フローの流れに沿って、本番運用を想定したテストを実施します。
本番を想定したテストであるため、業務の実施タイミング（朝・昼・夜、月初・月末など）や、同じ業務を複数回実施するサイクルテストなども含まれます。
また、システムテストでは、非機能面のテストも行います。
例）
・負荷テスト
・ロングランテスト
・耐障害性テスト
・セキュリティテスト
・運用テスト（また、システム監視・システム障害対応・システム保守等）
開発したシステムの総合的な検証となるため、会社によっては「総合テスト」と呼ぶ場合もあります。
受け入れテスト
ITベンダーのシステムテストが完了した後に、顧客企業側での受け入れテストが行われます。
基本的には、要件定義や基本設計に基づいたテストになりますが、全ての検証をすることはできないので、主要な業務フローに沿って画面を打鍵してみたり、いじわるな操作（探索的テスト）をみたりして、機能面を確認することが多いと思います。
さいごに
最初の画像をもう一度載せておきます。
