プロジェクトマネジメント講座...

2014年 2月 21日開催

千葉工業大学文化会

ソフトメディア研究会

担当：中川勇人

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

（基礎編）

【2014 プロジェクトマネジメント講座（基礎編）】

プロジェクトマネジメント講座（基礎編）

0．はじめに ....................................................................................................... 4

1.プロジェクトとは ............................................................................................ 5

1.1そもそもプロジェクトとは何か？ ............................................................. 5

1.2 時間の管理 .............................................................................................. 5

1.3 目的の明確化 .......................................................................................... 6

2. プロジェクトをマネジメントする ............................................................... 7

2.1 プロジェクトの流れ ............................................................................... 7

2.2 PMとは計画を立てること？ .................................................................. 8

1．立ち上げ ................................................................................................. 8

2．計画 ........................................................................................................ 8

3．実行 ........................................................................................................ 9

問：どう対処するか？ ............................................................................... 10

2.3 プロジェクトの基幹部 .......................................................................... 11

2.4 結局プロジェクトマネジメントとは？ ................................................. 12

3 事前対策と事後対策とは？ ......................................................................... 13

3.0火事の例（防火と消化） ......................................................................... 13

3.1 事前対策 ............................................................................................... 13

3.2 事後対策とは ........................................................................................ 15

3.3 まとめ ................................................................................................... 16

1．立ち上げ ..................................................................................................... 17

1.1「立ち上げ」では何をするのか？............................................................ 17

1.2プロジェクトの目的を決める。 .............................................................. 17

1.3企画書の作成 ........................................................................................... 17

1.4 メンバーを集める。 ............................................................................. 18

2．計画をする。 .............................................................................................. 19

2.0 計画をすること..................................................................................... 19

2.1 プロジェクト計画書の作成 ................................................................... 19

2.2 プロジェクトの範囲 ............................................................................. 21

2.3 スケジュール計画 ................................................................................. 22

2.4 リスク計画 ............................................................................................ 24

2.5 品質計画 ............................................................................................... 28

2.6 コミュニケーション計画 ...................................................................... 28

2.8 仕様書の作成 ........................................................................................ 29

2.8計画を終えて ........................................................................................... 30

2.9 まとめ ................................................................................................... 30

3．実行する ..................................................................................................... 31

3.1 実行段階ですること ............................................................................. 31

ア）スプリント計画 ...................................................................................... 31

イ）日々の製作 ............................................................................................. 32

ウ）週の振り返り ......................................................................................... 34

エ）スプリントの振り返り ........................................................................... 35

オ）対策・再計画 ......................................................................................... 36

3.2 まとめ ................................................................................................... 36

4．チームマネジメント ................................................................................... 37

4.1 チームで動く前に ................................................................................. 37

4.2 リーダーシップ理論 ............................................................................. 37

4.3 チームの変遷とリーダーの役割............................................................ 38

4.5 教え方 ................................................................................................... 40

4.6 質問の仕方 ............................................................................................ 40

4.7 孫子の兵法 ............................................................................................ 41

4.8 心構え ................................................................................................... 41

5．ゲーム制作の心得 ....................................................................................... 41

0．はじめに

・凄いゲームシステムを思いついたけど絵が描けない、曲も作れない…

・面白いストーリーができた！後は絵と曲とプログラムがあれば！

・プログラムも絵も曲もできないけど、面白いアイディアはあるんだよな…

→せっかく良いアイディアがあるのに、それを表に出さないのはもったいない

・自分に足りないスキルがあるのならば

A勉強する。

B他の人と一緒に作る。○

我がソフトメディア研究会は

・プログラム、マルチ、ＤＴＭと 3班に分かれている

・いずれもその道のプロ。

利用しない手はない！

しかし、

・どうチームで活動すれば良いかわからない

・チームができたけど、みんなバラバラ

・結局、発表できなかった…

今回の講座は

・計画の立て方

・プロジェクト管理

・チームでプロジェクトを動かすこと

についてやります。

別にチームで動くつもりはない！と言う方も、対応していますのでご安心を。

1.プロジェクトとは

1.1そもそもプロジェクトとは何か？

よく「我が社のプロジェクトが」とか言うけど、プロジェクト全部が大きい

ものではない。

→ソフメのゲームプロジェクトなど

プロジェクトとは

→「ある目的を達成するために、一定期間（チームを組み）活動すること」

（独自性）（有期性）

例：文化祭に発表するＲＰＧ制作。（文化祭）（ＲＰＧ）

期間（時間）と目的がプロジェクトの心臓部

つまり

・時間の管理

・目的の明確化

がプロジェクトで重要になる。→それがＰＭ？→間違いではない

1.2 時間の管理

・締め切りを過ぎたら死ぬ

・学生症候群によってモチベーションが下がる。

→しっかりと日程計画を立てる必要がある

手法などについては後程詳しく

1.3 目的の明確化

目的はプロジェクトの方針になるので最重要となる。

→何のためのプロジェクトなのか？

・目的がぶれるとプロジェクトそのものがぶれる。

・最終到達地点が分からない

目的＝プロジェクトの定義

→目的は漠然としていてはいけない

例：目的「ゲームを作る」→漠然としている

→何のゲームを作るのか？

RPG？STG？ADV？

