ソフトウェア開発管理技術 ― 開発プロセス・アジャイル・構成管理

1. 開発モデルと開発手法 ― 直列で作るか、回して作るか

開発モデルとは「工程をどう並べ、利用者にいつ動くものを見せるか」の型です。選ぶ基準は 2 つ、要求がどれだけ固まっているかとリスクをいつ潰したいかです。要求が確定していれば直列に流すのが速く、確定していなければ小さく回して確かめるほうが安全、というだけの話です。

ウォーターフォールモデルは、要件定義・設計・実装・テスト・運用を直列に並べ、各工程の成果物をレビューで確定させてから次へ進みます。確定した成果物は後述のベースラインとして凍結され、以降の変更は変更管理の手続を通します。分担と進捗が明確な反面、後工程で要求の誤りが見つかったときの手戻りコストが最大になります。第 13 章の V 字モデルは、このモデルの各設計工程と対応するテスト工程を突き合わせた見方です。

段階的モデル（Incremental Model）は、全体の要求と方式は先に決めたうえで機能を分割し、増分（インクリメント）ごとに設計からテスト・リリースまでを通します。早い段階で一部の機能が実際に使えるのが利点です。進展的モデル（Evolutionary Model）は逆に、最初に全体を粗く作り、繰り返しながら精度を上げていきます。要求が固まりきらない領域に向きます。

ほかに、試作品を利用者に触らせて要求を確定するプロトタイピングモデル、「計画→リスク分析→開発→評価」を渦巻き状に繰り返して危険な部分から潰すスパイラルモデル、少人数チームとツールで短期間に作り込む RAD（Rapid Application Development）があります。製品群に共通する資産をあらかじめ整備し、製品ごとの差分だけを開発する戦略はソフトウェアプロダクトラインと呼びます。機械学習モデルの学習・評価・デプロイ・再学習を継続的に回す運用は MLOps（Machine Learning Operations）です。

設計技法としては、機能を階層構造化して段階的詳細化していく構造化手法（ソフトウェア構造を表す構造化チャート・HIPO・DFD・状態遷移図など。詳細は第 13 章）と、仕様記述言語で厳密に書いて数学的に検証する形式手法があります。形式手法の代表は VDM-SL・VDM++（支援ツールは VDMTools）と Z 言語で、状態の網羅的検査を行うモデル検査ツールには SPIN があります。コーディングをせずに画面部品の組合せで作るローコード／ノーコード開発は生産性が高い一方、複雑なロジックやプラットフォーム移行に弱い点が留意事項です。

2. アジャイル ― 宣言・原則と手法の地図

アジャイルは特定の手順書ではなく、変化に適応しながら短い間隔で動くソフトウェアを届けるという考え方の総称です。出発点は 2001 年のアジャイルソフトウェア開発宣言で、4 つの価値が対比の形で書かれています。日本語訳では左に「価値を認めるもの」、右に「より価値をおくもの」が並びます。

宣言には 12 の原則が添えられています。試験で使えるのは「動くソフトウェアこそが進捗の最も重要な尺度である」「要求の変更は開発の後期であっても歓迎する」「短い時間間隔で頻繁にリリースする」「意欲に満ちた人々を信頼し、環境と支援を与える」「最良のアーキテクチャ・要求・設計は自己組織的なチームから生まれる」「一定のペースを継続的に維持する」「定期的にふりかえり、やり方を調整する」あたりです。進捗を「消化した工数」や「作成した文書の量」で測る選択肢は、この原則に反します。

アジャイル共通の道具

チームが 1 つでは収まらない規模に広げる枠組みをエンタープライズアジャイルと呼びます。SAFe（Scaled Agile Framework）、LeSS（Large-Scale Scrum）、複数チームの代表が集まる Scrum of Scrums、DA（Disciplined Agile）が代表例です。名称と「大規模向けの枠組みである」ことが分かれば十分です。

3. スクラム ― 3 役割・5 イベント・3 成果物

スクラムは、透明性・検査・適応という経験主義に基づく軽量なフレームワークです。要素は3 つの役割・5 つのイベント・3 つの成果物だけで、この 11 個を「誰が」「いつ」「何を」で結び付ければ、スクラムの問題はほぼ解けます。

