システム開発技術（要件定義・設計・実装・テスト・導入・保守）

この単元の範囲

基本情報技術者試験のシラバスは、大分類4「開発技術」を中分類12「システム開発技術」と中分類13「ソフトウェア開発管理技術」の2つに分けている。このうち中分類12は、ソフトウェアが生まれてから役目を終えるまでの一生（ソフトウェアライフサイクル）を、「1. システム要件定義・ソフトウェア要件定義」「2. 設計」「3. 実装・構築」「4. 統合・テスト」「5. 導入・受入れ支援」「6. 保守・廃棄」という6つの小分類として順番に扱う。ITパスポートで学んだ「システム開発の大まかな流れ」を、より実務に近い粒度の用語（アーキテクチャ、ホワイトボックステスト、リファクタリングなど）で学び直すのがこの単元の到達目標になる。

1. システム要件定義・ソフトウェア要件定義

この段階では「開発対象のシステムが何をすべきか」を明確にする。業務の流れを図式化する業務モデリングでは、データの流れを表すDFD（データフローダイアグラム）、データの構造を表すE-R図、オブジェクト指向の設計図であるUMLなどの表記法を用いる。UMLには利用者（アクター）が何をするかをまとめるユースケース図、処理の時間的な流れを表すシーケンス図、オブジェクトの状態遷移を表すステートマシン図など目的別の図が用意されている。要件は、画面設計・帳票設計・伝票設計など「システムが何をすべきか」をまとめる機能要件と、レスポンスタイム・スループットといった性能要件やセキュリティ要件・移行要件・テスト要件・運用要件・保守要件などの非機能要件に分けて整理する。アジャイル開発では、利用者の要望を「〇〇として、△△したい。なぜなら□□だから」という短い文で表すユーザーストーリーを積み上げてプロダクトバックログを作り、大きなまとまりをエピック、作業量の目安をストーリーポイントで見積もる。要件定義書と設計書・テスト項目の対応関係を保つ双方向の追跡可能性（トレーサビリティ）の確保も重要である。

2. 設計

要件を「どう実現するか」に落とし込む段階。まずシステム全体の骨組みであるアーキテクチャを決める。近年は自社でサーバを持たずクラウド事業者のインフラ（IaaS）・実行基盤（PaaS）・ソフトウェア（SaaS）を組み合わせる設計が主流になり、機能を小さなサービス単位に分割するマイクロサービスアーキテクチャや、サーバの管理をクラウド側に任せるサーバレスアーキテクチャも採用される。データベース設計では、表形式のRDBに加え、キーバリュー型・ドキュメント型など多様なデータ構造を扱うNoSQLデータベースなど用途に応じた選択がある。品質の良し悪しを測る規格が、国際規格ISO/IEC 25010に整合する日本産業規格JIS X 25010で、ソフトウェアそのものの出来を測る製品品質モデル（機能適合性・性能効率性・互換性・使用性・信頼性・セキュリティ・保守性・移植性の8特性）と、実際に使ったときの満足度を測る利用時の品質モデル（有効性・効率性・満足性・リスク回避性・利用状況網羅性の5特性）に分かれる。処理手順を図で表す技法にはNS図（Nassi-Shneiderman図）・HIPO・ジャクソン法・ワーニエ法があり、機能をモジュールに分割する設計原則としてオブジェクト指向設計の5原則であるSOLID、業務知識をモデルの中心に据えるドメイン駆動設計（DDD）、STS分割・TR分割・MVCモデルなどがある。設計内容の妥当性は、複数人でコードを読み合うコードレビュー、手順に沿って処理を追うウォークスルー、より形式的なインスペクションによって確認する。

3. 実装・構築

