SQUARE ENIX OPEN CONFERENCE

ゲーム開発
プロジェクトマネジメント講座
２０１１年１０月８日
株式会社スクウェア・エニックス
CTO 橋本 善久©SQUARE-ENIX 20111

なぜプロジェクトは失敗するのか？
©SQUARE-ENIX 20112

プロジェクトの失敗ポイント• 見込みより売上が少ない• 計画よりもコストがかかっている• 発売時期が遅れた• 発売に間に合わせるため内容が削られた• ユーザーの評判が悪い• 不具合が発生• スタッフの満足度が低い、故障者が出た、辞めてしまった• など・・・©SQUARE-ENIX 20113

プロジェクトの失敗ポイントの分類• スコープ（コンテンツの範囲）の問題• 品質の問題• コストの問題• 時間の問題• リソース（人員・環境）の問題• ビジネスの問題©SQUARE-ENIX 20114

プロジェクトの失敗ポイントの分類• スコープ（コンテンツの範囲）の問題• 品質の問題• コストの問題• 時間の問題• リソース（人員・環境）の問題• ビジネスの問題
絡み合う複雑なパラメータ

これらをうまく制御したい©SQUARE-ENIX 20115

問

プロジェクトの初期に立てた計画は最終的にどれほどの誤差を生むのでしょうか？

©SQUARE-ENIX 20116

当初計画比で１．２倍？
１．５倍？
それとも２倍？
©SQUARE-ENIX 2011

7

いえいえ
そんな甘い数値ではないのです©SQUARE-ENIX 20118

まずは計画を変動させる
主要因を列挙してみましょう©SQUARE-ENIX 20119

計画の主な変動要因• スコープの変化• 人員計画のエラー– 仕様の追加・変更• タスク分解のエラー– 既知の仕様に対してタスクの洗い出し漏れがあった場合• 見積もりのエラー– 思ったより人数を増やせない– 思ったより能力がない– 辞められる、故障者が出る• 品質マネジメントのエラー– 品質が上がらないので作り直し– タスク消化にかかる時間を見誤った場合• 技術マネジメントのエラー• 一日あたりの作業時間見込みエラー– プログラム的に実現が困難なので作り直し– 会議その他で思ったよりも作業時間が取れなかった場合など• その他いろいろ・・・©SQUARE-ENIX 201110

変動要因別の変化幅の例
•
•
•
•
•

•
•
•

仕様追加でスコープ変更⇒１．５倍
タスク分解のエラー⇒１．４倍
見積もりのエラー⇒１．３倍
一日あたりの作業時間見込みエラー⇒作業時間－２０％＝１．２５倍人員計画のエラー– 思ったように増員できなかった⇒－２０％＝１．２５倍– 思ったような能力が無かった⇒－３０％＝１．４倍
品質マネジメントのエラー⇒１．３倍
技術マネジメントのエラー⇒１．３倍
・・・©SQUARE-ENIX 201111

それぞれの要因による
計画増加分を掛け合わせてみると・・・※それぞれの要因は独立しており、おおよそ直交性があると仮定します©SQUARE-ENIX 201112

１．５×１．４×１．３×１．２５
×１．２５×１．４×１．３×１．３©SQUARE-ENIX 201113

１．５×１．４×１．３×１．２５
×１．２５×１．４×１．３×１．３≒１０倍！！

©SQUARE-ENIX 2011

14

まさかの

当初計画比１０倍という無茶苦茶な数値が出てきました©SQUARE-ENIX 201115

相当ラフな計算ではありますが、如何に直感と異なる大きな誤差になるのかはお分かりになれたかと思います※あくまでも、直感よりも遥かに大きいということを伝えるための計算なので、その計算方法や数値の精度に対しては目をつむってください©SQUARE-ENIX 201116

ではこの途方もない誤差に対してみなさんは普段どのように対処しているのでしょうか©SQUARE-ENIX 201117

１０倍なんて膨らんだら解決は無理？
いえいえ結構みなさん日常的に対処してるのです©SQUARE-ENIX 2011

18

対処１
仕様を３５％削減©SQUARE-ENIX 2011

19

対処１
仕様を３５％削減⇒１．５４倍の対策効果©SQUARE-ENIX 2011

20

対処２
人員を６０％追加投入©SQUARE-ENIX 2011

21

対処２
人員を６０％追加投入⇒１．６倍の対策効果※もちろん人を足したからといって素直に人数分の効果が出るわけではありませんが簡易計算として割り切ります©SQUARE-ENIX 2011

22

対処３
期間を５０％延長©SQUARE-ENIX 2011

23

対処３
期間を５０％延長⇒１．５倍の対策効果©SQUARE-ENIX 2011

24

対処４
品質を３０％妥協する©SQUARE-ENIX 2011

25

対処４
品質を３０％妥協する⇒１．４３倍の対策効果※品質を下げる事で工数を減らすという意味で単純計算しています©SQUARE-ENIX 201126

１．５４×１．６×１．５×１．４３©SQUARE-ENIX 201127

１．５４×１．６×１．５×１．４３≒５．６４倍の対策効果©SQUARE-ENIX 201128

１．５４×１．６×１．５×１．４３≒５．６４倍の対策効果
うーんまだまだ１０倍の対策効果まで足りません
これでは発売不能です©SQUARE-ENIX 201129

なにか良い手だては無いでしょうか©SQUARE-ENIX 201130

あ、
©SQUARE-ENIX 201131

ひとつ効果的な方法が残っていました©SQUARE-ENIX 2011

32

対処５
月の労働時間を
１６０時間から
２９０時間にする©SQUARE-ENIX 2011

33

対処５
月の労働時間を
１６０時間から
２９０時間にする⇒１．８倍の対策効果©SQUARE-ENIX 201134

１．５４×１．６×１．５×１．４３
×１．８©SQUARE-ENIX 201135

１．５４×１．６×１．５×１．４３
×１．８≒１０倍の対策効果©SQUARE-ENIX 201136

１．５４×１．６×１．５×１．４３
×１．８≒１０倍の対策効果

これで晴れて対策を打つことができました！！
発売可能ですね！！！
©SQUARE-ENIX 201137

めでたしめでたし！！

©SQUARE-ENIX 201138

めでたしめでたし！！
・・・のはずもありませんよね©SQUARE-ENIX 201139

対処１ 仕様を３５％削減
対処２ 人員を６０％追加投入
対処３ 期間を５０％延長
対処４ 品質を３０％妥協する
対処５ 月の労働時間を８０％増やす©SQUARE-ENIX 201140

対処１ 仕様を３５％削減
対処２ 人員を６０％追加投入
対処３ 期間を５０％延長
対処４ 品質を３０％妥協する
対処５ 月の労働時間を８０％増やす

見事なデスマーチの完成です
結構ありがちな風景ではないでしょうか©SQUARE-ENIX 201141

プロジェクトの失敗ポイントの分類• スコープ（コンテンツの範囲）の問題• 品質の問題• コストの問題• 時間の問題• リソース（人員・環境）の問題• ビジネスの問題©SQUARE-ENIX 201142

プロジェクトの失敗ポイントの分類• スコープ（コンテンツの範囲）の問題• 品質の問題• コストの問題• 時間の問題• リソース（人員・環境）の問題• ビジネスの問題

がんばって着地させたが・・・

プロジェクトとしては失敗©SQUARE-ENIX 201143

プロジェクトの失敗ポイントの分類• スコープ（コンテンツの範囲）の問題• 品質の問題• コストの問題• 時間の問題• リソース（人員・環境）の問題
ビジネスとして成功か失敗か• ビジネスの問題
は発売するまでは不明

がんばって着地させたが・・・

プロジェクトとしては失敗©SQUARE-ENIX 201144

プロジェクトの失敗ポイントの分類• スコープ（コンテンツの範囲）の問題• 品質の問題• コストの問題• 時間の問題
この状況で売れるか売れないか
どっちが幸福かは難しいところ• リソース（人員・環境）の問題
ビジネスとして成功か失敗か• ビジネスの問題
は発売するまでは不明

がんばって着地させたが・・・

プロジェクトとしては失敗©SQUARE-ENIX 201145

一般的に、ソフトウェア開発ではとてつもなく巨大な計画の誤差が生まれ、それに対して途方もない
苦労を割いてどうにかこうにか対処し、不満足な状態で無理やり着地させているのが実情です。
※もちろんうまく行っているプロジェクトにはあてはまりません©SQUARE-ENIX 201146

ウキウキ♪

希望©SQUARE-ENIX 2011

47

ハッ！

ウキウキ♪

膨張
希望

©SQUARE-ENIX 2011

48

ハッ！

シクシク・・・

ウキウキ♪

膨張
妥協

希望

©SQUARE-ENIX 201149

失敗プロジェクトハッ！

シクシク・・・

ウキウキ♪

膨張
妥協

希望

©SQUARE-ENIX 201150

プロジェクトの初期計画とその結果の誤差は１０倍になってもおかしくないほどに乖離してしまうのです※現実には初期計画誤差１００倍などというトンデモケースもありえると考えます©SQUARE-ENIX 2011

51

つまり

©SQUARE-ENIX 201152

プロジェクトの正確な予想なんて
出来っこないのです©SQUARE-ENIX 201153

では、プロジェクトを制御することは無理なのでしょうか？
やるだけ無駄なのでしょうか？

©SQUARE-ENIX 2011

54

いいえ、

プロジェクトを制御することは可能です©SQUARE-ENIX 201155

予想は難しくても制御はできるのです©SQUARE-ENIX 201156

プロジェクトとは不確実なものであるという事実を受け入れ、問題が大きくなってから対応する
行き当たりばったりの運営から用意周到な事前対処と積極的な事後対処を実践することでプロジェクトを制御することが可能になります©SQUARE-ENIX 201157

不確実性を乗りこなす• 事前対策（調査・戦略・設計・計画）– 不確実性を減らす• 見通しが悪い部分の調査や検証/実験をしっかりと行う• 作業データを取り、フィードバックをかけて予測精度を向上させる• 計画規模を小さくする– どうせ計画は膨らむのだから最初に目いっぱいコンパクトにする• 設計をなるべく詳細に行う• リスクの高い要素を予め極力減らす– 不確実でも良い事にする• リスクの高い要素を無くしてても成立する設計にする– その要素が無くなっても商品の価値が下がらない設計にする» トカゲのしっぽとしていつでも切れるようにする• 事後対策（イテレーション）– 変化や問題発生にすばやく気づく– 変化や問題にすばやく対応する©SQUARE-ENIX 201158

まずはイテレーションの大切さから©SQUARE-ENIX 201159

Plan-Do-Checkサイクル
すべての
基礎！

Plan
計画や対策を
考える

Check

Do

振り返る

実行する

©SQUARE-ENIX 201160

ん？という方いますよね。

