プロジェクトマネジメント入門以前

プロジェクトマネジメント入門以前

プロジェクトマネジメント入門以前

2009/04/18

minamo

2009/04/18

minamo

タイトルは・・・

こちらから取りました！

何年も前に読んだ本ですが、良書です！

突然ですが！突然ですが！

デスマーチになったことがある人は挙手！

デスマーチになったことがある人は挙手！

マスターアップ後の常套句

• 「いやぁ、なんとかなったね」

• 「次回からはもっと余裕を持って（ｒｙ」

• 「今回は特別だったから」

マスターアップ後の常套句

• 「いやぁ、なんとかなったね」なんとかなってない。

• 「次回からはもっと余裕を持って（ｒｙ」また繰り返す悲劇。

• 「今回は特別だったから」プロジェクトは毎回特別。

出来上がった商品も・・・

• デスマーチをこなしたからといって、いい商品ができるわけじゃない

• やるべきことで、やり残したことがいっぱい

• ゲームをプレイしてても、「ここはこうするつもりだったんだろうな」と感じる部分も

このままじゃダメだ！！このままじゃダメだ！！

なんとかせねば！

なんとかせねば！

理想を言えば・・・

• 売れる／ユーザーに楽しんでもらえる

• プロジェクトに振り回されるのではなく、コントロールしたい

• スタッフが疲弊せずに、イキイキと制作にあたることが出来る

今は・・・

• せっかくの「スタッフの技術」と「努力」が、ちゃんと作品に反映されてない！！

技術＆努力

作品

本来なら・・・

• 本来なら、こうなるべき！！

技術＆努力

作品

いやいや

• 理想はこうだ！！

技術＆努力

作品

チームワー

ク

そもそも・・・

　プロジェクトがコントロールを失った状態というのは、

損失以外のなにものでもない！

こういうのを解決しようとする活動

プロジェクトの成功を目指す活動を、

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

というようだ。（とても広義な意味で）

ちゃんと考えてるＩＴ業界

ゲーム業界のお隣であるＩＴ業界は、

そのあたりのことを

ちゃんと考えているらしい。

いや、ちょっと訂正

ちゃんと考えている企業は

ちゃんと考えているらしい。

そして何より、体系立った方法論がある！

→もうあるんだったら、　ＩＴ業界を参考にするのが早そうだ！

ＩＴ業界を参考にする理由

類似点–プロジェクトベース– 仕様＋プログラム（＋素材）で成り立つ

そしてさらに・・・–ゲーム業界より歴史が長い（ゲーム：２５年？　ＩＴ：４０年？）

– 市場規模・就業人口が多い（ゲームソフト： 8500億円　ハード： 2兆円　　　↑国内＋海外出荷　２００８ＣＥＳＡゲーム白書より　ＩＴ業界： 12.3兆円）

– 体系立ったプロジェクトの進め方がある

今日の趣旨

何があるか知ろう！

今日の趣旨

何があるか知ろう！

本日のお品書き

• プロジェクトマネジメントとは？

• プロジェクトマネジメント手法

• ＰＭＢＯＫの全体像

• プロジェクトライフサイクルと開発手法

プロジェクトマネジメントとは？

プロジェクトマネジメントとは？

プロジェクトの定義

プロジェクトとは・・・• 有期的であること• 独自性があること

ゲーム関係でプロジェクトではない例としては・・・•ユーザーサポート•ネットゲームの運営

プロジェクトの成功とは

Ｑ：プロジェクトの成功とは？

制作側にフォーカスすると・・・• 品質（クオリティ）• 予算（コスト）• 納期（スケジュール）これらを満たすこと。

その他、プロジェクトごとに売り上げ以外の目標が設定されていることもある。

Ａ：売り上げ目標を上回ること

プロジェクトマネジメントとは

プロジェクトマネジメントといって思い浮かべるもの。

• スケジュール管理？• 外注管理？• 予算管理？

プロジェクトマネジメントとは「プロジェクトを成功に導く活動」

のこと。

プロジェクトマネジメントとは

現状との区別をハッキリさせると・・・

プロジェクトマネジメントとは「プロジェクトを成功に導く活動」

“ 各種知識やスキルを用いて”プロジェクトを成功に導く活動

どうやって成功に導くか？

どうやって成功に導くか？

プロジェクトマネジメント手法プロジェクトマネジメント手法

