この記事では、要件定義で失敗したくない企業に向けて、判断すべきポイントを実務目線で整理します。マクティズムでは、いきなり作り直すのではなく、延命・部分改善・パッケージ活用・周辺開発・スクラッチ再構築のどれが現実的かを、現行業務と帳票・データから確認することが重要だと考えています。
この記事で分かること
- 現行踏襲と改善の切り分け
- 帳票・バッチの見落とし
- 部門間の意見不一致
- 例外処理の未整理
- 移行データの軽視
- 責任範囲の曖昧さ
- 診断で整理する価値
まず結論
結論として、基幹システム再構築の要件定義で最初に確認すべきなのは、新システムの機能一覧ではなく、現行業務がどのように動き、どこに問題があり、何を再構築によって変えたいのかという点です。画面や機能だけを現行踏襲すると、古い業務の非効率や属人化まで新システムへ持ち込むことになります。
一方で、改善を優先しすぎて、現場が日常的に使っている帳票や例外処理、外部連携を見落とすと、稼働後に業務が止まりかねません。要件定義では、残すもの、改善するもの、廃止するものを分け、各判断の理由と影響範囲を記録することが重要です。保守期限や担当者の退職が迫っている場合も、調査を省略するのではなく、対象範囲と優先順位を決めて段階的に進める必要があります。
よくある背景・失敗しやすい理由
このテーマで相談が増える背景には、古い基幹システムのブラックボックス化があります。設計書が一部しか残っていない、帳票の意味を説明できる人がいない、サーバーやデータベースの保守期限が近い、パッケージを検討したが標準機能では現場業務が回らない、といった状況です。現場では業務を止めないためにExcelやAccess、CSV加工で補うことが多く、その場しのぎの対応が積み重なるほど、再構築時の調査範囲とリスクが大きくなります。
要件定義が失敗する原因は、要望が足りないことだけではありません。部門ごとの要望を優先順位なしで集める、現行システムの仕様を確認せずに新しい画面を決める、データ移行を開発終盤まで後回しにするといった進め方も問題になります。要件を増やすことではなく、業務上の目的、必要性、実現方法、受け入れ条件を関係者が合意できる状態にすることが要件定義の役割です。
確認すべきポイント
1. 現行踏襲と改善の切り分け
現行システムと同じ画面や機能を求めれば要件定義が簡単になるように見えますが、現行踏襲には注意が必要です。長年の追加改修で複雑になった処理や、すでに使われていない機能まで再現すると、開発費用と保守負担が増えます。まず各機能について、法令や取引条件により必要なのか、事業の強みに直結するのか、単なる慣習なのかを確認します。
改善候補は、現場の不満だけでなく、処理時間、ミスの発生数、二重入力、承認待ちなどの事実をもとに整理してください。現行踏襲、改善、廃止の区分と判断理由を一覧化すれば、途中で担当者が変わっても要件の意図を追いやすくなります。
2. 帳票・バッチの見落とし
画面中心で要件を整理すると、納品書、請求書、製造指示書、管理帳票などの出力物や、夜間・月末に動くバッチ処理が漏れやすくなります。帳票は取引先の指定や社内統制に関係する場合があり、レイアウトだけでなく、出力条件、計算方法、配布先、保存期間まで確認しなければなりません。
バッチ処理については、実行時刻、前後関係、処理件数、異常終了時の対応、他システムとの連携を整理します。担当者が意識せず使っている自動処理ほど見落としやすいため、ジョブ設定やログ、運用手順書も確認し、停止した場合の業務影響を明らかにします。
3. 部門間の意見不一致
営業、在庫、製造、経理では、同じデータでも必要とするタイミングや粒度が異なります。ある部門の入力作業を減らした結果、別の部門で確認作業が増えることもあります。要望を個別に聞くだけでは全体最適にならないため、業務の前後関係とデータの受け渡しを部門横断で確認する必要があります。
意見が一致しない場合は、声の大きさではなく、法令・契約上の制約、顧客への影響、処理件数、費用対効果などの基準で判断します。決定者と承認手順をあらかじめ定め、未決事項、決定内容、判断理由を記録することで、開発途中の要件変更を抑えられます。
4. 例外処理の未整理
通常の受注から請求までの流れだけを定義しても、返品、分納、遡及単価、特注品、欠品、締め後の訂正などに対応できなければ現場業務は回りません。例外処理は発生頻度が低くても、金額や顧客対応への影響が大きい場合があります。
すべての例外を個別機能にするのではなく、発生頻度、処理時間、誤りの影響、法令・契約上の必要性で分類します。高頻度または重要な例外はシステム化し、低頻度で影響が限定的なものは承認付きの手作業で補うなど、費用と運用リスクのバランスを取ることが重要です。
5. 移行データの軽視
新システムの機能が完成しても、必要なデータを正しく移せなければ稼働できません。移行対象にはマスタや残高だけでなく、未完了の受注、発注、在庫、売掛・買掛、過去の参照データなどがあります。どの時点のデータを、どの形式で、何年分移すかを要件定義の段階で決めます。
現行データには、重複、欠損、表記揺れ、使われていないコードが含まれることがあります。変換ルールとクレンジングの担当を明確にし、試験移行を複数回行って件数・金額・残高を照合してください。本番移行に必要な停止時間と、移行に失敗した場合の切り戻し条件も定めます。
6. 責任範囲の曖昧さ
発注側と開発会社の責任範囲が曖昧だと、要件の確認、マスタ整備、データ移行、受け入れテスト、現場教育などの作業が抜け落ちます。「必要に応じて対応する」といった表現だけでは、費用や納期をめぐる認識違いが生じやすくなります。
成果物ごとに作成者、確認者、承認者、期限を定め、外部サービスや他ベンダーとの連携責任も明記します。また、仕様変更の申請方法、見積もり、承認、スケジュール反映の手順を決めておけば、変更が必要になった場合も影響を管理できます。
7. 診断で整理する価値
要件定義の前に現行システムと業務を診断すると、再構築の対象範囲や優先順位を決めやすくなります。画面、帳票、データ、外部連携、保守状況を棚卸しし、延命できる部分と早急に刷新すべき部分を分けることで、最初から大規模開発を前提にせずに済みます。
診断結果は、開発会社へ渡す資料だけでなく、社内稟議や製品比較の共通基準としても使えます。概算費用、期間、段階導入の順序、主要リスクを可視化し、経営側と現場が同じ前提で判断できる状態を作ることに価値があります。
自社で整理できること・外部に相談すべきこと
社内でまず整理できるのは、業務範囲、画面、帳票、困っている作業、保守期限、利用部署、関連するExcel・Access・CSVです。資料がすべて揃っていなくても、分かることと分からないことを一覧にするだけで、調査の優先順位が見えてきます。特に、停止すると出荷や請求ができない処理、特定の担当者しか操作できない業務は、早めに明らかにしてください。
一方で、影響範囲が複数部門にまたがる、データ移行や外部連携が絡む、現行仕様を説明できる人がいない、複数の刷新案を比較する必要がある場合は、外部の開発会社と現状を整理した方が安全です。相談時には、調査範囲、成果物、概算費用の前提、判断に使う評価軸まで確認すると、その後の要件定義につなげやすくなります。
判断表
| 状態 | まず検討すること | 注意点 |
|---|---|---|
| 軽微な不具合・一部帳票の変更 | 延命・保守・部分改修 | 本体再構築の前に影響範囲を確認 |
| データ量増加・動作遅延・バックアップ不安 | DB改善・性能改善 | 根本的な業務課題が残らないか確認 |
| パッケージ標準で業務が合う | パッケージ導入 | 帳票・例外処理・データ連携を事前確認 |
| パッケージで足りない機能が明確 | パッケージ＋周辺開発 | 責任範囲と連携仕様を明確にする |
| 独自業務・例外処理が多い | スクラッチ再構築 | 要件整理と段階導入が重要 |
| 判断が難しい | 開発前診断・刷新ロードマップ | 社内稟議や他社比較に使える資料化を行う |
相談前に準備しておく情報
相談前にすべての資料を揃える必要はありません。ただし、現行システム概要、利用部署・人数、画面一覧、帳票一覧、データ項目、外部連携、保守期限、困っている業務、パッケージ検討状況、想定予算・時期などが分かると、初回相談の精度が上がります。
一覧がない場合は、日常的に使う画面のスクリーンショット、出力帳票のサンプル、月末処理の手順、連携しているサービス名など、入手しやすい情報から準備してください。現時点で不明な項目も隠さず共有することで、調査が必要な範囲を正確に見積もれます。
マクティズムの見解
マクティズムでは、要件定義で最も避けるべきなのは、現行業務を正しく理解しないまま新機能の一覧だけを作ることだと考えています。要望を集めただけでは、業務の前後関係やデータの流れ、例外時の対応が見えず、稼働後に必要な処理が不足する可能性があるためです。
まず確認するのは、現行の画面と機能だけではありません。帳票、バッチ、データ、外部連携に加え、ExcelやAccess、CSV、紙で行っている作業まで含めて業務を捉えます。システム外の作業には、現在の仕組みで対応できていない要件や、担当者に依存した判断が表れていることがあります。
そのうえで、現行踏襲、業務改善、廃止の三つに分け、なぜその判断をしたのかを記録します。事業の強みや取引条件に関わる独自業務は残す一方、標準化できる業務はパッケージや一般的な運用へ合わせることで、開発範囲と将来の保守負担を抑えられます。
刷新方法も一つに決め打ちするべきではありません。延命・部分改善、パッケージ導入、パッケージと周辺開発の併用、スクラッチ再構築を、費用、期間、適合度、移行リスク、保守性の同じ軸で比較します。対象が大きい場合は、業務を止めない順序を考え、段階導入も含めたロードマップを作ります。
要件定義書は開発会社へ渡すためだけの資料ではなく、発注側と開発側が完成条件を共有するための基準です。機能の説明に加えて、処理量、応答時間、権限、バックアップ、障害対応、移行、教育、受け入れテストまで明確にし、誰が何を確認するかを決める必要があります。
マクティズムは、大きな投資を決める前に現状を診断し、分からない点と判断材料を可視化することが重要だと考えています。再構築ありきではなく、残す範囲と変える範囲を整理し、経営側と現場が納得できる根拠をそろえることが、要件定義の失敗を防ぐ第一歩です。
よくある質問
要件がまとまっていなくても相談できますか？
はい。現状の課題や分かる範囲の資料から、まず何を確認すべきか整理できます。無理に要件を固めてから相談する必要はありません。
仕様書や設計書が一部しかなくても相談できますか？
はい。画面、帳票、データ、業務フロー、操作手順などから現行調査を進められます。
いきなり大きな開発を依頼する必要がありますか？
いいえ。初回相談、簡易棚卸し、開発前診断・刷新ロードマップから段階的に進められます。
パッケージとスクラッチのどちらがよいか相談できますか？
はい。標準機能で合う範囲、周辺開発で補う範囲、スクラッチが必要な範囲を比較します。
500万円〜1,000万円規模の部分改善から相談できますか？
はい。DB改善、性能改善、帳票・データ連携、バックアップ自動化など部分改善から相談可能です。
相談後にしつこい営業はありますか？
ありません。まずは現状を整理し、必要な選択肢と進め方をご提案します。
