ソフトウェア工学｜高品質なソフトを体系的に開発する学問

ソフトウェア工学

ソフトウェア工学（Software Engineering）は、ソフトウェアの開発・運用・保守を、経験や勘ではなく体系的かつ定量的な手法で行うための工学分野である。要求定義、設計、実装、テスト、保守という一連の工程を対象とし、品質・コスト・納期を管理可能なものにすることを目的とする。英語名は1968年に西ドイツのガルミッシュで開かれたNATO科学委員会の会議で広まった。土木や機械と同じように「ものづくり」としてソフトウェアを扱うという考え方が、この名前に込められている。

ソフトウェア危機と分野の成立

1960年代後半、汎用コンピュータの性能は急速に向上した。しかし、それを動かすプログラムの開発は追いつかず、予算超過や納期遅延、完成しても使えないシステムが続出した。IBMのOS/360の開発では数千人規模の技術者が投入されたものの、計画は大幅に遅れた。この経験をもとにフレデリック・ブルックスは1975年に『人月の神話』を著し、「遅れているプロジェクトに人員を追加すると、さらに遅れる」という法則を示した。こうした状況は「ソフトウェア危機」と呼ばれ、1968年と1969年のNATO会議では、属人的な作業から工学的な規律への転換が議論された。ソフトウェア工学はこの危機感から生まれた分野であり、その後の構造化プログラミングやオブジェクト指向の普及を後押しした。

開発プロセスモデルの比較

開発の進め方を定めた枠組みを「プロセスモデル」と呼ぶ。代表的なのは、1970年にウィンストン・ロイスの論文をきっかけに広まったウォーターフォール・モデルである。工程を上流から下流へ順に進めるため、計画は立てやすい。その反面、後戻りには大きなコストがかかる。この弱点を補うため、反復型のスパイラルモデルや、2001年の「アジャイルソフトウェア開発宣言」に始まるアジャイルソフトウェア開発が登場した。

実務では、どれか一つに絞るよりも組み合わせて使う例が多い。たとえば国内の製造業の情報システム部門では、上流工程はウォーターフォールで要件を固め、画面まわりだけを短い反復で作り込むといったハイブリッド型がよく採用されている。

国際規格とプロセス成熟度

ライフサイクル全体の作業項目は、ISO/IEC/IEEE 12207で定義されている。日本ではこれに対応する規格としてJIS X 0160が制定されており、官公庁の調達仕様書でも参照されることがある。製品の品質特性については、ISO/IEC 25010（SQuaRE）が機能適合性・性能効率性・互換性・使用性・信頼性・セキュリティ・保守性・移植性の8特性を定めている。

組織の開発能力を評価する枠組みとしては、米カーネギーメロン大学ソフトウェア工学研究所（SEI）が開発したCMM、その後継のCMMIが知られる。成熟度は「初期」から「最適化」までの5段階で表される。海外の発注元がオフショア開発の委託先を選ぶとき、レベル3以上の認定を条件とする例も少なくない。

ISO 9001との関係

製造業の品質マネジメントで広く使われるISO 9001も、ソフトウェア開発組織に適用できる。ソフトウェアへの適用指針としてはISO/IEC 90003が発行されている。

製造業における組込みソフトウェア

工作機械、産業用ロボット、自動車などに搭載される組込みシステムでは、ソフトウェアの不具合がそのまま人身事故につながりかねない。そのため、自動車分野ではISO 26262（機能安全）、産業機器ではIEC 61508が求める開発プロセスに従う必要がある。ASIL Dのような高い安全度水準になると、要求からテストまでのトレーサビリティを文書で証明しなければならない。開発工数が通常の2倍近くに膨らむことも珍しくない。

現場で見落とされやすいのが、ハードウェアとの並行開発による手戻りである。試作基板の改版に合わせてドライバを作り直す、といった事態は日常的に起こる。経験のある開発チームは、PLCやマイコンのシミュレータを早い段階で用意し、実機がなくても結合テストを始められる体制を整えている。また、モデルベース開発でMATLAB/Simulinkから制御コードを自動生成する手法は、国内の自動車部品メーカーで2000年代後半から急速に広まった。

見積りと品質の定量化

工学と名のつく以上、測定は欠かせない。開発規模の見積りでは、ソースコード行数（LOC）やファンクションポイント法がよく使われる。バリー・ベームが1981年に発表したCOCOMOでは、工数を次の式で表す。

工数（人月） = a × (KLOC)^b
※KLOCは1000行単位の規模。基本モデルの組織型ではa = 2.4、b = 1.05

指数bが1を超えているのは、規模が大きくなるほど調整やコミュニケーションの負荷が増え、生産性が下がるためである。ベームは、要求定義の段階で見つかった欠陥に比べて、運用段階で見つかった欠陥の修正費用は最大で約100倍になるとも指摘した。この知見は、レビューや静的解析で上流の品質を高める根拠として今も引用されている。国内の受託開発では、1人月あたり80万〜130万円程度の単価に工数を掛けて見積額を出すことが多い。ただし、テスト工程の比率を全体の30〜40%として見込んでおかないと、後になって赤字に陥りやすい。

実装・テストを支える技術

設計の表記法としては、1997年にOMGが標準化したUMLが事実上の共通言語になっている。クラス図やシーケンス図を使うと、プログラムを書く前に構造と振る舞いをチーム内で共有できる。実装段階では、Gitなどのバージョン管理システムによる変更履歴の管理と、コードを登録するたびに自動でビルドとテストを行う継続的インテグレーション（CI）が標準的な手法となった。

テストはいくつかの段階に分けて行う。

• 単体テスト：関数やクラスなど最小単位を検証する。分岐網羅率（C1カバレッジ）100%を目標とする組織もある
• 結合テスト：モジュール間のインタフェースを確認する
• システムテスト：要求仕様どおりに動くかを総合的に検証する
• 受入テスト：発注者が実際の業務に近い条件で確認する
• 回帰テスト：修正によって既存機能が壊れていないかを再確認する

テスト技法の詳細はソフトウェアテストの項目に譲る。なお、日本ではJSTQB（日本ソフトウェアテスト資格認定委員会）が国際的なISTQBと連携した資格試験を運営しており、テスト技術者の能力を示す指標として使われている。

隣接分野との違い

計算機科学がアルゴリズムや計算理論といった「何が計算できるか」を扱うのに対し、ソフトウェア工学は「限られた人員と期間で、どう作り、どう保守するか」に重点を置く。複数のサブシステムを含む大規模な装置全体を扱うシステム工学とは重なる部分が大きく、宇宙・防衛分野では両者を一体で運用する場合が多い。プロジェクトの計画や進捗管理の面では、PMBOKに代表されるプロジェクトマネジメントの知識体系とも密接に結びついている。IEEEコンピュータ・ソサエティが2004年に初版を公開し、2024年に第4版へ改訂したSWEBOKは、この分野の知識範囲を整理した文書として大学教育や技術者認定の基準に使われている。