ソフトウェア開発管理技術

目次

応用情報技術者試験（レベル３）シラバス－情報処理技術者試験における知識・技能の細目－ Ver. 7.0 に基づき，「ソフトウェア開発管理技術」の対策ノートを作成した。

本稿は，システムアーキテクト試験，プロジェクトマネージャ試験 午前Ⅱ 問題の対策としても活用できるようにしている。

• 開発プロセス・手法
• 知的財産適用管理
• 開発環境管理
• 構成管理・変更管理
• 本稿の参考文献

開発プロセス・手法

(1) ソフトウェア開発手法

① ソフトウェア開発モデル

ウォーターフォールモデル（waterfall model）

ウォーターフォールモデルとは、システム開発の手順を模式化したモデルの一つで、設計やプログラミングといった各段階を一つずつ順番に終わらせ、次の工程に進んでいく方式。最も古典的な開発モデルの一つで現代でも広く普及している。

要件定義，基本設計，詳細設計，実装，単体テスト，結合テスト，システムテストといった各工程を時系列に沿って順に並べ，一つ前の工程が終わったらその成果物をもとに次の工程を始める，という単純なルールで進めていく方式である。滝（waterfall）を水が流れ落ち、逆戻りしないという意味合いでこのように呼ばれるようになった。

ウォーターフォールの要件定義，基本設計，詳細設計，実装においては，以下のことを実施する。

プロトタイピングモデル（prototyping model）

プロトタイピングとは、工業製品の開発手法の一つで、設計の早い段階から実際に稼働する製品モデル（プロトタイプ）を作成し、その検証とモデルの再制作を何度も反復する手法。IT の分野ではソフトウェアやシステムの開発でこのような手法を用いることを意味する。

IT システムやソフトウェアでは、利用者がどのような機能をどのように使いたいのか自身も明確には理解していない場合があり、最初に完全に仕様を確定してから開発に入ることが困難だったり、開発工程に入った後や完成後の修正、やり直しが頻発する場合がある。

プロトタイピングでは、要求を分析する初期の段階で、最低限の機能や操作画面を実装した原型（プロトタイプ）を用意して、業務に適用することを想像しながら操作してもらい、利用者の具体的な要求を引き出していく。プロトタイプの作成と検証を繰り返すことにより、次第にシステムに必要とされる機能・仕様が具体化・明確化していく。

スパイラルモデル（Spiral Model）とは，システム開発手順の一つで，ユーザからのフィードバックや要望に対応しながら，精査や改善を重ねつつ，設計とプロトタイピングを繰り返して完成させる手法のことをいう。

アジャイル

アジャイル開発とは、ソフトウェアを迅速に、また、状況の変化に柔軟に対応できるように開発する手法の総称。「アジャイル」（agile）とは、俊敏な、しなやかな、素早い、などの意味で、短いプロセスを何度も反復して次第に全体を組み立てていくアプローチの手法が多い。

ウォータフォール型とアジャイル型の違いを比較すると次のとおり。

DevOps

DevOps とは、ソフトウェアの開発担当と導入・運用担当が密接に協力する体制を構築し、ソフトウェアの導入や更新を迅速に進めること。“Development”（開発）と “Operations”（運用）の略語を組み合わせた造語。

ソフトウェアプロダクトライン

ソフトウェアプロダクトライン（SPL）開発では，コピーではなく，統一して管理された資産から各製品を導出する点に大きな特徴がある。

統一して管理された，再利用可能な資産のことを部品化したコア資産と呼び，いつでも製品群の全ての製品の導出が可能であるように，定期的にバージョンアップを行う。そのため，どの製品に変更が必要になっても，変更は部品化したコア資産の最新バージョンのみでよくなる。

また，新製品の開発時には，既に開発・テスト済みの部品化したコア資産を最大限に再利用できるため，新製品の固有機能の作り込みのみに専念することができる。

つまり，変更開発時，新規開発時のいずれにおいても，SPL 開発では重複した機能開発を防ぐことができるため，従来に比べて，ムダな開発工数を削減することができる。

段階的モデル（Incremental Model）

