Product Ownership
    NTTデータと楽天それぞれの文脈での
サービスづくり、人づくり、チームづくりの取り組み




  NTTDATA
 2013/1/16     http://www.flickr.com/photos/ranh/270486786/
自己紹介
 柴山 洋徳 (Twitter:shibao800)
 株式会社NTTデータ 認定プロジェクトマネージャ
 仕事
     CCPM/TOC コンサルティング
     組織変革コンサルティング
     NTTデータグループのアジャイル開発組織運営
     社内システム開発のプロダクトオーナー
     社内アジャイルコーチ
Copyright © 2013 NTT DATA CORPORATION
Copyright © 2013 NTT DATA CORPORATION
Agile Professional Center



      オンデマンドな
     Scrum開発体制


                 組織的な

                 開発サポート
      Scrumの

     プロフェッショナル
        育成

                  http://www.flickr.com/photos/zzpza/3269784239
                  http://www.flickr.com/photos/conchur/3358169824/
とある主人公が
        プロダクトオーナーシップで
             仲間を作る物語




 NTTDATA
2013/1/16   http://www.flickr.com/photos/ranh/270486786/
主人公(PO)のプロフィール

名前:菅原 康友
所属:株式会社NTTデータ 技術開発本部
     プロアクティブ・テスティングCOE
経歴:汎用機での方式系開発
   OSS Java FW(web/batch)開発
   テスト自動化支援ソリューション開発

現在、新規テストソリューションの
   プロダクトオーナー
物語の登場人物
POチームメンバ:   長年、主人公と共にテスト自動化
            支援ソリューションを開発。
            過去開発したソリューションの価値に
            不満あり。
   ユーザー: ソリューションに興味を示してくれた
         社内のファーストユーザ。
         良いものは使う、悪いものは使わない。
主人公の上司:
            生粋のプロジェクトマネージャ。
            長年、従来型開発での成功を体験。
            Agile開発に懐疑的。
主人公のつくりたいもの

研究開発ソリューション

全社のテストに関する
  問題を解決
企画開始

従来型の企画手法

  数ヶ月かけて
要求機能一覧まで完成
主人公の悩み
 既存の       ユーザ
                   上司アドバイス
業務フロー    ヒアリング結果




          機能一覧




作成する機能は本当にユーザーが
求めている機能なのか?
主人公の悩み
 既存の       ユーザ
                   上司アドバイス
業務フロー    ヒアリング結果




          機能一覧




作成する機能は本当にユーザーが
求めている機能なのか?
http://www.flickr.com/photos/usnationalarchives/6124109059
Copyright © 2012 NTT DATA CORPORATION




   Agile Professional Centerへようこそ!
Agile Professional Centerの支援




Scrumのプロ(?)が仲間になった
Step0


事前準備
認定スクラムプロダクトオーナー研修




プロダクトオーナーシップの権威
  Jeff Patton研修受講
          こころのなかで


Jeff Pattonが仲間になった
Step1:
POチームメンバーを仲間にしよう!
物語の登場人物
POチームメンバ:   長年、主人公と共にテスト自動化
            支援ソリューションを開発。
            過去開発したソリューションの価値に
            不満あり。
   ユーザー: ソリューションに興味を示してくれた
         社内のファーストユーザ。
         良いものは使う、悪いものは使わない。
主人公の上司:
            生粋のプロジェクトマネージャ。
            長年、従来型開発での成功を体験。
            Agile開発に懐疑的。
Before
主人公は、
 誰のためにどのような機能を提供し、どのような
  メリットをもたらすかを説明できなかった
 その結果として、POチームメンバの協力を得ら
  れていなかった

リーンキャンバスを活用
リーンキャンバス

 プロダクトのアイディアを“一枚の紙で”仮説として
  まとめることができるツール

 軽量かつ必要最低限な要素に絞られているため、
  短時間で作成できる

 関係者全員で簡単にアイディアを共有することがで
  き、また、共同で簡単に修正することができる
                             19
リーンキャンバス




           20
「顧客」「問題」「アイデア」「価値」を中心にリーン
キャンバスの作成をメンバと一緒に繰り返し


 初版           第3版




      第2版           完成!
ユーザーのことをもっと知りたい・・・ので、




 Before
 付箋は主人公の意見のみ。付箋をはれない
 項目もあった…
 After
 顧客や価値に関する主人公の悩みを共有しつつ、
        ユーザーと一緒に作成した ①
 POチームメンバから意見が積極的にでてきた
 当初、POチームメンバーは、POから提示された
  機能一覧ではユーザのためになるものができると
  思えず、半ば諦めぎみ


 POと一緒にリーンキャンバスを作成する中で
  ユーザにとって価値あるものを作るための活動
  に参加していることへの実感を持つように


