いま、全国タクシーチームで開発者として働くということ (2018 Spring)

全国タクシーチーム 沼井
開発部 全国タクシーチーム サーバサイドエンジニアの沼井です。今回は、全国タクシーチームで開発者が普段どのように働いているか、その一側面をお伝えします。

全国タクシーアプリは、JapanTaxi内の全国タクシーチームによって開発されています。

全国タクシーチームの構成や開発フローは、時期に応じて様々な変遷・変化をたどっています。
これは、業務のやり方に関する問題点などの課題の対策を都度考え、やり方を変えていった結果となります。

本記事では、2018年春現在の業務スタイルを説明します。

チーム構成

チームの構成は以下のようになっています
(注:本記事では「開発者」の業務に限って説明しますが、実際にはセールス・マーケティング部門やカスタマーサポート部門のメンバー、社外の関係者も関わりがあります)。

全国タクシーチーム構成

PM (Project Manager) はCTOが兼任しています。

【経緯・背景】意思決定の迅速さを担保するため。全国タクシーは多種多様な案件が多数並行し、またステークホルダーの数も多いため、迅速な意思決定は重要となります。

チームは、「プロジェクトチーム」「プラットフォームチーム」の更に2種類のサブチームに細分化されます。

「プロジェクトチーム」は、プロジェクト (新機能開発、期間限定キャンペーン対応、仕様変更・刷新などの各案件) ごとに結成され、そのプロジェクトの遂行を担当します。
プロジェクトごとに必要な役割(アプリ、サーバサイド、セールス・マーケ等)のメンバーが集まります。
プロジェクトチームは毎日のスタンドアップミーティングを行ない、メンバー内で日々の状況を確認します。

「プラットフォームチーム」は、iOSAndroidServer(サーバサイド)の3種類があり、各プラットフォームごとの不具合の対応や、カスタマーサポート部門からのエスカレーション対応などを行ないます。
各プラットフォーム別アプリケーションの安定性の維持が主目的となります。
プラットフォームチームは毎週の定例を開催し、各プラットフォーム内部での不具合・エスカレーション対応状況の共有や担当割り振り、プラットフォーム内の課題の共有などを行ないます。

メンバーは、上記のどちらかだけに所属するのではなく、基本的には両方の種類に所属します。

上記のサブチーム分類とは別に、「外部チーム(外部の協力会社: 株式会社ソニックス)」が存在します。
外部チームは、プロジェクトチーム、プラットフォームチームに対するリソース提供を行ないます。
多種多様な案件が日々動き続けている全国タクシーに対し、現在の社内のチームメンバーだけでは(時間的・人数的に)対応が難しい案件や、「プロジェクト」として個別に編成するほどでもない小~中規模案件に対する対応をメインで行なっています。

各サブチームには「メンテナ」が存在します。
各チームの責任が適切に果たされるよう、監視・監督することや、プロジェクト外部とのやりとりの窓口になることが役割です。
どんなルールも決めただけでは維持していくのは難しく、形骸化する可能性があるため、決めたルールを維持していくための責任者を割り当てているわけです。
それと同時に、メンテナやPMの仕事を過剰に増やさないためにも、個々人が自分でルールを守っていく意識を持つことも求めています。

【経緯・背景】もちろん、この構成になる前から、プロジェクト(案件)ごとに人は集まっていたし、iOS/Android/Serverそれぞれを担当しているメンバーが同じまとまりの中で話し合うことはありました。しかし、それが「チーム」という形ではっきりとした形をとっておらず、ミーティングも週1のチーム全体定例だけがあり、個別のプロジェクトごとの詳細な話し合いはプロジェクトごとのやり方に任せられていました。また、上記で言う「メンテナ」のような責任者的立ち位置をセットしていなかった時期もあり、外部から各プロジェクトの状況が見えづらい部分がありました。

現在の形(関心事を共有するサブチームを形成)になり、前述のようなミーティングの形態を明確に定めたことで、関心事を共有するメンバーで密接に情報共有・連携できるような状況ができあがってきています(*)。また、メンテナを介して、全国タクシーチーム内の他のサブチームメンバー、あるいはチーム外に対して明確な形で情報共有や状況説明ができるようになったと感じています。

(*)例えば、社内にはいくつもの技術勉強会/Tips会がありますが、「日々の業務における関心事を共有する、大きすぎない程度のまとまり」で開催しているものが継続してうまくいっているように思えます(個人の意見ですが)。

全国タクシーチーム全体としては、週次での定例があります。
ここにはカスタマーサポート、セールス・マーケティング部門のメンバーも参加し、各プロジェクトごとの進捗確認や重要事項の共有、各部署からの要望の検討などを行ないます。

開発サイクルとリリース

現在は、毎月のアプリリリースを目標に、約1ヶ月前後のサイクルで開発を進めています。
月次で「リリース対象検討会」を開催 (前回のリリース直後、数日以内) し、次のリリース対象の機能を決定します。

もちろん、アプリに緊急のバグFIXがあれば即座に対応し、個別にリリースします。
また、サーバサイドは機能追加・不具合修正ごとに必要に応じて日々デプロイを行ないます。

リリース後は「リリースノート」を作成し、チーム内外と共有します
(サーバサイドは都度デプロイして機能追加・不具合修正されますが、アプリのリリースサイクルと軌を一にして、1ヶ月単位での変更点をまとめています)。

