プログラマブルな基盤を売るということ ~100年企業を目指して~
ポエムです！
長いのでまとめ
ローコード・ノーコードという言葉の括りは大きな意味をもたず、「プログラマブル」という表現が妥当
プログラマブルな基盤を作って売ることは、課題解決の幅を最大化する。複利でのアセット積み上げが可能で、ひいてはコンパウンド・スタートアップの地盤を作りやすい利点がある
この基盤は最初から覚悟を決めて作らないと、後追いで構築するのが難しいため商材としての希少性が高い
プログラマブルな基盤は、売り手に高い課題探索・抽象化能力と海外サービスへの強い関心が求められる
こうした基盤を事業として成長させることは、将来「Sell work, not software」の時代が来たとしても生き残る手立てを作る最良の手段になりうる
まとめても長いですね…
はじめに
皆さまこんにちは、株式会社ベースマキナの代表取締役社長を務めております高橋と申します。
現在弊社では、ソフトウェアエンジニアの皆様向けにヒューマンエラーを減らすローコード管理画面構築SaaS「ベースマキナ」を提供しています。
今回はローコード・開発者向けツールのマーケットに身を置く者として、ソフトウェアエンジニアの方以外にもぜひ「プログラマブルな基盤」を作ること・売ることの面白さを知ってほしいと思い、文章を書いております。
また、末尾におまけで今後ソフトウェアが商材ではなくなった時代が来ることも見越してどう備えるのが良いかの私見をまとめてみようと思います。
余談: 「プログラマブルな基盤」とは？
この記事のタイトルは「プログラマブル」という呼称を使っています。私達のサービス含め、ローコードという言葉よりも適切な表現だと思うため、あえてこちらを利用しています。
背景は別の拙作の記事でも書いたのですが、昨今のローコードツールは設定を一部コードで記述できる枠を超えて、「SDKを提供しつつ通常のソフトウェア開発と同様のコード表現を設定形式としてサポートし、その動作環境を提供する」というトレンドがあります。
要は自前より遥かに効率的な方法でコードを書いてもらいつつ、成果物がクラウド上で動作するためのフレームワークを提供している状態に近いということですね。このトレンドの結果、ローコードってほぼコード書いているじゃん、という状態になっています。
このように◯◯コードのローとかノーという形容詞は濃淡の問題で、より包括的に言い表すなら「プログラマブル」という言葉のほうがしっくりきます。こちらは先日セキュリティ事業を展開するFlatt Securityさんから下記の記事が公開され、同様の概念をプログラマブルと呼称されており、拝借しました。
大変にしっくりきたので、自分は最近なにかとプログラマブルというワードを使ってこのトレンドに言及するようにしています。
プログラマブルな基盤という商材
プログラマブルな基盤を商材として扱う際の妙味について考えてみたのですが、大きく３点思い当たります。
ソフトウェアを顧客に最適化できるため実現可能な提案の幅が広い
ユースケースを新たに開拓したときの複利の積み上がりが大きい
事業のコンパウンド化の地盤が強化できる
です。
1. ソフトウェアを顧客に最適化できるため実現可能な提案の幅が広い
管理画面SaaSと銘打っているからには、お客様ごとに異なるオペレーションをしていてもそれを表現できなければなりません。「内製するより良い」と思って頂くには、お客様が理想とするオペレーションを表現できるよう機能をご提案する必要があります。
その際にデータアクセスの機構やミドルウェアが十分汎用化できた状態で開発を進められると、お客様から一見エッヂケースと思えるようなご要件を頂いても汎用機能の組み合わせで大部分を表現し、残りは現場にフィットするようにUIをカスタマイズして最適解を提案できます。
要するにサーバーサイドに近いところは汎用で、フロントエンドに近いところはプログラマブルにしておけば、お客様が実現したい業務イメージに対して極力「ノー」と言わずに向き合うことができます。
2. ユースケースを新たに開拓したときの複利の積み上がりが大きい
SaaSの醍醐味として、お客様からのご要望を反映するとその分ほかのお客様にも還元されるという点があります。プログラマブルな基盤を持っていると、この複利的な効果が最大限発揮されると思っています。
お客様が用意したコード表現が動作する基盤は、表現したい業務の種類によって制限を受けずに汎用でなければなりません。ただその分、機能要望を反映して基盤を拡張したときにほぼ全てのお客様に対して機能追加の価値が還元されます。
これはまだベースマキナをお使いではない方々に向けても例外ではなく、例えば今のベースマキナのお客様と事業フェーズが違う方にご利用頂く際に、既存機能が活きないということがほとんどありません。ご要望を反映するとほぼ確実に複利が積み上がり、売る際に強気に出れる確率が上がり続けます。
3. 事業のコンパウンド化の地盤が強化できる
現時点での商材の価値というより少し先の話になりますが、プログラマブルな基盤を用意しておくことで事業の複数立ち上げの機動力を上げることもできます。
「コンパウンド・スタートアップ」という言葉があります。
単一プロダクトではなく、複数プロダクトを意図して開発を進めて、データを中心にプロダクト間の連携を強めてクロスセル/アップセル戦略を柔軟に取れるスタートアップのことです。詳しい解説は以下のような記事にお任せいたします。
このスキームでの勝負の仕方は、基盤構築により開発の生産性とアップセル/クロスセルが複利的に増加していくことで、競合優位性を強められる代わりに、開発資源の大量投下・精緻な設計力が求められるため、非常に難易度が高いと言われています。
が、弊社の場合は幸いこの基盤を、たとえ自社内で使う場合であっても問題ないように設計して作っているので、最初期からコンパウンド化の地盤を整えているといえます。現時点でベースマキナが持っている基盤の上にプロダクトを立ち上げるとしても割と地に足付いた戦略が取れると思います。
私自身はこの辺を意図して機能の抽象度を最大限上げる形での提供を社内で推奨してきましたし、弊社は開発基盤ゆえお客様の機密情報を極力持たないようにはしていますが、データを持ちうること、持つとしたらこの分野だろうという想定はアテがあります。
機能の抽象度が高いプログラマブルな基盤を商材とすることは、初期の構築フェーズを乗り越えたときの振れ幅が大きいため、将来に期待を持って良いと私個人は思います。
プログラマブルな商材の希少性
プログラマブルな基盤を特別扱いしているが、それって商材として用意するのが大変なのか？という疑問もあると思います。結論から言うと結構大変でして、これは開発工数が大変だからというより最初から覚悟を持って基盤を作るところから始めないと、作り上げられないからです。
「個別の業務を改善するSaaSを作って、共通機能を基盤化しよう」という流れを踏もうとする、いわゆるプラットフォーム構想もよく目にします。が、これは現実的には無理じゃないけど相当難しいと思っています。
お客様から予算を大きく頂いて特定部署・業務向けに局所解なSaaSを作り込んでいくと、いざ共通機能をまとめて汎用基盤を作りたくなったときに強制的に価値提供のスピードを鈍化させて工数を捻出するか、強力な基盤開発チームを組成する必要があります。
その場合、前者はお客様目線で見ると急に新機能追加のスピードが遅くなったとき許容できるかが怪しいですし、後者は共通基盤を組み上げている間に局所解が成長していくので開発がいたちごっこになってしまうリスクがあります。
弊社を始めとして、プログラマブルな基盤をつくるところから始まっている企業はプラットフォームの構想が単なる青写真で終わらないため、自信を持ってお薦めできます。
プログラマブルな基盤を売る難しさ
私自身ソフトウェアエンジニアの出自なので、偉そうに言えた口ではないのですし、こういうのは就活で偉そうに助言する人間みたいでむず痒いのですが……
プログラマブルな基盤は機能の抽象度と開発難易度が群を抜いて高いので、その分売り手として目立って求められる要素がいくつかある、という経験上のお話をさせていただきます。
他の業界・プロダクトと比較して、特に深く学習が必要だったり、求められる姿勢が具体的には４つあると感じています。
開発基盤の表現力への理解
ヒアリング力・仮説立案力
抽象化能力
常に海外と切磋琢磨する姿勢
1. 開発基盤の表現力への理解
端的に言えば「自分が売っているものはどんな価値を持つのか理解すること」でしかなく当たり前といえば当たり前にやるべきことなのですが、要求される技術リテラシーが顕著に高い点は特徴的です。もちろん、Vertical SaaSであれば業界ドメインの理解が求められるのと同じ話で、自分の持ち場で勉強が必要というのはどこも一緒かもしれません。
個人的にはセールスの矢面に立つ人が実装レベルの詳細まで把握する必要は必ずしも無いとは思います。
ただ、お客様の業務フローのうち、今表現できるものと機能追加が必要な線引きを認識しながら提案を持っていくには基盤が持つコンポーネントの役割やアーキテクチャへの理解が必要です。
そのため、エンジニアと二人三脚で開発基盤への理解を進めなくてはなりません。
2. ヒアリング力・仮説立案力
エンジニアの方が直接のお客様だったとして、その方々が開発したものを使うのは概ね非エンジニアの従業員の方です。また、各事業者様の事業ドメインも異なります。
そのため、決裁者の方に説明するためにエンジニアの方のその先にいる従業員の方や部署全体の業務課題を都度ヒアリングしたり、業界ごとにどういったオペレーションをエンドユーザー相手にしているか、一足飛びで仮説を立てなくてはなりません。
3. 抽象化能力
お客様から頂いたフィードバックや導入ブロッカーのご意見を持ち帰った際に、そのフィードバックが他の事業者様にも価値還元されていくために抽象化された機能に落とし込む必要があります。
これはどの分野のSaaSも変わらず持たなければならないスタンスですが、私達のようなプログラマブルな基盤を開発する会社では、もう１段階踏み込んで抽象化しなければなりません。というのも、下手にご要望の表層だけなぞって機能化すると早期に負債化するためです。
一方で逆に将来的に生じるあらゆる用途をカバーする機能を提案しようとしても（エンジニアの方なら誰しも心当たりがおありだと思いますが）、お客様にデリバリーするまでの時間が長引く上、複雑過ぎて誰も使わない機能ができがります。
もちろん機能要件の詳細を詰めるのは開発チームの役割ですが、お客様の期待値調整をするときに良き塩梅で成果物のイメージを共有しなければならず、ややアーキテクトに近い性質が求められます。
4. 常に海外に目を向ける姿勢
最後に、開発者向けツールを開発する会社全般に言えることですが海外のツール群の情報を常に追う必要があります。海外だから目線が高いとかの話ではなくて、単純に作るために技術者に体力が必要で、持続性のあるサービスは世界で見ても限られています。
新規サービスが立ち上がる数は多いため開発者向けツールの市場は盛り上がりやすく見えるかもしれません。しかしメンテナンスされて収益を上げて続けていく体力のある会社は観測範囲では正直少ないです。
先程ヒアリング力が求められると書きましたが、開発者向けツールはセキュリティ要件以外は法的に要件が決まっているわけではないため、地道にお客様の声を聞いて実装方針を考えて機能化する必要があります。
例えば、「〇〇のサービス・ストレージとの連携機能」のようにインテグレーション系の機能は潤沢なサービスが多いのですが、エンジニア以外も巻き込んだ業務で使えるのそれ？といったご意見に答えられる機能はめったに出てきません。
手前味噌ながら自信を持っている例として、弊社のサービスだとビジネスサイドの方が管理画面上で処理を繰り返し実行する一括実行の機能があります。
この機能では非エンジニアの方が作業しやすいよう、CSVをアップロードして各行ごとに処理を繰り返せるのですが、こうした現場ならではの課題にフィットする機能は実は海外のツールを見てもそうはありません。
また、お客様目線から見ても海外サービスとの比較検討されることが多くなるのがこのマーケットです。プログラマブルな基盤を提供する道を選ぶと必然的にエンジニアの方に向き合うことになりますが、エンジニアの方はドキュメント等で英語に触れる機会があるせいか、海外のサービスにもアクセスする方が多いです。
そうした方々に選んでいただくには、海外のサービスを参考にしつつも、単にタイムマシン経営で機能を持ってくるのではなく、彼らがまだ実装していない機能価値で勝てるように地道なヒアリングと実装を繰り返して商材を磨いていく必要があります。
…
というように、いくつか根気を持って学習したり持たなければならない姿勢はありますが、そんなものはどこの会社も大なり小なりあると思います。
その上で、弊社を始めとしてこの市場に属する企業は、課題探索や抽象化能力といった頭をウンウン唸らせる必要性が高く、海外サービスを見て戦略を考える機会が多いため、好奇心強めの方には結構楽しいと思いますので、お薦めです。
”ソフトウェアを売る”世界じゃなくなったときのために
最後に、かなり先だと思っているものの現実的にあり得る未来に備えて、プログラマブルな基盤を持つことは、時代の荒波を超える上で非常に重要だと考えているというお話をさせていただきます。
生成AIが浸透しつつある今私が感じるのは、ソフトウェアそのものはいつまで商材たりうるんだろうという漠然とした疑念です。
というのも、例えばサービス間のインテグレーションを前提としたZapier等のノーコードツールがやっていたことは概ねChatGPT等で代替できると思いますし、Vertical SaaSなら全部代替されないにしても、簡素な機能であればあるほどお客様が自力で解決できる幅が増えて、ソフトウェアをわざわざ開発・提供しなければならないレイヤーって当然薄くなるよなと思っています。
その上で、今後お客様から見たときにソフトウェア企業に求める提供価値は「データのモデリング能力」と「業務の”最適化”」だと思っています。
今後ソフトウェア企業に求められうる価値
まずデータモデリングの話です。導入すれば業界特有の法令に遵守できるソフトウェアを除き、アプリケーションの実装コストが下がってもツールを導入したくなるパターンで思い浮かぶのは、「データ構造を１から考えるコストが高い」、モデリングの能力が活きるものだと思います。
例えばERPが今まで取っていた業務領域も、個人的には開発難易度が高まる要素は、バルクでの膨大なデータ入力を捌く必要性を除けばアプリケーションレイヤーには集約されず、組織構造・ドメイン特有のデータの構造が複雑なことだと捉えています。
組織規模が大きいお客様へのソフトウェア提供であればあるほど、エンジニアとそうでない人の間でのモデリング能力のギャップに起因する需要に応えてお金を頂いている節はあるな、と。
次に最適化の話です。簡素な（しかし今までからすると１から開発が必要だった）業務効率化・自動化ならお客様自身で解決できる場合、データ構造に起因する需要以外で残るのはその会社特有の慣習や、事業運営に合わせてオペレーションをカスタマイズして最適化できるかだと思っています。
こっちは結構ソフトウェア企業にとってシビアな話題だと思っています。というのも、お客様ごとへの最適化のために開発者向けツールまでではないにせよ、各社がプログラマブルな側面を獲得するために基盤開発への投資が必要になりそうだからです。
Sell work, not software
最適化の話の延長で、ソフトウェアが直接の商材ではなくなった未来もありうると思います。
サンフランシスコに拠点を置く著名ベンチャーキャピタルのBenchmarkのジェネラル・パートナーの方が、以下のようなポストを書いていました。
端的に言うとお客様にソフトウェア提供するのではなく、LLMを活用した高効率・低単価のBPO企業として”Work”を売っていくお話をされています。
今現在開発者向けのツールを提供している人間がこういうと不思議に聞こえるかもしれませんが、個人的にはこのポストの内容にはいたく共感しておりまして、現実解だと思っています。
お客様からしたら業務が推進されてエンドユーザーの方を満足させられること、実現したい正解感に近づくこと、そして利益が上がることが重要なわけで、ソフトウェアはあくまで手段の１つでしかないはずです。
ましてや「人類」は最高の最適化用インターフェースでして、お客様の実現したいオペレーションを人が汲み取って、彼らが社内で基盤を使いこなす方が、お客様ごとに最適なスピード・品質で業務解決の手段を提供できると思います。
これはソフトウェアの価値を諦めているわけではありません。むしろ、最適化可能なプログラマブルな基盤を今作って売ること、将来そこにLLMを付加価値として載せていきさえすれば、ソフトウェアが直接の商材ではならなくなった時代でも通用する最強の武器を持てるチャンスだと考えています。
私は、100年企業を創りたいと思っています。日本は驚くべきことに、長寿企業を作ることに世界一長けている国です。そんな国に生まれ落ちた身として、日本人としてのアイデンティティの良い部分を活かして、自分がこの世から去っても脈々と続くインフラを作れるかもしれないという想いは、何より日々の原動力になります。
プログラマブルな基盤を作るというのは、ソフトウェア企業が長寿たるための一つ重要な手段だと考えています。
この市場で今からモノを売っていくことは、単に目先の収益指標を伸ばすだけではなく、着実にアセットを積み上げ生存戦略の柔軟さを上げられるという意味で、非常に魅力的です。
長々と書きましたが、プログラマブルな基盤を売るということは、今現在求められ、提供できる課題解決の手段の幅を広げてくれること、将来へのアセットの積み上がりが顕著に高いことが面白いところです。
そして弊社事情で恐縮ですが、ビジネスサイドの責任者の方を募集しています！こうした環境・将来像に魅力を感じてくださり、一緒に市場を開拓したいと少しでも感じてくださった方、あるいはエンジニアの方も、是非一度お話させてください。
DM開いてるので、ぜひお願い致します！
https://twitter.com/__timakin__
そして繰り返しになりますが、サービスにご興味頂けた方はぜひこちらもどうぞ！
長文でしたが、お読み頂きありがとうございました。
この記事が気に入ったらサポートをしてみませんか？