【第3回】「〇〇したい」じゃなくユーザーの物理動作だけで要求を定義しよう

「アイデアはあるのに、作り始めると機能が増えすぎて収拾つかない」そんな人へ。そのアイデアほとんどいらないぞッ♪ 欲望を捨てて物理動作に落とし込むだけでAIの過剰実装を防ぐ月見の要求定義。

こんにちは!

AIに仕事を奪われる未来に怯えつつ、今日も元気にキーボードを叩いているTS系バーチャル美少女エンジニア(中身はおじさん)の月見ルナです!

今日の作業のお供は、湖池屋のポテトチップス ガーリック味と炭酸水です。最近はサイダーとかコーラの甘い炭酸が飲めなくなって、ポテチをキメるときは無糖の炭酸水ですね、キックゥ~~~。

さて、前回(第2回)は「個人開発の最低アクティブユーザー数は自分1人でいい」「リリースをゴールにせず、淡々とバージョンを育てていこう」という、個人開発を長生きさせるためのマインドセットについてお話ししました。

「よし!明日からの自分が毎日使うオレオレ(美少女です!!)ツール、早速作ってみるぞ!」

そう意気込んでから、次にぶち当たる分厚い壁があります。

そう、要求定義です。

若い人や最近開発はじめた人は「要求定義」なんてIT業界の堅苦しい言葉を聞くと、臭そうなおじさん達が会議室に集まって、A4用紙何十ページもの分厚い仕様書をうんうん唸りながら作っている光景を思い浮かべる人もいるかもしれません。

でも、安心してください。

要求定義なんて、実際にはそんな高尚で面倒なものじゃ全然ないんじゃないかなってボクは思っています。

ぶっちゃけ、スマホのタスクアプリやメモ帳に殴り書きするくらいのテンションで十分! なんならチラシの裏でいいですよ。

今回は、誰もが罹患しがちな「したいことぜんぜんまとまんない病」を回避しつつ、AIエージェントに振り回されずに最短で動くツールを手に入れるための、要求定義をゆるーくお話ししてみようと思います。

そもそも要求定義ってなんなの

AIドリブンな開発から始めた人はあまり要求定義ってピンッとこないかもしれませんね。

簡単に言えば、日頃タイピングしてる 〇〇したい構文 のプロンプト、あれが要求定義です。

お仕事の話を少しだけすると、ボクは普段、SEとして現場や取引先の担当者さんとシステムの話をまとめる機会がよくあります。そのとき、今回の記事みたいに、相手に向かって「では、今日はシステムの要求定義を始めましょうか♪」なんて口が裂けても言いません。

だって「要求定義書を作りましょう」なんて言った途端、なんかコイツ小難しいこと言い始めたぞってなるじゃないですか。 自分より偉いひとは表情険しくなるし、自分より若いひとはなんか身構えちゃう。 「なんかもっともらしいこと言わないといけない」って雰囲気 で本音が何ひとつ引き出せなくなっちゃうんですよね。

だから現場では、「普段の作業で一番イラッとする瞬間ってどこですか?」みたいな、世間話の延長のようなテンションで引き出すようにしています。

フフフ、人間の負の感情こそ美味

第1回で開発に個人も企業も関係ねぇよって言ったとおり、個人であってもまったく同じでいいと思うんです。 タスクアプリを開いて、「やりたいことリスト」を箇条書きで3行〜5行ポチポチッと書く。それくらいの気楽なテンションで十分なんじゃないかなぁって。

月見www客先でスマホとか出してんのかよwwwザッコ

月見は客先でもスマホ出すが??

一応「スマホでメモ取りますね〜」って一声かければ全然問題ないんですけど……できないの? もしかして客先に嫌われるんじゃないですか、臭そうだし。

でも、「要求定義」は覚えておいてほしい理由

「じゃあ、ただの『やりたいことメモ』でいいじゃん!」って思いますよね。

ただ、連載の今後のためにも、言葉として 「要求定義」 という名前だけは頭の片隅に置いておいてほしいなぁって思うんです。

なぜなら、この後に出てくる 「要件定義(システムとしてどう実現するか)」 としっかり区別してほしいからなんですよね。

  • 要求定義: 「使う人(例えば、ボク)が何をしたいか、どう動かしたいか」

  • 要件定義: 「それを実現するために、システムにどんな画面や機能、データを持たせるか」

ここを一つにまとめちゃうと途端に迷走しやすくなります。

