ERP導入の勘所（９）ERPパッケージ導入におけるプロトタイプ型開発の強みと弱み
ERPパッケージの検討フェーズでは、自社の業務見直し、製品の調査、ベンダー絞込み、RFPなどによる提案依頼、ベンダーからの提案やプレゼンテーション等を実施します。こうした検討段階を経て、ERPパッケージを選定したら、いよいよ導入フェーズに入ります。
目次
ERPパッケージ導入フェーズ
これまでの提案フェーズにて、費用や納期・ベンダーの信頼性・同業他社事例の有無・機能要件のFIT&GAP等、様々な条件をクリアしたからこそ、そのERPパッケージを選定したのだと思いますが、いざ導入フェーズに入り、詳細な要件を詰めていくと認識のズレや解釈の相違が判明することがあります。
特に機能要件のFIT&GAPで認識のズレが大きければ、費用や納期に大きな影響があります。
検討フェーズで受領したRFP回答書では機能要件すべてに「○」が付いていたとしても、それはあくまで個別要件への回答であり、必ずしも自社が望む業務の流れを完璧にこなせるという意味ではありません。それぞれ単独の機能要件をクリアしただけでは業務フローを回せるとは限らないのです。
そこで、ERPパッケージ導入フェーズの早い段階から、ある程度機能を制限して簡易化した試作機を作成する「プロトタイプ型開発」を用いることで、自社とベンダーの機能要件に関する認識のズレを早期に発見、修正し、開発工数が膨むのを防ぐことができます。
今回はこのプロトタイプ型開発について見ていきましょう。
プロトタイプ型開発とは
プロトタイプ型開発とは、モック画面と呼ばれる、実際の完成イメージに近い画面をプロジェクトの初期段階で作成し、ユーザーに確認を取りながら要件定義等を進めていくことによって、機能要件と開発導入するシステムの適合の精度を高めて自社の業務が回るシステムを導入する方法です。
プロトタイプ型開発を適用することにより、導入プロジェクトのリスクや費用を低減しやすいと言われています。
また、実際にブラウザ上などで動かせるモック画面を作ることで、ユーザーが感覚的にシステムの操作感や画面遷移の動き、業務への適用方法などを理解することができます。文字と絵だけで何回も説明されるよりも理解しやすいでしょう。
このように、導入プロジェクトの初期の段階からユーザーエクスペリエンスを得ることができるのは、プロトタイプ型開発の大きな特徴と言えます。
プロトタイプ以外の画面レイアウト確認手段
プロトタイプ型開発にてモック画面を作成する方法以外の、画面レイアウトの作成や確認を行う手段として、ワイヤーフレームや画面仕様書を用いる方法があります。
ワイヤーフレーム
ワイヤーフレームとは、何をどこに配置するかといった、Webページのコンテンツやレイアウトを示した「サイト設計図面」です。ここでは色や装飾などデザインは考えません。
画面仕様書
画面仕様書とは、各画面のデザイン、動作、機能、画面遷移などを記述する設計書のことで、動作や遷移に重点を置かれています。
プロトタイプのメリット
上記のワイヤーフレームや画面仕様書を用いた開発手段と比較して、プロトタイプ型開発のどこが優れているのかを見てみましょう。
要求が具体的に確認でき、精度の高い要件を集めることができる
ワイヤーフレームや画面仕様書と違い、導入プロジェクトの初期段階から実際に動かせるモック画面ができるので、システムに不慣れなユーザーでも、ここをこうしてほしい、といった細かい要求を伝えやすくなり、ユーザーが求めているシステムの機能や仕様を具体的に明示することができます。
また、実際の業務を想像しながら操作できるので、画面構成の使用感を体感することができ、頭の中では想定できなかったような使用方法を見つけることもあるでしょう。
こうして仮説検証を繰り返し、より品質の高いシステムを作っていくことができます。
出来上がりを待たずに最終形が把握できる
プロトタイプ型開発では、初期の段階から最終形に近い形を確認することができるので、開発終盤になって「イメージと違う」という事態を避けることができます。
また、開発途中においても、イメージが共有できているので、発注者と開発者の双方に安心感が生まれます。
プロトタイプのデメリット
プロトタイプ型開発が良いとこばかりかというと、必ずしもそうではありません。
いくつかデメリットを見てみましょう。
大規模なシステムの場合、プロトタイプの作成に時間がかかる
ワイヤーフレームや画面仕様書に比べて、プロトタイプを作成するには時間がかかります。画面数が多い場合、初期の段階でプロトタイプをその数だけ作成する必要があり、かえって開発効率を落としてしまうため、プロトタイプを適用するのは難しいと言われています。
また、発注者が納得できる試作がなかなか出来上がらない場合、それだけ試作をする時間が増えることとなり、開発会社の負担が大きくなることも問題となるでしょう。
追加アドオンが大量に発生してプロジェクトが長引いてしまう可能性がある
初期段階から具体的なイメージができるゆえに、開発途中での細かい要求が想定以上に増えてしまう可能性もあります。初めはERPパッケージ標準機能で業務を回せる想定だったが、追加要求に応えるためにアドオンが大量に必要となり、結果として費用が膨らんでしまったり、プロジェクト期間を延長することになってしまうこともあるので注意が必要でしょう。
その他のERPパッケージ導入のための開発手法
ERPパッケージ導入方法はいくつかありますが、プロトタイプ型開発以外で多く用いられている方法に、ウォーターフォール型開発があります。
これはその名の通り、高いところから水を流すように、工程を上流から下流へ最後まで一気に開発する方法です。
具体的には「基本設計」「外部設計」「内部設計」「プログラム設計」「プログラミング」「テスト」という工程に分けて順番に実行します。
メリットは、ひとつの工程が終わる度にその工程の成果が文書化され、管理がしやすいことがあります。システム開発の管理者の立場から見ると優れた手法と言えるでしょう。
この手法において、問題点とされるのが、システム開発の終盤になるまでシステムの最終形のイメージがわからず、そのタイミングで発注者が「求めているものと違うから修正してほしい」となると、前段階の工程に戻って修正する必要があり、とても時間がかかるという点です。
修正の内容によっては初期段階まで戻らなければならないケースもあり、最初からやり直しということも起こりえるのです。
こうした問題点を解決した方法が、プロトタイプ型開発と言えるでしょう。
まとめ
ERPパッケージを導入するには、開発を始める前にある程度、新業務プロセスを決定し、標準機能でできる範囲とアドオンが必要とされる範囲の切り分けを行い、標準機能に関するパラメータ設定とアドオン部分の仕様を決めておく必要があります。
検討時のFIT&GAPで、ERPパッケージの標準機能でどこまでやるのか、新業務プロセスをどうするかを決めているはずではありますが、実際にその通りにいくことは難しいでしょう。
なぜなら業務は個別要件を集めたものではなく、流れ（フロー）があるからです。
ベンダーがそれぞれの要件を分断して、その要件ごとに複雑なパッケージ運用方法を提示してくるようでは、業務全体で見たときには複雑になりすぎて運用が現実的ではないということになりかねません。
プロトタイプ型開発を行う場合は、導入プロジェクトの初期段階で作成されるモック画面を有効活用し、業務全体を見据えたFIT&GAPを実施し、自社の導入予算にあった標準パッケージでできる範囲とアドオンで対応する範囲を早い段階で見極めることができ、実際の業務が回るERPパッケージが導入できると思います。
筆者プロフィール
- ビーブレイクシステムズ
- 家電量販店でウィンドウショッピングするのが好きです。
