2 年ぶりのスクラムについての記事になります。
Contrea ではスクラムを導入して 3 年が経ちました。Sprint 番号は 75 まで到達し、振り返りで利用している Figjam は端から端に到達しました。
1 つのチームでここまでスクラムを回し続けることも中々ないと思うので、みなさんの環境でも起きそうな課題とどの様に乗り越えてきたかを FAQ 形式でまとめていきます
前提
- 1 チーム構成
- PO: 1 名
- エンジニア: フルタイム 5 名 副業 3 名
- デザイナー: 1 名
- 1 Sprint: 2 週間
FAQ
チーム構成
Q. 副業メンバーはスクラムに入ってもらう？
立ち上げ当初は、開発の中心に副業メンバーも多かったためスクラムに副業メンバーも入れる前提で組み合わせていました。フルタイムのメンバーそれぞれに、副業メンバーの担当みたいな形をつけ進捗管理していたのですが、副業メンバーの場合にはコミットメントがバラバラな場合もあり、2 週間で進捗が出ない場合もあり、無理にスクラムに入ってもらう考えをやめました。
代わりに、副業メンバーのチケットはスプリントボードには入れるので、毎日のデイリーで進捗は確認し、ディレイしている時には Slack で本人に確認という形にしました。
また、スクラム化を進める中で、フルタイム比率が徐々に高まる様にはなっています。
Q. デザイナーもスクラムに入ってもらう？
Contrea では現在デザイナーメンバーにもスクラムに一緒に入ってもらっています。
現在というのは、過去業務委託のみの時代には、スクラムには入ってもらわずに別途タスク説明の時間を確保するということもありました。ここは、デザイナーの方の思考性（システムの要件まで伸ばせる、稼働時間が確保できる）という条件も必要になると思います。デザイナーの方が参加可能な場合には、要件定義や仕様策定において新たなインサイトをもらえることも多く、入ってもらうことのメリットが多いように感じております。
Contrea では別途プランニング前に「ポイント付けしたいタスク募集スレッド」が立ち上がるので、ここでデザイナーメンバーが参加必要か事前判断して時間を効率化しています。
イベント全般
Q. イベントは何をやっている？
現在は、「デイリースクラム」「プランニング」「スプリントレビュー」「レトロスペクティブ」「バックログリファイメント」が常時開催になっています。
- デイリースクラム：15 分を目指したいけど、20 分〜30 分程度かかっています
- プランニング：3 時間〜4 時間
- スプリントレビュー・レトロスペクティブ：45 分程度
バックログリファイメントは作業時間確保のため、事前に話したいものがあるか募集し、特になければスキップとしています。
Q. イベントの欠席はどのように考えている？
基本的には「欠席が発生する場合にはリスケ」を原則としています。というのも、説明のための MTG が発生するのが一番勿体無いので、可能な限り全員が参加できることを前提としています。
しかし特例として、病院訪問や商談同席などプロダクト構築において最優先にしてほしいイベントがある場合には積極的に参加して欲しいのもあり、欠席を可能な形になっています。
Q. ファシリテーションは誰がする？
チームによってはスクラムマスターもしくはマネージャーがファシリを定常的に担当することもあると思いますが、現在はスクラム内のメンバーがファシリを持ち回りすることに落ち着いています。
これは、ファシリをすることで自分以外のタスクに関心を持つ必要性が生まれるため、他メンバーの進捗や問題にも即座に気づけるように、フォローアップできるようにというのを前提にしています。
Q. 使っているツールは？
- チケット管理・スプリントボード・ドキュメント管理: Notion
- 振り返り・設計: Figjam
- コミュニケーション: Slack
チケット管理は、当初 JIRA か Github か Notion で悩んだのですが、Notion のスプリントボードテンプレートが出たタイミングで、これは有用だと思い導入しました。
昔は、Task 量が増えていくと重くなることがよくあったのですが、現在はレコード数が増えても問題なく使える様になりました。
Notion AI の導入により、より使いやすくなったとも感じています。
各イベントの運用
Q. デイリースクラムはどうやってやる？
「ひとりずつ昨日やったこと今日やることを話す」など色々な方法を試しましたが、時間やキャッチアップの都合を考えると、現在はスプリントボードを上からファシリが進捗をさらっていくという方式に安定しています。
シート上では、プロジェクトごとに区切りその中で担当者ベースでチケットを表示しているので、「A プロジェクトの〇〇さんのチケットのステータスはどうですか？」という聞き方でステータスの変更を答える形にしています。
Q. スプリントレビューはどうやって呼ぶ範囲を決めている？
スプリントレビューの前日に、成果物をチームで確認し、影響がある・意見が欲しいステークホルダーを決め、招待制にしています。セールスに影響がある変更など特定の人物でない場合は、チーム単位で声掛けをし、1 名以上出席してもらうようにしています。
Q. スプリントレビューが億劫
指摘の場になるのが怖いというのはスプリントレビューあるあるだと思います。
Contrea の場合、そもそも代表をはじめ Biz メンバー全員がプロダクト活動にリスペクトを持って対応くださっているのがありがたいです。その上でメンバーには、この対応が発生した背景・考慮したポイント・できるだけ動くもので見せること・今後の方針まで話してもらうようにしています。
また、頻繁に「スプリントレビューをなぜするのか？」というのは全社員向けの発信は続けています。リリース判定のための場ではなく「盛り上がるのが正解の今後のための場である」というのは伝えておくと、雰囲気も良くなり進めやすいと思います。
Q. レトロスペクティブはどうやってやる？
Figjam を使って振り返りを実施しています。基本的にはシート上部に「スプリントゴールの達成率」と「ポイント消化率」を掲示し、その結果をもとに「良かったこと」「進め方の課題」「Try」の形式で進めています。
Try は忘れ去られがちなので、ファシリが具体的なアクションを終了後すぐにスプリントボードに記載し、必ず毎朝目に入る様にしています。
また Try を引き継いで次回の振り返りシートに記載する様にし、忘れずに振り返れる様にしています。
見積もりと運用
Q. ポイントの付け方は？
つける対象としては「プロダクトの変更に携わる実装タスク」としています。
3 年も続けていると、ポイントに対する感覚は相当シンクロしてくるようになってきています。
Q. ベロシティをどうやって評価すれば良い？
正直ここはうまく使いこなせていないポイントになります。
スプリントごとやプロジェクトごとの消化ポイントを管理しているので、大体のチームの速度は把握していますが、新しいプロジェクトに対して「正確なトータルポイント」を見積もることは不可能なので、消化までの大体のスプリント数を把握するレベルにとどまっています。
Q. 開発以外のこともやるんだけどどうすれば良い？
仕様設計や、顧客社内対応などのアクションがあるメンバーもいると思います。これらにポイントつけようとするとカバー仕切れないですし、そもそもポイントをつける必要もないのでこれらは 0pt という扱いにしています。
あくまで Product チームは MediOS の開発・改善のためのチームですので、チームとしての意識するべきポイントは「プロダクトの変更に携わる実装タスク」のみにしております。
Q. 差し込みの考え方は？
Contrea では当初からスクラムを導入していることもあり、経営陣をはじめ開発以外のメンバーもスプリントの考えを理解してもらっています。そのため、急に今週までにリリースして欲しいという話になることが多くないことが前提として大きくあります。
不具合や顧客対応の調査などで差し込みが発生することがあり、これらのタスクは許容するようにしています。
課題と気づき
Q. チームの属人依存は？
スクラムを続けていくと、チームの成熟度が高まっていくに従って、システム仕様や開発スタイル含め、言葉にできない（できていない）コンテキストが蓄積されて行きます。
これらを属人性と捉えられますが、私自身はこれ自体はそこまで悪いことではないと見ており、それこそが練度が高まるということだと思っております。スクラムを進めれば進めるほど、チームに対して変更可用性が下がっていく感覚があります。
Q. 結局 3 年続けてどう？
一番はアジャイルな開発スタイルがチームや会社に根付いたと思います。
トップダウンで決められたことをやるというよりは、日々の顧客レスポンス、ロードマップ、不具合対応といった事象に臨機応変に対応しながら、チーム内で権限を持ち、優先度を責任を持って決めながら、日々の開発を必ずスプリント毎に完了させるというサイクルが生まれていることが大きいです。
進めていくうちに築かれるものですが、エンジニア自身が自分ごとかして取り組むことができるのはスクラムのメリットだと思います。
最後に
私たちと一緒に、プロダクトを開発してくださるエンジニアの方を募集しております！
特に、フロントエンドと AI エージェント開発が現在の注力領域ですが、フルスタックに顧客視点で開発できるエンジニアを求めております！
ぜひ一度お話しさせてください！
インフォームドコンセント支援システム「MediOS」を開発するContreaのProductチームのブログです。 様々なバックグラウンドをもつメンバーが所属し、医療の未来を作る仕事をしております。
Discussion