業務改善が進まない原因とは？DXが失敗する理由とローコードの罠

「DX・業務改善」というキーワードは、ほぼ全ての企業で課題として挙げられて久しいものですが、施策の実施前後において、期待した通りの結果が出なかった、というケースは少なくありません。

例えば、以下のようなケースです。

よくある失敗パターン

• 紙の帳票をExcel化した
  →個人/部署ごとにExcelが乱立し、管理しきれなくなってしまった。
  →作成時のマクロ・関数がブラックボックス化し、誰もメンテナンスできない。

• ツールを導入した
  →ツールの限られた機能では現場の複雑な業務を再現できない。
  →IT部門とベンダーで開発したツールだが、現場の業務に沿った作りではないため使いにくい。
  →修正を依頼するたびに数週間～数か月単位の時間、改修費用が掛かるため改善要望を出しにくい。

結果として、

• ツールの導入前より業務効率が落ちている
• 誰もツールを利用しない

という“逆効果”が発生してしまいます。
つまり、「改善のための施策」が“新たな非効率”を生んでしまっているのです。

次に、その原因を構造的に整理し、「なぜ改善がうまくいかないのか」についてお話しします。

業務改善が進まない3つの構造的原因

業務改善が進まない原因として、「ツール」ではなく「施策の構造」にある、と私は考えています。
問題はどこにあるのか。大きく3つの構造に分けて整理します。

施策が「目的化」してしまっている

本来の目的は「業務改善」であり、「施策の実施」は手段の1つでしかありません。

しかし、
・トップダウンでとりあえずツールを導入した
・とりあえず表面的な業務をシステム化した
というように、「ツール導入」や「システム化」などの施策が目的になってしまうケースが多く見られます。
これだけでは複雑な業務にフィットするわけもなく、当然不便な点は出てきます。

しかし、「施策の実施」が目的になってしまうと、実施が完了した時点で満足してしまいがちです。

業務改善活動が日々の業務の邪魔をしてしまう

現場は日々の業務で余裕がありません。
そこに、「業務改善をしろ」「このツールを使え」という指示が加わると、

「そのような活動をする暇はない。」
「よくわからないツールを使うことで、かえって手間が増えてしまった。」

というように、「今のままでいい」という認識が現場で定着してしまいます。

継続的改善の仕組みがない

改善は「一度作って終わり」ではなく、「小さく試して回し続けるもの」です。

しかし、前述のような状況になってしまうと、「システムの改善ができない」「そもそも改善の要望が出てこない」などの状態に繋がってしまいます。これでは業務改善が進むはずがありません。

重要なのは、

• スピード重視の小規模開発スタート
• 継続的改善体制(PDCA)

などの改善体制だと考えます。

図：DX・業務改善　理想と現実の比較表

観点	理想	ありがちな状態
開発主体	業務部門	IT部門・ベンダー
初期開発	数週間~数か月	年単位
改修スピード	即時	数週間~数か月
改善体制	継続的	なし

ローコードツールの”罠”

前章では、業務改善が進まない理由を大まかに説明しました。

では、ローコードツールの導入でこれらの問題は解決できるのでしょうか？
ローコードは業務改善の有効な手段ですが、導入だけでは問題は解決しません。
むしろ、以下のような新たな課題が生まれることがあります。

なぜ解決しないのか？ローコードツールに潜む”罠”を3点ご紹介します。

“新しい属人化”の発生

ローコードツールを部門に導入したあとのよくあるパターンとして、

• ツールの操作が一部の人しかできない
• 設計思想を利用者が理解できない/まず共有されていない

などの状況に陥ってしまうことがあります。
結果、「その人が辞めたら終わり」状態の再来となり、ツールを導入した意味がなくなってしまいます。

業務部門が主導できていない

ローコードツールを導入するために開発を行うのはIT部門またはベンダーがほとんどですが、真に業務を理解しているのは現場の業務部門です。

現場主導になっていないと、開発時の仕様伝達ロス、認識のズレが発生し、 結果として「使われないステム」に繋がってしまいます。

“作れる”と”改善できる”の違い

ローコードツールでなんとかして1機能作ることができました！

さて、将来的に機能を増やして業務全体をカバーする、となった際にこの機能は全体にとって最適化されているでしょうか？
ローコードは作ることはできても、

• 全体最適の設計
• 継続的な改善

ができなければ、部分最適のシステムが集まり、サイロ化(部門ごとに分断され同じようなシステムが乱立している状態)になりがちです。

本記事の結論｜まとめ

ローコードの罠にかからず、業務改善を成功させるためのポイントは、

• ツールではなく「構造」を見直す
• 現場主導で進める
• 小さく改善を回し続ける

であると本記事ではお話しさせていただきました。

• トップダウンでのツール導入が目的化してしまっている
• 現場に余力がなく、改善活動が定着しない
• 小さく改善を回せる体制が構築されていない

こうした構造的な課題がある状態では、たとえローコードツールを導入しても、

• 新たな属人化の発生
• 業務部門主導にならない開発
• 部分最適によるシステムのサイロ化

といった別の問題を生んでしまい、本質的な業務改善にはつながりません。
DX成功の鍵は、「何を作るか」ではなく「どう改善し続けるか」にあります。

また、ローコードの罠を回避するためには、推進層・業務部門・ベンダーの関係性も重要なポイントであると考えます。
業務改善を業務部門が主導するためには、推進層・ベンダーそれぞれが適切な役割を担う必要があります。

図：業務部門を中心に、業務部門を推進層が引っ張り、ベンダーが業務部門を支える

次回予告

次回は、

現場主導の業務改善を実現する開発体制とローコードツール「Accel-Mart Quick」をテーマに、

• 業務改善における経営層・現場・ベンダーの体制と役割
• ノーコード/ローコードを用いた効果的な開発モデル
• 「Accel-Mart Quick」の基本的な特徴

をご紹介します。