経営とソフトウェアエンジニアリングの接続

はじめに

2020年の1月から執行役員CTOに就任し、そこから数年間「CTOの役割は何か」を自問自答してきました。 就任当初から「CTOの役割とは、経営とソフトウェアエンジニアリングを接続することである」という考えはありましたが、上手く言語化できずにいました。 最近になってようやく他者へ説明できるレベルまで言語化できるようになったので、現時点での考えを残しておきたいと思い、4年ぶり(!)にブログを更新する1ことにしました。

本ブログポストの要旨

筆者の考えるCTOの役割は、「ソフトウェアエンジニアリング組織の日々の活動が企業価値の向上に繋がっている状態を作ること」です。 企業価値の向上のためにソフトウェアエンジニアリング組織が行うべき取り組みは、コーポレートファイナンスの視点を導入することで論理的に導けます。 そして、ソフトウェアエンジニアリング組織の日々の活動がこれらの取り組みに自然と向かうような組織を設計して運用することで、実際に企業価値を向上できると考えています。

なお、企業価値の向上を目的としていることからもわかるように、本論では企業の形態として株式会社を想定しています。

本ブログポストの構成

本ブログポストの以降の構成は次の通りです。

  1. 企業価値の構造化
  2. 企業価値向上のための取り組み
  3. 企業価値向上のための組織設計
  4. 運用時に考慮すること

最初に、企業価値向上の目的と算出方法を説明した上で、その構成要素をソフトウェアエンジニアリングによって改善できるところまで順に分解していきます(1)。 なお、DCF(Discounted Cash flow)法による事業価値の算出や財務三表の読み方を理解されている方は、次の「企業価値向上のための取り組み」から読み始めてもらって構いません。

次に、分解された企業価値の構成要素の増減に繋がる取り組みをソフトウェアエンジニアリング組織が行うべき取り組みとし、その実行を支える組織設計を考えます(2)(3)。

最後に、設計した組織の運用にあたって考慮すべき事項である、事業のライフサイクルについて説明します(4)。

これらの内容はできる限り一般化するよう努めましたが、筆者が置かれた状況、具体的にはインターネット経由で顧客にソフトウェアサービスを提供する事業会社を暗に前提とする記述が含まれうることをご了承ください。

1. 企業価値の構造化

企業価値向上の目的

本題へ入る前に、そもそもなぜ企業価値を向上させたいのかについて説明します。 端的に言うと、株式会社では株主がキャピタルゲイン(ここでは株価の値上がり益)を期待して出資しているからです。 理論的な株価は、企業価値から有利子負債を除いた株主価値を株式総数で割ると算出できます。 したがって、企業価値を向上させることで株主のキャピタルゲイン期待に応えられます。

企業の存在意義は企業によって異なり、それは理念やミッション、最近ではパーパスという形で定義されていることが多いでしょう。 これらの実現のためには、第一に株式会社として企業が存続し続けなければなりません。 したがって、どの企業も(程度の差はありますが)株主のキャピタルゲイン期待に応え続ける、すなわち企業価値を向上し続ける必要があります。

企業価値の算出方法

企業価値を算出するためのアプローチには、次の3つがあります。

  • インカムアプローチ: 対象企業が将来得るリターンをもとに企業価値を算出するもの
  • コストアプローチ: 対象企業が持つ資産価値を企業価値とするもの
  • マーケットアプローチ: 対象の企業と類似した上場企業の株価をもとに企業価値を算出するもの

ここでは、企業価値を構成要素をソフトウェアエンジニアリングによって改善できるところまで分解することが目的なので、インカムアプローチを採用します。 インカムアプローチにもいくつかの手法がありますが、その1つであるDCF法では企業価値を次のように算出します。

 企業価値 = 事業価値 + 非事業価値

 \displaystyle 事業価値 = \sum_{n=1}^N \dfrac{FCF_n}{(1 + WACC)^n} + \dfrac{FCF_N(1 + g)}{(WACC - g)(1 + WACC)^N}

ここで、非事業価値とは事業活動に用いられていない現預金や不動産、有価証券などの資産を時価に換算したものの合計です。 また、数式中の記号 FCF_n g WACCはそれぞれ、 n年後の予測フリーキャッシュフロー、永久成長率( N + 1年後以降の一定の成長率)、加重平均資本コスト2(以降「WACC」と表記)を表します。 つまり、事業価値とはその事業の将来のフリーキャッシュフローをWACCを用いて現在価値に換算したものの合計になります3

なお、WACCは次のように定義されます。

 WACC = R_d(1 - t)\dfrac{D}{D + E} + R_e\dfrac{E}{D + E}

