「アジャイルな見積もりと計画づくり」を読みました

名著と言われながら、今まであまり興味がなくて読んでなかった分野。もっと早く読んでおけばよかったなと思う反面、おそらく以前の自分では消化できなかった&活かせなかっただろうなと思ってはいます。

1章:計画の目的

1. なぜ見積もりや計画づくりが必要なのか?

しょっぱなにあるこの問いかけ、最初からすごいためになる文章です。この本を読むまでは、見積もりや計画って、やりたくないけどやらざるを得ないといった、どちらかというと消極的な理由しか思い浮かびませんでした。でも、それだけでないよという話。具体的には、以下の5つが挙げられています。

  • リスクを軽減する
  • 不確実性を減らす
  • 意思決定を支援する
  • 信頼を確立する
  • 情報を伝達する

この中で太字にしたものが、消極的な理由ではなく、計画作りをしていくことによってもっと前に進めるための理由かなと感じました。開発者・チームにおいても、いやいや計画づくりをやっていくのではなく、チームが計画づくりをやっていくことによって、ビジネス面での意思決定を支援したり他チームとの信頼を確立していくことを意識する。それが結果的に、開発チームだけでなく全体のサービス・プロダクトにいい影響をもたらしていくというのは、自他共に意識づけていきたいなと強く思いました。

あとは、これかな。

3. アジャイルな計画づくりとは?

本書で扱うのはアジャイルな「計画づくり(planning)」だ。アジャイルな「計画(plan)」ではない。
...
アジャイルな計画づくりで重視するのは、計画よりも、計画を作る過程そのものなのだ。

プロジェクト初期のみ「計画」を作成するだけじゃだめで、ちゃんと日々の活動の中で計画を更新していく「計画づくり」が大事だよということ。これって、プロセス改善の文脈でのメトリクスとかでも同様だよなーというのを思い描きながら読んでました。

11章:「望ましさ」による優先順位づけ

狩野モデルについての説明。このモデルについてはどっかで見たことがある気がするけど、本の中で出たので改めて見なおしてみました。守備範囲的にはプロダクトオーナーの領域っぽいけど、スクラムマスターとしてもさらっとでも知っておいて損はない領域だし、参考になりました。

モデルの説明については、先人のブログを参考に。
d.hatena.ne.jp

16章:ベロシティの見積もり

ベロシティは常に固定になるわけではなく当然幅があるけど、その幅をどう扱うかの話。3イテレーション(スプリント)以上取れる場合、以下の方法が挙げられていました。

  • イテレーション毎のベロシティをそのまま幅として扱う
  • 不確実性コーンを活用する

前者は単純。3回のイテレーションのベロシティが (12, 15, 16) ポイントだった場合、見積もり幅は 12~16 ポイントと扱います。

後者は、不確実性コーンと呼ばれる、プロジェクトの状況に応じて不確実性の幅が変わる図を流用しています。ここで、3回イテレーションこなした後の平均ベロシティが20ならば、下限が20*0.85=17, 上限が20*1.15=23 で、17~23 の幅に収まるだろうと推測する感じ。

f:id:ikikko:20160813102519p:plain

実施したイテレーション 下限の係数 上限の係数
1 0.60 1.60
2 0.80 1.25
3 0.85 1.15
4以上 0.90 1.10

ちょっと計算式は複雑になるけど、不確実性コーンをもとにした方が、今のうちのチームにとってはいいかなと思いました。理由としては、ベロシティの平均が基準となってるから。

うちのやり方として、1イテレーション内できれいに終わりきらないことがあるのですが、その場合各イテレーションのベロシティは変動しやすくなるんですよね。ただ、各イテレーション毎の変動はともかく、移動平均をとっていくと中長期的には問題とならないことが多い*1。なので、平均を考慮した方がより精度が高いものが出せるかなと思っています。

22章:なぜアジャイルな計画づくりがうまくいくのか

11. ゆとりを残す

チームメンバー全員の時間を100%使い切るような計画を立てないこと。特にイテレーション計画では気をつけること。高速道路の限界100%まで車を詰め込むと、誰も身動きの取れない渋滞になってしまう。開発チームもこれと同じだ。メンバー個々の時間を限界まで使ってしまうと、プロジェクトの進みは遅くなってしまう。

はい、やってしまってました。イテレーション計画ミーティング時は作業時間見積もりをしてるのですが、このとき全時間を詰め込もうとして結局計画したものが全部終わりきらない。終わらないものを計画時に話すのムダだし、終わらなかったという事実はチームメンバーのモチベーション的にもいい影響を与えない。

