ERP（業務システム）コミュのプロトタイピング開発のはじめ方

会社で現在パッケージERPを導入しようとしている、ユーザー側情報システム部の人間ですが、外部コンサルタントがプロトタイプ開発の手法で行います！ということで、したがっているのですが。。。プロトタイプ型の開発ってあまりやったことがないもので、ちょっとやりかたにめんくらってます。。。

かれらのやり方が。。。

１．現在、ユーザー側がどんな業務フローで仕事をしているかインタビュー
２．いきなり要求もきかずに、プロトタイプ開発
３．プロトタイプの使い方講習会をおこない、1日、2日のうちに追加案件があるならいってこいと要求

物流販売エリアなので、関連代理店、企業さんとの調整もあるので、まず1日、2日で返事しろ、といわれても。。。

なにより要求定義をはじめないで、自分たちのかってな前提をもとにしたプロトタイプをみせられても返事のしようがなくてこまっています。。

プロトタイピングって、プロトをはじめるにあたっての最低限のリクエストの抽出とかはしないで、As-Isをたたきに開発側の想定をもとにはじめるのが普通なのでしょうか。。。

コメント(2)

最初
全て
最新の40件

[1] mixiユーザー 01月24日 01:25

>プロトタイピングって、プロトをはじめるにあたっての最低限のリクエストの抽出とかはしないで、As-Isをたたきに開発側の想定をもとにはじめるのが普通なのでしょうか。。。

いろんな考え方はあるかと思いますが、基本的にはプロトの目的次第じゃないかと思います。パッケージを使う以上、標準機能はすでにどういうものか決まっている訳で、品質、コスト、納期を考えると細かい要求を出して一々プログラムを作りこんで行くというより、極力標準機能で行けるところは標準機能で行きましょう、というのが基本戦略となるかと思います。

とした場合、ユーザさんといえども要件出しのためにはある程度事前にパッケージの機能を理解することは必須であり、例えばSAPでいうと物流販売エリアならプラントとか保管場所とか購買組織とか販売エリアとはどんなもので、どんなマスタがどんな風に必要で、プロセスとして基本的な発注、入庫、在庫転送、出荷、請求の処理についてはどんなイメージで処理が行われ、できることできないことの大まかな理解をしてもらうことは必要だと思います。

そういう意味ではしょっぱなの要求出しの前提となるパッケージの知識を共有するためのトレーニングに近い目的であればまずはAsIsでこんな感じですかね？というのはありだと思います。

しかし、いきなり開発のスコープや開発要件確定のため、という目的なら乱暴な印象は受けます。
工程としてウォーターフォール的にやるのか、スパイラルでやるのか、納期がどうなのか、とかそういうとこでもまた話が違うような気もしますが、例えばスコープ確定（どこまで標準でやってどこから追加開発にするか）のため、という目的のプロトならコンサル側も相当程度To　beの要件を理解してお客さんと共通認識を持ってプロトを用意していないとまずいと思います。

とりあえずコンサルにプロトの目的を聞いて今やってることがその目的にかなうことなのかどうなのかを判断される必要があるように思われます。また、プロトの目的自体も全体のゴールやスケジュールの中で適切なものかどうかの判断も当然に必要なように思います。

[2] mixiユーザー 01月30日 01:44

なるほど。
たしかにあんまりToBeがかたまってない状態でのプロトタイプなのに、
プロトをみて「ああしたい、こうしたい」というと「それはスコープ外です」といわれているので、コンサル側とユーザー側のプロトタイプに対する認識がずれているようです。

コンサルさんとちょっと話をしてみます！

ログインすると、みんなのコメントがもっと見れるよ