そして、この要求定義のステップ、初めてやる人がほぼ100%発症する、恐ろしい病気があります。

「したいことぜんぜんまとまんない病」 です。

ふぇぇしたいこと全然まとまんないよぅ

アイデアを思いついた瞬間って、頭の中が一番キラキラしていますよね。

  • 「読んだ技術書のメモをいい感じに残したい!」
  • 「日々のタスクをストレスフリーに管理したい!」
  • 「よく使う定型文をワンクリックでサクッとコピペしたい!」

なんかイケんじゃない? 今日のボク、来てるんじゃないって感覚。
この 「〇〇したい」という願望ベースの思考 って、開発にとっては一番足元をすくわれやすいトラップだったりするんじゃないかなぁってボクは感じています。

なぜなら、「〇〇したい」という言葉、抽象的すぎて永遠に出せるんですよ。
つまり、終わりが決まってない。
人間の欲張りな脳内で 無限にリストができてまう からなんですよね。

そして人はそれをアイデアとかチャンスとか呼んで美化してしまう……なぜなのか。

ちなみに月見さんは、「ピンチはチャンス」とかいう言葉、結構嫌いです。ピンチはピンチです。逃避してないで現実みてくださいよ。

ボク ガ カンガエタ サイキョウ ノ アプリ

例えば、「読んだ本のメモを残したい!」という願望からスタートしたとしますよね。

最初は「タイトルと感想をサッと書くだけでいいや」と思っていたはずなのに、考えているうちに脳内でアイデアが囁いてくるんです。

  • 「あ、本のタイトルだけじゃなくて、著者名や出版社も記録できたほうが便利かも?」
  • 「表紙の画像もアップロードできたほうが、本棚っぽくてテンション上がるよね!」
  • 「カテゴリごとにタグ分けして、インクリメンタルサーチもつけなきゃ!」
  • 「星5段階の評価レビューもつけたいし、読書ログをカレンダーでグラフ化しよう!」

笑。

Notionに課金しろや。

ほんまこれです。 それ「Notionとブクログを足して2で割ったような超巨大サービス」作ろうとしてません? ありますよ。 無料で、メンテ付きです。

人の手でやってた頃は、着手から数日後、画面レイアウトの調整やデータベース設計であまりに見合ってなくて、そっとIDEを閉じることになるわけですけど、今ってAIがいい感じにやってくれるのが普通に厄介です。

巨大テックがAI使って複数人で回してるようなサービスを、自分の管理能力や本当にやりたいことを遥かに超えていることにも気がつかず生み出された、肥大化した承認欲求の化け物の誕生です。

誰一人使いこなせなくて海の藻屑となる定め。

AIってめっちゃイイヤツダヨネー、ワカルー

現代にはClaudeやCodexといった超優秀なAIエージェントがいますが、彼らは往々にしておせっかいです。 クラスに一人くらいいそうなめっちゃ細かいことに気がついてくれるいい奴です。

普通にスパダリですよね。

「スキルで制御しろよ、ハーネス設計は?」とか言うのはやめてください。そういう話してんじゃないです。文脈も読めない人はふつうにキモイです!

AIに向かって、何気なくこうプロンプトを投げてみたとしましょう。

読んだ本を記録できるWebアプリを作って!」

AIはめちゃくちゃ親切で、こっちのやりたいこと考えて先回りしてくれて、ほんと人類の何倍も気が利く彼ピッピなので初速は張り切ってくれます。一撃でこんなコードを出力してくるんです。

  • Supabaseを使ったユーザー認証・ログイン画面
  • PostgreSQLの複雑なテーブル設計(Users, Books, Tags, Reviews…)
  • 検索バーとソート用ドロップダウン
  • 謎のアニメーションライブラリが組み込まれたリッチなカードUI
  • 保存成功時にポーンと鳴るトースト通知

Opus5.5がポン出しで会員サイトつくってきたwww

でも、まぁよくよく触ると

  • 「外部ライブラリのエラーで画面が真っ白になった……」
  • 「文言をちょっと直したいだけなのに、どのコンポーネントを触ればいいのかサッパリわからん……」

まぁ、今ならスクショをペタッと貼ってAIに「直して!」って言えばいい感じに手を入れてくれるわけですが、そのたびに全体の構造が変わっていくわけですよね。

さっきの500行どこ消えたっていうのはいいとして、ちょっと落ち着いて胸に手を当てて考えてみてください。

