【開発生産性カンファレンス 2025】『レベル３』の開発生産性を実現するための技術経営とSaaSファースト戦略

SaaS is Dead(？)な生成AI時代

「SaaS is Dead？」という議論が最近メディアでも取り上げられ、各企業のIR資料にも登場するようになってきました。私自身、B2B SaaS歴が10年以上ありますが、この業界に身を置く者として、今起きている変化を正しく理解し、適切に対応していく必要があると感じています。

SaaSビジネスの多くはシートベース、つまりユーザー数課金モデルを採用しています。特にアメリカにおいてはSaaSの普及率が非常に高くなってしまい、1人当たりが使っているSaaSの数が100個を超えるといった例も出てきています。

しかし、当然のことながら労働人口にはキャップがあります。ユーザー数だけで課金をしていくモデルだと、すぐにビジネスモデル上の収益限界を迎えやすいという構造的な問題があるのです。

実際にアメリカでは、この浸透率・普及率が高まったことで、SaaS事業自体の発展性に疑問視する声が高まっていました。SaaS自体が市場で飽和をしていき、「シート数を増やして売上を拡大する」というモデル自体に限界が来るのではないか、というのがそもそもの前提にあったわけです。

そんな中で登場したのが、生成AI、特にコーディング系のAIエージェントです。

AIエージェントとは、従来のチャットで自動的にユーザーのインプットに対してアウトプットを提供するものとは違って、目標や目的を設定すると、ツールやデータベースと接続をしながら、タスクを自律的に実行してくれるコンセプトです。

このAIエージェントの登場により、開発者側には開発コストの削減と開発スピードの加速が起きています。そして、これが重要な点ですが、「SaaSを利用せずに自前でソフトウェアを作った方が安く済むよね」という考え方が出てきているのです。



一方、SaaS利用者側も大きく変わってきています。AIによって自然言語でソフトウェアを操作できるようになり、場合によってはSaaS自体にログインしなくても業務が遂行できるようになります。これまでの「操作慣れ」による「このソフトじゃないとこの業務は無理だよ」といったスティッキネスが失われているということです。

ここで私が非常に懸念しているのは、AIの発展によってコストの削減とスピードが加速すると、コードベースが非常に速い速度で肥大化するという状態になることです。

こうした状況によって自前で作りやすくなることで、いわゆる「よくない自前主義」が加速してしまうのではないかと懸念しています。つまり、ビルドトラップにハマってしまって、顧客の価値に直結しない機能が氾濫してしまうリスクがあるということです。

さらに重要な点は、作る部分は確かにAIによって加速するでしょうが、運用していくことがソフトウェアにおいて重要であることは変わりません。生成AIの影響は開発フェーズに集中しており、それはプロダクト全体の10-15%に過ぎないと言われています。運用軽視でプロダクト自体が肥大化していくリスクがあります。

こういったことに向き合っていく際に、開発生産性というものの捉え方を、開発量のような視点で捉えている段階においては、生成AIによってかなり状況が変わってしまっていると思います。

一エンジニア自身が、お客様の目線や経営の目線・視点を捉えて業務に取り組んでいく、ある種のクラフツマンシップが求められる時代によりなっているのではないかと考えています。つまり、生成AIによって、「開発生産性」がより経営の視点である『レベル３』で捉える重要性が高まっているのです。

『レベル３』の開発生産性について

「レベル3」とは何かについて、皆さんの認識を揃えるために改めて整理したいと思います。

生産性は「アウトプット ÷ インプット」で表されます。これは広木大地さんの分類ですが、アウトプットを3段階で分けると以下のようになります。

レベル1：仕事量の生産性は、ソースコードやプルリクエストといった量で測られるものです。決まった時間でどの量の仕事を終えることができたかという観点になります。

レベル2：期待付加価値の生産性は、決まった時間で、どのくらいの価値が期待される仕事ができたかという観点です。

レベル3：実現付加価値の生産性は、事業数字として表現され、事業部門全体に係る生産性の視点になります。



レベル1は生産した時点で数値を把握できますが、レベル3ではリリース後にお客様の反応を得たり事業数字が付いてくるまでにタイムラグが発生します。そのため、レベル1の生産量と組み合わせて事業の期待効果を測り、タイムラグを軽減するのがレベル2の役割です。

レベル3は「実現付加価値の生産性」と定義され、売上やKPIなど実際のサービスに対しての貢献を評価する尺度になります。

NSM（North Star Metrics）やKPIの例として、動画視聴サービスでは「総動画視聴時間」、音楽サービスでは「1ユーザーあたりの週間音楽視聴時間」、チャットサービスでは「チームあたりの週次アクティブユーザー数」があります。

売上・総利益の観点では、SaaSなら「MRR」「ARR」「LTV」、プラットフォームビジネスなら「GMV」「テイクレート」、広告モデルなら「ARPU」といった指標で測定されます。

エンジニアが今後意識すべき重要な観点として、財務的な視点があります。

