『スクラムを活用したアジャイルなプロダクト管理』第1章のコメント・疑問

まえがき(xii)

「プロダクトマネージメントについて、多くの優れた書籍があります」私自身はプロダクトマネージメントについて何の知識もないことに気づきました。ちなみに「プロダクトマネージメント」でGoogle検索すると約316万件がヒットします。「プロジェクトマネージメント」だと約246万件です。プロダクトマネージメントの方がより一般的に知られている概念なのでしょうか。意外でした。（山本）

P.xiii 「なぜアジャイルなプロジェクトマネージメントは異なるのか」 プロダクトマネージメントの誤訳？ (You&I)

    • 原書で確認したら「WHY AGILE PRODUCT MANAGEMENT IS DIFFERENT」だったので誤訳ですね。

第1章 プロダクトオーナーの役割を理解する(P.1)

1.1 プロダクトオーナーの役割(P.2)

P.2 「Ken Schwaber」 Jeff Sutherlandと共に1993年にスクラムを体系化したお方。 (You&I)

P.2 「Scrum Guide」 PDFで配布されているスクラムの解説資料。日本語版もあります。 (You&I)

P.2 「スクラムミーティング」 恐らくデイリースクラム(朝会)と同義。 (You&I)

    • ここではスクラムの様々なミーティングの意味合いで使われている。

P.2 「SAP AG」 日本で言う所の「SAP株式会社」のドイツ語表記。 (You&I)

P.2 「スクラムチーム」 プロダクトオーナー、開発チーム、スクラムマスターの３つ役割の人々で構成される７±２人(資料・文献によって変わるが基本的には10名以下)のチームの事。 (You&I)

P.3 「大きなスクラムプロジェクト」 スクラムにおいて大規模開発を行う場合には、スクラム オブ スクラムというスクラムチームを幾つも束ねてまたスクラムチームとするやり方があります。 (You&I)

P.3 「Ript」 もう会社や製品はなくなってしまっているようですね。 (You&I)

P.3 プロダクトオーナーに権限と責任を集約することでメリットを引き出そうという発想だと分かりました。プロダクトマネジメント初心者として、一極集中による弊害、例えばその人が不在になる状況での停滞とか、その人の能力以上のことはできないとか、もあるのではと考えてしまうのですが、どうなのでしょうか。この先を読み進めれば分かるでしょうか。（山本）

1.2 プロダクトオーナーとして望ましい特性(P.3)

1.2.1 明確なビジョンを持った実行家(P.4)

P.4 「作家のJonathan Swift」 ガリバー旅行記などを執筆。 (You&I)

1.2.2 リーダーとチームプレーヤー(P.4)

P.4 「GE」 アメリカのGeneral Electric社。 (You&I)

P.4 「プロダクトオーナーは、製品に関して開発チームにおける「リーダー」だと言えます」 日本ではリーダー＝責任者＝管理職という事が多く、役職を持つ人が担当する事が多い。アジャイル開発やスクラムにおいて、プロダクトオーナー＝管理職というのは必ずしもそうではない。 (You&I)

P.5 「ファシリテーション能力」 ファシリテーションとは組織や参加者の活性化、協働を促進させる手法・技術・行為の総称。 (You&I)

1.2.3 コミュニケーターとネゴシエーター(P.6)

1.2.4 権限が付与された献身的な人物(P.6)

P.6 「適切な意思決定の権限を与えられたプロダクトオーナーが不可欠」 プロダクトオーナーの発言は、自己組織化されたスクラムチームにおいてだけではなく、組織においても尊重される必要があります。 (You&I)

1.2.5 可用性と資質(P.6)

P.7 「機能横断的で自立的なチーム」 自己組織化されているという事。スクラムチームは誰かに指示を仰いで行動するのではなく、自分達の意思決定を持って行動を行う。 (You&I)

P.7 ここまで読む限り、プロダクトオーナーはエース級の人材ですね。そんな人がマネージャならばScrumを採用しない場合でもプロジェクトは成功する可能性が高い気がします。（山本）

1.3 チームとの協働(P.8)

