AI時代だからこそ、顧客体験からのフィードバックまでを開発のサイクルにする

2026.11.11#受託開発 #開発体制 #生成AI #プロジェクトマネジメント

2026年11月6日、songmu さんの次の投稿が X で広く読まれました（元の投稿）。

AIを使って局所最適化されたスプリントサイクルをより速く回すのではなくて、顧客体験とフィードバックまで巻き込んだより大きなループを作れるかどうかというのがより大事になってきている。

同じ日、私たちも社内の面談で同じ話をしていました。お客様の業務アプリの運用が始まり、想定していなかったことがいくつも起きた件の振り返りです。面談では、開発の1サイクルを「作ったところ」ではなく「お客様の業務で運用が回ったところ」で区切ると決めました。songmu さんの言う「より大きなループ」は、私たちにとっては、お客様の現場のオペレーションや開発以外の部署まで巻き込んで、このサイクルを速く回すことだと考えています。

運用が始まってから見えてきた業務

最近リリースしたお客様の業務アプリで、運用が始まると、開発中には知らなかった業務がいくつも出てきました。お客様の現場では、ヒアリングで話に出なかった手続きが日常的に行われていて、画面や機能の作りがその手続きに合っていない箇所がありました。

この案件を担当したエンジニアのすーざんは、面談でこう話しています。

普段やっている業務に乗せたオペレーションで1回回さないと、絶対に漏れが出ると思いました。

どれも、作る前のヒアリングと要件定義の段階では分からなかったことです。お客様の実際の業務の中で使ってもらって、初めて分かりました。

こうした業務を見つけるには、お客様と実際に会い、オペレーションを一緒に確かめる必要があります。そのうえでお互いに意見を言い合いながら、ソフトウェアの使いやすさと価値を高めていかなければならない。私たちはこの件から、そう考えるようになりました。

「作るところまで」で区切っていた開発の流れ

面談で私たちがまず反省したのは、作るところまでしか考えていなかったことです。これまでの開発は、ヒアリング、要件定義、開発、テスト、リリース、保守運用の順に進めていました。テストの工程では、お客様の業務で使われることを想定して確認していました。それでも、運用が始まると業務に合わない箇所が出てきました。原因は、現場でオペレーションを担う方とのコミュニケーションが足りず、実際に作業する方を開発に巻き込めていなかったことにあります。

以前は、この抜けが表に出にくかったとも考えています。リリース後に業務と合わない箇所が見つかっても、システムを直すより運用の工夫でしのぐことが多く、開発者が相談されないまま現場で処理されていた手続きもあったはずです。それでも運用でしのいだ分は、あとで改修や保守をするときに、私たち自身の負担になって返ってきます。

AI で作るのが速くなって変わったこと

AI を使うようになって、作る速さは大きく変わりました。弊社のフォーム管理サービス INQBOX は、最初のプロトタイプが1日ほどでできました。ただ、そこからリリースするまでには1週間ほどかかっています。それらしい形になるまでは速く、細部を詰める段階で時間を使います。

作るのが速くなれば、作り直すのも速くなります。運用で見つかった問題を、運用の工夫でしのがずにシステムの側で直すことが、現実的な選択肢になりました。そうなると、開発会社がリリースで手を離す理由はなくなります。運用で問題を見つけて直すところまでを同じサイクルで回すほうが、お客様の業務に合ったシステムに早くたどり着きます。

songmu さんの投稿にある「局所最適化されたスプリントサイクル」は、開発チームの中だけで閉じたサイクルだと私たちは読みました。作って納めて終わる開発はもちろん、PoC で小さく作って試すやり方も、確かめているのが「作ったものが動くか」までなら、同じく開発の内側のサイクルです。お客様の業務が回るかどうかは、実際にその業務を担う人に使ってもらわなければ分かりません。

作る速さがどれだけ上がっても、使われないソフトウェアを生産したところで、何の意味もありません。だからこそ、songmu さんが挙げている顧客体験とフィードバックが重要になります。使う人が実際の業務でどう使い、どこで困ったのかを知り、それを次の修正につなげる。そのためには、作ったものを使う人の手に渡し、その声を聞くところまでをサイクルに含める必要があります。

これまでの受託開発では、実際に「作る人」と実際に「使う人」が直接コミュニケーションを取ることは、なかなか難しいものでした。いまは AI によって作る側の作業の自動化が進み、使う側の業務もある程度は自動化される時代です。だからこそ、作る人と使う人が直接やり取りする開発が実現できるのではないかと考えています。作る人が使う人に直接アプローチし、使う人を巻き込んだサイクルを作ることが、ソフトウェアの価値を上げる方法ではないでしょうか。

そこで私たちは、開発者とお客様の窓口の担当者だけでなく、現場のオペレーションを担う方や、開発以外の部署の方まで巻き込んでサイクルを回すことにしました。サイクルを大きくしても、AI で作り直しが速くなった分、回す速さは保てます。大きなサイクルを速く回して、業務の現場からフィードバックをもらう。これが、投稿と私たちの反省が重なるところです。

運用が回るところまでを1サイクルにする進め方

これからは、次のように開発を進めます。

開発の段階で、お客様が普段行っている業務の流れを、現場で業務を担う方からあらためてヒアリングする
リリースの前に、お客様の実際の業務にシステムを乗せて1回通して回すオペレーションテストを、現場の方や関係する部署の方と一緒に行う
オペレーションテストで見つかった問題を直し、お客様と「これで業務が回る」と確かめたところでサイクルを完了とする

オペレーションテストは、本番の前のリハーサルにあたります。こうした場面では、オンラインだけで済ませず、お客様の現場に実際に伺います。現場の方と一緒にスマートフォンやパソコンを触りながら問題点を確かめ、直せるものはその場で修正してリリースします。

私たちはフルリモートで開発している会社ですが、要件定義の前のヒアリングでも、対面でのコミュニケーションを大切にしています（要件定義前の「対面ヒアリング」を大切にする理由）。最初のヒアリングは業務を理解するための工程で、オペレーションテストは、その理解が正しかったかを実際の業務で確かめる工程です。どちらも、お客様と同じ場所で同じ画面を見ながら進めます。

作っているメンバーの顔が見える体制

現場に伺うのは、お客様に、作っているエンジニアの顔を覚えていただくためでもあります。お客様にとって、システムを作るのが「誰でもいい」エンジニアではなく、顔と名前の分かるメンバーであることが大切だと私たちは考えています。誰が作っているのかをはっきりさせるところは、ほかの受託開発の会社と違う点かもしれません。

これができるのは、メンバー一人ひとりが、Web アプリのディレクションから実装までを責任を持って担えるからです。現場で問題点を聞いたエンジニア本人が、その場で修正してリリースできます。