イベントはすべてタイムボックス（時間の上限）付きで、スプリントという入れ物の中に他の 4 つが入ります。順序は、プランニングで始まり、毎日のデイリースクラムを挟み、成果物を見せるレビュー、やり方を見直すレトロスペクティブで終わる、という 1 本道です。

4. アジャイルの可視化 ― バーンダウンとベロシティ

アジャイルは計画書で進捗を管理しません。代わりに実績値をグラフにして毎日眺めることで、遅れを早く見つけます。試験で問われるのはグラフの形の読み取りで、計算そのものはほとんど要りません。

バーンダウンチャートは、縦軸に残作業量（ストーリーポイントや残時間）、横軸に時間をとったグラフです。作業が消化されると残量が減るので、線は右下がりになります。開始時点と終了時点を直線で結んだ理想線を引いておき、実績線がその上にあれば遅れ、下にあれば前倒しと判断します。

誤答肢は「軸か向きだけを入れ替えた別のグラフ」で作られます。図 14-4 の 3 つの形を覚えておけば取り違えません。バーンアップチャートは完了量の累積を積み上げるので右上がりになり、スコープ（総量）の線を重ねると要求追加も見えます。ガントチャートは作業ごとの期間を帯で表すもので、残量のグラフではありません。

ベロシティと残スプリント数

ベロシティは、1 スプリントで完了できたストーリーポイントの実績値です。見積りではなく実測なので、直近数スプリントの平均を使って「あと何スプリントで終わるか」を機械的に出せます。

ベロシティはチーム固有の値で、チーム間の比較や評価に使ってはいけない点も押さえます。見積りの単位であるストーリーポイントは相対値であり、チームが違えば尺度も違うからです。

リーンソフトウェア開発から持ち込まれた可視化手法がバリューストリームマップです。要求が出てから利用者に届くまでの工程を横に並べ、各工程の付加価値時間（実際に作業している時間）と待ち時間を書き込みます。リードタイムの大半が待ち時間であることを見える化し、どこの滞留を削ればよいかを決めるための道具です。

5. XP・リーン・カンバン ― プラクティスの帰属を間違えない

スクラムが「チームの回し方」を決める枠組みなのに対し、XP（エクストリームプログラミング）は「コードの書き方」まで踏み込んだ具体的なプラクティスの集まりです。試験では両者の用語を入れ替えた誤答肢が定番なので、どの手法の言葉かを対応表で覚えます。

XP は 5 つの価値（コミュニケーション・シンプル・フィードバック・勇気・尊重）を掲げ、それを実現するプラクティスを立場別に整理しています。

YAGNI（You Aren't Gonna Need It）は「今必要ないものは作らない」という指針で、シンプルの価値に対応します。ソースコードの共同所有は、誰でもどのコードでも直してよいという原則で、担当者不在で修正が止まる事態を防ぎます。

開発のプラクティスの中心がテスト駆動開発（TDD）です。実装より先にテストを書き、失敗を確認してから最短で通し、最後に重複を除く、という 3 拍子を小刻みに繰り返します。「先にテストを書く」ことで、テストが仕様書と回帰テストを兼ねる点が要点です。

ペアプログラミングは 2 人 1 組で 1 台の端末に向かい、実装役と確認役を交代しながら 1 つのプログラムを作る手法です。書きながらレビューが済むので欠陥の早期発見と知識共有に効きます。人数が 3 人以上のチーム全員に広がるとモブプログラミングです。「2 人で分担して並行に別々の部分を作る」「完成後にまとめてレビューする」は、どちらもペアプログラミングではありません。

リーン・カンバン・FDD

リーンソフトウェア開発は、トヨタ生産方式の考え方をソフトウェア開発に持ち込んだもので、ムダを取り除く・品質を作り込む・決定をぎりぎりまで遅らせる・速く提供する・全体を最適化する、といった原則からなります。前述のバリューストリームマップはこの流れの道具です。

カンバンは、作業をカードにしてボード上の列（未着手・仕掛り・完了など）を移動させ、各列に置ける枚数の上限（WIP 制限：Work In Progress の制限）を決める手法です。上限に達したら新しい作業を始めず、詰まっている工程を手伝います。スクラムのように固定長の反復を必ずしも持たず、流れを絶やさないプル型である点が特徴です。

FDD（ユーザー機能駆動開発）は、利用者にとって価値のある「フィーチャ（機能）」の単位で全体モデルを作り、フィーチャごとに設計と構築を繰り返します。

