2012年 CSM研修 (東京)を振り返る

IT業界 アジャイル

今更だけど、2012 1/12 ~1/13で受講したCSM研修の振り返りをしたいと思う。
（･･･っと言っても会社に提出したレポートの焼き増しだけど。）
http://jp.agilergo.com/13

講師はJim Coplien、パターン本をいくつも出している人。
Jim Coplien - Wikipedia

研修受講者は全部で35名でした。
それを以下のようなグループに分けられて座りました。

受講者以外にも同時通訳の方が３名程度、サポートスタッフの方が５名程度いらっしゃいました。
同時通訳の方は淡々とJimの言葉を訳し、サポートスタッフの方はJimの意図が伝わりづらいときに補足説明して頂くなどとても助かりました。
普段なかなか味わえない雰囲気でそれだけで少しテンションが上がりましたね(笑)

そして研修がスタート。

（以降は研修中に印象に残った言葉や研修内容を元に考察した結果をレポートしたいと思います。）



Scrum：It’s All About Common Sense

研修資料の１ページ目に書かれてある言葉です。
「スクラム：重要なのは認識を共有すること」
という意味です。

これはScrumだろうがXPだろうがWFだろうが大事なことだと思います。
チームメンバー全員が同じ方向を向いて、顧客も目指す方向は同じで ･･･ っと実は案外難しいことですね。

Scrumを採用すればそれが実現出来るということではなく、そこに焦点を当てているということです。
研修中にも
「Scrum is not method. It does not tell you what to do, nor how.（スクラムは方法（手法）ではない。やるべきことや、やり方を教えるものでもない）」
ということを言われていました。
つまりScrum自体が問題を解決するわけではなく、Scrumというフレームワーク（※）を使って自分で解決するというようなイメージになると思います。

※「Scrumはメソドロジーではなくフレームワークだ」ということも何度も言われていました。


この言葉を最初に研修がスタートしました。

（もし自分的にアレンジすることが許されるなら「It’s All About Common Sense (Of Values)」といった感じにしたいですね。つまり「共通の価値観を持つこと」というのが大事かなと。）


Bule pill or Red pill？

研修スタート早々、Jimにこのように問われました。
「なんのことだ???」
と受講者一同頭の中に疑問符が浮かびました。

少し議論があった後にサポートスタッフの方がフォローして
「Blue Pill ＝ 教科書通り、型通りのもの」
「Red Pill ＝ 時に痛みを伴うが、現実的な改革を実施するためのアプローチ」
という意味だと説明して頂いきました。
つまりJimは
「教科書通りのScrumを学びたいか、それとも現実的にアプローチする方法を学びたいか」
ということを問うていたわけで、もちろん全員一致でRed Pillを選択しました。

Wikipedia：Red pill and blue pill
http://en.wikipedia.org/wiki/Red_pill_and_blue_pill


not failure, only feedback

「（プロジェクトに）失敗はない、あるのはフィードバックだけ」
という意味です。
この言葉を研修中何度か繰り返し使用していました。

これをAgile界隈でよく言われる
「小さく、早く失敗する」
という言葉と合わせて考えるとなんとなく直感的に理解できるのでは、と思います。
失敗しても問題ない、それをフィードバックとすればプロダクトはもっと良くなるということを言われていたと思います。

あとは何か問題が発生した場合に「失敗（failure）にするもフィードバック（feedback）にするも自分次第」みたいな意味合いも根底にはあるのかなとも取れました。
失敗を悔やむよりもそれを次に活かす、ということを心掛けていきたいですね。


合わせて言っていたのが「改善マインド」について。
この言葉も研修中何度も繰り返し使用していました。
これは読んで字の如く、改善していく心のことです。
実際、自分も結構忘れがちになってしまうのですが、ちょっとした些細なことでも改善していく心を持ち続けることが大事だと再認識しました。

「改善マインド」を持って「not failure, only feedback」精神で今後のプロジェクトに臨んでいければと思います。


Scrumにおける守破離について

Scrumにおける「守破離」の説明をして頂きました。
ただ他のことをメモってる間にJimが話してて一部聞き逃してしまったんですが･･･orz

  • 守　･･･ とにかく忠実にScrumのプロセスに準拠する。プラクティスもなるべく多く取り入れる。
  • 破　･･･ （聞き逃した。まぁでもアレンジしろ的なことを言ったんだと思うが。）
  • 離　･･･　デイリースクラムをやるのは良くないですね。

ここで面白いなと思ったのは「離」の部分。サポートスタッフの方も
「何で「離」だとデイリースクラムやるのがダメなのか分からない」
ということを言っていました。

