Sasuke Financial Lab株式会社にて、自社サービス開発チームのスクラムマスターをしております、オオツカと申します！
フリーランスでUI/UXデザイナー出身→現在は会社所属にて、デザイナー→スクラムマスターに社内ジョブチェン、バリバリスプリント回す日々でございます。
今月でなんとスクラムを導入して一年となりました！
そこで今回はスクラム開発をゼロから導入してきた記録！として、
現在のSasukeの自社サービス「コのほけん！」の開発チームのスクラムについてじっくり中身をみていこうと思います！
の前に自社サービス「コのほけん！」の紹介
コのほけん！は「デジタル保険代理店」です！
弊社のミッション「自分に合った保険を、自分で選べる世界を」を体現するサービス。
今まではお店に行ったり、保険屋さんに相談して決めていた保険。
でもコのほけんを使えば、オンライン上で保険に加入できちゃうんです。文字通り、自分で選べるということ！
プロジェクトメンバー一丸となって、日々開発をおこなっています。
詳しくはこちら！
というわけでコのほけんチームのスクラムについて
スクラムは現場によって違うという話はよく聞きますが、
そのチームに入ってみないと実際どんなスクラムになってるのかわからないですね。
頑張って初めてみたけど、そもそもスクラムにならなかったとか、やめたとかいう話もよく聞きますよね。
Sasukeバージョンはどうなんでしょうか。スクラムできてるのだろうか。自分だとなかなか検査しづらいものです。
せっかくだから洗いざらいみてみましょう！
よかったら質問とかツッコミも超お待ちしております！！
チーム人数
画像でかいな…まあいいや。
ちょっと多めです15人。
あれっ、よく見てみるとエンジニア以外にもいろんな人が入ってますね。
エンジニア以外も入ってる！なんで？→部署間で連携を取るため！
そもそもSasukeでなんでスクラムを始めたのか？という話をしないといけませんね。
当時は定まった開発体制がなく、またメンバーの出入りが激しい時期でした。
そんな中で部署間の連携がとれず手戻りが頻繁に発生。
別の部署が、どんな仕組み・プロセス・ペースで仕事をしているか、相互に知り合う必要があると考えた私は、
コミュニケーション強化のため、全員ワンチームでのスクラムを導入したというわけです。
なんでデザイナーの自分がスクラムマスター始めたのかについては別記事がありますので、最後に貼り付けときます！
スクラムイベントはどうなってる？
これもほんとにスクラムやってる場所によって違いあったりするみたいですね。スプリントの長さとかもさまざまですし。
うちはこんな感じです
こんな感じなんですが、まあスクラムガイド通りには行ってないわけです。
ただその分の工夫は行なっているので、それを解説します。
大体の会議が本来のタイムボックスよりも短い。
→参加者の一部が忙しいため時間が取れないという事態…。
部署跨いでのチームにした故の弊害でもありますね。
企画デザインに関しては、スクラムのプロジェクト以外の仕事も兼務していることもあり、さまざまな会議を縫ってスクラムに参加している状況。
会社人数がまだ少ない弊社としては、これはどうにもできない問題でした。
そこで対策として…
企画デザインとエンジニアのイベントを分割した
プランニングは主にエンジニアが一番時間が必要なので。
企画デザインは一週早くプランニング
企画デザインはエンジニアへ依頼する必要があるため。
リファインメントのイベントを作った
次のスプリントでやりたいことの認識を合わせ、準備しないといけないが、
人数が多くなるとこれもズレがち。なのでイベントとして全員参加の上、次スプリント作業の頭出しをします。
(デザイン確認したり企画趣旨を説明したり設計することも)
レトロスペクティブについて、参加人数に対し時間が短く、意見が吸い出し切れない
これに対しては
部署レトロスペクティブの実施
各部で時々やってもらうようマネージャーたち中心にお願いをした。
1on1する
月1でチームメンバーそれぞれとスクラムマスターが話す時間をもうけた。
各部ふりかえりに関しては、初期は自分も参加してファシリテート、ふりかえりのフォーマット提供なども行いました。
全部署を一気に集めようとすると予定がなかなか合いませんが、各部であれば大きめの時間設定ができる+人数も少ないので、サクッと終わるんですね。
もちろん部署を超えた問題を話すことがチームとして大前提にあるので、全体ふりかえりは継続しつつ、各部でもサブイベントとして振り返ってもらいました。
ほか、独自にやって(しまって？)いること
特殊な条件が入ると、どうしてもその分の歪みをどこかが受けることになるので、その分のアレンジが必要になるものですね。
できるならストレートに正しくフレームワーク入れるべき。
そんな他のアレンジ部分です。
時間で見積りしてない
スプリントバックログはストーリーポイントで見積もってもらってる。
時間見積りが正しいという話をよく見るのですが、特段いまのところ問題らしい問題が発生していない(遅れなども起きていない)(ように見えるだけで残業はあるんだよなー)(残業については別機会に語りたい)
見積もりは見積もりを行う人たち全員の基準が揃っていればよし、
ポーカー時に「意見を交換して、最終的にチーム内の合意揃える」ことが重要と考えているので、あまり数値自体には拘っていません。
(これって問題？)
企画はプランニングで見積りしていない
・企画はチーム内に入ってますが、ポジション的にはステークホルダーに近い立場でデザインとエンジニアに依頼を行っています。
企画立てに関しても調査から、外部会社都合の調整事項などもあり、デザイン/エンジニアのタスク、スプリントバックログアイテムとはかなり性質が変わってしまうことが多々。
・また、現在参画中の企画メンバー3人それぞれが別領域の作業を担当しているため、互いに作業を見積もることができません。
以上のことから、ここ4スプリントくらいは企画の見積りを廃止しています。
スプリントレビューが短い
運用保守の事項が多いスプリントでは、webの文章変更や画像差し替えなど、スプリント内にすぐリリースしなきゃ事項も多いので、
スプリントレビューに関してはPOへの報告会のような形式になりがち。短時間で終わりがちです。
(リリース時は企画やPOに情報連携した上でリリースしているので、常にレビューが行われているような状態とも言える？)
あ、新規の機能や要望が多いスプリントの時は当然長くなります。
懸念点ぽいこと
・スプリント中にPO判断すっ飛ばしてリリースされることがありうる。
→コのほけんのリリースに関してはステークホルダーである企画がハンドリングしてる&Slackで情報共有はPOも見れているので、やばい確認漏れが出たことはない…けども。
・インクリメントに対する改善点のレビューなどが出づらい
これもスプリント中に見てもらってるからレビュー時に出づらい、んだと思います。
できれば正しくスクラム、したいけども
歪んでいるとしても、最終的に開発が進むならそれはそれ？なのかなと思う自分もいます。
実際、売上も上がっており、開発も一年前みたいに3ヶ月リリース無し、みたいなものは減ってきました。
現時点のウチのスクラムはこんな感じです。
まだまだやるべきことはありますが、まずは一年、ぐるっと登ってきて、いまどこにいるんだっけ、と、
歩を止めて足元を見つめてみました。
元々自分の一存で始めたスクラムなので、開発者的には、やらされている感もあるような気がしていて、そこにちょっと限界的なものも感じたりします。残業がへらなかったり(残業したいというモチベも見え隠れ)もするし。
でも良いモチベーションも出てます。
最近はエンジニアからの提案で、前回の見積りを振り返って、ポイントの正確さを上げよう、という試みが実行中。
直近基準で、チーム内のポイント感覚を正確に揃えていきたいという狙いのようです。
先ほど「数値自体にはこだわらない」と自分は書きましたが、正確さが高まるならいいことだし、
やりたいということであればやってみるべき！と思うので、実行中。
あと自分の立場でこれからやっていきたいのは、
最初はプロダクトバックログのアイテムが機能ベースの言葉で並びがちでした。
現在は新規の施策を揉んでいるので、これからそれをユーザーストーリーに変換できるようにしていきたいと思ってます。
これからもがんばるぞ！
今日は勇気を振り絞って公開し、「検査」のつもりで現在を書き留めてみました！
最後ですが、前回の記事が、僕がスクラムマスターになった最初のエピソードになります。
そこからここまでの間の話は細かいので記事化…できるかわかりませんが、追々書いていこうと思います。
ここまでお読みいただき、ありがとうございました！