個人向け・法人向けに金融系ウェブサービスを提供する株式会社マネーフォワードでは、エンジニア組織における個人の振り返りや組織の課題発見に、エンジニア組織支援クラウド「Findy Team+」を活用いただいています。

今回は、マネーフォワードの関西拠点にて、クラウドERP本部の副本部長を務める大倉さんと、「マネーフォワード クラウド会計Plus」の開発に携わるエンジニアの段松さんにインタビュー。開発生産性の可視化に「Findy Team+」をどのように活用しているかや、社内での複数チームにわたる可視化への取り組みの広まりなどについて、お話をうかがいました。

京都と大阪の関西拠点で「クラウド会計Plus」を開発

――まず最初に、お二方のこれまでの主な経歴や現在の業務について教えてください。

大倉：私は前職では、主にプロジェクトマネージャーやスクラムマスター、プロダクトマネージャーなど、全体を見るポジションでプロダクト開発に携わっていました。4年ほど前にマネーフォワードに入社し、1年目はエンジニアとしてプロダクト開発に参加。2年目からは開発チームのマネージャーになり、3年目からは本部単位で、複数のプロダクトを含む開発組織のマネジメントを担っています。

段松：前職では、従業員30名くらいのスタートアップでエンジニアをしていました。その後、東京から地元に戻ってきたことがきっかけで、マネーフォワード大阪オフィスの「クラウド会計Plus」チームに入りました。エンジニアとして、いくつかあるスクラムチームのうち1つに所属していて、普段はバックエンド、フロントエンドを含めて開発しています。

――大倉さんと段松さんが属している、本部やチームについて教えていただけますか？

大倉：マネーフォワードビジネスカンパニーという、BtoBプロダクトの販売や開発を行う組織のなかに、クラウドERP本部という部があります。私はその部の副本部長として、開発の責任者をしており、段松は部内にある「クラウド会計Plus」の開発チームに所属しています。

――チームの立ち上げには、どういった背景がありましたか？

大倉：我々のプロダクトチームは、京都と大阪に住んでいるメンバーで構成されています。このプロダクトの開発を始めたころは、まだ京都オフィスにエンジニアが数名しかおらず、関西で開発する中核プロダクトとして成長させていく狙いがありました。プロダクトの成長と関西拠点の成長、両方を求めて立ち上げられた背景があります。

――チームでは、どのようなミッションを掲げていますか？

大倉：我々のお客様は、企業の経理部の方々です。経理部の方々のペインを解消していくことが基本的なミッションです。

ビジネスサイドとのコミュニケーションにおける3つの工夫

――チームで設定されている、目標やKPIがあれば教えてください。

大倉：会社全体での目標からブレイクダウンした目標を設定していて、ロードマップをどこまで進めるか、それによってどういったアウトカムがあるかについて設定することが多いです。特にここ1年は体制も整ってきて、技術的負債の返済にも投資できるようになってきたので、そういったところも含めて目標を設定しています。

KPIに関しては、適切な目標値を設定するのが難しいと思っていて、ヘルスチェックとしてFour Keysや「Findy Team+」の数字を見ているものの、あまり細かく設定していません。ただ、Four Keysだけは、Eliteランクの数字を目指すところを目標にしていました。

――アウトカムを意識した開発をされるなかで、ビジネスサイドの方々とのコミュニケーションも重要な要素だと思います。何か工夫していることはありますか？

大倉：スクラムチームでは、プロダクトオーナーやプロダクトマネージャーが近くにいること、そのチームのなかにいることがすごく大事だと思っていて、そういったチームづくりを意識してきました。なので、そこはチーム一体として動けているのですが、ビジネスサイドのセールスやカスタマーサクセス、カスタマーサポートの方は距離があるので、適切なコミュニケーションが必要だと考えています。

工夫しているポイントは3つあって、1つ目は開発に入る前、価値のディスカバリーをしている段階から、ビジネスサイドの方とコミュニケーションを取ること。今どういうペインを解消しようとしているのか、事前に相談するプロセスを入れています。これはエンジニアというより、プロダクトマネージャーを中心に行っています。