©SQUARE-ENIX 201161

ちょっと補足©SQUARE-ENIX 201162

世間ではPDCAという言い方が主流ですが

Plan
計画する

ActionDo

対策を講じる

実行する

Check
振り返る

©SQUARE-ENIX 201163

①は②に内包できて冗長でありどうにも違和感があるのでこの表現は本講義では用いません

Plan

②

計画する

Do

Action① 対策を講じる

実行する

Check
状況を確認する©SQUARE-ENIX 2011

64

戻ります

©SQUARE-ENIX 201165

Plan-Do-Checkサイクル
すべての
基礎！

Plan
計画や対策を
考える

Check

Do

振り返る

実行する

©SQUARE-ENIX 201166

ありがちなプロジェクト
問題・リスク

Plan

Do

Do

Do

Do

Plan

Do

Do

時間

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

ダメなプロジェクト
問題・リスク

Plan

Do

Do

Do

Do

Do

Do

Do

時間

一回計画を立ててあとは作りつづけるのみ。
リスクは増大する一方©SQUARE-ENIX 2011

68

ダメダメなプロジェクト
問題・リスク

Do

Do

Do

Do

Do

Do

Do

Do

計画もなくただやみくもに作る。
プロジェクト初期から問題だらけ。

©SQUARE-ENIX 201169

惜しいプロジェクト
問題・リスク

Plan

Do

Check

Plan

Do

Check

Plan

Do

時間

計画⇒実行⇒振り返り⇒再計画⇒実行⇒振り返り⇒再計画・・・というサイクルを行っているが、その単位が大きい。

©SQUARE-ENIX 201170

良いプロジェクト
問題・リスクP D C P D C P D C P D C P D C P D C P D C P D

時間

短いサイクルで計画⇒実行⇒振り返り⇒再計画⇒実行⇒振り返り⇒再計画・・・と回すことで問題やリスクが早い段階で摘み取られるので、安定したプロジェクト運営が行われる。
©SQUARE-ENIX 201171

ひとつ例を見てみます©SQUARE-ENIX 201172

イテレーションの例

ミサイルを飛ばす©SQUARE-ENIX 201173

ミサイルを飛ばす（ダメな例）
１０秒に一回制御

風（外的要因）ターゲット
イテレーションサイクルが長いので軌道修正しにくい

ハズレ

発射！
©SQUARE-ENIX 2011

74

ミサイルを飛ばす（良い例）
風（外的要因）ターゲット

イテレーションサイクルが短いので文字通り
軌道修正しやすい

アタリ

発射！
©SQUARE-ENIX 201175

すばらしい©SQUARE-ENIX 201176

じゃあイテレーションを
細かくまわせばプロジェクト
マネジメントはバッチリ！

©SQUARE-ENIX 201177

じゃあイテレーションを
細かくまわせばプロジェクト
マネジメントはバッチリ！
・・・でもありません©SQUARE-ENIX 201178

実はなにも考えずに
細かくイテレーションをまわしているだけでは大きな落とし穴にハマります©SQUARE-ENIX 2011

79

その話に移る前準備として・・・©SQUARE-ENIX 201180

近頃はアジャイルという言葉が流行っていますが・・・©SQUARE-ENIX 201181

誤解の中運用されているケースもあるように思います©SQUARE-ENIX 201182

よくあるアジャイルの誤解• 仕様や設計なんていらない！
• ドキュメントなんていらない！
• 計画なんていらない！
• 「作って、壊して」を短いイテレーションで繰り返せば万事解決！
• ウォーターフォールは悪！

©SQUARE-ENIX 201183

よくあるアジャイルの誤解• 仕様や設計なんていらない！
• ドキュメントなんていらない！
• 計画なんていらない！
• 「作って、壊して」を短いイテレーションで繰り返せば万事解決！
• ウォーターフォールは悪！

©SQUARE-ENIX 201184

アジャイルが「楽をする為の免罪符」
的に曲解されて扱われている
ケースがあるように思います※もちろんちゃんと運用されている方もたくさんおられます©SQUARE-ENIX 201185

よくあるアジャイルの誤解• 仕様や設計なんていらない！
• ドキュメントなんていらない！
• 計画なんていらない！
• 「作って、壊して」を短いイテレーションで繰り返せば万事解決！
• ウォーターフォールは悪！

©SQUARE-ENIX 201186

よくあるアジャイルの誤解• 仕様や設計なんていらない！
• ドキュメントなんていらない！
• 計画なんていらない！
• 「作って、壊して」を短いイテレーションで繰り返せば万事解決！
• ウォーターフォールは悪！

これは幻想です©SQUARE-ENIX 201187

よくあるアジャイルの誤解• 仕様や設計なんていらない！
• ドキュメントなんていらない！
• 計画なんていらない！
• 「作って、壊して」を短いイテレーションで繰り返せば万事解決！
• ウォーターフォールは悪！

繰り返します©SQUARE-ENIX 201188

よくあるアジャイルの誤解• 仕様や設計なんていらない！
• ドキュメントなんていらない！
• 計画なんていらない！
• 「作って、壊して」を短いイテレーションで繰り返せば万事解決！
• ウォーターフォールは悪！

これは幻想です©SQUARE-ENIX 201189

アジャイルを誤解して導入するとむしろ危険です©SQUARE-ENIX 201190

よくあるアジャイルの誤解• 仕様や設計なんていらない！
• ドキュメントなんていらない！
• 計画なんていらない！
• 「作って、壊して」を短いイテレーションで繰り返せば万事解決！
• ウォーターフォールは悪！

なぜ間違いなのか考察してみます©SQUARE-ENIX 201191

「建物を建てるプロジェクト」
を想像します©SQUARE-ENIX 201192

建物を建てる
超高層ビル

犬小屋©SQUARE-ENIX 201193

犬小屋を建てる場合• 一人でもできる• せいぜい２、３日もあれば建てられる• すべての作業を容易に洗い出す事ができる• 一つ一つの作業の時間を予想しやすい• 最悪やり直してもどうにかなる• 計画ゼロでもどうにかなる©SQUARE-ENIX 2011

犬小屋

ワンワン！

94

超高層ビルを建てる場合• 途方もない人数が必要

超高層ビル• 構想、設計から始めて数年かかる• すべての作業を見通すことは大変難しい• 一つ一つの作業の時間を予想しにくい• やり直しがきかない– 例）４０階建てのつもりだったけど
やっぱり６０階にしよう（無理！）©SQUARE-ENIX 2011

95

建物を建てる
超高層ビル

犬小屋©SQUARE-ENIX 2011

96

建物を建てる
超高層ビル

同じ方法論が通用する？
犬小屋©SQUARE-ENIX 2011

97

犬小屋

超高層ビル

一人でもできる

途方もない人数が必要

せいぜい２、３日もあれば建てられる

構想、設計から始めて数年かかるすべての作業を容易に洗い出すことができる

すべての作業を見通すことは大変難しい

一つ一つの作業の時間を予想しやすい

一つ一つの作業の時間を予想しにくい

最悪やり直してもどうにかなる

やり直しがきかない©SQUARE-ENIX 201198

よくあるアジャイルの誤解• 仕様や設計なんていらない！
• ドキュメントなんていらない！
• 計画なんていらない！
• 「作って、壊して」を短いイテレーションで繰り返せば万事解決！
• ウォーターフォールは悪犬小屋を建てるならば確かにそれもアリかも・・・©SQUARE-ENIX 201199

よくあるアジャイルの誤解• 仕様や設計なんていらない！
• ドキュメントなんていらない！
• 計画なんていらない！
• 「作って、壊して」を短いイテレーションで繰り返せば万事解決！
• ウォーターフォールは悪でも高層ビル建築でこういうポリシーでは大破綻©SQUARE-ENIX 2011

100

建物を建てる
超高層ビル

犬小屋©SQUARE-ENIX 2011101

建物を建てる
超高層ビル

同じ方法論は通用しない！
犬小屋©SQUARE-ENIX 2011

102

建物など

“規模や問題が目に見えやすい物”
で考えれば誰にでも簡単にイメージ出来る話でしたね©SQUARE-ENIX 2011

103

超高層ビルを建てる場合に調査も設計も計画もなにもせずにいきなり柱を立て始める
人はひとりもいませんよね？

©SQUARE-ENIX 2011104

地盤調査や立地調査をし、資金計
画やビジネス計画も行い、外観設
計、内装設計、強度計算、素材実験、コスト計算、リスク見通し、人員計画、作業洗い出し、工数見積
もり、なんでもやれる限りの事前準備をしないととてもまともな超高層ビルが建つ気がしないですよね？
©SQUARE-ENIX 2011105

でもなぜかソフトウェア開発になると人は間違えてしまいます©SQUARE-ENIX 2011106

調査しない・・・
戦略を立てない・・・
設計しない・・・
計画しない・・・©SQUARE-ENIX 2011107

それでも中型・大型プロジェクトをスタートさせてしまう無謀な事例は決して尐なくないと考えます※きちんとやられている方の事は指しておりません©SQUARE-ENIX 2011108

“規模や問題が目に見えにくい”
ので自分が大破綻に向かってまっ
しぐらなことを全く自覚せずに、問題が表面化してどうにもならなくなるまで作業を進めることができてしまうのがソフトウェア開発の恐ろしい所なのです©SQUARE-ENIX 2011109

話は戻りましてさっきのおさらい©SQUARE-ENIX 2011110Plan-Do-Checkサイクル
すべての
基礎！

Plan
計画や対策を
考える

Check

Do

振り返る

実行する

©SQUARE-ENIX 2011111

良いプロジェクト
問題・リスクP D C P D C P D C P D C P D C P D C P D C P D

時間

短いサイクルで計画⇒実行⇒振り返り⇒再計画⇒実行⇒振り返り⇒再計画・・・と回すことで問題やリスクが早い段階で摘み取られるので、安定したプロジェクト運営が行われる。
©SQUARE-ENIX 2011

112

ミサイルを飛ばす（良い例）
風（外的要因）ターゲット

イテレーションサイクルが短いので文字通り
軌道修正しやすい©SQUARE-ENIX 2011

アタリ

113

イテレーションサイクルさえ
細かく回してれば万事解決的に見えますが・・・©SQUARE-ENIX 2011114

本当にそうでしょうか©SQUARE-ENIX 2011115

確かにイテレーションを細かく回すことは絶対的に重要です
疑う余地がありません©SQUARE-ENIX 2011116

ですがそれだけでは越えられない壁があります©SQUARE-ENIX 2011

117

再び考察

©SQUARE-ENIX 2011118

「ダンジョンを歩いて抜ける」
プロジェクト©SQUARE-ENIX 2011

119

G

スタートとゴールS©SQUARE-ENIX 2011

120

G

見える

岩

岩
岩
岩

