プロフェッショナルプロダクトオーナー プロダクトを効果的にマネジメントする方法

花井宏行 高江洲睦 水野正隆 斎藤紀彦 木村卓央

• 丸善出版 (2024年7月16日発売)

作品紹介・あらすじ

プロダクトオーナーシップとは、仕組みにとどまらない。説明責任を執りながら、あなたのするすべてのことから生まれる価値に集中することである。本書では、スクラムにおけるプロダクトオーナーシップの第一人者である2人が、あなたのプロダクトライフサイクルを通じて価値を発見、測定、最大化する方法を示してくれる。

「アウトサイドイン（外側から内側）」成功を定義し、外からの測定値を開発の指針とする
プロダクトオーナーの役割にエンパワーメントと起業家精神を持ちこみ、共有されたビジネスモデルの元で全員の足並みをそろえる
スクラムにおけるプロダクトオーナーの役割、作成物、イベントを効果的に適用する
プロダクトバックログをし定着させ、管理。リアルタイムな仕様を使う
透明性を高め、技術的負債を減らし、読者の（スクラムではなく）プロダクトをスケールさせる
スクラムで読者のプロダクトチームに自律性、熟達、目的を注入する

感想・レビュー・書評

[trshimaさんの感想 · 2025年1月6日]

プロダクトオーナーのことかだと思ったら、サブタイトルにある通りでプロダクトマネジメントにも言及した内容になっていた。スクラムにおけるプロダクトオーナーの役割だけでなくプロダクトマネジメントてしてのスクラムについて書くこともされていた。
他のアジャイル本を読んだ後に読むと、書かれてあることが理解しやすかったのと、やっぱり、アジャイルの失敗はアジャイルを教科書通りに実践できてないことが発端なのかとなと感じた。

プロダクトオーナーとスクラムにりついて理解を深めつつ、プロダクトマネジメントについても学べる良書でした。
プロダクトマネジメントについては、この本を入門書として読むのをおすすめしたい。

[fraserlibさんの感想 · 2024年11月1日]

請求記号　007.61/Ma 15

[japapizzaさんの感想 · 2024年9月29日]

Zingerman'sでは、効果的なビジョンは次のようなものであるべきだとされています。
・動機付ける:ビジョンの実現に協力する誰もが、感動を覚える
・戦略的に思える: 実現する可能性が十分にある
・文書化されている: ビジョンを実現させるために、文書化されている
・伝わっている: 文書化されているだけでなく、伝える必要がある


　スクラムは自らをプロセスと呼ぶことを慎重に避けています。なぜでしょうか。
　裁判では、スクラムはプロセスではないという主張はおそらく負けるでしょう。スクラムは、順序付けられたイベント、役割、作成物があり、まるでプロセスのようです。
　ここでポイントとなる要素はオーナーシップです。このプロセスを本当に「自分のもの」とすべきなのは誰でしょうか? 経営陣? 組織のプロジェクトマネジメントオフィス (PMO)? 本やガイド? シュエイバーとサザーランド?
　もちろん、違います。ここまでくれば、答えはわかりますよね。スクラムチームがプロセスを自分のものにする必要があります。チームやプロダクト、企業は それぞれ異なるので、独自のニーズを支援するためにそれぞれに合ったプロセスが現れてくるはずです。とはいえ、足場となる何かから始められれば、チームにとって助けになるでしょう。それは、最小限のルール、つまりフレームワークです。
　家を借りるのと所有するのとで考えてみましょう。家を借りていて何か問題が起きたらどうしますか? 家主に電話をして文句を言いますよね。いつも物が壊れると文句を言い、もっと家主から支援があって然るべきだと訴えるでしょう。あなたは被害者意識を持つのです。
　しかし、家を所有していて何か問題が起きたらどうしますか? どうしようもないですよね。文句を言わずに自分で問題を解決する必要があります。リターン (価値)と投資(コストと時間)に基づき決断します。自分で解決することもあれば 、専門家に依頼することもあるでしょう。場合によっては、そのまま耐えることもあります。最終的には、自分の責任で実行可能な解決方法を見つけるということです。
　プロセスでも同じことが起きます。チームの外で定義され導入されたプロセスを頭ごなしに「押し付け」られたなら、何か問題が起きたときにチームは経営陣やPMOに連絡するでしょう。彼らはプロセスのせいにし、同僚とランチを食べ ながら文句を言ったり、ネット上に怒りの投稿をしたりします。責任追及ばかりになってしまうのです。
　スクラムが出発点、つまり、変更と改善の機会が組み込まれた真のフレーム ワークだとわかったとき、チームはオーナーシップを持ちます。物事が上手くいかなかったとしても、自分たち以外に責任を追及することはできません。これは、説明責任と自己組織化にとって不可欠な要素です。
　前章で説明したように、複雑さは創発的なプラクティスを必要とします。柔軟な (経験的な)プロセスに対するチームのオーナーシップが鍵なのです。
　組織が気をつけなければ、スクラムは借り物のプロセスだと見なされかねません。


