キャリア台帳チームでエンジニアリングマネージャーをしている溝渕です。
私が所属するSmartHRでは、多くのチームでスクラム開発を採用しており、労務ドメインではScrum@Scaleの運用も開始しています。ちなみに、どの程度スクラムが採用されているかと言うと、スクラムとか色々やめましたというブログが出るぐらいには普及しています。
そんな中、キャリア台帳は2024年2月にリリースされ、2024年9月からスクラム開発をスタートさせました。
この記事では、もともとスクラムを取り入れたいと思っていたわけではないキャリア台帳チームが、どのような軌跡を辿ってスクラム開発へ移行したのかお伝えします。
キャリア台帳チームでスクラムを採用していなかった背景
最初に、SmartHRでは多くのチームでスクラム開発を採用しているにもかかわらず、キャリア台帳チームでは採用していなかった理由をご説明します。私の入社前ですが、リリース前は、ユーザーの要望も見えにくく、細かい検証が不向きだったなどの理由で、スクラムを採用していなかったとのことです。リリース直後も、キャリア台帳チームにスクラム開発を導入するメリットが見えておらず、実践していなかったそうです。私はリリースして数ヶ月が経ったころに入社したのですが、同じ状況でした。
ただし、スクラムではなかったとは言え、朝会（デイリースクラム）、リファインメント、振り返り（レトロスペクティブ）など、部分的にスクラムの要素を取り入れた状態で開発は進めていました。
もともとはカンバンで運用をしており、状況や課題に応じて徐々に必要なイベントが追加されていったらしいです。（自分が入社する前の話なので詳細は把握していません。）
以下は当時のSlackのコメントを抜粋したものですが、みんなが色々と悩んでいることが分かります。
- スクラムまでやるべきか悩ましいところ
- 早めにスクラム回し始めたほうが良さそう感
- スクラムはちゃんとやろうとするほど、いかにスクラムをうまく回すかに関心事が向いてしまうので難しい
- 前のプロジェクトはちゃんとスクラムをやってたけど、スプリントレビューで実際にプロダクト活用している人に話を聞けるのは良かった
プロダクトとしてのフェーズに変化が訪れた
キャリア台帳をリリースしてから1年ほどが経過し、プロダクトとしてのフェーズが変わってきたなと感じました。
まずは、フェーズが変わる前の状況を紹介します。以下は、スクラム開発導入前の2024年下半期開始時に設定したOKRです。ユーザーが求めていることが一定把握できていたこともあり、機能のリリースにフォーカスされていることが分かると思います。
- 提供予定の機能
- 〇〇がキャリア台帳で閲覧できるようになっている
- △△がキャリア台帳で閲覧できるようになっている
- ☓☓がキャリア台帳で閲覧できるようになっている
- ……
- 目標
- satisfactory
- 上記のうち5件がユーザーへ提供されている
- very good
- 上記のうち7件がユーザーへ提供されている
※プロダクトによりますが、キャリア台帳ではコミットゴールをsatisfactory、ストレッチゴールをvery goodとして定義しています。
続いて、フェーズが変わったあとの状況を紹介します。以下は、スクラム開発導入後の2025年上半期開始時に設定したOKRです。目標が提供する機能の数ではなく、ユーザーの活用度合い（アウトカム）に変化していることが分かると思います。
- 目標
- satisfactory
- 対象テナントのうち、マネージャー以上の管理職に権限が付与されているテナントが〇〇%以上になっている
- very good
- satisfactoryを満たした上で人材育成に必要な定性情報が蓄積されているテナントが△△%以上になっている
チームとしてアウトカムを狙うようになったことは良い変化だなと感じました。
定量的なアウトカムを定義し、進捗を解釈することで、スクラムチームは将来的な指針を定め、ステークホルダーへ価値を提供できているか検証することができます。
2025年に発表されたScrum Guide Expansion Packでもアウトカムについては語られています。
2024年下半期から2025年上半期にかけて、プロダクトやチームに求められることが変化したことは、2024年下半期の途中でチームがスクラム開発に移行したことの要因の一つとしてあると考えています。
度々のリリース延期を経験し、スプリントレビューの開催へ
実はスクラムへ移行する前の2024年下期に、キャリア台帳チームは2回ほどリリースを延期しています。1つはユーザーに不都合が発生するケースが見つかったから、もう1つは機能不足によるユーザーからの問い合わせが明らかに増えることが予想できたからです。
スクラムへ移行する前のキャリア台帳チームでは、スプリントレビューの形式でフィードバックを受けていませんでした。
レビューを全く受けていないというわけではなく、ある程度必要な機能を作りきり、一通り動作する状態になってから、朝会や夕会の中で見てもらうケースが多かったです。
また、ユースケースに沿ってステークホルダー（社内の人事など）にプロダクトを触ってもらい、フィードバックをもらうケースも自分が観測している範囲では多くなかったと思います。
ただ、リリースが度々延期されてしまう問題をそのままにしておくわけにはいかないので、少しずつ改善を進めていきました。
開発チームがステークホルダーに対して単に機能紹介をするだけでなく、ユースケースを伝えた上でステークホルダーにインクリメントに触れてもらったり、エンジニア視点でほしいフィードバックの観点をお伝えしたり、デザインモックの状態で触れてもらうなど、検証に必要な要素を増やしていきました。
結果として、現在は週に1回30分の固定枠を設けて、スプリントレビューを開催しています。
とは言え、スプリントレビュー開催には一定コストがかかるので、随時非同期でレビューをもらうためのテキストコミュニケーションや、少しでも早くプロダクトを触ってもらえるようにカスタマーサクセス（以降CS）やカスタマーサポート（以降SP）の方にchromaticのアカウントを発行し、画面だけ先に開発することで、フィードバックを受け取れるようにしています。
OKRの進捗が見えない不安から、スプリントプランニングの開催へ
スクラム開発移行前の話ですが、2024年下期OKRの進捗が見えないという不安が度々レトロスペクティブで上がっていました。
OKRに対する現在地が見えず、改善系のタスクを着手することに気が引けたり、チームとしてどの程度の出力を維持し続ける必要があるか分からないなど、背景は様々です。
現在地を把握するためにも、今見えている開発のざっくりとした見積もりをチームで行い、スケジュールに落とし込みました。
ビジネスの状況や開発リソースによってスケジュールは常に変わりますが、一旦これで現在地は把握できました。
現在地が見えたことで、開発チームがいつまでにどのような価値をステークホルダーへ提供する必要があるか、プロダクトとしてどのような状態になっていれば良いか、大まかに把握することができます。
そこで、キャリア台帳チームは、目標と現在地の差分を検証するために、スプリントプランニングの運用を開始しました。
最初はレトロスペクティブの中で軽くOKRの進捗を確認する程度でしたが、次のスプリントのTODOリスト（スプリントゴールではないです。）を作成するようになり、先々を見据えて詳細化しておきたいチケットを洗い出したり、スプリントゴールについて話し合うようになったりと、徐々に変化してきて、現在はレトロスペクティブとは分離してスプリントプランニングを開催しています。
スプリントプランニングの中でスプリントゴールを設定することで、スプリントの終わりに自分たちがOKRで達成したいゴールに対して進捗できているか、細かく検証できるようになりました。
スプリントレビューとスプリントプランニングが追加されたことで、スクラムガイドで定義されている全てのイベントを実践するようになりました。
このタイミングで社内のアジャイルコーチの方からスクラム開発への移行を提案いただき、キャリア台帳チームは正式にスクラム開発をスタートさせました。
アウトカムを設定したことによるスクラム開発の加速
会社やサービスが大きくなるにつれて、アウトカムの規模が大きくなり、達成するために必要な関係者も増え、責任の境界も曖昧になりやすいです。
そんな中、開発チームとしては、ついつい機能のリリースにフォーカスしたOKRを立ててしまう気持ちも分かります。自分たちでコントロール可能で、計測もしやすいです。
それでも、歯を食いしばって開発チームがアウトカムを狙い続けることは価値あることだと考えています。
アウトカムを設定したことによる効果を感じる場面が、スクラム開発導入後の2025年上半期にありました。
CSVを利用したアカウントの一括追加・編集機能のリリースです。
期初のタイミングではCSVによるアカウントの一括追加機能を作る想定は全くありませんでした。
キャリア台帳は元々人事や経営層をターゲットとしていましたが、2025年からは現場のマネージャーもターゲットにしており、アウトカムとしてマネージャーの活用状況をOKRに設定しました。
そこで、開発チームはプロダクトマーケティングマネージャーやプロダクトマネージャーと協力して現場で活用してもらうまでのステップを定義し、どこで離脱しているか調査を実施しました。
結果として、マネージャー向けの権限を付与するタイミングでテナント数が大きく落ち込んでおり、そもそもマネージャーに権限を渡すことにハードルがあることが判明しました。このタイミングで開発チームは、権限を付与するハードルを下げる方向にシフトすることができたのです。
マネージャーへの権限付与を困難にしている理由の1つに、権限を変更する際には、画面上から１人ずつ操作する必要があることが挙げられます。
ターゲットが人事や経営層だけであればそれでも問題ないのですが、マネージャーまで拡大すると対象人数が多くなり、部署異動や昇格にあわせて1人ずつ権限を変更するのは手間だったり、操作ミスが発生する可能性が高くなることで、権限付与まで踏み切れないユーザーが一定数存在することが分かりました。
最終的には運用コストの低さから、CSVを利用したアカウント一括追加・編集機能を開発する方向になりました。
ユーザーの課題整理には、社内のCS、SP、人事の方にご協力いただき大変感謝しております。
アウトカムを設定したことで、多くの関係者を巻き込みながら、ユーザーの課題整理、チームの方針転換、リリースの達成をすることができたと思います。まさに、スクラムにおける検査・適応を実践できた良い例でした。
現場マネージャーに権限を付与している企業様も2025年1月と比べて2025年6月では1.8倍ほどに増えています。
ただし、OKRの方向性は良かったものの、開発チームだけでは達成できないことによる不安、CSやSPと開発チームの間で優先度にズレが生まれているなど、少なからず課題もあったので今後改善していきたいと思っています。
現在のキャリア台帳チーム
キャリア台帳チームの特徴として、ほぼ毎日リファインメントをしていることが挙げられます。
もともと週2日1時間ずつリファインメントを実施していたのですが、より柔軟に開発アイテムを選択できるように毎日実施するようになりました。
現在のキャリア台帳チームの1週間のスケジュールは以下のようになっています。赤がスクラムイベント、青がその他の会議です。
水曜日はもともと固定の会議が多かったので、スクラムイベントも水曜日に実施することで、長時間開発に集中できる時間を確保しています。
ただし、水曜日が1日会議になったことで、腰へのケアが急務になっています。（※キャリア台帳チームは比較的シニアな方が多いです。）
最後に
プロダクトとしてのフェーズの変化に伴い、開発チームのプロセスも大きく変わってきました。今の状態も1年前からは想像もつかないです。
ここから半年経つ頃には、今の状態から更に大きく変化していることでしょう。
プロダクトやチームが抱える不確実性を糧にキャリア台帳チームは成長してきたと思っています。これからも不確実性を楽しみつつ、ユーザーのビジネスを加速させるプロダクトを作っていきたいと思います！
We Are Hiring!
タレントマネジメントの領域は非常に不確実性が高く、非常にスリリングな開発環境です！
少しでも興味を持っていただけましたら、以下のリンクをポチッとお願いします！