ここで、数式中の記号 D E R_d R_e tはそれぞれ、有利子負債、株主資本、負債コスト(≒ 支払利率)、株主資本コスト、実効税率を表します。  R_eの推定にはCAPM(Capital Asset Pricing Model)という手法が主に用いられます。 ここではこれらの詳細には立ち入りませんが、もし詳しく知りたい場合は次の書籍がおすすめです。 筆者はこの書籍のおかけでレバードベータとアンレバードベータについて理解できました。

前述の定義からわかるように、企業価値は事業価値と非事業価値から構成されます。 そして、前者は(永久成長率を定数とみなすと)分子である将来のフリーキャッシュフローと分母であるWACCから構成されます。 したがって、企業価値を向上させるためには次のいずれかのアプローチしかない4ことがわかります。

これらのうち、非事業価値はそもそも積極的に増やすべきものではないため、無視してしまってよいでしょう。 なぜなら、株主は事業への投資を通じてキャピタルゲインを得ること期待しているからです。 その資金を事業活動に関係しない、ましてや株主自身でも投資できる資産のために用いることは、彼らの期待に反します。 このように、株式会社の仕組みを踏まえると、非事業価値を増やすことは企業価値向上のための適切なアプローチとはいえないでしょう。

また、WACCもソフトウェアエンジニアリングによる企業価値の向上を考える場合には無視してしまってよいでしょう。 なぜなら、これを低下させるための取り組みは、ソフトウェアエンジニアリング組織による関与が難しいからです。 WACCの低下は、(負債コストが株主資本コストよりも小さいことから)財務リスクの懸念が生じない範囲で有利子負債の比率を高めたり、IRを通じて株主資本コストを低くすることで達成できます。 しかし、これらはCFOの率いるファイナンス組織が取り組むことであり、ソフトウェアエンジニアリング組織が取り組むことではないでしょう。

フリーキャッシュフローとは

ここまでの話から、ソフトウェアエンジニアリング組織の場合、企業価値を向上するためには将来のフリーキャッシュフローを増やすことを考えればよいとわかりました。 では、フリーキャッシュフローとは何でしょうか。 文字通り「(企業が)自由に使える資金」ではあるのですが、定量的には次のように定義されます。

 フリーキャッシュフロー = 営業利益 \times (1 - 法人税率) + 減価償却費 - 運転資本増加額 - 設備投資額

ここで、減価償却費を足しているのは実際にキャッシュアウトが生じているわけではないからです。 このあたりについて詳しく知りたい場合、次の書籍などで財務三表について理解を深めるとよいでしょう。 筆者はこの書籍と『図解「ROEって何?」という人のための経営指標の教科書』のおかげで財務三表を概ね読めるようになりました。

前述の定義から、フリーキャッシュフローを増やすためには次のいずれかのアプローチを採ればよいことがわかります。

  • 営業利益を増やす
  • 法人税率を低くする
  • 減価償却費を増やす
  • 運転資本の増加額を減らす
  • 設備投資額を減らす

これらのうち、営業利益以外はソフトウェアエンジニアリング組織による関与が難しいため、無視してしまってよいでしょう。 各々の理由を説明すると長くなってしまうので、ここでは運転資本の増加額を減らすアプローチについて取り上げます。

運転資本とは、日々の事業活動に必要な資金のことです。 その増加額は、買掛金の支払いを遅らせる、商品が在庫として存在する期間を減らす、売掛金の回収を早めることで減少できます。 ソフトウェアサービスの世界では商品在庫が存在しない場合も多いですが、買掛金・売掛金は発生しているはずです。 身近な例では、顧客がソフトウェアサービスの利用料金をクレジットカードで支払った場合、その代金は後日入金されるので売掛金にあたります。 このような日々の資金の流れや在庫管理の最適化は、主にファイナンシャルコントローラーやそれ相当のポジションの方が取り組むことであり、ソフトウェアエンジニアリング組織が取り組むことではないでしょう。

営業利益とは

ここまでの話から、ソフトウェアエンジニアリング組織の場合、フリーキャッシュフローを増やすためには営業利益を増やすことを考えればよいとわかりました。 営業利益は損益計算書の1項目であるため、ご存知の方も多いでしょう。 一応定義を確認しておくと、次のようになります。

 営業利益 = 売上高 - 売上原価 - (販売費 + 一般管理費)

ここで、販売費は営業部門の従業員の給与、販売手数料、広告宣伝費などから構成されます。 また、一般管理費は管理部門の従業員の給与、採用費、通信費などから構成されます。

前述の定義から、営業利益を増やすためには次のいずれかのアプローチを採ればよいことがわかります。

  • 売上高を増やす
  • 売上原価を減らす
  • 販売費を減らす
  • 一般販管費を減らす

ようやくソフトウェア開発やシステム運用領域に近づいてきました。 分解はここまでにして、次にこれらのアプローチに沿ったソフトウェアエンジニアリング組織の取り組みを考えていきましょう。

2. 企業価値向上のための取り組み

