「現場を知らない者に、設計などできるはずがない」という誤解
―業務改革とIT開発に共通する、日本的“設計不在”の正体
業務改革の話をすると、必ずと言っていいほど聞こえてくる言葉があります。
「現場を知らない者に、設計などできるはずがない」
一見すると、もっともらしく聞こえます。
しかし私は、この言葉こそが業務改革を遠ざけている大きな誤解だと考えています。
なぜならこの発言は、「設計とは何か」を誤解したまま使われているからです。
多くの人がイメージしている「設計」とは何でしょうか
この反論を口にする方々が想定している「設計」とは、
多くの場合、次のようなものです。
•現場業務を細部まで知っていること
•現行の業務手順を漏れなく把握していること
•例外やイレギュラーを経験として理解していること
•暗黙知を体感的に知っていること
つまり、「設計」と言いながら、実際には現場理解の延長線上にある作業を指しています。
しかし、それは設計ではありません。
現状の把握であり、再現であり、追認です。
設計とは「現状を詳しく知ること」ではありません
本来の意味での設計とは、次の問いに答える行為です。
•何を目的とした業務なのか
•どの機能が必要なのか
•判断はどこで行うべきなのか
•何を標準化し、何を捨てるのか
これらを、論理的に決めていくことが設計です。
ここで必要なのは、
•経営戦略の理解
•制約条件の整理
•原理原則の明確化
•業務構造を捉える力
であり、「その業務を何年やってきたか」ではありません。
設計とは、経験ではなく思考の成果なのです。
IT開発の現場でも、同じことが起きています
この誤解は、業務改革に限った話ではありません。
IT開発の現場でも、同じ構図が見られます。
多くの企業が、開発ベンダーに対して次のような条件を出します。
「当社と同業他社のシステム開発を経験した人を、プロジェクトに必ず入れてください」
一見すると、安心感のある条件です。
しかし、ここで立ち止まって考える必要があります。
この条件が意味している本当のこと
この要望の本質は、「他社のノウハウを知りたい」ということではありません。
実際には、次のような心理が働いているケースが多いのです。
自社では、何を作るべきかを論理的に定義できていない。
だから、抜けや漏れを“経験者”に補ってほしい。
これは、
•要件定義を自社で完結できていない
•設計を経験補完に委ねている
という状態を意味します。
経験者アサインは「安心材料」ではありますが、業界経験者をプロジェクトに入れること自体を
否定するつもりはありません。
問題は、それに何を期待しているかです。
•戦略から業務を設計する代わりに
•業務構造を定義する代わりに
•判断基準を言語化する代わりに
「この業界なら、だいたいこうですよね」
という暗黙の前提に依存してしまう。
これは、設計ではありません。設計を放棄している状態です。
戦略に基づく業務設計から、最も遠い場所
この状態では、次のような結果になります。
•業務は他社事例の寄せ集めになる
•ITはパッケージやベンダー都合に引きずられる
•なぜその機能が必要なのか、誰も説明できない
•経営戦略との関係が曖昧なまま進む
これで「業務改革」や「DX」と呼べるでしょうか。
残念ながら、答えは いいえ です。
業務設計は、論理的に可能です
ここで、はっきりさせておきたいことがあります。
業務設計は、現場に精通していなくても、論理的に可能です。
必要なのは、
•経営戦略を理解すること
•目的と制約を整理すること
•判断構造を設計すること
•業務をモデルとして捉えること
現場は、
•その設計が実行可能かどうかを
•検証する役割を担います。
役割は、明確に分かれています。
「現場を知らないと設計できない」という言葉が止めているもの
最後に
「現場を知らない者に設計はできない」という言葉は、
一見、現場を尊重しているように見えます。
しかし実際には、
•誰も設計責任を負わない状態
•経験に依存した意思決定
•改革に踏み出さない安心感
これらを守っているに過ぎません。
その言葉を前提にしている限り、業務改革もDXも、前に進みません。
設計とは、勇気を持って「決める」行為だからです。
合同会社タッチコア 小西一有
悩む前に、相談してみませんか？
