本記事は、要求と要件の徹底解説記事を事前に読んでいるとより理解しやすいです。
今回は、システム開発・導入において特にパッケージシステムの開発・導入に焦点を当てて解説します。
パッケージシステムとはSAP S/4HANAやoracle EBSに代表されるような既製品システムのことです。一方で、一から作るものを決めて開発するスクラッチ開発とは、同じシステム開発・導入といっても実は進め方が全く異なります。
そこで、今回は、「要求」と「要件」の違いや要件定義、基本設計といった上流工程の進め方に言及して、パッケージシステム導入について解説します。
私自身、これまでプロジェクト規模の大小があれど、数多くのパッケージシステムの導入案件を行ってきましたので、その経験を詰め込みたいと思います。
この記事を読んでわかること
★パッケージ導入における「要求」「要件」、Fit&Gapの位置づけがわかる
★Fit＆Gapを含めた上流工程の進め方がわかる
★Gapに対するソリューション検討の方法がわかる
結論
・要求＝顧客のやりたいこと、要件＝顧客のやりたいことを実現する内容及び、プロジェクトスコープとして実際に実施すること
・Fit&Gapは業務要件定義（机上）とプロトタイプ検証（実機）を行うことで要求（Gap）を明らかにすること
・Gapに対するソリューション検討は要求レベルに応じて検討する
パッケージシステム導入の進め方
要求と要件のおさらい
まずは、スクラッチ開発であろうとパッケージシステム導入であろうと、言葉の定義として「要求」「要件」が何ものかを整理したいと思います。
スクラッチ開発における「要求」「要件」の違いについてはぜひ以下の記事を読んでおさらいしていただければと思います。
端的に言えば、次のようになります。
| 用語 | 説明 |
|---|---|
| 要求 | 顧客のやりたいこと |
| 要件（広義の意味） | 顧客のやりたいことを実現するための内容及びその方法 |
| 要件（狭義の意味） | 顧客のやりたいことを実現するための内容及び方法のうち、プロジェクトスコープとして実施すること |
図で示すと次のようになります。
パッケージシステム導入手順における基本的な考え方
導入における基本方針
続いて、Fit&Gapが何ものかを整理する前に、大前提としてパッケージシステム導入の基本的な考え方を確認します。
その考え方とは、パッケージシステム導入の基本は「Fit to Standard」で行うということです。つまり、「業務をシステムに合わせる」ということです。
スクラッチ開発の場合、顧客がやりたいことを吸い上げ、それを実現するようにシステムを開発します。しかし、パッケージシステム導入の場合、既にシステムは完成しています。例えるならば、自由に間取りから設備器具まで何でも自由に決めることができる注文住宅の購入ではなく、建売の分譲住宅を購入するイメージと同じです。分譲住宅の場合、多少のオリジナリティを出すことはできるかもしれませんが、間取りや階数、設備器具などは最初から決まっています。そのため、パッケージシステムを導入する場合はできるだけ既にある機能を使った方が合理的です。
「Fit to Standard」をできるだけ取るべき理由はもう１つあります。それは保守性を担保するためです。
通常パッケージシステムの場合は、提供元のベンダー（SAP S/4HANAであればSAP社、Oracle EBSであればOracle社）が定期的いバージョンアップを行います。例えば、機能バージョンアップなどです。国内ベンダーが提供しているパッケージシステムの場合は国内の法改正（消費税変更、インボイス制度、電子帳簿保存法など）にも対応していることが多いです。
そのような際に、パッケージシステムをそのまま導入している場合には、機能の保証を提供元のベンダーが実施してくれるため、これらのバージョンアップを素直に受け入れることができます。
しかし、パッケージシステムに対して何かオリジナルの改修を行ている場合には素直に受け入れることができません。オリジナルの改修をした部分の動作保証を自分達でしなければいけないためです。そうすると、バージョンアップの度に自分達でテストをする必要があり、テストの結果、不都合があればバージョンアップのための改修を自分達でしなければいけません。
もうお分かりかと思いますが、そうすれば保守性は低下し、保守要員の確保、バージョンアップ時の対応のためにコストが多くかかることになります。
こうした理由から、できるだけシステムに業務を合わせるという考え方が重要です。
正直、この考え方をいかに浸透させることができるかがパッケージシステム導入の成功の鍵とっても過言ではありません。
Fit&Gapの位置づけ
パッケージシステム導入のFit to Standardで進めるべきという話をしました。しかし、すべての業務をシステムに合わせることは到底できません。
そこで、要件定義工程にて現行業務をヒアリングしてパッケージシステムとマッチするかそれともマッチしないのかを確認します。これをFit&Gapと言います。
ここで出たGapが「要求」になると理解してください。
何かしらで解決しなければいけないこと、顧客がやりたいことになります。
スクラッチ開発では「要求」＝「やりたいこと」という位置づけでしたが、パッケージシステム導入では「要求」＝「解消しなければいけないこと」＝Gapという意味合いの方により重きが置かれると考えると良いと思います。もちろん、Gapの中にはパッケージシステムを導入して「やりたいこと」も含まれています。ただ、前述した通り、パッケージシステム導入の原則は、導入するパッケージシステムに業務を合わせるという考え方のため、Gap＝解消しなければいけないことという意味合いの方がより近いと言って良いでしょう。
そして、Fit&Gapで挙がったGapをどのように実現するかを検討することが、パッケージシステム導入における要件定義（特に、システムで解決する場合に焦点を当てた場合は、システム要件定義ということもある）と言え、さらにその中から最終的にプロジェクトスコープとして実施するものが狭義の意味での「要件」とります。
上述したパッケージシステム導入におけるGapの位置づけを先ほどの表や図に盛り込むと次のようになります。
| 用語 | パッケージシステムにおける説明 |
|---|---|
| 要求 | 顧客のやりたいこと ＝Gap |
| 要件 （広義の意味） | 顧客のやりたいことを実現するための内容及び方法 =Gapに対する解決策 |
| 要件 （狭義の意味） | 顧客のやりたいことを実現するための内容及び方法のうち、プロジェクトスコープとして実施すること = Gapに対する解決策のうちプロジェクトスコープとなるもの |
Fit&Gapの進め方
ここまで、パッケージシステム導入におけるFit&Gapの位置づけを整理しました。
ここからは、Fit&&Gapを含めた要件定義、基本設計といった上流工程の進め方について解説します。
まずは、全体図を示します。
大きな流れについて順に解説します。
Fit&Gapはスクラッチ開発における業務要件定義と位置付けることができ、詳細化すると２つに分けることができます。
業務要件定義（机上）
パッケージシステムの業務要件定義書や機能定義書、すなわちパッケージとして想定している業務定義や機能定義を説明しながら、顧客業務をヒアリングします。
そして、パッケージの考え方と現行業務の考え方とで一致しない部分を洗い出していきます。
プロトタイプ検証の実施（実機）
実際にユーザにパッケージシステムを利用してもらい、意見を聞き出します。
具体的には、業務要件定義（机上）でヒアリングした業務シナリオや業務フローに沿ってユーザに操作してもらいます。この時可能な限りユーザが理解しやすいような設定をしておくことを心がけます。例えば、組織設定や品目マスタの設定、取引先マスタ設定などは事前にヒアリングをしておき、実際の業務に近しい形で操作してもらいます。
業務上必要不可欠な機能がない、処理順番が異なるといった業務上のGapも見つかるでしょうし、画面レイアウトの変更などシステム観点でのGapも見つかると思います。こうした要求事項、すなわちGapを漏れなく拾っていきます。
できれば、業務要件定義（机上）で挙がったGapに対してカスタマイズ設定やマスタ設定などで既に解決ができるものであればこの段階でプロトタイプ環境に反映しておいた方が実機検証がより効果的なものになります。
ここまでで挙がったGap（要求）をGap一覧、要求一覧としてまとめます。まずは、Gap起票者までを埋めていきます。
またステータスでは、ユーザに対して追加ヒアリングが必要な状態なのか、ソリューション検討に入って良い状態なのかを明らかにします。
ソリューション検討
業務要件定義（机上）とプロトタイプ検証（実機）で挙がったGapについて解決策の検討を行います。実際には、業務要件定義（机上）の段階から順次Gapは明らかになっていくため、業務要件定義（机上）やプロトタイプ検証（実機）と並行してソリューション検討を進めていくことになります。
ソリューション検討の考え方については詳細を後述します。
ソリューション採用判断
ここまででGapを解決するための実現方法の検討、要求事項を実現するための検討が行われました。
しかし、プロジェクトには納期やコストを代表するような制約条件があります。（なお、実現可能性についてはソリューション検討段階で解決済という前提となります。）
そのため、列挙されたGapやその解決ソリューションの中から実際にプロジェクトスコープとして扱っていき、実現していく要件を決定します。
こうして晴れて、要件（狭義）、すなわち、プロジェクトスコープが決定し次工程以降の設計・開発工程に進むことができるようになります。
要求（Gap）の解決方法
Fit&Gapで挙がったGapについては、解決方法の検討（ソリューション検討）を行います。
先ほど掲載したGap一覧における後半部分の検討です。
ここで意識していただきたいのは、列挙されたGapがどのレベルにあるかです。このレベルについてはソリューションの方向性に記載することで解決の方向性について認識のズレが発生しないようにします。
どういうことか、それは、要求と要件にはそれぞれレベルがあることを理解していただければと思います。要求を解決するためのレベルを誤るとその後どんなに良いソリューションを導き出してもうまくいくことはありません。
そのため、解決の方向性としてまず最初に認識を合わせることが重要になります。
端的に言えば、要求（すなわち、Gap）にはビジネスレベルで解決するGap、業務レベルで解決するGap、そしてシステムレベルで解決するGapがあります。
分かりやすいところでいうと、システムに合わせて業務フローを変更することは業務レベルでの解決となります。システムレベルでの解決は、もう少し詳細化すると、カスタマイズ対応とアドオン対応、モディフィケーションに分かれ、これらいずれかの対応を取ることでGapを解決することとなります。
したがって、まずはGapを解決するレベルが適切かどうかを整理することから始めます。
そしてその後に、個別具体的な検討に入ります。
要件と要求の違いについては、詳細はこちらをご覧ください。
それぞれのレベルを理解したうえで、要求に対するソリューション案を次のように検討します。
ビジネス・業務変更
これは、ビジネスレベル・業務レベルの変更にあたります。
ビジネスモデルの変更、ビジネスの在り方を変更して解決します。
極端な例ですが、システム導入を機に販路を絞るであったり、商品の出荷形態を変えたりといったことが考えられます。
また業務レベルの変更では、業務フロー、手順、業務上のルールを変更することで解決します。
例えば、契約に対する承認については不要にしたり、これまで郵送していた帳票を廃止したりといったことが挙げられます。
これらはシステム導入ベンダーが実施するものではなく、顧客企業が主体となって取引先や関係企業、関係部門と調整を行って解決案を検討し、実行していきます。
カスタマイズ設定
これは、システムレベルの変更にあたります。
パラメータ設定、コンフィグレーション設定とも呼ばれ、会社やプロジェクトによって様々な呼ばれ方をしますが、ここではカスタマイズ設定と呼びます。
カスタマイズ設定とは、パッケージシステムが元々持っている考え方で、機能に対してある設定をすることで機能の動作を変更することです。ある機能はパッケージシステムが元々提供している設定の範囲内で挙動を変えることができる部分があり、その設定を変えることをカスタマイズ設定と呼びます。
これはGapとは言わずに、標準機能で対応できる部分であるためFit部分という方もいます。ただ、本記事では、顧客のやりたいことを実現する方法の１つであるという観点からGapに対する解決策の位置づけで定義します。また、顧客のやりたいことを実現するために設定を変えなければいけないという意味では、後々の設定作業が必要になるという観点からもGapとして列挙することが望ましいと言えます。
分かる方に分かればですが、SAPでいえば、TrCd:SPROで実施するConfiguration設定のことだと思っていただければと思います。
アドオン
こちらは、システムレベルの変更にあたります。
パッケージシステムに対して新規機能を追加することGapを解決する方法です。
分かりやすい例でいえば、受注登録をする際のチェック処理について、パッケージシステムが提供しているチェック処理の他に顧客企業の要求に合わせたチェック処理を追加することを指します。
モディフィケーション
こちらも、システムレベルの変更にあたります。
パッケージシステムの既存機能を改修することでGapを解決する方法です。
既にパッケージシステムが保証している処理に対して改修を加えることで挙動を変えたり、処理を追加したりします。
例えば、MRP実行処理において、MRP処理の計算方法を変えるなどがあります。
なお、アドオンとモディフィケーションについては区別をしない場合もあり、単に新規か改修かの区分けしかしない場合もあります。
カスタマイズ、アドオン、モディフィケーションの違い、メリットデメリットなどはこちらをご覧ください。
以上が、要求（Gap）に対する解決策の検討でした。
パッケージシステム導入手順まとめ
いかがでしたでしょうか。
今回は「要求」「要件」の違いに触れつつ、パッケージシステムの導入手順、そしてFit&Gap分析の進め方を解説しました。
そして、Fit＆Gapを含めた具体的な上流工程の進め方、ソリューション検討の方法を解説しました。
ぜひ、今回の内容が何かの役に立てば嬉しいです。
コメント