随分前になってしまいますが認定スクラムマスター研修を受け、その後の Web テストを経て、無事に認定スクラムマスターになりました。
なぜ認定スクラムマスターを取得しようと思ったか
ここ数年はずっとスクラムを採用したプロジェクトに参加し、スクラムマスターとして活動をしてきました(実態としてはスクラムマスターを専任できるほどの技量もなかったので、開発チームとの兼任で)。
もちろんいくつかの書籍を読み、その基本を学び実践をしてきたつもりです。 ただ、その学び、その実践が正しいものだという自信はなかなか持てませんでした。 守破離を基本とするスクラムにおいて、自分がその「守」をきちんと理解しているのか。 スクラムを自分たちなりにアレンジし失敗しているにもかかわらず、成功しているように見えているだけではないのか。
そこをきちんと学ぼう、書籍からのインプットではない別の学び方をしよう、そういうモチベーションで認定スクラムマスターになろうと想いました。
認定スクラムマスター研修
認定スクラムマスター研修は、アトラクタ社の研修を利用させていただきました。 講師は Joe Justice さんでした。TED でトークもされています。
中だるみのない、密度の濃い研修でした。学んだはずのことだったにもかかわらず、研修の場で言われると「そうだよな…」と反省せざるを得ないことが多々ありました。 以下、整理せずですが、強く心に残ったことを羅列します。
品質の低いベロシティは存在しない
そもそもベロシティというものは、品質基準を満たしたものの数で測られるもの。だから、品質が悪いけどベロシティが出ている、ということは存在しない。
実績がないのに見積もるな
「今回これだけできたから、次はもっとできるでしょ」ではなく、あくまで過去の実績がベースになる。願望は入れない。それが一番良い予測になる。
Yesterday's weather とも言われるようですが、これはこれまで多くの見積もりを出してきた自分からすると耳の痛い言葉でした。
小さいアジャイルPJが一番成功率が高い
ウォーターフォールと比較しても、小さいアジャイル PJ の成功率が一番高いというデータがある。
では、大きな PJ で成功率をどのように上げていくか。それは大きな PJ を小さく分割するという戦略です。 そこで必要なのは、modularity。単一で分析し開発しテストできる単位に分割する。それによって大規模ソフトウェアの断片を独立してリリースできるようにする。
Joe Justice さんはこれを「車の製造」という世界で実現し、凄まじいスピードで車を作っています。 そういうバックグラウンドを知ると、「大規模 PJ にスクラムは向かないんじゃないか」とは言えなくなりました。
プラットフォームは収穫するものだ
一番やってはいけないのはなにか、それは「最初からプラットフォームを作る」ことだ。 プラットフォーム化は、「うまくいったものから収穫」する、「共通部分を取り出す」もの。
これもまた、Yesterday's waether とつながる考え方なのでしょう。
見積もりはT-shirtサイズで十分
自分自のプロジェクトでも、各ストーリーにストーリーポイントを振ります。 ただ、現実ではストーリーポイントは S、M、L で最後までいくことが多い、ということでした。
ストーリーポイントの値をフィボナッチ数列から選択するというプラクティスは、人間の感覚は「大きなものを相手にするほど当てにならない」から、という話はよく聞きます。 T-shirt サイズはさらに割り切った考え方で、3 段階しか選択肢がありません。これでベロシティを測れるのか、とも思いましたが、十分実践的なようです。 数字をこね回すことに疲弊せず、価値を作ることに集中しろという、メッセージのようにも感じられました。
いきなりログイン機能を作るな
プロダクトに価値があることを先に証明しましょう。それが認証機能なのであればそこから作れば良い。認証機能でないのなら、なぜ最初に認証機能を作るのか。
よくありませんか、Web アプリの「認証機能」から作に作ること。
分業すると作りすぎる
分業すると、それぞれの人が作ったもの同士で依存が発生する。なにか機能が足りないと怒られるので、怒られないように余計な機能を作ってしまう。
だからユーザストーリーベースできちんと駆動しましょう。
人間には学ぶ力がある
- スクラムは「検査」を重んじるが、唯一検査なしに信じている価値観がある。それが「人間には学力がある」ということ。
- チームメンバーは幼稚園児ではない。
- 人が学ぶスピードを過小評価するな。
こちらのスライドにも書いた「人間には学ぶ力がある」という言葉。 この言葉は「チーム個々人が成熟していないので、cross functional なチームが作れない。どうすればよいか」という質問に対する回答の中で出てきたものでした。
資料に書くほど強く心に残りました。
チームの見えないところでPOに何かをさせるな
それは、開発チームからのフィードバックを捨てている。
POはすぐに判断するのが仕事
情報が揃っていない、は言い訳にならない。情報が揃っていない状態でも判断するのが PO の仕事。
レビューで「この機能ができました」では駄目
良いプロダクトを作っているのであれば「スゲー」と PO やステークホルダに言わせないといけない。 できたものが魅力的でない場合、開発プロセス等へのツッコミに至りやすいので、そういう観点でもエキサイティングであることは重要。
スクラムマスターはSPoFになるな
スクラムマスターは、サーバントであるがゆえに頑張ってしまいがち。 あなたというスクラムマスターが疲弊しチームからいなくなること、それが一番問題なのであれば、頑張りすぎるな。
認定スクラムマスターになって
その後、Web 上でのテストを受けて、無事に認定スクラムマスターになりました。 何か変わったかというと、ほとんど何も変わりません。
ただ、研修を受けて意味がなかったかというとそうではなく。むしろ研修を受けて良かったです。 自分がおっかなびっくり進んでいた方向性はたぶん間違ってなかった。あとはいかにしてそのプロセスを充実させ、結果に結びつけていくかという点を考え実践していくことだなぁと。
