1. プロジェクトマネジメント 入門以前 2009/04/18 minamo プロジェクトマネジメント 入門以前

2. タイトルは・・・ こちらから取りました！ 何年も前に読んだ本ですが、良書です！

3. 突然ですが！

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

5. マスターアップ後の常套句 「いやぁ、なんとかなったね」 「次回からはもっと余裕を持って（ｒｙ」 「今回は特別だったから」

6. マスターアップ後の常套句 「いやぁ、なんとかなったね」 なんとかなってない。 「次回からはもっと余裕を持って（ｒｙ」 また繰り返す悲劇。 「今回は特別だったから」 プロジェクトは毎回特別。

7. 出来上がった商品も・・・ デスマーチをこなしたからといって、 いい商品ができるわけじゃない やるべきことで、 やり残したこと がいっぱい ゲームをプレイしてても、 「ここはこうするつもりだったんだろうな」 と感じる部分も

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

9. なんとかせねば！

10. 理想 を言えば・・・ 売れる ／ユーザーに 楽しんでもらえる プロジェクトに振り回されるのではなく、 コントロール したい スタッフが疲弊せずに、 イキイキと制作 にあたることが出来る

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

12. 本来なら・・・ 本来なら、 こうなるべき！！ 技術 ＆ 努力 作品

13. いやいや 理想は こうだ！！ 技術 ＆ 努力 作品 チームワーク

14. そもそも・・・ プロジェクトがコントロールを失った状態というのは、 損失 以外の なにものでもない！

15. こういうのを解決しようとする活動 プロジェクトの成功を目指す活動を、 プロジェクトマネジメント というようだ。 （とても広義な意味で）

16. ちゃんと考えてるＩＴ業界 ゲーム業界のお隣である ＩＴ業界 は、 そのあたりのことを ちゃんと考えているらしい。

17. いや、ちょっと訂正 ちゃんと考えている企業は ちゃんと考えているらしい。 そして何より、体系立った方法論がある！ -> もうあるんだったら、 ＩＴ業界を参考にするのが早そうだ！

18. ＩＴ業界を参考にする理由 類似点 プロジェクトベース 仕様＋プログラム（＋素材）で成り立つ そしてさらに・・・ ゲーム業界より歴史が長い （ゲーム：２５年？ ＩＴ：４０年？） 市場規模・就業人口が多い （ゲームソフト： 8500 億円 ハード： 2 兆円 ↑国内＋海外出荷 ２００８ＣＥＳＡゲーム白書より ＩＴ業界： 12.3 兆円） 体系立ったプロジェクトの進め方がある

19. 今日の趣旨 何があるか 知ろう！

20. 本日のお品書き プロジェクトマネジメントとは？ プロジェクトマネジメント手法 ＰＭＢＯＫの全体像 プロジェクトライフサイクルと開発手法

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

22. プロジェクトの定義 プロジェクトとは・・・ 有期的 であること 独自性 があること ゲーム関係でプロジェクトではない例としては・・・ ユーザーサポート ネットゲームの運営

23. プロジェクトの成功とは Ｑ：プロジェクトの 成功 とは？ 制作側にフォーカスすると・・・ 品質（クオリティ） 予算（コスト） 納期（スケジュール） これらを満たすこと。 その他、プロジェクトごとに売り上げ以外の目標が設定されていることもある。 Ａ： 売り上げ目標を上回ること

24. プロジェクトマネジメントとは プロジェクトマネジメントといって思い浮かべるもの。 スケジュール管理？ 外注管理？ 予算管理？ プロジェクトマネジメントとは 「プロジェクトを成功に導く活動」 のこと。

25. プロジェクトマネジメントとは 現状との区別をハッキリさせると・・・ プロジェクトマネジメントとは 「プロジェクトを成功に導く活動」 “ 各種知識やスキルを用いて” プロジェクトを成功に導く活動

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

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

