記事

内製化の成功術

IT報酬の実態

海外と比べて日本のITエンジニアの報酬が低いという記事をよく目にする。それもそのはずで、ハイクラスIT人材は都合のいい「何でも屋」にはならないからである。

導入時の誤解

ユーザー企業やシステムのユーザーは、IT化を行うことで業務が減るという先入観を持っていることがある。システム導入を着手したときの目的を忘れて、その時、その場の課題を優先して都合よくITエンジニアを動かしてしまう。また動くITエンジニアもそこにいたりする。

システムと医療

たとえば、「お腹が痛い」と病院にいって「すぐに切開しよう」とはならないはずだ。このようにシステムにもその他にも色々な条件が絡まり合っている。システムは取り扱う情報量や関連する業務が多く導入に時間がかかる。時間がかかる結果、最初の導入目的を忘れてしまうのである。

真のIT人材価値

ハイクラスIT人材はユーザー側の状況と心理を配慮しつつ、現場のプログラマーの状況と心理を考慮して陣頭指揮できる人材といってもよいだろう。心理というのは物の言い方だけではなく、無形の財産を構築したり業務にフィットさせたりするので、プロジェクトの円滑さが変わるのだ。

まとめ

小手先だけでシステムに関するプロジェクトを推進しようとすると、「言われた通りにやった」という受動的な参加者が増えてしまう。情シスのSIer化を回避するにはITエンジニアを「何でも屋」にさせて疲弊させないことも大切である。開発チームの雰囲気作りも非常に効果がある。

予算ブレの原因 前の記事 生成AIは使えない？ 次の記事

関連記事

記事

ローコードで失敗する企業

導入の落とし穴

ローコード開発は、プログラミング知識がなくても業務アプリを構築できる手法として注目を集めている。しかし、導入企業の多くが期待した成果を得られず、プロジェクトが頓挫するケースが後を絶たない。「簡単に作れる」という触れ込みを鵜呑みにし、適切な計画なく導入を進めた結果、かえって業務効率が低下する事態も発生している。失敗の原因は、ローコードの特性を正しく理解していないことにある。

活きる業務

ローコードが真価を発揮するのは、定型的な業務プロセスの自動化や、シンプルなデータ管理アプリの構築である。例えば、申請承認ワークフロー、在庫管理、顧客情報の一元管理といった業務では、短期間で実用的なシステムを構築できる。また、現場部門が主体となって改善を繰り返す必要がある業務にも適している。成功企業に共通するのは、最初から大規模なシステムを目指さず、小さな業務改善から着手している点である。スモールスタートで効果を検証し、段階的に適用範囲を広げることで、確実に成果を積み上げている。

業務選定の失敗

一方で、ローコードには明確な限界がある。複雑なビジネスロジックを含む基幹システム、大量データのリアルタイム処理、高度なセキュリティ要件が求められるシステムには不向きである。失敗企業の典型的なパターンは、これらの領域にローコードを適用しようとするケースである。開発途中で機能の限界に直面し、結局フルスクラッチでの再開発を余儀なくされることも少なくない。また、ベンダーロックインのリスクも見過ごせない。特定のプラットフォームに依存することで、将来的な拡張性や他システムとの連携に支障をきたす事例が増えている。業務特性を見極めずに導入を急ぐことが、失敗の最大の要因である。

選定フレームワーク

ローコード導入を成功させるには、業務の棚卸しと適性判断が不可欠である。まず、対象業務の複雑性、データ量、連携要件を可視化し、ローコードで対応可能な範囲を明確にする。次に、将来的な拡張性や保守運用の観点から、長期的なコストを試算することが重要である。短期的な開発コスト削減だけを見て判断すると、運用フェーズで想定外の負担が発生する。成功企業は、ローコードと従来型開発を適材適所で使い分けている。すべてをローコードで賄おうとせず、業務特性に応じた最適な開発手法を選択することが、DX推進における重要な判断軸となる。

まとめ

ローコードは万能ではない。定型業務や小規模アプリには有効だが、複雑な基幹システムには不向きである。成功の鍵は、業務特性を正しく見極め、適切な領域に適用すること。導入前の計画策定と、段階的なアプローチが失敗を防ぐ最善策である。ツールの特性を理解し、戦略的に活用することでDX推進を加速させよう。

続きを見る >
記事

DX抵抗の本質

「現状維持」の本音

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

抵抗の3要因

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

現場を味方にする方法

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

DX定着の共通点

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

まとめ

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

続きを見る >
記事

業務データ資産の発見と活用

AI活用の第一歩

AI活用による生産性向上のためのシステムツール構築では、過去データの利用が必要不可欠である。しかし、過去データが整備されていない場合の対処法を考えてみたい。多くの企業がAI導入を検討する際、まず直面するのがこのデータ品質の問題である。完璧なデータセットを求めがちだが、実際には現実的なアプローチで進めることが成功への鍵となる。

目的の明確化

まず「何に使いたいデータなのか」を明確にする必要がある。目的に応じて、必要なデータの「粒度・項目・量」が変わるため、いつも扱っている部門ではない人が客観的に整理するのがよいかもしれない。例えば、生産管理の異常検知であればセンサーデータの時系列とアラート履歴が必要になり、顧客離反の予測であれば購買履歴と問い合わせ履歴が必要になる。このように具体的な用途を定めることで、収集すべきデータの方向性が見えてくる。

データの現状把握

やりたいことを整理すれば、次に足りないデータなどが見えてくるはずである。このとき、データが重複していたり、欠損していたり、バラバラであったりというのも、すべてデータはあるものと考える。形式としては、Excel、CSV、紙、システム内に点在などを把握して、データの棚卸を行う。完璧でないデータでも、適切な処理を施すことで価値ある情報源に変わる。重要なのは、現在持っているデータ資産の全体像を正確に把握することである。

データ整備の実践

データの棚卸が終われば、データクレンジング（整備）の作業方針を立てる。手動で整えるのか、何らかのツールを使うのか検討が必要である。また、このツールはExtract（抽出）、Transform（変換）、Load（読み込み）の頭文字をとってETLツールと呼ばれている。Power Queryなどがその代表例である。作業量と精度のバランスを考慮し、コストパフォーマンスの高い整備方法を選択することが重要になる。自動化できる部分は積極的にツールを活用すべきである。

まとめ

データを整えていく途中で足りないデータが発見されることもあるだろう。しかし、ここからがAIの使い様である。ファインチューニング（学習させていく）ことや、生成AIやRAG（Retrieval-Augmented Generation）を利用して補完するなどが考えられる。

続きを見る >