本記事は、CADDi プロダクトチーム Advent Calendar 2024 10日目の記事です。 adventar.org
はじめに
CTO室の西名(@mikesorae)です。最近はもっぱら予算策定や生産性改善の施策を担当しています。
ソフトウェア開発とビジネス、インフラ構成と予算管理、生産性と投資対効果等、事業組織でソフトウェアを開発する上ではどうしてもお金の話がついて回ります。 本記事では、ソフトウェア開発者がステークホルダーと建設的に議論し、より大きなインパクトを生み出すために抑えておくべき会計の用語やポイントをご紹介します。
Why 会計知識
ゲームのルールを理解する
「今このチームにこれ以上の人員は追加できない」「なぜこのツールが必要なのかを説明してほしい」「その技術導入による事業インパクトを説明してほしい」
皆さんも経営者や事業責任者(あるいは中間のマネージャ)との議論の中で上記のようなことを言われ、やきもきしたことが少なくないのではないでしょうか。
僕は、ソフトウェア開発者と経営者、事業責任者とのコミュニケーション摩擦の原因の一つは、それぞれがプレイしているゲームのルールが異なることだと考えています。
営利企業で働く以上、我々は市場や法制度のルールに従う必要があり、会計はその中でも特に重要なものの一つです。 経営者や投資家、金融機関は会計を共通言語として会話し、その基盤の上に経営戦略や事業戦略のレイヤーが存在しています。 経営者や事業責任者も漏れなくこのルールや力学に従っているので、彼らがどういうルールの上でゲームをプレイしているのかを理解することで、より建設的で有意義な議論ができるようになると考えています。
本記事のゴール
今回は特に損益計算書(Profit and Loss statement: PL)にフォーカスし、以下を目指したいと思います。
- PLレベルでの事業構造の解像度を上げる
- ソフトウェア開発の施策の事業的価値をPL上の言葉で理解する
財務会計と管理会計の話は長くなりそうなので、今回は触れずに進みます。
財務三表と損益計算書(PL)
財務三表とは「貸借対照表(Balance Sheet: BS)」、「損益計算書(Profit and Loss statement: PL)」、「キャッシュフロー計算書(Cash Flow statement: CF)」の3つで、それぞれ会社の資産状況、収益状況、お金の流れを表す資料です。 特に上場企業であれば有価証券報告書として上記を含んだ財務諸表を提出する必要がありますし、会社法ではすべての会社が事業年度ごとの貸借対照表や損益計算書を作成することを義務付けられています。
経営者や投資家はこれらの資料を使って会社の資産や事業、財務状況の健全性を把握し、今後の方針を判断します。
今回は特に「事業の健全性を把握するためのツールとしてのPL」と「ソフトウェア開発」の関係について説明してみたいと思います。
PLの基本構造
下記の図は、一般的なPLの内訳をわかりやすく表現したものです。
具体的にイメージしやすくするために、簡単なPLのサンプルを用意しました。
一番上に売上高があり、そこから売上原価や一般管理費等を引いたり営業外収益を足したりしていって、最終的に残ったものが純利益となります。
PL上の売上高や原価率、営業利益率等を見ることによって、事業の収益性の健全さを知ることができます。 (余談ですが、売上目標文脈でよく出てくる「トップライン」という言葉は、PLの一番上の行に売上高が来ることから来ているそうです)
ここからはPL上の各項目について、事業上の意味やソフトウェア開発における関係を掘り下げていきたいと思います。
売上高 (Sales)
売上高はその名の通り、その会社や事業が製品やサービスの販売によって得た売上の合計です。 売上高が大きいということは、単純に良い製品やサービスを提供していることや、優れたブランド認知、マーケティングチャネル、セールス部門等、売上に影響するなんらかの強い要素を持っていることの間接的な証明になります。
一般的に、売上高はその事業が成長し続けているかどうかを測るための最重要指標として利用されます。
売上原価 (Cost of goods sold: COGS)
売上原価は、製品やサービスを提供するために必要なコストです。 例えばパン屋さんであれば以下のようなものが含まれます。
- パンを作る材料費 (直接材料費)
- パンを作る職人さんの賃金 (直接労務費)
- パンを焼く設備費 (直接経費)
- パンを作る上で必要な、オイルやクッキングシート等の消耗品 (間接材料費)
- パンを販売する人の賃金 (間接労務費)
- パンを焼く設備の修繕費 (間接経費)
(厳密には売上原価には当期に販売された製品の製造原価が含まれます)
何を原価として計上するかは会社のポリシーにもよりますが、ソフトウェア開発では以下のようなものが売上原価として考えられます。
- AWS/Google Cloud/Cloudflare等のインフラ費用
- サービス提供に必要なソフトウェアやライセンス費用 (地図APIや決済API等)
- 運用・監視・保守に必要なソフトウェアやライセンス費用
- オンコール対応や待機における人件費の一部
- サポートやカスタマーサクセスの人件費の一部
- サービス維持に必要なセキュリティパッチや不具合修正対応の人件費
売上総利益 (粗利益、Gross profit)
売上高から売上原価を引いたものが売上総利益(一般的に粗利と呼ばれる)ものになります。 粗利には事業維持のための一般管理費や営業活動費が含まれておらず、サービスそのものの純粋な収益性を判断する重要指標として利用されます。
例えば全体の利益が赤字になっていても、粗利が黒字かつ売上高が成長していればサービス自体の収益力としては健全と判断され、投資家や金融機関からの融資を受けやすくなります。
特にスタートアップでは、Jカーブと呼ばれるように短期的には赤字を出しながらも最終的には急角度で成長していく売上モデルを目指すことが一般的です。
販売費および一般管理費 (販管費、Selling, General and Administrative expenses: SG&A)
販売費および一般管理費(一般的に販管費と呼ばれる)は、事業活動の維持に必要な費用や製品の営業・販促に必要な費用をまとめたものです。
日本で一般的に使われるJ-GAAPやアメリカのUS-GAAPなどの会計基準では、これらの費用は販売費および一般管理費として一つのカテゴリにまとめられることが多いですが、国際財務報告基準(International Financial Reporting Standards: IFRS)ではこれらを性質別(人件費、減価償却費、原材料費等)または機能別(販売費、一般管理費等)で分類することが義務付けられるようになりました。
昨今ではIFRS対応のため、販売費および一般管理費を更に販売・マーケティング費(Sales & Markething: S&M)や一般管理費 General and Administrative: G&A)、研究開発費(Research & Development: R&D)のように分類する企業も増えています。
販売・マーケティング費 (Sales & Marketing expenses: S&M)
COGSが現在のサービスを提供・維持する目的なのに対して、S&MやR&Dコストは未来の売上高成長や利益率改善に対する投資です。 そのため、経営層や投資家に合理的な説明ができる限り(かつ財務状況が許す限り)赤字であっても投資するという判断が有りえます。
例えばSales&Marketingコストには営業の人件費や出張費、会食費、広告宣伝費等が含まれますが、これらは未来の売上獲得のための投資と考えることができます。
ソフトウェア開発者が直接的に営業やマーケティングの活動に関わることはあまり多くないかもしれませんが、MA(Marketing Automation)ツールの導入による人件費の抑制やEFO(Entry Form Optimization)によるコンバージョンレートの改善等、間接的にこれらのコスト効率に関わる機会は多くありえます。
研究開発費 (Research & Development expenses: R&D)
R&Dには短期の売上向上や利益率向上のための投資や、中長期の基礎研究開発的な投資が含まれます。 例えば、向こう半年から1年程度の機能提供ロードマップに含まれる開発は短期のR&D、顧客への提供価値があるかわからないものや技術的な実現方法自体がわからないものに対する開発は中長期のR&Dと考えることができます。
COGSやS&Mに含まれない開発はほぼR&Dコストなので具体例は枚挙にいとまがありませんが、例えば以下のようなものが挙げられます。
- 新機能の開発
- UIの大規模なアップデート
- メンテナンス性向上のためのリファクタリング
- テスト自動化
- 各種機械学習のPoC
- IaC導入
S&MやR&D費用の基本的な考え方は、売上総利益(粗利)から一般管理費(G&A)を引いた残りの利益を事業に再投資し、未来の売上や利益を伸ばすことです。 中長期のR&Dを行う前提としては、ある程度の財務健全性が担保されていることや、事業計画とアラインしていることが求められます。
一般管理費 (General and Administrative expenses: G&A)
COGSにもS&MにもR&Dにも含まれない、会社運営に必要な業務はG&Aに分類されます。 例えば人事評価、全社会議への出席、各種トレーニングの受講、月次の経費精算等にかかる人件費や有給休暇、看護・介護休暇等はG&Aに含まれるのが一般的です。
G&Aコストは多すぎないことが望ましいですが、例えばチームビルディングやリーダー・マネージャーのトレーニング等が今後のチームの生産性に大きく影響すると判断した場合は、短期的にG&Aコストを投資するという戦略が考えられます。
営業利益 (Operating profit)
売上総利益からSG&A(販管費)を引いたものが営業利益です。
ここから営業外損益や特別損益、法人税を抜いたものが当期純利益となり、その会計期の会社全体の利益になります。 営業外損益には為替差損/差益や有価証券売却益、利息の支払いなどが含まれますが、一旦は営業利益まで意識しておいてもらえればOKです。
Jカーブで一定の成長期に入ったスタートアップや一般的な企業は、売上高や営業利益率を如何に高めるかが基本的なゲームになります。
ソフトウェア開発とPL
PLの構造について理解を深めたところで、改めてソフトウェア開発者が意識するべきポイントを考えてみたいと思います。
事業インパクト
よく聞く言葉ではありますが、事業インパクトとは何でしょう。定性的なもの、定量的なもの様々が考えられますが、わかりやすい表現の一つとしてPLの項目が利用できます。
例えばプロダクトや機能の開発によってどのくらいの売上が増加したかは、収益性分析によってある程度定量化することが可能です。 CSやOpsの作業効率の改善はCOGSや粗利率として表現することができます。
もちろんPL以外にもKPIを使った定量表現や、セキュリティの強度や採用優位性等の定性的な表現もありえますが、経営者・事業責任者と会話するうえで一番シンプルで説得力が高いのは会計の用語を使うことだと僕は考えています。*1 もしも採用強化や離職率の低減といったインパクトを盛り込みたい場合は、採用にかかる成功報酬や人件費、オンボーディングコスト、関係構築コストといったものをG&Aコスト観点で織り込むといった方法も一つのアイデアだと思います。
また、事業インパクトとしては、これらのPL上の項目に対してどの程度の割合で影響があるかも重要なポイントです。 例えば「インフラ構成の改善によって500万円/月の改善が見込める」は効果の大きな改善だと思いますが、これがCOGSの1%なのか10%なのかでもインパクトは変わりますし、事業として人件費COGSが課題なのか、システムCOGSが課題なのかによっても大きく優先度判断が変わり得ます。 経営者や事業責任者と事業課題の認識を揃えることで、より大きな事業インパクトのある施策を生み出しやすくなるのではないかと思います。
(それはそれとしてコスト改善はやれるならやった方が良いですが)
投資対効果 (Return on Investment: ROI)
他にも、施策のインパクトを語る上で重要なキーワードとしてROIがあります。 ROIはその名の通り、「投資」に対してどれだけの「リターン(利益)」があったかを表す用語です。最終的な結果指標は利益ですが、利益が出るロジックとしては「COGSが減る」「R&Dコストが減る」等が考えられます。
例えば最近であればChatGPTやCopilotによって設計やコーディング、テストにかかる工数が削減され、同じものを作った場合でもAIツールを利用した方が開発工数が短くなることが期待できます。 これはつまり、ChatGPTやCopilotへの投資によってR&Dコストが低く抑えられるようになったと表現できます。*2
具体的にどのくらいの効果が得られるかはPoCやベンチマーク、リサーチ会社のレポート活用等で工夫する必要がありますが、このように「いくらの投資で」「どういった見返りが得られるのか」をPLベースで説明できると、より説得力のある提案ができるようになるのではないかと思います。
インフラコスト
突然ですが、Development環境やStaging環境のインフラコストはCOGSとR&Dどちらに計上するのが正しいでしょうか？
また、A事業部とB事業部と横断プラットフォーム部がある場合のインフラコストはそれぞれどの事業部のコストとして計上するのが正しいでしょうか？
正解はどれも「会社の方針による」だと思います。
恐らくインフラ寄りの方であれば、「今月の予算実績を集計するために、各事業(または各サービス)ごとのインフラコストを出してほしい」というお願いをされたことがあるのではないでしょうか。
会社や事業のフェイズによっては、それぞれの事業単位で収益の健全性を見たいという要求があります。そのため、インフラ構成の要件として環境やサービス単位でコスト集計ができることが重要です。
同一k8sクラスタで動いているサービスや、プラットフォームサービスのコスト等、どうしてもルールベースで按分するしかないものもありますが、GCPプロジェクトやAWSアカウントの分離、タグやラベルを活用することで、サービスや環境に基づいた柔軟なコスト集計を実現することができます。
会計要求に合わせてインフラ構成を後から変更するのは基本的に現実的ではないので、インフラの初期構築時にはぜひこういった会計処理のことを意識していただけると、会計エンジニアが泣いて喜びます。
単純にROIが説明しづらい施策はどうすればいいの？
施策の効果説明としてPLを用いたアプローチをいくつかご紹介しましたが、依然としてソフトウェア開発にはPLだけでは効果が表現しづらい技術的チャレンジが存在します。 例えば「新しいプログラミング言語の導入」や「レガシーシステムのリアーキテクチャ」といったものが最たる例ではないでしょうか。
特に大きな改修を必要とするものは開発期間も長く、投資と回収が複数の会計期をまたがることになる上、成功の不確実性も高いです。 このような施策をうまく進めるためには、ROIの説明ももちろんですが、コミットメントや信頼といったものが大切です。本当にその施策が事業価値に繋がると信じるのであれば、丁寧にステークホルダーと会話を続けながら課題の言語化や実現方法の模索を進めることが、結果として近道になるのではないかと思います。
まとめ
少し長くなりましたが、PL上の項目の意味合いとソフトウェア開発の関係について、少しでも理解を深めていただけたら幸いです。
実際の現場で、KPIベースで話すべきか、PLベースで話すべきか、ミッションやバリューベースで話すべきかは組織のフェイズ、財務状況、ステークホルダーの好み、会社の文化によってそれぞれ異なると思いますが、PLをベースに会話できることはソフトウェア開発者としても一つの重要な武器になるのではないかと思います。 今後もしも上長やステークホルダーとの議論が噛み合わないと思ったときは、まず事業上の課題の認識のすり合わせや問題提起から始めてみるのが良いのではないでしょうか。
We are Hiring
CADDiは製造業全体を前進させ、世の中を変えていくためにもグローバルな企業を目指しています。 そのため、グローバルで共に戦える仲間を随時募集しています。
ご興味がある方はぜひ下記リンクからご応募ください。