28. ～ＱＣＤマネジメント～ 昔から製造業全般で使われていたマネジメント手法。ＱＣＤはそれぞれ次の意味。 Ｑ： Quality （品質） Ｃ： Cost （コスト） Ｄ： Delivery （納期） 現在は“満たすべき基準”として語られることが多い印象。

29. ～ＰＤＣＡサイクル～ 製造業や建設業における管理サイクル・マネジメント。 ＰＤＣＡはそれぞれ次の通り。 Ｐｌａｎ （ 計画 ） Ｄｏ（実行） Ｃｈｅｃｋ（評価） Ａｃｔ（改善） Plan から Act まで順番に行い、再び Plan に戻る。 こうして、継続的な改善をしていく。 Plan Do Check Act

30. 紹介 ～ＣＭＭ（ＣＭＭＩ）～ CMM （ capability maturity model ） -> 能力成熟度モデル 企業や組織をある一定の基準で判定し レベル付け することで、向上を目指す。主にソフトウェア開発を対象としている。 レベル１ プロセスが確立されていない初期段階。 レベル２ プロジェクトを計画通りに組織的に実行できる。 ただし、特定のリーダーや技術者に依存している。 レベル３ 首尾一貫したプロセスを標準として持っている。 レベル４ 標準化されたプロセスを定量的に測定し、 洗練化していく状態。 レベル５ 技術・要件環境の違いによって、 標準プロセスを最適化して用いられる段階。 国内でレベル３以上は１０社前後。「ＣＭＭレベル＝開発力」ではないが、知っておいて損はない。

31. ～ＰＭＢＯＫ～ 注目！ PMBOK （ Project Management Body of Knowledge ） -> プロジェクトマネジメント知識体系ガイド アメリカの非営利団体ＰＭＩ が定めた物 現在の デファクトスタンダード 適応範囲は製造業全般 ＰＭＢＯＫの資格であるＰＭＰは全世界で約２５万人、日本で２万人が取得している

32. ＰＭＢＯＫ にフォーカス

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

34. ＜理由＞ メジャーだから

35. ＰＭＢＯＫの全体像

36. ＰＭＢＯＫを導入する利点 ＰＭＢＯＫは、 「計画と追跡の優れたツール」 である。 プロジェクトのコントロールができる “コントロールを取り戻せ！” マネジメントしないときと比べて、 理想の着地点 に近づける 改善のための “気づき” を与えてくれる

37. “ 現状把握”できれば怖くない 個人的な意見として…… プロジェクトの現状を正しく“実感として”把握できれば、マネジメントの６～７割は完了している のではないかと思う。 それくらい現状を把握することは重要。 でも、これが難しい。 ⇒ ＰＭＢＯＫは”現状把握”を助けてくれる！

38. ＰＭＢＯＫの全体像 ＰＭＢＯＫは ９つの知識エリア（ジャンル） ５つのプロセス群（開発ライフサイクル） によって定められている。

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

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

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

42. 今回は・・・ 前回は知識エリアでまとめましたが、 今回はプロセス群でまとめました。 ９つの知識エリア（ジャンル） ５つのプロセス群（開発ライフサイクル）

43. 立ち上げフェーズ プロセス群 その１

44. 立ち上げフェーズの主なプロセス プロジェクト憲章作成 （総合マネジメント） プロジェクトスコープ記述書暫定版作成 （総合マネジメント）

45. 計画フェーズ プロセス群 その２

46. 計画フェーズの主なプロセス ＷＢＳ作成 （スコープ・マネジメント） スケジュール作成 （スケジュール・マネジメント コスト見積もり （コスト・マネジメント） コストの予算化 （コスト・マネジメント） 品質計画 （品質・マネジメント） 人的資源計画 （人的資源・マネジメント） コミュニケーション計画 （コミュニケーション・マネジメント） リスク・マネジメント計画 （リスク・マネジメント） その他色々。計画フェーズが一番多い。

