メリークリスマスイヴ！エンジニアリングマネージャーの さとうだいすけ @dskst9 です！
この記事は Engineering Manager Advent Calendar 2019 24日目の記事です。
みなさんはプロダクト作りを楽しんでますか？
私達エンジニアの存在意義であるプロダクト開発において、プロダクトマネジメントは切っても切れない存在です。
本稿では、エンジニアが持つべきプロダクト思考とは何かを探求します。
エンジニアにとってプロダクトとは
私達は機能を作っているのではなく、プロダクトを作っています。 プロダクトとは顧客に届ける価値であり、私達はプロダクトの価値を高めたいと考えています。
しかしながら、プロダクトを取り巻く環境は多様であり、価値提供のための活動は開発だけに留まりません。
採用などの一見プロダクトと関わりのないような活動も、辿ればプロダクトの価値提供に帰着します。
プロダクトの価値がゼロになると
プロダクトの価値がゼロになると何が起こるでしょうか。そう、私達の価値はゼロになります。（お給与も出ません…！）
企業はプロダクトの価値を販売して売上を上げ、原価や固定費、変動費などを差し引いて利益をあげます。簡単な図にすると下図のように整理ができます。
私達の人件費は、管理会計上は固定費に属します。財務会計上は少しややこしいので下図を引用いたします。
プロダクトの価値とは企業活動においてコアとなるものであり、プロダクトが上げる売上やお金の流れを理解して開発をする必要があります。採用などの活動においても同様です。人件費を増やすことで、どのような効果を出すのかを計画して行う必要があります。
私達の活動すべてが企業の活動と理解すればよいでしょう。
プロダクトにおける技術的負債の返済
プロダクトに一見関係のなさそうな技術的負債について考えてみましょう。会計図解で見たときに技術的負債はどこに入るのでしょうか。
プロダクトの生産活動の低下による人件費増、価値提供遅延による売上減などに反映されるかも知れません。技術的負債の返済とは何をするべきか、一般的には下記ような活動がイメージされるのではないでしょうか。
- プロダクトコードをリファクタリング
- システムの段階的リニューアル
- 開発プロセスの自動化
これらを解消することで、価値提供が加速化してさらなる利益を見込めることでしょう。
しかしながら、技術的負債の返済において“プロダクトの価値”があまり登場してこないという問題もあります。
たとえば、リファクタリング。リファクタリングとは「ソフトウェアの外部的振る舞いを保ち、内部構造を整理すること」とあります。外部的振る舞いを変えないのはなぜでしょうか、変えてはダメというこはないはずです。
技術と同じようにに、長い年月をかけてプロダクトの負債も溜まっています。プロダクトの価値を最大化するためには、プロダクトの負債も返済する開発が求められています。
プロダクトの機能と価値と負債
企業活動におけるさまざまな施策がプロダクトの機能として開発され、年月が経つほど機能は増えていきます。すべての施策が成功すればいいのですが、ほとんどは失敗に終わり、長い時間をかけて価値を失っていく機能もあります。知らず知らずのうちにプロダクトの負債は溜まっているものです。
どのような機能も存在する限りは、顧客体験を提供する機能でなければなりません。
負債だと思っていたものがプロダクトの重要な機能であるということもあります。Quipper社の事例はとても素晴らしい事例なので紹介いたします。
プロダクトの負債を判断することは難しく、事業の状況やどこに何を投資しているかにより定義する指標が異なります。プロダクトにおける機能が、売上等どの指標どう変えようとしているものなのか見極めが重要となります。
プロダクトの価値を高める、あるいは負債を返済する
幸いなことに、エンジニアはプロダクトの価値を気付きやすい環境にいます。
変更のないプロダクトコードに気付いた時。リクエストがないエンドポイントに気付いた時。過去に開発したあの施策はどうなったのかと気になった時。ソースコードという剥き出しのプロダクト、ログというむき出しのデータからでも気付くことはたくさんあります。
せっかくの気付きは、すぐにでもエンジニア自身で価値を見極めたいものです。とはいえ、プロダクトの価値はどのように見極めたら良いでしょうか。
ストーリーを知る
プロダクトには必ずストーリーが存在します。まずは、プロダクトを定義する5つの質問に答えてみましょう。
- なぜ開発をするのか？ （ビジョン）
- 誰に対しての製品なのか？ （ターゲットとなる顧客）
- どのような問題点を解消するのか？ （ユーザーの抱える問題）
- どのようにそれを行うのか？ （戦略）
- そして、なにを達成するのか？ （最終目標）
しっかりと答えられましたか？ プロダクトのストーリーがクリアになると、プロダクトの機能を考えることができます。
ストーリーは企業のKPIツリーなどにも反映されているはずなので、各種指標も確認してみましょう。
ファクトを集める
プロダクトの価値の検証は「この機能をこうしたらいいのではないか？」などの小さな疑問が事実なのかを検証することから始まります。
データ分析チームに頼らずとも、まずは見れるデータの範囲で確認します。プロダクトのKPIツリーのどこに効果があるのか、それに対して機能はどのような効果を出しているのかデータを集めます。機能の狙いや機能が作られた背景を丁寧に紐解いていきます。
多角的にファクトを集めて仮説が有力になったところで、データ分析です。データ分析のプロがいる場合は協力してもらいましょう。
機能の価値を見極める
集めたファクトを分析すると機能の傾向が見えてきます。
- 高い価値を提供している
- 価値は少ない（あるいは、価値がない）
価値が少ないものは、機能改善をして価値を高める可能性を秘めています。 一方で、価値がないというものも事実存在します。
- 価値が少ないものは価値を高める
- 価値がないものは削除する
という、2つのアクションが考えられます。
ほとんどの場合、価値を高める可能性を模索することになりますが、価値がないものは放置してはいけません。*1
ネゴシエートする
機能を改善、あるいは削除するときには、ステークホルダーと交渉する必要があります。エンジニアもプロダクトオーナーなどと交渉する機会はありますが、苦手な人が多いのではないでしょうか。
交渉とはただ論理的に会話をしてもうまくいきません。ゼロサム*2ではなく、Win-Winの関係を目指す必要があります。そこで、交渉の条件や範囲など整理する方法としてBANTA, RV, ZOPAを考えます。
- BANTA(Best Alternative To Negotiated Agreement)
交渉合意できなかった場合の最善案。 - RV(Reservation Value)
BANTAを行使した際に得られる価値。絶対に交渉で妥結しないという最低条件。 - ZOPA(Zone Of Possible Agreement)
交渉妥結する範囲。
図解すると以下のようなイメージになります。
ZOPAの範囲で以下に交渉を妥結するために、ステークホルダーとの会話を進めます。
プロダクトの負債を返済を例にします。 RVがプロダクトの保守費用を1%削減することであれば、その価値が他指標を押し下げて利益にどう反映するのかをロジカルに説明します。次に相手の視点から見るとまた別の案が出てくることで交渉が始まります。相手のRVを理解してZOPAの範囲を見出して妥結案を詰めていくことになります。
また、顧客との交渉も必要です。ある時に機能が無くなるということが許容できることは難しく、別の機能でフォローアップすることや段階的に機能をクロージングしていくなどさまざまな考慮が必要です。
機能を削除するときは機能を作ることよりも大変になりますが、誰かがやらなければいけません。負債を返済することで、プロダクトは健康を保ち続けさらなる成長させることができるはずです。
成長するプロダクトを描く
プロダクトの機能を改善、プロダクトの負債を返済する横で、新たなプロダクト機能開発は始まっています。 プロダクトの進化 (Sequoia Capital) - FoundX Review - 起業家とスタートアップのためのノウハウ情報 ではプロダクトの進化というものが紹介されています。
プロダクトの成長はEarly, Growth, Hyper Growth, Matureのフェーズがあります。 Growth, Hyper Growthでたくさんの機能が作られますが、急激な成長はたくさんの負債を生むはずです。「今回だけ」と言われて機能を作ることもあるでしょう。
Matureフェーズに入ったらプロダクトの負債をゆっくりと返済できるかといったら、そんなことはありません。プロダクトは新たな環境や機能で新たな成長曲線を描きはじめます。
プロダクトが成長する限り、プロダクトを作り続けていきます。プロダクトを作り続ける限り、プロダクトの改善は続きます。
おわり
エンジニアが持つべきプロダクト思考について探求してみました。
プロダクトを開発すると言えば、何か機能を作るイメージが強いかと思いますが、時には何も作らないことが最良のプロダクト作りになることもあります。
なにをしないのかを決めるのは、なにをするのかを決めるのと同じくらい大事だ。
ー スティーブ・ジョブズ
プロダクトチームの一員になるということは、開発している機能が”プロダクトにどのような価値を提供するのか”を理解を求められます。プロダクト思考を持つことは、正しいプロダクト作りの手助けになってくれるはずです。
