Scrum Inc. Japan さんの２日間にわたる「Scrum Inc. 認定資格スクラムマスター(RSM)研修」を受けてきた。


↑研修の最後に撮影した集合写真

研修プログラム自体も スクラム風になっていて、非常にわかりやすく、理解が深まった。
研修内容は受けてみてのお楽しみということで、受けてみての所感、特に気づきがあったことを中心に残しておく。
（したがってできるだけ自分の言葉で書いています。）

研修の特徴

座学だけでなく、グループワークやQAが充実していた。特に、質問は随時受け付けてくれるため、しっかり課題を持って研修を受けると、疑問点がクリアになった。
座学も、実際の例や適応例などを交えて伝えてくれるため、非常にわかりやすい。
加えて、研修終了後のwebテストを受けて合格すると、「Scrum Inc. 認定資格スクラムマスター(RSM)」の 資格がもらえる！（私もいただきました）


↑研修の様子

「スクラム」とは

アジャイルな開発を実現するための「フレームワーク」のこと。下記の３本の柱の元にシンプルなルール（３−５−３）があり、基本的な考え方とルールを押さえることでアジャイルな開発を実現できます。ウォーターフォールに慣れた人にとってはかなり大きなマインドチェンジが必要ですが、スクラムパターンなどある程度のプロジェクト運営上の定石・テクニックが提唱されており、それらを学ぶことでより成功率が上がるものと考えられます。

  • 経験的プロセスによる統制の三本の柱
  • 透明性（＝見える化）
  • 検査（＝振り返り）
  • 適応（＝再計画・軌道修正）
  • シンプルなルール（３－５－３）
  • 3つの役割
    ・PO（プロダクトオーナー）
    ・SM（スクラムマスター）
    ・開発者
  • 5つのイベント
  • スプリント
    ・これがスクラムの最大の特徴。1～4週間の短期間で区切り集中して成果を出し続ける。
  • スプリントプランニング
    ・１スプリントの計画を立てる。
  • デイリースクラム
    ・毎日実施。朝会、夕会、など。進捗確認→都度方向修正。
  • （バックログリファイメント）
    ・プロダクトバックログの見直し、修正。随時行う必要があり５つのイベントには含まれないが重要な要素。
  • スプリントレビュー
    ・実装した機能（＝インクリメント）のお披露目！
  • スプリントレトロスペクティブ
    ・いわゆる振り返り
  • 3つの作成物
  • プロダクトバックログ
    ・作成する機能（アイテム）のリスト。優先順位の順に並んでいる必要がある。
  • スプリントバックログ
    ・そのスプリントで作成する機能（アイテム）のリスト。こちらも優先順位の順に並んでいる必要がある。
  • プロダクトインクリメント
    ・そのスプリントで作成したプロダクト（「インクリメント」という名がついているが、その回の「増分」だけでなく、その増分を含めた全体を指す）


↑研修にて私の班で作成したスクラム の図解まとめ

「アジャイル」との違い

「アジャイル」は思想、マインドセット
「スクラム」は手法、フレームワーク
アジャイルな開発を実現するための開発手法はスクラムだけではないようだが、スクラムが現状広く認知・実践されている。
言い方を変えれば、「アジャイル開発」はアジャイルな思想を根幹においた開発全般を指し、代表的な手法としてスクラムが行われるケースが多い、ということ。

アジャイルの「４つの価値観」と「12の原則」

コピペになるので省略。要すると、下記２点に集約されるかな、と。

  • 変化に対応できる、効率的で自己組織的なチームであること。
  • 動くプロダクトをいち早く顧客へ提供しフィードバックを得て改善していくこと。
    とにかく早く顧客のフィードバックを得てどんどん改善していこう！それができるチームでいよう！という考え方だと理解した。

ウォーターフォールとの違い

  • ウォーターフォールは
  • 初期計画（＝定義されたプロセス）とのズレを最小限に抑える
  • トップダウン体制
  • 請負契約が推奨
  • 発注側と請負側が疎結合に感じる（私発注する人、あなた開発する人、これを責任もって作ってね、あとよろしく！な感じ）
  • スクラムは
  • より短い時間で集中して動くプロダクトを提供→フィードバックを繰り返す（＝経験的プロセス）
  • 自己管理型組織（マネジメントを不要とする）
    ・ ただしリーダーシップは必要
  • 準委任契約が推奨
  • 発注側と請負側が密結合（一緒にチームを形成し、同じ目標に向かって動いていく）で、より一体感をもったチームビルドが要求されるように感じる。
    ・ 顧客側（POを務めることが多い）もスクラムとアジャイルの価値観への深い理解が必要。
    ・ 開発側には、言われたものを作ればよいのではなく、ビジネス的な視点を持って顧客の目標を共有する姿勢が必要。
  • 発注側、受注側が、より相手を理解した上で取り組む必要がある、と言えそう。

ウォーターフォールでも、アジャイル的な思想を持って開発を行うことは可能（実際、行っている）と感じた。もちろん、「可能」というだけで、適してはいない（スクラムの方が適している）。

スクラムを実施するためのギャップ

