2.1システム開発技術

利用者が「こんなシステムがほしい」と考えてから、実際に動くシステムが手元に届くまでには、いくつもの工程を順番に踏みます。この工程の流れと、各工程で何を確認するのかを理解することが、システム開発技術の出発点です。

2.1.1開発の流れと要件

• 要件定義＝利用者が何を実現したいかを明確にする最初の工程。ここで固めた要件が以降の設計・実装のよりどころになります。
• 設計＝要件を、実際に作れる形（画面・データ・処理の構造）へ落とし込む工程。実装＝設計に基づいて実際にプログラムを作る工程。
• テスト＝作ったものが要件どおりに動くかを検証する工程。受入れ＝発注者（利用者側）が、納品されたシステムを実際に確認し、要件を満たしているか最終的に承認する工程。
• 機能要件＝システムが具体的に何をするか（例：ログインできる、注文を受け付ける）。非機能要件＝性能・信頼性・セキュリティなど機能以外の品質面の要件（例：応答時間3秒以内、稼働率99.9%）。

2.1.2テストの段階と手法

• 単体テスト＝プログラムの部品（モジュール）1つ単位でのテスト。結合テスト＝複数のモジュールを組み合わせたときに正しく連携するかのテスト。
• システムテスト＝システム全体を通して、要件（性能・セキュリティ含む）を満たすかを検証するテスト。運用テスト＝実際の業務環境に近い条件で、利用者が使えるかを最終確認するテスト。
• ホワイトボックステスト＝プログラムの内部構造（処理の流れ）に着目してテストケースを作る手法。ブラックボックステスト＝内部構造を見ず、入力と出力の対応だけに着目してテストケースを作る手法。
• モジュール分割＝プログラムを扱いやすい部品（モジュール）に分ける設計の考え方。レビュー＝人の目で成果物（設計書・プログラム等）を確認し、早い段階で誤りを見つける活動。工程の後になるほど誤りの修正コストは大きくなるため、早期発見が重視されます。

小さな社内向け経費精算システムを作る場面を考えてみましょう。まず要件定義で「申請者が経費を入力し、上長が承認できること」といった機能要件と、「同時に100人が使っても3秒以内に応答すること」といった非機能要件を整理します。次の設計工程では、この要件を画面・データベース・処理の単位に分解し、扱いやすい部品にするモジュール分割を行います。実装でモジュールごとにプログラムを書いたら、まず各モジュール単体で正しく動くかを単体テストで確認し、次に「申請入力モジュール」と「承認処理モジュール」を組み合わせて連携を結合テストで確認します。さらにシステム全体を通して性能やセキュリティも含めて確認するシステムテストを行い、最後に実際の利用部門が業務に近い形で使ってみる運用テストを経て、発注者が最終的に受入れを行います。テストのケースを作る際、承認ロジックの内部処理の分岐を網羅するように狙うならホワイトボックステスト、逆に「この金額を入力したらこの結果が返る」という入出力だけに着目するならブラックボックステストという使い分けになります。そして各工程の節目でレビューを挟むことで、実装が終わってから要件の誤りに気づく、といった手戻りの大きい事態を防ぎます。

2.1.3この節のまとめ

• 開発の流れは要件定義→設計→実装→テスト→受入れ。機能要件（何をするか）と非機能要件（性能等の品質）を区別
• テストは単体→結合→システム→運用の順で範囲が拡大。ホワイトボックス＝内部構造・ブラックボックス＝入出力
• モジュール分割で扱いやすい部品に分解。レビューは早期に誤りを見つけ修正コストを抑える