成功したプロジェクト・失敗したプロジェクトから学ぶ、エンジニアのチームビルディング

成功したチームと失敗したチームの取り組みを振り返る

門田矩明氏（以下、門田）：みなさん、こんばんは。F.O.X Meetupの主催の門田と申します。

今日はF.O.X Meetupというイベントの3回目になるんですが、場所はヒカラボさんにお借りして、共催というかたちで開催させていただいています。

僕からは「成功したチーム、失敗したチーム」というテーマで話をさせていただきます。私の名前なんですが、門田矩明と申します。今F.O.Xというサービスのサービスマネージャーをしてまして。

エンジニアチームのマネージャーや、エンジニアじゃない人たちのマネージャーだったり、採用をやったり広報をやったり、基本的に組織のなんでも屋をやってます。

F.O.Xについて。F.O.Xを聞いたことがある、ご存知の方ってどれくらいいらっしゃいますか？

（会場挙手）

ありがとうございます。ありがたいことに、ご存知の方も多いので、簡単にご説明します。F.O.Xはスマホアプリの広告効果の計測ツールです。

GoogleアナリティクスやFirebase的なやつだと思ってもらえればだいたい合ってるかなと思います。

私のキャリアについてですが、もともとSIerでエンジニアをやってました。そして、2012年くらいにサイバーエージェントに転職しまして、amebaっていう事業部で新規サービスの立ち上げに関わっていました。そこから4年ほど前にCyberZという子会社に出向になり、そこからはずっとF.O.Xに携わっています。

今回はサイバーエージェントに転職してからとCyberZに異動してからの間で、スタートアップに携わることが多かったんですが、その中から成功したチームと失敗したチームの事例を3つくらい挙げてお話させていただきます。

JK・JC向けのSNSサービス

1つ目なんですが、JK、JCってわかりますか？（笑）。女子高生と女子中学生なんですが、JK、JC向けのSNSを作っていたときの話です。

どんなサービスだったかと言うと、簡単に言うとJKとJC向けのスマホSNSサービスでした。エンジニアチームの構成なんですが、サーバーサイドが3人くらい、フロントエンジニアが1人くらい、AndroidとiOSがそれぞれ1人ずつ、みたいな感じです。

サービス立ち上げ当初は2週間ごとにユーザー投稿型のイベントが開催されていまして、基本的にいかなるものよりも優先度が高いという状況でした。イメージとしては、ゲームのイベントのようなものです。当時、サービスにおいて1番重要なのはイベントという感じでした。

イベント1回の設計や実装、テストはだいたい3週間くらいかかるようなものになっていました。とくに2週間に1回やっているので、やっている最中にも、次のイベントの設計、実装が同時並行で走るという状態でした。

このときのチームの課題としては、サービスが立ち上がった直後ということもあり、イベントの開発と同時にサービスの機能開発もしなければいけませんでした。

どうやって対応したかなんですが、開発ラインを3つ用意して、サーバーサイドが3人だったので、1人ずつ分けました。1人は直近のイベントの設計と開発をやって、2人目はその次のイベントの設計と開発をやる。3人目はそれ以外の機能追加、普通の機能追加の開発をする、というかたちで分けました。

1人がずっとイベントを開発し続けるというわけじゃなくて、イベントの開発が終わればその次は機能追加の開発に移るみたいな感じで。開発レーンみたいな感じで3つくらいあって、それを順番に2週間ずつ回すようなイメージです。

チームと個人のバランスをとるために

これが実際どうだったか？　結論としては一応成功しました。ここでの成功というのは、イベントと機能追加のバランスがうまく取れたということです。

今だから言えることですが、イベント担当ってけっこう気疲れするというか。プロデューサーとかディレクターが、リリース3日前くらいに「こんなことも追加でやりたいんだけど」とか、イベント終了3日前くらいに「今回すごい盛り上がってるからフィナーレにこういう盛り上げを入れたい」みたいなとんでもないことを言ってくることがあります（笑）。

当然イベント担当は追い込みで気疲れをします。終わったら休みを取るというのもちょっと安直かなと思ったので、余裕のある開発ラインに移ってやりたいことやってリフレッシュか、ちょっと休んでリフレッシュするとか、どちらもできるようにしてみました。

その結果、チーム全体と個人のバランスを取りやすくなったので、一応成功かなと思っています。

4システムの膨大なタスクを処理する

続いて、2つ目のお話に移ります。CyberZに移ってからのアドテクプロダクトの話です。実は既にクローズしているサービスなので、今はないんですが、新規の広告の配信サービスです。立ち上げの開発チームは、エンジニアが4人、プロジェクトリーダーが別にいるような構成です。

