フルスクラッチは体力

デジタル化は効率化を保証しない

デジタル化と聞くと、多くの人が効率化を期待する。しかし、たとえばFAXで受け取った紙の受注をOCR（文字認識）でデジタルデータ化し、データベースに保存しても、それは単なるデジタル化に過ぎない。デジタル化を行うだけでは本質的な効率向上は望めず、業務フローの見直しがなければ効果は限定的だ。

非効率なフローをそのままデジタル化するリスク

最も大きな問題は、業務フローを見直さずにデジタル化を行うことだ。従来の手作業のフローをそのままデジタル化すれば、かえって作業が煩雑化し、時間がかかることもある。特にITに疎い権限者が意思決定を行う場合、このような失敗はよく見られる。「デジタル化＝効率化」と誤解し、実際には逆効果となるケースも少なくない。

俯瞰できないシステム担当者の問題

システム担当者やシステム会社が、俯瞰的な視点を持たない場合も問題だ。業務フローを把握せず、指示通りにデジタル化を進めれば、非効率なシステムが出来上がる。ユーザー部門は「IT化で逆に効率が悪くなった」と感じ、最悪の場合、システムが欠陥品だと誤解されることもある。業務の流れを把握し、適切にデジタル化を進めることが必要だ。

生成AI導入の失敗例

生成AIの導入に関する相談も増えているが、その多くは「期待通りに動かない」という内容だ。その原因は、多くの場合、AIが本来必要ない箇所に導入されていることだ。たとえば、ただのデータ管理であれば、生成AIではなくRDB（リレーショナルデータベース）のほうが合理的だ。効率を上げるには、AIの利用が本当に適切かを見極める判断力が必要だ。

まとめ

「ITが分からないから任せる」という姿勢はリスクが高い。ITを知らない人がIT化を進めるのは、決算書を読めないのに経営をするのと同じだ。業務フローを理解し、技術を正しく活用するには横断的な視点と経験が不可欠だ。

開発手法の選択基準

大がかりなシステム開発においては、ウォーターフォールモデルという開発手法がとられ、設計書などのドキュメント類も整理してから、プログラミングへ着手する。逆に中小規模なシステム開発においては、アジャイル開発と呼ばれ、プログラミングをしながらシステム開発が進められたり、ドキュメント類は簡易にして、プログラミング工程へ着手するといった方法がとられる。状況に応じて開発手法は使い分ける必要がある。

設計書の必要と課題

建築では図面なく建物を建てることはないが、中小規模のシステムについては簡単な概要だけでシステムの開発ができてしまう。もちろん設計書をしっかりと書いて、要件を詰めてシステム開発を進めることができれば、トラブルもなくていいのではないかと言われる。しかし、設計書を作成するにはシステムをプログラミングすることと同じくらい費用が掛かる。

設計書の粒度と要因

中小規模のシステム開発において設計書が簡易になってしまう理由は、ユーザー側や発注側の予算が乏しいという理由がある。建築のパターンの場合は、法律によって作成しなければならない図面や、施主から同意をもらうべき書類などが決められている。システム開発には法的に作成しなければならない書類が明確にされているわけではないため、この粒度が各社・各エンジニアによりバラツキが発生する。

文書管理の現状

中小規模のシステム開発において、最悪の場合は設計書がないケースもある。小さなプロジェクトの場合は予算も少なく特にドキュメント類がないが多くある。あるいは、システムはアップデートされ続けているのにドキュメントはアップデートされていなかったり、ひどい場合にはシステム保守ベンダーが紛失している場合もある。

まとめ

システム開発に時間がかかる理由は、設計書から作成することでプログラミング作業の2倍以上の時間がかかると言われる。いわゆる動作検証の工程まで入れるとプログラミング作業の3倍程度は時間がかかる。また、システム開発はほとんどが人件費である場合が多く、かかる時間に応じて費用が上がる。つまり、非エンジニアが単純に開発費用を値切ると、プログラミング以外の重要な情報を削っていくことになる。

「現状維持」の本音

DX推進の現場で最もよく聞かれる言葉が「今のままで十分回っている」という声である。しかし、この言葉の裏には単なる保守的な姿勢だけではない、切実な事情が隠れている。現場担当者にとって、新しいシステムの導入は「業務負担の増加」と「習熟までの不安」を意味する。日々の業務をこなしながら新しいツールを覚える余裕がない、というのが本音なのだ。この心理を理解せずにDXを押し進めても、形だけの導入に終わってしまう。

抵抗の3要因

現場のDX抵抗には、大きく3つの要因がある。1つ目は「自分の仕事がなくなるのでは」という雇用への不安である。効率化によって人員削減されるのではという恐れが、無意識の抵抗を生む。2つ目は「これまでのやり方を否定された」という感情的な反発である。長年培ってきた業務ノウハウを軽視されたように感じ、心理的な壁が生まれる。3つ目は「導入後のサポート体制への不信感」である。過去にシステム導入で混乱した経験があると、また同じことが起きるのではと警戒心が強まる。これらは論理ではなく感情の問題であり、丁寧な対話なしには解消できない。

現場を味方にする方法

現場の抵抗を協力に変えるには、戦略的なアプローチが必要である。まず「スモールスタート」で成功体験を積むことが重要だ。全社一斉導入ではなく、協力的な部署や担当者から小さく始め、目に見える成果を出すことで周囲の関心を引く。次に「現場キーマンの巻き込み」が効果的である。影響力のあるベテラン社員をプロジェクトメンバーに加え、当事者意識を持ってもらうことで、自然と周囲への波及効果が生まれる。そして最も大切なのが「目的の共有」である。DXは手段であり、目的は現場の負担軽減や働きやすさの向上であることを繰り返し伝える必要がある。「あなたの仕事を楽にするため」というメッセージが、抵抗感を和らげる鍵となる。

DX定着の共通点

DXに成功している企業には共通点がある。それは導入後も現場との対話を継続していることだ。システムを入れて終わりではなく、定期的なフィードバック収集と改善を繰り返すことで、現場の声がツールに反映される実感が生まれる。この「聞いてもらえている」という感覚が、次の変化への受容性を高めるのである。また、成功企業は小さな改善成果を積極的に社内共有している。「このツールで月5時間の作業が削減できた」といった具体的な数字は、懐疑的だった社員の心を動かす。DXは一度きりのプロジェクトではなく、現場と伴走し続ける長期的な取り組みであると理解することが、真の定着への第一歩である。

まとめ

現場のDX抵抗は、単なる保守性ではなく、不安や過去の経験に基づく合理的な反応である。この心理を理解し、スモールスタート、キーマンの巻き込み、目的の共有という3つのアプローチで丁寧に進めることが成功の鍵となる。DXは現場を敵に回すものではなく、現場を味方につけてこそ真の効果を発揮する。