業務でのSaaS利用が加速する中、パッケージ型のソフトウェアが主流であった時代と比べ、現在の開発者体験やソフトウェアを提供するビジネスにはどのような違いがあるのでしょうか。
本記事では『Developer eXperience Day 2024』（主催：日本CTO協会）における小笹佑京氏・藤倉成太氏によるセッション「The Shift to SaaS for All：ビジネスとテクノロジーの融合による開発者体験の変容」の内容をお届けします。
小笹 佑京氏（右）
株式会社アンチパターン
CEO
立教大学卒業後、2014年に株式会社イノベーションに入社し、マーケティングオートメーションツール開発業務に従事。2015年には全社MVPを受賞。2017年よりマネージャー職に就任し、2018年には開発本部長を歴任。2019年7月に株式会社アンチパターンを創業。
藤倉 成太氏（左）
日本CTO協会 理事
キャディ株式会社
DrawerVP of Engineering
株式会社オージス総研でシリコンバレーに赴任し、現地ベンチャー企業との共同開発事業に携わる。帰国後、金沢工業大学大学院工学研究科知的創造システム専攻を修了。2009年にSansan株式会社に入社し、2019年執行役員 CTOに就任。Sansan Global Development Center, Inc.のDirector/CTOとして海外開発体制を強化した。2024年キャディ株式会社に入社し、Drawer VP of Engineering に就任。
目次
SaaSus Platformで実現できること
小笹：私は株式会社アンチパターンのCEO小笹佑京と申します。BtoBのSaaS製品のエンジニアとしてキャリアをスタートし、その後マネージャー職などを経て、現在は株式会社アンチパターンを経営しています。本日はよろしくお願いします。
藤倉：日本CTO協会の理事を務め、普段はキャディ株式会社にて製造業向けVertical BtoB SaaSのビジネスに携わっている藤倉成太です。本セッションでは、Horizontal・Verticalなどいくつかの対比が出てくると思います。以前はHorizontalなBtoB SaaSの会社にも在籍していたため、その比較や私自身が感じることなどお話しいたします。よろしくお願いします。
小笹：セッションに入る前に、我々がSaaSに関するセッションを行う背景も含め、株式会社アンチパターンのご紹介をします。
我々は「日本のソフトウェアエンジニアを憧れの職業へ」という理念を掲げる、創業6期目のスタートアップです。いろいろなサービスを提供していますが、そのうちの1つがSaaSus Platformという、プロダクト作りを支援するプロダクトです。氷山の図で説明すると、下の部分がどのようなSaaSを作る場合でも必要な機能群を表しています。
これらは、ないとSaaSを運用できない重要な機能です。しかし、直接ユーザー様に価値を提供する部分ではないため、非競争領域となります。この部分は、各SaaS提供事業者が自前で作るのではなく、我々のSaaSus Platformを使うことで省力化できます。それによって、氷山の上の部分＝直接ユーザー様に価値を提供する部分の開発に、各SaaS提供事業者がフォーカスできる状態を実現します。
我々自身、このようなプラットフォームの提供を通じて多くのBtoB SaaSに関わる中で、SaaSの可能性を感じています。
そのため、今回のセッションを通じて皆さまにSaaSの魅力をあらためてお伝えしたいですし、SaaSを使う・SaaSを作る場面での開発者体験がどのように変容していくのか、SaaS業界の大先輩である藤倉さんとの対談を通じて模索していきたい、そういったセッションです。
SaaSとは
小笹：まずSaaSとは何かについてあらためて解説します。
従来型のソフトウェアは、ユーザー企業の中で行われている業務プロセスに合わせて開発や機能拡張をしていました。しかしSaaSの登場で、業務のベストプラクティスや業界標準をソフトウェアとして提供し、ユーザー企業側が業務プロセスをSaaSに合わせるという変化が起こりはじめました。
単純に法人向けのソフトウェアをSaaSと呼ぶのではなく、特定の業務プロセスのナレッジの集合・ベストプラクティス集を、ここではSaaSと定義します。
そして、人事労務や会計など業界を問わず横断して行われる営みに対して提供されるのがHorizontal（水平）SaaSです。それに対して、業界特化の業務プロセスに対して価値を提供するものはVertical（垂直）SaaSといいます。
この業界という概念はSaaSを分類する指標のひとつで、業界標準を作っていろいろな業務プロセスを企業横断で変えていこう、という動きはどの業界・業務でも発生しています。
そのため、現在多くのアプリケーションがSaaSに移行しつつあり、SaaSが増えている時代となっています。
こうした中で、SaaSとしてソフトウェアを提供する＝SaaS提供事業者になる場合にはさまざまな変化があります。パッケージソフトウェアはユーザー企業側が運用を行うのに対し、SaaS提供事業者は運用も行わなければならず、マルチテナント（テナント＝1契約単位）を前提としたアーキテクティングも必要になります。
またSaaS提供事業者にとっては、対象業界の標準機能を提供することで多くの企業に利用してもらい、顧客のビジネスを効率的にスケールさせるという考え方が重要です。
このスケールを支える機能として、コントロールプレーンというものがあります。
こちらの図は、AWSが提唱しているSaaSのスプリットプレーンアーキテクチャです。
左側が顧客に直接価値を提供するコア機能＝アプリケーションプレーンです。これに対し、スケールを支える仕組みとしての機能群をコントロールプレーンと呼びます。こちらはSaaSの提供事業者用の管理画面や料金プラン作成・請求など、どのBtoBサービスでも必要で、ないとスケールさせられない部分が該当します。
このコントロールプレーンという概念自体は啓蒙が進んでいるものの、理解度としてはまだまだ低いのが実態です。ビジネス的な側面でのSaaSの注目度は高く、市場は伸びています。しかし、技術的な側面はまだまだ認知・啓蒙が必要です。SaaSを実装し提供するうえでは、プロダクトの特性や市場、事業の成長度合いなどを考慮してアーキテクチャを考える必要があります。つまり、ビジネスとエンジニアリング双方の観点が必要となり、この点もSaaSの面白さ・難しさです。
こうしたSaaSの魅力について、ここからは私の観点だけではなく藤倉さんのお話も伺いながら考えていきたいと思います。
長く法人向けソフトウェア業界にいる身としてSaaSについて思うこと
小笹：藤倉さんは長く法人向けソフトウェアに関わってこられましたが、SaaSに関してどのような将来性を感じていますか？
藤倉：前職では2009年に入社して2023年まで在籍していたので、約15年になります。前職と現職ではVertical・Horizontalの違いはあれど同じBtoB向けのSaaSで、そこでの15年間では市場の変化が一番大きいと感じています。
とくにお客様から見たSaaS導入のハードルがあまりにも違いますね。15年前はまず先進的な企業がSaaSを導入し、その後マジョリティ層のお客様にタッチするのですが、そこではなかなか意思決定が進みませんでした。
今だとお客様のコアコンピタンスでないところはSaaSプロバイダーに任せて事業を伸ばすという考え方は一般的になっており、ここは15年で変化したところだと考えています。
小笹：SaaSの利用に関して、業界全体でリテラシーが上がったということでしょうか？
藤倉：そうだと思います。SaaSの課金体系はいわゆるサブスクリプション型が一般的ですが、パッケージソフトの場合は買い切りがメインでした。
今は、たとえばSaaSを長期間契約するのとパッケージの購入とでどちらが安いか、といった議論はあまりしなくてよくなっているようです。どういう考え方でこのお金を使っているのか、というリテラシーは変化していると思われます。
小笹：逆に、SaaSを長く作ってこられた中で、従来の開発者体験と今とで変わったことはありますか？
藤倉：すごくありますよね。15年前は基本的にすべてオンプレでした。データセンターを借りてサーバをラッキングして、ネットワーク設計してケーブリングして、などをやっていましたが、今はそういう機会も減っています。
また、ポピュラーな考え方や設計パターンなど、先達の知恵や失敗・学びはたくさんありますし、共通コンポーネントもたくさんあります。エンジニアはある意味楽になりましたし、楽をして稼いだこの時間をドメイン理解に使おう、といった流れになっているのは大きく変化したところかと思います。
小笹：これまでHorizontal SaaSに携わってこられましたが、転職でVertical SaaSの業界に飛び込んだ背景など教えていただけますか？
藤倉：HorizontalをやっていたからVerticalに行こう、といった意思決定ではありませんでした。
前職も15年やっていて非常に面白かったですし、やらなければならないこともたくさん残っていました。しかし自分のキャリアを考えたときに、新しい場所でゼロから挑戦してみたいという思いがあり、たまたまそれがVerticalだった、ということです。
小笹：昨日、キャディ社が製造業AIデータプラットフォームに事業を転換する、というリリースが出ていました。Drawerという製品には中心的に関わられていると思いますが、あらためてSaaSにどのようなポテンシャルを感じているのか、どのような背景で事業統合という経営的な意思決定になったのか、伺えますか？
藤倉：我々のマニュファクチュアリング事業では、内部的にはソフトウェアを使っているものの、サービスとしてはあくまでの調達のご支援でした。この調達の事業もしっかりと伸びてはいましたが、調達は裏で人が動かなければなりませんし、モノも我々が動かさなければなりません。
我々は製造業全体をイノベーティブな何かで変えていきたい、世の中を前に進めていきたいと考えていたのですが、本当に世の中が変わったという実感が得られるには社員が何万人要る、何十年かかる、といったスピード感になってしまうんですね。
ソフトウェアでやれることを増やしていったほうがスピードも速いし、レバレッジがかかるだろうと考えたのが決定の背景です。
小笹：伸びている事業をいったん中止してソフトウェアにあらためてBETする、というのは経営的にも大きな意思決定だったと思いますが、藤倉さんはどのような形で携わっていたのでしょうか？
藤倉：どのような形で統合すべきかについては一定の議論がありました。私がCADDiに入ったときには両方の事業があり、マニュファクチュアリング・調達の事業も魅力の1つだと思っていたので、統合後の姿がどうあるべきかは私なりにも考えていましたね。
マニュファクチュアリング事業において、自分たちの困りごとはテクノロジーを使って自分たちで解決していましたし、だからこそできていることもたくさんありました。マニュファクチュアリングがあったからこその今のDrawerであり、まだローンチして2年しか経っていませんが、初速的にはなかなか良いスピードで成長しています。
小笹：自社の強みがどこにあるのか、そこをソフトウェアとして提供したらより成長が見込めるのではないか、という選択をされていると理解しました。ありがとうございます。
APIファーストなプロダクトマネジメント
小笹：経済産業省が出しているDX実践手引書からの引用ですが、SaaSに限らず一般的にプロダクト開発においては、何を自社で作るべきかを検討するのが議論のスタートになります。こちらの図は、技術的に競争領域なのか・事業的に競争領域なのかの二軸でマッピングをするものです。この図において、すべての領域を自分たちでカバーするのは困難です。
技術的にも事業的にも競争領域、という部分にフォーカスすべきですし、技術的にも事業的にも競争領域でないところはSaaSを使うことが重要だと考えています。その理由を、プロダクトの成長のフェーズで考えてみましょう。
プロダクトを企画して、検証のために開発して、事業を検証していく。この流れの中ではさまざまな変化があります。たとえばお客様からの要求や、Horizontalの場合は法律改正など、Verticalの場合も業界ルールなどが変化の要素として考えられます。こうした変化が絶えず求められるのがSaaSビジネスの難しいところです。
将来の運用まで考えたときに、競争領域でない部分まで変化に追従し続けるのは大変です。
そのため、自社で作るスコープを限定し、自分たちエンジニアが作るべき箇所にフォーカスすることが非常に重要です。
SaaS時代における開発者体験の変容
小笹：このセッションのラストとして、SaaSを使うもしくは作る際の開発者体験の変容についてお話しします。
SaaSとは業界内でのスケーラビリティを維持してビジネスを拡大していくためのものという定義をしたうえで、自前で作る領域をしっかり絞っていくことが重要、というお話をここまでしてきました。
そして、現代はエンジニア自体がドメインを深く理解することの必要性が増している、そのような時代だと考えています。ドメインに深く入っていく際の開発者体験は、道具を作っているときの感覚とは違う何かがあるはずで、長くBtoBの業界にいらっしゃる藤倉さんから見た開発者体験の変容について伺いたいです。
藤倉：ソフトウェア業界に入ったのが1999年なので、当時はエンジニアの環境というと「良いマシンが使えるか」「エディターは何を使うか」など、開発に閉じた範囲で開発者体験を語れたように思います。
一方、ドメインを深く理解するためには、営業が何を売りにしているか・CSに寄せられる声などを通じてお客様のビジネスを理解する必要があります。つまり、開発者体験は開発だけでは閉じなくなってきていると感じています。
小笹：他のチームと一緒に連携しながらお客様の像を理解するパターンもあれば、開発者自身がお客様のところに行くパターンもあると思っています。キャディさんの中ではどういった取り組みをされているのでしょうか？
藤倉：とくにVerticalでは特定の業界が対象なので、Horizontalに比べるとマーケットのサイズは狭いです。しかし、そのぶん深いんですよね。理解しなければならない総量はHorizontalもVerticalも変わらないでしょう。
製造業ですと、メーカーさんの設計部門の方・調達部門の方・品管を管理されている方が日々何に気をつけているのか。加工会社さんがどのような加工機械を使っていて、どのような加工の方法だとコストが安く済むのか。こういったことまで知らないと、ものが作れなかったりします。
当社の場合は製造業出身者がそれなりの割合いるので、彼らが「前の会社ではこんな苦労をしていた」など教えてくれることが多いです。
小笹：なるほど、社内にドメインエキスパートの方がいて、社内でのコミュニケーションによってエンジニアにもナレッジが入ってくる、ということですね。
藤倉：はい。事業の全員が集まる会議では、まさにドメインエキスパートが前職での調達やコストコントロールのやり方、よくある課題などを教えてくれています。
小笹：そういった形で開発者も徐々にドメイン知識を得ていくのだと思いますが、これは藤倉さんが以前からおっしゃっている「事業に資するコードを書こう」というお話に通じるものでしょうか？
藤倉：そう思います。我々がソースコードを書いてソフトウェアを提供するのであれば、当然お客様には喜んでもらいたいと考えます。そして、会社のミッション達成に近づくためには、その手段として事業を大きくしていかなければならないはずです。それに資する設計をし、それに資するコードを書きましょう、と思っていますね。
小笹：それをメッセージとして伝える以外に、実現のための仕組みや評価制度など、用意しているものはありますか？
藤倉：エンジニアとして行う設計や、ある部分を柔軟にするか柔軟性を持たせないかなどの意思決定は、最終的には技術的に正しいかどうかではなくビジネスとして正しいかどうかだと思っています。
事業に貢献する設計ができる人は正しい設計ができる人であって、それができない人はまだスキルが追いついていないんですね。なので、事業自体の成果の良し悪しで測ってもいいのではないか、と考えています。
小笹：なるほど、ありがとうございます。
早いものでここでお時間となってしまいました。今回お伝えしたかったことは、ドメインに入っていく際に開発者体験がどのように変わっていくのか、変わっていっているのかでした。
藤倉さんのお話からも、ドメインに深く入り込んでいく、お客様の価値に直結するプロダクト作りにエンジニア自身が積極的に取り組んでいく姿勢がより求められる時代になってきていると言えると思います。
そしてそれをソフトウェアの形で表現しているのがSaaSだということをご理解いただけたかなと思っています。
本セッションを通じてSaaSの魅力や面白さ・難しさがお伝えできていればうれしいです。
取材後記：ドメインに深く入り、開発者自ら開発者体験を向上させる大切さ
今回とくに印象深かったのは、現在の開発者体験は開発に閉じておらず、ドメイン・顧客のビジネスへの理解も関連するというお話でした。事業に資する設計をし、事業に資するコードを書く。そのためにはドメインに深く入り、さまざまな条件を加味しながらアーキテクティングを行うなどの技術的にチャレンジングな活動が求められます。小笹氏がSaaSの難しさでもあり魅力でもあると表現していましたが、開発者体験は会社から与えられる環境ではなく、自らチャレンジをすることで得られるやりがいだと捉えることが重要だと感じました。
（撮影／文：伊藤由貴）
