「手を動かさない奴は要らない」という雰囲気のプロジェクトで「 手を動かさない奴が生まれた」理由

グレンジでクライアントエンジニアをやっている...と名乗りつつ、ここ半年間コードを書いてない woki です。
グレンジ Advent Calendar 2018 14日目の記事を担当させていただきます。

■はじめに

私は新卒で入社してからおよそ3年間、仕様を設計に落としてC++でコーディングをしていました。
運用タイトルで度重なるアップデートを経験する内に

• MTGを円滑にするための ファシリテート
• 設計をするための 仕様書 (のようなもの)作成
• デスマを防ぐための スケジュール組み
• 仕様のバッティングや競合を防ぐための 開発環境整理とリリースの段取り

などを行うようになり、
コーディングしてるよりもこちらに力を入れた方がチームとしての生産性が上がってる のでは？
ということで、この半年間は開発ディレクションに努めさせていただいています。

この記事は 「手を動かさない奴は要らない」 という雰囲気のプロジェクトで、 手を動かさない奴が生まれた理由 をつらつら書いていきます。
自分のプロジェクトで 皆めっちゃ頑張ってるのにユーザに届けれてるものが少ない 。と感じている場合は手を動かさない奴が必要なのかもしれません。

参考までに
プロジェクトの規模としては各セクション3~6人、全員で50人ほど。
アップデート(Appleへの申請)は1カ月に1~2回ほどのペースで行っています。
またプロジェクトの方針としてトップダウンではなく ボトムアップが望ましいという風潮 があります。

　
※この記事はポエムです。ダイオウグソクムシを見るような気持ちでご覧ください。

■アップデートの流れ

1. PMとディレクターがプランナーに戦略を共有
2. プランナーがメンバーに施策を展開
3. 設計・実装・疎通確認
4. 全体レビュー
5. Feature確認
6. 統合Feature確認 (v2.1.0とか今回のアプデで入るもの)
7. develop
8. staging
9. master

GIT周りのフローはこんな感じ

master
↓↑
staging
↓↑
develop 
↓↑
統合Feature v1.2.0とかでアップデートするものが詰まった環境
↓↑
feature/00001 ハロウィン施策〇〇パッシブスキル
feature/00002 パッシブスキルアイコンをうんたらかんたら
......

ね、簡単でしょ？開発ディレクターなんて要らないんですよ。
っていう綺麗事はこれくらいにして 実際の現場はどうなってるか というと↓

■アップデートの流れ（現実世界）

1. PMとディレクターがプランナーに戦略を共有

PMとディレクターがカレンダーに中/長期を見据えた大枠のスケジュールを引く。

肝試しイベント＆サマーガチャを走らせて、お月見とハロウィンまでの間はアウトゲームの改善系をいれて〜的な。

PMとディレクターからプランナーへ共有し、定数的な目標などを確認する。

ハロウィンガチャでの売り上げはこれくらいを目標としているから強めのパラメータ設計にして〜的な。

こうして次のアップデートに入れるものが決まります。

2. プランナーがメンバーに施策を展開

各施策についてプランナーが詳細を詰めて開発メンバーへ展開。通称キックオフ
大抵はサーバー、クライアント、UI、アニメーションが１人ずつ集まり、プランナーがやりたいことを共有する。
小さい施策は下記のようなペライチでスタートします。

大きいものは数枚に渡ります（生々しくて本物の画像を出せなかった）

既存のモンスターを倒してそのドロップアイテムを得る。だと、コンテンツの消費が激しくて、ユーザのやることがすぐになくなってしまう。
そこで次のイベントでは、倒すモンスターにポイントを付けて、そのポイント数で何か報酬を渡せるようにしたい。
さらに特攻となる武器を追加してポイントをより多く得られるようにして、さらに〜的な。

MTGでは必要な作業の洗い出しをして、その後に調査/設計を進める...と思いきや、これがなかなかどうして進みません。

はじめの頃は、何事もなくMTGが終わるが実装後、 レビュー時に「え、これってなんでこんな風になってるんですか？」 とか 「そもそもこの施策微妙だと思ってたわ」 といった意見が上がり、 根本的な作り直しが発生 していました。

