概要

James O. Coplienさんと川口さんの認定スクラムマスター研修に参加しました。自分は、スクラムマスター歴4ヶ月程度で、基本的なセレモニーのやり方を理解をしていたのですが、基礎的な考え方の部分が不足していました。他のスクラムマスター研修に参加した記録に乗っていないようなスクラムができるまでの歴史や、スクラムマスターとしてのマインドで大切な部分等、あまり本に書いていない内容についてメモを残します。

ありがたいことに、前回のワークショップの記事をCorp先生が紹介してくださっていました。 f:id:sanryuu:20151102181835p:plain

まとめている項目はこんな感じです。ご興味のあるものをどうぞ。

朝会の目的
スクラムで大切なこと
改善するためには
スクラムの心構え
スクラムマスター研修がなぜ必要なのか
どうして高い頻度でやらないといけないのか
残作業の測り方
予定がどのくらい守られているか
プロセスやツールではなく個人との対話
コミュニケーションの頻度
アジャイルの源流
トヨタ・モーターのマニファクチャリング
バグは即直す
トヨタのカイゼン
自己組織化の仕組み
バグをトラッキングしない
未来予測に気をつけろ
アジャイルとリーン
全員がリーダーシップを
他のチームからメンバーが来たとき
スクラムマスター
各ロールの兼務
顧客
障害物リスト
タイムボックス化
プロダクトオーナー
コミット
スクラムとチームワーク
リモートワークに対する他社の話
守破離
担当ではなく求められること
新しいことを学びましょう
フィードバック
リクルーティング
責任
チームを子供扱いしない
チームがスプリントを達成できない場合
発生しそうなでなく発生した問題について話す
チームの学びを促進する
スクラムマスターはワーカーホリック
スクラムマスターに権限はない例外
タスクは絶対見積りか相対見積りか
リリースバーンダウン
カイゼンの確認
チェックとテスト
単体テストがROIにどう影響するか
技術的負債とリファクタリング

内容

朝会の目的

最初に朝会をどうしてやっているかの理由に対する質問があった。多くの参加者が「進捗の情報共有」との回答をして、不正解と言われていた。

本当の朝会の目的は、作業内容の共有会ではなく、今スプリントの作戦会議。なので、15分かけて現状を共有するのではない。 1人あたり1分程度で「やったこと」「やること」「困っていること」を共有し、残りの時間で、どうやったら今スプリントを成功させられるか考える。子供の体調が悪くて早退する人がいるかもしれない。それをどうやったらフォローできるのか、みんなで考える。

関係ない話と思うものが長ければ、関係ないと思う人がダレてくる。なので、オープンにビジュアライズしてください。終わってないなら、課題について確認する。チーム全員で、どうやって解決するか話すための時間を作りましょう。

スクラムで大切なこと

スクラムで大切なのは、2つ。「カイゼンの心」と「見える化する仕組み」失敗したのは良いこと。物事を見える化するのが真髄で、見えるかするからこそ失敗を発見できる。

改善するためには

約束をしたことを守れなかったら反省する。反省なければ、改善はない。そして、どうしてできなかったかを考える。原因の障害をとりのぞくことができれば改善できる。障害は躓く原因を取り除いて改善する。

スクラムの心構え

スクラム上にマネージャはいません。テストが必要なら自分でします。やりかたが分からなければ自分で勉強します。みんなで1つの心を持って挑む。

スクラムマスター研修がなぜ必要なのか

スクラムって、3つのロール、4つの儀式、3つの成果物で説明できるのにどうしてスクラム研修が必要なのか。スクラムは、説明するのは簡単だけど実行するのは難しい。実行する上での課題と元になっている理論を理解してほしい。そうすると、実践できるようになる。

どうして高い頻度でやらないといけないのか

短い間隔でお客さんに渡すことで間違えた方向に進むことを防ぎやすくなるから。

残作業の測り方

バーンダウンチャートでどれくらいの仕事が残っているか、どうやって測るか。くまのグミで図ってください。時間で測らないでください。みなさんは、8時間はたらいているのですか？純粋に8時間やっているのでしょうか。時間を元に決めているのは、馬鹿げている。