なので、最近ではベロシティ(実績)ベースで考えるようにしようとしてます。普段大体これぐらいポイント消化できてるのだから、(作業時間はもうちょい余裕あるけど)計画するのはここまでにしておこう。で、おかわりできるならばそのとき考えよう、という方針にしてます。

チームがもっと成熟して毎回安定して計画したものを終わらせられるようになってきたならば、その次はいかにベロシティを上げていくかを考えていく感じ。もしかしたらその中で、作業時間のムダに着目していって、より効率的にタスクに取り掛かれるようになるかもしれないなーとは考えています。


いつもより長くなった。それだけためになる内容が多かったです。特に1章の「1. なぜ見積もりや計画づくりが必要なのか?」は常に意識しておきたいです。

あと、タイムリーなことに、先月の WEB+DB PRESS でちょうど見積もりの話がでてました。こちらも参考に。

WEB+DB PRESS Vol.93

WEB+DB PRESS Vol.93

*1:この辺は「7章:再見積もり」の「4. 部分的に完了したストーリーの再見積もり」も参考に。

「ピープルウエア」を読みました

事務所にあったやつをひっぱってきたので、最新でないちょっと古いやつ。名著と言われてたけど読んだことなかったし、今の立ち位置的に読んでおいて損はないと思って。

ピープルウエア 第2版 ? ヤル気こそプロジェクト成功の鍵

ピープルウエア 第2版 ? ヤル気こそプロジェクト成功の鍵

第 II 部:オフィス環境と生産性

騒音、特に電話の話。電話という点では、うちにはそこまで影響がないとは思ってます。が、(別チームの)ミーティングがうるさい問題は以前ちょっと感じてたので、その辺を頭に思い浮かべながら読んでました。

なお、つい先日事務所引っ越しして、ミーティングルームが増えたので、今はかなり改善されてるのかなと思ってます。

第 III 部:人材を揃える

採用における「能力テスト」についての説明が気になりました。

その人物は、能力テストで測られた作業を2年間で終え、他の作業を20年間やることになるかもしれない。

採用の際には、今できることという短期的な視点だけではなく、長期的にどうなりそうかを重視するのがよさそうだというのを、改めて考える機会となりました(もちろん、今までも無意識的にそういう風に考えていたとは思いますが、改めてということで)。

第 IV 部:生産性の高いチームを育てる

組織のビジネス的な目標、例えば「今期の利益を2倍にする」といったものが、ダイレクトに個人やチームの目標と結びつくかは分からないという話。この点も、うちではある程度解消されているのかなと感じています。というのは、自分たちが作ってるサービスを自分たち自身でも使ってるので、「サービスをよりよくすること=自分たちも楽になる」というのが分かりやすく実感できる目標なためです。

とは言っても、「自分たちのサービスをよりよくする」だけじゃ足りないところももちろんあるので、やっぱりその他やれることはやっておく必要があります。という点では、この辺かな。

チーム編成の目的は、目標の達成ではなく、目標に向かって一体になることである。

このチームの目的は満たされたとき、チームのメンバーはずっと効率よく働く。一体になったことでベクトルが合ったからだ。

これを達成するためにも、チームの目標が何なのかと、それを各チームメンバーにも意識付ける取り組みに注力しようとしてるところです。


全般的に、名著と言われるほどには自分が読み解けない点が多かった気がしました。もっと経験を積んだ後に読み直すと、また違ったものが見えてくるのかなあ。

「リーン開発の現場」を読みました

前回のカンバン仕事術でカンバンが気になってきたので、もう一冊カンバン系の本を読んでみました。少し昔の本ですが、カンバン仕事術が最近の本だったので、敢えて古めの本を手にとってみることに。

リーン開発の現場 カンバンによる大規模プロジェクトの運営

リーン開発の現場 カンバンによる大規模プロジェクトの運営

第3章:デイリーカクテルパーティーに参加しよう

30人から60人の大規模チームにおける、デイリースタンドアップミーティングの効率的なやり方について。

こんな感じで、3段階に分かれてそれぞれデイリーミーティングを行ってるようです。

  • 第1段階:機能開発チームのスタンドアップミーティング
  • 第2段階:スペシャリティ同期ミーティング(テスター同士のミーティングや、開発リーダーミーティングなど)
  • 第3段階:プロジェクト同期ミーティング(プロジェクト全体に関連するミーティング)