これを経験したことにより、次のアップデートからは 仕様に対するダメ出しと曖昧な部分に対するツッコミ が止まらず、MTGがまとまらなくなりました。
　→ポイントである必要性ある？倒した数とかじゃダメなの？
　→ポイントはモンスターIDに紐付いているの？モンスターが逃げた場合は？
　→パラメータが違うけど同じモンスターIDの場合は一緒？
　→これで継続率あがるとは思えない、もっと〜したらいいのに
　→報酬を受け取る時のアニメーションが全然わからない。これなにで制御されてるの？
　→やることが変わらないから作業感でて辛いんじゃない？ユーザはそれを求めてるの？

そしてMTGで消化しきれない質問は 懸念点の持ち帰りをして再展開のMTG をする。ということを繰り返すことになり、その結果として 開発期間が十分に取れない、でもスケジュールはずらせない 、よって下記のような状態になります。

• 暫定対応による今後の メンテナンスコストの高騰
• 開発メンバーの高稼働・デバッグ期間が不十分なことによる 不具合
• 心理的安全性の低下による コミュニケーションロス
• リリース優先の対応による 品質の低下 （工数削減のための仕様カットにより施策本来の目的が迷走）

そして次のアップデートでは

• 暫定対応のクソコードによってさらに伸びる開発期間
• 疲れ切った開発メンバー
• 不具合対応によって削られた開発期間
• コミュニケーションの冷え切ったチーム
• 前アプデに対するユーザからの辛辣な意見

の上で開発が行われます。（地獄ですね☆）

【手を動かさない仕事：その１】

・MTGを円滑にするためのファシリテート

現プロジェクトでは比較的に経験が少ないプランナーが多く、方針がボトムアップというのも拍車をかけていて、MTGが生産的なものになっていませんでした。

• キックオフの展開で 重要なポイントがずれている （ので質問責めにあう）
• 様々な観点からでる意見をどの程度吸い上げて消化するかの 判断がつかない
• 質問を捌きながら GATを意識して進めることができない
  • GATは(Goal, Agenda, Time)のことで、生産的なMTGにするための考え方です

※一応名誉のために書いておくとキックオフ時点で明らかに開発期間が少なく、現場でモノを作る側のメンバーも必死でした。

ファシリテートとしては下記のことを意識して進めました

• 前提の認識を合わせる
  • このMTGのゴールの確認（共有なのかブレストなのか懸念出しなのか）
  • この施策はスケジュール重視なのか（版権または季節的なもの）
  • この施策は品質重視なのか（最悪次バージョンに回せるのか）
• 施策自体へ意見と設計に必要な情報を分ける
  • まず施策の目的を確認して、大きなブレを無くす
  • 仕様のツッコミが止まらないなら、設計のツッコミは一旦止めて仕様の方針を固める（設計の話はその後）
• 先にある程度資料を読んで時間配分や突っ込まれそうなポイントを把握しておく
  • 必要に応じてメンバーに先に軽くリークする
  • MTGで質問できるように30分くらい軽い調査を頼む
• その場で決めれないこと（調査やPM判断が必要なこと）はTODO確認して話を切る
  • 誰に、何を、いつまでに確認するか決めて、次のMTGで展開します
• MTG後に各自どんなアクションをとるのか確認
  • 調査待ちなのか、調査するのか、実装に入るのか
  • 次のMTGはいつなのか、そのMTGで↑の展開はできるのか
• すごいざっくりとしたスケジュールの共有
  • 各セクションの工数も肌感でいいので聞きます
    • サーバーがざっくり10~20営くらいかかると話していて、2週間後がイベントなら普通にやってたらOUT
    • やばい部分について調べてもらって、どこを削ればワンチャンあるのか調べてもらいます
    • で、削る部分の相談をPMやDに持ってきます（担当者含めてMTG組むことが多い）

【手を動かさない仕事：その２】

「デスマを防ぐためのスケジュール組み」