ここまでの話から、企業価値は事業価値、フリーキャッシュフロー、営業利益の順に分解できることがわかりました。 そして、営業利益は売上高、売上原価、販売費、一般販管費によって構成されることがわかりました。 したがって、企業価値の向上のためにソフトウェアエンジニアリング組織が行うべき取り組みは、これらの会計項目の増減に繋がるものということになります。

では、各項目の増減に繋がる取り組みとは具体的に何でしょうか。 筆者は次のように考えています。

  • 顧客生涯売上の増加を目的としたプロダクト機能開発: 売上高を増やす
  • 売上損失の最小化を目的としたシステム運用改善: 売上高を増やす
  • サーバー費の適正化: 売上原価を減らす
  • 離脱率の低下を目的としたプロダクト機能改善: 販売費を減らす
  • 人件費の抑制を目的としたプロダクト運用改善: 販売費・一般管理費を減らす

以降では、これらの取り組みを取り上げた理由について説明します。

顧客生涯売上の増加を目的としたプロダクト機能開発

ここでの顧客生涯売上とは、売上高ベース5の顧客生涯価値のことです。 「価値」を「売上」に言い換えているのは、前者は「顧客がプロダクトの利用を通じて享受する恩恵」というような非会計的なニュアンスを纏ってしまうからです。 また、売上高ではなく生涯売上(高)を対象としているのは、前者の集計期間は制度会計上3ヶ月から1年間ですが、これより長い期間についても取り組みの対象とするためです。

顧客生涯売上は、例えばサブスクリプション型のソフトウェアサービスの場合、顧客平均単価をチャーンレートで割ると算出できます。 したがって、顧客平均単価を増やすかチャーンレートを低くすることで顧客生涯売上を増加できます。 そして、ソフトウェアエンジニアリング組織は、新規顧客に料金が高くても利用したいと思わせたり、既存顧客のアップセルやクロスセル、継続利用の理由となるプロダクトの機能の開発によってこれに貢献できます。

売上損失の最小化を目的としたシステム運用改善

売上高を増やすためには、プロダクトの機能を継続的に開発することに加えて、開発した機能を顧客に継続的に提供する必要があります。 なぜなら、ソフトウェアやサーバーの不具合によってプロダクトが障害を起こし、その機能を一時的に提供できなくなった場合、これらが発生してから復旧するまでの間に得られたであろう売上を失うことになるからです。 そして、ソフトウェアエンジニアリング組織は、システムの異常を早期に検知するアラートの実装や、リリースしたソフトウェアのロールバックにかかる時間の短縮などによってこの損失を最小化できます。

サーバー費の適正化

売上原価として計上される費用は事業内容によって異なります。 しかし、インターネット経由で顧客にソフトウェアサービスを提供する事業を運営しているのであれば、その内容が何であれ、ソフトウェアが動作するサーバーの費用が売上原価として計上されているはずです。 そして、ソフトウェアエンジニアリング組織は、サーバー構成の見直しや(パブリッククラウドを利用していれば)スポットやプリエンプティブと呼ばれる方式の仮想マシンの活用などによってこの費用を適正化できます。

離脱率の低下を目的としたプロダクト機能改善

ここでの離脱率は前述のチャーンレートのことではなく、顧客がオーガニック検索や各種広告、メディア経由でプロダクトに流入してから何らかの成約に至るまでの過程で離脱してしまう割合のことです。 ソフトウェアエンジニアリング組織は、プロダクトの既存機能における各ページの情報設計やユーザーインタフェースの改善などによってこの割合を低下できます。 これは、顧客獲得単価の削減、すなわち販売費を構成する会計項目である営業部門の従業員の給与や広告宣伝費の適正化に繋がります。

また、プロダクトに依らない技術的なアプローチを採ることもできます。 例えば、Webフロントエンドにおけるバンドルサイズの削減は、Largest Contentful Paintの改善によってユーザー体験を向上させ、離脱率を低下させるための取り組みといえるでしょう。

人件費の抑制を目的としたプロダクト運用改善

プロダクトの運用において、人の手による業務は多かれ少なかれ存在します。 ソフトウェアエンジニアリング組織は、プロダクトの管理画面やバッチ処理と呼ばれる機能の開発・改善によってこのような業務を完全自動化したり、その負荷を軽減できます。 これは、事業の成長に伴って増加するプロダクトの運用にかかる人件費の抑制、すなわち販売費・一般管理費を構成する会計項目の1つである従業員の給与の抑制に繋がります。

3. 企業価値向上のための組織設計

仮にソフトウェアエンジニアリング組織を構成する一人ひとりがこれまで説明した内容を理解し、これを彼らの日々の活動に反映できるのなら、意図的な組織設計は不要です。 しかし、組織規模が大きくなるにつれて、この仮定は現実的でなくなるでしょう。 したがって、これまで説明した内容を理解してもらわなくても、彼らの日々の活動が前述の5つの取り組みに自然と向かうような組織を設計する必要があります。

