チームにスクラムを導入したらチーム力がアップした話
見出し画像

チームにスクラムを導入したらチーム力がアップした話

はじめに

こんにちは。株式会社マネーフォワードにて『マネーフォワード クラウド勤怠(以下、勤怠)』の開発をしている磯野です。

社内外ではkatuo(カツオ)と呼ばれています!私はマネーフォワードに2021年6月にジョインし、現在はフロントエンドを始め、サーバーサイドの開発など幅広く勤怠の開発を行っております。

突然ですが、直近、クラウド勤怠開発チーム(以下、チーム)では開発体制にスクラムを導入しました。この記事ではクラウド勤怠にスクラムを導入してから約2カ月たった今、改めて振り返りを書いていこうと思います。スクラム開発導入に興味がある方やクラウド勤怠の開発体制などを知りたい方は是非ご覧ください!

私が入社した直後のチームの状態

自分がチームにジョインした直後の感想をそのまま打ち明けるとメンバー同士で同じ方向を向いて仕事をする機会があまりなかったように感じました。

また、チームとしての目標が何かを意識する場面があまりなく、事業部側から何を求められているものは何か?マネーフォワード HRグループの中でチームはどのように動いていけば良いか?などがわからず、モヤモヤしながら仕事をしていました。

スクラムを導入した理由

画像2

そんな中、プロダクトマネージャーの提案によりチームにスクラムを導入することになりました。導入に至った理由は大きく分けて3つあります。

チーム力を高める

これまでの開発体制は、チームで開発を進めるというより、個々のメンバーでプロダクトマネージャーとコミュニケーションをとりながら、それぞれ開発を進めるといった体制でした。

これはエンジニアのリソースを効率的に使えるというメリットはあるものの、慢性的にドメイン知識やタスクが属人化してしまったり、チームで何かをするといった一体感が欠如してしまう、といった問題がありました。

生産性の向上

勤怠のシステムを開発にするにあたって、タスクによっては深いドメイン知識が必要になります。そして、チームメンバー全員がドメイン知識を知っていなければ開発スピードが極端に遅くなり、従来の個人ベースでの開発体制ではチーム間でナレッジ共有できず、新入社員・新メンバーの開発スピードや品質の底上げに時間がかかってしまう状態でした。

ここでいうドメイン知識とは、勤怠に関する法令や実務知識だけでなく、これまで書かれたコードに関する知識も含みます。

ユーザへの価値提供を通じた、ミッションビジョンの実現

前述の通り、これまでは個々のエンジニアが基本的に一人で開発を進めていくという体制だったので、プロダクトが抱える課題に対しての意識が薄くなりがちでした。

新メンバーの割合が多いクラウド勤怠においては、「チーム vs 課題」という構図で、課題に対してチームの力を結集するというマインドの醸成が必要な状態でした。

スクラムを導入して良かったこと

画像3

チームにスクラムを導入してから約2ヶ月が経過し、チーム内でポジティブな変化が現れました。大きな変化として次の2つが見られるようになりました。

情報共有が活発になった

チームにタスクが紐付くようになったこともあり、モブプロ・ペアプロを実施する機会が増えました。

テキストベースのコミュニケーションとは違って、既存の仕様や実装の歴史的な経緯などを気軽に話せる場面になり、1人で実装していたら中々気づけないであろう貴重な情報が活発にチーム間でシェアされるようになりました。

また、リファクタリングやパフォーマンス改善といった直接事業に関係しないタスクを行う場合も、今のスプリントで実施するか否かを開発メンバーで相談した上でスプリントに組み込んで実施する、といったルールを設けたため、突然PRのレビュー依頼を受けて、一部のメンバーがレビューをするといった以前の状態よりも、メンバー全員に知見が共有されやすい状態になりました。

メンバー間で助け合う機会が増えた

これまでは属人化した開発が進んでいたこともあり、チーム内でメンバー同士での助け合いが構造的に起きづらい状態でした。

スクラム導入後は、チームにタスクが紐付いている状態のため、各メンバーで目指すゴールが統一され、オーバーワークや困っているメンバーがいれば直ぐに他のメンバーがサポートするという場面が増えました。