最初に小さなシステムを作成し，それを段階的に発展させていく手法。要求を全部一度に実現するのではなく，複数に分割し，順次実現していくアプローチをとる。

進展的モデル（Evolutionary Model）

開発プロセスの一連のアクティビティを複数回行う反復型のモデルである。要求に従ってソフトウェアを作成し，出来栄えを評価する。その結果改訂された要求に従って作成し，また出来栄えを評価する，というように，要求事項やソフトウェアを改訂しながら，反復を繰り返し，ユーザが本当に求めている要求に近づけていくといった特徴をもつ。

② アジャイル

(a) アジャイルの概要

アジャイルソフトウェア開発宣言

アジャイルソフトウェア開発宣言を以下に示す。

私たちは、ソフトウェア開発の実践あるいは実践を手助けをする活動を通じて、よりよい開発方法を見つけだそうとしている。この活動を通して、私たちは以下の価値に至った。

プロセスやツールよりも個人と対話を、包括的なドキュメントよりも動くソフトウェアを、契約交渉よりも顧客との協調を、計画に従うことよりも変化への対応を、価値とする。すなわち、左記のことがらに価値があることを認めながらも、私たちは右記のことがらにより価値をおく。

アジャイルソフトウェアの 12 の原則

アジャイル宣言の背後にある原則（アジャイルソフトウェアの 12 の原則）を示す。

1. 顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。
2. 要求の変更はたとえ開発の後期であっても歓迎します。変化を味方につけることによって、お客様の競争力を引き上げます。
3. 動くソフトウェアを、2-3 週間から 2-3 ヶ月というできるだけ短い時間間隔でリリースします。
4. ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません。
5. 意欲に満ちた人々を集めてプロジェクトを構成します。環境と支援を与え仕事が無事終わるまで彼らを信頼します。
6. 情報を伝えるもっとも効率的で効果的な方法はフェイス・トゥ・フェイスで話をすることです。
7. 動くソフトウェアこそが進捗の最も重要な尺度です。
8. アジャイル･プロセスは持続可能な開発を促進します。一定のペースを継続的に維持できるようにしなければなりません。
9. 技術的卓越性と優れた設計に対する不断の注意が機敏さを高めます。
10. シンプルさ（ムダなく作れる量を最大限にすること）が本質です。
11. 最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます。
12. チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちのやり方を最適に調整します。

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

エクストリームプログラミング（XP : eXtreme Programming）とは、迅速で柔軟性の高いソフトウェア開発手法の一つ。いわゆるアジャイル開発手法と総称される軽量で柔軟な手法の先駆けとなったもので、1999年に米著名プログラマのケント・ベック（Kent Beck）氏らが提唱した。

スクラム

スクラムはアジャイル型開発手法の一つで，スプリントという短い開発期間を設定し，透明性と検査，適応によって，経験に基づいた最適化を進めながら，各スプリントの中で選択した機能を開発していく。開発体制は，機能を決定するプロダクトオーナ，全体をマネジメントするスクラムマスタ，開発作業を行なう開発チームの 3 つで構成される。

毎朝デイリースクラムというミーティングで「昨日したこと」「今日すること」「問題点」を確認する。各スプリントの最後tでは，振り返りのレトロスペクティブミーティングを行い，成果と反省をまとめ，次のスプリントでその経験を反映する。

リーンソフトウェア開発

リーンソフトウェア開発は、トヨタ生産方式が生んだ「7 つのムダ」の基本理念を発展させたリーン生産方式を、ソフトウェア開発に適用した手法である。ソフトウェア開発に潜む ムラ（ばらつき）・ムリ（不合理・過負荷）・ムダ（付加価値のない作業） を排除することを中核に据え、生産効率と品質の最適化を追求することを目的としている。リーン（lean）は、痩せていて脂肪のないこと、無駄がなく引き締まっていることなどを意味する。

リーンソフトウェア開発を支える 7 つの原則は，次のとおり。

1. ムダをなくす
2. 品質を作り込む
3. 知識を作り出す
4. 決定を遅らせる
5. 速く提供する
6. 人を尊重する
7. 全体を最適化する

ペルソナ

ユーザストーリ

