私の苦い経験について
KAGに入社する前、2020年頃スクラムに出会ってからの1年間は、ずっとスクラムと向き合い、試行錯誤とインプットの日々でした。
今までやってきたことを重ねてみると、変なスクラムになる違和感があり、「まずは教わった本来のスクラムをやろう」という意見で、もう一度原点に戻すことを繰り返しました。しかし、リモート業務であったため、スクラムイベントでしかやり取りがなくなり、コミュニケーションの不足から心理的安全性が失われていく感覚に怯えました。その中で私が経験した内容をいくつか紹介します。
チームの責任に変える難しさ
ペアプロやモブプロを導入していればまだ違うかもしれませんが、バックログは個人に割り振られるので、いつの間にか責任が個人になっていることがあります。
デイリーでアラートを出しても、そのバックログを持っている人の責任のままで、チームで責任を持たないままです。時には、みんなの時間を奪っているという感覚に陥ることもあります。
そして、バックログを終わらせることに集中して、プロダクト全体に注意を払うマインドが損なわれることもしばしばあります。スプリントレビュー時に壊れていると気づくこともあります。
私が経験したこの問題は、メンバーそれぞれがチームの大切さを知らないことと少し違います。メンバーみんながチームになりたいと思っていても、バックログがチームにさせてくれず邪魔していました。
リード役の負担増加
なんだかんだでリード役に相談したい時間は少なからずありました。悲しいことに、「我々はチームだ!」というマインドが強くなればなるほど、相談するコミュニケーションや意思決定の場が増えるものです。その結果、リード役の取り合いが起き、リード役の時間がなくなっていきます。
この問題の厄介なことは、初めはうまくいくことです。しかしジワジワとチームを蝕み、身動きが取りづらくなっていきます。
変えたいという意見を溜めてしまう
そんなルールはどこにもないのに、スクラムイベントが始まるまで意見を手元で持ったままにすることがあります。
よくあるのは、レトロスペクティブになるまで改善したいことを言わないことです。そして重要な改善内容なのにバックログを優先する場合が多く、その改善が優先されずいつまでも行われないことです。
当時思っていた私の考え
これらの問題に対して、自分の経験としてうまく回っていたことをうまく組み込めないだろうかと考えていました。
自分の今日1日をふりかえること
自称なんちゃってアジャイルをやっていた会社に派遣で行っていた時期に行っていたのが帰りの会でした。
主に進捗の共有がメインで、ここが難しいから明日一緒にやってほしいという調整や、出来上がったので明日第3者テストお願いしますとか、雑談交えつつ話す場でした。朝会は逆に存在しませんでしたが、今日起きた不安を明日に持ち越さないという副作用もあり、また夕方の方が鮮度高い会話で行われるので、私は好きでした。
勉強する日を週1設けること
たまにブログ記事でも見かけた勉強だけの自由時間を週1で設けること。月〜木が業務で、金曜は1日勉強したりアウトプットの機会にすることです。
当時のスクラムチームは設計部分の経験値が私を含めてなく、みんなと意識合わせして取り組みたかったわけですが、なかなか実現がしませんでした。
その結果、ただひたすらにドキュメントや手順書を作成し残して読めば分かる環境を作り上げることでしたが、ことさら勉強に関しては役割が違うのだろうなと感じていました。
レビューと意思決定、スイッチングコストと向き合う
リファインメントでは基本的に要件定義レベルを仕様レベルにまで落とし込む程度であって、具体的な実装方法(How)については裁量が振られています。なのでスプリントが始まってから「さて、どうするか」となるわけで、これが完全に個人の裁量となると話が変わってきます。もちろん個人の裁量としてプルリクエスト時のレビューとしても良いわけですが、プルリクエストはよくスプリント後半に集中するため、気づきに遅れる問題があります。これでは開発力としてのスピードが弱いという弱点があります。
なのである程度設計が出来上がった時点でまずは設計レビューを行うわけですが、スプリントはよーいドンでスタートしているので、みんなバックログに集中したいため、2〜3日目にレビューを挟まれるとスイッチングコストがかかり、結果的にこれも開発力の低下を起こします。
スプリント中によく起こっている問題として、このスイッチングコスト問題を解決するのが1番の有効策じゃないかと考えていました。
コミュニケーションと向き合う
あれこれとどうやったらスクラムがうまく回るのかを考えていたのですが、ある記事に出会います。
この考えを見るまで、うまくいかない理由は「バックログの切り方」だと私は勘違いをしていて、レビューや個人の裁量で持てないほどの大きさであることが問題だと考えていました。もちろんバックログの大きさの考えも重要ではあると思いますが、どちらかというと「チームづくり」の問題の方が大きいのだと気付かされました。
が、しかし、「チームづくり」って何なのか、エンジニアという枠にいながらそのような立ち振る舞いをどうしたら良いのか分からずにモヤモヤし続けていました。
ターニングポイント
そんなこんなでKAGへ入社してからしばらくして、piyoさんこと中島さんのチームに参加することとなりました。
daily sprintとの出会い
まず初日にしていただいたのが、ドラッカー風エクササイズでした。（以下はオフショア開発で用いた例）
メンバーの得意不得意から、ただの挨拶ではなく互いの共通点を知ることで、見えない壁を取り払ってくれます。散々記事で見てきたことでしたが、体験したことはなかったのでこれほど有効なものだとは目から鱗が落ちる思いでした。
日々の働き方は以下のサイクルで行われます。
- Good & New
- プランニング
- リファインメント（必要あれば）
- モブプロ
- チーム内レビュー（ステークホルダーへは別）
- ふりかえり
毎朝行っているのが、Good & Newです。これが非常にコミュニケーションの場作りとして良いフレームワークでして、趣味や気になるニュースなど軽めの雑談ができるため、チームの居心地がよくなります。
それと中島さんのチームならではで、忘れてはならないのがFunDoneLearnのふりかえりです。日々の喜び（楽しかったこと）、学んだこと、終わったことを毎日メンバーでふりかえっています。(たまに🐘🎣🤮)
毎週金曜日はOST（Open Space Technology）が行われており、気になるニュースや技術をみんなとわいわい共有したり発表する場があります。
メジャーバージョンアップされたパッケージを試したい、話題のフレームワークを試したい、発表されたAIを試したいなどなど。
どうなったか
1つ目にまず、段違いにコミュニケーションが取りやすくなりました。
毎日のふりかえりが楽しいです。日々あったことをメンバーに共有できるのは気持ちがいいものです。悩み、不安、喜び、達成感をチームで共有することが一体感を生み、プロダクトを前に進めてくれます。
2つ目にpivotできる迅速さが強いと感じています。モブプロとレビューが毎日あるので、常に状況が共有できており、より良いものがあれば即座のpivotが可能です。
3つ目に自分の興味がある分野や技術に巻き込みやすくなりました。業務中の隙間時間にメンバーへ技術の共有は苦労がつきものですが、Good & NewやOSTを利用して、メンバーに「共有する場」があるというのは行動のしやすさが上がります。
楽しくやるのは大事
KDDIアジャイル開発センターでは、「楽しくやる」を基盤のカルチャーとして働いています。
今回の気づきは、改めてその大事さを感じた学びです。