Pairsサーバーサイドチームの立ち上げと変遷・未来について

この記事は、eureka Advent Calender 23日目の記事です。
前日は Mizuki Kobayashiの 猫でもできるDeepLearningの文章自動生成 でした。

自己紹介
このブログでは複数回登場していますが、はじめましてなみなさまはじめまして。eurekaのAPIチームで責任者をしています、@takochuuといいます。

趣味は酒とゲームとゼンハイザーの製品を集めることです。
momentum true wireless にはめちゃ期待しています。

## 概要
この記事では、今年4月に立ち上げられたAPIチームの変遷と課題との苦闘について話したいと思います。
同じようなエンジニアリングマネージャーの皆様、スクラムマスターの皆様に読んでもらえればと思います。

## APIチーム立ち上げの経緯
これまでは、サーバーサイドの開発者は各チームに散らばっており、いくつかの課題を抱えていました。
* 書かれるソースコードの質がチームによってバラバラ
* 各開発者が持っているPairsについての知識が偏っていて、組織立った活動ができていなかった
* 育成観点で、上長・先輩がチームにいないなどスキルの成長の阻害要因があった

これらの解決を図る形で、4月にされた意思決定が「サーバーサイドの開発者を1つのチームに集結させる」という意思決定でした。

APIチームは、上記の図のように特定の事業部のチームに属さず、事業部を横断して成果を出す事が求められる組織横断型のチームになります。

事業部に対してサーバーサイドが絡む施策については、事業部 <-> API <-> AI / SREとのコミュニケーションの中央になることが多いことから、次の2つがAPIチームのミッションになりました。

1.APIチームとして、JP・Globalチームに対しての情報共有に責任を持つ
2.長期的な技術投資が可能な開発体制を構築することにより、フロントエンドの要望を実現するAPI開発を行う事に責任を持つ

タックマンモデル

上記はタックマンモデルと呼ばれる考え方で、チームビルディングにおいての段階を表現したモデルになります。
プロセスには4段階あり、形成後、混乱を経て統一(目的・役割期待などが一致する)状態から、機能(力が目標達成に向く)状態になるというモデルになります。

すべてのチームは平等に上記プロセスを踏むと僕は考えており、APIチームにおいてそれぞれの期で何が起きたか、何に向き合ってきたかを解説します。

形成期 (2018/04 ~ 2018/07)

形成期は、タックマンモデル的に言うとお互いを全く知らない状態で、責任者に指示を求めるフェーズとされています。

この時期に、僕をはじめとしたメンバー8人はそれぞれ、Global事業・UI/UXチーム・マネタイズチーム・ユーザ獲得チームなど別々のチームから集まってきました。もちろん全員で一緒に働いた経験などはありません。

そこで、 yoh nakamuraさんに相談をしておおよそ3時間半をかけて「ドラッカー風エクササイズ」「Working Agreement」「インセプションデッキ」というワークを行い、相互に価値観を擦り合わせてチームがスタートしました。

同時に、CustomerCareチームからの土日の問い合わせ対応や、Globalチーム、JPチームとの関わり方をチームで相談しつつ決めていきました。 (この頃に、JPチームとしてカンバンでの仕事がスタートしていきます。)

その後は、APIチームの中でのMTGの進め方を定義したり、チーム内の日々の仕事をどのように改善するかという観点において話し合いを重ねることになります。

Working Agreementの中で「ペアワークを一度は検討する」というものがあったのですが、Pairsの中で機能の実装を理解している範囲が各々違い、新しい施策として行おうとしている実装が正しいのか、正しくないのか決めることができせんでした。なので、ペアワークはやめることにしました。

この頃はまだ、「長期的な技術投資が可能な開発体制を構築する」 ということに取り組むことはできていない状態で、目の前のタスクをさばいていくので精一杯。コミュニケーションの中央として機能することも遠かった時期です。

混乱期 (2018/07–2018/10)

混乱期は役割を意識し始める時期で、メンバー間の衝突が起こる時期とされています。

