「これを作って」を、そのまま作らない。ひとりFDEが最初に聞く8つのこと

現場から改善の相談を受けると、最初に出てくるのは、困りごとではなく「作ってほしいもの」であることが多いです。

「Excelで一覧にしてほしい」

「メールを自動で転送してほしい」

「Salesforceに項目を追加してほしい」

「AIに判定させたい」

どれも、現場が真剣に考えた要望です。

だからこそ、すぐに作ってあげたくなります。

でも私は、言われたものをそのまま作る前に、一度立ち止まるようにしています。

なぜなら、その要望は本当の問題ではなく、困っている人が考えた解決方法の仮説かもしれないからです。

要望に忠実でも、問題を解決できるとは限らない

たとえば、

「売上を見えるようにしてほしい」

という依頼があったとします。

そのまま受け取れば、売上を表示する画面や一覧表を作ることになります。

でも、少し話を聞いてみると、本当に困っていたのは別のところにあるかもしれません。

数字を探すのに時間がかかっている。

部署ごとに売上の定義が違っている。

異常な数字が出ても、気づくのが遅い。

自分の行動が、どの結果につながったのか分からない。

同じ「売上を見えるようにしてほしい」という言葉でも、背景にある問題によって、必要な仕組みは変わります。

一覧表を作れば解決する問題もあります。

一方で、数字の定義をそろえなければ、画面を作っても混乱が増えるだけの問題もあります。

通知が必要な場合もあれば、見るべき指標を減らす方が効果的な場合もあります。

現場の要望をそのまま作ることが、必ずしも現場に寄り添うことではありません。

本当に寄り添うとは、その要望が生まれた場面まで戻ることだと思っています。

要望は、答えではなく仮説として受け取る

私は、現場から出てきた要望を否定したいわけではありません。

むしろ、その要望には大切な情報が含まれています。

「一覧にしてほしい」と言われたなら、必要な情報が散らばっているのかもしれない。

「自動化してほしい」と言われたなら、同じ作業を何度も繰り返しているのかもしれない。

「AIに判断させたい」と言われたなら、判断できる人が限られているのかもしれない。

要望は、問題へ近づくための入口です。

ただし、入口をそのまま完成形だと思わない。

私は要望を、

として受け取るようにしています。

そして、その仮説を一緒に確かめていきます。

ひとりFDEが最初に聞く8つのこと

何を作るかを決める前に、私は次の8つを確認します。

1．最近、何とかしたいと思った具体的な場面は何か

「業務を効率化したい」ではなく、実際に困った場面を聞きます。

いつ、どこで、誰が、何をしていたのか。

何を探していたのか。

どこで止まったのか。

何に時間がかかったのか。

抽象的な課題を、実際の場面まで戻すことで、問題の輪郭が見えてきます。

2．最も困っている人は誰か

要望を出した人と、実際に困っている人が同じとは限りません。

管理者が依頼していても、日々困っているのは入力担当者かもしれません。

営業が困っているように見えて、実際には後工程の品質や生産管理に負担が集まっている場合もあります。

誰の作業を軽くするのか。

誰の判断を助けるのか。

誰の不安を減らすのか。

対象を間違えると、便利な機能を作っても、本当の負担は残ります。

3．現場では、何を作ってほしいと言っているか

要望そのものも、きちんと確認します。

一覧がほしいのか。

通知がほしいのか。

自動入力してほしいのか。

判断してほしいのか。

ただし、ここで決定はしません。

要望を記録したうえで、

「なぜ、それが必要だと思ったのか」

を聞きます。

作ってほしいものより、その理由の方に本当の問題が隠れていることが多いからです。

4．必要な情報はどこにあるか

仕組みを作る前に、情報の所在を確認します。

メールにあるのか。

Excelにあるのか。

Salesforceにあるのか。

紙に書かれているのか。

誰かの頭の中にしかないのか。

情報が存在していても、更新されていなければ使えません。

複数の場所に同じ数字があり、それぞれ違う場合もあります。

「見える化したい」という問題が、実は「情報の正しさを決められない」という問題だったこともあります。

5．人が判断している場所はどこか

すべての作業が、決められたルールだけで動いているわけではありません。

担当者が経験から判断している。

過去のやり取りを思い出して決めている。

相手との関係を見ながら対応を変えている。

例外を見つけて、あえて処理を止めている。

こうした判断を、単純な作業だと思って自動化すると危険です。

どこまでを仕組みに任せるのか。

どこからを人に残すのか。

人の判断をなくすのではなく、判断しやすい材料をそろえる方がよい場合もあります。

6．通常とは違うケースは何か

業務を聞くとき、通常の流れだけを確認してしまいがちです。

でも、仕組みが止まるのは、多くの場合、通常ではないケースです。

情報が不足している。

同じ名前のデータが複数ある。

急ぎの案件だけ処理が違う。

取引先によって書式が異なる。

判断できないときは、特定の担当者へ確認する。