アジャイル型開発では，ソフトウェアが実現すべき機能を提議するため，ユーザストーリを作成する。ユーザストーリは「ユーザは投稿をキーワードで検索できる」など，ソフトウェアが実現すべき機能をユーザ視点で簡潔に記述したものである。

ユーザストーリを評価する観点に INVEST がある。これは，次の六つの観点の頭文字をとったものである。

プランニングポーカ

数字に書かれたカードを使い，チームで相談しながら作業工数の見積りを求める手法。

バーンダウンチャート（burn down chart）

バーンダウンチャートは、縦軸に「残作業量」、横軸に「時間」を割り当てて、作業の消化具合を視覚的に把握できるようにした図である。プロジェクトの経過に伴い残作業量は減っていくので基本的には右肩下がりのグラフになる。実績線が予定線より上方にあれば計画より遅れている、下方にあれば計画より進んでいると判断できる。

ふりかえり（レトロスペクティブ）

ふりかえり（レトロスペクティブ）は，イテレーション内で実施したことや起きたことを、最後にチーム全員でふりかえり、開発プロセス、コミュニケーション、その他様々な活動をよりよくする改善案を皆で考えることをいう。したがって，適切な実施タイミングは，各イテレーションの最後である。

継続的デリバリ（CD）

エンタープライズアジャイル

インセプションデッキ

インセプションデッキは 10 個の質問と答えから構成される。10 個の質問は，顧客（ステークホルダ）と開発チーム間で認識を合わせるべき重要な項目といえる。

1. 我々はなぜここにいるのか（Why 1）
2. エレベータピッチを作る（Why 2）
3. パッケージデザインを作る（Why 3）
4. やらないことリストを作る（Why 4）
5. 「ご近所さん」を探せ（Why 5）
6. 解決案を描く（How 1）
7. 夜も眠れなくなるような問題は何だろう（How 2）
8. 期間を見極める（How 3）
9. 何を諦めるかをはっきりさせる（How 4）
10. 何がどれだけ必要なのか（How 5）

インセプションデッキ（Inception Deck）を直訳すると「最初のデッキ（カードの束）」という意味であり，アジャイルプロジェクトにおけるプロジェクト憲章に近い意味である。

(b) XP（エクストリームプログラミング）の特徴

XP には年々いくつかのプラクティスが追加されているが，基本となった 12 のプラクティスは次の通り。

計画ゲーム

求める機能のコンセプトを短い文章で記したストーリーカードを作成する。そのカードをもとに、開発者・管理者を含めたチームとのミーティングを行い詳細を決定する。

短期リリース

動くソフトウェアを 1～3 ヶ月というできるだけ短い時間間隔でリリースする。

共通の用語

開発メンバ・顧客・管理者全員でイメージや理解を共有するため、用語集や図表を作成する。

単純さ優先

品質低下のもとと複雑な実装の組込みを避け最も単純な実装を優先する。

テスト駆動開発

求める機能を明確化するため、テスト対象コードを実装するよりも前に単体テストを作成する。

リファクタリング

完成済みのものでもソフトウェアの機能を変えずにソースコードの品質を良くすることを随時行う。

ペアプログラミング

これは二人一組で実装を行い、一人が実際のコードをコンピュータに打ち込み、もう一人はそれをチェックしながら補佐するという役割を随時交代しながら作業を進める。

ソースコードの共同所有

開発チーム全員がどのコードに対しても改善処置を行えるようにするため、ソースコードの所有者を決めない。

常に統合

あるコードが単体テストをパスする度にすぐに結合テストを行い問題点や改善点を探す。

週 40 時間労働

集中力を高め、開発効率を高めるためには心身の健康を保つ必要があるため残業を認めない。

顧客も一緒

顧客は開発チームと同室（または近く）で開発の見守りを行う。

コーディング規約

上記を実現するためのにコーディング規約を決めて遵守する。

アジャイル開発などで導入されているペアプログラミングは，品質の向上や知識の共有を図るために，2 人のプログラマがペアとなり，その場で相談したりレビューしたりしながら，一つのプログラムの開発を行う。ペアプログラミングには，以下のようなメリットがあるとされている。

