16時間で終わった案件です。うち、コードを書いていたのは4時間ほどでした。
Googleスプレッドシートの顧客台帳と、毎月の報告書づくりをGoogle Apps Scriptで自動化した記録です。作る対象がはっきりした、規模の小さい案件でした。ヒアリングは1時間で足りています。
ところが実物を提出業務に使ってもらった瞬間、ヒアリングでは一つも挙がらなかった要件が7件出ます。登録番号がセルの中で日付に化ける。提出日は和暦で書く。設備の欄に書くのは型式ではなく処理区分。どれも見れば1分で分かり、聞いても出てこない種類のものでした。
残りの12時間が、どこに消えたのかを書きます。
設備の法定点検を行っている事業者からの依頼です。顧客台帳と点検記録をGoogleスプレッドシートで管理し、毎月、複数の行政窓口へ点検実績の報告書を提出しています。
手作業だったのは次の四つでした。
依頼内容としては、これ以上ないほど明確な部類です。作る対象は目の前のスプレッドシートにあり、出力すべき様式も現物があり、業務のサイクルも毎月同じです。実際、ヒアリングは1時間で済みました。
本稿の事例は実際の案件をもとにしていますが、依頼者が特定されないよう、業種・提出先・件数・工数はいずれも実際から少しずらしています。設計上の判断と、出てきた要件の性質は、実際のものです。
にもかかわらず、この案件の工数の三分の二は、ヒアリングの時点では存在しなかった要件に使われました。本稿はその記録です。
1時間の打ち合わせで確定したことと、確定しなかったことを並べると、境目がはっきりします。
確定したこと。どのシートを使うか。検索を三種類つけること。提出先が三つあること。月次のサイクルがどう回っているか。つまり、何を作るかです。
確定しなかったこと。それぞれの様式の、どの欄に、何を、どういう書式で書くか。つまり、作ったものが正しいかどうかを判定する条件です。
この境目は、依頼者の説明が不十分だったから生まれたのではありません。三つの理由が重なっています。
一つ目は、当人にとって当たり前すぎる項目は、言語化の対象にならないことです。この案件では、事業者の登録番号が該当しました。毎月、報告書の決まった欄に手で書き込んでいる番号です。手が覚えている作業は「入力すべき項目」として意識に上らないため、「何を自動化したいか」を聞かれたときに出てきません。
二つ目は、依頼者自身も正確には覚えていないことです。提出日を和暦で書くか西暦で書くかは、現物を前にすれば即答できますが、記憶から取り出すとなると自信を持って答えられません。曖昧な記憶で答えるくらいなら言わない、という判断は合理的です。
三つ目は、様式の現物を見ても分からないことです。記入例のない空欄には、そこに何を書くのが正解かが書かれていません。設備の記載欄に型式を書くのか処理区分を書くのかは、様式を眺めても決まらず、その窓口に実際に提出して受理された経験の中にしかありません。
要件定義という工程に「曖昧さをゼロにする」ことを求める限り、この三つは埋まりません。この構造については「プロジェクト失敗の原因は要件定義」を100回見聞きしたに書いた通りで、規模が小さくなっても性質は変わりませんでした。
要件を「何を作るか」「どの欄に何をどう書くか」「どう運用し続けるか」の三層に分け、各時点でどこまで確定しているかを並べている。
確定する範囲は、聞いた回数ではなく、顧客が何を見たかで決まる。
聞き取りを重ねても上の三つは埋まらないので、聞くのをやめて作りました。1周目に使ったのは5時間です。
作ったものは次の通りです。
ここで重要なのは、モックにしないことです。1周目の目的は「顧客に理解を進めてもらうこと」なので、画面の絵だけでは何も進みません。実際の台帳の実データが通り、実際に窓口へ持っていける形式のExcelが出るところまで作ります。そこまで作って初めて、依頼者は「これは違う」と言える状態になります。
開発はローカルで行いました。Google Apps Scriptのエディタで直接書くのではなく、claspでローカルに落としてGitで管理し、Claude Codeで実装しています。この選択には後で効いてくる意味があるので、後半で改めて書きます。
1周目を実際の提出業務で使ってもらいました。出てきた指摘は次の7件です。
#REF! が並びます。数式が外部のシートを参照したまま書き出されるためでした。一時的なスプレッドシートに対象シートだけをコピーし、数式を値に確定させてからxlsxとして書き出し、最後に一時ファイルを消す、という手順に変えています7件のうち、ヒアリングで挙がっていたものは一つもありません。そして7件とも、実物を前にした依頼者は即座に、正確に指摘できました。迷いも、検討の時間もありません。
この非対称が、本稿で一番言いたいことです。同じ人間が、同じ業務について、聞かれても答えられず、見せられれば1分で答えられる。要件を引き出す手段として、質問と実物では、引き出せるものの種類がそもそも違います。
なお7件の内訳を見ると、1・6・7は依頼者からは「なんだかおかしい」としか出てこない類のもので、原因の特定はこちら側の仕事です。2・3・4・5は業務知識の側にあり、依頼者にしか判定できません。1周目の実物は、この両方を同時に表に出します。
この案件で実際に挙がった要件を、出てきた経路で分けている。実物で出た7件は、ヒアリングでは一つも挙がらなかった。
同じ人が、聞かれても答えられず、見れば1分で答えられる。質問と実物では、引き出せる要件の種類が違う。
2周目に使ったのは10時間です。前半は上の7件の反映で、後半はデータ構造の作り直しに使いました。
運用に乗せてから見えたのは、点検記録を1枚のシートに積み続ける構造が、月次の提出サイクルと噛み合っていないことでした。提出が終わった月の記録と、今まさに入力している月の記録が、同じシートの中に混ざったまま増え続けます。件数が増えれば当然、片付けたくなります。そして片付けようとした瞬間に、消してはいけない行を消せてしまう構造でした。
これを運用ルールで解こうとすれば、5分で終わります。「このシートの行は消さないでください」と伝えればよい。ただしそれは、システムの安全性を依頼者の注意力に預けることと同じです。仕組みで解けるものを、注意喚起で済ませないという判断で、構造を分けました。
運用のサイクルは「月の途中は従来通り入力する、翌月の頭に報告書を作る、提出が済んだら月締めで蓄積用に移す」という形に落ち着きました。依頼者の入力操作そのものは、案件の開始時から最後まで一度も変えていません。
記録の置き方を作り替えた前後である。依頼者から見た入力の操作は、前後で変わっていない。
「行を消さないでください」と伝えれば5分で終わるが、それは安全性を依頼者の注意力に預けることと同じである。
この案件の工数は、ヒアリング1時間、1周目5時間、2周目と運用対応で10時間、合計16時間です。金額は10万円台の後半に収まりました。
注目してほしいのは配分です。2周目が1周目の2倍あります。
ここで、もし一般的な組み方をしていたらどうなるかを考えます。ヒアリングを終えた時点で全体を見積もり、契約し、作って納品する。この形で見積書を書いたとして、そこに前章の7件は一行も載りません。載りようがありません。まだ誰も知らないからです。データ構造の作り直しも同じです。
そうすると、実際に発生した10時間分は、追加見積りとして請求するか、こちら側の持ち出しにするかの二択になります。前者は依頼者から見れば「言った通りに作られなかったのに追加を請求された」という話になり、後者は事業として続きません。どちらも、見積りの精度が低かったせいではありません。着手前に確定できない要件を、着手前に見積もる形式を採ったこと自体が原因です。
そこで、次のように分けて置きます。
| 内容 | 何のための工数か | |
|---|---|---|
| 1周目 | 実データが通り、実際に提出できる実物を作る | 顧客が理解を進めるための工数 |
| 2周目 | 実物が引き出した要件と、運用で見えた構造を実装する | 確定した要件を実装する工数 |
言い方を変えると、1周目は「作る工数」ではなく「要件を引き出す工数」です。ヒアリングの延長線上にあります。この案件で1周目に5時間かけたのは、5時間分の機能が欲しかったからではなく、7件を表に出すために5時間が必要だったからです。ここを削れば、削った分がそのまま2周目に乗ります。
そして2周目は「直しの工数」ではありません。要件が確定したあとに、その要件を実装する工程です。手戻りと呼ぶと、防げたはずのものを防げなかった、という含意が入りますが、実物を見るまで確定しない要件に対して、これは正確ではありません。
規模が小さい案件ほど、この組み方が効きます。1周目のコストが低いからです。5時間で捨てられる実物が用意できるなら、打ち合わせを3回重ねて様式の解釈を詰めるより速く、そして安く終わります。「小さい案件だから2周する余裕がない」というのは、順序が逆になっています。
この考え方自体は、本サイトでキャリブレーション開発モデルとして書いてきたものです。1周目で誤差を測り、2周目で収束させる。エンタープライズ規模の開発プロセスとして提示した仮説ですが、16時間の案件でも同じ形になりました。むしろ、規模が小さいほうが、周回の境目がきれいに出ます。
工数の話をもう少し細かくします。合計16時間の内訳は、おおよそ次のようになりました。
| 内容 | 時間 |
|---|---|
| 業務の理解と、言語化を促すやりとり | 3時間 |
| コードを書く | 4時間 |
| 正しさの確認 ― 実データを通し、出力が様式と合うか | 3時間 |
| 使い勝手の確認と調整 | 2時間 |
| 指摘を受け取り、原因を特定する | 3時間 |
| 判断の記録を残す | 1時間 |
コードを書いていたのは、全体の4分の1です。残りの12時間は、何を作るべきかを引き出すことと、出てきたものが正しいか・使えるかを確かめることに使われています。
そして、この4時間の中身も一様ではありません。実際に手を動かしている感覚で言えば、書くこと自体は一瞬で終わります。2,000行のうち大半は、指示を出せばすぐに出てきます。4時間の大部分は、出てきたものを読み、既存のシートの入力規則や表示形式と噛み合っているかを確かめ、噛み合っていない箇所を直す時間です。
ここが、「AIを入れれば自動化できる」という要約が取りこぼしているところです。
自動化できるのは、正しさの条件が決まっている作業だけです。この案件で一番難しかったのは、正しさの条件を決めることでした。「登録番号を報告書に書き込む」までは自動化の対象です。しかし「その番号はハイフンを挟んだ数字の並びで、セルに入れると日付として解釈される」ことは、実際に出力して現物と見比べるまで、誰も知りません。「顧客番号から氏名を補完する」も自動化の対象ですが、「顧客番号は既存の入力規則との整合のために数値のまま保持し、表示だけを4桁のゼロ埋めにする」という判断は、既存シートの入力規則を読んで初めて決まります。条件が決まっていない作業に自動化という言葉を当てても、決まっていないという事実は動きません。
もう一つ、正しさの確認と使い勝手の確認は別の作業です。
この案件では、氏名の自動補完がまさにそれでした。機能としては初日から正しく動いていましたが、複数行をまとめて貼り付けたときの挙動、台帳にない番号を入れたときの表示、ゼロ埋めの見え方は、実際に何十件も入力してもらうまで詰まりませんでした。
実装が速くなったこと自体には、単独ではほとんど価値がありません。短くなったのは全体の4分の1の工程で、残りの4分の3は、人と業務に向き合う時間として残っています。むしろ実装が短くなった分、確認と対話が全体に占める比重は上がりました。「AIで自動化」という言い方は、作業のうちコードを書く部分だけを見て、その前後にある工程を見ていない要約です。
自動化できるのは、正しさの条件が決まっている作業だけである。この案件で最も難しかったのは、その条件を決めることだった。
短くなったのは全体の4分の1の工程で、残りの4分の3は人と業務に向き合う時間として残る。
では、AI駆動開発はこの案件で何に効いたのか。前章の通り、実装が速くなったこと自体ではありません。この進め方が成立するかどうかを決めているのは、1周目の単価です。
1周目に必要なのは、実データが通り、実際に提出できる形式まで出る実物です。これを人手だけで作ると、5時間では届きません。届かないなら、1周目の見積りは20時間なり30時間なりになり、依頼者から見れば「実物を見てから決める」という進め方は高すぎて選べません。結果として、聞き取りで要件を固めきる従来の形に戻るしかなくなります。つまり、速度が上がったことの本当の効果は、捨てる前提の実物を作れる価格帯に落ちたことにあります。
もう一つ、この案件で効いたのが開発環境の置き方です。GASのエディタで直接書くのではなく、claspでローカルに落とし、Gitで管理し、Claude Codeで実装しました。
小規模な自動化ほど、エディタ上で直接書いて済ませたくなります。しかしこの案件は、2周目に7件の様式差分を反映する工程が控えていました。どの記述がどの指摘に対応して入ったのかを追えないと、後から「この処理はなぜこうなっているのか」に答えられません。実際、登録番号の桁が依頼文と原本とで食い違っていた場面があり、原本を確認して原本側を採る判断をしています。こうした判断の理由をコミットに残しておくと、半年後に別の窓口の様式が変わったときに、同じ確認を繰り返さずに済みます。
Claude Codeを受託開発の中でどう回すかについては、Claude Code プロジェクトパックに、リポジトリの構成と運用の形をまとめてあります。
本サイトではFDE(フォワードデプロイドエンジニア)という職能について繰り返し書いてきました。顧客の現場に入り、顧客の環境の上で、業務が回る状態まで持っていく働き方です。Palantirの事例で知られる形なので、大規模なエンタープライズの話として受け取られがちですが、この16時間の案件でやったことは、規模が違うだけで構造は同じでした。
対応させてみます。
使った道具は、Googleの標準機能と、Claude Codeと、Gitです。特別なプロダクトは何も持ち込んでいません。FDEの価値は、持ち込むプロダクトの側ではなく、顧客の環境に合わせて業務が回る形を組み立てられることの側にあります。その意味で、身近なツールの上での業務最適化は、FDEの仕事のうち最も小さく、最も分かりやすい形だと言えます。
規模で変わるのは、関わる人数と、失敗したときの損害の大きさです。「顧客の環境の上で、顧客の業務が回る状態にする」という点そのものは、数千万円の案件でも16時間の案件でも変わりませんでした。この職能をどう捉えているかはFDE（Forward Deployed Engineer）とは？とうちのFDE - FDEという多義的な役割にまとめてあります。
本稿で書いたことをまとめます。
スプレッドシートで回っている業務を自動化するとき、最初の判断は「何を作るか」ではありません。依頼者が正しさを判定できる状態に、どうやって最短で持っていくかです。この案件では、それが5時間の実物でした。
同じ構造の業務は珍しくありません。台帳と記録がスプレッドシートにあり、提出先ごとに様式が違い、毎月の転記に半日を使っている。こうした業務の自動化や、AI駆動開発を自社の開発プロセスに組み込む進め方については、AI駆動開発の導入・定着支援「AI Delivery Scope+」でご相談を承っています。