情シス1人でもできる？システム刷新の体制づくり実践ガイド

「誰がプロジェクトをまとめるのか」が決まらないまま、システム刷新に着手する企業がある。担当者が情シス一人、事業部門は「ITは情シスの仕事」と距離を置き、ベンダーに言われるがまま進む。結果は予算超過、スコープ肥大、稼働延期という三重苦だ。

IPA「ソフトウェア開発データ白書2018-2019」は、プロジェクト失敗の約半数が要件定義に起因すると分析している（出典：IPA ソフトウェア開発データ白書2018-2019）。要件定義は情シスとユーザー部門が協働して進めるプロセスだ。どちらかが欠けた体制でこの工程を乗り越えることはできない。

本記事では、システム刷新プロジェクトの体制設計を実務者の視点で解説する。PMOの要否判断、情シスと事業部門それぞれの正しい役割、外部ベンダーとの協働モデル、そして少人数でも回せる体制の作り方を順に説明していく。

なぜ「体制」がシステム刷新の成否を左右するのか

システム刷新は一部門の仕事ではない。現行システムの調査から要件定義、開発・テスト、本番切り替えまで、複数の部門とベンダーが交差するプロジェクトだ。誰が何を決め、どこに報告し、どこで合意するのかが曖昧なまま走り出すと、課題が滞留し続ける。

具体的な弊害は3つある。

1. 意思決定の遅延

「この要件は対応する・しない」の判断がPMに権限がなく、都度オーナーへのエスカレーションが発生する。週1回の会議で合意が得られなければ、2週間スケジュールが止まる。

2. 責任の空白

「それは情シスの担当では」「いや事業部門に決めてもらわないと進まない」という押し付け合いが、特に要件定義フェーズで多発する。

3. ベンダーへの過度な依存

発注側の体制が弱いと、ベンダーがプロジェクトを実質主導する。ベンダーは自社の利益（工数最大化、既存提案の採用）を優先する場合があり、発注側の利益と必ずしも一致しない。

体制を設計する目的は、これら3つの弊害を構造的に排除することにある。

システム刷新プロジェクトの基本体制図

刷新プロジェクトには、少なくとも以下4つの役割を配置する。プロジェクト規模や社内リソースによって兼務や外部委託の組み合わせは変わるが、役割そのものは省略してはならない。

この表で一つ注目してほしいのは、PMを「事業部門のリーダークラス」に置いている点だ。多くの企業では情シスがPMを担っているが、これは避けるべき構造である。次のセクションでその理由を説明する。

情シスがPMをやってはいけない理由

情シスはシステムに詳しい。だからこそPMに就くことが多い。しかし、この配置には構造的な問題がある。

技術サイドに立ちすぎる

情シスはシステムの制約を熟知している。その知識は「これは難しい」「ベンダーの提案が現実的」という方向に働きやすく、業務要件を妥協させる判断につながる。

ベンダーコントロールが甘くなる

技術的な話ができる情シスとベンダーは、ともすれば「技術者同士の合意」を優先し、ビジネス側の要求が後回しになる。情シスがPMとして最終判断者になると、ビジネス観点でのブレーキが効かなくなる。

ゴールが「プロジェクト完遂」ではなく「技術的な完成」にズレる

情シスの評価軸はシステムの品質だ。しかしプロジェクトのゴールは「業務改善」や「経営課題の解決」にある。評価軸が異なる人間がPMを担うと、優先順位が歪む。

情シスが最も力を発揮できる役割はPMOだ。技術的なリスクの把握、ベンダーの成果物レビュー、課題管理の事務局。これらはシステムを理解している情シスの強みが直接活きる領域である（参考：情シスコンサルティング「なぜIT部門・情シスがプロジェクトマネージャーをやってはいけないのか？」）。

PMO設置の判断基準：何人月から必要か

PMOを設置すべきかどうかは、プロジェクトの規模と複雑さで判断する。費用がかかるため、小規模案件で設置しても費用対効果が出ない。目安となる判断基準を示す。

PMO設置が必要な条件

規模の目安

• 総工数が100人月以上
• 関与部門が3部門以上
• ベンダーが2社以上並行稼働

状況の目安

• PMにプロジェクト経験が少ない
• 複数のサブプロジェクトが並行する（例：受注管理と在庫管理の同時刷新）
• 重要な意思決定を経営層に対して定期的に報告する必要がある

PMO設置が不要なケース

