転職してまたスクラムをはじめて感じたこと
転職後、スクラムをはじめて感じたこと
はじめに
転職をしてから異なる組織でスクラムからは離れていましたが、またスクラムに関わる機会を得ました。
前職、現職の2つの組織でのスクラム経験を通じて、スクラムの実践方法やチーム組成は組織の環境変数（要因）で変わるのを実体験を通じて感じました。
まだ1スプリントが完了したタイミングで、今後いろいろな課題に遭遇しそうですが、個人的な整理のために感じたことをまとめておきます。
この記事では、転職前後でのスクラム実践を通じて感じた5つを共有します。
前提：転職前後の状況比較
以下に転職前後の環境変数を記載します。
前職でも、現職でも基本的にスクラムマスター的な立ち位置でのチーム参画をしています。
| 項目 | 転職前の状況 | 転職後の状況 |
|---|---|---|
| スクラム導入アプローチ | トップダウンでの導入 | ボトムアップの提案での導入 |
| プロダクト | B2BのSaaSプロダクトでの新プロダクト開発 | B2BのSaaSプロダクトでの既存プロダクト開発 |
| 技術スタック | 新規技術領域で手探り状態 | 既存プロダクトと同じで確立済み |
| ドメイン知識 | メンバーに豊富な知識あり | メンバーに豊富な知識あり |
| 自分の役割 | EM、アジャイルコーチ的な立場でのスクラムの外側からサポート、スクラムイベントには参加 | 専任スクラムマスターとしてチーム支援 |
| PdMのスクラム経験 | スクラム経験者なし | スクラム経験者が存在 |
| 研修・教育 | 3か月程度のスクラム研修・教育期間を確保 | 1週間程度 |
前提：なぜスクラムを導入したのか？
転職後のプロダクトでは、チームのサイズが大きくなってきて現状の開発プロセスだと、PdM、デザイナー、開発者の3者間のコミュニケーションが重くなっているという問題があり、仕様確定や画面UIのデザインの決定がオーバーヘッドになっています。
そのオーバーヘッド解消にスクラムが刺さるのでは？という仮説のもと、開発チームのメンバーを一部切り出してスクラムチームを組成しました。
まだ、パイロットチームの段階でこの試みがうまくいったら適用範囲を拡大していく予定です。
感じたこと5つ
1. 不確定要素が少ないとストーリーポイントの見積もり精度が高い
転職前は新規技術スタックの新プロダクト開発、転職後は既存プロダクト、既存技術スタックでのスクラム導入という違いがありましたが、1スプリント目の、ストーリーポイントの着地見込み精度はやはり、既存プロダクト、既存技術スタックの方が出ているなと感じました。
経験に基づいていることが見積もり精度に大きな影響を与えているな。と、だったらウォータフォール開発でも良さそうに思いますが、解決したい課題はコミュニケーションのオーバーヘッドだったので、当たり前のことに実感をもって気づいたという形になります。
前職は逆に不確定要素が多すぎだったのでは？というのがあり、変数減らしての実験をできる状況作りが大事なのでは？とも思ったりしました。
2. 組織固有のスクラム慣習
転職後はスクラム経験者がPdMにいて、スプリント0で各イベントの目的や進め方を擦り合わせる機会がありました。
筆者の方で、各イベントのアジェンダ、Readyの定義と、Doneの定義のドラフトを作成し、それをベースにディスカッションをしました。そこで過去のスクラムでの状況の違いで一部の議論が白熱しました。以下2点は大分乖離があり、勉強になりました。
- リファインメントで確保する時間枠と議論する内容
- ストーリーポイントの見積もり方、バグに対してポイントを付与するか否か？
このあたりはお互いの折衷案採用になる部分と、最終的な状態は一致するので、どちらかのやり方に寄せるやり方で意見がまとまりました。しかし最終的な形よりも、議論の過程で大分理解が深まった状態になりました。スクラムはガイドが薄くて、「正解」のない領域、複数の「正解」がある領域が存在します。異なる組織での経験を持つメンバーとの対話は、新たな視点を得る機会なのだと感じました。
ディスカッションの前後に、以下のような記事を確認していたので、参考情報として、貼っておきます。
-
プロダクトバックログリファインメント
-
ストーリーポイント
3. プロダクトオーナーの権限構造の違いを感じた
観測した範囲だと、以下の2点でスクラムを導入した時の効果が変わってくるな。。と思いました。
- スクラムのプロダクトオーナーのロールを誰が担当するか？
- PdM組織がどの程度の権限を保持しているか？
組織規模にもよると思いますが、開発者はPdMだとアプローチがしやすいので、PdMが組織上で強い権限を持ってくれると、スクラムを導入したときのメリットが強く出る感はありそうに思いました。
転職前後の状態の違いは以下の通りです。
| 項目 | 転職前 | 転職後 |
|---|---|---|
| プロダクトオーナー（担当） | Lead PdMがプロダクトオーナー担当（組織内での権限は限定的） | Lead PdM配下のPdMがプロダクトオーナー担当 |
| 仕様決定権限 | 仕様決定権限は事業責任者が保持 | Lead PdMが仕様決定権限を保持 |
| スプリントレビューの参加者 | 事業責任者がステークホルダーとして参加 | Lead PdMがステークホルダーとして参加 |
共通して、権限を保持している人は捕まりにくく、スクラムの開発スピードに影響があるため、できる限りプロダクトオーナーへの権限委譲は進めるべきとも思いました。
また、現職ではプロダクトオーナーにスクラムマスター経験者がいて、そこに由来する推進のしやすさがあります。
4. スクラム学習期間
前職時代は、3か月程度の研修期間を設けて、スクラムの座学、実際にやってみるところを研修として実施していました。
現職では1週間程度のチームビルディング期間のみで実際の開発を行いました。
この状況だと、スクラムチームにスクラムの三本柱のチームへのインストールが不十分な感覚をもっていて、この状況だとスクラムマスターの存在がとても重要になると感じました（チームの状況を見ながら、必要な知識やプラクティスをインストールする）。
チームへのスクラムのインストールができていない状況だと、よりプロフェッショナルなスクラムマスターが求められる気がしています。
5. ファシリテーション実践からの学び
前職ではスクラムチームを外から支援する観察者として、スクラムチームとの関わりを持っていました。
転職後はスクラムマスターとして、スクラムイベントのファシリテーターを実践していますが、ファシリテーションを実践することでの学びは大きいなと思いました。場の直接的なコントロールが容易で、アジェンダの微調整など、詳細な課題も把握できるようになりました。
一方で、コントロールとリードのバランス調整が重要な課題です。過度なリードはチームの自立を阻害する可能性があります。
現在の状況では、当面はスクラムマスターによるリードが必要と判断していますが、段階的にチームにファシリテーションを委譲していきたいと思います。
今後やろうとしていること
現状は、パイロットチームなので、まずチームのスクラムのプロセスを確立させることに注力したいと考えており、以下のことに取り組みたいと考えています。
-
スクラムの基礎知識の段階的インストール
スクラムの3本柱と、価値基準のインストールができていないと感じられ、各スプリントで、1つの価値基準を深掘りしていくのが良さそうに思っています。 -
Doneの定義の説明、Doneの定義の修正
Doneの定義は作成しましたが、今の段階だと機能しているとは言えない状態です。
2-3スプリント後までには、Doneの定義のインストールがされたスクラムチームになるのが良いと思っていて、その状態が作れるようにしたいと考えています。
まず、守れていないDoneの定義の項目と、実際に実行するにはどうすれば良いのか？という議論、議論の末のDoneの定義の修正を実施していきたいです。
- 既存プロセスとの開発生産性の比較
パイロットチームなのでどこかそう遠くないタイミングで、既存プロセスと比較した評価を求められます。
組織構造や仕事の進め方で、どのようなメトリクスを設定するのが良いかは変わりそうに思いますが、現職では、開発着手からプロダクトオーナーの承認までの期間をまず比較するのが良さそうと考えていて、その期間の比較から始めてみようかと考えています。やりたいことは、以下の記事の内容が参考になりそうだなと思っています。
カンバンの指標をスクラムイベントの改善でどう活かすのか | サーバントワークス株式会社