CLOSE

Developer Product PMの仕事の進め方(全1記事)

2019.11.12

Brand Topics

PR

LINEのDeveloper Productの開発スタイルと、プロダクトマネージャーに求められる役割

提供:LINE株式会社

LINE株式会社が2019年10月4日、「LINE Ads Platform/LINE公式アカウント エンジニア&PM採用説明会」を開催しました。LINEで働く現役エンジニアとPMたちが、同社における働き方やカルチャーなどをざっくばらんに語ります。「Developer Product PMの仕事の進め方」に登壇したのは、Developer Product 室の下郡愛氏。

Developer Product PMの仕事の進め方

下郡愛氏:私からはDeveloper ProductのProduct Managerの仕事の進め方について説明させていただきます。

まず簡単に自己紹介ですが、下郡と申します。今、開発4センターのDeveloper Product Managementチームで、LINE LoginとProfile+というユーザー情報管理機能、LINEアプリのトークルーム内で動作するウェブアプリが実装できるLIFFというSingle Page Application向けのFront-end Frameworkのプロダクトマネージャーを担当しております。

前職は、某インターネットサービス企業で6年間アプリケーションエンジニアを経験してから、その後PMに転身して、現在まで技術プラットフォームのプロダクトマネジメントに携わってきました。

実は、LINEに入社してまだ3ヶ月も経っておらず試用期間中ですので、入ったばかりの観点でLINEで働く魅力を説明させていただければと思ってます。

今日のアジェンダです。

まず一般的なプロダクトマネージャーの主な役割、次にLINEのDeveloper Productにおけるプロダクトマネージャーの主な役割を説明します。

プロダクトマネージャーの役割は会社によって異なると思います。ストラテジーからエグゼキューションまで守備範囲が広く、会社によってはプロジェクトマネージャーをPMと呼んでいたり、マーケティング寄りの人をPMと呼んでいたりします。

そのなかでLINEのDeveloper Productのプロダクトマネージャーが何をしているのかについて説明します。まず他のチームと連携して進める業務についてですが、リリース後の利用者のサポートやエンゲージメントを上げるフェーズについては、Technical ReadinessというDeveloper Product利用者としての開発者の技術成熟度を高めるようなチームであったり、Developer Relationsという開発コミュニティを運営するチームがいて、彼らが推進してくれます。

また、Developer Productでは、一部有料機能も提供しており、有料機能のプランニングについては事業側のプランニングチームと一緒に検討をします。ふだんは主に、プロダクトの仕様作成とプロジェクト管理を中心に進めています。

次に、具体的に、日々プロダクトマネージャーがどういう仕事をしているのかを説明します。

初期フェーズにおける役割

まず開発のサイクルがストラテジーを作るところから実際にデリバリーするところまであると思いますが、まず初期のフェーズでは、市場・競合・自社の状況調査をしたり、実際の利用者にインタビューを行いフィードバックをまとめます。また、それらの調査結果から、方向性を絞るということを最初に行います。

次に、最初のアイデアの分析を元に、具体的な製品仕様のプランニングに入ります。製品開発の方向性はシンプルに1ページのロードマップにまとめ、また細かい個々のアイディアやタスクについてはJIRAのバックログにまとめます。

仕様書には、ユーザシナリオ・機能仕様・UI仕様を定義します。ユーザシナリオでは、対象の機能よってユーザに届けたい体験を「誰が何をして、なぜそれをしたいのか」という形式で記載します。

また仕様は決めて渡して終わりではなく、その後に関係者との調整がたくさんあります。開発者と技術的な最適解と仕様が噛み合っていない場合は調整し、デザイナーとUI仕様を調整し、情報セキュリティや法務チェックを行ってもらい、仕様を確定させていきます。この交通整理がなかなか工数がかかりますが、プロダクトの成否が関わっているので大事な部分です。

開発・リリースフェーズでの役割

次に、実際に開発が始まってからですが、開発のフェーズに入るとプロダクトの管理というよりはプロジェクトの管理の要素が強くなってきます。

LINEの開発プロセスはあまりカチっと決まっていないのですが、明確にしておいたほうが、チームが集中できる項目もあるので、最低限のガイドラインにまとめて、みんなの認識が揃った状態で仕事が始まり、集中すべきことに集中できるよう工夫をしています。

また、それ以外にも、スプリントという開発期間ごとの目標設定と進捗管理を行なっています。また、開発中にやはり仕様が変わるなどの問題が起きて、もともと考えていたことができなくなることもあるので、その場合も都度、仕様調整と意思決定をして、開発のプロジェクト全体が止まらないように推進していく必要があります。

実際に開発が終わったあとにQAに入ると、次にQAチームに仕様を説明する作業があります。また、バグが発生した時には、バグ修正の優先度を決めます。また、バグの内容によっては仕様調整をします。

最後にリリースフェーズです。厳密にはリリースする前なのですが、Developer Productに関しては、リリース前にテクニカルライターの方とユーザーマニュアルを作成します。

また、この作成したユーザーマニュアルを、LINEはLINE API ExpartというDeveloper Productのエキスパートの方を認定しているのですが、LINE API Expartの方に先行公開をしてフィードバックを受けるプロセスも設けたりしています。

それ以外にもリリース後のサポートがあるので、リリース前にサポートをしてくださるTechnical Readinessチームの方と連携して、その後リリースを告知する作業が発生します。