企業の売上から売上総利益を算出するには、売上原価（エンジニアの人件費、インフラ費など売上を出すために必須の原価）を差し引きます。さらに販売管理費（営業人件費、業務効率化のための費用など）を差し引いたものが営業利益となります。

上場企業では、作業時間の記録と原価・販管費の仕分けが求められることがありますが、これは勘定科目が異なり事業数字として現れる影響が違うためです。

ソフトウェアの会計処理は、市場販売目的、自社利用、受注制作の3種類に区分され、それぞれ処理方法が異なります。

特に重要なのは、研究開発費として当期に費用計上するか、固定資産として計上するかの判断です。研究開発費は使用した年に全額計上されますが、固定資産の場合は3年で償却されます。つまり、リリースされたソフトウェアは3年間で償却される会計処理が行われます。


処理を誤った場合の影響は深刻です。例えば、1億円の資産計上すべき開発費を費用処理してしまうと、法人税の過少申告による追徴課税、財務指標の歪みによる銀行融資・投資判断への悪影響、内部統制上の問題が発生する可能性があります。

企業経営において重要な指標は、売上向上、コスト削減、リスク軽減の3つです。

エンジニアの関わり方として、売上向上では売上に資するプロダクト開発、コスト削減では効率的な開発環境への投資、リスク軽減ではセキュリティ対策や信頼性向上が求められます。特に生成AIは、コスト削減に直接的に寄与しています。

生成AIによって少人数でも量を担保できるようになりました。従来は人数を増やしてソフトウェア開発を行っていましたが、人数増加はコミュニケーションチャネル数の莫大な増加を招きます。

これまでの対策として、チームを分割してコミュニケーションパスを制限する方法がありましたが、今後は「小さなチーム、大きな仕事」という経営アプローチがより現実的になると考えています。

AIを使った生産性向上はスタンダードな動きですが、重要なのはAI自体が業務を代替するのではなく、AIを使う人がAIを使わない人を代替していくという点です。

生成AI時代において良くない自前主義への対応が求められる中、レベル3である「実現付加価値の生産性」への注目が重要です。日々の活動が財務諸表のどこに紐付くかを理解することで、レベル3の視点に近づくことができます。

変化の激しい時代をサバイブするためには、事業目線や経営者目線のマインドとスキルセットが必要であり、経営者視点とクラフツマンシップが肝要と考えています。

技術経営とSaaSファースト

経営者視点とクラフツマンシップが重要と考えた時に、技術経営とSaaSファーストがどのように関連するかについて説明します。

我々は長くB2B SaaSを扱っていますが、B2B SaaSを単純に法人向けのソフトウェアとして捉えているわけではありません。

SaaSとは「ある業務に対するベストプラクティスを提供するビジネスおよびソフトウェアデリバリーのモデル」です。従来の業務をソフトウェアで個社ごとに表現するのではなく、「これが業務のベストプラクティスです。これに合わせて業務を変えてください」という、ある種のパワーを持ったのがSaaSの魅力だと考えています。

これは「Fit to Standard」という考え方で、SaaSに合わせて業務プロセスを変革することに価値があるのです。

プロダクト開発における一般的なフレームワークとして、技術的に競争領域なのか、事業的に競争領域なのかという四象限で何を自前で作るべきかを検討する必要があります。

全部を自前で作るのは現実的ではありません。事業的にも技術的にも競争領域である部分を自前で表現し、そうでない部分は共通プラットフォーム化、技術コンポーネントの導入、SaaSの利用を行う。フォーカスする領域を定めた技術戦略が重要です。



ハードウェアでは理解されやすい考え方です。iPhoneもカメラセンサーはソニー、通信チップはクアルコムと調達している部分がある一方で、チップ設計やOS・ソフトウェアは自前で開発しています。しかし、ソフトウェアになると急に自前で作りたくなる傾向があり、ソフトウェアエンジニア自身の自制が重要だと考えています。

ソフトウェア事業では、プロダクト企画期から開発期、検証期、運用開始期、成長期という流れがあります。お客様の声によるソフトウェアの変化だけでなく、法律の変更、エコシステムの変化など、好むと好まざるとに関わらず変化が絶えず求められます。

自前で作るということは、開発時点の要求を満たせれば良いわけではなく、変化に対して対応し続ける覚悟があるかが問われるということです。

SaaS提供に必要な機能群は多岐に渡ります。コア機能群（顧客提供価値の中心）以外に、テナント管理、認証・認可、SaaS提供事業者向け管理画面、監視、分析、請求・計測など多くの機能が必要です。

SaaSファーストでは、すでに世にある機能は外部サービスを活用し、コア機能に集中投資することで、結果的にコア機能の集中開発・集中投資ができるようになります。



Dropbox社の開発投資4分類が参考になります。システム維持管理（Keep the Lights On）、新機能開発（Build New Stuff）、既存機能改善（Improve Existing Stuff）、生産性向上（Increase Your Productivity）の4つです。

