失敗しない基幹システム刷新の進め方
よくある失敗の構造と、現行システム資産の解析から動く画面での合意までをひと続きに進めるFormula AIの刷新の進め方をご紹介します。
刷新が失敗する構造
長年の改修を重ねた基幹システムは、属人化・保守費の増大・ブラックボックス化という共通の課題を抱えます。いわゆる「2025年の崖」で指摘された構図ですが、根にあるのは一つ——設計書と実装の乖離、つまり現行の仕様が信頼できる文書として残っていないことです。刷新プロジェクトのつまずき方も、業種を問わずよく似ています。
| 失敗パターン | 根にあるもの |
|---|---|
| 要件定義の認識齟齬 | 文書に合意しても解釈は読み手ごとに揺れる。ずれを確かめられるのは動くものができた後で、発覚が遅いほど手戻りは高くつく |
| ベンダー丸投げ | 何を守り何を変えるかは経営判断そのもの。IT部門とベンダーだけの体制では、業務上の判断が必要な局面で意思決定が止まる |
| 現行業務の焼き直し | 現行の仕様が見えないまま「今と同じ」を選び、非効率な業務や使われない機能までそのまま引き継ぐ |
| テストと移行の圧縮 | 上流の遅れを後工程で吸収する計画になり、品質問題が稼働後に顕在化する |
| 設計書の再陳腐化 | 稼働後の改修で文書の更新が後回しになり、数年で次のブラックボックスができる |
このうち認識齟齬と再陳腐化は、担当者の力量の問題ではありません。「文書で合意する」「設計書を手で維持する」という進め方の仕組みに原因があります。Formula AIは、この2点を仕組みごと置き換えます。
Formula AIによる刷新の進め方
Formula AIは、AIによる現行解析から仕様書化・生成・検証までをひと続きの工程で進めます。取り込む素材と生成される成果物は次のとおりです。
取り込む素材
- ソースコード・DB定義などの現行システム資産
- 設計書・帳票・Excel台帳などの業務資料
- 議事録・スライドに残る要望や決定事項
生成される成果物
- 画面・API・ルールをIDで相互参照する仕様書
- 動く画面・API・DB・権限・テスト
- 設計書類・操作マニュアル
- 検証結果と監査ログの記録
- 01目的とスコープの明確化——現行踏襲を目的にせず、刷新で何を変えるかを経営の言葉で定義します。
- 02現行解析と仕様書の復元——AIが現行システム資産と業務資料を読み解き、現行の仕様書を復元します。貴社の有識者の確認を経て確定します。
- 03動く画面での要件確認——仕様書から画面とAPIを生成し、業務部門が操作して確かめます。
- 04一括生成と検証——画面・API・DB・権限・テストを一括で生成し、検証ゲートを通します。
- 05段階移行と定着——業務単位で切り替えます。仕様書起点の変更サイクルが定着するまでを完了条件に含めます。
文書の往復ではなく動く画面で合意する
要件定義書は自然な日本語で書かれ、解釈は読み手ごとに揺れます。暗黙知は文書に写しきれず、ずれを確かめられるのは動くものができた後——文書を介した合意には、丁寧さでは越えられない限界があります。
Formula AIは、確認する対象を文書から動く画面に変えます。仕様書から画面とAPIを生成し、要件確認の段階で業務部門が操作して確かめます。認識のずれは、修正の負担が小さい上流で表面化します。
仕様書と画面は同じ源から生成され、画面・API・ルール・テストはIDで相互参照されます。画面で確認して合意した内容はそのまま仕様書に残り、「この画面はどの要件に基づくか」を後からでも辿れます。設計書と実装の乖離は、この構造が防ぎます。
立場の異なる三者が同じ成果物を見て判断できることは、丸投げを防ぐ推進体制の土台にもなります。
動く画面で確認する
資料の説明ではなく、実際に操作できる画面で要件を確かめます。合意した内容は仕様書に残ります。
仕様書と記録で統制する
仕様書と検証の記録を起点に、品質・変更・セキュリティを統制します。判断の根拠を文書で示せます。
成果物で進捗を判断する
報告の言葉ではなく、仕様書や画面といった成果物の積み上がりで進捗を判断できます。
生成のたびに検証を通し証跡を残す
合意した仕様書から画面・API・DB・権限・テストを一括で生成し、読み取り専用の検証ゲートを通します。合格しない生成は差し戻して再生成され、どの項目をどのチェックで確認したかが記録として残ります。品質の判断を、人の申告ではなく記録で示せます。
稼働後にレガシー化させない変更サイクル
刷新の評価は稼働日で終わりますが、システムの寿命はそこから始まります。稼働後の変更要求は、コードの改修ではなく仕様書への反映から始まります。
- 変更差分が記録され、影響を受ける範囲だけを再生成します
- 仕様書・テスト・操作マニュアルが変更のたびに更新されます
- 誰がいつ何を変更したかが監査ログに残り、要件から実装・テストまでIDで辿れます
設計書の維持を担当者の努力に頼らないため、5つ目の失敗パターン——設計書の再陳腐化を仕組みとして防ぎます。
ベンダー選定前に動くもので判断する
RFIやRFPという文書と提案書の往復で判断する限り、認識のずれは選定の時点では見えません。Formula AIでは、対象業務を小さく区切り、現行システム資産の取込から仕様書の復元・動く画面までを選定前に確かめる進め方をご相談いただけます。
あわせて、ベンダー・製品比較の評価軸に「稼働後も仕様書が最新に保たれるか」を加えることをおすすめします。その一点が、今回の刷新が次のブラックボックスを作るかどうかを分けます。
よくあるご質問
- Q設計書が残っていない場合でも刷新を進められますか？
- A進められます。Formula AIは、ソースコードなどの現行システム資産と、帳票・Excel台帳・議事録といった業務資料を取り込み、仕様書を復元するところから始めます。復元した仕様書は貴社の有識者の確認を経て確定するため、実態と合わない文書を前提に進める心配はありません。
- Q全面刷新ではなく段階的な移行はできますか？
- Aできます。業務単位で対象を区切り、段階的に切り替える進め方を標準としています。並行稼働や切り戻しの計画は、貴社の環境に合わせた個別設計としてご相談のうえ決めていきます。
- Qどのような業務が対象になりますか？
- A対象はエンタープライズの基幹業務です。販売・購買・生産・在庫・会計など、業務資料と現行システム資産がそろう領域を中心にご相談いただけます。詳細は資料またはお問い合わせでご確認ください。