DXを「終わらない数か月」にしないために：週単位で価値を届けるデジタル変革

DX＝大規模ITプロジェクトではない

「DX」と聞くと、

• 数年間のロードマップ、
• ERPの全面刷新、
• 大量の要件定義、
• 大規模なコンサルティングチーム、
• 何か月にもわたる会議、
• 大規模データ移行、
• 遠い将来の本番稼働

を想像することがあります。

もちろん、その規模のプロジェクトが必要な場合もあります。 しかし、それを最初から前提にする必要はありません。

企業が抱えている課題は、もっと具体的なことかもしれません。

• 購買承認に10日かかる。
• サプライヤーからの書類が複数のメールに分散している。
• オンボーディング申請がどこで止まっているか分からない。
• CRMとERPへ同じ顧客情報を手入力している。
• 品質検査をまだ紙で記録している。

このような場合、企業全体を一度に「DXする」より、 まず一つの業務を改善する ことから始める方が現実的です。

何か月も成果が見えないことの問題

長期間のプロジェクトには、いくつかのリスクがあります。

• 完成する前に事業環境が変わる。
• 最初に要件を決めた担当者が異動する。
• 何か月も開発した後で、現場の実際の業務と合っていないことが分かる。
• 最初に選んだ技術が古くなる。
• 「DXを進めています」と聞いても、社員の日常業務は何も変わらないため、関係者の期待が下がる。

そして特に重要なのは、 学ぶ速度が遅くなる ことです。

半年後に初めて利用者へ見せるより、

1. 1つくる
2. 2使う
3. 3観察する
4. 4学ぶ
5. 5改善する

というサイクルを早く回す方が、実際の業務に合った仕組みをつくりやすくなります。

「週単位」は「全部を数週間で終わらせる」という意味ではない

これは明確にしておく必要があります。

複数の基幹システム、大規模なセキュリティ要件、規制対象データ、複数国、複雑な組織変更を含むプロジェクトであれば、数か月以上かかることは当然あります。

• セキュリティ審査にも時間がかかります。
• 調達にも時間がかかります。
• 既存システムへのアクセスを確保するだけでも時間が必要な場合があります。
• 業務ルールについて部門間で合意する必要があります。
• データ整理が必要な場合もあります。

短くすべきなのは、 最初の実用的な成果が出るまでの時間 です。 例えば、

• 一つの承認フロー、
• 一つのサプライヤー業務、
• 一つの品質検査、
• 一つの文書処理、
• 一つのシステム連携、
• 一つの外部向けポータル

から始めることができます。

そして、実際の利用結果を見ながら広げます。

なぜ日本企業に特に関係するのか

日本企業では、長年利用してきた重要なシステムを維持しながら、デジタル化・モダン化を進める必要があります。

経済産業省のレガシーシステムモダン化委員会は、既存のレガシーシステムが新しいデジタル技術導入や事業変化への柔軟な対応を妨げていることを指摘しています。また、IT資産の可視化、ガバナンス強化、事業部門とIT部門の連携、変化に対応できる柔軟なモダン化の必要性を示しています。

だからこそ、 「全部入れ替える」 だけではなく、

1. 1残すべきものを残す
2. 2周辺業務を改善する
3. 3システムをつなぐ
4. 4学ぶ
5. 5段階的にモダン化する

という方法が重要になります。

Fluyentaもレガシーシステムに関する説明の中で、全面的な書き換えを前提とせず、既存環境を活かしながら業務をモダン化する考え方を示しています。

日本のDXは「導入」から「価値」へ

IPAの「DX動向2026」では、日本企業のDX・AI導入が進む一方で、成果は業務効率化、デジタル化、迅速化に集中しており、企業価値創出やより大きなビジネス変革につなげることが引き続き課題として示されています。

つまり、 技術を導入しただけではDXは終わりません。 重要なのは、 どれだけ早く実際の業務改善へ変えられるか です。

DXを速く進める7つの考え方

1. ツールではなく業務課題から始める

「このプラットフォームを購入したので、何か自動化しましょう」 ではなく、 「どの業務が最も負担になっているか？」 から始めます。

例えば、

• 承認が遅い。
• サプライヤーへの確認が多い。
• 品質情報が届くまで時間がかかる。
• 同じデータを何度も入力している。
• 顧客が進捗確認のために毎回電話している。

課題から始めることで、最初の範囲を絞りやすくなります。

2. 最初の業務範囲を明確にする

最初から会社で最も大きなプロセスを選ぶ必要はありません。

重要でありながら、理解できる範囲に収まる業務を選びます。

• どこから始まるのか。
• どこで終わるのか。
• 誰が関わるのか。
• どのシステムを使うのか。
• どこで時間がかかっているのか。
• 何を改善したいのか。

