効率化の誤解

焦りの正体

「DXを推進しているのに、目に見える成果がまったく出ない」。そんな焦りに押しつぶされそうになっていないだろうか。ツールを導入し、業務フローを見直し、社内への説得に奔走する毎日。それでも経営層からは「結局なにが変わったの？」と聞かれてしまう。中小企業白書においても「具体的な効果や成果が見えない」はDX推進の代表的な課題として挙げられている。この焦りを抱えているのは、あなただけではない。

成果が出ない真因

DXの成果が見えにくい最大の原因は、成果が表れるまでの「時間軸」を正しく認識できていないことにある。DXは売上のように短期で数字に直結する取り組みではなく、業務プロセスの再設計や組織文化の変革を伴う中長期的なプロジェクトである。経済産業省のDX推進指標でも、定量的な成果測定の難しさが指摘されている。たとえば紙帳票を電子化しても、その効果がデータとして蓄積され意思決定のスピードに影響を与えるまでには数か月単位の時間がかかる。焦りの根本は「すぐに大きな成果が出るはず」という期待値のズレにあるのだ。

小さな成功の見える化

では、どうすれば成果を「見える化」できるのか。鍵となるのは「小さな成功の可視化」である。いきなり全社的な大変革の成果を求めるのではなく、まずは一つの業務改善にフォーカスすべきだ。たとえば「請求書処理の時間が週5時間短縮した」「問い合わせ対応のスピードが30%向上した」など、数値で語れる改善を一つずつ積み上げていくのである。具体的にはKPI（重要業績評価指標）を事前に設定し、改善前後のデータを比較できる仕組みをつくることが有効だ。作業時間の短縮率、エラー件数の減少、コスト削減額といった定量的な指標を継続的に追いかけることで、経営層にも現場にも「確かに前に進んでいる」と伝えられるようになる。小さな数字の積み重ねが、やがて大きな説得力を持つのである。

組織を動かす一歩

小さな成功を積み上げることには、もう一つ大きな意味がある。それは「組織全体の巻き込み」だ。一つの部署でDXの効果が数字として証明されれば、他部署からも「自分たちの業務でも試してみたい」という声が自然と上がり始める。DXは「推進する」ものではなく「広がる」もの。そのためには最初の成功事例をモデルケースとして社内に共有し、横展開していく流れをつくることが重要である。社内ミーティングや掲示板で改善実績を発信し、成功体験を共有する文化を根づかせるべきだ。焦って大きな成果を狙うよりも、小さく始めて確実に成果を示す「スモールスタート」の姿勢こそが、結果として全社的なDX推進を加速させるのである。目の前の焦りに負けず、一歩ずつ着実に前進していくことが大切だ。

まとめ

DXの成果が見えないと感じたときこそ、「時間軸の見直し」と「小さな成功の可視化」に取り組むべきである。KPIを設定して改善を数値で追いかけ、スモールスタートで着実に実績を積み重ねていく。大きな変革は、小さな一歩の先にある。この順番を意識するだけで、漠然とした焦りは確かな手応えへと変わるはずだ。

はじめに

会社の雰囲気や要件定義の内容をみれば、おおよそそのプロジェクトが成功するか否かがわかる。うまくいかない場合のユーザー側とシステム会社側の原因の一例である。

・要件定義をシステム会社に任せてしまう
・元請けシステム会社が無理な要件でも受注する
・準委任契約の人材紹介会社がリスクなく利鞘を稼げる
・末端エンジニアの作業遂行以外の責任
・ユーザー側、発注側の担当者が保身する

今回はその背景を説明したい。

要件定義の丸投げ

要件定義をシステム会社に任せてしまう。
要件定義はシステム会社がユーザー企業をヒアリングして作るものではなく、ユーザーとシステム会社が議論を重ねることで答えを出していくものにしなくてはならない。ユーザーが目指すべき姿と、システム会社が実現すべき姿のすり合わせが重要である。