47. WBS 作成 プロジェクトの 作業をすべて洗い出す ⇒いわゆるタスクリストのようなもの ↓ 行う際に重要なこと ＭＥＣＥ （漏れなくダブりなく）で洗い出す 段階的に割り出す ＷＢＳ番号を振る

48. WBS 作成 サンプル１ プロジェクト名 プロジェクト基盤 実装 素材作成 ・・・・・・ 企画立案 仕様書作成 ・・・・・・ ・・・・・・ タイトル画面 キャラ選択画面 ・・・・・・ ・・・・・・

49. WBS 作成 サンプル２

50. WBS 作成 ワークパッケージ ＷＢＳの最下層のタスクを、 ワークパッケージ という ワークパッケージは 細かくなりすぎない ように（２～４週間程度） １つのワークパッケージに付き、 １人の担当者 を振り分けられるレベルまで細分化する

51. コスト見積もり 各アクティビティ、各リスク を見積もる 見積もり方法 類推見積もり（コレが多いか？） ボトムアップ見積もり （アクティビティごとに見積もる） 係数見積もり （コンテンツビジネスでは使わない？） コンティンジェンシー予備 は最低でも１割くらいほしい（日本では承認されないことが多いので、見積書上は他の項目に割り振っておくのが主流）

52. コストの予算化 プロジェクトをコントロールするための、 コスト・ベースライン を設定する 時系列で、どのタイミングでどれだけコストがかかるかまとめる 通常、 Ｓ字カーブ を描く コスト 時間 ベースライン

53. コミュニケーション計画 情報配布の計画を立てる 具体的には次のことを決める 誰に？ いつ？ どのような情報を？ どのような形式で？ 誰が？ 不足が無く 、かつ 細かすぎない のがベスト

54. 実行フェーズ プロセス群 その３

55. 実行フェーズの主なプロセス 情報配布 （品質・マネジメント） プロジェクトチーム編成 （人的資源・マネジメント プロジェクトチーム育成 （人的資源・マネジメント） 納入者選定 （調達・マネジメント） etc……

56. 管理フェーズ プロセス群 その４

57. 管理フェーズの主なプロセス 統合変更管理 （統合・マネジメント） スコープ・コントロール （スコープ・マネジメント） スケジュール・コントロール （スケジュール・マネジメント コスト・コントロール （コスト・マネジメント） 品質管理 （品質・マネジメント） プロジェクト・チーム・マネジメント （人的資源・マネジメント） ステークホルダー・マネジメント （コミュニケーション・マネジメント） リスク監視・コントロール （リスク・マネジメント） etc……

58. 統合変更管理 プロジェクト途中で発生した 変更を管理 する ↓ 行う際に重要なこと 変更要望を上げるときの ルールを作る 要求された変更を分析し、 承認 を行う 変更ログを付けて情報を 共有 する

59. 統合変更管理 サンプル Excel で十分可能！

60. コストコントロール コストの予算化で作成したコスト・ベースラインと実際の経過を 比較して 、正しい対処をする 対処としては・・・ 追加予算の調達 コンティンジェンシー予備の投入 スコープの縮小 時間 ベースライン 実コスト 成果物 コスト

61. アーンドバリュー法 時間 ベースライン 実コスト 成果物 コスト スケジュール差異 コスト差異 現在 完了予定 超過予算予想 これが アーンドバリュー法

62. 終結フェーズ プロセス群 その５

63. 終結フェーズの主なプロセス プロジェクト終結 （統合・マネジメント） 契約終結 （調達・マネジメント）

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

65. まとめるとＰＭＢＯＫは・・・ 計画重視 のマネジメント手法 計画 コントロール

66. まとめるとＰＭＢＯＫは・・・ プロジェクトでコントロールすべき 要素を全て網羅 してある 当たり前のこと を、しっかりと記した教科書的な内容 プロジェクトマネジメントの基礎

67. しかし

68. 違った 視点 もある

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

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

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

