グレンジ Advent Calendar 2019 10日目を担当させていただきます woki です
新卒から３年間cocos2dxのネイティブエンジニア
その後、１年ほど開発ディレクションを経験し
現在では開発ディレクションと実装を7:3くらいの割合で行なっています
昨年、エンジニアから開発ディレクションへのチャレンジについて泥臭くやってる記事を書かせて頂きました
「手を動かさない奴は要らない」という雰囲気のプロジェクトで「 手を動かさない奴が生まれた」理由
うわっ改めて見るとすごい長いし読みづらい
今回も引き続きディレクション周りのあれこれを書こうと思います
背景
前年度、チームは様々な経験を経て雨降って地固まり、
本当の意味で手を動かさない奴が要らないプロジェクトになる日は、もうすぐそこまで来ているのかもしれない。
と盛大なフラグを立てていましたが...バッチリ回収しました☆ミ
突然ですが、
皆さんの現場では、見積もりもできない状態の仕様(アイデア)が展開された
肌感で1~3週間はかかりそうだが、開発期間があと1週間しかない。みたいな状況ありませんか？
我々にはよくあります
そんな時、
技術力はもちろんのこと、他セクションを巻き込みつつ、仕様を詰めて取捨選択を行い、最後には気合で、 なんとかリリースにこぎつけてくれる人 はいませんか？
我々にはいます!
...そんなエンジニアが２人、年明け早々に プロジェクトを離れることになりました
（サーバー１人とクライアント１人）
しかし、我々はたった4時間で本音で語りあえるチームになるためにやったこと をやったチームだ
これくらいで揺るぎはしな...だいぶ揺らぎました
アプリやその運用に造詣がありこのプロジェクトに長らく関わっていた２人だったので
単純な頭数の問題ではなく、企画を練る時間が十分に取れない中で展開された ふわっとした内容から、懸念点の洗い出しや運用を想定した設計を広い範囲で考えることができる人が減った ことに大きく影響を受けました
無理がきかなくなった分、チームは より詳細な仕様と綿密なスケジュールの管理 を必要としましたが、新機能や新スキルの開発以外にも運用タスク（イベントのキャンペーンやダンジョン設計など）を積まれているプランナーは首が回らなくなっていきました
そこでプランナーの負担を減らすために企画の進行管理や仕様書などの作業を減らすことを考えたのですが、これが結果としてアジャイル開発宣言のようなものになりました
アジャイル開発のようなもの宣言
ポイントだけ掻い摘むと下記の内容を開発メンバーに展開しました
プランナーがディレクションをしなくなった分はチームで補います
決裁者への当てはチームで判断を仰ぎ、仕様の判断やスケジュールもチームで管理します
これまでスケジュール管理や決裁者とのトレードオフについてはプランナーがやるというのが明確に決まっていたというよりは、企画をするのだから当然やるのだろうという暗黙の了解がありました
が、今回からプランナーがまとめて当てるということを必須にしていません
レベルデザインに関わってくるのでプランナーもメンバーにいることもありますが、 チームのメンバーなら誰でもその仕様に決めた理由が話せる状態 を目指しました
例えば、クエスト中の状態異常ターン数可視化については、まずUIデザイナーが仕様書の代わりに画面の構成を画像で作り、その挙動についてはエンジニアと相談して決めます
ユーザビリティ的にはこうしたいけど、工数的にはこっちの方が安いと行った判断もここで行い、チームで決めたことを決裁者に当てます
これがアジャイルソフトウェア開発宣言 のようなもの です
これまでどちらかというとウォーターフォール式に近く、先に仕様を固めてから開発する傾向にありましたが、判断をチームで任せるようにしたことで 強く決めて実行時間を稼ぐ ことが難しくなると考えたので、出来るだけ 迷ってる時間をなくして判断を早くするために小さく作って確認する ことを意識しました
時にはモックや動画を作って、完璧な仕様書がなくてもお互いが頭の中で描いている完成図に差異ができないようにしています
スケジュールについては特に方針が変わっているわけではないのですが、トレードオフに慣れていないメンバーもいるので、改めて言語化しました
スケジュールの判断には大きく分けて
・ハロウィンやクリスマスなど時期をずらすと機会損失になるもの
・ユーザビリティの向上や時期に関わらないもの
の２軸で考えます
イベントのための機能開発ならば多少無理をして(重要でない機能の削除や暫定対応など)でも間に合わせる必要があり、そうでないならば長く使われるものなので運用やユーザビリティを重視してリスケを考える
といったことです
実際にはイベントのための開発でなくても、イベントによって獲得した新規ユーザの定着が関わってくるので、時期による機会損失は存在するのですが、その影響度が大きく違います
その感覚の共通認識がどれだけ決裁者とチームで持てるかで、この開発フローの是非が問われます
反響
実際はデバッグのためのマスタ設定や関連する仕様を決めたりやっぱり仕様書的なのが必要だったりと、作業が0になるまではいきませんでしたが、なんとかなっている状態になりました
またKPTの際に
元々のスケジュールがイケてないとか仕様が詰まってないからプランナーがもっと早く動くしかないよね
といった 正論のProblemが上がって終わるのではなく、その中でTryできそうなことやKeepの意見が上がる ようになったことが一番の収穫でした
実を言うともっとハレーションが起こると思っていて備えていたのですが、メンバーがとても前向きにに動いてくれて助かりました
セクション問わず行動を起こせる視野の広いメンバーと文化の力を感じました
開発ディレクションとしての進め方
2~3ヶ月近くは全申請施策のキックオフと進捗MTGに入りました
明確にレギュレーションを決めて始めたわけではないので、その都度にこう言う判断の仕方をするとか、この場合はこうした方が良さそうという思想をメンバーに伝えるため
そして、施策が4~6本くらい並走しているので同じ失敗をしないように隣の施策との共有はまとめて共有していました
しばらくするとチームがこのやり方に慣れてきて、各施策でセクション問わず出来る人が舵を取ってくれるようになりました（この空いた時間で実装が出来るようになりました）
チーム全員の稼働が高かったり座組みで適正な方がいなかった場合は舵取りに入ったりしてます
（無理にチームで完結させようとしてません）
チームでの進め方
キックオフでは施策の目的を確認し、その施策の進め方をチームで話してもらいます
まずUIデザイナーが見た目を作った方がいいとか
その仕様だとサーバーに負荷がかかるからこう言う風に変更できないかとか
クライアントで実装すると時間がかかるからまずアニメーターに動画を作ってもらって擦り合わせしたいとか
大抵は1~3日ごとに集まって進捗を確認し、それ以上になりそうな場合は可能であればタスクを分解します
進捗はモックとかでない限りは一部分でもいいので 実機で挙動を確認します
完全な仕様書がないので口頭でここまでできてるなどといった確認をしても、実は当事者間で完成図がずれていたということが稀によくあります
またセクションの繋ぎ目で認識違いが起こることもあります
クライアントは残り素材を差し替えるだけだと思って実装が完了したと思っていたが、想定外の構成をしていて手直しが必要だった等
そういったズレをなくすために 最も効果的なのが現物をチームで確認すること でした
スケジュールについても基本はチームに任せます
あるバージョンをリリースする際にはdevelopにマージする前にプロジェクトメンバー全員が内容を見れるようにレビューする環境を作ります
基本的にはこのレビューを行う日がそれぞれの施策の締め切りになります
全体スケジュールを伝えた後はチームのメンバーにどうやって進めていくかを考えてもらっています
チームメンバーに段取りを考えてもらうことで、何日になんの作業をするという共有が行われるようになりました
このおかげで実は来週サーバーのメンテナンスの準備があって工数を避けないなど、これまで知り得なかった各セクションの稼働状況をチームのメンバーが把握することが多くなり、来週はサーバーが大変だから今週先にこの実装周りをやろうとか、UIデザイナーがバナーの制作で手が空かなそうなのでレイアウトツールの調整はクライアントが巻き取る、などの 助け合いが起こりやすくなりました
残った課題
経験不足からくる課題が多いです
最初に完璧な仕様書を作らないと言っても、当然洗い出しは行います
その中で 最も重要な部分から取り掛かることで、リリースが近づくにつれてシンプルな実装が残るので正確な見積もりができ、トレードオフの判断がやりやすくなる
というのがミソなのですが、最初の洗い出しでそこそこ工数に関わる部分が抜けてしまうことがあります
これに関しては現在も色々試してる最中ですが、ユーザーストーリーマッピングに可能性を感じています
すでに良い記事がありましたので拝借させていただきます
簡単！楽しい！5分でわかるユーザーストーリーマッピング(User Story Mapping)
要件の洗い出しに使う手法なのですが、
ユーザーストーリーマップを作ることが目的なのではなく、その過程で要件についての理解をチームで深めることに重きを置いています
大きな機能開発をする際に、リリーススライスをチームの進捗確認に置き換えて、3日に1回くらい実機で挙動を確認する2~3週間の開発をしましたが、かなりいい感じに機能しました
終わりに
振り返ってみると、昨年は開発フローのことを考え試行錯誤していましたが、今年はチームや人と向き合う１年になりました
昨年はこのプロジェクトにあった最適な開発フローが作れるはず。と踠いていましたが、
スケジュール、人、やりたいこと、が変化していくなか、開発フローだけが変わらずにあり続けるというのには限界を感じました
開発フローを作る。というよりフローを改善しやすい環境を作り、毎バージョン区切りがつく度に少しずつでも試して改善して、前よりちょっと良くなった。と言う感覚をチームで共有し 変化に対応できるチームになる ことが最適な開発フローなのかもしれない