これは Kyash Advent Calendar 2021 の3日目の記事です。

こんにちは。Kyashでプロダクトマネージャーをやっているyanaiです。
私はKyashアプリの中で、決済機能と、直近ではとある新規事業の担当をしています。機能の開発はスクラムのフレームワークに則って運用しているのですが、スクラムマスターが参画したタイミングで、長らくやっていた運用方法をガラッと見直しをしました。この記事では、「これまでのチームでのスクラムの実践方法」と「課題」、「実践方法を最近どう変えたか」について話したいと思います。

なお、この記事の中では、スクラムフレームワークそのものの話には触れません。その代わりに私が好きな、アジャイル宣言の背後にある原則の画像を載せておきます。また、記載している感想や課題感については、開発チームのメンバーとも認識があっているところもあると思いますが、あくまで私個人の認識で記載をしています。

f:id:Yanai3:20211202160937p:plain — アジャイル宣言の背後にある原則

前提として、チームの概観と私

初めに我々のチーム構成ですが、現在POとしての私と、開発チームとしてサーバエンジニアが5名、スクラムマスターが1名という役割分担です。チームが生まれたのは2020年の1月で、最近までスクラムマスターは不在でした。ここを、「POがスクラムマスターを兼ねる」という、分かりやすいアンチパターンでスクラム開発を実践してました。これ以外にも課題はあったので後述しますが、状況を見かねて今年の10月からエンジニアリングマネージャーの方がスクラムマスターに名乗り出ていただき、今の構成になったのが直近の経緯です。

また、私自身は2020年1月にKyashに入社したのですが、それまでの開発プロジェクトの経験は以下の通りです。Kyashに入社した時点で、スクラムフレームワークの理解はある程度あったんじゃないかなと思います。

これまでに、ウォーターフォールの開発のプロジェクトマネージャーを7年ほどと、スクラム開発のPOを1年ほど行いました
アジャイル検定Lv1という試験の合格証明書を持っています
アトラクタ社さんによる初学者向けのスクラム開発研修を受講しました

以後は、「スクラムマスター降臨前の時代」と、「降臨後の時代」について、それぞれ話していこうと思います。

スクラムマスター降臨前

Kyashに入社した私は、スクラム開発で運用する前提で、開発チームのメンバーと開発の進め方のルールをすり合わせて、以下のように決めました。当時は私とサーバエンジニア2名の計3名のチームだったので、「様子を見ながら都度運用は変えればいいか」と考えて一旦走り出したのですが、結果的にここで決めた運用はスクラムマスターが降臨するまで約1年半ほど続くことになります。

デイリースクラムは、13:00-13:30に毎日実施
プランニングとレビューとレトロスペクティブは、まとめて木曜14:00-15:00に実施(ちなみに木曜にしている理由は、月金は基本的に祝日やメンバーの休みの調整が無駄に増えることと、週後半の方が頭が冴えてるだろうって言う理由です)
チケットの見積もりは、(プランニングの前日の)水曜14:00-15:00に実施
ストーリーポイントの基準として、「1日で終わる作業なら2pt」
チケット管理ツールはJIRA
スクラムマスターはいないので、POが会議のスクラムマスターっぽいことをする(そのうちきっと入社してくれるだろう)

具体的には以下のように実施していました。

デイリースクラム

各自にアサインされたチケットの進捗状況の報告をする
チケットに限らず、気になること、情報共有や、事務連絡など、自由に発言してもらう

PBR

翌日のプランニングに向けて、次スプリントに入れる予定のチケットの詳細化と見積もりを、POと開発メンバーで実施
見積もりをまともにする日もあれば、要件をPOからエンジニアに伝えて、タスクを洗い出すことだけやったことも

プランニング/レビュー/ レトロスペクティブ

スプリント中のチケットで、ステータス(未着手、進行中、レビュー中、リリース待ち、完了)の動かし漏れがないか確認
スプリントを閉じ、JIRA上でスプリントレポートと、ベロシティを確認
今回のスプリントのゴールと、「起きたこと」をベースに振り返りを実施
チーム内で議論したいことがあれば、議論
- 例)
  - こういう開発ツール使いたい
  - 今後のチームでの施策の見通しとしては、xxを考えている
各自から、この1週間の感想を話す
- 開発に関することだけじゃなく、プライベートな内容も含み、雑談モードなアジェンダでした
次のスプリントのプランニング
スプリントゴールの設定

その他の細かい工夫

四半期の終わりなど区切りのよいタイミングで、チームで行う施策を時間軸で並べて、POから開発チームへシェアをし、その場で技術負債の解消としての施策も計画に取り入れるということをしていました
リモートになってからコミュニケーションしやすい環境を作るために、強制ではないですが勤務中はGoogle meetを繋ぎっぱなしにして、口頭でのコミュニケーションができる状態にしていました

これらを実践していたときの、ポジティブな感想

POと開発メンバーの距離が近く、お互いにコミュニケーションを取りながらPOからはユーザ目線でやりたいことを相談でき、開発メンバーからは技術的なチャレンジや負債の解消としてやりたいことを相談できていました
私自身がKyashのプロダクトマネージャーで、プロダクト全体の方向性や、他チームの施策の見通しについても情報を比較的早く取れる立場だったので、そういった会社全体の動きやチームに影響がありそうな物事の情報共有が素早くできていたと思います (こういった共有は、各スクラムイベントの端々で行っていました。)
開発チームの状況が毎日把握できるので、チームの状況をチーム外のメンバーに対して説明するときには、割と細かくレポートすることができました

課題

