開発技術

SDLC（Systems Development Life Cycle / システム開発ライフサイクル） とは、情報システムを企画・開発・運用・廃棄するまでの一連の流れを体系化したものです。

SDLC は一般的に以下のフェーズで構成されます。

フェーズ	内容	主な成果物
要件定義	利用者の業務ニーズを分析し、システムに求める機能・性能を明確化	要件定義書
設計	要件をもとにシステムの構造・画面・データベースなどを設計	基本設計書、詳細設計書
実装（プログラミング）	設計書に基づきプログラムを作成	ソースコード
テスト	作成したプログラムが要件どおりに動作するか検証	テスト結果報告書
運用・保守	本番環境で稼働させ、障害対応や改善を継続	運用手順書、保守記録

要件定義で顧客の要望を正しく把握できなければ、後工程でどれだけ品質を上げても「使えないシステム」 になってしまいます。要件定義は SDLC において最も重要なフェーズの一つです。

ウォーターフォールモデル

ウォーターフォールモデル は、各フェーズを順番に進め、前のフェーズが完了してから次に進む開発モデルです。名前のとおり水が上から下に流れ落ちるイメージで、後戻りしないことが原則 です。

後戻りしない理由は、各工程が前工程のドキュメント（成果物）に基づいて進むためです。上流工程に誤りが見つかると、設計書・コード・テスト仕様書など大量の成果物を作り直す必要があり、変更コストは下流に行くほど指数関数的に増大します。

• 各フェーズの成果物を確実にレビューしてから次へ進む
• 要件が明確で変更が少ないプロジェクトに適している （要件確定済みの基幹系システム等）
• 大規模な基幹系システムの開発で多く採用される
• 後半で問題が発覚すると手戻りコストが大きいという欠点がある

使い分けの目安: 要件が明確で変更が少ない → ウォーターフォール。要件が不確実で変更が多い → アジャイル。この使い分けは試験で問われやすいポイントです。

V モデル

ウォーターフォールモデルを発展させた V モデル は、開発の各フェーズとテストの各段階を対応づけた考え方です。左側が開発工程、右側がテスト工程で、V 字型に対応関係を示します。

開発工程	対応するテスト工程
要件定義	受入テスト
基本設計	システムテスト
詳細設計	結合テスト
実装	単体テスト

V モデルにより、各テスト工程で何を検証すべきか が明確になります。

スパイラルモデル

スパイラルモデル は、システムを複数のサブシステムに分割し、設計→実装→テスト→評価のサイクルを繰り返しながら段階的に完成させる開発モデルです。

特徴	内容
リスク管理	各サイクルでリスクを評価し、早期に対策を講じる
プロトタイピング	試作品を作って利用者の評価を得ながら進める
段階的開発	サイクルを重ねるごとにシステムが成長する
適用場面	要件が不確定、またはリスクの高い大規模プロジェクト

リスク管理を重視する理由: プロトタイプを作ることで「技術的に実現可能か」「ユーザーの期待と合っているか」を早期に検証できます。大規模システムでは要件が不確実なことが多く、完成間近に問題が発覚すると致命的です。各サイクルで小さく試しながらリスクを潰していくことで、プロジェクト全体の失敗リスクを低減します。

ウォーターフォールモデルの「手戻りしにくい」という弱点を補い、変化に対応しやすい点が利点です。ただし、サイクルの終了判断が難しく、管理コストが増大するリスクがあります。

その他の開発モデル

モデル	特徴
プロトタイピングモデル	早期に試作品を作り、ユーザーに確認しながら要件を固める
インクリメンタルモデル	機能ごとに段階的にリリースする。最初から全機能を一括開発しない
RAD（Rapid Application Development）	ツールを活用して短期間で開発する手法
リバースエンジニアリング	既存のソフトウェアを解析し、仕様を復元する手法

アジャイル開発 は、短い期間（イテレーション）で開発・テスト・リリースを繰り返し、変化する要求に素早く対応する開発手法の総称です。2001年に発表された アジャイルソフトウェア開発宣言 が基盤となっています。

アジャイルソフトウェア開発宣言の4つの価値

重視するもの	より重視するもの
プロセスやツール	個人と対話
包括的なドキュメント	動くソフトウェア
契約交渉	顧客との協調
計画に従うこと	変化への対応

左側にも価値はあるが、右側の項目をより重視するという考え方です。アジャイル開発は要件変更が多い Web サービスやモバイルアプリ開発で広く採用されています。

スクラム

スクラム はアジャイル開発で最も普及しているフレームワークです。固定の短い期間 スプリント（通常1〜4週間） ごとに動くソフトウェアを作り、フィードバックを得ます。

