冥冥乃志

ソフトウェア開発会社でチームマネージャをしているエンジニアの雑記。アウトプットは少なめです。

follow us in feedly

語ってもらうための仕掛け(フレームワーク)の重要性

ようやく自分の得意な「正しく作る」領域に持ち込めそうな状態になった、つまりはある程度のロードマップが見えてきたタイミングなので、これまでの仕事のまとめをしてみようかと思います。当たり前ですが、具体的な内容は出せません。抽象的な話でも参考になれば。

「語る」ことから始まる

「こんなプロダクトいいんじゃない?」ってのは、たいていちょっとしたアイデアからプロダクトの形を思い込んで話をし始める人から始まります。その人は何らかの課題を体感し、何らかのビジョンを見てるんだけど、形を思い込んでしまうとその形にとらわれてしまいがちです。その課題やビジョンを大切にしながら、それが目指すべき価値はどんなプロダクトになるべきか、を形にしていく必要があります。

形にする方法論は様々あるんですが、それよりも大事なのはその方法論を使うための材料(情報)を出してもらうことです。機能について合意をするよりも、「誰の、どのような課題を解決したくて、それでどう世界が変わるのか」を語りやすいフレームワークやプロセスを整備しようと思って手法を手探りしていました。

プロセス

今回、何度か行ったり来たりしながら、とりあえず落ち着いた流れは以下のような感じです。

  • プロダクトのオーバービュー
  • ストーリーマップ
  • UX(UI)

フォーマットというのは今この場に出ている(出てきた)情報を整理する力なので、自分の中で整理しやすいものを採択しています。

プロダクトのオーバービューを作る

少なくとも、今の思いつきがどんな姿を持っているかは整理する必要があります。最初はプロダクト全体で、そこからロードマップに従った直近のステップの範囲で俯瞰できるペラ一くらいのボリュームの方でとにかく何度も話に持ち込みたい。

この話の中で、この思いつきは本当に課題に効果が出ることなのか、といったことを言葉にしていきます。その中で私とビジネスオーナーの間にこのプロダクトのビジョンに対する知識が蓄積されます。

少しずつ語るんです。プロダクトがどういう完成系を持って世の中にインパクトを与えて欲しいかなんてそうそうクリアにイメージできないですから。特に思いつきの最初の時は。じゃあ、次のステップはどこに置こうか、というスライスが見えて来るタイミングがないと、プロダクトは価値のないものになってしまうと思います。

で、フォーマットはPMJPで @yamotty さんが上げていたものを採用しています。前は仮設キャンバスを使っていたのですが、こっちの方がテキストでガリガリかける感じだったので。ちなみに、PMJPでは特にフォーマットの名前が指定されていなかったのですが、自分の中で呼びづらいのでプロダクトオーバービューと勝手に名付けています。

  • 前提
  • このプロダクトは誰向けか
  • このプロダクトは何を解決するか
  • エレベータピッチ
  • HOW
  • KPI
  • コンテンツ構成
  • マネタイズの方向性

ちなみに、エレベータピッチは私が追加しました。これをベースにビジネスオーナーとの話を繰り返してある程度最低限ストーリーとして成立するフローで1stリリース対象とします。

ユーザストーリーマッピング

どちらかというとカスタマージャーニーマッピングかもしれませんが、一応ユーザストーリーマッピングの書籍の方を見ながらピックアップした方法なので。いわゆる「エピック」とか「ナラティブフロー」のようなレベルで、「それでどう世界が変わるのか」についてストーリーの流れを語ってもらいます。

全員集まって、という大きな場では2回ほど試したのですが、ここで語ってもらう時にサービスの機能として提供しようと思っている範囲の外側についても語ってもらう。具体的には、ユーザはどんな動機を持っていて、サービスを使った後にどうするのか、もストーリーとして語ってもらうことが大事だという結論に落ち着きました。

このタイミングで具体的なUIや機能の分割や遷移についての検討はしませんが、ストーリーとして出ている前後のあるべき姿があることで、後々具体的なUIや機能を検討する時に目的が明確になります。

UX,UI検討

この流れが決まったら、デザイナとともにUX,UIの検討をします。ビジネスオーナーには少し形がまとまったタイミングで逐次レビューという頻度でやりました。

仕様検討

ストーリーを機能で分割して、仕様を検討します。ここまで来ると課題は技術的なものが多くなるので、迷いの質が変わってくるというか、今までに経験した迷いが多くなってきて少しほっとします。

オーバービューからUI検討までをステップバイステップで繰り返す

この流れをステップ(イテレーションでもなんでもいいや、小さな区切りの単位)で、私とビジネスオーナーがプロダクトの方向性について繰り返します。最初は時間がかかりました。プロダクトが最終的にたどり着くべきものに対して「なぜ?」を語るので、時間がかかっても仕方ないかな、とは思っています。次のステップは、もう少し早くなりそう。だんだんと価値の提供が早いサイクルができてくるといいですね。

プロダクトマネージャの作家性について

で、こんなプロセスを手探りしながら、PMJPで投げた質問から始まった「作家性」について少し考えておりました。プロダクトマネージャに作家性が必要だという議論から始まっていたのですが、私の場合、作家性をエンターテインメントと同じに考えていたので、プロダクトのアイデアなどのオリジナリティーを元に考えてあまり腹に落ちていませんでした。

この時の議論と、今回私がやってきたことの中で、なんとなくこういうことかな、と思い始めたのは、

  • 作家性は意思決定の積み重ね(およびその結果)において発揮される
  • その意思決定がどういうフィルターでなされているか、という偏り
  • 別のビジョンから生み出される形が同じものになることはある
  • プロダクトは幾つかの点で模倣しても問題ない

まあ、最後の点に関しては、ProductHuntなどで日々リリースされるプロダクトをいくつも見てきた、というのはあります。例えばToDo管理でも、切り口を変えたアプリがそれこそ毎日リリースされるんですよ。

まあ、今はプロダクトの魅力を一言でキャッチーに表せる言葉が自分で出せるかどうか、がクリエイティビティが発揮できているかどうかの指標なのかなあ、とぼんやり思ってます。