クライアントエンジニアの梅林です。
8月10日に弊社で開催した学生向けのイベント「“エンジニアMEETUP!!”～チームの生産性を上げる試み～」にて、同テーマで登壇発表した内容をベースに普段の業務で使いやすい形にまとめてみました。
大規模チームで生産性を上げるために意識している10のこと
# コミュニケーションについて
1. 背景を説明する
2. 会話で解決しつつ、ツール(チャット、Wikiなど)を活用する
3. 会議に必要以上の人を呼ばないが、共有は全体へ# 開発/運用について
4. ゴールイメージを常に合わせる
5. 手段を問わない
6. 助け合う
7. やらないことをハッキリさせる# QCDについて
8. ユーザ目線を忘れない
9. 力技による負債を作らない
10. 常に期限を設定する
大規模チームでの生産性について
数十人規模の体制で長らくゲームアプリを運用していると、少人数や短期開発では顕在化してこない課題に日々遭遇します。
例えば以下のようなものです。
- 飛び交う情報量が多く、1人で常に全てのことを把握するには物理的に限界がくる
- 業務上でやりとりしていた人が新しい人に変わり、昔のことを知っている人の方が少なくなる
- 昔のことを知っている人が残り続けている領域は、属人化が激しくなる
- 業務フローが安定すると、変化に乏しく、パフォーマンスが上がらない
- 定常運用をしながら新しい開発を並行する時がくると、タスクが増大する
何も対処しなければ生産性は上がることは無く、どんどん下がってきます。
意識している10のことは、これらの課題に対する処方箋として蓄積してきたものです。
1. 背景を説明する
誰かに依頼する際、実装する機能や実施するタスクのみを伝えると、頼まれた人自身で想像できる範囲が狭くなってしまい、最終的に良いものが出来上がらなかったり、作り直しの手戻りが発生することがあります。
依頼するに至った経緯や意図を伝えることで、主体的に関わってもらい易くなったり、モチベーションが高まることに繋がります。
2. 会話で解決しつつ、ツール(チャット、Wikiなど)を活用する
会話相手を拘束しないという意味でチャットは凄く便利ですが、文字情報だけだと、複雑な事柄を扱う場合に説明する時間が余計にかかってしまったり、空気感や温度感(緊急度合い)が伝わらず、着手が遅れて期限に間に合わないことがあります。
逆に口頭だけだと記憶頼りになり、着地した内容の認識に齟齬が出ることも多々あるため、会話した後に結論を文字情報で共有の流れが確実です。
3. 会議に必要以上の人を呼ばないが、共有は全体へ
1人で全てを把握できていない場合に、関わる人達全員を呼びたくなる誘惑がありますが、人数が多くなると時間を浪費してしまうことに加え、参加者1人1人の集中力も低下してしまうことが多いです。
ただし会議で決まったことは適切なタイミングで関わる全員に共有しておかないと、思わぬ考慮漏れにより再検討が必要になるケースもあります。
4. ゴールイメージを常に合わせる
開発や調査作業において何をどこまでやれば終わりとするのかが曖昧だと、判断者のフィードバックを受けた後、フィードバック内容を反映してチェックを受けると、また別のフィードバックを受けて修正したり、調査項目が増えたりしがちです。
ゴールとなるアウトプットのイメージについて作業に関わる全員が共通認識を持ち、作業期間の最初から最後まで見失わないようにすることが大切です。
5. 手段を問わない
実現方法がタスクまで詳細化された後は、タスクをこなすことが目の前の目標になりがちで、状況が変化した際に目的に沿った手段を再検討すべきところを、タスク消化につまずく(壁にぶちあたる)までは当初の予定通りに進めてしまいがちです。
この点は、常に目的を見える化しておくことで軽減できますが、開発途中においては早い段階で動くものを見れる事が一番進捗に繋がるので、コーディングせずに他の何かで代用できないかを常に考えています。
6. 助け合う
その人で無いと出来ない事以外は、複数人でやった方が早く終わることが多いです。
ですが全員の予定が100％埋まっていると他のタスクに関われる余地がなくなり、本来なら助け合えば早く終わるところが延びてしまいがちです。
計画段階でゆとりを作り、特定の誰かしか出来ない事を減らし、予定を見える化することで、必要になれば自然と助け合える状況を生み出せるのが望ましいです。
7. やらないことをハッキリさせる
ToDoリストなどで、やるタスクを明確にすることは良くやると思いますが、やらないことを明確にしておくのは意識しないとなかなか出来ないです。
やらないことがハッキリしていると、考慮すべきことの抜け漏れをチェックできるようになるので、必要以上に心配したり不安になることを防げ、本来のやるべきことに集中できるようになります。
8. ユーザ目線を忘れない
いろんな目標を掲げて進めていると、どうしても同時並行で進めきれないものが出てきて、優先順位をつけて順番に進めていくことが必要になるのですが、この時にアウトプットを判断する人からのフィードバックだけに集中しすぎると、実際にそのアウトプットを使ってもらう人のメリットが損なわれるケースがあります。
すぐ目の前のことだけでなく、その先のことも考えて判断していきたいところです。
9. 力技による負債を作らない
期限がギリギリになってくると、どうしてもその場しのぎの対応になりがちですが、運用を開始したり運用中のゲームアプリは、一度リリースしてしまうと簡単には既存のゲーム仕様を変更したり、サービスを数日間停止するようなことが出来ないため、運用をしつつ改修を並行で出来る機会がくるまで技術的な負債として残ってしまいます。
技術的な負債は開発スピードに直結するため、初期段階での設計が特に重要です。
10. 常に期限を設定する
締め切りが設定されていないタスクは、重要度の高低に関わらず、他にやることが全く無くなった時以外は着手もされずに放置されることが多いです。
細分化したタスクの中で他のものが全て終わる時に揃っていれば急がないようなタスクに対しても、仮の期限を設定しておくことでズルズル遅れることが少なくなります。
合わせて常にどれくらい時間がかかるかを見積り、実績との差分をチェックする習慣をつけることで、次回同じことをやる時の工数感や、誰がやってもこれくらいはかかるなどの工数感が蓄積でき、見積もりの精度が上がっていくのでオススメです。
まとめ
最後に、使うタイミングも意識してみました。
まず最初に、
「どのような目的で、誰が何をいつまでにやるのか」
定期的に
「話し合った結果、変わった部分があるか
やる事が増えた時、それは本当に必要なことか
やらないと決めた時、当初の目的が未達にならないか
少し時間がかかっても出来る人を増やせないか」
思うように進まない時に
「他の方法で何とかできないか
１人じゃなくて３人でやればすぐ終わらないか」
最終的に
「ユーザにメリットがあるか」
1つ1つは当たり前のように思えることなのですが、慣れてくると“常にきちんと実行する”のが疎かになりがちなので、お手元のリファレンスになれれば幸いです。
