[PdM/PO] プロダクトの構想フェイズについて(4層の仮説立案→リーンキャンバス→インセプションデッキ→ストーリーマッピング→プロダクトバックログ化)

  • アジャイル開発における、プロダクト像の構想〜タスク化までについての個人的まとめ
  • PO(プロダクトオーナー)PdM(プロダクトマネージャー)は以下の流れで、何を作るか?をまとめていく必要がある
  1. プロダクト像の仮説を立案
    • 抽象度で4層程度に分解して考える
  2. リーンキャンバスを作成
  3. インセプションデッキを作成
    • ex. エレベーターピッチ/やらないことリスト
  4. ユーザーストーリーマッピング
  5. 重み付け(各ストーリーにSMLを定める)
  6. 優先度付け(MoSCoW法や狩野モデルを活用する)
  7. 優先順位付け→プロダクトバックログ
  8. 受入条件の設定
  9. プロダクトバックログアイテムに分割
    • ここでタスク単位になる
  10. DoD(完了の定義)の設定
    • 各アイテムにはDoDが必須
  11. スプリントプランニング~スプリント開始
    • バックログの中からスプリントないで取り組む物を決定する
    • ここで開発が始まる

概要/用語

PO/PdM

  • アジャイル開発においては、以下のロールがプロダクトについての責任を持つ
  1. プロダクトオーナー(PO)

    • プロダクトに関する全ての責任と権限を持つ
    • プロダクトビジョンを確立し、育み、伝達する
    • プロダクトバックログの管理・優先順位に責任を持つ
    • ROIの最大化に責任を持つ
  2. プロダクトマネージャー(PdM)

    • 人によって認識が異なるが、POとスクラムマスターの機能性を合わせた存在と定義されていることが多い
    • スクラム開発においてはPOとスクラムマスターに分解されており、PdMは存在しない。兼任すべきでないと言われている

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

  • ユーザストーリー

    • システムやSWのユーザーにとって価値のある機能を記述したもの
    • ある特定の役割の持ったユーザーから要望された結果を記述し、そのプロセスで何を行いたいのか?その効果(実現価値)も表現する
    • 書式
      1
      「<役割>として<機能>ができる (それは<理由>のためだ)」
  • ユーザーストーリーマッピング

    • ストーリー(ユーザーにとっての価値)を付箋などに書き出し、ユーザーの体験順に時系列で左右に整理、似た機能は上下(基本機能を上、派生的な機能は下)に整理して壁などにマッピングしていく手法
    • 通常ワーク形式で実施する
      • 複数名で3h程度で実施する場を設ける

プロダクトバックログ

  • プロダクトバックログとは?

    • ロードマップと要件に基づいて開発チームが行う作業に優先順位を設定したリスト
      • 機能開発以外の作業も含まれる
      • バックログへの項目の追加&変更は誰でもいつでも可能
      • POが項目の優先順位付とリストの管理の責任と権限を持つ
      • プロダクトバックログはスクラムチームに限らず、誰でも(ex. ビジネスチーム)参照できる
    • ストーリーを元に作られる
      • 最低限の分解や重み付け、優先順位の定義を経てプロダクトバックログになる
    • バックログ=タスクではない
  • プロダクトバックログアイテム

    • プロダクトバックログを分解してタスク単位にしたもの

リーンキャンバス

リーンキャンバス

  • リーンキャンバス
    1
    リーンスタートアップという著書で有名な起業家のエリック・リースから応用されたビジネスモデルを一枚の図にまとめたフレームワーク
    • ユーザーストーリーマッピングの前に、プロダクト像の意識合わせに利用する
    • 目的
      • アイディアに対してビジネス視点からも検討できるようユーザーとビジネスのバランスを考えること
      • ユーザー視点で事業の価値を定義し、価値の構造を可視化することで実現性を検証することが可能になります。

インセプションデッキ

インセプションデッキテンプレート

  • インセプションデッキ

    • プロジェクトの全体像(目的、背景、優先順位、方向性等)を端的に伝えるためのドキュメント
    • 質問 x 10で構成されている
    • プロジェクト憲章に近い存在でPJ計画書のインプットにもなる
    • 考案者: Robin Gibson (ThoughtWorks社)
    • アジャイルサムライの著者(Jonathan Rasmusson氏)によって広まった
    • プロジェクト計画書ができる時点で盛り込まれていればいいので、初めから全て必須ではない
      • プロダクト像を揃える為の最低限として、エレベーターピッチや、トレードオフスライダーやらないことリストを作っておくと良い
  • エレベータピッチ

    • 以下の書式で[]の中身を書き換えていき、プロダクトを表現する
      エレベーターピッチ
    • リーンキャンバスと同様に、ユーザーストーリーマッピングの前に、プロダクト像の意識合わせに利用する
  • やらないことリスト

    • その名の通り

