プロダクト開発プロセスの価値
この記事について
直近PdMとして仕事をしていく中でプロダクトが世の中のどのようなイシューを解決することでどう良くなるのか？を検証していくことも大事だと考えているのですがプロダクト開発における全体のプロセスも大事だと感じそのことについて現状の考えを残しておくため書いてみました。
プロダクト開発プロセスが差別化時代
既に差別化時代になっていて気づくのが遅かったのかも知れません。
近年はネットや本でプロセスについてアクセスしやすい環境かと思います。
ウォーターフォール、アジャイルといった言葉を聞いたことがある方は多いのではないでしょうか？
それぞれの手法についてどういうものか、どういうやり方なのか？については説明が載ってるものがほぼ(正しい、正しくないの判断はある)で実際取り入れると良し悪しは置いといてリリースまでは到達することが可能でリリース自体は達成しやすいと考えており取り入れて良かった！とKPTで落ちてきやすい(ネガの言いにくさもあるかも)気がします。
これで良いのでしょうか？
僕個人は良いと思いません。
後に触れるOutPut, OutComeの観点でまずOutComeを得るためにはOutPutが必要となります。リリースすることはOutPutに該当し僕らが真に得たいのはOutComeになると考えるためOutPutに満足してはならないと考えてます。
※リリースすること自体は差別化にならず当たり前な活動の一つに属するという認識。
OutComeに着目し成果を得るためのプロセス、言い換えると長期に栄えるためのプロダクト開発のプロセスとはどういうプロセスなのか？に関心を持ち
現場で改善を繰り返す、繰り返さない、※改善プロセスはどうなっているか？は一つ見えてこない他社とのプロセスにおける差になるのかもしれません。
また、こういうケースの時は誰がどう動くなど個々が持ってるプレー原則なるものがプロセス中に意図したしてない戦術のような動きも含まれていると考えます。
※改善プロセス
・プロセスイシューがどう落ちる？
・優先度は？
etc…
割と感覚的な話になってしまい恐縮なのですが、プロセス導入の初期における印象について触れます。
このプロセスを導入しよう！フェーズはサッカーで言うなら4-3-3システムで戦おうとほぼ近い感覚を持ちます。
プロダクト開発のプロセスは導入した後効果を実感しやすいです。実感しやすさはリリースまでがゴールと思ってしまうが故に感じやすさがあると考えてます。
サッカーにおいてはとりあえず試合ができる状態になります。
試合に勝つというOutComeを得るには試合に出れるOutPutが必要でここはプロダクト開発と同じところがありそうですね。
しかし、先に触れましたが僕らが求めるのはリリースのOutPutではなく成果であるOutComeです。
試合に出ることが目的ではなく勝つことが目的です。
勝つためには？の手法で思い浮かびそうな一つとして模倣をあげます。
ここで先ほど挙げたサッカーの4-3-3を具体化した例を出します。
まず見てわかるのは人材の差ですかね。
プロダクト開発におけるこのイメージは他社のスターエンジニアなどでしょうか。
このフォーメーション図だけでは見えないものが隠れてます。
それは戦術です。
シティの場合は偽9番、偽サイドバック,5レーン、各選手の位置で自分がどこにいるべきなのか？、サイドが高い位置を取ってる場合他選手の配置はこうするなどのプレー原則などが該当するかと思います。
プレー原則の例としては障害が発生した場合解決までこうすると既にある程度決まったプロセスに乗せて対応していくようなイメージです。
簡易的にいうのであればAという事象が発生した場合はBのプロセスをベースに解決まで持っていくような感覚で割と無意識にやっているよう思えますが必ず図示化できる対象になると考えてます。
プロダクト開発のプロセスと比べるとサッカーの場合試合を観に行く、録画を巻き戻しで観るなどして模倣、対策は出来ると言えば出来る環境かなと思いますがプロダクト開発の場合所属してるメンバーの振る舞い、戦術なるものは基本一切見えてこないと思います。
何かしらの情報源からキャッチアップし試してみても上手く行くエッセンスは現場に転がっており(メンバーそれぞれの振る舞い、プロセスの細かいところなど)得た情報をそのまま試すと自滅するパターンもあるかもしれません。
(これもリリースまではいけるが成果につながるイメージはそこまでない)
なので、導入フェーズは始まりにしかすぎずとりあえず回るよねで終わることに対しては懐疑的でどういうプロセスであるべきなのか？は現場を俯瞰(特に関わる人)し都度考えてコトへ向かうその時の最善なプロセスを追うことは重要かと考えます。
ここが言語化できていれば現チームではどういう人が足りてないのか？
も明確になり採用する際の獲得したい人材像もはっきりしやすい印象があります。ここまでできればリファラル採用というのは角度高く採用できる手段として最適に思えどのような振る舞いを期待しているのか？を過去から探して適切な人が見つかりやすいように思えるからです。
(リファラル採用を行うには社員がその会社、プロダクトのファンであるという状態が前提で機能すると考えてます。)
僕自身はイシューの特定含め、この見えないプロセスこそがプロダクト優位性を作り上げ、価値の積み上げを行なっていく上で大事な要素だと考えております。
良いプロセスについては模索中でして、形になっていけばOutComeに繋がる再現性高い組織になれるのでは？とちょい夢みてたりしますが興味があり追っかけてます。
次は自分が好むベースのプロセスからどういう戦術があるか？について触れていきます。
プロダクト開発プロセス
プロセスのベースとして好んでいるのはlean+agileです。
緑: デザインフェーズ
黄: 開発フェーズ
赤: 振り返りフェーズ(←ここ図示化されてないイメージですが追加
きっかけとしてはagileでの開発をよく観察すると開発面だけでなく企画も簡易的ではあったのですがagileのようなサイクルで回っていることに気づき海外のサイトや本などから知見を集めた結果lean+agileというパターンに辿り着き慣れていたのと今までの経験的にしっくりきてます。
lean+agileのポイント
大きな手戻りがないようプロセスでカバーできる
アイデアを社内で検証し不確実性をなるべく落とした上でリリースできる
QAではより良くするためのユーザに価値を届ける最終フェーズであるべき磨きが行える
どういう人がどのフェーズでどういう思考のもと行動を行うか？(プロセス戦術)
デザインフェーズ
このフェーズでは次にリリースする施策内容の決めを行うためのイテレーションを回すのがメインだと考えてます。
特に重宝されるスキルはデザインだと考えており次の施策案はいくつかの情報源(数値、インタビュー、アンケートなどの貯蓄)から案を出すが議論する際に抽象度が高く進めていくうちに議論参加者の脳内に描く像がブレてゴールまでが遠くなるまたは中途半端になる経験があります。
生じてる課題は抽象⇄具象の往復にそれぞれの脳内で違うものを描き始めることでこれがズレに繋がります。
この課題に対するアプローチの方法として僕がオススメするのはデザインで
皆が視覚的に同じものを見ている状態であればそもそもここからズレる？なケースもないですし議論の成果の落ち方も大きく異なります。
もやもやして終わるとまた同じような会議を開く必要が出てきたりもするので抽象的な話のスタートになり得る会議はデザインを通して具体的にイメージできるよう仕組み化しちゃんとコトへ進めるプロセスになっているか？に着目することでこのフェーズのイテレーション速度、質は良くなるかと！
僕自身はエンジニア出身であり会議中の抽象⇄具象運動をイメージしやすくするために簡易的ではありますがデザインがあった方が良いと捉えFimgaで作る(デザイナーほど上手く使えてはない)かホワイトボードを駆使するかの2択でいつも考えてます。
抽象⇄具象の往復運動を積み重ねこのフェーズではなるべく落とせる不確実性は落とし少しでも価値提供できる可能性の角度を上げることが大事だと考えます。
何を作るか？の方針が決まれば簡易的なプロトを作成しなるべく多くの人に見てもらうのが良いと考えておりペルソナに該当する、普段から使ってる社内の方に触れて反応を見ることでも社内で落とせる不確実性はあると考えるのでなるべくここは泥臭く潜んでいる不確実性を落としユーザへ届ける価値について考え行動しまくるのがベターかと思います。
プロトに関してはコードを書くというより速度優先で行えるツールがコスパ良いかと。
抽象⇄具象、プロトと大きくこの二つを切り取るだけでもデザイナー出身PdMが生きるフェーズって感じがしますね！
開発フェーズ
このフェーズで意識するのは赤矢印の開発→デザインフェーズへの戻しになります。
これってどういうこと？、何がやりたいのかわからないなど開発者からの負なるものが集まった結果巻き戻しになるイメージです。(例の一つになるかと
赤矢印が発生すると関係者は多少なりと疲弊します。
なので発生しないようにデザインフェーズでイテレーションを回すなりで磨くのは大事になってきます。
リリースの手順が絡んできそうな場合、例えば強制アプデが必要でServerのリリースが先とか順序立てが必要な場合もこのフェーズで計画しておくとスムーズなのと当日慌てるとミスる可能性もあるので安全性を保ちながらリリースできるよう振る舞うことも大事かと。
振り返りフェーズ
デザイン、開発フェーズを終え結果がわかるフェーズです！
このフェーズにおいて大事こととして考えてるのはOutPutではなくOutComeだと考えておりこのことについて触れます。
OutPut, OutComeの定義は以下です。
OutPut: 世の中にリリースすること
OutCome: 得た成果
OutPut → OutCome
"とりあえずリリースしよう" という言葉がありますがOutComeが大事だよねと分かればそうだよねと思えてきます。
ポジティブな成果が得られた場合は施策がどういう結果だったのか？を共有し士気上げとかに繋げていける場になるでしょうがネガティブな成果になった場合の振る舞いこそ重要性があると感じます。
ネガティブな結果になった際一番気をつけないといけないのは
"何も得られることがありませんでした！"と共有する、聞き手はそう捉えることです。
進撃の巨人の一コマになりますが、
この報告を受けた方(壁の内側の民)はただただ不安になるだけです。
ではどうあるべきなのか？は次の手を考える際今まで持ってなかった事実を獲得できたことについて触れることかなと考えてます。
例
・建物の位置を地図に起こし安全性が高いであろうルートを確立
・巨人の動きにパターンがあることを把握
一般的に見えてこないフェーズ例
lean+agileの図示化されたものに追加されてないフェーズについて触れます。
というのも実際のプロダクト開発を観察するとlean+agileのフレームとして括られるプロセスには含まれてないものをあえて図示化したらどうなるか？を整理したく見えてないプロセスの一例として起点の0フェーズを挙げさせていただきます。
デザインフェーズのアイデアを細かく見ていくと青色枠に含まれていることだということもあると思いますが敢えてフェーズとして表現します。(細かく見れるのであればこれもこれで図示化対象なところだと思います。)
このフェーズはプロダクト開発のプロセスを回していくための弾を探すため無数な情報から検証すべき内容を探るフェーズです。
闇雲にただみたら良いわけでもなくなるべくあたりをつけてみるのがベターかと思います。
施策のインパクト
グロースの逆説で書かれている内容ですがユーザが流れてない箇所の施策は当初思ってた以上に無風です。
一度やってみるのが良さそうですが経験してるとこの記事の受け止め方が違うかもしれませんね。
ちょこちょこ上下したりするのですが、その日の登録者数に影響されたり何かしらのトリガー(ユーザのメンタルとか)でも左右され影響度は結果小さくなると考えてます。
なので基本はユーザが多く流れているかつKPIツリーと照らし合わせてアイデアを練り上げていくのが良いと考えます。
定量、定性のバランス
個人的に定量、手異性どちらかに押し切ると※不安な印象がありバランスが大事だと考えてます。
※状況にもよるかと思います。0からの立ち上げの場合は自分だけが気づいている圧倒的な課題とかインタビューから出てきた熱量高いN1があると思うので。
定量→定性パターンは数字だけではWhy?が見えないです。
この数字が事実だと言えばそうなんですがなんでそうなるのか？については事実っぽく仮説を上げることがしばしば観測する中だと起こります。
なのでこの場合できる限りWhy?を追求し角度が高い(周囲が納得しやすい) 仮説を持つことが大事で定性であるインタビューや過去のアンケートからWhy?を説明することができそうな種を見つけることがプロセス中における不確実性を一つ落とすポイントになり得るかなと考えてます。
となってくるとインタビューというのはとりあえずやれば良い！というわけではなく何かしらの目的に紐づいている必要性が出てきます。
インタビューをなぜ行うか？という問いにユーザを知るためで済むようではだめで、具体的になんで行うのか？の目的を持って行わないとコトへの結びつきが弱い印象です。
また、インタビュー対象であるインタビュイー(ユーザー)をどうやって集めるか？もインタビュー要素において重要でどういう集め方をしたら角度高くイテレーションを回せるか？も戦術において大事な要素かと考えます。
例えばセグメント切ってこのセグメントのユーザに今回インタビューすることがWhy?に近づけそうなど。(FirebaseのAudienceバリバリ活用してるとか
情報の閲覧しやすさと操作性
膨大なデータはこのデータストアに置いてきた
叩けSQL
世はまさにBigData時代！！(ドンッ
これはこれでSQLを叩ける人が増えて目的であるデータ抽出がでdashboardにまとめいつでも誰でも閲覧できるようになってる仕組みがあれば問題ないちゃないと思います。
ただ、目的は達成できるんだけど運用もっと良く出来るくない？状態かと考えており個人的に触れてきた中だとLookerでdashboard化が良いかと思います。
普段SQLを書かない、書いたことない職種な方々でもLookerの使い方を教わればボタンぽちぽちでSQLが裏側で組み上がり目的のdashboardが作れるようになった場を何度かみてきたためです。
プロセス戦術に落とすと誰でもデータに閲覧できる、加工、作成できる環境と言いますかデータ民主化？は良いアプローチだと思います。
重要だと考えてること
チーム全員への経験値配分が均等
施策を行うたびに得た経験値はPdMに限らず関わった全ての人に配分されること、配分されるよう意識することが長い目で見た時重要だと考えてます。
なぜならプロセスに関わる人はチームメンバーだからです。
体感として責任を意識するとPdMが頑張るため結果経験値がPdMに集まってそうな気がしているのですが関わるすべての人に同じ経験値が蓄積されないとプロセスの改善へと繋がって行きにくさを感じます。
特に施策案出しをチーム全員でやる方法を採用している場合経験値が偏ると第一回の企画案出しから特に変わらないまま継続だけしてるような残念なルーティンになりがちなイメージがあります。
うまいことやるにはPdMが経験値の分配を意識するのとPdM外が施策一つ一つを自分ごととして考えられているか？と意識が双方向にマッチしてる必要があるとも感じます。
なぜなら自分ごとではなければ関心が薄く
共有もただ受動的なイベントでしかないためです。
プロダクト思考なチーム化を目指すのであれば意識しておきたいことの一つとして経験値はあるかなと考えてます。
採用にはPdMが絡むのが良い組織ではないか
とりあえず出てもらうレベルではないです。
プロダクトの成功に向けてコトを成し遂げたく現状のプロセスを俯瞰し見ているのであればどのプロセスのどの要素でどういう役割、振る舞いが欠けているのか？と全体のプロセスを早く回す上でボトルネックがわかっていれば獲得したい人物像が多少なりと明確になっていると考えているためです。
とはいえ難しいものもあるよねと思うのも正直ある・・・
PdMの採用に関しては現場にいるPdMのスキルをマッピングし今一番足りてないスキルは何か？をプロセス中に起きているボトルネックと照らし合わせつつ行うと角度高い採用へと一歩近づけるのではないかな？と思います。
頼れ！チームでコトへ向かえ
時には個のプレーと言いますか打開力が求められるシーンがあるかとは思いますがPdMである自分が・・・自分が・・・と矢印が自分に全て向くことばっかり考えているとダークサイドへと落ちていきそうなイメージです笑
プロダクトの仕様に詳しくユーザの一番の理解者じゃないとダメだ・・・と思い詰まらせないでください。
ユーザのことを考えていることは大変素晴らしいと思いますがその時一番詳しかったりするのはCSの方だったりします。
というのも実際ユーザからの電話、メッセージなどのお問合せに向き合っているためユーザと触れ合う時間というのはきっと長いはずです。
なのでチーム全体としてユーザのコトを大事と考えるのであればCSもチームだ！という認識が大事でユーザを知るためにはCSの方から声を集めていこうという戦術を足していくのもありだと思います。
大きなことを成し遂げるためには自分が。。。とならずに周りを巻き込んで総力戦で成し遂げていくプロセスを作り上げていくのが良いと思います。
線の太さが存在している
何度がプロセス図が出てきてますが各要素間には線が存在してます。
この線には太さ、言い換えるとコトへ向かっているか？のレベル帯が存在していると考えてます。
例えば画像内でレベルが高い、低いの二つに分類すると以下になります。
レベルが高い: 学び→アイデア, プロト→検証
レベルが低い: アイデア→プロト, 検証→学び
レベルが低いに挙げられる検証→学びのなぜか？の例としては
検証するも何をどう見て良し悪しを決めるのかがあやふやで学びへ持っていくも材料がなさすぎるとかです。
レベルが上がるような例としては以前はプロト→検証の線は細かったとします。課題となっていたのはプロトを現場エンジニアに頼んでコーディングしてもらっていたがゆえ検証まで到達するに時間がかかっていたとします。
そこで採用したのがノーコード(FigmaのProtoTypeとか)でそれなりに動きがわかるような仕組みを整えるというアプローチを取ったことが検証までの速度改善へと繋がるとかです。
線のレベル帯についてはプロダクト開発をする大きな目的にちゃんと方向あってやれているか？(コトへ向かっているか？)を基準としておくと割と白黒つけやすいです。
現場で採用しているプロダクト開発のプロセスの話をチーム全体で行う際も
デザインフェーズの話でも触れましたが共通したイメージがないと像がズレていくのでプロセスを図示化し線で強弱を付けここが今ボトルネックになってそうだよね。こういう取り組みで改善できるのでは？の共通課題認識を持って話しやすいかなと思います。
プロセス中のPdMのポジショニング
どこに顔を出して物事進めていくか？についてです。
環境(採用してるプロセス、メンバーなど)の影響度が高く必ずこうだ！ということはできないですがどんな環境であれ共通してそうな判断軸だと考えているのは"コトへ向かって進行するにあたり優先度が高いホットな場所か？"です。
ホットな場所で振る舞いどうだったか？何ができた、何ができていればもっと良い解決になったか？を都度振り返りつつ取り組んでいくとそのチームではありがたい人になっていけるのではないか？と考えます。
割と個人slackに感じたことメモって振り返りをするのはおすすめです。
また、そもそもホットな場所だったのか？の嗅覚センスなところはメンターとなるPdMな方がいる環境であれば相談してみると良さそうです。
例をいくつか紹介します。
開発,QA間で調整が必要なケース
両サイドが不安になることがないよう交通整理を行いスケジュール通りコトへ向かえるように整える。
こぼれ球問題
プロダクト開発を行なっていくとslackで投げられた不具合ややりとりの中で結局誰がやるんだっけ？と中途半端になることがあったりします。
エンジニア業務100%の時は表裏両方触れる技術スタックなプロダクトだったのでこぼれ球に食らいついては対応してたのですがこぼれ球はチームの全員が把握してるタスクではないためその周辺にいた方からはありがたがってもらえるのですが評価に繋がるイメージが出来ずボランティア？な面がちょい頭を悩ませました。
この経験からなるべくPdMとしてロールをこなす際はこぼれ球は基本率先して取りに行くことで同じような悲しみを背負うことがないよう意識はしてます。
チームが動きやすいようにする、プロセスを上手く回すためにこぼれ球も取ると思えば全然やりがいは違ってくるという感覚値でいます。
突発的だが開発リソースが足りない
機能開発がメインで進む中QAで上がってきた不具合が複数でお問合せで既存の不具合が見つかりこれも優先度高く対応しないといけない状況下ではエンジニアPdMの場合入っていける可能性があります。
ステークホルダーとの共有
状況にもよりますが敷いたロードマップ通りに行かない、別案があるが以前共有した内容とは別のものになっているなどステークホルダーに共有、相談した方が良いタイミングでアクションを取るケースです。
突発的な緊急性を要するケース
クリティカルな障害が発生しなるはやで解決しないといけないシーン。
このケースでは障害対応のプロセスが整備されてない状況であっても
まず自分から飛び込んでいくマインドが何より大事かなと思います。
と言うのも割とメンバー全員がお見合い状態になって誰がやる？と宙ぶらりんになりがちなところ多少あるかなと思っているためです。
なのでまず顔を出し状況把握した上で障害を解決するためにどうすべきか？を周りの協力をいただきつつ進めていくための道筋を作っていくことを考えるのが良いと思います。
PdMロールはホットな場所に出没しその場での振る舞いが割と重要になってくると考えてます。
また、場に顔を出す場合その場にいるチームメンバーが必ずいると思っておりメンバー間とのコミュニケーションは普段から取っているとやりやすさがあるでしょうし社内活動などを通して深く関係性を築くことができていればいるほど良い仕事ができるのではないかなと感じたりします。
さいごに
今や本や現在PdMをやられている方々がありがたいことに記事にしてくれたりとどういうスキルが大事なのか？について触れることができます。
僕個人としてはこれらに触れ所属してるProductのプロセスを俯瞰しコトへ向かうためには？早くやるためには？からボトルネックを見つけ改善していくことも一つスキルを身につける上では必要な振る舞いなんじゃないかなと考えます。
やるやらの判断、優先度決め、プロダクトの課題発見なども大事でありこれらはプロセスに含まれる要素だと考えているためプロセスでの振る舞いを意識しコトへ向かうための行動と振り返りをセットで行なっていくことでスキルはついていくんじゃないかな？と。
プロダクト開発は長い道のりで共に作り上げていくメンバーとは普段からも良い関係性を築いていく必要があるでしょうしいい成果を上げた時は皆がやりきった！やったぞ！と心から思える状態でお酒が飲みたいっす！
またこれまで経験してきた複数のチームで起こっていたことをプロセス図に表現し現状このプロセスが良い、このプロセスの場合このような振る舞いができる人がいいなどまとめていければいいな〜と思ってます。
所属してるチームのプロセスについて話してもいいよって方いらっしゃったらぜひ話てみたいので連絡待ってます😄
自分からも提供できるものは提供しますので！