ソフトウェア開発管理技術（開発プロセス・知的財産・開発環境・構成管理）

この単元の範囲

シラバスは「開発技術」を大分類4として独立させており、その2番目の中分類が「ソフトウェア開発管理技術」である。中分類12「システム開発技術」が要件定義・設計・プログラミング・テストといった開発の中身を扱うのに対し、この中分類13は開発プロジェクトをどう進め、どう守り、どう管理するかという横断的なマネジメント技術を扱う。シラバスは本中分類を「1.開発プロセス・手法」「2.知的財産適用管理」「3.開発環境管理」「4.構成管理・変更管理」の4項目に整理している。アジャイルやDevOpsといった開発の進め方から、著作権・特許といった法務、開発環境そのものの管理、ソースコードのバージョン管理まで幅広く扱うため、実務で「開発を回す」上で必要な周辺知識がひとまとまりになっているとイメージするとよい。

1. 開発プロセス・手法

1-1 ソフトウェア開発モデル

開発の進め方には複数のモデルがある。要件定義→設計→実装→テストを順番に一度だけ行うウォーターフォールモデル、試作品を早期に作って利用者の確認を得ながら進めるプロトタイピングモデル、小さな単位を繰り返し積み上げるアジャイル、開発と運用を一体化するDevOps、機械学習モデルの開発・運用を一体化するMLOps、共通部品群から製品群を派生させるソフトウェアプロダクトライン、機能を段階的に追加していく段階的モデル（Incremental Model）、要求の変化に応じて設計自体を進化させていく進展的モデル（Evolutionary Model）などが用語例として挙げられている。ウォーターフォールは計画通りに進めやすい反面、途中の仕様変更に弱い。逆にアジャイルは変化への対応力が高い一方、全体の進捗が見えにくくなりやすい、というトレードオフを押さえておくと理解しやすい。

1-2 アジャイル開発（XP・スクラム）

アジャイルは、価値観をまとめた「アジャイルソフトウェア開発宣言」と、それを具体化した「アジャイルソフトウェアの12の原則」を土台に持つ開発の進め方の総称である。代表的な手法として、XP（エクストリームプログラミング）とスクラムがある。

XPは技術的なプラクティスを重視する手法で、コードを書く前にテストを書くテスト駆動開発（TDD）、2人1組で1台の端末を使ってコードを書くペアプログラミング、外部から見た動作を変えずに内部構造を整理するリファクタリング、誰もが誰のコードでも修正できるソースコードの共同所有、こまめに変更を統合してビルド・テストする継続的インテグレーション（CI）、将来必要になるかもしれない機能は今作らないというYAGNI（You Aren't Gonna Need It）の原則を特徴とする。

スクラムはチーム運営の枠組みを重視する手法で、要件の優先順位を決めるプロダクトオーナー・実際に開発する開発者・チーム運営を支援するスクラムマスターからなるスクラムチームが、数週間単位のスプリントという期間を繰り返しながら開発を進める。全体の要求一覧であるプロダクトバックログから、そのスプリントで実装する分だけを取り出したものがスプリントバックログである。ふりかえり（レトロスペクティブ）では、うまくいったこと・問題点・次に試すことを整理するKPT（Keep・Problem・Try）というフレームワークがよく使われる。

1-3 DevOps

DevOpsは開発（Development）と運用（Operations）を一体的に進める考え方で、リリースの頻度と信頼性を両立させることを目指す。運用の信頼性をソフトウェア工学的な手法で担保するSRE（Site Reliability Engineering）、コードの統合を継続的に行う継続的インテグレーション（CI）、本番環境へいつでもリリースできる状態を保つ継続的デリバリー（CD）、実際に自動でリリースまで行う継続的デプロイ、コードを書く前にテストを書くテスト駆動開発（TDD）、あえて本番環境に障害を注入して耐障害性を検証するカオスエンジニアリング、セキュリティを開発の初期段階から組み込むDevSecOpsが用語例として挙がっている。CI/CD/継続的デプロイの違いは、「統合を自動化する（CI）」「デプロイ直前まで自動化する（CD）」「デプロイまで完全自動化する（継続的デプロイ）」という段階の違いとして理解すると整理しやすい。

1-4 ローコード／ノーコード開発

プログラムのソースコードをほとんど、あるいは全く書かずにアプリケーションを構築する手法である。画面部品をドラッグ＆ドロップで配置して業務アプリを作るツールなどが該当し、開発スピードの向上や非エンジニアによる内製化といった利点がある一方、複雑な業務ロジックの実装やツールへの依存（ベンダーロックイン）といった留意点もある。

