前置き
この度、ご縁あってこちらの記事の内容でFindyさん主催の 『「脱！なんちゃってスクラム」実践事例から学ぶ Lunch LT』 に登壇しました！
もし、よろしければアーカイブご視聴ください！
当日、発表で使用したスライドも載せておきます。併せてご確認いただけるとより理解が深まると思います。
はじめに
今の会社に転職してきて２ヶ月が経ち、まだまだ分からないことも多いですが少しずつ環境にも慣れてきたので頭の中を整理するためにも今感じていることをアウトプットしたいなと思い書きました！
現在、私が参画しているチームはスクラムをベースとして開発を行なっており、前職もスクラムでの開発を経験していたので、その違いを整理していきます。
前職 スクラムを導入するまでの背景
前職では、美容医療・精神科クリニックを運営している会社で、クリニックスタッフが使用する社内システムの開発に携わっていました。働き方としてはフル出社になります。
チーム構成は以下で、私はメンバーでした。
チーム構成（7名）
- ディレクター(PM) 1名
- リーダー 1名
- アーキテクト 1名
- メンバー 4名
はじめからスクラムを導入していた訳ではありませんでした。
開発の流れとしては、クリニックスタッフまたは関係者からディレクター（PM的な役割）に要望があり、リーダーとアーキテクトに課題が共有されます。アーキテクトの方が画面設計や仕様を詰めていき、そしてリーダーからメンバーにタスクが割り振られるという、いわゆるトップダウンの形でタスクをこなしていました。ファクトリー型よりのアジャイルなイメージです。
しかし、リーダーの方が退職されたことをきっかけに自律したチームづくりを目指すという名目でディレクターからスクラムを導入しましょうと提案がありました。
その数ヶ月後にディレクターも退職してしまい、そのためにも導入したんだなと。。
前職でのスクラム
チーム構成(6名)
- PM（ディレクター）
- スクラムマスター（SM）
- プロダクトオーナー（PO）
- メンバー 3名
そんなこんなでスクラムを導入することとなり、チーム内でスクラムを経験したことがある人は誰もいなくディレクターの方だけが理解している状況でした。
SMは責任感の強いメンバーの方が担当され、POは自分ともう1名候補がいてルーレットで私が担当することになりました。。
POといっても、基本的なスクラムの役割とは異なっていて、スプリントの進捗確認やスプリントレビューで画面共有しながら、今スプリントでのタスクがしっかり実装されていることを確認するといったことが主でした。
とりあえず一通りのスクラムイベントは行いましょうという話合いになり、デイリースクラム・スプリントレビュー・スプリントレトロスペクティブ・スプリントプランニングをスケジュールに組み込みスタートしました。
バックログリファインメント
スプリントプランニングの中で実施し、ディレクターからタスクの説明をチームに行います。そのタスクに関しての質問・不明点をメンバーに問いかけ、実際にどういった作業が必要になるか列挙していきBacklogに課題を切っていきます。
例）マイグレーション・モデル・ファクトリの作成、APIの作成
質問がなくなったらプランニングポーカーを実施して開発工数を設定します。
スプリントレビュー
POが主体となり画面共有しながらディレクターとチームにタスクの実装確認を行なっていました。
私自身がこれはPOの業務だと思い、あまり周りのメンバーに助けを求めず、どのタスクに対しても私が共有しながら確認し説明するということを行なっていたので正直辛かった面が多かったです。
お通夜ミーティングのような雰囲気で圧迫感もあり、今思うと心理的安全性が低い状態だったんだなと思います。
毎週火曜日にスプリントレビューを行なっていたんですけど、火曜日は憂鬱でした。。
全てPOから説明しなくても良いのではというSMの助言もあり、次第に実装したメンバーに説明してもらうなどのサポートをお願いしていました。
現職でのスクラム
チーム構成（6名）
- スクラムマスター（SM）
- プロダクトオーナー（PO）
- メンバー 3名
- フリーランス 1名
そんな前職でのスクラムだったのですが、現職はHR系ベンチャーの社内システムに携わっています。働き方としては週に1回対面でのスクラムイベント（スプリントレビュー・スプリントレトロスペクティブ・スプリントプランニング）があり、それ以外はリモートになります。
スクラムでの役割はメンバーになります。
参画して早々、対面でのスクラムイベントがあり緊張していました。けど前職でのスクラム経験もあるから大体同じ流れだろうとその当時の私は感じていました。
ところが、まずはじめに行ったのは「偏愛マップ」というワークショップでした！
自分の好きなものや興味があることをMiroでまとめ各々発表するといったことを行いました。
それが終わった後は、「ムービング・モチベーターズ」というマネジメント3.0のゲームを行い「仕事に対するモチベーション」というテーマのもと、上位３つまでそれぞれ発表を行いました。自分がどんなことを大切だと思っているのか改めて考える機会でもあり、チームメンバーがどんな趣味・価値観を持っているのかを知る機会にもなってすごくよかったです。
それらのワークショップを提案してくれたSM（@YUM_3）をはじめ、フリーランスの方もチームの関係性を一番大事にしているなど、チームとしてオープンマインドをすごく大切にされていて、発言しやすい環境づくり・心理的安全性が高いチームを意識しているんだなとすごく感じました。
バックログリファインメント
「実例マッピング」というワークショップを用いながら週に２・３回程行っています。時間は1時間で区切って行います。
こちらは開発チームだけでなく、ステークホルダーの方々にも参加していただいてます。ユーザーストーリーをもとに現状の痛みとなっていることは何か、痛みとなる実例のケース・実際の使われ方のイメージ、実例としてこうなった場合はどういう挙動になるかなど列挙していきます。
列挙した実例にそれぞれ回答していくことでルール(≒ 仕様)を固めていくといったものです。
それに加えて、ユーザーストーリーが抽象だった場合は発散系の実例マッピングで行うや、具体だったら収束系の実例マッピングで行うといったことも最近は意識して行っています。
実例マッピングについて
実際に開発チームで行っている実例マッピングについて興味がある方は
【実例マッピングを実施し、チームでやり方を標準化するまでの過程の話】
↑ こちらの記事を読んでいただくと詳細が掴めるかと思います！
この記事を書いた野澤さん（@TairaNozawa）は、同じ開発チームのPOとして一緒にプロダクト開発をしています。
実例マッピングを導入した背景からチームでやり方の標準化まで詳細に書いてありますのでぜひ興味がある方は読んでみてください！
スプリントレビュー
その時のスプリントゴールの内容的にステークホルダーの方々にも参加していただくべきか検討します。
単なるレビューの場となるのではなく、ステークホルダーからフィードバックをいただいたり、実際に操作してもらい直感的に操作することができているか開発チームが感じとる場とすることを意識しています。
現職と前職のスクラムの違い
以上が前職と現職での大まかなスクラムになります。
私の所感をまとめると以下の図のようになります。
特に開発時間は前職と比較するとだいぶ短くなりました。前職では、デイリースクラムを行った後はひたすら開発して1日が終わるということが結構ありました。これはバックログリファインメントにかけている時間が大きく異なるからです。
前職では、ユーザーストーリーがあらかじめ具体になっている状態でスタートするため、あとは実装方法・必要になる作業を洗い出すだけでよかったという文脈があったからです。
ただ、この進め方だとステークホルダーが求めていたものとは異なるケースが発生しそうなのですが大幅な手戻りが発生したことはあまりなかった記憶があります。
これはディレクターの方が今まで大企業で働かれていた経験、能力が非常に高い方だったということもあり、ステークホルダーからの要望を汲み取って要件にする能力が長けていたため発生しなかったのかなとも思っています。
前職を振り返ってみて
振り返ってみるとチーム内であまり雑談できていなかったなと思います。年に４回だけある飲み会の場で、メンバーの趣味知ったりだとか。。
デイリースクラムでも進捗共有の場になってしまっていたり、フル出社という働き方で横に他事業部がいて、あまり長く雑談できない環境ではあったと思います。
それでもデイリースクラムに雑談の場を少し設けたりなど改善の余地があったなと思い、適度に雑談を挟むことは、発言しやすい環境づくりに繋がるなと個人的にも実感しました。
私が伝えたかったことは決して前職のスクラムが酷かったということではないです。
チームとしてスクラムの知見がなかったこと、熟練度が低かったことなど仕方ないことだと思います。私自身も当時は技術面でのスキルアップの関心度が高く、組織開発やチームビルディングに関しては関心度が低かったです。
大事なのは、その体験をした上で、チームとしてどうやって進めていくのが一番効果的かチームで模索することだと現職のスクラムを通じて感じました。
前職だと、ブラックボックス化してしまっていたステークホルダーとディレクターとのやり取りをMTGに参加し聞いているだけでも全然違ったと思います。ディレクターを通して二次情報で知るよりも、生の声を一次情報で聞く方がステークホルダーと開発チームで共通認識も深められると思いますし、ディレクターの負担軽減にも繋がったと思います。
最後に
現職と前職のスクラムを通じた上で、チームビルディング・チームでのカイゼン・ステークホルダーを巻き込んだ開発の大切さを知りました。
あの時、こういうことを提案できていたらもっと良いチームができたかなと考えさせるきっかけを与えてくれた今のチームには感謝しています！
現職でのスクラムも一朝一夕で出来上がったものではなく、SM・POをはじめチームとして紆余曲折あった中で自分たちなりのチームを確立していった結果なのだと思ってます。
そうした環境で働けていることに感謝しつつ、チームとしてカイゼンしていけることを私も提案し、更により良いチームを作っていきたいなと思ってます！
ここまで読んでいただき、ありがとうございました！