前回の「ゾンビスクラムサバイバルガイド」に続き、また翻訳者の たくぼん さんから書籍「プロフェッショナルプロダクトオーナー」をプレゼントしていただきました。いつもありがとうございます。
概要
この本は、サブタイトル「プロダクトを効果的にマネジメントする方法」にもあるとおり、プロダクトオーナーの役割を担う人が、スクラムを使ってプロダクトを構想し、生み出し、成熟させる方法を説明しています。
感想
この本は、私がこれまでセミナーや書籍やコミュニティなどで学んできたスクラムとプロダクトオーナーに関する重要なポイントが分かりやすく纏められていました。さらに、これまで私が学んできた中には無かった新たな重要なポイントについても、エピソードや具体例を交えて解説してくれており、今後の現場で役立ちそうな知識の引き出しが増えたように思います。原書は2018年の出版以来、アジャイル界隈におけるベストセラーとして広く読まれていたようですが、翻訳版も忖度なしに良書だと思えました。一点だけ残念な点を挙げるならば、持ち歩き用にKindle版の電子書籍を買おうとしたら超絶不便な固定レイアウト形式（文字列検索などができない形式）だった点でしょうか…😅
本書の構成
本の構成は、下記のような章立てになっています。
＜構成＞
原書刊行に寄せて
日本語版刊行に寄せて
まえがき
■第１部 戦略
第１章 アジャイルプロダクトマネジメント
第２章 ビジョン（Vision）
第３章 価値（Value）
第４章 検証（Validation）
■第２部 スクラム
第５章 経験主義
第６章 スクラム
■第３部 戦術
第７章 プロダクトバックログマネジメント
第８章 リリースマネジメント
第９章 プロフェッショナルプロダクトオーナー
本を読んで個人的に印象に残った点を中心に書き留めておこうと思います。
印象に残った点
印象に残ったフレーズや共感できた点などを以下にメモしておきます。
原書刊行に寄せて
【Page：iv】
"スクラムの大きな強みは、伝えていることがどれだけ明確であるか、相手がどれだけ認識していさるかを頻繁に確認できることです。"（ケン・シュエイバー）
まえがき
【Page：x】
"プロダクトオーナーは、開発、パートナーシップ、インターフェースなどさまざまな方法でプロダクトを持続させ、成長させます。ただし、「自分が決断する」という人物、つまり委員会やグループではない1人の個人だけが、この機能を果たします。"
第３章 価値（Value）
オンプロダクト指標
【Page：68】
"開発者がプロダクトなど、ただ１つの仕事に取り組むことが許される時間。開発者が競合する仕事の間でタスクを切り替えれば切り替えるほど、開発者のコミットメントは低下し、遅延が発生する"
イノベーション率
【Page：73-74】
"設計・開発不良のソフトウェアによる技術的負債の増大。古いソフトウェアを生き長らえさせるため、予算がどんどん消費される（中略）Forrester researchの調査によると、2010年には、IT予算のうち、新しいフィーチャーと保守・拡張に費やされる割合は30%未満でした（図3.16 参照）"
率指標の悪用
【Page：81】
"問題を解決しようとしたことが問題を悪化させてしまい、意図しない結果に至ることをコブラ効果といいます。この言葉はインドの英国植民統治時代の逸話に由来しています。デリーに出没するコブラの数、これが政府の懸念事項でした。そこで、コブラの死体１匹につき報奨金を出すことにしたのです。当初は報奨金目当てに多くのコブラが殺されたので、戦略は成功したかの用に見えました。しかし、収入の足しにするためにコブラを繁殖させようとする輩が現れ始めました。英国政府がこれに気づいて報奨金制度を廃止すると、コブラを飼育していた者たちは価値のなくなった蛇を野に放ちました。結果として、野生のコブラはさらに増えました。表面上の問題解決が状況をさらに悪化させたのです。（中略）「尺度が目標になったとき、それはよい尺度ではなくなる」というグッドハートの法則がこれを言い表しています（図3.20 参照）。"
第４章 検証（Validation）
ステークホルダーからのフィードバック
【Page：87】
"ステークホルダーの検証の好例として、Subwayのサンドイッチショップがあります。Subwayは、sandwich作りと顧客との間に透明性を作り出しています（図4.1 参照）。"
狩野モデルによるMVP
【Page：90】
"当たり前フィーチャー、十分な一元的フィーチャー、いくつかの魅力的フィーチャーを押さえれば、MVPになります（図4.4 参照）。
プロダクトは決して「完成」するものではないので、一連のMVPを次々と作っていくことになります。いったんMVPを市場に出したら、主要な価値指標を収集して、次のMVPのためのプロダクトバックログ作成などを行います。
時が経つにつれ、魅力的なものも一元的フィーチャーに変わり、やがて当たり前フィーチャーへと変わっていきます（図4.5 参照）。アンチロックブレーキシステム（ABS）は、かつては高級車のみに搭載されていたフィーチャーでした。現在では、すべての車の当たり前フィーチャーだと考えられています。"
第５章 経験主義
複雑さの可視化
【Page：108】
"ステイシーマトリクス（改変版）（図5.1 参照）では、
X軸は使おうとしている技術の確実性を表しています。（中略）左側に行くほど確実性は高くなります。そして右側に行くほど確実性は低くなります。右端では、新しい技術を開発する必要があり、その過程で多くの課題があることを示しています。（中略）
Y軸は要件がどの程度合意されているかを表しています。原点に近いほど必要なことが完全に合意され、変更がないことが期待できます。原点から離れるほど、合意されていることが少なくなります。極端な話、誰も合意しておらず、大まかな目標でさえ合意していないかもしれません。
ケン・シュエイバーは３つ目の軸として、チームという次元を追加しました。"
リスクをマネジメントする
【Page：118】
"僕はマネジメント3.0のクラスで、ティム・ハートフォード（Tim Harford）の短いTEDトーク「Trial, Error and the God Complex」を紹介するのが好きだ。この動画でティムは、リスクを取って学習すること、つまり「よい失敗」をすることの重要性を説明している。"
第６章 スクラム
なぜフレームワークなのか？
【Page：126】
"スクラムは自らをプロセスと呼ぶことを慎重に避けています。（中略）ここでポイントとなる要素はオーナーシップです。（中略）スクラムチームがプロセスを自分のものにする必要があります。チームやプロダクト、企業はそれぞれ異なるので、独自のニーズを支援するためにそれぞれに合ったプロセスが現れてくるはずです。とはいえ、足場となる何かから始められれば、チームにとって助けになるでしょう。それは、最小限のルール、つまりフレームワークです。（中略）
プロセスでも同じことが起きます。チームの外で定義され導入されたプロセスを頭ごなしに「押し付け」られたなら、何か問題が起きたときにチームは経営陣やPMOに連絡するでしょう。彼らはプロセスのせいにし、同僚とlunchを食べながら文句を言ったり、ネット上に怒りの投稿をしたりします。責任追及ばかりになってしまうのです。
スクラムが出発点、つまり、変更と改善の機会が組み込まれた真のフレームワークだとわかったとき、チームはオーナーシップを持ちます。物事が上手くいかなかったとしても、自分たち以外に責任を追求することはできません。これは、説明責任と自己組織化にとって不可欠な要素です。"
プロダクトオーナー
【Page：132】
"プロダクトの成功には、プロダクトを本当の意味で所有し、最終決定権を持つ人が１人いることが肝心です。
再考の開発チームがいても、間違ったプロダクトを作ってしまっては意味がありません。プロダクトオーナーは、正しいプロダクト、つまりプロダクト全体の品質を左右する重要な存在です。"
ドメインエキスパートとステークホルダーとの関係
【Page：134】
"よいプロダクトオーナーは、ビジネスをさまざまな角度から理解しているドメインエキスパートです。よって、プロダクトオーナーはステークホルダーと協調している中で新しい情報が出てきたときに、素早く調整し、合わせることができるのです。代理人となったプロダクトオーナーは、ステークホルダーの要望を集め、一番声の大きいステークホルダー（騒ぎ立てる人）が喜ぶように優先順位をつけることしかできません。（中略）
現実的には、プロダクトオーナーにそのドメインに関するすべての知識を求めることは、どだい無理な要求です。結果的に振る舞うプロダクトオーナーは、ビジョンとオーナーシップを保ちながらも、プロダクトを導くために他の専門家（Subject Matter Experts：SME）を活用できるはずです。"
開発チーム
【Page：138】
"プロダクトオーナーとして、完璧な開発チームとスタートすることはありえません。時間をかけて完璧なチームになっていくのです。プロフェッショナルなチームになるために必要な時間、集中、リソースを与えましょう。"
プロダクトオーナーとスプリントプランニング
【Page：161】
"２番めのシナリオでは、開発チームは最初から関与します。彼らは、なぜそうするのかという目的を理解します。その機能のオーナーシップを持つ、つまり自分たちのものになります。自分のものならば、気を配り、世話をし、成功させたいと思うものです。"
プロダクトバックログリファインメント
【Page：173】
"僕は、リファインメントは毎週１回がいいと思っているんだ。２週間のスプリントなら、リファインメントは２回だ。予定する時間は就業前の２時間、普通は午後３時から５時。ガイドに書かれている10%ではなく、5%の時間を使う。そして必要に応じて検査し、適応する。その場限りの少しの時間延長で済むこともあれば、そもそも時間を増やしたり、回数を増やすこともある。リファインメントに必要な時間は大きく跳ね上がることはないけれど、リリース内のどの位置にいるかによって、特にメジャーリリースがある場合は変わるかもしれないことを実感している。"
第７章 プロダクトバックログマネジメント
プロダクトバックログ
【Page：183】
"では、具体的には何をプロダクトバックログに入れればよいでしょうか？図7.2からもわかるように、プロダクトバックログはあらゆる種類の作業を受け付けます。
- 機能要求
- 非機能要件
- 実験
- ユーザーストーリー
- バグ・欠陥
- ユースケース
- ケイパビリティ
- etc.
"
エピック
【Page：193】
"どうやってストーリーを分割しますか？
これは多くのチームでよく課題になります。プロダクトバックログアイテムは、顧客にとって価値がなければならないことを思い出してください。たとえ小さくても、分割されたどのストーリーも何らかの価値を示さなければならないということです。こういった理由から、技術的なコンポーネント（UI、データベースなど）で分割されたストーリーは適切ではないと考えられています（図7.7）。"
受け入れ基準
【Page：195-197】
"ここで、よくある受け入れ基準の書き方を３つ紹介します。
テストは…
各受け入れ基準を「テストは…」という言葉で始めます。こｒが即座に人をテストマインドにさせます。プロダクトバックログアイテムごとに「完成」の確認をするために何をテストしようか？という具合です。
デモは…
各受け入れ基準を「デモは…」という言葉で始めます。これが、価値を実証するためにステークホルダーに見せたいことや、スプリントレビューについて考えさせます。ある意味、スクラムチームはスプリントレビューの台本を書いているとも言えます。スプリントレビューで受け入れ基準のリストを配り、１つずつ確認できます。例として図7.9では、受け入れ基準の欄に「デモは…」を追加しています。"
「完成」の定義の例
【Page：212】
"図7.15は１つのプロダクトに取り組む複数チームのための「完成」の定義の便利なテンプレートです。これは、各チームに共通する要素を定義していますが、各開発チーム内での作業方法には自主性が残されています。"
「準備完了」はマインドセットだ
【Page：213】
"ゴミを入れたら、ゴミが出てくる
ゴミをスプリントに投入すると、ほとんどの場合ゴミが出力されます。
スプリント開始時に「準備完了」でないものに手をつければ、スプリントの終わりに「完成」しないとも言えます。"
準備完了にする
【Page：217】
"素晴らしいアイデアを持ったスクラムチームと仕事をしたことがあるんだ。彼らは、ストーリーマップのように配置したプロダクトバックログの壁に「準備完了」ラインを追加した。リファインメントで、見積もられ、複数のカードに分割され、受け入れ基準を追加されるにつれ、プロダクトバックログアイテムは壁をどんどん上っていく。
やがて、カードは来居「準備完了」ラインのすぐ近くまでくる。その後、開発チームとプロダクトオーナーが「準備完了」であると判断して初めて、カードはラインの上にう移動され、次以降のスプリントに持ち込まれる。図7.17がその例だ。"
インパクトマッピング
【Page：224】
"インパクトマッピングは、企業がプロダクトを作る際の迷いを防ぐ戦略的なプランニング手法です。各想定は明確に伝達され、チームの各活動は、明確なビジネス目標の１つに向かって明確に商店を当て、調整されます。各活動が目的に明確に向けられているため、それに取り組みながら測定し、検証できます。そうすることで、より効果的なロードマップ作成に繋がります。"
第８章 リリースマネジメント
メジャーリリース
【Page：240-241】
"チームによっては、技術的なフェーズを複数のイテレーションで束ねることがアジャイルアプローチだと信じています（スプリントと呼ぶことすらあります。例えば、分析スプリント、設計スプリント、テストスプリントのように）。通常、そこには定められた計画と承認プロセスがあり、それから事前に準備された要件を実装するためにスクラムが使われ、最終的なリリース前にいくつかのテストがあります。これは、ウォーターフォールにスクラムのプラクティスをいくつか挟んだもの、つまり、ウォータースクラムフォールに他なりません（図8.3 参照）。"
複数チームを管理する
【Page：251-252】
"組織は、開発チームそれぞれに複数のプロジェクトを割り当てることでより多くの成果を得ようとし、その結果、ジョハンナ・ロスマン（Jphamma Rothman）が『Manage Your ProjectPortfolio』で述べているような問題が発生することが多くあります。
図8.5からわかるとおり、現在進行中のプロジェクトが増えると、人の時間の奪い合いが増えます。そのため、プロジェクトを素速く終わらせる能力が低下し、完了したプロジェクトの数は減少します。しかし、すべてのプロジェクトは会計年度を通して計画されているので、他のプロジェクトを開始する必要はあります。この複雑な適応システムにおいて、これは正の強化ループと呼ばれるものです。このループは、自己強化し、ループを通るたびに状況を悪化させます。最終的には、あまりに忙しく、過負荷で、多くのことを並行して行うため、何も出荷できなくなるのです。"
スケールしてもスクラム
【Page：258】
"結論から言うと、スクラムのコアとなる価値観とプラクティスは、スケールしても適用されます。Nexus、LeSS、およびScrum@Scaleは、『スクラムガイド』にしたがって開発されたため、経験主義のマインドセットと自己組織化を中心に据えており、それに最も近いものです。" ← ディシプリンド・アジャイル・デリバリー（DAD）、Scaled Agile Framework（SAFe）が含まれていないことに注目！
ガバナンスとコンプライアンス
【Page：281】
"企業規模が大きいほど、監視を維持し統制下に置くためのガバナンスが必要です。ウォーターフォールでは、ガバナンスのチェックポイントを開発フェーズ間のマイルストーンに一致させます。（図8.25 参照）。何かが構築されるまでは、書類上のガバナンスしかありません。
物事が上手くいかないと、たいていガバナンスが強化され、リリースがさらに遅れます。
ガバナンスなしではカオスになり、ガバナンスを強化すれば秩序も強化されるというのは根拠のない通説です（図8.26 参照）。"
スキルと特性
【Page：301】
"最も重要なスキルはドメインとビジネスに関する知識で、次に強力なコミュニケーションスキルと続きます。
最も重要な特性は決断力、すなわち決断し議論を終わらせる権限と能力を持つこと、次いでビジョナリーであることです。"
"プロダクトオーナーの職務記述書の例
ビジネスとドメインを理解する優れたビジョナリーを求めています。役割として、すべてのステークホルダーや関係者と強い交渉力を発揮する、決断力のあるリーダーであることを期待します。プロダクトへの情熱と聞く力は、変化や時折の逆風に対処するのに役立ちます。" ←いや、これスーパーマンやん！現実的にこんな人がどれくらい居るんだろうか、、、こんな人が居たら、別にスクラムじゃなくても上手くいきそうな気すらしますが、以前から思っていたとおり、やはりスクラムはプロダクトオーナー Heavy なフレームワークだなと再認識しました。😅
