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

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

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

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

その中で今回は、システム要件定義フェーズの要諦（前編）として、システム環境構築と標準機能検証を中心にご説明します。

システム環境構築では、主に選定したERPについて、システム要件定義としての実機検証ができるようにシステム環境を構築します。また、システム開発フェーズにおける開発環境、テスト環境、本番環境などの構築準備を行います。これらの環境は、ERP環境、アドオン環境、インターフェース環境ごとに用意する場合があるので、情報システム部門や導入ベンダーと連携して進めます。

システム環境構築の内容

ERP環境の構築
ERPの標準機能が動作するシステム環境を構築します。この環境構築はERPを導入する形態（オンプレミス型、IaaS型、PaaS型、SaaS型等）によって、構築主体、手順等が異なります。それぞれプロジェクトで選択した形態に応じて構築する必要があります。

また、ERPについて開発環境、テスト環境、本番環境を構築します。テスト環境は、単体テスト、結合テスト、システムテスト、ユーザー運用テスト（UAT）について、それぞれ別個の環境を用意するかも検討します。さらに、ERPのシステム環境の構築においてテスト環境数などの制限がないか、ERP提供ベンダーに別途確認が必要です。

アドオン環境の構築
選定したERPが前提とするアドオン開発環境を構築します。アドオン開発環境の構築については、ERPの提供ベンダーが推奨するアドオン開発環境の条件を具体的に確認したうえで、どのような環境を構築するか検討して実施します。また、必要に応じてテスト環境等も準備します。

インターフェースの環境構築
インターフェース環境構築については、インターフェース開発の開発環境、テスト環境、本番環境を構築します。これらの環境として、上流の既存システムのシステム環境を利用するか、新たにシステム環境を構築しなければいけないかは、別途確認が必要です。特に、上流の既存システムが老朽化している場合、システム的な制限があることが多いので注意してください。

システム環境構築の具体的な手順

システム環境構築は、下記の手順で実施します。

標準機能検証では、選定したERPの標準機能で業務要件をどのように実現するかを検討します。スクラッチ開発の段階では、実際に動作する画面などは見ることができませんが、ERPの場合、実際の画面や処理プロセス、出力データなどを確認することができます。

したがって、ERPの導入では、実際の製品を使いながら標準機能を確認する実機検証を行うことが一般的です。この実機検証を、デモ、CRP（Conference Room Pilot）、POC（Proof of Concept）、プロトタイプ検証などと称すことがあります。選定したERPの導入ベンダーによって用語や意味が異なることから、どういう言葉を使うか、その概念は期待していることと同じかを確認することが必要です。

標準機能検証では、選定したERPに合わせて業務フローを更新する①業務フロー更新、業務フローについて実機を使い検証する②実機検証、実機検証の結果として標準機能の要件を固める③標準機能要件定義があります。

業務フロー更新では、前フェーズで作成した業務フローを元に、導入するERPを踏まえた業務フローを最終化し、システム化範囲の確認を行います。

業務フローの更新は、ERPの導入ベンダーと確認しながら行います。業務フローベースで、導入ベンダーが提案書で提示した「標準機能で実現できる範囲とできない範囲」を両社で確認することが重要です。
業務フロー更新が、標準機能検証におけるシナリオの前提になるからです。

ユーザー部門の方々は、導入ベンダーが使う用語や製品への理解を深めるため、この段階でERPのトレーニングを受けることを推奨します。システムはシステム屋が用意するもの、といった考え方ではなく、自分たちのシステムは自分たちで用意するといった考え方に、頭を切り替えることが重要です。

実機検証では、Fit to Standardを目指し、検討を進めます。
ユーザー部門は、標準機能で対応できない機能についてアドオンを行わず、ルール変更やプロセス変更など業務の前提条件を見直すなどの抜本的な検討を行うこと重要です。こうした抜本的検討は、まさにシステムを使うユーザー部門の責任として行ってください。

実機検証を有効に行うためには、実現したい業務について業務シナリオを作り、そのシナリオに基づいて実際にシステムがどういう振る舞いをするかを確認していく必要があります。

業務シナリオでは、インターフェース要件とも関連しますが、関連システムからのデータの流れと基幹システム内での処理を一気通貫で検証するシナリオを準備することも重要です。この業務シナリオをしっかり用意せず、実機検証を行った場合、大きな要件が漏れていたり、期待したことができなかったりするので注意してください。

実機検証の内容

業務シナリオの実行
ERPの標準機能が、設計された業務プロセスどおりに動作するかを確認します。主要な一連の業務プロセス（例えば、インターフェースによる売上計上から回収、債権消込、債権残高管理まで）をエンド・トゥ・エンドで、実機検証します。

標準機能設定の検証
業務要件定義に基づく標準機能設定（パラメーター設定、マスタ設定）が正しく機能に反映されているかを確認します。標準機能設定では、組織、品目、勘定科目など動作の前提となる主要マスタを、事前に整備しておく必要があります。今までのコード体系の変更等を目指す場合、早い段階でマスタ定義を行う必要があるので注意してください。マスタ定義の詳細については、業務運用整備フェーズで説明します。

ギャップ対応策の確認
事前に洗い出された主要なギャップについて対応策（設定変更、代替業務フロー、アドオン案など）を検討し、業務要件を満たす方法を確認します。また、標準機能での実現を想定した機能で、実機検証の中で発生したギャップについても同様にギャップ対応策を検討します。

操作性の確認
画面等の操作性（ユーザーにとっての画面の使いやすさ、必要な情報の表示、入力項目の妥当性など）を確認します。

実機検証の具体的な手順

実機検証は、下記の手順で実施します。

標準機能要件定義では、実機検証結果を元に標準機能としての設定要件を最終化します。
具体的には、ERPの標準機能を活用する範囲、各標準機能を動作させるためのパラメーター値やマスタ構造を確定します。

今回は、「クラウド時代！ユーザー主導のERP導入とは」として、基幹システム刷新におけるシステム要件定義フェーズの秘訣（前編）をご紹介しました。次回は、システム要件定義フェーズの秘訣（後編）として、アドオン要件定義、インターフェース要件定義、プロジェクト計画更新をご紹介します。

今後の基幹システム刷新は、情報システム部門やベンダーへ丸投げはできません。ユーザー部門が主導して、ERPを Fit to Standardで導入していくことが成功の秘訣といえます。詳細な Fit to Standard でのERP導入のポイントについては、是非レイヤーズ・コンサルティングにお問い合わせください。