今の自分のチームの状況と照らし合わせると。規模がここまではないので3段階はやり過ぎ感があるけど、2段階で各チーム + 開発リーダーミーティング的なのはありかなと思いました。というのも、今は自分がハブになる感じで各チームとのミーティングを個別にやってるけど、それだとどうしても自分がボトルネックになりがちなんですよね。持続可能じゃない気がするので何とかしたいところ。

第16章:僕たちが学んだこと

「実験しよう」「失敗を抱擁しよう」とか、色々いい言葉が書いてます。時々、この辺の言葉を思い出したいです。

いくつか気に入った言葉をピックアップしておこう。

完璧な解決策を探そうとしてはダメだ。そんなものを期待して待ってもたぶん仕方がないだろう。
...
その代わりに、小さく少しずつできる改善点を探して、改善を実験だと考えてみよう。

失敗への恐怖が、改善の最大の敵だ。「なぜ俺達は失敗したんだ?誰がやらかしたんだ?」と問いただす代わりに、「僕たちは何を学んだんだろう?そして、次に何を試そう?」と聞いてみよう。

本当の失敗はひとつしかない。それは、失敗から何も学ばないという失敗だ。

たいていの人は変化を好む。でも、他の誰かに変えられるのは好まない。だから変化を起こすときは、影響を受ける人々をまず主体に巻き込まなければならない。

第20章:因果関係図

カンバン仕事術でも紹介されてたし、「なぜ5回」とかも呼ばれてるよくあるやり方だと思うけど、この本は説明が多く例が分かりやすかったです。これやらないと、何か気持ちモヤモヤしたままになったり、ひとまず一番最初に思いついた問題に対して(結果として表層的な)解決策を実施しようとかなったりするので、大事なことかなと思ってます。結構時間使うのでいつでもできることじゃないとは思いますが、ふりかえりと合わせて、自分も取り入れ始めてみました。

翻訳者の一人の@papandaさんのスライドも合わせて。

www.slideshare.net

おまけ:5分で理解するリーンな「かんばん」

本書でもとりあげられてますが、このサイトのマンガ、カンバンやWIPの制限の紹介に便利なのでよく引用させてもらってます。

lean-trenches.com

「カンバン仕事術」を読みました

ちょっと読むのに時間かかってしまった、カンバン仕事術。最初読んでるときは、カンバンもよさげな開発手法だなとは思いつつ、実業務の中で活かしどころがイメージできてなかったのですが、読んでるうちにちょっと霧が晴れてきた気がしたので、2周読んだ感じ。

カンバン仕事術

カンバン仕事術

カンバン3原則

カンバンって何となく、最初の「見える化」したものって思ってたのですが、それだけでなく「WIPの制限」とそれによる「流れの管理」も必須なんだなと理解できました。見える化だけでもある程度は解決するものもあるでしょうが、カンバンから継続的な改善を引き出すには後ろ二つが重要になってくると。

「流れ」対「リソースの稼働率

WIPとリードタイムについて疑似体験するゲーム、コイン渡しゲームの結果を受けての一言。

逆に、最後のイテレーションでは、リードタイムは短くなりましたが、それぞれの作業者の作業時間は長くなりました。効率が落ちたのです。ですが、チーム全体としては一番でした。

「WIPを小さくして流れを早くすると、個々のリソース(開発者)の効率は落ちる」ってのは、目からうろこでした。ついリソースの稼働率を気にしちゃうけど、稼働率が max なのがそのままユーザにとっての価値につながるわけじゃないですもんね。ならば、稼働率にとらわれ過ぎるのではなく、リードタイムを短くして流れを早くし、より早くユーザに届けることを意識するのは理にかなってると思いました。

そのままキャプチャで抜粋させてもらいますが、同様のことを言ってるやりとりがこちら。これはがつーんときましたね。意識改革が必要なんじゃないかと思ったところ。個人個人がそれぞれで動くのではなく、チームとして動くべき一つの理由になると思いました。


デイリースタンドアップ

他の手法でのスタンドアップミーティングとは違って、「個人の作業ではなくてチーム全体の作業・流れについて着目する」ってのはなるほどなと思いました。

多分、この辺のことを意識せずに普通にスタンドアップを開くと、「昨日やったこと」「今日やること」「困ってること」をそれぞれ個人に聞く形式をしそうだなと思ってました。だけど、カンバンでは「ボードを右から左に歩く」つまり完了に近い方から見ていって話し合うというやり方がいいようです。

f:id:ikikko:20160605021748p:plain


