こんにちは！コンじゃぶろーです！
ゲームを開発した事がある人も、そうでない人でも、
スケジュール管理について悩みを抱えている人は多いでしょう。
私は、２０年間の中で、大小の数１００を超えるプロジェクトを管理してきました。
その上で言える事は、
チーム制作におけるスケジュール管理とは「クリエイティブを高める為のもの！」と言う事です。
今回は、短納期案件を大量に、かつ超高速で回してきたスケジュール管理のノウハウを、１つの記事にまとめました。
・納期遅れ、工数や予算オーバーなど、スケジュール管理に悩んでいる人に向けた記事です。
・チーム制作でのスケジュール管理は、「クリエイティブを高める為のもの」
モバイルアプリの開発は、１週間規模の小さなものから、２年に及ぶ長期のものまで様々です。ほとんどの場合は、同時に２・３本走っているのが普通でした。
１タイトルに２〜３年以上かかる家庭用ゲーム開発では、一生のうち１０本作れれば多い方です。なので失敗してもやり直しは１０回しかできません。また、担当できる仕事も専門性が高く全体を把握することはできないでしょう。一方モバイルアプリの開発は、短期間少人数です。０〜１のアイデア作成の部分はもちろん、１〜１０までの開発工程を全て経験する事ができます。
つまり、私は、大量の案件を、同時に、そして高速に回して壁にぶつかってきたという事です。
原理原則の話をするので、大きな「ビッグプロジェクト」から、小さい「飲み会」までスケジュールにも転用可能な、「チーム開発における、スケジュール管理」資料の永久保存版です。
前半は、主にスケジュールに対する考え方（マインド面）に関しての原理原則の解説で、
後半は、スケジュールの精度を向上させる為の、知識面に関しての解説になります。
マインド面と、知識面の両軸で考える事で、トラブルの少ないスケジュール管理が実現可能です。
スケジュール管理し続けて２０年！ゲーム開発のディレクション実績を元に、スケジュール管理を解説
ゲームプランナーをやっていると、スケジュール管理を兼任する事が多いんです。なので、割と給料が上がりやすいポジションと言えるでしょう。
私の場合は、１０年間で１００本以上ガラケーのゲームを開発した後、複数案件の品質管理やディレクション、進捗管理等に携わってきました。最終的に常時３０ラインの進捗管理を実施していました。
長くやっていると、様々なトラブルを経験できるので、スケジュール管理に悩んでいる人向けに、そのノウハウを永久保存版としてまとめてみました。
スケジュール管理に関して丁寧に情報をまとめ、私の経験を盛り込んだ内容になっていますので、何度も繰り返し読んでいただく事で、理解も深まるでしょう。ブックマーク等に保存しておいてもらえると幸いです。
これから、何らかのプロジェクトで管理者を目指している人の力になれれば幸いです。
▼ゲームプロジェクト管理者の年収はこちら
仕事をスケジュール管理する目的とは？
まず、スケジュール管理する目的は、
「開発者を、スケジュール管理の煩わしさから解放し、クリエイティブの質を向上させる為」です。
スケジュール管理ができているか？できていないか？
自分が、どれくらいスケジュール管理できているのか、分かっていない人は多いんです。誰しもできてないと思って働いてないですし（むしろできてると思っている人の方が多い）、働いている環境によって気づかない場合があるからです。
スケジュールの質を確認する方法はいくつかありますが、納期遅れになるのが普通とか、残業が多いとかだと、赤信号でしょう。
そういう環境で働いていると、ストレスも溜まりやすく、体調も崩しやすいです。気づいたらスケジュール関係の課題ばかりで、開発の質を向上する話合いができないので、クリエイティブの質は下がってしまいます。
もっとクリエイティブに時間を使いたい。
常習的にデスマーチ（ずっと忙しい）が続いている環境を改善する方法を紹介します。
時間的にも精神的にも余裕が生まれ、より良いモノを作る為にそのエネルギーを使いたいですよね。
まずは、納期遅れを起こすチームの共通点から迫っていきましょう。
【スケジュール管理】納期遅れを起こすチームの３つの共通点
納期遅れが常習化している組織では、その原因に目を向ける人がいません。疲労とストレスで思考停止状態となり、ゾンビのように考えずに働き続けてしまうからです。なので、何度も同じミスを繰り返します。これまで、たくさんの納期遅れのプロジェクトを見てきましたが、トラブルが発生するプロジェクトには、３つの共通点があります。
まず、１つ目。
開始時と、終了時で、スケジュールが違いすぎる（スケジュール変更が多い）
プロジェクトを開始した時は、３ヶ月の予定だったのに、終わってみると５ヶ月かかっている。あるいは、３人で対応予定だったのに、最終的に５人で対応していた等、シンプルに予算オーバーが発生しているパターンです。そう言う場合は、最初のスケジュールと、最終のスケジュールを比較すると良いです。ただし、スケジュール遅れが発生しているチームでは、スケジュールが正常なルールで管理されていないので、捏造されたものになっている可能性が高いです。（もしそうなら、捏造資料の価値は、ゼロ以下のマイナスです。それを次の案件の参考にすると、地獄になるからです。）
「最終のスケジュール」から「最初のスケジュール」を引くと、増えた部分になります。
単純な引き算にならないのは、最初予定していたけれど対応が不要になった仕事も混ざっているからです。
そして２つ目。
プロジェクトメンバーの価値観が違うから、足並みが揃わない
人が複数人集まると、トラブルが発生しやすくなります。みんな育ってきた環境が違うので、価値観の違いから、思わぬトラブルに発生する場合も多いです。人の悩みの原因のほとんどは、人間関係なので、一番対策が必要な部分だったりします。特に価値観の違いには注意が必要です。人間の本性を理解するという事は、とても大切な事だからです。
人によって価値観は違います。育ってきた環境が違うからしょうがないです。
メンバーの価値観を「７つのパターン」に分けて解説します。
最後に３つ目です。
スケジュール管理してるのに、想定外のトラブルが多い
完璧なスケジュールを立てているはずなのに、なぜか想定外のトラブルが多い。そういう悩みを抱えるリーダーは非常に多いです。２度も３度も同じようなトラブルが発生し、仕様変更やスケジュール変更でバタバタしてしまう。トラブルが発生しないようにスケジュールを一生懸命作り込んでいるのに、毎回スケジュール変更が発生してしまう無限地獄です。
昔、「想定内です。」という言葉が流行ったの覚えてますか？
どんなトラブルが起きても「想定内です。」と言って乗り切ってくれる。そんな、参謀みたいな人がいると良いですが、なかなかそうはいかないですよね。
プロジェクトを管理していると、大小様々なトラブルが発生します。
リーダーは、トラブルに対して「打ち手」を立てないといけません。
トラブルは、原因を分析し、「人」「時間（期間）」「金」のバランスを調整して解決します。「金」は変更できないので、「人を追加する」か「期間を延ばす」が、主な打ち手になります。
最適な打ち手を実施する為には、スケジュール遅延が発生する原因を、詳しく知ることが大切です。
紹介した納期遅れになる３つのポイントを、１つずつ詳しく解説します。
まずは、「開始時と終了時のスケジュールが違いすぎる（スケジュール変更が多い）」からです。
開始時と、終了時で、スケジュールが違いすぎる（スケジュール変更が多い）
プロジェクトが始まった時のスケジュールを、必ず残しておいてください。
最初の状態が残っていれば、終了時のスケジュールと比較すると、どの作業が増えているかが分かります。とても簡単な引き算なので、簡単に分かる方法なんですが、多くの人はできません。
なぜなら、最初のスケジュールが残っておらず、終了間際にスケジュール更新されていない事がほとんどだからです。
おそらく、何らかのスケジュール管理をした事がある人なら経験がありますよね？
スケジュールは日々変更が加えられ、最初の原型はとどめておらず、終盤はバグリストの管理に必死で（スケジュールを）更新しなくなる…。
その後見積もりの参考にと誰かが開いても、内容がぐちゃぐちゃで…そっ閉じ。
ありますよね？
スケジュールは宝の山なので、少し丁寧に管理するだけで、チームの状況はぐんとよくなります。
クラウド上でスケジュール管理すると、最初と最後のスケジュールの変更履歴が全て残せるので非常に効率よくスケジュール管理する事が可能です。
スケジュール管理の、オススメツールを紹介します。
こちらは、私がずっと使ってきた管理ツールです。非常に低コストかつ高機能なのでオススメ。
＼おすすめの管理ツール／
myredmine
▼オンライン上でスケジュール管理できる「myredmine」が、オススメです。
redmineは、不具合（バグ）のステータス管理の為のツール（オープンソースなので自社サーバーを立てて運用可能）です。「myredmine」は、自社サーバーの管理が不要で、1000ユーザーまで月額8000円で利用可能な、redmine管理代行サービスです。
スケジュール変更で、工数が増えるメカニズム
スケジュール変更によって、スケジュールが汚くなるなら、スケジュール変更の回数を減らせばいいんじゃないか？最初から、完璧なスケジュールを作ればいいんじゃないの？
そう思った人は、なかなか鋭いです。なぜなら、途中でスケジュールを変更すると、最初に作るよりも時間や労力がかかってしまうからです。トラブルの多いプロジェクトのリーダーは、毎日一日中スケジュールと睨めっこしている事も少なくありません。
どうせ時間を使うなら、もっとクリエイティブな事に時間を使いたいですよね？その為にも、まずはチームで理解する必要があります。
「途中でスケジュール変更すると時間がかかる」という事を理解するだけで、かなり改善する事もあります。メンバーが、最初によく考えるようになるからです。
なので、ここでは、スケジュール変更に時間がかかるメカニズムを、少し丁寧に解説します。
スケジュール変更にどれくらい時間がかかっているか？
すぐに対応できるので、実績を残していないチームは非常に多いです。
一度、スケジュール変更にかかった時間を記録してみてください。プロジェクト終了時に、とんでもないくらい時間がかかっている事に気づけます。
通常のスケジュール作成の流れ
スケジュール作成の流れをシンプルに表現すると、このようになります。
- 作業の洗い出し
- 作業担当者の設定
- 作業工数の設定
- 作業優先の決定
- スケジュール表作成
少し難しい書き方をしていますが、スケジュールを作成するとは「誰が？いつ？何を？どのように？どこで？なぜ作成するか？（５W１H）」を決めるという事です。
何の問題もなければ、とてもスムーズに終わります。ただ、ゲームを開発したり、イベントを立ち上げたりすると、進行中にさまざまなトラブル（問題）が発生し、スケジュール変更が発生するんです。
そうなると、また１からこの工程を見直す必要が出てきます。
０から作るわけではないので、大した作業ではないんですが、逆にどの部分を変更するかを判断する必要があり、少しずつチリツモ（ちりも積もれば山となる）で、スケジュールを圧迫します。
では、スケジュール変更の原因にどういうものがあるのか、具体的に見てみましょう。
スケジュール作成方法に関しては、その詳細を後述します。
ここは「ふーん、そんな感じなんだ」という程度で流し読みでOKです。
スケジュール変更がかかる原因
スケジュール変更の原因は、色々ありすぎて書ききれないですが、代表的なものを紹介します。
- 作業の漏れ
- 作業担当者の欠員
- 作業工数の見積もり間違い
- 作業優先の間違い
- スケジュール表への転記ミス
これらの原因は、スケジュール作成の手順の全てのステップで発生するものです。
作業の洗い出しをした時に、抜け漏れがあった場合は、作業を割り込ませる必要が出てきます。
予定していた担当者が、急に休むとか離職する場合、別の担当者を立てる必要が出てきます。他のプロジェクトから引っ張ってくるので、他のチームを巻き込んでスケジュールをかき乱す事になります。
そもそも見積もり（予定していた作業時間）が間違っていたら、後ろの作業をずらさなければいけません。作業優先が変更されると、他のメンバーの作業待ちが発生してしまいます。
最後の「スケジュール表への転記ミス」なんて、プロの世界にあるの？と思われる方もいるかもしれません。でもこれは、意外と多いんですよ。人の手が加わる部分は、簡単なミスが発生するものと考えておいた方がいいです。極力人の手を使わない為に、自動化の仕組みを導入するチームも多いです。
スケジュール遅れの原因なんて、いくらでもあります。
一番の問題は、「情報の共有不足」です。「僕、それ聞いてないんですけど…」というワードが出てきたチームは「赤信号」と思って間違いないでしょう。
スケジュール変更の原因はすぐには分からない
スケジュール変更（作業の遅れ）の原因は、すぐには分かりません。
スケジュールがクラウド管理されていて、毎日進捗確認をしているならば、原因を見つけるのは容易いですが、パソコン内のローカルファイルで管理されていたり、リーダーの頭の中だけで動いている場合は、スケジュールが遅れている事すら誰も気づかないかもしれません。
クライアントから「状況を報告せよ」と言われて、状況がわかるまで数日かかった事もありました。クラウドで管理されていたら、すぐに返答できますが、ローカル管理だとかなり時間がかかるんです。
スケジュール変更の原因を特定する
スケジュールが変更されるという事は、「予定通りではない」という事です。それはそのまま納期遅延につながります。遅れが出ても適当に進行して、最終的につじつまを合わせる開発もありますが、それだと後半は高い確率でデスマーチになります。
スケジュールが変更される事態になったら、（案件終了後でも良いので）原因を特定し再発防止につとめましょう。デスマーチばかり続くチームだと、優秀な人材が逃げてしまうからです。
ここでは、代表的な４つの打ち手を紹介します。必ず３つ以上の視点から分析して下さい。１つだけだと、情報が足りず判断を誤ってしまいます。
- 全体の状況を把握する
- 個人の状況を把握する
- 進捗を把握する
- 品質を把握する
４つの視点で確認し、リーダーはトラブルの影響範囲を見きわめなければいけません。
「人」「期間」「金」に対して対策を考えます。
視点１：全体の状況を把握する：スケジュール表の分析
問題が起きた場合、全体の状況を把握するのは、とても大事な事です。大枠での打ち手にミスすると、被害を大きくしてしまうからです。
まずは、鳥の視点で全体を俯瞰して見てみましょう。
視点２：個人の状況を把握する：各担当者へのヒアリング
個別にヒアリングをして、それぞれの担当者がどのように考えているのかを知ります。この時注意すべきなのは、犯人探しをしない事です。また、チームで犯人探しをするようなノリにならないようにしましょう。
場合によっては、マンツーマンで行った方が良いでしょう。
視点３：進捗を把握する：成果物の確認
全体を確認し、個人へのヒアリングを行ったら、次は成果物を確認します。必ず自分の目で実際に動いているモノ（場合によってはソースやグラフィック等の成果物）を触って下さい。
それぞれの担当者の言い分と、食い違いが見えてきます。
視点４：品質を把握する：不具合分析
成果物だけでは、その中身の品質までは見えない事が多いです。
ちょっと触ったくらいでは分からないのが、潜在的な不具合量です。どのくらいのテストを実施し、何件くらいの不具合が出て、そのうち何件修正済みなのか？を確認します。
トラブルが発生する度に、リーダーは、高速で考え判断しなければいけません。
問題が多いという事は、クリエイティブにさける時間がなくなる事を意味する事がお分かりいただけるでしょうか？
スケジュール変更の原因へ対策する
プロジェクトの問題を、４つの視点で分析し原因を特定したら、すぐに対策を考え実行しなければいけません。
作業の追加：作業が抜けていた場合は、追加しなければいけません。単純に工数増となります。
作業工数の変更：想定しているよりも時間がかかっている場合は、いつ終わるのか？正確に見積もりし直さなければいけません。
担当者を追加：作業が増えても納期（期間）は簡単に増やす事ができません。他のプロジェクトから引っ張ってくるか、時間外に働いて貰わなければいけません。
作業優先の変更：担当者が増える場合、あるいは現在起きているトラブルによっては、作業の優先順を変更する必要があります。作業の優先順を変更する事で時短になる事もあれば、効率が悪くなる場合もあります。リーダーは、時に効率が悪くなっても要員を増やす決断をする場合があります。
スケジュール修正：対策をうったあと、全体的にスケジュールを更新しなければいけません。修正漏れがあった場合、スケジュール遅れになってしまうので慎重に実施します。
かなりの作業が発生する事がわかります。
これらの作業は、スケジュールに残りづらく、次の案件で生かされない事が多いです。
だから、同じ事を繰り返してしまうんです。
スケジュールの変更を加えて情報を共有する。
トラブルが発生したら、原因を探し対策を打つ。これらの一連の流れには「明確な答え」がありません。１００人のリーダーがいれば１００通りの解決策が示されるでしょう。
しかし、一番大事なのはここからです。
変更したスケジュールを、全体に共有しなければいけません。
・いつまでに、何が終わるかを明確にする
・全員で、再度ゴールを共有する
スケジュールに変更を加えたら、全員で確認し（内容を納得した上で）それに向かって進まなければいけません。スケジュール変更は、全員の作業を一旦止めてでも、全員で取り組むべき事です。結果的にその方が早く終わる場合があります。数日後に「それ聞いてませんけど…」が頻発すると、その時点でアウトです。
納期間際の忙しいタイミングで実施することがほとんどなので、情報の共有漏れには十分注意しましょう。
納期間際になると、みんな自分の作業に必死になります。すると情報共有が難しくなるので「目」を増やすのも手です。
定期的に、１人ずつデバッカーを増やしていくんです。「目」が増えれば問題の発見も早くなります。
スケジュール作成の苦悩…、先に対応するか、後で対応するか
スケジュールを、最初に完璧なものを作るか？、開発しながら作り込んでいくのか？
リーダーにとっては永遠に近いテーマです。
先に頑張るか？、後で頑張るか？
あなたはどちらのタイプのリーダーですか？
先に頑張る方が効率は良いんです。なぜなら、すでに説明したように「途中で変更する」のは多めに工数を使う事になるからです。ただ、先にやる方が良いからと言って、簡単にできるわけではありません。
このあたりは、非常に重要な部分なので、これまでの説明を踏まえて丁寧に解説させてもらいます。
スケジュールは、途中で変更する方が時間がかかる
スケジュールを、開発中に変更するのは非常に時間がかかります。
その上、どれくらいの時間かけたかが残りづらいんです。この辺りの工数を記録するようにすると、非常に強いチームになります。
▼記録するメリットに関してはこちらの記事で詳しく解説しています。
スケジュール遅れの原因特定に時間がかかる
「スケジュールが遅れている」これ事態把握するのが難しかったりするんですが、その原因を特定するとなると、もっと大変です。
できれば、毎回同じ失敗を繰り返さないように、１度失敗したやり方は対策も含めて何らかの形で残しておくのが望ましいです。ただ、スケジュール遅れを発生させているチームには難しいでしょう。記録を残す文化のないチームの場合、スケジュール遅れの原因を特定するのにも時間がかかります。
納品日にスケジュール遅れが見つかった場合最悪です。
納期遅れは、クライアントや責任者へ最速で報告する必要があります。報告は、原因の特定や対策の前です。
スケジュールの更新に時間がかかる
スケジュールを変更するという事は、当然ですが更新に時間がかかるという事です。
何らかのスケジュール管理をした事のある人ならばイメージは着くと思いますが、１つのタスクを３日ずらすだけで割と面倒なんです。その後に続く予定も込みでずらす必要があるからです。
使っているツールにもよりますが、ドミノ倒しのような現象が起きたりもします。
オンラインではなく、エクセル等をローカル環境で管理すると、マージだけで数時間ロスしたりするので、オンラインに切り替えた方がいいですよ。
割り込み作業が、仕事の効率を下げる
何らかの仕事をしている最中に、「スケジュールが遅れている！」「原因はなんだ！」となると、作業を止めなければいけません。状況が大きく変わる為、今作業している内容が無駄になる場合があるからです。
仕事というのは、意外に「ノリ」が大切なので、「集中力」が一旦途切れてしまうと、また作業に戻った時に集中力が低下した状態からスタートしなければいけません。
作業の切り替え練習をしていると、パッパッパと、スイッチを切り替えるように頭を切り替える事も可能です。
▼集中力の切り替えをマスターする方法を紹介します。
新しいスケジュールの共有に時間がかかる
新しいスケジュールの共有には、非常に時間がかかります。
スケジュール変更の会議に全員で参加していれば、ある程度スムーズに移行できるでしょう。しかし、そういう時に、作業優先を選んでしまうメンバーもいます。
その場合に、「議事録読んで」というスタンスで進むと「僕聞いてません」という二次災害になります。納期を変更した上で、さらに納期変更を重ねると、最悪クライアントから仕事がもらえなくなるでしょう。
会議に参加しなかったメンバーがいる場合は、個別に説明する時間を設けるようにしましょう。
みんなで集まっているのに、参加しないのは、他に爆弾を抱えている場合があるからです。
先に完璧なスケジュールを作り上げる
スケジュールを構築する上で、誰しも考えてしまう落とし穴について話をしなければいけません。
これから話す事は、これまで話してきた事を、根底から覆すような内容です。人によっては、大混乱に陥る人もいるかもしれません。しかし、これまで話してきた事を「光」とすると、これから話すことは「影」の部分です。
光と影、清濁併せ持って初めて完成する。
ここからは、これまでの話と逆転する内容なので、心して読んでください。
心の準備は良いですか？
スケジュールを作る上での落とし穴は、「完璧なるスケジュールを求める」という事です。
物事には、なんでも加減が大切だという話になります。
完璧なスケジュールを作る事は、理論上不可能な話なのですが、どうしてもそれを求めてしまい時間を多く使ってしまうケースがあります。変更しないですむスケジュールが作れるならば、それに越した事はないですから、なるべく変更が少ないスケジュールを作ろうとするのは正しい判断です。
しかし、完璧なスケジュールを求めると「時間を浪費している事に気づかない」リーダーが増えてしまいます。
サラリーマン病というか、「時間をかければ、必ず良い品質になる」そういう一種の思考停止に陥るケースが良くみられます。
なぜそうなるのか？について知っておく事で、防げる確率も上がるので、思考停止してしまいがちなメカニズムを解説します。
変更不要の完璧なスケジュールが立てられればそれに越した事はない
変更不要な完璧なスケジュールを立てるという事は、「仕様変更しない」という事です。尚且つ、「仕様に一切の間違いがない」状態を指します。
ただ、そういう奇跡的な事はありません。特にゲーム開発は、仕様変更が多いです。
許された期間の中で、ギリギリまで面白くしようとする人が多いからです。
これは、ゲームに限らずあらゆる分野でも一緒でしょう。ただ注意しなければいけないのは、「完璧なスケジュール」を否定するものではないという事です。あくまで最優先すべき事は、できる限り変更回数が少ないスケジュールを立てるというスタンスです。
優先すべきは、スケジュールの精度を上げる
しかし、スケジュール作成の期間を決めておくのがオススメです。
人は、ゴールを決めてないと、無限に作業できてしまうからです。
スケジュールのゴールを明確に定められる人だけしかできない
私自身、完璧なスケジュールを目指した事は、何度もあります。
しかし、完璧なスケジュールだ！と自信があっても、スケジュール変更が発生しなかった事はほとんどありませんでした。１００本も作っていれば、変更がかからなかったプロジェクトもありましたが、仕様を変更しないので、面白さの爆発力は少なくなるのを感じました。
メンバーも、クリエイティブの発揮を止められる事になるので、モチベーションはダダ下がりでした。最初に作成した仕様をぶち壊しながら進む方が、やっぱりクリエイティブなんですよね。完璧なスケジュールをメンバーに求めると、「破壊」や「変更」を恐れるようになりました。
スケジュール作成を、リーダーの自己満足にしてしまうと大変です。
「スケジュール変更は許さない！」を強要すると、仕様の変更ができなくなり、メンバーのクリエイティブが低下します。
デメリット①：１００％完璧なスケジュールを立てるには時間がかかる
なんでもそうですが、７０点くらいまでであれば１時間とか短期間で組み上げる事ができるんです。しかし、７０点から１００点に上げようとすると、ものすごく時間がかかります。
１つ１つの制度を、上げる必要があるからです。
参加するメンバー一人一人の能力も違う為、その作業スピードも考慮しなくてはいけません。莫大な時間がかかるんです。１００点満点のイメージが明確でないと、無限に時間を費やしてしまいます。
１度くらいは、（みっちり時間をかけて）１００点満点のスケジュールを狙ってもいいと思います。１から１０まで細かく精査する力がつくと、後で変更が発生しても素早く対応できるからです。時間があるならば、終了したプロジェクトのスケジュールを「作り直してみる」のは、いい経験になるでしょう。
デメリット②：もし変更が発生した場合、変更に時間がかかる
完璧なスケジュールというのは、作業と作業が密接に絡み合っています。
Aの作業が終了したらBとCの作業ができる等、作業の順番が関わってくるからです。１つ変更すれば、それ以降の作業を全て変更しなければいけません。
細かく作れば作るほど、変更にかかるコストは莫大なものになります。
作業を追加するだけでも単純にずらせば良いというわけではありません。
納期が変えられないので、必ず皺寄せが発生するからです。
デメリット③：スケジュールが立ち上がるまでの期間、ロスが発生する
完璧なスケジュールを作成するには、時間がかかるので、その間メンバーを待たせる事になります。完璧なスケジュールを作成するには、完璧な仕様書が必要です。なので、長時間メンバーの作業が止まってしまうでしょう。
先に作業を割り振りながらスケジュールを作成する方法もありますが、その時点で完璧なスケジュールを立てない状態でプロジェクトがスタートしている事になります。
現場では、スケジュールが完成した状態で開発がスタートする事は稀です。
なので、リーダーはメンバーの手が空かないように、仕事を作り続ける必要があります。これが、スケジュール作成を難しいものにしているわけです。
スケジュール変更は必ず発生するという点を忘れてはいけない
スケジュール変更は、必ず発生します。
これは断言できます。このことは、頭にしっかりと叩き込んでおく事が大切です。
「どうせ変更がかかるんだから、スケジュールも柔軟に対応できるようにする」それくらいの遊びは用意しておいた方がいいですね
しかし、同時に「納期」や「予算」を守らなければいけません。
一見矛盾するような事を、リーダーは求められるので、ジレンマに苦しむ人は多いでしょう。なので、あらかじめ「クリエイティブ」の予算を確保しておくのが良いでしょう。
日本は、３０年もデフレが続いた国です。
見積もり時に、無駄な工数があると厳しく追求されて削減されてきました。なので「クリエイティブ費」は真っ先に「０」になります。ただ、その上で「品質」が悪いと２度と仕事がもらえないという…まさに地獄の世界です。僕は地獄を生き抜いてきました。
なぜスケジュールが変わってしまうのか？
スケジュールが変わってしまう原因は、様々です。
あえてその原因を大きく２つに分類するとしたら、「内的要因」と「外的要因」です。
内的要因は、チームメンバーの人間関係や価値観の相違によって発生するもの。そして、外的要因とはそれ以外の原因によって生まれるものです。
- 内的要因：プロジェクトメンバーの足並みが揃っていないこと
- 外的要因：クライアントや他プロジェクトによるもの
次項では、スケジュール変更が発生する原因について解説していきたいと思います。
まずは、内的要因から…
内的要因：プロジェクトメンバーの価値観が違うから、足並みが揃わない
プロジェクトの中には、さまざまな価値観を持った人がいます。
プロジェクト運営において、人間関係はとても重要で、価値観の相違は人間関係に多大なる影響を与えるからです。
価値観以外にも、能力不足が原因でスケジュールが遅れる事もありますが、それは「研修」によって修正可能です。しかし、人の価値観は簡単に変える事はできません。その特徴を知り丁寧に対策を講じなければいけません。
人の価値観の種類は、非常に多い為、
スケジュール作成のメリットを元に、７つの価値観を絞り込んでみました。
スケジュールを立てるメリットが多すぎて、目的や行動が食い違う人々
スケジュールを作成して、プロジェクト運用するメリットは非常に多いです。
私が感じている一番のメリットは、参加しているメンバーの「クリエイティブ」を最大限に引き出すという事です。ただ、そう考えている人は少ないでしょう。直接的なメリットではないからです。
スケジュール作成には、もっとわかりやすい直接的なメリットが多く存在します。
メリットの種類が多いので、参加するメンバーが考えている「スケジュールの意味」も全く違ったものになります。グループ作業には、価値観の相違がついてまわります。
これから紹介する７の価値観は、スケジュール作成のメリットと結びつくものです。その全てが正解であり、１つとして間違いはないものです。人によって何を１番に考えるか？は千差万別です。
- 評価重視型：スケジュールは、人事考課（給料アップ）の判断材料にできる。
- 納期重視型：スケジュールは、納期を厳守するのになくてはならないものだ。
- 品質重視型：スケジュールは、コンテンツの品質を向上させるのに欠かせない。
- 問題発見型：スケジュールは、問題を事前に発見する為にある。
- 不安解消型：スケジュールは、曖昧な部分を明確にし漠然とした不安を無くす為にある。
- 効率重視型：スケジュールは、効率アップに欠かせないツールだ。
- 労働環境改善型：スケジュールは、時間外や休日出勤を無くす為にある。
これらは全てスケジュールを作成するメリットに紐づくものです。どれも間違っていません。
しかし、この価値観の相違（微妙なズレ）によって、スケジュール変更のトラブルに発展する事になります。
ここで大事なのは、誰も間違っていないという事です。
全ての人がスケジュールを守ろうとした結果、ズレが発生してしまう
そういう現実を知る必要があります。
評価重視型：スケジュールを、評価の為と考える人
スケジュール変更が多いって事は…つまり、仕事のやり方がまずいって事よ！
評価を得る為にも、最初に決めたスケジュールを守らなくっちゃ♪
評価を上げて、給料アップよ♪
スケジュールの更新状況を見ると、その人の能力が見えると言っても過言ではありません。右も左も分からない新入社員であっても「スケジュールは評価に響く」と本能的に理解しているでしょう。
ただ、「評価」に使えると考えるのは「錯覚」かもしれません。
毎日仕事が遅れている人と、毎日余裕を持って前倒しする人がいたとしても、同じ基準では測れないからです。担当者が同じ条件で働くという事はない為、比較できないんです。毎日仕事が遅れている人は、期日設定が厳しいだけの場合もあります。分析にはかなりの時間がかかるので（AIが導入された未来なら別ですが…）、安易な印象のみで評価してしまう会社も多いかもしれません。だからこそ、「評価に影響する！」という思いが強くなります。
納期重視型：スケジュールを、納期を守る為のモノと考えている人
このプロジェクトが一体いつ終わるのか？本当に納期までに間に合うのかは、スケジュールを作らないと分からないですよね。スケジュールは、人と人の約束そのものです。
スケジュールは、納期までにプロジェクトが終了する根拠になります。
細分化され考え込まれたスケジュールは、根拠の精査が非常に楽なので、信用につながりやすくなります。
もし、数ヶ月のプロジェクトのスケジュールが、期日だけしか切られておらず、作業の細分化や担当者の割り振りができていない場合、「本当にこの案件終わるの？」にしかなりません。
スケジュールはどこまで細分化するか？に関しての議論は一生続けられますが、「納期までに商品が完成するか？」に対しての根拠となるものである。そういう視点に立つと見えてくるものがあります。
品質重視型：スケジュールを、品質を守る為のモノと考えている人
商品の品質を上げるには、スケジュール上に品質チェックする日を設定しておかなくちゃいけないよね。それさえ決めておけば、早い段階で品質の低下を防げるんだ。
スケジュールの中に、品質チェックの段取りが記載されていると、メンバーは意識します。この小さな意識が、商品の品質を向上するものとなります。
この日にクライアントや上長がチェックする。それだけで、チームが同じ目標に向かって走りやすくなるからです。これは人間の性質を詳しく知れば分かるロジックです。人は「上司の指示を１００％守ろうとしません」が、「上司がチェックする事は、１００％実行する」そんな性質があります。
人の思考を理解すれば、品質を向上させてなおかつ無理のない仕組み（ルーティーン）を作る事も不可能ではありません。
問題発見型：スケジュールを、プロジェクトの問題を見つける為のモノと考えている人
スケジュールは、いち早く問題に気づく為にあるんだ。
納品日に、何もできてない事が発覚したら手遅れになるから、細かいゴールを設定して早めに対応できるようにする事が肝心だ。
スケジュールを見ると、課題を早い段階で見つける事ができるようになります。仕事を「タスク」と呼ばれる最小単位に分解し、それぞれに期日を割り振るので「タスク」が期日までに終了しなかった時点で「問題あり」に気づく事ができます。
また、スケジュール管理をしている上で、評価を気にするあまり「問題発覚」を隠そうとする人もいます。そう言う場合も、スケジュールを見ると「おかしな点」が多く見られる為、問題の早期発見に役立ちます。
不安解消型：スケジュールを、不安解消の為のモノと考えている人
スケジュールが無いプロジェクトで仕事するなんて最悪。不安で頭がおかしくなるわ。
私は、リーダーやメンバーの言葉よりも、スケジュールを信じる。不安材料は全てスケジュールに記して安心したいの。
人間は、「不安」を感じ、その不安を「解消」する事で進化してきた生物です。
暗闇に、ありもしない幽霊や猛獣を想像して逃げるような、一見非効率な思考の生物ですが、その特殊能力によって生き残ってきた歴史があります。なので、人間の中で一番多いのは「不安」を感じる人です。不安を感じる人は、不安材料を全て潰す事が有効なので、スケジュールで全ての作業のゴール地点を決める行為は、とても有効な手段です。
不安が無くなった時、人間は凄まじい成果を生み出します。
効率重視型：スケジュールを、効率化の為のモノと考えている人
スケジュールを見たら、そいつが効率の良いヤツかどうか一発で分かるよ。優先順位を決めるセンスっていうの？
どうせなら、無駄な作業が発生しないメンバーと仕事したいもんだね。
作業の優先順位を決めるには、センスが必要です。
ちょっとした作業順序の組み替えで、驚くほど効率よく作業できるからです。仕事をしていて一番時間がかかるのは、ランダムに積み上げられた仕事を、１つずつ順番に作業した時です。
仕事には、準備が必要なので、準備ができていない仕事は完了させる事ができません。だから、何も考えずに作業すると、（準備不足のタスクがやってきた時に）手が止まってしまいます。いかに効率よく準備をしていくかで、作業のやり直しを防ぐ事ができます。作業の優先順を決めるというのは、非常に大切な事です。
作業の優先順だけでも、熟練の先輩に見てもらうだけで、作業工数はグッと節約する事ができます。
労働環境改善型：スケジュールを、時間外労働を減らす為のモノと考えている人
なんとなく不安だから残業してって馬鹿げてるよね。スケジュールを立てればどれくらい遅れが出てるか一発で分かるんだから、もっとロジカルに判断して欲しいわ。
スケジュールを正しく運用すれば、時間外や休日出勤なんて発生しないのよ。
人生の貴重な余暇を、仕事で消費するなんておかしいと思った事はないでしょうか？スケジュールの遅れを事前に察知し対策すれば、時間外や休日での対応は発生しません。
対策する事から逃げて、安易に時間外を使ってしまうチームは、非常に生産性が低いです。
時間外労働が常習化していたチームを、無理やり定時で帰宅させた時、作業が遅れるどころか効率が良くなりスケジュールが短縮された事例もあります。（思考停止状態の）安易な時間外労働を無くすヒントは、スケジュールの中にこそ隠されています。昭和や平成の時代では黙殺されていた意見ですが、令和になり各社で急速な改革が実施されホワイト化が進んでいる企業が目立ってきました。
改革が遅れコンプライアンス違反を続けている会社は、いずれ淘汰されていく事でしょう。（少子化が進み子供に対する溺愛度が上昇する）これからの時代に、大切な我が子をブラック企業へ入れたい親は、いなくなるからです。
以上が、７つの価値観の解説です。
自分がどれに当てはまるのか？について、メンバーと話し合ってみてください。
どれにも当てはまらない！という方は、お気軽にコメントくださいね。
何を優先してスケジュール管理するのかを、明確にする必要がある。
スケジュールには、様々なメリットがあります。たくさんのメリットが全て良い方向に進めば何も問題はありません。しかし、大抵の場合は、良くない方向に発揮される事が多いです。
人によってスケジュールに期待するものが違うと、認識にズレが生じるからです。
チームメンバーがスケジュールを守ると言う目標に向かって進んでいたとしても、スケジュールの目的が違うだけで、それぞれのメンバーの対応が変わってきてしまいます。
同じトラブルに対して、どのように違う対応になるのか、例を用意して説明します。
スケジュールのトラブルが発生した時の、お決まりのセリフを使って解説します。
▼納品前に良くあるストーリー例
ある日の朝
他のメンバーよりも早く出社して、スケジュールを確認していたリーダーが、スケジュールの遅れに気づいたようです。
あれ・・・？
今週、α版の提出日なのに、スケジュールが遅れてるみたいだ
間に合わないんじゃないのか？
…どうしたんですか？
なんだか顔色が悪いですよ？
いや、月末納品する予定なんですけど
遅れが出ているようで…
なるほど…、予定よりも１週間くらい遅れているようですね。
まずは、状況を整理して、それからうてる手を考えましょう。
スケジュールの遅れに気づいたリーダーは、早速朝イチで進捗ミーティングを開きました。
そして、お決まりの課題を提示します。
みんな聞いてくれ…、今週末は、α版の提出日である事は、皆承知していると思う。
しかし、スケジュールを見る限り、全体的に１週間程の遅れが発生しているみたいだ…、どうしてこんなに遅れているのか説明できる人はいないか？
ザワザワ…
様々な表情を見せるメンバー…
今回のケースは、７人規模の案件で１週間遅れのシチュエーションです。
『７（人）×５（日間遅れ）』なので、３５日分の作業が遅れている事になります。
なかなか厳しい条件ですが、納品当日に発覚する事を考えれば、不幸中の幸いですね。
それでは、７つの価値観のメンバーが、リーダーの問題提起に関してどのように反応するのかをシミュレーションしてみましょう。人は、ネガティブな問題が提示された時に、その人の本性が見え隠れします。そう言う点に注目してみましょう。
評価重視型の場合
（やばい…遅れが出ている事がバレると、自分の評価が下がってしまう。スケジュールを偽装して、自分の作業は遅れてない事にしよう…。）
評価を重視するタイプは、こういう場合に、残業とかして、あとでつじつまが合えば大丈夫。そういった思考で動く傾向があります。悪質な場合は、スケジュールを改竄し、遅れが出ていないように見せる場合があるので注意が必要です。最悪、納品日になってから「実は、遅れてました…」となるパターンもあります。そうなると、手の打ちようがありません。
納期重視型の場合
（納期を守る為には、当然人手が足りない…、隣のプロジェクトは人が余っていたはずだから引っ張ってこよう。あとは…時間外でみんなにお願いするしかないな）
納期重視するタイプは、安易に時間外での残業や人手の追加で手を打とうとします。納期を守る為であれば手段を選びません。状況によっては、徹夜とかしてしまう場合もあるでしょう。しかし、これだけ頑張っているんだから許してよ…みたいな思考（地獄へ道連れモード）になる場合もあるので、注意が必要です。時間外や徹夜が増えると、思考が鈍ってくる為、割とマインドが崩壊するパターンが多くなります。
品質重視型の場合
（品質が低すぎるのが問題なんだ…、このままリリースしてもどうせ大した売上にはならないだろう、であれば品質の見直し計画を立ててクライアントに納期相談をすべきだ！）
今のままじゃ品質を守ることができなくなる。何とかして納期を後ろにズラせないものか？と思案するのが、品質重視型です。納期は簡単にズラせないので、リーダーの多くは納期までに間に合わせようとするので、方針のぶつかり合いが発生します。
チームの中で綱引きが発生してしまう為、作業効率が悪くなってしまいます。ただ、難しいのは品質を重視するという行為が、悪いというわけではないという事です。案件トラブルに明確な答えはありません。価値観の相違、ズレによって生産性が落ちるという事を理解する必要があります。
問題発見型の場合
（問題が起きるのは・・・まぁ、当然だろうな。その為にスケジュールがあるんだし、この機会に、チームのウミを出し切ってしまおう。）
今回の作業遅れの原因を徹底的に追求して、再発を防止しようと動くのが問題発見型です。その行動自体に問題はありませんが、下手なやり方をすると「犯人探し」によって、チームの雰囲気が悪くなります。問題行動があったメンバーは萎縮してしまいますし、問題がなかったメンバーは痛くもない腹を探られる事になります。
問題を追求するのは後でもできますし、追求する場合も「人」にフォーカスせずに「仕組み」にフォーカスする等の、丁寧な対応が必要になります。
不安解消型の場合
（・・・どうしよう、きっと私のせいだ。私のせいでみんなが残業するのは申し訳ない。二度とこんな事が無いように、スケジュールの見直しを徹底しなくちゃ…。）
不安解消型は、不安になりやすいです。なので、自分が悪くなかったとしても、「自分のせいだ…」と思ってしまいがちです。納期遅れを解消する為には、目の前の仕事を片付けなければいけないですが、スケジュールの精査に没頭してしまうケースも多いです。
指示ベースに落とし込んで、今日のゴールを明確にして作業する仕組みを用意しなければいけません。
効率重視型の場合
（おいおい…、この会議意味あるのか？
全員の手が止まったら、もっと作業が遅れてしまうよ…。せめて会議のアジェンダを示して欲しいもんだな。）
作業は確かに遅れているけれど…この会議は非効率だ。作業を優先して会議に参加しないでおこう。効率重視タイプの場合、無駄な会議避ける傾向にあります。なので、行き当たりばったりで会議する事を非常に嫌います。それによって情報共有レベルが下がり２次災害に発展するケースもありますが、効率型が間違いというわけでもありません。
Googleでは、「会議は３０分まで（途中でも終了する）」「発言しない人は次回呼ばない」「事前に会議内容を共有する」そういうルールで会議が実行されます。無意味にダラダラ会議しない。そういう意識が、これからのリーダーには必要になるでしょう。
労働環境改善型の場合
（え…っ！？まじ？この展開は、週末まで終電コース！？やってらんない。そうだ、私の作業は遅れてないんだから、私が手伝える箇所を時間内に全て終わらせてしまおう。そうすれば、定時で上がれるはず。）
時間外労働を避けるタイプの人は、作業の段取りが比較的上手い人です。ただ、自分の作業が早く終わっても、他の人の作業が追加されるだけだとモチベーションは、極端に下がるでしょう。
なぜなら、全ては余暇優先で動いているからです。時間外労働を封印する事によって、かなり頭を使う事になる為、生産性は高くなります。
ただ、そういう点を評価できない組織にいる場合は、ただただモチベーションが低下して、離職率も上がるでしょう。突然の離職は、チームに大打撃になる為、注意が必要です。
重ね重ね言いますが、今回のケースは、「誰が悪者か？」を解説したものではありません。全ての価値観に間違いはありません。それぞれの価値観が違う方向を向いていると、解決するものもしなくなるという事です。
スケジュール管理の目的を、チームで共通認識する。
今回のプロジェクト
最優先すべきは、納期だ！
トラブルが発生した場合、時間外対応等はもちろん、場合により仕様を一部削る（後回しにする）判断をする。
プロジェクト内には、様々な価値観のチームメンバーがいます。なので、プロジェクト開始前に、リーダーがやるべき事は、スケジュールの目的を明確に打ち出す事です。
どの価値観に合わせるのかは、その時のメンバーの特徴を押さえて判断するのが良いでしょう。
一番簡単な方法としては、「今回のプロジェクトは、納期を優先する」と意思表示する事です。
どんな事があっても、納期を重視する！納期は変更しない！とい強い意志を示しましょう。
実際に、納期を変えるというのは、契約内容によっては損害遅延金が発生するパターンもありうるからです。たとえ、クライアントと強固な信頼関係があったとしても、容易にズラすべきではないでしょう。
多くのリーダーは、不本意ながら、「納期重視」に動かなくてはいけない事が多いです。
もっと良いモノを作りたい…、そう思いながらも納期を重視するのは非常に辛い選択です。ただ、その判断ができるからこそ、リーダーに指名される。そういう側面もあります。マネジメントを志したい人は、心得ておくのが良いでしょう。
困難な課題がやってきたら、それぞれの役割の人がベストを尽くす
クリエイターとして志を立てたなら、もっとクリエイティブな基準で仕事したいですよね。
これから紹介するのは、僕の理想です。
しかし、２０年の中で何度か実現できた事です。
スケジュールは、クリエイティブを高める為にあります。
なので、ほとんどのリーダーは、「納期を守る為に、質を下げる」なんて判断をしたくはありません。
できるならば、前のめりに倒れたいと願っている事でしょう。
では、クリエイティブになるにはどうしたら良いか？それに対して、１つの方法を紹介します。
その方法とは、全ての課題に対して３つの問いかけをするという方法です。
＜クリエイティブになる為の３つの問いかけ＞
その発想は、自由であるか？（Free your self）
その発想は、クリエイティブであるか？（Create your self）
その発想は、限界を超えているか？（Exceed your self）
スティーブ・ジョブズ氏は、クリエイティブを高める為に、「Follow Your Heart and Intuition（自分の直感に従え）」と言いました。
チームで作業すると、自分の思考が何らかのマインドブロックによって閉ざされた考え（クリエイティブでないモノ）に支配されていないかチェックする必要があります。
全ての価値観を活かす選択。
３つのチェックをチームに浸透させてみてください。
今回のトラブルを、もしこの３つの観点で振り返った場合に、どういう結果になるでしょうか？
見てみましょう。
▼先ほどのストーリーも、クリエイティブなチームではこうなる
リーダーとしてのクリエイティブ
リーダーとして、クリエイティブを高めるにはどうしたらいいか？
メンバーの価値観に縛られるのは自由ではない。活かす為のアイデアを考えるべきだ。
その発想は、自由か？：メンバーに少しずつ妥協してもらうのは不自由だ。
その発想は、クリエイティブか？：むしろ、価値観の違いを使って課題を解決しよう。
その発想は、限界を超えているか？：今回の問題を、このプロジェクトだけで考えず、開発部全体の方針として対策を打ち出そう。
トラブルが発生した時こそ、小さくまとまらない事が大事だ。
全員が妥協するよりも、全員の満足を目指す方法を考えよう！まずは、メンバーの意見に耳を傾けるぞ！
トラブル発生時の朝礼にて…
みんなに、今一度クリエイティブな発想を求めたい。
今、みんなが発想しているアイデアは、自由だろうか？クリエイティブだろうか？そして、それぞれの限界を超えたモノだろうか？
評価重視型をクリエイティブ思考にチェンジ！
＜クリエイティブ思考前：Before＞
（やばい…遅れが出ている事がバレると、自分の評価が下がってしまう。スケジュールを偽装して、自分の作業は遅れてない事にしよう…。）
↓ クリエイティブ思考注入！ ↓
その発想は、自由か？：評価を考えて、嘘をつくのは自由がなくなる選択だわ…。
その発想は、クリエイティブか？：商品の質をあげるよりも、嘘をつく事に力を注いでしまっている。
その発想は、限界を超えているか？：自分の評価にとらわれて、商品の質を下げる事になっている…。このままでは、（長い目で見ると）クライアントの評価が下がって、仕事がなくなってしまう。
↓ マインドチェンジ！ ↓
＜クリエイティブ思考後：After＞
仕様の削減は、結果的に商品の質を下げる事になります。
商品が売れないと、長い目で見て我が社の評価が下がってしまう事になるでしょう。
まだ１週間あります。クライアントとの約束（納期）を守る為に、打てる手を考えましょう！
納期重視型をクリエイティブ思考にチェンジ！
＜クリエイティブ思考前：Before＞
（納期を守る為には、当然人手が足りない…、隣のプロジェクトは人が余っていたはずだから引っ張ってこよう。あとは…時間外でみんなにお願いするしかないな）
↓ クリエイティブ思考注入！ ↓
その発想は、自由か？：納期によって、他のメンバーを拘束するのは不自由だ…。
その発想は、クリエイティブか？：人が足りないから追加するでは、クリエイティブとは言えない。
その発想は、限界を超えているか？：自分のプロジェクトだけの事を考えるんじゃなくて、他のプロジェクトの納期も守る方法を考えて提案しよう。
↓ マインドチェンジ！ ↓
＜クリエイティブ思考後：After＞
他のプロジェクトのAさんが担当している技術は、こちらのプロジェクトでも利用可能です。
Aさんを少し借りる代わりに、Aさんが苦手な作業を私が刈り取るのはどうでしょうか？
Aさんも私も、お互いのプロジェクトで、工数を変えずに対応が可能だと判断しています。
品質重視型をクリエイティブ思考にチェンジ！
＜クリエイティブ思考前：Before＞
（品質が低すぎるのが問題なんだ…、このままリリースしてもどうせ大した売上にはならないだろう、であれば品質の見直し計画を立ててクライアントに納期相談をすべきだ！）
↓ クリエイティブ思考注入！ ↓
その発想は、自由か？：リーダーやメンバーのバラバラな品質基準に左右されるのは不自由だ。
その発想は、クリエイティブか？：品質を満たす為、安易に納期をズラすのはクリエイティブじゃない。
その発想は、限界を超えているか？：自分のチームの品質だけを考えるんじゃなくて、部全体の品質基準を統一しよう。クライアントが考えているよりも高い基準にできれば、要望対応もなくなるはず。
↓ マインドチェンジ！ ↓
＜クリエイティブ思考後：After＞
社内のメンバーに品質基準の認識に差ができないように、テスト項目を用意する等して、品質基準を明確にしましょう。将来的に、クライアントの基準よりも高いレベルにできれば、納期間際の要望も減って、スケジュール変更も減らす事ができるでしょう。
問題発見型をクリエイティブ思考にチェンジ！
＜クリエイティブ思考前：Before＞
（問題が起きるのは・・・まぁ、当然だろうな。その為にスケジュールがあるんだし、この機会に、チームのウミを出し切ってしまおう。）
↓ クリエイティブ思考注入！ ↓
その発想は、自由か？：問題が発生して、その対応で職場の空気が悪くなるのは不自由だ。
その発想は、クリエイティブか？：問題が起きてから対処するのではクリエイティブが低すぎる。
その発想は、限界を超えているか？：問題が起きてからではなく、問題が発生する前に防ぐ仕組みを考えよう。またその際に、人の感情を絡めない仕組み（自動化）が望ましい。
↓ マインドチェンジ！ ↓
＜クリエイティブ思考後：After＞
過去のトラブルと、スケジュールの関係を調べて、問題が発生する前に異常に気づけるルーティーンを構築します。部全体で共有し、問題を事前に防げるようになれば、対応工数が劇的に減る見込みです。将来的に、他プロジェクトと協力し、スケジュールから自動でアラート（警報）が出る仕組みを構築します。
不安解消型をクリエイティブ思考にチェンジ！
＜クリエイティブ思考前：Before＞
（・・・どうしよう、きっと私のせいだ。私のせいでみんなが残業するのは申し訳ない。二度とこんな事が無いように、スケジュールの見直しを徹底しなくちゃ…。）
↓ クリエイティブ思考注入！ ↓
その発想は、自由か？：状況の変化によって、いちいち不安に支配されるのは不自由だ。
その発想は、クリエイティブか？：不安だからといって、スケジュールだけで対処するのはクリエイティブとは言えないかもしれない。不安を新たな着眼点として有効活用できないかしら？
その発想は、限界を超えているか？：自分だけの不安にとどめるのではなくて、不安箇所を共有する仕組みを考えよう。そうすれば、同じ不安に悩む人が減るはず。
↓ マインドチェンジ！ ↓
＜クリエイティブ思考後：After＞
私は、人よりも敏感に不安を感じる体質です。
不安に思った箇所を共有する為に、専用のチャットグループを作成します。不安要因を先んじて共有する事で、対策しやすくなりますし、（私のように不安を感じている人は多いはずなので、）後で対応リストをアーカイブ化し、誰でも検索して参照できるようにします。
効率重視型をクリエイティブ思考にチェンジ！
＜クリエイティブ思考前：Before＞
（おいおい…、この会議意味あるのか？
全員の手が止まったら、もっと作業が遅れてしまうよ…。せめて会議のアジェンダを示して欲しいもんだな。）
↓ クリエイティブ思考注入！ ↓
その発想は、自由か？：目先の効率化の為の会議で時間が奪われるのは、不自由だ。
その発想は、クリエイティブか？：非効率だからと自分の作業に没頭するのはクリエイティブとは言えない。
その発想は、限界を超えているか？：自分の効率だけを考えるんじゃなくて、チームや部全体の効率を考えて会議のルールを考え直そう。このプロジェクトで非効率となっても、将来的に部全体の作業効率が上がる方法を考えるべきだ。
↓ マインドチェンジ！ ↓
＜クリエイティブ思考後：After＞
必要のない会議の回数が減るように、チャットグループのルールを整理して、会議しなくても解決できる課題はそちらで解決するようにしましょう。チャットグループで解決した課題と、会議で解決した課題は定期的にアーカイブ化して、会議を実施する時の基準を設けましょう。
労働環境改善型をクリエイティブ思考に
（え…っ！？まじ？この展開は、週末まで終電コース！？やってらんない。そうだ、私の作業は遅れてないんだから、私が手伝える箇所を時間内に全て終わらせてしまおう。そうすれば、定時で上がれるはず。）
＜クリエイティブ思考前：Before＞
↓ クリエイティブ思考注入！ ↓
その発想は、自由か？：時間外で働かない事だけに命をかけるのは不自由だわ。
その発想は、クリエイティブか？：時間外が発生しそうになってから対策するんじゃ、受け身でクリエイティブじゃないわ。
その発想は、限界を超えているか？：自分だけ時間外作業を回避するんじゃなくて、会社全員が時間外をしないで済む方法を考えるべきだわ。
↓ マインドチェンジ！ ↓
＜クリエイティブ思考後：After＞
時間外が発生している子がいたら、その原因をヒアリングする仕組みを設けます。
時間外は、トラブルの一番最初の予兆です。なので、私が先んじてそこに手を打つことで、部全体のトラブル量は、かなり減らせるでしょう。結果的に、全員が定時で帰れるなら、何の気兼ねなく仕事おわりの時間を楽しめるわ♪
メンバー全員がクリエイティブ思考で挑めば、頼もしいチームになる
いかがでしたでしょうか？
全員が頼もしく感じませんでしたか？
クリエイティブ思考は、非常に建設的なポジティブ思考と言えます。こういうマインドのチームだと、ものすごくいい仕事ができそうですよね。
メンバーの価値観が違っていても、「スケジュールは、クリエイティブを向上させる為のもの」という思考で満たされた時、凄まじい力となります。
最初に紹介したのは、価値観の違いによるズレの一番悪い部分でした。悪い相乗効果が生まれるのは、いつだってクリエイティブが欠如した時です。自由で、クリエイティブで、常に自分の限界を突破しようとする人が集まった時、かなりすごい事が起きます。
実際、そういうチームを組めた事が何度かありましたが、作ったゲームはヒット必ずしました。
ビギナーズラックというか、お互いの事を知らない時にそういう事がよく起きていたように思います。お互いに緊張感を持つという点が良いのかもしれませんね。
スケジュールの変更よりもクリエイティブに時間を使いたい。
ゲームの質を上げることに時間を使えば、トラブルを減らす事ができます。
質が良くなれば、仕様変更も少なくすみますし、要望も起きづらくなります。逆に質が悪いと、不具合が頻発し、無駄な工数が発生してしまうでしょう。
どうせ同じ時間を使うならば、クリエイティブにかける時間を増やしたいですよね。四方八方から怒られながら、全員が妥協する案を推進するって、やっぱり辛いんですよ。
そんな事よりも、全員が力を出し切った結果、納期通りに開発できる。そういう開発の方が、メンバーの能力は上昇しますし、離脱率も減るでしょう。
全員がイキイキ仕事をしている。
その為に、クリエイティブは必要不可欠です。
プロジェクトチーム内の問題によって発生するスケジュール変更は、クリエイティブ思考を高める事でかなり防ぐ事ができます。
＜内的要因のトラブル例＞
・質が低い（面白くない）
・メンバーの変更・追加が多い
・特別な技術を持ったメンバーが別プロジェクトへ移動
・メンバーの急な退場（離職・怪我・病気）
・技術的に困難な事が発覚…、想定していた方法で対応できなくなった
少し長くなりましたが、内的要因によるスケジュールの遅れと対策は以上です。
ほとんど９割のトラブルは、内部の問題から発生するものなので、これまでの対策で対応可能だったりするんですが、残り１割のトラブルにも目を向けなくてはいけません。
それは、外的要因によるスケジュールの遅れです。
チームや同じ部内に収まらない、他部署や社長、クライアント、スポンサー、版元等
様々な要因によって、スケジュールは遅れるので、外にも目を向けなければいけません。
１割ですが、インパクトは非常に大きいからです。
外的要因：スケジュール管理してるのに、想定外のトラブルが多い
プロジェクト外の要因によってスケジュールが遅れるリスクも、山ほど存在します。
そのうち先に解説したクリエイティブの向上で乗り切れるものは多いですが、それではどうしても乗り切れないものも存在します。
・クライアントからの要望
・スポンサーの意向
・版元からの指摘
・自然災害による環境の変化
・重大な事件による世論の変化
これらは、一方的に発生するので、スケジュール変更を避ける事はできないでしょう。
メンバーの努力で防げるものもあるけれど、防げないものもある。そういう認識を持つという事も時には大切だという事です。ただ、これらのことは、そんなに頻繁に発生しない事なので、対応方法をアーカイブに残す手間もそこまでかかりません。全員で共有する事で対応しましょう。
▼コントロールできないものがある。それを知るだけでチームは強くなれます。
スケジュールのトラブルは、情報共有で減らせる
スケジュールのトラブルを、クリエイティブなセンスで乗り切るのは難しいですよね。
センスの良いメンバーが揃っていればそれで対応できますが、現場ではなかなかそうはならないと思います。まだ経験の浅いメンバーが参加していたり、他の案件と兼任で対応していて余裕がない人もいるからです。
そういう場合に、諦めるだけしかないのか？
と思う方もいると思います。
諦めるのは早すぎます。パフォーマンスが低くなっているチームでも、トラブルを事前に防ぐ方法はあります。私は、複数のラインを同時に管理していたので、かなりパフォーマンスが下がっていました。
学生あがり直後なんかは、スキルもそこまで高くなかったです。
では、どうやって乗り切れば良いのか？
その鍵となるのは、「トラブルの内容と対応方法をどのように残して共有するか？」となります。
スケジュールのトラブルを未然に防ぐには、過去プロジェクトの情報共有が必要です。
情報共有をする上で頭に入れておくべき３つのポイントを紹介します。
- スケジュールが遅れる原因のほぼ９９％は、初動のミス
- スケジュール変更が発生したら、チームの問題と捉える
- スケジュール変更した原因は、チームの宝と考える
スケジュールが遅れる原因のほぼ９９％は、初動のミス
スケジュールが遅れる原因の９９％は、初動のミスによるものです。解説した「内的要因」と「外的要因」によってスケジュールが遅れるのですが、終わってみて反省会を実施すると、計画段階で対策可能なものばかりだという事に気づけるものばかりだからです。
つまり、過去のアーカイブを分析して共有する事で、それ以降の他の案件のスタート時に対策可能なのです。初動のミスを防ぐ為に、チーム一丸となって情報を残せば、トラブルによって苦しい思いをする人を減らすことも可能です。
逆に、何の情報も残さないと、なぜこんなに問題が発生するのかが理解できず、一生苦しむ事になります。そんな場所に人が居続けるわけはないので、離脱者も増えるでしょう。そうなると、よりチームの状況は悪くなってしまいます。
メンバー間の信頼を築くには、時間がかかります。そのあたりを理解して文化を形成しましょう。
トラブルのほぼ９９％は、初動の動きで対策可能である。トラブルが発生したら、次回防ぐにはどうすべきか？という視点で情報を残す。
▼早めに行動したい人は、こちらの記事もどうぞ
スケジュール変更が発生したら、チームの問題と捉える
スケジュール変更は発生するものですが、それを個人のミスと捉えると、空気が悪くなってしまいメンバーのパフォーマンスが低下します。
トラブルを、チームの問題と捉えて作業ルーティーンや、ルールの見直しをしましょう。
ただ、宣言するだけでは、なかなかなくならないので、プロジェクトで発生したトラブルは、「チームの問題である」と周知し行動で示しましょう。
プロジェクトの振り返りを通じて、「次に活かせる」という点でメリットを感じるように、文化を形成していきましょう。
個人に責任を押し付けない。トラブルには、チームとして対応する。
▼チームで乗り切りたい人は、こちらの記事もどうぞ
スケジュール変更した原因は、チームの宝と考える
何らかのトラブルが発生し、スケジュールが変更された場合、その原因は宝物であると認識しましょう。もし、スケジュール変更の原因が特定できて、今後それが発生ない場合、その恩恵は計り知れません。
１つのプロジェクトで５日間短縮できるとしたら、その後１０件で再発しないだけで５０日分の短縮になりますし、回数を重ねるほどに、その精度が上昇していきます。
これは、チームにとってかなりの利益になります。
プロジェクトの問題は宝と捉えて、細かく情報を残すようにしましょう。
クラウドでスケジュール管理する等して、過去事例を検索できるようにしておくと、情報が残りやすくなります。
過去のトラブルは、オンラインで共有する文化を作る。情報を残す事が、将来のメリットにつながる事を実体験する。
▼失敗から思いつくアイデア
はい！前半終了でーす！！！！！
スケジュール管理に関する「マインド面」がようやく終わりました！前半戦終了です！
ふぅ、お疲れ様でした。
ここまでで前半終了です！
・・・ながっ！！
ちょっと、長すぎない！？
いやいや、まだまだ語り尽くせぬものがあるんです。。。
でも、泣く泣くここまでになっているんです（泣）
まだ、前半戦なんでしょ！？
どれだけ書くつもりなんだよ！
ここまで読めたあなたは、かなりマッチョです。
勉強への意欲を感じますね♪
多分、ここまでに９０％の人は離脱してるだろうね。。。
でしょうね。
でも、とても大切な事なので、丁寧に解説しました。
ここからは、より具体的なスケジュール管理の方法について解説していきます。
それでは後半戦！元気よくいきましょう！！
仕事のスケジュールを作成する。管理する。
スケジュール作成の順序に関しては、様々な人のやり方があります。
ここでは、僕のやり方を解説します。まずは、１から１０までやってみて、その上で自分なりに強化するもの、省略するものを選択するのが良いでしょう。
スケジュールを作るといっても、やらなければいけない事は山ほどあります。
それらを一度にやろうとすると混乱してしまうので、順番にやっていきましょう。
今から紹介するスケジュールの立て方は、これまでの２０年間で実際に開発しながらインプットや改善を繰り返してきた方法になるので、その通りにやってもらえると試行錯誤の時短になります。
これまで解説してきた事のおさらいにもなりますので、１つずつ丁寧に進めていきます。
＜スケジュールの作成と、運用手順＞
- 要件の確定
- メンバーの確定
- キックオフ
- 作業（タスク）の洗い出しと分解
- 作業時間の見積もり
- 優先順位の設定
- 期日の設定
- スケジュールのレビュー
- 開発中の記録
- 進捗確認
- 品質チェック
- 納品
- 反省会
1.要件の確定
要件が確定するタイミングは、クライアントと契約を終結した時です。
正式に契約書を交わさなくても、発注書と呼ばれる１枚の紙で契約が成立する場合もありますし、メールや口頭での発注になる場合もあります。（口頭発注：電話などの会話だけでも契約は成立します。法的に守られます。）
提案書や、要件書と呼ばれる書類に対応すべき内容をまとめて、工数積算し金額を提案して契約を確定させます。場合によってはコンペと呼ばれる手法で、他者とプレゼンで案件を取り合うといった事も発生します。
ここで注意すべきなのは、契約が成立するまでは、開発はスタートさせないという事です。見積もり時に技術調査をする事もありますが、その場合は「技術調査」という名目で案件化した方が良いでしょう。
ゲーム案件の場合ややこしいのは、「面白い」や「売れる」という要件が含まれている事です。
それ自体が曖昧で、後でトラブルに発展しやすいので、極力定量目標（数値目標）を盛り込むようにしましょう。
社内での認識と社外の認識を合わせる為に、サウンドのイメージやグラフィックイメージを共有する等して、完成のイメージを擦り合わせる事が大切です。
会議した内容に関しては、議事録という形で残しメールで送付して、お互いに後で確認できるようにしておくと、トラブルになった時に助かります。
※エンタメ業界では、会社間のトラブルは割とあります。裁判まで発展する事は稀ですが、弁護士を含めて話し合いというのは良くあります。その時に、契約からの経緯を時系列で並べやすくしておくと非常に便利です。
要件漏れが発生しないように、細かくヒアリングするという事、また、その時の状況をメールや議事録で残しておくという事が大切です。ここが狂ってしまうと、スケジュールも意味がなくなってしまうからです。
プロジェクトのトラブルは、ほぼ全てこのタイミングで決まります。
ここで対策をとれていればトラブルは発生しません。
もしトラブルが発生した場合は、このタイミングで何をしていれば防げたのか？という点で話し合うようにしましょう。
2.メンバーの確定
要件が定まったら、メンバーを確定させます。というのも、担当するメンバーによって、対応スピードが変わるからです。
見積もりをする人と、実際に開発する人は、同じであれば良いですが、違う事がほとんどなので、見積もり意図等をヒアリングするようにしましょう（次の工程のキックオフに参加してもらうという手もあります。）
技術や経験を加味して、参加メンバーの役割を明確にして下さい。
各担当者に、相談相手（メンター）を設定するのを忘れないようにしましょう。参加メンバーがそれぞれ相談できる人を設定してください。
スケジュール作成するのも、運用するのも、一人で悩む人を作らないようにするのがコツです。
プロジェクト開始時にメンバーが決まっていない事もありますが、それによるリスクを話し合い。いつまでに確定しないと納期に間に合わなくなる事、プロジェクト内外のメンバーに共有しておきましょう。
どんな会社であっても、メンバーが確定せずにプロジェクトが開始する事がほとんどでしょう。都合よく開発者がフリーである事は無いからです。
不確定要素の解決をする。その為に、プロジェクトリーダーは存在しています。
3.キックオフ
プロジェクト開始時に、担当メンバーを集めてミーティングをします。
サッカーのキックオフ（試合開始）と同様に、契約終結を内外に知らしめる為のミーティングです。
ミーティングの目的は、「プロジェクトの要件（目的）」と「チームメンバーの構成」「直近１・２週間の予定」を共有する事です。
場合によっては、スケジュールを作成した後で実施する場合もありますが、ミーティングが長くなってしまうのと、情報共有は最速でするの原則の元先に実施する事をおすすめします。
現段階でプロジェクトの「リスク（問題点）」を話し合い記録しておくようにします。時間は３０分程度で収まるように、あらかじめ資料を展開しておくと良いでしょう。
意外とよくあるのは、契約を結んでいないのにキックオフをするケースです。
この場合、契約が終結できなかった場合のリスクが大きいのでやらないようにしましょう。
作業が無く暇をしている開発メンバーがいる場合は、別の優先度の高い技術研究をする方が良いです。
4.作業（タスク）の洗い出しと分解
開発に必要な作業を洗い出します。
作業の洗い出しは、決めた役割毎に必ず担当者が実施して下さい。自分の作業は自分で管理するのが、トラブルを少なくするコツです。（人が作成したスケジュールは、責任が発生しづらいです。）
また、要件書や見積書をそのまま使うようにしましょう。（タスクの名前等が変わると管理しづらくなるからです。見積もりした人とスケジュールを作った人が違う場合が多いので、見積もりした人が分かるようにしておく事が重要です）。
要件を１つずつ見ながら、作業に抜け漏れがないか確認していきます。（見積もりは、忙しい時期に片手間で実施する事も多く、抜け漏れがあるものとしてみる事が大切です。）
タスクを洗い出す時は、成果物（アウトプット）を明確に記しながら１つずつ確認してください。
仕様書を作る場合なら、仕様書。
ゲームデータを作る場合は、何のデータを作るのかを明確にしましょう（できれば作成するファイルの名前をあらかじめ決めておくのが良いでしょう。名前は適当に決めずに、一定のルールにそって命名すると劇的に管理しやすくなります）
アウトプットと紐づいていないタスクは、進行に曖昧さを生みます。終わっているんだか終わっていないんだか分からなくなり、進捗状況が確認しづらくなりスケジュール遅れに繋がります。
作業が洗い出せたら、スケジュールを組み立てる前に、メンター（相談役）にレビューするのが良いです。
タスク（作業）を大量に洗い出すと、それ自体に満足しすぎてしまい「内容の精査」ができていない事があります。第三者の目を入れて抜け漏れが無い事を確認しましょう。
5.作業時間の見積もり
１つのタスクに対して作業日数を割り振っていきます。
作業内訳を箇条書きにして、各作業の目安時間（０.５時間単位）を書いていきます。
１つのタスクが３日から５日等、長期間になると、今度は「どんな作業をするのか？」が曖昧になります。１つのタスクの中にやる事リストを記載し、それぞれに目安の時間を記載し、管理しやすくしましょう。
作業時間を設定すると、作業の抜け漏れに気づく事もあります。その場合は、タスク（作業）を追加しましょう。
作業時間が設定できたら、再度メンター（相談役）にレビューして内容を精査します。この時に、当初の予定（見積書の工数）と違う内容が出てきたら、リーダーや見積もり担当者に共有し、協議した方が良いです。
予定と違う場合、前提条件が間違っている可能性もあるからです。前提条件の間違いは、早めに潰しておかないと大きなトラブルに発展しやすいです。
メンター（相談役）にレビューする際に、リーダーや見積もり担当者を混ぜるのも手です。
ここで相違箇所を共有できてなくて、間違った前提条件で進行すると高い確率でスケジュール遅延につながります。
6.優先順位の設定
作業（タスク）の優先順序を決めます。見積もりする際に、作業順に項目を出しておくと非常にスムーズです。優先の基準は人それぞれなので、まずは自分の基準で優先をつけるようにします。
具体的に何をするかというと、各タスクを実施する前に実施するタスクを明確にするという事です。（例：タイトル画面のデザインをする際に、タイトル画面の画面仕様書がないと作業できない 等）
＜優先順位の判断基準＞
・見積書の並び順で作成した場合に詰まる部分が無いか確認する
・作りやすいものから作る
・技術的に難しいものから作る
・実現できるか分からない（検証が必要）なものから対応する
・他の人にふれないもの（自分しかできないもの）から対応する
優先順位を設定できたら、メンターと優先順に関してレビューを行ってください。これも、第三者にレビューする事で担当者の判断力の良し悪しが鍛えられます。スケジュール管理は、「判断力」が高い人が多くなればなるほどトラブルを回避できるようになります。教育機会と捉えて、積極的に任せるようにしましょう。
優先順位を考える段階でも、作業の抜け漏れを発見する場合があります。
そういう場合は、必ずメンターやリーダーに共有して追加しましょう。
このあたりの情報を共有する事で、見積もりの精度も向上します。
7.期日の設定
作業の洗い出しができて、作業優先が決まれば、あとは作業順に並べるだけでスケジュールになります。スケジュール管理ツール（microsoftのProject：有料ツール）を使えば、この時点でガントチャートが自動生成できるので積極的に使用しましょう。
エクセルで作成しようとすると「見た目」に工数を使ってしまうケースがあるので注意が必要です。無駄に時間が必要ですし、変更するたびに修正工数もかかるので、極力見た目を良くする為に時間を使わない環境にしておく事が大事です。
作成目標とデッドライン２つの期日を設定するのがおすすめです。
１つ目の期日：オールインの確認
２つ目の期日：品質の確認
もし、１つ目の期日をオーバーしても、２つ目の期日までの期間がバッファとなり余裕が生まれます。
期日を設定し終わったら、メンターにレビューし、最終チェックしましょう。
メンターへのレビューが後半になるにつれ、作業漏れが出てくる頻度は低くなりますが、もし発生した場合は、なぜその時点まで気づけなかったのか確認しておくとベストです。
期日にバッファ（余裕）を作りすぎると、チリも積もれば山となり、最終の納期に間に合わない事も発生してしまいます。そういうのを事前に発見できるのも、スケジュールの良い所です。
8.スケジュールのレビュー
スケジュールが出来上がったら、プロジェクトに参加する人を全員集めて全体にレビューします。
レビューするポイントは、当初の予定（見積もり書）との相違箇所をメインに共有します。
各担当者がスケジュールを作成した際に見つけた相違点は、他の担当者にも影響を及ぼすからです。
レビューには、各担当者のメンター（相談役）も同席し、相違箇所や各ステップでの判断基準を共有する事に集中しましょう。
スケジュールで発生するトラブルの原因第１位は、「スケジュールを共有できてない」です。
この時点で共有できていない事が原因で、納期遅れは発生します。
・タスクが共有できてない：誰が何の仕事してるか分からない
・アウトプットが合意できてない：何ができているかが明確になっているか？
・期日が合意できてない：担当者とリーダーが納得した期日になっているか？
スケジュールの共有できていないと、ヒアリング作業が増えます。初期段階であれば対応可能ですが、納期間際の忙しいタイミングだと疎遠になりやすく、大きなトラブルに発展します。
このタイミングで意外と多いのは、担当者が割り振られていない作業です。
このレビューが終了した時点で、担当者不在の作業や、アウトプットが曖昧なものがないようにします。
9.開発中の記録
スケジュールがレビューできたら、スケジュール作成の段階から、スケジュール運用の段階に切り替わります。ここまでの準備ができていると、自分の担当している作業に集中する事が可能です。
スケジュール運用ですべきことは、「毎日の実績を記録する」という事です。
作業を実施したら、そのタイミングで記録していきます。（スケジュールをオンラインで管理すると、実績がオンラインで抽出できるようになり、プロジェクト終了時の分析が楽になります。）
また、スケジュールはオンラインで管理する事で、作業効率は非常に楽になります。
誰がいつどんな作業をしたのか？どういう対応をしたのか？を、各タスクに記述して共有する事で、進捗をヒアリングで確認する必要がなくなります。
また、同時にスケジュールを触る事ができるので、スケジュールをマージする作業も不要になります。
スケジュールを、エクセル等のローカルファイルで管理すると、各担当者が見やすく独自改良してしまう為、状況の確認が難しくなります。必ずオンラインで管理するようにしましょう。
10.進捗確認
朝、簡単なミーティングをする等して、その日に各担当者が実施する作業を共有しましょう。
また、１週間に１回は、メンター（相談役）に進捗状況を報告し、対応の遅れが発生している部分に関して相談しましょう。
進捗確認の目的は、早い段階でトラブルを見つける事になります。担当者レベルでは（経験や実績が少ない為）、トラブルの種を発見できる事は稀です。
なので、必ずメンター（相談役）にレビューするようにしましょう。
時間は１０分程度で十分です。
コツは、担当者が主導権を握り説明するということです。
作業の曖昧な部分や問題がある部分は、絶対に説明に詰まります。メンターは、そこを見逃さずにサポートするようにして下さい。この時、「人格否定」したり「責任追及」したりしない事が大切です。
心理的安全性を確保する事により、担当者とメンターの信用や信頼が溜まり、社内の風通しも良くなります。
スケジュールでトラブルを抱えた場合、一人でなんとかしようとしてしまう人が多いです。
それだと問題の発覚が遅れてしまうので、第三者を入れることが大切です。
一人で悩まない環境を作る事で、自然に教育機会も増えます。
11.品質チェック
成果物ができたら、品質をチェックします。
ゲームの場合は、デバッグと呼ばれるテスト作業がメインになります。
※テスト項目に関しては、仕様書を作成したタイミングでどんなテストをするのかを決めておくと効率が良いです。
プロジェクトが納期に近づくにつれて、テスター（デバッグをする人）を１人ずつ増やす事で、プロジェクトの安定感は増します。
当初予定していた品質基準を満たしているかを事前に確認する事で、納品時のトラブルも減らす事が可能です。スケジュール作成のタイミングで、品質基準を明確に決めておくのもおすすめです。
品質基準は、数値目標と、数値化できない目標を両方設定しておく事が大切です。
曖昧な基準も用意しておく事で、担当者も思考停止に陥りづらくなります。品質は、人によって基準は違います。最終的にそれを見る事になるお客さんの基準はさらに多岐にわたるので、沼にハマってしまう事もあります。そうならないように、ターゲットを明確にしておく事が大切です。
ターゲットは、「ペルソナ」を設定するという方法がオススメです。
実在しない顧客の個人情報を作る事を「ペルソナ」を設定すると言いいます。
SNS運用をする人には馴染みのある言葉です。
「３０代 女性 OL 性格 趣味 ライフサイクル」等を設定し、開発中のゲームをプレイした時に、どのように判断するかを考える事で、当初の目的からズレていないか確認する事が可能です。
このペルソナは、企画時や提案時に決めておきましょう。
ペルソナに名前を設定すると、よりイメージしやすくなり
当初のコンセプトもズレにくくなります。
12.納品
クライアントと決めた納品日に納品物をまとめて提出します。
この時に、納品物のチェックを行い、どんなチェックをして提出したのかを記録しクライアントに開示します。このチェックをしておくと、動作しないゲームを提出してしまうようなミスを防ぐ事が可能です。
割と多いのは、「納品物が揃っていない」です。
納品日は、バタバタしている事も多く、簡単なミスが発生しやすいです。
極力、第三者にチェックしてもらうようにしましょう。
最低限、納品物が揃っている事と、起動確認してから提出します。スマホアプリの開発であれば、どの端末でチェックしたのかを書いておくと良いです。
もしトラブルが発生した場合に、納品時の状況が資料として残っているだけで、クライアントとの信用を落とす事はありません。少なくとも、納品時には問題がなかった事はお互いに確認しているので、問題解決に協力できます。
ここで、雑に提出している場合、なぜ発生したのかを説明する責任と、どういう対策をするのかを報告する必要が出てきます。なぜ発生したか？については、数日前の事であれば問題ないですが、数ヶ月前の事であれば誰も覚えていません。
誰がいつ、どんな状況で納品したのかが分からない為、調べるのに数日必要になります。また、原因がわかればすぐにどう対応するかを検討しなければいけません。クライアントへ報告をあげるまでに、かなりの時間を使う事になります。
納品トラブルが発生したら、どれくらいの時間を使っているか記録するようにしておきましょう。その時間が多ければ多いほど、納品時のチェックに時間をかける方が楽である事に気づけるようになります。
13.反省会
プロジェクトを納品し、代金を支払ってもらったらプロジェクトは完了です。
プロジェクトが完了したら、反省会を実施します。
当初の予定からどのように変わっていったのかを共有する事で、さまざまな気づきを得る事ができます。
スケジュールをオンラインで管理しておくと、この反省会で気づいた事を完了したタスクに追記しておきましょう。今後、新たなプロジェクト管理をする際に、他の人が調べられるようになります。
もしこれが残っていないと、ヒアリングする事もできず同じ問題が再発してしまいます。
失敗は全て財産です。
他のプロジェクトで失敗した事を再発させないだけで、開発する商品の質は自然に向上していきます。
反省会は、個人の失敗を責める場所ではありません。
失敗は宝だ！という意識でなんでも話し合える環境を作ることが大切です。
スケジュール作成の応用技
スケジュールの作成とスケジュールの運用を一通り解説してきましたが、スケジュール管理はこんなにスムーズには進行しません。
なぜなら、プロジェクト進行中は本当に様々な事件が起こるからです。
地震、雷、火事、親父、ゲーム開発をしていると、本当に理解できないような事件が起きたりします。自然災害によって、ゲームの発売が中止されるなんて事もありますよね。そういうどうしようもないトラブルもありますが、どんな事が起きてもゲームを完成させるのが、ゲームクリエイターに求められる力です。
建設的に、前向きに対応する為には、基礎的な知識や対応も必要になりますが、イレギュラーな方法も知っておいて損はありません。
型にハメようとしすぎるあまり、柔軟な思考を失ってしまう場合もあるからです。ここから解説するのは、型にハメないスケジュールに関する応用技です。基礎を抑えるという事を前提で紹介するので、取り扱いにはご注意ください。
＜型にハマらない２つの応用技の紹介＞
・詳細スケジュールを２週間分しか作らない。
・スケジュール作成の前に開発をスタートさせる。
詳細スケジュールは、２週間分しか作らない
プロジェクトによっては、要件が定まっていない状態でスタートする場合もあります。
そういう時は、スケジュール変更が発生する事が多い為、全ての詳細スケジュールを作成すると、ロスが大きくなります。（スケジュール変更が発生する度に、スケジュールを作り直す必要が出てくる為）
要件が定まっていないプロジェクトの場合は、直近の２週間分のスケジュールだけ作成するようにします。それ以外のスケジュールは、ざっくりと大枠で定めておきます。（詳細を決めずに進行します。）
プロジェクトを数ヶ月単位に分割する
まずは、プロジェクトを数ヶ月単位で分けて管理します。
要件が定まっていないので、「プロトタイプ版の作成」「本制作」といったイメージになります。
最初から最後まで要件が定まっていない状態だと、とても不安定な開発になるので、最優先は「要件を定める」という部分に注力する方が良いでしょう。
とはいっても、要件が定まっていても「変更」が多発する事が想定される場合は、この方法を使って、ゴール地点を変更しながら開発するのも手でしょう。
プロジェクトを、どのように分割するかも経験と実績が必要になります。
最悪、大海原に漕ぎ出した船が大破して、目的地に辿り着けない…そういう可能性もある方法になります。
直近の２週間分以外の項目は、工数と最終的なマイルストーンのみ
スケジュールは、変更されるものとして詳細まで作らないので、小回りが利きやすくなります。
ゲーム開発の現場では、割とこういう開発の仕方が取られていたりします。
最初から最後までスケジュールが決まった開発の方が珍しいでしょう。
だからこそ、当初想定していない程面白いゲームが作れる場合もあります。ただ、ほとんどの場合は、提案書の面白さに到達できず、迷走に迷走を重ねてしまう。
そういうケースが多いでしょう。
ゲーム開発は、一攫千金の博打要素が強い為、そういう開発でも成立してしまうので、面白くなるまで開発し続ける…そういうマッチョな開発スタイルの会社もあります。
昔は、発売後にバージョンアップができなかったので、面白くなるまで開発し続けるスタイルが主流でしたが、今は、とりあえず公開して、バージョンアップで面白くするゲームも非常に多いです。
スケジュールより先行して開発を進める
スケジュールができる前に開発メンバーがたくさん参加する場合、スケジュールができるまで待っていると、開発メンバーを遊ばせてしまう事になります。
開発メンバーが綺麗にハマらない事の方が多い為、ほとんどの場合は、スケジュールができる前に開発がスタートするでしょう。
そういう場合に、リーダーやプランナーと呼ばれる人が、何らかの作業を一生懸命作りながら進む事になります。技術的に不明要素が多い場合に、先行して調査したり、確実に発生する事がわかっている作業から始めていきます。
要件やメンバーが固まっていない状態でスタートする事がほとんどだから前向きに対応
全てのプロジェクトは、スタートするタイミングや状況が異なります。
毎月月初にスタートする等、発生日が決まっているプロジェクトは、「ソーシャルゲームの運営」等、ルーティーン化されたものくらいでしょう。
なので、その為にリーダーやプランナーが存在していると考え、建設的なアイデアを出していく事が大切です。想定外の事や、うまくいかない事を嘆いても前に進めないからです。
もし、このタイミングで、ため息をついたり、後ろ向きな発言が多い場合は、プロジェクトから外れてもらうのも手でしょう。そういう人がいるだけで、プロジェクトの進行は悪くなるからです。
ため息をたくさんついている人がいたら、個別にヒアリングしてサポートしてあげるのがいいですよ。
多めに案件を受注しようとするから、コントロールしづらくなる
チームメンバーが多い程、安定的な収入源の確保が必要になります。
すると、発生するかどうか分からないようなプロジェクトに対しても、受注を獲得する動きを取らざるを得ません。すると、プロジェクトが集中してしまったり、逆に分散してする事がなくなってしまったりします。
１つのプロジェクトが終了するタイミングで、次の案件が決まっている事が望ましいので、何かの案件がクライマックスのタイミングで、いくつか新しい案件が立ち上がる事が多いでしょう。
新規プロジェクトは、立ち消えや、開始まで時間がかかる場合が多いので、振り回される事も増えるでしょう。メンバーに空きが出ると赤字になるので、案件は多めに受注する動きになりがちです。
それらの要因の一つ一つが、不安定な開発環境を作ってしまいます。
スケジュール管理は、何のトラブルもなく進行させる事はできません。
何が起こるか分からない時代だからこそ、コントロールできる部分はしっかりとコントロールする為に、基礎的なスケジュール管理のノウハウが必要なんです。
スケジュール管理のポイント まとめ
お疲れ様です。
ここまで長い記事を、よくぞ読み切りました。
スケジュール管理の方法は、本当に様々です。１００社あれば、１００通りの管理方法がある事でしょう。ここまで詳しく解説する記事を書いたのは、僕自身試行錯誤の２０年間だったからです。もし、これからゲーム開発を始める人が、それを１からまた実践するのは勿体無いので、僕が得た知識を共有する事にしました。
プロジェクトの管理をする時に、一番大切にしなければいけないのは、クリエティブに時間をかけるという事です。トラブルに振り回されて時間を、精神を、体力をすり減らすべきではありません。
そうならない為に、スケジュールを正しいルールに乗っ取って管理するべきです。
やり方は違っていても、「記録」さえできていれば高速で改善する事が可能で、尚且つ成長を実感する事ができます。
そして、「情報共有」ができていれば、１つのチームの失敗をすぐに共有する事ができ、他のチームの失敗を減らす事もできるでしょう。
全ては、世界のゲーム開発が、より良いものになるように。そういう意識で書いたので、参考にしてもらえたら嬉しいです。
スケジュール管理の煩わしさから解放し、クリエイティブの質を向上させましょう。
・スケジュールは、変更が発生するものという認識を持つ
完璧なスケジュールを立てて、自己満足に浸らない
・初動の動きに注意する
できるだけ多くの人を巻き込み、チェックする目を増やす
・トラブルは、個人の責任にせず、チームの責任にする
メンターを配置する一番の理由はそこにある
・終了後に、振り返りを行う
失敗は宝物、チームで情報共有する
↓ゲームクリエイター（ゲームプランナー）を雇ってみませんか？
コメント