• 単一システムの入れ替えで部門間調整が最小限
• 50人月未満の小規模案件で、PMが経験豊富
• ベンダー1社への完全委託で社内の調整負荷が少ない

この場合はPM一人が計画・進捗管理・事務局を兼務する「ライトPM体制」で対応できる。ただし、その場合もPMを情シス担当者ではなく事業部門に置く原則は変えない。

事業部門の役割：「ITは任せた」は失敗の入り口

「システムのことは情シスに任せる」という姿勢の事業部門は、刷新プロジェクトの最大のリスク要因だ。業務要件を決められるのは現場だけであり、情シスもベンダーも、業務の実態を代替できない。

事業部門が担うべき3つの役割

役割1：業務要件の一次責任者

「この業務ではこういう処理が必要」という判断は事業部門にしかできない。要件定義フェーズで業務リーダーが週次で参加できる体制を組む。「月1回しか時間を取れない」という事業部門は、要件定義を完走できない。

役割2：受入テスト（UAT）の実施主体

システムが業務要件を満たしているかどうかを確認するのは、その業務を実際に行う人間だ。情シスがUATを代行しても、業務現場の実態とのズレを発見できない。

役割3：プロジェクトオーナーの担当

投資判断と最終承認は、そのシステムで業務する部門の長が持つべきだ。「IT投資だから情シス部門長が承認すれば良い」という組織は、誰も刷新の成否に責任を持たない構造になる。

IPA「DX白書2023」は、DXを組織横断で推進している企業の割合が日米で13.9ポイントの差があることを指摘している（出典：IPA DX白書2023）。体制の壁が、日本企業のDX遅延の一因だ。

着手金0円・完全後払い。まずはお見積り → SysDock（シスドック）

現行システムの構造が把握できていなければ、事業部門も要件を定義できない。SysDockはAIマルチエージェントがソースコードから依存関係・業務フロー・技術的負債を1週間で可視化。情シス・事業部門・ベンダーが共通言語で話し合えるWordレポート+PPTスライド+React Flowフロー図を納品する。ライト30万円から。

外部ベンダーとの協働モデル：3つのパターン

ベンダーとの関係設計はプロジェクトの成否を左右する。発注側とベンダーの役割分担には、代表的な3つのパターンがある。

パターン1：主幹ベンダー型（1社委託）

特徴：要件定義から設計・開発・テスト・移行まで、1社のベンダーに一括委託する。

メリット：発注側の管理負荷が低い。ベンダー間の調整コストがゼロ。

デメリット：発注側がベンダーに依存しやすい。価格交渉力が弱まる。ベンダーの品質問題が全工程に波及する。

適するケース：社内にITリソースが少なく、プロジェクト経験も薄い中小企業。ただしPM機能だけは発注側が持つことが必須条件だ。

パターン2：PMO分離型（PMO外部委託）

特徴：PMO機能を専門会社に委託し、開発は別のベンダーへ発注する。

メリット：PMOが開発ベンダーとは独立した立場でチェック機能を果たす。品質と進捗の客観的な監視が働く。

デメリット：PMO委託費が追加でかかる。2社間の連携コストが発生する。

適するケース：プロジェクト経験の少ない情シスが体制の中心になる場合。PMOが中立的に機能することで、ベンダーのリスクをコントロールできる。

パターン3：内製開発型（ベンダー協調）

特徴：設計・要件定義は社内で進め、開発工程に技術者派遣を活用する。

メリット：要件定義の品質が高まる。社内にノウハウが蓄積する。

デメリット：内製を担えるエンジニアが社内にいることが前提。技術者管理コストが発生する。

適するケース：情シスにエンジニアがいる中堅以上の企業、またはDX推進室を新設した企業。

選択基準はシンプルだ。「社内にどれだけの人材・時間・スキルがあるか」だけを見て判断する。予算規模ではなく、リソースの実態で選ぶ。

少人数体制でシステム刷新を進める現実解

「情シスが1〜2名で、専任PMも置けない」という企業は少なくない。そうした状況でも刷新を進める方法がある。

現実解1：役割の兼務とスコープ分割

少人数では全役割をカバーできないため、優先順位をつける。PMとPMOは同一人物が兼務し、業務リーダーを各部門から1名ずつ出してもらう。スコープも一括刷新ではなく、フェーズ分割で段階的に進める。

一括刷新は大きなリスクを伴う。フェーズ1で受注管理を刷新し、安定稼働を確認してからフェーズ2で在庫管理に着手する方式なら、少人数でも管理できる範囲に収まる。