～ＱＣＤマネジメント～

昔から製造業全般で使われていたマネジメント手法。ＱＣＤはそれぞれ次の意味。•Ｑ： Quality（品質）•Ｃ： Cost（コスト）•Ｄ： Delivery（納期）

現在は“満たすべき基準”として語られることが多い印象。

～ＰＤＣＡサイクル～

製造業や建設業における管理サイクル・マネジメント。ＰＤＣＡはそれぞれ次の通り。

•Ｐｌａｎ（計画） •Ｄｏ（実行）•Ｃｈｅｃｋ（評価）•Ａｃｔ（改善）

Planから Actまで順番に行い、再び Planに戻る。こうして、継続的な改善をしていく。

Plan

DoCheck

Act

紹介　～ＣＭＭ（ＣＭＭＩ）～

CMM（ capability maturity model）→　能力成熟度モデル

企業や組織をある一定の基準で判定しレベル付けすることで、向上を目指す。主にソフトウェア開発を対象としている。

•レベル１ プロセスが確立されていない初期段階。•レベル２ プロジェクトを計画通りに組織的に実行できる。

ただし、特定のリーダーや技術者に依存している。•レベル３ 首尾一貫したプロセスを標準として持っている。•レベル４ 標準化されたプロセスを定量的に測定し、

洗練化していく状態。•レベル５ 技術・要件環境の違いによって、

標準プロセスを最適化して用いられる段階。

国内でレベル３以上は１０社前後。「ＣＭＭレベル＝開発力」ではないが、知っておいて損はない。

～ＰＭＢＯＫ～　注目！

PMBOK（ Project Management Body of Knowledge）→　プロジェクトマネジメント知識体系ガイド

• アメリカの非営利団体ＰＭＩ が定めた物• 現在のデファクトスタンダード• 適応範囲は製造業全般• ＰＭＢＯＫの資格であるＰＭＰは全世界で

約２５万人、日本で２万人が取得している

ＰＭＢＯＫにフォーカ

ス

ＰＭＢＯＫにフォーカ

ス

＜理由＞使えるのが多いから

＜理由＞使えるのが多いから

＜理由＞メジャーだから

＜理由＞メジャーだから

ＰＭＢＯＫの全体像ＰＭＢＯＫの全体像

ＰＭＢＯＫを導入する利点

ＰＭＢＯＫは、「計画と追跡の優れたツール」である。

• プロジェクトのコントロールができる“コントロールを取り戻せ！”

• マネジメントしないときと比べて、理想の着地点に近づける

• 改善のための“気づき”を与えてくれる

“ 現状把握”できれば怖くない

個人的な意見として……

• プロジェクトの現状を正しく“実感として”把握できれば、マネジメントの６～７割は完了している

のではないかと思う。それくらい現状を把握することは重要。でも、これが難しい。⇒ＰＭＢＯＫは”現状把握”を助けてくれる！

ＰＭＢＯＫの全体像

ＰＭＢＯＫは

• ９つの知識エリア（ジャンル）

• ５つのプロセス群（開発ライフサイクル）

によって定められている。

９つの知識エリア

ジャンルごとに９つに分けたもの。• 統合・マネジメント• スコープ・マネジメント• スケジュール・マネジメント• コスト・マネジメント• 品質・マネジメント• 組織・マネジメント• コミュニケーション・マネジメント• リスク・マネジメント• 調達・マネジメント（外注マネジメント）

５つのプロセス群

プロジェクト・ライフサイクルごとに５つに分けたもの。• 立ち上げフェーズ• 計画フェーズ• 実行フェーズ• 管理フェーズ• 終結フェーズ

今回は・・・

GamePM#2でやった「よりぬきＰＭＢＯＫ」から、さらによりぬいてみた

今回は・・・

前回は知識エリアでまとめましたが、今回はプロセス群でまとめました。

• ９つの知識エリア（ジャンル）

• ５つのプロセス群（開発ライフサイクル）

立ち上げフェーズ

プロセス群　その１

立ち上げフェーズの主なプロセス

• プロジェクト憲章作成（総合マネジメント）

• プロジェクトスコープ記述書暫定版作成（総合マネジメント）

計画フェーズ

プロセス群　その２

計画フェーズの主なプロセス

• ＷＢＳ作成（スコープ・マネジメント）• スケジュール作成（スケジュール・マネジメント