読んだ本を記録したいだけだんだよね???

わかんないよ。わっかんないよ!AIのやってることは一つもわかんないよ!
AIが良いって勝手に追加してくることは何がいいのかぜんっぜんわかんないよ!わかんない!
私にはわかんないの!

Supabaseって何が良いの!?ユーザー認証なんていらないよ!
読んだ本をメモしたいだけなのに、なんでメールアドレス登録して確認メール踏まなきゃいけないの!?
そんなのただのログインの手間が増えるだけじゃん!
これのどこが便利なの!?

PostgreSQLのどこがいいのかわかんない!
UsersテーブルとかBooksテーブルとかTagsとかReviewsとかって何なの!?
リレーション組んで外部キー制約つけるのの何がいいの!? 
そもそも環境変数って何!?.env.local?だから何なの!?

「認証基盤はSupabaseで堅牢に設計しておきました!」って、何それただの身も蓋もない過剰設計じゃん!
ローカルストレージにちょろっとJSONで保存してくれる方がずっと使いやすいよ!立派だよ!

普段は親切ぶって一撃で出力してくるくせに、動かしてみたら
「あれ?ボタン押しても保存されないぞ?」
って何が凄いの!?
そんなのただのバグの押し付けだよ!
6,000行も吐き出さないで、100行でちゃんと動くコード書いてくれるAIの方がカッコいいよ!

どうしてRow Level SecurityとかRLSポリシーとか色々つけるの!?
いっぱい設定があったって画面が真っ白になって動かなくなるだけじゃん!
「JWTトークンが失効しました」とか赤いエラー出さないでよ!直せないんだよ!

OAuth認証とかMagicLinkとかSession管理とか、
ちょっと公式ドキュメント読んだくらいでそういう実装しないでよ!
コードの直し方もちゃんと教えてくんなきゃ意味が分かんないよ!
吐き出すならちゃんと動く状態で出してよ!

謎のアニメーションライブラリも意味不明だよ!
トースト通知がポーンって鳴って何が良いのかぜんっぜんわかんない!
他のファイル構造も謎なんだよ!
@supabase/auth-helpers-nextjsとかmiddleware.tsとか……名前がモダンで格好いいだろってどういうこと!?
アーキテクチャの美しさで感じろとか言われても無理だよ!

ベストプラクティスとかスケーラビリティとか、ちょっとWebで拾っただけで知ったかぶらないでよ!
「将来のユーザー数増加に対応しました」とか言われてもちっとも嬉しくないんだよ!

「設計が甘い」とか偉そうなこと言わないでよ!
上流エンジニアの小難しい言葉使われても何が言いたいのか全然わかんないんだよ!
人間が読める言葉で書いてよ!

お願いだから私が分かること話してよ。

読んだ本を記録したいだけなのに……なんでログイン画面から作らせるの!?
認証通らないと本の一冊も登録できないってどういうことなの!?

わかんないわかんないわかんないわかんない!わかんなーい!

AIの親切心なんて、最初っから何一つ、これっぽっちも、わかんないのよー!

「曖昧な願望」でAIに指示を出すと、AIの過剰な親切心によって、人間には到底メンテできないコードが爆誕してしまうわけです。

しかも困ったことに、最初だけはなんかいい感じに使えちゃったりするからタチが悪いです。

月見の処方箋:「指やマウスの物理動作」だけ書けばいい

じゃあ、この「ふぇぇしたいことぜんぜんまとまんない病」をどうやって治せばいいのか?

ボクの処方箋は、とってもシンプルです。

「〇〇したい」という願望や感情をぜーんぶゴミ箱に捨てて、「ユーザーの物理動作」だけを書き出すこと。

頭の中でフワフワしている理想を一旦全部忘れて、「画面の前に座った自分が、マウスを持つ手やキーボードを叩く指をどう動かすか」という物理的なアクションだけに絞り込んでみるんです。

まるで、工場のロボットの動作ログを書くようなテンションですね。

例えば:このサイト(fillmee.com)の場合

月見さんのサイト(fillmee.com)はAstroで構築されています。

コンテンツ管理は *.md 。静的サイトとしてCloudflare Pagesにデプロイしています。まぁ、よくある構成ですよね。

Astroさん、ビルドするときに画像をWebPに最適化してくれたりしてめちゃくちゃ優秀なんですが、ちょっと嫌なところもあって。