やらないことリスト


プロダクト像の仮説立案〜タスク化までの流れ

  • ストーリーマッピングの前にプロダクト像を合わせる
  • 1~はワーク内で実施することが多い
  1. 仮説立案
    • プロダクト像を抽象度に応じて階層分けして定義する
  2. リーンキャンパス
  3. インセプションデッキ
  4. ストーリーマッピング
    • ストーリー出し/分類/分割
  5. 重み付け(SMLを話し合う)
  6. 優先度づけ
  7. 優先順位付け
  8. 受入条件設定
  9. バックログアイテムに分割
  10. DoD(完了の定義)の設定

プロダクト像の仮説立案

  • プロダクトのあるべき姿はステークホルダー間で認識齟齬が生まれ易いため、以下のような抽象度で階層分けした仮説を共有することで、アジャイルPJを円滑に進めることができる

抽象度で階層分けしたプロダクト像の仮説

  • 上段が下段のインプットとなる
  • 下段に行くほど抽象度が下がり具体化される
  • Whatばかり話し合っていて、上段のCoreやWhyがずれていることが多い
  • この仮説はアジャイル開発を進めながら何度も見直してブラッシュアップしていく物なので、最初に完璧にする必要はない
    • ステークホルダーでビジョンを共有する

リーンキャンパス

  • 以下の9つの項目を埋め、ステークホルダーと共有する
    • 特にビジネスチームや予算承認者との合意が重要

リーンキャンバス

インセプションデッキ(エレベーターピッチ/やらないことリスト/トレードオフスライダー)

インセプションデッキテンプレート

  • インセプションデッキのテンプレートは以下のURLから入手可能

    • https://cacoo.com/diagrams/nsgCdwRZAHJBXTLy/F96B8
    • インセプションデッキはアジャイル開発におけるPJ憲章やPJ計画書に相当する
    • ストーリーマッピングに入る前に、エレベーターピッチとやらないことリストを作っておくと円滑に進め易い
  • エレベーターピッチ

    • 以下の[]の箇所を埋めて、ステークホルダー間の認識を合わせる
    • [差別化の決定的な特徴]の認識が承認者やビジネスチームとずれていると後で揉めかねない
1
2
3
4
5
6
7
[潜在的なニーズを満たしたり、潜在的な課題を解決したり]したい
[対象顧客]向けの、
[プロダクト名]というプロダクトは、
[プロダクトのカテゴリー]です。
これは、[重要な利点、対価に見合う説得力のある理由]ができ、
[代替え手段の最右翼]とは違って、
[差別化の決定的な特徴]が備わっている
  • やらないことリスト
    • 進める前にやらないことを明確に定めることで、承認者やビジネスチームとの齟齬が生まれにくい

やらないことリスト

  • プロジェクトコミュニティ

    • ステークホルダー全員を明文化
  • トレードオフスライダー(何を諦めるか?)

    • 何を優先するか?メンバとスタンスを揃えられる

トレードオフスライダー

  • その他アクターの認識合わせも実施しておくと良い

ここまででプロダクトの大枠の認識を合わせることで、ストーリーマッピングを円滑に実施可能になる。経験上、ストーリーマッピングは結構な時間がかかるので、こういった前提条件の設定は効果が高い。

ストーリーマッピング

  • マッピングはメンバ間の齟齬を回避するためにワーク形式で行う
  • 難しければ、少なくともPOがマッピングしたものに過不足がないかコメントをもらう

ワークについて

  • 所用時間:3h程度
  • 参加者
    • できうる限り多くのステークホルダーを集めた方が良い
  • ワークの流れ
    • マッピングの前にメンバ間のプロダクト像を整合する
      • ここで、リーンキャンバスやエレベータピッチ、抽象度分けされた仮説を用いる
    • ストーリーマッピング(全部ワーク内でやらなくてもOK)
      • ストーリーを付箋に書き出す
      • 時間軸で物語順に並べる
        • ex. ログイン→認証→…
      • フィチャーとして分類/分割
        • 共通するワードをフィーチャーとして上に付箋を貼る
        • その下に細かいストーリーを並べる
        • 大きすぎるストーリーは分割する
  • 開催形式
    • Localで集まれる場合
      • 複数名でホワイトボードに付箋を貼っていく
    • Remoteで実施する場合
      • Mural, Realtime Boardなどでホワイトボードを代用する
      • BOXなどの同時編集可能な環境があれば、そこのファイルにマッピングする

INVEST

  • ユーザーストーリーはINVEST要素を保持していることが望ましいと言われている
  • INVEST
    • Independent(独立している)
      • 可能な限り他のユーザーストーリーに依存しない
      • 実装、見積もり、テストが容易
    • Negociatiable 交渉可能
    • Valuable 価値がある
    • Estimatable 見積もり可能
    • Small 小さい/適切な大きさ:一つの反復に収まるサイズ
    • Testable:テスト可能
      • ストーリーが完了したかを示すことができる

