『マネーフォワード ME』 でスクラム開発にチャレンジしたら新たなチームワークが広がった話(前編)
見出し画像

『マネーフォワード ME』 でスクラム開発にチャレンジしたら新たなチームワークが広がった話(前編)

こんにちは!
自動家計簿アプリ『マネーフォワード ME』(以下、ME)のサーバーサイドエンジニアで、 マネージャー、チームリーダーを務めている よこてぃ (@yokotty) こと横田です。

私たち ME のサーバーサイドチームでは、昨年12月からスクラム開発を導入しました。スクラム開発とは・・・

複雑な問題に対応する適応型のソリューションを通じて、人々、チーム、組織が価値を生み出すための軽量級フレームワークである

スクラムガイドで定義されています。

一口にスクラム開発といっても、開発するプロダクトやフェーズ、チーム構成などによって取り組み方はさまざまだと思いますので、1つの事例として参考になればと、note を書くことにしました。

まだ導入から半年が経過したばかりですが、タイトルの通り、良い変化が生まれて新たなチームワークが広がっているなと効果を実感しています!そんな私たちのプロダクト開発現場の様子を今後いろいろとお伝えしていたいと思っていますが、今回は、スクラム開発の導入に至った背景や、導入までに行った取り組みについてご紹介します!

スクラム導入前に感じていたチームの課題

ME のサーバーサイドチームは、ME アプリから呼ばれる API や Web 版サービス、社内向けの管理画面などの開発全般が担当領域です。アプリエンジニア、デザイナー、マーケター、CS、経営陣などたくさんの人と関わって日々 ME の開発・運営に取り組んでいます。

私はちょうど大きなプロジェクトがひと区切りした昨年9月から、サーバーサイドチームのリーダーに就きました。それまでもアジャイル開発は行っていましたが、色々と課題に感じることがありました。具体的に当時の状況をお伝えすると、こんな感じです👇

・タスク管理するかんばんボードには優先度/緊急度のバラバラな開発チケットが積み上がっている
日々、新たなチケットが作られる(新機能開発、改善施策、システムの運用保守、ユーザーからの問い合わせの調査対応などさまざま)
・要件が決まっておらず着手できないチケット、着手していたが保留となったチケットなども多数
主にリーダーが優先度を判断し、保留/未着手状態のチケットは要件を明確化して、メンバーへアサインする
・週1回1時間の定例で、進捗共有と、新たに取り組むべきチケットを選定
・毎日30分ずつの朝会と夕会で進捗共有や相談
・見積りは着手する時にメンバーが任意で行い、終了目処を共有
(すぐに終わりそうな場合は、見積りを省略して手を動かすことも多い)

(かんばんボードは GitHub Project、チケットは GitHub Issue で構成)

スクリーンショット 2021-05-08 10.04.00

これまで長らく少人数での開発が続いたため、開発プロセスをカッチリさせずスピード重視で走っていました。その結果、次のような課題が発生していました👇

・次にどのチケットに取り掛かるべきか分からない
・急な依頼(差し込み)に振り回される
リーダーがボトルネックになって次のタスクがない、開発が進まないなど
・メンバー間でチケットの内容を共有できておらず、助け合えない
・レビューの大きめの指摘や考慮漏れが発生して保留となった状態のチケットが積み上がっていく
少し先の開発計画が立てられない。立てても大幅にズレる

見ての通り、課題が山積みでした。。。
これでは、今以上にメンバーが増えると開発が回らなくなってしまいます。

育休直前!開発プロセスの改善を模索 〜スクラム開発へのチャレンジ〜

加えて、もう一つ大きな山場がありました。それは、私の家庭にまもなく第一子が生まれ、2週間の育休に入る予定があったことです。里帰り出産のため育休は短めにしたのですが、年明けからは夫婦のみでの育児も始まるため稼働時間が減りそうです。

このままでは開発が回らなくなる…!

そう焦りを感じ、開発プロセスの改善を急ピッチで模索しはじめました。
そこで着目したのがスクラム開発でした。私自身、スクラムガイドや関連書籍をいくつか読んで少し知識はあったものの、実戦経験がありませんでした。チームメンバーにも1人も経験者はいません。

自分がスクラムマスターをやるしかなさそうかな 🤔
でもプロダクトオーナーも今は身近にいないぞ… どうしたらいいんだ 😩

そう思っていた矢先の昨年10月に、社内で『SCRUMMASTER THE BOOK』の輪読会がスタート。(いま振り返るとこれが絶妙なタイミングでした)
私が「自分のチームではまだスクラム開発やってないけど、何とかしないといけないんです。。。」と他の参加者に打ち明けたところに手を差し伸べてくれたのが、輪読会の主催者で社内専任スクラムマスターの渡邊さんでした。

渡邊: ぜひ、ちょっと1回話聞かせてくださいー

横田: 🥺 (救世主現る…!)

誰がPOになるべき?スクラムマスターの導き

そこからは、導入までのスケジュールがトントンと決まっていきました👇

画像4

印象的だったのは、最初の 1on1 でプロダクトオーナー(以下、PO)とスクラムマスター(以下、ScM)のロール決めの話をした時のことです。

横田: このスクラムでは誰に PO をやってもらうのがいんでしょうか 🤔

渡邊: PO はプロダクトバックログの優先順位に責任を持つことが一番の役割です。よこてぃがやるべきだと思んですよねー ScM は最初は僕がやりますよ!

横田: 😲 (その発想はなかった…!)

