「AIがコードを書いてくれるなら、もうエンジニアに頼まなくてもいいのでは？」
最近、お客様からこの質問をいただく機会が本当に増えました。答えは半分イエスで、半分ノーです。たしかにAIは驚くほどのスピードでアプリケーションを作れるようになりました。ただし、それは「何を作ってほしいのか」を正しく伝えられた場合に限ります。
AI開発の成否を分けるのは、プログラミングの知識ではありません。要件定義です。しかもこれは、エンジニアではなく、業務を知っている発注側・企画側のあなたにしか書けないものです。今日はその話をします。
腕のいいシェフに「美味しいもの作って」と頼むと何が起きるか
想像してみてください。世界中の料理を作れる腕利きのシェフがいます。あなたは席に着いて、こう注文します。
「なんか美味しいもの作って」
出てきたのは、完璧に調理されたフォアグラのポワレでした。でもあなたが食べたかったのは、あっさりした和食だった――。
シェフの腕に問題はありません。問題は注文の仕方です。そして今のAIは、まさにこの「腕は超一流だが、あなたの頭の中は読めないシェフ」です。
「いい感じの顧客管理画面を作って」と頼めば、AIはいい感じの何かを確かに作ります。ただしそれは、AIにとっていい感じのものであって、あなたの業務にとっていい感じのものとは限りません。承認フローが抜けている、既存の業務ルールと合わない、例外処理の考慮がない。出来上がってから「これじゃない」とやり直す時間は、最初に注文書を書く時間よりずっと長くつきます。
これは私たちがAI開発の支援現場で最もよく見る失敗パターンです。AIの性能の問題ではなく、渡している情報の問題。だから解決策も、より高性能なAIではなく、より良い「レシピ」なのです。
要件定義とは、AIに渡すレシピである
要件定義と聞くと、分厚いドキュメントを想像して身構えるかもしれません。でも本質はシンプルで、**「シェフに渡すレシピ」**だと考えてください。
レシピには、完成品の姿（どんな料理か）、材料（何を使うか）、手順（どの順番で何をするか）が書いてあります。要件定義も同じで、AIという開発者に対して「完成イメージ・登場人物・動きの順番」を伝える文書です。
ポイントは、レシピに専門用語は要らないということです。「フライパンを中火で熱する」は誰にでも書けます。同じように、「営業担当が顧客を検索して、履歴を見て、次のアクションを記録する」という業務の流れは、プログラミングを知らなくても書けます。むしろ、その業務を毎日回しているあなたにしか書けません。
レシピに書くべき3つのこと
では具体的に何を書けばいいのか。私たちが非エンジニアの方におすすめしているのは、次の3点セットです。
1つ目は、ユースケース図。「誰が、何をするのか」の一覧です。レストランでいえば注文票のようなもの。「営業担当は顧客を検索できる」「管理者はメンバーの権限を変更できる」と、登場人物ごとにやりたいことを書き出します。図といっても、最初は箇条書きで十分です。
2つ目は、画面遷移図。「どの画面から、どの画面へ移動するのか」の地図です。遊園地のマップを思い浮かべてください。入口（ログイン）から入って、どのアトラクション（機能）にどう辿り着くのか。これがないと、AIは各画面を立派に作っても、画面同士のつながりがちぐはぐなものを作りがちです。
**3つ目が最も重要で、機能要件詳細。**一つひとつの機能について、「何を入力すると、何が起きて、何が出てくるのか」を書いたものです。レシピでいえば、「中火で3分」にあたる具体的な指定です。「検索できる」だけでなく、「顧客名の一部一致で検索でき、結果は更新日の新しい順に並ぶ。0件のときは『該当なし』と表示する」まで書きます。
実際に書き比べると、違いがよく分かります。たとえば「問い合わせ対応の記録機能」なら、こうです。
上の依頼でもAIは何かを作ります。しかし「7日以上放置された問い合わせを見逃したくない」というあなたの現場感覚は、下のように書かない限り、絶対に実装されません。逆にここまで書けば、AIはほぼ一発でその通りに作ります。
3つ目だけ粒度が急に細かくなったと感じるかもしれません。実はここに、AI開発ならではの理由があります。
なぜ「1機能ずつ」渡すとAIの精度が上がるのか
AIには、人間の短期記憶にあたる「一度に集中して扱える情報量」に限りがあります。分厚い仕様書を丸ごと渡して「全部作って」と言うのは、シェフにフルコース10品のレシピを一度に読み上げて「はい、調理開始」と言うようなものです。器用にこなしているように見えて、細部の取りこぼしが必ず起きます。
そこで機能要件詳細を**「1機能につき1ファイル」**に分けておきます。そしてAIには「今日はこの1品だけ」と、1機能分の詳細だけを渡して開発させる。すると、AIが読むべき情報が絞られるぶん、一つひとつの指定が確実に反映され、実装の精度が目に見えて上がります。
この分け方には、発注側にとってもう一つ嬉しい効果があります。確認が楽になるのです。10機能をまとめて納品されて「どうぞご確認ください」と言われても、どこから見ればいいか分かりません。1機能ずつ完成していけば、「今日は問い合わせ記録機能だけ、自分が書いた要件の通りに動くか見る」という確認ができます。要件が発注側の言葉で書かれているからこそ、答え合わせも発注側にできる。これはAI開発に限らない、健全な開発の姿です。
全体を小さな単位に分けて、単位ごとに確実に作り、積み上げていく。この進め方ができるかどうかは、要件定義の段階で「機能ごとに切り分けて書けているか」で決まります。つまり、非エンジニアが書く要件定義の質が、そのままAIの開発精度を左右するのです。
書くべきこと、書かなくていいこと
「そこまで自分で書くのは大変そう」と思われたかもしれません。安心してください。全部を書く必要はありません。
書かなくていいのは、技術の中身です。どのプログラミング言語を使うか、データベースをどう設計するか、サーバーをどう構成するか。これらはAIと開発パートナーの領分で、レシピでいえば「火加減の科学」にあたる部分。任せて構いません。
一方、あなたにしか書けないのは、業務の意図と判断基準です。なぜこの機能が要るのか。どんな例外が現場で起きるのか。「金額が10万円を超えたら上長承認が要る」といったルールは、システムのどこにも書かれておらず、業務をしている人の頭の中にしかありません。AIがどれだけ賢くなっても、あなたの会社の暗黙知だけは推測できないのです。
おわりに ― 要件定義は、発注側の手に戻ってきた
これまで要件定義は、開発会社がヒアリングを重ねて代わりに文書化する、専門性の高い工程でした。それがAI開発の時代には、「業務を知る人が自分の言葉で書き、AIが即座に形にする」という順番に変わりつつあります。作る力の希少性が下がったぶん、伝える力の価値が上がった、と言ってもいいかもしれません。
まずは今の業務の中で「これを自動化したい」と思うものを1つ選び、「誰が・何をして・何が出てくるのか」を箇条書きにしてみてください。それがあなたの最初のレシピであり、AI開発の最初の一歩です。
株式会社Four Youでは、AI開発の要件定義づくりからシステムの実装・運用までを一気通貫で支援しています。「AIで作りたいものはあるが、どう伝えればいいか分からない」という段階のご相談も歓迎です。
#AI開発 #要件定義 #非エンジニア #AI導入 #DX
