ブログ

「何のために、どのようなシステムを作るのか」を決める工程です。業務の課題を洗い出し、必要な機能（機能要件）と、性能・セキュリティ・使用環境などの条件（非機能要件）を定義します。成果物は「要件定義書」としてまとめられるのが一般的です。

要件定義の抜け漏れは、後工程になるほど修正のコストが大きくなります。システム開発の失敗原因として最も多く挙げられるのもこの工程です。時間をかけてでも丁寧に進める価値があります。

要件定義の内容をもとに、画面のレイアウトや項目、操作の流れ、出力する帳票、扱うデータの構造などを決めていきます。利用者から見える部分を具体化する工程のため、「外部設計」と呼ばれることもあります。

基本設計の承認後に大きな変更を加えると、作り直しによる追加費用やスケジュール遅延につながりやすくなります。「なんとなくOK」ではなく、納得したうえで承認することが大切です。

基本設計で決めた内容を実現するために、プログラムの内部構造や処理の詳細を設計します。技術的な内容が中心となるため、発注者が細部まで確認する必要は通常ありません。

ただし、この段階で開発会社から仕様に関する質問が来ることがあります。回答が遅れると全体の遅延につながるため、迅速な回答を心がけましょう。

設計書にもとづき、エンジニアが実際にプログラムを作成する工程です。期間としては最も長くなることが多い工程です。

開発中に「やっぱりこの機能も欲しい」と思うことはよくあります。変更自体が悪いわけではありませんが、その都度の影響を把握せずに積み重ねると、予算やスケジュールが大きく膨らみます。

テストはいくつかの段階に分かれています。

• 単体テスト：プログラムの部品ごとに正しく動くかを確認する
• 結合テスト：部品を組み合わせたときに正しく連携するかを確認する
• 総合テスト（システムテスト）：システム全体が要件どおりに動くかを確認する
• 受入テスト：発注者がシステムを実際に操作し、業務で使えるかを確認する

このうち受入テストは、発注者が主体となって行う重要な工程です。実際の業務データや業務シナリオに近い形で操作し、要件を満たしているかを確かめます。受入テストで合格とした後に見つかった問題は、対応の扱いが契約内容によって変わる場合もあるため、十分な時間と人員を確保しておきましょう。

テストを終えたシステムを本番環境に導入し、利用を開始します。既存システムからのデータ移行や、利用者への操作説明もこのタイミングで行われます。

システムはリリースして終わりではありません。稼働後の不具合対応、OSやライブラリの更新への対応、業務の変化に合わせた機能改善など、継続的な運用・保守が必要です。保守の範囲や費用は、開発の契約とは別に取り決めるのが一般的なので、リリース前に内容を確認しておきましょう。