ほかにも色々実運用を考える際に参考になるところはあったのですが、大きく揺さぶられたのはこの辺ということで。カンバン使えそうな気がするので、もうちょい追ってみようかと思ってます。

「アジャイルコーチの道具箱-見える化実例集」を読みました

カンバン仕事術を先に買ってたのですが、京都遠征したときに@yohhatu, @posauneと話した際、まずはこっちを読んだほうがいいとアドバイスもらったので。

leanpub.com

いつでもさくっと確認できるように、iPhoneにPDFを入れておいた上で、気になるやつをブックマーク付けしておきました。ブックマークしたやつはいくつかに分類分けできそうなので、記憶の定着がてら、簡単に紹介します。

モチベーション上げる系

ちょっと反省点なのですが、ふりかえりなどでどうしても悪い点ばかり目について指摘しがちになってしまってます。言うべきところでは言わないといけないと思いますが、そればかりだとモチベーション的にもあーあーってなっちゃうので、悪い点を指摘するのではなくいい点を取り上げてうまくモチベーションを向上できるような仕掛けもやっていかないとなと、改めて思いました。

f:id:ikikko:20160508173203p:plain

  • 成果ポスター
  • 時間通りのスタンドアップ + ハイスコア
  • 遅刻はケーキ
  • ごほうびビン
  • 失敗ボード
  • レース場

なお、偉そうなこと言ってる割に自宅でのモチベーション管理がまったくできていないので、家でも導入しようかしら・・・


チームのコンディション確認系

↑のモチベーション上げる系にも関連しますが、チームのコンディションを手軽に見える化できると面白そうかなと思いました。口で「ツライわー」とはなかなか言いにくい人もいるけど、こんな感じでアイコンちょっこっと動かすぐらいなら朝会の前にでもぱっとできそうなので。

f:id:ikikko:20160508173253p:plain

  • 自信のニコニコマーク
  • ストレスレベルのメーター
  • チームのムードメーター

情報共有系

うちは拠点が分散してるのもあるので、通常以上に情報共有を意識しておかないといけないんですよね。その辺を見える化するためのやつもいくつか気にかかりました。

f:id:ikikko:20160508173307p:plain

  • サーバンドマネージャーのドア
  • 私の学びたいこと

アジャイルレトロスペクティブズを読みました

スクラム現場ガイドに引き続き、今回はアジャイルレトロスペクティブズです。日本語では「ふりかえり」ですね。

スクラムでもいくつかスクラムイベントが定義されてますが、その中でもこのふりかえりが一番大事なんじゃないかなと思ってきました。

アジャイルレトロスペクティブズ 強いチームを育てる「ふりかえり」の手引き

アジャイルレトロスペクティブズ 強いチームを育てる「ふりかえり」の手引き

レトロスペクティブの基本は、以下の構成に従ってるようです。

  1. 場を設定する
  2. データを収集する
  3. イデアを出す
  4. 何をすべきかを決定する
  5. レトロスペクティブを終了する

以下、それぞれ気になったことを簡単にピックアップ。

1.1 場を設定する

チームの約束(ワーキングアグリーメント)を最初に定めておいた方がいいと書かれてました。同時に、なぜワーキングアグリーメントが必要なのかの説明も。

基本的にはワーキングアグリーメントはチームそれぞれに特有のものになるから、他のチームがこうだからうちも真似しよう、というのはあまり意味がありません。とはいっても、どんなものを設定していいか、最初はよくイメージできないと思います。なので、うちのチームでは、下記のサイトを参考にさせてもらい、その上で自分たち特有のルールを話し合って決めました*1

blog.guildworks.jp

3.2 集団ダイナミクスの管理

「集団ダイナミクス」と言われるとちょっと分かりづらいですが、「集団力学」もしくは「グループダイナミクス」と言われることが多いみたい。詳しくは、グループ・ダイナミックス(グループ・ダイナミックス)とは - コトバンクとかを。

集団ダイナミクスを管理する際の一つのアドバイスとして、「あなたが言葉」ではなく「私が言葉」を使っていこうとあります*2。例として、

OK:あるチームメンバーがビルドを壊したメンバーを非難した。「お前がちゃんとやってれば目標を達成できたんだよ!」
NG:「私が怒っているのは、目標を達成できなかったことだ。あのビルドを修正するのはとても厄介なんだよ」

な感じ。相手を一方的に決めつけるのではなく、自分がどう感じたかをもとに話を進める。ファシリテーションの文脈でも結構大事な要素だと思います。