S

岩
©SQUARE-ENIX 2011

121

G

歩く

岩

岩
岩
岩

S

岩
©SQUARE-ENIX 2011

122

G

見える

岩
岩

岩

岩
岩
岩

S

岩

岩

岩
©SQUARE-ENIX 2011

123

G

歩く

岩
岩

岩

岩
岩
岩

S

岩

岩

岩
©SQUARE-ENIX 2011

124

G

見える

岩

岩
岩

岩

岩

岩
岩

岩
岩

S

岩

岩

岩

岩

©SQUARE-ENIX 2011

125

G

歩く

岩

岩
岩

岩

岩

岩
岩

岩
岩

S

岩

岩

岩

岩

©SQUARE-ENIX 2011

126

G

見える
岩
岩

岩
岩

岩

岩

岩

岩
岩

岩
岩

S

岩

岩

岩

岩

岩

岩

©SQUARE-ENIX 2011

127

G

歩く
岩
岩

岩
岩

岩

岩

岩

岩
岩

岩
岩

S

岩

岩

岩

岩

岩

岩

©SQUARE-ENIX 2011

128

G

見える
岩
岩

岩
岩

岩

岩

岩

岩
岩
岩

岩

岩

岩

岩

S

岩

岩

岩

©SQUARE-ENIX 2011

岩

岩
岩
岩

129

G

歩く
岩
岩

岩
岩

岩

岩

岩

岩
岩
岩

岩

岩

岩

岩

S

岩

岩

岩

©SQUARE-ENIX 2011

岩

岩
岩
岩

130

G

見える
岩
岩

岩
岩

岩

岩

岩

岩
岩
岩

岩

岩

岩

岩

S

岩

岩

岩

©SQUARE-ENIX 2011

岩 岩

岩
岩

岩
岩

岩

岩

131

G

歩く
岩
岩

岩
岩

岩

岩

岩

岩
岩
岩

岩

岩

岩

岩

S

岩

岩

岩

©SQUARE-ENIX 2011

岩 岩

岩
岩

岩
岩

岩

岩

132

G

順調順調
岩
岩

岩
岩

岩

岩

岩

岩
岩
岩

岩

岩

岩

岩

S

岩

岩

岩

©SQUARE-ENIX 2011

岩

岩

岩 岩

岩

岩

岩

岩
岩

岩

岩

133

G

イテレーション万歳！
岩
岩

岩
岩

岩

岩

岩

岩
岩
岩

岩

岩

岩

岩

S

岩

岩

岩

©SQUARE-ENIX 2011

岩

岩

岩 岩

岩

岩

岩

岩
岩

岩

岩

134

G

オレって天才？
岩

岩

岩

岩

岩

岩
岩
岩

岩

岩

岩

岩

岩

©SQUARE-ENIX 2011

岩
岩

岩

岩

S

岩

岩

岩

岩

岩

岩

岩

岩 岩

岩

岩

岩

岩
岩

岩

岩

135

G

楽勝だね♪
岩

岩

岩

岩

岩

岩
岩
岩

岩

岩

岩

岩

岩

©SQUARE-ENIX 2011

岩
岩

岩

岩

S

岩

岩

岩

岩

岩

岩

岩

岩 岩

岩

岩

岩

岩
岩

岩

岩

136

G

もうすぐゴールだ！

岩
岩

岩

岩

岩

岩

岩

岩

岩
岩

岩

S

岩

岩

岩

岩

岩

岩

©SQUARE-ENIX 2011

岩
岩

岩

岩

岩

岩

岩

岩

岩

岩

岩

岩

岩

岩 岩

岩

岩

岩

岩
岩

岩

岩

137

G

ゴンッ！！

岩

岩

岩

岩

岩

岩

岩

岩

岩

岩
岩

岩

S

岩

岩

岩

岩

岩

岩

©SQUARE-ENIX 2011

岩
岩

岩

岩

岩

岩

岩

岩

岩

岩

岩

岩

岩

岩 岩

岩

岩

岩

岩
岩

岩

岩

138

G

うっそ～！
行き止まり！！
岩

岩
岩

岩

S

岩

岩

岩

岩

©SQUARE-ENIX 2011

岩

岩

岩

岩

岩

岩
岩

岩

岩

岩

岩

岩

岩

岩

岩

岩

岩

岩

岩

岩

岩

岩

岩

岩 岩

岩

岩

岩

岩
岩

岩

岩

139

G
・・・ってことは最初からやりなおし！？
トホホ・・・
岩

岩
岩

岩
岩

S

岩

岩

岩

岩

©SQUARE-ENIX 2011

岩

岩

岩

岩

岩
岩

岩

岩

岩

岩

岩

岩

岩

岩

岩

岩

岩

岩

岩

岩

岩

岩

岩 岩

岩

岩

岩

岩
岩

岩

岩

140

岩

岩 岩

岩

岩

道

岩

岩

岩

岩
岩

岩
岩

岩

岩

岩

岩
岩

岩

岩

岩

岩
岩

岩
岩

岩

岩

岩

岩

©SQUARE-ENIX 2011

岩
岩

岩

岩

岩

岩

岩

岩

岩

岩

G

岩

↑実はこっちが正解

岩

岩

岩

岩

岩

S

岩

岩

岩

岩

岩

道

道

岩
岩

岩

岩

岩

岩

岩 岩

岩

岩

岩

岩
岩

岩

岩

141

岩

岩 岩

岩

岩

道

岩

岩

岩

岩

岩

岩

岩

岩

岩

岩

岩

岩

岩

岩
最初から地図を入手して岩
岩
岩
おけばこんなことには
岩
岩
岩
岩
岩
ならなかったのですが・・・
岩
岩
岩
岩
岩

岩

岩
岩

岩
岩

岩

岩

岩

岩

岩
岩

S

岩

岩

岩

岩

岩

岩

G

道

道

岩
岩

岩

岩

©SQUARE-ENIX 2011

岩

岩

岩 岩

岩

岩

岩

岩
岩

岩

岩

142

岩

岩 岩

岩

岩

道

岩

岩

岩

岩

岩

岩

岩

G

道

道

岩
岩

岩

岩

岩

岩

岩

岩

プロジェクトは目先だけを見て岩
岩
岩
岩
行き当たりばったりで歩いていても岩
岩
岩岩
ダメなのです。
岩
岩
岩
岩

岩

岩

岩

岩

岩

しっかりと地図（調査・戦略・設計・計画）
岩
岩
岩 岩
岩
岩
を用意して歩むべきなのです。
岩 岩
岩

岩

S

岩

岩

岩

岩

岩

岩

岩

©SQUARE-ENIX 2011

岩

岩

岩

岩
岩
岩
岩

岩

岩

岩

143

超高層ビル

こんな例や©SQUARE-ENIX 2011

144

G
岩

こんな例からも岩
岩

岩©SQUARE-ENIX 2011

岩
岩
岩
岩

145

調査・戦略・設計・計画の重要性が示されています©SQUARE-ENIX 2011146

ソフトウェア開発だけが特別なのでしょうか？
本当に調査・戦略・設計・計画を軽視してソフトウェア開発はできるのでしょうか？
©SQUARE-ENIX 2011147

調査・戦略・設計・計画なしで一定サイズ以上のソフトウェアを作ることは極めて危険です©SQUARE-ENIX 2011148

調査・戦略・設計・計画から逃げてはいけないのです！

©SQUARE-ENIX 2011149

当たり前の準備を
地道にやる©SQUARE-ENIX 2011150

それが不確実性を乗りこなす秘訣です©SQUARE-ENIX 2011151

不確実性を乗りこなす• 事前対策（調査・戦略・設計・計画）– 不確実性を減らす• 見通しが悪い部分の調査や検証/実験をしっかりと行う• 作業データを取り、フィードバックをかけて予測精度を向上させる• 計画規模を小さくする– どうせ計画は膨らむのだから最初に目いっぱいコンパクトにする• 設計をなるべく詳細に行う• リスクの高い要素を予め極力減らす– 不確実でも良い事にする• リスクの高い要素を無くしてても成立する設計にする– その要素が無くなっても商品の価値が下がらない設計にする» トカゲのしっぽとしていつでも切れるようにする• 事後対策（イテレーション）– 変化や問題発生にすばやく気づく– 変化や問題にすばやく対応する©SQUARE-ENIX 2011152

いきなり歩くのは危険です©SQUARE-ENIX 2011

153

確かに
慎重に歩けば（イテレーション）
足元の石ころで転ぶことは避けられるかもしれません©SQUARE-ENIX 2011154

しかし、目先だけを見ていては行く手に行き止まりや落とし穴
やモンスターや山や渓谷が存在することに直前までなかなか気づけません©SQUARE-ENIX 2011155

足元（ショートレンジ）も
遠くの行く手（ロングレンジ）もちゃんと見て歩かないとゴールには無事たどり着けないのです©SQUARE-ENIX 2011

156

だから

地図（設計）や双眼鏡（計画）を予め用意して、不測の事態を事前に避けたり、もし事前に避けられなくてもそれに気づき易く、対策し易くする
事前準備をしましょう©SQUARE-ENIX 2011

157

地図や双眼鏡を作ってから歩き出しましょう©SQUARE-ENIX 2011

158

そして
その地図や双眼鏡は常にメインテナンスしましょう※地図や双眼鏡のメインテナンスは大きなＰＤＣサイクルと言えます©SQUARE-ENIX 2011159

不確実性を乗りこなす• 事前対策（調査・戦略・設計・計画）– 不確実性を減らす• 見通しが悪い部分の調査や検証/実験をしっかりと行う• 作業データを取り、フィードバックをかけて予測精度を向上させる• 計画規模を小さくする– どうせ計画は膨らむのだから最初に目いっぱいコンパクトにする• 設計をなるべく詳細に行う• リスクの高い要素を予め極力減らす– 不確実でも良い事にする• リスクの高い要素を無くしてても成立する設計にする– その要素が無くなっても商品の価値が下がらない設計にする» トカゲのしっぽとしていつでも切れるようにする• 事後対策（イテレーション）– 変化や問題発生にすばやく気づく– 変化や問題にすばやく対応する©SQUARE-ENIX 2011160

事前対策も事後対策も両方やることに意味があるのです
片方だけでは機能不全です©SQUARE-ENIX 2011161

極めてシンプルな話なのです©SQUARE-ENIX 2011162

しっかり準備、段取りしてしっかりイテレーションしましょう©SQUARE-ENIX 2011163

ウォーターフォールｖｓ
アジャイルというような見方をついしてしまいがちですが©SQUARE-ENIX 2011164

ウォーターフォールｖｓ
アジャイル
対立構図は好ましくありません©SQUARE-ENIX 2011165

ウォーターフォール×
アジャイル©SQUARE-ENIX 2011166

