こんにちは、プロダクトエンジニアのa2cとプロダクトマネージャーのdaisukeです。
本稿では、2024年1月に組成され、スクラムを採用した私たちのチームが最初の3ヶ月間に直面した課題とその改善策、それによってもたらされた変化を共有します。スクラムに参加するエンジニアとPMの多様な視点を取り入れ、実際の経験に基づく具体的な事例をオープンに紹介します。
なお、この記事は「SmartHRのプロダクトマネージャー全員でブログ書く2024」への参加記事です。ぜひ他の記事もご覧ください。
チームの紹介
PM1名・プロダクトエンジニア3名の計4名がコアとなり、価値提供に責任を持ちます。そのコアチームに兼任のプロダクトエンジニア(チーフ)1名・兼任のプロダクトデザイナー1名が加わりチームを構成しています。専任のスクラムマスターはいません。
担当しているプロダクトとプロジェクトは、SmartHR Plus、SmartHR API、SmartHR Labs等と多岐にわたります。
コアメンバーの4名の社歴はチーム組成時点で平均2ヶ月で、とっても社歴の浅いチームです。開発プロセスは、前身となるチームから引き続きスクラムを継続して採用していました。
ここからは、1~3ヶ月目でそれぞれどのような状況でどのような施策を実行してきたのかに注目してお伝えします。
1ヶ月目：新チームの一歩目
新たなチームが発足した当初、開発プロセスだけでなく日常のコミュニケーションに至るまで、多くの認識のズレが発生していました。そのため、チームの生産性も低く、アウトプットの数も少なかったです。
目指すチームのあり方を決めた
チーム結成直後、プランニングやリファインメントなどのイベントを実施していましたが、各イベントの目的や成果物、お互いの役割分担などの認識がズレており、デリバリーが遅くなっていました。
チーム全員が改善の必要性を感じていましたが、具体的な方向性が定まらずにいました。 この問題を解決するために、社内の『アジャイルコーチ相談枠』を利用してチームの状況を共有したところ、「まずはチームでどういう状態を目指していくのか話し合うのはどうか？」という提案を受けました。そこでチームメンバー全員で話し合った結果、「自己管理型チーム」（誰が何を、いつ、どのように⾏うかをチーム内で決定するチーム）を目指すことで意見が一致しました。
（自己管理型チームを学び、感じたことを全員で共有しました）
仕事だけでなく人間として仲良くなった
チームが結成されたばかりで、まだお互いの性格や人となりを十分に理解していませんでした。そこで、心の距離をぐっと近づけたいと考え、以下のような施策を行いました。
- 総当たり1on1
上司とメンバー間だけでなく、メンバー同士も1on1のミーティングを行い、個々の関係を深めました。トピックは各々お任せで、カジュアルな内容もプライベートな話題も大歓迎です。 - 雑談会
金曜日の朝会でランダムなトピックを使ってお互いのことをより深く知る機会を設けました。 - 出社推奨日
月に1回の頻度でオフィスに、任意で集まり、飲み会でのカジュアルな交流やオフラインで実施するミーティングを設けることで、チームの結束を強化しました。基本的には開発組織のLT大会の日に合わせて設定されます。
（雑談が大事すぎて、個人開発で雑談アプリつくりました！！）
2ヶ月目：混乱と成長の兆し
2ヶ月目に入ると、私たちは大きな混乱期に突入しました。自己管理型チームを目指す共通認識を築き、メンバーが自由に意見を共有するようになりましたが、チームのデリバリーは短期的には向上しませんでした。対話やプロセスを負担に感じ、「本当にスクラムを続けるべきか？」という議論もありましたが、認識のズレをお互いに埋めあって、徐々にチームの型が見えてきました。
理論を学びながら実践のくりかえし
時間とともにメンバー間のスクラムの知識と経験の違いが課題として浮かび上がりました。スクラム未経験者やスクラムを体系的に学んでいないメンバーもおり、各スクラムイベントの準備、イベントの進行、求められるアウトプット、使用する用語に至るまで、一貫した定義が欠けていました。これが原因で開発スピードが落ちたり、手戻りが発生していました。
これらの問題を解決するため、会社が開催するスクラム講座にチーム全員で参加し、スクラムの理論を学びながらチームの課題に対処しました。このプロセスを通じて、全てのスクラムイベントと会議の運営方法を見直しました。例えば、デイリースクラムだとこんな感じです。
2024年2月当時
- 各自の進捗（昨日やったこと、今日やること、困っていること）の口頭共有
- （もしあれば）議論や質問
2024年4月現在
- 各自の進捗をスプリントバックログを画面共有しながら共有
- スプリントゴールに対する進捗をチームで確認
（直感的かつ視覚的に表現できるように天気で例えています。）
見直して実践し、また見直すことをいとわない経験主義を、チーム一体の文化として育て始めた期間でした。スクラム講座ありがてえ..（いまなら無料！）。
tech.smarthr.jp
フロー効率の向上
私たちのチームは複数のプロダクトやプロジェクトを同時に扱うことが多く、各スプリントで個々人が担当するタスクに集中しリソース効率を重視する傾向にありました。その結果、チームとしてフロー効率が低く、価値提供までの時間が長くなっていました。
この問題を解決するために、明確なスプリントゴールを設定し、チーム全体の目標と優先タスクを明確にすることでフロー効率の向上を目指しました。具体的にはロードマップのプロダクトゴールからスプリントゴール案に分解し、プランニングでスプリントゴールと達成指標をチームで決めています。
これにより、個々人のタスクではなくチームの目標達成にコミットするマインドが生まれ、タスクの透明性が高まり、スプリントゴールの達成に向けた自律的な協力が自然に発生するようになりました。
（プロダクトゴールからスプリントゴール案に分解しています。魂のこもったゴールを常に追い求めたいです。）
3ヶ月目：変化の実感
日頃のコミュニケーションがスムーズになり、全員の意識が自然とスプリントゴールに集中するようになりました。この変化と合わせて、機能の企画から開発、リリースまでのスピードが明らかに速くなっていきました。
プロダクト開発知識の共有と文化の形成
先述したようにメンバーの社歴は浅く、プロダクト開発知識の不足や知見の暗黙知化が課題となっていました。具体的には、例えば「フロントエンド・バックエンドの設計意図を知りたい」「SmartHR Plusの一部の機能について仕様がよくわかっていない」といった声があがりました。この問題を解決するために、私たちは以下のような対策を講じました。
- 開発伝承会の開催
「そもそも何がわかっていないんだっけ？ 何がドキュメント化されていれば良いんだっけ？」という問いから始め、過不足なく最小限のコストで知識を身につけることを目指しました。 - プロダクトバックログアイテムのREADY状態の明文化
プロダクトエンジニアのB6がリードしてくれ、開発チケットの開始条件を明確にして、作業の着手前の不明瞭さを解消しました。 - Design Docの手法導入
プロダクトエンジニアのutakahaからの提案で導入されたこの手法は、効果的なドキュメント作成文化を確立しました。
これらの取り組みにより、チーム内の情報共有やコミュニケーションがスムーズになり、開発プロセスの透明性も大きく向上しました。
(チームの皆で一語一句にこだわって話し合いながら定義しました。)
チームに現れた変化
スクラムを学びながらチームの運営を見直したことで、チームの目標達成に向けたリリースに集中できる体制になりました。チームに現れた変化を2つ紹介します。
- リリースまでのリードタイムが削減された
チームのスプリントゴールと優先タスクが明確になったことで、チームの集中を引き出し、機能の企画から価値提供を行うまでの速度が向上しました。その結果、リリースした機能は2ヶ月間で約3倍になりました。 - 仮説を検証して次の改善へ活かす動きが取れ始めた
開発プロセスの見直しにあわせてプロダクト開発の改善サイクルを見直しました。具体的にはリファインメント時点で検証計画をチームで合意し、リリース後に検証期間を経てから達成基準を満たしているかチームで確認して、次の改善に向けて学んでいます。
（黄色がリリース機能です。四半期振り返りでウオオオとなりました）
メンバーの声
それぞれのメンバーが振り返って感じたことを共有します。
3ヶ月振り返って感じることは？
「振り返ってみると、良い変化も良くなかった変化もありますが、それを経験できたことがとても大事だったと感じてます。毎日の小さな検査と適応の積み重ねが3ヶ月で大きな改善になりました。」（utakaha）
「振り返ってみて3ヶ月の間に、これだけ色々なプロセスの改善に向き合い、実行されていることにシンプルに驚きました。混乱と秩序を繰り返して、みんなで遠くに行けている最中という気持ちがあります。」（B6）
「何かしらの”方法”にだけ注目してしまうとフレームワークの罠に陥っちゃって本末転倒だと感じました。『なぜやるのか？』というWHYに注目してみんなで議論を重ねた結果、チームが軌道に乗り始めたのかなと思います。」(a2c）
「みんなが問題と人を切り離して解決に集中していたのがよかったですね。みんなすごい。」（daisuke）
自分自身またはチームとして、大きく変化したと感じることは？
「チームとして、変化していくことに恐れがなくなりました。試した結果うまくいかなかったとしても、経験から得ることが大事という共通認識があるので、色々なことが試せるようになりました。」（utahaha）
「経験主義への信頼感です。予期せぬ状況や問題が起こっても、舵をとりなおせばなんとかなるよねという前向きな気持ちを与えてくれた気がします。」（B6）
「一つのやり方や正解に囚われず、小さく試してチームで経験を大切にするという姿勢が身につきました。そうして得られた経験に基づいて振り返ったり、意思決定をしていくことで精度も上がったような気がします。」(a2c）
「ミーティング中に笑ったり冗談を言うシーンが明らかに増えていること。チームは機能してきたので、良いサービスづくりに集中できるぞ！」（daisuke）
今後のチームの伸びしろは？
「まだまだチームとしてアジャイルやスクラムの知識が浅く、スプリントの改善に時間がかかることがあります。今後アジャイルやスクラムをより深く理解することで、課題を発見するスピードが上がり、より良い改善ができるのではないかと考えています。」（utakaha）
「しばしば課題の発見や調査をプロダクトオーナーに任せきりにしてしまい、トップダウンで開発者がそれを受け取ることがあるので、開発者もプロジェクトの初期段階から積極的に参加し、自分たちの専門知識を活かして課題の発見や調査に取り組みたい。」（B6）
「改善施策のバリエーションや引き出しを増やしていくことや、専門家に頼ることを更に推進して行きたいなと思っています。何か課題が出た時に、最短距離で素早く解決していくために私たちだけの知識と経験だけではなく、先人の方々や社内の有識者の力を借りてレバレッジを効かせていきたいです。」(a2c）
「チャレンジ精神ですね！ 高い目標を限りあるリソースでどう達成するか、そのために何をすべきか、自分も含めてストイックにチャレンジしていきたいです！」（daisuke）
おわりに
私たちの3ヶ月間はいかがだったでしょうか？ 日々大小さまざまな改善を繰り返しながら少しずつ私たちなりの”型”が出来上がってきていることを実感してきています。
スクラムを採用した初期のフェーズでは、私たちがそうであったように多くのチームが様々な壁にぶつかることだろうと思います。私たちも依然として様々な壁に向き合い、乗り越える術を模索し、自律的な改善を続けています。スクラムといったある種のフレームワークには完成された状態や正解のようなものがあるかのように錯覚してしまいますが、現実はそうではないことも経験から学びました。スクラムにとって目指すべき状態は、様々な場面における変化や困難に対して自律的な課題解決を行っていける、変化に強い組織状態だと考えています。
We are hiring !
SmartHRでは引き続きプロダクトエンジニア、プロダクトマネージャーの採用に注力しています。 各職種に関する情報をまとめた記事がありますので、ぜひご一読ください。カジュアル面談のリンクなどもこちらに掲載しております。
