【第10回】
システム要件定義フェーズの秘訣は何か（後編）

システム要件定義フェーズの位置付け
システム要件定義フェーズは、導入対象となるERPを前提に、今後目指す新しい業務プロセスを検証しながら、標準機能設定やアドオン要件、インターフェース要件を具体化し、今後のプロジェクトのQCD計画を詳細化する重要なフェーズです。

システム要件定義において、ERPをFit to Standardで導入できるか否かが決定します。また、導入ベンダーの本当の実力値も判明します。したがって、システム要件定義においては、妥協せずに徹底的な要件検討と業務改革検討を行うことが重要です。ここで安易な検討を行うと、導入できたが業務で使えなかったり、想定以上のコストと期間がかかったりと、プロジェクトが頓挫することも少なくありません。

システム要件定義フェーズの進め方
システム要件定義フェーズとしては、選定したERPなどのシステム環境を構築するシステム環境構築、ERPの標準機能で業務要件をどのように実現するかを実機で検証する標準機能検証、アドオンで開発する機能を具体化するアドオン機能要件定義、周辺システムとのインターフェース要件を具体化するインターフェース要件定義、システム要件定義を踏まえプロジェクトのQCD計画を更新するプロジェクト計画更新があります。

その中で今回は、システム要件定義フェーズの要諦（後編）として、アドオン機能要件定義、インターフェース要件定義、プロジェクト計画更新を中心にご説明します。

アドオン機能要件定義では、標準機能ではカバーすることができない機能要求に対して、追加開発が必要なアドオン機能を決定し、アドオン機能要件を具体化します。

Fit to Standardの考え方からすれば、これは本来あってはいけません。
本当にアドオンの対象になるか否か、導入ベンダーを含め慎重に検討する必要があります。特に、導入ベンダーによっては、アドオン開発を比較的安易に引き受けるケースもあります。安直にアドオンを増やすと、ERPの導入段階では問題がでなくても、その後の保守やバージョンアップに影響を及ぼします。
したがって、アドオン開発を行う場合であっても、その後の保守やバージョンアップに影響を及ぼさない方法を、導入ベンダーとしっかり検討することが重要です。また、アドオン開発については、一般的なスクラッチ開発と同様の方法論で行います。

アドオン機能要件定義の内容

アドオン開発環境の定義（システム環境構築で実施）
アドオンを開発する環境を定義します。アドオン開発環境の構築については、ERPの提供ベンダーのアドオン開発環境構築の条件を具体的に確認したうえで、どのような環境を構築するか検討して実施します。

アドオン機能概要の定義
アドオン機能を利用する業務プロセスと利用ユーザーを明確化します。
アドオン機能が解決するべき業務課題と、その導入効果を明確化にします。

アドオン機能要件の定義
アドオン機能について、入出力要件を詳細化します。

• 入力要件（インプット）：ユーザーが手入力するデータ、または他システム・標準機能から連携されるデータです。
• 処理要件：インプットデータに基づき、どのような計算、検索、変換などの処理を経て、アウトプットを生成するのかというロジックを定義します。
• 出力要件（アウトプット）：帳票、画面表示、または他システム・標準機能へ連携するデータです。

インターフェース要件の定義
アドオン機能が、ERPの標準機能のどのテーブル、どのトランザクションと連携するかといったインターフェース要件を明確化します。アドオンについて、ERPと外部システムとのデータ連携方式（バッチ、リアルタイム、APIなど）や、連携データ項目なども定義します。

非機能要件の定義
アドオン機能について、パフォーマンス要件（処理時間）、セキュリティ要件（アクセス権限）、監査証跡要件などを定義します。

アドオン開発規模の見積
アドオン機能の開発規模を具体化することで、開発コスト、期間、必要なリソースなどを正確に見積、プロジェクト計画に反映させます。

アドオン機能要件定義の具体的な手順

アドオン機能要件定義は、下記の手順で実施します。

アドオン機能要件定義におけるポイント

Fit to Standardの徹底
標準機能で対応できない場合、アドオン開発を行うかどうかの検討が必要になります。しかし、Fit to Standardの導入をするためには、アドオン開発をできるだけ認めない方針で進めることが重要です。
例えば、購買管理システムで、支払手段やサイト等が取引先ごとに複雑に定義され、標準機能で対応できない場合などでは、支払条件を見直すくらいの抜本的な変革を行うことが重要です。私どもの経験でも、なぜそんなことを後生大事に守っているのか不思議に思う慣習も少なくありません。また、そのような支払条件による金融効果より、それにともなうシステムコストや人件費の方が明らかに高いといったこともあります。

Fit to Standardによる導入を目指すなら、TOPや関連部門を巻き込んで聖域なき改革を行い、こうした旧態依然の因習を打破することが最も重要です。アドオンはアップグレードや保守の際に大きな足かせとなります。アドオンを必要最小限にすることを目指し、そのためにビジネス要件そのものの見直して、ルールや業務プロセスの変更を最優先で検討しなければいけません。

