開発の基本概念

ソフトウェアエンジニアリング そふとうぇあえんじにありんぐ

システム開発設計プロセス品質管理開発手法工学
ソフトウェアエンジニアリングって何?

簡単に言うとこんな感じ!

「橋を造るときに設計図や安全基準があるよね?」それのソフトウェア版だよ!ただコードを書くだけじゃなくて、計画・設計・テスト・保守まで、品質の高いソフトを効率よく作るための”体系的なやり方”の総称なんだ!


ソフトウェアエンジニアリングとは

ソフトウェアエンジニアリング(Software Engineering) とは、ソフトウェアを体系的・規律的・定量的に開発・運用・保守するための工学的アプローチ全般を指します。1968年にNATOが開催した会議で初めて提唱された概念で、「なぜソフトウェア開発はこんなに失敗するのか」という問いに答えるために生まれました。

単なるプログラミングとは異なり、要件定義・設計・実装・テスト・リリース・保守というライフサイクル全体を対象とします。建築や土木と同様に「再現性のある手順」「品質基準」「コスト管理」を取り入れることで、大規模なシステムでも安定して開発できるようにするのが目的です。

ビジネス側の視点では「発注したシステムがなぜ予算超過・納期遅延・品質不良になるのか」を理解する上で欠かせない知識です。ソフトウェアエンジニアリングの考え方を発注側も知っておくことで、ベンダーとの対話の質が大きく変わります。


ソフトウェア開発の主なフェーズ

ソフトウェアエンジニアリングでは、開発を次のようなフェーズに分けて管理します。

フェーズ内容発注側が関与するポイント
要件定義「何を作るか」を明確にする最も重要。認識齟齬はここで生まれる
設計構造・データ・インターフェースを決めるビューへの参加が品質に直結
実装(コーディング)プログラムを書く主にエンジニアが担当
テスト動作・品質を検証する受け入れテストは発注側が実施
リリース本番環境に展開する切替タイミング・移行計画の承認
保守・運用障害対応・機能追加SLA(品質保証レベル)の管理

「ソフトウェア危機」という言葉を覚えよう

1960〜70年代、コンピューターが普及するにつれてソフトウェアが大規模化し、納期遅延・コスト超過・品質不良が多発しました。これを「ソフトウェア危機(Software Crisis)」と呼びます。この反省から「もっと工学的にやろう」という動きが生まれ、ソフトウェアエンジニアリングという分野が確立しました。現代でもプロジェクト失敗の原因の多くはこの時代と変わっていないと言われています。

代表的な開発プロセスモデル

ウォーターフォール型(伝統的)
  要件定義 → 設計 → 実装 → テスト → リリース
  ↑ 上から順に進み、原則戻らない

アジャイル型(現代的)
  ┌────────────────────────────┐
  │ 計画 → 設計 → 実装 → テスト │ ← 2〜4週間の短いサイクルを繰り返す
  └────────────────────────────┘
  → リリース → フィードバック → 次のサイクルへ

歴史と背景

  • 1968年 — NATO科学委員会がドイツで「ソフトウェアエンジニアリング」会議を開催。業界初めてこの用語が公式に使われる
  • 1970年代 — ウォーターフォールモデルが普及。大企業・政府系プロジェクトで標準化が進む
  • 1987年 — SEI(ソフトウェア工学研究所)が CMM(能力成熟度モデル) を発表。組織の開発プロセス成熟度を測る指標として普及
  • 1990年代 — オブジェクト指向設計・UMLが登場。設計手法が体系化される
  • 2001年アジャイルマニフェストが発表。「変化への対応」を重視する現代的な開発哲学が確立
  • 2010年代〜 — DevOps・CI/CDの普及により、開発と運用の境界が曖昧になり、ソフトウェアエンジニアリングの範囲がさらに拡大

ウォーターフォール vs アジャイル

発注側が最もよく直面する選択が「どちらの開発手法を採用するか」です。

比較項目ウォーターフォールアジャイル
進め方上流から順番に1度だけ進む短期サイクルを何度も繰り返す
向いているケース要件が最初から明確・変更が少ない要件が変わりやすい・早く試したい
発注側の関与要件定義フェーズに集中全サイクルで継続的に関与が必要
リスク後半で問題が発覚しやすい管理コストが高くなりやすい
契約形態請負契約が多い準委任契約が多い
代表的な採用例基幹システム・官公庁案件Webサービス・スタートアップ
ウォーターフォール vs アジャイル ウォーターフォール ① 要件定義 ② 設計 ③ 実装 ④ テスト ⑤ リリース アジャイル 【スプリント 1〜4週間】 計画・設計 実装・テスト リリース(部分的) フィードバック 繰り返す

関連する規格・RFC

規格番号内容
ISO/IEC 12207ソフトウェアライフサイクルプロセスの国際標準。開発・運用・保守の各プロセスを定義
ISO/IEC 25010ソフトウェア品質モデル(SQuaRE)。機能性・信頼性・使いやすさなど8つの品質特性を定義
ISO/IEC 90003ソフトウェア開発にISO 9001(品質マネジメント)を適用するためのガイドライン
IEEE 730ソフトウェア品質保証プロセスの標準

関連用語

  • 要件定義 — 「何を作るか」を明確化する最上流工程。発注側の関与が最も重要なフェーズ
  • ウォーターフォールモデル — 上流から下流へ順番に進む伝統的な開発プロセスモデル
  • アジャイル開発 — 短いサイクルで開発・フィードバックを繰り返す現代的な開発手法
  • DevOps — 開発(Development)と運用(Operations)を統合して高速リリースを実現する考え方
  • システムテスト — ソフトウェアが要件を満たしているかを検証する工程
  • プロジェクト管理スコープ・コスト・スケジュールをコントロールしてプロジェクトを成功に導く手法
  • 技術的負債 — 短期的な妥協で積み上がった「後で払うことになるコスト」のこと
  • CI/CD — 継続的インテグレーション/継続的デリバリー。自動テスト・自動デプロイの仕組み