tuneの日記

アジャイル開発、組織変革、マネージメント、ファシリテーションについて学んだことの記録

Scaled Agile with Jim Coplien に行ってきました

f:id:tune:20191208125056j:plain

はじめに

TACO(Tokyo Agile COmmunity)主催の勉強会に行ってきました。

taco.connpass.com

すでにまとめてくださった方もいますが、自分の言葉でまとめ直しておくことが大事かと思い、当日のメモを整理してみました。

Coplien氏の講演内容

"Scaled Agile"の勉強会なので、最初に参加者の取り組み状況を挙手で聞いていました。

  • 1チームスクラム:会場の1/3〜1/2ぐらい→20〜30人ぐらいかな?
  • LeSS:私を入れて2名だったはず。CopeはLeSS嫌いだったがLeSS考案者に"convinced"されたと言っていました。
  • SAFe:何人か手を挙げていたのかも。Cope曰く"SAFeはアジャイルでない"
  • Scrum@Scale:10人位か、ここ最近醸し出している「オフィシャル感」から広まっている印象。

次にCopeは「なぜスケール」を考えなければならないかについて疑問を投げかけました。 「作りたいものがたくさんあるから」というのは良く聞く理由の一つですが、人々は大きなプロダクトになるほどその使い方を知りません。 作った機能の大半が使われていないというのはソフトウェアエンジニアであれば一度は聞いたことがある話だと思います。 また開発員が増えるとプロダクトはその分良くなるのでしょうか? Coplien氏はSkypeを例に挙げていましたが、増えたエンジニアの数に見合う価値が上がったかと言うと疑問に思う方が多いでしょう。 ソフトウェア開発は1人のエンジニアがレバレッジを効かせてアウトプットを出すことができる業種です。 それなのに何故カイゼンを続けたり、スケールを考える必要があるのでしょうか?

スケールさせるとコミュニケーションコストが生じることは明らかです。 「組織の構成員が増えたからコミュニケーションコストを抑えて生産性を上げなければならない」と言う理屈もあるかもしれません。 しかしある調査結果では組織のアウトプットは構成員の人数に比例していたそうです。 したがって「組織の構成員が増えたからコミュニケーションコストを抑えて生産性を上げなければならない」と言う課題は実は存在しないことになります。

ジェフ・サザーランドはScrum@Scaleをフラクタルに設計しましたが、チームの代表者を介してコミュニケーションを行うやり方は軍隊のやり方に似ています。 5名チームのScrum@Scaleを4階層で組むと625人が参加することになり、チーム同士が会話するのに必要なコミュニケーションパスは平均7.6人となるそうです。 世界中の人と6人介すれば繋がることができる六次の隔たりという理論もあるのに、組織内で7.6人を介するコミュニケーション設計はどこかおかしいのではないでしょうか。

ではこのような環境で人はどう問題を解決するかと言うと、ハブを作り特定の誰か・専門家を介して短く繋がります。 Spotifyモデルだとギルド、LeSSだとコミュニティがこれに当たると思います。

ハブがあることでコミュニケーションが最適化できます。 限られた人がたくさんの人と繋がり、ハブとなっている構成をスケールフリーネットワークと呼びます。 Coplien氏はスケーフリーネットワークの例として学術論文を挙げていました。確かに多くの論文が限られた数の論文を引用しており、その形はスケーフルリーネットワークと言えます。 ハブがあることでコミュニケーションがやりやすくなり、フィードバックをすぐにもらえることからアジャイルに物事を進められるようになります。 マネージャーやアーキテクトといった役割は組織の自然なハブになります。 しかしアジャイルな開発を目指し、上記の役割を人から取り上げてしまうとハブが消え、フィードバックを得る機会が失われてしまいます。

やり方をカイゼンしていくには自らの常識に従うことが重要です。 「Scrum@Scaleでこう決められているから」、「集まるのは大変だからハブをツール化(例えばConfluence)しよう」としてはいけません。

Coplien氏は講演の最後をこの言葉で締め括りました。

Small is beautiful

おわりに

終わってからも色々と考えさせられる講演でした。 「スケールは基本的に良くないこと」という前提に対し、プロダクトが大きいからチームを大きくしなければならないと質問した人方がいましたが、Coplien氏はこれに「リリースしたらユーザーをよく観察しろ」と回答していました。短絡的に人員を増やして対応するのではなく、ユーザーを良く観察し、何が価値を提供するのかを良く見極め、そしてそこに注力する。小さく開発を続けることにいつか限界が来ると思うのですが、それでも自らの常識に照らし合わせて考え、シンプルなやり方を追求していく必要がある。私にはそんなメッセージに受け取れました。