2週間のスプリントで、これだけの作業をしないといけない。

1スプリントでどのくらいのグミを実行できているのか。これは確率なので差異があるものである。複雑なものだと20％の誤差があるのではないか。

予定がどのくらい守られているか

3ヶ月以上先の予定の納期に70％が間にあっているのであれば、それはテストを伴わないものか、技術的負債を負っているものである。それでは会社が潰れてしまうので上司を教育してください。

プロセスやツールではなく個人との対話

プロセスやツールではなく個人との対話が大切です。 JIRAは使わないでください。問題を見える化するのは、向いてない。 JIRAに入れるとコミュニケーションせずに、JIRAにバグを入力しなくなってしまう。書物に収めるのではなく、ソフトウェアを作るのです。

コミュニケーションの頻度

毎日エンドユーザから話を聞いて話をすることが必要です。 JUnitの緑のバーを増やした所でエンドユーザの満足には継がっていません。それはアジャイルではない。

アジャイルの源流

全員が自分の専門に特化して生産し続けても、生産量の多いところは在庫になってしまう。仕掛り在庫が生れる。使えない部品が生産されたとき、気付けるのはいつか。発覚するのは、在庫を全部使い切って問題があったとき。

組立てラインがあるのではなく、みんなで協力して1つの製品を作って完了させていく。これが一個流し」と言われる生産方式。スクラムチームは。1つの要件だけに集中して作り上げる。 1つのユーザストーリーを全員で扱う。

トヨタ・モーターのマニファクチャリング

コミュニティ及び米国の経済成長に貢献する
チームメンバーを安定と幸福に貢献する
お客様への価値の提供を通じてトヨタ全体の成長へ貢献する

後の説明でも、この3つを使って説明していた。順番が大切なので覚えておく。

バグは即直す

スクラムでは受け渡しをしないようにしている。スクラムではバグのトラッキングはせずにすぐに直す。それが最優先今やっているものを全て中止して行う。それは、過去のリリースが終わってないってことだから。

4時間たってもバグを修正できない場合には、POにもビジネス側にも確認する。お客さんに出すタイミングを業務側で対応すること。

トヨタのカイゼン

ゼネラルモーターズは、非常に厳しい時期にトヨタにお願いしてコンサルをしてもらった。ゼネラルモーターズは、各工程ごとの機械が離れていて、カートで運んで次の工程に移動させていた。トヨタの人がゼネラルモーターズに、機械を近づけてくれと言っても移動させてもらえなかった。なので、トヨタの人は現場の人といっしょに機械をうごかしました。

トヨタの改善は、10\~20％の改善ではない。100\~1000％の改善。

自己組織化の仕組み

バグを作ってシステムをダウンさせた人がいる場合、給料を下げるべきか、解雇すべきか。

バグを作った人に感謝するといい。バグができるプロセスだってことが分かる情報を貰えたので。もしこれが、100回起ってしまったらどう直したらいいかって考える。

バグを作って、修正した人にはメダルをあげたい。ビジネスの仕組みを変えた。自分達で新しい仕組みを作ったってこと。自己組織化されている。

バグをトラッキングしない

不具合は0にしたいし、0にしなければ出荷しない。バグをレベルごとに分類して深刻度が最大のものを8％減らす目標を立てたらどうなるか。組織として考えたら良い方法とは言えない、もっとも効率的な方法(深刻度の変更)でやってしまう。

子供には学んで欲しいと思うでしょう。子育てで8％改善したからいいってことになりますか。ソフトウェアを自分の子供だと思って扱ってください。

未来予測に気をつけろ

石を積みあげていくような仕事なら予測できるでしょう。物理学と数学を使えば予測できます。しかし、ソフトウェアは、理念や哲学に従って作るので予測はできない。

間違っているということであれば、コンパイルすればいい。どうやって正しく作るか知っていればテストをする必要がない。フィードバックを早い段階でうけることが大切。

アジャイルとリーン

アジャイルは、この方向性に行きたいということはできる。