• 2 人の共同作業なので個々で行うよりも怠けにくい。
• 2 人で実装を行う相乗効果で，よりよいコードに仕上がることが期待される。
• 他の人からの問合せにも，空いている 1 人が対応できるので作業効率が向上する。
• 共同作業を行うことで，メンバに対する理解が進みチームワークが向上する。

プログラムをコンピュータに打ち込む人をドライバ，それを補佐する人をナビゲータという。

リファクタリング（Refactoring）は、外部から見たときのソフトウェアの機能や振る舞いを変えずに、ソフトウェアの内部構造を変えることをいう。ソースコードの品質を良くし、高効率化や保守性向上を目的として行われる。

完成済みのコードであっても随時改善することが、XP のプラクティス（実施項目）として挙げられている。

イテレーション（Iteration）は、アジャイル開発における反復の単位で、分析、設計、実装、テストの一連の活動を含む。アジャイル開発では、概ね数週間程度ごとにこの開発サイクルを繰り返して次第に完成度を高めていく。短い期間で区切ることで、開発の工程管理がしやすくなったり、計画の変更に対応しやすくなったりする利点がある。

テスト駆動開発は、XP の基本となる 12 のプラクティスのうちの 1 つで、求める機能を明確化するために、プログラムを記述するよりも前にテストケースを作成する開発手法である。そのテストをパスする最低限の実装を行った後で、機能を維持したままコードを洗練していくという手順で開発を進める。

継続的インテグレーション（CI : Continuous Integration）

システムのビルド，テストの実行を自動化し，短いサイクルで継続的に行うことで品質改善や納期短縮を図る手法であり，次のような効果が期待できる。

• 継続的に「出荷できる状態」にできる
• 新しく追加されたコードが問題既存のバグを引き起こしても，早期に検知できる。
• 問題に早期に対処することで継続的に出荷可能な状態を保つことができる。
• 動作環境も含め，継続的インテグレーションできるため，自動テストやアジャイル型開発の基盤の一つとなる。

(c) スクラムの特徴

スクラム（Scrum）とは、ソフトウェア開発手法の一つで、チームが一丸となって仕事に取り組むための方法論を中心にまとめられた方式。少人数で迅速に開発を進める、いわゆるアジャイルソフトウェア開発手法の一つ。

プロダクトオーナ

プロダクトオーナは，チームに最も価値の高いソフトウェアを開発してもらうために，プロダクトに必要な機能を定義し，プロダクトバックログの追加・削除・順位付けを行う。開発への投資に対する効果を最大にすることに責任をもつ。

開発チーム

開発チームは，実際に開発を行うチームのことで，開発者たちを指す。ビジネスアナリスト，プログラマー，テスター，アーキテクト，デザイナーなどの機能横断的な様々な技能を持った人がプロダクトを中心に集まり，自律的に行動する。開発チームはバックログに入っている項目を完了状態にし，プロダクトの価値を高めていくことに責任を持つ。

スクラムマスタ

スクラムマスタは，スクラムの理論とプラクティスを全員が理解するように支援する。それにより，スクラムチーム全体が自律的に協働できるように，場作りをするファシリテーター的な役割を担う。ときにはコーチとなってメンバーの相談に乗ったり，開発チームが抱えている問題を取り除いたりする。スクラム全体をうまく回すことに責任を持つ。

スクラムでは，スクラムチームを構成するプロダクトオーナ，開発チーム，スクラムマスターの役割，5 つのイベント，3 つの作成物が定義されている。

スクラム開発プロセスの例を次表に示す。

ベロシティ

ベロシティ（velocity）は，開発チームが 1 回のスプリント（またはイテレーション）で完了させたユーザーストーリのストーリポイントの合計値である。端的に言えば，1 スプリントにおける開発量のことである。

プロダクトバックログ

開発対象のシステムやソフトウェアで最終的に実現されるべき要求機能や要素をまとめたもの。

スプリントバックログ

スプリントバックログは，プロダクトバックログから抜き出された，今回のスプリントで追加する機能のリストである。スプリント中のスプリントバックログは開発チームが管理し，スプリントバックログへのタスクの追加や削除，見積りとその更新は開発チームの責任で行わなければならない。

③ DevOps

④ ローコード／ノーコード開発