• コスト見積もり（コスト・マネジメント）• コストの予算化（コスト・マネジメント）

• 品質計画（品質・マネジメント）

• 人的資源計画（人的資源・マネジメント）

• コミュニケーション計画（コミュニケーション・マネジメント）

• リスク・マネジメント計画（リスク・マネジメント）

その他色々。計画フェーズが一番多い。

WBS作成

• プロジェクトの作業をすべて洗い出す⇒いわゆるタスクリストのようなもの

↓行う際に重要なこと• ＭＥＣＥ（漏れなくダブりなく）で洗い出す

• 段階的に割り出す• ＷＢＳ番号を振る

WBS作成　サンプル１

プロジェクト名

プロジェクト基盤 実装 素材作成 ・・・・・・

企画立案 仕様書作成

・・・・・・ ・・・・・・

タイトル画面 キャラ選択画面 ・・・・・・ ・・・・・・

WBS作成　サンプル２

WBS作成　ワーク パッケージ

• ＷＢＳの最下層のタスクを、ワーク パッケージという

• ワーク パッケージは細かくなりすぎないように（２～４週間程度）

• １つのワーク パッケージに付き、１人の担当者を振り分けられるレベルまで細分化する

コスト見積もり

• 各アクティビティ、各リスクを見積もる• 見積もり方法

– 類推見積もり（コレが多いか？）– ボトムアップ見積もり（アクティビティごとに見積もる）

– 係数見積もり（コンテンツビジネスでは使わない？）

• コンティンジェンシー予備は最低でも１割くらいほしい（日本では承認されないことが多いので、見積書上は他の項目に割り振っておくのが主流）

コストの予算化

• プロジェクトをコントロールするための、コスト・ベースラインを設定する

• 時系列で、どのタイミングでどれだけコストがかかるかまとめる

• 通常、Ｓ字カーブを描く

コス

ト

時間

ベースライン

コミュニケーション計画

• 情報配布の計画を立てる

• 具体的には次のことを決める– 誰に？– いつ？– どのような情報を？– どのような形式で？– 誰が？

• 不足が無く、かつ細かすぎないのがベスト

実行フェーズ

プロセス群　その３

実行フェーズの主なプロセス

• 情報配布（品質・マネジメント）

• プロジェクトチーム編成（人的資源・マネジメント

• プロジェクトチーム育成（人的資源・マネジメント）

• 納入者選定（調達・マネジメント）

etc……

管理フェーズ

プロセス群　その４

管理フェーズの主なプロセス

• 統合変更管理（統合・マネジメント）

• スコープ・コントロール（スコープ・マネジメント）• スケジュール・コントロール（スケジュール・マネジメント

• コスト・コントロール（コスト・マネジメント）• 品質管理（品質・マネジメント）

• プロジェクト・チーム・マネジメント（人的資源・マネジメント）

• ステークホルダー・マネジメント（コミュニケーション・マネジメント）

• リスク監視・コントロール（リスク・マネジメント）

etc……

統合変更管理

• プロジェクト途中で発生した変更を管理する

↓行う際に重要なこと• 変更要望を上げるときのルールを作る• 要求された変更を分析し、承認を行う• 変更ログを付けて情報を共有する

統合変更管理　サンプル

Excelで十分可能！

コストコントロール

• コストの予算化で作成したコスト・ベースラインと実際の経過を比較して、正しい対処をする

• 対処としては・・・– 追加予算の調達– コンティンジェンシー

予備の投入– スコープの縮小

時間

ベースライン

実コスト

成果物

コス

ト

アーンドバリュー法

時間

ベースライン

実コスト

成果物コス

ト

スケジュール差異

コスト差異

現在完了予定

超過予算予想

これがアーンドバリュー法

終結フェーズ

プロセス群　その５

終結フェーズの主なプロセス

• プロジェクト終結（統合・マネジメント）

• 契約終結（調達・マネジメント）

雰囲気をつかんで頂けましたか？

雰囲気をつかんで頂けましたか？

まとめるとＰＭＢＯＫは・・・

• 計画重視のマネジメント手法

計画 コントロール

まとめるとＰＭＢＯＫは・・・

• プロジェクトでコントロールすべき要素を全て網羅してある

• 当たり前のことを、しっかりと記した教科書的な内容

プロジェクトマネジメントの基礎

しかししかし

