Jeff Sutherlandが5年前にやってたAMAを訳しつつ今を考えた その1
スクラムの生みの親、Jeff Sutherlandさんが5年前に自身の本の宣伝も兼ねてAMA（Ask Me Anything=なんか質問ある？）をやってたのでまとめてみます。めちゃめちゃ長いので2分割！
Jeff Sutherland AMA
Q: Jeff！あなたがチームやスクラムマスターをコーチしてきた経験の中で、なかなか伝わらず苦労した点はある？それともう一つ、チームがスクラムやったつもりになってて実は出来てないってパターンはどんなものがある？
A(Jeff): スクラムの本質を理解できたのは唯一Googleぐらい。みんながソフトウェアのコンポーネントアーキテクチャを理解し、ソフトウェアを進化させるのに最小限の変更で済ませられることこそがすべて。長い話になるね。Googleのエンジニアたちは理解できるまで私をレストランの隅で4時間取り囲んでたよ。
スクラムが出来てないパターンは1つしか無い。それはスプリントの終わりに動くソフトウェアができていないこと。50%の「アジャイル」チームはこれができていないね。
Wow Google。まぁこのAMA自体が5年前ですから当時と比べたら理解している人たちは増えているはず。日本国内を見ればアメリカに5年遅れていると言われているのでまだ少数派でしょう。
Q: どんなチームのサイズがスクラムに適してる？
A: ハーバードの研究によると4.6人が最適。Scrum Inc内での経験からいえば5人を超えると色々遅くなってくる。7人で目に見える遅さ。9人では機能しない。
私もスクラムチームのサイズは小さい方が圧倒的に上手く回ると感じます（5人、7人、9人を経験）。特に経験者が少ないうちはPO1 : SM1 : Dev3の5人がオススメ。情報伝達のスピード感やチームビルディングのやり易さが違います。9人では透明性が確保できずチーム内での分断が起きやすかったので慣れたスクラム戦士を揃える必要があるでしょう。
Q: スクラムを作るきっかけとなったことは？
A: 私たちはより速く、より良く、よりいい感じでプロダクトを作りたかった。竹内さんと野中さんはその方法を理解していて、1986年に出した論文New New Product Development Gameで説明していた。彼らがScrumと呼んでいたのでそれを実装したんだ！
New New Product Development Game（＝新たな新製品開発ゲーム）はスクラムの原点です。上のリンクの要約スライドを読めば内容は理解できると思います。原文は英語ですが興味があれば読んでみてください！
Q: 皆が狭く深い能力持ってたほうが良い？それとも広く浅く？
A: ハイパフォーマンスなチームの秘密はT型人材だ。彼らは1つのことに深い理解がありつつ他に2つ担当できるエリアを持ってる。これはキーパーソンが居ない時でも動き続けるため大切なことなんだ。
私が理解してるT型は得意エリア1つ、他は広く浅くでした。広く浅くでも良いですが確かにJeffさんの言う通りある程度自信のある他2つのエリアがあったほうが強いかもしれませんね。それだけできれば他もある程度身につくだろうし。
Q: スクラムはスプリント、スパイク、インピディメントなどの言葉通り、開発者が燃え尽きてしまうようなアクティビティがずっと続くよね。私の経験上、スクラムを採用してるチームは短期で結果を出すことを上から求められるから12～18ヶ月で燃え尽きて会社を離れてしまいR&Dなどに人を回せないことが多い。スクラムを「短期で生産性を出すため、長期のイノベーションを犠牲にする」メソドロジーと呼ぶのは正しい？
A: サステイナブルなペースでの開発はアジャイルマニフェストの重要な原則の一つ。私は何年も離職者ゼロのチームで続けられた経験もあるよ。マネジメント層がアジャイルでないせいでスクラムを使ってチームを働かせてる。興味深い話として、マイクロソフトはこの問題に対して人事評価を変えることで取り組んでいる。真のアジャイルな会社は完全に個人評価をやめてる（例えばGoogle）。
いかにサステイナブル（持続可能）なペースでスクラムを回すかは、スクラムマスターにとって大切な課題です。そして評価の問題はよく議論になりますね。成果は、チームでないと出せない。だからチームとしての成果を最大限にするために個人を評価することはない。言うは易し……実施は難し……
Q: オープンオフィスの動向について何か意見はある？
A: 人々はアジャイルな場所が必要。オープンオフィスは正しくやれば協力の場として機能する。間違ってやれば、結果は散々になるだろう。
スクラムチームは個別の部屋があると、心理的安全性が守られるでしょう。あとは結構喋る機会も多いので、周りに迷惑かけないかも。あとはデイリースクラム開くのが楽になったり、壁に自由に貼ったり、楽しい。
Q: 課題についてフェイス・トゥ・フェイスで話したほうが良い？それともオンラインで話してログ残すことで他の人が学べる方が良い？
A: Scrum Incでは原則フェイス・トゥ・フェイス。よくGoogle Hangoutを使う。電話は避けるし、メールも情報の共有以外では避けるよ。
フェイス・トゥ・フェイスの何が大切って、言葉以外のコンテクストがそのまま伝わることです。チャットだとそういうの伝えるの難しいし、意識してできない人もいるので。ですます調で続くチャットって固く感じません？
Q: 毎日のミーティングって必要？自分がなにやってるのか伝え続けるのってストレスにならない？
A: 慣れたらあまりそう感じないよ。私の妻は教会でスクラムをやってメンバーには毎日参加できない人も居た。週に1回だとしても20%の得があって何もないより良い！デイリースタンドアップはBell Labs（ベル研究所）Borlandチームの報告によればMicrosoftチームの52倍の早さをだしている。そこまでのスピードは毎日のミーティングなしには得られない。
デイリースクラムをストレスに感じたことは、私はあります。理由はやってる理由をチームが見失い、単なる報告会になっていたから。そういう時はなぜチームがデイリースクラムをやってるかの意味を見直しましょう！
Q: スクラムを個人のワークフローに適用することはどう思う？
A: 私はたくさんのTODOを短時間でこなさなくてはいけない時に一人スクラムをよくやるよ。ふせんを壁に貼って優先順位をつけると2倍速く半分の力量でタスクがこなせる。これについては本も書いたよ。
Jeff！これって一人スクラムってよりカンバンでは！？ということでJeffのスクラム本を読んでみたくなり思い個人的にも購入しました。
Q: スクラムを始める時にチーム内に変化を嫌がり意識的にかに関わらずチームの進行を邪魔してくる人がいたらなんて伝える？
A: スクラムチームはスポーツチームと似てる。ボールのパスをしなければ守りにも参加しないメンバーが居たらどうする？ロッカールームで心を通わせようと会話するよね。できればメンバーが、できなければコーチがする。もしそれで変われなければ準備が整うまでベンチで頑張る。ベンチで時間を過ごしすぎればトレードされる。
チームメンバーレベルではこういった動きもやりやすいですが、経営層が変化を嫌がってたら下は変われません。緩やかな死です。変化を促しても変わらなければ自ら移籍先を探すのも手でしょう。
Q: スクラムは開発者、アナリスト、POが地理上離れ離れでもうまくいく？何か良いTipsはある？
A: 私は今まさしく分散型チームに居る。私はボストンだし、ある人はポートランド、ある人はワシントンDCで常にGoogle Hangoutで繋がって一緒に仕事している。
もしこれが上手くできれば、「同じ場所で働くチームは分散してるチームの2倍生産性がある」という問題に打ち勝つことができるよ。このことについては色々書いたから見てね。
どのチームもいきなり分散型でうまくいくわけではありません。チームビルディングが上手く成されてる、あるいはスクラムを理解しているなどの最低条件や、Google Hangoutを始めとしたツールの整備がされた上で始めて機能する分散型チームになると思います。
Q: UXの人間として、より良いソフトウェアを作るためにユーザー・セントリシティ（顧客中心主義）をどうスクラムに組み込めば良いか教えてください。
A: UXはバックログを作るのとチームの開発の両方に必要。以前、医者向けアプリを作った時に、必要な機能を持ったアプリを作るのにはコードの1行目を書き出すより前にUXが欠かせないと感じたよ。ほとんどのチームはレディの定義のためにワイヤーフレームが必要だ。すなわち、UXの人たちは未来のスプリントのための作業と今のスプリントの作業が求められるね。
補足をするなら、UXは最初のプロダクトバックログ(PBL)を揃える段階から必要になる、つまりスクラム開始前からUXデザインは必要です。スクラムを始めるにはアイテムが追加されたPBLがないとね。
Q: ソフトウェア開発の次のステップは何だと思う？
A: 良い質問だね。次のステップは継続的デプロイメント(Continuous Deployment)。ストーリーが完了したら即ライブ環境に反映される。それも1スプリントに何百回も。
今はアジャイルはCI/CDとセットで語られることも当たり前ですよね。5年前はまだ進んでなかったのでしょうか？ミッションにもよりますが、チームで最初にCI/CDの環境を作ることはかなり大切です。
Q: やぁJeff、スクラムの仕組みと生産性は理解できてる。スクラムチームの文化的な話をしてくれないかい？
A: スクラムチームの文化は、ハイパフォーマンスなスポーツチームのように、チームがそれに対して取り組むことで進化していく。最初のスクラムチームはラグビーが好きでAll Blacks（ニュージーランド代表）のスクラムのビデオをよく流していたよ。彼らと自分たちの違いは何か考えると、完全に集中しているかの違いだった。全員で腕をつなぎ、道の上にあるすべての邪魔なものはぶっ潰す。誰か一人がラインを超え得点を決めればチーム全体で熱狂的に喜ぶ。最初のスクラムチームのメンバーが「このチームでの経験は私の人生を変えたし、残りの人生も同じ経験を繰り返し探し続ける」と人に伝えていた。そのチームが会社ごと買われて分裂するときにはたくさんの涙が流れたよ。
大切なのは、良いチームで仕事をすることなのです。そのためにスクラムマスターはなすべきことをなす。
Q: グッドプラクティスをまとめた教科書を作ることはいいこと？それとも各自で自分たちのやり方をみつけてく進め方の方が良い？
A: 「教科書」がベストな例えではないかもだけど、私たちはScrum Inc.でScrum Labという形式で過去21年の中から何がベストだったかを提供しようとしている。私の今日発売の本では誰もが（ソフトウェア開発者に限らず）スクラムを可能にしチームをより良くするためのキーポイントを理解できるように書いているよ。
現在、Scrum Labははさまざまなコンテンツが提供されているので見てみるのはオススメです（ただし英語）。私もこういうコンテンツ増やしてアジャイルYoutuberやってみるか？笑
Q: 戦闘機のパイロットになろうと思った理由はある？（補足：Jeffは戦闘機パイロットとしてのキャリアがあります）
A: 興味深い質問だね。私が学校を卒業した時、レンジャーになる道かパイロットになる道かがあった。レンジャーのトレーニングは1週間睡眠も取れず空腹を耐える中、パイロットは柔らかいベッドと毎晩バーでビールが飲める。決断するのは簡単だったよ（ただし実際パイロットはリスクが高いし、その忠告は受けてた）。
Jeffさんは戦闘機のパイロットとしてベトナム戦争にも従事し、生死を分かつ状況判断が求められる経験をされています。その時からOODAループなどの思考法に触れており、それがスクラムのエッセンスになっているのでしょう（つーかOODAループがそもそも米空軍の大佐が考案したものって知らなかった！！！Wikipedia参照）
Q: オープンスペースはスクラムに適していますか？オープンスペースの騒音は開発チームを邪魔しません？
A: アジャイルなスペースはチームがフェイス・トゥ・フェイスでチーム外のノイズから邪魔されずに会話できるエリア。PatientKeeper社でうまくいったスクラムでは開発者一人ひとりに区切られた専用スペースがあったけど使ってなかった。彼らは会議室を占拠してお互いが見える一で作業して、他の人に邪魔されないようにしてた。
働く場所問題ですね。PatientKeeper社の例は専用スペースがあってもそれを使わないことをチームが選択したというのがポイントです。チームは、そちらの方がより良いと感じたということ。大事なのはフルオープンではなくチーム内でオープンであること。
Q: フリーランスで開発者してて自分のワークフロー効率化のためにスクラムを覗いてる。グループとかチームのコンセプトを一人開発に落とし込むにあたって助言はある？
あと、100匹のアヒルサイズの馬か1匹の馬サイズのアヒル、戦うならどっち？
A: 1匹にターゲットを絞れるから巨大なアヒルかな。
グループやチームのコンセプトは個人向けに変換できる。当然あなたはプロダクトオーナーであり、スクラムマスターであり、開発者でもありオールインワンのチームだ。ただし彼らの機能は独立していて、POはバックログを正しくメンテし、SMは障害を取り除き、それでやっと2倍の成果を半分の仕事量で達成できる。
タイトルの話になるのですが、日本版の本は「仕事が4倍速くなる」と訳されていますが、原題は「The Art of Doing Twice the Work in Half the Time」です。訳せば「2倍の成果を半分の時間」では数学的にみればまぁ「4倍速くなる」は正しいんですが、ニュアンスが違うし4倍速くなるって言いたいならJeffさんが4倍速くなるって書くと思うんですよ。
***
UXやCI/CDとの関わりも言及されてて興味深いですねー。Scrum Inc.のScrum Labについては見たことなかったので今度覗いてみようかなと思います。また良いナレッジが見つかったら掲載しますね。次の記事もよければ読んでみてください。
では、良いアジャイルライフを！
いいなと思ったら応援しよう！