現実解2：外部PMOの限定活用

PMO専門会社を全期間通して委託するのではなく、要件定義フェーズの3ヶ月のみスポット契約する方法がある。最もリスクが高い上流工程だけ外部の目を入れ、下流の進捗管理は情シスが担う。コストを抑えながらPMO機能を確保できる。

現実解3：ベンダーのPMを活用しつつ牽制する

ベンダーにPM機能を依存する場合でも、月次のステアリングコミッティで経営層が直接進捗を確認する会議体を設ける。経営層が定期的に関与することで、ベンダーが進捗を誇張したり、問題を隠蔽したりするリスクを抑制できる。

経済産業省の中堅・中小企業向けDX推進ガイドラインでも、IT人材が不足する場合は外部機関を活用しながら社内のノウハウを蓄積する並行戦略を推奨している（出典：経済産業省「中堅・中小企業等向けDX推進の手引き2025」）。

体制設計でよくある失敗パターン3選

失敗パターン1：ステアリングコミッティの形骸化

月次で役員が集まる会議を設けたが、PMからの報告を聞くだけで意思決定が行われない。課題が滞留し、PMが一人で判断を抱え込む状態に陥る。

対策：ステアリングコミッティの議題を「報告」ではなく「判断」に設計する。毎回必ず1〜2件の意思決定事項をアジェンダに入れ、判断を求める場にする。

失敗パターン2：業務リーダーの兼務過多

事業部門の業務リーダーが本来業務と並行してプロジェクトに参加するため、要件定義の会議に遅刻・欠席が常態化する。要件が確定しないまま設計が進み、後から大量の修正が発生する。

対策：業務リーダーの参画時間を「週X時間」と明示的に計画書に記載し、部門長から約束を取りつける。プロジェクトオーナーが部門長に協力を要請する場を設けることが有効だ。

失敗パターン3：ベンダーへの情報非対称

現行システムの仕様書がなく、ベンダーに情報を与えられないまま提案依頼をする。ベンダーは不確実性をリスクとして見積もりに上乗せするため、費用が過大になる。あるいは、情報が少ないまま契約し、調査後に追加費用が請求される。

対策：ベンダーに提案を依頼する前に、現行システムの構造を自社で把握しておく。システム刷新プロジェクト計画書テンプレートでも指摘したとおり、現状分析フェーズへの投資がプロジェクト全体のコストを下げる。

体制設計の実践チェックリスト

プロジェクト着手前に、以下の項目をすべて確認する。一つでも「No」があれば、着手前に手を打つ。

まとめ：体制設計は着手前の最優先事項

システム刷新において、体制設計はツール選定や予算策定より先に行うべき作業だ。誰が何を決め、誰が何に責任を持つかが明確でなければ、どんなに優れたシステムを選んでも、プロジェクトは漂流する。

情シスはPMOとして強みを発揮する。PMは事業部門が担う。ベンダーは管理の対象として位置づける。少人数であればスコープを絞り、外部の専門家をスポット活用する。

これらの原則は、プロジェクトの規模に関わらず共通だ。500人月の大規模刷新も、50人月の中規模案件も、体制設計の基本構造は変わらない。

着手金0円・完全後払い。まずはお見積り → SysDock（シスドック）

体制設計と並行して必要なのが、現行システムの構造把握だ。「何があるか」「どこが複雑か」「どこからリスクが生じるか」を把握していなければ、スコープも工数も役割分担も設計できない。SysDockはAIマルチエージェントが13言語・FW対応でソースコードを解析し、1週間でWordレポート+PPTスライド+React Flowフロー図を納品する。ライト30万円、スタンダード50万円、プレミアム80万円。ソースコード非送信・完全後払い。

お見積りはこちら → sysdock.genbacompass.com

現場改善に役立つ関連ツール

GenbaCompassでは、SysDock以外にも現場のDXを支援するツールを提供している。

参考文献

• IPA「ソフトウェア開発データ白書2018-2019」
• IPA「ソフトウェア開発分析データ集2022」
• IPA「DX白書2023」
• IPA「DXを推進する体制とは？先進企業の6つの事例から学ぶDX推進の体制づくり」
• 経済産業省「中堅・中小企業等向けDX推進の手引き2025」
• 情シスコンサルティング「なぜIT部門・情シスがプロジェクトマネージャーをやってはいけないのか？」
• addlight journal「なぜPMOが必要なのか〜基幹システム導入におけるPMOの必要性〜」