3213 プロジェクトマネジメントにおけるレビュー計画に関する研究

3213
日本機械学会
第 18 回設計工学・システム部門講演会・2008.9.25-27
Copyright © 2008 社団法人 日本機械学会
プロジェクトマネジメントにおけるレビュー計画に関する研究
Planning of Project Review in Project Management
正 青山 和浩（東大）
正
Kazuhiro AOAYAMA (The University of Tokyo)
古賀 毅（東大）
Tsuyoshi KOGA (The University of Tokyo)
正 丹羽 隆（東大）
渥美
Takashi NIWA (The University of Tokyo)
航（東大）
Wataru ATSUMI (The University of Tokyo)
Recently, the development of a large-scale and complicated system has the critical subject how to eliminate rework costs and
satisfy user requirements in the limited development period. The innovative project management in the contents industry is
especially desired because the content development has the problems that the evaluation of contents by users is so different from by
developers that the content development should adopt the evaluation of the contents under development by users and developers
(review). Therefore, the proper review planning is quite important in the content development. However, although the
developers should create a new content to meet the ever more uncertain needs of users owing to competing with other developers
for novelty and originality, the concentration on the competition with no regard to the review by users can bring on the unwanted
contents.
In this research, the authors pose the problem "The optimal planning of review timing, frequency, and substance" to be solved
with the objective of a proper review planning in the content development. Moreover this problem is formulated, and we develop
the tool to solve the formulated problem on a computer for the support a project manager in the content development.
Key Words： Project Management, Design Management, Review-Driven Development, Risk Management, Content Development
1. はじめに
2. コンテンツ開発と関連研究
近年，大規模化・複雑化が進むシステムを開発する際に，
限られた開発期間の中で，如何に手戻りコストを抑え，かつ，
ユーザ要求を確実に満足するシステムを開発・設計できるか
が重要な課題となっている．ユーザ要求の実現を確実にする
ために，システムの開発モデルとして，ウォーターフォール
モデルから，プロトタイピングをベースとした発展型の開発
モデルへ移行することが検討されている．さらに，開発・設
計におけるプロジェクトマネジメント手法を導入し，リソー
ス，コスト，および時間などのシステマティックな管理が検
討されている．
一方において，労働集約型の典型的な産業として位置づけ
られるコンテンツ産業では，そのコンテンツの大規模化・複
雑化は深刻な問題であり，コンテンツ開発における革新的な
マネジメントが待望されている現状がある．一般的にコンテ
ンツ開発では，ユーザと開発者とが有するコンテンツを評価
する視点に大きな隔たりが存在するため，ユーザと開発者の
双方によるコンテンツの評価（以下レビューと呼ぶ）を開発
段階において積極的に取り入れる必要がある．このレビュー
によってユーザ要求の不明確性を可能な限り排除し，ユーザ
要求に合致したコンテンツを開発することが期待される．し
たがって，コンテンツ開発では，適切なレビューの計画が重
要な鍵を握ると理解できる．
2-1. コンテンツ開発におけるレビュー計画
財団法人デジタルコンテンツ協会[2]は，コンテンツを次の
ように定義している．
「様々なメディア上で流通する［映像，音楽，ゲーム，
図書］など，動画・静止画・音声・文字・プログラムな
どの表現要素によって構成される“情報の内容”」
本研究では，特にユーザ要求が不明確なコンテンツの開発を
対象に，その開発のマネジメントを研究対象とする．
先述のように，コンテンツ産業ではコンテンツの新規性お
よび独自性を競う必要があり，開発者は過去のコンテンツに
対する評価などを基に，不明確なユーザ・ニーズに対して新
しいコンテンツを考案する．しかしながら，ユーザによるレ
ビューを全く取り入れずに開発を進めてしまうと，最終的に
開発されたコンテンツはユーザに受け入れられない可能性
が高くなってしまうといったリスクが存在する．
著者らは，コンテンツ開発を例題に，プロジェクトマネジ
メントに関する研究に取り組んでおり，既報告[1]において，
コンテンツ開発におけるレビューの導入とその計画の重要
性を提起している．この先行研究において，コンテンツ開発
プロセスにレビューを導入するために必要なコンテンツの
モデルを考案し，開発プロセスを評価するシミュレーション
を行うためにレビュー，タスク，およびレビューウェイトの
モデル化を検討している．さらに，提案するコンテンツ開発
モデルを用いてプロジェクトマネージャーが開発プロセス
を計画する方法も提案している．本研究では，先行研究を発
展させ，「レビューを考慮したコンテンツ開発における，プ
ロジェクトマネジメントのモデル化」を研究対象として設定
する．
Working Load (Man-Hour)
本研究では，コンテンツ開発における適切なレビューを計
画することを目的に，解決すべき具体的問題として，「レビ
ューのタイミング，回数，内容の最適計画問題」を設定する．
この問題を定式化し，計算機によって解くことができるツー
ルを提供することで，コンテンツ開発におけるプロジェクト
マネージャーを支援することを狙っている．
Bad Managed Project
Well Managed Project
Design
Lifecycle
Production
Use
Fig. 1 Review Timing and Man-Hour (Excerpt form [3])
日本機械学会〔№08-2〕第18回設計工学・システム部門講演会CD-ROM論文集〔2008.9.25-27,京都〕
-506-
Inspection
また，関連研究ではミーティングを定量的に扱うことを提
案しているが，最適なミーティングの決め方や，それに伴う
開発プロセスの最適化については十分に議論されていない．
そこで本研究では，ミーティングのモデルをレビューと対応
付け，レビューを開発プロセス内で定量的に扱えるようにし，
最適なレビューのタイミング，回数，内容を求めることを検
討する．
１）レビューのタイミング（時期）の計画問題 一般的に開
発プロジェクトが終盤に近づくにつれてユーザはコンテン
ツを評価し易くなる．しかしながら，プロジェクト終盤であ
ればあるほど軌道修正が困難になり，手戻りコストを増大さ
せるリスクが増加する[3][4]．したがって，Fig.1 が示すプロ
ジェクトの計画の良否と作業負荷の関係から推測できるよ
うに，レビューはできるだけ早期が良いとされているが，適
切なタイミングでレビューすることが望まれる．
3. コンテンツの開発プロセスのモデル化
２）レビューの実施回数の計画問題 開発リスクを低減する
対策として，レビューの回数を増やし，一回のレビューあた
りの手戻りの発生を軽減することが考えられる．しかしなが
ら，レビュー自体にも時間を要し，人件費などのコストが発
生するため，単純にレビュー回数を増やすことは容易ではな
いといった問題もある．
本研究では， Fig.3 が示すように，サブコンテンツ，タス
ク，リソースおよびレビューによって開発プロセスを表現で
きるものとしている．本章では，これらのモデル化について
述べる．
３）レビュー内容の計画問題 ユーザと開発者とではレビュ
ーする観点が大きく異なるため，ユーザ視点のレビューを行
うためには，適切な情報を含む成果物を用意する必要がある．
したがって，レビューの内容，および時期を決めるためには，
成果物の制作時期，スケジュールを考慮する必要がある．
3-1. コンテンツ，タスク，リソースのモデル化
本研究では，コンテンツは複数のサブコンテンツから構成
され，またサブコンテンツも複数のサブ（サブ）コンテンツ
から構成されると仮定する（Fig. 4）
．詳細は後述するが，サ
ブコンテンツを定義する情報として，必要工数（Man-Hour）
および，その進捗度（Progress）を扱う．
2-2. 関連研究におけるモデル化
野間口・藤田らは，学生のものづくり演習を題材に，工業
製品の開発・設計プロジェクトにおけるミーティングの効用
を議論している[5]．本研究が対象とするレビューは，彼らが
定義しているミーティングと同様の効果を持つものと考え，
レビューがプロジェクトに及ぼす効果を定量的に扱う際の
参考にする．下記に，関連研究が扱う情報の概要を示す．
Increasing the
Achievement Level of
Design Knowledge
Previous Step
Decreasing the
Achievement Level of
Design Knowledge
Storing Design
Knowledge
(Execute Task)
Pointing Out Wrong
Design Knowledge
設計知識：設計者が（ある時点で）正しいと考える設計知識
を指す．設計知識を正しいものと判断するためには設計
者の能力や共同作業の仕組みにもよるが，このような知
識は開発プロセスが設計されるに従って徐々に蓄積・習
得される特徴をモデル化している．
meeting
Removing the gap
between Tasks
Next Step
設計知識の達成レベル：設計者が習得した設計知識の量およ
び品質を扱う情報としてモデル化している．
Finding the Wrong in
the Design
Knowledge
Fig. 2 Behavior of Meetings
タスク：開発プロセスの一部．近年，製品開発の規模は拡大
し続けており，必要とされる設計知識の量も膨大なもの
となっている．したがって，製品開発が複数の設計者に
よるコラボレーションによって行われるのが普通であり，
さらには，人やチームあたりに要求される設計知識の量
を減らすために，チーム同士のコラボレーションが行わ
れている特徴を指摘している．
2-3. タスクの整合性とミーティング
関連研究では，製品の部品が互いに依存関係にあるため，
通常，それらを製作するタスクも互いに依存関係にあるとし
ている．したがって，設計者は他のタスクとの整合性を保障
しながら自らのタスクを処理する必要があると指摘してい
る．さらに，このタスクの依存性は，タスクを処理する際に，
依存するもう一方のタスクの設計知識がどの程度必要かを，
二つのタスクの依存度合いとして定義している．
関連研究では，先ずタスクを実行することで設計知識の達
成レベルが増加し，ミーティングを行うことで設計知識の達
成レベルが減少するが，タスク間の不整合が減少することで
設計品質が向上するとモデル化している（Fig. 2）．したがっ
て，関連研究におけるミーティングは，開発プロジェクトに
次の作用をもたらすと理解できる．
Sub-Contents(Product)
Task and Viewpoint
(Processing)
Resource
Fig. 3 Overview of Content Development Process
Graphics
Sound
Game
y タスクに潜む不整合の洗い出しと削減
Program
y 設計知識の達成レベルの減少
Character
Scenario
Fig. 4 Composition of Contents
-507-
Background
Vehicle
タスクは，サブコンテンツを生成するために行われる仕
事・処理を意味し，リソースは，その仕事を処理する主体（主
に人間）を指す．これらの関係は Fig.5 が示すように，グラ
フィッカー（リソース）が絵を描くという処理（タスク）を
通じて背景画像（サブコンテンツ）の進捗を高めるといった
関係にある．ここで，サブコンテンツの全工数（Man-Hour）
を total_time と設定し，リソースの処理能力（Ability）を
ability[r_i]とした場合，サブコンテンツの進捗度（Progress）
が p_ratio[sc_j](%)の時に，このリソースが time[r_i]時間働く
と，Progress の増分：delta_p[sc_j]は（１）式によって求める
ことができると仮定する．
delta _ p [ sc _ j ] =
ability [ r _ i ]
× time [ r _ i ]
total _ time
（１）
3-2. サブコンテンツの開発ハザード
リソースが制作するサブコンテンツには複数の要素があ
り，あるレビューを実行したい場合に，一部の要素が必要に
なる場合がある．Fig. 6 は，あるデモムービーによってレビ
ューを実行する際に必要なキャラクターA，B，および C に
関連する要素と，それらの間にある依存関係を示している．
このサブコンテンツの要素間の依存関係は，それらを制作
する際に，互いの要素の情報を得る必要があることを意味す
る．この情報を交換する際に，正確に，かつ必要十分な情報
が得られることは保障されず，交換される情報の誤りや不整
合な情報が含まれる場合が多く，コンテンツ制作のリスクの
要因となる．本研究では，このリスクの要因となる情報の誤
りや不整合をサブコンテンツに内在する開発ハザードとし
て定義する．ここで，要素間の依存関係に存在する開発ハザ
ードを要素間開発ハザードと呼ぶ．
本研究では以上のように要素間と要素内の二種類の開発
ハザードを定義する．
3-3. レビューのモデル化
本研究では，関連研究のミーティングのモデル化に倣い，
レビューを行うことによって開発ハザードが解消される仕
組みをモデル化し，導入する．レビューはサブコンテンツの
Progress を減少させるが，同時に開発ハザードを下げ，コン
テンツの品質を保持するものとする．Fig. 7 は，背景画像と
いうサブコンテンツをレビューした際に，Progress および開
発ハザードが変化する様子を示す．
既に述べているように，ユーザと開発者ではレビューの観
点の違いから，成果物によってレビュー可能なポイントが大
きく異なる．本研究では成果物のレビュー可能なポイント
（関連性の強さ）を，サブコンテンツの各要素における
Review-Weight として定義する．
例えば，Fig. 8 に示すように，サブコンテンツ A，B から
構成されるサブコンテンツ AB をレビューする場合，A，B
の Review-Weight を図中のように設定した例を考える．例え
ば，R1 において AB の色合いをレビューした場合，A がよ
り強くレビューの影響を受ける．使用されたレビュー項目を
There are
some problems
Progress： －40%
Hazard： －50
Review Background
Progress： 100%
Hazard： 50
また，誤りや不整合な情報を含んだ経路から得られる情報
を基に要素を制作してしまうと，誤りや不整合な情報が要素
に混入してしまう場合が考えられる．本研究では，この開発
ハザードを要素内開発ハザードと呼ぶ．
There is
no problem
Review Background
Progress： 100%
Hazard： 0
Revise Contents
Progress： 60%
Hazard： 0
Go to Next Stage
Review until the hazard of element
that is target of review will be 0
Fig. 7 An Example of Progress and Hazard in Reviews
Progress：80%
Progress：30%
Ability：5
Draw
Picture
Background
Picture
2 Hours
Working
Progress：
30%→80%
Sub-Contents A
Review Item
Color
Shape
Move
Man-Hour：20
Review Weight
2
1
0
Fig. 5 Relationships between Tasks and Resources
B
Sound of
Action
A
R1
AB
Sub-Contents B
Review Item Review Weight
Color
1
Shape
3
Move
1
Fig. 8 Composition of Sub-Content A, B, and AB
Sound Creator
Sound of
Working
Sound of
Flying
Sound of
Running
Man-Hour-A
Hazard-A
Review-Weight-A
Polygon
3DCG
Creator
Character A
Character B
Character C
Character D
Task
Framework
Resource
Sub-ContentA
Hazard-AB
Review
Result（Review）
Ability
Animation
Creator
Human Type
Bird Type
Sub-ContentB
Dog Type
Fig. 9 Increase and Decrease of Progress and Hazard
Fig. 6 Dependencies between Elements
-508-
review_w[sc_j]レビューの結果を result[rv_i]としたとき，各サ
ブコンテンツの Progress 減少量：delta_p[sc_j]は（２）式で示
すように計算される．
delta _ p [ sc _ j ] = review _ w[ sc _ j ] × result [ rv _ i ]
B
（６）
4. レビューシミュレーションによる最適化
4-1. レビューのシミュレーション実行
前章のモデル化を踏まえ，本研究における開発プロセスの
シミュレーションのフローは，次に示す手順で実行される
（Fig. 10）
．
178
Task
1735
Cost
2205
Review
470
A
Execution of R3
C
Man-Hour：4
440
Execution of R2 and R3
Total Time
163
Task
1675
Cost
2115
Review
440
[Step_I] プロジェクトの目標を目的関数として設定する．
目的関数は，開発に要する合計時間と人的コスト
によって定義する．
[Step_II] 各ノード，依存関係を設定する．DSM を用いた
要素のパーティショニングを実行する．
[Optimizing Loop]
[Step_III] レビューの組合せを生成する．
Set up a project goal as
an objective function
III
IV
List finished
tasks and reviews
2070
Review
本研究におけるレビューのタイミング，回数，内容の最適
．
化は，次に示すフローで実行される（Fig. 12）
Check progress
of sub contents
Assign resources and
fit them into schedule
Task
2510
[Step_5] 処理が終了したタスク，レビューを列挙する．
[Step_6] リソースを解放する．
[Step_7] 各要素の完了状態をチェックする．未完了の要素
がある場合は，[Step_1] へ，そうでない場合は，
[Step_E]へ．
[Step_E] シミュレーション終了
If all sub contents are finished
Release resources
150
Cost
4-2. レビューの最適化手法
End simulation
List idling resources
R2
Total Time
Fig. 11 Reviews Dependent on Combination of Sub-Contents
I
If unfinished sub contents exist
R3
ABC
BC
[Step_S] シミュレーション開始
[Step_1] 製作可能な要素，およびレビューを列挙する．
[Step_2] アイドル状態のリソースを列挙する．
[Step_3] リソースを割り当て，スケジュールを追記する．
[Step_4] タスク，およびレビューの実行
[Step_4a] 各要素の進捗度を増減させる．
[Step_4b] リソースによる人的コストを計算する．
[Step_4c] 時間コストを計算する．
[Step_4d] 開発ハザードを計算する．
List producible
sub contents, reviews
465
シミュレーションがプロジェクトの合計時間，および人的
コストを計算できることを Fig. 11 の開発プロセスで確認し
た．この例では 3 つのサブコンテンツ A，B，C を組み合わ
せてサブコンテンツ ABC を作る際に，中間生成物である AB
および BC を想定し，それぞれをレビューした場合の合計時
間・人的コストの変化を比較計算した．結果として，プロジ
ェクトのコアとなる部分を，早い段階でレビューすることが
望ましいという結果が得られた．得られた結果は，現実のレ
ビューの計画に則した結果であると判断され，本研究におけ
るレビューのモデルが合計時間・人的コストを計算できる特
徴を持つことを示した．
（５）
Start simulation
2210
Review
Total Time
B
（３）
■レビューによる増減
delta _ p [ sc _ i ] = review _ w[ sc _ i , m ]
delta _ h [ sc _ i ] = review _ w[ sc _ i , m ] × t R
Task
2675
C
Man-Hour：6
（４）
×result [ rv _ l ] × t R
158
Cost
Execution of R1 and R3
Man-Hour：8
タスク，レビューの実行時間をそれぞれ tT，tR とし，サ
ブ コ ン テ ン ツ の Man-Hour を man_hr[sc_i] ， Hazard を
hazard[sc_i]，Review-Weight を review_w[sc_i, m]，リソースの
Ability を ability[re_k]，レビューの Result を result[rv_l]とする．
また，サブコンテンツ[sc_x]と[sc_y]の間の依存関係上にある
Hazard を hazard[sc_x, sc_y] と す る ． Progress の 増 量
delta_p[sc_i]および Hazard の増量 delta_h[sc_i]は，タスクによ
る増減の場合では（３），
（４）式，および，レビューによる
増減の場合では（５），（６）式に示すように計算される．
Total Time
R3
ABC
（２）
ここで，Fig. 9 に示した開発プロセスを用いて，Progress
と Hazard が増減する仕組みを整理する．
×hazard [ sc _ i , sc _ j ] × tT
Execution of R3
R1
AB
3-4. Progress と Hazard の増減
■タスクによる増減
ability [ re _ k ]
× tT
delta _ p [ sc _ i ] =
man _ hr [ sc _ i ]
delta _ h [ sc _ i ] = hazard [ sc _ i ] × hazard [ sc _ j ]
Man-Hour：2
A
II
Apply DSM partitioning
to sub contents
VIII
Generate combinations
of reviews*
Generate combinations
of review substances*
Evaluate III
combinations
VII
Improve
review plan
Evaluate IV
combinations
* Generated by GA
V
Execute develop
process simulation
VI
Execute of tasks and reviews
Update Progress
of each sub contents
Count up
resource costs
Count up
time costs
Output the optimal
review plan
(Timing, Substance)
Update Hazard
of each sub contents
Fig. 12 The Optimizing Loop
Fig. 10 The Flow of Review Simulation
-509-
Calculate the
object function
Project Plan A
Number of Tasks
Number of Reviews
Number of Resources
22
13
11
Project Plan B
Fig. 13 Two Types of Development Process Model for Computational Experiments
[Step_IV] レビュー内容（項目）の組合せを生成する．
※上記の組合せは，GA による遺伝子によって指定．
[Step_V] 開発プロセスの実行シミュレーション
[Step_VI] 目的関数を計算する．
[Step_VII] レビュー内容（項目）の組合せを評価する．
[Step_VIII] レビューの組合せを評価する．
[Optimizing Loop]
[Finish] 最適なレビュー案（レビューのタイミング，内
先ず，プロジェクトマネージャーがサブコンテンツ，タス
ク，リソース，およびレビューに関する必要情報を入力し，
プロジェクトの目標を目的関数として設定する．目的関数は，
開発に要する合計時間と人的コストによって定義する．つづ
いて，タスク構造に対して DSM（Design Structure Matrix[6]）
のパーティショニングを適用することでタスクの順序関係
を整理する．ここから，前節で述べたシミュレーションを繰
り返し実行することによって，合計時間および人的コストに
おいて最適なレビュー案（レビューのタイミング，内容）を
導出する．ここで，Fig. 12 のステップ III およびステップ IV
において，使用するレビューの組み合わせおよびレビュー項
Plan A
Plan B
Number of
Review Items
Total
614
844
523
519
594
776
5. プロトタイプシステムによる計算実験
本研究で提起した開発プロセスのモデルおよびレビュー
の最適化手法の有効性を検証するために，プロトタイプシス
テムを構築し，計算実験を実施した．
5-1. 設定した計算条件
容）を導出する．
Timings of
Reviews
目 の 組 み 合 わせ は ， 遺 伝 的ア ル ゴ リ ズ ム（ GA ： Genetic
Algorithm）を適用し生成している．
Fig. 14 Optimization of Total Working Time
計算実験に用いた CG ムービー制作における開発プロセス
の構造を Fig. 13 に示す．Plan_B は Plan_A と比較して，後工
程の処理が増える構造となっている．なお，このプロジェク
トは携帯電話，および携帯ゲーム機のプロジェクトとほぼ同
じ規模のタスク数を想定しており，11 名の開発スタッフ（リ
ソース）で，22 の開発タスクを処理する問題としている．
下記に示すように三つのケースに分けて実行し，提案する
最適化手法を検証した．また，最適化の目的関数として開発
に要する合計時間を最小と設定し，最適化プロセスにおける
収束状況を，Fig. 14 には開発に要する合計時間，Fig.15 には
開発に要する人的コストを示す．
Timings of
Reviews
Number of
Review Items
Total
Plan A
13,366
12,856
12,833
Plan B
13,581
13,344
12,823
Fig. 15 Optimization of Development Cost
-510-
Plan A
Plan B
Fig. 16 Calculated Optimal Reviews
た．これにより，コンテンツ開発の進捗状況において，レビ
ューを遅らせる程，レビューの容易性は上がるが，一方でコ
ンテンツ開発における手戻りリスク（Hazard）も大きくなる
ことが示された．すなわち，本研究によりレビューの容易性
と開発の手戻りリスクとのトレードオフを考慮したレビュ
ーのタイミング，回数，および内容を計画するための基本的
な仕組みの実現可能性を示すことができたと言える．
Case_1: レビュー内容を固定し，設計変数をレビューのタイ
ミングとして最適化を実行した． Review_A ， Review_B
に最適値の収束状況を示す．
Case_2: 実行するレビューを固定し，設計変数をレビュー内
容（項目）として最適化を実行した．RItem_A，RItem_B
に最適値の収束状況を示す．
しかしながら，今回は，サブコンテンツの組み合わせ方を
ベースとした最適なレビュー計画の立案に焦点を当ててお
り，コンテンツの設計および製作工程の計画フェーズからレ
ビューを考慮したプロジェクト計画までは対象としなかっ
た．さらに，実際のコンテンツ開発では，開発中にレビュー
計画を見直す動的な対応も必要とされる．今後は，プロジェ
クトの計画および開発において迅速にレビューのタイミン
グ，回数，および内容を算出可能な仕組み作りが期待される．
Case_3: レビューのタイミングとレビュー内容を設計変数と
して設定し，最適化を実行した．Total_A，Total_B に最
適値の収束状況を示す．
5-2. 計算結果の考察
Case_1 および Case_2 は，
共に解は収束したが，特に Case_1
のレビューについての最適化はプロジェクトの合計時間を
大きく低下させた．また，Plan_A から Plan_B に変えたこと
で，プロジェクトの合計時間は減少したが，同時に人的コス
トも増加した．これは，プロジェクトの後半に手戻りが多く
発生したことが原因と考えられる．
Case_3 によって得られた合計時間の最小値に関して，
Case_1 と Case_2 の実験結果と比較して良いものが得られた．
また，Plan_A と Plan_B で合計時間や人的コストの上では大
きな違いは見られなかったが，採択されたレビューは異なる
結果を得た．Fig. 16 に Case_3 における各 Plan で採択された
レビューのタイミング（位置）を青丸でマークする．マーク
されていないレビューは実施されていないことを意味する．
また，意匠的要素の多いとされるコンテンツの開発では，
設計者や製作者などの間における円滑なコラボレーション
を如何に実現できるかが重要な課題であると考えられ，同時
に，このコラボレーションにおけるレビュー作業では属人的
な要素が多いと考えられる．しかしながら，今回はリソース
のモデル化には焦点を当てなかったため，この属人的要素の
強いレビュー作業に関しては検討の余地があると言える．今
後は，例えば，リソース間の相性などを考慮した協調的レビ
ューモデルのような議論が期待される．
参考文献
ここで，Plan_B においてプロジェクトの前工程でレビュー
が必要になった理由は，後半で作業が多くなる分，前半の成
果物に含まれる Hazard を軽減する動きが影響したことが原
因であると考えられる．
6. 結論と今後の課題
本研究では，先ず，コンテンツ開発におけるレビューの最
適計画の重要性を提起した．これを踏まえ，開発対象のコン
テンツをモデル化し，さらに，このコンテンツモデルをベー
スとしたレビューのタイミング，回数，および内容の調整か
ら，プロジェクト全体のリードタイムおよび人的コストを算
出することが可能な開発プロセスのモデルを提案した．また，
簡易な CG ムービー製作の開発プロセスをモデル化しシミュ
レーションを実行することにより，プロジェクトに最適なレ
ビューのタイミング，回数，および内容を算出する例を示し
-511-
[1] 渥美航, 古賀毅, 青山和浩, “コンテンツ開発におけるプ
ロジェクトマネジメントのモデル化”, 第 17 回 日本機械
学会 設計工学・システム部門 部門講演会, 仙台, 2007.
[2] 財団法人デジタルコンテンツ協会, デジタルコンテンツ
白書, 2007.
[3] 織田巖, ソフトウェア・レビュー技術, ト・リサーチ・セ
ンター出版, 2006.
[4] 森口繁一, ソフトウェア品質管理ガイドブック, 日本規
格協会, 1990.
[5] Nomaguchi, Y. and Fujita, K., “Design Process Planning from
a Viewpoint of Progressive Nature of Knowledge
Acquisition,” Proceedings of 16th International Conference
on Engineering Design, No. 490, Paris, France, Aug, 2007
(CD-ROM).
[6] Design Structure Matrix, http://www.dsmweb.org/