スクラムの3つの役割

役割	責務
プロダクトオーナー（PO）	製品の価値を最大化する責任者。プロダクトバックログの優先順位を決定
スクラムマスター（SM）	スクラムの実践を支援するファシリテーター。チームの障害（開発環境の不具合、他チームとの調整、過剰な会議など）を取り除く
開発チーム	実際に開発を行う自己組織化されたチーム（3〜9人が目安）

スクラムのイベント

イベント	内容
スプリントプランニング	スプリントで取り組むバックログ項目を選定し、計画を立てる
デイリースクラム	毎日15分の短いミーティング。「昨日やったこと・今日やること・障害」の3点だけを共有。立ったまま行い、長い議論は別途設ける
スプリントレビュー	スプリント終了時に成果物をデモし、ステークホルダーからフィードバックを得る
スプリントレトロスペクティブ	チームの働き方を振り返り、改善点を見つける

カンバン

カンバン は、作業の流れを可視化し、仕掛り作業（WIP: Work In Progress）の数を制限することで生産性を高める手法です。

要素	説明
カンバンボード	「To Do」「In Progress」「Done」などの列で作業状態を可視化
WIP 制限	各列に同時に置けるカードの上限を設定し、ボトルネックを防ぐ
フロー管理	作業がスムーズに流れるよう継続的に改善する

スクラムのようにスプリントという固定期間を設けず、継続的に作業を流す のがカンバンの特徴です。

XP（エクストリームプログラミング）

XP（eXtreme Programming） は、ソフトウェアの品質を高めるための技術的プラクティスを重視するアジャイル手法です。

プラクティス	内容
ペアプログラミング	2人1組でコーディング。リアルタイムでレビューし品質を向上
テスト駆動開発（TDD）	テストを先に書き、テストが通るコードを実装する
リファクタリング	動作を変えずにコードの内部構造を改善する
継続的インテグレーション（CI）	コードを頻繁に統合し、自動テストで品質を保つ
YAGNI	「You Aren't Gonna Need It」。今必要ない機能は実装しない
共同所有	コードは特定の個人ではなくチーム全員が所有する

DevOps

DevOps は、開発（Development）と運用（Operations）が連携し、ソフトウェアの開発からデプロイまでを迅速かつ継続的に行う考え方・文化です。

概念	説明
CI（継続的インテグレーション）	コード変更を頻繁にリポジトリに統合し、自動テストを実行
CD（継続的デリバリー / デプロイ）	テスト済みのコードを自動的に本番環境にデプロイ
Infrastructure as Code	インフラ構成をコードで管理し、再現性を確保
モニタリング	本番環境を常時監視し、問題を早期に検知

DevOps により、開発と運用の間の壁（サイロ）を取り払い、リリース頻度の向上 と 障害復旧時間の短縮 を実現します。

ソフトウェアテストは、プログラムが正しく動作するかを検証する工程です。テストはバグ（不具合）を発見するために行いますが、テストではバグがないことを証明することはできない という原則を理解しておくことが重要です。

テストの段階

V モデルに対応する形で、テストには段階があります。

テスト段階	別名	目的	実施者
単体テスト	ユニットテスト	個々のモジュール（関数・クラス）が正しく動作するか検証	開発者
結合テスト	インテグレーションテスト	モジュール間のインタフェースが正しく連携するか検証	開発者
システムテスト	総合テスト	システム全体が要件を満たしているか検証	開発チーム
受入テスト	ユーザーテスト	発注者（ユーザー）が業務で使えるか最終確認	発注者

単体テストから始めて段階的にテスト範囲を広げていく ボトムアップ のアプローチが一般的です。

ホワイトボックステスト

ホワイトボックステスト は、プログラムの内部構造（ソースコード）を理解した上で、すべての処理経路を網羅的にテストする手法です。主に 単体テスト で使われ、内部構造を知る プログラマ自身が実施 します。

カバレッジ基準	説明	網羅度
命令網羅（C0）	すべての命令文を少なくとも1回実行	低
分岐網羅（C1）	すべての分岐（真/偽）を少なくとも1回実行	中
条件網羅（C2）	各条件式の真/偽のすべての組み合わせを実行	高

例えば if (A && B) という条件があった場合、命令網羅は条件が真のケース1つで済みますが、分岐網羅は真・偽の2ケース、条件網羅は A と B それぞれの真偽の組み合わせが必要です。

ブラックボックステスト

