最新技術が現場で使われない、について考える
現場課題を工学的に解決した技術が、現場では全く使われない。よく見る光景だ。
原因は技術の完成度ではなく、問題定義の構造にあると思う。今回はそのことについて考えてみたい。
◎評価軸がそもそも違う
開発側の問い：「この技術で何ができるか？」
現場側の問い：「これは今の仕事に収まるか？」
前者は機能・性能・新規性で評価するが、後者はコスト・リスク・慣れで評価することが多い。問いの形が違う以上、同じ技術を見ても評価は噛み合わないのではないか。
開発者が「現場を理解しよう」と努力しても、そもそも使っている評価言語が違えばすれ違いが続く。「技術として正しい」と「現場で使われる」は、別の問いへの答えなのだ。
◎「使わない」は氷山の一角
現場の「使いづらい」という一言の背後には、複数の層が折り重なっていると思う。
UI・学習コスト（表面） → 既存フロー・設備・システムとの干渉（統合層） → 保守・教育コスト（コスト層） → トラブル時の責任の所在（リスク層）
そして更に、根底にある 「なぜ今変える必要があるのか」という正当化コスト。
UI改善で対応しようとするのは、この氷山の上層にしか触れていない。根底にある「なぜ変えるのか」という問いに答えない限り、どれだけ磨いても採用されない。
製造現場に置き換えると分かりやすい。AIやIoTプラットフォームが中堅・中小製造業で普及しない理由も、技術の未熟さではない。
「既存のデータをどう移行するか」
「トラブル時に誰が対応するか」
「なぜ今動いているシステムを変えるのか」
これらの正当化コストが未解決のまま、技術だけが先行しているからだ。
◎ズレが解消されない3つの構造的理由
以前から「ユーザー視点を持とう」という啓発は繰り返されてきた。それでもズレが解消されない理由は、個人の意識ではなく評価・報酬構造の問題にあるのではないか。
① 評価指標が現場適合と切り離されている
研究・開発の評価は論文・特許・展示会での反響が中心だ。現場で「使われなかった」という結果が、開発者の評価に直接ペナルティとして跳ね返らない。結果、「技術として正しい」ことに最適化されたアウトプットが生まれ続ける。
② 現場側の言語化コストが高い
現場の作業者や工場エンジニアは、自分が感じている不便・限界・懸念を構造化して伝える機会も訓練もない。「使いづらい」という感覚は実在しても、それを「なぜ・どのように・どう改善すれば」という仕様レベルに落とし込む作業は、現場には本来求められていない。問題を言語化するコストを現場に転嫁している限り、本音のニーズは届かない。
③ 翻訳者が育たない
開発の技術言語と現場の業務言語を双方向に翻訳できる人材が、組織内で評価されにくい。技術開発の華やかさに比べ、現場課題を構造化して仕様に落とす作業は地味で、キャリアパスとして認知されにくいため、担い手が育ちにくい構造がある。
◎技術の価値をどこに置くか
私の過去の経験から見ても、技術の価値は「何ができるか」では確定しない。「誰の・どのコンテキストの・どの問題を・どの程度の負担で解決するか」によって初めて確定する。
これは「そうあるべき」という理想論ではなく、設計の手順と評価基準を具体的に変えることを意味する。
例えば、
- 問題の定義権を現場と共有する
- 採用コストを性能スペックと同等の設計要件として扱う
- 「使われ続けること」を成功指標にする
「高性能だが使われない技術」は、ビジネスとして失敗しているだけでなく、設計として失敗しているという認識が必要だ。
◎開発者・設計者に求められる転換
この「現場で使われない」問題を解決するには、「技術を作る人」から「現場の文脈の中で問題を解く人」へのアイデンティティの転換が必要だと思う。具体的には4つ。
【１】問題定義を独占しない
「何を作るか」を技術的可能性から逆算で決めるのをやめる。現場観察と対話から問題を共同定義する。ただし「現場の言いなりになれ」ではない。現場は自分が困っていることを正確に言語化できないことが多い。観察から問題を構造化する能力こそが求められる。
【２】採用コストを設計要件に入れる
習熟コスト・統合コスト・リスク・正当化コストの合計を、性能スペックと同じ重みで設計に織り込む。このコスト合計が技術のもたらす価値を上回れば、どれだけ優れた技術でも使われない。
【３】早く失敗する哲学を持つ
現場とのズレを事前に完全に把握することは原理的に難しい。完成品ではなくプロトタイプを現場に持ち込み、摩擦が発生するポイントを早期に可視化する。PoCの成功基準を「動いた」ではなく「現場が継続使用した」に設定する。
【４】双方向の翻訳能力を持つ
「なんとなく使いづらい」を設計変更可能な仕様に落とす（現場語→技術語）。「応答速度5ms」を「ライン停止が月に何回減るか」に変換する（技術語→現場語）。これはコミュニケーション能力という曖昧な話ではなく、構造化・抽象化・具体化の往復運動という明確な知的スキルだ。
特に【3】は重要だ。早く失敗し、PDCAを高速回転させよう。
◎個人の努力だけでは限界がある
ここまで書いてきて思ったが、これは個人の意識改革だけで解決できる問題ではない。
- 「技術的新規性」だけでなく「現場採用率・継続使用率」を開発者評価に含める。
- 現場訪問・ユーザーインタビューを任意活動ではなく開発フェーズの必須ステップにする。
- 翻訳者ポジションをキャリアパスとして制度化する
これらの構造変化なしには、個人の実践は例外的な事例に留まってしまう。
「最新技術が現場で使われない」問題は、技術力の問題ではない。「問題定義の権限、評価指標の設計、組織の翻訳能力」という構造の問題だと私は思う。
Want to publish your own Article?
Upgrade to Premium