こんにちは、アプリケーションエンジニアの @yukung です。突然暑くなったり寒くなったり、気温の変化が大きい今日このごろ、体調いかがでしょうか。コロナの勢いも再び出てきてしまっており少し不安な状況になりつつある中、再度気を引き締め直してしっかり体調に気をつけていきたいですね。
スクラム始めてみてその後どうなった？
さて、今回は以前ご紹介した、弊社の ICP 開発チームにおける開発の様子のその後について触れてみたいと思います。
以前このブログで、ICP 開発チームでは開発の進め方としてスクラムを導入して開発を行っていることをご紹介しました。その時の経緯や具体的なやり方の様子などは、以下の記事もぜひご覧ください。
また、本記事の趣旨とは少しずれますが、今年の大きな変化として多くの企業がリモート・在宅での業務にシフトしていく中で、我々 ICP 開発チームもスクラムを継続しつつ、自ずとリモート主体の業務スタイルに移行しています。その時の変化の様子については、以下の記事で紹介されていますのでこちらもどうぞご覧ください。
スクラムを始めてみて浮き彫りになった課題
上記の記事で触れた通り、スクラムを始めてしばらくは、私自身がスクラムマスター兼開発者兼各種スクラムセレモニーの MC を兼任する形で進めていました。見様見真似で始めたこともあり、はじめの頃はチーム全体が何が正解かも分からず、まずは私が言っていることを正として、進めていたと感じています。
そうすると、容易に想像できることではありますが、だんだんと私自身がボトルネックになりはじめている感触を持つようになりました。どんな点でそう感じていたかについて、細かいものまで挙げると切りがないですが例えば以下のようなものです。
- スプリントプランニングの進め方について
- ストーリーポイント見積もりの基準について
- デイリースクラムのファシリテーション
- プロダクトバックログリファインメントの議論のファシリテーション
- 振り返りのファシリテーション
- etc...
当然といえば当然ですが、知らないものに取り組んでいるのでそうならざるを得ないのはある程度仕方のない面があります。
一方で、この状況は決して芳しいものではなく、チームの成果を最大化するにはこの状況自体を改善する必要性がありました。PM の Gyopi が機を見たタイミングで違和感や改善提案などを出してくれてそれ自体に大分助けられていたのですが、私自身も認定スクラムマスターの資格を持っている訳ではなく、私自身でも自信を持って進められているわけではありませんでした。
そんな折、私が以前在籍していた職場で現場コーチとして関わってくれていたギルドワークスの中村さん
からお声がけいただいて、中村さんのご厚意によりアドバイスをいただける機会を得ることができました。
コーチングの内容（一部）
漠然とした課題感は持っていたものの、自分たちでも何が課題なのかをはっきり認識できていない中で、中村さんには現状を率直にぶつけてお話を聞いていただきました。以下はその時のミーティングの様子で話していたメモの一部です。（字が汚くてすいませんｗ）
（この時からは結構時間が経っており、今となってはという話も含まれていて個人的には懐かしい感情が沸いてきます…）
また、中村さんにはチームの振り返りのある会にご同席いただいて、様子を観察していただきました。一部ですが抜粋してみます。あくまでも私たちのチームの状況なので、全て参考になるわけではないと思いますが、なんとなく雰囲気が伝わればと思います。
中村さんとのオンライン雑談会
また、この後ある程度時間が経ってからも、オンラインでの雑談会で相談に乗っていただいたりもしました。その時にいただいたメモなどを一部抜粋してご紹介します。
こちらも私たちが直面した状況に対する議論のメモなので、これを読んでそのまま何か答えとなるようなものではありませんし、特定の課題に限っていないので取り留めもないのですが、少しでも参考になればと思い載せてみます。（中村さん）とカッコ書きにしているところは、中村さんからいただいたアドバイスの一部です。
オンライン雑談会のメモ
- ストーリーポイントの確からしさに対する不安
- 怖い？
- （中村さん）正確さを求められる強迫観念をチームが持っている？
- 数字は取っているけど、それを見てカイゼンする姿勢になりづらい
- ポイントについて話しているのにいつの間にか工数見積になっている。
- （中村さん） 議論する前にまず最初につけてみると良い かも？
- （中村さん）1，2，3，5，8，13 で 2 つ以上離れていると、話し合うと良さそう なアラート。
- （中村さん） 規模見積と工数見積の違い について
- 怖い？
- チームの人数の大きさについて。多いと感じているが実際どうなのかが不安
- 最適な人数ってどれくらい？分けたほうがいい？
- （中村さん）どうして分けないの？
- 実際に回るかどうか不安
- （中村さん） 試しに PO と SM (私自身) が、一緒に1週間くらい旅行に行ってしまって、その間みんなに回してもらえばいいのでは？
- （中村さん） 小さく分けてうまくいかなければ、元に戻せばいい んじゃないかな？
- （中村さん）PO が一人で回らないかもという場合、POを増やすという選択肢もある。例としてエンジニアから企画の人に手伝ってもらってPOをできていた例がある。
- チームをわけることで、ドメイン or 技術スキルに偏りが出るかもという不安
- （中村さん） 「みんながいい感じに守備範囲広くできる状態」をそもそも目指すのか？目指すとしたらそこにはどのように到達する のか？
- （中村さん） ”チーム”としてユーザーに届けるためのスキルを持っているか が大事。
- （中村さん） スモールチームでやったほうが、学びの増幅が起きやすい 印象がある
- チーム分ける時、コードベースでも分けてる？
- （中村さん）とある現場の例では、別れているチームも１つあるけど、２チームは同じところを触っている
- （中村さん）同じところを触りそうなときにはスプリントの手前でやることをずらして被りづらいようにしている
- 最適な人数ってどれくらい？分けたほうがいい？
- リファインメントっていつしたらよい？今は週一回時間を取ってやっているが、議論が発散しがちでうまくできていないと感じる
現場コーチから持ち帰って実践したこと、変化があったこと
上記のような取り組みをさせていただいたことで得られたこととしては、まずは 私自身の良い振り返りの機会になった 、ということが大きかったと思っています。
自分自身でも自信を持てていたところ、逆にあまり自信を持てておらず不安だったところ、全く観点がなかったところなど、率直にぶつけさせていただいたことで気付かされることが多くありました。それによって私自身の振る舞いが少しずつ変わっていったように感じています。
また、上記でいただいたようなアドバイスを元に起こったチームの変化という意味で 1 つ挙げると、 私が行っていたような多くの議論のファシリテーションなどを、今ではチームメンバー全員で交代しながら実施することができるように なりました。
それによって、プロダクトバックログリファインメントとの向き合い方が以前より変わり、 しっかりリファインメントできたものに関してはやることがはっきりしてチームメンバーが理解できている状態でスプリントプランニングに臨めるようになった ため、議論がスムーズになりました。
スプリントプランニングやプロダクトバックログリファインメントなどについて、関わっているメンバー一人一人が、 誰かがやってくれるものという認識ではなくチームメンバーが自分のタスクとして認識する ことで、どういう事に気を配らないといけないのか、また議論の着地点をどこにするのか、という意識が少しずつチームメンバーに芽生えてきたのではないかと感じることが多くなってきました。結果的にリモート中心となってもミーティングの練度が高まっていったように感じています。
まとめ
スクラムを始めてしばらくして浮き彫りになってきた課題について、幸運にもギルドワークスの中村さんにアドバイスいただける機会をいただけたことで、チーム開発におけるカイゼンを一歩前に踏み出すことができたと感じています。
お声がけいただいたギルドワークスの中村さん、この場を借りて御礼申し上げます。ありがとうございました！
我々 ICP 開発チームはまだまだ完成された開発チームではありませんが、スクラムを用いて自分たちの開発するものについてチームで議論しながら進められるような開発ができています。こうした開発にご興味がある方は下記バナーの採用サイトからご応募いただければと思います。