72. プロジェクトライフサイクルとは プロジェクトの開始から終了までの フェーズの移り変わり ＰＭＢＯＫであれば、 立ち上げフェーズ 計画フェーズ 実行フェーズ 管理フェーズ 終結フェーズ

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

74. ＰＭにおける 制作手法 とは 明確な定義はないけど・・・ プロジェクトライフサイクル ＋ フェーズごとのプロセス （スキル）

75. ウォーターフォール開発

76. ～ウォーターフォール開発～ 一番単純な構造の開発手法。 基本計画 外部設計 内部設計 コーディング テスト（デバッグ） リリース 仕様は変わらない という 前提で進められる。

77. ～ウォーターフォール開発～ 次のように考えられることから、 別名 「Ｖ字モデル」 とも言われている。 基本計画 外部設計 内部設計 コーディング 単体テスト 受け入れテスト 結合テスト

78. ～ウォーターフォール開発～ 利点 承認プロセスが明確 分業しやすい 文書の管理がしやすい 欠点 手戻り（仕様変更）が発生した際のコストが高い プロジェクト終盤にならないと動作しない 大量に文書化する必要がある

79. ～ウォーターフォール開発～ 先ほどのＰＭＢＯＫと相性が非常によい 大規模開発 に向いていると言われている ※ ＩＴとゲームでは、“大規模開発”の規模が違う ＧＴＡ４：１００億円（ゲームの最大規模） 携帯電話：８０億～１００億（このくらいらしい） 三菱東京ＵＦＪ銀行 システム統合ＰＪ： 技術者６０００人・２５００億円

80. プロトタイピング

81. ～プロトタイピング～ 実働する プロトタイプ を早期に制作し、それに拡張を加え完成を目指す。 （プロトタイプを破棄を前提に作ることもある） プロトタイプＡ プロトタイプＢ マスター 追加 ＆ 改良 追加 ＆ 改良 設計（仕様策定） 実装 テスト 実装 テスト 実装 テスト 回数はプロジェクトによる

82. ～プロトタイピング～ 利点 早い段階から動いている物がある 各段階で仕様変更のチャンスがある 欠点 作業者が「後から考えればいい」と、最初の仕様策定の手を抜く可能性がある プロトタイプ作成に時間をかけすぎることがある 一般的な ゲーム制作 に一番近い開発手法。

83. そして！

84. これを話したかった！

85. アジャイル開発

86. ～アジャイル開発～ アジャイルソフトウェア開発 とは、 一つの開発手法を示すのではなく、 次の特徴を持つ開発手法全般のことを示す。 プロセスやツールよりも、 個人と対話 を優先する 包括的なドキュメントよりも、 動作するソフトウェア を優先する 契約の交渉よりも、 顧客との協調 を優先する 計画に従うよりも、 変化への対応 を優先する －アジャイルソフトウェア宣言より－

87. 簡潔に言うと・・・ 仕様変更を“抱擁する”柔軟な開発 「計画通りのもの」ではなく、 「本当に必要なもの」を作り出す 開発者がイキイキと開発できることを目指す

88. よくある誤解 × 行き当たりばったり。計画しない。 × 自分勝手にやる。

89. アジャイル開発の主な特性 １週間～１ヶ月の短い期間で区切る （イテレーションなどと呼ぶ） フィードバックを重視する どうやって仕様の変更に耐えるかの工夫がある コミュニケーションにフォーカスした工夫がある

90. アジャイル開発の利点と欠点 利点 仕様変更を前提としている 制作者が作っていて楽しい 常に最新の状態の動くソフトウェアがある 欠点 承認プロセスがあいまい 書類化しない部分が多い 予算見積もりがしづらい ⇒ 大規模開発に向かない

91. ほんの少しだけご紹介

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

93. アジャイル開発：ＸＰ XP （ eXtreme Programming ） エクストリームプログラミング 。 WindowsXP とは全く関係ない。 アジャイル開発の代表的な開発手法 ４つの価値と１９のプラクティス ペアプログラミングや短期リリース、テスト駆動開発などで有名 ２００５年前後に流行した