検査して適応していく。これがアジャイル。道が通れるか確認して進める。行きたい方向に机があるか確認してあれば避けて、あれば避けてを繰り返して進む。

トヨタ生産方式(リーン)は道をあけて通れるようにする。行きたい方向に机があれば机を動かして、進む。

リーンは設計・デザインすること。アジャイルはテストをすること。

全員がリーダーシップを

それぞれがリーダーシップを発揮する。プロダクトオーナーは、プロダクトのリーダー。 1人より5人考え方の方が優れているから。スクラムでは、誰かに決定をさせるって意味では委任させない。それぞれ詳しいことが違うので、適した人がリーダーシップを取るといい。

リーダーが必要なことって、どれくらいありますか？私は7823個くらいあると思います。シンプルなことをやるなら上手くいくかもしれません。リーダーがムチを持ってピラミッドを作らせるとうまくいくでしょう。チームが1つになって1つの心になってほしい。

リーダーが前にでると、他の人の意見が無駄になってしまう。リーダーがいると、スクラムマスターのインプットをスタックして止めてしまったりするので良くない。

プロダクトオーナーは一瞬にして意思決定しないといけないので1人。開発チームは情報共有しながら進めていく。

誰がチームをリードするのか。例えば技術的によく分っている人がいたとして、周りの人からアイデアが集められなかったらどうなると思いますか。あるアイデアがうかんで、彼が30秒リーダになって、 1秒だけリーダをやったり、仕切り屋は変わるのですよ。

他のチームからメンバーが来たとき

他のチームからメンバが来た場合、違うチームから集まってくると、全然違うプラクティスを持ってくる。そんなときには、基本に立ち返って相談する。やりながら、スタンダートを参照して修正していく。世の中の学びを持ってきてチームをつくる。

スクラムマスター

スクラムマスターは、ROIを最適化する文化と環境を維持する。プロダクトオーナーがプロダクトバックログを更新できているか確認したり、チームを外部からの攪乱の盾になる。チームに指示はしない。

そして定期的に、チームの障害になることをリスト化して取り除いていく。

あえて、何をすべきか言わなかったり、チームが考えるようする。サーバントリーダーをやるようにする。ふりかえりでやるのが一番大切だけど、他のときにも考えるように促せたらよりよい。コミュニケーションを円滑化していく。

チームみんなで考えてもらうんがメイン。なるべくチームで解決できるようにする。どうしても決められない場合には、アドバイスしてもいい。プロダクトオーナーと話をする場合にも一緒に考える。

スクラムマスターがコードを書くことも含めて責任を持つこともあるが、スクラムマスターであることを忘れない。隣りが火事になっているのに気づけるのはスクラムマスターだけなので、スクラムマスターであることを意識しておく必要がある。

各ロールの兼務

POの複数チームは兼務しないことが理想だが、兼務は問題ない。チームに必要なものは揃えるようにする。

SMの複数チーム兼務は問題ない。優れたスクラムマスターは、3チームまでもてる。偉大なスクラムマスターは、1チームしか見れない。偉大なスクラムマスターは、どんどんチームの問題を見える化していくので、仕事が多くて複数のチームを見ることができない。

開発チームの兼務はしないようにする。

SMと開発チームの兼務は、95％開発に使われている。書くコード数が大切だと思われているわけで、改善の真髄には近づきにくい。

SMとPOの兼務はうまく機能しない。チームの目標に間に合せろといいながら、健康に気を付けろって言うことになる。

顧客

顧客ってのは、大切なステークホルダー川口さん「ドキュメントは顧客を真面目にして、プロダクトは顧客をマジにする。」

障害物リスト

障害物リストは、スクラムマスターのプロダクトバックログ。プロセス関係のものを上げる。スクラムマスターがプロダクトオーナーにやる意味を説得して改善の業務をプロダクトバックログに入れるようにする。

タイムボックス化

チームが邪魔されずに働ける時間。プロジェクトのリズムを作る。

途中で新しい要求を受けつけるときには、他のものを外さないといけない。 ROIを高めるために仕事をしているので、途中で仕事のやりかたを変えることは、チームは計画を重視するのか、ROIを高めるのか、を良く考える。