今回の場合に限らず、組織設計の変更によって何らかの問題を解決しようとするとき、筆者は次の流れで考えています。

  1. 対象の問題の構造を解明し、複数の具体的な問題に落とし込む
  2. 1の問題の解決を各チームに割り当てる
  3. 各チームが割り当てられた問題解決を上手く実施できているかどうかを表す定量的な指標を設定する

1はこれまで説明した内容そのものになります。 今回の場合、解決したい問題は企業価値が目標とする値6に達していないことで、具体化された問題は前述の5つの取り組み(解決策)の裏返しになります。 すなわち、顧客生涯売上、サーバー費、離脱率、人件費が目標とする値に達していないことです。

3の定量的な指標の設定は、ソフトウェアエンジニアリング領域では難しいことも多いのですが、大変重要です。 なぜなら、定量的な指標がないとチームが改善サイクルを上手く回していくことができないからです。 ここで設定した指標はそのチームのKPIとなります。

以降では、1で具体化された問題の解決策にあたる前述の5つの取り組みに対して、2、3を考えていきます。 具体的には、これらの取り組みの実施をどのような種類のチームにどんなKPIとともに割り当てるかについて説明します。 なお、チームの種類とKPIには、次の3冊の書籍で定義されたものを一部用いています。 各々の定義を説明すると長くなってしまうので、詳細はこれらの書籍を確認してもらえると幸いです。

顧客生涯売上の増加を目的としたプロダクト機能開発

顧客生涯売上の増加を目的としたプロダクトの機能の開発をStream-aligned teamに割り当てるべきなのは、その役割から明らかでしょう。 問題はそのKPIです。 これは、要求定義を誰が担うかによって異なります。

プロダクトオーナーやプロダクトマネージャーといったプロダクト責任者が要求定義を担う場合、Stream-aligned teamは要件定義以降の開発プロセスを担うことになります。 この場合、そのプロセスが上手く実施されているかどうかを表す定量的な指標をKPIとして設定します。 この指標としては、サイクルタイム(あるタスクに着手してから完了するまでにかかった時間)を採用し、単位期間における中央値の時系列推移をモニタリングするとよいでしょう。 なぜなら、プロダクト責任者の考案する機能が一定の確率で顧客生涯売上を増やすとするなら、単位期間内にリリースした機能の数が多い状態を保つことで、顧客生涯売上の期待増加額を最大化できるからです。 ただし、単位期間内にリリースした機能の数はチームの規模の影響を受けるため、その時系列推移をモニタリングしたい場合にはそのまま採用できません。 サイクルタイムはタスクに着目した指標であるため、この影響を除外できます。 もちろん、単位期間内にリリースした機能の数をソフトウェアエンジニアの数で割った値でも同じことを達成できます。 しかし、時間を表すサイクルタイムの方がチームに開発プロセス上のボトルネックに着目することを促せると考えて、こちらを採用しています。

ここまでの話はプロダクト責任者が要求定義を担う場合のものでしたが、要求定義もStream-aligned teamが担う場合、そのKPIは何が適切でしょうか。 筆者は今までこのようなKPIの設定に直接関わった経験がないため断言できませんが、サイクルタイムに加えて顧客生涯売上の構成要素をKPIとして設定すればよいと考えます。 例えばサブスクリプション型のソフトウェアサービスの場合、顧客生涯売上は顧客平均単価とチャーンレートで構成されると述べました。 この場合、顧客平均単価やチャーンレート、またはこれらをさらに分解して得られる指標をStream-aligned teamのKPIとすればよいでしょう。

売上損失の最小化を目的としたシステム運用改善

売上損失の最小化を目的としたシステムの運用改善をPlatform teamに割り当てるべきなのは、その役割から明らかでしょう。 そして、売上損失の最小化、すなわちプロダクトの障害時間の最小化が上手く実施できているかどうかを表す指標をKPIとして設定すればよいでしょう。 この指標としては、システムのSLO(Service Level Objective)を採用し、対応するエラーバジェットの残量の減少をバーンレートベースのアラート7を用いてモニタリングすればよいでしょう。

単位期間におけるエラーバジェットの残量は、同期間におけるエラーバジェットからシステム変更起因の障害時間と外的要因の障害時間を除いたものになります。 そして、単位期間におけるシステム変更起因の障害時間は、過去のデプロイの頻度、変更失敗率、平均修復時間の積から予測できます。 これら3つは「LeanとDevOpsの科学」で用いられた4つのソフトウェアデリバリパフォーマンス指標に含まれます。 また、残り1つのリードタイム(≒ サイクルタイム)も、後述するように特定の条件下ではデプロイ頻度の逆数を定数倍したものになるので、同書の4つの指標全てがSLOの遵守の可否に関係していることになります。

