スクラムは属人性を排除しない？？

今朝書いた、下記記事の続きです。 bonotake.hatenablog.com

一旦は「Facebookで議論すんのしんどいから」という理由でやり取りを打ち切ったはずでしたが、この記事に対してアジャイルコーチの守田さんが「SCRUM BOOT CAMP THE BOOKをお読みなら話が早い」と仰って、結局その後もFB上にて守田さんとやり取りしてました。

結構長々とやり取りしたんですが適当にまとめます。

前回記事のざっくりした要約一部切り抜き

Scrum*1で「チーム内の属人性は排除する」と考えるのは誤りらしい。本当？

守田さんのたとえ

従来型：バッチ処理の担当者に必要なスキルと、バッチ処理技術ルールをドキュメント化して、属人性を排除する。

アジャイル：バッチ処理をペア作業などで実施して、誰かもう1、2人くらいは分かるようにする。

よくある誤解：アジャイルだから、チーム全員がバッチ処理を書けるようになるべき。

要は、各メンバーが多能工化するのはするんだけど、エクストリームに何でもできるようになる訳じゃないと。 ある程度はスキルを共有して、共有できた範囲で属人性を排除するということのようです。

トラックナンバー

blog.fenrir-inc.com 「ある日突然トラックに轢かれてもプロジェクトが停止しないメンバーの数」らしい。（後述する同僚のEは初めて知ってめっちゃウケてました。） 僕はとっさに「トラック転生するから何人でも大丈夫では」とか考えてしまい（ｒｙ

トラックナンバーは当然1だとまずくて、ただ2, 3確保すればとりあえずはOK、なんでしょうか？ 言い換えれば「1人の人が2,3のスキルを身につけるって感じ」だと。

この程々感がまぁ、アジャイルっぽいっちゃ、アジャイルっぽい（小並感）

スキルマップ

www.ryuzee.com

似たようなものは BOOT CAMP本でも登場してました。

なので、「チーム内の全員が同じスキルを持つ」という前提はないし、「属人性の排除」でなく「スーパーエンジニアを評価して、その人から学ぶ事で、チームの能力を向上させる」と捉えるべきである、と。

閑話休題：Regional Scrum Gathering Tokyo 2018

2018.scrumgatheringtokyo.org

今日たまたま、このイベントで「Scrumと属人性」にまつわるセッションがあったそうで。

チェックしてた守田さんによると 「とことん掘り下げた尖った人を集めて、ポートフォリオで（必要なスキルを）揃える。そうでないと、今時の次々に新しい技術やフレームワークがでてくる状況に対応できない。」という話だったようです。ふむ、見事に今回の話題につながっておる。

同僚のスクラムマスターE登場

とまぁ、基本守田さんが色々と解説してくれ、まぁ肯けるところは肯けるし、ふむふむと僕がもっぱら聞き役になっていた感じではあったんですが。

ここでふと、会社で隣に座ってる同僚のEにこの話を振ってみました。というのも彼、前職ではずっとScrumで開発を回しており、その経験から、来月からの我がチームでおそらくスクラムマスターを勤めることになるだろう人物だったからです。

拙い英語で*2「チーム内の属人性とかスキルの偏りとか、どう考えるべきなの？」と聞くと、

「traditionalな*3Scrumでは、チーム全員同じスキルを持つって考えるのが基本だよ」

うぉーい話がひっくり返っとるやないかーい！

Eによれば、チーム内の各人のスキルの持ち方は”T-shape”であるべき、なんだそう。つまり1点では深い専門知識を有する（かもしれない）けど、その他のスキルについても広く浅く有しているべき、だと。

あれー話がおかしくなったぞ、と思いつつも。 ふとこのとき、以前職場でScrum導入するかどうか皆で話し合ったときの話を思い出したんですよ。

そのとき別の同僚が「チーム内で各人が持ってるスキルも熟練度もバラバラなのに、どうやってチームのベロシティ*4を評価できるの？同じタスクでもAさんがやるのとBさんがやるのとで速さ違わない？」と質問して、それに対するEの回答が「Scrumではみんな同じスキルを持つと考える」だったんです。

これこそ、僕が「チーム内全員同じスキル」が非現実的だと思いつつ納得した瞬間だったんですよね。彼の説明は筋が通ってる。非合理だけど。

てか、そう考えないと「ベロシティ」って概念こそが非合理になってしまう。

守田さんの反論と旧友N

一応Eが話したことも、かいつまんでFBに書いたんですが、守田さんの反応は

誤解と思われます。

まぁ、話食い違ってますもんね、明らかに。

その後も色々なんで「誤解」か説明してもらったけど、ここではざっくり省略。

僕は結局、2つの「正解」の前にわからなくなってしまった、というのが正直なところで。 守田さんとは、そのうちEも入れて一緒に議論＆情報交換しましょう、といった感じで話は終わったんですけども。

晩になって、ふらりと旧友のNがそのスレッドに現れ、こんな書き込みを残していきました。

N おそらく言うまでもなく、「チーム全員全知全能」が理想形で、その場合当然属人性は排除されてて、現実そこに至らないときに、個々人の能力を広げてカバレッジを上げるのか、マニュアル化でスキルがなくても出来るようにするのか、業務をスキルがなくても出来る範囲で設計するのか、アプローチが違うだけなんでしょう。実際にはどのアプローチも程よく必要だと思いますが。

何やらうまいことまとめおって。

結局N的視点から言えば、（前回の記事の話に立ち戻って）アジャイルも伝統的WFも、「アプローチの差」でしかないと。 アジャイル信者でも否定論者でもない僕からすれば、この立ち位置が一番バランス取れてて腑に落ちる感はありました。

まぁやっぱ、Scrumは一見シンプルなようでいて、奥が深いというか底が知れないというか。イマイチまだ疑問は残ったままではありますが、そのうち「やればわかる」的境地に達する……といいな、とは思っています。

【追記】 西尾泰和さんが僕の前回の記事の記事を読んでくれて、以下みたいな記事を書いてくれました。 scrapbox.io 「二種類」とも、Nの言及した「アプローチ」に含まれていますね。

【追記おわり】

*1:見出しにはカタカナで「スクラム」としましたが、どうも個人的にはScrumと書くのが好み（というかカタカナ書きがイマイチ好きじゃない）ので本文はScrumです。でもスクラムマスターは「スクラムマスター」です。統一感なくてすいません。

*2:彼は東欧人で、うちの会社に来るまではずっと英国で働いてました。なので彼とは基本英語でやりとりしてます。「属人性」とか訳すのめっちゃ辛かった。

*3:彼は結構、Scrumの亜流というか派生版というか、そういうものにも色々詳しいようなのです。

*4:スプリントごとにチームがこなせる仕事量のこと。間違ってたらスイマセン。正確な定義はちゃんとScrum知ってる人の書いたものに譲ります。適当にググってくだせい。