DXプロジェクトの進め方

DXプロジェクトの出発点は、技術の選定ではなく「何を変えたいのか」をそろえることです。経営層・事業部門・情報システム部門では、同じ『DX』でも思い描くゴールがずれていることが珍しくありません。プロジェクトマネージャーは最初にこのずれを表に出し、合意できる言葉に落とします。

具体的には、対象とする業務（受注処理、在庫管理、顧客対応など）を名指しし、変革後にどんな状態になっていれば成功かを定義します。この段階の成果物がプロジェクト憲章と、対象業務の現状を描いた業務フロー図です。現状フローを描くと、紙とExcelと基幹システムが混在して二重入力が発生している、といった具体的な課題が見えてきます。

• 変革の目的を一文で書く
  「月次の締め作業を短くする」のように、関係者が同じ絵を描ける粒度まで具体化します。
• 範囲の内と外を分ける
  今回触る業務と触らない業務を明記し、途中で膨らむのを防ぎます。

つまずきやすいのは、目的があいまいなまま先にツール導入を決めてしまう進め方です。目的が共有されていないと、後工程で「これは何のためだったか」という問い直しが起き、手戻りにつながります。

DXプロジェクトは、おおむね現状把握・あるべき姿の設計・システム構築・移行・定着という順で進みます。業務変更と開発が並行するため、どちらか一方だけ進めると現場が置き去りになります。

現状把握では、業務フロー図とともに、どの作業に時間がかかっているかを現場へのヒアリングで集めます。次のあるべき姿の設計では、新しい業務フローと、それを支える要件定義書を作ります。ここで業務側の担当者を巻き込まないと、できあがった仕組みが実際の作業と合わなくなります。

1. 現状把握と課題整理
   現行業務フローを描き、ムダや属人化している箇所を洗い出します。
2. 新業務とシステムの設計
   新業務フローと要件定義書を作り、何を自動化し何を人が担うかを切り分けます。
3. 構築・移行・定着
   システムを作り、並行稼働などで切り替え、マニュアルと研修で現場に根づかせます。

つまずきやすいのは、構築が終わった時点を完了と見なす進め方です。DXは現場が新しいやり方で日々回り始めて初めて成果が出るため、定着までを工程に含めて計画することが欠かせません。

DXプロジェクトは複数の部門にまたがるため、役割分担を早めに決めておくと判断が滞りません。登場するのは、意思決定を担う経営層やステアリングコミッティ、業務の実情を知る事業部門の担当者、システムを担う情報システム部門や開発ベンダー、そして全体を束ねるプロジェクトマネージャーです。

プロジェクトマネージャーは、誰が決裁し誰が実務を担うかを責任分担表で整理します。特にDXでは、業務ルールを変える権限を持つ人を明確にしておくことが重要です。現場の運用が変わる以上、業務側の責任者が意思決定に加わっていないと、設計が途中で止まります。

• 意思決定の場を用意する
  定例のステアリングコミッティで、範囲の変更や予算の判断を記録に残しながら進めます。
• 成果物を工程ごとに定める
  業務フロー図・要件定義書・移行計画・運用マニュアルなど、各工程の出口を先に決めます。

つまずきやすいのは、情報システム部門だけに任せてしまう体制です。業務の変更が伴うDXでは、技術側だけで進めると現場の納得が得られず、稼働後に旧来のやり方へ戻ってしまうことがあります。

DXプロジェクトの方法を考えるとき、通常のシステム開発やアジャイル開発との違いを押さえておくと、どの進め方を選ぶか判断しやすくなります。軸は「変える対象」と「決めてから作るか、作りながら決めるか」です。

通常のシステム開発は、既存業務を前提にそれをシステム化することが中心で、ウォーターフォールのように要件を固めてから作る進め方がなじみます。一方DXは業務そのものを変えるため、やってみないと最適な形が見えにくい部分が残ります。そこで、小さく作って現場で試し、反応を見て直すアジャイル寄りの進め方を一部に取り入れる場合があります。

• 固められる部分は決めてから作る
  基幹の業務ルールなど影響が広い箇所は、要件を定義してから構築します。
• 探索が必要な部分は試しながら
  現場の使い勝手に関わる画面などは、試作と改善を繰り返して形にします。

つまずきやすいのは、全部を一度に変えようとする進め方です。対象を広げすぎると関係者も成果物も増え、収拾がつかなくなります。まず一つの業務で成果を出し、そのやり方を横に広げる段階的な進め方のほうが、現場の負担を抑えやすくなります。

DXプロジェクトを進めた経験は、プロジェクトマネージャーのキャリアで扱える幅を広げます。業務部門・情報システム部門・経営層という立場の異なる関係者をつなぎ、目的の合意から現場定着まで一本で通した経験は、システム開発だけを担ってきた経歴とは別の強みになります。

職務経歴書に書くときは、担当した工程名と成果物、そして自分がどの判断を担ったかを具体的に記すと伝わりやすくなります。たとえば現状業務フローの可視化を主導した、業務側の責任者を巻き込んで要件定義をまとめた、定着まで運用マニュアルと研修を設計した、といった形です。技術と業務の両面を橋渡しできる点を示せると、変革を伴う案件を任せたい側からの評価につながりやすくなります。

DXプロジェクトは普通のシステム開発とどう違いますか。

最大の違いは、システムを作るだけでなく業務のやり方そのものを変える点です。既存業務をそのままシステム化するのではなく、現状の課題を踏まえて新しい業務フローを設計し、現場への定着までを工程に含めます。そのため業務部門の関与が欠かせません。

DXプロジェクトはどこから手をつければよいですか。

技術やツールの選定より先に、何のために変えるのかを関係者でそろえることから始めます。対象業務を名指しし、変革後の状態を定義し、現状の業務フローを描いて課題を具体化します。この土台があると、後工程での手戻りを抑えやすくなります。

DXプロジェクトが失敗しやすいのはどんなときですか。

目的があいまいなままツール導入を決めたとき、情報システム部門だけに任せたとき、構築完了を終わりと見なして定着を計画に入れなかったときに、つまずきやすい傾向があります。業務変更を伴う以上、現場が新しいやり方で回り始めるところまで見届ける進め方が求められます。