⑤ ソフトウェア再利用

(a) 部品の種類と特徴

関数部品

オブジェクト部品（クラスライブラリ）

データ部品

プロセス部品

常駐部品と組込み部品

ブラックボックス部品

ホワイトボックス部品

パラメトリック部品

ノンパラメトリック部品

クローズドシステム部品

オープンシステム部品

(b) 部品設計の基準

モジュールの独立性

モジュールが，そのモジュールで完結し，他のモジュールと影響し合わない性質をモジュールの独立性という。良い設計で導出されたモジュールは独立性が高く，プログラムの保守性が高くなる。

モジュールの独立性を評価する尺度に，モジュール強度とモジュール結合度がある。モジュール強度を高く，モジュール結合度を低くするようにモジュール分割を行うことが，モジュールの独立性を高めるために重要となる。

• Masassiah Web Site，「モジュールの独立性」

カスタマイズ

ライブラリ

命名規則

⑥ リバースエンジニアリング

リバースエンジニアリング（reverse engineering）とは、出荷された製品を入手して分解や解析などを行い、その動作原理や製造方法、設計や構造、仕様の詳細、構成要素などを明らかにする。例えば，ソースコードから設計書を作成するのは，リバースエンジニアリングである。

互換性

コールグラフ

⑦ マッシュアップ

マッシュアップとは、各々の企業が提供している Web サービスを組み合わせて、あたかも新しい 1 つの Web サービスのようにする機能・開発技法である。IT の深い知識がなくても、既存の Web サービスを組み合わせて、短期間でアプリケーション開発ができることから、新しい開発技法として注目されている。

公開されている Web サービスには、SNS やサイトの情報を取得できる API をはじめ、Google Map に代表される地図情報や画像認識、音声認識、動画関連、翻訳、EC 情報など様々なものがあり、誰でも API を介してサービスを操作することができる。一からその機能を自サイトに実装するのに比べて、簡単に目的の機能を自サイトに掲載できる利点がある。

⑧ モバイルアプリケーションソフトウェア開発

モバイル用Web アプリケーションソフトウェア

ネイティブアプリケーションソフトウェア

ハイブリッドアプリケーションソフトウェア

User-Agent

パーミッション要求

端末仕様（ディスプレイサイズほか）の多様性への対応

アプリケーションソフトウェア動作中の圏外時・着信時の対応

アプリケーションソフトウェア審査

アプリケーションソフトウェア配布

(2) 構造化手法

階層構造化

段階的詳細化

構造化チャート

状態遷移図

HIPO（Hierarchy plus Input Process Output）

DFD

ソフトウェア構造

(3) 形式手法

モデル検査，VDMTools，Z 言語，SPIN

(4) 開発プロセス

① ソフトウェアライフサイクルプロセス

SLCP-JCF（共通フレーム）

共通フレームとは，情報処理推進機構（IPA）が発行しているソフトウェア取引に関するガイドラインで，ソフトウェアの構想・設計から開発，導入，運用，保守，破棄に到るまでの各工程について，個々の作業内容，用語の意味などの標準的なモデルを示したもの。

共通フレームの目的は，取得者と供給者の二者間取引における共通の物差しとして用いることで，取引を明確化することである。

共通フレームは、ソフトウェアライフサイクルにかかわる諸活動を網羅的に定義した百科事典のようなもので、そのまま適用するのではなく利用の局面において対象とするプロジェクトの範囲や重要度に応じた修整が必要となる。修整（tailoring）とは、使用する開発モデルに合わせてアクティビティやタスクを取捨選択する作業で、共通フレームを適用する上での必須の活動である。

JIS X 0160 : 2012「ソフトウェアライフサイクルプロセス」

英語名は "Systems and software engineering−Software life cycle processes" である。

この規格の目的は，ソフトウェア製品のライフサイクルにおける，取得者，供給者及び他の利害関係者の間で円滑にコミュニケーションを行う場合に必要な定義されたプロセスの集合を提供することである。

この規格は，次の者を対象としている。

1. システム，ソフトウェア製品及びソフトウェアサービスの取得者
2. ソフトウェア製品の供給者，開発者，運用者，保守者，管理者，品質保証管理者及び利用者