事業状況によって投資比率は変わります。皆さんのプロダクトの状況、事業の状況も踏まえて、自分たちはどのフェーズにいるのかをしっかり捉えていくことが重要です。PMF前の改善段階、PMF後の顧客増大期、顧客のLTV最大化（顧客満足度・信頼性・生産性）段階といったように、それぞれのフェーズに応じて投資の重点が変わっていくからです。

フィリップ・クルーシュテンのバックログ4象限では、見える・見えない、ポジティブな価値・ネガティブな価値で分類されます。見える領域の新機能や欠陥は判断しやすいですが、見えない領域のアーキテクチャや技術的負債は、エンジニアから説明が必要な領域。開発者に責任が求められる領域です。



ソフトウェア企業においてレベル3の開発生産性を実現するためには、エンジニア一人ひとりの経営感覚とクラフツマンシップが重要です。

Whyに対する説明責任として、見えない領域に関する価値の説明、顧客価値との紐付けが求められます。Howに対する説明・結果責任として、価値と見合う実装方針の説明（SaaSファーストで考える）とベストを尽くした実装が必要です。

アンチパターン社のアプローチ

ここまでお話ししてきた考え方を踏まえ、我々アンチパターン社がどのようなアプローチで課題に向き合っているかをご紹介します。

我々はB2B SaaSに長く向き合ってきた中で、自分たちもSaaSを作ってきましたし、お客様のSaaSも作ってきました。その中で、どのB2B SaaSにも共通で必要な機能群があり、なおかつそこが直接ユーザーに価値を与えるわけではない非競争領域であると捉え、その部分をSaaSとして提供することによって、SaaS提供事業者の方々が競争領域に投資できるようにするソフトウェアを開発しました。

それがSaaSus Platformというサービスです。基本コンセプトは「SaaS control plane as a Service」で、弊社がもつSaaS開発のナレッジと米国における最先端のトレンドを取り入れ、SaaS開発・運用・販売を支援するSaaSを開発・提供しています。



オライリージャパンから今年1月にリリースされた「マルチテナントSaaSアーキテクチャの構築」という本で、Tod Goldingさんが書かれているのですが、SaaSにおいてはアプリケーションプレーンとSaaSコントロールプレーンという概念があります。

アプリケーションプレーンは、お客様の価値に直結する機能群です。例えば会計系のソフトウェアで言えば、請求書を作って見積もり書を作って送付するといった部分の機能群のことです。

一方で、SaaSコントロールプレーンは、SaaSを運用するための機能群です。契約企業やテナントを管理したり、中にいるユーザーを管理したり、認証認可を提供したり、料金プランを作ってテナントと紐付け、実際のメータリングや請求を行うといった、本当にどのB2B SaaSにも共通で必要な部分です。

SaaSus Platformは、このSaaSコントロールプレーン自体を作成・提供し、管理画面とSDK/APIで提供しているというのが我々のプロダクトデザインです。

我々が生成AIの部分で非常に力を入れているのが、Smart API Gateway機能です。



多くのSaaS企業にサービスが出てくる中で、皆さんの業務を自動化しようという取り組みが非常に多く出てきていますが、日本のSaaSのほとんどがAPIを公開していないという現状があります。我々の独自調査によると、APIを公開している日本のSaaSは14.7%程度で、海外の製品だと86%程度がAPI公開している状況です。

つまり、AIがSaaSを使って業務を実行したり、ワークフローを作るということが、日本のSaaSにおいてはやりにくくなってしまっているという状態です。

そこで危機感を持って、我々はSmart API Gateway機能をリリースしています。APIも結局、どのテナントの誰がどんなロールとして呼び出してくれているのかという認可の部分が非常に重要になってくるので、その部分の情報をSaaSus Platformが持っているため、API公開自体を支援するという機能を出しています。

既存のファンクションにSDKをインポートしアノテーションを書いていただいて、SaaSus Platformの管理画面上にアップロードし、ボタンを押していくと、そのファンクションがAPIとして公開できるようになります。API公開自体が自前で作るよりも圧倒的に早く、1時間程度でその外部APIを公開するということが実現できています。

さらに最新の機能として、Smart MCP Server機能を開発しました。Smart API Gatewayを使って作成されたAPIを用いて、リモートMCP Serverを自動生成する機能です。

これにより、我々のSaaSus Platformを使って作っていただいたSaaS、もしくは我々のSaaSus Platformを使ってSaaS化されたパッケージソフトなども含めて、そういったものがいきなりAIエージェントやClaude Desktopなどで操作できるようになっています。



当社の理念は、「日本のソフトウェアエンジニアを憧れの職業へ」です。その実現に向けて、日本のソフトウェア市場をしっかり盛り上げていきたいと考えています。

先ほどの財務諸表の話も含めて、開発生産性向上に向き合っていくためには、一人ひとりのマインドセットが非常に強く求められる領域だと考えているので、今回発表させていただいた次第です。



アーカイブ動画も公開しております。こちらも併せてご覧ください。

※ご視聴には登録が必要です