違った視点もある違った視点もある

ＰＭＢＯＫの紹介を聞いて・・・

• Ｑ．ＰＭＢＯＫの紹介を聞いて、違和感や疑問を感じませんでしたか？

Ａ．計画通りに行くことは少ない

Ａ．計画通りに行くことは少ない

プロジェクトライフサイクルと制作手法

プロジェクトライフサイクルと制作手法

プロジェクトライフサイクルとは

• プロジェクトの開始から終了までのフェーズの移り変わり

• ＰＭＢＯＫであれば、　　立ち上げフェーズ　　計画フェーズ　　実行フェーズ　　管理フェーズ　　終結フェーズ

プロジェクトライフサイクルとは

• プロジェクトライフサイクルには、いくつか種類が存在する

ＰＭにおける制作手法とは

• 明確な定義はないけど・・・

プロジェクトライフサイクル

＋フェーズごとのプロセス

（スキル）

ウォーターフォール開発

～ウォーターフォール開発～

一番単純な構造の開発手法。

基本計画

外部設計

内部設計

コーディング

テスト（デバッグ）

リリース仕様は変わらないという前提で進められる。

～ウォーターフォール開発～

• 利点– 承認プロセスが明確– 分業しやすい– 文書の管理がしやすい

• 欠点– 手戻り（仕様変更）が発生した際のコストが高い

–プロジェクト終盤にならないと動作しない– 大量に文書化する必要がある

～ウォーターフォール開発～

• 先ほどのＰＭＢＯＫと相性が非常によい

• 大規模開発に向いていると言われている

※ＩＴとゲームでは、“大規模開発”の規模が違う

　ＧＴＡ４：１００億円（ゲームの最大規模）

　携帯電話：８０億～１００億（このくらいらしい）　三菱東京ＵＦＪ銀行　システム統合ＰＪ：　　技術者６０００人・２５００億円

プロトタイピングプロトタイピング

～プロトタイピング～

実働するプロトタイプを早期に制作し、それに拡張を加え完成を目指す。（プロトタイプを破棄を前提に作ることもある）

プロトタイプＡ プロトタイプＢ マスター

追加＆改良

追加＆改良

設計（仕様策定）

実装

テスト

実装

テスト

実装

テスト

回数はプロジェクトによる

～プロトタイピング～

•利点– 早い段階から動いている物がある– 各段階で仕様変更のチャンスがある

•欠点– 作業者が「後から考えればいい」と、最初の仕様策定の手を抜く可能性がある

– プロトタイプ作成に時間をかけすぎることがある

一般的なゲーム制作に一番近い開発手法。

そして！そして！

これを話したかった！

これを話したかった！

アジャイル開発アジャイル開発

～アジャイル開発～

アジャイルソフトウェア開発とは、一つの開発手法を示すのではなく、次の特徴を持つ開発手法全般のことを示す。

• プロセスやツールよりも、個人と対話を優先する • 包括的なドキュメントよりも、動作するソフトウェアを優先する

• 契約の交渉よりも、顧客との協調を優先する • 計画に従うよりも、変化への対応を優先する

－アジャイルソフトウェア宣言より－

簡潔に言うと・・・

• 仕様変更を“抱擁する”柔軟な開発「計画通りのもの」ではなく、「本当に必要なもの」を作り出す

• 開発者がイキイキと開発できることを目指す

アジャイル開発の主な特性

• １週間～１ヶ月の短い期間で区切る（イテレーションなどと呼ぶ）

• フィードバックを重視する

• どうやって仕様の変更に耐えるかの工夫がある

• コミュニケーションにフォーカスした工夫がある

アジャイル開発の利点と欠点

• 利点– 仕様変更を前提としている– 制作者が作っていて楽しい– 常に最新の状態の動くソフトウェアがある

• 欠点– 承認プロセスがあいまい– 書類化しない部分が多い– 予算見積もりがしづらい⇒大規模開発に向かない

ほんの少しだけご

紹介

ほんの少しだけご

紹介

アジャイル開発：ＸＰアジャイル開発：ＸＰ

アジャイル開発：ＸＰ

XP（ eXtreme Programming ）エクストリームプログラミング。WindowsXPとは全く関係ない。

• アジャイル開発の代表的な開発手法• ４つの価値と１９のプラクティス• ペアプログラミングや短期リリース、テスト駆動開発などで有名

