良いチーム構成のための図解思考法

こんにちは、ゆのん(id:yunon_phys)です。みなさん、良いチームを作っていますか？良いプロダクトを生み出すためには、良いチームであることが必要です。そして、良いチームであるためには、チーム構成が適切になっていないといけません。今回は、どうやったら良いチーム構成が出来るか、というのを考えるときの思考ツールをご紹介します。

チーム構成はトレードオフの関係がある

モバイルゲームはリリースがゴールではなく、むしろリリースがスタートです。リリースしたら何年も運用することになり、プロダクトチームは数ヶ月~1年後を見据えてアセットを用意していきます。そのため、いかに普段から効率的にアウトプットを出せるプロダクト組織を作ることが重要です。*1 効率的にアウトプットを出すためには様々な工夫をしますが、プロダクト組織内のチーム構成も一つの鍵です。

私がチーム構成が鍵であると考えるようになったのは、私が関わっているプロダクト組織で、今後のチーム構成をデザインする場面に立ち会ったときです。あれこれ思考錯誤を重ねても、どうしてもベストなやり方が思いつかず・・・。それもそのはず、チーム構成は、何かを重視すると、何かが失われるトレードオフの関係にあるのです。例えば、エンジニアがいるチームとエンジニアがいないチームを構成すると、エンジニアのいないメンバーだけで行動するときは機動力が高くなるが、逆にエンジニアがいないチームでエンジニアのスキルが必要になったときにそのための調整コストが発生します。

これまで様々なプロダクト組織を渡り歩いてきましたが、一つとして同じチーム構成は見ていません。これは、プロダクトが開発・運用されていく過程での複雑な歴史的経緯を経ながらチームが形成されてきた結果のように見えます。例えば、開発・運用拠点の違い、在籍メンバーのスキルセット、週に何回デプロイするのか、チームやメンバーの学習によるスキル向上、拠点ごとの文化の相違、メンバーの出入りなどが関係しています。

さらに、チームはまるで生き物のように変化していきます。状況が変わると、トレードオフのポイントが変わっていき、これまでなんともなかったものが気になりだしたり、逆にこれまで一生懸命やっていたものがそこまで問題でなくなったりします。

このように、チーム構成を固定化して考えるのはあまり意味がなく、そこに至った背景や今後どうなるのかを見据えることが重要です。

トレードオフの可視化

チーム構成にはトレードオフがあることは既に話しましたが、このトレードオフをいざ言葉で出してみようとしました。しかし、言葉で書き示しても、なんとなく実感値がなかったり、トレードオフの抜け漏れが発生するような感覚がありました。そこで、より直感的に考慮すべき点が抜けもれなく可視化出来るようにしたのが、今回提案する良いチーム構成のための図解思考法という思考ツールです。

今回はアカツキにおけるモバイルゲームの運用プロダクトのチーム構成を題材にします。以下に示す図はゲーム開発において、トレードオフの観点を洗い出したものです。 f:id:yunon_phys:20190930163912p:plain 横に並べているBOXがMECEに洗い出したプロダクト組織でやることで、隙間はその事象が独立していることを表します。事象が独立しているということは、ここでチームを分割するとコミュニケーションコストが最小化されます。縦に並んでいるのは同時に考えなければいけない観点です。

例えば、ゲーム内のイベントを開催するケースを考えましょう。イベントを開催するためには、アセットデータやマスターデータの更新が必要となります。これを図では”コンテンツ更新”という言葉にしています。次に、開催しようとしているイベントが従来のスキームで開催出来るのか、開催出来ないのかが観点となります。もしスキームの変更が必要になるなら機能追加・改修が必要となります。さらに、機能追加・改修にはソースコードの改修を伴いますが、モバイルアプリの更新(バイナリ改修)とサーバーの更新が必要となる場合もあるし、サーバーの更新のみとなる場合もあります。

次に、この図に垂直な縦線を入れてみましょう。 f:id:yunon_phys:20190930165518p:plain 縦線を入れると観点のBOXが分断されることがわかります。この分断こそがチームを構成する行為となります。図で明らかなように、どこに縦線を入れても、切れ目に沿った綺麗な切り方は無く、必ずBOXが分断されます。 BOXが分断されると、本来はコミュニケーションをとらなければいけない人たちが違うチームになるので、コミュニケーションの隔たりが発生しやすくなります。このコミュニケーションの隔たりを解消するために、多くの組織では、定例会議を作ったり、そのコミュニケーションハブを作ったり、座席を工夫したり、という行動をおそらく取るのでしょう。他にも、クライアントもサーバーも出来るエンジニアを採用する、モバイルアプリのアップデートは半年に1回だから多少のコミュニケーションの隔たりは許容する、という手段を取る場合もあります。

このように、分断が可視化されたら、ではそのコミュニケーションの隔たりをどう解消するか、というアクションを考えやすくなるのがこのツールの特徴です。

具体例から考えるメリット・デメリット