エピック

  • エピック
    • まだ明確に表現できないものや緊急度の低いもの、NicetoHaveな事柄は大きな塊(エピック)としておいておく
    • 必要に応じてユーザストーリーとして詳細化する
    • 複雑で1つの反復で完了することはできない
    • リリース開始までに1回の反復で完了できる大きさに分割する必要がある

ストーリーの分割

  • 見積もったストーリーがアジャイル開発の一反復に治らない場合にはストーリーの分割を行う。タスクへの分割とは別

分割のガイドライン

  1. データ境界に沿って分割
  2. 操作の境界で分割
  3. 横断的な関心ごとを分離する
  4. パフォーマンス制約をストーリーにする
  5. 優先度に沿ってストーリーを分割する
  6. ストーリーをタスクに分割してはならない

ストーリーとフィーチャーの書き出しが終わったら過不足について議論を行う。その後、各ストーリーの重み付けと優先度付けを実施する。

重みづけ

  • 重み付け
    • 優先順位付の前にSMLで重みづけを行う
      • 重み(ストーリーを達成するまでのコスト)&優先度(ストーリーが産む価値)を先に定めてから順位づけをしないと混乱が生じてしまう
    • Small, Middle, Largeをメンバ間で話し合う

優先度付け

優先度と優先順位は別物

  • 優先度づけ→優先順位付け
    • 優先度
      • 高中低、ABCなど
    • 優先順位
      • 明確な序列
    • 優先順位がつくとバックログになる

優先度付けには様々な手法がある

  • MoSCoW法(各ストーリーに以下のタグを定めていく)
    • Mo: Must Have
      • 絶対必要
      • MVPに必要なフィーチャーはここに含まれる
    • S: Should Have
      • できれば実装すべき
    • Co: Could Have
      • 他への影響がなければ実装できるとよい
    • W: Won’t Have
      • 今回は実装しないが将来に実装するかも

重み付のSMLと頭文字が被って混乱を招くことがあるので注意

  • 可能であればMVPを定義しておくと優先的な機能を可視化しやすい
    • MVP (Minimum Viable Productivity)
      • 実用最低限の製品のこと
      • 使い勝手はともかく最低限の価値を生み出せる状態
    • MVPに含まれる機能は、自ずとMust Haveになる

その他、狩野モデルも有名

  • 狩野モデル(利用者の好みでタグ付)
    • 魅力的(あると魅力的)
    • 一元的(なくても良いがあると差別化できる)
    • 当たり前(あって当たり前)
    • 無関心(どうでもよい)
    • 逆行(あったら困る)

プロダクトバックログの定義(優先順位付け)

  • 先に各ストーリーに設定した重みや優先度を参考に、優先順位をつける

  • ストーリーを優先順位で上から並べる

  • Walking Skelton

    • 実装が短期間で終わる場合は注意深く優先順位付けしなくて良い
  • 判断基準

    • ビジネス価値
      • ex. 同等のビジネス価値を提供可能な場合、開発工数の少ないほうがROIが高いため、つけられる優先順位も高くなる
    • 技術的なリスク
      • 技術的なリスクが高い項目ほど早いスプリントで対処して、リスクを減らすべきである
      • ただ、新設チームの場合は始めにもってこな方が良いケースもある
    • 市場リスク
      • 早く市場に出してフィードバックを得る必要がある物を優先する
      • 他社に先出しされると致命的になる機能など
  • 例えば、MoSCoW法であれば、Must Haveの項目から先に取組み、MVPを完成させる必要がある。

    • 必須の機能が実装されることで、技術的なリスクが序盤で下がり、少なくともプロダクトが動く状態になる
    • その後にビジネス価値に基づいてShouldの項目を片付けていくイメージ
  • ここまでのアウトプット

    • プロダクトバックログ
      • 優先度付されたフィーチャー/ストーリーのリスト

プロダクトバックログを起点として、スプリント計画や詳細なタスクへの落とし込みを行っていく


プラダクトバックログアイテムの定義

  • プロダクトバックログを細分化するとタスクになる
    • プロダクトバックログアイテム(項目)=タスク
    • これらのアイテムにはDoD(完了の定義)を定める必要がある
    • バックログごとに表を作るイメージ
      • カラムはバックログ、バックログアイテム、各アイテムのDoD(完了の定義)

完了の定義:DoD(Difention of Done)を追加

  • DoD(Difention of Done):完了の定義

    • アウトプット
      • ex. 関連する設計ドキュメントがある
    • 状態
      ex. 2名以上がレビュー、テスト実行済み
  • DoDを定めなければ進捗の実態の測定や品質管理が難しくなる