別に「ゲームを作る」でも良い

しかし

→何を作るか決めていないので創造と破壊を繰り返してしまう

→「メンバーを集める」時に漠然とした目的だとメンバーと共有できない。

例：「ゲームを作る」メンバーに入った。

リーダーの方針は「RPG」

でも俺は「ADV」が作りたい。

→チームがばらばらに

目的の明確化は重要

→チームならば目的の共有化が重要

プロジェクトの成功＝目的の達成＝プロジェクト成功基準？

・ゲームの完成

・お客さんに喜んでもらう

・モチベーションを保つ

→燃え尽きる×

次につなげる○

2. プロジェクトをマネジメントする

プロジェクトをマネジメントするとは、

→プロジェクトを成功させるために活動すること。

プロジェクトの成功＝プロジェクトを実施する目的の達成

目的＝ゲームの完成・発表

先ほどの

・目的の明確化←前提条件

・時間の管理←こちらがプロジェクトマネジメントとして重要

2.1 プロジェクトの流れ

「プロジェクトの一連の流れ」

・プロジェクトを立ち上げる

：目的の決定・チーム結成・企画立案・方針決定

・計画をする

：制作計画・日程計画・とにかく計画

・実行する

：実際に作る・プログラミン・作曲・絵を描く

・終わり（完成）

：完成！発表！

これが一連の流れになる。

・時間の管理―――計画、実行

・目的の明確化―――立ち上げ

のところでやる

2.2 PMとは計画を立てること？

プロジェクトマネジメント＝計画を立てること？

→間違いではない

が、それだけでは足りない。

→何が足りないのか？

ではとりあえず計画を立ててプロジェクトを運用しよう！

例：

1．立ち上げ

プロジェクト名：

「ソフメクエスト（仮）」

締切（期間）：

3月 1日～5月 1日（5月 2日発表）

ジャンル：

３D RPG

2．計画

・システムは「FF」みたいなのにしよう！

・じゃあキャラグラも「FF」みたいな 3Dで！

・主人公は龍の血を引く一族で―能力が―

・カラス娘いいよね！いいよね！

・ガバ

アマチュアの特徴

―システムを凝ろうとする

―シナリオを盛り上げすぎる

―演出や外観の質を高めようとする

別に良いことだが

・目標が大きすぎる。

・規模が大きくなる。

・要求される技術力が高くなる。

という問題がある。

しかし、

・チームを組む

・しっかり計画を立てる

で補える

→ちゃんとできたらの話し。

あと、

・ゲームのことしか計画しない←アマチュアにありがち

ここら辺の話はのちほど詳しく

3．実行

・やっぱり RPGじゃなくてパズルゲームね

・キャラ設定を深くしたら、もっとステージが必要だ！

・ごっめーん！あと 12体敵キャラ描いて－！

・あれ？バグが…バグがあぁぁぁ！

・３Dって言われても…棒人間しかできないよ！

・ガバ

・進捗どうですか？→ダメです！

計画から必ず誤差が出る

問：どう対処するか？

対処 1．仕様を削減→○

対処 2．人員を追加投入

対処 3．期間を延ばす

対処 4．品質を妥協する→○

対処 5．残業しようぜ→最強の効果

これで完成できる！めでたしめでたし

→んなわけない・・・見事なデスマーチの完成

※デスマーチとは

一般的に、過酷なプロジェクト環境下であり、尚且つ、失敗に終わる可能性の

高いプロジェクトをデスマーチという。

帰さない寝かさないは当たり前、社の歯車として歯が折れたがが外れ、文字通

りバターンするまで昼も夜もない「精神と時の部屋」でこの行軍に付き合わさ

れるのだ。

デスマーチという言葉は、決して嘘でも誇張でもなく、本当に過労死が身近で

あったり、自殺を考えたりする。

現在のソフトウェア開発環境においても、自殺者や過労死、発狂による退社処

分は多い。

（ニコニコ大百科より引用）

プロジェクト立ち上げ時には希望に満ち溢れていた。

計画する時もあんなにワクワクしていた。

しかし、プロジェクトが始まるとどんどん問題が出てきて

最後には妥協しなくてはいけなくなり

妥協すると悲しくなるしやる気も下がる。

プロジェクト終了後には身も心もボロボロ

なによりも締め切りに追われるせいで精神的にやばい

どんなに綿密に計画を練っても、プロジェクトは計画通りにいかない

→プロジェクトの正確な予想なんてでき来ない

じゃあ、どうすれば良いのだ！？

→予想はできなくても制御はできる

2.3 プロジェクトの基幹部

「目的の明確化」と「時間の管理」がプロジェクトの心臓だと言いました。

で「目的の明確化」が定義的なもので

「時間の管理」がプロジェクトマネジメントだと言いましたが、

「時間」以外にもプロジェクトの基幹部がある。

ゲーム自体の完成度（クオリティ）→「品質」

実際に制作する人・機材→「資源」

「時間」「品質」「資源」・・・プロジェクトの基幹部

→これらをバランスよく制御できればプロジェクトは限りなく成功に近い

→プロジェクトマネジメントの本質

対処法でも述べたのですが

・「時間」が一番の決定要因→限りがある

・「品質」は妥協でき「資源」は追加投入できる

