LINEのサービス開発フローと組織づくり

LINEにおけるエンジニアの働き方

御代田亮平氏：今日は京都開発室よりまいりました、御代田と申します。よろしくお願いします。

僕はウィークエンドコーダーといいつつも、もう子どもがいて、ウィークエンドも（コードを）書けない……今はそんな状態ですが、プロダクトのマネジメントをしています。

とくに、デベロッパー向けのプロダクトの開発を担当しています。ですので、LINEのコアのフィーチャーにはあまり関わっていません。関わっているところは、LINE Login、LINE SDK、LIFFなどです。よく聞かれますが、僕はBotにはなにも関わっていないので、Botのことを聞かれても、あまりよくわからないです。

現在で3社目なんですが、前職も前々職も外資系の会社でした。転職の時に「LINEはどうですか？」みたいな話を、個人的にもいろいろ聞いたり、聞かれたりするんですが、先ほどのディスカッションでもあったとおり、僕の印象として、シリコンバレー系の会社から来てLINEで働いている人と話したりすると、LINEの環境は、実はすごくよくて。

外資系企業のほうが、給与面ではべらぼうに高いところもあったりするので、そういう面では条件は悪いかもしれません。ですが、それ以外の部分……必要性が認められればフレキシブルに勤務するオフィスを変えられることや、与えられる機会など、とくに技術力の高さも含めて、LINEの環境は本当に遜色ないか、僕の感覚としては、むしろそれ以上なのかなという気もしています。

とくに、プロダクトの開発の面でいうと、開発者自身がイニシアティブを持って、何か新しいフィーチャーの開発や企画に取り組める体制をとっていたりするので、そういった意味でも非常にいい環境だと思います。

僕のセッションの目標についてです。弊社はおかげさまで、会社が非常に大きくなってきて、先ほどもあったように従業員の数も増えています。そうなると、面接などでよく聞かれるのが「会社が大きくなるなかで、少し官僚的になっているのでは？」「居心地が悪くなっているんじゃないか？」といったことです。でも、実はそんなことはありません。

会社が大きく成長していくなかで、そういった弊害は絶対にどの企業でも生まれると思います。そんななかで、我々はプロダクトの開発やサービスの設計フローの（構築の）仕方という面から見て、非常に働きがいがあり、楽しい場所を維持している、ということを（このセッションで）感じていただけたらなと思います。

LINEのサービス

まず、LINEには、非常に多様なサービスがいっぱいあります。例えば、LINEのネイティブクライアント。先ほど登壇した者のなかで、上野はiOSのネイティブクライアントに関わっています。

それからファミリーサービス。

ここでは「LINEショッピング」の例を出していますが、LINE以外のネイティブアプリケーションや、クライアントの中のWebサービス、ブラウザで使うようなWebサービスといったものをファミリーサービスと呼んでおります。

それから、こういったネイティブのゲームもあったり、「LINE NEWS」の例を出していますが、真ん中に広告のプロダクトもあったりします。

さらに、僕が担当しているデベロッパーのプロダクトもあります。また、エンドユーザーには直接見えないところではあるんですけど、内部のインフラチームにエンジニアが非常に多く在籍しております。

多様なステークホルダーと仕事をする環境

このように非常に多岐にわたるステークホルダーがいます。

当然、エンジニア以外にもプランナーの方がいたり……ビジネスデベロップメントですね。つまり「パートナーシップを結んでビジネスを展開するために、こういった特殊なフィーチャーを入れてほしい」といったリクエストをしてくれる人々です。

それから、いわゆるアドなどのセールスのチーム。データのインフラやマシンラーニング周りのチーム。そして、リーガルチームや、アプリケーションセキュリティチーム、PRチームなど。さらに、今日、こちらの（イベントを）主催してくれているDeveloper Relationsチームなど、ありとあらゆるチームが存在します。

実際に、これらを開発者がすべて行うのは大変です。そんな究極のミドルマンが必要になるのですが、それをするのが僕の仕事です。ですので、「a.k.a. PM」とありますが、人柱に近いようなイメージを持ってもらえるといいのかなと思います。

いきなり宣伝になってしまいますが、先ほどのSessionでも話があったとおり、DEV DAYが21日にあります。そのときに「LINE SDK V5」というものをリリースするんですが、その開発部署の一例を挙げています。

Engineeringは8人で、プロダクトは僕1人です。開発者向けのプロダクトなので、テクニカルライターが2人。それからサポートのチームが2人。QAのチームが3人。そして、アプリケーションのセキュリティに3人関わっています。

それから、リーガルや情報ポリシーのチームとして2人が関わっています。Developer Relationsチーム……これは主に、オープンソース周りを担当してくださっているんですが、今日来ている藤原が1人で担当しています。さらに、マネージメント陣とありますが、C-level層といいますか……それを挙げだすとキリがないので、最低3人以上は見ています。

PMをどこに置くべきか？

こんななか、エンジニアがPMを担当するのは大変だと思います。実際にPMは、うちの会社でも、その部署、そのチームにもよりますが、はっきりとPMという肩書きの人間もいれば、そうでないパターンも多く、兼務しているパターンもあると思います。