6. DevOps と CI/CD

アジャイルで開発が速くなっても、リリースが月 1 回の手作業なら価値は届きません。DevOps は、開発（Development）と運用（Operations）の壁を取り払い、文化と自動化の両輪で「小さく速く、何度でも安全に」リリースできる状態を作る考え方です。特定のツールの名前ではありません。

DevOps の構成要素を整理した枠組みが CALMS です。Culture（文化：チームをまたいだ責任の共有）、Automation（自動化）、Lean（リーン：ムダの排除と小さいバッチ）、Measurement（測定）、Sharing（共有）の頭文字で、先頭が文化であって、道具ではない点が趣旨です。運用側からソフトウェアエンジニアリングで信頼性を作り込む役割・実践を SRE（Site Reliability Engineering）と呼びます。

自動化の背骨が CI/CD パイプラインです。開発者が変更を push するたびにビルドとテストが自動で走り、通ったものだけが次の段階へ進みます。

本番反映の仕方にも型があります。ブルーグリーンデプロイメントは本番と同等の環境を 2 系統用意し、新版を待機系に載せてから切り替える方式で、問題が起これば切り戻すだけで復旧できます。カナリアリリースは一部の利用者にだけ新版を出し、指標を見ながら比率を上げる方式です。ローリングアップデートはサーバを 1 台ずつ順に入れ替えます。

DevOps の成果は測定して初めて改善できます。よく使われる 4 指標が Four Keys です。

測定の前提がオブザーバビリティ（可観測性）です。ログ・メトリクス・トレースという外部から観測できる出力だけで、内部で何が起きているかを説明できる状態を指します。この計装（テレメトリの収集）を標準化する仕様・実装が OpenTelemetry です。さらに、開発の早い段階からセキュリティの検査を自動パイプラインに組み込む考え方を DevSecOps と呼びます。

カオスエンジニアリングは、本番環境で意図的に障害を起こしてシステムが定常状態を保てるかを検証する実践です。「定常状態の仮説を立てる」「現実に起こり得る事象を変数とする」「本番環境で実験する」「継続的に自動実行する」「影響範囲（ブラストラジアス）を局所化する」といった原則が知られています。「テスト環境に限る」「障害を起こさないようにする」は、直観的には正しそうに見えて原則に反する誤答肢です。

7. プロセス改善・共通フレーム・ソフトウェア再利用

個々のプロジェクトの巧拙ではなく、組織としてのやり方（プロセス）の質を測って底上げする活動がプロセス改善です。測るための物差しが成熟度モデルで、代表が CMMI（Capability Maturity Model Integration：能力成熟度モデル統合）です。組織の成熟度を 5 段階で示し、上の段に上がるには下の段の達成が前提になります。

国際規格の系統では、プロセスアセスメント（プロセス評価）の枠組みを ISO/IEC 33000 シリーズが定めており、その JIS 版が JIS X 33001 以下の規格群です。試験では番号と内容の対応がそのまま問われます。

• JIS X 33001　プロセスアセスメントの概念及び用語（この体系の共通語彙を定める）
• JIS X 33002　プロセスアセスメントの実施に対する要求事項（診断のやり方を定める）
• JIS X 33020　プロセス能力水準及びプロセス能力測定枠組み（能力を何段階でどう測るかを定める）

JIS X 33020 のプロセス能力水準は、レベル 0 不完全なプロセス・1 実施された・2 管理された・3 確立された・4 予測可能な・5 革新しているの6 段階で、CMMI の 5 段階と数え方が違う点に注意します。組織のプロセスを評価して改善する活動全般は SPA（Software Process Assessment）とも呼ばれます。

共通フレーム（SLCP）

発注者と受注者が「どの作業まで契約に含むのか」を同じ言葉で話せるようにするための共通の物差しが SLCP（Software Life Cycle Process：ソフトウェアライフサイクルプロセス）で、国内向けに具体化したものが共通フレーム 2013（SLCP-JCF2013）です（現行版が 2013 年版で、98 年版・2007 年版が旧版です）。規格としては JIS X 0160（ソフトウェアライフサイクルプロセス）、システムを対象とする JIS X 0170 があります。

