AI駆動開発で、最初の画面が出るのは5日目 ── 何が出てきて、どちらが何をやるか
1日目・5日目・2週目・1ヶ月目に何が起きるかを、そのまま書きました
— 姿勢の説明ではなく、日程と役割分担をそのまま書きます。 —
5日目に、動く画面が出ます
先に結論を書きます。私たちがシステムを作るときの日程は、こうなっています。
| いつ | 何が起きるか | 御社の作業時間 |
|---|---|---|
| 1日目 | 今お使いのExcelや帳票を見せていただく（打ち合わせ1時間） | 1時間 |
| 5日目 | 一覧・登録・検索の画面と、テストデータが入った状態でお見せする | — |
| 2週目〜 | 画面を触っていただき、いただいた指摘をその日に反映する | 週30分 |
| 1ヶ月目〜 | 権限の設定と、今あるデータの引っ越しに入る | 決めごとへの○×のみ |
「ここを直したい」の反映は、だいたい1時間から2時間です。
一般的な受託開発だと、要件定義に3ヶ月、開発に6ヶ月。最初に形が見えるまで半年から9ヶ月かかります。そこが5日になった、という話です。
ただし、「5日で動く」と「5日で使える」は違います。この違いについては後半で具体的に書きます。
なぜこの進め方にしたか
私はいまシステムを作る側にいますが、もともとは発注する側でした。
自分の会社の業務システムを外部の開発会社にお願いして、およそ3,000万円を投じたことがあります。要件定義に3ヶ月、開発に6ヶ月。
出来上がったものは、現場で使えませんでした。追加の改修をお願いして、さらに費用が出て、それでも使えるようにならず、最終的にExcelに戻りました。
仕様書を読んだ時点では、思い出せなかった
仕様書にはこう書いてありました。「申請画面から上長に承認依頼を送信する」。
私はそれを読んで、「うん、そうだね」と言いました。
実際に動くものが出てきて、初めて気づきました。うちの会社では——
- 金額が一定を超えると部長の承認が要る
- 部長が不在のときは課長が代わりに押す
- ただし代理で押したことは記録に残す必要がある
- 月末は締めの都合で承認期限が前倒しになる
これ、仕様書を読んだ時点ではひとつも思い出せませんでした。
隠していたわけではありません。現場では当たり前すぎて、わざわざ言うことだと思っていなかったのです。
私が悪かったのか、開発会社が聞き出すべきだったのか。どちらでもなくて、触ってみるまで思い出せないことを、触る前に全部言え、という順番に無理があったのだと思います。
だから、先に動くものを出す順番に変えました。
同じことが、統計にも出ています
日経コンピュータの「ITプロジェクト実態調査 2018」では、1,745件のシステム導入・刷新プロジェクトのうち、成功したのは**52.8%**でした。
そして、満足を得られなかった理由の筆頭が「要件定義が不十分」。スケジュールを守れなかった理由の筆頭が「システムの仕様変更が相次いだ」でした（日経クロステック）。
何十年も同じところでつまずいているなら、それは個人の段取りの問題ではなく、順番の問題だと思います。
AIが出てきたいまも、この構造は変わっていません。ボストン コンサルティング グループが2025年に発表した調査では、AIで継続的に大きな価値を生み出せている企業は世界全体で**5%**にとどまっています（BCG AI RADAR 2025）。
AIを入れれば解決するのなら、この数字にはならないはずです。
AIを入れること自体が目的になってしまう話は、「AIを使える社員」と「AIを使う会社」は別であるにも書きました。
1日目：打ち合わせ1時間。決めていただくことはありません
日程を、1日ずつ具体的に書きます。
初回の打ち合わせは1時間です。この日にお願いするのは、今お使いのものを見せていただくことだけです。
見せていただくもの
Excelでも、紙の帳票でも、いまのシステムの画面でも構いません。画面共有で結構です。
整理していただかなくて大丈夫です。 むしろ、整理する前のそのままの状態のほうが助かります。
- 手書きの書き込み
- セルの色分けのルール
- シートの端に溜まっている例外の一覧
- 誰かが個人的に付けた記号
こういうところに、仕様書には絶対に書かれない実務が入っています。私が3,000万円のときに言えなかったのは、まさにこの種類の情報でした。
こちらからする質問
- 「これは何のためのシートですか」
- 「この色は何を意味していますか」
- 「この列を使うのは誰ですか」
- 「この作業は月に何回ありますか」
答えられる範囲で結構です。分からないところは「分からない」で構いません。あとで現場の方に聞けば済みますし、そもそも2週目から現場の方に入っていただくので、そこで出てきます。
この日に決めていただくこと
ありません。
仕様書へのご署名も、要件のとりまとめもお願いしません。こちらから「まずこの画面から作ります」とお伝えして終わります。
5日目：出てくるのは絵ではなく、動く画面です
5日目にお見せするのは、デザイン案やモックアップではありません。
具体的に出てくるもの
- 一覧の画面 — テスト用のデータが並んでいて、並べ替えと絞り込みができます
- 登録の画面 — 実際に入力して保存でき、一覧に反映されます
- 検索 — 名前や日付で探せます
- URL — ブラウザで開けるので、お手元のパソコンやスマホからいつでも触れます
「テスト用のデータ」というのは、こちらで用意した架空のデータです。空っぽの画面をお見せしても判断しづらいので、それらしいデータを入れた状態でお出しします。
御社の実際のデータは、この段階では使いません。まだ置き場所や見せる範囲を決めていないうちに実データを動かすのは、こちらの方針として避けています。実データを入れるのは、権限の設定が決まったあと、1ヶ月目以降です。
ここで「違う」が出るのが正常です
5日目に「あ、ここ違う」が出てきます。それが正常です。むしろ出てこないほうが心配になります。
このとき、細かい文言の違いも遠慮なく言っていただきたいです。「こんな細かいこと言っていいのかな」と思われるレベルのことが、実際に毎日使うときには一番効きます。
直しの反映は、1〜2時間です
具体的な時間を書きます。
| ご要望の例 | 一般的な受託開発 | 私たちの場合 |
|---|---|---|
| 入力項目をひとつ足したい | 見積り → 承認 → 数週間 | 1〜2時間 |
| 一覧に絞り込みを足したい | 同上 | 1〜2時間 |
| この文言を変えたい | 次回のまとめ改修へ | その場で |
これまでのシステムだと、ちょっと直したいだけでも、見積もりを取って、社内で承認を通して、何週間か待つ必要がありました。
そうすると、だんだん言わなくなります。私もそうでした。「これくらいなら言わなくていいか」と飲み込んで、そのまま使いにくい状態で残る。
まとめてからでなくて大丈夫です。 思いついた順に言っていただければ、こちらで整理します。
どちらが何をやるか
一番はっきりさせておきたいのがここです。
| 工程 | 私たちがやること | 御社にお願いすること |
|---|---|---|
| 現状の把握 | 質問して整理する／業務の流れを図に起こす | 見せていただく（1時間）／整理は不要 |
| 画面を作る | 全部（設計・実装・テストデータの用意） | — |
| 確認と手直し | 動く画面を毎回用意する／指摘をその日に反映 | 触って言う（週30分）／まとめなくて可 |
| 権限の設計 | 案を作って提示する／実装と動作確認 | 誰が何を見るか決める／**案への○×**で可 |
| データの引っ越し | 変換・投入・検算／表記ゆれの候補を一覧化 | 「同じか別か」の判断（迷う分だけ） |
| 運用開始後 | 月1回の点検・修正／不具合はこちらから連絡 | 気づいたことを言う（タイミングは問わず） |
御社にお願いするのは、1日目に1時間、あとは週30分、それと決めごとへの○×。これだけです。
どれもシステムの知識は要りません。全部、業務側の判断です。逆に言えば、ここだけはこちらでは代われません。
2週目から1ヶ月目にかけて、繰り返していること
5日目のあと何が起きるのかが見えにくいと思うので、1週間の中身を書いておきます。
週の前半：こちらが直す
前の週にいただいた指摘を反映します。項目の追加や絞り込みの追加は1〜2時間なので、いただいた翌日には入っていることがほとんどです。
同時に、まだ作っていない画面を1つか2つ足していきます。5日目は一覧・登録・検索の3点セットですが、そこから「一括で取り込む」「印刷する」「集計を見る」といった画面が足されていきます。
週の後半：30分見ていただく
画面共有で、実際に触っていただきます。こちらから「ここ、この順番で合っていますか」と聞くこともありますが、基本は触って気づいたことを言っていただくだけです。
このとき、2週目からは現場の方にも入っていただくようにしています。決裁される方と、毎日使う方では、見るところが違うからです。
決裁される方は集計や一覧の見え方を気にされ、毎日使う方は入力の手数を気にされます。どちらも大事ですが、後者は完成してから言われると直すのが大変になります。
この繰り返しで、だいたい何周するか
ケースによりますが、最初の1ヶ月で3〜4周というのが多いです。
3周目あたりから、最初は思い出せなかった例外が出てきます。「そういえば、この取引先だけ違うんですよ」というやつです。これが出てくるのが、この進め方のいちばんの狙いです。
権限の設計で、決めていただくこと
「決めごとへの○×」と書きましたが、具体的に何を聞かれるのかが分からないと不安だと思うので、実際の例を書きます。
こちらから、こういう表をお出しします。
| 誰が | 何ができる案 | ご判断 |
|---|---|---|
| 一般の社員 | 自分が登録したものだけ見られる／編集できる | ○ / × |
| 課長 | 自分の課のものを全部見られる／編集できる | ○ / × |
| 部長 | 全部見られる／編集は自分の部のみ | ○ / × |
| 経理 | 金額欄だけ全社分見られる／編集はできない | ○ / × |
これに○×をつけていただくだけです。ゼロから考えていただく必要はありません。
×がついたところだけ、「では、どうしましょうか」とご相談します。
権限は、後から足すと必ず穴が空きます。 「とりあえず全員が全部見られる状態で作って、あとで絞る」は、ほぼ確実に漏れが出ます。なので、ここだけは最初にお時間をいただいています。
「できました」と言う前に、3つ通します
品質の話も、具体的に書きます。
1. 機械で調べる
書き方の誤りや、想定外の値が入ったときの動きを、自動で検査します。空欄で保存したら、マイナスの数値を入れたら、全角で入力したら——といった動作です。
2. 本番と同じ環境で、実際のデータを入れて動かす
エンジニアの世界に「自分のパソコンでは動いた」という言葉があります。それは確認になりません。
実際にお使いいただく環境で、権限ごとに動作を確認します。管理者では動くが一般ユーザーでは動かない、という不具合は、権限を分けて試さないと見つかりません。
3. 確認項目をチェックリストにしてお渡しする
何を確認したかが分かる形でお出しします。御社側で追加で見たい項目があれば、そこに足していただけます。
この3つを通していないものを「できました」とは申し上げません。
正直に申し上げると、このルールは過去に何度も先走った報告をしてしまったからできたものです。「できました」とお伝えした翌日に本番で動かない。あれほど信頼を削ることはありません。だから、気をつけるのではなく、仕組みとして止めることにしました。
ご報告が少し遅く感じられたときは、ここに時間を使っています。
AIに任せきりにしない4つと、その具体的な手順
AIを使って作りますが、この4つは必ず人が確認します。
お金の計算。 請求額・税額・按分は、AIが書いた計算とは別に、もう一度別の方法で計算して突き合わせます。一致しなければ止めます。計算式が正しく見えることと、正しいことは違うからです。
法律に関わること。 労働基準法や下請法など、解釈が要るところは人が確認します。判断がつかない場合は、専門家をご紹介します。こちらで断定はしません。
個人情報の置き場所。 どのデータをどこに、どれだけ置くかを、作り始める前に決めて書面にします。あとから移すのは、たいてい大ごとになります。
お客様にお出しする文章。 メールや帳票の文面は、必ず人が読んでから出します。
「AIが作ったので分かりません」とは、申し上げません。そう言わないために、この手間はかけています。
こうした「作ったあとまで見る役割」が外部CTOや技術顧問とどう違うのかは、FDEとは何か──外部CTO・技術顧問・SESとの違いに整理しています。
運用が始まったあと、月1回点検します
作って終わりにはしません。月1回、この3つを点検します。
1. 外部サービスの仕様変更を確認する。 決済・地図・メール配信・認証。こういうものは、こちらの都合と関係なく変わります。「何もしていないのに動かなくなった」の大半はこれです。
2. エラーの記録を確認する。 画面には出ていない不具合が記録に残っていることがあります。使っている方が気づく前に直します。
3. 御社の変化を反映する。 組織が変われば見られる範囲が変わり、制度が変われば帳票が変わります。
不具合が見つかった場合は、ご連絡をいただく前に、こちらから連絡します。
正直に申し上げると、AIで作れる量が増えたぶん、ここの重みは増しました。小さいものでも数が増えれば、それぞれが壊れる可能性を持ちます。
だから、作る前に「これは何年使うものですか」と必ずお伺いしています。3ヶ月だけ使うものと、5年使うものでは、作り方も守り方も変えるべきだからです。
ここは、早くなっていません
「5日で動く」と「5日で使える」の違いを、具体的に書きます。
承認や例外の決めごと
「部長がご不在のときはどうするか」「この取引先だけ締め日が違うが、例外として扱うか」。
こうしたことは、社内でご相談いただく時間が必要です。決まっていないときは、こちらから「ここが決まっていません」とお伝えして、いったん止まります。急かすことはしません。
作る側が数時間で直せても、決めるのに2週間かかるなら、待ち時間はそちらになります。ここは正直に申し上げておきます。
データの引っ越し
地味ですが、一番時間を使う工程です。
同じ会社名が「株式会社◯◯」「(株)◯◯」「◯◯」の3通りで入っている。使われなくなった列に大事なメモが残っている。担当者が独自に付けた記号が、実は「要注意先」を意味している。
こちらで機械的に候補を一覧にしてお出しできますが、「この2件は同じ会社か、別か」を判断できるのは、その取引をご存じの方だけです。迷う分だけご確認いただくことになります。
現場への切り替え
新しい手順を誰がいつ教えるか、旧手順をいつ止めるか。手順書はこちらで作りますが、実施のご判断は御社になります。
新旧を並行して動かす期間が長引くほど、現場は混乱します。「いつから完全に切り替えるか」を先に決めておくと、逆算で必要なものが見えます。
この3つで、画面が動いてから実際に使えるようになるまでに、数週間かかります。
途中でやめる場合
一括でまとめてご発注いただく必要はありません。区切りまでの分をお支払いいただく形で、その先には進みません。
最初の区切りは5日目です。 動く画面をご覧いただいたうえで、続けるかどうかをご判断いただけます。
それから、作ったものは御社のものとしてお渡しします。 中身も、どういう考えで作ったかの記録も、御社側に置きます。他社様に引き継いでいただくことも可能です。
3,000万円のときの契約は、途中で止められない形になっていました。9ヶ月かけてから「思っていたのと違う」と気づくより、5日目でご判断いただけるほうがいいと考えています。
よくいただくご質問
「AIが書いたコードって、大丈夫なんですか」
「誰が書いたか」より「どれだけ確かめたか」で決まると考えています。人が書いたコードでも、確認していなければ同じように壊れます。
やっていることは、さきほど書いた3つ（機械で調べる／本番と同じ環境で実データで動かす／チェックリストでお渡しする）と、お金・法律・個人情報・対外文書の4つを人が確認することです。
御社の側で中身を読める必要はありません。「ちゃんと動くか」を見ていただければ十分です。
「うちみたいな小さい会社でも頼めますか」
これまでは、規模が小さいほど頼みにくい構造がありました。数百万円から1,000万円規模の投資が前提だと、小さな会社ほど手を出せません。
最初の画面が5日で出せるようになって変わったのはそこで、まず小さく作って、使ってみてから広げることができるようになりました。
いきなり全社の基幹システムから始めるのではなく、一部署の一つの業務から試していただくことをお勧めしています。最初に大きく始めて途中で方向が変わるのが、いちばん時間もお金も失うパターンです。
「作ってもらっても、社内で使ってもらえないのでは」
そうならないために、2週目から現場の方に触っていただくようにしています。
決裁される方と、実際に毎日使う方では、見るところが違います。完成してからお披露目するのではなく、まだ粗い段階でお見せする。
粗い段階のものを見せられると「まだこんなものか」と思われるのでは、と心配される方もいらっしゃいます。実際は逆で、まだ変えられる段階で意見を言えたほうが、使う側は自分のものだと感じてくださることが多いです。
「今の担当者が辞めたら、分からなくなりませんか」
作ったものは御社のものとしてお渡しし、どういう考えで作ったかの記録も御社側に置きます。
そのうえで、いま起きている変化についてもお伝えしておきます。以前は、他人が書いたものを読み解くのに何ヶ月もかかりました。いまはAIが読み解きを手伝ってくれるので、引き継ぎのハードルはかなり下がっています。
とはいえ「だから大丈夫です」と言い切るつもりはありません。引き継げる状態にしておくこと自体を、こちらの仕事に含めています、というのが正確なところです。
「5日で作ったものって、作りが雑ではないですか」
5日で出すのは、その時点で必要な画面です。全機能を5日で詰め込むわけではありません。
一覧・登録・検索の3つに絞って、そこだけきちんと動く状態にします。そのうえで、2週目から「一括で取り込む」「印刷する」といった画面を足していきます。
作りの中身についても、後から足せるように組んでいます。ここを雑にすると、3周目あたりで直せなくなって、結局最初から作り直すことになるからです。それが分かっているので、見えない部分ほど最初に決めています。
逆に、見た目の細かい調整は後回しにしています。5日目のものは配色や余白が整っていないことがありますが、そこは中身が固まってからでも直せるので、優先順位を下げています。
「費用はどう決まりますか」
金額は案件ごとに違うので、この記事では書けません。ただ、何にお金がかかるかは先にお伝えしておきます。
作る作業そのものは、以前よりかなり安くできるようになりました。一方で、決めごとを詰める時間、確かめる時間、データを引っ越す時間、現場の方に慣れていただく時間は、圧縮できていません。
ですので「AIだから全部が何分の一になります」というご説明はしていません。それを言ってしまうと、後で必ず食い違います。
安くなった分は、確かめる工程にまわしています。以前は確認に時間をかけるほど納期が延びるので、どこかで妥協するしかありませんでした。いまは作る時間が短くなったぶん、同じ納期でも確認の回数を増やせます。
お支払いも、区切りごとです。最初にまとまった金額をお預けいただいて、あとは出てくるのを待つだけ——という形にはしません。
なお、運用が始まったあとの月1回の点検は、最初のお見積もりに入れてお出しします。あとから「保守費用が別途かかります」とはなりません。
向いている場合と、向いていない場合
正直に書いておきます。
向いていると思うのは、いまExcelや紙で回していて、そろそろ限界だと感じている場合です。すでに業務が動いていて、そのやり方をご存じの方が社内にいらっしゃる。この場合は、早く形にして触っていただくのがよく効きます。
あまり向いていないと思うのは、業務そのものがまだ固まっていない場合です。何をやるか自体を探している段階だと、システムより先に決めることがあります。この場合は、無理に作らずに業務の整理からご一緒することもあります。
もうひとつ、社内で週30分も時間を取れない場合も難しいです。触っていただけないと、こちらは推測で作るしかなくなり、結局9ヶ月かけて外すのと同じことが起きます。
このあたりは、最初のご相談のときに正直にお話しするようにしています。合わないと思ったときに「できます」と言うほうが、後々おたがいにつらいので。
おわりに——聞いてみていただきたい一問
もし今、システムの発注を検討されているなら、依頼先を選ぶときにひとつだけ聞いてみていただけたらと思います。
「最初に動く画面を見せてもらえるのは、いつですか」
その答えが半年後なら、私が3,000万円で経験したのと同じことが起きるかもしれません。仕様書の段階で全部を思い出すのは、少なくとも私にはできませんでした。
依頼先が私たちでなくても構いません。ただ、この一問だけは聞いてみていただきたいと思っています。
もし「要件が固まってからでないと着手できません」という答えが返ってきたら、そこは正直な会社だと思います。実際、従来のやり方だとそうなります。
ただそのときは、固めた要件が本当に合っているかを、どこで確かめるのかを続けて聞いてみてください。その答えが「完成したときに」であれば、私が9ヶ月待って経験したのと同じ構造になっています。
なお、権限の設定でつまずかないための考え方は、22の権限定義を調べて作った共通設計にまとめてあります。
この記事のポイント
- 私たちの日程は、1日目：打ち合わせ1時間（見せていただくだけ）／5日目：動く画面／2週目以降：週30分の確認／1ヶ月目：権限とデータの準備。「ここを直したい」の反映は1〜2時間です
- 5日目に出てくるのは絵ではなく、一覧・登録・検索の画面とテストデータ、そしてブラウザで開けるURLです
- 御社にお願いするのは、1日目に1時間、以降は週30分、それと決めごとへの○×。どれもシステムの知識は要りません
- 「できました」と言う前に、機械での検査／本番と同じ環境での実データ動作確認／チェックリストのお渡しの3つを通します。お金・法律・個人情報・対外文書は必ず人が確認します
- 一方で、承認や例外の決めごと・データの引っ越し・現場への切り替えは早くなっていません。画面が動いてから実際に使えるようになるまで、数週間かかります。日経コンピュータの調査で今も不満の筆頭が「要件定義が不十分」であることからも、ここは順番を変えて向き合うしかないと考えています
伊藤翔太 株式会社IIWAYO.TECH 代表取締役 / 株式会社リサスティー 代表取締役