現役PMが語る、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があったり。そういう状況でした。

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

そうしたことも、突然ダイナミックに行ったりします。

開発フローや組織について

最後に、いくつかFAQとして、僕のチームの開発フローや組織に関するところを紹介しようと思います。

「誰がプロダクトの企画をするんですか？」とよく聞かれます。みなさん、開発チームや開発者自身が、どれだけエンドユーザーに触れる部分の機能の設計に口出し……というか、企画からできるかを、すごく気にされています。

プロダクトの企画をするのは、開発チームやプランナーチーム、ビジネスチームなどいろいろです。しかし、詳細なスペックや最終的なプライオリティは、必ず開発チームが決めます。

また、現在ちょうど取り組んでいるところですが、社内ハッカソンで新しい企画を自ら創出することもあったりします。「こういうことをやりたいんだけど、できますか？」と聞かれますが、もちろんできます。むしろやってください。

LINEのルールはおもしろいんです。CTOに「こういうところがうまくいっていないから、なんとか改善してくれ」「この機能は、あのチームがうまくやってくれていないから、直してくれ」と訴えると、「じゃあ、あなたがやりなさい」と言われて、翌日からその作業を自分が担当することがわりとあります。

またチームのサイズは、これもプロダクトによってまちまちなのでなんとも言えませんが、直近で作っている機能の単位で見ると、オフィスの場所は違えど、実際に手を動かすエンジニアは5人前後。その中で、コミュニケーションを取りながら進めるパターンが多いかと思います。

例えば、クライアント側やデザイナーさんと関わる部分が入ると、マークアップの人も含めてもう少しエンジニアの数が増えるかもしれません。ただ、1つの機能だけで見ると、関わっているのは5人前後が多いと思います。

開発に制限はあるか？

僕のチームのスペシフィックな話になりますが、「どんなAPI、SDK、OSS、Open Sourceを作ってもいいのでしょうか？」ということもよく聞かれますが、とくに制限はありません。

積極的に、すばらしい機能を提案してください。これはAPI、SDKプロダクトを問わず、ありとあらゆるプロダクトに関しても同じことが言えます。

しかし、API、SDKプロダクトに関しては、LINEの全体的な方針として、個人情報やプライバシーの保護は非常に重要だと考えています。

そうした観点ではいろいろ制限がありますが、それはあくまで、LINEは非常に多くのユーザーに使われているサービスなので、そうした社会に対する責任も1つのコアのミッションとして捉えながら、いつも仕事をしています。

また、オープンソースに関しても、積極的なコミットメントを強く推奨しています。

最後に……LINEでは、このようにエンジニアがエンジニアリングに専念できて、非常におもしろく、世界を変えるようなプロダクトを作れるように、開発フローや組織づくりにも非常に真剣に取り組んでいます。仕事をしやすい環境を作っていますので、ぜひご応募ください。よろしくお願いします。

僕のセッションは以上です。ありがとうございました。

（会場拍手）