Magnolia Tech

いつもコードのことばかり考えている人のために。

『スクラムの拡張による組織づくり』を読んで、そもそも”組織をつくる”ってなんだろうなって考えた

だいくしーさんこと、粕谷大輔さんの『スクラムの拡張による組織づくり』を読みました。

複数のスクラムチームを協業させていく手法として「Scrum@Scale」を軸に、スクラムという概念自体のおさらいから始まり、コミュニケーションを軸とした組織の作り方、運用の仕方を解説していく構成になっています。


第3章で出てくる「毎日45分で問題が解決する」というのはなかなかキャッチーな表現で、Daily Scrum -> Scaled Daily Scrum -> Executive Action Teamのそれぞれに15分という目安を作ることで、議論ではなく問題の確認と決定の場としてショートに実行するものである、という定義が明確で分かりやすい。


問題の起きているプロジェクトでは朝会や、Daily Scrumが議論の場になったり、一方的に司会の人だけが話して終わり、みたいな雰囲気になりがちで、最初から「この状態から外れていると上手く機能していないな?」というベンチマークが分かっていると、問題に気づきやすくなる。

経験が無いと、上手く行っていないことを場当たり的に解決しようとしてしまうのだけど、プロジェクトにおいて問題が”順調に解決されていかない”理由は、たいてい「メンバのプロジェクトへのコミットメントの欠如」か、「タイムリーにコミュニケーションが行われず、意思決定のタイミングが遅れる、間違った情報をもとに意思決定が行われる」ことだったりして、その点に先回りして解説がされているのが上手い。

経験が無い人にとっては、組織間のコミュニケーションが乱れている状態が発生するとどこから手を付けてよいのかが分からなくなるので、内容的な交通整理は当然やるとして、日々のコミュニケーション方法を見直す指針がこうやって示されると、「まずはやってみるか」と考えられる。


この本に書かれているような組織構造や、営みをやったからと言って、問題がすぐに解決するわけではないけど、問題の可視化と、その情報の流通、意思決定をやっていくための型を作ることで、一つ一つの課題によりフォーカスした議論ができるな、と思いましたし、それを定義すること自体がまさに、”組織をつくること”なんだと思います。

人員を配置して、体制図を作れば組織ができるわけじゃないですからね。


追記