はじめに
こんにちは。サービス基盤本部長の鈴木です。
サービス基盤本部は、マネーフォワードが開発するサービス自体やそれを開発のためのプラットフォームや技術支援を通し、マネーフォワードの提供するサービスの安定化と開発にかかる生産性を最大化することがミッションです。
常々、プラットフォームはそれ単体ではなく、それを利用する開発組織とセットで考えなくてはいけないと思ってます。とてもありがたいことにマネーフォワードの開発組織はサービスの成長と共に成長し続けており、それに伴い変化する課題に、難しさとやり甲斐を感じています。このブログでは、過去、現在、将来においてサービス基盤本部がどのように開発組織を捉えているのかお伝えしたいと思います。エンジアリングそのものより、組織論としての話が多くなりますので、その観点でご興味があればぜひお読みください。
開発の生産性を上げるとは？
サービス基盤本部のミッションの一つである開発生産性の向上に焦点を当てたとき、生産性を上げるためにはどのようなことが必要でしょうか。
答えは無限にありますが、一例を挙げるならば、自動化や標準化の推進やAI技術の活用、またはより安価な人材を採用するというのも、会社としての生産性を上げる上で大事なことでしょう。
ただ私はある規模を超えた開発組織にとって、一番考えるべきはコミュニケーションのコストであろうと考えています。依存関係による調整やコミュニケーションのコストが開発に必要な時間を奪うことにどのように立ち向かうかというのが何よりも大切だと思っています。 開発の規模によりその課題や影響は変わり、対策も変化させていく必要があります。
1〜10人の規模で考えること
コミュニケーションの構造をモデル化して考えてみます。このモデルはコミュニケーションの全てを表している訳ではなく、不正確な部分もありますが、大体のイメージとして掴んでいただければと思います。3人の規模であればコミュニケーションの経路は3経路、4人の規模であればコミュニケーションの経路は6経路、5人の規模であればコミュニケーションの経路は10経路になります。
10人の場合、コミュニケーションの経路数は全体で45経路で、1人で意識するコミュニケーション先は9人です。また少人数であれば、お互いを理解してるため、1つの経路のコミュニケーションもあまり労力を使いません。この規模であれば、コミュニケーションのコストが特に問題になることはないでしょう。
10〜100人の規模で考えること
しかし、人数が増えると変わります。100人で同様に考えると、コミュニケーションの経路数で4,850通り、1人で意識するコミュニケーション先も99人です。感覚的にも分かると思いますが、この数は一人当たりの認知負荷の限界を当に超えていて、とても意識できるものではありません。
このモデルだと、コミュニケーションの経路の数は、全体のメンバーから2人を選び出す組み合わせの数なので以下のように表されます。
コミュニケーションの経路数(n) = n × (n - 1) / 2
開発者が増えることで、n2のオーダーでコミュニケーションの経路が増えることになります。開発者が増えることによって増加する生産力と一緒にグラフでイメージすると以下の通りです。
開発者が増えることで全体の生産力も上がりますが、その増加は開発者の数に比例します。(n1のオーダーです)
このグラフは、開発者を増やしていくと、発生するコミュニケーションコストが増員による生産力の増加を上回ることを示しています。 実際にはそうなる前に対策を打つのでそのようなことは起きませんが、そこまで行かなくても人数が増えるに伴い、増員当初に期待していた開発力が発揮できなくなることは皆さんも実感するところではないでしょうか？
対策1. チームの分割
その対策として一番に思いつくのは、チームを分けることでしょう。
チームを分割して、チーム内外のコミュニケーションを分けます。スモールなチームに分割することで、コミュニケーション先を限定化することができます。上図のように20人の開発体制を5人チームに分割すると、メンバーにとって必要なコミュニケーション先はチーム内の他メンバーの4経路だけに限定されます。
対策2. バックグラウンドの共有
全体の背景や理解を共有できていると、コミュニケーションのコストを抑えられます。 マネーフォワードはMVVCをすごく大事にしていますが、MVVCは背景を揃え、コミュニケーションのコストを抑えるためにも有効に機能します。
100〜1,000人の規模で考えること
マネーフォワードの開発組織は、まさにこのフェーズにありますが、開発組織の規模が100人を超えてくると、さらに状況が変わってきます。10〜100人で個人間で起こったコミュニケーション経路の爆発が今度はチーム間で起こるフェーズです。意識しないといけないチームの数が多すぎて、チームの窓口になる方がボトルネックになります。
例えば、200人の開発者を5人のスモールなチームで分割し、40チームになった場合、
- チーム間のコミュニケーションの経路数 = 40 × 39 / 2 = 780通り
- 1チームが意識しないといけないチーム = 39チーム
になります。これも認知不可の限界を超えています。
対策3. 組織、コミュニケーションの構造化
次の対策として、組織、コミュニケーション構造化することが挙げられます。
組織を階層化することで、コミュニケーション先を絞ることが可能です。 多くの組織で自然と組織を階層構造(例.会社-事業部-部-課)にして、コミュニケーションは限定化されてるのではないでしょうか？
他にも、マイクロサービス化はこの対策に含まれると私は考えます。 逆コンウェイの法則で組織をマイクロサービスのシステムアーキテクチャに合わせることで、コミュニケーションが構造化され、経路が限定されます。サービスのProviderはそれに必要な機能や開発者を隠蔽し、Consumerに対してコミュニケーションの経路を1つに絞ります。
対策4. チームの自律化、疎結合化
他チームに依存しない自律的なチームを作るという手段もあります。
職能横断型組織、フィーチャーチームは、チームの中に開発に必要な要素を閉じ込めることでチーム外への依存を無くします。また開発するサービス自体を他のサービスと疎結合にして、依存を無くす方法もあります。どの手段も依存を減らし自律化することで、必要なチーム外のコミュニケーションを減らすことに本質があると考えています。
対策5. APIの提供
APIを提供することも有効な手段です。（ここでいうAPIには、ドキュメンテーションも含みます。）
APIに問い合わせを任せることで、意識するコミュニケーション先を削ることが可能です。
要するに「人でなくて、物に任せる」ということだと思うのですが、システムやドキュメントは人よりスケーラビリティに優れており、任せることで多くのコミュニケーションから解放されます。上の図では、4つのConsumerからの問い合わせをAPIやドキュメントに任せています。サービスのProviderにとって意識するコミュニケーションはAPIの1つであり、この先Consumerが増えてもコミュニケーションの経路数は変わりません。
対策6. コミュニケーション言語の統一
マネーフォワードは現在、日本語、英語が入り乱れながら、エンジニアのコミュニケーションを英語に切り替えようとしている最中です。違う言語はやはりコミュニケーションのコストを上げるので、コミュニケーションの言語を統一することも大事です。
総合で考える
ここまで読んでいただいていかがだったでしょうか？
既に知っている、あるいは取り組んでいる話も多かったのではないかと思います。中には実践した上で、そんなに上手くいかなかったという方もいらっしゃるのでないでしょうか。正にその通りだと思っています。全てメリットとデメリットがあります。一つひとつはよく知られた話で、BigTechから情報が発信されているので正しいという先入観を持ってしまいますが、決して全ての場合において正しい取り組みでありません。
ただ私は総合で考えることが大事だと思うのです。 どれか1つを取り出して考えることではないのです。
この図はそれぞれの施策がどのような関係性を持ち、どのように影響しているのか、私なりに書いてみたものです。大事なのは、これらの対策は相互に複雑に補完しあい、強化しあい、コミュニケーションコストの削減という大きなゴールに繋がっているということです。一つひとつは欠点もあり、単品だとマイナスの影響が出てしまう可能性もあるものの、全体としてコミュニケーションを削るという一貫したコンセプトの元に相互に補完し、大きな効果に繋がっているのだと私は考えています。
一部だけを模倣してもダメです。先に述べたようにデメリットがあるので、むしろ後退する可能性があります。一度に全部をやることは大変だと思います。しかしだからこそ、BigTechは自分たちが得た知識を積極的に公開しているにも関わらず、競争優位性を保ち続けているのではないかと思うのです。一部分の模倣では大きな価値に繋がらず、それどころかマイナスになることすらあります。効果を最大化するには総合的に取り組む必要がありますが、それには大きなコストがかかるため、なかなか越えられない壁になってると私は考えています。（戦略は総合で考えることなど、最近ご紹介いただいて読んだ「ストーリーとしての競争戦略」に多分に影響を受けています。ご興味あればお読みください。）
まとめ
マネーフォワードでもそれぞれの施策でやっているチーム、やっていないチームがあり、全部を実現してるチームは希少です。しかし、マネーフォワードが更に大きくなり、より大きなユーザー価値をより早く提供できるようになるためにはどこか一部分を齧ってもダメだと思うのです。もちろんマネーフォワードのカルチャー、環境にあったやり方を模索しながらですが、一貫したコンセプトのもと、総合的にこういった組織戦略を実行していく必要があると考えています。
サービス基盤本部はこういった組織の成長・変化を支援し、加速させていきたいと考えています。前述のように総合的に取り組むことはすごく大変なことだとは思うのですが、その大変さを和らげ、壁を越えられるように推進していきたいです。やれることは無限にあります。
常に変化が求められるので大変なこともありますが、だからこそ成長ができる環境です。まだまだ変化しなくてはいけないことは多くあり、一緒に働く仲間を必要としています。成長する開発組織を支える経験を一緒に積みたい方、ぜひお声がけください。
【SRE】全社横断プラットフォームエンジニア・Enabling SRE_東京
あとがき
最初、サービス基盤本部が考えるプラットフォームやそれに付随する本部のロードマップを書こうと思いました。ただプラットフォームはそれを利用する組織とセットで考える必要性があり、それを伝えないと十分に意味のあるものにならないと思い、今回はサービス基盤本部が考える組織にフォーカスして書きました。次はこのブログを踏まえて、本題のロードマップをブログに書きます。（時間ができたら）