ウォーターフォール×
アジャイル
それぞれの持ち味を生かしましょう©SQUARE-ENIX 2011167

ウォーターフォール派とかアジャイル派
といったように表面上の型やイメージや定義にふりまわされるのはやめて、
プロジェクトマネジメントの本質を捉えてハイブリッド型の良いとこ取りの方法でバランス良く行きましょう©SQUARE-ENIX 2011168

一旦まとめます©SQUARE-ENIX 2011

169

一旦のまとめ• プロジェクトには当初に予想しきれないほど大きな不確実性が潜んでいる• 従って不確実性とうまく付き合う必要がある• イテレーションを重視しよう– こまめなPlan-Do-Checkサイクルで、不確実性から生まれる問題の早期発見と早期解決を繰り返そう• 調査・戦略・設計・計画からは逃げない– 不確実性を下げ、見通しを良くするための地図を準備しよう– それらはなるべくドキュメント化しよう©SQUARE-ENIX 2011

170

さて、概念論はこれくらいにしてもう尐し具体的な話に降りて行きます©SQUARE-ENIX 2011171

プロジェクトマネジメントの手順©SQUARE-ENIX 2011172

プロジェクトマネジメントの手順
1.
2.
3.
4.

調査する
戦略を立てる（リスク一覧/開発戦略マトリクス/価値空間）設計する
計画する（中長期計画）
①
②
③
④

5.

タスクを洗い出す（ユーザーストーリー/フィーチャー/タスク/ＬＯＤ式タスク分解）
見積もる（２点見積もり/見積もりポーカー/ＬＯＤ式見積もり）
優先度を決める
マイルストーンを定める

スプリント（４週間単位の制作イテレーション）
–
①
②
③
④
⑤

階層化ＰＤＣ
スプリント計画（成果物目標/スプリント計画会/タスク管理シート）
日々の制作（朝会/タスク管理ボード）
週の振り返り（週報/週定例）
スプリントの振り返り（スプリント報/スプリント振り返り会/成果物発表会）
対策・再計画•••⑥

戦略・設計の修正（ゲーム仕様、アート、プログラム設計などの修正）
中長期計画の修正（タスクの追加・変更、見積もりの変更、優先度の変更）
リソースの修正（人員の追加や担当変更など）

クライアントや上司への報告©SQUARE-ENIX 2011173

プロジェクトマネジメントの手順
1.
2.
3.
4.

調査する
「プロジェクトの立案」や「コンセプトワーク」などは戦略を立てる（リスク一覧/開発戦略マトリクス/価値空間）
状況によって１～２のどこかで行うことが多いと思います。今回は触れません。
設計する
計画する（中長期計画）
①
②
③
④

5.

タスクを洗い出す（ユーザーストーリー/フィーチャー/タスク/ＬＯＤ式タスク分解）
見積もる（２点見積もり/見積もりポーカー/ＬＯＤ式見積もり）
優先度を決める
マイルストーンを定める

スプリント（４週間単位の制作イテレーション）
–
①
②
③
④
⑤

階層化ＰＤＣ
スプリント計画（成果物目標/スプリント計画会/タスク管理シート）
日々の制作（朝会/タスク管理ボード）
週の振り返り（週報/週定例）
スプリントの振り返り（スプリント報/スプリント振り返り会/成果物発表会）
対策・再計画•••⑥

戦略・設計の修正（ゲーム仕様、アート、プログラム設計などの修正）
中長期計画の修正（タスクの追加・変更、見積もりの変更、優先度の変更）
リソースの修正（人員の追加や担当変更など）

クライアントや上司への報告©SQUARE-ENIX 2011174

プロジェクトマネジメントの手順
1.
2.
3.
4.

調査する
戦略を立てる（リスク一覧/開発戦略マトリクス/価値空間）設計する
計画する（中長期計画）
①
②
③
④

5.

タスクを洗い出す（ユーザーストーリー/フィーチャー/タスク/ＬＯＤ式タスク分解）
見積もる（２点見積もり/見積もりポーカー/ＬＯＤ式見積もり）「プロジェクトの立案」や「コンセプトワーク」は優先度を決める 状況によって１～２のどこかで行うことが多い
マイルストーンを定めると思います。今回は触れません。

今回は主にこの二つにフォーカス

スプリント（４週間単位の制作イテレーション）
–
①
②
③
④
⑤

階層化ＰＤＣ
スプリント計画（成果物目標/スプリント計画会/タスク管理シート）
日々の制作（朝会/タスク管理ボード）
週の振り返り（週報/週定例）
スプリントの振り返り（スプリント報/スプリント振り返り会/成果物発表会）
対策・再計画•••⑥

戦略・設計の修正（ゲーム仕様、アート、プログラム設計などの修正）
中長期計画の修正（タスクの追加・変更、見積もりの変更、優先度の変更）
リソースの修正（人員の追加や担当変更など）

クライアントや上司への報告©SQUARE-ENIX 2011175

プロジェクトマネジメントの手順
1.
2.
3.
4.

調査する
戦略を立てる（リスク一覧/開発戦略マトリクス/価値空間）設計する
計画する（中長期計画）
①
②
③
④

5.

タスクを洗い出す（ユーザーストーリー/フィーチャー/タスク/ＬＯＤ式タスク分解）
見積もる（２点見積もり/見積もりポーカー/ＬＯＤ式見積もり）
優先度を決める
マイルストーンを定める

スプリント（４週間単位の制作イテレーション）
–
①
②
③
④
⑤

階層化ＰＤＣ
スプリント計画（成果物目標/スプリント計画会/タスク管理シート）
日々の制作（朝会/タスク管理ボード）
週の振り返り（週報/週定例）
スプリントの振り返り（スプリント報/スプリント振り返り会/成果物発表会）
対策・再計画•••⑥

戦略・設計の修正（ゲーム仕様、アート、プログラム設計などの修正）
中長期計画の修正（タスクの追加・変更、見積もりの変更、優先度の変更）
リソースの修正（人員の追加や担当変更など）

クライアントや上司への報告©SQUARE-ENIX 2011176

調査する①• すべての起点となります• 例えば– 市場動向を調査する– 最新技術動向を調査する– スタッフのスキルセットを調査する– 会社の財務状況を調査する– リスク要因を調査する– 他プロジェクトの状況を調査する– 過去のプロジェクトの予算と実績を調査する※各国の経済状況予測までしないとならない時代に突入したかもしれません©SQUARE-ENIX 2011

177

調査する②• 戦略や設計や計画や制作をスムーズに進め、
なるべく手戻りを少なくするためにとても大切
なアクションです• 類似商品を発掘し尽くし、それらを徹底的に要素分解することも含まれます• リスクを減らすために出来る限りの調査をしましょう• 今回は調査の話は軽めに終えます©SQUARE-ENIX 2011178

プロジェクトマネジメントの手順
1.
2.
3.
4.

調査する
戦略を立てる（リスク一覧表/開発戦略マトリクス/価値空間）設計する
計画する（中長期計画）
①
②
③
④

5.

タスクを洗い出す（ユーザーストーリー/フィーチャー/タスク/ＬＯＤ式タスク分解）
見積もる（２点見積もり/見積もりポーカー/ＬＯＤ式見積もり）
優先度を決める
マイルストーンを定める

スプリント（４週間単位の制作イテレーション）
–
①
②
③
④
⑤

階層化ＰＤＣ
スプリント計画（成果物目標/スプリント計画会/タスク管理シート）
日々の制作（朝会/タスク管理ボード）
週の振り返り（週報/週定例）
スプリントの振り返り（スプリント報/スプリント振り返り会/成果物発表会）
対策・再計画•••⑥

戦略・設計の修正（ゲーム仕様、アート、プログラム設計などの修正）
中長期計画の修正（タスクの追加・変更、見積もりの変更、優先度の変更）
リソースの修正（人員の追加や担当変更など）

クライアントや上司への報告©SQUARE-ENIX 2011179

戦略を立てる• 細かな設計や計画に入る前に、担当プロジェクトの開発戦略を入念に考えることで後々のリスクを最小化します– 「リスク一覧表」の作成（調査フェイズで終わっていることが理想）– 「開発戦略マトリクス」を参考に意志決定を予め行う– 「商品の価値空間」を意識して、プロジェクトに本当に必要な要素は何かをしっかり考える• ゲームデザイン、アートワーク、プログラム、サウンド他、すべての項目が対象です©SQUARE-ENIX 2011180

リスク一覧表
項目

難易度

重要度

警戒度
(難×重)

対策案

責任者

○○機能

２

４

８

・・・

Ａさん

△△システム

５

５

２５

・・・

Ｂさん

村

３

２

６

・・・

Ａさん

・・・

・・・

・・・

・・・

・・・

・・・

・・・

•
•
•

さまざまな事前調査を受けて、案件別に難易度と重要度のスコアをつけてみます
難易度と重要度のスコアを掛けたものを警戒度とします
警戒度が高いものを中心に予め入念に対策を練っておきます•••

代替案を用意してでも絶対になにかを実現するのか、最悪切り捨てても問題ないのか、
いつ、どうやって「安全化」するのかを考えます
対策責任者も明確にします
ゲームデザイン、アートワーク、プログラム、すべてが対象です©SQUARE-ENIX 2011

181

開発戦略マトリクス
難易度

低

難

必ず作れる要素

おそらく作れる要素

作ってみないと不明

必要な要素

・優先度中★★★
・迷わず作る・他に影響を与えないのならば、むしろ後回しでもＯＫ

・優先度高★★★★
・できるだけ早期に検証・実験する

・優先度最高★★★★★
・最優先で検証・実験し、バックアッププランを用意

できれば欲しい要素

・優先度低★★

・優先度中★★★
・優先的に検証・実験するかどうかを早期に決める・優先度を下げる場合は切り離し可能な状態を維持してゆとりの人員と時間で挑戦・優先度低★★
・なるべく作らない
・作る場合は切り離し可能な状態を維持してゆとりの人員と時間で挑戦無くても困らない要素

・優先度最低★
・人員や時間にとても余裕があったら後で作る・優先度最低★
・なるべく作らない
・とても余裕があったら挑戦してみても良い・優先度×・作ってはならない

重要度

高

易

※あくまで概念の紹介として記載していますので各方針や優先度の記述は例として捉えてください※いろいろな事情や戦略によっては優先度は変化します©SQUARE-ENIX 2011

182

開発戦略マトリクス• 必ず作れる物、たぶん作れる物、やってみな
いと出来るかどうか分からない物などに分類します• 本当に必要な物、できれば欲しいもの、無くても困らない物などに分類します• マトリクスを参考に、やること、やらないこと、
バックアッププラン、優先順位などを決めます• ゲームデザイン、アートワーク、プログラム、
すべてが対象です©SQUARE-ENIX 2011183