94. プラクティス例 ～スタンドアップミーティング～ 毎日実施 （プロジェクト規模により変化） 立ったまま のミーティング １０分程度で終了 「前日のタスク」「本日のタスク」「問題点」の ３点のみをひとりひとり報告する 解決すべき問題点は、ミーティング後に解決する

95. プラクティス例 ～ペアプログラミング～ ２人で１台 のＰＣを使ってプログラム 「ドライバー」がコードを書き、 「ナビゲーター」は後ろから見ている 「ナビゲーター」は気になる点を助言をする 一定時間ごとに役割を交代する

96. プラクティス例 ～テスト駆動開発～ ＩＴでは “テスト” と呼ばれる、プログラムを 検査するプログラム を組むことが多い（ほとんど？） 通常“テストプログラム”はコーディングの後に行うが、ＸＰでは コーディングの前 に書く 例） 四捨五入をする関数に対して、 ・「 9.49 」を渡して「 9 」が返ってくるか ・「 9.5 」を渡して「 10 」が返ってくるか などなど ゲームに有効かはわからないケド

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

98. アジャイル開発：ＳＣＲＵＭ スクラム／ＳＣＲＵＭ ＸＰが技術的要素を多く含んでいるのに対して、チームとしての振る舞いを中心としている。 「ＸＰは開発されているソフトウェアの質を増強し、 スクラムはプロジェクトの日々の運営を増強する」 （アジャイルソフトウェア開発スクラムより） ゲーム開発 で一番事例が多い開発手法 ３０日のイテレーション（スプリント）で開発 ＰＤＣＡを毎日／スプリントごとに行うようなもの？ 欠点：日本の書籍が少ない

99. 詳しくは今度！

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

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

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

103. ＩＴとゲームの主な違い クオリティ （品質）の指標 グラフィック ／ サウンド の扱い ビジネスモデル

104. クオリティ（品質）の指標 ゲームにおける品質 おもしろさ 遊びやすさ 見た目の質 バグがないこと 統一性 ＩＴにおける品質 顧客の求めるものを提供すること 保守・拡張のしやすさ バグがないこと 統一性

105. グラフィック・サウンド ゲームでは グラフィック と サウンド の質が品質を大きく左右する。 特にグラフィックは開発要員の半分を占めるため、この違いは大きい。

106. ビジネスモデル ゲームのビジネスモデル パッケージ売り ダウンロード販売 ⇒ お客様は一般ユーザー ＩＴのビジネスモデル Ｗｅｂサービス 組み込み系 上流・下流工程に分かれた受託開発 ⇒ お客様は企業のことが多い

107. で、どうするか

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

109. 最後に

110. 導入に当たって こういうプラクティスは、一気に導入しようとすると失敗する ミニマムに導入 して広げていくのがベター 今回のＰＭＢＯＫも、全部やろうとしないで、気になった ひとつを 試してみるといいかも

111. テーラリング テーラリング （仕立て直し）とは、自分の状況に合わせてカスタマイズすること 手法は型（テンプレート）なので、 必ずテーラリングを行う 必要がある！

112. 参考書籍 プロジェクトマネジメント標準 PMBOK 入門 ／ 広兼修 Web プロジェクトマネジメント標準 PMBOK でワンランク上の Web ディレクションを目指す ／ 林千晶 , 高橋宏祐 プロジェクトマネジメント リテラシ ／ アイテック情報技術教育研究部 ベースラインで成功する プロジェクトマネジメント ／ 深沢隆司 実践 ! プロジェクト管理入門 増補改訂版 ／ 深沢隆司 実務で役立つプロジェクトマネジメント ／ カーティス・ R ・クック 中西 全二 実務で役立つ WBS 入門 ／ Gregory T. Haugan 伊藤 衡 アジャイルソフトウェア開発スクラム ／ ケン シュエイバー ・マイク ビードル 他

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