基幹システムの刷新は、開発会社が技術を担うだけで完結するものではない。何を作るかを決め、現場の業務と擦り合わせ、判断を下すのは発注側の役割である。ここがあいまいなまま開発会社に任せきりにすると、決めごとが進まず、プロジェクトが停滞する。逆に、発注側に意思決定と現場をつなぐ体制があれば、刷新は着実に前へ進む。

本記事は、移行プロジェクトを進めるための発注側の体制と、プロジェクトマネジメントの考え方を、発注者の視点で整理する。読者として想定しているのは、中小企業の経営者、DX担当、情シス担当、事業責任者である。専任の担当を多く置けない企業でも、最低限の役割分担と意思決定の仕組みを整えることで、プロジェクトは回せる。

結論：意思決定者を決め、現場をつなぐ体制を発注側に置く

移行プロジェクトの体制づくりで、GXOが重視するのは次の3点である。

  • 最終的に判断する意思決定者を、早い段階で明確にする
  • 開発会社と現場をつなぐ窓口役を、発注側に置く
  • 現場を早くから巻き込み、業務の実態を設計に反映する

刷新は、技術以上に「決めること」と「擦り合わせること」が多い。誰が決めるか、誰がつなぐかを先に固めておくと、プロジェクトが止まりにくくなる。RFPやベンダーへの質問を整理する段階の考え方は基幹システム刷新の進め方｜刷新のRFPと開発会社への質問も合わせて参照されたい。

なぜ発注側の体制が必要か

刷新を開発会社に任せきりにすると、次のような問題が起きやすい。開発会社は技術を担えても、何を作るべきかや、どの業務を優先するかを決めるのは発注側にしかできない。発注側に体制が要る理由はここにある。

  • 判断が滞る：仕様の選択や優先順位を決める人がおらず、開発が止まる。
  • 業務とずれる：現場の実態が設計に反映されず、使えないシステムになる。
  • 窓口が分散する：開発会社の問い合わせ先が定まらず、回答が遅れたり食い違ったりする。
  • 責任が曖昧になる：何かあったとき、誰が決めるべきだったかが分からなくなる。

これらは、発注側の役割を最初に決めておけば避けられる。体制づくりは、プロジェクトを開始する前の準備段階で行いたい。

発注側に必要な役割

発注側の体制は、大きく三つの役割に整理できる。一人が兼ねることもあるが、役割としては分けて考えておきたい。

役割主な担当期待される動き
意思決定者経営者・事業責任者範囲・予算・優先順位を最終判断する
推進担当DX・情シス担当開発会社と現場をつなぐ窓口になる
業務担当現場のキーパーソン業務の実態を伝え、仕様を確認する

意思決定者は、すべての会議に出る必要はないが、重要な判断が必要な場面では速やかに決められる立場の人がよい。推進担当は、日々のやり取りを担い、論点を意思決定者に上げる。業務担当は、現場で実際に使う立場から、仕様が業務に合うかを確認する。この三者がそろうと、決めごとが滞りにくくなる。中小企業では、一人が意思決定者と推進担当を兼ねたり、限られた人数で複数の役割を担ったりすることも多い。それ自体は問題ないが、役割を頭の中で分けておかないと、判断とやり取りが混ざって抜けが出やすい。誰がどの立場で動いているかを意識しておきたい。

プロジェクトマネジメントの基本

刷新を進めるには、進捗・課題・判断を管理する仕組みが要る。専門のPMを開発会社が担う場合でも、発注側がその動きを理解しておくと連携がうまくいく。

進捗を見える化する

何がどこまで進んでいるかを、双方で共有できる形にしておく。スケジュールに対して遅れがあれば、早めに分かるようにしておきたい。

課題を放置しない

検討が必要な論点や、決まっていないことを一覧で管理し、誰がいつまでに対応するかを決める。課題が滞留すると、後工程に影響が連鎖する。

判断の場を定期的に持つ

定例の打ち合わせで、上がってきた論点を意思決定者が判断する。判断の場が定期的にあると、決めごとが溜まらずに済む。逆に、判断の場が不定期だと、決まらない論点が積み上がり、開発の手が止まってしまう。短い時間でもよいので、定期的に判断の場を持つことを勧める。移行方式の選択など、大きな判断は基幹システム刷新の進め方｜段階移行か一括移行かの論点とも関わってくる。

現場の巻き込み方

刷新したシステムを実際に使うのは現場である。設計の段階から現場を巻き込んでおかないと、稼働後に「使いにくい」「業務に合わない」という声が出やすい。

  • 早い段階で意見を聞く：要件を固める段階から、現場のキーパーソンに業務の実態を聞く。
  • 負担を考慮する：現場は通常業務を抱えている。プロジェクトへの関与が過度な負担にならないよう配慮する。
  • 変化を事前に伝える：業務のやり方が変わることを早めに共有し、稼働時の混乱を抑える。