プロジェクトの天秤：

入力：（時間×資源）×生産効率

出力：価値（品質×範囲）

生産効率：

・チームの能力（チームワーク）

・チームの士気

・mayaなどの設備環境

・開発手法（プロジェクトマネジメントなど）

入力→生産効率＝出力

変換

この天秤のバランスを適正にできれば最高！

→リーダーの腕の見せ所

プロジェクトの天秤

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

「時間」「品質」「資源」という内臓を備えた生物→変化していく

＝プロジェクトは生物＝正確な予想はできない

しかし「時間」「品質」「資源」という基幹部に目を配れば制御できる。

その制御方法が「用意周到な事前対処」と「積極的な事後対処」

プロジェクトを運用するに当たって

○「プロジェクトとは不確実なものである」という事実を受け入れる。

○「用意周到な事前対処」と「積極的な事後対処」を実践する

これが重要＝プロジェクトマネジメント

3 事前対策と事後対策とは？

3.0火事の例（防火と消化）

ひたすら防火活動（事前対策）ばかりしていても、出火（時間配分のミスや計

画不足）そのものをゼロにすることはできず、消火活動（事後対策）をきちん

とできなければ大炎上してしまいます。

かといって防火活動をせず、消火活動だけに頼ろうとすると、出火量が多すぎ

てとても消化しきれず、やはり大炎上してしまいます。

火元がたくさんあると追いつかないです。

結局は防火活動と消火活動の両方の質の高さが要求されます。

どちらか一方が高品質でもダメで、どちらかの手を抜くと大炎上まっしぐら

どちらも大切なのです。

3.1 事前対策

・事前対策（調査・戦略・設計・計画）

－不確実性を減らす

・見通しが悪い部分の調査をしっかり行う

・計画規模を小さくする

・設計を詳細に行う

・リスクの高い要素を極力減らす

－不確実でも良いことにする

・リスクの高い要素をなくしても成立する設計にする。

→要は計画をすること

・何がどのくらい必要なのか？

・どれくらいかかりそうか？

→プロジェクトの規模（全体図）の把握

＝問題が起きそうな箇所の把握

対策とは？

・あらかじめクオリティを下げておく

・時間を多く見積もっておく

・人を多く集める

→事前対策

案外ここも問題なのです。

「アマチュアはゲームのことしか計画しない」と言いました。

・実際に作るゲーム本体の計画（仕様書）

だけでなく

・プロジェクト自体の計画

が必要なのです

→仕様書になっている可能性が多い。

大まかなスケジューリングと役割分担はできているがそれ以外のことが計画さ

れていない。

プロジェクトは「時間」「品質」「資源」の管理が重要

それらの要素を管理する計画が必要(重要)

―日程計画

―役割分担（人員計画）

―コミュニケーション計画

―進捗管理計画

―品質管理計画

→何のためにするのか？

○事前対策（事前計画）の意義は「防火」－問題を極力減らすこと。

○プロジェクトの全体図を見通せるようにする―「地図」

事後対策につなげるため

3.2 事後対策とは

・事後対策（イテレーション）

－変化や問題発生に素早く気付く

－変化や問題に素早く対応する

実行段階での対応。

ある意味、こちらがプロジェクトマネジメントの本質と言える。

事前対策（計画）が重要なのはみんな漠然と知っています。

→事後対策がおろそかになる。

―PDCAサイクル―

Plan（計画）

Do（実行）

Check（評価）

Action（反省）

※Actionは除外して PDCでも良い

反省計画・反省策実行・反省策評価みたいな感じで

このサイクルを実行段階で繰り返す。

→すぐに問題が発見できて解決できる。

ありがちなプロジェクト：

計画・実行・実行・実行・実行・計画・実行

問題が無視できないほどに大きくなって仕方なく計画を途中で見直している。

リスクが増えてって途中でやばいとなって追加投入

駄目なプロジェクト：

一回計画を立てて後は作り続けるのみ。リスクは増大する一方。

ダメダメなのは：

計画しないでやみくもにつくる。

おしいプロジェクト

ＰＤＣＡＰＤＣＡＰＤＣＡ

のサイクルが長い。＝機動力が弱い

良いプロジェクト：

ＰＤＣＡの間隔が短い

ミサイルの例：

悪い：発車→10秒に 1回制御する→風（外的要因）→ハズレ

良い：60ＦＰＳで制御なら文字道理軌道修正しやすいので当たる。

PDCAの手法については後程。

簡単に言うと

・問題が起こった時の対策と報告

・メンバー間での情報の共有

・反省会

とか

3.3 まとめ

●つべこべ言わずに設計しろ、計画しろ

●行き当たりばったりで物が作れるわけない、後からどうにかなるわけない

・プロジェクトは予想できない大きな不確実性が潜んでいる。

・不確実性とうまく付き合わなければならない

・事後対策を重視しよう

－こまめな PDCAサイクルで不確実性から生まれる問題の

早期発見と早期解決を繰り返そう

・事前対策（調査・戦略・設計・計画）から逃れられない

―不確実性を下げ、見通しをよくするための地図を準備しよう

－それらはなるべく書式化しよう

→ただ、個人製作やアマチュアの場合

計画がしっかりしていれば、PDCAはそこまで必要ではない

1．立ち上げ

