こんにちは、DevBrandingのellyです。2月4日に配信した「期日じゃなくて優先度を決めろ！悩めるスクラムマスターの本音」の様子をご紹介します。
今回はスクラムマスターの2人を招いてfreeeがどのようにスクラムに取り組んでいるのか、専任スクラムマスター、兼任スクラムマスターそれぞれの立場からの悩みや葛藤、取り組みの工夫について話してもらいました。
Takeru Ichii: 写真左上。2017年10月入社。IAM（=Identity and Access Management）チームで専任スクラムマスターを担当。
sayoshi :写真右上。2020年新卒入社。freee人事労務のエンジニア兼スクラムマスター。
のぶじゃす (@noblejasper): 写真右下。ラジオパーソナリティ、2017年に中途入社。mixi、ソーシャルゲーム企業でソフトウェアエンジニアを経験し freee に。入社後はエンジニア→エンジニア採用担当→エンジニアと DevBranding を担当。しゃべりたがり。声が大きい。
専任・兼任スクラムマスター
―Ichiiさんはアプリケーション基盤系の専任スクラムマスターを担当しているんですよね。
Takeru Ichii:そうですね、主に認証認可と呼ばれる部分でログイン・ログアウト、サインアップみたいなところを担当しているチームの専任スクラムマスターです。
―sayoshiさんは兼任スクラムマスターなんですね。
sayoshi :そうですね。スクラムマスターの責務の一つでもある「スクラムをチームに広める」というところをミッションとして持ちながらエンジニアもやりつつという感じです。ところによってはアンチパターンと言われる形だったりはします。
―それぞれの立場で違った悩みがありそうですね。今日は解決策をお届けするというよりはスクラムマスターってこういう悩みがあるよね、ぶっちゃけこうだよね、うちの場合はこういうふうにやっているというのを共有できたらいいですね。
freeeのスクラム開発事情
―まずはfreeeでのスクラムについてざっくり全体感を教えてください。
Takeru Ichii:freeeは全チームでスクラムをやっているというわけではないです。だいたいのチームでアジャイルプラクティスの導入はやっているんですけど、アジャイル開発を全体で採用しているというわけではなくて、スクラムチームがいくつかあるという形でやっています。正式にスクラムをやっているとしているチームはだいたい10チームくらいだと思います。
―かっちりスクラムをやっているという定義は難しいですからね。
Takeru Ichii:そうですね、ずっとスクラムでやるというよりは、スクラムから進化してチームに合った独自の方法を編み出すところもあります。振り返りをやっていく中でスクラムのフレームワークとは別のものを取り入れてみよう、取捨選択していこうみたいなことは起きていると思います。
―基本的にはアジャイルなんですか？
Takeru Ichii:アジャイル開発をしているというよりは、アジャイルプラクティスを導入しているというのが近いと思います。
―各チームがなぜスクラムを始めたのかを教えてください。
sayoshi :僕はもともとスクラムをやってるチームにジョインしたという感じで、スクラムを始めたときにはいなかったのでどういう課題感を持って始めたのかは僕の体験談として持ってないんですが、過去のドキュメントを見ると、QAとのコミュニケーションが疎遠になってたり、差し込みタスクの優先度決めを誰がやるんだっけとか、振り返りがプロジェクト単位になっていて単位が大きくて準備も大変だし忘れてしまうといった問題があって、スクラムを始めたという経緯があります。
―QAやPM、Biz側とのコミュニケーションがスポットになってしまうというのはあるあるですよね。現状は一緒にやれている状態なんですか？
sayoshi :ちょっとずつできるようになってきてるんじゃないかなと思っていて、開発チームの中ではいわゆるアジャイルな状態でコミュニケーションを頻繁に取りつつ、仕様の変更を確認したり、スクラムイベントにはBiz側の人も呼んで現状の状態を共有したりしています。
Takeru Ichii:僕のチームも僕がスクラムマスターとして入る前からスクラムをやっていたんですが、当時は認証認可に加えてユーザーに近いプロダクトを持ってやっていたのでスクラムが導入しやすかったんだと思います。
認証認可のほうで大規模なリプレイスプロジェクトが始まって、そこでスクラムマスターを担当しました。LeSSという大規模スクラムのフレームワークを導入したんですが、これがかなり苦戦していて、いまのIAMチームでも続けてそのリプレイスプロジェクトを担当しています。あとは、実は他のチームのスクラムマスターもやっていたりします。
―スクラムマスター自体を兼任しているんですね（笑）
期日より優先度が重要
―リプレイスプロジェクトや兼任しているチームのスクラムで、困ったり悩んだりしていることはありますか？
Takeru Ichii:リプレイスプロジェクトって、ある程度期日への期待があって、一気にやらないといけないし人もたくさん集めないといけないというのがあって、いろんなところでプレッシャーが強いというのがあります（笑）
―リプレイスされることによるメリットが大きいからこそ期待が強いということですよね。
Takeru Ichii:そうですね、機能を足すことはあまりないけどリプレイスするとバッチサイズが大きくて一発でリリースする規模がでかくなりがちなのでアジャイルな動きが難しいと思う部分があります。だからこそ少しずつでも進められるようにプロジェクト管理手法としてスクラムを選択したというのはあると思いますが。
あとは、リプレイスプロジェクトって既存のコードの挙動をけっこう追わないといけなくて不確定要素が多いというところも苦労しているポイントです。実際に作っていた人であれば分かるものでも、扱う人が全員知っているわけではないので不確定要素が多いです。なので期日を決めると作ってる側としては辛いです。
―タイトルにもありますが、なぜ期日より優先度が重要なんでしょうか？
Takeru Ichii:期日を決めすぎると、別の先の期日が近づいてくるとそっちにリソースをとられて、いま目の前でやっているタスクが遅れることがあるんですよね。我々のプロジェクトでもそれが起きました。やっぱりちょっとこっちも進めなきゃいけないよね、じゃあそろそろここのチームも安定化してきたから人を引き剥がして別のプロジェクトにあてましょうみたいな話っていうのは結構ありますよね。期日が決まっているのに進んでいないと不安が募るので進めたい気持ちは分かるんですが、そういうところが辛いなと思いました。
―タスクAがいちばん近い期日だけど、タスクAが少し遅れるとタスクBの期日も近づいてきて、結局並列作業が発生してしまい、結果コンテキストスイッチングのコストがかかりさらに遅れるということですよね。
Takeru Ichii:そうですね、とはいえ期日を決めないのも実際はなかなか難しいとは思いますけどね。説明するのも大変なので。
―期日ありきのものもありますよね、例えば確定申告は日付が決まってるし、これは期日じゃないんですか？
Takeru Ichii:それは期日になりますね、その中で何が一番価値があるか、何を一番実現しないといけないのかというコアな機能を見定めたり、それに対してスコープを落としたり小さい範囲で出す実験をするのは必要だと思います。
sayoshi :freee人事労務でいうと法令対応が必要なものもあって、そういうのはまさに期日だと思うんですが、一方で例えば新機能開発でもよく期日という言葉を使うと思いますが、それって本当は期日じゃないというか、それは目標なんじゃないかっていう話をチームの中でしています。未来の日付には、「期日」と「目標」と「予測」という3つの言葉があるんだと思います。
期日というのはそれを守らなければ法律違反になってしまうとか著しくユーザーに打撃を与えてしまう、例えば所得税の計算ができなくなってしまうといったものだと思います。
でも、新規機能開発っていうのはこの日までに出したいよねという目標であるべきだし、目標として設定することによって自分たちがうまくいったらもちろん祝福するし、うまくいかなかったとしたら何でうまくいかなかったんだっけと振り返りするために使うものであり外から言われて決まるものではないので、そのあたりの言葉の定義は改めてチームや組織の中で考えてみる必要があるのかなぁと思いました。
―目標の日付までに終わらないと困るんですけどって言われたりすることはないですか？
誰かが「この日までに出します」と外で約束をしてきたとなればそれは期日になると思います。そうするとQCDS（Quality,Cost,Delivery,Scope）のどれを最優先に考えるのかという話で、約束してしまっているのであれば期日を最も重要と置く一方でスコープを落とす必要があるといったように、何を最優先に考えるのかという話だと思っています。
Takeru Ichii:スコープも十分小さい粒度で区切るべきだと思います。単純に QCDS調整してくださいというわけではなくて小さく素早く出していくことが重要だと思います。
スクラムマスターをやって分かったこと、工夫していること
―視聴者の方から「リモートワークならではの大変さや工夫ポイントがあれば聞きたい」という質問がきています！
Takeru Ichii:スクラムの三種の神器として良く使われるものに付箋があるんですけど、インターネットでは使えないですよね（笑）オンラインホワイトボードツールが世の中にはあるのでそういうのを活用しているチームもあって、あれはいい活用の仕方ですね。
sayoshi :うちのチームはmiroを使ってます。レトロスペクティブや次のプロジェクトのことを考えるブレインストーミングなどでアイディア出しする時にホワイトボード代わりに使ってます。
Takeru Ichii:うちのチームは全盲の方も働いていて、オンラインホワイトボードはアクセシビリティを考えると難しいので、基本的にはGoogle ドキュメントで全部記録を残して議論に参加しやすいようにしています。議事録をとる人のスキルもあるんですけど、結果的に話してる内容を後で見やすく残しておくということがチームでできるようになったのでメリットが大きいです。
付箋はいいんですけど細かい話の記録が残らないんですよ。Google ドキュメントなら途中経過とかどういう意思決定を我々はしたんだっけみたいなことを振り返ることができるので、そこは工夫ポイントのひとつなのかなと思います。
―「アンチパターンと分かっていながらも兼任スクラムマスターをやってみて発見したことが気になる」というコメントももらっています。
sayoshi :アンチパターンだと言われる理由の一つとしてやっぱり自分がデベロッパーになってしまうので俯瞰的に見ることができない、チーム全体を見ることができずにスプリントのタスクに集中してしまうというのがありますが、やっぱりそれは感じますね。僕のチームは1週間でスプリントをやってるんですが、僕自身タスクをやっている中で、気付いたら1週間経っていて次の日はスクラムイベントだ、みたいなときもあります。
チームの中でスクラムガイドを改めて読んでみましょうみたいなこともしたんですけど、当然1日では終わらなかったので何回かに分けて実施したんですが、1-2回目は2週間のペースでやったんですが、3回目は2ヶ月後みたいな。全体をみて計画を立てるみたいなところががうまくいかないっていうのはまさにアンチパターンと言われる所以だなーっていうのは感じますね。
一方で必ずしもデメリットばかりではなくて、やっぱり自分自身がデベロッパーなので、デベロッパーの動きとしてこういうふうに改善してきたいよねみたいなところに自分も当事者として視点を入れることができたり、レトロスペクティブの振り返りの中でこの人にいま話振った方がいいなというのが見えてきたりします。
―細部まで見えやすくなるという意味では兼任の良さもあるってことですね。
sayoshi :細部まで見えてしまうのがいい方向にも悪い方向にも働くって感じですかね（笑）
―俯瞰したり見通しを立てるために工夫していることはありますか？
先にカレンダーだけ押さえちゃうとか、（仮）で予定を入れておいてここまでに準備しなきゃというのを自分のために入れておくというのはやってます。ただ、それでもまだまだ厳しいところはあります。
―俯瞰してバックログをちゃんと眺める時間をとっているのはいいですね。
freee Agile Partyの発足
―freeeでアジャイルやってる人たちでコソコソ集まって何かやってるって噂を聞いたんですが、何をやっているんですか？（笑）
Takeru Ichii:コソコソ（笑）僕主催で去年の12月頃から始めたんですが、スクラムマスターって開発チームの中でちょっと孤独になることがあるんですよね。チームがスクラムに集中できる状態を作るために、結構それまで1人で頑張らなきゃいけなかったりするんですが、そのときにスクラムマスターが空回りすることがあったりします。スクラムマスターをひとりでやってるとそういう悩みを結構自分で抱えちゃうんですよ。
これまでfreeeはいくつかスクラムをやってきているのに、スクラムマスターが集まって情報交換とか悩みを語り合う場が意外とないなと思ったのと、freee全体でアジャイル開発を盛り上げたい、アジャイルな計画を立てられる組織にしたいという想いがあって、スクラムマスターを集めて互助会兼グループ会として freee Agile Party というのを内部で設立しました。
―頑張ってエネルギーをかけて走らなきゃいけない場面が長いからこそお互いの悩みを共有したり、まだまだアジャイルの未熟な部分を共有して改善していくための場ということですね。
Takeru Ichii:そうですね、あとは新しくスクラムをやりたいっていう人たちに対して支援もしていきたいです。呼んだらやりたいやりたいって言ってくれる人が結構いて嬉しかったです。
―新しい取り組みが生まれてくるのはいいですね。社外のスクラムマスターとも情報交換する機会ができたら面白いですね。
Takeru Ichii:ぜひコラボレーションできると嬉しいです！
本編終了後にZoomで開催されたアフタートークにもたくさんの方にご参加いただき、取り組み事例をシェアしたり意見交換したりする良い時間となりました。
▶次回freee Tech Night
3月18日（金）19:00～ freee Tech Night × 食べログ 「何度でも食べたいテスト自動化導入の必勝レシピ」
▶今回のイベントのアーカイブ（録画）