キックオフの議事録をコンフルなどにまとめ、次のMTGを設定して誰が何を展開するのか、 チーム全員が把握できるように見える化 します。
責任を明らかにすることに多少抵抗はあるかもしれませんが、誰もボールをもっていない状態になって1週間後にMTGをした時に 「え？それってプランナーの仕様(エンジニアの調査)待ちなんじゃ...」って状態になるより遥かにマシです 。

下記は常にチーム全員で共有することを意識してます

• 調べなきゃいけないことは何か
  • ここは とにかく全力で洗い出し切れるように メンバーに発破を掛けて下さい
  • ゴールが見えない開発は必ず地獄に落ちます
• 誰がどこに当たっているのか
  • エンジニアとプランナーが調べる。なんて曖昧な書き方は何も書いていないのと同じ です
    • バイネームで いきましょう。複数セクションに跨るなら
    • 画像名の洗い出し(織田) → コードの影響範囲(徳川) みたいな感じで
• スケジュール
  • 重要なのは セクション間で付き合わせるポイント です
  • 細かすぎるとすり合わせに時間がかかるのでざっくりで
  • 現プロジェクトなら疎通確認、レビュー、Feature確認
  • 重要なマイルストーンは 必ず日時を明確に しましょう
    • 12日に疎通確認「え？12日中に疎通確認できるようにするから見れるのは13日の10:00からだと思ってました」とかは無しです
    • 12日にMTGの時間を抑えて、 全員で顔を付き合わせながら検証端末で動きを確認する 認識をとって下さい
    • 「12日中に各自でやりました。クライアントは大丈夫っす」はNG。
      • ダミーを扱う場合が多いのでちゃんと表示されてるのか（本物なのかデフォなのかダミーなのか）どうか確認するのは顔付き合わせるのが一番です（あとで後悔しますよ）

【手を動かさない仕事その３】

「設計をするための仕様書(のようなもの)作成」

MTGの議事録、仕様のすり合わせ、口頭でやったIFやCSVの設計など、 決まったことは資料化する。を徹底 させるように働きかけて下さい。
口頭で終わらせるのは言った言わないが始まるので論外、チャットは流れちゃうのでwikiかスプレッドシートかコンフルとかとにかく 専用の場所を作る のが良いです。
エビデンスをとって揚げ足を取られないようにするのがメインではありません。（そういう副次効果はありますが）
文字に起こすことで設計を見直すきっかけになったり、口頭で話した時のニュアンスによるすれ違いを防いだりすることができます。
また仕様と設計は書く所を分けることをお勧めします（冗長になって可読性が低くなると、読み返しの心理的に負担が大きくなって、確認頻度が減っちゃうので）

タスクはRedmineのチケットとWrikeで申請のマイルストーンから逆引きしたのを仮で引いて、調査しながら担当者に変更してもらってます。
曖昧な部分がなくなればチームで進めてくれるので、この後はリリースの段取りとレビューの時以外はほとんど任せっきりにできてます。

アップデート時に仮引きするスケジュール

各施策のスケジュール

ここまでの手を動かさない仕事はアップデートに入れる施策の数だけやります 。

3. 設計・実装・疎通確認

設計が固まったら開発メンバーで仕様書を通して、最終的に出来上がるモノの確認をして本実装に入ります
（といいつつ、皆すでに作れるところから実装着手している場合が多いです）

【手を動かさない仕事その４】

「仕様のバッティングや競合を防ぐための開発環境整理とリリースの段取り」

ここでアップデートに入れる施策の設計が出揃ってきたら仕様のバッティングがないか整理します
例えば
・ハロウィンガチャである新スキルを作る
というのと、別の施策で
・パッシブスキルを見やすくするためにアイコンを追加する
というのがある場合に、設計が終わった後どちらもpassive_skill.csvに新規カラムを追加するとします。

別々に施策を進めていると統合環境に入れる時 に、ハロウィンの新パッシブにはアイコンが表示されなかったり、同じコードを触ってしまっていて 競合解決に手間取ったりします。
基本的には コミュニケーション取って進めようぜ！ って方向でやってきていましたが、一度地獄を経験したメンバーだとままならないことがわかります。