無理な受注

元請けシステム会社が無理な要件でも受注する。
無理な要件でも受注できるのは、発注側にもシステムの知識がないため、ゴールが曖昧なまま元請けシステム会社が請け負ってしまうからである。もし、発注側にITリテラシーがなければ、パワハラなども発生する可能性が高い。したがって、元請けシステム会社に精神的な課題を回避するため、要件定義を作る人でさえも二次受けシステム会社から集めてくることがある。

人材紹介会社の利益構造

準委任契約の人材紹介会社がリスクなく利鞘を稼げる。
システムの完成責任は負わず、作業だけ請け負うことになるため、人さえ集めてくれば、そこでリスクなく利鞘が稼げる。発注側のユーザー企業からすれば、契約は元請けシステム会社であるため、3次請け、4次請けを使おうが、完成さえすればいいと考えていることが多い。

エンジニアの責任範囲

末端エンジニアの作業遂行以外の責任。
末端のエンジニアには、クライアントとの調整や導入、一定品質や納期の遵守など、責任感や危機感がないこともある。プロジェクトの全貌が見えないことも原因である。また、言われたことをやるだけで報酬がそこそこあるのが、システムエンジニアの業界だったりするので、作業をした時間分だけ報酬を支払ってほしい、という話にもなる。

発注側の保身

ユーザー側、発注側の担当者が保身する。
システム開発がうまくいかなかったときに、発注側の担当者がシステム会社に責任を押し付けるといったことがある。これは信頼関係によるもので、共同でプロジェクトを成功させようという目標が作れなかった場合に発生する。システム会社を業者扱いして要件定義を丸投げしてしまわないようにしなければならない。

市民開発の正体

市民開発（Citizen Development）とは、IT部門やSIerに依存せず、業務部門などの非エンジニアが自らアプリケーションを作成する取り組みを指す。従来は「プログラミングができないと無理」と思われがちだったが、現在ではノーコード・ローコードツールの登場により、非技術者でも業務に必要なツールを構築できるようになった。代表的なものとして、SaaSベースの業務アプリやMicrosoft Power Platformなどがあり、これにより業務現場の課題解決が加速している。

IT不足とマクロの功罪

市民開発が注目を集める背景には、深刻なITエンジニア不足がある。人手が足りないなら自ら開発するしかない——この流れが市民開発を後押ししている。その原型とも言えるのがExcelマクロである。かつて現場では、個人PC上で動作するマクロが業務改善ツールとして使われていたが、多くが属人化し、結果として保守不能な“遺産”となってしまっている。

マクロの限界

Excelマクロの最大の弱点は「ファイル単体依存」である。複数人での同時使用や、プログラムの共有に極めて不向きである。マクロ付きファイルをコピーすれば、そのコピーごとに独立した修正が可能となり、誰がどのバージョンを使っているのか把握が困難になる。しかも、更新履歴の管理も難しく、組織全体の業務統一を図るには限界がある。こうした特性が、非効率と混乱を招く要因となっている。

マクロの呪い

属人化の果てに起きるのが「ブラックボックス化」である。Excelマクロにパスワードがかけられ、開発者も不在、しかし業務には不可欠——そんな状態が現場には数多く存在する。これらは情報システム部の管理外にある「野良プログラム（シャドーIT）」と呼ばれ、セキュリティリスクを高める要因でもある。結果として、誰も触れず、誰も捨てられず、今も現場の根幹に鎮座している。まさに、手遅れになる前に対処すべき課題だ。

まとめ

市民開発は、Excelマクロに代わる次世代の業務改善手段となり得る。ローコード・ノーコードの活用により、野良プログラムの乱立を防ぐには、組織としての運用ルールとガバナンスの確立が不可欠だ。アタラキシアDXでは、Power Appsを活用し、手遅れになる前にブラックボックス化したマクロのリプレイス支援を行っている。