良いチームを目指して
この記事は、マネーフォワード関西拠点 Advent Calendar 2022- Adventar の25日目の投稿です。
私はマネーフォワードの大阪開発拠点長として、また、エンジニアリングマネージャとして良いプロダクトを作れる良いチームを作るために日夜奮闘しています。
この記事では今年一年を振り返って、考えてきたこと、悩んできたこと、学んだことを言語化していこうと思います。
ちなみに筆者ってどんな人？についてはこちらの記事を閲覧いただけると喜びます。
私たちのチーム
私の所属している関西開発拠点の多くのメンバーがビジネス向けのプロダクトの開発に携わっています。
具体的には以下の３プロダクトの開発を担当しています。
私はこの３つのプロダクトの開発チームに責任を持ち、マネジメントしています。（実はベトナム拠点で開発しているプロダクトのサポートも少しだけ担当しているのですがそれはまた別のお話）
プロダクトは３つありますが、基本的なプロセスや、ロールなどは共通化することでナレッジの共有やメンバーのチーム異動などが柔軟に行えるように設計してきました。
それぞれのチームでプロダクトマネージャ、デザイナー、エンジニアがチームとしてプロダクトの開発に取り組んでいます。
クラウド会計Plusの開発チームは結成から3年超、他の２チームは結成からちょうど1年、という感じです。会社やビジネスの拡大とともにチームの規模も大きくなって、色々な課題と向き合うことになりました。
どんなチームを目指しているのか
大前提にマネーフォワードの Mission / Vision / Value を置きながら、私は以下のようなチームを良いチームと定義し、この実現を目指して色々とトライしてきました。
チームのメンバー一人一人が成長と貢献を感じることができる
関西開発拠点のコンセプトであるGive it a tryの精神でFail Firstなチャレンジに溢れている
一人一人が自律して、自ら意思決定して開発している
何よりもプロダクトの開発に携わっている時間を楽しいと感じることができる
これまでやってきたこと
良いチームを作るためにこれまで以下のような取り組みを実施してきました。これらはこの1年、というよりは私がマネージャになってからの2年ちょっとを通して実施してきたことです。
チームビルディング
相互理解を深め、円滑に開発を進められる関係性を構築するために多くの時間を投資してきました。
まずはチームに新しいメンバーが入ってきた時のオンボーディングです。
プロダクトドメインや、技術的な内容のオンボーディングももちろんあるのですが、チームビルディングの観点で２つの取り組みを実施しています。
１つ目は放課後ティータイムと称した少人数での雑談時間の確保です。新しく入ってきたメンバーを３、４人の既存メンバーで囲んで自己紹介やQ&Aを行う会を入社研修が終わったくらいから毎日30分実施しています。全員と一度は話したことがある状態を作ることでメンバーに声をかけやすい状態を作ることを目指しています。
２つ目はSlack上にオンボーディングチャンネルを作って何かわからないことがあれば呟いてもらってみんなでフォローする、というものです。新しい会社に来たばかりの頃は何か１つ質問するだけでも緊張するものです。しかし、質問を書いた瞬間に色んな人からサポートのメッセージが届く体験はその緊張を解き、困った人がいたら助けよう、というチームのカルチャーを伝えてくれていると信じています。
新規入社の方がジョインするタイミング以外でも、定期的にチームビルディングのワークショップを実施してチームの関係性をアップデートすることを目指しています。ドラッカー風エクササイズやValue cardなどなど、有名なものからマイナーなものまで色々試してみています。
これらのワークショップはデザイナーの方に設計・ファシリテーションしてもらうことが多いです。視覚的にも楽しくなるmiroのボードを用意していただけるなど、スキルを活かした活動にはいつも感謝しています。
チームビルディングには日々のコミュニケーションも重要です。私たちのチームの働き方は週1回の物理出社と週4日のリモートワークというスタイルです。（もちろん出社したい人は残りの週4日を出社することも可能です）
オンラインでお仕事している場合、ともするとテキストチャットのみでの会話となり、壁打ちやブレストなどが難しい場面もあると思いますので、Discordを導入して仮想オフィス的に利用しています。口頭で話したいときにすっと話かけやすい雰囲気作りに一役買ってくれています。
また、逆にオフラインでのお仕事の場合、黙々と作業するというよりはワークショップを開催する方が向いていたりするのでワークショップ開催を出社日に寄せたりしています。
アジャイル開発・スクラム開発
良いプロダクトを作るためにはアジリティが必要不可欠だと考えています。
アジリティが高ければ価値の提供スピードも早くなりますし、方向が間違っていた時のピボットも適切に行うことができます。これらはプロダクトマーケットフィットや、プロダクトのグロースに必要だと自身の経験からも強く感じています。
私たちは拠点開設当初からアジリティを高めるための道具としてスクラムを活用しています。もちろんスクラムを導入すればアジリティが上がるなんてことはなく、スクラムはチームの課題、上手くいってないことを炙り出してくれるだけです。この課題を解いていくのは、チーム自身でやっていくしかありません。今年に入ってから関西開発拠点には専任のスクラムマスターが3人まで増えていて、チームやプロセスの改善を大きくサポートしてくれています。
決して世界最先端ではないかもしれませんが、当たり前のようにスクラムを活用できているこの状況は10年近くアジャイル開発・スクラム開発に携わってきた身としては感慨深いものがあります。もちろんスクラムが最も良い選択肢である保証はありませんので、もっと良い型が見つかればプロセスも変化していくと思いますが、現時点で最も自分たちにフィットしたソリューションだと考えています。
一般的にスクラムが語られるのはDual track agileでいうところのDeliveryにフォーカスされることが多いと感じます。しかし、どんなに Deliveryのループがうまく回っていても、なぜ作るのか、という Discoveryのループも回っていないと意味がありません。この２つのループが効果的に回っている状態を目指して、プロセスの設計や役割分担を適宜見直しています。例えばDiscoveryはプロダクトマネージャだけ、Deliveryはエンジニアだけ、のような形で線引きしてしまうと２つのループが分断され、うまく回らないのではないか、と私は考えています。ロールを超えて越境し、本当の意味でチームが１つになって活動することが求められます。なかなか理想通りという形には辿り着けていませんが、越境を始めるところまでは来れている感じです。
関西開発拠点の仕事の幅を広げる
マネーフォワードはロケーションと仕事が強く紐づいたカルチャーの会社です。そのため、地方拠点で働いているメンバーにより多くの活躍、成長の機会を提供するためには、拠点で開発しているプロダクトや案件を増やしていくことが必要です。
現在、私がマネジメントしている３つのプロダクトチームでは利用しているバックエンドの言語を意図的にずらしています。（Ruby, Go, Kotlinを利用しています）これはマネーフォワードで経験できるものが関西にいながら全て選択できるように、という目的のためです。ちなみに関西開発拠点には機械学習系のチームもいるので、幅という意味では大分広がっているのではないかと考えています。
この1年で立ち向かってきた課題
さて、上記のような理想を目指して取り組んできたわけですが、当然のように様々な課題に直面した1年でした。特に私にとっては去年よりも今年の方が確実にタフな1年でした。
技術的負債との戦い
技術的負債との戦いはプロダクトのフェーズによって考えることを変えながら対処してきました。
クラウド会計Plusについては、もともと歴史の長いコードベースを引き継いで新規プロダクトとして開発を開始した背景があり、最初からかなりの負債を積んだ状態でプロダクトマーケットフィットを目指さないといけない難しい状況でした。そのため、去年までの２年間、新規開発部分にはGoやReact.jsの採用などソリューションに向けて必要なものは取り入れてきましたが既存コードに大きく手を加えることはしてきませんでした。
しかし今年は既存コードの負債解消に対応するべく改善チームを作ったり、改善Dayを作ったり、次のアーキテクチャの検証のためのPoC（Proof of Concept）を実施したり色々とトライしてきました。新規機能開発への投資を大きく制限することは難しい中で失敗を重ねながら着実に前進させたところはありますが、まだ自分たちの型を獲得するところまでは至っていません。
他の２プロダクトについては、完全なスクラッチ開発であることからリリースまでに必要な部分はリファクタ、リアーキテクチャする、ということを習慣づけすることを意識して投資判断を促してきました。やはりリリースまで突っ走って、リリース終わってから後で直そう、というのは結局何もしないことが経験上多いので、とにかく習慣化することを目指しました。こちらは実際に設計の見直しなど開発を進めて解像度が上がる度に実施してきましたので、一定の成果を上げられたと考えています。
ロールを超えたコラボレーションのやり方
DiscoveryとDeliveryのダブルループをうまく回すために、主にエンジニアがプロダクトマネージャの領域に越境して Epic（最も大きな粒度のプロダクトバックログアイテム）のユーザーペインの理解や仕様検討などを行う立ち回りをしてきました。しかし、エンジニアにとってその活動の負荷が高く負担になる、キャパシティを圧迫してしまう、などの課題が顕在化してきました。負荷軽減のために複数人で対応するなど、手は打ってみましたがまだ自分たちの型を獲得するところまでは到達できていません。
運用においては、開発チームのキャパシティ確保のために問い合わせの一次切り分けをプロダクトマネージャに担当してもらう運用に変更しました。こちらも一次受けで対処できるものできないものが時期によってバラツキがあることからエンジニアへのエスカレの頻度にバラツキが生まれるなど、適切な運用にはもう一歩というところです。
お互いに越境したときにお互いの領域に関しての知識、スキルなどが不足していることから上手く任せきる、というのも難しいということもわかってきました。
開発組織の英語化・グローバル化
CTOの中出からの情報発信もあるようにマネーフォワードでは開発組織の英語化、グローバル化を進めています。
※参考：CTOの中出がエンジニア組織の英語化について話をしています。
当然、関西開発拠点も英語化、グローバル化に向けた取り組みを今年から開始しました。新規プロダクトを開発しているチームでは最初からPRやコードコメントなどのテキストは最初から英語で書いてみるなどスモールスタートできるよう進めてきました。
英語の習得には会社からのトレーニングの提供と、業務時間での英語学習が会社として準備されています。この英語学習とそれに伴う開発ペースの調整など、トレードオフの発生する問題なので非常に頭を悩ませました。（主にはロードマップの調整など、スコープやデリバリーをスライドさせました）
グローバル化を成功させるためにも、なぜ英語で仕事をするのか、グローバル化するのか、ということをメンバーの一人一人が腹落ちしている状態を作る、ということが重要です。経営の目線に立てば簡単に理由が説明できるものでも、実際にチームの中で開発しているメンバーにどういう形で繋がって、どういうメリットがあるのかということを伝えるために、情報発信など実施しましたが完璧な状態にはまだまだ至っていないと認識しています。
退職との向き合い
包み隠さずに書いてしまうと、今年はクラウド会計Plusのチームを中心に昨年よりも退職者が多い年でした。
チームとしての混乱期を迎え、そこから脱出するためにみんなでもがいていったものの、一定の退職者を生んでしまいました。その中には私の後任を任せたマネージャも含まれており、私のサポートの仕方が悪かったととても後悔しています。チームとしてもやはりショックは大きく、難しい雰囲気になっていたのも事実です。
しかし、そこからもう一度踏ん張ってみんなで良いプロダクトをユーザーに届けていこう、というマインドを持てるようユーザーとの接点を増やしたり、岡山で１泊２日の合宿をしたりと、みんなでやってきました。
今では、前向きに2023年を迎えられる雰囲気になっているのではないかな、と自分では捉えています。
ただ、本当に個人的にも精神的な負担が大きく、チームにとってもプロダクトにとっても難しい状況を招いてしまう事象でしたので、今回のことを教訓により働いていて楽しいチームをみんなで作っていきたいです。
2023年に向けて
より成長と貢献を感じられるチームになれるよう、2023年を飛躍の年にしていけるように以下のような取り組みを実施していく予定です。
技術的負債の根本的な返却
クラウド会計PlusについてはRuby on Railsのプロセスから完全にフロントエンドを分離していくことを意思決定しています。
またそれに合わせてRuby on RailsのapiをGraphQLベースに変更していきます。GraphQLの導入は、これまでRestfulなapiで実装してきて辛かった部分を解消することを目的としています。
これらの活動を一緒に進めたいエンジニアの方、絶賛大募集中です！
他の２プロダクトはリリースから日が浅く、大きな負債を抱えているわけではないので、正しく負債の大きさを管理できるような習慣づけを実現していきます。
開発生産性の可視化・向上
今年はFindy Team+を利用して開発に関わるメトリクスを可視化することで生産性の改善やオンボーディングの効率性の向上に取り組んできました。
来年はGoogle Four keysを本格的に運用し、チームの目標としてセットして生産性の改善度合いを可視化していきます。
もちろんKPIの数値を上げることだけにフォーカスするのは本末転倒ですので、そうならないように注意しながら進めていきますが、改善施策に対しての結果数字としては有効に活用できるのではないかと考えて運用することを決めました。
役割分担、誰がどの課題にフォーカスするのか
異なるロールへの越境について課題があることを前述しましたが、そこへの打ち手として少し役割分担やどの課題にフォーカスするのかをチームで改めて認識を揃えていくことを考えています。
Customer Problem Fit、Problem Solution Fit、Product Market Fitのフェーズの中でどのように整理して、開発のループを回していくのか、色々とトライしてみようと思います。
成果が出たら、またどこかのカンファレンスで登壇したいな、と狙っています。
グローバル化の第一歩
来年から本格的に英語のトレーニングが進んでいきますし、グローバルメンバーとの交流も増えていきます。
自分たちが何ができて、何ができないのか、過渡期として何を妥協して、何を譲らないのか、どうやっていけばユーザーへの価値提供が最大化できるのか、まだまだわからないことだらけですが、一歩づつ進めていきます。
来年の後半には関西のチームでも海外から移住をベースにした採用などにもチャレンジしていくことを計画しています。
チームマネジメント体制の拡充
マネージャの退職もあり、私が関西のチームマネジメントをかなりの部分引き受けてしまっている現状があり、属人性が高い状態になっていると懸念しています。
来年は、エンジニアリングマネージャにチャレンジしたいというマインド、スキルを持った方がチームの中から立ち上がることも期待しながら、エンジニアリングマネージャって楽しい仕事だよ、というのを身をもってアピールできるよう自身の働き方もブラッシュアップしていきます。
来年の今頃には自分だけではなく、マネージャもチームで動けるような体制が作れるようやっていければと考えています。
最後に
これらの活動を通して良いチームを作り、良いチームによって良いプロダクトを作り、ユーザーに価値を届け、課題を解決することで貢献したいです。
そんな私たちは一緒に良いプロダクトを作ってくれる仲間を大募集中です。１ミリでも興味を持っていただいた方がいらっしゃいましたら是非カジュアル面談でお話しましょう！
この記事が気に入ったらサポートをしてみませんか？