最新情報をお届けします！
『LINE』という大規模プロダクト開発ならではの苦労が？！ デベロッパー向けツール開発経験から行き着いた「7つのルール」について、PMである御代田亮平さんが語ってくれた。
【プロフィール】
御代田 亮平／LINE株式会社 開発1センター プロダクトマネージャー
GoogleやTwitterで開発者向けプロダクトに携わった後、LINEへ入社。Login Platform、及び、開発者向けプロダクト共通のバックエンドシステムのプロダクトマネジメントを担当する。日課は10か月の子供との朝の散歩。
twitter:@josolennoso
※2017年11月14日に開催された「Japan Product Manager Conference 2017」よりレポート記事をお届けします
Google、Twitterを経てLINEへと入社した御代田亮平さん。現在、彼はLINEのデベロッパー向けツールの開発をPMとして担っている。
今回、言及があったのは『LINEログイン』（LINEプロフィール情報を使い、その他サービスへのログインが簡単にできるツール）について。
彼がチームに配属されたのは約２年前。プロダクトの課題を突き詰めていく中で見えてきたのは「開発プロセスそのものに課題がある」ということ。そして行き着いたのは組織改革だったー。
これまでチームで体験してきた失敗と成功とは？ そして行き着いた「PMはこうあるべき」という７つのルールとは？ 講演の模様を書き起こし形式でお伝えする。
私が所属しているのは、主にLINEのバックエンドの開発を担うチームです。『LINEログイン』やBot作成におけるToken発行システム、認証システムなどを扱っています。
既存のシステム・サービスを、外部のデベロッパーが使いやすいように加工し、提供すること。これらのミッションを達成していく上で、プロダクトの課題の多くは、開発プロセスや組織に課題があるというところに行き着きました。
まずはチームが抱えていたプロダクトの課題からお話しさせてください。大きく次の3つがありました。
・独自実装が多い
・謎のマジックナンバー
・一貫しない挙動
具体例として、LINEでメッセージを送る時、APIを外部に公開していくプロジェクトについてお話します。
現在はもちろん改善されていますが、作った当初は次のようなAPIの実装になっていました。
何を意味しているのかわからないマジックナンバーが多用され、誰にとっても使いやすいAPIとは決して呼べない状況に…。
問題を分析していくと、トレードオフが原因だとわかりました。
PMはデベロッパーチームだけではなく、セキュリティチームやリーガルチームとも頻繁にやりとりを行う。その中で次のようなことが起こっていたのです。
さらに、海外に拠点があったり、機能も豊富であったり、開発チームも多岐に渡ります。不明瞭なオーナーシップが原因で「不完全なプロダクトをリリースしてしまう」という問題が起きてしまっていたのです。
これらの開発プロセスの改善のため、まずは開発プロセス、組織を改革していくために目標を3つ掲げました。
・デベロッパー目線で優れたプロダクトを作りたい
・事業目線で優れたプロダクトを作りたい
・クオリティを損なうことなく、迅速に、継続的にリリースできるような環境作りをしていきたい
そこから、機能追加のフローを定めるのと同時に上長や周囲のメンバーとも連携し、大胆に組織改革を行っていきました。
以前の体制では、あるときフィーチャー全体を眺めていると、どのチームが作ったかわからない「API Service X」が、システム上に存在することに気づいたという。なぜかオーナーもCEOに紐付いてしまっていた。
さらに、仕事のスタイルを徹底していくため「PMはこうすべし！」という７つのポイントもあげます。
・Ownershipを持たせる
・依存関係の見える化
・新規開発プロセスの明示
・3つの数字を最大化するように務める
・Influener足り得るVocal Minorityを見極める。
・スクラムマスターやPjMとの協業
・PM=Party Managerであれ。チームを鼓舞する存在
一つひとつ、それぞれの背景や意味について説明していきます。
1. Ownershipを持たせる
各プロダクト、その中の機能それぞれにオーナーをつけた組織構造にしておくことにすることをオススメします。
これは、初期プラットフォームチームのミーティングで実際にあったことなのですが、会議室の中にいる誰もが、意思決定者が誰か知らないということがありました。フィーチャー（ある機能）をリクエストした当人が誰が決定権があるかわかっていない…ということも。議論ばかりで開発が進まなくなってしまったということがありました。
たとえば上の例では、LINE Clientで新たに追加したフィーチャーを活かして、デベロッパー向けAPIとして公開するとする。そういったときにLINEでは、中長期的にそのAPIを管理する者を、アプリ側ではなく、API側の人間（プラットフォームチーム）をオーナーにすることにしたそうだ。
2．依存関係の見える化
1つのシステムの仕様変更に伴い、それに紐づくサービスも変更せざるを得ないという状況があると思います。そのためにも、依存関係の見える化を徹底すべきです。
たとえばこれは、LINEのWeb APIにおけるバックエンドについて。API Gateway自体の仕様変更により、それらに紐づくサービスやプラットフォームにも影響が出るということがありました。サービス間でも、Bot PlatformがToken Serviceを使っているなど、依存関係があったんです。
これらの関係性や依存性、仕様変更をエバンジェリストへ伝達したり、ドキュメントに反映したりしやすくするため、次の4つに具体的に取り組んでいきました。
・ツールでカバー（JiraやTrelloなど値段に問わず使いやすいものを選択）
・ツールをベースとした、PM／TeamLeader間での徹底した議論
・どのチームがどの機能をいつリリースするかをトラッキング
・限界がある部分はプロジェクトマネジャーが人力
3．新規開発プロセスの明示
多くの開発チームは、他チームからのリクエストによって開発をすることがほとんどだと思います。だからこそ、明確化されていないリクエスト方法やプロセスは、フォーマット化していくのがいいでしょう。
たとえば私達の場合だと、チャットやメールなど「フロー型」のコミュニケーションツールによるリクエストが多かったんです。それを極力Jiraなどの「チケットベース」のものにしていきました。
ただ、チケットを書くときは抽象的な表現をしてしまって、伝わらないという問題も。そこで、次のような5W1Hのフォーマットに揃えていきました。
When：いつリクエスト出来るの？
プロダクトやフィーチャーによってリリースタイミングはマチマチ。どのようなものなら受け入れるのかというルールを開発チーム内で明確にしていきます。
Who：誰がリクエストできるの？
組織が大きくなったときには、誰でもリクエストできるというスタイルではなく、リクエストできる人を決めておいたほうがいい。まとまったリクエストにすることで、ロードマップも引きやすくなります。
What：何をリクエストできるの？
どのチームがどこを担当しているか。責任範囲の明示と周知を徹底すべきです。外から来るリクエストの精度も上がってきます。
Why：なぜリクエストをするの？
開発者だけでロードマップをつくると事業やビジネスの観点からそれてしまうこともあります。事業サイドのステークホルダーを巻き込んだり積極的にリクエストの理由を聞いていくのがよいです。
Where：どこからリクエストするの？
How：どうやってリクエストするの？
これらは、テンプレートをつくることで制限することが可能です。
4．３つの数字を最大化するように務める
次に、PMとして次の3つの数字を最大化していくことを「心がける」とともにこれらの数字が常に最大化できるのが最高のPMと言えると思ってます。
開発者が開発に注ぐ時間
チームが開発する時間を減らさないように務めるのがPMとして重要な役割です。たとえば、開発途中でミーティングを挟む必要があっても、PMのみが参加し、開発者はコーディングする時間に費やしてもらう。そういった努力をするようにしています。
書いたコードがリリースされる割合
データテストやプロトタイプなど、実際に書いたコードが全てリリースされることは少ないと思います。その中でも確実にリリースされるもののプライオリティを上げています。
実際に使われる頻度
これは、プロダクトによって定義が変わります。リリースされた後にもKPIを最大化できるようなフィーチャーを作ったり、優先度をあげることが重要です。たとえば、コンシューマープロダクトなら利用するユーザー数、売り上げるプロダクトなら売上の伸びなどがこれにあたりますね。
5．Influener足り得るVocal Minorityを見極める。
多くの人に使われるプロダクトを作り、広めることがPMの使命。それを進めていくためにもカスタマーの声と上手く向き合っていくことが重要です。
カスタマーの多くは特段、声高に新機能をリクエストするわけではありません。彼らのようなサイレントマジョリティに耳を傾けるべきだという風潮になりがちです。ただ、そんなことはありません。
ある少数の人のために作ったニッチな機能が、多くの人にとって使いやすい機能になることもある。そのチャンスを逃さないための見極めはとても重要になるところだと思っています。
ただ、気をつけたいこともあります。Vocal Minorityと我々は呼んでいますが、頻繁にリクエストしてくる、数少ない重要な顧客の声についてです。彼らの声を実直に聞けば、アップフロントを手にして事業のKPI達成に大きく近づくことができるというのは実際よくあること。
ですが、それらの対応を「簡易な実装」で済まそうとすると、将来的にプログラムがどんどん複雑になっていってしまいます。
一時的にドキュメントで補足するなど、カバーできるかもしれませんが、それで満足していてはいけません。
PMはプロダクトの今と未来に責任をもっています。プロダクト・ライフサイクル全体に渡るコストを計算しながら判断をしていく必要があるでしょう。
6．スクラムマスターやPjMとの協業
PMが担う本当の役割は、リリースしたら次のスプリントに何をするのか、マーケティングなど事業に関わる部分を常に考えていくこと。
図でいうと、点線で示したまるの部分ですね。そこに注力していくためにもスクラムマスターや、PjM（プロジェクトマネージャー）との協業が欠かせません。
やりがちなのはプロジェクト全体において、QAやリリース関連などの細かい作業まで見すぎてしまうということ。どのサイクルに、どのくらいコミットをしていくのか、バランスをとっていくのがよいでしょう。
7．PM=Party Managerであれ。チームを鼓舞する存在
プロダクトの成長を見守るのはあたりまえ。PMは、チームを鼓舞するParty Managerであるべきだと考えています。なにより「チーム」のコンディションを第一に考えていくのが重視すべき役割だと思っています。
LINEの御代田さんが語ってくれた「プラットフォームチーム改善のウラ側」、そしてPMのあるべき姿を示した7つのルール。それぞれのチームに最適化し、ぜひ参考にしてみてほしい。
当日の資料はこちら！
文 ＝ まっさん
編集 ＝ CAREER HACK
4月から新社会人となるみなさんに、仕事にとって大切なこと、役立つ体験談などをお届けします。どんなに活躍している人もはじめはみんな新人。新たなスタートラインに立つ時、壁にぶつかったとき、ぜひこれらの記事を参考にしてみてください！
経営者たちの「現在に至るまでの困難＝ハードシングス」をテーマにした連載特集。HARD THINGS STORY（リーダーたちの迷いと決断）と題し、経営者たちが経験したさまざまな壁、困難、そして試練に迫ります。
Notionナシでは生きられない！そんなNotionを愛する人々、チームのケースをお届け。
