エンジニア組織の開発生産性を いかに定量化し、改善する？〜マネーフォワードとアンドパッドの EM・テックリードによる実践〜
近年、メガベンチャーや大規模調達を果たしたスタートアップでは、エンジニア組織は拡大し、開発環境やプロセスも複雑化しています。それに伴い、採用や人事、組織づくりを担うエンジニアリングマネージャー、技術領域の課題解決を推進するテックリードの重要性も高まっています。
2022年2月24日に開催した『EMとテックリードに聞くエンジニア組織づくり最前線vol.4』では、株式会社マネーフォワードと株式会社アンドパッドでエンジニアリングマネージャーやテックリードとして事業や組織の成長を率いるお二人に、現場のリアルな課題や取り組みを語っていただきました。
目次
登壇者
柴﨑 優季さん/株式会社アンドパッド[@shiba_yu36]
2021年10月に株式会社アンドパッドに入社。アカウント基盤チームのテックリードとして認証基盤のリアーキテクチャの設計・実装を担当しつつ、チームの生産性向上やエンジニアリング組織づくりにも取り組んでいる。 スピーカーのブログ記事：Findy Teamsの指標を使ってチームの生産性を改善しよう
西村 友裕さん/株式会社マネーフォワード[@tomohi_ro]
2021年1月に株式会社マネーフォワードに入社。『マネーフォワード クラウド会計Plus』の開発チームでソフトウェアエンジニアとして開発に従事。ユーザーに価値を届けるスピードを上げるため、開発プロセスの無駄をなくす活動を推進。同年12月からはマネージャーとして個人ではなくチームでの生産性を上げることに注力しています。
チームの成果を最大化するための課題解決を続けた結果、EMやテックリードに
冒頭ではそれぞれのエンジニア組織の構成を踏まえ、二人の担当している役割や担うようになった経緯を聞きました。
アンドパッドのエンジニア組織は100名を超え、施工管理や受発注など機能単位でミッションを持つプロダクト系チーム、それらを支えるアカウント基盤やSREなどプラットフォーム系チームに分かれています。
柴﨑さんがアカウント基盤チームのテックリードを担うにいたった経緯は「チームにおいて『うまくいってないことが何だろう』を考え、手を動かした」結果だと振り返ります。
柴﨑さん：「私がアカウント基盤チームに入ったとき、認証基盤を作り直そうとしていたのですが、何だかうまく進んでないなと思っていました。全社戦略を踏まえて、認証基盤作り直しのマイルストーンや技術的なアーキテクチャなど、手を動かす前に一気に整理を進めました。
2、3ヶ月続けたとき、『テックリードのロールがあれば、より円滑に進められると思います』とVPoEの下司に伝え、今のロールになりました。
今回に限らず『チームで成果を最大化するために解くべき課題』が何かを考えて、色々やっているうちに、結果としてロールが与えられるっていう流れが、私のキャリアには多いように感じます」
マネーフォワードのエンジニア組織では、継続的に権限委譲に取り組んでおり、現在はプロダクトごとのスモールチームを置いているそう。それぞれのチームが、最も生産性の高い状態を目指して意思決定し、開発を進めています。
西村さんは、『マネーフォワード クラウド会計Plus』の開発チームで15名ほどのエンジニアのピープルマネジメントやエンジニアリング戦略立案、イネーブリングやオンボーディング、ティーチングに近い領域を担当。部全体の運営も一部担っています。
元からエンジニアリングマネージャー的な役割を担おうと決めていたわけではなく、手を動かしているうちに、機会が訪れたようでした。
西村さん：「そもそも、マネーフォワードに転職した理由の一つが、立ち上げ中の関西拠点で色々チャレンジできるからでした。加えてこぼれたボールを拾うのも好きなので、転職後も自分で手を動かして、チームの課題に取り組んでいました。
そのうち、たまたま上長の昇進が決まり、繰り上がりで自分がマネージャー的な立場になりました。どちらかというと、私の場合はロールありきと言いますか。繰り上がりで入った形ですから、まだロールに合わせて実力を積み重ねている状況だと捉えています」
続いて、具体的にエンジニアリングマネージャーやテックリードとして注力している仕事、ミッションや目的について聞きました。
西村さんは、エンジニア組織のスケーリングや、開発スピードを高めるための課題解決などを挙げます。
西村さん：「今の組織は、やりたいことに対して開発速度が追いついていない状況。最大のミッションはエンジニア組織のスケーリングです。
特に注力しているのは、定量的な指標を用いて、組織の状況を可視化すること。課題点を洗い出し、客観的に『ここが課題だね』を皆で認識する必要があると思っています。
もう一つはメンバーの育成。今のチームは、ジュニアなメンバーの割合が高く、伸びしろがある。成長してもらうための環境づくりも重要だと捉えています」
柴﨑さんは、認証基盤の作り直しや開発力の向上について話します。
柴﨑さん：「アンドパッドのエンジニア組織の規模は、2021年から2倍以上に拡大しています。組織のミッションなど明確に決まっているわけではなく『走りながら考える』状態です。
アカウント基盤チームとしては、アカウント周りの認証実装を中心に、開発者体験を改善することをミッションに位置づけています。
注力している取り組みは、先ほども述べた認証基盤の作り直し。全社の2、3年先までの戦略を見通し、そのなかでチームはどのような立ち位置で、どのようなマイルストーンで進めばいいか、模索しながら取り組んでいるところです。
もう一つは開発の改善です。個人的に探究したい領域でもあり、ミッションとして注力しています。生産性を定量的な指標によって把握し、それを用いてスクラムを取り入れたり、コードレビューのフローを整えたりと、チームの開発力の向上に取り組んでいます」
チームの拡大に比例して生産性を高めていくには？アンドパッドとマネーフォワードの試行錯誤
二人の役割や注力領域を踏まえ、イベント中盤ではより具体的に、組織の短期的、長期的な課題や解消に向けた取り組みを聞きました。
アンドパッドの柴﨑さんは、短期的な課題として開発スピードの向上に言及します。
柴﨑さん：「事業成長に伴い、ユーザーが求めている機能を素早く形にし、安定して提供することが一層求められています。その速さに対応するため、チームの開発スピードをいかに高めるかは大きな課題です。
そのためにいくつかの取り組みを進めています。一つは、生産性の定量的な可視化。具体的には『Findy Teams』を導入してパフォーマンスを可視化し、数値を見ながら改善につなげています。
他にも、機能のメンテナンスなどにおいて、優先度を判断する基準をガイドラインとしてまとめ、優先度の低いものにリソースを割きすぎない仕組みを整えています。
あとは、できる限りタスクはペアでアサインする、スクラムを取り入れるなどして、一人で行き詰まってしまうケースを防いでいます」
中長期的な課題としては、組織の急拡大に伴う課題についてシェアしてくださいました。
柴﨑さん：「人数は2倍になったけど生産性は1.2倍ぐらいにしかなっていないといった状況は避けたいです。組織の拡大に比例して、いかに生産性を上げていくかは中長期的に大きなテーマです。
また、分業化が進み過ぎると、製品全体やその先の顧客を意識して開発する意識を、共有しづらくなる可能性があるなとか、コミュニケーションコストが増えたら開発が逼迫するな、とかも考えています。
いずれも具体的に今起きているというより『こうなるかもな』を日々想像し、組織構造やチーム構成、コミュニケーションパスを検討しています」
西村さんは「まだまだ自分は中長期的な課題の検討が足りないなと、柴﨑さんの話を聞いて実感した」と前置きしつつ、現在のチームやプロダクトの課題を共有します。
西村さん：「一つは、プロダクトのビジネス的な目的や売り上げ目標に比べ、開発チームとして『なぜこのプロダクトを作っているのか』の認識が揃っていないこと。というのも、私たちが開発しているのはバックオフィス向けの会計システム。一般的なエンジニアはあまり普段使ったり触れたりする機会がほとんどないもので、『なぜこれを開発しているか』がピンとこないケースもある。もっと『なぜ』を明確にし、共有する必要があると思っています。
二つ目は組織のスケーリング。人の増加に比例して生産性が伸びているわけではなく、正直あまり変わっていない認識なので、そこを変えていきたい。
最後に、先ほども少し触れたのですが、去年入社したばかりのメンバー、これからスキルや経験を積んでいくジュニアメンバーを伸ばしていく環境づくりですね」
プロダクトを作る目的意識の共有や生産性の向上、メンバーの育成環境づくりなどの課題について、具体的な取り組みも教えてくれました。
西村さん：「『なぜこれを作ってるのか』を明確にするため、部署のエンジニア以外のメンバーも含めてワークショップを開き、ミッションを策定する活動を進めています。
二つ目の生産性の向上については、現状どこに課題があるかもあまり見えていない。まずはどこに課題があるかの可視化を進めていきたい。
並行して、組織のなかでチームメンバーがより自律的に動ける状態をつくりたいと思っています。一つのチームが見ているマイクロサービスやシステムの数を最適化して認知負荷を下げる、権限委譲を進めて一部メンバーの持つ権限をできるだけ開示し、独立して動ける体制を整えるなどを進めています。
また、リモートワークを取り入れた結果、以前のような同期コミュニケーションが難しくなり、物事の進みが遅くなっている部分がある。非同期で進められる部分を増やせないかなど、試行錯誤しているところです。
三つ目のジュニアメンバーの育成でいうと、これまで知識を伝える形でのスキルトランスファーを進めてきました。ただ、トランスファーする側が教える経験を通して成長する一方、トランスファーされる側の成長にはあまり見込めないのではと最近思っていています。自ら手を動かし、課題を乗り越える経験を用意できないかと意識的に取り組んでいるところです」
Four Keysなどの指標を用いて、エンジニア組織の生産性を把握する意義
お二人の取り組みに「開発チームの生産性向上」や「そのための生産性の可視化」が共通して出てきたことから、イベント後半ではデータを活用したエンジニア組織マネジメントの話題に。日頃活用している指標やツールなどをそれぞれに聞きました。
柴﨑さん：「生産性を測るために用いている指標としては、基本的に前職でも本職でも『Four Keys』と呼ばれる指標群を使っています。
これはデプロイの頻度と変更のリードタイム、変更障害率、サービス復元時間という4つの指標から成るものです。生産性や事業成果などに相関が高いと言われています。
基本的にはFour Keysをトラッキングして、チームごとのパフォーマンスを測り、改善に取り組んでいます。意識しているのは、なるべく継続的にトレンドを理解し、時系列の変化を見ること。例えば変更のリードタイムが以前に比べて3倍になっていたとしたら、着実に何かが悪化していると捉え、改善策を練ります。
より具体的にはFindy Teamsの指標を使ってチームの生産性を改善しようというブログに書いたので参考にしていただけたらと思います」
西村さんのチームではデプロイ頻度を主な指標として用いているそうです。
西村さん：「当初はFour Keysを取り入れようと考えていたんです。ただ、私たちの場合、そもそもデプロイ頻度がそこまで高くなかったり、リードタイムの開始時間をどこからとするかが難しい部分もあったりして、まずはデプロイ頻度のみを指標として追いかけています。
と言うと、デプロイ頻度は無のデプロイをすれば、どんどん増やしていけるものではと思われるかもしれません。ただ、デプロイ回数を上げようとすると、リードタイムは短くしないといけないし、不具合が沢山出ているとデプロイ頻度は一時的に増えますが、実際の開発は進まないので、継続的に価値をデプロイできない。デプロイ頻度を追うだけでも、ある程度は全体的な生産性を改善できるのではと考えています。
実際に変化も起き始めていて。以前はストーリーブランチやエピックブランチを作って、そこに貯めてからリリースする流れが多かったんですが、今はメインブランチに向けてプルリクエストを投げ、マージしたらすぐデプロイする流れに変わりつつあります。とはいえ、やはりFour Keys全体を見ていくほうがいいとは思うので、いずれは追っていきたいです」
二人の回答を受け、佐藤は「サーバーのスペックや稼働状態などは細かくトラッキングしてボトルネックを見つけ、改善を考えるが、人に関しては『なんとなくOKそう』と性善説で見逃されてしまうケースも多い。可視化は重要だと改めて思った」と語ります。
それに対して柴﨑さんは「組織もパフォーマンスチューニングみたいに取り組めると良いと思う」と同意しつつ、「組織の場合は、チームが『困っている』と認識している事象が、最大のボトルネックとは限らないのが難しい」と付け加えました。
西村さんも「DBのチューニングなら数値だけでいいが、人間の場合は数字だけじゃ計れないところもある」と語ります。
西村さん：「まだ考えがまとまっていないのですが、生産性だけでなくワークエンゲージメント、どのくらい前向きに仕事に取り組めているかも合わせて、見ていく必要があるのだろうなと思っています。
例えば、私のチームではeNPSをトラッキングしています。NPSの形で『今のチームを他の人におすすめできますか』や『会社としておすすめできますか』を1から10で評価してもらっています。そういったワークエンゲージメントを計測するサービスも増えていますので、導入を検討しています」
構造や仕組みによって、人の変容を促せるマネジメントの面白さ
イベントの最後では二人に現在の役割の面白さについて語ってもらいました。
柴﨑さん：「生産性が低いと思ってるとき、何かしら仕組みを入れると、急に人の行動がそれによって変わって、一気に改善が起きることがあります。
例えば、デプロイやロールバックが高速になれば、開発環境で確認工数がかさんでいた状態から『本番で確認して駄目だったらロールバックしたらいいじゃん』と意識が変わり、プロセス全体が高速になる。あるいは、テックリードを担うメンバーに『期待するのはこういった役割です』と明確に伝えるようにしたら、何を学習すればいいかを理解し、一気にスキルをつけてくれる。それで数ヶ月、半年の生産性が一気に変わる。
構造が人の動きを変え、結果に結びつくというのは、非常に面白く、楽しいと感じます」
西村さんは「マネジメントは仕事のフィードバックが早い」と語ります。
西村さん：「もともと開発したプロダクトによって誰かに喜んでもらえるのが嬉しくて。ソーシャルゲームを開発していた頃などは、リリースしたら即フィードバックを得られるのが楽しかったんです。
マネジメントの仕事は、ユーザーよりも身近な社内のメンバーから、すぐフィードバックを得られる仕事でもあると思っています。うまくいけば目の前で喜んでいる様子がすぐに見える。さらに、そのメンバーが力を発揮し、自分だけでは作れなかったプロダクトを生み出せる。プロダクトが人にもたらす喜び、自分が得られる喜び、両方を最大化できる仕事だと思っています」
西村さん、柴﨑さん共に、悩みながらもテックリードやエンジニアリングマネージャーの役割に、現場の開発とは異なる面白さを見出しているよう。近しい役割に関心を持つ参加者に向けて「過去プロダクトマネージャーのロールをもらったとき、実際は何度も失敗した。ただ当時の失敗は学びが非常に多く、結果的に今のテックリードロールに活きている。もし失敗してもやり直せる環境で機会があれば、臆せずトライしてみてほしい。」とエールをくださいました。
Findyでは、今後もエンジニアの組織づくりにまつわるイベントを定期的に開催しています。ぜひイベント情報をチェックしてみてください。 https://findy.connpass.com/
