この記事はInsurtech研究所2025アドベントカレンダー14日目の記事となります。
半年実施していたプロジェクトが12月で終わります。プロジェクトのふりかえり自体はまたチームメンバーとあるのですが、その際も使えると思うので、個人的なふりかえり（気づき）を先に書いておこうと思います。
結構特殊な立場で参画していたので、あくまでも個人に拠った感想となります。
プロジェクトの概要
従業員向けの総務/事務系の作業について紙作業⇒電子に切り替えるため、開発を実施するにあたって、画面イメージやUXについて検討してプロトタイプを作成するプロジェクトでした。自社向け作業とはいえ、数万人の方が毎日使う業務だったりするので、UXの影響が非常に大きいということで立ち上がったプロジェクトになります。
FigmaとAIを活用しながら２日間のスプリントを繰り返しつつ、画面を修正し、実際のユーザーにインタビューしたり、様々なステークホルダーに情報を聞きながらスプリントを回すということを実施していました。
私自身はPO補佐とSMを兼任するような形でプロジェクトを進めていました。補佐と書いていますが、かなりPO側に越境して対応を進めていたのが実態です。
プロジェクト自体は成果物もでき、普段あまり出来ていない動くものを触ってもらっての現地インタビューなどもしっかりでき、アジャイルの新たな進め方も体験でき概ね良かったのだと思います。ただ、個人的には反省点がいくつかあるので、反省点や良かった点について記載しておきます。
POとスクラムマスター/コーチ業は兼任の難しさ
分かりきっていて、何度か経験していますが、POとSMの兼任は難しいなと思いました。アジャイルが初めてのお客様で、さらにPOとしての経験もあまりない。また、PO作業時間にも若干の懸念がある、といった時は特に最初は自身が、PO代替として作業しつつ、「やって見せる期」→「やらせて見せる期」に移行する形で、進めるのはかなり良いと感じています。実際に経験しないとわからないことが多いので、最初に一定のリズムで動くインクリメントを定期的に作り出すことができると、その後の展開がかなり楽になります。
ドメインに一定理解がある等、前提はあると思いますが、私は、生命保険業界であれば、わりとPO代替として最初スタートダッシュを切れるという自信があります。
初めてのアジャイルだとステークホルダーも怪しんでいるところがあるので、スタートダッシュは結構重要で、このやり方は一つの勝ちパターンなのですが、スタートダッシュからの移行をうまくできていないのが現状です。
POの移行については何となくは出来るのですが、問題はPO補佐という立場になってからアジャイルコーチ、スクラムマスターとしてチームの自己組織化を進める際のふるまいがうまくできていないことがあります。
問題があった時にどうしてもPO補佐の立場として考えてしまい、短期的な解決をしてしまう傾向がありました。発生した問題自体は解決に動くのですが、もっとアジャイル/自己組織を意識した動きをしないといけないと反省しながらも実際出来ていないということが多かったです。
具体的には下記のような問題がありました。
- ふりかえりについて、チームのカイゼンに時間をかけるよりプロダクトとしてのカイゼンを優先させてしまい、十分時間をかけられなかった
- 透明性を高めて、検査/適応するといった活動をサボりがちになった。特に開発者/デザイナー⇔POで状況を見える化することをサボってしまい、若干の分断が生まれてしまった
- レビューについて、開発者が作ったものをPOやステークホルダーに説明するという構図が多く発生しがちで、インタラクティブなレビューにするような動きをあまりかけられなかった
- チーム自体の学習にもっと興味を持たせたかったが、後回しになってしまった
- SHにアジャイルの進め方などをもっと理解してもらうような動きをかけないといけなかったが、サボってしまい、SHの状況に合わせて楽にレビューしてしまった（インタラクティブな動き等最初はかけていたものの、途中からは普通のレビューといった動きになってしまった)
難しさの背景
問題として大きかったのは私の時間が限られている中で、さらに期限もわかっている受託開発の中で、自身が若干、計画駆動およびPOドリブンな動き方をしてしまっていたこともあったと思います。最近610さんが下記ブログでスクラムマスターの仕事について書いていましたが、こういった時間を取ることは割と必須だと思っています。こういった時間を取ってチームと向き合わないと良い意味で不確実性を自分達で高めて新たなことをどんどんやるような雰囲気になりづらいので、やはり難しいと感じました。
また、固い企業文化の中で、かつ受委託という関係性の中でアジャイル開発を進める場合、さまざまなステークホルダーから強い要求や圧力がかかりがちになります。POに対しても上司から多くの指示が出るため、「プロダクトをどう良くしていくか」を考えることよりも、「上司にどう納得してもらうか」が優先されやすい状況になります。
こうした状況では、チーム自身に立ち返って問い直す働きかけを意識的に行わない限り、変化を起こすことは難しいと感じました。
その意味で、チームに問いを投げ続けられるスクラムマスターの存在が非常に重要だと実感した案件でした。一方で、良し悪しは別として、私はバランスを取ることを優先し、その場を収める方向に動いてしまった場面が多かったと感じています。
取組でよかったこと
とはいえ、0⇔100でうまくいかなかったということでもなく、上記のような「POと開発者の壁がある」「SMがあまり機能できていない」ということに対しては対応も色々進めていきましたので、良かった点を中心に記載します。
モブワークの価値
要件を詰める作業などで、POと開発者と皆でワークをして、その時間に要件をまとめるという作業を何回かやりましたが、お客様側のPOも非常によさを感じてもらっていました。やはり実際に一緒に進めるという経験が大事だと改めて思いました。
本当は、もっと普段から一緒にいて仕事を進めるということに慣れるとより良かったのですが、同期/非同期ともどうしても一緒に進めるという文化までは作れませんでした。この辺はかなり意図的に動かないと、またその時間を取るようにしないと自然にはなりづらいと感じました。
支援側でのＭＴ/ふりかえり
今回のプロジェクトはお客様をPO代替、開発者で支援するという形でしたが、支援側メンバーでのふりかえりや、1on1は良かったです。その中で出てきた声を踏まえて、いくつか対策を打てたので、重要だと思います。また新たな環境はそれだけで負荷なので、自分達のケアという意味でもしっかり制度化した方が良いと思いました。
一方で1on1等は支援先メンバーとも定期的に実施する仕組みを作っておけると良いと思いました。この辺は最初の設計で整理したいと思います。ちゃんとしたSMであればやると思うのですが、先ほども記載した通りPO業務を優先させてしまい、今回はそこまで出来ませんでした。
モヤモヤを確認する会
日々のDS（デイリースクラム）で、モヤモヤを確認する会をやりました。そのモヤモヤから出てきたタスクは重要度・優先度が高いものが多い気がしたので、とても良かったです。ただ、PO側のモヤモヤが中心で開発者側のモヤモヤが途中から少なくなってきたので、その点についてはまたふりかえり等で確認したいと思います。個人的には、日々のスプリントに慣れてくると「こういうもの」という前提ができてしまい、モヤモヤが上がりづらいと感じました。
ただ、スクラムのフレームワークや仮説検証の進め方等世の中のやり方と比べると、モヤモヤしたことは個人的には結構あったので、そういったモヤモヤを増やす活動がいるのかもと思いました。モブワークの時など、動画視聴などの勉強会もしましたが、たくさんはできなかったので、学習により共通言語を作るという行動は意図的に入れないといけないと改めて思いました。
PO/SMをサポートする会
私が忙しいということで開発者中心にSMの仕事などを刈り取れないか、という点を話してくれて実施してくれました。とても嬉しかったです。ありがとうございました。
おわりに
ということで個人的なふりかえりでした。一人でふりかえるとネガティブな意見が多く出ていますが、プロジェクト全体としては非常に良いものではあったと思うので、チームでふりかえって可能であれば、どこかで発表できるネタに昇華できればと考えています。
読んでいただきありがとうございました。