構造はプロセス → アクティビティ → タスクの 3 階層で、合意プロセス、組織のプロジェクトイネーブリングプロセス、テクニカルマネジメントプロセス、テクニカルプロセスといったプロセス群に分かれます。企画・要件定義から開発・運用・保守・廃棄までを対象範囲に含む点が要点です。すべてを使う必要はなく、プロジェクトの特性に合わせて取捨選択することを修整（テーラリング）と呼び、規格の全項目を満たす「完全適合」と、修整した上で満たす「修整適合」という適合の考え方があります。共通フレームは作業の標準手順書ではなく、用語と作業範囲を共有するための枠組みである、という位置づけが問われます。

ソフトウェア再利用とリバースエンジニアリング

生産性と品質を同時に上げる王道が再利用です。ただし「作ったものを後で使い回す」のではなく、再利用されることを前提に設計するのが部品化の要点で、そのためにモジュールの独立性を高め、カスタマイズできる箇所を明示し、命名規則を統一してライブラリとして登録します。既製のソフトウェアパッケージを購入して業務に合わせて使うことも、開発量そのものを減らす再利用の一形態です。

部品より大きな単位では、独立して差し替えられるまとまりとして境界と提供機能を定めたコンポーネント、共通の骨組みを提供して開発者が差分だけを書くフレームワーク、機能を境界越しに呼び出す API、業務機能をサービスとして疎結合に組み合わせる SOA（Service Oriented Architecture）、それを小さな独立配備単位まで分割したマイクロサービスがあります。複数の提供元の API を組み合わせて新しいサービスを作る手法がマッシュアップで、画面を組み合わせるプレゼンテーションマッシュアップ、データを統合するデータマッシュアップ、処理を組み合わせるロジックマッシュアップに分かれます。短期間で作れる反面、提供元の仕様変更やサービス停止に品質が左右されるのが留意点です。

リバースエンジニアリングは、既存のソフトウェアや実行形式を解析して仕様・構成・呼出し関係（コールグラフ）などの情報を取り出す行為です。互換製品の開発や仕様書が失われた資産の保守に使われますが、権利者の許可なく解析結果を用いて開発・販売すれば知的財産権の侵害となり得ること、利用許諾契約でリバースエンジニアリング自体が禁止されている場合があることを押さえます。

8. 知的財産適用管理 ― 著作権・特許・ライセンス

この節は法律の暗記ではなく、開発の現場で誰に何の権利が残り、何をするのに許諾が要るかを判断する話です。法規そのものの体系は第 22 章で扱います。

著作権 ― 誰のものになるかは契約で決まる

プログラムは著作物として保護され、プログラムの著作者は原則としてそれを創作した者です。ただし、法人等の発意に基づき、その業務に従事する者が職務上作成したものは、契約や勤務規則に別段の定めがない限り法人等が著作者になります（職務著作）。プログラムの著作物だけは「法人等の名義で公表する」という要件が不要で、社内システムのように公表しないソフトウェアでも法人が著作者になります。したがって、外部に開発を委託した場合は、何も定めなければ著作権は受託者（開発した側）に残り、委託元は納品物を使えても改変や再利用に制約が生じます。委託元へ移したいなら、契約で著作権の譲渡を明記します。

ただし著作権を譲り受けても、著作者人格権（公表権・氏名表示権・同一性保持権）は著作者本人に一身専属的に残り、譲渡できません。とくに同一性保持権があると、委託元が納品されたプログラムを自分の判断で改変することに支障が出ます。そこで実務では、契約に著作者人格権を行使しない旨の特約（不行使特約）を入れます。この条項の目的は「委託元が委託先の了解を都度取らなくても保守・改良できるようにすること」であり、財産権の帰属や公表の可否とは別の論点です。

特許 ― 属地主義と実施許諾

特許権は国ごとに成立する権利で、日本の特許権の効力は日本国内にしか及びません（属地主義）。そして特許発明の「実施」には、物の生産・使用・譲渡・輸出・輸入などが含まれます。ここから、試験で繰り返し問われる結論が出ます。国内で製造すれば、その製品を全量国外へ輸出しても国内での実施に当たるため、実施許諾が必要です。

実施許諾には 2 種類あります。専用実施権は設定した範囲で実施できるのが実施権者だけになる強い権利で、登録が効力の発生要件です。通常実施権は同じ範囲について複数人に重ねて許諾できます。両者の違いは「独占できるか」です。

ライセンス管理と技術的保護