また、チーム全体で技術的課題を思考する場面が増えたことで、誰か1人が難しいことをやって、それを抱え込むということが少なくなりました。

そして、気がつけば以前よりもMTGでの発言が増え、MTG時にはメンバーの誰かが必ず議事録を取ったりと、チームを意識した行動が以前よりも多く見られるようになりました。

また、属人化が進んでいた従来のチーム体制では、特定のメンバーに開発負荷が集中しやすく、勤務時間にも偏りがありました。

スクラムを導入してからは、チームメンバー全員で知見をシェアするという体制になったので、特定のメンバーに大きな負荷がかかる状態を回避できるようになりました。

スクラムを導入して苦労したこと

画像4

スクラムを導入する上で、苦労した場面も多々ありました。その中で特に苦労した箇所としては次の3つです。

ストーリーポイントの定義

スクラムでは、スプリント期間内で実施する予定のタスク対して、ストーリーポイント(タスクの作業量を示す数値)を割り当てます。

実際タスクにストーリーポイントを割り振ろうとしたとき、エンジニア側で事前に設定した定義のどれに当てはまるのかといった部分で判断に迷うことが多々ありました。

これはストーリーポイントの定義自体がまだ熟成されてないことも原因の1つではありますが、未然に予測して定義し辛いタスクに対してストーリーポイントを割り当てる難しさを感じました。

適切なスプリントゴールの設定

スプリントを導入した直後は、チームのベロシティ(スプリント中に完了する平均作業量)が適切に把握できていなかったことなどもあって、タイトなスプリントゴールを設定してしまい、チーム全体で多忙なスプリントになってしまうといったことがありました。

こうなると、チームでスプリントゴールを絶対に達成するといった意識も薄れてしまい、チームとしての動きも損なわれてしまいました。

また、メンバー間でスプリントゴールは適切に設定できていても、緊急度が高いタスクが差し込まれることで、上記のような状態になってしまうこともあり、無理のないスプリントゴールを設定するのに苦戦しました。

自発性の高いタスクの意識低下

何かを開発をするときは、必ずチーム内で共有、アサインをしてから着手するといったルールを定めたことで情報共有は活発になりました。

一方で、リファクタリングなどの自主性が求められるタスクについては、修正箇所に気づいてから実際に手を動かすまでに時間がかかり、自発的な活動への意識が少し薄れてしまう状態になってしまいました。

今後の課題

画像5

正直なところ、まだまだチームにおけるスクラムの運用は課題だらけですが、特にチーム内で温度感が高い課題は次の2つです。

複数案件の同時進行

現状、開発メンバーに同一の案件がアサインされていますが、これを少しずつ複数の案件を並列でこなせるようにチーム力を上げていきたいです。チームで情報を共有しつつ、スクラム導入前のような属人化が極力発生しないように上手く移行していきたいと思っています。

ストーリーポイントの認識合わせ

エンジニアのメンバー間ではストーリーポイントの共通認識が取れるようになってきましたが、プロダクトマネージャーやデザイナーがどのような基準でストーリーポイントを定義しているのかの共通認識が揃っていないことがあるので、開発チーム全体で認識を合わせていく必要があると感じています。

現状、ベロシティの算出においては、エンジニア、デザイナー、プロダクトマネージャーそれぞれのタスクのストーリーポイントを同一に扱っていますが、そもそも一緒に計算して良いのか?ストーリーポイントの作業量は同じとみなして良いのか?などの問題を抱えています。

このあたりは、チームでブラッシュアップしてより正確なベロシティを算出できるようにしていきたいです。

おわりに

このように、マネーフォワード クラウド勤怠におけるスクラム開発は発展途上ですが、自分が入社した6月に比べて、現状のチーム体制や雰囲気は大きく異なっており、スクラム導入でここまで変わるのものなのかと正直びっくりしています。

これからもトライ&エラーを繰り返しながらチーム力を上げて「もっとも手放せない勤怠管理システム」を目指して開発していきます!

マネーフォワードではカジュアル面談も実施しています!マネーフォワード クラウドのHR領域に興味のあるエンジニアの方は、是非一度ご連絡ください!

Work illustrations by Storyset

この記事が気に入ったら、サポートをしてみませんか?
気軽にクリエイターの支援と、記事のオススメができます!