設計をプログラムコードに変換する段階。読みやすいコードにするため、字下げ（インデンテーション）を揃え、変数名やクラス名に一貫した命名規則を用いる。品質を測る指標の一つがサイクロマティック複雑度で、条件分岐が多いほど値が大きくなり、テストすべき経路の数の目安になる。コードの検証は、プログラムを実行せずコードを読んで欠陥を見つける静的解析（コードインスペクション、ピアコードレビュー）と、実際に動かして確認する動的テストに分かれる。動的テストでは、意図した位置で処理を止めるブレークポイント、想定どおりの値かを検証するアサーション、動作を追跡するデバッガ・トレーサーといったツールを使う。個々のモジュール単位で行うユニットテストでは、まだ実装されていない呼び出し先を代替するスタブ、呼び出し元を代替するドライバを用いる。テストケースの網羅基準には、全命令を最低1回は実行する命令網羅、条件式の真偽値を網羅する条件網羅・判定条件網羅・複数条件網羅などの段階があり、境界値の周辺を重点的に確認する限界値分析法、入力を同じ性質のグループに分けて代表値だけ確認する同値分析法も併用される。

4. 統合・テスト

単体で作られたモジュールを組み合わせ、システム全体として正しく動くかを確認する段階。モジュールを組み合わせる順序には、上位モジュールから順にテストを進めるトップダウンテスト（未完成の下位モジュールをスタブで代替）と、逆に末端の下位モジュールから積み上げるボトムアップテスト（未完成の上位モジュールをドライバで代替）がある。テストの種類は目的によって多岐にわたり、要求どおりの機能かを見る機能テスト、応答時間や処理量を確認する性能テスト・負荷テスト、想定を超えるアクセスへの耐性を見るセキュリティテスト、想定外の入力を大量に送り込んで欠陥を探すファジング、修正の副作用で既存機能が壊れていないかを確認する回帰テスト（リグレッションテスト）、決められた手順に縛られずテスト担当者の知見で自由に探索する探索的テストなどがある。要件定義段階で整理した双方向の追跡可能性を用いて、どのテストがどの要件を検証しているかを確認しながら進める。

5. 導入・受入れ支援

完成したシステムを実際の利用環境に導入し、発注者側が「納品物を受け取ってよいか」を判断する段階。導入計画では、導入可否判断基準・導入手順・導入体制をあらかじめ定め、本番前に仮想環境で最終確認を行うことが多い。利用者向けにはウィザードや学習書（チュートリアル）、オンラインヘルプといった利用者用文書類、e-Learning・Web Based Trainingなどの教育訓練システムを準備する。受入れ側は受入れ基準・受入れ体制を整えたうえで受入れテストを実施し、業務上の使いやすさを見る使用性テストなども行いながら検収を行う。妥当性確認テストでは、目的・成功基準（期待される結果）・適用する技法・環境条件を事前に明確にしておくことが求められ、不具合が見つかった場合は不具合の根本原因を特定した上で是正処置につなげる。

6. 保守・廃棄

稼働後のシステムを安定的に使い続け、最終的に役目を終えたシステムを安全に廃棄するまでを扱う。保守は目的によって、不具合を直す是正保守、機能を良くする改良保守、将来の不具合を未然に防ぐ予防保守、稼働環境（OSやミドルウェアなど）の変化に合わせる適応保守、保守作業そのものをしやすくする完全化保守に分類される。保守作業では、修正が既存機能に悪影響を与えていないかを回帰テストで確認し、外部から見た振る舞いを変えずに内部構造だけを整理するリファクタリングや、既存プログラムから仕様を読み解くリバースエンジニアリングも行われる。現地に出向くオンサイト保守と、ネットワーク越しに対応する遠隔保守がある。システムを廃棄する際は、廃棄計画を立案し、開発プロセスからの成果物や問題管理手続きを次のシステムに引き継ぎ、新旧環境を並行運用してから旧環境を段階的に停止し、廃棄後も一定期間は関連データを保持してアクセス可能な状態を確保することが求められる。

---

参考文献

• IPA「基本情報技術者試験シラバス Ver.9.2」大分類4「開発技術」中分類12「システム開発技術」（p.45-57）: https://www.ipa.go.jp/shiken/syllabus/omgdg50000005kpe-att/syllabus_fe_ver9_2.pdf
• IPA シラバス一覧・概要ページ: https://www.ipa.go.jp/shiken/syllabus/gaiyou.html
• JIS X 25010（ソフトウェア品質モデル）解説: https://kikakurui.com/x2/X25010-2013-01.html