こんにちは、freee株式会社 CTO の横路です。
この記事はfreee developers Advent Calendar 2019の最終日です。
昨年のアドベントカレンダーでは新卒で入ってくる君たちへというお題で、freeeの新卒の期待値は「3年でスモールチームのCTO」であるという話をしました。今年は次のステップとして、100名を超えるような「大きなチームのCTO」になるとどんなことを考えているのか？なかでも恐らくイメージしにくい技術戦略の考え方について、freeeの事例を振り返りながら、わかりやすくお伝えしたいと思います。
技術トップの役割の全体像と技術戦略の位置づけ
プロダクトマネジメントのバイブルである「INSPIRED 第2版」に、大きなチームの技術トップの責務がよくまとまっています。
- 組織
- 従業員の採用とスキル向上に全力を注ぐ強力なマネジメントチームづくり
- リーダーシップ（技術戦略）
- 全社戦略において技術部門を代表し、企業の進路、M&A、つくる/買う/提携するに関する意思決定をサポート
- 市場投入
- 高品質/迅速な製品デリバリーで、競合に負けないことに責任を持つ
- アーキテクチャ
- 競争・成長に必要な機能性・拡張性・信頼性・セキュリティ・性能を提供できるアーキテクチャに責任を持つ
- 製品発見
- 技術やエンジニアリング起点で製品企画に重要な貢献をする
- エバンジェリズム
- 開発者、提携企業、顧客とのコミュニティでリーダーシップを発揮
これらの責務を技術系幹部で分担していくのですが、このなかで最も馴染みがないのが技術戦略ではないでしょうか。
事業が増え組織が大きくなってくると「やったほうがよいこと」「できること」が大量に出てきて、施策の優先順位が以前より分かりにくくなってきます。そこで目指すべきゴールに最短経路でたどり着くために、思い切ってやらないことを決めるのが技術戦略です。
freeeでは今年から本格的に技術戦略に取り組みはじめており、CTOがその責務を担当しています。
「何で突き抜ける会社か？」を起点に技術戦略を考える
そもそも戦略とは、あるビジョンをどんな道筋で達成すべきか？に答えるものです。何を目指すかによって戦略は大きく異なるため、事業会社の全社技術戦略はまず「何で突き抜ける会社か？」を起点に考えることが重要です。
freeeは「スモールビジネスを、世界の主役に。」という壮大なビジョンを掲げ、そのビジョンを具現化したプロダクト群を軸に事業を展開することで大きく成長してきました。freeeにとっては、いかにプロダクトビジョンを達成しながらビジネスとしても成長を続けるか？が至上命題です。freeeのようなプロダクトカンパニーにおける技術戦略とは、プロダクトとビジネスの成長をいかに技術でサポートするか？ということです。
freeeでは、以下のようにプロダクト事業ビジョン（社内では航海指針と呼んでいます）を起点に技術ビジョンや技術戦略を引いています。
ビジョンや戦略は必ずしも明示されていないケースも多く、定期的に他部門のトップや経営幹部とコミュニケーションしながら自分なりに解釈していく必要があります。会議体の設計も重要です。
余談ですが、昨今は多くの企業が「テックカンパニー」を標榜していますが、時価総額1兆円以下の規模の企業で純粋に技術をコアな競争力にした事業で勝っているIT企業は現状ほぼないという認識です。将来ビジョンやマーケティングメッセージとして「テックカンパニー」を打ち出すのはもちろん構わないですが、技術戦略を考える上では、数年スパンではプロダクトで勝つ会社なのか？セールスで勝つ会社なのか？マーケティングで勝つ会社なのか？をクリアに認識しておくことは重要です。
プロダクトで勝つための技術仮説を立てる
次に、プロダクトで勝つための技術仮説を立てます。社内外のさまざまな情報とこれまでの経験を総合し、自分なりに確信を持てるストーリーをつくります。
例えばわたしは、「今後もプロダクトラインナップを増やすことで事業成長を狙うなら、仮説検証がとにかく速くて売れる・使われるプロダクトがどんどん出るというケイパビリティをfreeeの競争力に出来ないか？現状の開発投資比率を踏まえると、もっと基盤投資を加速させるべきではないか？」という仮説を立てて、市場からファクトを集めて確信を深めアクションに落とすというアプローチをとっています。
以下の図は、プロダクト開発のプロセスにおける、技術による付加価値の連鎖イメージです。かなり抽象的ですが、それぞれの歯車が回って正のサイクルが働けば、勝てそうなイメージが湧いてきませんか？
仮説の詳細や背景は話すと長くなるので、興味ある方は直接ご連絡ください。ランチでもご一緒しましょう。
技術による価値連鎖を積み上げていく順番
freeeのプロダクトはSaaSの形態で提供しており、顧客からのサブスクリプション課金によって売上が積み上がるビジネスモデルです。SaaSのセオリーやプラクティスについては米国を中心にすでに広く浸透してきており、業績や将来性をみるための指標も成熟してきています（手前味噌ですが、このあたりのキャッチアップには弊社CEOによるSaaSビジネスモデルの解説記事がおすすめです）。SaaSは初期投資のために大量の資金調達が必要なビジネスモデルであることからも、よいプロダクトを顧客に届けるだけではなく、SaaSに求められる成長を担保するための技術投資も重要になってきます。
freeeではこれまで、SaaSやリーンスタートアップのセオリーに則りざっくり以下の順番で技術投資をしてきました。 それぞれのステップは多少前後したり並走期間もありますが、概ねこの順番だと思います。
1. プロダクトマーケットフィットへの到達
まず、最低限の機能を揃えることとコア機能の価値確立にフォーカスしました。ここで金融機関の自動明細取込と自動仕訳の仕組みを磨き込んだことが、後にfreeeにとって大きな競争優位性になりました。
コア機能以外はなるべく手を抜き、基盤技術はなるべく内製せずSaaS, PaaS, OSSを使いたおす方針でした。
図2で言うと、⑦をとにかく絞り、①②④をとにかく高速に回すことにフォーカスするイメージです。
2. より大きな市場の顧客にも価値を届ける
SaaSのセオリーでは、特定の小さなセグメントでプロダクトマーケットフィットを達成したあと、新規顧客の売上規模を伸ばすために、投資を加速させながらより大きなセグメントへの価値提供を目指してプロダクトを拡張していきます。freeeではまず個人事業主向けの確定申告プロダクトからはじめて、給与計算・税務申告など周辺業務のサポートや、数百名規模の中小企業でIPOにも対応可能なようにプロダクトを進化させました。
図2で言うと、①②④を回せる規模を拡大しつつも、まだ⑦への積極投資はしないイメージです。アーキテクチャ的には、認証・課金などんの共通基盤を除いて積極的なマイクロサービス化などは行わず、各プロダクト毎にモノリスを太らせる選択をしました。
この過程でプロダクトの品質や開発スピードが著しく問題になるケースも増えてきたため、一括での負債返却や、問題を検知して暫定対応できる最低限の体制づくりをトップダウンの号令で行いました。
3. 本当に使えるプロダクトで顧客に長く価値を届ける
既存顧客からの売上の積み上げが大きくなってくると今度は、新規顧客の獲得よりもいかに既存顧客にプロダクトを使い続けてもらうか？が売上に効くようになってきます。SaaSのこの構造は、顧客が価値を感じてくれているからこそ使い続けてくれてくれるというロジックがfreeeの顧客ファーストな思想にマッチしやすく、プロダクトで顧客価値を追求すれば売上が上がる構造になっています。
これは前項の2の時期から始めたことですが、freeeではSFA・マーケティングオートメーションの導入、課金基盤の整備など、データドリブンなセールス・マーケティング・カスタマーサクセス基盤を構築しました。プロダクトの進化と並行して、どんな顧客層にどんな価値を届けるか？それはいくらなら使ってもらえるのか？どんな価値を感じた顧客がプロダクトを使い続けてくれるのか？ということを継続的に高速検証してアップデートしていくためにも技術基盤が重要です。得られた知見はプロダクトマネージャーが分析し、開発項目に落としていくイメージです。
図2で言うと、③に大きく投資するイメージです。
3. プロダクト・事業・組織のさらなる成長に向けて
主力プロダクトを中心にして屋台骨となる事業が育ってきた後は、既存事業の売上成長が一旦落ち着くリスクを想定して、さらなる安定成長のため将来の主力事業の種となるプロダクトラインナップを拡大していきます。ラインナップを増やしたときにいかにレバレッジが効くつくりにしておくか？は、戦略的に考えておくべき重要なポイントです。開発効率だけでなく、ユーザ体験や売り方にも大きく影響があるポイントです。
また、この頃になると恐らく開発組織も100名を超えてきて、主にコミュニケーションがボトルネックになって開発効率が落ちていきます。昨今のトレンド的には、DevOpsの文脈で、100名を超えても開発効率が落ちにくい、むしろ逆に上がっていくようなプラクティスがあることも分かってきています。
伸ばしたいプロダクトやコア機能の単位で、チームが独立して開発・リリース出来るケイパビリティが最もコアな競争力で、その競争力のテコを効かせるために、各独立チームが走るための高速道路や武器をつくって配る基盤投資が重要だと考えています。ここでもチームを独立させる単位は、開発効率やソフトウェアアーキテクチャの綺麗さだけではなく、売り方や組織論を考慮する必要があります。
freeeでは、プロダクト戦略や売り方の観点からマイクロサービス化するモジュールを決めたり、サービスは分けないまでもgRPCでIFを明示化してテストしいつでも分離できるように整備するような取り組み、マイクロサービス化ガイドラインや、新プロダクトが簡単に仮説検証できるフレームワークの開発などを始めています。技術的負債の返却に定常的に割くべき適正コストの肌感も分かってきたので、各チームが自律的に判断して適切な負債返却を行えるような指針も示していく予定です。
図2で言うと、⑤⑥⑦⑧に中長期でやりきる強い意志を持って投資を始めるイメージです。創業年数が浅く、優秀な開発チームを集められていた場合、⑤に必要なDevOps系のプラクティスの多くは既に実践できているケースも多いかもしれません。
まとめ
大きなチームの技術トップには必ず求められるが何をやっているのか分かりにくい技術戦略の考え方について、具体的にイメージしてもらいやすいようにfreeeの事例を交えながら紹介しました。課題解決を生業とするエンジニアのひとつのキャリアパスとして、これまで培った技術的センスと論理思考、情報収集力を活かして正解のない領域に仮説を立ててチャレンジするこの役割に興味を持ってもらえたら幸いです。
また、特に最近ますます増えてきたB2B SaaSスタートアップで開発部門を支えている皆さまにも、ひとつの事例として参考にしてもらえればと思います。正直に白状すると、創業時から経営に技術視点を持ち込めていたわけではありませんし、万事を戦略ストーリーに沿って進めていたわけではありません。後から振り返るとこういう構造だったよなということも多いですが、ご連絡いただければより詳細をお話しできます。
freeeは創業から7年が経ちますが、フロントエンドからインフラまでほぼすべての技術スタックが無事に一回転以上の世代交代をすることができました。freeeには運良く各技術領域に腕力と実行力を兼ね備えたエンジニアが揃っていたから、ボトムアップなアプローチで技術革新の波を乗りこなしてきましたが、次回の世代交代はボトムアップだけではうまくいかなさそうなポイントが既に見え始めています。ベストな技術選定がボトムアップかつ自律的に行われる環境を残すことで優秀なエンジニアの成長や採用を加速させつつ、現在はトップダウンの意思決定のテコを効かせるべきポイントを定義して、技術意思決定プロセスを整備しているところです。
通ってきた道だよ！という諸先輩方におかれましては、引き続きご指導ご鞭撻をよろしくお願いします。
技術戦略以外の技術トップの役割についても、Developer Blogでまた発信していこうと思っています。