プロダクトオーナー

プロダクトに投資する予算も、プロダクトオーナーがもってないといけない。ビジョンを持っていて、価値を説明できるのはプロダクトオーナーである。

チームによってプロダクトを複数をもっているパターン。それぞれのプロダクトオーナーが早くしてくれっていってくる。そこから1つのプロダクトバックログにできるのは、PO。

すべきじゃないこと

プロジェクトマネージャとしてふるまうこと(チームが一番詳しいから)
チームのやる気を削ぐ信頼こそすべて。(「これできる人なら3日でできるよね」みたいな発言)
締切を決めること(締切を決めるのは信頼をしていないからだ。)

すべきこと

デイリースクラムで話す(上級者向け)
課題を明確化する
最近のビジネス価値をデリバリーする。その価値をフィードバックした価値のあるものを。
チームの価値を引き出す。(どうやればROIを最大にできるか)
緊急脱出手順を起動する(スクリプトを緊急に停止する)
チームが問題の情報を上げて、POが判断する。

コミット

コミットって言葉はスクラムでは使わないようにしている。コミットというと、絶対遂げないといけないってことになるから。スプリントバックログにはコミットしない。 50％は失敗しているわけなので、コミットできてない。コミットする対象は、スプリントのゴールに対してのみである。

スクラムとチームワーク

それぞれ全員がスプリントアイテムは90％を終わらせていたら価値は0である。一緒に仕事をできるようにする。一緒に作業すること。スクラムにおいては、チームワークを助長する道具だと理解したらいい。

リモートワークに対する他社の話

スカイプのCEOが、スカイプは開発に使うツールではないと言っている。スカイプの人でさえ、顔を合せて話すようにといっている。リモートは避けましょう。

アトラシアンの開発メンバーは壁を使ってタスク管理している。

守破離

守破離は、日本の茶道、武道における師弟関係のありかた。

スクラムで言う守破離は、以下のようなもの。

"守"は、みんあではなしあって問題を見付けていく。 "破"は、おなじサイズのスプリントバックログがすべてが同じサイズになるように分割していく。すると見積りする必要がない。 "離"は、野中先生が、5スプリントを並行して行う。あたらしい技を作り出していく。

スクラムガイドに準じて"守"を身につけるからこそ、次の段階へ行ける。

担当ではなく求められること

シカゴブルスといっしょに働いているときに、マイケルジョーダンがエースだと思うんですけども、センターのポジションを取りたいと思うのだけど、チームから求められていることをしないとチームには入れません。

チームの方からテストをしてほしいと思われているなら、テストをすべきだし、知らないなら、勉強するといい。プロダクトオーナーがお金を持ってきて、テストのコースを受講させてくれるかもしれない。

新しいことを学びましょう

ソフトウェアのエンジニアは、専門的な仕事です。靴職人の子供は、くつづくりを教える。でも、われわれは、チームなので、チームに求められていることを一員としてすべきですね。ほとんどは、テストに関連する仕事かもしれません。

今プログラマだったら、もっといろんな仕事をやってみてほしい。脳の1％しか使ってないって言われますが、もっと使ってない人もいますので、もっと新しいものを学びましょう。新しいことを学ぶのはとても楽しいことです。やりたいことがあるなら、そんな会社にいってもいいでしょう。

フィードバック

スクラムチームは、だれからフィードバックを貰うの？

フィードバックは人から貰うのですよ。JIRAからではありません。観察するときにいろんなことが見えてくるんだよ。

レストランが込みすぎているから、新しいお客さんがだれもこなくなってしまった。見ているだけでも、分かりますよね。歩きまわることで人を管理するとも言えると思います。日本人が良く言うじゃないですか「現場に行ってよく人を見ろ」と。

リクルーティング

何か採用したい人がよいスキルをもっているとか、いい人格だってどうやったら分かるのですか。どうやったら学べるか、学び方を知っている人を雇えばいいんじゃないですか

責任

作るチームが責任を持つ以外の責任を持ちかたはない。

