社内プロジェクト体制を作る企業にとって、最初から大きな開発を決める必要はありません。まずは現行業務・帳票・データ・連携・保守状況を整理し、延命、部分改善、パッケージ活用、周辺開発、スクラッチ再構築のどれが現実的かを見極めることが重要です。
マクティズムでは、作り直しありきではなく、情シスだけでなく、現場責任者と意思決定者を入れることを重視して進め方を整理します。
この記事では、基幹システム再構築の社内プロジェクト体制をどう設計すれば、開発が始まった後に迷走しないかを整理します。体制づくりを任された情報システム担当者と、推進体制の承認を求められている経営層の双方に向けた内容です。
この記事で分かること
- 基幹システム見直しで確認すべきポイント
- 延命・部分改善で済むケース
- パッケージ活用や周辺開発を検討すべきケース
- スクラッチ再構築を検討すべきケース
- 相談前に準備しておく情報
まず結論｜すぐに作り直す前に現状を整理する
基幹システムは、受注・出荷・在庫・請求・生産・会計連携など、複数の業務にまたがります。そのため、表面上の不具合だけを見て判断すると、後から帳票、データ移行、外部連携、現場運用で想定外の問題が出ることがあります。
まず必要なのは、現行システムの全体像を把握することです。特に、どの業務が止まると困るのか、どの帳票が実際に使われているのか、どのExcel・Access・CSV運用が周辺に残っているのかを確認するだけでも、再構築の方向性はかなり明確になります。
体制の失敗は「人が足りない」ではなく「役割が決まっていない」
プロジェクト体制の問題でよく挙がるのは人数不足ですが、実際に迷走するのは人数が十分でも役割が曖昧なケースです。誰が要件を確定するのか、部門間の意見が割れたら誰が裁くのか、開発会社との窓口は誰か、テストの段取りは誰が仕切るのか。この四つの役割に名前が入っていれば、少人数でも回ります。逆に名前がないまま人数だけ増やすと、全員が他の誰かが決めると思って判断が止まります。
情シスだけの体制は最大の構造リスク
基幹システムの再構築は、システムの作り直しではなく業務の作り直しです。業務の現場を知らない情報システム部門だけで要件を決めると、完成後に「こんなはずではなかった」という声が各部署から噴出します。営業・製造・経理など主要業務から実務を語れるキーパーソンを体制に入れ、その人たちの参画時間を部署として正式に確保することが、体制設計の最重要ポイントです。
このテーマでよく起きる問題
このテーマでよく起きる問題は、技術的な問題に見えて、実際には業務整理の不足から起きていることが多いです。たとえば、同じ機能でも部署ごとに運用が違う、帳票は同じ名称でも用途が違う、CSVの出力タイミングが担当者依存になっている、といったケースです。
この状態でパッケージを入れたり、スクラッチで作り直したりすると、開発途中で追加要件が増え、費用と期間が膨らみやすくなります。
よくある失敗は、キーパーソンを任命したものの通常業務が減らされず、打ち合わせに出られない・資料を見る時間がないという状態が続くケースです。名ばかりの参画は、参画しないのと同じか、それ以上に悪い結果を招きます。形式的に名前を入れた安心感で問題の発見が遅れるからです。
また、プロジェクトオーナー（最終意思決定者）が不在、あるいは関心が薄いまま進むケースも危険です。部門間の調整は現場だけでは解決できない場面が必ずあり、そのときにオーナーが裁定しなければ、判断待ちが積み上がって開発が停滞します。オーナーの参画は月に数時間でよいのですが、その数時間が確保されないと全体が動かなくなります。
さらに、社内体制と開発会社の体制の間で役割が重複したり、逆に空白になっている領域も要注意です。要件の確定は発注側、技術的な実装は開発側、という基本の線引きを契約前に合意しておくことが、責任の押し付け合いを防ぎます。
自社で確認できるチェックポイント
体制を設計する前に、次の点を確認しておくと、必要な役割と人の配置が具体的になります。
- 現在のシステムで実際に困っている業務を1つずつ書き出す
- 画面・帳票・CSV・バッチ・Excel補完作業を棚卸しする
- 利用部署、利用人数、締め処理、止められない業務を確認する
- サーバー、データベース、外部連携、バックアップの状態を確認する
- 現行システムを残す部分、直す部分、作り直す部分を分ける
- パッケージで足りる業務と、周辺開発が必要な業務を分ける
- 初期費用だけでなく、保守・追加改修・移行リスクも比較する
体制設計ならではの棚卸しポイント
基本のチェックリストに加えて、プロジェクトオーナーを担える経営層の候補、各部門から出せるキーパーソンの名前と稼働可能な時間、情報システム担当者の人数と兼務状況、過去のプロジェクトでの体制の成功・失敗体験を確認してください。特に「稼働可能時間」は理想ではなく現実で見積もることが重要で、週4時間が精一杯ならそれを前提に計画を組むほうが、週20時間を約束して守れないよりはるかに健全です。
体制には「記録と共有」の担い手も明確に置いてください。決定事項・検討経緯・保留事項を議事録として残し、次の会議の冒頭で確認する。この地味な運営が、メンバーの入れ替わりにも耐えるプロジェクトを作ります。記憶に頼る運営は、人の異動と同時に崩壊します。
体制の設計では、合意形成のルールも決めておくことをおすすめします。全員一致を求めると判断が止まります。「検討は全員で、決定は実務責任者が、対立はオーナーが」という階層を宣言しておくだけで、議論が前に進みやすくなります。議論の質は高く、決定の速度は速く。この両立が、よい体制の証拠です。
延命・部分改善で対応できるケース
プロジェクト体制は規模によって大きく変わります。次のような場合は、軽い体制でも成果を出せます。
- 対象業務が限定されている
- 帳票やCSV連携の一部改善で足りる
- データベース改善やバックアップ自動化で安定運用できる
- 利用者が限られており、現場への影響が小さい
- 将来の全面刷新までの橋渡しとして改善したい
たとえば500万〜1,000万円規模の部分改善なら、担当者1名＋経営からの承認ルートで十分な場合もあります。この規模で重い体制を組むのは過剰であり、意思決定の速さこそが小さなプロジェクトの武器です。体制は規模に合わせて軽重を付けるものであり、常に重厚である必要はありません。
逆に、3,000万円を超えるような規模で担当者1名に任せきりにするのは過少であり、専任化と部門横断の体制が必須になります。体制の軽重の判断基準は、「この人が抜けたらプロジェクトが止まるか」で測ってください。止まるなら、体制が薄すぎるサインです。
体制づくりにかかるコストは、人の時間です。プロジェクト期間中のキーパーソンの稼働を金額換算し、プロジェクト総費用に含めて計画する企業ほど、途中で「人が出せない」問題に遭わずに済みます。社内コストを見えるようにすることが、経営の理解を得る近道です。
パッケージ活用・周辺開発・スクラッチ再構築を検討すべきケース
体制の設計は、構築方式によって力点が変わります。
- 保守期限が近く、現行環境を長く使えない
- 開発会社がなく、改修や障害対応が難しい
- Access・Excel・古いDBではデータ量や運用に限界がある
- パッケージ標準機能が業務に合わない
- 周辺システムや帳票が増え、全体像が分からない
- 今後も機能追加や外部連携が増える見込みがある
パッケージ活用が向くケース
パッケージ導入では、業務を標準に寄せる変革を各部門に浸透させる推進力が体制の中心課題です。システムに詳しい人より、業務変更を説明して納得を得られる人を厚く配置してください。
周辺開発で補うケース
段階的な周辺開発では、各段階で対象業務の担当者を入れ替えつつ、全体の設計思想を貫く人が一貫して関わる構成が理想です。番人役を一人置くだけで、段階間の整合が保たれます。
スクラッチ再構築が向くケース
スクラッチの全面再構築では、業務領域ごとに要件を確定できるサブリーダーを配置し、領域間の調整をプロジェクトマネージャーが担う分業型が有効です。一人にすべてを集中させるのは、規模的に無理があります。
マクティズムの見解
マクティズムの見解として、基幹システム再構築プロジェクトの社内体制の作り方では「何を作るか」より先に「何を残すか、何を直すか、何を作り直すか」を決めることが重要です。
特に、情シスだけでなく、現場責任者と意思決定者を入れることを意識しないまま進めると、パッケージを入れても周辺Excelが残ったり、スクラッチで作っても現場が使いにくかったりします。相談段階では、資料が完全にそろっていなくても問題ありません。画面、帳票、運用メモ、担当者の記憶を集めるところから始めるべきです。
体制の相談で私たちがまず行うのは、理想論を押し付けることではなく、今いる人と時間でどこまでできるかを一緒に考えることです。足りない部分は外部支援で補う選択肢も含めて設計します。完璧な体制は世の中に存在しませんが、弱点を自覚している体制は十分に戦えます。弱さを知っていることそのものが、最初の強さです。
相談前に準備しておく情報
体制の相談では、プロジェクトの規模感と期間、候補となるメンバーの名前と稼働余力、経営のコミットの度合い、過去のプロジェクト経験が分かると、初回から具体的な布陣の話ができます。体制が足りないという不安そのものが、最も重要な相談材料です。
実務では、プロジェクト開始前に体制診断を行い、役割の空白と稼働の無理を洗い出したうえで、現実の人員で回せる体制案に落とし込む支援をおすすめしています。
そして体制は、一度組んだら固定ではなく、フェーズの変わり目で見直すものです。要件定義期は業務を語れる人を厚く、テスト期は検証の手を厚く。山場に合わせた組み替えまで計画しておけば、体制は最小限の人数で最大の効果を発揮します。
よい体制で完走したプロジェクトは、システムだけでなく、部門を超えた協力の経験を会社に残します。その経験は次のプロジェクトを、もっと少ない苦労で完走させる資産になります。体制づくりへの投資は、一つのプロジェクトを超えて効き続けるのです。
体制づくりは、役割の定義、候補者の選定と稼働確保、オーナーの確定、運営ルールの合意、の順で進めてください。この四つが揃えば、開発を始める準備の半分は終わっています。
外部のPMO支援や要件定義支援を活用する場合も、自社が主導権を持つことが前提です。外部は足りない能力を補う存在であり、判断を代わりに行う存在ではありません。どの判断を自社が行い、どの作業を外部に委ねるのかの線引きを、支援開始前に文書にしておくと、役割の混乱を防げます。
プロジェクトのキックオフでは、メンバー全員が顔を合わせ、役割と連絡先を共有する場を必ず設けてください。顔が見える関係から始めるだけで、後の連絡の速さと質が変わります。体制は図ではなく、人と人のつながりで動くものです。
なお、体制が固まるまでプロジェクトを始められない、と待つ必要はありません。まず始められる範囲（調査・診断）を軽い体制で動かし、本格開発に進む段階で本格体制を固める、という二段構えが現実には最もうまくいきます。
走りながら体制を磨いていく柔軟さも含めて、よい体制です。完璧を待たずに始めましょう。
最初の一歩は、今いる人で役割を決めることです。それだけで半分は動き始めます。
動きながら整えていけば、体制は自然とプロジェクトの形に馴染んでいきます。
よくある質問
要件がまとまっていなくても相談できますか？
はい。分かる範囲の業務内容、現在困っていること、使っている画面や帳票から整理できます。完璧な資料よりも、現状の困りごとを早めに共有することが大切です。体制の相談を含めて、整理されていない段階のご相談こそ歓迎しています。
すぐに全面再構築する必要がありますか？
いいえ。延命・部分改善で足りる場合もあります。まずは残す部分、直す部分、作り直す部分を切り分けます。はい。規模によっては担当者1名と承認ルートで十分回せるケースもあります。
パッケージとスクラッチのどちらがよいか判断できますか？
はい。業務が標準機能に合うか、帳票や例外処理をどう扱うか、将来の保守性まで含めて比較します。構築方式による体制の力点の違いも含めて、一緒に最適な形を探します。
500万円〜1,000万円規模の部分改善から相談できますか？
はい。データベース改善、帳票・連携、バックアップ自動化など、段階的な改善から始められる場合があります。はい。数百万円の改善は軽い体制で速く進めるのが正解です。
相談後にしつこい営業はありますか？
ありません。現状を確認したうえで、必要な進め方を整理します。無理に大きな開発を勧めることはありません。体制の不安を伺い、足りない部分をどう補うかから一緒に設計します。