大きくは２点あると考える。

  • 複数案件並行を少なくし、できるだけひとつのプロジェクトに専任させる
    ・ ワインバーグの表：掛け持ちは効率✗　せめて、ひとつのチームで複数プロダクトを扱い、スプリントによってわける
  • 開発メンバーが全員ひとりの「専門家」であり、PMのような責任感を持った主体的な関わりが「メンバー全員に」要求されること
    ・ 指示する人間がいないため、メンバー間の温度感の差が看過できなさそう。
    したがって、思想的なギャップを解消していくことが必要。

加えて、下記も必要（下記は、やろうと思えばできそう）

  • そもそもスクラム用語の理解が必要。難しくはないが、30分とか１時間で説明できる内容でもない。
  • スクラム経験者を増やし、プロジェクトに最低ひとりはスクラム経験者がいた方が良さそう。
  • CICDを構築し、短いスプリントで回すための環境が必要
    ・ 自動テストをもっとデフォルトに。
    ・ ただし、必ずしもスプリント 毎にリリースする必要はなく、いくつものスプリント の最後にリリースする計画でも良い。その場合は、リリースバーンダウンチャートを描く。
  • 顧客がPOを務める場合、POを務める担当者もスクラムに対して深い理解が必要。そうでなければ、開発を受注する側でPOを立てる場合もある。
徐々にスクラムに移行していくことも可能。導入できそうなところから導入していってよい。

ただし、スプリント を導入したり、マインドチェンジを行ったりといった、大きな転換は生じる。

そもそもスクラムよりウォーターフォールの方が適しているパターン

ステイシーマトリクスで判断する。

  • 作りたいものが明確で、技術的にもリスクが低ければウォーターフォールが効率が良い。
  • 作りたいものが不明確、または、技術的にリスクがあれば、 スクラムが向いている。
  • 作りたいものが不明確でかつ技術的にも不確実なら、プロジェクトにするにはまだ早い。

３つの役割（スクラムチーム＝PO+SM+Ds）

スクラムにはPM、PL、TLといった役割はなく、下記３つの役割があると明確に決まっている。これが特徴的だと思うので、特記しておく。

PO（Product Owner）

文字通り、プロダクト（製品）に対して責任を持つ。
ユーザーの要望や必要な機能を一番よく理解し、「プロダクトバックログ」という優先順位付きのタスクリストを作成し、プロダクト全体の品質やリリーススケジュールを担保する。
whyを語り、whatを指示する（＝プロダクトバックログ）。
howは開発メンバーに委ねるのが理想。

SM（Scrum Master）

開発メンバーが仕事しやすいように動く縁の下の力持ち。
コーチ兼ファシリテーター。
スクラムチームのプロセス（仕事の仕方、働き方）に対して責任を持つ。
PLに近い感じがするが、技術的な責任は持たないし、タスクを割り当てたりもしない。
その代わり、決めたことを守らせ、うまくいっていないルールややり方を改善するよう促し、メンバー個人のパフォーマンスやメンタル、メンバー間のトラブルなどを客観視し、作業の見える化やプロセス改善に責任を持つ。
一般的に、開発メンバーが優秀になればなるほど、SMのやることは減るとされているが、他にもやるべきことは多い。

  • ワーキングアグリーメントを作成させ、守らせる。
  • スクラムパターンを把握し、実行する。

D（Developer）

開発メンバー。それぞれが専門家として、作業の計画からスプリントのスケジュールや品質に責任を持つ（=「how」に責任を持つ）
プロジェクトマネージャーはいないため、誰もがプロジェクトマネージャーの責任を果たす。

心にぐさっときたこと

ストレッチゴールは士気を下げる

「経験的プロセス」から次の計画を立てるスクラムだが、過去の実績から、上乗せした目標（＝ストレッチゴール）を設定することは逆効果とされている。なぜなら、たくさんこなせばこなすほど次の目標が上がり、目標を達成できないことが増えるとだんだんと疲弊してくるものだから。チームの生産性が上がれば、自然と目標を超えて達成することが増え、自然と過去の実績のベロシティが上がってくる。

かけもちはすればするほど非効率（スイッチングにリソースをとられる：ワインバーグの表）

こちらも研修の中で体感することができた。複数タスク持つことで、人員調整がしやすいように見えるが、本人の作業効率はガクッと下がる、とのこと。４つ５つとかけもちした日には、リソースの半分以上をスイッチング（頭の切り替え）に割かれることになる。
生産的で効率的な開発を目指すなら、スウォーミングと同様、集中してひとつを片付けてから次にとりかかる、ということができるような環境づくりが求められる。

結果、自分のプロジェクトでスクラムができるようになるのか？

結論はすぐには出ないが、定期的な振り返りの期間を短くするなどして「スプリント」を導入したり、チームの一体感を出すためにデイリーを導入したりと、できるところから取り組んでいくことはできそう。あとは、これらの内容を自分がきちんと理解し、この研修を受けなかった同僚にもきちんと説明できるようにしていきたい。
あとは実践あるのみ！というところまで導いてくれるとても有意義な研修だった。