すこし説明が難しいのでざっくりになってしまいますが、広告の配信システムと広告をトラッキングするシステムと管理画面、集計をするバッチシステムが存在してました。

1システム毎のサイズが大きいのと、フルスクラッチで全部開発することになっていたので、開発タスクがかなり膨大になっていました。

このチームの課題は、4システムあって、その4システムに膨大なタスクがあるということでした。この時どのように対処したかと言うと、システムごとに、トラッキングや広告配信、バッチなど、1システムずつに1人をアサインして専任担当というかたちでアサインしました。

プロジェクトリーダーは基本設計とシステム毎のタスクの分割が仕事の中心です。この開発機能はこのシステムだとこうで、このシステムだとこうで、みたいなタスク分割をする。システムごと、要はひとりひとりのタスク管理はプロジェクトリーダーがやることになっていました。

これによって専任担当が余計なことを考えずに担当のシステムだけに専念できる環境を整備する、ということでやっていました。

タスクが偏り、最終的に専任制を廃止

これは成功か、失敗か？　1つ目の例に近いですし、うまくいきそうな感じがするんですが、数ヶ月後に問題が発生しました。

バッチシステムは最初の開発が少なくて、後から要件がたくさん出てくるとか。逆に集計や広告配信のほうにタスクが偏って、後ろにいけばいくほどどんどん空きが出るという偏りが発生していました。

当然空いている人にタスクを回したいところなんですが、基本的に専任担当ということでタスクを分けてしまったので、自分が携わっていない部分のキャッチアップがぜんぜんできていませんでした。その結果、自分の領域外はぜんぜんカバーできないという問題が発生しました。

そんな状況なので慢性的にタスクの偏りが出て、消化できないタスクがかなり発生していたので、リリースの遅れが発生してしまいます。

なんとかリリースに至った後、運用が始まると当然トラブルが起きたり、バグが発生したりするわけなんですが、その運用対応も専任担当になってしまっているので対応ができないという問題も発生してしまいました。

一応、ディレクターを入れて、専任制を廃止してみんなでワークをシェアしてカバーしようと試みたんですが、解決するまでにかなり時間がかかってしまっています。

ソーシャルマッチングサービスの事例

3つ目なんですが、ソーシャルマッチングサービスの話です。出会い系じゃなくてマッチングサービスです（笑）。サーバーサイド3人とWebフロント1人、スマホのアプリのエンジニアがAndroidとiOSで1人ずつという構成ですね。

これは相当古い話でして、2012年1月くらいの話です。6年前というのはiPhone4SとかXperia arcの時代でした（笑）。Galaxyで言うとのS2やS3がメインだった頃ですね。スマホに関する技術情報がほとんど世の中に出てないような時代の話です。

この頃の経験がある人とは懇親会でいいお酒が飲めると思うんですけど、当時のスマホのWebブラウザは機種依存だらけでした。今はChromeブラウザが標準搭載になって挙動に差異も少ないですが、当時は各社基本的に標準ブラウザに手を加えるのが主流になってまして、機種依存バグが出まくっている状態でした。当然AndroidやiOSアプリについても情報がないので試行錯誤を強いられてました。

加えて、一番難易度が高かったのがアプリ内課金、特に月額課金でした。AndroidとiOSで月額課金が始まった直後ぐらいでして、「対応したい！」という話が持ち上がり、やらなきゃいけない流れになりました。

技術調査と開発の両立

この時のチームの課題なんですが、技術調査と開発の両立です。実際にどう対処したかなんですが、専門領域に関係なく、サーバーサイド・アプリ・Webなど複数名で技術調査をするようにしました。

調査メンバーはだいたい3人から4人くらいでやることが多かったんですが、サーバーやWebまわり、DBなどの設計も調査メンバー全員で設計するようにしました。

あと、専門領域は問わず、お互いに書いたコードのレビューも行いました。当然「iOSのコードは読めない」ということはあるんですが、ドキュメント通り実装されているかどうかであったり、「ここはなんでこういうふうに実装してるの？」というのはある程度わかるので、調査メンバーで専門領域に関係なくコードレビューをしていました。つまり、調査から開発までを複数名で取り組むということを徹底していました。

これは当然なんですが成功しまして、予定通りリリースできました。

リリースの前のアプリ内課金のテストには1ヶ月ほどかかってしまいました。やってるとAppleとかのドキュメントに書いていない出来事が平気で起きて大変でした。

トラブルが発生した場合も調査メンバーが3、4人いるので多角的に見れるようになりました。1人だと見方が固定化してしまうのですが、複数人の場合、仮説を立てやすいというか。仮説のバリエーションが出やすいので、解決までが早く、これは成功かなと思っています。