この規格は，二者間の契約で使用することを想定しているが，この二者が，同じ組織に属している場合でも同様に適用できる。この規格が適用される状況としては，非公式な合意から法的に拘束力がある契約にまで及ぶ。単一の当事者は，一連のプロセスを自ら課して，この規格を適用してもよい。ここに記載したことは，市販のソフトウェアの供給者又は開発者がこの規格を使用することを妨げるものではない。

JIS X 0170 : 2020「システムライフサイクルプロセス」

英語名は "Systems and software engineering-System life cycle processes" である。

この規格の目的は，システムのライフサイクルにおける，取得者，供給者及び他の利害関係者の間で円滑に情報伝達を行う場合に必要な定義されたプロセスの集合を提供することである。

この規格は，組織が取得者の役割を行う場合でも，供給者の役割を行う場合でも適用される。単一の組織が，自主的に計画し開発する状況又は複数の当事者で計画し開発する状況でも，使用することができる。当事者は，同じ組織又は異なる組織であってもよく，この状況は非公式の合意から公式の契約にまで及ぶ。

この規格の中のプロセスは，例えば，方法，手順，手法，道具及び訓練された人員といった，業務環境を確立するための基礎として使用することができる。附属書Aは，これらのシステムライフサイクルプロセスの修整の仕方に関する基準を示す。

プロセス

アクティビティ

タスク

② プロセス成熟度

システム開発は場当たり的にではなく，定義されたプロセス（プラクティス）に則って実施すべきである。そのためにも，標準的なプロセスを確立し，成熟させていくことが求められる。CMMI (Capability Maturity Model Integration) は，ソフトウェアを開発する組織やプロジェクトにおけるプロセスの成熟度を評価するモデルである。開発プロセスの成熟度は 5 段階に分けて定義されている。

初期

プロセスが場当たり的。

管理された

プロセスは存在するが定義や管理は行われていない

定義された

定義・標準化されたプロセスが確立されている。

定量的に管理された

プロセスと成果物を定量的に計測・評価できる。

最適化している

• 組織が自発的に継続してプロセスの改善を行える
• 定量的なフィードバックを元に継続的に改善されている

知的財産適用管理

(1) 著作権管理

プログラムの著作権

職務著作

(2) 特許管理

特許権

特許で保護された技術を使っていないソフトウェアであっても，使用許諾することは可能である。

特許のサブライセンス（再実施権）とは、特許の実施権者が第三者にそのライセンスを許諾できる権利をいう。

特許として登録された発明は、原則として特許権者だけが独占して製造や販売等を行うことができる。しかし特許権者と「実施契約」を締結し、実施権者となれば特許権者以外の人でも発明を事業として利用することが可能となっている。実施権者は、実施契約の範囲内で特許された発明を使用することができるが、子会社や提携会社などは特許権者と実施契約を結んでいないので製造や販売を行うことが原理的にはできない。このような不便に対処するために特許法77条4項では「専用実施権者は、特許権者の承諾を得た場合に限り、その専用実施権について質権を設定し、又は他人に通常実施権を許諾することができる。」として、特許の実施権者は他人に通常実施権を許諾することができることを規定している。

専用実施権

特許の実施権の許諾を受けた者が，当該特許の実施権を独占的に行使すること。

通常実施権

(3) ライセンス管理

ライセンス

ライセンスとは，知的財産の所有者が与える，知的財産の使用を許す（使用許諾）権利であり，所有者がユーザにライセンスを与える契約をライセンス契約という。

ライセンシ

(4) 技術的保護

コピーガード（copy guard）

コピーガードとは，信号やデータの記録媒体（メディア、ディスク）に講じられる、記録内容の複製を防止するための技術的な措置のこと。音楽や映像、ソフトウェアなど著作物の販売に用いられる記録メディアでよく用いられるもので、著作者に無断で行われる不正な複製・配布を阻止するために行われる。

DRM (Digital Rights Management)，デジタル著作権管理

DRM とは、デジタルデータとして表現されたコンテンツの著作権を保護し、その利用や複製を制御・制限する技術の総称。デジタル著作権管理。音声・映像ファイルにかけられる複製の制限技術などが有名だが、広義には画像ファイルの電子透かしなども DRM に含まれる。