商品の価値空間• 通常は価値＝質×量と簡単なモデル化をすることがありますが、本手法では価値＝基本要素数×品質×物量と設定します©SQUARE-ENIX 2011184

商品の価値空間•

品質(高さ)
–
–
–
–
–
–
–
–

•

品質

基本要素数(幅)
–
–
–
–
–
–
–
–
–
–

•

面白さ
操作性
映像の美しさ、カッコよさ
魅力的な世界観と登場キャラクター
物語の展開
エピックな体験快適さ
分かりやすさアクションパート
タウンパートミニゲームパート
収集、効果
育成
イベント
オンライン
メニュー
技術チャレンジ○○システム

物量(奥行き)
–
–
–
–

ステージ数
エネミーの種類
武器の種類
イベントの数

基本要素数※各軸は完全な直交性はありませんが、概念の理解の為にあえて分離しています※体積が大きいからといって必ずしも価値が高いとは限らないですが、目安として見てください©SQUARE-ENIX 2011185

商品の価値空間•

基本要素数（幅）– 純粋な物量を取り除いた、基本要素の種類数を指します– 敵、ボス、空を飛ぶ、コンボシステム、時間の変化、天候の変化、オープンワールド、カット
シーン、などの単位です– 面白さ、或いは技術面でなにかしら乗り越えないとならないものが多く含まれ、通常このファクターにリスクが集中します– 質でもあり量でもある部分です– 不確実性を減らす場合に最も効果を発揮するポイントであり、ここの種類を減らすことでスケジュールの見通しは立ちやすくなります– 「ほんとうにその基本要素は必要なのか？」という問いをプロジェクト初期に真剣に行いましょう•

品質（高さ）– 基本要素に対しての質です– 基本要素の構築を乗り越えていれば、単純に作り込みによって高まるファクターです– コントロールしやすい要素です•

物量（奥行き）– 基本要素に対しての量産の数です– 基本要素の構築を乗り越えていれば、単純に時間や人数によって増やせるファクターです– コントロールしやすい要素です©SQUARE-ENIX 2011

186

戦略を立てる• これらの考え方や他の考え方などを組み合
わせてリスク分析、価値分析、状況分析などをして開発戦略を立てます• 今回は戦略の話は軽めに終えます©SQUARE-ENIX 2011187

プロジェクトマネジメントの手順
1.
2.
3.
4.

調査する
戦略を立てる（リスク一覧/開発戦略マトリクス/価値空間）設計する
計画する（中長期計画）
①
②
③
④

5.

タスクを洗い出す（ユーザーストーリー/フィーチャー/タスク/ＬＯＤ式タスク分解）
見積もる（２点見積もり/見積もりポーカー/ＬＯＤ式見積もり）
優先度を決める
マイルストーンを定める

スプリント（４週間単位の制作イテレーション）
–
①
②
③
④
⑤

階層化ＰＤＣ
スプリント計画（成果物目標/スプリント計画会/タスク管理シート）
日々の制作（朝会/タスク管理ボード）
週の振り返り（週報/週定例）
スプリントの振り返り（スプリント報/スプリント振り返り会/成果物発表会）
対策・再計画•••⑥

戦略・設計の修正（ゲーム仕様、アート、プログラム設計などの修正）
中長期計画の修正（タスクの追加・変更、見積もりの変更、優先度の変更）
リソースの修正（人員の追加や担当変更など）

クライアントや上司への報告©SQUARE-ENIX 2011

188

設計する①• 計画や制作をスムーズに進め、なるべく手戻りを少なくするためにとても大切なアクションです• 例えば– ゲーム仕様を設計する– キャラクターや背景のアートワークを用意する– 世界観設定を用意する– シナリオのプロットを考える– 技術戦略を考える– プログラム設計をする©SQUARE-ENIX 2011189

設計する②• 原則、頭の中で想像の出来得る限りは設計をとことん行い、思考検証し、設計を洗練させます• 作らずとも頭の中で分かることはまず先に設計し尽くすべきです• 実際に作って物にしてみないと分からないことがあって初めて「設計のための仮実装（＝実験）」を行
うべきです©SQUARE-ENIX 2011190

設計する③• ひとり～数人で数カ月で作るゲームならほぼ無計画に作ってもさほど問題無いでしょう。
• しかし、数十人～数百人、年単位で作るゲームで基本設計が固まっていないままプロジェクトを本格稼働させるのは大変危険です• 特にゲーム仕様、技術仕様は早期に固めましょう• 今回は設計の話は軽めに終えます©SQUARE-ENIX 2011191

プロジェクトマネジメントの手順
1.
2.
3.
4.

調査する
戦略を立てる（リスク一覧/開発戦略マトリクス/価値空間）設計する
計画する（中長期計画）
①
②
③
④

5.

タスクを洗い出す（ユーザーストーリー/フィーチャー/タスク/ＬＯＤ式タスク分解）
見積もる（２点見積もり/見積もりポーカー/ＬＯＤ式見積もり）
優先度を決める
マイルストーンを定める

スプリント（４週間単位の制作イテレーション）
–
①
②
③
④
⑤

階層化ＰＤＣ
スプリント計画（成果物目標/スプリント計画会/タスク管理シート）
日々の制作（朝会/タスク管理ボード）
週の振り返り（週報/週定例）
スプリントの振り返り（スプリント報/スプリント振り返り会/成果物発表会）
対策・再計画•••⑥

戦略・設計の修正（ゲーム仕様、アート、プログラム設計などの修正）
中長期計画の修正（タスクの追加・変更、見積もりの変更、優先度の変更）
リソースの修正（人員の追加や担当変更など）

クライアントや上司への報告©SQUARE-ENIX 2011192

計画の手順① タスクを洗い出す② 見積もる③ 優先度を決める④ マイルストーンを定める©SQUARE-ENIX 2011193

計画の手順① タスクを洗い出す② 見積もる③ 優先度を決める④ マイルストーンを定める©SQUARE-ENIX 2011194

計画の手順① タスクを洗い出すA) ユーザーストーリーの列挙
B) フィーチャーに分解C) タスクに分解② 見積もる③ 優先度を決める④ マイルストーンを定める©SQUARE-ENIX 2011195

ユーザーストーリーとは①•••

そのソフトウェア（ゲーム含む）で実現したいことを「文章で」表現したものです
ユーザーストーリーと図解を組み合わせて「仕様書」としても良いです
例
–
–
–

–
–
–
–

１００ｋｍ四方のフィールドを自由に散策できる
プレイヤーも敵も建物を破壊することができるプレイヤーはライフがゼロになったら死んでリスタートポイント
で復帰できる
敵キャラクターは５０人同時に画面に登場する
プレイヤーはほふく前進をして、狭い隙間をくぐりぬけることができる
煙がキャラクターをよける動きをする
スイッチを踏んだらドアが開く©SQUARE-ENIX 2011196

ユーザーストーリーとは②• とにかく実現したいこと、すべきことを漏らさず洗いつくすことに注力します• マインドマップソフトを活用するのがオススメです• 複数人で宿題でユーザーストーリーを洗い出したマインドマップを持ち寄って、大きなマ
インドマップを作ると漏れを少なくしやすいです©SQUARE-ENIX 2011197

ユーザーストーリーとは③••••次のステップのフィーチャーを列挙する手掛かりとなるのがユーザーストーリーです
このユーザーストーリーの範囲こそがスコープ（作る範囲）となります
制作が進んできた際の品質のガイドラインともなります
ユーザーストーリーが大量に漏れていた場合、後で大きな手戻りが発生する可能性があるので極力最終形の８割ほどは網羅することを目標に洗い出します©SQUARE-ENIX 2011198

ユーザーストーリーとは④• 書物によっては「重なり合わないこと」とありますが、重なり合うことは寧ろアリと考えます• 漏れが無いことを重視します
ストーリー
ストーリー

重なり歓迎！
©SQUARE-ENIX 2011199

フィーチャーとは①••••制作する機能や対象を意味します
ユーザーストーリーを分解することで列挙します○○機能、○○システムなどの「名詞で終わる」事が
多いです
例
–
–
–
–
–

ライン描画機能
プレイヤーのジャンプ
プレイヤーのほふく前進
炎攻撃
メモリ管理システム©SQUARE-ENIX 2011200

フィーチャーとは②• 「大きなタスク」と言っても良いです• 別々のストーリーを分解してみると、その重なりから同じフィーチャーが出てくることは普
通です
ストーリー

ストーリー
ストーリー

分解
フィーチャー

フィーチャー

フィーチャー

フィーチャー©SQUARE-ENIX 2011

フィーチャー

フィーチャー

フィーチャー201

タスクとは• 各メンバーが作業を行う管理単位です• フィーチャーを分解した物です• １日あたり１～２タスク程度のサイズまで分解します• 例– スコア表示のフェードイン、フェードアウト処理– ほふく前進モーション– ドアの開閉©SQUARE-ENIX 2011202

ストーリーとフィーチャーとタスク
ストーリー

ストーリー
ストーリー

分解

フィーチャー

フィーチャー

フィーチャー

フィーチャー

フィーチャー

タ
ス
ク

タ
ス
ク

タ
ス
ク

タ
ス
ク

タ
ス
ク

タ
ス
ク

タ
ス
ク

タ
ス
ク

タ
ス
ク

©SQUARE-ENIX 2011

タス
ク

フィーチャー

タ
ス
ク

タ
ス
ク

タ
ス
ク

タ
ス
ク

203

ストーリーとフィーチャーとタスク
ただ、いきなりプロジェクトの隅か
ストーリー
ストーリー
ら隅まですべてのストーリーをタス
ストーリー
クレベルまで分解するのはとっても分解
しんどいので・・・
フィーチャー

フィーチャー

フィーチャー

フィーチャー

フィーチャー

タ
ス
ク

タ
ス
ク

タ
ス
ク

タ
ス
ク

タ
ス
ク

タ
ス
ク

タ
ス
ク

タ
ス
ク

タ
ス
ク

©SQUARE-ENIX 2011

タス
ク

フィーチャー

タ
ス
ク

タ
ス
ク

タ
ス
ク

タ
ス
ク

204

LOD的分解で時間効率を上げる
近い

遠い

作業順

荒い

ストーリー

ストーリー
ストーリー

分解

細かい

フィーチャー

フィーチャー

フィーチャー

タ
ス
ク

タ
ス
ク

タ
ス
ク

タ
ス
ク

タ
ス
ク

フィーチャー

フィーチャータス
ク©SQUARE-ENIX 2011

205

LOD的分解で時間効率を上げる
近い

遠い

作業順

荒い

ストーリー

ストーリー
ストーリー

分解

細かい

フィーチャー

フィーチャー

フィーチャー

タ
ス
ク

タ
ス
ク

タ
ス
ク

タ
ス
ク