その他にも、参加者の感情の変化について、注意が必要な状況とその対処方法についても述べられてます。具体的には、下記のような行動を参加者が取った場合。

  • 怒鳴る
  • 部屋を出て行く
  • 不適切な笑い・おどけ

自分も心の準備なくこういう状況に遭遇するとすぐにテンパるので、予めシミュレーションしておくことは効果的だと思いました。

5.1 タイムライン

ここからは、レトロスペクティブを構成する各アクティビティの紹介。

タイムラインは、チーム内のイベントを思い出して、年表形式に洗い出していくもの。割りとイメージしやすいしGWで少し区切りができるので、さっそく使ってみました。

毎スプリントレトロスペクティブでやるというよりは、ちょっと長めの区切りでやった方がいいかなと思います。実際、うちのチームでやったときも1月から4月末までを思い出す目的で行いました。

6.6 ドットによる優先付け

出てきたアイデアのうち、どれを選択するかを決めるときに使う手法。参加者が、決められた数の投票権をドットとして持ち、アイデアにドット投票していくやり方です。

これもさっそく採用しました。うちは基本的に拠点が分散してるので、あまり複雑な手法は取りづらいのですが、これはドットを書いていくだけでいいので、シンプルに導入できました。

7.2 SMARTな目標

  • Specific (明確な)
  • Measurable (計測可能な)
  • Attainable (達成可能な)
  • Relevant (適切な)
  • Timely (タイムリーな)

の頭文字をとって、SMARTらしいです。

まあ個々はさておき、「計測可能な」というのが一番重要だと思ってます。計測できないと、達成できたかどうか分からなくて、結局流されてしまいますしね。

というわけで、何か目標を立てる際は「計測可能かどうか」を常に意識するようになりました。常に「計測可能なこと」が一番ですが、たとえ「計測可能かどうかちょっと曖昧」な状態でも、それを踏まえて次のふりかえりで問題があったかどうかを考えるようにしています。その結果、やっぱり計測可能にした方がいいと判断したら、改めて考えなおすことに。

7.4 短い話題

ここで、ふりかえりの手法として有名なKPTも挙げられています。

ただ、ここで触れられていたのは、こればかりやってると飽きがくるよとも言われてます。

イテレーションごとにレトロスペクティブを開いていると、1~2週間のインクリメントなどの短いイテレーションのときは特に、毎度おなじみのアクティビティにチームは飽きてしまう。

あまり色々やって、チームが新しいものに疲弊してもあれなので、飽きがこない程度にちょっとずつ新しいものを取り入れるなり、区切りでは別のアクティビティをやるなりを考えようと思います。

付録B 感想を聞くアクティビティ

ふりかえり中に問題を深堀りしていくことや、(ポジティブ・ネガティブ問わず)何かしらの意見を聞きたいことがあります。けど、「何で?」ばかり連発してても、聞いてる方は萎縮するときがあります。

このときのうまい質問方法について、少しだけ紹介されてました。何も意見が出てこないときに「何か一つだけ感想を述べるとしたら?」とか、まったく別の考え方をしてもらうために「もしも〜だったら」とか。

と、この辺のを読んでたときに、グッドタイミングで目に入ってきたので、また紹介しておきます。

blog.guildworks.jp


最後に、ファシリテーションについての参考資料として、- プロジェクトファシリテーションTOPが紹介されていました。今更ながらちゃんと読んでみて、そういやKPTの正しいやり方も知らずに亜流でやってたのがかなり凹む・・・。ちゃんと読んでおきます。

*1:厳密にはグランドルールとワーキングアグリーメントで適用されるスコープがちょっと違うみたいですが、まあ目的は大体一緒だから参考にするのはありかと思ってます。

*2:英語では"You language / You message"と"I language / I message"と呼ばれてるみたい。日本語より英語の方がカッコいいですねw

スクラム現場ガイドを読みました

最近全然できてなかったので、本を読む時間を増やそうとしています。合わせて、メモ的にでもアウトプットしておくことによって、読みっぱなしではなく、より自分の中に定着させようかと。

というわけで、最初はスクラム現場ガイドです。この本がどんなものかは、前書きから引用しますが、今の自分のフェーズに丁度合ってると思って、色々参考になりました。

スクラムアジャイルを始めようと思っていたり、まさに始めたところだったり、1年くらいやってきて道に迷ったように感じているなら、本書はあなたのためにある。僕は公式には、新たにプロジェクトを始めて6ヶ月から18ヶ月の12ヶ月の間にいる企業が対象だとしている。