プロジェクトマネジメントの手順

1．立ち上げをする。

2．計画する。

3．実行する。

1.1「立ち上げ」では何をするのか？

・プロジェクトの目的を決める

・企画書の作成

・メンバーを集める

1.2プロジェクトの目的を決める。

目的の明確化のところで言った通り

「目的が漠然としているとプロジェクトがぶれる」

「チームがまとまらない」

1.3企画書の作成

～書くこと～

・タイトル

・ジャンル

・ターゲットプレイヤー

・プレイ時間

・コンセプト

・開発環境

・必要人員

・開発期間

・あらすじ

・システム

・書式の作成者名

・書式のバージョン・履歴

○企画書を書くときの注意

・シンプルに

・客観的に

・実現性があること

・分かりやすく

・書きすぎない←企画書の段階では詳細に書かない

○ダメな企画書

・覚書風

・シナリオ風

・仕様書風

・「〇〇みたいなシステム」

○企画書を作成する意義

・チームで動く→情報の共有化

・アイディアの整理

・記録を残す

・プロジェクトの見直し

→書類全般を書く意義

1.4 メンバーを集める。

・どういうプロジェクトか？

・何をしてほしいのか？

→受注と委託の関係でも良いが、最低限に意思の疎通ができるようにしよう。

「計画」の段階で具体的に説明します。

2．計画をする。

2．計画する。

3．実行する。

2.0 計画をすること

・プロジェクト計画書の作成

・プロジェクトの範囲

・スケジュール計画

・リスク計画

・品質計画

・コミュニケーション計画

・仕様書の作成

2.1 プロジェクト計画書の作成

プロジェクト運用のルールを決めた書類

事前対策の分類で事後対策につながる重要な計画。

―何を優先するのか

―だれが、なにを、なぜ、いつまでに、いくら

・プロジェクトの名前

・プロジェクトのメンバー

・プロジェクトの目的

・プロジェクトの背景・・・なぜプロジェクトを立ち上げたのか

・プロジェクトの期間

・成果物の定義・・・・・・最終的にどういうものが出来上がるのか

・プロジェクトの範囲・・・どんな作業をしなければならないのか

・開発環境

・マイルストーン・・・・・中間発表などの日程

・責任と権限

・役割分担

・スケジュール計画・・日程や進捗はどう管理するのか？

・リスク計画・・・・・問題があったらどう対処するのか？

・変更計画・・・・・・計画に変更があったらどうするのか？

・品質計画・・・・・・・・・品質について

・コミュニケーション計画・・・メンバーとの連絡手段などについて

2.2 プロジェクトの範囲

事前対処は全体を見通せる「地図」と言いました。

ここでは、どんな作業が必要になるのか→すべて洗い出す。

ＷＢＳ・・・階層的に作業を洗い出す

・大項目、中項目、小項目に分類する。

ゲーム本体のＷＢＳとプロジェクトのＷＢＳ

例：

・「売店システム」→「アイテムの選択」→「アイテムの表示」

・「日程計画」→「進捗管理」→「進捗報告」

全ての作業を洗い出せれば

・やらなければいけないこと

・必要な資材

・必要な人材

・必要な能力

・どのくらいの時間がかかるか

・どういう問題があるか

が分かる

○洗い出し方

・ＫＪ法

・他プロジェクト（ゲーム）の実績

2.3 スケジュール計画

○時間見積もり

・洗い出された作業に対してどれくらいの時間がかかるかを見積もる

・マイルストーンと比較して日程を組む

・後述のリスク計画で決まった作業の優先度を元に日程の完成版を組む

＜人間の悪いところ＞

・パーキンソンの法則

―見積もりよりも早く作業が終わったとしても、終了報告をせずにのんびり過

ごしたり、ぎりぎりまで必要以上の作りこみ作業をしてしまう。

例）見積り 4 日にして 2 日で終わってしまった時に、まだ時間があるからとク

オリティを上げようとしてしまい、結局 4日消費しつくしてしまう。

・学生症候群

―夏休みの宿題病

例）余裕を手前に持ってきて、ぎりぎりまで活動しない。

追い詰められて・・・

余裕→やるか→あれ？やばくね？→おわらねぇ

＜解決策＞

―2点見積もり

2点見積もり：

開始日から終了日、最悪終わり時間までを見積もる

（予備日を設ける）

・作業が終了したら次の作業をすぐ開始できる

・心理的に最小見積もりを目指す傾向がある。

○進捗管理

・ガントチャート

・進捗管理を実行する方法と日程

時間を見積もるワンポイントアドバイス

3日で終わりますというのは終わらない

→1日はフルで使えない

平日の一般作業時間を１時間とする。

休日の一般作業時間を 6時間とする。

2.4 リスク計画

洗い出された作業と決定したスケジュールから、考えられる問題点（リスク）

を洗い出す。

・難易度と重要度を決める。

・これが決まったら各作業の優先順位を決めて、スケジュール計画に反映させ

る。

リスク一覧表と開発戦略マトリクスと商品の価値空間の 3 つを考慮してリスク

に対する計画を立てる。

※ここで注意したいのが、実際に作る物ののみのリスクだけではなく、プロジ

ェクト自体のリスクも考える。

・メンバーの能力