• ２００５年前後に流行した

プラクティス例　～スタンドアップミーティング～

• 毎日実施（プロジェクト規模により変化）

• 立ったままのミーティング

• １０分程度で終了

• 「前日のタスク」「本日のタスク」「問題点」の３点のみをひとりひとり報告する

• 解決すべき問題点は、ミーティング後に解決する

プラクティス例　～ペアプログラミング～

• ２人で１台のＰＣを使ってプログラム

• 「ドライバー」がコードを書き、「ナビゲーター」は後ろから見ている

• 「ナビゲーター」は気になる点を助言をする

• 一定時間ごとに役割を交代する

プラクティス例　～テスト駆動開発～

• ＩＴでは“テスト”と呼ばれる、プログラムを検査するプログラムを組むことが多い（ほとんど？）

• 通常“テストプログラム”はコーディングの後に行うが、ＸＰではコーディングの前に書く

• 例）四捨五入をする関数に対して、・「 9.49」を渡して「 9」が返ってくるか・「 9.5」を渡して「 10」が返ってくるかなどなど

ゲームに有効かはわからないケド

アジャイル開発：ＳＣＲＵＭアジャイル開発：ＳＣＲＵＭ

アジャイル開発：ＳＣＲＵＭ

スクラム／ＳＣＲＵＭ　ＸＰが技術的要素を多く含んでいるのに対して、チームとしての振る舞いを中心としている。

　「ＸＰは開発されているソフトウェアの質を増強し、　スクラムはプロジェクトの日々の運営を増強する」

（アジャイルソフトウェア開発スクラムより）

• ゲーム開発で一番事例が多い開発手法• ３０日のイテレーション（スプリント）で開発• ＰＤＣＡを毎日／スプリントごとに行うようなもの？• 欠点：日本の書籍が少ない

詳しくは今度！詳しくは今度！

ここまで紹介してきましたがここまで紹介してきましたが

一番考えなきゃいけないことが残ってます

一番考えなきゃいけないことが残ってます

ゲーム開発に適応するにはゲーム開発に適応するには

ＩＴとゲームの主な違い

• クオリティ（品質）の指標

• グラフィック／サウンドの扱い

• ビジネスモデル

クオリティ（品質）の指標

• ゲームにおける品質– おもしろさ– 遊びやすさ– 見た目の質– バグがないこと– 統一性

• ＩＴにおける品質– 顧客の求めるものを提供すること– 保守・拡張のしやすさ– バグがないこと– 統一性

グラフィック・サウンド

ゲームではグラフィックとサウンドの質が品質を大きく左右する。

特にグラフィックは開発要員の半分を占めるため、この違いは大きい。

ビジネスモデル

• ゲームのビジネスモデル– パッケージ売り–ダウンロード販売⇒お客様は一般ユーザー

• ＩＴのビジネスモデル– Ｗｅｂサービス– 組み込み系– 上流・下流工程に分かれた受託開発⇒お客様は企業のことが多い

で、どうするかで、どうするか

次回以降に一緒に考えていきましょう

次回以降に一緒に考えていきましょう

最後に最後に

導入に当たって

• こういうプラクティスは、一気に導入しようとすると失敗する

• ミニマムに導入して広げていくのがベター

• 今回のＰＭＢＯＫも、全部やろうとしないで、気になったひとつを試してみるといいかも

テーラリング

• テーラリング（仕立て直し）とは、自分の状況に合わせてカスタマイズすること

• 手法は型（テンプレート）なので、必ずテーラリングを行う必要がある！

参考書籍

• プロジェクトマネジメント標準 PMBOK入門　／　広兼修• Webプロジェクトマネジメント標準 PMBOKでワンランク上のWebディレクションを目指す　／　林千晶 , 高橋宏祐

• プロジェクトマネジメント リテラシ　／　アイテック情報技術教育研究部

• ベースラインで成功する プロジェクトマネジメント　／　深沢隆司

• 実践 ! プロジェクト管理入門 増補改訂版　／　深沢隆司• 実務で役立つプロジェクトマネジメント　／　カーティス・R・クック 中西 全二

• 実務で役立つWBS入門 　／　Gregory T. Haugan 伊藤 衡• アジャイルソフトウェア開発スクラム　／　ケン シュエイバー ・マイク ビードル 他

ご静聴ありがとうございました！

ご静聴ありがとうございました！