ブラックボックステスト は、プログラムの内部構造を意識せず、入力と出力の関係だけに着目してテストする手法です。仕様書だけを頼りにテストするため、開発者以外のテスターでも実施可能 です。主に 結合テスト 以降で使われます。

技法	説明	例
同値分割	入力データを有効な値と無効な値のグループに分け、各グループから代表値を選んでテスト。全パターンをテストするのは不可能なため、代表値で効率的に欠陥を発見する考え方	年齢入力：0〜150（有効）、-1やabc（無効）
境界値分析	同値クラスの境界にある値をテスト。バグは境界で発生しやすい	0, 1, 149, 150, 151 をテスト
デシジョンテーブル	条件の組み合わせと期待される動作を表にして網羅的にテスト	複数の条件が絡む割引計算
状態遷移テスト	システムの状態遷移図に基づいてテスト	ログイン状態→ログアウト状態

リグレッションテストとその他のテスト

テスト種類	説明
リグレッションテスト（回帰テスト）	修正や変更によって既存機能に悪影響が出ていないか確認するテスト。修正箇所とは無関係に見える箇所に波及的なバグが発生することがあるため重要
性能テスト	応答時間やスループットが要件を満たしているか検証
負荷テスト	想定以上のアクセスや処理量に耐えられるか検証
セキュリティテスト	脆弱性がないか検証（SQLインジェクション、XSS 等）
ユーザビリティテスト	実際のユーザーに使用してもらい、使いやすさを評価

リグレッションテスト は、バグ修正や機能追加のたびに実施が必要で、自動テストの導入が効果的です。

レビュー は、成果物（設計書、ソースコード、テスト仕様書など）を人の目で確認し、欠陥や改善点を見つける活動です。テストと異なり、プログラムを実行せずに品質を検証できるため、上流工程から適用可能 で、早期に欠陥を発見・修正できます。

レビューの種類

レビュー種類	特徴	形式性
インスペクション	訓練を受けたモデレーターが進行。チェックリストに基づき体系的に欠陥を検出	高い
ウォークスルー	作成者が成果物を説明しながらレビュアーが指摘。比較的軽量	中程度
ピアレビュー	同僚（ピア）同士で相互にレビュー。日常的に実施	低い
パスアラウンド	成果物を配布してレビュアーが個別にコメント。会議不要	低い

インスペクション は最も形式的で欠陥検出率が高いですが、準備と工数がかかります。逆に ピアレビュー は手軽ですが、見落としのリスクがあります。プロジェクトの規模やリスクに応じて使い分けることが重要です。

コードレビューの観点

ソースコードのレビューでは、以下の観点で確認します。

観点	確認内容
正確性	仕様どおりに動作するロジックか
可読性	変数名・関数名が適切で理解しやすいか
保守性	将来の変更に対応しやすい構造か
効率性	無駄な処理や非効率なアルゴリズムがないか
セキュリティ	脆弱性（SQL インジェクション、XSS 等）がないか
規約準拠	コーディング規約に従っているか

ソフトウェア品質の考え方

ソフトウェア品質は ISO/IEC 25010（SQuaRE） で体系化されています。品質特性は以下の8つに分類されます。

品質特性	説明
機能適合性	要求された機能を正しく提供しているか
性能効率性	応答時間やリソース消費が適切か
互換性	他システムと連携できるか
使用性	ユーザーにとって使いやすいか
信頼性	故障なく安定して動作するか
セキュリティ	不正アクセスやデータ漏洩を防げるか
保守性	変更や修正がしやすいか
移植性	異なる環境に移行しやすいか

品質メトリクスとバグ管理

品質メトリクス は、ソフトウェアの品質を定量的に測定する指標です。

メトリクス	説明
バグ密度	コード1,000行あたりのバグ数。品質の基本指標
テストカバレッジ	テストがコードのどの程度を網羅しているかの割合
MTBF（平均故障間隔）	障害と障害の間の平均稼働時間
信頼度成長曲線	テスト実施に伴うバグ検出数の累計推移をグラフ化。バグ発見数の増加が鈍化し曲線が平坦になったら品質が安定（収束）したと判断し、リリース可能と見なす

バグ管理 では、発見されたバグを記録・分類・優先度付けし、修正状況を追跡します。バグの 重大度（Severity） と 優先度（Priority） を区別して管理することが重要です。

• 重大度 — バグがシステムに与える影響の大きさ（致命的・重大・軽微など）
• 優先度 — ビジネス上どの順番で修正すべきかの判断（最優先・通常・後回し可など）

重大度が低くても、ユーザーの目に触れる部分であれば優先度が高くなる場合があります。