プロダクトオーナーとして余裕があれば複数チームを担当するのもありと本書には書かれています。私はいま3チームをみているのですが、スクラムのアクティビティにかかる時間的に3チームが限界ですね。2チームまでが適切な感触です。プロダクトオーナーチームチーフプロダクトオーナーという役割が出てきますが、チーフプロダクトオーナーは直接開発チームを見ないようなのでそれってもはやプロダクトオーナーじゃないんじゃないかと思ったのですがどうなんでしょうか。プロダクトマネージャー?勉強会ではプロダクトオーナーとプロダクトマネージャーの違いについてディスカッション。個人的にはスクラムだとスクラムマスターという存在がいるので、プロダクトオーナーの方が少し楽なんじゃないかと思っています(スクラムではない体制におけるプロダクトマネージャーに比べて)。勉強会参加者にプロダクトオーナーになりたい人はと聞いたところ、やりたい人・やりたくない人双方いました。(決して軽視しているわけではないけれども)「プロダクト」よりも「プロセス」の方が面白いからプロダクトオーナーになりたいとは思わないとのことでした。スクラム」を読みたい人が集まる勉強会10回目。問題を解決するためにいるわけではない。あなた方が問題を解決できるようにここにいるのだ」チームに作業を依頼したり、仕事のやり方を指示したりすることもできない。スクラムマスターには仕事を完成させる責任はない。スクラムマスターはコーチのように振る舞いプロセスのリーダーとして支援する役割の人です。スクラムマスターの存在はスクラムのかなり大きな特徴といえる要素だと思っています。スクラム以外の開発プロセスで同様にコーチ的な役割の人は定義されているのでしょうか。そんな特筆すべきスクラムマスターですが、期待よりかはちょっとあっさりな説明だった感じはします。誰がスクラムマスターになる?スクラムマスターの経験豊かな人がいる場合は別として、多くの場合は今いる人の中の誰かになってもらうことになるのでしょう。その場合はビジネスドメインの専門家の必要はないが技術的知識を理解していることコーチとして質問力がある・辛抱強いことが良い条件のようです。人が少ない場合はどうでしょうか。その場合は複数のチームのスクラムマスターを兼任する形が良く、そうでなければ(有能な人であれば)開発チームメンバがスクラムマスタを兼任するのが良いとのことでした。前の章でも書かれている通りスクラムマスターとプロダクトオーナーの兼任はやめた方が良いとmもあらためて述べられていました。スクラムマスターはとても1章で全てを語れるものではない奥が深いものなのでしょうね。担当することになったら沢山学ぶべきことがありそうです。スクラム」を読みたい人が集まる勉強会11回目。ここまでの章で様々な視点でスクラムの説明がされてきたので、開発チームの章は比較的おさらないな感じで読めました。テストなど必要な作業を全て行うので、必要なスキルをチームは全て備えている必要があります。このためにマネージャーは、今いる人たちでT型スキルのチームを作るべきである。マネージャーは、学習や実験の時間がうまく作れるように、チームメンバーを支援する必要がある。他のメンバと互いに専門分野を教え合いながらできる仕事を増やしていくのがまずは近道でしょうか。型の縦の部分、専門分野の部分を深めていくのは(機能別のチームで学び合うのに比べて)難しくなるのではと感じました。「専門分野については個人で学ぶ方法を獲得していて自力で学べるのでは」という意見が勉強会では出ました。開発チームの構成チーム構成の話では小さいチームの方がコミュニケーションでの帯域が向上する誰かがやってくれるという意識が減るとしています。学習などを考えるとある程度の人数も必要でこのあたりのバランスが重要そうです。本章では一般的には5〜9人のチームが最適とされている。ビジネス価値を迅速に届けるスイートスポットは5〜7人のチームである。いう意味では今の私のいるところのスクラムチームは人数がちょっと少なすぎるかなと感じました。掛け持ち掛け持ちに対する問題は承知しているものの、現実的にせざるを得ない場合が発生します。複数のプロダクト(またはプロジェクト)や複数のチームに関わると生産性が低下する3つ以上のプロジェクトの仕事を同時に行うのは経済的ではないとありこれに従うとすると仕方なく兼務にするにしても2つまでにすべきということですね。いった状況が発生するのは多くの組織では、同時に開始するプロジェクトが多すぎるということで組織体制の工夫以前にプロジェクトの見直しをすべきなのでしょう。長寿のチームはできたてのグループよりも生産性が高いについては完全同意。今までもチーム殺しをしないように意識はしてきました。スクラムではチームとして見積もりやベロシティの履歴が蓄積されることで正確性が向上していくところがあるので、チームを維持していくことがより大切に感じられます。スクラム」を読みたい人が集まる勉強会12回目。スクラムチームの構成。今回の内容は主にスクラムチームメンバより上のレイヤーの人たち向けの内容です。複数のスクラムチームによる共同作業が必要だと、いつかは思い知ることになるのだ。いうことで複数のスクラムチームの話。前半はフィーチャーチームとコンポーネントチームについて。本書ではフィーチャーチーム推しで、コンポーネントチーム構成からフィーチャーチーム構成へ徐々に移行する場合の体制の案を示しています。フィーチャーチームかコンポーネントチームかという問題を解決する万能のソリューションはない。いうことで、ここはプロダクトと組織にいるメンバの状況に合わせて考えていくしかない感じです。本章でも「同時に開発を進めるプロダクトの数を減らす」という話が出てきていろいろ考えさせられます。スクラムオブスクラムについては、定期開催で開かれるのは良いとして現実的にはアドホックにどんどん相談していっちゃう方が早いんじゃないかなと感じました。リリーストレインについてはかなり大規模なプロダクトが想定でしょうか。「スクラムのためのアクティビティで時間が奪われすぎないか」「末端のスクラムチームでは適応できる余地が少なくなってしまうのでは」などという疑問が湧きました。スクラム」を読みたい人が集まる勉強会13回目。スクラムフレームワークではマネージャーという役割は取り上げられていませんが、組織を回すために必要な役割として1章割かれています。ファンクショナルマネージャーファンクショナルマネージャー(あるいはリソースマネージャー。機能エリアごとのマネージャーのこと)の責務として本書では以下を上げています。チームを編成するチームを育てる環境を合わせてなじませる価値創造の流れを作るマネージャーの役割は「戦略的な方向性を定めること」「戦略目標を達成するための組織的リソースを採算を考慮して揃えること」とのこと(スクラムの環境において)。チーム編成のところで権限の7つのレベルの話が出てきます。自己組織化されたチームであるためにはメンバが権限(と信頼)が必要で、マネージャーはアクティビティや意思決定の種類ごとに適切なレベルで移譲すべきとしています。本書ではマネージャーが分野・コミュニティ別にいる組織をメインに説明されていましたが、マネージャーが複数のチームを抱えるような組織についても説明を聞きたいなと思いました。チーム編成のところは今の自分の立場での大きなトピックとして意識していきたいです。後半はプロジェクトマネージャーの話。スクラムチーム数が多くて、さらに立場が異なってスクラムオブスクラムでの話し合いでもうまくいかないような場合に、他チームとの調整を効率的にする役割としてのプロジェクトマネージャーを置く場合もあるという説明がされていました。多くの組織ではいらないのかなと感じました。スクラム」を読みたい人が集まる勉強会の14回目。スクラムのプランニングの原則。人があらためて「原則とは?」という点について掘り下げてくれました。人が語ってくれました。「アジャイルソフトウェア開発宣言」と「アジャイル宣言の背後にある原則」についてその場でみんなで見返しました。事業体としての価値観と原則、個人としての価値観と原則、そして開発プロセスフレームワークとしての価値観と原則と、この辺り自身でも整理しないとなと最近考えているところです。プランニングプランニングについては出来上がった計画よりも計画のための対話などのプロセスが重要なのだなと最近感じるようになりました。事前にきちんと計画を作れると思うな計画を守ることよりも、計画の調整や再計画を重視するということで継続的にプランニングし直していくことが大切なのだなと。プランニングの選択肢は、最終責任時点まで変更可能にするについてはここではかなりあっさりとかかれています。物事を進めるには常に大小様々な意思決定をしていく必要があるので、さらっと読むと気持ちわるい感じがします。節にも重要で後戻りのできない決定をしかるべき最後の瞬間まで行わないのである。あるので、方向転換できない状態に早い段階でならないようにするといったところなのだと理解しました。早めにリリース、頻繁にリリースについては原則として頭にいれつつ、実際には適切なフィーチャーが揃っているかをきちんと考える必要がありますね。あまりに小さなリリースすぎて早い段階でユーザーに見限られてしまう危険性や、頻繁な変更によってユーザーが負担を感じて満足度が低下してしまう可能性も常に意識すべきかと。この章でもこの手法には限界もある。どんなプロダクトであっても、最低限これだけは揃えないとリリースできないし市場で勝負できないというフィーチャー群がある。言った上でもし部分的にでもよいから少しでも早めに受け取りたいという業界を相手にしているのなら、小さい単位で頻繁にリリースするという原則はとても重要になる。スクラム」を読みたい人が集まる勉強会の15回目。さまざまなプランニング。昨年12月のプロダクトオーナーの章ぶりの発表当番です。この章ではスクラムを使ったプロダクト開発に関係する以下のプランニングを紹介しています。1つのプロダクト)を確認し、実際やっていることのどれが各プランニングにあたるのかを確認。スクラムチームメンバから直接体感できるのはプロダクトプランニングまでで、ポートフォリオプランニングはうかがい知れないことが多そうという話になりました。それから(旧来からの)受託開発の場合は、リリースが固定スコープ・固定日だよねなんて話も。スクラム開発チームメンバからは「トップダウン型のプランニングの流れの印象だが、スクラムチームの見積もりでわかった計画との差異はどのように上位の計画に反映していくのか?」という疑問もあがりました。このあたりは続く章で説明があるのかもしれません。スクラム」を読みたい人が集まる勉強会の16回目。ポートフォリオプランニング。これまで読んだ章の中で一番頭にすっと入ってこない章だったのは、あまりかかわってこなかった領域だからでしょうか。ポートフォリオプランニングはプロダクト(あるいはその1リリース、プロジェクトなど)をどれぐらいの期間でどの順番でやるかを計画する作業です。本書ではプロダクトのライフサイクル収益(プロダクトの生存期間中に見込める利益の総合計)が最大になるように優先順位を決めましょうと言っています。ライフサイクル収益は遅延コストと存続期間の影響を受けるのでこれをきちんと考えましょうとのことでした。今日の発表者によると「ライフサイクル収益を使うのは社内政治の排除のため。研修で聞いたとのことでした。社内政治排除のためというところが重要どころだそうです。本書によるとポートフォリオバックログに入れる際はコストや価値に関するちょっとした見解の相違で言い争いになって決断ができないのだとしたら、そのプロダクトの開発は却下すべきだ。ほとんどの組織では、価値の高いプロダクトを開発する機会が有り余っている。価値を生み出すか疑わしいプロダクトについて、いつまでも議論をしている余裕はないはずだ。採用面接ゲリラガイドを思い出しました。スクラム」を読みたい人が集まる勉強会の17回目。(プロダクトプランニング)。「エンビジョニング」という言葉に馴染みがなかったので「プロダクトプランニング」の方がわかりやすいよなーと最初は思ったのですが、慣れてくればエンビジョニングでも「ビジョン」に意識が向いていい気がしました。エンビジョニングのタイミング何度も繰り返すアクティビティであり、一度やってそれで終わりではない。これ系のアクティビティはどうしても半期毎のサイクルになってしまいがちなのですが、アジャイル的にはもっと早いサイクルにやった方が良いということですね。エンビジョニングをやりすぎないようにエンビジョニングの完了予定日を設定しておくのは確かに必要だなと感じました。やろうと思えばいくらでもやれてしまうものなので期日を明確にした方が経済的でしょう。最初のエンビジョニングで必須なのはプロダクトオーナー。プロダクトの開発が動き出して以降のエンビジョニングにはスクラムチーム全体が参加すべき。概要レベルのプロダクトバックログの作成でストーリー記述する際もスクラムチームメンバ全員が関わった方が良いと言っています。このあたり結構孤独にやっちゃうことも多いんじゃないかと思うですが、やはりチームでやった方が良いようです。「ステークホルダーが得る価値の分野」としてカテゴリ分けされているのは地味に便利ですね。市場に投入する時期を早める開発工数や投入する要員を減らす利益を増やすプログラミングの技術を高める自分が取り組んできたものだと「顧客を喜ばせる」「要員を減らす」とかが多かったですが、製品・市場によっては確かに妨害とかもあるのでしょうね。今日は参加者少なめで5人。23章までいれるとあと6回のところまできました。入門勉強会グループメンバで都合のつく人で交流ランチ。第1回の勉強会のふりかえりや次回の進め方などの話をしつつ、カジュアルにプロダクトマネージャー業の情報交換となりました。私のグループのチームは今はスクラムで開発していますという話をしたところ、他の3名のところではスクラムを導入していない/できていないとのことでした。スクラムを読む会」という社内勉強会に参加している最中です。1週1章1時間、(参加者がその回の章を読んできている前提として)その日の当番の人がサマリを発表、流れで随時「ここ良くわからなかったのですけれどどう思います?」とか「私たちの組織・やり方だとここが当てはまっている・違っている」とかそういう会話をする流れでやってます。いった感じで進めていますと紹介しました。戻って読み合わせやろうという話になっているというコメントをもらって、皆さんスピード感があってさすがだなぁと。事業の部長をしています。日記(兼パーソナルナレッジベース)です。※内容は個人的見解であり所属組織とは関係ありません。