私はなんとなく、Jimはこういうことが言いたかったのではないかな？と自己解釈しました。
「デイリースクラムが悪いわけではない。「離」の段階ではScrumの提唱する価値は全てチームの根底に存在しているハズ。であればデイリースクラムにて稼働時間を削ってしまうよりもプロダクトに注ぐ時間を増やせる方が良い。（※）」


※ デイリースクラムがベストプラクティスとされてある所以は色々あると思います。例えば自分で「今日はこれをやります」と言って自己組織化を促すためであったり、それをチーム全体に公言することによって「コミットする」という価値を生んだり、そもそもチーム全体が共通認識（Common Sense）を持つためであったり。しかし「離」の段階ではそれらの価値観は全てすでにチームの根底には根付いている（ハズの）ため、それに時間を費やすよりもプロダクトに掛ける時間を増やす方が良いと考えているのではないかな、というのが私の解釈です。この辺は飲み会でJimのことをサポートスタッフの方に聞いたりして、彼がどういった考え方をしているのか、どういったことを大事にしているのかということも含みで解釈したことです。まぁ結局「勝手に」ってのは変わらないんですが(笑)
（JimはTPSでいう「ムダ」というものをいかに省くか、ということにとてもパワーを注ぐタイプのようでした）

ちなみに以下は私なりの守破離。
一般的な守破離と同じことを言ってるんですが、「根底にある価値を自分のものにする」ということに焦点を当てた感じです。（Scrumに関してというわけではなく、何か新しいことを実施する際に、の守破離）

  • 守　･･･ とにかく忠実に言われた通り（教科書通り）やってみる。何か疑問を覚えてもその通りにやってみる。そしてその根底にある価値観というものを理解しようと心掛ける。
  • 破　･･･ 教えられたことを少し（破って）アレンジしてみる。（つまり自分の価値観をエッセンスとして付け加えるイメージ）それが新しい価値につながるのであればそのまま実施するし、ダメな方向に行くのであればアレンジはやめて元に戻す。
  • 離　･･･　存在するのは価値観だけ。その価値を満たすために自分（自分たち）に合った手法で推し進める。

まぁこういう自分の考え方があったのでJimの話を前述のように受け取ったのかもしれません。

守破離について
http://www.la3-beam.com/contents/shuhari.html

「ほう･れん･そう」をデイリースクラムに置き換える
http://jibun.atmarkit.co.jp/lskill01/rensai/scrum/01/01.html

Scrum of Scrums

Scrumでは大規模開発をする際には複数チームに分けて実施する、というような定石があります。（１チームで20名、ではなく7名＋7名＋6名のような感じ）
その場合、それぞれのチームでデイリースクラムを実施し、またそれぞれのチームのスクラムマスターを集めてさらに全体のデイリースクラムを実施します。
後者のことを「Scrum of Scrums」と呼びます。

以下のようなイメージです。

ユーザーストーリーは使えない

Jimはユーザーストーリは全然使い物にならないと言っていました。
それはなぜかと言うと、ユーザーストーリーは「Enabling Specification」ではないからとのこと。
つまりそこに仕様が盛り込まれていないからとダメだということでした。

でもむしろユーザストーリーの狙いはそこにあるわけで、ストーリー形式だから顧客視点のビジネス価値だけ管理することができ、Specificationの部分は作る側に委ねられると思うのですが。。。
ここはJimの主張に対してたぶん私の理解が足りていないのだと思います。

まぁ「良」「悪」というのはコンテキスト（顧客、チームメンバーのスキル、etc…）によって変わり得ると思いますし、自分としても「良」「悪」を判断するよりもそういった方法が１つ存在するんだなくらいのスタンスで良いかなと思っています。

あとはJimが「XP、TDD」といった所を強烈にdisっていたのでその一環でこういうことを言ったのかなとも思いましたが･･･(笑)


5人のメンバーで2週間、どれだけの仕事がこなせるか

人月による見積もりですと、「5人×2週間＝400時間」となります。（1人が8時間／日　とした場合）
このことに問題提起していて
「本当に400時間の仕事をこなせますか？」
と問いかけられました。

以下、Scrumで2週間のスプリントとした場合の稼働時間算出結果です。

予想以上に稼働時間少ないです。
これはScrumに当てはめた場合の算出結果ですが、WFだとどうなるでしょうか？
フェーズによるかもしれませんが（※）、自分の経験上ではさほど変わらないのでは？と思います。
むしろ顧客によってはこれ以上に稼動時間が圧迫される結果になるかもしれません。（無用な打ち合わせ等に無理やり参加させられたり･･･）
で、結局400時間の作業なんて出来ないので残業の嵐となってしまうと思います。。。