なお、システム変更起因の障害時間を減らすためにデプロイの頻度を減らすと、単位期間内にリリースした機能の数は当然少なくなります。 これは、前述の顧客生涯売上の期待増加額の減少に繋がるため、エラーバジェットを使い切ってしまった場合を除いて原則採るべきアプローチではありません。 したがって、平均修復時間と変更失敗率を短縮・低下させることが、システム変更起因の障害時間を減らすこと、すなわちSLOの遵守のために採れるアプローチとなります。

このあたりの考え方については、はてなの古川さんによる次の講演資料が大変参考になるので、ぜひ一度ご確認ください。

speakerdeck.com

サーバー費の適正化

サーバー費の適正化は、データベースやオブジェクトストレージのようにプロダクト固有の事情を多く含む項目と、仮想マシンロードバランサーのように固有の事情をあまり含まない項目で割り当て先が異なります。 前者であればStream-aligned team、後者であればPlatform teamにその適正化を割り当てればよいでしょう。

Platform teamはソフトウェアが動作するサーバーの構成を把握しており、これらに対して広範な変更権限を持つ場合が多いため、彼らに全ての項目の適正化を任せてしまいたくなります。 しかし、例えばオブジェクトストレージの費用の適正化は、顧客がアップロードしたファイルの保存期間の短縮といったプロダクトの仕様変更によっても達成できます。 このようなプロダクトの仕様変更を含む幅広い解決策の実行を促すため、プロダクト固有の事情を多く含む項目の適正化はStream-aligned teamに割り当てています。

では、このときのKPIは何が適切でしょうか。 この回答に関して筆者は今も試行錯誤している最中ですが、今のところ各事業の「売上高とサーバー費の予測増加率の差」と「当月のサーバー費の予算と予測の差」の2つを採用しています。 なお、前者は予算策定・修正時期に確認し、後者は週次でモニタリングするようにしています。 後者は簡易的な予予分析ともいえるでしょう。

離脱率の低下を目的としたプロダクト機能改善

離脱率の低下を目的としたプロダクト機能の改善をStream-aligned teamに割り当てるべきなのも、その役割から明らかでしょう。 そして、「顧客生涯売上の増加を目的としたプロダクト機能開発」で述べたのと同じ理由で、サイクルタイムと(必要に応じて)離脱率の構成要素をKPIとして設定するとよいでしょう。

1つ注意すべきなのは、プロダクトの特定のドメインにおける機能の開発と改善は、必ず同じチームに割り当てることです。 なぜなら、これらを別のチームに割り当てると、プロダクトの機能を「開発」するチームがソフトウェアの内部品質8を犠牲にして短いサイクルタイムを保つという行為を取ることを許してしまうからです。 これは彼らにとっては合理的な行為ですが、プロダクトの機能を「改善」するチームのサイクルタイムに悪影響を与えるため、避けなければなりません。

人件費の抑制を目的としたプロダクト運用改善

人件費の抑制を目的としたプロダクトの運用業務の改善は、必要な機能の開発・改善の規模によって割り当て先が異なります。 大規模なものであれば専任のプロジェクトチームを組成し、小規模なものであればStream-aligned teamにその実施を割り当てればよいでしょう。 なお、プロダクトの運用業務改善のための小規模な機能の開発・改善に継続して取り組む専任のチームを組成することは、そこに所属するソフトウェアエンジニアのモチベーションの観点から、あまりおすすめできません。 前述した顧客生涯売上の増加や離脱率の低下を目的としたプロダクトの機能を開発・改善するチームが、関連する運用業務の改善に並行して取り組む形が現実的でしょう。

では、このときのKPIは何が適切でしょうか。 前者の場合、プロジェクトの進捗状況の良し悪しを表す定量的な指標をKPIとして設定するとよいでしょう。 例えば、プロジェクト完了前のある時点における残タスクの量の計画と実績の差を採用し、これをバーンダウンチャートで可視化したものをモニタリングするといった方法があります。 後者の場合、これは筆者の同僚の方が考案したものですが、単位期間内に完了したタスクの種別を分類し、プロダクトの運用業務に関するタスクが全体に占める割合の時系列推移をモニタリングするという方法があります。 この値を一定の範囲内に保てていれば、プロダクトの機能の開発・改善と関連する運用業務の改善が上手く両立できていると判断できます。

補足: デプロイの頻度について

