見出し画像

#問いの設計|構想は翻訳である

DXの構想を描くとき、私たちはつい「完璧な全体像」を求めてしまいます。 すべてのシステムがシームレスに繋がり、データがリアルタイムで統合され、現場から経営まで滞りなく情報が流れる未来。 それ自体は目指すべき理想ですが、最初の一歩としてそこを見据えすぎると、足元がすくんでしまいます。

構想とは、本来、最初からすべてを「描き切ること」ではありません。 要件定義という硬い箱に押し込む手前で、まだ輪郭が曖昧な状態のまま、「私たちは何を解決し、どこに向かいたいのか」を共に見通し、考えること。 そこにこそ、DX初期設計の本質があります。


構想とは、翻訳である

現場の言葉と、経営の言葉。 これらは同じ日本語を話しているようでいて、その実、根本的なOSが異なります。

経営やシステム部門は、全体最適、効率化、稼働率の向上といった「数字と方向」を語ります。 一方で現場は、日々のイレギュラーな対応、画面の入力の手間、長年培ってきた判断の勘所といった「手触りのある現実」を語ります。

たとえば、製造の現場に新しいシステムを導入する際、経営側は「全工程のデータを一元化し、リアルタイムで製造原価や進捗を把握したい」と願います。しかし現場から見れば、「なぜ今の作業に加えて、システムへの入力という新たな手間を増やさなければならないのか」という痛みが先に立ちます。

どちらが正しいわけでもなく、どちらも真実の断片を持っています。 だからこそ、両者の言葉をそのままぶつけても、話が通じ合うことはほとんどありません。

私たち業務設計者の役割は、その「すれ違い」の間に立ち、言葉を翻訳することです。

経営の語る「全体最適」という無機質な言葉を、現場が納得して動ける「日々の入力が少し楽になり、探し物の時間が減る手順」に落とし込む。 同時に、現場が抱える「やりづらさ」や「工夫の知恵」を、経営が投資判断を下せる「ボトルネック解消のためのロジック」に変換する。

それは単なる情報整理や伝言ゲームではありません。 相手の文脈を理解し、意図を保ちながら、もう一方の部族が受け取れる言葉へと形を変える作業。 つまり「翻訳」と呼ぶにふさわしい、高度で泥臭い営みなのです。

20%の構想で始める

翻訳という作業には、相手とのキャッチボールが不可欠です。 最初から分厚い仕様書や、完璧な要件定義書で正しい言葉を伝えようとするより、まずは20%の完成度で形にしてみることです。

たとえば、業務の一部だけを簡易的なノーコードツールなどでデジタル化してみる。 それを現場に触ってもらい、「ここは使いにくい」「この情報はあとで必要になる」といった生の反応を引き出す。そのフィードバックを受け取り、システムの言葉へと再翻訳しながら、少しずつ目的地を補正していく。

最初から100%の完成図を狙えば、言葉はそこで固定化され、関係性は止まってしまいます。 未完成なままのプロトタイプを差し出し、相手の反応というデータを拾い集める。 その試行錯誤の往復こそが、経営と現場をつなぐ「共通言語」をつくるプロセスであり、構想を育てるということなのだと思います。

スキマを読む、余白を残す

DXの設計において、すべてのプロセスをシステムで埋め尽くすことが最適解とは限りません。 むしろ、業務と業務の間にあるスキマの意味を読み取り、そこに意図的な「余白」を残すことが重要になります。

仕組みをガチガチに固めすぎると、現場がイレギュラーな事態に直面したとき、システムが思考を奪い、身動きが取れなくなってしまいます。 逆に、あえてシステム化しない余白を残し、不要な手順を「引き算」することで、現場の工夫や新しい発想が入り込む余地が生まれます。

構想とは、すべてを自動化する完璧な設計図ではありません。 人が人として機能し、判断し、動けるようにするための設計です。

業務設計者の価値は、この「余白の翻訳力」にあります。 現場の実態と経営の理想、その間に漂う言葉にならない違和感をすくい取り、それぞれが納得して歩き出せるように、システムと人の境界線を引いていくのです。

構想は、歩きながら磨かれる

DXを進めるということは、単に新しい技術や高価なツールを導入することではありません。 それは「人としくみの関係性を、もう一度設計し直すこと」に他なりません。

構想とは、ゴールを示す完成図ではなく、現在地と方向を示す翻訳図です。 共通の目的地を見いだし、摩擦を恐れずに歩きながら、ズレを補正していくためのコンパスのようなものです。

では、あなたの組織において、その「翻訳」は誰が担っているでしょうか。 そして、あなた自身は今日、どの文脈の言葉を、どちらの世界へ届けているでしょうか。


🍵 関連記事:思考のOSをさらにアップデートする

なぜシステムと現場の間に「隙間」が生まれるのかを知りたい方へ #業務設計者論|業務でもITでもない、しくみの“スキマ”に立つ

現場の文脈を、ITの言葉へ変換するスキルについて #業務設計者論|翻訳者はしくみの言葉を編む

現場と経営の間で、翻訳コストを払い続けている方へ 板挟みの正体は「能力」ではなく「構造」にある─上司の数字と現場の感情を翻訳するコスト

ツール単体の機能ではなく、それらがどう連携し情報がバトンパスされるかを考える視点 #しくみのスキマ |情報の連携がしくみをつなぐ


いいなと思ったら応援しよう!