お子さんがいたら、教育をコントロールしたいと思うのでしょうか。マネジメントのブックは脇においておいて、人を中心に考え始めるべきだと思います。みなさんが支援して良いことをすれば、みなさんの子供が世の中に貢献するところが見える。

プロダクトオーナーは価値に対する責任を持たなければならない。 ROIが出ていないのなら、プロダクトオーナーはの首締られるべきだ。

ベロシティを改善できない。改善されない。それは誰の責任か。できるだけのことをやろうと人間は思うものだ。開発者は、全力でやっている。チームのデリバリーに責任を負うのはスクラムマスター。

スポーツチームのパフォーマンスが出ないのなら、コーチが悪いのでクビにすればいい。スクラムチームの監督はプロダクトオーナーで、コーチはスクラムマスターである。ただし、スクラムマスターはチームをコントロールできないし、すべきでない。

チームを子供扱いしない

チームがかかえる問題すべてをチームで考えてもらう。すべての情報を提示していく方が良い。

見せない方法もあるが、子供扱いだと思うし、それは伸びない。だれかのようにできるようにならなければ、その人のインプットを知りなさい。おなじようにできるようになる可能性がある。何を生み出しているかだけを見ていたらいいわけではない。そこの枠から出て、よくするって考え方を改善しないのではないか。その人が情報を持ちすぎて混乱する場合もあるなら、補助してあげればいい。

チームがスプリントを達成できない場合

スクラムマスターはチームに対して、チームに対して見積りが甘かったんじゃないかって言える。見積りがあまかったって言えるんでしょうか。マネージャが言いがちですね。これは自分達で修正していくしかない。スプリントに入れる量はベロシティを元に入れていく。

それがうまくいってないなら、プロセスに関係に問題があるのではないか。そして、みなさんがやってもらうのはチームをしっかり教育して、プロダクトオーナーを教育していく。

それを理解してもらえないのなら、スクラムマスターが全責任を果す。システムの理解も必要になってきます。チームがスプリントを達成できない一番の理由は、バックログに入ってない仕事のせいだ。スクラムマスターは、テリーテイトのように「ここは私のチームなのだから横槍を入れないでくれ。」と言うべきだ。

プロセスを改善すると考えてください。人間は自分の最善を尽そうとするものでしょう。

明日からスクラムマスターを始めて、プロダクトバックログに同意することはできますか。一旦決めたきめごとに対してそれを守らせる。プロセスに対して、約束してもらわないといけない。アジャイルの鍵は、合意してもらう。それを指差して、これに合意できてないじゃないか、と言える。

発生しそうなでなく発生した問題について話す

いまある問題は解決できるけど、存在していない状態には話ができない。原則を学んでいただけると思います。抽象的な理論だけだと一晩中語り明かすことができると思います。

チームの学びを促進する

スクラムマスターは2つチャレンジすることができる。 1つは、思った通りやってもらって失敗してもらって、学んでもらう。チームは1回くらいで気付いてくれる。もう1つは、「本当にそれでいいの？」、「見逃していることはない？」と失敗する前に問いかける。

スクラムは、安全に管理されて失敗を繰り返してそこから学ぶ、コントロールド・フェイリアなんですよ。

スクラムマスターはワーカーホリック

原田騎郎さん「チームは40時間で帰れるようになるけど、スクラムマスターはワーカーホリックになりがち。」

スクラムマスターに権限はない例外

権限はない例外：チームを破壊する人をチームから取り除くことはできる

意図的にチームを破壊するような人は、スクラムマスターが排除すべき。

タスクは絶対見積りか相対見積りか

スクラムでは触れていないので、どっちにしても良い。スプリントゴールを達成するために良い方を使うとよい。金曜の朝に残作業が40時間ってどうするの。チームに5人いるよね。問題ない。8時間。みたいに、絶対時間にする問題点は、プロジェクトマネージャが簡単な計算をしてしまって、チームのモチベーションが下がるのです。相対時間には、プロジェクトマネージャが勝手に計算できないようにする効果もある。

絶対時間で見積りをするときには、「優れた人だったらどうなるか」考えるのが上手くいく。時間で見積るときは、どう処理されるか。

