システム開発手法

共通フレーム は、ソフトウェア開発ライフサイクル全体を発注者と受注者が同じ言葉で理解 するための標準ガイドラインです（SLCP：Software Life Cycle Process、2013版が最新）。試験で開発手法が出題されたとき、まず「どの工程の話か」を判別することが理解の近道になります。7つの工程が順序立てて進みますが、開発モデル（ウォーターフォールなど）によって 進め方は変わります。

システム開発は複数企業が関わることが多く、発注側と受注側で用語や期待が異なると、要件のズレ、品質問題、遅延などが起こります。共通フレームは、どの業界・企業でも「企画」「要件定義」「開発」などの工程を同じ定義で扱い、意思疎通をスムーズにする役割を果たします。

企画で「何をするか」の方向が決まり、要件定義で「ユーザーが求める具体的な機能」が決まり、設計で「技術的な実装方法」が決まります。この流れを頭に置くと、後述の「要件定義と設計の違い」や「開発モデルの違い」が理解しやすくなります。

試験で最も落としやすいのが「要件定義」と「設計」の混同です。要件定義は**「ユーザーが何を求めているか」を理解して言葉にする工程で、設計は「その要件をどうコンピュータで実現するか」を決める工程**です。この違いを把握すると、開発モデルの選択理由、テスト戦略、契約形態までが自動的に理解できるようになります。

ユースケース：オンラインショップの「在庫不足時の通知」機能

この違いが分かると、「要件変更が頻繁ならアジャイル、要件が確定済みなら請負契約」という判断も自動的に出てきます。

ユーザーが目に見える形で期待する処理・機能です。「このシステムで何ができるか」を直接的に説明するもの。

機能要件は、ユーザーとの要件定義の場面でまず出てくるものです。多くの場合、「○○ができるようにしてほしい」という形で表現されます。

機能そのものではなく、システムが満たすべき「品質」に関する要件です。ユーザーからは直接は要望されないことが多いですが、システムの使いやすさ、信頼性、セキュリティに大きく影響します。

なぜ非機能要件が重要か：多くの品質問題（遅い、落ちやすい、セキュリティ侵害）は、非機能要件の定義が甘かったために発生します。試験では、特に性能、可用性、セキュリティがよく問われます。

ユーザーとの対話のなかで、要件を漏らさず、正確に把握し、ユーザーとの認識ズレを早期に解消するための手法群です。試験では、各技法を「どんなときに使うか」で判別することが出題されます。

システム開発は、プロジェクトの特性によって、どの手法を選ぶかが決まります。試験で頻出なのは：

この4つの軸で判断すると、最適な開発モデルが決まります。

V字モデルは、「ウォーターフォール」に「テスト工程との対応関係」を追加した、より品質重視の開発モデルです。単なる工程図ではなく、各開発工程の出力物が、後段のテスト工程の入力・検証基準になる という因果関係を視覚化しています。

開発工程は左上から下（V字の底部）へ進み（要件定義→基本設計→詳細設計→実装）、その後、対応するテスト工程がV字の底部（実装）から右上へ向かいます（単体テスト→統合テスト→UAT）。この形が「V字」に見えることから名付けられました。重要なのは、テストを後付けではなく、開発の各段階で行うことで、品質を段階的に組み込むという考え方です。

ウォーターフォール開発では、テストは実装の後期に一度だけ行われるため、以下の問題が起こります：

V字モデルは、各開発工程と対応するテスト工程を明示することで、これらを防ぎます。

両者とも「左から右へ順に工程を進める」という点では同じです。違いは：

試験では、「V字モデル」という用語が出たら、必ず「テスト工程との対応」を思い出してください。

アジャイル（Agile）は、「素早い・敏捷な」という意味の英単語です。アジャイル開発とは、短い反復サイクル（1～4週間）で、機能の実装とテストを繰り返しながら、顧客フィードバックを受けて段階的に完成させていく開発方法です。

ウォーターフォール・V字モデルは「最初に全要件を決めて、後から変更は難しい」という前提でしたが、アジャイルは「要件は段階的に確認しながら進める。変更は当たり前」という前提に立ちます。

Web業界やスタートアップでは、市場のニーズが急速に変わります。その環境で「半年後に要件をすべて決めて、その通りに作る」というウォーターフォールは現実的ではありません。アジャイルは、このような変化が当たり前の環境で価値を生み出すための手法です。

2001年にアジャイル宣言という指針が作られました。これは「ウォーターフォール的な重厚なプロセスより、人と人のコミュニケーションと価値提供を優先しよう」という宣言です。

これらの価値観は、ウォーターフォールとの対比として理解すると、アジャイルの特徴が鮮明になります。

スクラムは、アジャイルの最も一般的な実装方法です。1 スプリント（1〜4 週）ごとに、要件 → 設計 → 実装 → テスト → レビューの全工程を回します。

スクラムは3つの役割を厳密に分ける。試験では「PO と SM の違いを言え」という問題が頻出です。

試験での頻出混同：POはプロジェクトマネージャーではない。SMが指示命令するのではなく、障害を除去するサポーター。

各イベントは時間を厳密に守ります（タイムボックス）。これがスクラムのリズムを作ります。

XP は、スクラムを技術面から支える開発プラクティスの集合です。コード品質、テスト自動化、迅速なリリースを重視します。

カンバンは、スクラムより軽量な反復管理手法です。WIP（Work In Progress）制限 が特徴です。