ここまで読まれた方の中には、「LeanとDevOpsの科学」で用いられた4つのソフトウェアデリバリパフォーマンス指標のうち、デプロイの頻度を利用していないことに気づいた方もいるでしょう。 なぜデプロイの頻度を利用していないかというと、特定の条件下では単位期間におけるデプロイの頻度はサイクルタイムを別の観点から捉えたものに過ぎないからです。 特定の条件とは、プロダクトの機能を開発・改善するチームの一人ひとりが同時に複数の進行中のタスクを持たず、完了したタスクを1つずつ本番環境にデプロイし、タスクの完了日内にデプロイを完了することです。 これらの条件が成り立つとき、単位期間におけるデプロイの頻度は、サイクルタイムの逆数にソフトウェアエンジニアの数と単位期間の長さを乗じたもので近似できます。 例えば、あるチームのサイクルタイムが5日、ソフトウェアエンジニアの数が4人の場合、単位期間を20日間としたときのデプロイの頻度は16に近い値となるはずです。 単位期間が短ければソフトウェアエンジニアの数は定数とみなせるので、デプロイの頻度はサイクルタイムによって近似できるといってもよいでしょう。

そして、3つの条件はWIP(Work in Progress)の制限とデプロイの自動化によって概ね達成できます。 これらの改善はサイクルタイムの短縮や障害発生時のエラーバジェットの減少の抑制にわかりやすく繋がるため、遅かれ早かれ実施されるでしょう。 これらの実施後、デプロイの頻度は前述したようにサイクルタイムの近似値となります。 このように、デプロイの頻度はいずれサイクルタイムによって代替できるため、前述の5つの取り組みの実施にあたって利用していません。

では、デプロイの頻度は全く使えないかというとそうではなく、ソフトウェアエンジニアリング組織改善の初手として大いに活用できます。 なぜなら、デプロイの頻度の方がサイクルタイムや他の指標よりも容易に計測できるという利点があるからです。 例えば、ニューズピックスの高山さんはこの利点を活かして、CTO就任後の短期間で素晴らしい成果をあげられています。

speakerdeck.com

4. 運用時に考慮すること

これまで説明した組織設計をチームの観点からまとめると、次のようになります。

チームの種類 取り組み KPI 関連する会計項目
Stream-aligned team プロダクト機能の開発・改善
サーバー費の適正化
プロダクト運用業務の小規模改善
顧客生涯売上・離脱率の構成要素
サイクルタイム
サーバー費の予算と予測の差
運用業務改善タスクの割合
売上高
売上原価
販売費
一般管理費
Platform team システム運用の改善
サーバー費の適正化
システムのSLO
サーバー費の予算と予測の差
売上高
売上原価
プロジェクトチーム プロダクト運用業務の大規模改善 残タスク量の計画と実績の差 販売費
一般管理費

こうして見ると、Stream-aligned teamに多くの取り組みが割り当てられていることがわかります。 したがって、その運用にあたっては各チームが抱えるタスクの量を現実的な大きさに抑える必要があります。 タスクの量を小さくするには、タスクのスコープを狭くするか、タスクの種類を少なくするしかありません。 前者は、プロダクトが扱うドメインのコンテキスト境界(≒ ストリーム)に沿ってチームを分割することで達成できます。 後者は、事業のライフサイクルを考慮してソフトウェアエンジニアリング組織が注力する取り組みを決めることで達成できます。

では、事業のライフサイクルとは具体的に何でしょうか。 以降では、筆者が事業のライフサイクルをどのようにモデル化し、注力すべき取り組みの決定にどのように利用しているかを説明します。

事業のライフサイクルモデル

企業価値の構造化」において、企業価値は事業価値と非事業価値から、事業価値は将来のフリーキャッシュフローとWACCから構成されると述べました。 そして、ソフトウェアエンジニアリング組織の場合、企業価値を向上するためには将来のフリーキャッシュフローを増やすことを考えればよいことを見てきました。 また、もう1つのアプローチであるWACCを低くすることは、ファイナンス組織の役割であることも述べました。

では、これらの組織を含む企業全体の業務執行の権限を持つ執行役9会の役割は何でしょうか。 筆者はその1つを「リソースアロケーションの最適化」と考えています。 これは、単一事業を運営する企業であれば「どの機能を持つ組織に経営資源10を投下するか」、複数事業を運営する企業であれば「どの事業に経営資源を投下するか」を決めることにあたります。 そして、後者を考えるにあたってよく用いられるのが、次のような2×2マトリックスです。

出所: 経済産業省(2020)「事業再編実務指針~事業ポートフォリオと組織の変革に向けて~

ここで、図中の横軸と縦軸の資本収益性、成長性にはそれぞれ、投下資本利益率(ROIC: Return On Invested Capital、以降「ROIC」と表記)、売上高成長率がよく用いられます。 ROICは次のように定義されます。

 ROIC = \dfrac{営業利益 \times (1 - 実効税率)}{有利子負債 + 株主資本}

また、横軸と縦軸を二分する基準値にはそれぞれ、WACC、売上高成長率の全社目標やGDP成長率がよく用いられます。