2つ目は、実際に開発を進めている段階で、リアルタイムにフィードバックをもらうこと。毎週行っているスプリントレビューの出席を自由にしていて、そこにセールスやカスタマーサポートの方々も参加します。多いときは数十人が集まり、今開発しているものに対するフィードバックをもらっています。

3つ目はリリース後の段階で、最もエスカレが多いカスタマーサポートの方とのコミュニケーションパスをしっかり整理し、上手くコミュニケーションが流れるようにしていることです。ただ、これらはあくまで目指しているもので、現状まだそこには至っていない部分もあります。

開発スピードへの疑問から、計測の取り組みを開始

――開発生産性の計測に取り組み始めたきっかけを教えてください。

大倉：もともとスモールチームで開発していたのですが、開発スピードを上げるため、採用活動に力を入れてメンバーを増やしました。ところが、チームの人数は増えたものの、本当に開発が速くなっているのかという疑問があったんです。

その時の「クラウド会計Plus」チームのマネージャーからも、同じ課題認識があるという声を聞き、どうしようかと考えていたところ、SNSで「Findy Team+」の活用事例を見かけました。さらに、そのマネージャーからも「Findy Team+」を導入してみたいという連絡をもらったので、すぐに試してみることにしました。

――導入当初、可視化にあたって懸念していたことはありましたか？

大倉：チーム運営のポリシーとして、情報をオープンにして情報格差を減らそうという考え方があったので、可視化することへの懸念はまったくありませんでした。「Findy Team+」はアカウントの招待をする際、マネージャー権限とメンバー権限に分かれていますが、迷わず全員マネージャー権限で招待して、フルオープンにして進めました。

――「Findy Team+」を導入する以外に、自社で内製ツールを作るなどの検討はありましたか？

大倉：社内でも計測ツールが作られていました。ただ、それはリポジトリを横断しての計測ができず、複数リポジトリで開発している今のプロダクトでは、上手く測ることができなかったんです。「Findy Team+」ではそれが可能だったことが、導入の決め手の1つになりました。

――「Findy Team+」を導入した当初、設定されていたゴールはあったでしょうか。その後の変化もあれば教えてください。

大倉：まずは可視化を実現し、データに基づいて会話ができることが最初に目指したゴールでした。具体的な数字は覚えていませんが、当時からサイクルタイムを短くしていこうと話していたと思います。サイクルタイムをいかに短くするかというところが、一番ヘビーユースしている部分なので、直近では課題が改善されてきて、むしろ見る頻度は減っていますね。

――「Findy Team+」上の数値を見ると、デプロイ頻度が大きく増えています。Four Keysのなかでも、特にデプロイ頻度も意識して見られていましたか？

大倉：そうですね。デプロイ頻度を高めるところから始めて、最初は1日1デプロイを目指していました。ただ、デプロイ頻度については、フィーチャーフラグの導入が最も効いたので、個別での改善というよりは仕組みによって改善した部分が大きいです。

――メンバー目線では、計測した数字を普段どのように活かしながら進められていますか？

段松：スプリントを1週間に設定していて、毎週スプリントのレトロスペクティブのなかで、計測した値を見る時間を設けています。みんなで画面共有しながら数字を見て、もし悪かったらどこが良くなかったかを振り返ります。そこで、改善に向けた案が出たら、みんなで次のスプリントでトライすることを決めて、また翌週振り返るという流れで進めています。

複数チームに広がっていく、生産性可視化への動き

――現在は、社内の複数チームへ可視化の取り組みが広まっているとお聞きしました。この背景について教えていただけますか？

大倉：エンジニアのなかで開発生産性への関心が高まっているトレンドも背景にありますし、開発生産性を可視化してレポーティングしてほしいという、経営陣からの要望も背景にあります。

さらに、「Findy Team+ Award」に選出いただくなどして、評判が評判を呼んだ面もあります。月1回のエンジニア全員が参加するEngineering All Handsやマネージャー合宿など、さまざまな場で取り組みをシェアしていくうちに、「自分たちのチームでも試してみたい」と声を掛けてもらうことが増えていきました。

――可視化に興味があるチームに対して、社内ではどのようにフォローされていますか？