Fit to Standard実現性の早期検証
業務要件定義フェーズから、ERPの標準機能を熟知した専門家を参画させ、業務要件そのものがギャップにならないように準備することが重要です。こうした専門家が自社にいない場合、レイヤーズ・コンサルティングのようなコンサルティング会社を活用することも一つです。

ERPの専門家の参画
ERPの専門家を参画させ、定義されたアドオン要件がERPの設定等で技術的に実現可能か（標準機能で対応可能か）を再度評価します。標準機能検証で明確になっていない要件が明確になることにより、標準機能で対応できることも少なくありません。ただし、導入ベンダーは、一度決めた標準機能の範囲を変更することを躊躇うことも多いので、事前に十分調整することが重要です。

アドオン開発費用の早期見積
アドオンにするか否かを検討する場合、導入ベンダーには早い段階から常にアドオンの概算金額を確認してください。金額提示を躊躇うベンダーもいますが、後々の金額が想定外で手戻りすることもあるので、事前に概算金額提示を約束しておくことが重要です。

インターフェース要件定義では、基幹システムと連携する全ての外部システムとのデータの流れ、形式、タイミングを明確にし、データ連携における要件を具体化します。
通常インターフェースにはETLツール等を使います。

また、インターフェース要件定義では、どのシステムからどのデータがどのような形式でいつインターフェースされ、そのデータをいつどのようにERPが求める形式に編集し、どうERPに渡すかといったことを具体化していきます。逆に、ERPから他のシステムへのインターフェースも同様に具体化していきます。特に、関連システムが数多く存在している場合、インターフェース開発のボリュームが多くなるため、その開発規模の見積も重要になります。こうしたインターフェースの設計・開発は、上流のシステムに大きく依存し、ERPの導入ベンダーの支援範囲外になるため、一般的に自社のIT部門が行います。

インターフェース要件定義の内容

インターフェース要件定義では、基幹システムと連携する全てのシステム（連携元・連携先）に対して、以下の内容を具体的に定義します。

インターフェース要件定義の具体的な手順

インターフェース要件定義は、下記の手順で実施します。

インターフェース要件定義におけるポイント

マスタ統合の検討
可能な限り、連携システム間で利用するマスタデータの共通化・統合を図ることで、変換の負荷やリスクを低減させます。マスタ統合ではMDMなどの導入の検討も必要になります。

データ発生源の明確化（Master of Record）
データの更新権限を持つシステムを項目ごとに明確に定義します。これにより、二重更新やデータ不整合を防ぎ、どのデータが最新かつ正しいかを明確にします。

コード変換（マッピング）の厳密な定義
既存システムとERPのコード体系が異なる場合、どのコードをどのようなルールで変換するか（マッピングルール）を、例外も含め完全に定義します。この定義の曖昧さが連携エラーの最大の原因となります。

エラーハンドリングの徹底した設計
正常にデータが流れるケースだけでなく、通信遮断、データ形式エラー、コードの不一致など、エラーが発生した際の検知・通知・再実行・リカバリのプロセスを詳細に設計します。連携状況を常に監視し、異常を早期に発見するためのログ出力やアラート機能なども要件に組み込みます。

既存システムの制約の早期特定
連携元の既存システムが古い技術で構築されている場合、リアルタイム連携や特定の通信方式に対応できないことがあるため、プロジェクト初期に既存システムの技術的な制約を洗い出し、要件反映させます。

システム要件定義の結果として、プロジェクト計画を更新します。

システム要件定義が完了すると、ERPの導入ベンダーから導入費用の提案がでます。導入費用の内訳は、ライセンス、システム開発費用、保守費用等などがあります。また、ベンダーからの見積が当初の想定開発費を超える場合には、要求機能の一部を削減するといった調整もこの段階でおこないます。

アドオン開発については開発主体（社内、社外）、インターフェース開発については連携システムの担当主体（社内、社外）が一般的に費用見積を行います。こうした見積を元に詳細コスト・投資計画を作成し、これらをベースに次フェーズ以降のプロジェクト計画として更新（精緻化）していきます。プロジェクト計画は、ステアリングコミッティ等での承認といった社内承認手続きに沿って承認を得ます。

今回は、「クラウド時代！ユーザー主導のERP導入とは」として、基幹システム刷新におけるシステム要件定義フェーズの秘訣（後編）をご紹介しました。今後の基幹システム刷新は、情報システム部門やベンダーへ丸投げはできません。ユーザー部門が主導して、ERPを Fit to Standardで導入していくことが成功の秘訣といえます。詳細な Fit to Standard でのERP導入のポイントについては、是非レイヤーズ・コンサルティングにお問い合わせください