ROICとWACCの大小関係と売上高成長率は、企業価値の向上に関係します。 具体的には、ROICがWACCよりも大きく、売上高成長率が高いほど企業価値は大きく向上します。 逆に、ROICがWACCよりも小さく、売上高成長率が高いほど企業価値は大きく低下します。 McKinsey & Companyの佐藤さんによる次の連載記事に感度分析の結果が掲載されているので、興味のある方は確認してみてください。

dhbr.diamond.jp

なぜ事業のライフサイクルの説明にあたってこのマトリックスを取り上げたかというと、筆者はこれを事業のライフサイクルのモデルとして利用しているからです。 具体的には、4つの象限をライフサイクルの各ステージに対応付け、AからDの順に事業が成長・衰退していくとしています。

なお、事業の誕生から衰退までの各ステージを2×2マトリックスの4象限で説明するという発想は、特に目新しいものではありません。 類似するものの中で最も有名なのが、ボストン・コンサルティング・グループが考案した「プロダクト・ポートフォリオマネジメント」です。 このブログポストを読んでいる方の中には、「金のなる木」や「キャッシュカウ」という言葉を聞いたことのある方もいるでしょう。 実はこれは、プロダクト・ポートフォリオマネジメントの2×2マトリックスにおける1つの象限の名称です。

どのように利用するか

前掲した2x2マトリックス図における各ステージは、事業の資本収益性とその基準値の差の正負、事業の成長性とその基準値の差の正負によって定義されます。 横軸と縦軸の値に前述したような会計項目から算出される財務指標を用いると、これらの値を増減するためにどの会計項目を増減すればよいかがわかります。 そして、どの会計項目を増減すればよいのかがわかれば、今までの説明から、自ずとソフトウェアエンジニアリング組織が実施すべき取り組みもわかります。

では、各ステージでは具体的にどの会計項目の増減に注力すればよいでしょうか。 ソフトウェアエンジニアリング組織の取り組みと関連する会計項目に絞った場合、筆者は次のように考えます。

  • ステージA: 売上高を増やす
  • ステージB: 売上高を増やす、販売費を減らす
  • ステージC: 売上原価を減らす、販売費・一般管理費を減らす
  • ステージD: 売上高を増やす

以降では、各ステージでこれらの会計項目の増減に注力する理由を企業価値の向上の観点から説明します。 そして、注力すべき会計項目の変化に応じてソフトウェアエンジニアリング組織の注力する取り組みを変えていく様子を示します。

ステージA

ステージAでは、事業を始めたばかりなので売上高成長率は高いものの、売上高自体は小さいためほとんどが営業赤字となります。 したがって、ROICはWACCよりも小さく、このステージに留まり続けると企業価値は低下していきます。 また、このステージではプロダクトの完成度も低いので、まずはプロダクトをできる限り早く作り込んで顧客数と売上高を増やすことに注力して、ROICの向上を目指します。

ソフトウェアエンジニアリング組織では、Stream-aligned teamを組成して顧客生涯売上の増加を目的としたプロダクト機能の開発に注力して、売上高の増加を図ります。

ステージAで(成り行き任せの)顧客獲得が難しくなってきたら、営業やマーケティングによる意図的な顧客獲得に取り組みます。 このとき重要なのは、顧客生涯売上と顧客獲得単価の差が正となる、すなわちユニットエコノミクスが成り立つ手法を探すことです。 なぜなら、ユニットエコノミクスが成り立たない状態で営業やマーケティングに注力すると、売上高は増えますが、同時に営業赤字も大きくなり続けてROICが低下するからです。 逆に、ユニットエコノミクスが成り立った状態でこれらに注力すると、ある時点で営業赤字が小さくなり始めます。 これ以降では、売上高をさらに増やしながら販売費の適正化にも注力することで、ROICがWACCよりもできる限り早く大きくなるようにします。

ソフトウェアエンジニアリング組織では、Stream-aligned teamで離脱率の低下を目的としたプロダクト機能の改善に少しずつ取り組み始めます。 また、売上高が大きくなるとプロダクトに障害が起きたときの売上損失も大きくなるので、Platform teamを組成して売上損失の最小化を目的としたシステム運用の改善にも取り組み始めていきます。

ステージB

ステージBでは、ROICがWACCよりも大きく、売上高成長率も高いので、このステージに長く留まり続けることで企業価値を大きく向上できます。 したがって、売上高の増加と販売費の適正化の両方に注力することで、ROICと売上高成長率の両方を維持、またはさらに向上させることを目指します。

ソフトウェアエンジニアリング組織では、顧客生涯売上の増加を目的としたプロダクト機能の開発に注力して、売上高の増加を図ります。 また、離脱率の低下を目的としたプロダクト機能の改善にも注力して、販売費の適正化を図ります。 どちらもStream-aligned teamの取り組みとなるため、必要に応じてチームを分割して各チームの取り組みのスコープを狭くすることで、タスクの量を現実的な大きさに抑制します。

ステージC