スクラム現場ガイド -スクラムを始めてみたけどうまくいかない時に読む本-

スクラム現場ガイド -スクラムを始めてみたけどうまくいかない時に読む本-

まえがき

少なくとも3回はそのままで試してみて、結果を見て欲しい。

ってのは、忘れがちだけど大事だなと思いました。新しい取り組みをしてるわけだから、今までと違ってうまくいかないことも結構あるのですが、そこで安易にモデルを変えちゃうと、よく分からなくなるんですよね。

一方、うまくいかないことは改善するために変えていかないといけないですね。そこで、モデルを変えるのではなく、自分たちのやり方を変えていく、という自分たちが今どっちを変えようとしているのかは意識していかないとダメだなと思いました。

というわけで、モデルを変えないためにもモデルがどのようなものかは、上辺だけでなくちゃんと把握しておかないとだめだなというところが、今ここ。

第1章 スクラム:シンプルだが簡単ではない

「新しいやり方になったせいで、仕事は悲惨になったの?それとも前から悲惨だったのが目に見えるようになっただけ?」
「元々ひどかったんじゃないかな」「そうだよ、ここまでひどいとは今まで気づかなかったけど」

というやりとり。

うまくいかないときはプロセスに責任を押し付けたくなるけど、実はだめな部分が見えるようになっただけなんじゃないか?というのはいつも意識しておかないとですね。

第3章 チームコンサルタントでチームの生産性を最適化する

この本の中でも、一番革新的な内容だと思うこの章。

"チームコンサルタント"は、特定のチームに所属するのではなく、その人の専門性を活かして複数のチームをサポートする役割とされてます。社内にいる、特定分野の専門家ですね。デザイナーやUIに携わる人などが、イメージしやすいかなと思いました。

うちだと、まさにデザイナーやマークアップエンジニアが、特定プロジェクト専属というよりスポットでプロジェクトに入ることが多いので、図らずもそういう感じで動いてるところはありました。ただ、アプリエンジニアはそういう働き方はしてなかったので、今以上に組織をスケールさせるときに、こういうアプローチももしかしたら取れるのかなという、一つの引き出しにしておこうと思います(正直、効果があるのか?とか、効果があったとしてもうまくそういうアプローチにもっていけるのか?はまだ半信半疑ですが)

第5章 スクラムの役割

スクラムマスターの役割を、チームメンバーが交代で受け持つようにして成功したというチームの話もある。僕自身は試したことがないし、うまくいっているのを見たこともない。スクラムマスターが長期にわたる観点を持てないと、ただの管理者に成り下がってしまう。スクラムマスターに必要なスキルは特殊だし、とても重要な役割でもある。キャンプファイヤーで回し飲みするボトルのように考えてはならない。

ちょっと長いけど、ここはなるほどと思ったので。

スクラムマスターの仕事は、以下の三つとされてます。

  1. 高効率のチームを作り、維持する
  2. プロダクトオーナーに協力しつつ、プロダクトオーナーの意図をチェックしバランスを取る
  3. 組織を変える

割りとイメージしやすいのが1番目かなと思ってて、具体的にはデイリースクラムやチームのミーティング・タスク調整とか。で、この辺の見えている作業をこなすだけならば、持ち回りでやるとか開発チームが肩代わりしてやるでもいいかと思ってます。

が、具体的な作業は見えていないけどチームや組織・会社の大枠を改善するような施策は、交代制だと難しいんじゃないかなとは思ってました。ある程度チームが完成されてくれば、もう具体的な作業に落とし込めるものばかりになって、そしたらスクラムマスターもいらなくなるのかなとは思いますけどね。

なので、完成されたチームになって物事を具体的な作業に落とし込めるところを目指しつつ、そこに向かってどういう手を打つのが効果的かを大枠で考えることが、今の自分の仕事じゃないかなと勝手に考えています。

第8章 専任スクラムマスターの利点

スクラムを初めて取り入れるときによく言われるのが、「スクラムマスターを専任でおく余裕がない」ってことだと思ってます。それに対する一つの回答が、この章に書いてありました。

この章いわく、スクラムマスターが開発チームと兼任した場合と専任した場合の、それぞれおチーム全体の生産性向上率は、大体こんな感じになるようです。

  • 兼任時の生産性向上率:110~125%
  • 専任時の生産性向上率:180~200%

こうやって数値として出るのであれば、専任した方がすごく価値があることかなと思いました。もちろん、専任したら誰でも200%の生産性向上につながるわけではないので、そこに向かって努力はしないとですが。