現場を巻き込むことは、よりよい仕様を作るためだけでなく、稼働後に新システムを受け入れてもらうためにも重要である。一方的に決めて押し付けると、運用が定着しにくい。

巻き込みの度合いは、業務によって調整したい。すべての現場を均等に関わらせるのではなく、刷新の影響が大きい業務や、独自の運用がある業務を担う人を重点的に巻き込むと、限られた負担で効果が出る。誰を巻き込むべきかは、現状の棚卸しで業務の重要度を把握しておくと判断しやすい。

体制づくりでよくある失敗

体制づくりでは、次のような失敗が起きやすい。

  • 意思決定者が不在：判断する人が決まっておらず、論点が宙に浮いてプロジェクトが停滞する。
  • 窓口が一本化されていない：複数の人がばらばらに開発会社とやり取りし、指示が食い違う。
  • 現場を後から巻き込む：設計が固まってから現場に見せ、大きな手戻りが発生する。
  • 推進担当に負荷が集中する：一人にすべてが集まり、その人が動けないと全体が止まる。

これらは、役割と進め方を最初に決めておけば避けられる。専任を多く置けない場合でも、誰が何を担うかを明確にすることが、停滞を防ぐ鍵になる。

開発会社との役割分担

体制は、発注側だけで完結するものではない。開発会社とどう役割を分けるかも、あわせて決めておきたい。境界が曖昧だと、双方が相手任せにして抜け落ちる作業が出る。

領域発注側の役割開発会社の役割
要件の決定業務の実態を伝え判断する選択肢と影響を提示する
進行管理課題を判断し優先順位を決める進捗を管理し論点を上げる
現場調整現場との橋渡しをする業務ヒアリングを支援する
移行作業データや業務の確認を担う移行の設計と実装を担う

この分担に正解はなく、自社の体制と開発会社の支援範囲によって変わる。重要なのは、どちらが担うか曖昧な作業を残さないことである。特に、判断を要する場面は発注側、技術を要する場面は開発会社という大枠を共有しておくと、互いの期待がずれにくい。

役割分担は、プロジェクトの途中で見直すこともある。当初は開発会社に任せていた部分を、慣れてきたら自社で担うように切り替えることもある。最初に固定して終わりにせず、状況に応じて調整できる関係を作っておきたい。

相談前に整理しておくとよい情報

体制づくりについて相談する前に、社内の状況を整理しておくと、現実的な進め方を一緒に描きやすい。多くの人手を割けない場合でも、誰が関われるかが見えていれば十分である。

  • 刷新の方針を最終的に判断できる立場の人は誰か
  • 開発会社とのやり取りを担える窓口役の候補がいるか
  • 刷新の影響が大きい業務と、その業務を担う現場のキーパーソン
  • 関われる人がどの程度の時間を割けるか
  • 過去にシステム導入や刷新を経験した人が社内にいるか

これらが整理されていなくても相談は可能である。専任を置けない前提でも、決める人とつなぐ人の候補が見えていれば、限られた人数で回せる体制を一緒に設計できる。無理のない関わり方から考えていきたい。

よくある質問

Q1. 専任の担当を置く余裕がありません。それでも刷新できますか

専任でなくても、役割を明確にすれば進められる。一人が複数の役割を兼ねる形でもよいが、意思決定者と窓口役だけは決めておきたい。誰が決め、誰がつなぐかがはっきりしていれば、限られた人数でもプロジェクトは回せる。

Q2. プロジェクトマネジメントは開発会社に任せてよいですか

進行管理を開発会社が担うのは一般的だが、発注側でも進捗と課題を把握しておきたい。判断は発注側にしかできないため、上がってきた論点を速やかに決められる体制が要る。任せきりにせず、判断の場を持つことが大切である。

Q3. 現場が忙しく、プロジェクトに関わってもらえません

現場の負担に配慮しつつ、要所だけでも関わってもらう形を探りたい。すべての会議に出てもらう必要はなく、業務の実態を確認する場面や、仕様を確認する場面に絞って関わってもらうと、負担を抑えながら現場の声を反映できる。

移行プロジェクトの体制づくりから、刷新の進め方を一緒に整理しませんか

GXOでは、専任の担当を多く置けない企業でも回せるよう、発注側の役割分担、意思決定の仕組み、現場の巻き込み方を整理し、プロジェクトの進め方をご支援します。技術だけでなく、進め方の面から刷新を支えます。

基幹システム刷新の相談をする

※ 初回相談では、営業資料の説明よりも現状整理とリスク確認を優先します。