エンジニアの思いつきプロダクトあるあるというか、自分自身耳が痛すぎるのだけど、データベース駆動設計の果てに、単体または少数のテーブル操作にそのまま対応するRESTFul APIがあり、アプリケーション全体をとおしてほとんどデータベースのCRUDしかやっていないようなサービスがあるとする。

ここで、アプリケーションとは大体そういうものでは?と感じるひとと、そうではないと感じるひととでメンタルモデルがまずことなる。ソフトウェアアーキテクチャにおいて抽象化が過剰と感じるか必要と感じるか、オブジェクト指向が必要な場面があるか、DDDが役に立つかどうか、といった感覚にも繋がっているように思う。

データベースのCRUDとは、データベース管理システムに備わるデータ操作の基本の4つで、次の総称である。

  • CREATE - データの作成
  • READ - データの読み取り
  • UPDATE - データの更新
  • DELETE - データの削除

いっぽうRESTFul APIは、リソース(データ)とその操作をHTTPプトコルで行う際の約束事を定めたもので、本来データベースのCRUDとRESTFul APIは強い対応関係になくてよいが、ごくシンプルなアプリケーションの場合、各HTTPメソッドとCRUDが次のように対応する。

  • POST - CREATE
  • GET - READ
  • PUT - UPDATE
  • DELETE - DELETE

よくサンプルアプリケーションとして引き合いに出される「ToDo管理アプリ」をイメージするとよい。

  • POST - CREATE - ToDoを作成する
  • GET - READ - ToDo一覧または詳細を取得する
  • PUT - UPDATE - ToDoを更新するまたは完了にする
  • DELETE - DELETE - ToDoを削除する

ここから本題だが、自分がつくろうとしているプロダクトがほとんどデータベースのCRUDしか取り扱っていないようなら、解決しようとしている課題が単純すぎるかもしれない、という兆しであるから、プロダクトを発展させるつもりがあるなら、それ以上の何かを見つける必要がある、という話。

シンプルなのはよいことである、と言いたくなるが、実際シンプルであるという裏側に、複雑なドメインを扱っていないという不都合な事実が隠れている可能性から目を背けないほうがよい。複雑なドメインを扱っていなくて何が悪いかと思われるかもしれないが、そうしたサービスにはお金が払われないのでプロダクトが発展しないという問題が事後的に生じる。

もちろん例外はあって、単純なCRUDで扱うデータやサービスに独自性がある場合がある。資格や免許がないと提供できないサービス、ここでしか売っていないモノ、ここでしか会えない人など。なんだMoatの話かと思ったひとは半分あっている。

Moat(モート): スタートアップの競争戦略概論|原健一郎 | Kenichiro Hara
moat /moʊt/ [名]  (都市・城壁の周囲に掘られた)堀 Moat(モート)とはウォーレンバフェットと盟友のチャーリーマンガーが様々なインタビューで繰り返し繰り返し述べている事業において最も大切な概念です。 僕が投資家として、最も時間と思考を費やしている対象もMoat(モート)です。 バフェット/マンガーにはMoatについてのいくつもの引用がありますが下記の質疑応答の一部がわかりやすいです。 The most important thing, what we’re trying to do is to find a business wit

Moatを築こう、で終わりそうなところ、もう少しだけシステムの話として続けたいと思う。

システム開発におけるサーバーサイドアプリケーション不要論がSNSで話題になっていたことがあった。実際まだ不要にはならないわけだが、例えばSupabaseがこれだけ支持されていることを考えると、少なくともこれまでサーバーサイドアプリケーションが担っていた役割はすでに変容し、ある部分では小さくなっていると想像できる。この理由には次の2つがあると思う。

  • ユーザーインターフェース(UI)の重要性が増していること
  • CRUDの実装には独創性を挟む余地が少なく、しばしば退屈であること

ToDo管理アプリの場合、データ構造やその操作としてはもうあまり工夫の余地がないので、UI勝負ということになる。実際優れたUIを生み出せるチームがあることはMoatになると僕は考えるが、UIが優れているかどうかは別の指標でしか証明できないので、事前の説得コストとしては高くなると考える。

システム全体が比較的単純なCRUDで占め、事業自体に参入障壁がない場合、UIを発明する必要があるように思う。これが上手くいっている例としてはプロダクトマネジメントシステムのLinearをあげる。

Linear – Plan and build products
Linear streamlines issues, projects, and roadmaps. Purpose-built for modern product development.

Linearが扱っているドメインとしてはプロジェクトマネジメントであり、再発明もよいところであるが、同系統のツール史上最も優れたUIを提供しているように思う。Linearは2023年にシリーズBで3,500万ドル(約52億円)の資金調達に成功している。

逆に言うと、UIを突き詰めないのであれば、なにかしらの複雑性を隠蔽したシステムになっていないと付加価値が生み出せない。もちろんシステムを複雑にするとプロダクトの優位性が生じるということはあり得ないので、これは結果論の話をしている。

最近ではこの付加価値提供をAIに担ってもらおうとするケースが増えてきている。AI自体が自前でない場合(そしてそのほうが適切であることが多い)AIの単純な利用では模倣平易性が高すぎて優位性にならない。2025年はAIエージェントの時代と言われているが、これにはエージェントシステムに大きな可能性があることと、AIがあっという間にコモディティ化していることとの両面が関係していると思う。

ごく個人的には、どのようなアイデや、どのような小さなプロダクトであっても何らかの価値や発見があると思うが、プロダクトを事業化し中長期で成長させていきたいのであれば、データベースの薄いラッパーのようなシステムを構築していないかどうかを、定期的に点検してみてもいいのではないかと思う。開発者視点では、ソフトウェアのモデリングや抽象化を軽視する傾向があると感じたら、それが幅広い経験に基づくものか、携わってきたアプリケーションの傾向によるものなのかを俯瞰してみるとよいのではないかと思う。