・時期の背景（期末テストが近いなど）

・コミュニケーション不足

A）リスク一覧表

項目難易度重要度警戒度

（難×重）

対策案責任者

・警戒度が高いものを中心に入念に対策を練っておく

・代替案を用意して、いつ、どうやって「安全化」するのかを考えます。

・対策責任者も明確にします。

・「必要」「できれば」「そうでもない」と重要度を必ず考える。

B）開発戦略マトリクス

易難易度難

重要度

必ず作れる要素おそらく作れる要

作ってみないと不

必要な要素

・優先度中★★★

・迷わず作る

・他に影響を与え

ないのならば、む

しろ後回しでもＯ

・優先度高★★★

・できるだけ早期

に検証・実験する

・優先度最高★★

★★★

・最優先で検証・

実験し、バックア

ッププランを用意

できれば欲

しい要素・優先度低★★

・優先度中★★★

・優先的に検証・

実験するかどうか

を早期に決める

・優先度を下げる

場合は切り離し可

能な状態を維持し

てゆとりの人員と

時間で挑戦

・優先度低★★

・なるべく作らな

・作る場合は切り

離し可能な状態を

維持してゆとりの

人員と時間で挑戦

無くても困

らない要素

・優先度最低★

・人員や時間にと

ても余裕があった

ら後で作る

・優先度最低★

・なるべく作らな

・とても余裕があ

ったら挑戦してみ

ても良い

・優先度×

・作ってはならな

どれを犠牲にしてどれを優先して戦略を立てるか

C）商品の価値空間

価値＝品質 ×（物量 × 基本要素数）

品質：きれいか汚い・動きが良いか悪いか・面白さ・操作性・快適さ

―基本要素数の構築さえできていれば単純に作りこみによって高まる

物量：ステージが何面・敵が何体・イベントが何個

―時間や人数によって増やせる

―「色違い」とかで調整できる。

基本要素数：町がある・アクションパートがある・ミニゲームがある・イベン

―質でもあり量でもある。

―不確実性を減らす場合に最も効果を発揮するポイント

―ここの種類を減らすことでスケジュールの見通しが立ちやすくなる

―「ほんとうにその基本要素数は必要なのか」とプロジェクト初期に真剣に考

えましょう。

Ｘ＝基本要素数

Ｙ＝品質

Ｚ＝物量

→この箱を大きくするのが課題

→別に縦長でも、奥行きだけがすごくても、平べったくても良い

○リスク対応策の実行

実行方法と日程を記載する。

商品の価値空間

2.5 品質計画

・成果物自体の評価とプロジェクト自体の評価をする。

・評価方法と評価する頻度・方法を計画する。

・チェックリスト

項目をリストアップして何が終わっているのかをチェックする

・商品の価値空間

・デバックの方法

実行方法と日程を記載する。

2.6 コミュニケーション計画

これが一番重要。主に事後対策に関わる。

―情報の伝達手段

―会議の日・報告の日

―書式

詳細はこの後の実行段階で説明する。

スケジュール計画、リスク計画、変更計画、品質計画など各計画の実行段階で

の実行結果の伝達について計画する。

スケジュール計画と大きくかかわる。

→スケジュール計画が日程でコミュニケーション計画が内容

・プロジェクトの状況を定期的に報告する

－悪い情報であればあるほど早めに伝える

・プロジェクトの進捗情報を定期的に伝える。

－進捗どうですか→ダメです×

－進捗どうですか→後 3日です。

→数量化することによって進捗管理がしやすい。

意思の疎通ができないと…

「顧客が本当に必要だったもの」みたいになる。

例）木の椅子が欲しい→椅子を作って→できたのがソファ

2.8 仕様書の作成

―ゲーム仕様を設計する

―キャラクターや背景のアートワークを用意する

―世界観設定を用意する

―シナリオのプロットを考える

―技術戦略を考える

―プログラム設計をする

・原則として頭の中で想像の出来得る限りは設計をとことん行い、思考検証し、

設計を精錬させます。

・作らずとも頭の中で分かることはまず先に設計しつくすべき

・実際につくってものにしてみないと分からないことがあって初めて「設計の

ための仮実装（＝実験）」を行うべき。

・ゲーム仕様、技術仕様は早期に固めましょう

特にプログラムの仕様書は重要になる

―グラフィックやサウンドの仕様書はそこまで決定要因にならないし、変更が

効く

プログラムの仕様書（特にプログラミングを分担する場合）

・変数名や関数名は絶対に統一しなければならない

2.8計画を終えて

プロジェクトが現実的かどうか分かる。→品質計画と照らし合わせる。

１：１：１の法則（感覚論）

準備：実装：仕上げ

たいていは実装以外を小さく見積もっている。

実装以外は時間をしっかり割く

実装は思ったより時間が割けない

10日規模のプロジェクトならば 3日くらい

30に規模のプロジェクトならば 10日くらい

準備：準備：準備：実装：仕上げ：準備：実装：仕上げ：準備：実装：実装：

実装：仕上げ：仕上げ：仕上げ

2.9 まとめ

色々と述べてきましたが、分かりやすく要点をまとめると

・必要な作業を洗い出す

・作業時間を見積もる

・重要なイベント（マイルストーン）をスケジュールに置く

