RFP作成のためのいろいろなヒアリングや課題抽出なども含めるとかれこれ3年くらい続いている基幹システム刷新のプロジェクト。

期間もそうだし、基幹システムということもあり当然紆余曲折はあり、それは弊社もご多分に漏れず。
（弊社の場合、多くはベンダー側の問題じゃね？とは思ってるけど）

基幹システム、というよりもERPの導入というと失敗する確率が非常に高く、一昔前だと成功率は2～3割くらいと言われていたような気がする。
今だとどうやら6割くらいには上がってきているらしい。

ERPの登場から十数年、下手したら数十年も経って多くの導入プロジェクトがあっただろうに、それでも4割は失敗しているという現実。
それにここでいう「成功」とは何を持って成功と言っているのだろうね。
当初の計画通りに進んで期待した効果が得られたことを成功と言っているかもしれないし、紆余曲折ありスケジュールに遅延はあったもののちゃんと社員が使えるシステムができたので成功と言っているのかもしれないし。

まぁ今回そういう「成功」の定義を話したいわけではなく、ERPの導入という点で見ると世界中はもちろん日本国内でも数え切れないくらいのプロジェクトがあったはずで、その中で「こうすれば成功できるよ」というベストプラクティスが生まれてもおかしくないはずなのに未だに数多くの企業で導入失敗してしまう理由はどこにあるんだろうということを話したい。

最近でも江崎グリコがシステムリプレースに失敗して長期間商品が出荷できないということが起きていた。プッチンプリンがスーパーの棚から消えたというのは皆さんの耳にも届いていたと思う。
同様にユニ・チャームもリプレースに失敗し、おむつの出荷が遅れるといった事案が発生した。

また日本通運が基幹システムの開発失敗を巡って124億円という途方もない金額の賠償請求をしたというニュースも報じられている。

そして弊社でも開発の遅延、それに伴うユーザーへの展開の遅延、またそれらにリカバリーするために当初の想定よりもやはりコストが膨らんできている。
まだローンチしてないので上述の例ほど大爆発しているわけではないが、それでも上手く行ってないのは事実。

そしてその理由を振り返った時に個人的に思ったことを以下にまとめる。
これが全てに通じるわけではないかもしれないが、多分弊社で上手く行ってない理由はここにあると思う。

まず結論言うと要件定義に問題がある。

こう書くと「IT系の記事でよく見ることやん」と思うだろうけど、もうちょっと実体験、実感を持った内容を書きたいと思うので少しは腹落ちすると思う。

システム導入の案件だと大体は、
RFP作成 ～ 各社より提案 ～ コンペの後にシステム及びベンダーを決定 ～ キックオフ ～ 要件定義・・・
という流れかと思う。
この要件定義ではいわゆるFit & Gapを行い、「ここはシステム標準で対応できるね」とか「ここはシステム標準に寄せるために運用を変えられないか」とか「ここはどうしても運用変えられないからカスタマイズしてもらわないと」とか「カスタマイズするならこういう内容で…」みたいな議論をしていく。

ここ！ここなんだよ！

我々ユーザーからすると、システムに対してコンペの時に見せてもらったくらいのことしかわかってない。
それがERPのような多くの機能を持つ巨大なシステムともなれば、ユーザー側のシステム部門の人間でさえそのシステムのことほぼ分かってない状態である。

かたやベンダー側。ベンダー側は我々ユーザー企業がどういう業務をしているのかはRFPレベルでしか知らない。場合によってはRFPちゃんと読み込んでないだろって人が担当になることもあるので、言ってしまえばユーザー企業の業務理解は全くない状態。

特に販売領域。
ここは本当に日本の悪いところだと思うけど、ユーザー企業が属している業界、またその業界での商慣習、これらがあまりに多種多様すぎる。
（よくよく見ると江崎グリコやユニ・チャームも出荷（販売領域）で失敗している）

ユーザー企業はシステムに対する知識。
ベンダーはユーザー企業の業務知識。
これらが圧倒的に不足している（というか知識ゼロの）状態で要件定義に入り、お互い何も分かってないまま「あーしましょうこうしましょう」と決めていく。
そしてそんな空論のままで機能を作っていき、受入テストや運用テストを始めてみると「こんなの求めてない」「こんな想定ではなかった」「そうなると標準機能では運用できない」「それだったらカスタマイズせずに標準機能でできたじゃん」となる。

要は王道のウォーターフォールな進め方だと要件定義に入るタイミングが早すぎると思っている。

んじゃウォーターフォールに対してアジャイルがいいのかというとそうは思わない。
もっとライトに開発と修正を繰り返せるようなものならアジャイルでいいと思うが、ERPは機能もそうだけど担う役割があまりに重たすぎてアジャイルのようにどんどんサイクル回してどんどん改良していくというのには不向きだとは思っている。
それにここで言いたいのは「お互いの理解不足」ということなので、アジャイルであろうと結局理解不足のまま開発に入ってしまうのは変わりない。

個人的には要件定義の前に「標準機能での並行稼働フェーズ」みたいなのが半年～1年程度あると良いと思う。
リアルな業務自体は現行のシステムで行い続けるが、その横でカスタマイズなしの素の状態の新システムでも業務をやってみる。
半年～1年程度並行して動かしてみて、その間にどういうマスタ設定が良いか、どう運用回避ができるか、またどうしても埋まらないギャップを洗い出す。
この期間にユーザーはシステムの理解を深める。
ベンダーはユーザーの業務理解を深める。
と言ったところが狙い。

そんなことするリソースがない、そんなことすると案件の期間が長くなってしまうといった問題はあるものの、出来るのであればやるべきだと思う。
とにかく要件定義に入る前にお互いの理解を深めるフェーズが必要。
そう感じた。

と書いてみたもののもう弊社ではそんなフェーズはとうに過ぎてしまっている。
ベンダーから上がってきた使えるかどうか分からない機能でどう運用していくかを考えなければいけない。
場合によっては無理やりその機能を使って非効率的な運用をするかもしれないし、場合によっては作ってもらった機能はもう捨ててしまいシステム外で処理するという判断もあるかもしれない。

皆さんはこうならないことを祈ります。