【経緯・背景】過去には2週間単位のスクラム体制をとっていた時期もありました。しかし、期日の決まった新規案件の随時発生や緊急対応タスクの多さ、開発機能の規模の大きさなどから、2週間という単位で計画・開発・リリースするというのは全国タクシーにそぐわず、いったん取りやめになっています。
この開発サイクルの部分は全国タクシーにおいて試行錯誤の繰り返しがなされており、まだ改善に向けた余地があるのではと考えています。

業務内容

全国タクシーの開発といっても、そこにまつわる様々な業務があります。
以下は主な業務の例です。

    ■要件定義 (チーム外からの要求の検討・採択、要件の詳細化)
    ■機能開発 (仕様定義、設計、実装、テスト)
    ■プロジェクト管理 (特に各プロジェクトチームのメンテナ)
    ■不具合対応・エスカレーション対応 (特に各プラットフォームチームのメンテナ)
    ■運用 (インフラの監視、アラートの対応、マスターデータの変更など)

全てのメンバーがこれらすべてをまんべんなくやるわけではなく、メンバーごとに比重は異なります。

また、一人のメンバーが全国タクシー以外のチームや案件(プロジェクト)に所属していることも珍しくないため、業務内容は多岐にわたるのが現状です。

タスク管理

リリース対象の機能(のissue)の開発タスク管理や進捗状況の可視化には、GitHub Project を使用します。

プロジェクトチームで進める「機能追加/仕様変更」タスク、プラットフォームチームで進める「不具合・エスカレーション対応」タスクのそれぞれに対するissue templateを用意しており、それを使用して起票します。

【経緯・背景】GitHubの「New issue」ボタンクリックでは既定の1テンプレートしか使えないですね。全国タクシーチームでは、既定のテンプレートは「機能追加/仕様変更」タスク用に割当てており、「不具合・エスカレーション対応」タスクのテンプレートは、後述するslack BOTを介した起票である程度まかなっています。

issueは案件(プロジェクト)単位で1つ作成し、1ヶ月のリリースサイクルより長くかかる案件の場合は、1リリースサイクルで完成するサブissueを切り出して対応します。
もちろん、1プロジェクトの完遂のためにタスクを細かく分けて作業を行なうわけですが、そのような細かいタスクはGitHubのIssueとしては作成・管理しない方針をとっています。

GitHubのissueは、チーム内で管理するのはもちろんですが、チーム外に向けての「チームがやっていることの可視化」の単位としても扱うようにしており、細かいタスクの大量起票により状況が可視化できなくなることを懸念しているためです (ただでさえ全国タクシーは案件数が多いので)。
細かく切り出された個別のタスクは、(GitHub issueでなく)個々人で管理することが求められます。

エスカレーション対応

カスタマーサポート部門 (や、セールス・マーケティング部門) からやってくる問い合わせ (不具合らしき現象の発見や、仕様の問い合わせ) は、slackの不具合対応用チャネルに一元化して受付を行ないます。

問い合わせ依頼者は、当該チャネルにてBOT用のアカウントに対してメンションを行ないます。
すると、自動的にGitHub Issueに新規起票されるので、そこに問い合わせ内容の詳細を記載してもらいます。
あとは、対応メンバーがそのissueに調査結果などを記載し、再びslackのチャネルで結果を依頼者へ報告する、というフローになります。

【経緯・背景】slackの不具合対応用チャネルは1年半以上前からありましたが、窓口が完全には集約されておらず、「別チャネルでの問い合わせ」「Direct Message (もしくは口頭のみ)での特定メンバーへの直接依頼」などがなされるケースがありました。最近は問い合わせ対応のフローの明確化を行ない、当該slackチャネルへの窓口一本化、およびGitHub Issueによるトラッキングができるようになってきています。

問い合わせの受付(一次対応)は、特定のメンバーだけが担当するのでなく、プラットフォームチーム全体で行ないます。
メンバーごとに受付担当の日を決めてローテーション対応するのが基本的なスタイルとなっています。

【経緯・背景】以前はローテーションがなく、任意の(善意の)メンバーによる対応に任されている部分が大きい状態でした。これだと、特定メンバーへの負荷集中や、トラブルシューティング知識の偏りなどが問題になるため、今は上記の体制になっています。もちろん、慣れないメンバーだと対応スピードが上がらないという問題もありますが、メンバー内で随時ヘルプを出したり、プラットフォームチーム定例でのアフターケアによってカバーしています。

その先へ

全国タクシーチームにおける開発者の現在の業務スタイルは、以上のような形に落ち着いています。
もちろん、これが将来に渡って最善であるとは限らず、都度直面する課題や、環境要因(会社の体制の変化やメンバーの増加など)に応じて柔軟に変化すべきものであることは言うまでもありません。

今後も、全国タクシーアプリを利用するお客様や、アプリの裏側で動くバックエンドのシステムを使用するタクシー会社の方々(乗務員、無線室オペレータ、事務員の方々など)によりよいアプリ・システムを提供することを目指し、全国タクシーチームは少しずつ進化を続けたいと思います。


JapanTaxiでは、全国タクシー開発部エンジニアとして一緒に働く仲間を募集しています。まずは一度話を聞きに来てみませんか?

JapanTaxiに興味を持ったら、まずはお話しませんか?