DX提案が通らない理由

熱意では決裁は動かない

「またその話か」——DX推進の提案を持っていくたびに、上司の表情が曇る。そんな経験はないだろうか。現場では非効率な作業が積み上がり、誰もが「変えたほうがいい」と感じている。それなのに、決裁の場に持ち込んだ瞬間、話が止まってしまう。予算がつかない、優先順位が低いと言われる、そもそも議題にすら上がらない。担当者は現場と経営の板挟みになり、少しずつ気力を削られていく。しかし、提案が通らない原因は熱意の不足ではない。伝え方の設計が抜け落ちているだけなのだ。

上司が見ている判断軸

上司が知りたいのは「現場が不便かどうか」ではなく「その投資が会社に何をもたらすか」である。だからこそ、感覚ではなく事実が必要になる。現場を観察し、業務を作業・判断・例外に分解し、流れを図として整理する。その積み重ねが判断材料になる。説得とは、集めた事実を意思決定へつなぐ橋渡しの作業だ。順番を飛ばして結論だけを持ち込んでも、相手には判断のしようがない。

ROIは3行で見せる

まず取り組むべきは、集めた事実をそのまま数字へ翻訳することだ。「この転記作業に月20時間かかっている」を人件費に換算し、年間コストとして示す。ここで大切なのは、効果を大きく見せようとしないことである。数字を盛った試算は必ず疑われ、一度失った信頼は次の提案にまで響く。むしろ控えめに見積もったほうが、承認後の実績が期待を上回りやすい。見せ方は3行で十分だ。現状にかかっているコスト、改善後に見込まれるコスト、その差額と投資回収までの期間。この3つが並んでいれば、上司は判断できる。数字の根拠となった作業ログを一枚添えれば、説得力はさらに増す。資料の厚さではなく、判断材料の明快さが決裁を動かすのである。

小さく始めて実績で語る

それでも金額が大きければ話は進まない。そこで有効なのが、最小単位から始めるスモールスタートの提案である。全社導入ではなく「一つの部署の、一つの業務だけ、3か月」と範囲を区切れば、上司にとってのリスクは一気に下がる。判断が軽くなれば、決裁のハードルも下がる。さらに、同業他社の成功事例を添える際は、そのまま並べるのではなく自社の業務に翻訳して語りたい。「あの会社が成果を出した」ではなく「うちの受発注業務なら同じ構造だ」と示すのだ。そして小さく動かした結果が出たら、それを次の提案の材料にする。定着を確認し、また新しい改善提案へ戻る。説得は一度きりの勝負ではない。

まとめ

提案が通らないのは、熱意でも運でもない。事実を数字に変え、範囲を小さく区切り、実績で次を引き出す。この順番を守るだけで、通る確率は確実に変わる。そして一度承認を得られれば、次の提案は通りやすくなる。大切なのは、一度で完璧な承認を狙わないことだ。小さな成功を積み重ね、改善を続けること。それが、DXを社内に根づかせるいちばんの近道である。

関連記事

ノウハウはタダじゃない

IT導入の難しさ

IT導入では、どの程度のコストをかけるべきか、その費用がどのように効果を生むかの判断が難しい場面が多い。正解が存在しないため、常に試行錯誤が伴うのが実情である。導入後も改善や調整が続き、理想の形を追い求めて進化し続ける必要がある。これこそが、IT導入のハードルを高める最大の要因である。

「導入=完成」の落とし穴

「導入すれば終わり」と考えると、ITプロジェクトは失敗しやすくなる。IT導入には明確なゴールがないため、段階的なチェックポイントの設計が重要となる。導入途中で要件が変化することも少なくないが、それを「失敗」とみなすのではなく、「成功への第一歩」と捉えるべきである。柔軟な対応と継続的な見直しこそが、成果につながる道である。

見積もりが難しい理由

目に見えるモノを作る場合とは異なり、ITシステムの見積もりには高い不確実性が伴う。業務の関連性、将来的な拡張性、外部環境の変化など、検討すべき要素は無数に存在する。したがって、本格的なIT導入には、実際の開発にかかる時間の2倍ほどの準備期間を設ける覚悟が必要である。余裕を持つことが、後のトラブル回避にも直結する。

DXがカオスになる訳

システム構築やDXのプロジェクトは、時間の経過とともに当初の目的を見失いやすい。最初に定めた要件が現場の混乱の中で忘れ去られ、後から新たな要求が持ち込まれることで、プロジェクトが迷走していく。現場も対応に追われ、全体が混沌としていく。こうした事態を避けるには、目的の定期的な再確認と明確な進行管理が不可欠である。

まとめ