この時期には、ペアワークをやめて、JP / Globalそれぞれに専任で開発者を立てて開発していたのがこの時期です。
それにより、一時的にタスクが消化されていくが常にチームはパツパツ状態。
優先順位が高く、タスクの粒度が大きい(6ヶ月程度)プロジェクトを複数持った時に他のタスクができない状態になってしまっていました。差し込みに対して上手くコミュニケーションできていないことありました。

そこで、チームメンバーと話し合い、会議体を見直す事にしました。
これまでAPIチームで行ってきたMTGは「Daily Standup」と「振り返り」の2つでしたが、新たにナレッジシェアを目的とした「レビュー会」とチームのベロシティが阻害されていないか確認するための「Doneレビュー」を追加しました。

レビュー会
これは、週1回の頻度で出されたプルリクエストから粒度の大きいものや、見て欲しいものをチームで見て設計や書かれたコードに対して会話をするという内容です。
Pairsのナレッジをシェアすることと、設計・実装のクオリティを上げることの2つが目的になります。

Doneレビュー
チームの生産効率を阻害する要因(着手してからの待ちが多いなど)がないかを確認するためのMTGです。
Doneになったチケットを並べ、納期通りだったか、そうでなければどのような状態だったのかを会話していきます。

この2つを追加し、振り返りMTGの頻度を見直したことによって課題が見えるようになってきました。
しかし、まだ形成器と変わらずミッションに対してはできていない状態が続いていたため、僕たちは自分たちの目標をもっと具体的なものにして、自分たちで自分たちの行先を決めていくことが大事でした。

統一期 (2018/10 ~ )

統一期は、オープンな意見交換が可能になり、お互いを認め合う時期だと言われています。

この時期の10月にJamesがAPIに加入し、メンバーは合計で8人になりました。このタイミングで、元々やりたかった「長期的な技術投資が可能な開発体制を構築することにより、フロントエンドの要望を実現するAPI開発を行う事に責任を持つ」ことにトライすることを決めました。

1. 今のPairsサーバーサイドの中で課題をチームで洗い出し、12月が終わるまでにやるべきことを決め、やりきること。
2. 会社の技術広報としてブログの執筆
3. 古くなったAPI仕様書のメンテナンス

この3つが12月末までのAPIチームの目標になりました。

また、このタイミングからペア/モブワークを再開することにしました。チーム立ち上げから6ヶ月経ち、色々な開発を経験したことでチームのメンバーが開発を上手にこなせる状態になってきていたからです。

僕を入れて8人のチームは、以下のように分けました
・Aチーム: JPの最優先の施策を開発するチーム
・Bチーム: 柔軟に施策開発を行うチーム (領域はJPなど問わない)
・Cチーム(個人): Globalの開発を行う個人チーム
・@takochuu: 全体のプロジェクトマネジメントや、課題の設定、MTGへの出席、外部への説明など

結果として、複数人で同じ作業(ペア・モブワーク)を行ったにもかかわらずチームの開発量は落ちず、設計・実装などのナレッジがシェアできました。

今は12/22ですが、今の所目標に対してはすべて達成可能な状態で推移できていて、本来のミッションにようやく近づけるようになりました。

学びですが、やはりチームの立ち上げというのは時間がかかります。焦って何かを変える、というよりも自分たちで気づいて変えていくことの重要性を感じた1年でした。
それに伴い、やはり自分の能力を上げる努力は常日頃やっていかないと取り残されてしまうと感じた1年でもあります。
医龍にもそのような言葉がありましたよね。

### これから
このような推移を辿ってきたAPIチームですが、来年はより事業を長期的に成長させるため、大きい技術課題の解決にトライしたいと考えています。

詳細はもちろんこの場には書けませんが、興味を持って頂いた方は @takochuu まで Twitterでmention頂ければ色々カジュアルにお話させていただければと。

長文でしたが読んでいただいてありがとうございました！
ぜひ、みなさまとお話するのを楽しみにしています。

それでは、よいお年を。