各施策のファシリテートをしていることもあり、ほとんどの施策を把握しているので、施策の設計が出揃った時に資料化してもらってるスプレッドシートを利用して、 アップデートの施策を担当する全チーム を集めて、どこの何に変更が入るかの共有会を行います。
一方的な展開ではなく、 MTGと項目を用意して詳しいことはそれぞれの担当者に話してもらってます （もちろん3の時点でバッティングしてる施策がわかれば先にそこだけすり合わせにいきます）

実装後、環境を揃えて疎通確認を行います。
（実装中でもサーバーとクライアント、UIとクライアントとかで連携しつつ、出来るところからつなぎ込みの部分は確認を行なっています）
データやクリエイティブはダミーであることが多く、基本的には動作確認がメインです。
疎通確認で表面化した不具合や表示/挙動のチェックとフィードバック対応を行います。
コードレビューはこの段階くらいから並行して行います。

【手を動かさない仕事その5】

レビュー環境の準備

疎通確認が終わったものから、各環境を引いてレビュー用の環境を作ります。
（バッティング解決をサボったら、ここでやばいコンフリクトが起きます）

他にもレビューで見てもらうポイントを確認したり、テストデータはどうするとか、レビューの日取りやメンバーの調整をします。

4. 全体レビュー

機能を保証するデバッグとは別に、 ユーザ視点で良いものになってるかという観点 で開発やリーダー以外のメンバーにアプリを触ってもらうものです。
レビュー後にFB対応を行います。

アプデ内容にもよりますが、30名くらいが1時間くらい触って100件くらいの意見や不具合報告をもらいます。
各施策ごとにチームでやるやらの判断をしてもらって 、対応がなくなったものはFeature確認(デバッグ)へ回します
開発メンバーが対応に追われることが多いので、進行のヘルプをしたり抜け漏れがないように確認したりしてます。

5. Feature確認

Feature確認(デバッグ)
デバッグのFB対応を行い
統合Feature環境へマージ

6. 統合Feature確認 (v2.1.0とか今回のアプデで入るもの)

この統合環境マージは 地味にスケジュールに影響がでることが多い です
（コードレビューで指摘があってデバッグをやり直さないといけないとか)
チケットを見ながら進捗確認してリマインドしていきます。
当日になって
woki ＜ あれ？まだ統合確認始まってないんですか？
デバッガ ＜ まだ統合に入ってないものがあるから確認できないよ
っていうことがちょこちょこあります
（人は動作確認終わると後はどうにでもなると思う生き物である）

7~10. develop→staging→master

おわりに

どうでしょう？思いの外やっていることはシンプルだったと思います。
が、これを実装しながらこなすとなると、どこかで手を抜く部分が出てくると思います。

「手を動かさない奴」がいなくてもモノを作ることはできます。
実際、半年前まではこの役割はいなくてもアップデートはできていました。
ただ上記の タスクが消えてなくなっていたわけではありません 。
誰かが尻拭い的にその役割を担っていたり、非効率な出戻りを繰り返していた はずです。
そのせいか、私が手を動かさなくなった時にチームのメンバーがそこに不満を漏らすことは無く、むしろ評価をいただけました。

また単純にディレクションの工数を丸投げ出来ただけでなく、誰かがそこに立つということで PDCAを回せたことが大きなメリットでした。
開発の片手間だと全体が見えづらく、工数も取れないため改善まで回すことは困難です。
半年間、多方面から意見を聞いてフローを改善し続けてきたおかげで、 最初の頃に比べて工数が掛からなくなっています 。
最近ではその分をAppleのガイドライン対応の仕様書を作って展開したり、何か軽い実装を持つくらいならできるようになりました。

そんな今でも時間が掛かっていることがあります。
MTGのファシリテートです。

仕事上でぶつかり合うメンバーが多いのですが、よくよく聞くと皆プロダクトのことを考えてくれているのに、すれ違いを起こしていることが多々あります。
キックオフから実装に入るまで、 お互いが理解を深めて進めることができれば、もう手を動かさない奴は要らなくなる のではないかと考えています。

これを解決するために取り組んでいることはこちら↓
たった4時間で本音で語りあえるチームになるためにやったこと

本当の意味で手を動かさない奴が要らないプロジェクトになる日は、もうすぐそこまで来ているのかもしれない。