Product...

http://www.flickr.com/photos/ranh/270486786/

Product Ownership NTTデータと楽天それぞれの文脈での

サービスづくり、人づくり、チームづくりの取り組み

NTTDATA 2013/1/16

自己紹介柴山洋徳（Twitter:shibao800）

株式会社NTTデータ認定プロジェクトマネージャ

仕事

CCPM/TOC コンサルティング

組織変革コンサルティング

NTTデータグループのアジャイル開発組織運営

社内システム開発のプロダクトオーナー

社内アジャイルコーチ Copyright © 2013 NTT DATA CORPORATION

Agile Professional Center

Scrumの

プロフェッショナル

育成

組織的な

開発サポート

オンデマンドな

Scrum開発体制

http://www.flickr.com/photos/conchur/3358169824/ http://www.flickr.com/photos/zzpza/3269784239


とある主人公がプロダクトオーナーシップで

仲間を作る物語

NTTDATA 2013/1/16

主人公（PO）のプロフィール

名前：菅原康友

所属：株式会社NTTデータ技術開発本部プロアクティブ・テスティングCOE

経歴：汎用機での方式系開発 OSS Java FW(web/batch)開発テスト自動化支援ソリューション開発

現在、新規テストソリューションのプロダクトオーナー

物語の登場人物 POチームメンバ：

ユーザー：

主人公の上司：

長年、主人公と共にテスト自動化支援ソリューションを開発。過去開発したソリューションの価値に不満あり。

ソリューションに興味を示してくれた社内のファーストユーザ。良いものは使う、悪いものは使わない。

生粋のプロジェクトマネージャ。長年、従来型開発での成功を体験。 Agile開発に懐疑的。

研究開発ソリューション

主人公のつくりたいもの

全社のテストに関する問題を解決

従来型の企画手法

企画開始

数ヶ月かけて要求機能一覧まで完成

作成する機能は本当にユーザーが求めている機能なのか？

既存の業務フロー

ユーザヒアリング結果

上司アドバイス

機能一覧

主人公の悩み

既存の業務フロー

ユーザヒアリング結果

上司アドバイス

機能一覧

主人公の悩み

作成する機能は本当にユーザーが求めている機能なのか？

Agile Professional Centerへようこそ！

http://www.flickr.com/photos/usnationalarchives/6124109059 Copyright © 2012 NTT DATA CORPORATION

Agile Professional Centerの支援

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

冒険の準備 Step0

事前準備

プロダクトオーナーシップの権威 Jeff Patton研修受講

Jeff Pattonが仲間になった

こころのなかで

認定スクラムプロダクトオーナー研修

Step1: POチームメンバーを仲間にしよう！


ユーザー：





Before 主人公は、誰のためにどのような機能を提供し、どのようなメリットをもたらすかを説明できなかった

その結果として、POチームメンバの協力を得られていなかった

リーンキャンバスを活用

19

リーンキャンバス

プロダクトのアイディアを“一枚の紙で”仮説として

まとめることができるツール

軽量かつ必要最低限な要素に絞られているため、

短時間で作成できる

関係者全員で簡単にアイディアを共有することがで

き、また、共同で簡単に修正することができる

20

リーンキャンバス

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

初版第３版

第２版完成！

ユーザーと一緒に作成した ①

ユーザーのことをもっと知りたい・・・ので、

Before 付箋は主人公の意見のみ。付箋をはれない項目もあった… After 顧客や価値に関する主人公の悩みを共有しつつ、 POチームメンバから意見が積極的にでてきた

プロダクトオーナの考えをチームで共有理解することができた！

当初、POチームメンバーは、POから提示された機能一覧ではユーザのためになるものができると思えず、半ば諦めぎみ

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

POチームメンバーが仲間になった

Step2: ユーザを仲間にしよう！


ユーザー：





エクスペリエンスマップ

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

ユーザが体験するワークフローに伴う感情の起伏も表現する

ユーザーと一緒に作成①

ユーザーのことを深く知る

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

ユーザーのことを深く知る

ユーザーと一緒に作成②

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

http://www.flickr.com/photos/flissphil/52158537/

ユーザーからの信頼が得られた！

ユーザから積極的に問題を共有してもらえるようになった

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

ユーザーが積極的に問題をまとめてくれた！

ユーザが仲間になった

Step3: 上司を仲間にしよう！


ユーザー：





ソリューションが持つ機能はいえるどの機能から優先的に提供し、誰にどのような価値をもたらすべきかを考えていない

Before

・機能に根拠のある優先順位がない・ソリューションのスコープがあいまい

機能一覧があるだけ…

しかも・・・

その結果、こんなやり取りも…

はい。わかりました・・・。

社内ソリューションXは、社内の多くのプロジェクトで使われているため、連携機能は必須である。

本ソリューションと社内ソリューションXには、深い連携は必要ありません。また、連携機能は開発コストが高く・・・。

本ソリューションと同じ領域をカバーする社内ソリューションXと連携する機能を追加せよ

ユーザーと一緒に作成した ①

ユーザーのことをもっと知りたい・・・ので、

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

ユーザー像を明確に


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

Jeff Patton が開発した

製品の設計ユーザーワークフローリリース計画

全部一発で見える化する手法

優先順位

誰のために

どのような機能で

どのような価値を

提供するか

ユーザーの体験するワークフロー

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

リリース２

リリース４

リリース３

リリース１リリースごとに創出する価値を明確に記載

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

社内ソリューションXとの連携は…

ユーザ像と社内ソリューションXとの関係を明確にしたことにより、連携機能の開発は必要なく、運用対処でよいこととなった。

http://www.flickr.com/photos/flissphil/52158537/

プロダクトオーナーとしての方針を共有することができた！

ハッキリとしたユーザー像を持ち、どの機能から提供すべきで、その機能によりどのような価値をもたらすかが説明できるようになった。

After

上司が仲間になった

次の企画があれば次もこのやり方で！（主人公）

やってみた感想を聞いてみた機能がユーザーの価値と結びついて、すっきりした（POチームメンバ）

作られるものが自分たちの課題を解決してくれるものだと期待できる（ユーザ）

シーズ指向に陥りがちな研究開発において、ユーザの価値をとことんまで追求することは、我々にとって価値がある。期待しています。（主人公の上司）

プロダクトオーナーシップ http://www.flickr.com/photos/tenz1225/6217529904

Product...

Documents

Transcript of Product...