この記事はenechain Advent Calendar 2024の25日目の記事です。
はじめに
こんにちは、ソフトウェアエンジニアの小沢です。
私が所属しているチームではeScanというプロダクトを開発しております。プロダクトをリリースしてから様々な機能開発を行い、ご利用いただくユーザーも増えてきました。
そういった状況変化の中で、eScanチームは開発スタイルの変更とチーム目標設定を通じたチームビルディングを実施しました。そして、チームに存在していた課題を解決するとともに、ビジネス目標も達成するという良い結果を得ることが出来ました。
今回は、我々が行なったチームビルディングに関する取り組みと、その結果としてのチームと個人の変化について紹介します。
eScanチームの課題
まずはじめに、eScanをリリースしてからこれまでの状況について簡単に説明したあと、eScanの課題について触れていきます。eScanは現在、プロダクト・ライフサイクル*1において、「導入期」から「成長期」へ移行する段階にあります。それぞれの期間において、どういう状態であったかを説明します。
導入期
リリース当初はなかなかユーザー導入に至らない状況でした。当時は導入をご検討いただいたユーザーからのフィードバックを受けて、機能の追加・改善を重ね、なんとか導入にたどり着けるよう開発を進めていました。
このときは、ユーザーからのフィードバックを整理し必要な機能を洗い出し、その機能を作成するという流れをプロジェクトとして取り組んでいました。このプロジェクトには基本的に複数人が割り当てられ、プロジェクトは常に複数進行するような形で進めていました。
導入期から成長期にかけて
現在は機能追加・改善を重ねたことにより、実際に導入していただくユーザーが増えてきました。その後も契約社数は増え続けております。 それに合わせて、今までのように機能開発をメインに進める方式から、プロダクトとして追うべき指標とそれをOKRと結びづけた目標を設定し、チーム全体で取り組むスタイルに変更しました。イメージとしてはスクラムをベースとしていくつかのアジャイルプラクティスを取り込んだようなスタイルです。
導入期に感じていた課題
eScanチームでは週1回、プロダクトに感じている課題・問題点などを話し合う場があり、必要なものをタスクとして登録し実行するという品質改善の取り組みがありました。その他、タスク化するほどでもないような細かいリファクタリングや機能以外の小さな改善は、日々の開発の中で行っていました。
しかし、日々の開発やこの取り組みの中で以下のような課題を感じていました。
- 品質改善タスクが個人の状況やモチベーションに依存しがちなので、チームの関心が薄れており進みづらい
- 技術品質の向上やチャレンジ要素の強い新しい取り組みが定常的に実践できない
実際に、毎週品質改善のMTGで進捗状況を確認していましたが進んでいないことが多かったように感じます。
では、この課題を解決するためにどのような取り組みを行ったのか紹介します。
取り組んだこと
まず、時系列に沿ってどんな取り組み・イベントがあったのか簡単に紹介します。
- 2024年5月 - OKR設定(2024年5月~2024年8月)
- 2024年6月 - 開発スタイルの変更
- 2024年6~7月 - チーム目標の設定
- 2024年9月 - OKR設定(2024年9月~2024年12月)
enechainでは、4ヶ月ごとにOKRを設定します。今回取り組みの対象とした期間は、4. 2024年9月 - OKR設定(2024年9月~2024年12月) です。また、2024年6月の開発スタイルの変更でアジャイルプラクティスを取り込んだ開発スタイルに変更しました。
これまで実施してきた品質改善では、タスクが個人に閉じてしまい状況把握が難しく協力しづらいという課題と技術品質や新しい取り組みが定常的にできないという課題の2つがありました。どちらも共通している要因として、以下が考えられました。
- 品質改善タスクの進行がタスク起票者に依存してしまう
- チーム全体として関心が薄れてしまう
改善の意欲はありましたが、緊急度の高い差し込み作業(不具合対応や全社対応など)やKR達成のためのタスクが入ると、このようなタスクは自然と優先順位は下がっていき次第と進まなくなります。また、品質改善タスクは個人で進めることが多かったため、他のメンバーはタスクが今どういう状態か・なにか困っていることがあるのかなどわからない状態でした。
一人なら良いですが、チームメンバーのほとんどがこのような状態になっていたため、チーム全体での品質改善タスクが進まない状況でした。
私はこのような課題に対して、チーム目標の設定とその目標の一部をOKRに設定することが効果的であると考えました。この取り組みには以下のような効果を期待しています。
- 課題をチームの関心事として、捉えチーム全体で取り組む
- ユーザー価値を最大化することに寄与できるチーム目標をKRに設定することで、関心事が離れにくく、ある程度強制力が生まれ進めやすくなる
また、このときには開発スタイルの変更があったため、チームの目指すべき方向を決めたほうが良いと考え、この取り組みをスタートさせました。
チーム目標の設定
チーム目標の設定の前に、メンバー全員に対してチーム目標の設定に対する是非を確認しました。仮にこの段階で誰か一人でも目標設定に対する意味を見出せなかったり、この時間がもったいないと感じたら、目標設定を見送ることを検討していました。
しかし、メンバーは全員チーム目標設定の意義について理解し自分ごととして捉えてくれたため、目標を立てても形骸化しないだろうと考え、チーム目標の設定を進めることにしました。
具体的な目標設定に関しては、以下のステップをMiroを繋ぎながら同期的に実施しました。
ステップ1. チームの理想の状態を決める
チームの理想の状態を決める作業は、以下のように進めました。
- チーム目標要素の読み合わせと質疑応答
- 読み合わせをして同じ内容の付箋はマージする
- 要素から重要視したいものをピック
- 良いと思う案に投票
- 票数が少ないものについてこれは入れたい！というものがあれば熱弁する時間
- 選ばれた要素をもとに目標を考える
最初は事前準備として目標のテキストを出してもらう方式を考えていましたが、事前準備段階では良い言葉が思いつかないというフィードバックがあったので、良いチームの要素の言葉・フレーズを出してもらい、そこから目標を作るように変更しました。
また、チームメンバーは4人なので基本的に全員が理解し、納得するまで議論するようにしました。
ステップ2. 現状と理想のギャップを見つけ出し、ギャップを生み出している課題を抽出し解決策を考える
1.で理想の状態が決まったら、現状とのギャップを見つけ出し、ギャップを生み出している課題を抽出する作業を行いました。 今回は理想の状態を4つ定めましたので、4サイクル実施しました。
- 項目ごとで理想と現状のギャップを抽出する
- 読み合わせ
- ギャップを解消するための打ち手を抽出する
- 打ち手を実行する計測方法を決める
最後に、課題が決まったらいつ実施するかを決めました。このときに、誰が実施するかは決めず、誰でも担当出来るようにしました。これは担当を決めてしまうとまた関心が離れてしまう懸念があるためです。
チーム目標を設定したあとは、月1回振り返りの場を設け、目標に向けて進捗を確認し、課題があれば解決策を考えるようにしました。
振り返りにはMiroを使い、振り返りのフレームワークとしてSailBoatを使用することにしました。以前はKPTを使うことが多かったのですが、ゴールが明確である点、今と将来に対する課題を明確にできる点がSailBoatのメリットだと考え、採用しました。
では、実際にどのような目標が設定されたのか簡単に紹介します。
ここであげたチーム目標と目指す状態に応じて、様々なアクションとしてPBIを作成・紐づけを行い、トラッキングをするようにしました。例えば、チームの状態として「楽にしようというマインドが常にある」に紐づくアクションとして「常に開発体験の向上を意識する」があります。
このアクションには「PBI単位のリリース」というタスクが紐づいています。これは元々品質改善で挙げられたタスクでしたが、後述のKR設定における「リリース頻度が1回/週から4回/週に増加」を達成するための重要タスクとして取り組むこととなり、KR設定とチーム目標を連動させながら進められるようになりました。
このほか、目標設定を通じ以下のような効果もありましたので、簡単に紹介します。
- メンバーそれぞれが何に強い関心を持っているか理解できる
- プロダクト、技術、プロセスなど
- 今課題と感じていることを理解できる
これは個人的なことですが、後のタスクのアサインや議論の際に、根底にある関心事がわかっているため、なぜそのような発言になったのかという理解を深めることに役立ちました。
OKRの目標にチーム目標の内容を反映する
eScanチームのOKRはビジネスチームと一緒に作成しており、基本的にはビジネス目標に関連するKRのほうが優先順位は高くなります。2024年9月のOKRでは、以下のビジネス目標に関するKRが設定されました(具体的な部分は伏せています)。
- KR1: 機能追加・改善を行い、新規顧客の契約を獲得する
- KR2: 既存顧客の取引を拡大する
上記ビジネス目標に関連するKRを達成する前提で、更にチーム目標からビジネスインパクトに寄与する技術的な目標をKRに設定しました。具体的には以下のようなKRを設定しました。
KR3: リスク計算とリリースの高速化
- リスク計算がXX分からYY分に短縮
- リリース頻度が1回/週から4回/週に増加
リスク計算はeScanの根幹を担う機能で、計算時間は可能な限り短時間で終わるのが理想です。現状は、リスク計算の設定・計算・結果確認のサイクルに1時間程度要していました。これでは一連のサイクルが一日数回しかできず、あまり業務効率が良い状態とは言えませんでした。計算時間が短くなれば、ユーザー・エンジニア双方の業務効率の改善につながるため、今回は計算時間の短縮を目標の一つとして設定しました。
リリース頻度の改善は、これから高速に仮説検証を繰り返し、ユーザー価値を最大化することを目指すための土台作りとして設定しました。現状は週1回のリリースで、リリース作業に数時間を要していました。更に、リリース時にユーザーを巻き込まないように注意しながらリリースすることが多く、高速に仮説検証できる基盤が整っている状態とは言えない状態となっていました。
ざっくりとした数値目標として、おおよそ1日1回、リリースに要する時間は1回あたり20分程度を目標の一つとして設定しました。
チーム目標の振り返りの振り返り
チーム目標を設定してから、4回振り返りを行いましたので、その時々でどんなコメントがあったか振り返ります。
1回目: 8月下旬
1回目の振り返りでは、まだ新しいOKRにチーム目標は設定していない状態ですが、チームの方向が定まり走り始めた状態です。このときのコメントを一部紹介します。
- (WIND)技術的な挑戦・変化などを取り入れようとする意識の変化が出てきた
- (WIND)チームメンバーの対応するタスクの幅がひろがっている
- (SUN)久々に勉強楽しい！と感じた
- (ANCHOR)PBI状態・優先度がわからないので改善活動をやっていいか判断つかない
ANCHORで起こった問題については、チーム目標とは少し毛色が違いましたが、チーム目標の進捗を妨害する内容だったためチームで話しました。当時差し込みタスクが発生し、コミットメントラインが不安定になることがありました。そこに対して今何をやるべきか、どういう状態かわらない。というフィードバックでした。
ネクストアクションとしては、差し込みタスクが発生した場合のスプリントゴールの見直しとPdM合意、朝会の報告フォーマットとして、ゴールに対しての進捗と困りごとを中心に会話する。というものをあげ、取り組みました。
2回目: 9月下旬
これは、OKRにチーム目標を設定してから初めての振り返りです。このときのコメントを一部紹介します。
- (WIND)ちょっとした改善がさくっとやりやすくなった
- (WIND)OKRで決まっていると気持ちよく進められる
- (WIND)Hasuraいけそう！
Hasuraに関しては、チーム目標のタイミングで入れてみてもいいんじゃない？技術検証しよう！という流れで少しずつ検証が始まっていったところでした。概ね、チーム目標を設定してからの進捗に対してポジティブなコメントが多かったです。
実際にHasuraの検証は同チームの平田さんが進めてくださいました。興味のある方はぜひこちらをご覧ください
3回目: 10月下旬
KRに設定したチーム目標に対して進捗が出始めた時期です。このときのコメントを一部紹介します。
- (WIND)大きな改善系目標を達成できた。という成功体験ができた
- (WIND)問題をみんなで解決したことで、チームでpnpm workspaceやturboに対する知識が増えた
- (REEF)KR達成に向けての進め方がわからない
- (SUN)モノレポ化できた！
REEFの課題については、ビジネス関連の目標であるKR1が残っており、KR3を達成に対するフィジビリティスタディも足りていない状態であったため、KR1とKR3の双方を達成できない懸念がありました。 ここでは、KR1の達成を必須条件とし、KR3のフィジビリティスタディに数日使い、KR1とKR3の同時達成が見込めない場合は、KR1を優先する方針としました。
4回目: 12月中旬
４回目は最終回だったので、チーム目標の作成もスコープに入れて振り返りを行いました。このときのコメントを一部紹介します。
- (WIND)コミュニケーションが多くなって、チームが明るくなった
- (WIND)スプリント開発しやすい
- (SUN)「開発体験向上」「挑戦的な選択」この辺はだいぶできた
- (SUN)攻めと守りのバランス感覚が身についた
たまに振り返りのタイミングで議論が白熱して時間が多くかかることもありましたが、結果として良い方向に進み、大きな改善にも取り組めたので良かったのではないかと思っています。
変化
チーム目標を設定してから今日にいたるまでに起こったチームと個人の変化について紹介します。
チームの変化
私が感じたことやチームの振り返りであったコメントを元に紹介します。
- 自分やチームの成長を意識したタスクの割り振りができるようになった
- チーム目標があるので、改善タスク自体がやりやすくなった
- チームでの議論や振り返りが以前よりも活発になった
特にチームで話す内容について変化があったと感じました。技術的な部分は、以前よりも新しいアイディアやそれに対してやってみよう！という前向きな姿勢が多くなりましたし、良いものでさくっと試せそうなものがあればその場でぱっとやって、PR出してマージというようなスピード感のある取り組みも増えました。
ビジネス的な部分については、メンバー間で知っている情報に差があります。しかし、チーム目標として顧客の理解を深め、課題解決に向けた本質的な機能開発ができるようにするという目標があります。そこに対しては、ビジネス側が共有してくれた議事録やその内容を共有し、ユーザーがどんなことを考えているのか、自分たちで開発した機能がどう活かされているのか議論するようになりました。また、他のプロダクトの情報も共有するようになり、全社としてどういう動きがあり、eScanのユーザーにどう影響があるか考えたりと議論の内容もかなり広がってきており、チームとして大きな変化があったと感じています。
個人の変化
ここでは個人に起こった変化について、私が感じたことやメンバーからのフィードバックをもとに紹介します。
- 開発や運用に対するマインドの変化
- 個人が大事にしたいものとチームが大事にしたいもののバランスが取れるように
- メンバーの様々な意見が受け入れられるように
- チーム目標があるから何を意図した意見か理解できる
- 柔軟な発想が生まれるように
- NestJSの廃止案
特に個人的には、開発や運用に対するマインドの変化に驚きました。以前であれば、運用第一で新しい技術の導入や取り組みについては、あまり積極的ではなかったのですが、今ではチーム目標に対してどう取り組むか、どういう意図で取り組むかを考えるようになりました。結果として、自分から「今のこういう取り組みはやめよう。」とか、「これめんどくさいね。」という発言が出るようになり、メンバーから驚かれることもあります(良い意味での驚きです)。
終わりに
今回eScanチームで設定したOKRの達成状況は以下のようになりました。OKRの最終月のため、定まっていないところはありますが重要指標であるKR1はすでに達成済みです。その他もMustは十分達成できる見込みです。
- KR1: 機能追加・改善を行い、新規顧客の契約を獲得する => Must項目の達成、ストレッチ項目の一部達成
- KR2: 既存顧客の取引を拡大する => Must項目の達成水準、ストレッチ項目の一部着手
- KR3: リスク計算とリリースの高速化 => Must項目の達成水準、ストレッチ項目の一部着手
結果として、ビジネス目標を達成しながら、チーム目標も達成させることでユーザー価値を最大化するための土台を作ることができました。また、その中でチームと個人の変化があり、結果としてチームの成果につながったと感じています。今後もこのような取り組みを続けていき、チームとプロダクトを成長させ、ユーザー価値の最大化に努めていきます。
enechainでは、事業拡大のために随時仲間を募集しています。興味がある方はぜひお声がけください！
*1:プロダクト・ライフサイクルとは、製品の売上と利益の変遷を4つの段階で説明するモデル。導入期、成長期、成熟期、衰退期それぞれの市場環境と基本戦略を提示する理論である。出典元:野村総合研究所 用語解説 プロダクト・ライフサイクル
