Jeff Sutherlandが5年前にやってたAMAを訳しつつ今を考えた その3
お待たせしました、その3かつファイナルです！Jeffと愉快な仲間たちの受け答えを見ていきましょう。（その1、その2）
Jeff Sutherland AMA Part.3
Q: 今度スクラムを使っている会社に転職するんだ。そこではシステムアドミニストレータを任命されたんだけど、スクラムは自分にとって始めての経験になる。何か役割についてのアドバイスはある？
A: システムアドミニストレータとして、あなたはどんなチームにいてそのチームはどんなスキルセットをもっているんだい？
スクラムでは、君が助けを必要としているなら皆が助ける必要があるし、君も皆を助ける必要があるよ。
ご存知の方も多いでしょうが「システムアドミニストレータ」というロールはスクラムにはないので、この人がどういったコンテキストでその役割を果たすことを求められているかが大事ですね。なのでJeffさんは最初に質問しているのだろうと思いました。
Q: スクラムとカンバンの最大の違いはなんだと感じる？
A: カンバンは仕事を可視化し、着手中のタスクを最小限の抑え、サイクルタイムが計測できる。スクラムはそれにPO、SM、チーム、そしてスプリントを加えたものだ。
ハイパープロダクティブ（超生産的）なカンバンはチームとチームリーダー、そしてバックログを管理する人が居ないと実現できない。チームが速くなるほどスクラムっぽくなる（これについてはHenrik Knibergの本を読んでみて）。
逆に言えば、良いスクラムチームは継続的に開発を進めていくとカンバンそのものみたいになる。2005年にPatientKeeperに居た時このことについて書いたけど、皆がこれはスクラムじゃないと言っていた。Ken Schwaberですらそれが何か解らないけど今まで見た中で最速の働き方だと言っていたよ。
サポート部隊やコールセンターなどには私がすべてのスクラムチームで使う「割り込みパターン」を使うよう教えている。彼らのチケットシステムはバッファ（最大90％）であり、残りはすべてプロセス改善に捧げる。それにスクラムの役割とミーティングを加えることで私の投資したグループはコールセンターの生産性を400％アップさせてたよ。まさに良いソフトウェア開発チームのようにね。
Jeffさんの1行目が全てですかね。スクラムとカンバンの境界線が分からなくなるみたいな話は自分はまだ見えてない境地です……割り込みパターン(Interrupt Pattern)は、プロセス改善のために10%割くということですがチームで合意取ってやるのは良さそう。ちなみにスクラムガイドではカンバン必須とは書いていません。ですが、見た目にも分かりやすいので採用しているチームは多いですね。
Q: Scaled Agile Framework (SAFe)についてどう見てる？
A: Scrum Incはスケールするためのフレームワークについてオンラインコースを提供している。「どれだけ予測可能か」vs「どれかでイノベイティブか」によりそれぞれの企業はそれぞれのゴールを設定している。Spotifyのような新興のプロダクトであればSAFeは全体をスケールさせるためのオーバーヘッドがあるため避けるだろう。巨大な軍事産業で、今までのマネジメント方法を使い続けてるところにとってSAFeは最良のスタート地点となるかもしれない。だからコンテキストによるし、それぞれの会社はそれぞれのスケールする道があるよ。
Spotifyみたいに自分たちの方法でアジャイルをスケールするマインドセットがあるならSAFeはいらないでしょう。ウォーターフォールしかやったこと無い、アジャイルをやってるけど上手くいってない、みたいな企業であればSAFeのように豊富なガイダンスのあるフレームワークがピッタリだと思います。そういう意味では日本国内の会社とも親和性が高いと感じています（ただし、上層部に働きかけられることは前提ですが）。
Q: Six Sigmaの門徒から脅迫受けてる？
A: ドイツのハードウェア企業からSix Sigmaやってるチームが丸々スクラムコースを受けに来たことがある。彼らはスクラムを始めてから、半年でその前の3年間より多くのSix Sigmaを実践できたと言ってたよ。スクラムがあることでSix Sigmaは倍の成果を半分の時間で出せたってことさ。
質問者はSix Sigmaと一悶着あったんですかね？笑 1つのプロセスやフレームワークが絶対とは思わず、お互いの良いところを吸収して成長することがアジャイルの本質だと思います。どんな世界でも一つのやり方や考え方に固執することは成長の放棄なので気をつけましょう。
Q: Dilbert（アメリカの技術者コミック）は読んでる？一番好きなやつは？
A: Dilbertは現代の企業内における作業環境がいかに悪いかを良く表してる。だからこそ私たちは新しい本でなぜ人々は仕事が嫌いになるのかとなぜ非人間的かつモチベーションを下げるのかという議論をしている。スクラムはこれらを正すためにデザインされた。
Dilbertはに日本語訳版もある！今回調べて初めて知りました😂アメリカンジョーク的に皮肉に溢れてIT業界のツラミを面白く描いているので見てみてください。ディスカッションのネタにするのもアリだと思います。このDilbertをスクラムやアジャイルの文脈で考えるとどう良く出来る？みたいなね。
Q: 企業はどうスクラムを間違った方法で使ったり適用したりする？
A: 質問を見ればよく分かるようにスクラムはよく非難される。管理者はタイムシートを使い開発者を罰する。Thoughtworks のコンテストに出た「開発者いじめ」のビデオを見てみて。
仕事を良くしたいがために、色々やろうとしてるのにバカにされ無視される、というビデオでした。今でこそスクラムは浸透していますが、スクラムを知らずに「ストーリーポイント」なんて言葉だけで聞いたらおとぎ話のはなししてる場合じゃないんだよ、みたいに思われるかも。それってスクラムに限らず新しい技術とか流行る前のプロセスに飛びつくイノベーターたちに対して冷ややかな視線を送ることと同じ虚しさを感じるべきなんでしょう。
Q: AMAやってくれてありがとう！私たちは６年間スクラムをいくつかのPJでやってきた。認定スクラムマスターも何人かいる。そんな中で直面してきた問題の一つに、人員が変わり続けることがある。どうやって変わり続ける人員と共同作業すればいいんだろう。チームが次の大きなリリースを迎えるまで人員追加をしないか、スプリントの都邑でも新たな人を追加して素早くキャッチアップしてくれることを祈るか、どっちが良いと思う？
A: Scrum Incでは新たなメンバーはスピードに乗ることを難しく感じていない。まず飛び入りでも参加して、プロセスを共にする。どうやって進めれば良いかわからない時はチームの誰かとペアになって進める。
最初からペアプロ・モブプロやるのもありだと思います。特にチームのやり方とか技術的な差がある時はなおさら。暗黙知の共有にはペアプロはかなり有効です。
Q: Jeffこれやってくれてありがとう。私は以前スクラムを本来の目的ではなく、従業員のパフォーマンスの監視と管理のために使ってる会社に居た。プロジェクトで完了したタスクとかかった時間を追跡し、時間の見積もりを重要視し見積もり以上にかかることを受け入れなかった。当然これはスクラムの意図と違うとおもてるんだけど、スクラムは本来どうやってこういった悪用を防ぐ？
A: 2006年から時間管理はやめるよう教えている。時間管理は不正確な見積もりを生み、時間を出すのにも時間がかかり、チームを遅くする。それを使う管理者は良くない管理者だけどちまたにはいっぱいいる。おそらく彼らは個人評価も利用してるはずだ。simplyhired.comで見たけど、いま521,206のスクラムに関する仕事がある。そんな会社のために働いているなら、辞めてホンモノの仕事を探そう。プログラマーが自分を売り出せるhired.comにいって企業に値付けしてもらうのも良い。
アメリカの労働者の流動性は、企業の競争力にどう影響するんでしょうね。まぁ国を問わずブラックであったり単純に合わない会社だと思ったら転職すればよいのです。スクラムもたくさん仕事があるよ、とJeffはアピールしてます。国内でもSIerレベルでも私は途切れること無くスクラムの仕事できてるので（上司と営業のおかげもあり）そこそこ需要あるな、と感じてます。
Q: スクラムマスターが持つべき一番の特性は何（スクラムの原則を理解しているという前提で）？教える能力なのか、コミュニケーション能力か、そもそもまったく違うなにか？
A: スクラムマスターが必要なスキルはこのビデオで示されてる。女性が通りがかり、小さなプロセスのカイゼンをわずか2分ほどで行う。壊れたものを見つける目とそれを直すためのチームへのコーチングが良いスクラムマスターへの鍵だ。
非常に印象的なビデオですね。Change your words, change your world. 言葉という他人へ働きかけるためのプロセスを少しカイゼンするだけで変化を起こせる。
Q: 自分のチームでよく論点になるのは、スプリントで何を追跡して何を追跡しないか。自分たちが今追跡しているのはプロジェクトで実際に届けるもの。以下みたいな感じ：
【追跡している】
・コード、ユニットテスト
・設計のディスカッション/ドキュメント作成
・スケジュール外のデプロイ
【追跡してない】
・コードレビュー（レビュアーが長時間束縛されることもある）
・QAで発見された新機能のバグ対応
・月次のデプロイ（些細な仕事）
・作業者以外のミーティング参加者
・横槍で入る作業（生産性に大きく影響することも）
・プロダクトオーナーとマネージャーのフィードバック
A: Scrum Incではポイントや追加の仕事が必要になることはすべて追跡している。個人的に、ポイントが与えられない仕事はやらないようにしているよ。誰もがバックログに書いてないことはすべきでない。Scrum Incは自己管理型で、チームベースのボーナスをチームは自分たちで作っていくので集中する必要がある。
どこまで数値を追跡するかはなかなか難しい問題ではあります。ポイントとしては、各数値を追跡するためにできるだけ労力を割かなくて良い仕組みを持つことです。その上で数値を拾って意味あるなしを見極めるでも良いと思います。
Q: ハードウェアの設計にスクラムを導入するのに何かTipsはある？ソフトウェアの問題を解決する為のものだとは知ってるけど、ハードウェアの設計にも使えるよう翻訳する試みがあった？
A: Joe Justiceが世界的なハードワイヤプラクティスを運営している。彼は空き時間でWikispeedという十数ヶ国の何百人もの参加者が1週間スプリントでオープンソースの車を作る活動をしている。ここでカギとなるのは、コンポーネント志向のアーキテクチャにし週単位で他のコンポーネントに影響を与えずコンポーネントのアップグレードを可能にすることだ。車はフリーウェイを毎週スプリントレビューで実際に走るんだよ！
ほとんどのハードウェア企業は車よりシンプルなプロダクトを製造している。農業機器のJohn Deereは700～800%の生産性改善を実現した。SAABやSpaceXのようなアジャイルな企業は戦闘機やロケットを高い品質を保ちつつ20%のコストで実現した。
スクラムは野中さんと竹内さんが研究したトヨタのリーン生産方式をベースにしていて、それはハードウェアのために考えられている。私たちがソフトウェアに適応しただけで、私たちはそれを改善できたのでソフトウェアで得たインサイトをハードウェアに返している。
Wikispeedすごいですね！公式HP見ると実際に公道走っているカスタム感溢れる車の動画が見れます。コンポーネント志向のアーキテクチャによる柔軟な作りはソフトウェア・ハードウェアに関わらず有用な考え方であることの実例です。
Q: スクラムは理論上は不完全にみえるけど実践すればすごい上手くいくタイプのアイデアに見えるね。理論時点で止まってる人を実践に引き込むためになんと伝える？
A: スクラムは竹内さんと野中さんがトヨタやホンダやその他企業のリーンプロダクト開発で見たものをベースにしている。正しくやれば4倍の生産性と12倍の質の向上が望める。これはメソドロジーと言うよりは武道（マーシャルアーツ）だ。武道では練習に練習を重ねる。理論は実践する前は役に立たない。実践してようやく何故自分が勝てるかの理論について熟考すれば良いよ。
Done is better than perfect だし、Just do itって感じです。とりあえず行動して終わらせる。これを繰り返すことで武術を身につけるが如くスクラムを体得できるわけです。体得していく中でカイゼンループを回すことで高みを目指す。なので、とりあえず理論で止まってる人を引き込むには圧倒的な成長を見せつけるか、その人を巻き込める範囲でスクラムを始めるしかないです。
Q: やぁJeff, スクラムマスターを認定してくれる団体がいくつかある。その中でどの団体が一番だと思う？もしくは認定証はただの紙でしかない？
A: Scrum AllianceとScrum.orgは先週、Scrum Incの補助とともにスクラムガイドこそが認定の基準であるべきだと合意した。それ以外はすべて派生でお金を稼ぎたい人や関係ない人が作ったものだ。scrumguides.orgを見てね。
認定に価値があるか？まぁ認定そのものが君を偉大なスクラムマスターにするわけではないよ。ただ、私が話す企業は基本のトレーニングを受けた人が欲しくてイチから教育するのは大変だと言っている。あと私の経験から言えば認定は運転免許証の役割に似てる。もしあなたの娘が運転免許証を今日取って、あなたのBMWの新車を乗り回すとして、良いドライバーか悪いドライバーになるか分からないけど、ひとつだけ確かなのは、彼女が色々問題を起こす可能性があるライセンスを持ってるってこと。
私もScrum Allianceの認定自体は誰でも取れる運転免許証と大差ないという考えです。CSM取得はスタートラインでしかなくて、取った上で実践を始めるということが大切です。CSMは先生によってスタンスが違うのが良くないですね。持っててあれですがスキルレベルを表す資格として機能してないです。そのためにはA-CSMとかがもっと推進されるといいんですが国内ではクラス自体がないですね。
Q: やぁJeff、私たちは10年目の企業で夏からスクラムに変えたばかりだよ。ご想像どおり、まだ適応の途中で、2つ質問がある：
1. 気になってる点として、現在スクラムマスターをやってる開発者が本当にコーディングではないことをやりたがってるのか。スクラムマスターの役割に適した人を見つけてくるのにアドバイスはある？
2. 組織が育ちスクラムチームが増えるにつれスプリントレビューをどうスケールすれば良い？まだ始めて2ヶ月だけどもうやりづらさを感じている。
A: 兼任スクラムマスターをやってもらうことは多いよ。最初は半分スクラムマスターで半分コーディング。チームが良くなってくればスクラムマスターはよりコーディングに時間が割ける。
スケールのためには、スプリントレビュー以外の全イベントを個別チームでやる方法を取っている。チーム数が多くなってレビューが正しく行われるようにするには7±2のチーム数で取り組むと良い（5以下がおすすめ）。
SMと開発者の兼任はどうなんですかねー。スクラム経験浅いチームだと、とくにスクラムマスターとしての役割がおろそかになってしまうことが多いと思いました。結果プロセスやカイゼンがおざなりになるならスクラムやる意味はないですね。
Q: なんでニワトリは道路を渡ったんだと思う？（訳注：相手に考えさせた挙げ句「反対側に行きたかった」という当たり前の返しをする高度なジョーク）
A: えーと、ニワトリはブタに「レストランを始めない？」と聞いた。ブタは「なんて名前にする？」と返した。ニワトリが「ハム・アンド・エッグス」と言うと、ブタは「それはダメだ。君は関わるだけだけど、僕は身を捧げねばならない」と言った。
これは私の新しいスクラムの本に書いてあるよ！
Q: ごめん、違うAMAに書くつもりだった
この質問を書いた人のHNが"SexyOmlet（セクシーなオムレツ）"ってのも含めてついたひどいオチでした……笑
***
以上、全3パート合わせて翻訳した文章含めて1万5千文字の重量級AMAでした。そうだよねーって共感できる話から、そうなんだ！ってなる盲点的な話もあったので自分のためにもなりましたね。全部読んでくださった方、お疲れさまでした。あとはScrum Incの他の資料が存在することも知れたので、いいキッカケでしたね。またその資料も絡めて発信できればと思います。
では、良いアジャイルライフを！
いいなと思ったら応援しよう！
