AIで作る前に、データ設計だけは決めておく

AIにコードを書いてもらうと、ものを作る速度がかなり上がる。

画面を作る。フォームを作る。データを保存する。通知を飛ばす。以前なら数日かけていた叩き台が、数十分で形になることがある。

これは本当に便利だ。小さく試せるし、頭の中だけで考えていたものを、すぐに画面で見られる。

ただ、最近少し怖いと思っていることがある。

それは、「とりあえず作ってみよう」が、後から思った以上に効いてくることだ。

コードが汚くなる、という話だけではない。もっと手前の、何を作るのか、誰のために作るのか、どんなデータを持つのかを曖昧にしたまま走ると、その曖昧さが仕組みの中に埋め込まれてしまう。

これを、自分は 仕様負債 と呼んでいる。

技術的負債とは少し違う

技術的負債という言葉は、開発の世界ではよく使われる。

急いで作ったのでコードが読みにくい。テストが少ない。同じ処理が何度も書かれている。今は動いているけれど、後から直すのが大変になる。

これはこれで問題だ。けれど、AI開発でより怖いのは、コードの書き方より前にある。

たとえば、最初に「個人が使うツール」として作ったものを、後から「チームで使う業務システム」に変えたくなる。

一見、機能を少し足せばよさそうに見える。ログインを足す。メンバー管理を足す。権限を足す。

でも実際には、かなり深いところから変わる。

データの持ち方が変わる。誰が何を見られるかが変わる。通知の出し方が変わる。履歴の残し方が変わる。削除してよい範囲も変わる。

最初に「個人のメモ」として保存していたデータが、後から「チームの共有情報」になると、ただ画面を足すだけでは済まない。

これは、コードが汚いから起きる問題ではない。

最初に置いた仕様の前提が、後から合わなくなる問題だ。

仕様負債は、データ設計に埋まる

仕様負債が厄介なのは、主にデータ設計に埋まるからだ。

データ設計というと難しく聞こえるけれど、要するに「何を、どんな単位で、どう保存するか」の決め方である。

このツールの利用者は個人なのか、チームなのか。

ひとつの案件に、担当者は一人なのか複数人なのか。

お客さんの情報は、店舗ごとに分かれるのか、会社全体で共有するのか。

誰が作ったデータを、誰が見てよいのか。

こういう前提は、最初は地味に見える。画面の見た目に比べると、あまり盛り上がらない。

でも、一度データが入り始めると、後から変えるのが急に難しくなる。

コードだけなら、書き直せる。大変ではあるけれど、まだ閉じた作業で済むことが多い。

データは違う。実際のユーザーが入力した情報が入る。業務の履歴が残る。通知や権限や集計が、そのデータを前提に動き始める。

その状態で「やっぱり個人単位ではなくチーム単位でした」となると、作り直すだけでなく、過去のデータをどう移すか、誰にどう説明するか、運用中に止めてよいのかまで考えなければならない。

だから仕様負債は、ユーザーが増えるほど重くなる。

最初の小さな決め忘れが、あとで何本もの枝に分かれて効いてくる。

「動くものがある」は、仮説検証とは限らない

AIで速く作れるようになると、「まず動くものを作って見せる」がやりやすくなる。

これは悪いことではない。むしろ、画面にしてみないと分からないことは多い。

ただし、動くものがあることと、仮説が検証されたことは同じではない。

たとえば、「移動したい人向けの乗り物」を作るとして、いきなり高性能なエンジンを作るとする。エンジンは動く。音もいい。技術的にはすごい。

でも、後から本当の課題が「子どもを送りながら荷物を運びたい」だったと分かったら、エンジンだけでは足りない。車体も、積載スペースも、安全性も、全部考え直しになる。

最初に確認すべきだったのは、エンジンが作れるかではなく、どんな移動を助けたいのかだった。

AI開発でも同じことが起きる。

フォームが動く。一覧が出る。通知が飛ぶ。ログインもできる。

でも、その業務が本当に必要としていたのは、個人の入力補助なのか、チームの引き継ぎなのか、責任者の確認なのか、監査のための履歴なのか。

ここが曖昧なまま作ると、動くものがあるせいで、かえって問い直しにくくなる。

「もうここまでできているし、このまま行こう」となる。

その瞬間に、仕様負債が積み上がる。

AI時代のMVPは、作る量ではなく問いの精度に寄る

MVPという言葉がある。最小限のプロダクトを作って、早く学ぶという考え方だ。

以前は、実装が遅かった。だから自然と、何を作らないかを考える必要があった。全部は作れないので、削るしかなかった。