事業が対象とする市場の成長やその中でのシェアの向上が落ち着いてくると、ある時点で売上高成長率が基準値よりも低くなってステージCに到達します。 売上高成長率は低いものの、ROICがWACCより大きいので、このステージに長く留まり続けることで引き続き企業価値を向上できます。 ただし、売上高の増加余地は小さくなっているので、相対的に改善余地の大きい費用の削減に注力することで、ROICの向上を目指します。 そして、得られた資金をステージAの事業に投下することで、企業価値の持続的な向上に繋げていきます。 これは、前述したプロダクト・ポートフォリオマネジメントにおけるキャッシュカウの役割に相当します。

ソフトウェアエンジニアリング組織では、Stream-aligned teamとPlatform teamでサーバー費の適正化に注力して、売上原価の削減を図ります。 また、必要に応じてStream-aligned teamからスピンアウトしたプロジェクトチームを組成し、プロダクトの運用業務の大規模な改善に取り組むことで、販売費・一般管理費の抑制を図ります。

ステージD

費用の削減余地が小さくなり、その上で売上高成長率がさらに低くなると、ある時点でROICがWACCよりも小さくなってステージDに到達します。 ROICがWACCよりも小さいので、このステージに留まり続けると企業価値は低下していきます。 したがって、売上高の再増加に向けた抜本的な改革、または事業の撤退かベストオーナーへの売却をできる限り早く行う必要があります。

ソフトウェアエンジニアリング組織では、売上高の再増加にあたって開発が必要なのであれば、Stream-aligned teamがこれに注力します。

おわりに

本ブログポストのように、コーポレートファイナンスの視点からソフトウェアエンジニアリングについて述べたものとしては、ビジョナルCTOの竹内さんの「CTOの頭の中」シリーズがあります。 中でも次のnoteの記事は筆者がコーポレートファイナンスに興味を持つきっかけを作ってくれた素晴らしい内容で、定期的に読み返しています。

note.com

個人的にはこのような内容がもっとインターネット上で議論されてほしいのですが、私が調べた範囲ではあまり見つけられなかったというのが本ブログポストを書いたもう1つの理由です。

本ブログポストの内容が、コーポレートファイナンスとソフトウェアエンジニアリングの関係性の議論の発展に少しでも貢献できれば幸いです。

参考文献

  1. コーポレートファイナンス 戦略と実践
  2. サステナブル経営とコーポレートガバナンスの進化
  3. 新規事業の実践論 (NewsPicksパブリッシング)
  4. 新版 財務3表一体理解法 (朝日新書)
  5. 事業ポートフォリオマネジメント入門―資本コスト経営の理論と実践
  6. 戦略としての企業価値
  7. 全社戦略がわかる (日本経済新聞出版)
  8. ワールドクラスの経営 日本企業が本気でグローバル経営に挑むための基本の書

  1. 当初は、筆者がホストを務めるポッドキャストtexta.fm」でこの話をするつもりでしたが、放送原稿を書き始めてすぐにこれを音声で説明するのは難しいと気づき、ブログポストの形での公開となりました。
  2. WACCはWeighted Average Cost of Capitalの略なので、日本語に訳すとこうなります。
  3. 事業価値の式の第2項は、継続価値を表しています。この値は、初項 \frac{FCF_N(1 + g)}{1 + WACC}、公比 \frac{1 + g}{1 + WACC}の無限級数(通常、 g \lt WACCとなるように gを設定するので収束します)を WACCを用いて現在価値に換算することで算出します。
  4. 実はこれらの上位に位置するアプローチが存在し、それが後述する「リソースアロケーションの最適化」になります。特にWACCに基づいた財務的資源の配分は、デットガバナンスの時代が長らく続いた日本企業の苦手とする分野です。
  5. 売上高以外だと、粗利(売上総利益)ベースの顧客生涯価値があります。
  6. 万が一目標とする値がない場合、まずはこれを決めるところから始めましょう。
  7. バーンレートベースのアラートの詳細に関しては、前述の「サイトリライアビリティワークブック ―SREの実践方法」や同書のオンライン版の5章「Alerting on SLOs」を参照してください。
  8. ソフトウェア開発において犠牲に捧げられがちな内部品質が具体的に何で、その犠牲によって本当に開発速度が得られるのかという議論に関しては、和田卓人さんによる講演資料「質とスピード」を参照してください。
  9. あえて「執行役(≠ 取締役)」としているのはコーポレートガバナンスにおける「監督と執行の分離」を強く意識しているからですが、このテーマについて言及すると収拾がつかなくなるのでここでは割愛します。
  10. Jay B. Barney氏によると、経営資源は「財務的資源」「物的資源」「人的資源」「組織的資源」の4つに分類できます。詳しくは彼の著書「[新版]企業戦略論【上】基本編――戦略経営と競争優位」を参照してください。