これらを明確にできない場合、最初の範囲が広すぎる可能性があります。

3. 必要のないシステム入れ替えをしない

ERPやCRMには、長年の業務知識が蓄積されています。

問題なく役割を果たしている部分まで作り直す必要はありません。

例えば、

1. 1ポータル
2. 2ワークフロー
3. 3承認
4. 4既存ERP

という形で周辺業務を改善するだけで十分な場合もあります。

4. すべてを一から作らない

従来型の開発では、すでに存在する機能を作り直すことに時間を使う場合があります。

ローコードでは、

• コネクタ、
• ワークフロー部品、
• フォーム、
• 業務ルール、
• API連携、
• 認証、
• 実行環境

などを再利用することで、開発量を減らせます。

Fluyentaも、ビジュアルなプロセス設計、再利用可能な部品、管理された実行環境を迅速なリリースの理由として挙げています。

考え方としては、 企業独自の価値を生む部分は作る。そうでない部分は再利用する。 ということです。

5. システム連携を早い段階で確認する

画面だけ完成しても、ERPやCRMと連携できなければ実用的ではありません。

• APIへアクセスできるか。
• 認証方法は何か。
• データ品質は十分か。
• 既存システムへ書き込みできるか。

こうした技術的な不確実性は、最後ではなく早い段階で確認します。

6. ガバナンスを後回しにしない

速いからといって、管理を弱くしてはいけません。

• 権限、
• 監査記録、
• バージョン管理、
• 承認権限、
• セキュリティ、
• エラー対応、
• 業務責任者

などを最初から設計します。

Fluyentaの「速さ」がエンタープライズ向けとして意味を持つ理由の一つは、迅速な開発だけでなく、ガバナンスや監査を同じ基盤で扱う設計を採用している点です。

目標は、 管理を犠牲にしたスピード ではありません。 管理されたスピード です。

7. 最初のリリースを「完成」と考えない

実際に使ってもらうと、

• 「この承認はもっと前に必要だった」
• 「この項目はいらない」
• 「取引先にはこの質問が分かりにくい」
• 「この例外は想定より多い」

といった情報が得られます。

このフィードバックを次の改善へ使います。

短いサイクルは単に「速く完成する」ためではなく、 より正しいものをつくるため にも役立ちます。

建設業で考える

建設業務の構成例です。Axtonが完了した顧客案件を示すものではありません。

例えば建設会社で、現場に入る前の協力会社書類を管理しているとします。

最初から、

• 全協力会社、
• 全現場、
• 全書類、
• 全契約、
• 全資格、
• 将来機能

を含む巨大システムを設計すると、大規模なプロジェクトになります。

最初のリリースでは、

1. 1協力会社が資料提出
2. 2必須項目確認
3. 3安全部門審査
4. 4現場責任者承認
5. 5状況可視化
6. 6書類保存

だけに絞ることができます。

この仕組みを実際に使うことで、

• 協力会社はポータルを使えるのか。
• どの書類で不備が多いのか。
• 差し戻しは誰が担当するべきか。
• どのシステム連携が本当に必要か。
• どの承認は不要なのか。

が分かります。

その後、

• ERP連携、
• 資格期限通知、
• AIによる文書読み取り、
• 複数現場対応、
• 分析

などを追加できます。

Fluyenta／RunMyProcessの実務例

Fluyentaが公開しているRunMyProcessの事例では、ある世界的な農業機械メーカーが、紙のチェックシートを中心に行っていた品質検査をデジタル化しています。

モバイルでのデータ入力、自動レポート・通知、集中管理ダッシュボードなどを導入し、既存の生産システムとも連携しました。

Fluyentaは、この仕組みが数週間で導入され、品質管理にかかる時間が30%削減されたと報告しています。

これはFluyenta／RunMyProcess側の実務経験であり、Axtonの完了案件ではありません。

また、30%という結果を他社にも保証するものではありません。

重要なのは、 会社全体を最初から作り直すのではなく、品質検査という明確な業務を対象に改善した という点です。

スピードに最も影響するのは「範囲」

開発技術だけが期間を決めるわけではありません。 実は、 どこまでを最初にやるか が非常に重要です。 例えば、

「購買業務をDXする」 より、 「東京事業部の100万円未満の購買申請を自動化する」 の方が、

• 理解しやすく、
• 設計しやすく、
• 検証しやすく、
• 成果を測りやすく、
• 導入しやすくなります。

成功した後で、対象範囲を広げればよいのです。

プロジェクト期間より「価値が出るまでの時間」を見る

12か月かかるプロジェクトが必ず悪いわけではありません。 問題なのは、 11か月間何も使えないこと かもしれません。 例えば、