タ
ス
ク

フィーチャー

フィーチャー

タ
ス
ク

数か月
半年程度
１年～
©SQUARE-ENIX 2011206

計画の手順① タスクを洗い出す
A)
B)
C)
–

ユーザーストーリーの列挙
フィーチャーに分解
タスクに分解
LOD式タスク分解② 見積もる③ 優先度を決める④ マイルストーンを定める©SQUARE-ENIX 2011207

計画の手順① タスクを洗い出す
A)
B)
C)
–

ユーザーストーリーの列挙
フィーチャーに分解
タスクに分解
LOD式タスク分解② 見積もる–––

２点見積もり見積もりポーカー
LOD式見積もり③ 優先度を決める④ マイルストーンを定める©SQUARE-ENIX 2011

208

見積もり
•
•

列挙したタスク群に対してそれぞれ何日かかるのかを見積もりします
以下の見積もりのテクニックを用います–––

２点見積もり見積もりポーカー
ＬＯＤ式見積もり©SQUARE-ENIX 2011209

２点見積もり•

通常は作業日数をひとつだけ予想する「１点見積もり」を行うケースが多いですが、本手法では二つの日数を予想する「２点見積もり」という方法を行います•○時間～○時間、あるいは○日～○日と二つの数字で表現します•

２点見積もりは心理力学の観点で非常に効果的でモチベーションの維持に向いていますし、分析時にも大変役に立ちます©SQUARE-ENIX 2011210

１点見積りと２点見積もり
４日
予想

開始

開始

３日
予想

©SQUARE-ENIX 2011

１点見積もり５日
予想

２点見積もり211

１点見積りの問題点• １点見積もりはメジャーな方法ですが、問題や欠点が多いです• 具体的には以下の悪い現象が発生します– 定義のあいまいさ– パーキンソンの法則– 学生症候群– のど元過ぎれば熱さ忘れるの法則©SQUARE-ENIX 2011212

定義のあいまいさ• １点見積もりで「４日」という予想があったとして、定義があいまい故にその「４日」の意味が人によって異なってしまいます– ある人は４日で出来上がるかどうか、実際に必要な日数と同じかそれよりも小さめのギリギリの日数を見積もります– 別の人は本当は３日で終わると思っているのですが安全をみてプラス１日して４日と見積もります– あるいは１日で終わると思っているのに４日という人もいるかもしれません• 定義があいまいなことで– 皆から集めた見積もりの一覧の精度は大変荒いものになってしまいます– 元々の意味がバラバラなので、進捗管理を行う際に消化日数の意味も不明になり、数値からリスクを読み取ることが難しくな
ります©SQUARE-ENIX 2011213

パーキンソンの法則• 「仕事は、その遂行のために利用できる時間をすべて埋める
ように拡大する」という現象• ４日という１点見積もりをしていて、２日で片付いてしまったとしても、完了報告をせずにのんびり過ごしたり、ギリギリまで必要以上の作業をしてしまうタイプの人がいます• なのでバッファを積んでも積んでも消費しつくしてしまいます©SQUARE-ENIX 2011214

学生症候群/夏休みの宿題病••

時間に余裕がある場合に作業の開始をギリギリまで遅らせてしまう性質の事を言います
典型パターン– 「５日」と１点見積もりしたとして、実はそのうち２日をバッファとして想定していたとします– この人は３日もあれば作業が終わると思っているので（人によっては）最初の２日はダラダラ過ごします– 残り３日となって「そろそろ本気出す！」と気合を入れ始めます––

ところが３日という事前予想が当たる事の方が珍しいわけで、結構な確率で３日よりも日数が必要になります
結果当初の見込みの５日よりも時間が必要になってしまいます

１００％

やる気

そろそろ
本気出す！
まだ余裕
ダラダラ

遅れちゃったよ
トホホ・・・

あれ・・・
間に合わないかも

３日間

開始

５日
©SQUARE-ENIX 2011

１点見積もり215

のど元過ぎれば熱さ忘れるの法則••

一旦スケジュールに間に合わないことが分かると集中力が落ちてしまう性質の事です
典型パターン– さきほどの学生症候群と同じ図で説明します–「そろそろ本気出す！」と気合モードに入ってから、その気合いは「このままでは見積もり日程内に収
まらない・・・」と途中で判明するまでは維持できるケースが多いのですが、間に合わないと一旦判明してしまうと「どうせ間に合わないのは一緒」となってしまい、１日でも半日でも１時間でも急ごうとする
気持ちが萎えてペースが落ちてしまう現象が（人によっては）発生します
どうせ間に合わないし６日になろうが７日になろうが
５０歩１００歩だ

１００％

やる気

もういいや・・・

そろそろ
本気出す！
まだ余裕
ダラダラ
あれ・・・
間に合わないかも遅れちゃったよ
トホホ・・・
やる気ダウン

３日間

開始

５日©SQUARE-ENIX 2011

１点見積もり216

１点見積りの問題点• １点見積もりには以下のような問題点がありました– 定義のあいまいさ– パーキンソンの法則– 学生症候群– のど元過ぎれば熱さ忘れるの法則©SQUARE-ENIX 2011217

１点見積りの問題点• １点見積もりには以下のような問題点がありました– 定義のあいまいさ– パーキンソンの法則– 学生症候群– のど元過ぎれば熱さ忘れるの法則

なんと２点見積りではこれらを心理力学として解消できます！
©SQUARE-ENIX 2011218

２点見積もり最大見積もり最小見積もり

開始

０％

バッファ

３日
予想

【最小見積もり】・出来るか出来ないかギリギリの挑戦
的な日数
・達成確率２０％（１０個タスクがあった
ら２個くらいは達成する）

１００％

５日
予想

【バッファ】
・最大見積もりー最小見
積もり＝バッファと定義します
・最小見積もりで完了した
ら見積もり精度＝０％、最大見積もりで完了した
ら見積もり精度＝１００％とし、見積もり精度＝５０％が優秀な見積もりと定義します【最大見積もり】・これを超えたら恥ずかしい日数
・達成確率８０％（１０個タスクがあったら８個くらいは達成する）©SQUARE-ENIX 2011219

２点見積りのメリット• ２点見積もりは１点見積もりの欠点を補います– 定義のあいまいさ⇒ＯＫ• 最小見積もり、最大見積もりという定義が入るので、個人による解釈の差が生まれにくいです– パーキンソンの法則⇒ＯＫ• 「見積もり精度」がタスク毎に表現されるので、タスクが片付いたらそのタスクをいつまでも抱えることなく、さっさと次のタスクを開始することに喜びを感じます– 学生症候群⇒ＯＫ• 一般的に、難しいのが分かっていても人は最小見積もりを目指す傾向があるので、いきなりアクセル全開で作業を開始してくれます– のど元過ぎれば熱さ忘れるの法則⇒ＯＫ• 最小見積もりを超えるのは普通の事ですが、例え最小見積もりを超えてもさらに最大見積もりという「超えたら恥ずかしい、絶対に死守したい防衛ライン」が控えているので、引き続き心が萎える事無くアクセル全開状態を維持できます©SQUARE-ENIX 2011220

２点見積りのメリット•

２点見積もりは、１点見積もりの数々の欠点を解消します
学生症候群対策
最小見積もりを達成させたいから
がんばっちゃうぞ！

喉元過ぎれば…対策
最小見積もり達成は無理っぽいな・・・
でも最大見積もりは絶対に超えないぞ！

パーキンソンの法則対策

１００％

無事に終わった～！
さあ次のタスクをやろう！

やる気

開始

最小見積もり３日
予想©SQUARE-ENIX 2011５日
予想

最大見積もり221

２点見積りのメリット•

心理作用により、同じ能力、同じ性格の人が作業をしても、１点見積もりを採用す
るか、２点見積もりを採用するかで全く結果が異なってしまうのです
２点見積もりの
やる気推移

１点見積もりの
やる気推移

１００％

やる気

開始

最小見積もり３日
予想©SQUARE-ENIX 2011５日
予想

最大見積もり222

３点見積りではだめなのか• 「最小見積り」「最大見積り」「目標見積り」という３つの日数を予想し、加重平均により完了確率の高い予測日を算出する方法があります• ３点見積もりを行うと、 心の中で「目標見積り」の日数、或いは加重平均日の存在が大きくなり、そこに意識がフォーカスされ、心理的には実質１点見積もりを行っているのと同じ状態に陥り易くなります• 手間が増える割に得よりも損の方が大きいと考えています©SQUARE-ENIX 2011223

見積もりポーカー①
•
•

•
•

見積もりを行う際には見積もりポーカーというものを使います
見積もるタスクリストの作業担当者、その同僚、上司などの３人ほどで集まって、タスクリストの各タスクを見積もることで、精度の向上と、タスクの相互理解を促します
やってみるとわかりますが面白いです（聞くのとやるのとでは違います、実際にやってみてください）
世間的には１枚のカードを場に出すのが普通ですが、私達の手法では最小、最大の２枚のカードを場に出します©SQUARE-ENIX 2011224

見積りポーカー②
•
•
•
•
•
•
•
•
•
•
•

無地のトランプを使って見積り専用のカードを作成する（雑貨屋の手品師コーナーなどで買えます）
見積りは３人程度で行う（担当者と同僚と上司など）見積りを行うタスクリストを用意する
タスクリストから見積りをするタスクを選ぶ
タスクの内容を見積りメンバー間で誤解の無いように確認する
それぞれでそのタスクに何日必要か考える「せーの」でそれぞれ最小見積り日数と最大見積り日
数のカードを２枚出す
食い違った場合はなぜその見積りなのかを互いに説明し合う
カードをそれぞれ回収
見積りがすり寄るまで繰り返す（だいたい２～３周ですり寄る）
タスクリストのタスクすべてが見積られるまで繰り返す©SQUARE-ENIX 2011225

見積もりもLOD式で• 見積もりも、タスク分解と同様にいきなりすべての詳細なタスクに対して見積もり作業を行うと日が暮れてしまうので、うまく省略しな
がら行います• 近い作業はタスクのレベルで見積もり、遠い
タスクはフィーチャーやストーリーのレベルで見積もりをします• 詳しくは別の機会にでも©SQUARE-ENIX 2011226

計画の手順① タスクを洗い出す
A)
B)
C)
–

ユーザーストーリーの列挙
フィーチャーに分解
タスクに分解
LOD式タスク分解② 見積もる–––

２点見積もり見積もりポーカー
LOD式見積もり③ 優先度を決める④ マイルストーンを定める©SQUARE-ENIX 2011227

優先度を決める•

詳細なタスクが列挙され、それが見積もられているならば、それらのタスクの処理の優先度を決めればそれがスケジュール表となります•

実際にはユーザーストーリーの段階で優先度が付き、フィーチャーの段階で優先度が付き、タスクの段階で優先度が付き・・・と常時優先度付けをやっても良いと思います。

