だいくしーさんこと、粕谷大輔さんの『スクラムの拡張による組織づくり』を読みました。
複数のスクラムチームを協業させていく手法として「Scrum@Scale」を軸に、スクラムという概念自体のおさらいから始まり、コミュニケーションを軸とした組織の作り方、運用の仕方を解説していく構成になっています。
第3章で出てくる「毎日45分で問題が解決する」というのはなかなかキャッチーな表現で、Daily Scrum -> Scaled Daily Scrum -> Executive Action Teamのそれぞれに15分という目安を作ることで、議論ではなく問題の確認と決定の場としてショートに実行するものである、という定義が明確で分かりやすい。
問題の起きているプロジェクトでは朝会や、Daily Scrumが議論の場になったり、一方的に司会の人だけが話して終わり、みたいな雰囲気になりがちで、最初から「この状態から外れていると上手く機能していないな？」というベンチマークが分かっていると、問題に気づきやすくなる。
経験が無いと、上手く行っていないことを場当たり的に解決しようとしてしまうのだけど、プロジェクトにおいて問題が”順調に解決されていかない”理由は、たいてい「メンバのプロジェクトへのコミットメントの欠如」か、「タイムリーにコミュニケーションが行われず、意思決定のタイミングが遅れる、間違った情報をもとに意思決定が行われる」ことだったりして、その点に先回りして解説がされているのが上手い。
経験が無い人にとっては、組織間のコミュニケーションが乱れている状態が発生するとどこから手を付けてよいのかが分からなくなるので、内容的な交通整理は当然やるとして、日々のコミュニケーション方法を見直す指針がこうやって示されると、「まずはやってみるか」と考えられる。
この本に書かれているような組織構造や、営みをやったからと言って、問題がすぐに解決するわけではないけど、問題の可視化と、その情報の流通、意思決定をやっていくための型を作ることで、一つ一つの課題によりフォーカスした議論ができるな、と思いましたし、それを定義すること自体がまさに、”組織をつくること”なんだと思います。
人員を配置して、体制図を作れば組織ができるわけじゃないですからね。
追記
別にスクラムを導入するとかしないとか、関係なく、組織におけるチーム間のコミュニケーションの形をどう考え、意思決定に結び付けていくか？という視点で読むだけでも価値があるなーって思った
— magnoliak🍧 (@magnolia_k_) 2023年8月27日
今まで組織の作り方に定型なんてなくて、全員が「うちは特殊だから」と思っていたことは無かったことがよくわかる
— magnoliak🍧 (@magnolia_k_) 2023年8月27日
組織をドライブするために大事なのは、メンバが保身に走ると「発言しない」「意見を言わない」ことに最適化されていくから、そうならないようにすることと、それを価値のある事だとわかってもらえるような意思決定をすることだと思っている（いま、すごくいい事言った）
— magnoliak🍧 (@magnolia_k_) 2023年8月27日
今まで組織の作り方に定型なんてなくて、全員が「うちは特殊だから」と思っていたことは無かったことがよくわかる
— magnoliak🍧 (@magnolia_k_) 2023年8月27日
組織をドライブするために大事なのは、メンバが保身に走ると「発言しない」「意見を言わない」ことに最適化されていくから、そうならないようにすることと、それを価値のある事だとわかってもらえるような意思決定をすることだと思っている（いま、すごくいい事言った）
— magnoliak🍧 (@magnolia_k_) 2023年8月27日
「プロダクトオーナーがWhatを担い、開発者がHowを担う」ってのを見て「プロダクトオーナーにはWhyをよく確認するなぁ」と思ったのだけど、よく考えると開発者もHowのWhyを伝えるからWhyはどこでも必要だった。WhatとHowで納得。
— Mitz Shiiba (@bufferings) 2023年8月27日
ぼーっと読みながら面白いなーと思いながらあれこれ考えてるのだけど、チームをまたいだプロダクトバックログの優先順位の高いタスクが特定のチームに偏る、って状況は、ありそうだなぁ。とか、ぼんやり。
— Mitz Shiiba (@bufferings) 2023年8月27日
