"SaaS is dead" is dead?直すのは安くなる。気づくのは安くならない

Xで流れてきた投稿を読んだ。Emooove社の藤澤諒一氏が、社内システムの内製に数ヶ月振り切ってみた実体験を書いている。

https://x.com/emooove/status/2088073432156266794

エンジニア経験のない入社二ヶ月の採用担当が、応募者管理から選考、ダッシュボードまで揃った採用管理システムを自力で作り上げた。営業オペレーション用の社内システムも並行して動いている。そのうえで、うまくいったことと痛い目を見たことの両方が書かれている。

つまずいた点のひとつとして、こうある。

わかる。そのうえで、この「粗」は二つに割れるのではないか。
割ってみると、内製という選択が何を買って何を手放したのかが見えてくる。

粗は二種類ある

応募者のエントリーが取り込まれていない。ダッシュボードの数値がおかしい。重要なボタンが抜けている。

これらの粗には、それぞれ二つの作業がぶら下がっている。直す作業と、気づく作業。

直す作業は、コードを書き換えること。気づく作業は、「取り込まれていないぞ」と誰かが発見すること。ふだんは一続きの体験なので、分けて考えない。
しかし内製の話をするときは分けたほうがいい。前者と後者では、この先の値段の動き方がまったく違う。

直す側は安くなる

前提。
直す作業は、これからさらに安くなる。

UIの細部が微妙なのも、保守が重いのも、そのうちAIの側が満足できる水準まで面倒を見るようになるのではないか。
ここ数年のコード生成の進み方を見ていると、逆に賭ける理由がない。何度も指示し直す執念が要るという現在の摩擦は、そのうち摩擦でなくなる。

だとすると、内製の話で保守負荷とUI品質を最大の論点に置くのは、数年で論点ごと消えてしまう置き方ではないか。

気づく側は残る

安くならないのは、もう一方。

ダッシュボードの数値がおかしいと気づくのは、その数値を毎日見て、あるべき値を知っている人間である。
エントリーが取り込まれていないと気づくのは、応募者が来たはずだと知っている人間である。
ボタンが抜けていると気づくのは、その操作をしたい人間である。

AIは指示された画面を作る。作られなかった画面については、何も言わない。
存在しない機能はバグとして観測されない。

気づかれるまで、それは粗ですらない。

気づかれなかったもの、それが要求

ここで言葉を置き換える。

気づく作業が発見しているのは、本当にバグだろうか。要求そのものではないか。
応募者情報が漏れなく手元に集まっていてほしい、という要求。今日の選考状況が正しく分かっていてほしい、という要求。

要件は、その要求を実装に落とした一つの形にすぎない。
取り込みのバッチも、集計のロジックも、要求そのものではない。

そしてSaaSの要件は、他社の要求が何年も畳み込まれた堆積物である。
使いにくいと言われ、直し、また言われ、直す。その反復のなかで、かつて誰かが一度は言語化した要求が、機能という形で保存されている。

内製は要件を捨てる行為。ここまでは正しい。
問題は、要件のなかにしか保存されていなかった要求まで、一緒に捨ててしまうこと。
捨てたことに気づけるのは、それが困りごととして表に出たときだけ。

だから内製は「作って終わりではなく直し続ける」のではない。作って終わりではなく、要求を発見し続ける。こちらが正確である。

例外がひとつある

元記事はセキュリティを別格に扱っている。
そうなのだ。理由も、いま置いた言葉で説明できる。

保守もUI/UXも、要求を持っているのは自社のユーザーである。
使えば不満が出る。不満が出れば要求が見つかる。発見のループが自社のなかで閉じる。

セキュリティだけ、要求を持っているのが攻撃側にある。
認証が甘い、権限がザルだ、という要求は、通常業務からは永久に出てこない。誰も困らないまま動き続け、ある日一度だけ、取り返しのつかない形で観測される。

ループが閉じない。だから外部に出すものには経験者を入れるべき、という結論になる。
AIにできるかどうかではなく、要求の発見者が社内にいるかどうかで線が引ける。

月額は機能の値段ではなかった

こう見ると、SaaSに払っていた月額の中身が変わる。

機能を借りる代金だと思っていた。実際には、要求を発見し続ける仕事を外注する代金だったのではないか。
ベンダーは何千社ぶんの利用から要求を集め、要件に畳み込み、こちらが困る前に直している。月額を止めるとは、その役を自分で引き受けるということなのだと。

作る値段が下がったので、機能ぶんの対価は確かに消える。
ただし発見ぶんの対価は消えない。誰がやるかが変わるだけだ。

死んだのは二元論

元記事の結論は、SaaSは死んでいない、選択肢が増えただけ。ここに一つ足してみよう。

死んだのは、SaaSでも「SaaS is dead」でもなく、SaaSか内製かという問いの立て方のほうではないだろうか。
作るか買うかは要件の層の話であり、要件は本来いちばん捨てやすい層である。
捨てられる層の選択に、判断の重心を置きすぎていたのではないだろうか。

問うべきは、その業務の要求を誰が発見し続けるのかではないか。
自社の利用から出てくる要求なら、内製に勝ち目がある。自社からは永久に出てこない要求が混ざるなら、そこは買う。同じシステムのなかで、層ごとに答えが違ってよい。

作る値段が限りなく下がった先に、値段の下がらないものが残る。
そして残ったほうが、そもそも本体だった。