　ユースケースとユーザーストーリーの違いは何かとよく聞かれ る。僕の考えでは、ユーザーストーリーはユースケースの中にあ る流れの一つを記述するものだ。ユースケースには通常、ハッピーパスと、いくつかの代替パス、エラーパス、例外パスが含まれる。基本的な仮説を検証するために、たいてい僕はハッピーパスをまず実装して価値を確かめる。最初の完全なシナリオを実装し、正しい方向に進ん でいるというフィードバックを受けたら、次に他のパスを実装できるんだ。


　大事なことなので繰り返しますが、1スプリントごとに価値があり品質を満た すインクリメントを完了させることへの集中が、スクラムチームとビジネス全体 のアジリティを高めるのに不可欠です。どのスプリントも、ステークホルダー視点で「完成」したインクリメントで終わります。


「完成」に関する以下を検討しましょう。
・ユニットテスト済
・コードレビュー済
・コードスタイルガイド適合済
・顕在欠陥がない
・開発のメインブランチにチェックイン済
・公開 API ドキュメントがある
・受け入れテスト合格済
・プロダクトオーナー確認済
・回帰テスト合格済
・リリースノートがある
・パフォーマンステスト合格済
・ユーザーガイド更新済
・サポートガイド更新済
・セキュリティテスト合格済


「完成」の定義の例
「完成」が何を意味するかは、チームによって大きく異なるでしょう。以下は、 高名なトレーナー仲間による「完成」の定義の例です。

・バリー・オーフレイム(Barry Overeem)
-設計されている
-ドキュメントが更新されている
-テストが実施されている
- プロダクトオーナーにより受け入れられている
- スプリントレビューでの「デモ手順」 が明確化されている

・フランソワ・デ・ロジェ (François Des Rosiers)
- コードレビューが完了している
- ユニットテストが完了している
-受け入れ基準に基づく BDD テストが完了している
-(顧客に必須かつ重要だとみなされた文書に基づいて) 文書化が完了している
- PO またはビジネスアナリストによるフィーチャーのテストと受け れが完了している
- ステージング環境にフィーチャーのデプロイが完了している
- フィーチャーのソースコードが適切なブランチにある

・ジェロニモ・パラシオス (Jerónimo Palacios)
- 機能する
- 受け入れ基準を満たしている
- 本番環境に出ている
- ピアレビューされている
- テストによってカバーされている
- すべてのテストに合格している
-マスターブランチにマージされている
-明らかなバグがない
- POに受け入れられている
- APIが文書化されている
- 意味のないコメントが残っていない
- バイナリ変数が文章化されている

・フレドリック・ウェント (Fredrik Wendt)
-すべてがバージョン管理されている
-コードがレビューされている
- 自動テストがセットアップされている
-チーム全体に解決策が共有されている
- 実稼働中