今の構成だと、デプロイするたびにPNGやJPEGが溜まっていくと再生成処理がクソ重くなるとおもうんですよね。 このサイト自体は立ち上げたばかりだからまだいいんですけど、既存サイトがそんな気配がするので。

それに、このブログもせっかくMarkdownで書いてるんだから、他のnoteとか外部メディアにも丸ごとコピペして転用したいじゃないですか。

Note? 1年以上更新止まってるが?

でも、記事の中にローカルのファイルパス ![サンプル画像](../images/sample.png)で直書きしてたら、他所にコピペしても画像が表示されなくて死にますよね。

というわけで、「画像コンテンツだけは、今のうちに別の専用アップローダーで管理してURLで扱いたい!」 と思い立ったわけです。

さて。これを「〇〇したい」という願望ベースで定義すると、どうなるでしょうか?

Astroで静的サイトを管理している。
PNGなどの画像ファイルの引用をファイルパスではなくURL指定にしてMarkdownの転用性を持たせるため、
外部にコンテンツ管理用のファイルアップロードサイトを作成し、URLを管理できるサイトを作成したい。

あれ?

なんかちょっとITっぽくてカッコよくないですか?

でもね、この内容のままAIに投げたら、ほぼ確実にProtonやGoogle Drive、Nextcloudみたいな「本格派オンラインファイルストレージ」を作ろうとしてきます。

  • 親切心で「検索機能」をつけてくるし?
  • 親切心で「タグ管理機能」をつけてくるし?
  • 頼んでもいないのに「フォルダ階層分け」もつけてきそうだし?
  • 「セキュアなログイン認証」も当然のように盛り込んでくるんやろなぁ……。

でもね。

いらないの。いらない、いまは、それ。

ボクがやりたいのは、大掛かりなファイルストレージの運用じゃないんです。ブログを書くときに画像をポイッと放り投げて、Markdown用のリンクが秒で手に入ればそれで100点満点なんですよ。

だからこそ、「物理動作ベース」 で定義し直します。

月見の物理動作ベースの要求定義:

以下の1〜5のシンプルな動作を体験できるサイトを作成してください。

  1. ドラッグ&ドロップできるファイルアップロード画面がある。
  2. アップロード画面に単一または複数ファイル(PNG, JPGなどの画像に限る)をドラッグ&ドロップする。
  3. 自動的にWebPに変換する。
  4. 変換した画像をストレージにアップロードする。
  5. アップロードされたファイルをグリッド表示し、サムネイル、URLコピーボタン、Markdown記述(![](image-link))のコピーボタンを持つカードを並べる。

……どうでしょうか?

物理動作で書いた瞬間、驚くほど視界がクリアになりませんか?

画面に必要なのはアップロードエリアと一覧カードだけ。

自分がマウスと指でやりたい「コアの動作」だけが綺麗に整理されていますよね。

最終的に認証機能や編集機能が本当に欲しくなったら、その時に追加していけばいいんです。最初から盛る必要なんて1ミリもありません。

4. 初期バージョンは「5ステップ以内」に収める

物理動作を書き出すときに、ボクがマイルールとしてなんとなく意識している目安があります。

「画面を開いてから、目的を達成して閉じるまでの手数は5ステップ以内で説明できるようにする」

これくらいの手数に収めておくのが、個人開発の初期バージョン(v0.1.0)としては一番健全で、進めやすいんじゃないかなってボクは思っています。

古の人間が手作業でコードを書いていた時代から、関数には「単一責任の原則(Single Responsibility Principle)」なんてものがありましたよね。

要求定義の単位も、まさにこの「単一の責任」でいいと思うんです。

先ほどのボクの指示も、責任としてはこれだけですが、最初のやりたいことは実現できます。

  1. ドロップする
  2. WebPにする
  3. ストレージに送る
  4. カードで並べる
  5. コピーボタンを押す

最初に作るのは、これくらい極限まで削ぎ落とされた「単一目的(Single Purpose)」の道具にしておくと、嬉しいメリットがたくさんあります。

メリット:すぐにとりあえず動くものが手に入る

やることがボタン数個、アクション数回レベルなら、AIにプロンプトを投げてから動くものが手元に来るまで本当に一瞬です。「実装終わったwww」という小さな成功体験を最速で味わえるので、モチベーションが枯渇する暇がありません。

メリット:可笑しな挙動のチェックが圧倒的に簡単

