はじめに
こんにちは、viviON開発部のakkt222です。viviONでは基盤チームというチームで、社内のプロダクト向けのマイクロサービス群の開発・運用に従事しています。
基盤チームはTeam Topologiesで言うところのComplicated Subsystemチームに分類されるチームです。自分たちで開発をするのみならず、社内の他のチームに対してマイクロサービスアーキテクチャの啓蒙も行っているので、Enablingチームでもあると言えるかもしれませんが、基本的には8割方Complicated Subsystemを作っているチームだと言って良いと思います。
viviONのエンジニアはしっかりと事業に貢献していきたいと思っている人が多いですし、ボード・マネージャーもそれを求めているので、事業貢献について考える機会があります。
ただ、直接プロダクトを作っているわけではないのに事業に貢献するのって正直なところ結構難しくないですか…？私はviviON入社前は直接プロダクトを開発する仕事しかしたことがなかったのでかなり戸惑いました。
そもそもエンジニアチームは心の持ち用や動き方としてはともかく、管理会計上はほとんどの場合コストセンター・間接部門になると思います。その上、エンジニアチームの中でもプロダクトから距離のあるComplicated Subsystemチームが事業に貢献するというのは具体的にはどういうことなんだろう？ということをこの2年間折に触れて考えてきました。その思考をアウトプットするのがこの記事の目的になります。
想定読者は以下のような方です。
- viviONという会社に興味のある、特にエンジニアの方
- ご自身がStream Alignedチーム以外の、プロダクトとは一定の距離があるチームに所属されている方
- エンジニアの事業貢献というトピックについて興味がある方
なお、この記事は「Complicated Subsystemチームが事業貢献をするとはどういうことなのか」を構造的に解き明かすことに終始しているため、行動に移すためのtipsや心持ちに関するアドバイスなどはほぼ全く含まれません。
また、他社のComplicated Subsystemチームの事情や同様にプロダクトとの距離があるPlatformチームの事情についてなどは（多少の共通項はあると思いますが）当事者ではないので書くことが出来ません。その点予めご了承ください。
事業とは
そもそも、我々が貢献せんとしている「事業」というのは何なのでしょうか？
硬めに辞書を引いても良いですし、あるいは「課題を解決することが事業である」というように柔らかい表現をしても間違っていなさそうですが、今回はweworkのホームページ
「事業」の言葉の意味とは？事業の種類も解説 から引用して理解しようと思います。
https://wework.co.jp/contents/knowledge/case263
企業（営利を目的として商品の販売やサービスの提供などの経済活動を営む組織）が、営利などを目的として組織を営むことを「事業」と呼びます。
事業、業務、職務の主な違いは以下の通りです。
・事業は、企業が行っている継続的な仕事
・業務は、事業の中の一部の仕事
・職務は、企業の各従業員が担当する仕事
イメージとしては、まず企業が行う事業があり、その事業の中で業務が発生し、その業務を職務として各従業員が担当しているといった流れになります。つまり、それぞれの言葉の意味こそは違いますが、点と点が1つの線として繋がっているのです。
これらから「事業」について以下の特徴が読み取れると思います。
- 1.営利的である
- 2.継続的である
- 3.業務は事業の一部であり、社内の業務の全てを集めた集合が事業である
1と2は表裏一体ですね。一般論として、継続的であるためには営利的である必要があるように思われます。（じゃあ例えばOpen AI社のように現在営利的でもなければ利益を生み出す兆しも見えないスタートアップの営んでいるのは事業ではないのか？と揚げ足を取りたくなりますが、スタートアップは特殊なので、例外だと考えましょう。）
3については、特に事業貢献について熱心でない従業員だったとしても普通に仕事をしていればそれだけで事業の一部を遂行していることになることを示しています。ただ、ボード・マネージャーの方が社員に「事業貢献をして欲しい」というメッセージを発している時「普通に仕事してればOK」という意味を込めている訳ではないと思いますし、そう受け取るのも聞き手の主体性が低いように思われます。この文脈においては3はあくまで定義の問題でしかなくて、実際に問題とされているのは1と2だと考えて良さそうです。ですので今回3は無視します。
ここで1と2についてもう少し掘り下げてみましょう。
1に関して、営利的であるとは利益が出ている状態を指すと考えられます。費用が売上を上回っていれば上回っているほど良さそうですが、ここに貢献する方法は大まかに以下の二通りがありそうです。
- 売上を増大させる
- 費用を縮小させる
前者は営業活動やマーケティング、あるいは攻めのソフトウェア開発などの設備投資によって実現出来る可能性がありそうです。後者は人件費も絡むため若干センシティブな話になりますが、例えばインフラ構成の見直しによってコストを削減するなどの活動によって貢献出来そうです。また、間接的な例を挙げると、例えば採用活動によって優秀な人を採用出来た場合、費用が増大するので一見事業に貢献していないように見えるものの、優秀な人は上記の2パターンのどちらか、または両方に大きく貢献してくれることが予想されるので採用活動は事業貢献になりそうです。
2に関しては、1よりも定性的な側面があるので読み解くのが少し難しくなりますが、利益が出ている状態の継続性に貢献出来れば事業貢献をしていることになりそうです。次章で詳述しますが、Complicated Subsystemチームとしてはこの2を通して事業貢献を目指していくのが有力な勝ち筋になるのではないかと考えています。
Complicated Subsystemチームの事業貢献について
Complicated Subsystemチームの活動が売上に直接繋がることは正直かなり稀だと思います。もちろん機会があればどんどん前に出ていくべきですが、基本的にはかなり間接的な話になってしまいます。
例外は無いこともないですが、基本的には我々が作ったものを社内のプロダクトチームがプロダクトに組み込んでくれて、それがユーザーに使われて初めて価値となるため構造上も間接的な貢献になります。
費用についても、ちょっと厳しいです。特に基盤チームの場合、新しいマイクロサービスをかなりの速度でリリースしており、さらにアクセルを踏んで2026年は100サービスをリリースすることを目標にしています。この活動によってインフラ費用はむしろ増加しますし、採用費も人件費もかかります。
強いて言えば、基盤チームには社内での車輪の再発明を防ぐというミッションもあるので、主に他チームの工数やプロダクトの機能リリースまでのリードタイムを節約していると言えないこともないですが…。
このように、直接金銭における貢献について明示するのは難しいのですが、継続性について見ていくと話は変わってきます。
継続性とは「今利益が出ているかどうか」ではなく「この先も同じように、あるいはより安定して利益を生み出し続けられる状態にあるか」という問いです。そしてこの問いに対して、Complicated Subsystemチームは比較的はっきりした形で貢献できる立場に居ると考えています。
最も分かりやすいところでは、基盤チームで運用している決済サービスの存在が挙げられます。これは様々な決済手段を社内向けに一元的に提供しているサービスで、コンスタントに決済手段を拡充しています。
弊社の場合、既報の通り突如としてクレジットカード決済が使えなくなる事態が実際に発生しました。
決済手段を拡充し、決済の冗長性を強化していくエンジニアリングの営みは、売上にも繋っていますがそれ以上に事業の継続性の観点での貢献が大きいものです。
ここまで分かりやすい例ばかりではないですが「継続性」について更に掘り下げてみると、これは「現状維持」の話ではないことが見えてきます。SaaS企業のRule of 40ほどでは無いにせよ、IT企業は毎年毎年同じような業績を出し続けていれば良いものではなく、現状維持は衰退を意味すると言って過言では無いと思います。（ここでは少し根拠が薄弱ですが、一般論として十分受け入れられる言説だと信じています）
つまり「継続性」とは正確には「事業の成長の継続性」のことだと言って良さそうです。
ではIT企業がどのように成長するのかというと、既存プロダクトは弊社でも伸び続けているものの、近年では基本的にはマルチプロダクト戦略によって成長すると考えられていると思います。
現に弊社でもM&Aは盛んに行われていますし、社内での新規事業も立ち上がっています。
マルチプロダクト戦略を取る企業において重要になるのは、「新しいプロダクトをいかに速く立ち上げられるか」「新しいプロダクトと既存プロダクトのシナジーをいかにして生み出せるか」という点です。
この文脈では、Complicated Subsystemチームの役割ははっきりしていると思います。
基盤チームが提供するマイクロサービス群は、個々のプロダクトの売上を直接押し上げるものではありませんが、「新しいプロダクトを立ち上げる際の初期コストを下げる」「共通データ基盤の提供によってプロダクト間のシナジーを生み出す」といった形で、事業の成長の継続性に寄与します。
例えば、新規事業を立ち上げるたびに、決済、ポイント、購入履歴、取引先マスタ等々のシステムを毎回スクラッチで作っていたらどうでしょうか。QCDの全てにおいて危険を孕みそうです。
一方で、基盤チームがこれらをマネージドに提供できていると、プロダクトチームは本来集中すべき価値創出の部分に集中することができます。
ここで重要なのは、この貢献が非常に測りづらいという点です。
「この基盤があったから売上がいくら増えた」と直接言えることはほぼありませんし、それ以外の数字に落とすのも簡単ではありません。しかし、「もしこれが無かったら？」と考えると、その不在は中長期的に致命的です。新規事業の立ち上げや新しい挑戦の機会が減少し、失敗のコストが増え、結果として打席に立てる回数自体が減るかもしれません。つまり「継続性」が損なわれてしまいます。
おわりに
結論、Complicated Subsystemチームは売上よりも、組織全体のアジリティ向上やプロダクト間のシナジーの創出を通して事業の継続性を高めるという形で事業に貢献するのではないか（しているのではないか）と思います。
Complicated Subsystemチームの事業貢献は、一見地味で分かりづらく、説明コストも高いですし、当事者の腹落ちも難しいものになりがちです。
しかし、書いていて改めて思いますが、日々の業務と事業貢献を結びつける際に求められる視座が非常に高いということは特徴的で面白い点ではないでしょうか。
正直、だいぶ背伸びして書きましたが、誰かの参考になれば嬉しいです。