1
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?

[読書メモ]アジャイルなプロダクトづくり

Posted at

[読書メモ]アジャイルなプロダクトづくり

書籍の概要

『アジャイルなプロダクトづくり 価値探索型のプロダクト開発のはじめかた』は、市谷聡啓氏による、仮説検証とアジャイル開発の実践を現場のストーリーを通じて学ぶ書籍です。本書は、具体的な事例をもとに、価値あるプロダクトをどのように生み出すか、そのプロセスと考え方を深く掘り下げています。アジャイル開発の基本から、仮説検証の手法、チームビルディング、プロダクトマネジメントの要点まで幅広くカバーしており、実務に直結する知識を提供しています。

読み始めた動機

私は日々の業務でスクラムを取り入れた開発を行っていますが、その中で「本当にこれで良いのか?」という疑問を抱くことがありました。特に、形式的にスクラムのフレームワークを使っていても、チームが形骸化してしまい、本来のアジャイルの価値を提供できていないのではないかと感じていました。

そんな中、『カイゼン・ジャーニー』の著者である市谷氏の新作である本書が発売されたことを知りました。『カイゼン・ジャーニー』は以前に読んでおり、その実践的な内容と現場感あふれるストーリーが大変参考になりました。市谷氏の新たな知見や最新のアジャイル開発の手法を学べると期待し、自分たちの開発プロセスを見直すきっかけになると考え、本書を手に取りました。

重要なポイントや学び

プロダクトづくりの3つの視点

ユーザー視点

プロダクトづくりにおいて、ユーザーの視点は最も重要な要素の一つです。本書では、ユーザーに対する「探索」と「検証」の活動が強調されています。

  • 探索:自分たちの知らないことや理解していないことを明らかにするために、ユーザーインタビューや観察を行います。これにより、ユーザーの潜在的なニーズや課題を発見し、プロダクトの方向性を定める重要なインプットを得ることができます。

  • 検証:自分たちが立てた仮説が正しいかどうかをテストします。プロトタイプやMVP(Minimum Viable Product)を用いてユーザーからフィードバックを収集し、仮説の妥当性を確認します。これにより、リソースを無駄にせず、ユーザーに価値を提供できるプロダクトを開発することが可能になります。

チーム視点

チームが一丸となってプロダクト開発に取り組むためには、共通の方向性と目標を持つことが不可欠です。本書では、チームが方向性を見失わないようにするための手段として「インセプションデッキ」の活用が紹介されています。

インセプションデッキは、プロジェクトの目的、ビジョン、ステークホルダー、成功の定義などを明確にし、チーム全員が共有するためのツールです。これにより、チーム内での認識のズレを防ぎ、一貫したプロダクト開発を推進することができます。

プロダクト視点

プロダクトは、ユーザーとチームをつなぐ架け橋のような存在です。本書では、プロダクトがユーザーに対して価値を適切に届けられているか、そしてその価値提供を継続的に行える状態になっているかを重視しています。

  • プロダクトとしての価値が届いているか:プロダクトの価値がユーザーに正しく伝わり、ユーザーの課題解決に貢献しているかを確認します。これは「PSF(Problem Solution Fit)」の達成度で評価します。

  • 継続的な価値提供の体制が整っているか:プロダクトを持続的に改善・提供し続けるための体制が整っているかを確認します。これは「Four Keys(デプロイ頻度、リードタイム、変更失敗率、サービス復旧時間)」といった指標を用いて測定します。

仮説立案

仮説立案における3つの罠

プロダクト開発で仮説を立てる際には、次の3つの罠に陥りがちであることが指摘されています。

  1. 答えありきで、いきなり作り始めてしまう(「前提が問えていない」の罠)
    自分たちの思い込みや経験に基づいて、「これがユーザーの求めているものだ」と決めつけ、検証せずに開発を進めてしまうこと。

  2. 想定する顧客やユーザーの声を、そのまま答えととらえてしまう(「顧客が正解」の罠)
    ユーザーからのフィードバックをそのまま受け取り、深掘りせずに実装してしまうこと。

  3. モノが出来たら、いきなり本格展開を始めてしまう(「完成=本番」の罠)
    十分な検証やフィードバックの収集を行わずにリリースし、後から大きな修正が必要になるリスクを抱えること。

仮説キャンバス

仮説キャンバスは、自分たちが何を分かっていないのか、何を検証すべきなのかを明確にするためのツールです。このキャンバスを用いることで、仮説とそれを裏付けるための検証項目を整理し、チーム全体で共有することができます。重要なのは、「自分たちが何を知らないか」を知ることに重点を置き、未知の領域を体系的に探求する姿勢です。

MKV(Most Knowledgeable Version)

一般的に使われるMVP(Minimum Viable Product)は、検証や学習のための最小限の実行可能なプロダクトを指します。しかし、本書ではMKV(Most Knowledgeable Version)という概念が紹介されています。MKVは、価値提供のために最大限学習結果を踏まえたプロダクトを意味します。

MVPの段階では、検証に重心を置くため、プロダクトの作りがラフになりやすく、技術的負債が蓄積することがあります。MKVでは、これまでの学習や検証結果を最大限に活用し、プロダクトのあるべき姿を再定義します。事業化に重心を移す段階で、プロダクトの品質やスケーラビリティを高め、ユーザーに継続的な価値を提供できるようにします。

Fitに基づくステージゲート

プロダクト開発の進捗を評価し、次のステージに進むべきかを判断するために、フィットに基づくステージゲートの考え方が紹介されています。具体的には、以下の3つのゲートがあります。

  1. CPF(Customer Problem Fit)ゲート

    • Objectives:アーリーアダプターの特定ができていること
    • Key Results:インタビュー検証を一定数実施し、その80%が課題仮説を肯定すること
      顧客の課題が明確になり、解決すべき問題が特定されていることを確認します。
  2. PSF(Problem Solution Fit)ゲート

    • Objectives:ソリューションへの好反応が得られていること
    • Key Results:プロトタイプ・MVP検証を10名以上実施し、その80%がソリューションを肯定すること
      提案する解決策が顧客の課題解決に有効であるかを検証します。
  3. PMF(Product Market Fit)ゲート

    • Objectives:アーリーアダプターおよびマジョリティに届くチャネルが確保できていること
    • Key Results:チャネル仮説の検証を終え、想定する事業規模を達成するロジックが成立していること
      市場での需要とプロダクトの提供価値が一致し、スケール可能な状態であることを確認します。

まとめ

本書を読んで、アジャイル開発の真髄は「仮説と検証のサイクルを高速で回すこと」にあると強く感じました。ユーザー視点での探索と検証、チーム内での方向性の共有、そしてプロダクトを通じた価値提供の継続。この一連の流れを円滑に進めるための具体的な手法やフレームワークが豊富に紹介されており、大変参考になりました。

また、仮説立案の際に陥りがちな3つの罠についての指摘は、自分たちの過去の失敗を振り返る良い機会となりました。今後は、これらの罠を回避し、仮説キャンバスを活用してチーム全体で未知の領域に挑戦していきたいと考えています。

1
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
1
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?