ここまで読んだ時点で既に、課題の匂いをプンプン感じている方がいるかもしれませんが、常々私が感じていたものをいくつか挙げると、以下の通りです。

POがスクラムマスターやっちゃだめでしょ。 全然スクラムのフレームワークに則ってなかったですね。「なんちゃってスクラム」でした。POとしてやるべきことを突き通す場面と、開発メンバーの開発効率や負荷を考えて、優先順位を崩してしまうということが、日常茶飯事に起きていました
レトロスペクティブも全然できてないやんけ。 雑談してんじゃないよ。(ただ、やってる本人たちとしてはめちゃ楽しいパートだったので、なかなか強い意志を持ってやめることができなかったのだ...知ってたさ、知ってたとも。)
見積もりの基準として「1日で終わる作業なら2pt」は、良くない。 スクラムの教科書的には、「基準になるような作業内容をチームで決め、その基準となる作業内容に合わせて見積もりをする」だと思うのですが、単純な時間見積もりになってる。
私個人としては、 めちゃめちゃ大変でした。 POとしても意見しつつ、会議のファシリをするための準備も必要なので、基本的に毎日何かしらの会議の準備時間が必要でした
開発チームのメンバーが話している技術的な話が、時々わかりませんでした。 わからないのにファシる役なので、そのせいで時々議論を止めてしまう申し訳なさがありました。私自身はCOBOLでの開発をちょっとだけやったことがある程度で、ナウいヤングにバカうけのイケイケツールのことは知らないんですよね。「API」は分かるけど、「gRPC」を知らない、みたいな感じです。(今もよく分からない。)

(課題を挙げすぎてしまったので一応フォローをしておくと、開発メンバーもスクラムフレームワークの知識や実践経験はあって、各自がそれぞれの意味を知った上でルールを破っていたと言うことはいえます。また、グダグダなスクラムイベントをやっていたことは認めますが、意思疎通が高いレベルで出来ているチームなので、やるべきことはやった上で、技術負債への取り組みも並行して実施できたチームでした。とだけ言わせてください。本筋に戻ります。)

スクラムマスター降臨後

これらの課題を抱えている我らが開発チームに、エンジニアリングマネージャー(以降、EM)の方が着任しまして、彼が「スクラムマスターに、俺はなる！」と言ってくれたことをきっかけに、運用の見直しを行うことにしました。

チームで行った議論

当初3人で始まったチームが、今やスクラムマスターを入れて7名のチームになっていたので、色々な意見が見直しの議論で出てきました。

そもそもスクラム開発じゃなくてよくない？見積もりすることに意味を感じないから、カンバン方式にしたい
- でも見積もりが無いと見通しは立てられないので、事業計画の達成可否が見えにくい状態になってしまう
スクラムイベントに時間を使いすぎなのでは？デイリースクラム30分、見積もり1時間、スプリントレビュー+プランニングで1時間で、週に270分使っている事になる。ふりかえりも、ふりかえりと言いつつ、スクラムと関係のない雑談が多い。
- 「...でも、雑談もしたいな。」と言うメンバーに対し、「うるせー！目を覚ませ！」とスクラムマスターが強烈なビンタをするシーンもありました(ありません)
そもそもJiraって重たすぎてストレス溜まるので、GitHub Issue使ってスプリント管理しない？
木曜日の13:00-13:30にデイリースクラムをやって、14:00-15:00でスプリントプランニングやるから、その間の30分はほぼ何もできない

これらの議論を経て、以下のようにスクラムイベントの運用を変えました。

具体的に変えたところ

デイリースクラムは、13:00-13:15の15分で終わらせる。課題があるなら別で時間をとって、ダラダラ話を続けない
木曜のデイリースクラムは、プランニングと統合し、13:00-13:15でデイリースクラム、13:15-15:00にプランニングを実施する
ふりかえりでの雑談要素は排除して、Trelloを使ってKPTを行い、チームとしての改善が回るようにする
それでもやっぱり雑談もしたいので、雑談しかしない時間を金曜日に取る (参加は任意)
水曜の見積もり会は廃止し、プランニングの中で見積もりを行う
Jiraをやめて、GitHub Issueを使ってスプリント管理をする
月火水は、極力開発作業に集中できるよう、会議を入れないようにする
EMがスクラムマスターとして振る舞う

週の予定としてどう変わったかをbefore / afterするとこんな感じです(Googleカレンダーっぽい見た目で、サンプル作成！)。

before

f:id:Yanai3:20211202160220p:plain

after

f:id:Yanai3:20211202160545p:plain

見た目としての変化は地味ですね！毎日15分会議体が減ったのと、水曜と木曜の13:30-14:00のアイドルタイムが無くなったので、週に2時間15分の時間が捻出される様になった形です。

運用変えた結果の、初速としての感想

まだ運用を変えてから間もないですが、明らかに前と変わったことをあげると、

自分自身は、POとしての役割に集中できるようになりました
スクラムイベントのファシリはスクラムマスターであるEMがやってくれるので、「会議のファシリのための準備」っていう時間が劇的になくなりました(ありがとう！スクラムマスター！)
スクラムイベントは、スクラムマスターがテキパキと話を進めてくれるので、会議の質やスピードが上がったと思います
GitHub Issue、めっちゃ軽い。サクサク動いて感動してます。スプリントレポートは逆に手動でベロシティ計算をしなければいけなくなったんですが、週1回の苦行よりも、毎日の苦行がなくなったことが何より快適です

以上が、Kyashの中のある開発チームが行っているスクラムイベント改善の初速です。まだまだ踏み込めてない課題も多いので、今後真面目にスクラムイベントが回っていくことで改善されていくと思います。