P.8 「私たち」 [私たち]と[問題]という構図で問題解決に邁進する事が重要ですね。問題の責任を誰が取るのではなく、問題をどう解決するか。 (You&I)

P.8 「個人の集まり」 個人の集まりを組織化するのに用いられるのがチームビルディングですね。チームビルディングもアジャイルは開発と同様に、持続性・継続性が大事だと思います。 (You&I)

P8. 「スクラムメンバー全員を同じ場所に配置」 eXtremeProgrammingのプラクティスにもある「全員同席」と同じですね。 (You&I)

P.8 プロダクトオーナーはスクラムチームの成果物を評価する立場にあるので、距離を置いた立場になるようなイメージを持っていましたが、間違った理解ですね。（山本）

1.4 スクラムマスターとの協働(P.9)

P.9 「全てのスクラムチームにはスクラムマスターが必要」 スクラムマスターは、開発チームが雇い入れ、スクラムチームがスクラムをうまく回せているかを監視し、補助する。スクラムマスターは権限を持たないが、スクラムチームが最大限の成果を出せるように尽くす。 (You&I)

P.9 「適切な製品が適切なプロセスで開発された場合にのみ、持続的な成功が実現します」誤解を招きそうな言い方だと思います。適切な製品と適切なプロセスは固定しているものではなくムービングターゲットで、探求し続けていくもの、ですよね？（山本）

P.9 「スクラムマスターとプロダクトオーナーの兼務」 自分は冷静に考えると、POと開発者は兼務してしまっていますね・・・。 (You&I)

1.5 顧客、ユーザー、他のステークホルダーとの協働(P.10)

P.10 「製品単体の話で終わるわけではない」 最近だと、DevOpsやALMといった、製品が開発部門が開発して終わりではないという考え方が重要視されていますね。 (You&I)

P.11 「戦略と戦術」 (You&I)

    • 戦略(Strategy)、作戦(Operation)、戦術(Tactics)、そして兵站(Logistics)

  • http://d.hatena.ne.jp/shi3z/20120416/1334543387

      • イベントで例えると・・・

      • 戦略

        • イベントを開催するべきか。いくらの予算をかけて、どんな成果を求めるか

      • 作戦

        • いつ開催するか、どこで開催するか、どんなイベントにするか、どこで宣伝するか

      • 戦術

        • 受付のシステムはどうするか、VIPが来た時には誰が案内するか、講演者の昼食はどうするか

      • 兵站(へいたん)

        • イベントの開催に向けて準備や行動をする事。

        • イベントは始まってしまったらどう足掻いても戦略や作戦のミスを取り戻すことはできない。

1.6 プロダクトオーナーの役割のスケーリング(P.12)

P.12 「最初から多くの人数で開始」 書籍『リーン・スタートアップ』でも語られている事ですが、物事を始める際にはあまり資金が多いと、逆に色々なものに手を出してしまって発散してしまい失敗してしまうとあります。この場合も同じだなと思いました。 (You&I)

1.6.1 チーフプロダクトオーナー(P.12)

1.6.2 プロダクトオーナーの階層化(P.13)

1.6.3 適切なプロダクトオーナーの選択(P.16)

P.16 「フィーチャー」 顧客視点でEnd-to-Endの一連の流れで定義される機能単位の事。 (You&I)

P.16 「プロダクトオーナーよりアーキテクトやシニア開発者がこの役割に向いている」 うーん。この役割＝プロダクトオーナーだと読み取れるので、何かちょっと翻訳に違和感を覚えますね。 (You&I)

1.7 よくある間違い(P.17)

1.7.1 力不足のプロダクトオーナー(P.17)

1.7.2 働きすぎるプロダクトオーナー(P.18)

P.18 「アジャイル宣言」 アジャイルソフトウェア開発宣言(アジャイルマニフェスト)は4つの価値と12の原則 (You&I)

1.7.3 限定的なプロダクトオーナー(P.19)

1.7.4 遠隔地のプロダクトオーナー(P.19)

1.7.5 代理のプロダクトオーナー(P.20)

1.7.6 プロダクトオーナー委員会(P.20)

1.8 おわりに(P.21)