社内にエンジニアがいない会社がAI開発を発注するときの正解は、「要件定義書を自社で作ってから渡す」のをやめることです。用意すべきは仕様書ではなく、実際の帳票・画面・例外パターンという現物です。
社内にエンジニアがいない会社は、AI開発をどう発注すればいいですか？
結論は、要件を一緒に作るところから引き受けるベンダーを選ぶことです。
不動産・建設の会社では、情報システム部門を持たず、社長か営業事務の方がIT全般を兼務しているケースが大半です。この状態で「まずRFPを作ってから相見積もり」に進むと、次のどちらかに転びます。
- 抽象的すぎるRFP（例：「契約業務をAIで効率化したい」）→ 見積もりの前提がベンダーごとにバラバラで、金額を比較できない
- 細かすぎるRFP（例：既存のExcel手順をそのまま画面仕様に落とした指示）→ 非効率な業務をそのままシステム化してしまい、使われない
発注側にエンジニアがいない以上、実現可能性とコストの当たりをつけるのは構造的に不可能です。そこは発注側の努力で埋める部分ではありません。埋めるべきなのは「自社の業務が実際どう動いているか」の情報です。
フォワードデプロイエンジニアリング（FDE）とは何ですか？
フォワードデプロイエンジニアリングとは、開発者自身が発注元の現場に入り込み、実際の業務を観察しながら要件定義と実装を並行して進める開発の進め方です。
従来の受託開発との違いは次の通りです。
| 従来型の受託開発 | フォワードデプロイ型 | |
|---|---|---|
| 要件定義 | 発注側が作る／コンサルが作る | 開発者が現場に入って一緒に作る |
| 最初の成果物 | 要件定義書・設計書 | 動くプロトタイプ |
| 仕様変更 | 変更管理として追加費用 | 前提として織り込む |
| 発注側に必要な力 | 仕様を書く力 | 現物を出す力・判断する力 |
| 向く会社 | 情シスがある会社 | 情シスがない会社 |
エクサテックが株式会社イーリアルティ様に構築した転記エージェント（リーシングサービスと基幹システム間のデータ転記を自動化する仕組み）では、契約の前段階から何度も現場に足を運び、困りごとを理解するところから着手しました。同社では業務マニュアルが未整備でしたが、転記自体を自動化したことで、マニュアルを作る必要そのものが減っています。マニュアルがないから発注できない、ではありません。
発注前に社内で準備すべきものは何ですか？
準備するのは文章ではなく、現物5点です。
- 実際の帳票の現物 — マイソク、売買契約書、重要事項説明書、見積書、グリーンファイル、施工体制台帳など。個人情報はマスキングして構いませんが、きれいに整えないでください。手書きの追記、FAXのかすれ、担当者ごとの書式のブレこそが設計上の重要情報です。
- 業務画面のスクリーンショットまたは操作録画 — 既存の業務システム、レインズ、会計ソフトの実画面。スマホで手元を撮った動画で十分です。
- 1件あたりの所要時間と月間件数の実測 — 1〜2週間、担当者に開始時刻と終了時刻をメモしてもらいます。推測値ではなく実測で取ってください。ここが投資判断の唯一の根拠になります。
- 例外パターンの一覧 — 「この管理会社のときだけ書式が違う」「共有名義のときは手順が増える」など。担当者に「先月イレギュラーだった案件」を挙げてもらうのが最短です。
- 承認フロー — 誰が確認し、誰が押印・記名し、どこで止まるか。
これらを揃えた時点で、要件定義の材料の大半は揃っています。言語化はベンダー側の仕事です。
最初に自動化する業務はどう選べばいいですか？
最初の1本は、次の基準をすべて満たすものを選びます。
- 月に繰り返し発生する（年数回の業務は学習も改善も回らない）
- 入力元がすでにデジタル（PDF・CSV・Web画面）である
- 中身が「判断」ではなく「転記・整形・分類」である
- 間違えても後戻りできる（提出前に人が確認する工程がある）
- 担当者が1〜2名で、その人が検証に時間を割ける
逆に、最初の対象にしてはいけない業務は次の通りです。
- 重要事項説明書の作成など、法的責任が直接発生する書類
- 積算のうち歩掛の設定や価格判断を伴う部分
- 年1回の決算・許可更新まわり
- 属人的な判断が価値の中心にある業務（仕入判断、価格査定の最終決定）
発注から稼働までは、どういう工程で進みますか？
各フェーズに完了条件を置いてください。「なんとなく進んでいる」状態を防げます。
| フェーズ | やること | 完了条件 |
|---|---|---|
| 1. 現場観察 | 開発者が実際の作業に同席し、操作を観察する | 例外パターンが一覧化されている |
| 2. 対象の切り出し | 業務全体のうち自動化する範囲と、人が残す範囲を線引きする | 「AIがやる／人がやる」の境界が図で合意できている |
| 3. プロトタイプ | 実データで動くものを作る | 現場担当者が自分の手で1件通せる |
| 4. 並走運用 | 従来手順とAI出力を両方回して突き合わせる | 誤りのパターンが把握でき、確認工程が設計できている |
| 5. 本稼働 | 従来手順を止める | 担当者が新人に説明できる |
| 6. 保守・改修 | 書式変更・項目追加に対応する | 依頼先と対応速度が決まっている |
エンジニアがいない会社ほど、フェーズ4（並走運用）を省略しないことが重要です。ここを飛ばすと、誤りが出たときに社内で原因を切り分けられず、「使えないから元に戻す」となります。
ベンダー選定で何を聞けばいいですか？
技術力は素人には判定できません。判定できるのは答え方です。
| 聞く質問 | 良い回答 | 危ない回答 |
|---|---|---|
| 現場には何回来ますか | 回数と目的を具体的に答える | 「オンラインで十分です」 |
| 当社の業務でAI化に向かないのはどこだと思いますか | 具体的に指摘する | 「全部いけます」 |
| 精度が出なかったときの運用は | 人の確認工程の設計まで答える | 「精度は問題ありません」 |
| 納品後に項目を追加するのは誰ですか | 誰が・いくらで・何日でを答える | 曖昧なまま保守契約だけ提示 |
| データはどこに保存され、学習に使われますか | 保存先とAPIの利用条件を明示 | 即答できない |
| 設計と実装は同じチームですか | 同一チームか、分業の役割分担を説明 | 説明が噛み合わない |
2番目の質問が最重要です。できないことを先に言えるベンダーのほうが、結果として使われるものを作ります。
社内の担当者は誰を立てればいいですか？
ITに詳しい人ではなく、その業務を一番多く手を動かしている人を業務オーナーに立ててください。例外パターンと判断基準を持っているのはその人だからです。役割は3つに分けます。
- 業務オーナー（実務担当者）：現物の提供、プロトタイプの検証。工数を確保する
- 意思決定者（経営層）：範囲と予算の判断。フェーズ2の線引きに必ず同席する
- IT窓口（兼務可）：既存システムの契約内容確認、アカウント発行、社内ネットワークの制約確認
IT窓口は詳しくなくて構いません。「既存システムのベンダーに問い合わせる担当」がいれば足ります。
AI開発で「できないこと」は何ですか？
発注前に理解しておくべき限界を明示します。
- 丸投げでは要件は出てきません。 業務が言語化されていない状態は、現場に入ることでしか解消できません。担当者の時間を確保できない場合、プロジェクトは進みません。
- 精度100%は出ません。 生成AIを使う以上、出力を人が確認する工程は残ります。設計するのは「誰が・どのタイミングで・何を見て確認するか」です。
- 法的な最終判断は代替できません。 宅地建物取引業法第35条に基づく重要事項の説明は宅地建物取引士が行い、書面には宅地建物取引士の記名が必要です（2022年5月18日の改正で押印は不要となり、記名のみとなりました）。AIができるのは調査結果の整理や下書き作成までで、内容の確認と責任は宅建士が負います。個別案件の解釈は専門家にご確認ください。
- 入力の質を超える出力は出ません。 手書き・FAX・低解像度スキャンは読み取り精度が落ちます。この場合、入力側の運用変更（スキャン解像度の統一など）とセットで設計する必要があります。
- 既存システムにAPIがなければ連携方法は限られます。 CSVの入出力すらできない業務システムの場合、画面操作の自動化になり、システム側の画面変更で壊れやすくなります。事前に既存ベンダーへ確認してください。
費用と期間はどう見積もればいいですか？
金額は「業務の複雑さ」ではなく、対象範囲の広さで桁が変わります。1業務に絞ったプロジェクトと、複数業務にまたがるプロジェクトでは前提が別物です。判断材料は次の4点です。
- 対象となる業務の種類数
- 入力データの状態（デジタルか、紙・手書きが混ざるか）
- 既存システムとの連携有無と、その連携方式
- 求める精度と、確認工程をどこまで人が担うか
エンジニアがいない会社ほど、最初は1業務に絞って発注することをおすすめします。小さく作って現場で回し、効果を自社の目で確認してから範囲を広げるほうが、社内の合意も取りやすくなります。
まとめ
- 社内にエンジニアがいない場合、要件定義書を自社で作ってから発注する進め方は成立しにくい
- 発注側が用意するのは仕様書ではなく、帳票の現物・画面録画・所要時間の実測・例外パターン・承認フローの5点
- 最初の1本は「頻度が高く／入力がデジタルで／判断より転記中心で／後戻りできる」業務を選ぶ
- ベンダーは技術力ではなく、「できないことを先に言えるか」で見極める
- 並走運用のフェーズを省略しない。ここを飛ばすと現場で戻される
よくある質問
Q. 社内にエンジニアがいなくてもAI開発を発注できますか。
A. 発注できます。ただし要件定義書を自社で完成させてから渡す前提だと失敗しやすいため、現場に入って要件を一緒に作るタイプのベンダーを選んでください。発注側が用意するのは仕様書ではなく、実際の帳票・画面・例外パターンといった「現物」です。
Q. 発注前に社内で準備しておくものは何ですか。
A. 実際に使っている帳票の現物（個人情報をマスキングしたもの）、業務画面のスクリーンショットまたは操作録画、1件あたりの所要時間と月間件数の実測、例外パターンの一覧、承認フローの4〜5点です。文章化された仕様書は不要です。
Q. 最初に自動化する業務はどう選べばよいですか。
A. 頻度が高く、入力元がすでにデジタルで、判断より転記・整形が中心で、誤っても後戻りできる業務を選びます。重要事項説明書の作成など法的責任が直結する業務や、年に数回しか発生しない業務は最初の対象に向きません。
Q. ベンダー選定で必ず聞くべき質問はありますか。
A. 「現場には何回来ますか」「当社の業務でAI化に向かないのはどこだと思いますか」「精度が出なかったときの運用はどう設計しますか」「納品後に項目を追加するのは誰ですか」の4つです。特に2番目に答えられないベンダーは要注意です。
Q. 社内の担当者はITに詳しい人を立てるべきですか。
A. ITに詳しい人より、その業務を一番多く手を動かしている人を業務オーナーに立ててください。例外パターンと現場の判断基準を持っているのはその人です。IT担当は既存システムの仕様確認とアカウント発行を担う役割に分けると進みます。
ご相談について
エクサテックは、仕組みの設計からWebアプリの構築までを同一チームで担当し、不動産・建設の現場に入って要件を一緒に組み立てる進め方をとっています。「何を頼めばいいか分からない」段階でも、まずは実際の帳票と業務の流れを拝見するところからご相談いただけます。
