DXは「要件定義」から始めない——業務の自動化を目指しながら効率化から実現する、現場に来て話を聞きながらその場で作る開発
この記事は バイブコーディング的仕事ブログ（VWork Blog）へ移りました。 最新版はこちらです → https://exbridge.jp/vibeblog/2026-10-14-dx-genba-de-sono-ba-de-tsukuru.html
名古屋でAIシステム開発の会社をやっています。DXや業務の自動化の相談を受けていて、最近よく思うことがあります。システム開発で一番大変なのは、作ることより、要件をまとめるところではないか、ということです。
1. 要件をまとめても、現場から「違う」と言われる
よくある流れはこうです。
- 現場の困りごとを聞き、要件をまとめる
- 何社かに相見積もりをとり、発注する
- 要件定義、設計、開発、テストと進める
- 運用が始まって、現場から「やっぱり違う」と言われる
- そこからの仕様変更で費用がふくらみ、発注した側と作った側で揉める
1から5まで、半年から1年かかることも珍しくありません。そして5は、少なくありません。
2. なぜ「違う」が起きるのか
理由は、要件を書く手間よりも、要件が現場を一番知らない人の言葉で決まってしまうことにあると考えています。
- 書く人と使う人が別：要件をまとめるのは発注の責任者で、毎日使うのは現場の人です。組織が大きいほど、現場と発注の責任者の距離が遠くなり、伝言が増えます。現場の「なんとなく使いにくい」「この順番だと二度手間」は、要件定義書の言葉になりません
- 違いが見つかるのが最後：現場の人が実際に触れるのは、テストか運用が始まってからです。そこで見つかった違いは、全部「仕様変更」になります
- 契約が変更を嫌う：一括の請負は「最初に決めた範囲を、決めた金額で作る」約束です。作りながら気づいたことを入れるほど、追加の費用と交渉が必要になり、揉めます
どれも、誰かが悪いわけではありません。作り直しに大きな費用がかかる時代には、先に全部決めてから作るのが合理的でした。
3. AIで、作り直しの費用がほぼなくなった
いまは、AIに相談しながら開発できます。画面を一つ作るのも、直すのも、数分から数十分です。作り直しの費用がほぼなくなったので、「先に全部決めてから作る」必要がなくなりました。
当社の今日の仕事で言うと、国会の質疑と答弁を集めるシステムを単体の製品に切り出し、質問と答弁を1枚の画像にするカードを3種類作り、販売のページと紹介の動画まで用意しました。この間、要件定義書は1枚も書いていません。
- 「URLだけでなく、タイトルとURLを一緒にコピーできるボタンにしたほうがいい」と言われて、その場で直す
- 「この例、古くない？」と言われて、新しい例に差し替える
- 作りながら見つかった問題（質問の途中で話題が移ると、別の答弁を組にしてしまう）も、その日のうちに直す
使う人の一言を、その場で反映できる。これが、請負の開発との一番の違いです。
4. 効率化から始めて、自動化を目指す
DXの目標は業務の自動化ですが、いきなり全部を自動にしようとすると、それこそ大きな要件定義が必要になります。そこで、順番を逆にします。
- 現場に来て、いまの仕事を見る：何に時間がかかっているか、どこで転記や二度手間が起きているかを、話を聞きながら確かめます
- 一番時間がかかっている作業から、その場で効率化する：たとえば、毎日手で写している表を自動で集める、問い合わせの返信の下書きをAIに作らせる。小さく作って、その日から使ってもらいます
- 使ってもらいながら直す：「この項目も欲しい」「この順番がいい」をその場で直します。ここで、現場の言葉がそのまま仕組みに入ります
- つながったところから自動にする：効率化した作業がいくつかつながると、人が間に入らなくても流れる部分が見えてきます。そこを自動化します
効率化の段階で、現場の人は「これは使える」と実感しています。だから自動化の段階でも、現場が協力的です。上から決めた仕組みを押し付けるのとは、ここが違います。
企業のAI活用を4つの段階で考えると、これは第2段階（資料やアプリで作業を支援する）から始めて、第3段階（仕組みが自動で業務を進める）へ進む道筋です。段階の考え方は、AI駆動経営の記事に書きました。
5. 現場に来て、その場で作る人がいればいい
請負の開発スタイルより、AIで開発できる人が現場に来て、話を聞きながらその場で作るほうが、費用も期間も大きく小さくなります。
- 要件定義と相見積もりの期間がなくなる：話を聞いたその日に、最初の画面ができます
- 仕様変更で揉めない：変更は「次にやること」でしかないので、追加の交渉が要りません
- 現場と発注の責任者の距離が縮まる：現場で作っているので、責任者も実物を見て判断できます
AIの開発の速さを示す例として、落合陽一氏は、AIを使った開発の生産性を人間だけのときの32倍と書いています。当社でも、300時間かかると見積もられるような難しい開発が3時間ほどででき、100万〜300万円の開発費が3万円ほどで済んだ例があります。
6. 気をつけること
現場でその場で作るやり方にも、気をつけることがあります。
- 契約は「働いた時間の分だけ」にする：現場に常駐して、現場の人と相談しながら作るなら、一括の請負ではなく、時間で精算する契約（準委任）にするのが筋です。請負の契約のまま現場で指示を受けて作ると、偽装請負と見られるおそれもあります
- 作った人にしか分からない状態を防ぐ：その場で作るほど、記録が残りにくくなります。設計のメモや手順書もAIに書かせて、作ったものと一緒に残します
- 決めることは人に残す：何から作るかの優先順位、外に出すかどうか、お金がかかる判断は、現場と責任者が決めます
- 最初に決めたほうがよい仕事もある：法令で仕様が決まっている基幹の仕組みや、何社かで責任を分ける大きな案件は、今でも先に要件を固めたほうが安全です
7. 当社のやり方
当社は、この形を「AI-IT顧問契約」として引き受けています。現場に伺い、話を聞きながらその場で仕組みを作り、働いた時間の分だけ請求します。保守料のように、何もしなくてもかかる費用はありません。
よくある質問
DXは要件定義から始めなくてよいのですか？
業務の効率化から始めるなら、大きな要件定義は要りません。現場に来て、一番時間がかかっている作業を見つけ、その場で小さく作って使ってもらい、直しながら広げます。法令で仕様が決まっている基幹の仕組みなど、先に要件を固めたほうがよい仕事もあります。
システム開発で仕様変更が揉めるのはなぜですか？
要件をまとめる人と使う人が別で、現場が実物に触れるのがテストや運用の段階だからです。そこで見つかった違いが全部仕様変更になり、一括の請負の契約では追加の費用と交渉が必要になります。
現場に常駐して開発してもらうときの契約はどうすればよいですか？
現場の人と相談しながら作るなら、一括の請負ではなく、働いた時間で精算する準委任の契約にするのが筋です。請負の契約のまま現場で指示を受けて作ると、偽装請負と見られるおそれがあります。
業務効率化と業務自動化は何が違いますか？
効率化は、人がしている作業を速く、楽にすることです。自動化は、人が間に入らなくても仕事が流れるようにすることです。効率化した作業がつながると、自動にできる部分が見えてくるので、効率化から始めて自動化を目指すのが進めやすい順番です。