最後にプロモーション系ですが、リリース後に開発者にスムーズに受け入れられるように、新機能の説明会やハンズオンのイベントなどをDeveloper Relationsのチームが開きます。

LINEのプラットフォームは日本だけではなく、タイと台湾でも高い利用率があるので、それらの地域における開発コミュニティも活発です。PMは、海外のDeveloper Relations チームとの連携・支援も行います。

また、そこからフィードバックを受けて最初の初期フェーズに戻る、というようなサイクルで仕事を進めています。

Developer Productの開発スタイル

今の私から見たLINEのDeveloper Productの開発のスタイルなのですが、入って一番思ったことが、コミュニケーションがものすごくオープンで率直な点がすばらしいなと思いました。

率直さというのは、言い方を変えてしまうと、空気が読めないというふうにも解釈はできると思うのですが、プロダクトが最初からすばらしいアイデアで完成しているなんていうことはぜんぜんなくて、最初はひどく未完成だったアイディアを率直なフィードバックによってどんどん精度を上げてユーザーにとってより良いものにしていくプロセスがあるので、この率直なコミュニケーションのスタイルはサービスを作る上ですごくいいカルチャーだと思いました。

また、議論をするときにすごくユーザーストーリーを重視する人が多いなと思いました。エンジニアや法務など、様々な全く違う観点を持つチーム間で議論をする時も、最終的には「それはユーザーにとってどうなのか?」「プロダクトとしてどうなのか?」という話になることが多く、「もっとユーザが驚くような体験を届けるにはどうするべきか?」という点で論点が揃うところも、PMとしてはやりやすいですし、何より楽しいです。

それ以外だと、エンジニアのレベル感がやはり高いなと感じたことも、感動したポイントです。エンジニアの方が自主的にプロダクトや進捗に対して自己管理してくれるので、プロジェクトマネジメントに手がかからない点もやりやすいと感じている点です。

プロダクトマネージャーに向いている人物像

最後に、LINEのDeveloper Productのプロダクトマネージャーとして向いているのではないか? と個人的に思う人物像について説明します。

プロダクトマネージャーをやったことある方はご存じだと思うのですが、人のコミュニケーションのハブになる仕事です。

例えば営業の方から「AとBとCの機能があったら絶対売れるから作ってほしい」、事業の方から「DとEという機能がどうしても必要なんです」と言われたり、例えば上司が「今のトレンドはAIだから、AI入れてよ」と言われたりすると。

こういうごちゃごちゃの目標や方向性の中でどうしようって悩むのは、プロダクトマネージャーをしてるとよくある状況だと思いますが、モノづくりが好きで、何かを作って届けて良い反響を感じたいという意欲があれば、目標を見失わずに調整をやりきれると思うので、プロダクト作りに強い熱意がある方は向いていると思います。

次に、新しい事を学ぶという点ですが、デベロッパープラットフォームなので、技術トレンドのキャッチアップが早い方も向いていると思います。

次は「問題解決をしたい」という点です。どういう仕事でも問題解決能力は大事ですが、プロダクトマネージャーとして「問題解決をしたい」というのはどういうことかと言いますと、いろいろな立場の方がそれぞれの立場の意見を言う中で、批判の的になって嫌になることもあると思いますがそこで投げ出さずに、一人ひとりの言っていることをよく聞いて理解して問題を分析することが大事だと思います。

例えば、1つの大きくて複雑な問題に見えても分解していくと、例えば、要素の1が解決できればなんとかなるかもしれない。要素の2は違っていて今ある仕組みで対応できるので解決しなくてもいいことかもしれない、というふうに分解していくと、いろいろな人が違うことを言っているようで、だんだん共通の要素が見つかってくることがあると思います。

そういったかたちで、個々の問題を個別に追いかけるのではなくて、共通要素を見つけて全体に対して効くような解決方法を考える意味での問題解決が好きな方は、とても向いていると思います。

次も、こういうことばかり言うとあれなんですけど、何か問題が起きたときに最高の解決方法がない、それどころか、思いつく選択肢A・B・Cが全部最悪で、全然やりたくないという状況もあると思います。そういったときでもプロダクトマネージャーの場合は粘り強さ、ギリギリまで最善の手を考えて打つ姿勢は大事だと思っております。

あと最後は、LINEなので海外でも利用される製品を担当してみたい方にはとてもおすすめです。裁量についても、まだ日が浅いのですが能力以上のことを任せてくれるので、裁量を持ってどんどんプロダクトを作っていきたい方にはとてもおすすめの環境です。

私からは以上です。どうもありがとうございました。

(会場拍手)

続きを読むには会員登録
(無料)が必要です。

会員登録していただくと、すべての記事が制限なく閲覧でき、
著者フォローや記事の保存機能など、便利な機能がご利用いただけます。

無料会員登録

会員の方はこちら

LINE株式会社

関連タグ:

この記事のスピーカー

同じログの記事

コミュニティ情報

Brand Topics

Brand Topics

  • 面倒な「営業の活動報告」を工夫したら起きた組織変革 報告数が5.5倍アップ、社員が自ら動き出すしかけ

人気の記事

新着イベント

ログミーBusinessに
記事掲載しませんか?

イベント・インタビュー・対談 etc.

“編集しない編集”で、
スピーカーの「意図をそのまま」お届け!