1-5 ソフトウェア再利用・リバースエンジニアリング・マッシュアップ

既存の部品やコードを再利用して開発効率を高めるソフトウェア再利用では、部品同士の依存が少ないモジュールの独立性、命名や設計を揃える標準化、既存部品を個別要件に合わせて調整するカスタマイズが重要になる。既に動いているプログラムを解析して仕様や構造を明らかにするリバースエンジニアリングでは、異なる環境で同じように動くかという互換性や、関数同士の呼び出し関係を図示したコールグラフが手がかりになる（例えば、古い社内システムの仕様書が失われた場合に、動いているプログラムを解析して仕様を復元するような場面で使われる）。複数のWebサービスの機能やデータを組み合わせて新しいサービスを作る手法はマッシュアップと呼ばれる（例：地図サービスのAPIと店舗情報を組み合わせた店舗検索サイト）。

1-6 モバイルアプリケーション開発

スマートフォン向けアプリの開発形態には複数の種類がある。ブラウザ上で動くモバイル用Webアプリケーションソフトウェア、端末のOS向けに個別開発するネイティブアプリケーションソフトウェア、Webとネイティブの技術を組み合わせたハイブリッドアプリケーションソフトウェア、Webページでありながらネイティブアプリに近い体験を提供するPWA（Progressive Web Apps）がある。ブラウザやアプリが自身の種類・バージョンを名乗る情報であるUser-Agent、カメラや位置情報へのアクセスを利用者に許可してもらうパーミッション要求、アプリストアが公開前に行うアプリケーションソフトウェア審査、ストア経由・企業内配布などのアプリケーションソフトウェア配布も関連用語として挙げられている。

1-7 構造化手法

処理の流れを上位から下位へ段階的に詳細化しながら整理する開発手法である。全体を階層的に分解する階層構造化、大まかな処理から徐々に詳細な処理へ落とし込む段階的詳細化、処理の呼び出し関係を図示する構造化チャート、状態の移り変わりを図で表す状態遷移図、入力・処理・出力の関係を階層的に示すHIPO（Hierarchy plus Input Process Output）、データの流れを図示するDFD（データフローダイアグラム）、こうした手法によって整理されたプログラム全体の構造を指すソフトウェア構造が用語例である。

1-8 形式手法

自然言語で書かれた仕様は曖昧さや解釈のブレを含みやすい。形式手法（Formal Method）は、この仕様を数学的に厳密な記法（形式仕様記述言語）で記述し、ルールに従って検証することでソフトウェアの品質を高める手法である。代表的なツールとしてVDMToolsが用語例に挙げられている。金融システムや制御システムなど、不具合が許されない領域で使われることが多い。

1-9 開発プロセス標準（SLCPとCMMI）

開発プロセスそのものを標準化する取り組みとして、ソフトウェアライフサイクルプロセスの考え方があり、その規格としてJIS X 0160（共通フレームとしてSLCP-JCFとも呼ばれる）が用語例に挙がっている。JIS X 0160はソフトウェア開発の企画から廃棄までの各工程を共通の用語・枠組みで整理した規格で、国際規格ISO/IEC 12207を日本語化したものであり、1996年に初版が制定された後、2007年・2012年・2021年に改正され、最新版はJIS X 0160:2021（発行2021年2月22日）である。

もう一つの重要な指標が組織のプロセス成熟度を測るCMMI（能力成熟度モデル統合）である。CMMIは組織のソフトウェア開発プロセスがどれだけ体系立てて管理されているかを段階的なレベルで評価するモデルであり、現在はISACAが管理している。2023年4月にISACAは最新版CMMI V3.0をリリースし、2024年1月1日以降は旧版CMMI V2.2によるアプレイザル（評価）は受理されなくなり、V2.2は2024年6月に正式に廃止（retire）された。試験で「CMMI」という用語そのものが問われる場合は、成熟度をレベル分けして継続的に改善するモデルだという骨格を押さえておけば十分だが、実務で使う際は現行版がV3.0であることを踏まえておきたい。

2. 知的財産適用管理

ソフトウェア開発では、成果物であるプログラムやそこに使われる技術・データを法的にどう保護し、どう扱うかという知的財産の管理も欠かせない。

2-1 著作権管理

プログラムは著作物として保護され、原則として作成した個人がプログラムの著作者になる。ただし、会社の業務として従業員が作成したプログラムについては、会社が著作者となる職務著作という例外規定がある（例：SIerの社員が業務時間内に開発した業務システムの著作権は、契約で別段の定めがない限り会社に帰属する）。

2-2 特許管理

