マネーフォワードビジネスカンパニー クラウドERP本部 会計Plus開発部の西村です。 エンジニアリングマネジャーとして クラウド会計Plus の開発に携わっています。(執筆時)
本記事では ユニコーン企業のひみつ ―Spotifyで学んだソフトウェアづくりと働き方 を何度も読んだ私が toB 向けのプロダクト開発において経験し､考えたことを紹介します｡ 私は2021年1月にソフトウェアエンジニアとして入社し､グループリーダーを経て､エンジニアリングマネジャーとしてマネジメントに従事しているという立ち位置です｡ もちろん1人でなしとげたことではなく､チームで考えて､学んで､成長してきた記録です｡
https://www.oreilly.co.jp/books/9784873119465/
この本はインセプションデッキなどを紹介した アジャイルサムライ のジョナサン・ラスマセンの新作。著者がソフトウェアエンジニアとして働いた急成長中の Spotify でどのような取り組みをして、なぜうまくいったのかをユーモアたっぷりに紹介してくれる一冊です。Design It! や モノリスからマイクロサービスへ などの翻訳をされている 島田浩二 さんと、アジャイルサムライ や アジャイルな見積もりと計画づくり、そして最近だと Clean Agile の訳者としても知られる 角谷 信太郎 さんによる翻訳です。訳者あとがき はCCライセンスで公開されているので気になる方はこちらをまず読んでみてください。
Spotify では組織をスケールさせるためにどのようなことをしてきたのかが書かれているのですが､そのままやれば成功するテクニック集ではありません｡ ちりばめられたヒントを拾い集めて､自分たちの組織をどうやってスケールさせるかを考えるきっかけにするという読み方が良いと私は思います｡
期待に応じる機械
本の中では､アジャイルな開発は今やふつうでみんながやっていることだと書かれています。 つまりアジャイルな開発をやっていることが優位性にはつながらないのが昨今のソフトウェア業界というわけです。
では私たちのチームはどうかというと御多分にもれず スクラム開発 をやっています。マネーフォワードではチーム毎に大きな裁量があり、それぞれの文化の中で開発を進めています｡会計Plus開発部では開発プロセスとしてスクラムを選択し、外部のスクラムコーチに開発プロセスの悩みを相談しながら開発を進めています。最近は人が増えたこともあって 大規模スクラム向けのフレームワークである LeSS に挑戦しています。
スクラム開発と聞くと経験主義を思い浮かべる方もいるかと思うのですが､本当に経験から学んでいるのは開発チームなのでしょうか？
私が入社したとき､チームは大きく分けて2つのグループに分かれているように見えました｡ ユーザーの課題をみつけて何を作るのかを決めるディスカバリーのプロセスを担当するプロダクトオーナー(PdM)とデザイナーと､それを開発してユーザーに届けるデリバリーのプロセスを担当するソフトウェアエンジニアの2つです｡
加えて会計領域というのは所属しているソフトウェアエンジニアメンバーにとって馴染みのない領域でした｡ 簿記などを勉強するなどして知識としては把握していても､実際に経理部の人がどのようなことで困っているのかまで把握するのは困難でした｡ よってディスカバリーを担当するメンバーの言うとおりに作るという動きがよくみられました｡
その体制は書籍に出てくるエンタープライズ企業のように｢期待に応じる機械｣でした｡ 私たちのチームでは実際に経験から学んでいるのはディスカバリーを担当しているメンバーだったのです｡
その分断は意図的に作った訳ではなくて､その壁を取り払おうとEpic大臣制度などを実施して努力している過程だったのですが､その辺りの話は今回は省略します｡ (Epic大臣については Scrum Fest Osaka 2022 に参加してきました！ も参照ください｡)
チームが｢学習する機械｣になるために｢探索･発見･学習｣のサイクルをどう回すかが課題でした｡
分離されたアーキテクチャ
少し話はそれますが､私たちのチームでは複数のマイクロサービスをメンテナンスしています
書籍の中でも触れられているとおり､アーキテクチャを分離するのは組織の責任範囲を明確にして､最速で開発できるようにする目的があるべきです｡ 本来は逆コンウェイ戦略と言われるように､組織を分割するための手段とすべきだったところを､私たちはアーキテクチャの分離自体を目的にしてしまいました｡ その結果､システム全体の複雑度が増してしまったり､コンテキストスイッチが発生して開発速度を落としてしまうことになってしまいました｡
現在はマイクロサービスを減らすために分離した機能を本体に戻す活動をしていますが､新規開発と比べると優先度を上げ切れておらず苦戦しています｡ 失敗談として触れておきます｡
マイクロサービスを作りたくなったら一度立ち止まってこの失敗を思い出していただけると幸いです｡
ベットに向き合う
書籍ではカンパニーベットというものが紹介されています｡ 会社が今どこに向かっているのかを明確にするために､やるべきことを絞るための手法です｡
当社は事業領域毎に会社として見立てるカンパニー制を実施していて､私が所属するビジネスカンパニーでも期毎に重点領域が決められています｡ それぞれの本部やプロダクト毎にそれを達成するために動いているので一見うまくいくように思うのですが､現状うまく回っているとは言い切れない状況です｡
マネーフォワード クラウドERP はコンポーネント型のEPRを目指しており､1つの課題をうまく解決するプロダクトを複数組み合わせて使う構成になっています｡ これはバックオフィスの各担当者がもっとも使いやすいものを提供するための戦略なのですが､最終的には各プロダクトに入力されたデータは一箇所に集める必要があります｡ その最終的にデータがたどり着く先が私たちのチームが開発している クラウド会計Plus です｡
ERPとしての方針が打ち出されたとしても､それを各プロダクトが全力で取り組むと結果を受け取る私たちのプロダクトも影響を受けます｡ つまり､他プロダクトがベットを達成しようとする動きが､私たちのチームのベット達成の障害になるということが起きていました｡
これは例えばERP全体としての優先順位をうまく設定出来ていなかったということでもあるとも言えるし､それを見越したロードマップを私たちのチームが立てられていなかったということでもあります｡ 目的はさらに使いやすいプロダクトを提供することに違いはなく､わざとこういう状況を作っている訳ではありません｡
現状､この問題についてはいい手を打てている訳ではありません｡ 試行錯誤しながらも､適切なベットが出来るように考え続けるしかないのかと思います｡
自律・権限・信頼
書籍の中では何度か｢自律･権限･信頼｣というキーワードが出てきます｡ チームがスケールするために必要なものとされていますが､私たちのチームはどうでしょうか｡
｢期待に応じる機械｣でも記述したとおり､ソフトウェアエンジニアのメンバーは作るものに対する理解がいまいち足りていなかったという事情があり､｢自律｣についてはまだまだ伸びしろありました｡反対に他の2つについてはうまくいっている他社と比べても遜色ない状態であったと思います｡あえて挙げるとすると｢権限｣はインフラ周りが全社管理となっている点､｢信頼｣については品質担当者のレビューが必須になっている点などが惜しい点です｡
以下にそれぞれどう改善してきたかを記します｡
まず｢自律｣についてですが､目的の明確化とドメイン知識の習得が重要と考えられます｡
目的についてはプロダクトビジョンの明確化や､部のミッションを作成するワークショップを行ったりと､自分達がどこに向かっているのかを自覚するための活動をしてきました｡ 目的が明確になると､自分達で判断するための軸が出来るために､より自立的に動けると考えています｡
ドメイン知識については勉強会や､経理部出身のプロダクトオーナーによる解説で補ってきました｡ 加えて2021年の暮れからドメインエキスパートとして参加したメンバーによって､紙を使った経理業務を体験するとワークショップが実施されました｡これによって実際に経理部がどこで困っているのか､なぜ私たちのプロダクトがあると嬉しいのかを身をもって体験することが出来ました｡
さらにこれまで分かれていたディスカバリーとデリバリーの溝を埋めるために､開発チームの中にそれぞれプロダクトマネージャとデザイナーに入っていただいて､普段から一緒に行動するようになりました｡ そうすることで､一緒にプロダクトを作っているという感覚がより強くなり､開発チームの自律が進んだように感じます｡
｢権限｣については､社内的に制限されていたのはインフラ周りの権限だったので､ここの改善を行いました｡ 元々のECSクラスタから､社内Kubernetes基盤へのアプリケーションの移行や､各ミドルウェアをチーム管理のAWSアカウントに移行することでチームで責任を持てる範囲の拡大を行ってきました｡ またSREチームを新設してチームでプロダクト全体を運用出来るような体制を整えつつあります｡
最後に｢信頼｣についてですが､元々チームメンバー間の信頼は担保されていました｡ しかし､あるときソフトウェアエンジニアのチーム編成を変えたところ､予定していた仕事が終わらずに毎スプリントしかかりが発生するようになってしまいました｡ 改善しようといくつかの手を打ったもののなかなか改善されず､結果的にプロダクトオーナーの信頼を失ってしまったのです｡ このときは一時的に権限を大きく制限することで､その権限の中で出来ることを確実にこなしてもらい､1スプリント毎に丁寧にインクリメントを重ねることで､チームに自信とペースを取り戻してもらいました｡ しっかりと開発出来るようになったチームはプロダクトオーナーの信頼を取り戻し､徐々に権限を戻していくことで以前より強いチームとなったのでした｡
またチームからマネジャーへの信頼に応えるためにも､マネジャー陣の議論を全てオープンな場所で行うことにして､風通しのよいチームを目指しました｡
生産性について考える
DORAチームによる研究でソフトウェア開発のパフォーマンスを計測する4つの指標が確立されています｡(Four Keys)
私たちのチームもこの指標を使ってまずは可視化をしてみることにしました｡ もっとも簡単に取得できるデプロイ頻度から計測を始めたのですが､他の指標を取る前に Findy Teams の存在を知って乗り換えることにしました｡
可視化を始めて良かったことは､これまで開発の速度が落ちているという実感があったタイミングで､実際にリードタイムが遅くなっていることを確認出来たことです｡ これによってチームに数値をみて判断するということの有用性が周知されて､すんなり導入することが出来ました｡
この辺りの話は書きたいことがたくさんあるのですが別途ブログが公開される予定なのでそちらに譲ることにします｡
文化を作る
文化を作るにはどうしたらいいでしょうか｡私もまだ何も分かっていません｡ 分からないなりにとにかく1つのことを言い続ける､試してみて有用性を体験してもらうことを意識していました｡
例えば､当初私たちのチームでは機能毎にブランチを分けて完成するまでの変更をまとめてから､最後にメインブランチにマージするという運用をしていました｡ QAのしやすさなどを優先した結果として選択した方法だったのですが､いわゆるビッグバンリリースをすることになるので様々な問題をはらんでいます｡ あるとき半年くらい育てたブランチをマージしたタイミングで様々な問題が起きてこの方法の限界を感じ､トランクベース開発に移行しようと決意しました｡ 最初は各所から反対が起きたのですが､何度も繰り返し言い続けてたり､フィーチャフラグを導入して次々とメインブランチにマージする体験をしてもらうことで有益なことを実感してもらいました｡ そうこうしているうちに､いまではむしろブランチがマージされずに残ってしまうことを避けるような文化に変わりました｡
新しいことをチームに取り入れるときは､最初は反発もあると思いますが､有益であることを訴え続けたり､実際に体験してもらうことで根付いていくのではないかなと思います｡
いかにしてモチベーションを生むか
私は組織をうまく動かす原動力になるのはモチベーションだと思っています｡
モチベーション3.0 によると､個人のモチベーションをうむのに必要な要素は｢自律･熟達･目的｣だそうです｡ 先に触れた｢自律･権限･信頼｣にも通ずる内容だと思います｡ この中で私は特に目的が重要だと思っていて､目的が明確であれば他の要素も追求しやすいと考えています｡
ところで､私たちのチームでは3年後のプロダクトビジョンは定義していたものの､チーム全員で考えたわけではなく､さらにビジョンの元となるはずのミッションを持っていませんでした｡ そこで｢自律･権限･信頼｣の項目でも触れたように､プロダクトオーナー主導でミッションを考えるワークショップを開催し､自分達が達成すべきことは何かを明確にする活動を行いました｡ ワークショップ内ではまず発散のフェーズを行い､メンバーの考えを吐き出すことに集中しました｡ そこから実際のミッションに収束するフェーズがまだ実施出来ていないのですが､これによって目的は明確になると信じています｡
これから
どうやって｢学習する機械｣となって組織をスケールするのか｡ ヒントを求めて何度も繰り返し｢ユニコーン企業のひみつ｣読むのですが､そのたびに｢近道はない｡やるしかないんだ｡｣という言葉に励まされます｡
繰り返しになりますが､この本を読めば答えが書いてあるということはありません｡ それぞれのチームで試行錯誤して､自分達の答えを探す必要があります
しかし､その課程こそが｢学習する機械｣そのものなのではないでしょうか。
チームで仮説を立てて､それをやってみて､そうやって少しずつでも良いチームになっていく｡ これを繰り返していくしかないのです｡
マネーフォワードでは、エンジニアを募集しています。 ご応募お待ちしています。
【会社情報】 ■Wantedly ■株式会社マネーフォワード ■福岡開発拠点 ■関西開発拠点（大阪/京都）
【SNS】 ■マネーフォワード公式note ■Twitter - 【公式】マネーフォワード ■Twitter - Money Forward Developers ■connpass - マネーフォワード ■YouTube - Money Forward Developers