ピンセント・テンス (Vincent Tence)
- すべての自動テストに合格している
- アプリケーションが想定負荷をサポートしている
- 応答時間が許容範囲内にある
- 手動テストが完結している
- 探索的テストが完結している
-開発チームがテストカバレッジに満足している
-アプリケーションがフランス語と英語に翻訳されている
-アプリケーションはすべての対応デバイスでアクセスし利用できる
- リリースノートが最新化され、公開する準備が整っている
- 直近のフィーチャーについてオンラインヘルプが最新化されている
- 効率的かつタイムリーに運用診断が実施できる
- 運用チームはアプリケーションを運用し保守できると自信を持っている
- 改訂履歴が活用できるようになっている
- 開発チームは新しい開発環境を自動的に構築できる
- 新たな重要な学びや設計上の決定が文書化されている
- 開発チームは新しいユーザー体験に満足している
-コードペースが以前よりよい状態にある
- 開発チームは新しいコードの品質に満足している
- 運用チームはすべてのデータを保持したまま前バージョンにロールバックできる
-アプリケーションが準本番環境で利用できる
- 新しいセキュリティ脆弱性が検出されていない
- 開発チームは特定のデプロイを再現できる

・ラルフ・ジョカム
-開発標準に準拠している
-コード解析に合格している
- 文章化されている(シナリオ、SAD、テストケース、インターフェース)
- レビューまたはペアプログラミングされている
- 自動ユニットテスト(UI以外、つまり、ビジネスロジックを含む層 は95%以上のテストカバレッジがある)
- 自動 Selenium テスト: 各利用シナリオに最低1つの Selenium テス トがある
- ターゲットデバイス上にAppiumのテストがある
- すべてのテキストが国際化されている
- 既知のバグが存在しない


プロダクトオーナーにとってなぜ重要なのか
　プロダクトオーナーにとって、これら「完成」の要素のいくつかは容易に理解できるものです。統合されたプロダクト、必要なレベルの文書化やコンプライアンス、そして、ある程度のテストは間違いなく必要です。それなのに、なぜコーディング標準の遵守といったプログラミングの要素にも関心を持つべきなのでしょうか。なぜ、メソッドは長くとも12行以内でとか、1行は80文字以下といったことが重要なのでしょうか。なぜあなたはプロダクトオーナーとして、こ れらの点を意識したり、チームに強要さえする必要があるのでしょうか。
　こう考えてみてください。なぜあなたは定期的に車のオイルを交換するのか と。なぜ、定期的にタイヤの空気圧をチェックしたり、車を修理に出したりするのでしょうか。ドライバーとして、あなたは単にA地点からB地点に移動したいだけであり、それがあなたにとっての価値なのです。しかし、日ごろからメンテナンスに気を配っていないと、やがてその怠慢が仇となり、道端で故障して高額な修理代がかかることになります。ソフトウェアも同じです。定期的にメンテ ナンスを行わなければ、大量の技術的負債を抱えることになります。つまり、開発が遅れ、イノベーションが減り、長い目で見ればはるかに多くのコストがかか るのです。
　そのため、プロダクトオーナーにとって「完成」の定義の技術的な概念を理解し、それが長期的に悲惨な結果をもたらす可能性があることを認識しておくことが重要です。これが、技術的なことについて知りたい、そしてトラッキングしたいと思う理由です。

TIMWOOD
運搬のムダ Transport 工程間で作業を運搬すること。ソフトウェアプロダクト開発では、人や部門間の引き継ぎがこれに相当する

在庫のムダ Inventory 不要な在庫。ソフトウェアでは、要件、仕様、ソースコード、テ ストなど、まだリリースされておらず、顧客に使用されていな いすべての作業がこれに相当する

動作のムダ Motion 手動回帰テストのような同じ動作の繰り返し。タスクの切り替 えも動作のムダの一例(例: オンプロダクト指標)

手待ちのムダ Waiting 人(スキル)、データ、システムの稼働待ちなどアイドルタイム の原因となるもの、つまり依存関係の管理に関わるもの

作りすぎのムダ Overproduction 未使用の機能(例:使用指標)

加工のムダ Overprocessing 付加価値を生まないプロダクトに役立たない仕事。不必要な書 類や会議、チーム間の人の移動に伴う再学習の繰り返し

不良・手直しのムダ Defects 欠陥


