dorakueyon

プロダクトマネージメントと機能一覧という名の魔物

はじめに

プロダクトを開発していくうえで、機能一覧ほど安易なものはない.

機能一覧とはとても便利なものだ.
これから作られる機能が一覧化されていて、「優先度」までついている.
場合によっては「リリース予定日」まで記載されている.

その一覧性等により、ステークホルダー(決裁者)が意思決定を行う際のインプットなどに重宝される.

完璧な成果物だ.

ただ一点を除いては.
それは機能の一つ一つが「ユーザー」の価値に紐付かない場合が多いということだ.

「ユーザー」の課題を解決することを念頭に始まった開発も、次第に「プロジェクト化」していき、機能一覧の管理、及び優先度の高いものから順に開発していく形に収斂していく.

そこの中心にいるものは、かつて「プロダクトマネージャー」と自称していた「プロジェクトマネージャー」だ.

今回は、プロダクト開発として始まったものが次第にプロジェクト化していくケースを記載する.
あわせて、プロジェクト化していく要因の一つである「機能一覧」が、そのコミュニケーションコストの低さによってプロジェクトの中心となっていく状況を説明したい.

開発開始時 ~ プロトタイプ

プロダクト開発の前段は、「課題発見」プロセスからはじまる.
通常、プロダクト開発を開始していきなり作るべき機能一覧が作成されることは無い.

最近では、どのようなプロダクト開発も、最初に解くべきユーザーの課題設定が行われる.

as-isのフロー整理やデザイン・シンキングなどを駆使し、ユーザーの特定化、及びユーザーの解くべき課題の設定が行われる.
そして、ある程度課題整理がされた後、エンジニアとともにプロトタイプの作成が開始される.

このフェーズにおいては、開発メンバーは下記のように状態となっている.

とにかく、ユーザーの課題を解決しようというモチベーションがとても高い.

機能よりも課題をベースとした会話が行われ、エンジニアとともに、最適と思われるソリューションの検討/プロトタイプの試作が行われる.

顧客が喜んでくれるものがなにか、というユーザー中心の考え方が、開発メンバーの基本となっている.

開発拡大期以降

プロトタイプを利用したユーザー調査の結果、ある程度ユーザーがついてくれる目処がたっとしよう.

実際の本リリースを目指し、プロダクトマネージャーは想定される売上規模や開発規模の試算を行う.
そして、プロダクトとしてのビジョンとともに、プロダクトとしての「戦略」がステークホルダーに対してコミットメントされる. 「ターゲットとしてはXXX. 想定利用ユーザーXXX人. 初年度で売上XXX万. 」といった具合だ.

このあたりから、ユーザー中心だったプロダクト開発から、次第にプロジェクト化していく. 機能一覧が作られ始められるのもこのころだ.

規模の大きな組織になると、このタイミングでより「ビジネス」に近いメンバーの関与が多くなる.
また、近年のSaaS型サービスでは更にマーケティング、カスタマーサポートなど関連するアクターも増大する.

ユーザー視点にたった観点の他に、いかに他のプロダクトからスイッチさせられるか、という観点から機能の劣位表が作成されはじめる. そして、競合にある機能のうち、劣位になりそうなものは機能一覧に「優先度高」として追加される.

個別ユーザーのヒアリングも毎週のように実施され、顧客の要望ベースに機能が一覧に追加されていく.

ここで日々肥大する機能一覧は、システム仕様の検討も行われ、想定工数の大小がつけられる.

そうして優先度と工数の塩梅がとれるものから、「アジャイル」開発のスプリントスコープ(開発対象)に流れていく.
想定リリースタイミングは各ステークホルダーに連携され、テストの取りまとめやリリース時の連携など、日々の業務にプロダクトマネージャーは忙殺されていく.

次第に、機能一覧をこなすことがタスク化していく.

要望者の期待値管理や開発側の工数の管理、ステークホルダーとの調整など、いわゆるプロジェクト管理の時間が拡大していき、プロダクトマネージャーのユーザーに対して利用される時間は日に日に減少していく.

プロジェクト拡大期に増加する下記の作業は、一見ものづくりのための作業にみえて実際はプロジェクトマネージメントワークとなる.

顧客の課題をいかに解決するのか、という視点はないがしろになり、いかにプロジェクトを円滑にすすめるか、というスタンスに変化していく.

なぜそうなるのか

理由は様々あると思うが、一つあげるとするならば、「機能一覧ベースのほうが、プロジェクト思考が強くある組織ではコミュニケーションコストが低くなる」という理由をあげたい.

プロジェクト思考が強い組織の特徴として、それぞれのアクターが自身の機能の役割に終始することで、プロジェクトを個々が推進する.
マーケはマーケ、営業は営業、開発は開発、といった具合だ.
そういったアクター間のコミュニケーションは日々発生するが、そのコミュニケーションは機能単位でなされることが多い.

例えば、

など、機能単位でなされることが多い.
アクター間のコミュニケーションとして、input/outputが「機能」を単位としてもので媒介される場合、個々のメンバーも、次第に、「機能」単位の思考に収斂していく.
顧客の課題ベースで思考を始めるよりも、機能を主語にしたほうが、アクター間のコミュニケーションがスムーズになるからだ.

言葉を言い換えれると、課題思考で検討しても、他アクターから求められるoutputは機能ベースのものであるため、次第に検討の段階から機能ベースで思考してしまう、ということになる.

特に関係者が多くなる場合、それが顕著だ.

例え、プロダクトチームがプロダクトビジョンを掲げていたとしても、プロダクトチームから離れるほど、その浸透度合いは低くなる. 何を解決するのか、ではなく、どのような機能が提供されるのか、という思考が支配的になる.

どうすればよいか

「プロダクトファースト」という価値感が低い組織では、プロジェクトベースの思考に収斂していくことは忌避しづらいのかもしれない.

関係者が増大すればするほど、チーム全体が次第にプロジェクト思考に吸収されてしまう. 課題志向でのプロダクト開発から乖離する.
あるいは、プロダクトチームとそれ以外とで別の志向で進んでしまう.

結局、みもふたもなくなってしまうが、プロダクト思考の組織にならないことには、プロジェクト思考から逃れることはできないのではないだろうか.

おわりに

開始当初はユーザー視点で物事を考えていたとしても、振り返ってプロジェクトマネージメントになっていたというケースは非常に悲しい.

組織全体のコミュニケーションが楽な方向に流れてしまい、ユーザーからどんどん離れてしまうのは、プロダクトマネージャーが最も忌むべき状態である.

「機能一覧」を中心に物事が進んでいると感じた場合、プロダクトマネージャーは顧客視点に立てているかどうか、今一度自問する必用がある.

参考文献