・作業の優先順位を決めてスケジュールに置く

・文書を必ず作成する（そしてメンバーと共有する）

・コミュニケーションは命

3．実行する

2．計画する。

3．実行する。

3.1 実行段階ですること

(ア) スプリント計画

(イ) 日々の製作

(ウ) 週の振り返り

(エ) スプリントの振り返り

(オ) 対策・再計画

スプリント：

2週間あるいは 4週間の固定期間でＰＤＣＡを回す周期のこと。

初日は計画に割き（スプリント会議のタイミングなど）

最終日は振り返りにする。

ア）スプリント計画

・スプリントの初日に「成果物目標リスト」と「タスク管理シート」を用意す

○成果物目標

・そのスプリントで達成したい作業の大項目～中項目を成果物と見なす

・「〇〇が△△できる」という文章で表現する。

・スプリントの終わりにこの成果物目標がどれだけ達成できたかを振り返る

○タスク管理シート：

・各タスクの進捗率を表したシート

・進捗どうですか？だめですというのをなしにするので細かく単位を見積もる。

・タスク管理ボードと照らし合わせ随時更新する。

イ）日々の製作

○タスク管理ボード：

・今週は何をすべきなのか、誰が何を担当しているのか、どこまで終わってい

るのかを管理するボード

・メンバーが常に確認の出来るようにする。

・タスク管理シートと照らし合わせ随時更新する。

スプリント計画週計画作業中完了

1班 2班 3班 1班 2班 3班

週 1 週 1 週 1 月 1班ＡさんＡさんＡさん

週 2 週 2 週 2 火 2班ＢさんＢさんＢさん

週 3 週 3 週 3 水 3班ＣさんＣさんＣさん

週 4 週 4 週 4 木ＤさんＤさんＤさん

金Ｅさん

―そのスプリントで行うタスクを班別に貼る欄

―その週で行うタスクを班別に貼る欄

―作業中のタスクを貼る欄

―完了したタスクを個人別に貼る欄

＜付箋の使い方＞

タスクの種類（付箋の色）

―黄色：計画内（スプリントの初日に計画したタスク）

―赤：計画外（スプリントの見積もりが甘かったために出てきた必要タスク）

―緑：割り込み（上司が計画にないことを追加するなど：災害）

―青：前倒し（スプリントに余裕ができたので）

黄色が多く・赤・緑・・・バランスが良い

赤が多い・・・設計の見積もりが甘い

○朝会

・メンバーで集まる

・司会担当者が以下を問います

－前日行った作業（1日の振り返り）

－本日の作業（1日の計画）

「進捗どうですか？」「だめです」ではなくて

「あと何日かかる」と言うことを言ってもらう

－問題や課題

・月曜日の朝会ではその週に行うタスクを「スプリント」の欄から「週」の欄

に移動し、「週の計画」とします。

タスク名：

Ａボタンでプレイヤーがジャンプ

最小見積もり・最大見積もり→実績：

―0．5日～1.5日→2日（オーバー）

実際の日付：

担当者の名前：

ウ）週の振り返り

○週報

○週定例会議

○週報

・各自にメールで全員宛に提出をしてもらう。

週次作業報告書（個人）

【報告者】

【作業期間】

【進捗率】

【作業内容】

【成果物】

【計画からの差異】

【良かった点】

【問題点→改善策】

【翌週の計画】

【自由コメント】

○週定例会議

・各制作ユニットのリーダーがユニットのメンバーを招集して、毎週金曜日に

端とする班の情報を確認します。

・事前に個人週報を提出してもらって、それを元に状況を分析し、必要に応じ

て対策を講じます。

・その結果は班長からチーム全体に「製作ユニット週報」としてメールで送ら

れます。

エ）スプリントの振り返り

○スプリント報

○スプリント振り返り会

○成果物発表会

○スプリント報

・現在のスプリントの状況を報告する。

○スプリントの振り返り

・4週間のスプリントが終わるとそのスプリントの進捗具合や問題点を振り返る。

○成果物発表会

・視覚化によって分かりやすくなる

・「成果物発表会までに良い感じに仕上げる！」とモチベーションが上がる。

振り返りの手法：：

KPT：

活動を振り返るときに「継続」「問題点」「挑戦」の 3視点で整理する。

振り返りの度に実施する。

・今後も続けること

・良いこと

・改善策

・工夫したいこと

・挑戦したいこと

（「しっかり」「ちゃんと」という表現

は×）

Problem

・不満点

・問題点

（「～していない」という表現は×）

・Ｐ→Ｔ→Ｋ・・・問題解決

・Ｔ→Ｋ・・・新しいことに挑戦

・Ｋ→Ｔ→Ｋ・・・より良く

オ）対策・再計画

―作業優先度の見直し

―担当者の配置換え

―設計の見直し

―人員採用計画の修正

だいたい以下の二点が問題の原因

―数値見積もりの甘さ

―見積もりの洗い出しが足りない

3.2 まとめ

・定例会議など情報共有の日程と頻度

・常に進捗報告

・報告、連絡、相談

・計画→実行→評価→反省→反省した計画→実行・・・

・どこを変更したかは明確に

4．チームマネジメント

4.1 チームで動く前に

ちーむで動くうえで重要なこと

・情報の共有化