　人間は物事を比較するのが得意であることが、研究により明らかになっています。例えば、建物の高さを比べるのは得意です。しかし、ビルの高さを何メートルで推定しろと言われるのは、あまり得意ではありません。
　このスキルを活用し、過去の経験を活かすことで精度を向上できるのです。忘れてはならないのは、これはまだ見積もりであり、科学的に100%正確ではないということです。Rally 社が行った研究[63]では、70,000以上のスクラムチームを分析し、パフォーマンスが圧倒的に悪いチームは見積もりを全く行わないチー ムではなく、時間単位で見積もりを行うチームであることがわかりました。対して最もパフォーマンスの高いチームは、相対的なポイント見積もりを使用していました。このことから、日数や時間で見積もるよりも、全く見積もりをしない方がよいと結論付けることもできそうです。
　ベロシティにポイントを使うことについての最後の注意です。第3章で触れた ように、ベロシティは価値の二次的な表現にすぎません。また、グッドハートの法則「尺度が目標になるとき、それはよい尺度でなくなる」に陥りやすいもので あることを思い出してください。
　ベロシティは価値中立な指標と考えるべきで、スクラムチームがその主な利用者であるべきです。それを使ってリリース計画を認識し、途中経過を検査して適応できるようになる必要があります。全体的な進捗を透明化することは重要です が、管理職や顧客などの外部のステークホルダーにとっては、ポイントの値そのものは意味がないと考えるべきです。第3章では、提供される価値のよりよい指標として使用できる、他の多くの選択肢を紹介しています。


アジャイルな予算作成 (FEED-ME)のための6つのステップ。
1. プロジェクトではなく、プロダクトとそのビジョンに資金を提供する (Fund products and their visions instead of projects)
プロジェクトの資金ではなく、プロダクト単位で考える。プロダクトを持 つには費用がかかる。2週間のスプリントで5万ドルかかるとすると、年間130万ドルの出費だ。その場合、何人の社員と開発チームに資金を提供できるだろうか

2. プロダクトオーナーに権限を与える (Empower the Product Owner)
スコープ、スケジュール、予算をプロジェクトマネージャーに割り当てる のではなく、プロダクトオーナーがプロダクトに対して起業家精神を持つ スポンサーになれるようにする(第1章参照)。プロダクトオーナーに受託者責任*3を持たせるのだ

3. 透明性の確保(Establish transparency)
定義された線形アプローチで考え、行動するのではなく、継続的な計測を可能にする経験的なフィードバックループを確立する。常に「まだ軌道に乗っているか? まだ正しい軌道に乗っているか?」と問い続ける

4. 価値をできる限り早く見せる (Demonstrate value sooner)
リリース頻度が高ければ高いほど、ステークホルダーは投資に対するリターンを実感し、資金提供の継続や増額に意欲的になる

5. ステークホルダーの期待値マネジメント (Manage stakeholder expectations)
ステークホルダーには、資金がどこに使われ、どのような見返りがあるのか、常に情報を提供する。複雑なプロダクトの構築には不確実性が伴うこと、方向性を変更する必要があることを、ステークホルダーに気づかせる。作業の進行に伴い、新たなステークホルダーに注目する

6. 検証を通じた経験的な予算作成を採用する (Employ empirical budgeting through validation)
固定された予算(およびスコープとスケジュール)に基づくのではなく、仮定を検証しながら集めた証拠に対処するために、予算は変化する必要があることを認識する。予算は、再割り当て、削減、増加、あるいは破棄する必要があるかもしれない。検証を行い、新しい証拠が収集されるたびに、予算を再検討することを計画に入れておく

[mcmrさんの感想 · 2024年8月12日]

想像以上に考え方やプラクティス満載で勉強になった。プロダクトマネジメントに通ずるのでチームで読書会してもいいかもしれない

[Yamamoto Yuichiroさんの感想 · 2024年7月29日]

プロダクトオーナーについて、かなり広範囲かつ具体的に書き綴られている。
経験者が知見を深めるには物たらず、入門に向けた位置づけにある。いくつか重要なポイントもあるものの、鵜呑みにしては危なそうなところがあったり、何を言わんとしてるか伝わらない下りがあったりと、初心者には難しいところもある。