株式会社エイチームフィナジーの @Adacchi3 です。
本記事はAteam Finergy Inc. × Ateam Wellness Inc. Advent Calendar 2023の23日目の記事になります。
はじめに
2023年2月から9月に掛けて、社内システムを開発した際にスクラム開発を導入しました。
スクラム開発の導入目的や、スクラムチームを醸成するために行ったこと、ローンチまでの振り返りを記載していきます。
当初の課題感
開発チーム内のドメイン知識不足
開発していく社内システムは、事業ドメイン特化の社内バックオフィス業務の方々向けのシステムでした。仕様書を読ませていただきましたが、そもそも題材となるオブジェクトから聞き覚えがなく、どんな形になるのか、想像することができませんでした。
ドメイン知識不足に起因する開発の停滞
ドメイン知識が不足していることが起因し、なかなか開発着手に踏み切れませんでした。開発チームには「我々が知識のないままの状態で開発を着手してもいいのだろうか？」といった雰囲気や、どうやって進めていけば良いプロダクトを提供できるのだろうか、といった悩みがありました。
スクラム開発の導入目的
上記の課題感を持っており、約1ヶ月はプロダクトオーナーにヒアリングしたり、開発着手できるよう開発環境を整備しておりました。
そうした中で話題に上がってきたのが「スクラム開発」です。
スクラム開発は銀の弾丸ではありません。子会社では実績がある開発体系ですが、我々にとっては未知へのチャレンジです。
私は1-2日間で「アジャイルザムライ」を読了し、今回の課題感に効果的であると判断し、スクラム開発の導入を決意しました。
Whatの不確実性
今回の大きな課題はWhatの不確実性です。我々は何を開発すればいいのか？、どのような価値をステークホルダーに提供すればいいのか？です。
スクラム開発では、スプリントごとにスプリントレビューを実施します。細かいサイクルの中で価値提供が誤っていた場合には素早く修正でき、手戻りが少なくなることをメリットとして感じました。
Howの不確実性
もう1つがHowの不確実性です。どのように開発していくのか？といった文脈です。スクラム開発といったフレームワークに当てはめていくことで、実施すべきスクラムイベントを明示し、目標を持って開発を進めていただけたのかと思います。
実際に開発途中のシステムを見ていただく機会があることによって、このまま開発を進めていって大丈夫なんだ！と心理的安全性の担保にもなると考えました。
スクラムチームを醸成するために行ったこと
スクラム開発のすり合わせ
一番最初に行ったことはスクラム開発の本を読むことです。我々はスクラム開発初心者ですので、専門用語やスクラム開発の目的、スクラムで目指すべきゴールなどを知る必要がありました。
開発チームで相談し、「スクラム実践入門」を読み合わせすることにしました。各自読んでもらい、別途私のほうで要約した内容を勉強会として共有しました。こうして、スクラム開発をするための知識基盤を担保しました。
また、プロダクトオーナーやステークホルダーの方々にスクラム開発の協力要請をしました。我々が開発していくシステムを定期的に検査し、価値提供できているのかを議論していく旨を共有し、快諾していただきました。
インセプションデッキの作成
スプリントゼロの段階で、改めて「我々はなぜここにいるのか？」といったような目的や要件を整理していきました。
特にエレベータピッチは目的を整理する上で効果的でした。エレベータに乗り合わせた際、20秒〜30秒で我々の開発しているシステムを説明する文章のことを示しました。
また、役割の整理をし、プロダクトオーナー、ステークホルダー、開発チーム、スクラムマスターを当てはめていきました。今回のスクラム開発では、私がスクラムマスター兼開発チームといったポジションとなりました。
目的の意識付け
開発が走り出した段階でわかったこととして、我々の開発チームではプロダクトバックログに「なぜこの価値、または機能が必要なのか？」といった目的の明記がないと、開発チームの手が止まってしまうことがありました。
この状況はスクラムマスターの役割の1つであるプロダクトオーナーと開発チームのコミュニケーションの橋渡しで担保するとともに、わからない！となった本人自身が質問していけるようフォローしていきました。また、事前の手立てとして、バックログアイテム作成時に目的の明記を意識的にしました。
別途、スクラムイベントにおいても目的の宣言やエレベータピッチを音読することにより、限られた時間の中で、我々は何を意思決定すべきかを意識していただきました。
開発スキルの向上
今回のシステム開発では、これまでに触れたことのない技術が多く、調べながら開発していくことがインセプションデッキにて明らかになっておりました。
ここでの開発スキルは今後の事業を運営していく上でも押さえておくべきスキルでした。メンバーの開発スキル向上とプロダクトの開発スピード向上のため、社外から開発エキスパートの方に参加していただきました。我々が知り得なかった技術や開発ノウハウを実業務を通して学び、またベロシティを約1.5倍に伸ばすことができました。
Minimum Viable Productの整理
開発の終盤に差し掛かってきた頃、開発チーム内で「どこまで実装したらゴールなんだろうか？」という意見が出てきました。こちらにはヒアリングしていくと「どこまで実装したらローンチするのか？」「ローンチするまでにほしい機能の抜け漏れがないか？」といった2つの文脈があることに気付きました。
アクションとしてユーザーストーリーマッピングの作成を依頼し、ペルソナ・ストーリー・タスクを洗い出し、現在実装している機能との照らし合わせ、ローンチまでに必要な機能の認識を揃えました。
スクラム開発の振り返り
ローンチできたタイミングで、開発チームやプロダクトオーナー、ステークホルダーに振り返りアンケートを実施しました。
プロダクトへの理解度や貢献したイベントに関しては独自で考え、プロダクトオーナーやステークホルダー、開発チームといった関わってくれたメンバーにアンケートを実施しました。
また、自己組織化やアジャイルの車輪は「SCRUMMASTER THE BOOK」の内容を開発チームにアンケートを実施しました。
プロダクトへの理解
プロダクトへの理解は全体的に向上した傾向にありました。ステークホルダーの方々も初めて触るシステムとなっており、開発段階を通じて理解度が向上し、ローンチ後はスムーズに利用していただいております。
プロダクト理解に貢献したイベント
スプリントレビューやプロダクトオーナーの動き、インセプションデッキの作成といった3点が大きく影響していたことがわかりました。
最初の走り出しのインセプションデッキで方針がわかり、そこから検査のためのスプリントレビューで実際に触りながら議論を重ね、レビュー時やバックログリファインメント時に出てきた疑問点をプロダクトオーナーが中心にステークホルダーとすり合わせてくれたことが良かったのだと思います。
自己組織化
自己組織化は6つの質問を実施し、回答によって点数を集計して自己組織化しているかの指標とするエクササイズです。
開発チーム全員が自己組織化している指標のボーダーに乗っていることを確認できました。
スクラムマスター兼開発チームの一員をしていたため、どこまで促せていけていただろうか？とアンケート実施時はドキドキしてましたが、結果を見てホッとしておりました。
アジャイルの車輪
アジャイルの車輪は、市場に出すまでの時間やチームの健康といった計12項目に対して、現状と期待を評価していくエクササイズです。
現状のチームとして、「顧客からフィードバックを得る」がとても高かったです。実際のステークホルダーが社内の方々だったので、フィードバックを得やすい環境だったことが起因しているかと思います。次手は「顧客満足」や「生産性」、「変化への反応」、「品質」といった項目が高かったです。
現状と期待を比較すると、「継続的改善」と「デリバリーの予測可能性」にて大きなギャップがありました。
「継続的改善」はスクラム当初では改善のためのTRYが出てきましたが、中盤になってくるとTRYが出づらくなってきました。変化を起こしてあげる動きが必要だったなと振り返っております。
「デリバリーの予測可能性」については、当初見積もった工数と実際の工数では6倍の差がありました。スクラム導入当初から不確実性コーンの話をしておりましたが、実際にそういった現象を観測しました。また、いつローンチするのか？が終盤のユーザーストーリーマッピングを通じて解消したため、早い段階で実施すべきだったとも振り返っております。
おわりに
本記事では社内で実施したプロジェクトについて、当初の課題感やスクラム開発導入目的、スクラムチームが醸成するために行ったこと、ローンチまでの振り返りを紹介しました。
今回の社内システムのローンチまで、経験として以下のことを学びました。
- スクラム開発の導入目的を明確にしよう
- スクラムの知識を揃えよう
- スクラム開発の最初にやるべきこと（スプリントゼロ）はちゃんとやろう
- 自己組織化を促していこう
スクラム開発でシステムをローンチできたという経験は、今後の開発においても貴重な経験だと思っております。
事業ドメインやスクラムチームの特性によって、取り組むべき課題はチームそれぞれです。課題については因数分解し、どのように改善していくかをチーム内で納得し、チーム全員で取り組めるかが大事になってきます。チームの自己組織化への参考になったのであれば幸いです。