私はそれまで、PO とは施策を企画するエンジニア以外の人が担当するイメージを持っていて、エンジニアのリーダーとして設計や手も動かす自分が PO の役割を担うのは適切ではないと思い込んでいました。しかし、最初から理想形を目指さなくてもよい、プロダクトの真の PO でなくても、最低限まずはスクラムを回す上での PO としての役割を果たせればよいと教えてもらい、驚きをもって納得したことを鮮明に覚えています。

ScM については、導入の10スプリント程度を渡邊さんが直接担い、その後はScM 不在でもファシリテーションなどを開発メンバーで回していける状態を目指していくことに決めました。

スクラムに対するチームの反応と意見のすり合わせ

最初は私から、これまでの方法に対して感じている課題と、それらを改善していくためにスクラム開発を取り入れたい旨をチームに伝えました。幸い、みんなポジティブな反応でした。ここで反対する人が多いと、導入は困難だったでしょう。

次に、「スクラムガイド」と「アジャイルソフトウェア開発宣言」を事前に読み、認識を合わせる会を開催。Google Jamboard を用いて感想を書き出し、疑問や不安を伝えて議論する時間を設けました。一部、上がった声をご紹介します。

・他チーム(マーケ、デザイナーなど)の人もスクラムに参加するのか?
・アプリチームも一緒にスクラムをやる?
・差し込みの依頼や障害対応も多いが、スプリントでどう扱うか?
・スクラムにフルタイム参加できないメンバーが多いので難しいのでは?
・いつまでに終わらせれば良いか分からないチケットが多い

こういった疑問や不安を1つ1つ、渡邊さんからスクラムの教科書的な方法論や他のチームでの事例を紹介してクリアにしたり、自分たちがどうしていきたいかを議論していきます。そして、「とりあえずこれでやってみよう、そして上手く行かなかったらまた振り返って改善案を考えよう」というマインドで議論を進めて、なんとか1スプリント目に入っていけそうな雰囲気が醸成されていきました。

(読み合わせ会で用いた Jamboard)

画像2

スクラム開始前の準備 〜開発チーム〜

スクラム開始まで1週間を切りました。ここで開発メンバーと PO の私は、少しずつ開始日を意識して動きます。

ここで開発メンバーがやることは、開始日までにできるだけ仕掛りをなくすことです。仕掛り状態が多いと、プランニングで新たにスプリントバックログに乗せられるチケットの量が少なくなる、適切なチケットの量が計れなくなるといった不都合が生じます。これを守るには、現在仕掛り状態のものを完了にするための作業だけでなく、手が空いたからといって新しいチケットを安易に取らないよう気をつける必要がありました。

スクラム開始前の準備 〜PO〜

そして PO がやるべきことは、プロダクトバックログの整備となります。「最初の2〜3スプリント分くらいはやるべきことが優先度順に並んでいる状態」を目指します。

既存のチケットを1つ1つ開いて、古く不要になったものは思い切ってアーカイブしたり、優先度が低そうなものはコメントを残しておき、優先度が高いものは場合によってはチケットのタイトルや内容をわかりやすく書き直していく地道な作業を行っていきました。

ついに迎えたスプリント1!

ほどなくして、いよいよ1スプリント目を迎えます・・・!

準備の甲斐あって最初のスプリントプランニングから順調・・・かと思いきや、そうはいきませんでした😅 仕掛りチケットがそう簡単に無くなっているわけもなく、またプロダクトバックログも短時間では全く整いません

結局、1〜2スプリント目は、ほとんどを仕掛りチケットの消化に当てることになりました。しかし、進め方はスクラム導入によって明らかに変わりました。スプリントプランニングを通してチーム全員で「なぜ仕掛り状態にあるのか、残りの作業は何なのか」を1つ1つ確認し、相対見積りによるポイント付け(リファインメント)を行っていきます。それだけでも、やることが明確になり、今までなかなか進まなかったチケットが少しずつ完了になっていきました。確実に、新たなチームワークの芽が出はじめていたのでした。

とはいえ、劇的に変わった実感はなかなか最初から掴めるものではありません。「こんな感じで、自分たちはスクラムを上手くやれているのか・・・?」と、チームにはまだ不安な雰囲気も漂っていました。

渡邊: 回数を重ねていくと慣れていきます!少しずつやっていきましょー

ScM のその言葉を半信半疑に受け止めながら、私たちのスクラム開発はスタートしたのでした。

おわりに

以上、前編として今回は、ME のサーバーサイドチームが
・スクラム開発以前にどのような課題を抱えていたのか
・スクラムマスターが入って、スプリント1までにどのように準備したか
といった様子をストーリー調でお届けしました。

順風満帆、教科書通りのスクラム導入とはなりませんでしたが、最初から完璧を目指さず、やるべきことを絞って取り組んでいく様子が伝わったのではないでしょうか。

前編では、肝心な「スクラム開発をはじめてどうだったのか?」「新たなチームワーク」の部分にまで触れられなくて申し訳ありません。続きが気になる方は、ぜひ「スキ」ボタンを押して、後編をお待ちください…!

この記事が気に入ったら、サポートをしてみませんか?
気軽にクリエイターの支援と、記事のオススメができます!
マネーフォワードで自動家計簿アプリ「マネーフォワード ME」のエンジニアリーダーとPdMを兼任。 現在はスクラム開発を通して開発プロセスを磨いたり、チーム作りに奔走中。 プライベートでは1児の父。スポーツ観戦全般が趣味です。