大倉：事例を共有するようにしていて、他のチームから「教えてください」と声を掛けてもらった場合は、30分くらい画面を見せながら、実際にどのように使っているかを説明しています。それ以外には、困ったときに質問できるチャンネルもあります。

――いろいろなチームから声が掛かり、負担になる部分はありませんか？

大倉：特にきっちりとした管理体制があるわけではなく、基本的にはそれぞれのチームに任せているので、それほど負担はありません。ただ、来期からはさらに導入するチームも増える予定です。そのためには中央で管理する体制が必要になってくると思うので、そこはまた別の方に任せようと考えています。

――御社では開発生産性の指標に関して、全社的に定められているものはありますか？

大倉：全社的にFour Keysが開発生産性を示す指標として定められていて、エンジニア組織の目標のなかには、必ずFour Keysを入れることになっています。当社では四半期に1回、CTOが方針を出すタイミングがあるのですが、1年ほど前にCTOから、Four Keysを指標として開発生産性を高めていきましょうという発信がありました。

――可視化の取り組みが複数チームに広がっていくことで、どのようなメリットがあると感じていますか？

大倉：チームによってケースバイケースではありますが、なかには同じパターンの部分もあるはずです。なので、計測によって見つかった課題に対して、数字の良いチームの取り組みを参考にするなど、ナレッジシェアの促進に効果があるのではないかと思っています。

それから、当社にはいくつか代表的な技術的負債があり、それが足かせになってるチームがある一方で、最近開発を始めたばかりで技術的負債がないチームもあります。そうしたチームを比較すると、負債を解消しておく必要性が見えてきて、意思決定もしやすくなるのではないかと、僕個人としては考えています。

課題の発見につながることが、一番のベネフィット

――開発生産性を可視化することによるベネフィットは、特にどういったところに感じられていますか？

大倉：課題を発見できることが一番のベネフィットだと考えていて、チームの改善だけでなく、1on1などでのキャリア支援にも活かしています。「Findy Team+」の詳細比較の機能を使って、チーム平均とその人の数字を比べて違いを見たり、ベンチマークしている人と比べて、数字がどう違うのかを見たりしています。

例えば、エースのエンジニアと歴の浅いジュニアエンジニアを比べて、ジュニアエンジニアが何を良くしていけば、エースのエンジニアの数字に近づけるのかとか。そういった個人の課題の発見にも使えて、すごく良いアイディアをもらえていると思います。

それに、数字を見てみると、思い込みだったとわかることも結構あります。「もっとここを伸ばそう」と伝えようと思っていたけれど、実際に数字を見てみたらすでに全然できていたという場合もあるので、定量的に確認できるようになって良かったと感じます。

段松：もし計測していなかったら、例えば今週はチケットが何枚はけたか、リリーススケジュールに対して何%進んでいるか、といった部分で自分たちの調子を測っていたと思います。ですが、Four Keysを計測することによって、より正しいチームの姿がわかるので、やはりそこがベネフィットの1つだと思います。

また、自分たちの開発プロセスのなかで、ボトルネックがどこなのかも判断しやすくなりました。チームの振り返りではリードタイムを一番よく見ていますが、「Findy Team+」ではリードタイムのなかでも、プルリクのオープンからレビューまで、レビューからアプルーブまで、と詳しく見られるので、どのプロセスに時間がかかったかわかりやすくなっています。

例えば、レビューからアプルーブまでが長かったということは、レビューで設計について議論が長く発生してしまったのかなとか、そういった具体的な部分まで深掘りできるのが、良いところだと感じます。

――取り組みを通じて、意識や行動が変化したと感じる部分はありますか？

大倉：何かあったときに、定量的なデータを見てから考える癖がついたところは、個人的な行動の変化としてあったと思います。メンバーに関しては、もともとなのか変化したのかはわからない部分もありますが、「Findy Team+」のカスタマーサクセスの方から、「大倉さんのチームは、メンバーでツールを見ている人が多いですね」と言われたことがあります。

段松：改善の結果が数字で見えるので、チームで決めたトライに対して、よりコミットしやすくなったと思います。例えば、レビューからアプルーブまでを早くするためにプルリクを小さくしたり、認識の齟齬を減らすためにモブプロをしたり、そういったトライをしたときに、その次の週にちゃんと改善したかが数字で確認できるので、よりモチベーションも高まりやすくなると感じました。