ここまでで、プロダクト像の定義〜タスク化が完了


2レベルプランニング

アジャイル開発は適当に進めていいわけではなく、2段階で計画を立てて、順次見直しながら進めていく

  • リリース計画
    • ユーザにコミットするリリースの時期
  • スプリント計画
    • 対象スプリント期間内に行うべきことの計画

リリース計画の立案

まずは全体の進め方を検討する

  1. SPの長さを決める
    • スクラム開発なら2w程度
    • 通常のアジャイル開発では4~8w程度
  2. ユーザーストーリー。エピックの規模を見積もる
    エピックは見積もり可能な大きさに分割する
  3. ユーザーストーリー、エピックに優先順位をつける
  4. 1反復で消化できるポイントなど(ベロシティ)を見積もる(例:一反復=15ポイント)
    • 立ち上げ段階の予測はとても難しいので厳し目に見積もる
    • 一度スプリントを回せば、前回はこの程度消化できたので…という測量が可能になり精度が上がっていく。段々精度が上がっていくものという認識でOK
  5. 反復にユーザーストーリー、エピックを配置する
    • スプリントの期間と、ベロシティが定まった箱の中にどのストーリーを詰めていくか?考えるイメージ
  • プロダクトオーナーは、ROIを最大化するにはどうすべきか?を常に考えて、責任を持つ必要がある

価値とシステムにおけるリスクの二軸のマトリクスで分類する

スプリントプランニング

次にスプリントごとの計画をする

  • バックログの中から次のスプリントで取り組む物を選択する

    • ここでやっと開発を始めることができる
    • 以降のスプリントサイクルについては別記事に記載
  • 2部構成で実施する

    • パート1
      • 開発チームはPOと一緒に次のスプリントでどのような機能を実装するか
      • SPで対象とするバックログの選定
      • ストーリーの確認
    • パート2
      • 開発チームがその機能をどのようにプロダクトに追加するかを決定する
        • ストーリーの作成
  • スプリントバックログ

    • タスクボード To Do/Doing/Done を使う
      • ここでGitのカンバンなどを用いる
    • ここでの単位はプロダクトバックログアイテム(タスク)
  • 三角測量 プランニングポーカー

    • 見積もるための基準となるストーリーやタスクを1つ決める、
      比較しながら見積もっていく手法
    • 相対的見積もり
    • 異なる数字を出した場合は、最も大きい数字を出した人と、小さい数字を出した人で根拠を説明しあう

参考

関連記事

その他

@EventEmitter @Input @Output @ViewChild ACM AMP API Gateway AR AR.js AR.js Studio AWS AWS Amplify AWS Budgets AWS Cost Explorer AWS SDK for JavaScript AddThis Adobe XD Alexa Amazon CloudWatch Amazon Honycode Amazon SNS Android Angular Angular Material AngularFire AppSync Augury C CDN CI/CD Cloud Craft Cloud9 CloudFormation CloudFront CloudTrail Cognito Cost Anomaly Detection Cubase ai Cubasis LE DTM Disqus DynamoDB Elgato HD 60S Firebase Firebase Hosting Former2 Github Github Actions Github.com GithubEnterprise GithubPages Google Chrome Google Cloud Shell GraphQL Hexo Hosting IAM Ionic JSON JavaScript LadioCast Logging LowCode MFA MS Authentication MacBook Pro 16 Mind Node NETDUETTO Netflix Party Netlify Network NoCode Observable PO PdM Promise RPA ReactiveForm Recognition Route53 S3 SAM(Serverless Application Model) SAR SSL SYNCROOM Schematics ScrumInc Serverless Service Siri Sitemap Spark AR Steinberg UR44C Teams Touch Cast Studio Treetable TypeScript UI UI Bakery WAF WAFv2 WEB Page Dev WEB会議 WebAR WebSocketAPI Webhook Windows Power Automate Wireshark aot async/await aws config cloud9 display.land draw.io e2e test filter() forkJoin() google search console hexo-generator-amp iOS iPad Pro iPhone icarus map() mat input mat tree mat-checkbox mat-input mat-selection-list mmhmm ngFor plantUML popIn Aladdin2 then() vscode ”global is not defined” らくがきAR アジャイル アジャイル開発 クロスプラットフォーム ショートカット スクラム スクラム開発 テレワーク ファイル操作 ブラウザ型IDE プロダクトオーナー プロダクトマネージャー プロトタイピング リモートセッション 共同開発 双方向データバインディング 待ち合わせ処理 認定スクラムマスター 静的WEB Hosting 静的WEBサイトHosting
Your browser is out-of-date!

Update your browser to view this website correctly. Update my browser now

×