動かない原因があるとしたら、「その5ステップのどこか」しかありません。 「画像が上がらないならステップ4のストレージ連携を見ればいいや」と、自分でコードを書かない・読まないAIドリブンな開発でも修正指示がめちゃくちゃ楽になります。

メリット③:すぐに使える

これ、地味に一番大切なんですよね。

買い物もそうですが、人間一番欲しい瞬間は思いついたときなんですよ。今使いもしないボタンがたくさんあって設定項目がズラリと並んでいるツールって、作った本人が言うのもなんですが開くのすらめんどくさいんですよ。

結局、アプリなんて説明書がいらなくて、直感的に使えるようなものが一番しっくりくるので、最初から作りこむ意味ってないとボクは思ってます。

あったら便利かもは大体便利じゃない

人間の欲求って罪深いもので、物理動作を考えている最中にもボクの考える最強の…がわいてくるんですよね。

「やっぱり、検索機能くらいはあった方が便利じゃない?」 「グリッド表示だけじゃなくて、リスト表示もあったほうがよくない?」 「ダークモードとライトモード切替できたほうがいいっしょ」

「ちょっとまって?先に使わせて。とりあえず、使わせて」

新しいAIモデルやゲームのリリース予告があったとして、直前に「ごめん、もっといいの思いついたし調整するね。少し延期で」とか言われたら萎えますよね。 これ自分にする必要ないじゃないですか。

検索機能なんてデータが全然ない状態でつける機能じゃないんですよ!! というか、初見で限界まで盛っていいのはパフェだけで十分なんです!!

FILLMEE.COM用のアセット置き場

……やっちまったなぁ!! アセット2件しかないのに何を検索するのって話ですよね。
ブログなんて続いた試しないのに……。

5. 物理動作からAIへ指示を出すお気楽プロンプト

要求が「物理動作」として数行にまとまったら、あとはそれをそのままAIに渡してあげるだけです。

最近の賢いAIエージェントさんたちには、小難しいプロンプトエンジニアリングの極意なんてテクニックは全然いりません。

数年前、みんなSNSでドヤ顔で言ってましたよね。

貴方は世界最高峰のフロントエンドエンジニアです(キリッ)
深呼吸をして、ステップバイステップで考えてください。

うん……ボクは当時から「あほくさ……」って思っていたよ。

そんなおまじないを唱える暇があったら、やってほしい物理動作を箇条書きでストレートに伝えた方が100倍早いです。

ボクが実際にAIに投げるときは、これくらいの気軽さで投げています。

以下の【物理動作】だけを満たす、シンプルな単一画面のWebツールを作成してください。
最小限の構成で動くものが必要です。

【物理動作】
1. 画面中央にドラッグ&ドロップエリアがある。
2. 画像(PNG/JPG)をドロップすると、ブラウザ側でWebP形式に自動変換される。
3. 変換後の画像が指定のストレージAPIにアップロードされる。
4. アップロード完了後、画面下にサムネイルカードが追加される。
5. カード内の「Markdownコピー」ボタンを押すと、クリップボードに `![alt](url)` がコピーされる。

場合によっては必要な制限事項を追加することもありますが、基本的にはこれだけ。 AIドリブンな開発をする場合、AIの作業範囲をどこまで絞れるかが、自分が掌握できる決定打になると思います。

自分の手数をきめよう

要求定義とは、小難しいビジネス資料を作ることでも、壮大なビジョンを語ることでもありません。

「キーボードを何回叩き、マウスを何回クリックするかという『手数』を決める作業」

ボクはそんなふうに捉えています。

  • 要求定義なんてチラシの裏書き程度でいい。
  • 「〇〇したい」という願望で進めると機能インフレする。
  • 要望ではなく「物理動作」だけで画面と処理を定義してみる。
  • 初期バージョンの物理動作は「5ステップ以内」を目指すとやりやすい。
  • AIにあれこれ指示するより、物理動作をそのまま箇条書きにして渡したほうがいい。

仕様を極限までシンプルに削ぎ落とすことこそが、最後まで楽しくやり切るためのコツなんじゃないかなってボクは思います。

さて! 物理動作が決まり、「ほな、実装するか。プロジェクト作成っと……」としようとしているあなた。 ちょっと待ってください。

いざ実装を始める前に動いてる画面見ましょうよ。

???

動いてる画面???

それって実装では?という方に次回は、

【爆速モック】AIドリブン×単一機能スタートなら爆速モックできるいい時代

というテーマでお話しします。

どうぞお楽しみに!