それでは縦線をどこに入れるかによってどのようにチームが変わっていくかを考えながら、メリット・デメリットを見てみましょう。

A. 運用チームと非運用チーム

f:id:yunon_phys:20190930164026p:plain このチーム構成は定期的な更新(コンテンツ更新やスキーム変更に伴う新イベント追加など)は運用チームで実施し、不定期の更新(コンテンツ更新を伴わない機能改善やパフォーマンス・チューニングやインフラ改修など)は非運用チームで実施します。運用チームはイベントの企画・実行をするプランナー、アートデザイナー、UIデザイナー、クライアントエンジニア、サーバーエンジニアが在籍するチームとなります。非運用チームはUIデザイナー、クライアントエンジニア、サーバーエンジニア、インフラエンジニア*2が在籍するチームとなります。

この構成のメリットとしては、定期的な更新は１つのチーム内で完結するため、定期的な更新が多いチームにとってはコミュニケーションが簡単化するということです。

一方、デメリットとしては、”機能追加・改修”と"バイナリ改修必要”のBoxが分断されているように、それぞれの行動を取ろうと思ったときに情報の同期が必要となることです。例えば、運用チームで新イベントのスキームを追加するためにUIやクライアントコードを改修しようとしているときに、非運用チームでよりプレイヤーが快適に操作できるようにUIの改修やパフォーマンス・チューニングなどをしようとしてコンフリクトが発生する可能性があります。逆にいうと、新イベントのスキームを稀にしか追加しないようなプロダクトであれば、このコミュニケーションコストはそこまでかからないです*3。

一方、新イベントのスキームをガンガン追加したい、運用に直接関わらない機能や非機能の改善も行いたい、という場合もあります。この場合は、お互いのチームの情報共有の定例会議を設けるとか、両方のチームに跨っている職種で情報共有会を設置するとか、QAが両方の機能チェックすることでコミュニケーションの橋渡しをする*4とか、コミュニケーションマネージャーを置く*5という方法がとられます。

B. 開発チームと運用チーム

f:id:yunon_phys:20190930164126p:plain アカツキの中でも最も良くあるチーム構成がこの構成です。このチーム構成はソースコードに手を加えるような変更は開発チームで行い、ソースコードに手を加えずにコンテンツだけを更新するのは運用チームで行います。開発チームは新規イベントの企画をするプランナー、UIデザイナー、クライアントエンジニア、サーバーエンジニア、インフラエンジニア等が在籍するチームとなります。運用チームには、イベントの企画・実行をするプランナー、アートデザイナー等が在籍します。

この構成のメリットとしては、エンジニアの効率が最も最大化する構成であるため、機能をガンガン作っていくときに有効です。例えば、リリース直後のアプリで、機能を追加したり改善することがそのまま価値となる場合に良いです。

一方、デメリットとしては、運用チームが知らない機能や想定していない機能が追加される可能性があります。「新イベントをこう使おうと思ったが、○○出来る機能が無いからうまくイベントを設計できない」といった事態はアカツキ内でも頻繁に発生します。これは開発チームにいるプランナーが運用チームのプランナーとどんなに情報共有していても発生してしまうので、なかなか難しい問題です。

こういった事態を防ぐには、開発を担当しているエンジニアが運用チームのプランナーに情報共有する機会を設けるとか、本番相当のイベントスキームを開発中に運用チームのプランナーが設計するとか、そういった事態が発生するのを見越して実際にリリースするより前のバージョンから試しておくとか*6、という方法があります。

C. 機能開発チームと非機能開発チーム

f:id:yunon_phys:20190930164844p:plain Bの開発チームをさらに、ゲームの機能開発をするチームと、ゲームには直接関係のない非機能を開発するチームにわけた構成です。非機能開発とは、例えば、運用ツール開発、デバッグツール開発、リファクタリング、開発環境整備などです。

非機能を開発するチームにはエンジニアしか在籍しないため、非機能開発のスピードが担保されることが、この構成の特徴です。また、いつも機能開発が優先されがちなプロダクト組織では、このように非機能を遂行するチームだけ切り分けるのも有効です。

ただし、デメリットとしては、バイナリ改修を伴う非機能開発をする場合は、機能開発チームと良くコミュニケーションをとっていなければなりません*7。例えば、非機能開発チームで技術的負債を解消するためにリファクタリングをしていた場合、機能開発チームの想定していなかったデグレが発生する可能性があります。

こういった事態を防ぐには、機能開発チームと非機能開発チームの情報共有の場を設けるとか、非機能開発チームがやろうとしていることを機能開発チームのQAが実施する、という方法があります。

尚、機能を開発するチームにはエンジニアの数が非機能開発チームと分割されることで少なくなるため、機能開発をガンガン進めたいタイミングでは不適切です。特に、機能開発を進めたいのに、過度に非機能開発が進められる可能性もあり、結果として機能開発用のエンジニアを採用することになりコスト高になる可能性があるので注意が必要です。