アクティベーション（activation）

アクティベーションとは、活性化、有効化などの意味を持つ英単語。IT の分野では、機器やソフトウェア、システムを利用可能な状態にする処理や手続きなどのことを「プロダクトアクティベーション」（product activation）あるいは略してアクティベーションということが多い。

CPRM (Content Protection for Recordable Media)

CPRM とは、DVD などに採用されている、記録メディア向けの著作権保護技術の一つ。利用者側で内容を書き込み可能なメディア（recordable media）向けの方式で、コンテンツのデジタルコピーをメディアに記録する際の一度だけ許容し、メディアから他の機器やメディアへのコピー（ダビング）を禁じる「コピーワンス」を実現する。

AACS (Advanced Access Content System)

AACS とは、Blu-ray Disc で採用されている著作権保護のための映像・音声データのコピープロテクト技術。販売・レンタルされる映像ソフトやデジタル放送の録画などを違法コピーから守るために用いられる。

開発環境管理

(1) 開発環境構築

構成管理

システムを適切に稼働させていくためには，システムがどのような品目（サブシステム，プログラムなど）の組合せで構成されているか，それらのバージョンはいくつか，いつ変更されたかといった事項を把握しておく必要がある。

構成管理はこれらの事項を管理するために実施する。

ソフトウェアライセンス

(2) 管理対象

① 開発環境稼働状況管理

資源管理

運用管理

② 設計データ管理

更新履歴管理

アクセス権管理

検索

③ ツール管理

構成品目

ある品目に変更の必要が生じた際に，関係する品目の変更を漏れなく行うために，構成管理ツールを使って，品目の依存関係やバージョンを管理する。

構成管理ツールにおいて，構成品目を管理するデータベースをリポジトリという。リポジトリへの操作には次表のようなものがある。

ソフトウェア開発・保守の工程において，リポジトリを構築する理由は，各工程での成果物を一元管理することによって，開発・保守作業の効率が良くなり，用語の統一もできることである。

バージョン管理

④ ライセンス管理

不正コピー

バージョン管理

棚卸

構成管理・変更管理

(1) 構成管理

ソフトウェア開発における構成管理（コンフィギュレーション・マネジメント）とは、ソフトウェアがどのような構成品目の組み合わせで構成されているかという構成識別体系を管理台帳や管理用のソフトウェアに記録して管理することをいう。個々のプログラム，ライブラリ，設計書，マニュアルなどの構成要素ごとに、変更内容，最新のバージョン番号，リリース番号，ビルド番号などが記録されている。

構成管理により，ソフトウェア，ハードウェアなど，システムの構成要素を効率よく管理できる。

ソフトウェア構成管理

ソフトウェア構成品目

SLCP（Software Life Cycle Process：ソフトウェアライフサイクルプロセス）

構成管理計画

ベースライン

バージョン管理システム（VCS : Version Control System）

バージョン管理システムとは、ファイルの変更履歴の保存・管理を行うソフトウェア。管理下のファイルについて、過去の版の参照や、複数の版の比較、差分の検出などを行うことができる。

(2) 変更管理

① 構成状況の記録

• プロダクト・構成要素などの仕様・特性を文書化する
• 変更の実施状況を記録し報告する
• 変更事項の適合性を検証する監査に情報を提供する

② ソフトウェア構成品目の完全性保証

一貫性

正確性

③ リリース管理及び出荷

バージョン管理

保管管理

本稿の参考文献

• アジャイルソフトウェア開発宣言
• アジャイル宣言の背後にある原則
• IPA，「アジャイル領域へのスキル変革の指針　アジャイル開発の進め方」，2020年2月
• 市谷 聡啓，新井 剛，小田中 育生「いちばんやさしいアジャイル開発の教本 人気講師が教える DX を支える開発手法」，株式会社インプレス，2020年5月1日発行

いちばんやさしいアジャイル開発の教本　人気講師が教えるDXを支える開発手法 [ 市谷聡啓;新井剛;小田中育生 ] 価格：1760円（税込、送料無料) (2021/9/12時点) 楽天で購入