AIで実装が速くなると、この制約が弱くなる。

作れてしまう。画面も作れる。APIも作れる。管理画面も作れる。将来使うかもしれない項目も、ついでに足せる。

すると、MVPの重心が変わる。

大事なのは、「どこまで小さく作るか」だけではなく、「何を確かめるために作るのか」を先に決めることになる。

誰の、どんな状況の、どんな困りごとなのか。

それを確かめるために、本当にシステムを作る必要があるのか。

インタビューで分かることと、実際に使ってもらわないと分からないことは何か。

もし仮説が外れたら、どのデータや運用が作り直しになるのか。

この問いを飛ばして作ると、AIは速いので、負債も速く積み上がる。

最初に聞くべき問い

最近、AIに業務システムや社内ツールを作らせる前に、かなり最初の段階で聞いたほうがいいと思っている問いがある。

これは個人で使うものですか。チームで使うものですか。

かなり素朴な問いに見える。

でも、ここを間違えると、後から広い範囲に効く。

個人用なら、データはその人のものとして扱えばよい。チーム用なら、共有、権限、引き継ぎ、責任者、履歴が必要になる。

個人用なら「自分が分かればよい」で済む項目も、チーム用なら「他の人が見ても判断できる」形にしなければならない。

個人用なら削除して終わりでも、チーム用なら「誰がいつ消したか」を残す必要があるかもしれない。

この違いは、画面の最後に足す機能ではない。かなり根っこの前提である。

だから、作り始める前に聞く。

個人か、チームか。

誰が入力し、誰が見るのか。

どの状態を保存し、どの状態は保存しないのか。

後から変えると一番痛い前提は何か。

このあたりを決めずに「とりあえず作る」と、最初は速い。でも後で重い。

小さく試すことは、雑に決めることではない

ここで誤解したくないのは、「だから作る前に全部決めよう」という話ではないことだ。

全部を決めてから作ろうとすると、今度は何も進まない。

大事なのは、後から変えやすいものと、変えにくいものを分けることだ。

文言は後から変えられる。ボタンの位置も、ある程度は変えられる。画面の見せ方も、AIならかなり速く直せる。

でも、データの単位、権限、責任の線、履歴の残し方は、後から変えにくい。

だから、全部を詰めるのではなく、変えにくいところだけ先に問う。

逆に言えば、そこさえ押さえれば、小さく作ることはむしろ強くなる。

スケートボードのような小さな形で出して、実際に使ってもらい、早く学ぶ。けれど、そのスケートボードが誰の移動を助けるものなのかは、先に言葉にしておく。

小さく作ることと、雑に決めることは違う。

人間の仕事は、止める場所を決めることに移る

AIで実装が速くなるほど、人間の仕事は減るというより、手前に移っている気がする。

画面を作る。コードを書く。表を作る。文章を整える。

このあたりはAIがかなり担える。

でも、何を作るべきか。何をまだ作らないか。どの前提は今決めなければならないか。どの前提は後から変えてよいか。

ここは人間が握らないと危ない。

AIは、頼めば作ってくれる。

だからこそ、「作れるから作る」になった瞬間に、業務システムは散らかりやすい。

仕様負債という言葉を置いておくと、少し立ち止まりやすくなる。

これはコードの問題なのか。

それとも、課題定義やデータ設計の前提を曖昧にした問題なのか。

後者なら、リファクタリングだけでは直らない。コードをきれいにする前に、何を解く仕組みなのかを問い直す必要がある。

作る前に、エンジンではなく車を決める

AI時代の「とりあえず作る」は、昔より強い。

速く形にできるし、試す回数も増やせる。これは大きな武器だ。

でも、速く作れるからこそ、最初の前提も速く埋め込まれる。

エンジンを作る前に、どんな車なのかを決める。

もっと言えば、そもそも車なのか、台車なのか、自転車なのか、徒歩を助ける地図なのかを決める。

ここを飛ばすと、後から「エンジンは立派だけど、荷物が載らない」ということが起きる。

仕様負債は、作業が遅い時代には目立ちにくかった。作るのが遅いぶん、途中で考える時間があったからだ。

でもAIで作る速度が上がった今は、考えないまま進める速度も上がっている。

だから、AIに作ってもらう前に、ほんの少しだけ止まる。

誰の、どんな場面の、どんな困りごとを解くのか。

その答えは、データの持ち方に落ちているか。

後から変えると痛い前提はどこか。

この問いを挟むだけで、「とりあえず作ってみよう」はもっと良い武器になると思う。