ベンダーを動かすのは仕様書ではない——事業者が磨くべき「課題を語る力」

なぜシステムは「使われないまま」になるのか

よくある失敗がある。半年かけて導入したシステムが、現場でほとんど使われない。機能に問題があったわけではない。他社では評判のいいツールだ。それでも現場に定着しなかった——という経験を持つ事業者は珍しくない。

理由のひとつは、ベンダーが「何を作るか」しか知らなかったことにある。どんな業務で、誰が、なぜ困っているのか。その文脈が最初から共有されていなければ、ベンダーは仕様書に書かれた通りのものを届けるしかない。

ベンダーの本来の仕事は、システムを開発することではない。ドメイン知識——その業界・業務の構造を深く理解したうえで課題を解くことにある。しかし、事業者側から課題が正確に渡されなければ、どれだけ技術力の高いベンダーでも空回りしてしまう。失敗の原因は、ベンダーの能力ではなく、課題の渡し方にあることが多い。

事業者が「ITを学ぶ」とはどういうことか

「事業者もITを学ばなければならない」という話になると、多くの場合、プログラミングやシステム設計の知識が連想される。だが、事業者に必要なのはそこではない。

必要なのは、問いを立てる力だ。

次のような問いを、自分の言葉で整えられるかどうかが、発注の質を大きく左右する:

1. 何が課題で、なぜ今それを解決したいのか
2. 解決できたとき、業務はどう変わっているか
3. 現場の誰が、どのタイミングで困っているのか

この問いが整っていない発注は、ベンダー側から見ると「なんとかしてほしい」と変わらない。仕様を推測しながらプロジェクトを進めることになり、認識のズレは完成間際に浮上する。

AIや自動化ツールの導入でも同じ構図が繰り返される。どのツールを選ぶかより先に、「どの作業を手元に残し、どこを機械に渡せるか」という整理が要る。その整理なしにツールを入れても、現場の使い方は定まらない。AIへの仕事の渡し方については、AIに任せた仕事をどう受け取るかでも詳しく取り上げている。

ITやAIのことを学ぶとは、技術の詳細を理解することではない。「自分の業務のどこが変えられるか」を問える状態になることだ。その感覚を持った事業者と持っていない事業者とでは、同じベンダーに頼んでも、結果が大きく変わる。

対話が始まるとき、プロジェクトが変わる

発注書や要件定義書を渡すことがプロジェクトの始まりだ——そう考えている事業者は少なくない。しかし、書類を渡す前に、言葉のやり取りが必要だ。

ベンダーに「課題を語る」ことができれば、最初の打ち合わせは受発注の場ではなく、対話の場になる。

対話の場では、ベンダーも業務の文脈を知ることができる。事業者もITの可能性と限界の輪郭をつかむことができる。この相互理解の積み重ねが、プロジェクトを現場の実態に即したものにしていく。

ITやAIを取り入れた会社とそうでない会社の差は、技術力の差である前に、対話の質の差であることが多い。何を変えたいのか、そのためにどんな情報が必要か——それをベンダーと共有できるかどうか。そこから、すべての実装は始まる。

ベンダー選定の前に整理すべきことについてはベンダー選定で使える問いの立て方でも触れている。

事業者とベンダーの関係を、発注と受注の対面から共同作業の横並びへ変えることは一朝一夕ではできない。しかし、最初の一歩は意外とシンプルだ。「なぜ、これが課題なのか」を自分の言葉で話せるようにすること。それだけで、プロジェクトはまったく違う形で動き始める。

DX推進の伴走支援についてはしぼるで詳しく紹介している。