DevOps は、開発と運用を分断せず、一体化させる 考え方です。CI/CD、インフラの自動化、継続的監視を通じて、迅速で安定したリリースを実現します。

テストは、V字モデルでも DevOps でも全工程に組み込まれます。試験では、各テスト段階の目的と手法を区分けすることが重要です。

ソースコードの内部ロジックを検証します。開発者が単体テストで実施します。

内部コードを知らず、仕様と入出力だけで検証します。QA・ユーザーが実施します。

複数モジュールを統合するときの順序と方法です。

コード・ドキュメント・設計の品質を高めるために、作成者以外が検証します。

システム開発では、いきなり 何を作るか を決めるのではなく、まず なぜ必要なのか と 誰が何を求めているのか を整理します。この考え方を体系化したものが BABOK です。

BABOK は、ビジネスアナリシスの知識体系をまとめたガイドです。重要なのは、固定された工程順序を規定する本ではない ことです。知識エリア と タスク を整理したものであり、ウォーターフォールのように「この順番で必ず実行する」と決めるものではありません。

試験でよく問われるのは、要求の種類です。要求 と一口に言っても、次のように分かれます。

機能要求 は ソリューション要求 の中に含まれます。一方で、品質や運用条件のような話は 非機能要求 であり、機能要求 と同一ではありません。

知識エリア = 開発フェーズ、BABOK = 実行順序の標準 と読んだ時点で危険です。BABOK は、ビジネスアナリストが何を考え、何を整理するかをまとめたガイドだと押さえてください。

システムの構造・動作を図で表現する標準言語です。試験では全 13 種を覚える必要はなく、主な 8 種の役割を理解します。

データの流れと処理を図で整理します。要件定義・基本設計で使われます。

実際の開発現場での対応を示します。

発注者（クライアント）と受託者の関係で、リスク配分が異なります。試験では、各形態の責任範囲と費用体系の違いを理解します。

開発見積では、何を基準に規模を見積もるか が手法ごとに異なります。試験では、ソースコード行数を使うのか 利用者から見える機能量を使うのか 過去データで推定するのか を切り分けられることが重要です。

判断のコツは、まだ実装方式が固まっていないなら FP 法、詳細設計後で作業分解できるならボトムアップ法、類似案件の実績があるならパラメトリック法 と考えることです。

どれも 一度で作り切らない という点では似ていますが、目的が異なります。

オブジェクト指向は、現実世界の対象と振る舞いを、部品として整理する考え方 です。UML は、その整理結果を図として表す道具です。オブジェクト指向 = UML ではありません。

UML でよく問われるのは、クラス図は構造、シーケンス図は時系列のやり取り、ユースケース図は利用者から見た機能 という対応です。何を表したい図か を先に決めてから選びます。

OSS の問題では、無料かどうか ではなく、改変物の公開義務があるか 著作権表示や特許条項がどうなっているか を見ます。

プログラミング言語の実行方式は、事前に機械語へ変換するか 実行しながら解釈するか の違いです。

試験では、コンパイル = 事前変換、インタプリタ = 実行しながら解釈 をまず押さえます。個々の言語名は時代で変化しても、この軸は安定しています。

クラウド移行やシステム更改の問題では、性能の上げ方 と 移行時にどこまで作り替えるか を分けて読みます。

❌ よくある間違い：「要件定義でも設計でも、どちらでもシステムの仕様を決める工程」として扱う

✅ 正解：

この違いが分かると、試験の大半の問題が解けるようになります。

❌ よくある間違い：「ウォーターフォール」と「V字モデル」は全く別の開発方法

✅ 正解：

つまり、V字モデルは「ウォーターフォールの進め方を保ちながら、テストをどう対応させるか」を視覚化したものです。別物ではなく、ウォーターフォールの品質管理版です。

❌ よくある間違い：「アジャイル、スクラム、DevOps はどれも短期反復の開発方法」

✅ 正解：粒度と対象範囲が異なります

❌ よくある間違い：「アジャイルは新しいからいつでも使える。ウォーターフォールは古いから避けるべき」

✅ 正解：プロジェクトの特性で選ぶ。アジャイルが向かないプロジェクトもあります

❌ よくある間違い：スタブは「上の代役」、ドライバは「下の代役」

✅ 正解：

覚え方：スタブ = sub（下）、ドライバ = drive（駆動）= 上から下を駆動する

❌ よくある間違い：「C2（パスカバレッジ）>C1（ブランチカバレッジ）>C0（ステートメント）だから、C2 を目指すべき」

✅ 正解：

試験のポイント：実務では C1 が基準になります。

❌ よくある間違い：「ホワイトボックステストは高度、ブラックボックステストは簡単」という混同

✅ 正解：これは「テストの視点」であり、「テストレベル」ではありません

つまり、開発の進み方によって、ホワイトボックスはいつ使い、ブラックボックスはいつ使うかが決まります。

❌ よくある間違い：「LOC 法も FP 法も、どちらも同じようなもの」

✅ 正解：

何を材料に見積もっているか を先に見ると混同しにくくなります。

❌ よくある間違い：「どちらも何度も作り直すから同じ」

✅ 正解：

反復していること自体ではなく、何のために反復するか が違います。

❌ よくある間違い：「OSS はどれも無料で使えるから差は小さい」

✅ 正解：実務では 派生物の公開義務 と 再配布条件 が重要です。特に GPL は、改変物の扱いに強い条件があります。MIT、BSD、Apache は比較的緩やかですが、Apache は特許条項まで見ます。