リーダーの多忙による弊害

DX推進とAIツール活用

2025年現在、DX推進において生成AIツールの活用は避けて通れないテーマとなっている。調査によれば国内ソフトウェア開発におけるAIコード生成の利用率は49％に達し、資料作成においても従来の60％以上の時間短縮が報告されている。しかし現場では「どのツールを選べばよいかわからない」「導入したものの活用が進まない」という声も多い。本記事では、デザイン・ドキュメント作成・コーディング・業務自動化の4分野において、DX担当者が即活用できる実践的なツールを具体的に紹介する。

デザイン・資料作成の効率化

デザイン・UI/UX分野では「Figma AI」と「Canva AI」が二大勢力として君臨している。Figma AIはプロトタイプ生成やレイヤー名の自動整理が可能で、Config2025で発表された「Figma Make」ではテキスト指示だけでコード生成まで実現する。Canvaは非デザイナー向けに画像編集・自動翻訳・音声生成を統合し、SNS投稿やプレゼン資料を短時間で仕上げられる点が強みである。資料作成分野では「Gamma」がテキスト入力のみでプロ級スライドを自動生成し、「Notion AI」は要約・文章生成・議事録作成をワンストップで対応する。Microsoft 365環境なら「Copilot」がWord・Excel・PowerPointと連携し、既存資産を活かした効率化が図れる。

コーディング支援AIの進化

コーディング・開発分野では「GitHub Copilot」が依然としてデファクトスタンダードの地位を維持している。VS CodeやJetBrains IDEとの深い統合によりコード補完・生成・テスト作成をシームレスに実行でき、NTTドコモやカカクコムなど大手企業での導入事例も増加中である。一方で2023年登場の「Cursor」はAIネイティブエディタとして進化を続け、2025年10月のバージョン2.0では専用モデル「Composer 1」とマルチエージェント実行機能を搭載した。プロジェクト全体を理解しながら複数ファイルを横断編集できる点が特徴である。さらにAnthropicの「Claude Code」はターミナル上で動作し、自然言語指示だけでコード生成からデバッグ・リファクタリングまで対応する。開発チームの規模や既存環境に応じた使い分けが重要となる。

業務自動化によるDX改革

業務自動化分野では「Microsoft Power Automate」がMicrosoft 365との統合度の高さで優位性を発揮している。2025年のアップデートではAIファーストの設計思想のもと、自然言語でフローを作成・編集できるCopilot機能が強化された。「Zapier」は7,000以上の外部サービスと連携可能で、異なるアプリ間のデータ転送を直感的なUIで自動化できる。エンタープライズ向けでは「UiPath」が世界的シェアを持ち、教育コンテンツとコミュニティが充実している点で社内人材育成にも適している。ただしツール導入においては、セキュリティポリシーの策定・情報漏洩対策・ライセンス管理が不可欠である。生成AIが業務データを扱う以上、社内ルールに沿った運用設計を先行させることが成功の分岐点となる。

上司が首を縦に振らない現実

「DXを進めたいのに、上司がまったく理解してくれない」。これはDX推進を任された担当者が最も多く抱える悩みのひとつである。現場では業務効率化やデジタル活用の必要性を日々感じているのに、いざ上司に提案すると「今のままで十分回っている」「よくわからないから後にしてくれ」と一蹴されてしまう。この認識のズレは単なる世代間ギャップではなく、DXの本質が正しく共有されていないことに根本的な原因がある。

上司世代が抵抗する3つの理由

上司世代がDXに消極的な理由は主に3つある。第一に、成功体験への執着である。従来のやり方で結果を出してきた上司にとって、業務プロセスの変更はリスクにしか映らない。第二に、デジタル技術への不慣れである。ITツールに日常的に触れてこなかった世代ほど、新しいシステムの導入に対する心理的ハードルは高くなる。第三に、評価制度との不一致である。短期的な売上や数値目標が評価軸になっている場合、すぐに効果が数字に表れにくいDX投資は優先順位が下がる。こうした構造的な背景を理解せずに「DXは必要です」と正論をぶつけても、上司の心には響かないのが現実だ。

上司を動かす3つの巻き込み術

では、どうすれば上司をDX推進の味方にできるのか。効果的なアプローチを3つ紹介する。まず、「DX」という言葉を使わないことだ。上司にとってDXはカタカナ用語の塊であり、抽象的で自分ごとに感じにくい概念である。代わりに「月次レポートの作成時間を半分にできます」「入力ミスによるクレームを8割減らせます」といった具体的な業務課題に紐づけて提案すべきである。次に、小さな成功事例をつくることだ。Excelマクロの自動化やクラウドストレージの導入など、低コストかつ効果が実感しやすい施策から着手し、目に見える成果を上司に報告する。最後に、競合他社の事例を活用することである。「同業のあの会社はもう取り組んでいる」という情報は、上司の危機感を最も強く刺激する説得材料になる。

上司は敵ではなく最大の味方

上司を巻き込めないままDXが停滞すると、競合との差は開く一方だ。しかし悲観する必要はない。上司が理解してくれないのは、提案内容が間違っているのではなく、伝え方と巻き込み方にもう一工夫が必要なだけである。大切なのは、上司を「抵抗勢力」ではなく「味方にすべき最重要キーパーソン」として捉え直すことだ。上司が何を重視し、どんな成果を求められているのかを把握した上で、相手の立場にメリットが伝わる提案に再構築すべきである。DXは担当者一人で進めるものではない。上司の理解と後押しがあってこそ、組織全体を巻き込んだ本当の変革が実現する。焦らず戦略的に、一歩ずつ認識のギャップを埋めていくことが重要だ。

まとめ

上司がDXに消極的な原因は世代差ではなく、伝え方と評価構造のズレにある。「DX」という言葉を避けて具体的な業務改善として提案し、小さな成功体験を積み重ねて見せることで、上司の認識は確実に変わる。上司を味方につける戦略的アプローチこそ、DX推進を成功に導く最大のカギである。

はじめに

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

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

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

要件定義の丸投げ

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

無理な受注

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

人材紹介会社の利益構造

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

エンジニアの責任範囲

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

発注側の保身

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