自社が権利を持たないソフトウェアを使うには、権利者（ライセンサー）から使用許諾を受け、利用者（ライセンシー）は契約の範囲内で使う義務を負います。管理側の実務は、保有ライセンス数と実際のインストール数を定期的に照合（棚卸）することに尽きます。契約条項を超えた利用は不正利用であり、不正コピーは法的処罰の対象になります。

OSS のライセンス類型（コピーレフトの強弱など）は第 6 章、著作権法・特許法・不正競争防止法といった法規の条文レベルの整理は第 22 章で扱います。本章では「開発の場面でどの許諾を取るか」の判断だけを押さえてください。

9. 開発環境管理と構成管理・変更管理

複数人・長期間の開発では、「今動いているのはどの版か」「誰がいつ何を変えたか」が分からなくなることが最大のリスクです。それを防ぐのが開発環境管理と構成管理です。

開発環境の分離と管理対象

環境は開発環境・検証（ステージング）環境・本番環境に分け、本番と同じ構成の検証環境で確かめてから反映します。仮想化やコンテナを使えば同じ構成を短時間で再現でき、「私の環境では動く」を減らせます。開発環境そのものも管理対象で、次の 5 つが押さえどころです。

バージョン管理 ― 集中型と分散型

バージョン管理システムは、ファイルの変更履歴を記録し、いつでも過去の版に戻せるようにする仕組みです。集中型（Subversion、CVS など）は履歴を中央のリポジトリだけが持ち、開発者は作業コピーを取得します。分散型（Git など）は各開発者の手元に全履歴の複製があり、中央に接続できなくてもコミットや履歴の調査ができます。

分散型の運用では、作業を枝分かれさせるブランチ、枝を統合するマージ、特定の版に印を付けるタグ（リリース版の目印に使う）が基本操作です。同じ箇所を並行して変更するとマージ時に競合（コンフリクト）が起こるので、ブランチを短命に保ち、頻繁に統合するのが CI の考え方につながります。

構成管理・変更管理とベースライン

ソフトウェア構成管理は、ソフトウェアがどんな部品の組合せでできているかを識別し（構成識別）、管理単位である構成品目ごとに版と変更を統制する活動です。構成品目にはソースコードだけでなく、設計書・テスト仕様書・ビルド手順・実行環境の定義なども含みます。管理の方法をあらかじめ決めた文書が構成管理計画です。構成品目とその相互関係を記録して一元的に照会できるようにしたデータベースを構成管理データベース（CMDB）と呼びます（サービスマネジメントでも同じ言葉を使います。第 16 章）。含まれる部品と依存関係を機械可読な形式で一覧にしたものが SBOM（Software Bill of Materials）で、脆弱性が公表されたときに影響範囲を即座に特定するために使われます。

この統制の要がベースラインです。正式なレビューを経て合意された構成品目の版をベースラインとして凍結し、以後の変更は変更管理の手続を通したものだけを反映します。「勝手に直せない基準の版」を置くことで、いつの時点の何を作っているのかが常に言える状態を保ちます。

変更を記録する活動が構成状況の記録で、変更回数・最新のバージョン・移行状況などを文書化します。あわせて、構成品目が仕様どおりの機能をもつこと（機能的完全性）と、必要な要素が過不足なく揃っていること（物理的完全性）を確認するのが完全性の保証で、一貫性と正確性が判断の観点です。完全性が保証されて初めて、新しい版の出荷や配布を行うリリース管理に進みます。出荷したコードと文書は、ソフトウェアの寿命がある間、定められた保管期間にわたって保守します。要求からコード・テスト・リリースまでを相互に辿れるようにしておくことをトレーサビリティと呼び、影響分析の精度はこれで決まります。

ひっかけポイント

理解度チェック（科目 A 形式）

まとめ

本章の得点源は、出題の約半分を占めるアジャイルです。役割・イベント・用語の帰属を表で押さえ、グラフは形で見分け、知財は「国内で実施したか」「人格権は行使しない」の 2 点に絞れば、例年 2〜3 問のうち 2 問は堅く取れます。

次の第 15 章では、ここで扱った開発の進め方を「いつ・いくらで・誰が」の観点から統制するプロジェクトマネジメントを学びます。本章のスプリントやベロシティは、第 15 章のスコープ管理・スケジュール管理・EVM と同じ問題を別の道具で解いたものだと捉えると、両章がつながります。