技術的なアイデア・発明を保護するのが特許権である。特許権者から実施許諾を受ける形態には、他者を排除して独占的に実施できる専用実施権と、非独占的に実施できる通常実施権がある（例：ある企業が特許技術を1社だけに独占的に使わせる契約を結べば専用実施権、複数社に並行してライセンスすれば通常実施権となる）。

2-3 ライセンス管理

ソフトウェアの利用許諾に関する用語として、権利を許諾する側のライセンサーと、許諾を受けて利用する側のライセンシーがある。ソフトウェア調達においては、誰がライセンサーで誰がライセンシーかを契約上明確にしておくことがトラブル防止につながる。

2-4 技術的保護

著作物やコンテンツを技術的な手段で不正利用から守る仕組みも重要である。複製そのものを制限するコピーガード、利用条件をデジタルに管理するDRM（デジタル著作権管理）、正規購入者であることを確認してから機能を有効化するアクティベーション、記録メディア単位でコピー世代を制御するCPRMが用語例に挙がっている（例：動画配信サービスがDRMによって画面録画や不正な再配布を防いでいるのが身近な例である）。

3. 開発環境管理

3-1 開発環境構築

開発を行うための環境そのものを整備・管理する活動である。管理すべき対象物である構成品目、利用するツールに紐づくソフトウェアライセンス、本番同等の環境でリリース前の最終確認を行うステージング環境が用語例に挙がっている。開発（Dev）・検証（Staging）・本番（Production）の3段階で環境を分けるのは実務でも一般的な考え方である。

3-2 管理対象

開発環境管理では、以下の4つの観点で管理を行う。

• 開発環境稼働状況管理：サーバやツールなどの資源管理、日々の運用管理を通じて環境が正常に動いているかを把握する
• 設計データ管理：設計書やモデルの変更履歴をたどれる更新履歴管理、誰が編集・閲覧できるかを制御するアクセス権管理、必要な資料をすぐに探し出せる検索、これらを一元的に保管するリポジトリが用語例である
• ツール管理：開発ツール自体も管理対象である構成品目として扱い、ツールのバージョンを追跡するバージョン管理を行う
• ライセンス管理：ツールやミドルウェアの不正コピーの防止、導入している製品のバージョン管理、保有ライセンス数と利用実態を突き合わせる棚卸を行う

4. 構成管理・変更管理

4-1 構成管理

ソフトウェア構成管理は、開発対象となるプログラム・ドキュメント・設定ファイルなどのソフトウェア構成品目を識別し、その版や状態を管理する活動である。先述のSLCP（Software Life Cycle Process）の枠組みの中に構成管理プロセスが位置づけられており、進め方を定めた構成管理計画を作成して運用する。近年新たに重要視されている用語としてSBOM（Software Bill of Materials：ソフトウェア部品表）があり、ソフトウェアがどのようなオープンソースライブラリ・部品から構成されているかを一覧化したものである。サプライチェーン（供給網）を経由した脆弱性混入が社会問題化する中で、自社製品にどの部品が使われているかを可視化する目的で普及が進んでいる。

4-2 変更管理

開発対象への変更を安全に取り込むための活動が変更管理であり、次の3つの観点で構成される。

• 構成状況の記録：変更がいつ・誰によって・どの構成品目に対して行われたかを記録に残す
• ソフトウェア構成品目の完全性保証：変更後も構成品目間の整合性が崩れていないという一貫性、記録された内容に誤りがないという正確性を保証する
• リリース管理及び出荷：どの版を出荷したかを追跡するバージョン管理、出荷物やその記録をいつまで残すかを定める保管期間の管理を行う

構成管理が「今どんな部品で成り立っているかを正しく把握する」活動であるのに対し、変更管理は「そこに加わる変更を安全に取り込み、記録を残す」活動であると整理すると両者の役割の違いが理解しやすい。

---

参考文献

• IPA「基本情報技術者試験シラバス Ver.9.2」大分類4「開発技術」中分類13「ソフトウェア開発管理技術」（p.58-62）: https://www.ipa.go.jp/shiken/syllabus/omgdg50000005kpe-att/syllabus_fe_ver9_2.pdf
• JIS X 0160（ソフトウェアライフサイクルプロセス）規格情報・改正履歴（1996年制定、2007年・2012年・2021年改正の記載を含む日本規格協会公式ページ）: https://webdesk.jsa.or.jp/books/W11M0090/index/?bunsyo_id=JIS+X+0160:2021
• ISACA「CMMI Updates Take Performance Improvements to the Next Level」（CMMI V3.0リリース・V2.2廃止に関する公式ブログ）: https://www.isaca.org/resources/news-and-trends/isaca-now-blog/2023/cmmi-updates-take-performance-improvements-to-the-next-level