ただ、その一方でFour Keysの数字を目標にすると、例えばリードタイムを短くするために、次の日が休みのときにあえてプルリクをオープンしないなど、数字を追いすぎるあまり本質から外れてしまう部分も少しありました。

――取り組みを進めるなかで、難しかったポイントはありましたか？

大倉：先ほど段松が言っていたように、やはり可視化したものを目標値にすると、ハックしようとする意識が働いてしまいます。本質からずれてしまうところは難しい部分だと思うので、そこにモチベーションをどうセットするか、目標設定として何が適切なのかは、頭を悩ませなければならないポイントだったかなと思います。

とはいえ、より良くしていこうというマインドを持っているメンバーばかりなので、トライしてみたことに対する当たり外れはあれど、取り組みのなかでそれほど大きな課題はなかったように思います。

段松：計測しているなかで、どうしてもリリースの都合で、例えば昔作ったプルリクエストをちょうどその週にマージした場合など、数値が下振れてしまって厳密に測れなくなるタイミングがあります。そういうときは、都度チームのコミュニケーションで理由を伝えるようにしていましたが、そこは少し難しいポイントだと感じました。

かけたコストに対する、アウトカムの計測にもつなげたい

――今後のトライについて、現在考えられていることがあれば教えてください。

大倉：Four Keysで言うと、すでにEliteのペースで開発できています。ただ、体感では自分たちの開発が本当にEliteの速さだとは思えないところがあり、これはチームからも同じような意見が出ています。なので、SREの文脈では、無駄な繰り返し作業のトイルを削減し、よりキャパシティを増やしていきたいと考えています。

そして、来期はアウトカムの計測もしていきたいと思っています。かけたコストは何人が何ヶ月動いたかで概算していますが、そのなかの効率が良くても悪くても、結局アウトカムがなければ、あまり意味がありません。そのため、かけたコストに対して、どういうアウトカムがあったのかまで、つなげて見ていきたいと考えています。

段松：数値が良くなってきてからは、あまり細かく確認することはなくなっていたのですが、直近チームが変わったので、改めてしっかりとFour Keysを見ていきたいです。数字が下がっている部分があれば、何が原因なのかをチームで議論しながら、次のトライを決めていきたいと思っています。

――より多くのチームで可視化を進めていくことに関しても、今後のトライとして考えていることを教えてください。

大倉：マネーフォワードの組織づくりの特徴として、各プロダクトチームに権限が委譲されていて、いろいろなことが自由にできるという良さがありました。ですが、これだけの組織規模になると、全体で見たときに効率の悪い部分が出てくるので、そこは経営課題として解消していかなければなりません。

そのなかで、良い取り組みをしているチームが、他のチームを引っ張り上げていけるのが、良い進め方の1つかなと。なので、各チームが上手くいっているチームの数字を見て、その差分を埋めていきやすい環境をつくりたいですね。こういったナレッジシェアから全体をより良くしていくコミュニティをつくっていければと思います。

――それでは最後に、組織のアピールや一緒に働きたいエンジニア像を教えてください。

大倉：関西拠点は規模も大きくなり、開発生産性を意識しながら日々の開発が行える土台ができてきました。またマネーフォワードでは、現在グローバル化を進めており、Non-Japaneseメンバーの入社やベトナムとの共同開発も増えてきています。

今ある複雑なプロダクトを開発生産性高くさらに伸ばしていきたい方、新しいプロジェクト立ち上げを経験したい方、グローバルな環境で働きたい方など、様々なチャレンジができると思います。 大変なことも多いですが楽しいフェーズでもあると思うので、興味を持っていただけた方はぜひ一度お話しましょう。

――大倉さん、段松さん、ありがとうございました！

※マネーフォワードでは、ミッション実現に向けて、世界中からグローバルで活躍したいエンジニアを募集しています。 https://recruit.moneyforward.com/

※「Findy Team+」のサービス詳細は、以下よりご覧いただけます。 https://findy-team.io/service_introduction