「標準機能でお願いします」という言葉が、現場に静かな影を落とすとき ── 「導入のしやすさ」と「使いやすさ」のあいだで
経営会議や、システムの選定プロジェクトで
こんなやり取りを聞いたことはないでしょうか。
経営層は言います。
「コストを抑えて、なるべく業界標準に合わせよう。無駄なカスタマイズは避けるべきだ」
ベンダーは深く頷きます。
「それが賢明です。当社のベストプラクティスを活用すれば、最短・低コストで導入できます」
そこにあるのは、合理的で、とても大人びた合意です。
誰も間違ったことは言っていません。会社のお金を守り、プロジェクトを遅らせないための、正しい判断です。
けれど、なぜその決定を聞いたとき、
実務を担当する現場の人たちの心は、少しだけ重くなるのでしょうか。
「わがままを言ってはいけない」
「変化に対応できない自分が悪いのかもしれない」
そうやって飲み込んだ言葉の正体について、今日は少しだけ立ち止まって考えてみたいと思います。
「初期費用」は見えるけれど、「苦労」は見えない
経営判断というものは、基本的に「目に見える数字」で行われます。
新しいシステムの導入費用が1,000万円なのか、
カスタマイズして1,500万円になるのか。
見積書に書かれたその「500万円の差」は、誰の目にも明らかです。
だから、それを削ることは企業として「善」とされます。
一方で、使いにくいシステムをカバーするために現場が支払う
「工夫」や「時間」は、見積書には決して出てきません。
画面遷移が悪くて、毎日10分増える入力作業
データが連携されないために、Excelに転記する手間
直感的に分からない操作を、隣の人に聞く時間
これらは往々にして「運用の慣れの問題」として片付けられてしまいます。
しかし、これは物理的なコストが消滅したわけではありません。
「導入コスト（Capex）」という目に見える借金が、
「運用コスト（OpEx）」という目に見えない借金に付け替えられただけなのです。
その「ベスト」は、何を約束してくれるのか？
さらに、もう一つ。
私たちがどうしても違和感を拭えない点があります。
それは、
「そのベストプラクティスを入れたら、具体的にどんないいことがあるのか（成果）」
が、驚くほど曖昧なまま進んでいくことです。
ベンダーが約束してくれるのは、
「システムが無事に動くこと（稼働）」までです。
「このベストプラクティスを導入すれば、残業が確実に減ります」
「売上が上がります」
といった「結果」までは、契約書には書かれていません。
まるで、
「この薬は業界最高峰です（ベストプラクティス）」と高額で売りつけられるのに、
「で、これを飲んだら治るんですか？」と聞くと、
「それは飲んだあなた次第（運用次第）です」と返されるようなものです。
手段（システム）は納品されるけれど、
結果（良くなること）は現場の努力義務として丸投げされる。
「標準に合わせろ」という号令の下、
苦労して業務を変えた先に、
「この苦労に見合うだけの見返り」が提示されていない。
これが、現場が感じる「やらされ仕事」の正体ではないでしょうか。
ゴール（報酬）が約束されていないマラソンを、
「これが正しい走り方だから」という理由だけで走らされているような徒労感です。
「標準」とは、誰かにとっての「平均点」
そもそも、ベンダーが提供する「標準機能」とは何でしょうか。
それは多くの場合、
「最も多くの企業に導入してもらいやすい形（最大公約数）」
のことです。
洋服で言えば「フリーサイズ」のようなものです。
誰でも着られますが、誰の身体にもぴったりとは合わない。
あなたの会社が持つ、独自の強み。
現場が長年大切にしてきた、顧客への細やかな配慮。
そういった「身体の凹凸」までは、標準機能はカバーしてくれません。
その「隙間」を埋めているのは、
現場の人たちの「優しさ」や「柔軟性」という名のクッションです。
フリーサイズの服を着こなすために、
現場が無理な姿勢を取り続けているとしたら。
それはいつか、組織の歪みとなって現れます。
解決策は「戦う」ことではなく「翻訳」すること
では、どうすればいいのでしょうか。
「現場のことをわかっていない！」と
経営層やベンダーを責めても、話は平行線です。
彼らは彼らの役割
（コスト管理や、安定したシステムの提供）
を果たしているだけで、悪気はないのですから。
必要なのは、感情的な対立ではありません。
現場の「感覚的な重さ」と「成果への問い」を、
経営者が判断できる「共通言語」に翻訳することです。
「この機能を削ると、みんなが大変です（感情）」
ではなく、
「ここを標準に合わせると、初期費用は下がります。
しかし、現場の工数は増えます。
そして何より、この標準機能では、
私たちが目指している『〇〇という成果』には届きません。
それでも導入しますか？（構造と目的）」
このように、選択肢とリスクをテーブルに乗せるのです。
「導入のしやすさ（ベンダーの都合）」を取るか
「運用のしやすさと、成果（現場の都合）」を取るか
それは本来、どちらが正解というものではなく、
経営的なトレードオフの判断です。
その判断をするための材料
（翻訳された事実）を提示することこそが、
私たち業務設計者の役割なのだと思います。
結び：成果の定義は、自分たちで握るしかない
ベンダーは成果を約束してくれません。
それは冷たいようですが、ビジネスの構造上、仕方のないことです。
だからこそ、発注側である私たちが、
その「空白の成果」を定義しなければなりません。
「標準だから」と思考を預けるのではなく、
「どこにお金をかけ、どこで汗をかき、そしてどんな果実を得るか」を、
自分たちの意志で選ぶこと。
「標準機能でお願いします」
その言葉を口にする前に、一度だけ問いかけてみてください。
その選択は、
単に「楽に導入するため」のものなのか。
それとも、本当に「自分たちが良くなるため」のものなのかを。
正解は、ベンダーのきれいな提案書の中ではなく、
日々の業務のスキマにあるはずですから。
🍵 思考の詰まりを解消する処方箋
現場のモヤモヤを「わがまま」で終わらせず、
構造として捉え直すためのヒントをいくつか置いておきます。
▼ 現場の負担を「見えないコスト」としてどう可視化するか
感情論ではなく、構造として「見えない仕事」を扱う視点について解説しています。
見えない仕事の本質＃1｜見えない仕事は、なぜ評価されないのか
▼ 経営と現場の言葉が通じないとき、どう翻訳するか
異なる論理（ロジックと感情）をつなぐための、翻訳者としてのスタンスはこちら。
板挟みの正体は「能力」ではなく「構造」にある
─ 上司の数字と現場の感情を翻訳するコスト
▼ ベンダー任せにせず、自分たちで「問い（目的）」を立てる
導入自体を目的にせず、その先の「何のため？」を設計する視点です。
#問いの設計 ｜DX推進者に贈る10の問い