•

見積もりが先か優先度決めが先か、その都度状況で決めれば良いです©SQUARE-ENIX 2011228

計画の手順① タスクを洗い出す
A)
B)
C)
–

ユーザーストーリーの列挙
フィーチャーに分解
タスクに分解
LOD式タスク分解② 見積もる–––

２点見積もり見積もりポーカー
LOD式見積もり③ 優先度を決める④ マイルストーンを定める©SQUARE-ENIX 2011229

マイルストーンを定める•••

詳細な見積もりまで終わり、優先度も決まった状態であれば中長期計画が出来上がったと言えます
そこから主要なフィーチャーやユーザーストー
リーが出来上がる時期を特定し、マイルストー
ン表を作って分かりやすい目標として表現します
マイルストーンは「戦略フェイズ」などを行っている初期段階でもラフな状態で作っておくのが良いですが、改めて精度の高いマイルストーンとして調整します©SQUARE-ENIX 2011230

計画のまとめ① タスクを洗い出す
A)
B)
C)
–

ユーザーストーリーの列挙
フィーチャーに分解
タスクに分解
LOD式タスク分解② 見積もる–––

２点見積もり見積もりポーカー
LOD式見積もり③ 優先度を決める–

スケジュールの完成④ マイルストーンを定める©SQUARE-ENIX 2011

231

計画を終えて• この時点でプロジェクトがスケジュール的に破綻しているかどうかはほぼ分かります• 通常はどうにも破綻が現実の物となって初めて発覚しますから、なにも作業をしていな
いのに破綻が見つかった場合はむしろ喜ばしい事です• 改めて開発戦略を見直しましょう©SQUARE-ENIX 2011232

プロジェクトマネジメントの手順
1.
2.
3.
4.

調査する
戦略を立てる（リスク一覧/開発戦略マトリクス/価値空間）設計する
計画する（中長期計画）
①
②
③
④

5.

タスクを洗い出す（ユーザーストーリー/フィーチャー/タスク/ＬＯＤ式タスク分解）
見積もる（２点見積もり/見積もりポーカー/ＬＯＤ式見積もり）
優先度を決める
マイルストーンを定める

スプリント（４週間単位の制作イテレーション）
–
①
②
③
④
⑤

階層化ＰＤＣ
スプリント計画（成果物目標/スプリント計画会/タスク管理シート）
日々の制作（朝会/タスク管理ボード）
週の振り返り（週報/週定例）
スプリントの振り返り（スプリント報/スプリント振り返り会/成果物発表会）
対策・再計画•••⑥

戦略・設計の修正（ゲーム仕様、アート、プログラム設計などの修正）
中長期計画の修正（タスクの追加・変更、見積もりの変更、優先度の変更）
リソースの修正（人員の追加や担当変更など）

クライアントや上司への報告©SQUARE-ENIX 2011233

スプリントとは• ２週間あるいは４週間の固定期間（タイムボックス）で計画⇒実行⇒振り返りのイテレーションサイクルを回す単位です• 私達のプロジェクトでは４週間で運用しています– 必ず月曜日始まり、金曜日終わり– 祝日などもあるのでだいたい１８～２０営業日• スクラムというアジャイル系手法で使われている言葉を拝借しまし
たが内容はかなりアレンジされていますのでスクラムのそれとは別物と捉えてください• スプリント初日にその４週間分のタスクを中長期のタスクリスト（見積もり済み）から持って来ます• タスク分解や見積もりの粒度が荒い場合は各スプリントの計画時に詳細化します• スプリント最終日にはデータ分析などを行って振り返ります©SQUARE-ENIX 2011234

スプリントの構造©SQUARE-ENIX 2011235

再びＰＤＣ登場©SQUARE-ENIX 2011236

Plan-Do-Checkサイクル
すべての
基礎！

Plan
計画や対策を
考える

Check

Do

振り返る

実行する

©SQUARE-ENIX 2011237

本手法のスプリントでは
ＰＤＣを階層化して運用します©SQUARE-ENIX 2011238

階層化されたPlan-Do-Check
Plan

Plan

日

週

Check

Check

Do

週のDo
スプリントのDo

スプリント
Plan

Check

©SQUARE-ENIX 2011239

階層化ＰＤＣ• 各階層でＰＤＣのイテレーションを回します– 毎日の単位でＰＤＣ– 毎週の単位でＰＤＣ（Ｄの中身は毎日のＰＤＣ）– 毎スプリント（４週間）の単位でＰＤＣ（Ｄの中身は毎週のＰ
ＤＣ）• 階層化を進めることで、大きなサイクル、小さなサイ
クルいろいろな粒度での問題や計画からの乖離を早い段階で気付き、早い段階で計画の修正をかける事ができます©SQUARE-ENIX 2011240

スプリントの手順• 階層化ＰＤＣ① スプリント計画② 日々の制作
③ 週の振り返り④ スプリントの振り返り⑤ 対策・再計画⑥ クライアントや上司への報告©SQUARE-ENIX 2011241

スプリントの手順• 階層化ＰＤＣ① スプリント計画
–
–
–

成果物目標
スプリント計画会
タスク管理シート② 日々の制作
③ 週の振り返り④ スプリントの振り返り⑤ 対策・再計画⑥ クライアントや上司への報告©SQUARE-ENIX 2011242

スプリント計画• スプリントの初日にそのスプリントの計画を立てます• 丸１日スプリント計画で消費しても構いません• 手順
1. 成果物目標リストを整備します
2. 中長期計画からスプリントでこなせそうな分だけのタスクを持って来ます3. タスクの粒度が荒い場合は分解を行い、見積もりも分解後のタスクに対して行います
4. スプリントに入る分のタスクを判定し、成果物目標リ
ストを調整します©SQUARE-ENIX 2011

243

成果物目標• そのスプリントで達成したいユーザーストー
リーを“成果物”と見なします• ユーザーストーリーなので「○○が△△できる」という文章で表現します• スプリントの終わりにこの成果物目標がどれだけ達成出来たかどうかを振り返ります• 個人の成果物目標を束ねて班の成果物目標とします©SQUARE-ENIX 2011244スプリント計画会• ディレクターと各班の班長が集まって各班の成果物目標を提示し合って、中長期視点も考慮に入れてその成果物目標の設定で問題がないか確認し合う会議です• スプリント計画会で班の成果物目標が問題無いことが確認された後、各班長はそれを持ち帰り、班の各メンバーのタスク管理シートを整備します©SQUARE-ENIX 2011245

タスク管理シート• エクセル表で各スプリントのタスクを管理します• 見積もり精度、バッファー消費率、タスク列挙精度、他、様々な指標が算出されます©SQUARE-ENIX 2011246

スプリントの手順• 階層化ＰＤＣ① スプリント計画
–
–
–

成果物目標
スプリント計画会
タスク管理シート② 日々の制作
③ 週の振り返り④ スプリントの振り返り⑤ 対策・再計画⑥ クライアントや上司への報告©SQUARE-ENIX 2011247

スプリントの手順• 階層化ＰＤＣ① スプリント計画
–
–
–

成果物目標
スプリント計画会
タスク管理シート② 日々の制作––

朝会
タスク管理ボード③ 週の振り返り④ スプリントの振り返り⑤ 対策・再計画⑥ クライアントや上司への報告©SQUARE-ENIX 2011248

日々の制作• スプリント計画が終わった後は制作作業に入ります• 「タスク管理ボード」の前で「朝会」を行って日々のＰＤＣサイクルを回します©SQUARE-ENIX 2011249

タスク管理ボード• 朝会を行う場所です• スプリント期間中の全員分のタ
スクの進捗状況が管理されます（プロジェクトの人数が多い
場合は複数枚用意します）• 構成– そのスプリントで行うタスクを班別に貼る欄– その週で行うタスクを班別に貼る欄– 作業中のタスクを貼る欄– 完了したタスクを個人別に貼る欄©SQUARE-ENIX 2011250

付箋の使い方
最小見積り～最大見積り⇒実績

タスク名

Aボタンでプレイヤーがジャンプ
０．５日～１．５日⇒２．０日
５月１２日～１３日

見積もり精度（シールで表現）
緑：３０％以下
黄：３０～７０％
赤：７０％以上

山田

担当者

作業期間
•

付箋の色で意味を変えています
–
–
–
–

•

黄 スプリント計画時から存在するタスク（計画内タスク）
赤 タスクの分解がうまく行っておらず、スプリント中に増えてしまったタスク（計画外タスク）
緑 人からの依頼で増えたタスク（割り込みタスク）
青 時間が余ったので前倒しで行ったタスク（前倒しタスク）

付箋の色と付箋に貼るシールの色によって、タスク管理ボードの完了欄を見れば各自の状況が一目瞭然となります©SQUARE-ENIX 2011

251

朝会
•
•
•
•
•

タスク管理ボードの前で行います
朝会の班あたり５～８名を目安にしています
人数が増えたら班を分割します
朝会の班を「制作ユニット別」で組むか「スプリント毎にランダム」で組むかはプロ
ジェクトの特性や目的に応じて使い分けます
司会担当者が以下を仕切ります– 前日行った作業について問う•

作業が終わっていたら実績日数を記入、見積もり精度のシールを貼って、担当者別の完了欄に付箋を移動– 本日の作業について問う••

新規作業の場合は未着手の付箋を作業中の欄に移動
作業継続の場合は「残り何日」かかるかを宣言– 問題や課題がないか問う•••

一人あたり１～３分で、朝会の班あたり１０～１５分で終わらせます
ひとつのタスク管理ボードで数十名、８班程度まで管理しており、各班が順番に朝会を行います
月曜日はその週に行うタスクを「スプリント」の欄から「週」の欄に移動し、「週の計画」とします©SQUARE-ENIX 2011252

スプリントの手順•①

階層化ＰＤＣ
スプリント計画
–
–
–

②

日々の制作
–
–

③
④
⑤
⑥

成果物目標
スプリント計画会
タスク管理シート
朝会
タスク管理ボード

週の振り返りスプリントの振り返り
対策・再計画
クライアントや上司への報告©SQUARE-ENIX 2011253

スプリントの手順•①

階層化ＰＤＣ
スプリント計画
–
–
–

②

日々の制作
–
–

③

朝会
タスク管理ボード

週の振り返り
–
–

④
⑤
⑥

成果物目標
スプリント計画会
タスク管理シート

週報
週定例

スプリントの振り返り
対策・再計画
クライアントや上司への報告©SQUARE-ENIX 2011254

週の振り返り• 以下の二つを通して週の進捗を振り返ります
– 週報
– 週定例

©SQUARE-ENIX 2011

255

週報
• 各自にメールで全員宛で提出してもらいます• 「個人週報」と「制作ユニット週報」があります（右は個人週報のフォー
マット）©SQUARE-ENIX 2011

