ソフトウェア工学１第9回 プロジェクトマネジメントと構成管理

2017年6月13日中島

1

授業内容

1. プロジェクトマネジメント（２）：リスク管理

2. 構成管理

2

１．プロジェクト･マネジメント（ＰＭ）とは（おさらい）

• プロジェクト：

1. 期間がある

2. 達成すべき目標がある

3. 割り当てられたリソース（人と設備）を使う一連のタスクである

4. 計画的かつ系統的なアプローチで目標を達成する

5. （多くの場合）チームで活動する

• マネジメント：

≠ (日本的な意味の）管理する

＝ 経営する，困難を克服する，道を切り開く

3

１．プロジェクト･マネジメント（ＰＭ）とは（おさらい）

開発の始まり 監視＆制御

成功領域 （品質、コスト、納期）

最初の目標（理想）

計画

再計画

・成功までのルートを発見

ｂｙ W. Royce

マネジメント ＝経営する，困難を克服する，道を切り開く

・駄目なら目標・ルートを再設定

・ルートを基準に監視＆制御

達成可能な目標

開発終了

4

２．PMの知識体系 （おさらい）

統合マネジメント

スコープマネジメント

タイムマネジメント

コストマネジメント

品質マネジメント

人的資源マネジメント

コミュニケーションマネジメント

リスクマネジメント

ステークホルダーマネジメント

プロジェクト憲章作成プロジェクトマネジメント計画書作成プロジェウト作業の指示・マネジメントプロジェクト作業の監視・コントロール統合変更管理プロジェクトやフェーズの終結

スコープマネジメント計画要求事項収集スコープ定義WBS作成スコープ妥当性確認スコープコントロール

タイムマネジメント計画アクティビティ定義アクティビティ順序設定アクティビティ資源見積りアクティビティ所要時間見積りスケジュール作成スケジュールコントロール

コストマネジメント計画コスト見積り予算設定コストコントロール

品質マネジメント計画品質保証品質コントロール

人的資源マネジメント計画プロジェクトチーム編成プロジェクトチーム育成プロジェクトチームのマネジメント

コミュニケーションマネジメント計画コミュニケーションマネジメントコミュニケーションコントロール

リスク特定定性的リスク分析定量的リスク分析リスク対応計画リスクコントロール

調達マネジメント計画調達実行調達コントロール調達終結

ステークホルダー特定ステークホルダーマネジメント計画ステークホルダーエンゲージメントマネジメントステークホルダーエンゲージメントコントロール

コストマネジメント リスクマネジメント

調達マネジメント

ステークホルダーマネジメント

Quality

Delivery

Cost 知識エリアの構成要素知識エリア

PMBOK: Project Management Body of Knowledge

10個あることを覚えとこう

１０個の知識エリア

5

３．プロジェクトマネジメントの基本（おさらい）

プロジェクトマネジメント ＝

リスクマネジメント

監視＆制御計画

スコープ（目標）を明確にし、不確定要素（リスク）を減らし、計画＋監視＆制御の精度を上げていくプロセス

時間

リスクマネジメント ＋ （計画＋監視＆制御）＊

スコープ定義 ＋

スコープ定義

プロジェクト目標を決める

6

リスクマネジメント

監視＆制御計画スコープ定義

４．スコープの定義（おさらい）

スコープ記述： プロジェクトの目標を設定する

・作業範囲 ：何を生み出すか (作り出す成果物とサービス）

・成功目標 ：何をもって成功とするか

・制約条件 ： プロジェクトが満たさなければならない条件

・前提条件 ： プロジェクトの成功上前提とする条件

・終了条件 ： プロジェクトが終結する条件

QやDに対する必達条件、規制、標準、運用環境など

客先の仕様の確定時期、再利用の目論見、前のプロジェクトの終了時期、外注先の利用など

・Ｑ (Quality) ： 要求する成果物とサービスに対する品質目標・Ｃ (Cost) ： 開発に要するコストの目標・Ｄ (Delivery) ： 成果物とサービスを提供する納期

7

プロジェクトスコープ（BJG開発の例）

• 開発の見積もりと前提条件を盛り込み、スコープを修正

作業範囲

成功目標

制約条件

前提条件

終了条件

ブラックジャックゲーム(BJG)の開発

BJGソフトウェアの開発

BJGプログラム

BJGマニュアルデモンストレーション

Q: プログラム： 顧客が満足する使用性と信頼性、GUI対応の拡張性をもつマニュアル： 顧客が読んで分かる

C: 開発コスト 22万円以内 （プログラム生産性 10行/人時以上）D: 10日後：プログラム動作確認完了、14日後：展示会終了

既開発のポーカーゲームの掛金管理部を80％流用する

14日後に展示会を実施、C言語で開発

展示会後の納入

これ書けたら一人前

8

３．プロジェクトマネジメントの基本（おさらい）

プロジェクトマネジメント ＝

リスクマネジメント

監視＆制御計画

スコープ（目標）を明確にし、不確定要素（リスク）を減らし、計画＋監視＆制御の精度を上げていくプロセス

時間

リスクマネジメント ＋ （計画＋監視＆制御）＊

スコープ定義 ＋

スコープ定義

プロジェクト目標を決める

計画を立てる

最初は不確定なことばかり→「リスク」がいっぱい

リスクを減らす計画

管理のための計画

9

リスクマネジメント

監視＆制御計画スコープ定義

５．リスクマネジメント

リスク：

• もし発生すれば，プロジェクト目標にマイナス（あるいはプラス）の影響を及ぼす不確実な事象

• 「～可能性がある」と表す。根拠（良くない状態）も記述

• リスクは、プロジェクトの最初で最大

例題： 「豊洲に来て初めての授業を受講する」のリスク

朝久しぶりなのでバタバタする⇒• 授業に必要なものを忘れ、授業で困る可能性がある。• 傘を忘れ、雨に濡れ、授業をまともに受けられない可能性がある。

最近電車の人身事故・信号トラブルが多い⇒• 電車が遅れ、授業に遅れる可能性がある。

豊洲は行ったことがない⇒• 電車の乗り換えを間違え、授業に遅れる可能性がある。• 豊洲から道に迷い、授業に遅れる可能性がある。

よくない兆候悪影響

起こり得る事象

10

リスク識別

対応策の策定

リスク分析

５．リスクマネジメント： 全体の流れ

リスクを洗い出す

リスクの発生確率の分析リスクの影響度の分析リスクの優先度付け

リスク管理

リスク対策のフォローリスクの評価（要すれば、上記手順のやり直し）

リスク対応策の洗い出し投資対効果の見積もり対応策の決定

11

リスク識別

対応策の策定

リスク分析

リスク識別

リスクを洗い出す

リスクの発生確率の分析リスクの影響度の分析リスクの優先度付け

リスク管理

暗黙の前提条件過去の経験（チェックリスト）ブレンストーミングステークホルダ分析

使用可能なテクニック

リスク対策のフォローリスクの評価（要すれば、上記手順のやり直し）

リスク対応策の洗い出し投資対効果の見積もり対応策の決定

12

リスク識別

過去の経験： システム開発のリスク（過去の失敗から抽出）

開発 キーとなる技術者の参加遅延、中途離脱

開発要員、開発設備が不足する

協業先が約束を反故（納期遅れ、品質未達、作業不履行）

利用したことのない先端技術へ過度に期待・依存する

開発中のデータを喪失する（手順ミス、ウィルスによる被害）

技術 利用技術に対する経験が不足している

要求機能・性能を実現できない（アルゴリズムがない、アーキテクチャが悪い）

自作外ソフトウェアが開発ソフトウェアと適合しない

リスク例カテゴリ

要求 顧客の要求があいまいで解釈を誤る

要求が矛盾を含む（ステークホルダ間、対運用環境・商習慣）

外部要因（競合他社の動向、政治的決定）による要求変更

13

リスク識別

対応策の策定

リスク分析

リスク分析

リスクを洗い出す

リスクの発生確率の分析リスクの影響度の分析リスクの優先度付け

リスク管理

リスク対策のフォローリスクの評価（要すれば、上記手順のやり直し）

リスク対応策の洗い出し投資対効果の見積もり対応策の決定

14

リスク分析

• 損失の期待値（発生確率×影響度）から対策優先順位を決める

R: リスク

L(R): リスクRによって生じる損失

P(R): リスクRが発生する確率

Ec(R): リスクRによる損失の期待値

Ec(R) = P(R) × L(R)

スケジュール／品質

より大きいものが優先度大

基準以上に不具合が発生し納期を超過する可能性がある

30%8万円

8万円×30%=2.4万円

15

損失期待値：

リスク識別

対応策の策定

リスク分析

リスク対策の策定

リスクを洗い出す

リスクの発生確率の分析リスクの影響度の分析リスクの優先度付け

リスク管理

リスク対策のフォローリスクの評価（要すれば、上記手順のやり直し）

リスク対応策の洗い出し投資対効果の見積もり対応策の決定 リスクマネジメント

監視＆制御計画

時間

スコープ定義

リスクを減らす計画

16

リスク対策の策定： 対応策の洗い出し

軽減対策の例• 開発プロセスの選択 (アジャイルなど）• 顧客参加• 管理計画の強化• 事前調査 （プロトタイピング、ベンチマーク分析）• 要員計画

委譲対策の例• 外部コンサル、外部委託利用

回避： 原因そのものを取り除く

軽減： 発生の確率／頻度／影響度を抑制する委譲： リスクごと他組織へ任せる受容： リスクを知りつつ対策せずに臨む

（発生時の対処手段を計画、例：コストを積む）

これ知っていると一目置かれる

４つのタイプのリスク対策

17

リスク対策の策定： 投資対効果の見積もり、リスク対応策の決定

• リスク対応策は、投資対効果のあるものを選ぶ

R: リスク

L(R): リスクRによって生じる損失

P(R): リスクRが発生する確率

Ec(R): リスクRによる損失の期待値

Ec(R) = P(R) × L(R)

スケジュール／品質

T: 対策

回避 ： P(R) → 0軽減 ： P(R) 減少 or L(R) 減少

C(T) < Ec(R) – Ec(T(R))

対策コストが、対策による損失の削減期待値を越えなければ、対策は有効

C(T): 対策にかかるコスト

Ec(T(R)):対策後損失期待

損失期待値： 8万円×30%=2.4万円

対策： テストを強化する対策コスト： 3万円 ⇒ ×

リスク： 基準以上に不具合が発生し納期を超過する可能性がある

18

[対策] ゲーム専門家を雇い仕様を作成してもらう （委譲）

問題１

• 「ブラックジャックゲームの開発」のリスクをあげ、対策を立てよ。どのタイプの対策か明確にせよ。

開発者がゲームをよく知らない⇒• 誤った仕様で作ってしまい、顧客確認で作り直しといわれ

コストオーバーする可能性がある。

前提条件で、「既開発のポーカーゲームの掛金管理部を80％流用」と言っているが、誰もその可能性とやり方を確認していない⇒

• ほとんど再利用ができず、コストや納期をオーバーしてしまう可能性がある。

19

[対策] 危険すぎるので開発そのものを断る （回避）

[対策] 早めに流用可能性を調査し、流用方法を検討する（軽減）

[対策] 流用できない場合に備え、要員割り当ての計画と、利益からコスト引当 をしておく （受容）

授業内容

1. プロジェクトマネジメント（２）：リスク管理

2. 構成管理

20

チーム開発と構成管理上の問題

保守困難

変更理由

ビルド構成

ドキュメント

プログラム

BV1.0

BV？

AV1.0

AV1.1

AV1.2

CV1.0

AV1.3

CV1.0

変更理由変更要求

統制されない変更

構成不整合（旧版の混入）

不整合不一致

不完全修正

原因不明の実行時エラーの発生

対応不明確 要求を反映し

ていないプログラム

同時多発修正→衝突→手戻り

生産性の低下

品質の低下

テスト成績書

設計書

信用できないドキュメント

21

分割コンパイル：開発を並行させる

• 関数のまとまりごとに，ファイルを分けて，開発できる．

• 別々にコンパイル＆テストしてできたオブジェクトコード（.0ファイル）を，リンクして（結合して）実行ファイルを作る．

f.cvoid f(void){}

int main(void){

f();}

main.c

コンパイル

コンパイル

リンク

f.o

main.o

a.out別々に作る

くっつけて完成品にする

% gcc –c f.c

% gcc –c main.c

% gcc main.o f.o

222015/07/13

ビルド： 問題１ 複雑な段取り

• ビルド： コンパイル・リンク・インストール

• ビルドには、段取りが必要（間違えやすい）– インストール用ファイルの作成： % tar cvf robot.tar a.c .b.c …– コンパイル： % gcc –c –UNIX –I/usr/local/include a.c

• コンパイラ指定

• オプション指定

• インクルードファイルの捜索パスの指定

– リンク： % gcc –o exename a.o b.o c.o –lm• リンクするオブジェクトファイルの指定

• リンクするライブラリの指定

• 実行ファイル名の指定

– インストール： % cp exename /usr/local/bin• 実行ファイルや設定ファイルを適切な場所に置く

23

ビルド： 問題２ 入り組んだ依存関係

• ファイル間の依存関係：

– あるファイルに変更があったら、その結果はビルドに反映

common.h a.c

b.c

libm.a

a.o

b.o

exename

c.c c.o

修正✔

依存する

✔

✔

✔

✔

✔

% gcc –c –UNIX –I/usr/loca/include a.c% gcc –c –UNIX –I/usr/loca/include b.c% gcc –o exename –lm a.o b.o c.o

以下を実行しなければならない

24

ビルド： 解決 支援ツール： make

• スクリプト(makefile)に、段取りと依存関係を記述⇒自動的にビルド 等を実施

Makeに似たツール： Apache AntMake機能を統合環境として提供： visual studio, eclipse

CC = gccCFLAGS = -UNIX -I/usr/local/includeLIBRARY = -lmEXENAME = exenameOBJS = a.o b.o c.o

$(EXENAME) : $(OBJS)$(CC) –o $(EXENAME) $(OBJS) $(LIBRARY)

.SUFFIXES: .c .o

.c.o:$(CC) -c $(CFLAGS) $<

a.o b.o : common.h

25

バージョン管理： 問題

• 変更の場所・経緯・理由が不明

Aさん

Aさんの作業環境

a.cb.cc.c

common.h

a.cb.cc.c

common.h最新版だけ

コピー

編集

ビルド実行

修正 チームのリポジトリ（プログラムのマスタ）

• 新しくなったのに更新を忘れてしまう

• 間違えて古いものをコピーしてしまう

• Aさんがなぜ修正したかわからない• 要求変更を反映したのか、テスト済な

のかわからない

他のメンバ

26

バージョン管理： 解決 支援ツールsubversion

• 変更の履歴の保持

Aさん

Aさんの作業環境

a.cb.cc.c

common.h

a.cb.cc.c

common.h

編集

ビルド実行

修正 チームのリポジトリ（プログラムのマスタ）

他のメンバ

更新update

変更の反映commit

（他の人の変更を反映する）

a.cb.cc.ccommon.h

revision1 revision2 revision3

Commit a.c Commit a.c c.c作業者：Bさん更新日：2015.5.4理由： CR1-10反映

作業者：Aさん更新日：2015.5.10理由：CR11-20反映

変更履歴

• 変更履歴で、何にいつどんな修正を何の理由で起こったかわかる

• 何を反映していないかわかる• どこを変えたかわかる• 変更を元に戻すことができる

差分 差分

差分

27

共同作業の管理： 問題

• ファイルへの変更の衝突

a.cb.cc.c

common.h

Aさん

Bさん

Aさんの作業環境

Ｂさんの作業環境

a.cb.cc.c

common.h

a.cb.cc.c

common.h衝突

編集

ビルド実行

編集

ビルド実行

修正

修正

チームのリポジトリ（プログラムのマスタ）

更新update

更新update

変更の反映commit

変更の反映commit

衝突

28

共同作業の管理： 解決 支援ツールsubversion

• 変更を制御する

a.cb.cc.c

common.h

Aさん

Bさん

Aさんの作業環境

Ｂさんの作業環境

更新update

a.cb.cc.c

common.h

a.cb.cc.c

common.h

更新update

変更の反映commit

変更の反映commit

編集

ビルド実行

編集

ビルド実行

修正

修正

チームのリポジトリ（プログラムのマスタ）

① commitで衝突があったら反映しない② updateで衝突があったら：

→ 反映できるものはマージ→ 反映できない場合はエラー通知

29

リリース制御： 問題

• A社向けに段階リリース（α版、β版、最終版）をする．

a.cb.cc.ccommon.h

要求仕様書テスト仕様書マニュアルMakefile

最終版β版α版

• 各リリースについて、以下が確認しにくい

− どの版の要求仕様書やテスト仕様書に基づいてテストしたか− テスト済のものを確実にリリースに含めているか

• α版やβ版で不具合が起きた時に、再ビルドと不具合再現できない

30

リリース制御： 解決 支援ツールsubversion

• リリースに含めるべき機能に関するテストを終えたものをコミット• 特定リビジョンのスナップショットを取り、α版、β版、最終版としてタグ付

a.cb.cc.ccommon.h

要求仕様書テスト仕様書マニュアルMakefile

最終版ﾘﾘｰｽβ版ﾘﾘｰｽα版ﾘﾘｰｽ

A機能のみテスト済

A,B機能テスト済

全機能テスト済

タグ タグ タグ

R5 R7 R9

• 意味のある状況（テスト済等）にある構成を明確化

• リリースの再構築が容易

リポジトリのスナップショット

タグのもつ情報（構成品目とそのステータス） 31

ブランチとマージ： 問題

• A社向けにソフトウェア製品Xを開発した．少し変えてB社向けに製品Yを作るが，A社向けも保守の必要がある。

• A社もB社も変更要求、クレームがあり、対応が必要

Git、GNU arch、Mercurial、SourceSafe

A社向け開発

B社向け派生開発

A社向け保守

全ファイルコピーでブランチ

B社向け拡張

A社ｸﾚｰﾑ対応

a.c

b.c

c.c

c.c’’

b.c’ c.c‘

バグ対応

a.c’

• 元からあったバグへの対応忘れ

• 要求に合わせ増えるブランチ

• マージしようにも、どこが、何の理由で、どう変更されているかわからない

⇒ 増大する保守費32

ブランチとマージ： 解決 支援ツールsubversion

• できるだけ幹から派生、適切なタイミングでマージ

A社向け開発

B社向け派生開発

A社向け保守

仮コピーによるブランチ

B社向け拡張

A社ｸﾚｰﾑ対応

a.c

b.c

c.c

c.c’’

b.c’ c.c‘

バグ対応

a.c’

• マージを支援

a.c’

幹c.c’’

• ブランチ時に、コピーは発生せず、修正が入って初めて差分が付け加わる

• マージを支援し、幹を育てるSubversionに似たツール：Git、GNU arch、Mercurial、SourceSafe 33

まとめ

• プロジェクトマネジメントにおいて

• チームによるソフトウェア開発において，構成管理はとても重要

• 構成管理にはいろいろな側面がある

– ビルド，バージョン，リリース管理，

– 共同作業，ブランチ・マージ

• 支援するツールがある： make, subversion• 構成管理の概念を理解し、ツールを使いこなそう

34