つまりJimは人月換算で作業量を決めるなんてことは出来ないのでそんなのはやめるべきだということを主張されていました。
激しく同意しますが･･･そう上手くはいかないのが現状かと(笑)


※要件定義や基本設計、システムテストとかのフェーズだとどうしても打ち合わせに時間がとられがちかと思います。

TPSの本質は（かんばん方式ではなく）Single Piece Continuous Flowです！

TPS（Toyota Production System：トヨタ生産方式）についてお話頂きました。
自分も勘違いしていたのですが、以下のようなことを主張されていました。

「世の中的には「TPS≒かんばん方式」と考えている人も多いと思うが、それは違う。TPSの真髄は「Single Piece Continuous Flow」である。TPSでは本当は「かんばん」なんて使いたくないんだ。１つの工場内で完結できるのであればそんなものは必要ない。

しかし１台の車を作成するのに（大体10万個くらいの部品が必要らしく、）とても１つの工場ではまかなえない。そのため「（これ大事！！） Sigle Piece Continuous Flowを満たすために」かんばん方式が生まれたのだと。なのでかんばんなんて本当は必要ないんだよ。」
（この話に伴わせてU字生産ライン（U-Type production line）についても語っていました。）

これまで自分も「TPS≒かんばん方式」というイメージだったので目から鱗な話でした。（TPSについて再度勉強し直さないと！！）
あと、１度でいいから機会があれば実際に工場見学とか行ってみたいなと思いました。

チームとって重要なのは多様性

研修の最後にベロシティゲームなるものを行いました。
①〜⑥の６つのチームに分かれてのチーム戦です。
それぞれのチームにPBI（Product Backlog Item）が複数渡され、その１つ１つにポイント（ビジネス価値）が付きます。

「直径40cmの風船を５つ膨らませること：200pt」
「直径60cmの風船を５つ膨らませること：300pt」
「トランプのタワー（２段）を作ること：300pt」
「トランプのタワー（４段）を作ること：2000pt」
といった感じです。
そしてそれらの合計ポイントをチームで争うというものです。


これだけではどこにでもよくありそうなワークショップなのですが、すごいことが起きました。
Jimが事前に優勝チームを予想し、そして見事に当てたのです。
（事前にチーム名の書いたpost-itを封筒にしまい、ゲーム終了後それを開けると･･･優勝チーム名がそこにありました）

以下、結果（正確に覚えていないので雰囲気だけｗ）です。

結局優勝したのは①のチームでした。
これをJimは見事に当てたわけですが、なんで分かったのでしょうか？

Jimは
「とても簡単です。みなさんにも予想できたハズですよ。」
と言いました。
続けて
「①チームには女性が２人います。（⑥チームを除いて）他のチームにはいません。だから①が優勝すると分かったのです。」
「チームにとって大事なのは「多様性」です。多様性とは単にその人の持っているスキルうんぬんだけでなく、年齢／国籍／性別／･･･そういったもの全て含まれます。色んなスキル、人種、性別によって色んな角度から物事を判断し、決定するということが一番チームの力を高めるのです。」
と言いました。

正直驚きました。
多様性が大事とはよく言われますが、結果にここまで影響を及ぼすものとは思っていませんでした。
これからチームに対しての考え方が大いに変わりそうな体験ができました。


同様に「多様性が大事」と語っている。
http://jibun.atmarkit.co.jp/lskill01/rensai/scrum/04/01.html




最後に

合計２日間の研修でしたが、もっとずっと研修を受けていたくなるような有意義な時間を過ごせました。
研修を通して学んだことは

「自分で考えること」
「失敗してもいいからチャレンジし、その失敗をもとに改善していくこと」

というごくごく当たり前のことでした。
そんなの当たり前だよと思いがちなのですが、振り返ってみると実は自分は結構実践できていなかったりすると思います。

「本にこう書いてあったから（･･･っと自分で考えることをしなかったり）」
「これは良い方法だがリスクがあるし（･･･っとチャレンジしなかったり）」

大事なのはこれらのマインドを「知っているか」ではなく「持っているか」なのではないかなと思います。
ただ知っているだけで実践しなければ意味無いですしね。


自分も日本ハムの斎藤佑樹選手のように「持ってる」人間を目指したい！！



【2012/8/23 追記】
Jim Coplien氏による「One-Piece Continuous Flow」の話。
（研修中は「Single Piece Continuous Flow」と言っていましたが、こちらでは「One-Piece Continuous Flow」と言っています。）
Scrum Log Jeff Sutherland