だいたい2〜3つぐらいのパターンがあります。

1つ目は、エンジニアリングマネージャーが兼務するパターンです。このデメリットとしては、エンジニアリングマネージャーもエンジニアリングリソースの1つといえば1つなので、これが純減してしまう。そういうデメリットもあります。

それから、プランナーが担当するパターン。この場合は、（プランナーが）技術に疎いと開発者との意思疎通がまったく取れず、開発の進行がぜんぜん進まない可能性があるというデメリットもあります。

ビジネス系の人が担当すると話は盛り上がるんですが、開発されずに終わってしまうとか、開発がぜんぜん違う方向になってしまうこともあります。

よってLINEでは、とくに僕が担当しているデベロッパープロダクトチームでは、エンジニアリングチームに所属する、僕のようなプロダクトマネージャーが担当しています。

LINEでは、オーナーシップをかなり明確に開発チーム内に持たせようという方針を持っているんですが、このようなかたちでも、エンジニアリングチームに明確に意思決定権やオーナーシップを持たせようとしています。

この中で、エンジニアリングマネージャー系の方はいらっしゃいますか？

（会場挙手）

こうしたプロダクトマネジメントも、同時にされたりしますか？

（参加者がうなずく）

そうですよね。そうなると、おそらくコードを書く時間なんてないですよね。でも、LINEは大丈夫です。僕みたいな人間がいて、全部カバーしてくれるので書けると思います。

サービスの開発サイクル

僕のチームを例として挙げると、サービス開発のサイクルはざっくりとこんな感じになっています。

リクエストが1個あったら、要件を定義して、開発して、QAをして、リリース作業をします。

ただ、1つのフィーチャーが入ってきてこのように進めているというよりも、LINE SDKは、先ほどお話ししたV5を作っているんですが、同じようなフィーチャーをいくつか並行して、それぞれが要件定義段階だったり、QA段階だったりといった、いくつかのサイクルが何個か並列に進んでいるようなイメージだと思います。

例えば、このフィーチャーAは「リクエスト」とありますが、内部や外部のステークホルダーからのリクエストに応じた開発フィーチャーだったりすると思います。Bは、開発チーム内で「こういうフィーチャーを入れたい」ということで、自ら発案して作るフィーチャーだったりします。Cは、長らく放置されている、バグを直すための作業に関連するフィーチャーだったりといったものが、混ぜこぜになって進んでいます。

では、このA・B・Cのうち、どれを最初にやるべきかというと、答えはないんですが、テックリードとともに、エピックごとの進捗などを確認しながらプライオリティを決めています。

また、「ロードマップは何クォーター先まで作っているんですか？」ということもよく聞かれます。これもチームによってまちまちですが、最低でも2クォーターぐらい先まで決まっている傾向にあります。

ただ、2クォーター先まで決まっているものでも「もう少しロングタームで見ないといけないな」といった話はチームによっては出ていると思いますので、1年先まで決まっているプロダクトもあります。

なお、SDK周りのチームに関しては、「来年からは、1年先までのプロダクトのロードマップを決めながら進めよう」といった話も進んでいます。

PMとして意識している3つの数字

先ほどのフィーチャーA・B・Cの例でもお話ししましたが、自分たちで考えたり、リクエストをもらったら、それをなんでもやるというわけではなく、プロダクトマネージャーとして、いつもこの3つの数字を意識して仕事をしています。

とくに、この3つの数字がエンジニアチームで100パーセントに近いぐらいできていれば、プロダクトマネージャーとしてはロックスタークラスに優秀な方だと思います。しかし、なかなかそうはいきません。それでも、この数字を改善することを心掛けています。

この3つの数字は何かというと、例えば1日8時間、1週間働くとしたら40時間ほどの中で、1人の開発者がどれだけコードを書く時間にあてられるか……そういったことを意識しています。

そのためにミーティングを少なくしたり、関係部署やステークホルダーとミーティングする際に、エンジニアがわざわざ出てこなくてもいいところは、全部PMがカバーするといったことをなるべく行うようにしています。

2つ目の変数は、リリースされるコードの量です。

フィーチャーをこのように作っても「やっぱりこれはダメだった」となってしまったら、せっかく（1週間の）40時間のうち30時間をコードに書くことに費やしても、全部無駄になってしまいます。こうしたことがなるべく発生しないようにするために、リスクなどを事前に把握した上で、正しく、まっすぐに進めるようレールを敷くことを心掛けています。

一番最後がもっとも重要なんですが、そうして作ったフィーチャーがユーザーに……、ユーザーとは必ずしもエンドユーザーだけでなく、例えば社内のインフラチームにしてみたら、ほかのエンジニアリングチームに（フィーチャーを）使ってもらうことが重要です。つまり、実際に開発した機能が使われる頻度も、特に重要であると考えています。

結局、40時間中の35時間を使って書いたコードが、すべてプロダクションに載ったとしても、その機能がまったく使われなかったら、なんにも意味がありません。ですので、こうしたことを見分けるところも、プロダクトマネジメントのレベルで行っています。

