小城久美子（@ozyozyo）

ソフトウェアエンジニア出身のプロダクトマネジャー。ミクシィ、LINEでソフトウェアエンジニア、スクラムマスターとして従事したのち、『LINE CLOVA』や『LUUP』などにプロダクトマネージャーとして携わる。そこでの学びを活かし、Tably社にてプロダクトマネジメント研修の講師、登壇などを実施。書籍『プロダクトマネジメントのすべて』（翔泳社）共著者

はじめまして、小城久美子です。

私はエンジニア出身のプロダクトマネージャーで、『プロダクトマネジメントのすべて』という本を共著で書いています。

今回はエンジニアtypeさんにご縁をいただき、連載の機会をいただきましたので「私がエンジニアだった頃に知っておきたかったプロダクトマネジメント」について余すことなくお伝えするつもりです。

なぜ、エンジニアがプロダクトマネジメント？

もしあなたの仕事が、仕様書に書かれた通りそのまま実装することであれば、プロダクトマネジメントは不要です。しかし、多くのエンジニアはエンジニアとしての役目と、プロダクトチームのメンバーとしての役目を持つでしょう。

プロダクトマネジメントをする上で、必要な領域はBusiness、UX、Techの交差領域だといわれています。プロダクトチームとしてこのベン図の和集合を満たすことでバランスよくプロダクトを育てていくことができます。

技術的な強みを持つプロダクトチームのメンバーとして、もっとどうすればユーザーを幸せにできるのか、事業を大きくできるのか、そういったアイデアを出すことでプロダクトはもっと良くなるはずです。

私が書いたコードでユーザーを幸せにしたい

もう一つ、エンジニアにもプロダクトマネジメントを知ってほしい理由があります。

私は、自分がイケてないと思う機能を実装したくなかったし、せっかく時間を使って開発をするならその機能でよりユーザーを幸せにする方法を考えたいと思っていました。

しかし、要件定義をした人に「それはイケてないと思う」と言った所で、「イケてる」かどうかは主観にしか過ぎないのでうまく議論をすることができませんでした。

今思えば、私はプロダクトの機能の考え方を知りませんでした。私が悪かったところばかりではあるのですが、少なくとも私はその時、開発が楽しくありませんでした。

もし、あの頃の私がプロダクトマネジメントの考え方を理解していたら、どうして自分の意見が却下されるのかに納得感を持つことができたでしょうし、もっとうまく議論してよりプロダクトを良くする議論ができていたはずです。

もし、昔の私のように「プロダクトを良くしたい」という思いの強さからつらい気持ちになることがある方がいれば、この連載が支えとなることを願います。もちろん、今楽しく開発している方のプロダクトがもっと強くなることのお手伝いもさせてください。

“プロダクト”とはアプリケーションのことではない

プロダクトマネージャーとエンジニアの話が噛み合わない理由の一つに”プロダクト”の定義の違いあると思います。

私はAndroidエンジニアだったので、プロダクトとは.apkのことだと思っていました。つまり、GitHub リポジトリにあるコードやビルドしたアプリケーションをプロダクトと呼んでいました。

しかし、“プロダクト”マネージャーが名前の通り責任を持つ”プロダクト”はアプリケーションではないのです。そのアプリケーションを使ってどんな課題を解決するのか、そしてその結果どんな状態を作ってお金を稼ぐのかというところまでを含んでプロダクトと呼んでいます。

例えば、今使ってくださっているユーザーではなく全く違う人たちをユーザーにしたいと考えていることもありますし、今のアプリケーションで課題を解決した後に生まれる次の新たな課題の解決を検討していることもあります。この未来をどう見据えているのか？ の違いがあることで、会話が難しくなってしまいます。

プロダクトとアプリケーション、それぞれの成功

例えば、『Youtube』のような動画プラットフォームを考えてみましょう。

動画の閲覧機能をつくったら次は、動画に高評価できる機能やリストで次々に動画を見る機能など、動画閲覧機能の延長にあるのでどんどん思いついて実装を進めていくことができます。

