最初の案件で、お客様に激怒された
「こんな仕様では頼んでいない！3ヶ月待ってこんな状況か！」
RPA開発者として現場に入って間もない頃でした。前任者から引き継いだ案件でデモを見せた瞬間、お客様の怒りが爆発しました。
状況はこうです。前任者が残した仕様書とシナリオを見ると「あと少し手直しすれば完成する」ように見えました。前任者には確認できない状況で、わたしはドキュメントを信じて開発を進め、デモを見せました。
結果、仕様書がお客様と合意されていないまま作られた代物だと判明しました。前任者は自分の思い込みで仕様書を書き、お客様には見せていなかったのです。
どう対応したか。「引き継いだのでわかりません」とは言いませんでした。それは不誠実だと思ったからです。「申し訳ございません、お話を再度聞かせていただけないでしょうか」と頭を下げ、1からすり合わせをしました。
その後、RPAは完成しました。できないことは「このステップを踏めばある程度できます」「この部分は人が判断してください」と切り分けながら誠実に向き合いました。
お客様との関係は、今もそのRPAが稼働しているだけでなく、複数の追加発注をいただき、最終的にはゴルフに行くほどの信頼関係になりました。
最初の炎上案件が、逆に最良の顧客を生んだ。これがわたしの方法論の原点です。
「間に合わないな」と感じる瞬間には、2つのパターンがある
6年間RPA開発に関わり、他のメンバーの案件を見ていると、炎上する前に「ああ、これは厳しいな」と感じる瞬間があります。パターンは2つです。
パターン①：仕様の煮詰めが甘い
お客様との仕様確認が不十分で、開発者の思い込みで進んでいる状態。納品日から逆算したとき「これは揉める」と直感的にわかります。
パターン②：工数80%消化・デモ未実施
1人月の工数なのに残り1週間、まだお客様にデモを見せていない状態。出直しや仕様変更が起きるかもしれないのに、終盤に突入しています。
どちらに気づいても、対処法は同じです。すぐにお客様に連絡を取り、現状を正直に話してすり合わせをします。工期に間に合わなかったケースもありました。それでもクレームにはなりませんでした。なぜなら、問題を隠さず、誠実に対話したからです。
この2つのパターンに気づいたのは、自分の案件だけを振り返ったからではありません。チームで動いている以上、メンバーの案件が炎上すればわたしも対応に入ります。「仕様の煮詰めが甘かった」「デモを見せるのが遅すぎた」——どのケースを振り返っても、根本原因はこのどちらかでした。他人の炎上処理ほど、方法論の輪郭がはっきり見えます。
方法論①：バックエンドを捨てて、まず動くものを見せる
RPAの開発でお客様が見たいのは「アプリケーションをどう操作するか」という見える動きです。
しかし実際に時間がかかるのはバックエンド側——条件分岐、ループ、データテーブル処理といった目に見えない部分です。
わたしがとるやり方はこうです。バックエンドをあえて切り捨てて、まず表側だけを動かします。
デモでの伝え方はこうなります。「今回のデモはTRUEの動作をします。FALSEの場合はこの動きが変わるだけです」と明確に説明します。
「こんな段階で見せるの？」と言われたことは1度もありません。
むしろ逆の反応がほとんどです。動くものを見た瞬間に「これを言い忘れていた」「こういうことはできるか？」と具体的な話が出てきます。頭の中にあった曖昧なイメージが、動くものを見ることで初めて言語化されるのです。
**総工数の30〜50%でデモを作る。残り工数でどこまで追加仕様を吸収できるか判断する。**これがわたしのやり方の核心です。
方法論②：仕様書を「盾」にする
追加要望が出たとき、感情で応じてはいけません。仕様書に書かれていることを根拠に動きます。
「記載がないので改めてすり合わせをさせていただけないでしょうか」
これだけです。責めているわけではありません。単に事実を確認しているだけです。
仕様書の書き方で徹底していることがあります。曖昧な表現を一切入れない。 数字、条件分岐の条件式、ループの条件は「誰が見てもそうなる」と言える表現で端的に書きます。どちらともとれる表現が「こんなはずじゃなかった」を生みます。
ウォーターフォールでもアジャイルでも、双方の認識が合意されて書面に残っていることが理想です。
方法論③：ボリュームを確認してスコープをコントロールする
デモ後に追加要望が出たとき、最初に確認することは「ボリューム」です。
「100件中10件の話ですか、それとも80件の話ですか？」
- 複雑かつボリュームが大きい → 開発する意味あり
- 100件中1件しかない → 「やめた方がいいです」と伝える
さらに「まず50件でも問題なく動くものを作りましょう」とスモールスタートを提案します。一気に全機能より、段階的な方が時間も費用も抑えられると説明します。
デモを作る過程でシステム操作の難易度はある程度わかります。要望の内容がどのくらいのバックエンドを必要とするかで、その場で判断します。難しい場合は「1度持ち帰って確認してから伝えます」でかまいません。
この方法論は技術ではなく「姿勢」
この方法論をチームメンバーに伝えたことがあります。全員には広まりませんでした。
自分ごととして捉えてくれた人には広まり、そうでない人には広まりませんでした。
理由はシンプルです。これは技術ではなく姿勢の問題だからです。 仕様書の書き方もデモの見せ方も、「お客様と誠実に向き合う」という前提がないと機能しません。
禅の思想がしっくりくる表現があります。「仕様書を盾にする」と「コミュニケーションが大事」は一見矛盾に見えますが、両輪です。どちらかに振り切った瞬間に崩れます。ルールに逃げてもダメ、感情で動いてもダメ。その緊張関係を保ち続けることが本質です。
AIの時代だからこそ、人との関係が差別化になる
わたしがこの方法論を大切にするのは、AIが普及した今の方が、むしろその重要性が増すと感じているからです。
コードを書くことはAIが代替していきます。でも「お客様が本当に何を望んでいるか」を引き出す対話は、人間がやるしかありません。
現在、この方法論のAI活用版を作ろうとしています。
- 打ち合わせの内容 → AIが仕様書のたたき台を生成
- UiPathのXAMLファイル → AIがコードレビュー（仕様書との乖離・問題のある実装・改善提案）
コードレビューは時間がかかります。AIで速度を上げることで、問題を素早く共有・改善できる仕組みを目指しています。
民主化できる部分はAIで仕組み化します。民主化できない部分——人との信頼関係——はわたしの強みとして磨き続けます。
この切り分けが、わたしの方法論の現在地です。
まとめ：6年間、クレームがなかった理由
- デモは早く・部分的に見せる（30〜50%工数で）
- 仕様書に書かれていないことは根拠にして対話する
- ボリュームを確認してスコープをコントロールする
- 誠実に、隠さず、早く伝える
この方法論はRPAに限りません。Webサイト制作でも、AIツール開発でも、「お客様が本当に何を望んでいるか」を引き出す姿勢は変わらないと思っています。
技術が高くなくても、この姿勢があればクレームは防げます。逆にどれだけ技術が高くても、この姿勢がなければ炎上します。
最初の炎上案件で激怒してきたお客様と、今でも良い関係が続いています。それが答えだと思っています。