システム開発で最も多いトラブルは、技術的な失敗ではありません。「そんなつもりじゃなかった」という、この一言に尽きます。
納品されたものを見て、こんなはずでは、と思う。開発側は「ご要望どおりに作りました」と言い、実際その通りの記録も残っている。どちらも嘘をついていない。ただ、頭の中に描いていた完成品が、最初から違っていただけです。そして、その違いに気づくのが、完成した後だったというだけです。
私たち株式会社Milestoneは、静岡県沼津市を拠点とするAIシステム・AIチャットボット開発の会社です。今日のテーマは、この事故を防ぐための工程──要件定義です。
先に言い切ります。要件定義とは、作る前に完成品を言葉で見る作業です。 建てる前に間取り図を見るのと同じ。図面の段階なら、壁の位置は消しゴムで動かせます。でも建ててから動かすなら、それは工事になります。壁を壊し、費用がかかり、工期が伸びる。──システム開発で起きる手戻りも、まったく同じ構造です。
なぜ揉めるのか、何を決めるのか、AIならではの項目、そして発注する側の役割まで。読み終える頃には、「要件定義の場で、貴社は何をすればいいのか」がはっきりしているはずです。
なぜ「言った・言わない」は起きるのか
まず、事故の構造からです。
同じ言葉を、違う意味で使っている
「問い合わせに自動で答えるシステムを」。この一文を、発注側と開発側が読んだとき、頭に浮かぶ絵は同じでしょうか。
発注側は、電話も含めた全部の問い合わせを想像しているかもしれません。開発側は、ホームページからの文字の問い合わせだけを想像しているかもしれません。「自動で」という言葉も、完全に人が関わらないのか、人が確認して送る下書きまでなのか、解釈が分かれます。「答える」も、その場で回答するのか、後ほど返信するのかで、まるで別物です。
言葉は、思っているより曖昧です。 そして曖昧なまま合意すると、その曖昧さは消えるどころか温存され、完成品を前にした瞬間に牙を剥きます。
「当たり前」が、会社によって違う
発注側には、言うまでもないと思っていることがあります。「うちは土曜も営業しているから、当然そこも対応するでしょう」「見積もりには消費税を含めるのが普通でしょう」。
でも開発側は、貴社の商売の常識を知りません。同じ地域の同じ商売でも、会社ごとにやり方は違います。言われていないことは、存在しないのと同じとして扱われます。悪意ではなく、知りようがないのです。
決めていないことは、後で誰かが決める
そして一番厄介なのがこれです。決めなかった項目は、消えてなくなるわけではありません。作る段階で、誰かが決めます。多くの場合、開発側が「たぶんこうだろう」と判断して進める。
その判断が当たれば、問題は表に出ません。外れたときに、「言った・言わない」が始まります。つまり運任せです。要件定義とは、この「誰かが勝手に決める項目」を、先に潰していく作業なのです。
要件定義で、何を決めるのか
決める項目を、五つに整理します。
| 決めること | 具体的に | 決めないと起きること |
| ①目的 | 何のために作るのか | 途中で方向がぶれる |
| ②範囲 | どこまで作り、どこは作らないか | 「入っていると思った」が起きる |
| ③動き | どんな場面で、どう振る舞うか | 完成品を見て違和感が出る |
| ④データ | 何を使い、どこに置き、誰のものか | 移行や解約でもめる |
| ⑤条件 | 期間・費用・体制・引き渡しの基準 | 完成の判断ができない |
①目的──「何のために」を一行で
意外に飛ばされがちなのが、ここです。「AIを導入する」は手段であって、目的ではありません。「電話対応に取られる時間を減らしたい」「営業時間外の取りこぼしをなくしたい」「新人が遠慮なく質問できる環境をつくりたい」。
目的が一行で書けていると、後から出てくる細かい判断のすべてに、物差しができます。設計の途中で意見が割れたら、目的に照らして決める。 これができる設計と、できない設計では、同じ費用をかけても出来上がりが変わります。
②範囲──「作らないもの」こそ書く
要件定義書で一番大切なのは、実は「作らないもの」の欄です。
今回はホームページの窓口だけで、電話は含まない。よくある質問には答えるが、見積もりの計算はしない。既存システムのデータは見るが、書き込みはしない。──こう書いてあれば、後から「てっきりやってくれると思っていた」は起きません。書いていないことは、やらないと決まっているのですから。
線を引くことは、冷たいことではありません。 線があるから、その中身を丁寧に作れます。何でもやりますという約束は、たいてい何も約束していないのと同じです。
③動き──場面ごとに、どう振る舞うか
ここが要件定義の本体です。「よくある質問に答える」だけでは足りません。答えられない質問が来たら、どうするのか。お客様が怒っているとき、どう振る舞うのか。営業時間外は何と言うのか。同じ質問を三回されたら、どうするのか。他社の商品名を出されたら、どう返すのか。
場面を並べて、一つずつ振る舞いを決めていく。 地味な作業ですが、この積み重ねが、使いやすさの正体です。よくできた仕組みとそうでない仕組みの差は、たいていこの細部に出ます。
④データ──持ち主と置き場所を、紙に
何のデータを使うのか。どこに置かれるのか。運用で溜まる記録は誰のものか。解約したとき、どう返してもらえるのか。
顧客情報のように扱いに気を使うデータであればなおさらですが、そうでなくても、この四点は最初に書いておくべきです。年月が経って業者を変えるとき、揉めるのはたいていここです。
⑤条件──「完成」の基準を、先に決める
いつまでに、いくらで、誰が担当し、何をもって完成とするか。特に最後の「完成の基準」が抜けると、直しても直しても終わらない開発になります。お互いにとって不幸な状態です。
「よくある質問30問に、想定どおりの答えが返ること」。このように、誰が見ても確かめられる形で書いておくのが理想です。「満足のいく品質」のような言葉は、基準になりません。
AIならではの、要件定義の項目
AIシステムには、従来のシステムに無い項目が加わります。ここが今の要件定義の勘所です。
答えていい範囲と、答えてはいけない範囲
普通のシステムは、決められたことしかしません。AIは、教えていないことにも答えようとします。だから、答える範囲を明示的に区切る必要がある。
料金は答えていい。納期は目安まで。契約内容の判断はしない。健康や法律に関わることは答えない。──この線引きを紙にしておかないと、想定していない場面でAIが勝手に判断します。そして厄介なことに、その答えは、堂々としているのです。
「分かりません」と言わせる設計
AIは、知らないことでも、それらしく答えてしまうことがあります。実在しない料金プランを案内する。取り扱いのない商品を「取り扱っています」と言う。悪気はなく、仕組み上そうなり得ます。
だから要件定義では、「根拠がないときは、正直に分からないと言う」を明記します。そして、分からないと言った後どうするかまで決める。担当者につなぐのか、フォームを案内するのか、電話番号を出すのか。「分かりません」で終わる窓口は、お客様を突き放すのと同じです。
人へつなぐ出口の設計
どんな場面で、人にバトンを渡すか。お客様が「担当者と話したい」と言ったとき。同じ質問を繰り返しているとき。感情的な言葉が出たとき。金額の交渉が始まったとき。
出口の無いAIは、行き止まりです。 どこで、誰に、どうつなぐか。営業時間内と時間外で、つなぎ先は変わるのか。ここも要件定義の対象です。
言葉づかいと、名乗り方
どんな口調で話すのか。AIであることを名乗るのか。愛称をつけるのか。会社の顔として立つ以上、これは技術ではなく経営の判断です。開発側に「お任せします」と言うと、当たり障りのない、どこの会社でもない声になります。設計の場で、貴社が決めてください。
育て方の取り決め
作って終わりではないのがAIシステムです。答えられなかった質問をどう回収するか。誰が、どの頻度で教材を直すか。その作業は保守に含まれるのか、別料金なのか。
この項目を書いていない要件定義書は、半分しか書けていません。 作る話だけで、使い続ける話が抜けているからです。
AI項目の、確認リスト
ここまでのAIならではの項目を、確認しやすい形にまとめます。要件定義書を受け取ったとき、この五つが書かれているかを見てください。
| 項目 | 書かれているか |
| 答えていい範囲・答えない範囲 | 具体的な線引きがあるか |
| 根拠がないときの振る舞い | 「分かりません」と言う設計があるか |
| 人へつなぐ出口 | 場面ごとのつなぎ先が決まっているか |
| 言葉づかい・名乗り方 | 会社の声として設計されているか |
| 育て方の取り決め | 誰が、いつ、どう手入れするか |
この五つが埋まっていれば、AIシステムの要件定義としては、ひとまず合格点です。逆に、一つでも空欄なら、その項目は「後で誰かが決める」ことになります。
発注する側の、役割
「専門的なことは分からないから、お任せで」。そう思われるのは自然ですが、要件定義だけは、お任せにできません。理由は単純で、貴社の業務の正解を知っているのは、貴社だけだからです。
とはいえ、難しい作業ではありません。求められるのは、資料を作ることでも、専門知識を身につけることでもありません。開発側の質問に、答えることです。「この質問には、普段どう答えていますか」「この場合、断ることはありますか」「土曜の対応はどうしていますか」。日々当たり前にやっていることを、言葉にするだけ。それができるのは、世界で貴社だけです。
設計者が仕組みの形を考え、貴社が中身の正解を出す。 この分担が、要件定義の基本形です。
そしてもう一つ、現場の人を巻き込んでください。経営者の頭にある業務と、現場で実際に起きていることは、しばしば違います。例外的な対応、暗黙のルール、よくある特殊な依頼、常連さんへの気遣い。それらは現場にしかありません。そして、そういう例外こそが、後で「そんなつもりじゃなかった」の火種になります。
やってはいけない、3つのこと
してはいけない①：要件定義を、急がせる
「早く形が見たい」というお気持ちは、よく分かります。でも、ここで削った時間は、後の手戻りで利子つきで返ってきます。設計で使う1時間が、後の10時間を消す。 全体の工期を縮めたいなら、むしろここを厚くするのが近道です。急ぐべき場所ではありません。
してはいけない②：口約束で、進める
「そこは大丈夫です、やっておきます」。この場では安心でも、記録に残らなければ、数カ月後には誰の記憶にも残っていません。決まったことは、その日のうちに書面へ。紙にするのは、相手を疑っているからではなく、人は忘れるからです。 担当者が変わることもあります。
してはいけない③：要件定義書を、読まずに承認する
専門用語が並んでいると、読み飛ばしたくなります。でも、ここが最後の関門です。分からない言葉は、その場で聞いてください。説明できない開発者は、その部分を理解していないか、貴社に伝える気がないかのどちらかです。読み手に分かるように書かれているかどうか自体が、相手を測る材料になります。良い設計者は、必ず素人の言葉で説明できます。
「AIを制御する技術」×要件定義──Milestoneの流儀
私たちが「AIを使う」のではなく「AIを制御する」と言うとき、その制御が実際に形になるのが、この要件定義の場です。
答える範囲を紙に書く。根拠のないことは言わせないと決める。困ったときの出口を設計する。そして、育て方まで取り決める。──賢いAIを作るのではなく、貴社の業務の中で、安心して働けるAIを設計する。その約束を交わす場が、要件定義です。
だから私たちは、この工程に時間をかけます。専門用語ではなく貴社の言葉で書き、「作らないもの」を必ず明記し、疑問はその場で全部潰していただく。分からないまま承認していただくことは、ありません。静岡・沼津の会社として、顔の見える距離で設計できることは、この工程で最も効いてくる強みだと考えています。
よくある質問（FAQ）
Q1．要件定義には、どれくらいの時間がかかりますか？ A．規模によりますが、小さな窓口AIなら、数回の打ち合わせで数週間。既存システムと連携する構成なら、1か月前後が目安です。貴社が拘束される時間は、その中の数時間から十数時間ほど。ここを惜しまないことが、結果的に一番の近道になります。
Q2．要件定義だけ、別料金なのですか？ A．会社によって扱いが違うので、確認する価値のある質問です。提案・見積もりまでは無料で、契約後の要件定義は開発費に含む形が一般的です。ただし、要件定義だけを切り出して有料で行う進め方もあります。見積書のどこに含まれているか、必ず確認してください。
Q3．要件定義書は、誰が書くのですか？ A．開発側が書き、貴社が確認して承認する形が一般的です。貴社が一から書く必要は、まったくありません。ただし、内容を理解して承認することが前提です。分からないまま印を押すのが、一番危ない状態です。
Q4．途中で「やっぱりこうしたい」となったら？ A．タイミング次第です。設計の段階なら、比較的柔軟に変えられます。構築が始まってからだと、範囲や費用の相談が必要になることが多い。だからこそ、設計の場で思いつくことは全部出し切ってください。「こんな細かいこと言っていいのかな」という遠慮が、後の追加費用と手戻りに変わります。
Q5．うちのような小さな会社でも、要件定義は必要ですか？ A．はい、必要です。ただし、規模に応じて驚くほど軽くなります。数枚の資料で足りることも多く、形式より中身が大切。「作るもの」「作らないもの」「完成の基準」の三点さえ明確なら、立派な要件定義です。
Q6．要件定義書を見ても、良し悪しが判断できません。 A．三つだけ見てください。第一に、「作らないもの」が書いてあるか。第二に、専門用語だらけでなく、貴社が読んで意味が分かるか。第三に、完成の基準が、確かめられる形で書いてあるか。この三点が揃っていれば、悪い要件定義書ではありません。
Q7．他社に依頼中ですが、要件定義に不安があります。 A．第三者の目で拝見することは可能です。実際、そうしたご相談も少なくありません。「作らないもの」の記述、データの取り扱い、完成の基準。この辺りが曖昧なまま進んでいないか、確認するだけでも意味があります。開発を引き受けるかどうかとは別に、ご相談ください。
Q8．何を準備して打ち合わせに臨めばいいですか？ A．よくある質問の上位10個と、「一番困っている場面」の具体例。この二つがあれば十分です。あとは、こちらの質問に答えていただく形で進みます。準備が足りないことを、相談しない理由にしないでください。
図面の段階なら、壁は消しゴムで動かせる──株式会社Milestone
要件定義とは、作る前に、完成品を言葉で見ておく作業でした。目的、範囲、動き、データ、条件。そしてAIならではの、答える範囲・分からないと言う設計・人へつなぐ出口・言葉づかい・育て方。
地味で、目に見える成果物も出ない工程です。でも、ここが厚い開発は、後半が驚くほど静かに進みます。逆に、ここを飛ばした開発は、後半が騒がしくなります。「言った・言わない」は、誰かの性格や誠実さの問題ではなく、設計の問題なのです。
私たちMilestoneは、静岡県沼津市を拠点に、AIシステム・AIチャットボットの開発と導入支援を専門に行っています。「AIを使う」のではなく「AIを制御する」を核に、設計図づくりの段階から、貴社の言葉で伴走します。
こんなご相談を歓迎しております
- 要件定義の進め方を、具体的に知りたい
- 他社からの要件定義書を、第三者の目で見てほしい
- 「作らないもの」の線引きを一緒に考えたい
- AIならではの項目（範囲・出口・育て方）を設計したい
- 小さく始めるための、軽い要件定義から相談したい
訪問対応（静岡県内・隣接エリア）、オンライン対応（全国）、どちらでも可能です。30分ほどお話を伺うだけで、貴社の設計図に書くべき項目と、決めるべき線引きは、たいてい見えてきます。
▶ ご相談・お問い合わせ https://milestone-net.com
「資料だけ見たい」「他社と比較検討中」というライトな段階のご連絡も、歓迎しております。
「やりたいをできるに、できるをできたに」。中小企業の長期パートナーとして、責任を持って伴走します。
株式会社Milestone（マイルストーン） 代表取締役 大石 湧斗（おおいし ゆうと） 所在地：静岡県沼津市
中小企業向けAIシステム開発・導入支援。「AIを使う」のではなく「AIを制御する」を経営の核に据え、業務にフィットしたAI導入を伴走型でご提案。静岡県全域と隣接エリアで対面対応可能。「やりたいをできるに、できるをできたに」をミッションに、貴社の長期パートナーとして責任を持ってご支援します。