・目的の共有化

4.2 リーダーシップ理論

パフォーマンス：目標達成や課題解決を中心に行うリーダー

メンテナンス：集団の人間関係の維持を中心に行うリーダーシップ

←課題指向型

＜P＞

目標達成に焦点を置くリーダー

＜PM>

目標達成を強調しながら人間関係に

も気を配るリーダー

＜pm＞

目標達成にも人間関係の調整にも

消極的なリーダー

＜M＞

目標達成よりも集団内の人間関係を

気に配るリーダー

人間関係指向型→

ＦＦＳ理論

ここではリーダーの特性についてはあまり述べません

4.3 チームの変遷とリーダーの役割

―チーム形成期

：チームを編成してメンバー同士がお互いを知合う段階

・プロジェクトの目的を的確に伝える。

・メンバーの役割、期待していることを明示する

・メンバー間の依存関係を明らかにする。

・メンバー同士を知り合える環境を提供する

・チームのルールを作る

→アイスブレークをする。

―嵐の状態

：自分の責任範囲や権限、あるいは思い込みなどにより、他のメンバーとの衝

突が起こる段階

・メンバー間の衝突は次の成長のために必要なことだと考える。

・衝突をうわべだけ無理に抑え込まないようにする。

・メンバーと向き合って本質的な問題解決を心がける。

・プロジェクトの進め方についての了承をとる。

→互いに協力し合う姿勢を

―規範期

：嵐の状態が過ぎてチームとして機能を始めた段階

・メンバー同士が能力を最大限に発揮できるようにサポートする。

・チームとしての意識を尊重する。

―高パフォーマンス

：チームが目的達成に向けて、自発的にどんどん義務を遂行している段階。

・チームがより効率的、効果的に業務遂行できるようサポートする。

・メンバーの責任範囲、業務範囲を拡大する。

・チームの達成した成果を祝う。

4.4 叱り方

ポジティブフィードバック

・良い行動を指摘

・望ましい行動の良い結果

・今後どんな行動をとってほしいかを伝える

例：

・おばあさんを助けたね？良いことだよ！

・お礼に林檎をもらえたじゃん！

・これからも助けてあげてね

ネガティブフィードバック

・客観的な事実に基づき問題行動を指摘する。

・問題行動による望ましくない結果を指摘する。

・今後どんな行動をとってほしいかを伝える。

例：

・バイト遅刻したね？悪いことだよー

・他のバイトの人が代わりにやったんだよ

・次からは遅刻しないでね

→この時に必ず原因を聞く、そして注意するときはそのことだけ注意をする。

関係ないことまで注意しない。

悪い例：

遅刻したね→寝坊したからだって？→だらしないなぁ→そんなんだから単位を

落とすんだよ

良い例：

遅刻したね→寝坊したからだって？→どう対処するのかね？→そうだね、目覚

ましを早めにセットするとかね→次からは気を付けてね

4.5 教え方

コーチング：

・気づかせる、考えさせる、決めさせる。

・協同型、参加型

・対等な関係、双方向

・内発的動機付け

ティーチング

・教える、指導する、アドバイス

・命令、指示待ち

・外発的動機付け

4.6 質問の仕方

オープンクエスチョン：

・どうやって作るの

・何が手に入るの？

→自由な解答

５Ｗ１Ｈ

アイディアや情報を引き出す際に使う。

自発性を引き出す効果がある。

1．限定質問

＝「いつ」「どこ」「だれ」

行動を明確にしたり、目標を具体化する際に使う。

2．拡大質問

＝「何」「なぜ」などを使う

相手の考えを広げたり深めたりできる質問

モチベーションを高めたいときに効果的

クローズドクエスチョン：

・報告した？

・作業終わった？

→ＹＥＳ、ＮＯ

きかっけとなる疑問、相手に決断を迫る質問。

1．狙い撃ちにする質問

的を射ていると鋭い質問になり、大きな【気づき】がある。

2．質問者の提案が含まれた質問

会話がはずまない→クローズドクエスチョン→オープンクエスチョン

4.7 孫子の兵法

「敵を知り己を知れば百戦危うからず」

とか

リーダーとしての心構えと言うより、チーム、組織で動くことについての本

4.8 心構え

●緻密に設計すべし

●地道にコツコツと

●背負う覚悟を持て！

泥まみれになれ！

腹をくくれ！

5．ゲーム制作の心得

・1ステップずつ進んでいこう

・失敗してもあきらめるな

・自分で調べる癖をつけよう

【参考】

「ゲームの作り方基礎編」

http://gcg.sakura.ne.jp/tt/g_creat/g_creat/g_creat_kiso01index.htm

「企画書の書き方」

http://gcg.sakura.ne.jp/tt/g_creat/g_creat/kikakusyo01index.htm

・橋本善久氏講演『ゲーム開発プロジェクトマネジメント講座 2012』

http://www.nicovideo.jp/watch/sm19433622

・吉田直樹氏講演『新生 FINAL FANTASY XIV：ゲームを作り直すというこ

と』

http://www.nicovideo.jp/watch/sm19427716

最新情報システムの開発伏見正則著

情報システムの分析設計と開発大木幹雄著

プロジェクト管理入門翔泳社

ＰＭプロジェクトマネジメント中嶋秀隆著