ITに苦手意識があるからといって「なんとかしてくれ」と丸投げする姿勢では、プロジェクトは成功しない。目的や進捗のチェックポイントといった、数値化できないノウハウの積み重ねこそが、成功への鍵となる。

続きを見る >

賢いコスト削減

投資と競争力

バックヤードのシステム開発は収益と直接結びつかないため、できるだけケチりたいものである。にもかかわらず、バックヤードのデジタル化には大きなコストがかかる。しかし、新しいインフラに適切な投資ができない企業は競争力を失うのである。

要件定義の罠

バックヤードのシステムをできるだけ安く抑えようと思うと、要求定義や要件定義をしっかり作って依頼すればよいと考えがちである。もちろん、間違ってはいないが、入り口が安くなるわりに、システム開発の途中で追加工数が発生してしまい、結果としてシステムが高くなってしまうのである。

未来志向の要求

システム開発の途中で追加予算がかかってしまうのは、最初の要求定義や要件定義のときに想定される未来が見えていないことが原因である。これを見通すには要求定義や要件定義を行う背景や、未来の目指すところまでをエンジニア出身のアナリストに情報共有しなければならない。

投資の真価

導入時の金額だけをケチることは、保守運用などのランニングコストに跳ね返ってきてしまい、システムの寿命が短くなる。そうならないために、第三者のIT業者やITコンサルタントを入れるほうがよいと言われている。うまくDX化できれば生産性が上がり、投資を大きく回収できる。ことIT投資については、竹槍戦か空中戦かくらいの違いを生んでしまうのである。

まとめ

システム設計やプログラミング作業と同じようにITコンサルタントも1人の能力に偏りがちである。それゆえ、PMOと呼ばれるチームを形成することで、集合知を活用して、さらに未来を予測できるような体制を構築することが望ましい。

続きを見る >

従来開発 vs ローコード開発比較

基本概念

企業のデジタル化が加速する中、システム開発手法の選択は事業成功の鍵を握る重要な決断となっている。従来開発は、プログラマーがコードを一から書き上げる伝統的な手法で、高い技術力と豊富な経験が求められる。一方、ローコード開発は視覚的なインターフェースを活用し、最小限のコーディングでアプリケーションを構築する革新的なアプローチである。両者の特徴を正しく理解することで、プロジェクトに最適な選択が可能になる。

費用対効果

従来開発では高度なスキルを持つエンジニアの確保が必要で、人件費が開発コストの大部分を占める。特に大規模プロジェクトでは、設計から実装、テストまで長期間の人的リソースが必要となり、総コストは数千万円規模に達することも珍しくない。対してローコード開発は、専門知識が少ない人材でも短期間でアプリケーション構築が可能で、初期投資を大幅に削減できる。しかし、プラットフォームのライセンス費用や将来的なカスタマイズ制約を考慮すると、長期的なコスト効率は慎重に検討する必要がある。

開発速度

開発期間において両手法の差は歴然としている。従来開発では要件定義から本格運用まで数ヶ月から数年を要するケースが一般的で、複雑な機能実装には綿密な設計と段階的な開発が必要である。一方、ローコード開発は既存のテンプレートやコンポーネントを活用することで、数日から数週間での迅速なプロトタイプ作成が可能である。特にビジネスアプリケーションや内部管理システムでは、従来開発の10分の1以下の期間で実装できる場合もある。ただし、複雑なロジックや高度な機能が必要な場合は、結果的に従来開発と同等の期間を要することもあるため、プロジェクトの性質を見極めることが重要である。

品質と制約

システムの品質面では、それぞれ異なる特徴がある。従来開発は細部まで制御可能で、パフォーマンス最適化や独自機能の実装において高い品質を実現できる。セキュリティ要件が厳格なシステムや大量データ処理が必要な基幹システムでは、従来開発の柔軟性が威力を発揮する。ローコード開発は標準化されたコンポーネントを使用するため、一定の品質は保証されるが、プラットフォーム依存による制約がある。また、複雑な業務ロジックの実装や外部システムとの高度な連携において、期待する品質レベルに到達できない可能性もある。品質要件と開発リソースのバランスを慎重に評価することが成功の鍵となる。

まとめ

最適な開発手法の選択は、プロジェクトの目的、予算、期間、品質要件を総合的に評価して決定すべきである。ローコード開発は迅速性とコスト効率に優れ、内部業務システムや簡易的なWebアプリケーション開発に適している。従来開発は高い技術的要求や独自性が必要なシステムに最適である。重要なのは、どちらか一方に固執するのではなく、各プロジェクトの特性に応じて柔軟に選択することである。

続きを見る >