そして、きっと当初からある程度必要な機能を見据えて設計をするので、エンジニアとしても見通しが良く開発をしていくことができます。

しかし、ある日突然、プロダクトマネージャーが「動画を投稿しなくても、テキストだけで投稿できるようにしたい」と言い出します。

エンジニアは「うちは動画プラットフォームだ！ 動画がある前提で実装をしているので、今更動画がない投稿だなんて設計が破綻する！ ユーザーは動画を投稿したいからうちのサービスを使っているのではないか！」と反発します。

このとき、以下二つの観点からは、動画のない投稿は辞めておいた方がよいでしょう。

・アプリケーションとしての成功: 保守性の良さの観点から動画のない投稿はできない方がよい
・動画閲覧プロダクトとしての成功: 動画を閲覧するプロダクトなので、動画のない投稿は不要

では、動画のない投稿を実施した方が成功に近い観点はどんなものがあるでしょうか。それは、このプロダクトを「動画閲覧プロダクト」ではなく、「動画配信者と閲覧者のコミュニケーションをよりスムーズにしてファンをつくるプロダクト」として捉えたときです。

Whyとエンジニアの助言

プロダクトチームの中で意見が合わないとき、多くの場合それは前提の違いに起因します。

「動画閲覧プロダクト」なのか、それとも「動画配信者がコミュニケーションをスムーズにするプロダクト」なのかという前提の違いによって、このプロダクトに必要な機能は異なります。

コミュニケーションに齟齬があるときは前提に立ち返るために「なぜそれを良いと思うのか」を深く議論をし、その「なぜ」を解決する一番良い解決策を模索するのがよいでしょう。

一つのWhyに対する解決策のアイデアは無数にあります。実装上、動画がある前提で設計をしているのなら、例えば「いまの動画投稿を改修するのではなく、新しくタイムライン機能を作った方が負債が少なくて済む」といったコミュニケーションができると、もともとのプロダクトマネージャーのアイデアよりずっとよい検証ができることでしょう。

ちなみに、『Youtube』にもコミュニティー機能が最近できましたね。動画投稿とは別にチャンネル登録者とのコミュニケーションができるようです。

次回に向けて

今回は抽象的な話となりましたが、なぜエンジニアにプロダクトマネジメントを学んでほしいのかについて書きました。次回以降はより具体的に、プロダクトをつくるための思考法を紹介していきます。

第2回は、アプリケーションではない抽象的なプロダクトとはどういったものであるのか、どうやって未来を見据えた仮説を構築するのかについてお話します。

最後までお読みいただき、ありがとうございます。私はこうした記事に限らず、主張とは誰が言っているかではなく内容で評価されるべきだと考えていますが、私の背景を知っていただくことでより伝わることもあるかと思いますので。

最後に自己紹介

小城久美子。珍しいですがkoshiroと読みます。フリーランスで仕事をして、プロダクトマネジメント関連ではTablyという会社でアドバイザリーや研修講師もしています。

経歴は、新卒でミクシィに入社しソフトウェアエンジニアとして広告系のお仕事をした後、家族アルバム『みてね』の立ち上げに携わりました。

その後、LINEに転職して、『LINE Pay』、公式アカウント、『LINE Beacon』といったプロダクトを経て、『LINE Clova』事業の立ち上げ時にプロダクトマネジメントのお仕事に転身して、その後携わったプロダクトには『LUUP』があります。

私はたくさん失敗をしますが、これらの失敗は世の中によくある失敗なのではないかとも考えています。失敗を元にプロダクトマネジメントを学問的に捉えることで私は同じ失敗をしなくなりますし、他の方が同じ失敗をしなくて済むのではと考えて、プロダクトづくりの手法を体系化して発信しています。

成果物に対して「すごい！」と言われるより、「もっとこうすればいいのでは？」「ここは他の考え方があるのでは？」とヒントを貰える方が嬉しいです。

「プロダクトづくりに関する知識を広げ、深め、身につける」ことを目的とした『プロダクト筋トレ』というSlackコミュニティーを主催してもいます。この記事が参考になった方がいらっしゃれば、ぜひお越しくださいね。