ありがちなスケジュール進行と光景
スケジュールを立てたところで、そのままうまくいくことはない。
なぜか?
- 企画が決まらない
- デザインが遅れる
- できると思ってた技術が、実は落とし穴だらけ
- だいたい仕上がったが、本番用の素材がこない
- ようやく本番用の素材を入れ込み、公開まであと少しの状態で「いま初めて確認したのですが」というディレクターの声
- そこからのエンドレスなデザイン修正
非常によくあるフローである。このフローを正すことも重要だが、必ず遭遇するので自分が対応できる範囲の準備をしておこう。
といいつつ、最終的には根性を出して寝ないで頑張る ところに落ち着くものである……。
ざっくり設計して、適当でいいから工数出す
スケジュールは自分の航路。全体像を把握し、だいたいの到着点を見通してスケジュールを組む。
- ざっくり設計して、作るものがどれほどあるかを把握する
- ↑で出した作るものに対して工数を出す
- デザイン等は何度か直しが入ることを考慮する
- 工数にはテストも含める
- バッファは1.5倍が基本
考えられる範囲では頭を絞りきって想定する。しかし、想定外のことが起きるのは当たり前。作って初めてわかることも多々ある。これが不確実性。
ガチガチのスケジュールの立て方
世の中にはギリギリの案件ばかりで、どれも等しくギリギリの期日が設定されている。
ギリギリを攻めるときは、悩まずフルパワーで進んでいけるようなガチガチのスケジュールを立てよう。
- まず、タスクを洗い出して書きまくる
- ゴールとなる期日を決める
- 週単位でスタートからゴールまでざっくりやることを割り当てていく
-
俺の実装タスク例。NotionでBoardをTimelineViewにするとわかりやすくなる
- 最後に直近1-2週間での詳細スケジュールを立てる
- 例: 月曜
- 10:00-12:00 技術検証
- 12:00-13:00 昼飯
- 13:00-15:00 検証まとめ
- 15:00-18:00 デバッグ用ビューの作成
- 18:00-20:00 バッファ
- 例: 月曜
取り組む順番は不確実性の高いものから
答えがわからないものや、試したことがないこと・検証しながら進める物事は、どれくらい時間がかかるか不透明だ。初めて使う技術を後回しにして検証し、「うまくいきせんでした」ではどうしようもない。
なので、何がわかっていて、何がわかっていないのか を知ることも大事だ。
- 答えがわかりきっていることは後回し
- 不確実性の高いものから取り組む
- 答えがわからないこと = 何度か作り直すことや案をたくさん出すことを求められているとき
- 検証しながら開発するもの
詳しくは 不確実で不安なものから先に手をつけるにて。
スケジュールの答え合わせをする
どうせスケジュールは遅れるし、自分の実装もうまくいかないこともあるし、見積もったスケジュールは崩壊していくこととなる。
しかし、せめて自分のスケジュールくらいは何がよかった・悪かったくらいは把握しておくべき。同じ轍を踏まないように。
マクロとミクロ。全体の体験の検証 VS コアな技術の検証
全体を通して体験しないとわからないこともある。 コアな技術を検証することと、全体の体験を検証することが並列で走るときはどうすべきか? コアな技術がコケそうなのに全体の体験を検証しても意味がない。しかし、全体の体験がクソなのにコアな技術を検証しても意味がない。
そんなときは
- 代替となる技術や解決策の目星をつけておく
- その上で全体の体験を進める
つまり、全体の体験 >>>>>>>> コアな技術 である。
全体の体験を優先すべきなのは、クソな体験にはなんの価値もないからだ。 技術には代替がある。体験の代替を考えるのは骨が折れる。企画はボトルネック中のボトルネック。企画のやりなおしとなると関わるプレイヤーの数も多くなってしまう。体験の根っこの検証を優先できるように、ひとがんばりだ。
まとめ
初めてやることや多くのチャレンジを含んでいたり、プレイヤーが多いと、スケジュールどおりにいくことはない。
だから、自分が対応できる範囲のことは頭で整理して、まっすぐ進めるようにしよう。