256

週定例
• 各制作ユニットのリーダーがユニットのメンバーを招集して、毎週金曜日に担当する班の進捗を確認します• 事前に個人週報を提出してもらって、それを元に状況を分析し、必要に応じて対策を講じます• その結果は班長からチーム全体に「制作ユニット週報」としてメールで送られます• ディレクターと各ユニットのリーダーが集まった「全体週定例」を別に行うケースもあります（プロジェクトの特性に応じて方針を変えています）©SQUARE-ENIX 2011257

スプリントの手順• 階層化ＰＤＣ① スプリント計画
–
–
–

成果物目標
スプリント計画会
タスク管理シート④ スプリントの振り返り⑤ 対策・再計画⑥ クライアントや上司への報告② 日々の制作––

朝会
タスク管理ボード③ 週の振り返り
–
–

週報
週定例
©SQUARE-ENIX 2011258

スプリントの手順• 階層化ＰＤＣ① スプリント計画
–
–
–

成果物目標
スプリント計画会
タスク管理シート② 日々の制作––

朝会
タスク管理ボード④ スプリントの振り返り–––

スプリント報スプリント振り返り会
成果物発表会⑤ 対策・再計画⑥ クライアントや上司への報告③ 週の振り返り
–
–

週報
週定例
©SQUARE-ENIX 2011259

スプリントの振り返り• ４週間のスプリントが終わるとそのスプリントの進捗具合や問題点を振り返ります• 「スプリント報」と「スプリント振り返り会」が振り返りの中心となります• スプリント振り返り会は全員で行います• それぞれ、週報や週定例と比べてより緻密な分析を行います• 今回は詳細は省略します©SQUARE-ENIX 2011260

数値見積りミスと作業の列挙漏れ• 振り返りの際には計画の変動要因として主に二つの要因を意識しましょう– 数値見積りミス– 作業の列挙漏れ©SQUARE-ENIX 2011261

成果物発表会• 「スプリントの振り返り会」に連結して「成果物発表会」も行っています• 各ユニットで目に見える成果物がある
場合は皆の前で実際に操作してプレゼンテーションします• 見せる側も、見る側もモチベーションが上がりますし、チーム内の意識統一もしやすくなるので、プロジェクトにとって重要な場となっています• 見せる側は「成果物発表会までに良い感じに仕上げる！」という気合が入ってくれるプラス効果もあります©SQUARE-ENIX 2011262

スプリントの手順• 階層化ＰＤＣ① スプリント計画
–
–
–

成果物目標
スプリント計画会
タスク管理シート② 日々の制作––

朝会
タスク管理ボード④ スプリントの振り返り–––

スプリント報スプリント振り返り会
成果物発表会⑤ 対策・再計画⑥ クライアントや上司への報告③ 週の振り返り
–
–

週報
週定例
©SQUARE-ENIX 2011263

対策・再計画• スプリントの進捗を振り返って、必要に応じて対策や再計画を行います• 対策・再計画例– 作業優先度の見直し– 担当者の配置換え– 設計の見直し– 人員採用計画の修正©SQUARE-ENIX 2011264

スプリントの手順• 階層化ＰＤＣ① スプリント計画
–
–
–

成果物目標
スプリント計画会
タスク管理シート② 日々の制作––

朝会
タスク管理ボード④ スプリントの振り返り–––

スプリント報スプリント振り返り会
成果物発表会⑤ 対策・再計画⑥ クライアントや上司への報告③ 週の振り返り
–
–

週報
週定例
©SQUARE-ENIX 2011265

クライアントや上司への報告• スプリントが終わる度にクライアントや上司へ進捗を報告しましょう• 進捗報告時に伝えること– 旧スプリントの成果物（目に見える成果物を中心に）– 新スプリントでの成果物目標の宣言– 問題点・課題とその対策案– 中長期計画やマイルストーンの変動情報• クライアントや上司への進捗報告を定期的にしっかり行う事でプロジェクトやプロジェクトリーダーへの信頼感が上昇します• 問題や課題を隠すのではなく、早期に積極的に開示して、出来ることならば一緒にプロジェクトの未来を切り開く仲間として、クライ
アントや上司に味方になってもらいましょう※なかなかそううまくは行かない環境も存在するとは思いますが©SQUARE-ENIX 2011266

プロジェクトマネジメントの手順
1.
2.
3.
4.

調査する
戦略を立てる（リスク一覧/開発戦略マトリクス/価値空間）設計する
計画する（中長期計画）
①
②
③
④

5.

タスクを洗い出す（ユーザーストーリー/フィーチャー/タスク/ＬＯＤ式タスク分解）
見積もる（２点見積もり/見積もりポーカー/ＬＯＤ式見積もり）
優先度を決める
マイルストーンを定める

スプリント（４週間単位の制作イテレーション）
–
①
②
③
④
⑤

階層化ＰＤＣ
スプリント計画（成果物目標/スプリント計画会/タスク管理シート）
日々の制作（朝会/タスク管理ボード）
週の振り返り（週報/週定例）
スプリントの振り返り（スプリント報/スプリント振り返り会/成果物発表会）
対策・再計画•••⑥

戦略・設計の修正（ゲーム仕様、アート、プログラム設計などの修正）
中長期計画の修正（タスクの追加・変更、見積もりの変更、優先度の変更）
リソースの修正（人員の追加や担当変更など）

クライアントや上司への報告©SQUARE-ENIX 2011267

本プロジェクトマネジメントの方法で得られる効果• 不確実性を制御– 不確実性が減る– 見通しが立つ– 早期に問題発見可能– 計画修正や対策もしやすい• メンタル効果– スタッフ自身の作業と期間の見通しが立つので、無根拠になんとなく日々残業しないとならないのかもしれないというプレッシャーから解放される⇒残業や休日出勤が大幅減– お互いの仕事を知ることができる– 楽しくなる• クライアントや上司からの信頼を得る• 目標通りに満足行くプロジェクトの成果がしっかり出る©SQUARE-ENIX 2011268

より詳しく知りたい方へ©SQUARE-ENIX 2011

269

推薦書籍

©SQUARE-ENIX 2011

270

推薦書籍
• 「マンガでわかる プロジェクトマネジメント」– PM世界標準PMBOKのダイジェストをマンガで• 「アジャイルサムライ」– 読みやすいアジャイル本• 「最短で達成する 全体最適のプロジェクトマネジメント」– CCPMを知る• 「ＸＰエクストリーム・プログラミング実行計画」– ＸＰにおける計画を知る• 「アジャイルソフトウェア開発スクラム」– スクラムを知る• 「Agile Game Development with Scrum」– ゲーム開発におけるスクラム実践例• 「アジャイルな見積もりと計画づくり」– 最もお勧めであり、最も考え方の近い本– 分厚く内容も高度なので最後に仕上げで読むのが良いです©SQUARE-ENIX 2011271

「デジタルゲームの技術」
第９章でもプロジェクトマネジメントについて
インタビュー形式で語っています©SQUARE-ENIX 2011272

来年プロマネ本が出版されます•

タイトル「スクウェア・エニックスのゲーム開発プロジェクトマネジメント（仮題）」• 出版時期– ２０１２年６月予定• 著者– 橋本 善久（スクウェア・エニックス ＣＴＯ）

• 出版社
– ソフトバンククリエイティブ• 内容– プロジェクトが失敗するメカニズム– プロジェクトを成功させる仕組みとメカニズム– 詳細なプロジェクトマネジメントマニュアル– ゲーム開発固有の課題へ向けて– スクウェア・エニックスにおける運用実例集– など（今回触れられなかった事を含めて語り尽くします）©SQUARE-ENIX 2011273

プロジェクトマネジメントは
とても奥深く
とても楽しい活動です©SQUARE-ENIX 2011274

やり方によって開発者やユーザーや会社をハッピーにも不幸にもできます©SQUARE-ENIX 2011275

プロジェクトマネジメントをうまく行うコツは「そのやり方をなぜ行うのか」を常に深く考察して徹底的に心理力学や情報の流れを意識して論理的に仕組みを組み上げ改善し続ける事にあります©SQUARE-ENIX 2011276

原典主義に陥ってはなりませんし、かと言ってなにも考えずに
自己流に走ってもなりません©SQUARE-ENIX 2011277

すべてに疑問を持ちましょう
すべてに自分の答えを用意しましょう
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•

なぜスプリントが必要なのか？なぜタイムボックス化は有効なのか？
スプリントは１週間、２週間、４週間、それ以上、どれくらいの期間が良いのか？
スプリントの期間は途中で変更しても良いか？
なぜ朝会があるのか？夕方の場合はどういう効果の違いがあるか？
朝会の一つの班の最少、最大人数は何人であるべきか？
なぜ２点見積もりなのか？１点や３点ではだめなのか？
見積もりの単位は“時間”“日”“週” どれが良いのか？各単位のメリット・デメリットは？
プロジェクト管理ボードはどういう構成であるべきか？
なぜ付箋は有効なのか？
付箋にはどういった情報を載せるべきか？
デジタル管理をするべきか？アナログ管理をするべきか？
プロジェクト管理シートはどういう構成であるべきか？
定例会議は行うべきか？行うならばどういうスタイルであるべきか？
日報は必要か？週報は必要か？スプリント報は必要か？
各報告書はどのようなフォーマットであるべきか？
そのやり方で誰にどんな情報がいつ届くのか、誰に届かないのか
そのやり方でどんな心理効果が生まれるのかなどなどなどなど・・・©SQUARE-ENIX 2011278

「本にこう書いてあったから」「あの人がああ言っていたから」ではなく、自分で「なぜ」「どうやって」を深く考察して納得の上で各“仕組み”を導入してみましょう。
（※やってみないと分からない仕組みの場合は「実験である」という明確な意識下でお試し導入しましょう。）

そして実行しながら効果を測り、効果を感じ、“仕組み”を調整し続けましょう。

©SQUARE-ENIX 2011279

すべての情報を全力で肯定しすべての情報を全力で否定し頭にたくさん汗をかいてひとつひとつの“仕組み”に対して「なぜそうなのか」をあなたなりに自力で導き出してください※本講義も「全力の肯定、全力の否定」の対象であるべきことは言うまでもありません©SQUARE-ENIX 2011280

思考停止しない©SQUARE-ENIX 2011281

それがプロジェクトマネジメントをなるべくうまく行かせるための最大のポイントなのです©SQUARE-ENIX 2011282

ぜひあなたなりの深い考察をした
プロジェクトマネジメント方法論を構築してください©SQUARE-ENIX 2011283

機会があったらそれをぜひ聞かせてください
ディスカッションしましょう©SQUARE-ENIX 2011284

ありがとうございました©SQUARE-ENIX 2011285