プロダクトオーナの考えを
チームで共有理解することができた!
POチームメンバーが仲間になった
Step2:
ユーザを仲間にしよう!
物語の登場人物
POチームメンバ:   長年、主人公と共にテスト自動化
            支援ソリューションを開発。
            過去開発したソリューションの価値に
            不満あり。
   ユーザー: ソリューションに興味を示してくれた
         社内のファーストユーザ。
         良いものは使う、悪いものは使わない。
主人公の上司:
            生粋のプロジェクトマネージャ。
            長年、従来型開発での成功を体験。
            Agile開発に懐疑的。
エクスペリエンスマップ

ユーザがソリューションを利用する際
 のExperienceを可視化するツール

ユーザが体験するワークフローに伴う
 感情の起伏も表現する
ユーザーのことを深く知る


     ユーザに現在の仕事で
     苦労しているところや、
     問題を追加してもらった。




     ユーザーと一緒に作成①
ユーザーのことを深く知る



       ユーザが強く共感し
       た付箋に印をつけて
       もらった




     ユーザーと一緒に作成②
 ユーザから積極的に問題を共有してもらえ
  るようになった
            ユーザーが積極的に
           問題をまとめてくれた!

 ソリューションの試行適用を約束してくれた


ユーザーからの信頼が得られた!
ユーザが仲間になった
Step3:
上司を仲間にしよう!
物語の登場人物
POチームメンバ:   長年、主人公と共にテスト自動化
            支援ソリューションを開発。
            過去開発したソリューションの価値に
            不満あり。
   ユーザー: ソリューションに興味を示してくれた
         社内のファーストユーザ。
         良いものは使う、悪いものは使わない。
主人公の上司:
            生粋のプロジェクトマネージャ。
            長年、従来型開発での成功を体験。
            Agile開発に懐疑的。
Before
ソリューションが持つ機能はいえる
どの機能から優先的に提供し、誰にどのよ
うな価値をもたらすべきかを考えていない

           しかも・・・
  機能一覧     ・機能に根拠のある
  があるだけ…    優先順位がない
           ・ソリューションの
            スコープがあいまい
その結果、こんなやり取りも…
 本ソリューションと同じ領域をカバーする
 社内ソリューションXと連携する機能を追加せよ

 本ソリューションと社内ソリューションXには、深い
 連携は必要ありません。
 また、連携機能は開発コストが高く・・・。
 社内ソリューションXは、社内の多くのプロジェク
 トで使われているため、連携機能は必須である。

 はい。わかりました・・・。
ユーザーのことをもっと知りたい・・・ので、

   ユーザー像を明確に
  Before
  機能一覧ではユーザの人物像が
  イメージできていなかった・・・
  After
  ユーザ像が具体的になり、
  優先的に解決すべき問題や
  価値の決定を行えるように

       ユーザーと一緒に作成した ①
ユーザーストーリーマッピング

 Jeff Patton が開発した
  製品の設計
  ユーザーワークフロー
  リリース計画
 全部一発で見える化する手法
誰のために


優          どのような機能で
先
順          どのような価値を
位
           提供するか


    ユーザーの体験するワークフロー
After
ユーザへの価値が明確になり、価値創出に必要な
最小機能セットをリリース計画とした

リリース1
        リリースごとに創出する
リリース2
         価値を明確に記載
リリース3
リリース4
社内ソリューションXとの連携は…


            リリース優先順位
             最後となった

ユーザ像と社内ソリューションXとの関係を明確
にしたことにより、連携機能の開発は必要なく、
運用対処でよいこととなった。
After
ハッキリとしたユーザー像を持ち、どの機能か
ら提供すべきで、その機能によりどのような
価値をもたらすかが説明できるようになった。




プロダクトオーナーとしての方針を共有す
ることができた!
上司が仲間になった
やってみた感想を聞いてみた
機能がユーザーの価値と結びついて、すっきりした
(POチームメンバ)
   作られるものが自分たちの課題を解決
   してくれるものだと期待できる
   (ユーザ)
シーズ指向に陥りがちな研究開発において、
ユーザの価値をとことんまで追求することは、我々
にとって価値がある。期待しています。
(主人公の上司)
    次の企画があれば次もこのやり方で!
    (主人公)
プロダクトオーナーシップ
http://www.flickr.com/photos/tenz1225/6217529904

Product Ownership~NTTデータと楽天それぞれの文脈でのサービスづくり、人づくり、チームづくりの取り組み