プログラムの比較例であり、Axtonの案件実績や納期の約束ではありません。

どちらが「速い」でしょうか。 DXでは、 全体の期間だけでなく、最初の価値が出るまでの時間 を見ることが重要です。

最初の成果は何で測るべきか

「システムが動いた」だけでは不十分です。

最初に解決しようとした業務課題が改善したかを確認します。

例えば、

• 処理時間、
• 手作業の引き継ぎ回数、
• 二重入力、
• 承認待ち時間、
• 例外件数、
• 書類不備、
• 進捗確認の問い合わせ、
• 利用者の作業量

などです。

指標を何十個も設定する必要はありません。

元の業務課題につながる数個で十分です。

不必要にプロジェクトを長くするもの

• 将来あり得るすべてのケースを最初から設計する。
• 問題のある業務をそのまま自動化する。
• すべての要件を「バージョン1必須」にする。
• 連携テストを最後まで行わない。
• 完璧なデータを待ち続ける。
• リリースを「最終完成」と考える。
• 業務部門とIT部門を別々に進める。

この最後の点については、経済産業省もレガシーシステムモダン化において、事業部門と情報システム部門の連携を重要な要素として挙げています。

「週単位」が現実的になりやすい条件

• 最初の範囲が明確。
• 意思決定者が参加している。
• 必要なシステムアクセスを確保できる。
• 連携方法が分かっている。
• データが利用できる。
• セキュリティ要件が整理されている。
• 既存機能を再利用できる。
• 段階的な改善を組織が受け入れている。

このような条件が整うほど、早いリリースが現実的になります。

数週間にすべきではないケース

逆に、

• 複数の基幹システムを全面刷新する。
• 大規模なデータ移行を伴う。
• 規制・法務審査が複雑。
• セキュリティアーキテクチャ自体を作り直す。
• ハードウェア展開を伴う。
• 複数国・法人で同時導入する。
• 業務責任者すら決まっていない。

という場合は、長い期間が適切なこともあります。

このような案件を、 「2週間でできます」 と表現するべきではありません。 スピードは必要な作業を省くことではなく、 不要な複雑さを減らすこと から生まれます。

ローコードは「考えなくてよくなる技術」ではない

ローコードによって開発量は減らせます。

Fluyentaもビジュアルプロセス設計、再利用可能なコンポーネント、管理されたインフラなどによって、適切なワークフローを従来より短い期間で構築できると説明しています。

しかしローコードが、

• この承認は必要か。
• 誰が業務責任者か。
• 正しいデータはどのシステムにあるか。
• この社内規程は合理的か。
• AIの判断を人が確認すべきか。

を決めてくれるわけではありません。 それは企業側の判断です。 技術は実装を速くします。 業務設計そのものを不要にはしません。

より良いDXのサイクル

より現実的なサイクルは、

1. 1理解する
2. 2簡素化する
3. 3つくる
4. 4つなぐ
5. 5管理する
6. 6リリースする
7. 7測定する
8. 8改善する

です。

そして、もう一度繰り返します。

最初のリリースですべてを解決する必要はありません。

実際の利用から学べるだけの価値を提供することが重要です。

Axton × Fluyentaにとって「weeks, not months」とは

Axton Group LTD JapanはFluyentaとの提携を通じて、日本のエンタープライズ業務自動化でも、この考え方を大切にします。

Axtonは、日本側の業務課題や関係者の状況を理解します。

Fluyentaは、20年以上のエンタープライズ業務自動化の経験を背景に、ワークフロー、システム連携、オーケストレーションの技術を提供します。

目的は、 非現実的な短納期を約束することではありません。 適切な業務自動化案件が、 必要以上に長期化しないようにすること です。 そのために、

• 最初の範囲を絞る。
• 既存システムを活かす。
• 実績のある機能を再利用する。
• 利用者を早く参加させる。
• ガバナンスを維持する。
• 成果を見ながら広げる。

という進め方を取ります。

DXは「勢い」を生むべき

社員が、 「以前よりこの業務が楽になった」 と感じるまで、一年待つ必要はありません。

• 一つのワークフローが改善されれば、次の改善について話しやすくなります。
• 一つのシステム連携が成功すれば、他の連携への信頼が生まれます。
• 一つの外部ポータルが機能すれば、他の取引先業務も改善できる可能性が見えてきます。
• 一つの管理されたAI活用が成功すれば、その経験を別の業務へ広げられます。

だから、 「数か月ではなく、週単位」 という言葉の意味は、 「DX全体を数週間で終わらせる」 ことではありません。 実際に使えるものを早い段階で届け、そこから学び、価値を確認しながら次の改善へ進むこと。 それが、より持続可能なDXの進め方です。

よくあるご質問