こうやって東京・シリコンバレーのリモートチームは動いています

こんにちは！Drivemode, Inc. のエンジニアのKAKKAです。本名は平田将久というので、ごくまれに平田さんと呼ばれることもあります。前回までは弊社横幕がブログポストを行っていましたが、今回から私も執筆させていただきます。テーマは表題の通り、実際にDrivemodeは（組織的に）どう動いているの？というお話です。
我々Drivemodeはまだ人数の少ないスタートアップで、ファウンダー含めて全員で８人のチームですが、東京とシリコンバレーのSan Joseに分かれて一つのチームとして日々働いています。「なんでやねん」というツッコミが一秒に３回くらい聞こえてきそうですが、理由としては同じ場所に全員いる必要があるかという問いの答えがNoだったというだけの話です。弊社CEO古賀のインタビュー記事にもあるよう、

僕よりすごくないと採用できない
本当に優秀な人を採用するのはシリコンバレーでも難しいですね。シリコンバレーのエンジニアやデザイナーは給料が非常に高いのですが、僕がすごいと思える人はごくわずかです。そもそもいい人は就職活動とかしないんですよね。彼らは基本的にふらふらしてて面白い事を見つけてから居着く生き物なので、ネットワーキング経由でしか見つからない。レジュメで経歴がすごい人を見つけても一緒に働いていて僕のペースについてきてもらえないので1日で解雇ということもありました。

「人」を何よりも最優先したということです。

しかしリモートチームはただリモートチームであるだけでかなり不利な条件を生みます。具体的な問題とその解決法を紹介していきます。

時差の問題

これは本当に深刻な問題です。日本とシリコンバレーの時差は16時間あり、お察しの通り日本での朝9時はシリコンバレーの17時です。Web業界にとっては、朝9時出社は早い方だと思いますし、アメリカ人は朝早く出社することはあっても夜は全然残業しないという国民性です。

よって日本チームが頑張って朝9時に出社しても、通常のアメリカ人チームであればおつかれっしたーと退社してしまうのです。しかしこの問題の解決方法はシンプルに労働時間帯をお互いに近づける努力をするという方法しかありません。結果、日本チームは朝9時に絶対に出社し、シリコンバレーチームは19時くらいまでは残ってもらうという方法に落ち着いています。そして必要であればその後チャットなどでかなりおそくまで付き合ってもらいます。これは規模が大きくなるにつれて問題が深刻化していくので、どうやって解決するかを模索中です。

コミュニケーションの問題

まずは言語の問題です。

Drivemode社の公用語は英語なので、全て英語です。シリコンバレーチームはアメリカ人なので余裕でNative English Speakerです。当然英語に慣れていない日本人にとっては少しつらいところもあるのですが、弊社CEOの古賀は何度もこう言っています。

弊社のポリシーは、
・英語ネイティブじゃない人→英語しゃべれないだろうけど、しゃべらなかったら◯◯す
・英語ネイティブの人→ネイティブじゃない人の英語がわからないだろうけど、わからなかったら◯◯す
となっております。

甘いことを言わずにお互い歩み寄る努力をするということですね。こういうスタンスなので、ミーティングでは遠慮なく超スピードの英語が話されるし、英語に慣れていない人にもバンバン話が振られます。お陰様で英語ネイティブじゃない人もぐんぐん英語力上がります。

次に物理的な問題です。

いくら人類が進化したとしても、我々の声の直接波はシリコンバレーには届きませんし、仮に届くくらい進化したとしても音速はせいぜい340.29 m/sであり、音波の伝達におよそ6時間40分ほどの遅延があるので、自然な会話ができるようになることはないでしょう。そこで我々はインターネットを使うのです。

Slack

言わずと知れた便利なチャットツールです。ほぼすべてのテキストメッセージはこのSlack上で行われます。会話だけでなく、botも大活躍しています。Githubのcommitのお知らせやCIによるbuild success or failのお知らせ、ユーザーフィードバックのお知らせなどなどかなり重要な働きをしています。そしてみんなそれぞれの私物のスマートフォンにもインストールして、通知に気づくようにしています。時間外でもリモートコミュニケーションがとれます。

ハングアウト

テキストコミュニケーションではなく、会議を行うときに使います。一対一のときも使うことがありますが、特に複数人の全社ミーティングなどではハングアウトを使います。

このように机の端っこにTVとマイク、カメラを設置して、机が延長されたように見せかけ、日本チームとシリコンバレーチームがまるでひとつの机にいるような演出をしています。TVに写っているのはシリコンバレーチームのYokichi Koga(CEO), Jeff Standard(PM), Johnny Ting(Design)です。これで会議は全く問題ありません。むしろハングアウトのスクリーンシェアという機能を使うことにより、より効率的な会議にすることが出来ます。

Google Docs

会議にハングアウトのスクリーンシェア機能を使うこともありますが、どうしても一方通行のプレゼントなってしまうので、会議の資料としてはGoogle DocsのPresentationやSpreadsheetなどを使います。

これらを使う利点としては下記の通り。