見積りは、スクラムガイドには乗ってない。常識。見積りは、ベストプラクティスであって、スクラムの一部ではない。自分達のチームで何がうまくいくかが大切。なので、測定していくこと。

スクラムをやる人達も、やりかたを変えていっている。みんな、過去はこう思っていたけど、今はこうするのが良いと思っているって言いあったりしている。

リリースバーンダウン

リリースのバーンダウンをいつアップデートするのか。リリースのときにアップデートするこれは作ってはいけない。3ヶ月先の予測をすうことになったりする。幻の世界です。古いプロジェクトマネジメント的な考え方で使われているが楽観的すぎる。

1ヶ月のスプリントでちょっとだけ遅れているので。次のスプリントでまた遅れてしまった。繰替えしてしまったり。これをショートカットしようとすると技術的負債で会社が回らなくなってしまう。

台風の予想と同じですよね。だんだん誤差が大きくなるじゃないですか。

カイゼンの確認

カイゼンをしたら、ばらつきがなくなるまで止める。カイゼンがあったのかどうか分からなくなるので、振れ幅が無くなるまで様子を見る。改善し、調整し、改善し、調整し、改善する(エクストリームトヨタ)とよたのやりかた。

チェックとテスト

チェックするのと、テストするのは違う。新しいフィーチャー向けのテストケースはどうなるのか。これは開発チームの仕事ではありません、プロダクトオーナーの責任です。良いチームは探索型のテストを行なう。

リグレッションテストはチェックです。チェックは完了の定義ではありません、完了の定義の一部だけど。

プロダクトオーナーが思っていたものかどうかの確認。チェックは既存の動作をしているか。テスティングは、想定した挙動をしているかのテスト。

探索テストは完了の定義には含まれない。

単体テストがROIにどう影響するか

テストをすることで品質が改善するわけではない、測定のサンプルを出すのがテスト。単体テストの殆どがムダだと私は思います。リーンという意味では、あまり。

単体テストに失敗したらROIに影響するの？現場で実行しないかもしれない。実行されないなら、ユニットテストがどんな価値を提供するのか答えられないなら作る必要がない。

良いコードは、メソッド1つ最大20行くらいですよ。オブジェクト思考でやってないのですか。

ユニットテストをすることはROIに価値があるのか？って聞くことがスクラムマスターの役割。裸の王様に、「裸じゃないか」って言えるのがスクラムマスター。それが仕事。

技術的負債とリファクタリング

技術的負債がでないようにする。あったとしたら、これはPBIです。 POが技術的負債のことが良くわからない。これで会社が傾いていくんですよね。

リファクタリングとは？キャンプ場と同じように、来た時よりも美しくすることを心掛けるようなものです。

まとめ

スクラムの核となっているマインドについての発見が勉強になった。ついつい、ロール、セレモニー、成果物に注目しがちだが、マインドの部分が理解できていないと正しいスクラムにはならないと感じた。

トヨタ生産方式からのスクラムの歴史について知れたのは、方法論好きの自分からすると非常にありがたい。マインドの元になっている歴史も理解することで一層スクラムに活かすことができると思う。

Corp先生は、非常に厳しい原理原則の部分を教えてくれるのが非常に参考になった。ベストプラクティスを聞きすぎていると、何が元になっているのか、誤認しやすくなっていると思う。原理原則を理解した上で、現状がどうなっているか認識することで、一層良いチームに近づけやすくなると思えた。

1つの理想的なあるべき姿を知ることができるということは、そことのギャップを課題に上げていける大切なことである。理想的なチームに関しては、これからも他の人達と議論していきたい。

質問をされるとき、「もし、○○になったらどうしたらいいんですか？」って聞かれたときに Corp先生は、毎回「具体的なケースを教えてもらえますか？」と返していて、抽象的な想像には解答しないようにしていた。おそらく、話をされた状況だったとしても、詳細な内容に応じて対応を変えるため想像で発生する状況では答えきれないのだろうと思った。自分も、変に決めつけたりしないように気をつけたい。