このように、「いかに3つの変数を最大化できるか？」を考えています。

あえて断ったり、プライオリティを調整してもらうことも

ですので、例えば、フィーチャーCを断るということもあります。

例えば、改善のリクエストが来ていたとしても、かなり限られたユーザーにしか使われていない、けれども、ちょっと声が大きめのパートナーさんやそのパートナーさんの先のセールスチームの方にお願いされた場合は、「ほぼユーザーに使われないでしょう」ということを伝えて、プライオリティを下げることもあります。

しかし、こうしたことをエンジニアのみなさんが直接やるのは、すごく大変だと思います。ですので、けっこう僕が担当しています。アクロバティックな土下座をしたり、たまに焼き肉を食べに行ったりして、フィーチャーCの作業をしなくて済むように（調整）します。

ただし、「不具合を放置します」というわけではありません。例えば「半年後にやろうとしていた別の大きいフィーチャーが関係するので、そのときに直します」といったプライオリティ付けをしています。

僕が関係しているプロダクトの中で、僕が関わる部分と、エンジニアリングマネージャーやテックリードなど、現場の人が関わる部分を大きくしてみたのが、これです。

外から来たリクエストについては、エンジニアの方がなにかのきっかけで、直接そのフィーチャーのリクエストをもらうこともあっていいと思います。

それ以外の社内からのリクエストなど……僕らが作っているのはデベロッパーのプロダクトなので、社内のミートアップに参加したときにもらったフィードバックは、だいたい僕が受けていて、その後の要件定義や開発部分をテックリードや現場のエンジニアリングチームと一緒に進めていくというかたちです。

それから、フィーチャーBについてです。これは、僕ら自身、開発チーム内で発案があったフィーチャーなんですが、テックリードや現場のエンジニアのみんなで、半年に1回ぐらい（集まって）話しながら、機能を追加しています。

LINE SDKの開発チームの構成

例えば、LINE SDKの開発チームはこんな感じになっています。

PMは1人。これは僕で、京都と新宿のオフィスを往復しています。それから、フロント寄りのサーバーエンジニアが2人、新宿にいます。また、トークン周りのサーバーエンジニア1人がブンダンにいます。ブンダンというのは韓国（の都市）で、ソウルの近くです。

さらに、iOSのSDKのうち、2人が新宿、3人が台北にいます。Android SDKは、台北に3人います。QAは、福岡に2人、台北に2人。そんなチーム構成になっています。

このように、多拠点になっていて、出身国も違うため、当然ながらコミュニケーションは全部英語です。LINEでは、英語の学習サポートも非常にしっかりしているので、「まったく英語ができないけど……」と心配する必要はありません。

また京都はオフィスも小さく、人数も少ないため（通訳が）いないのですが、東京、ブンダン、台北にはオフィスに通訳さんがいて、全部通訳してくれるため、コミュニケーションに困ることはありません。おそらく福岡にもいるはずです。

それ以外にも、社内ではLINEやSlackでコミュニケーションをとっています。（各ツールで）翻訳Botがあったりするため、日本語で書いてもなんとなく通じます。逆に、ほかの国の方が現地の言葉で伝えてきても、うまく日本語に訳してくれるので、なんとなくわかるようになっています。

ダイナミックに組織を変えることもある

こうしたことをやっても、うまくいかないときはあります。そんなときは、ダイナミックに組織を変えることもあります。実際にデベロッパープロダクトチームで起こった、あまりよくない事例ですが、むしろ本当にあった怖い話レベルの例です。

開発者としては例えばGoogleさんやMicrosoftさんが作っているようなAPIやSDKを使うときに、「この会社さんが作っているプロダクトなら、きっとこんなレスポンスを返してくれるだろう」「こんな機能単位だろう」と期待していると思います。

例えば、ビジョン系のAPIとマップ系のAPIは、おおむね同じようなロジックで組んでいるんだろうなと考えると思います。むしろそこに一貫性がないと、非常に使いづらかったりします。

以前のLINE API SDKプロダクトには、そういった物が比較的多かったです。なぜかというと、この組織の構造はこんな感じになっていました。

EMは、エンジニアリング・マネージャーですね。SEMがシニア・エンジニアリング・マネージャーや、VP of Engineeringです。

僕の「API Service 1」のチーム的には「API Service 3」のチームとけっこうコミュニケーションを取れていると思っていました。もちろん、1と2のチームはよくコミュニケーションを取れていたため、機能単位やインターフェースは一致していて、しっかりしたものを作れていました。

しかし、チームが違うと、1と3ではまったくレスポンスのかたちが違ったり、機能単位がまったく違うといったことがありました。

そんななかでも、1と3や4の間でがんばってコミュニケーションしていましたが、それでもうまくいかない。なんとなくうまくいったと思ったら、最終的にぜんぜん違う組織から「API Service X」みたいな、聞いたこともないAPIが出ていたり。またミートアップの場で話していたら「こういうのがあります」と言われて、はじめて知るAPIがあったり。そういう状況でした。

このように全然うまくいかなかったため、去年の暮れから今年にかけて、このような組織に変更しました。