14
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

『これがないと困る』を引き出して最速で学ぶための土俵をつくってみた

Last updated at Posted at 2025-12-24

こんにちは、LITALICOでPdMをしているみなみです。
入社して1年と少し、発達ナビ運営支援の新規機能やグロースの企画を担当させていただいております。

LITALICOにも様々なプロダクトがありますが、事業環境が異なれば戦略も変わり、プロダクトとしての価値を届ける広さ・深さ・スピードも変わります。

今回は ”最小単位の価値をできるだけ早く出す” ことが優先であった局面において、
顧客の『これがないと困る』を引き出して、最速で学ぶ土俵を作るために、プロセスを作ってみた話をしたいと思います。

チームを迷子にさせない要求定義のプロセス

前述の通り”最小単位の価値をできるだけ早く出す”ことが命題でした。
顧客からは「A〜Zまで全部ほしい」「うちではα、β、γのパターンがあるから対応できるようにしたい」「全部LITALICOにしたいからなるべく早くほしい」といった、とても熱量の高い要望をいただいていました。

早く出すためには最小単位の価値を定義する必要があり、以下のように進めました。

最小単位の価値をまず作ってみた

既存顧客のヒアリングから、業務フローを整理しAsIs/ToBeを描きながら、大多数が抱えるペインを5W1Hで整理し、PdM、デザイナー、エンジニア、QAで要求を読み合わせしました。
その後WFを5−6割作成した段階での視界はこんなイメージでした。
・「既存の形式に沿えば、直感的に使えて喜ばれるはず」
・「前工程の開発をしているチームの手を止めるのも良くないから、ある程度固まってからレビューしてもらおう」
・「便利機能は諦め、理想をスリムに削いだものを作ればいい」

要求漏れが見つかり複雑性も爆発した

しかし、いざ詳細を詰め始めると、自分の想定とは真逆に進んでいたことに気づきました

UIUXの複雑化: 顧客にとって理解しやすそうに見えたUIは、今までユーザが脳内で行っていた「判断」を無理にプロダクトに落とし込んでおり、逆に複雑性が上がり、開発上の論点が雪だるま式に増えてしまった

コミュニケーションコストの増大: チームにはそこに至る経緯が十分に伝えられておらず、「なぜこの要求からこのWFになったのか」という目線のすり合わせからやり直す必要が発生した

MECEではない要求: 要求の抜け漏れが発覚し、将来的な拡張性とのコンフリクトが発生しました。「将来的にやりたいこと」が考慮されていないため、「その要求があるなら設計はA→Bに変える必要がある」といった手戻りが発生しました

見えない「判断」が欠落していた

要求整理に着手する前、私は顧客ヒアリングに行きまくっていた時期がありました。
そのせいで、なんとなくその機能に対しては自信を持っていたのだと思います。

でも、顧客ヒアリングで「今のペイン」は拾えていたものの、ユーザが言葉にしない「頭の中での前提条件や判断」を落としていました。特にそれが常時発生するものではなかったので見落としてしまっていました。

例えるなら年賀状は一見すると「同じ文面を印刷して送るだけ」に見えるフローですが、実際には、
・友人か取引先か遠い親戚か
・喪中ではないか
といった無意識に近いレベルでの「人の判断」が入っています
私はその「目に見えないが不可欠な運用」を見落とし、表面的な操作だけをなぞって最小限にすることで、「スリムにしたつもり」になっていたのだなと振り返って思います。

チームで「価値の濃淡」を描いた

この失敗から、エッジケースであっても判断が発生する箇所を必ず業務フローに表現し、MECEさを担保できるよう、タスクと具体的な作業内容を詳細に洗い出すようにしました。

今解決したいペインを「コア体験(最小単位の提供価値)」として定義し、将来像もセットで並べることで、情報の解像度を上げることに取り組んでみました

1.業務フローの整理: まずは「顧客が今やっていること」をすべて書き出す
2.構成要素の分別: それは「本筋」か「横道(例外)」かを分ける
3.詳細タスクの洗い出し: 「人の判断」が発生する箇所をすべてMECEに書き出す
4.ペインの特定: どこでユーザーが苦しんでいるかを紐付ける
5.優先度分類とユーザストーリーの作成:【これがないと困る】【あったら嬉しい】【夢を描くならほしい】 で分類しユーザストーリーを作成

この可視化したユーザストーリーとWFを初期段階からチーム全員でレビューし、「要求・UX・工数」のバランスを全員ですり合わせながら進めました。

この時はとにかくチームの流れも止めてしまっていたし、めちゃくちゃ焦っていました。
こんな最初からやり直していいのか、やり直すくらいなら膨らんだものでも着手した方が結果早いんじゃないか、と迷宮入りしていました。

でも今振り返るとPdMとしても道筋を持って「今回はここまでしかやらない」と言えるようになり、全員が「なぜやらないのか」を理解しているため迷いがなくなったように思います。
「何を選択し、何を諦めるか」の納得感を持って進める体制へアップデートできたことは重要な成果だったなと思います。

蓋を開けて『これがないと困る』を引き出してみたら

当然ながらリリースして終わりではなく、顧客からのFBも集まる中で次の壁に当たりました。

削ったものがある顧客にとっては「これがないと困る」だった

【あったら嬉しい】とシビアに切り分けていたものが、想定以上に多くの顧客にとって【これがないと困る】ものだったとわかりました。

正直で前向きに丁寧なFBをくださる顧客や、不満を感じてご意見をくださる顧客もいました。顧客と接点を持っている社内のメンバーからもいろいろな意見をいただきました。

あんなに考えたのに…と受け取った時は落ち込んだし、焦る気持ちにもなりましたが、これがリリースして初めて得られた顧客の「本当の最小単位の価値」であったし、このラインが可視化されたこと自体が価値だといまは捉えています。

ある顧客からは「LITALICOなら使いやすいものを作ってくれると期待してるから頑張って!」と声をかけていただきました。PdMとしてはそんなに前向きで温かいFBをいただける環境はとても恵まれていると思っていますし、LITALICO入社時に描いていた「顧客からの声に直接触れて共感し、価値を提供すること」が体現できてるなとも思いました。

これらの改善プロセスは絶賛取り組み中の内容なので、また来年記事にできたらと思っています。

学んだこと

『最小単位の価値を提供する』ということは、確度の高い70点を早く叩き出すことと捉えていましたが、顧客の『これがないと困る』を引き出し最速で90点に近づけるための土俵をとりあえず作ること、だったんだなと思いました。

ユーザヒアリングをして、色んな角度で「これがないと困る」をどれだけ多種多様に受け取って最小単位の価値を定義しても、迷うことはあります。

私のPdMとしての今後の課題は、「わたしのかんがえる”顧客が思う譲れないライン”」を頭の片隅に置きながら、より早く土俵に立ち、「本当の最小単位の価値」を引き出す勇気を身につけることだなと思いました。(最後は根性論になった)

このサイクルを大切にしながら、時には勇気を持って未完成でも土俵に上がり、発達ナビをより良いプロダクトに育てていきたいです!

俺みたいになるな!ということで「とにかく早く価値を提供するぞ!」と意気込んでいるPdMのなにかの参考になれば嬉しいです。

14
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
14
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?