DXプロジェクトの進め方｜現状把握から保守運用までの全体像

「DXを進めたいが、何から手をつければいいかわからない」。そう感じている方に向けて、この記事ではDXプロジェクトの流れを最初から最後まで整理します。

結論から言うと、DXプロジェクトは「設計」と「実行」の2段階で進みます。設計では、今の業務（現状）と目指す姿を比べ、その差をどう埋めるかを決めます。実行では、決めた仕組みを作り、現場で使える状態にします。ツールやシステムを選ぶのは、設計の後半です。

DXプロジェクトは、どんな順番で進むのか

DXプロジェクトは、主に次の11の工程で進みます。1〜7が「設計」、8〜11が「実行」です。

1〜7は、ITコンサルタントがシステムを作る前に行う仕事です。システム開発の世界では「要件定義」と呼ばれる工程にあたります。

以下、工程の順に説明します。

1. 現状は、どう把握すればよいのか

現状は、日次・週次・月次・例外業務の4つに分け、それぞれを5W1H（誰が・いつ・どこで・何を・なぜ・どのように）で聞くと、漏れなく把握できます。例外業務は、誰がどう対応しているかまで聞きます。例外の対応ほど、特定の人にしかできない状態（属人化）になりやすいからです。

毎日の業務は、何時に何をしているかという時間帯の単位で聞くと、具体的な答えが返ってきます。また、質問には「DX」のような言葉を使わず、現場の言葉を使います。棚卸しの進め方と聞き方は「業務の棚卸しとは？業務改善を始める前にやる5つの手順」で詳しく解説しています。

現状を聞くと、多くの会社で「手作業が多い」「情報があちこちに分かれている」「特定の人しか分からない業務がある」といった悩みが出てきます。これらは、3の課題の特定で使う材料になります。

2. 目指す姿は、どう決めればよいのか

目指す姿は、「なぜ変えるのか（目的）」と「変えた後にどうなっていたいか（到達点）」の2つで決めます。

目的の例は、次のとおりです。

• 社内の連絡や確認にかかる手間を減らす
• 同じ内容を何度も入力する作業を減らす
• 報告書づくりを自動にする

到達点の例は、次のとおりです。

• 情報が1か所にまとまり、必要な人がいつでも見られる
• 一度入力したデータが、ほかの仕組みにも自動で反映される
• 必要な数字がすぐにそろい、判断が早くなる
• 会社の外からでも仕事ができる

あわせて、使える予算と期間も確認します。予算と期間によって、選べる解決策や作り方が変わるためです。

3. 課題は、どう特定すればよいのか

課題とは、現状と目指す姿の差を生んでいる原因です。多くの会社で見つかる課題は、次の5つです。

※ 例です。

4. 解決策と優先順位は、どう決めればよいのか

まず、課題ごとに解決策を決めます。

次に、解決策に優先順位をつけます。比べる物差しは、次の4つです。

優先順位が決まったら、「いつ・何を・どこまでやるか」を時期ごとに並べた計画表を作ります。これをロードマップと呼びます。

すべてを一度に変えようとすると、現場の負担が大きくなり、途中で止まりやすくなります。まずは「効果が大きく、手間が小さいもの」から始めます。効果を確かめてから、次の改善に進みます。

※ 進め方の例です。

5. 機能は、どう決めればよいのか

機能とは、解決策を実現するために必要な画面や仕組みです。機能は、4で決めた解決策ごとに決めます。

機能は「あると便利かどうか」ではなく、「解決策に必要かどうか」で選びます。機能が増えるほど、費用も、使い方を覚える手間も増えるからです。

6. 技術は、どう選べばよいのか

技術の選定では、5で決めた機能を、どんな作り方で実現するかを決めます。比べるのは、かかる費用、使える予算、かけられる期間の3つです。

作り方は、主に次の5つです。

作り方は1つに絞る必要はありません。たとえば、既製のサービスを中心に使い、足りないところをAPI連携でつなぐ組み合わせもよく使われます。

7. データと業務フローは、どう設計すればよいのか

設計の最後に、新しい仕組みで扱うデータと、業務の流れを決めます。

• データ：どんな項目を持つか、誰がいつ入力するか、どの項目でほかのデータとつなぐかを決めます。
• 業務フロー：新しい仕組みを使った後の業務を、誰が・いつ・何をするかの順に並べ、理想の業務フロー図にします。

請求書や納品書など、出力する書類がある場合は、書類の様式を先に決めます。そこから必要なデータを逆算すると、項目の漏れを防げます。

ここで決めたデータと業務フローが、8の開発で作るものの設計図になります。

8〜11. 設計が終わったら、どう作り、どう現場に根づかせるのか

設計が終わったら、開発・導入テスト・移行・保守運用の順に進めます。

8. 開発

設計をもとに仕組みを作ります。一度に完成させようとせず、作る・試す・直すを短い周期で繰り返します。途中の段階で現場の人に見てもらうと、完成後の手戻りを減らせます。

9. 導入テスト

実際の業務に近い使い方で、現場の人に試してもらいます。7で決めた業務フローどおりに仕事が回るかを確かめ、問題があれば本番の前に直します。

10. 移行

今の仕組みから新しい仕組みへ、データと業務を移します。一度にすべてを切り替えず、段階的に移すのが基本です。

11. 保守運用

使い始めた後も、仕組みを使い続けられる状態を保ちます。そのために、2種類の文書を残します。

• 仕様書：仕組みの中身や設定を記録したもの。直すときや、担当者が変わっても理解できる内容にします。
• 業務マニュアル：日々の使い方を記録したもの。担当者が変わっても、同じように使えるようにします。

あわせて、困ったときに誰に連絡するか、改善の要望をどう集めるかも決めておきます。

まとめ

• DXプロジェクトは、「設計」と「実行」の2段階、11の工程で進みます。
• 設計では、現状と目指す姿の差から課題を見つけ、解決策・機能・技術・データと業務フローの順に決めます。
• 解決策は、インパクト・工数・予算・期間の4つで比べ、ロードマップにします。
• 機能は解決策から、技術は機能と費用・予算・期間から決めます。
• 実行では、開発・導入テスト・移行・保守運用の順に進め、移行は段階的に行います。

今後、それぞれの工程について、ヒアリングの仕方、業務の棚卸し、課題の選び方、解決策と評価基準、機能の選定、技術の選定、開発の進め方を、個別の記事で詳しく解説していきます。