孫子の兵法のことがマンガで 3時間でマスターできる本安恒理著

プロジェクトはなぜっ失敗するのか伊藤健太郎著

ゲームデザイン脳舛田省治著

吉田直樹氏講演『新生 FINAL FANTASY XIV：ゲームを作り直すということ』

・お客様の信頼はどうやったら取り戻せるのか

・ゲームのどの部分が悪いのか

・お客様と同コミュニケーションをとるか

・どうやって「ＦＦらしさ」を出すのか

・ネガティブな印象をどう払しょくしていくのか

→などを「冷静」に分解することが重要

走るのをやめて、立ち止まったほうが良い。

・「ＦＦ」シリーズとしてのコンセプト確定

・「ＭＭＯＲＰＧ」として必要な要素の確定

・プレイヤーとの対話方法考案

・適切なビジネススキームの適用

・長期運用するために必要な技術の用意

→「ゲームデザインのゴールを設定」

知識が無かったら勉強をする。

・掲げた「ＦＦ」と今の「ＦＦ」の相違点は

・「ＭＭＯＲＰＧ」としての不足要素は何か

・フォーラムは？テストサーバは？

・クレジットカード以外の決済方法は

→現状とゴールの比較＝問題点の洗い出し

・テクノロジーを任せられるプロフェッショナル

・デザインの方向性を決められるコアスタッフ

・バトルシステムのスペシャリスト

・インターフェースのスペシャリスト

・現状の問題点を最も把握しているスタッフ

・熱意のあるマネージメントスタッフ

→信頼できる仲間さがし

パーティ募集

・実現可能なテクノロジー範囲なのか

・グラフィックスの方向性は妥当か

・バトルシステムは時代のニーズに合うか

・インターフェースの膨大さはどの程度か

・現状とゴールのギャップはどれくらいあるか？

→ゴールと問題点の正確性・妥当性を判断。

・人を増やしすぎない―少数精鋭で良い

・実現不可能なことはないか確認する

・感覚論「だけ」で製作しようとしていないか

・リソースの物量は果たして正しいのか

・ゴールは本当にゴールと言えるのか

・ビジネスとして成り立っているのか

→「後で何とかなるよ」などと問題から逃げたり、目を背けたりしないこと

・たくさんのキャラクターを表示するには

・サーバはワールドレスに設計し直せるか

・インターフェースは修正しきれるのか

→問題点に対しての解決策の定義をします。

粘り強く時間をかける。

・描画エンジンの性能は？

・サーバ性能は？

・バトル計算式やリソースは入替可能か？

・修正コストは？

→解決策の定義＝どうするのか？ではなく「なにをするのか」の定義

お客様の信頼を取り戻す＝「ＦＦ」というブランドの回復

理論的・現実的には作り直すより「新作」を作る方が良い

→しかし、それはブランドの「死」を意味する。

・これ以上の失望をお客様に与えてはいけない

・まずはプレイしていただいている方に面白さを提供

・批判を真摯に受け止めて誠実に対応

・ＦＦナンバータイトルのプライドを捨てない

・なにより「楽しんでいただく」

→ビジネス的な成功は二の次！

お客様からの信頼回復こそがゴール！

ネガティブな印象をどう払しょくしていくのか？

・新生を面白いゲームにするのは当たり前

・最終的には「触っていただく」しか方法はない

・「どうせだめだろう」をどう軽減するか

・足りなかった「ＦＦらしさ」を強く出したい

・作り直しすら楽しめないと意味がない

・マップは全て作り直す

→世界の崩壊を物語にしよう！

ＦＦ14の改善をそのままストーリーに

2014年にはマヤの予言から隕石により世界が滅びる

→隕石？ＦＦで隕石といえば・・・「メテオ！！」

→パッチで更新する毎に惑星のグラフィックが近づく→あえて告知はしないで

話題になったら告知「メテオイベント」

→だが、メテオが落ちてくるだけでは面白くない

→球体・・・ボール・・・卵・・・→バハムート！！

メテオと見せかけて中からバハムートが！

世界崩壊から新生へ

・メテオの落下を阻止するストーリー

・世界が破滅へ向かう中でリアルタイムプレイ

・メテオはバハムートの拘束具

・伏線は貼りつつ絶対に読めないように秘匿する

・「ＦＦらしさ」を追及して興味喚起を促す

プロジェクトマネジメント講座...

Documents

キャリア基礎講座第二回「自分を知る①」

チタンの基礎 - tohoku university official english...

専修大キャリア基礎講座...

プロジェクトマネジメントのあり方 ·...

ボライゥ゠感染対応...

キネシオテーピング基礎講座 ·...

ifrs基礎講座 ias第16号有形固定資産...ias第16...

プロジェクトマネジメント３時間講座...

xamarin 基礎講座

ニッケルの基礎 - tohoku university official english...

基礎講座物質と電気

第2回「クラシック・コンサート制作...

fibre channel 基礎講座

キャリア基礎講座最終回

自然を学ぶ基礎講座第 2 回

クリティカルチェーン･プロジェクトマネジメント...

教養科目「宇宙プロジェクトマネジメント入門」...

データサイエンス基礎講座€¦ ·...

xamarin 基礎講座 2016年7月版

第34回勉強会 google...