• 各自のPCで鮮明な資料が見られる
• 誰がどこを見ているのかがわかる（画像の赤い◯のアイコン参照）
• 補足等あればテキストや図などをリアルタイムに追加編集が可能

欠点

• 各自がPCを操作して見る必要がある

利点にあげたものはすばらしく、ほぼ全員が同じミーティングルームに入ってプロジェクターやホワイトボードを完備した状態を同じような状態に出来ます。とはいってもやはり音質の問題が聞こえづらかったり、空気感が伝わりにくかったり等あるので、比較すると劣ってしまいます。欠点もあり、これによってファシリテーターはかなり気を張って全員が会議に集中しているかを意識しなければなりません。SNSとか見て集中切れたりするので。

プロジェクト（開発）マネジメント・プロセスの問題

プロジェクトマネジメントやプロセスは上記コミュニケーションや時差の問題にかなり依存するものがあり、これもまた難易度が高いです。

私自身CSP(Certified Scrum Professional)という認定スクラムマスターの上位資格まで保有するほどにスクラムを愛していますので、個人的にスクラムを導入したい派ではあるのですが、我々のようなリモートチームには適さないプロセスです。スクラムを愛しているが故に守るべきすべてのルールを守ることなくスクラムをやっているとは言いたくありません。よって弊社ではスクラムはやっておりません。スクラムじゃない方法を提案するのもまた、スクラムマスターの役割ということも心得ていますので、我々のチームにあったオリジナルなアジャイルプロセスを導入し、改善を繰り返そうとしました。マインドセットとしてはアジャイルソフトウェア開発宣言を意識し、現在のプロセスとツールとしては下記があります。

Stand up meeting

これは思想や目的も含めスクラムにおけるデイリースクラムとほぼ同等のものです。日本は朝9時に出社、シリコンバレーは17時にミーティングルームに集まり、ハングアウトを使って昨日やったこと、今日やること、困っていることを報告します。

Retrospective Meeting

思想や目的も含めスクラムのスプリントレトロスペクティブ（振り返り）と全く同じです。アジャイルプロセスにおいて最重要なミーティングであり、決して外すことは出来ません。プロセスや環境、ルール等プロダクト以外のものを改善させる唯一の公式なイベントです。手法としては付箋をつかうことができないので、Google DocsのSpreadsheetをうまいこと駆使しています。これによって新たにミーティングが出来たり、なくなったりとプロセスが進化していきます。

Refinement Meeting

スクラムのものとやっていることは同じです。要件を明確にします。全員でやることによりビジネス優先度の高いものから順番に、誰でも着手できるようにするために行っています。

Bugs Review meeting

これはRetrospective Meetingによって生まれたミーティングです。ユーザー等からのバグ報告が散らかりっぱなしになっているものをエンジニアだけで整理、リファインし、プロダクトバックログにマージするためのミーティングです。

Drive Day

これもRefinement Meetingによって生まれたミーティングです。何をするかというと、実際に車を運転してプロダクトを使い、意図したとおりに動いているかを始め、様々なフィードバックを得ます。一見スクラムにおけるスプリントレビューに似ていますが、リリース前（スプリント終わり）のプロダクトオーナーによる承認フローではありません。車を調達して高速道路や一般道を走るというイベントはそれなりにビッグイベントなので、Drive Dayは不定期に行っています。

Weekly Meeting

全社ミーティングで、週に一回あります。プロダクト開発に関わる人だけでなくBusiness側の人やCEOも全員集まり、全社的な議題を報告及びディスカッションします。これは開発プロセスに関わらず一番昔からあるミーティングです。

Trello

プロジェクト管理に使っています。昔はGithubのissue機能なども使っていましたが、優先順位の一元管理を考慮してTrelloのみを使うようになりました。

Next upがスクラムでいうプロダクトバックログになります。
なるべく属人性を排除するために、上記リファインメントで、Next upにあるものを全員が着手できるようするのが重要です。そうすることでNext upのカードには誰もアサインする必要がなくなり、かつビジネス的優先度の高いものから着手可能になります。Doingに移動させるときに人をアサインしています（ただし責任の所在は個人レベルに明確にはしていません）。

DeployGate

apkのデリバリーや管理には最高のツールです。masterやブランチ、debugバージョン等それぞれ自由にインストールできるよう柔軟に管理しています。

フラットなチーム

少し話はそれて組織的なお話をしますと、我々はフラットなチームを維持しています。誰かが権限と責任を握っているわけではなく、全員で公平に責任及び権限を持っています。これにより、全員が責任をもって最前線で走っていけるような人材になれるようにしています。弊社のポリシーでは

Drivemodeのメンバーは全員がロックスターであるべき

というのもあるので、責任と権限を持ってロックスターを目指しています。

さいごに

以上Drivemodeの東京チームとシリコンバレーチームの組織やプロセスについてお話しました。課題はたくさんありましたが、かなり改善されてきました。ですがもちろん完成していませんし、完成するときなんてありません。プロダクトも組織もプロセスも常に良い方向に向かって改善をするのみです。あなたもDrivemodeをより良くしていきませんか？