最初からすべての例外に対応する必要はありません。

ただし、

「どんなときに自動処理を止めるか」

「誰へ返すか」

だけは決めておく必要があります。

7．その後の工程で、誰が何をするか

自分の作業が早くなっても、次の人の作業が増えたなら、全体では改善になっていません。

入力する人にとって便利でも、確認する人が読みにくくなることがあります。

営業の作業を自動化した結果、品質や生産管理に情報確認が集中することもあります。

そのため、目の前の工程だけではなく、その後に誰が何をするのかを確認します。

私はこのとき、いつも、

という考え方を大切にしています。

改善とは、作業を次へ送ることではありません。

次の人が、迷わず、安心して仕事を始められる状態を作ることです。

8．失敗した場合、どんな影響があるか

最後に、間違えたときの影響を確認します。

少し手直しすれば済むのか。

顧客へ誤った情報が送られるのか。

金額や納期に影響するのか。

品質問題につながるのか。

元に戻せるのか。

失敗の影響が小さければ、小さく試しながら改善できます。

一方で、影響が大きいなら、人の確認を残す、対象を限定する、処理を途中で止めるなど、安全な設計が必要です。

自動化できるかどうかではなく、間違えたときに安全に戻れるかどうかを見ます。

8つの答えから、問題の型を見つける

この8つを確認すると、表面上は違って見えた相談にも、共通する型が見えてきます。

情報が見えない問題。

判断が特定の人に集中している問題。

部署間の受け渡しが切れている問題。

ルールが安定していない問題。

例外や失敗時の影響が大きい問題。

作った後の運用が決まっていない問題。

問題の型が見えると、必要な対応も変わります。

情報が見えないなら、一覧やダッシュボードが役立つかもしれません。

判断が集中しているなら、判断材料や過去事例を残す方が先かもしれません。

部署間の受け渡しが切れているなら、ツールを増やすより、入力項目や責任の境界を整える必要があります。

ルールが安定していないなら、すぐに自動化せず、まず運用を記録する方がよいこともあります。

何を作るかを考える前に、何が問題なのかを分ける。

ここが、改善の設計で最も重要な部分です。

最初から完成形を作らない

本当の問題が見えても、すぐに大きな仕組みを作るわけではありません。

対象者を絞る。

一部の情報だけを見えるようにする。

人の確認を残す。

一定期間、試してみる。

発生した例外を記録する。

私は、最初の改善を「完成品」ではなく、問題の仮説を確かめるための小さな実験として考えています。

使ってみると、最初の想定と違うことが必ず出てきます。

必要だと思っていた機能が使われない。

想定していなかった人が最も活用する。

自動化したかった部分より、情報の見せ方を変える方が効果がある。

そうした発見を次の改善に反映します。

最初から正解を作るのではなく、正解に近づける仕組みを作る。

その方が、現場に無理をさせず、安全に進められます。

「今はしないこと」も決めておく

改善を始めると、やりたいことはどんどん増えます。

せっかくなら全社で使いたい。

AIで完全自動化したい。

他のシステムとも連携したい。

例外もすべて処理したい。

しかし、最初からすべてを含めると、何を確かめたいのか分からなくなります。

そのため、小さな実験では「今はしないこと」も決めます。

全社展開はしない。

判断の完全自動化はしない。

例外処理は人へ返す。

既存システム全体は作り替えない。

対象期間や対象者を限定する。

やらないことを決めるのは、諦めではありません。

問題を安全に確かめるための設計です。

作ることより、問い直すことに価値がある

言われたものを早く作ることはできます。

ツールを知っていれば、一覧も、自動化も、通知も作れます。

でも、本当に難しいのは、作ることではありません。

その要望の奥にある問題を見つけることです。

誰が困っているのか。

どんな場面で止まっているのか。

必要な情報はどこにあるのか。

人は何を判断しているのか。

次の工程にどんな影響があるのか。

失敗したときに、どう戻すのか。

ここを飛ばして作られた仕組みは、最初は便利でも、少しずつ使われなくなります。

あるいは、別の誰かへ負担を移しただけの仕組みになります。

良い仕組みは、要望ではなく、本当に困っていることに忠実である

現場の要望をそのまま作らないことは、現場の意見を無視することではありません。

むしろ、その言葉を大切に受け取りながら、

「なぜ、その要望が生まれたのか」

まで一緒に考えることです。

表面上の要望から始める。

具体的な場面まで戻る。

情報、判断、前後工程、例外に分ける。

本当の問題を仮説として整理する。

人に残す判断と、仕組みに任せる処理を分ける。

小さく試し、結果を見て直す。

それが、私が71件の業務改善を通して身につけてきた、ひとりFDEの基本的な進め方です。

現場から、

「これを作ってほしい」

と言われたとき。

すぐに作り始める前に、一度だけ問い直してみる。

良い仕組みは、要望に忠実な仕組みではありません。

本当に困っていることに忠実な仕組みです。