今回より当ページで毎週コラムを書くことになりましたTALON開発責任者の古関です、よろしくお願いします。 出来る限り一般論ではなく、現場で起きていることや感じていることを中心に書いていきますので興味を持っていただければ幸いです。
身もふたもない結論
さて、第一回目はシステム開発の現場で良く出てくる議論を取り上げてみたいと思います。 実際の現場（提案場面）でも、ネットや雑誌でもよく比較されるこの二つですが、身も蓋もない結論じみたことを言ってしまうとケースバイケースですよね。 そりゃそうです、どのケースの場合でもこっちが良いなんて言えるわけもありません。そもそも比較すること自体がナンセンスなのではと個人的には思っています。 では、なぜこの話題を取り上げたかというと、視点によってはITシステムを企業に導入するということの本質が現れるように感じているからです。
考えるまでもない領域を外す
まずはケースバイケースの意味を考えてみましょう。どのようなケースならばパッケージ導入が適していて、スクラッチ開発が適していないのでしょうか？ よく言われるのは定型業務率が高い業務の場合はパッケージ導入が適している、と言われています。あらかじめ定められた会計基準が存在する経理関連の業務などはその最たるものですね、 あとは医薬品などの品質管理関連など、エビデンスの提出が非常に厳しく、プログラムを修正した場合に大量の提出資料を求められたりするような業務でしょうか。これらに共通していることとして、
- 定型的な業務なので汎用的な業務プロセスでシステムを作っておける。その為システム開発会社がパッケージとして作ると特定の会社以外にそのままに近い形で販売が可能
- システム変更時の資料提出義務やバグがあった場合に会社全体に非常な影響がある
が挙げられます。つまり、これらはそもそもスクラッチ開発なんて考えるべきじゃないものです。まず、これらを除いて考えます（世の中の議論もこの領域ではあまり議論していないと思います）。
生産管理システムを例に考えてみる
では、上記例以外でのケースバーケースを考えてみます。私の専門領域は製造業になりますので、生産管理システムで考えてみます（生産管理で進めますが、会社によって違う、言ってみればビジネスモデルが存在する領域のシステムであればここからの話は同じだと思いますので、ご自分の担当業務に置き換えてお読みいただけると思います）。
生産管理システムの場合、管理領域として通常は、工場に対する生産要求（注文情報や内示情報）が入り、生産計画を立案して材料・部品の手配や社内の製造指示、外注先への依頼などを行い、生産をしたら、生産物の在庫管理をして出荷を行います。 まず、前提としてこのような大きな流れがあり、ここまでは各社大きく違うことはあまりありません。また、業種によっても特徴があり、自動車業界であれば、メーカからの3か月内示があり、徐々に間隔の短い内示になって最後は直前に確定注文が入ります。 この仕組みも業界によって大きくは変わりません。
さらに、工場の生産を管理する手法として長い間スタンダードになっている物もあまり違いはありません。製品一つ一つに製番と呼ばれる番号を付けて管理する製番管理やMRPと呼ばれる所要量の計算ロジックなど共通的に各社使える物は多数あります。ここまで共通なんだから世の中のパッケージどれかはかなりフィットするのではないか？と思いますよね？
そうなんです、よくよく選定すればかなり企業のビジネスモデル、業務運用に近いパッケージはあるはずなんです。でも、実際に生産管理パッケージを導入しようとした企業で、当初の目標を当初予算と期間で綺麗に達成したプロジェクトはどれくらいあるでしょうか？ 約15年ほど現場で体感してきた感覚ですと相当低いと感じています（ちなみに業務システム全体ですと成功率は３０％です）。
パッケージ導入を成功させるには
パッケージ導入が失敗する理由を考えるには、逆にパッケージ導入が成功するための条件を考えた方が早そうです。 失敗の原因は無限にありますが、成功の理由というのは限られているというのが私の実感です。パッケージ導入が成功する為には、
- 導入するパッケージが企業の業務運用に近い（フィット率が高い。最低７０％位は欲しい）
- フィットしない部分がビジネスモデルとあまり絡まない部分であればパッケージに合わせた運用に変更できる
- 導入するパッケージの標準機能を導入企業の責任者なり現場リーダが熟知する位の勉強をしている
- 信頼できる導入担当SEがおり、最初から最後まで担当してくれる
最低限上記の４つが必要だと思います。一つずつ検証してみましょう。
１．導入するパッケージが企業の業務運用に近い
これはパッケージ選定段階でのお話ですね。生産管理パッケージは非常に数多くあり、汎用的な物から特殊業種に限ったものまで様々です。 ここで企業に合ったものを選ぶことが出来れば非常に成功率は高まるのですが、なかなかそうは行きません。上手い選択が出来ない理由を考えてみましょう。
パッケージ選定にはコンペ形式でRFPを元にした各社の提案を受けて決めるケースが多くあります。まず、この方法だけですと正しい選択は難しいと思います。 それは、各社RFPに書かれていることは自社パッケージであれば簡単に実現します、カスタマイズも少なく済みますという文言を強調するからです。 プレゼンする側は売りたいのですから当然いかにノンカスタマイズで行けるかを強調します。これはそうしないとコンペに残れないからです。 正直に、「弊社のパッケージですとここの部分はギャップが多くが生じますので、運用変更かカスタマイズを行う必要があります」とプレゼンした人と、”ほとんどフィットします！”とプレゼンした人、どちらを選ぶでしょうか？ （当然カスタマイズ費用を載せる分だけ正直会社は高価になりますよね）
さらに、選定をする際に導入価格が非常に重要になるのは当たり前ですが、この価格提示にもかなりカラクリがあります。 パッケージの内容で負けそうになるとかなり安い価格までディスカウントして、フィットしていたパッケージ会社が到底提示できないような金額を出してくる場合があります。 そうなるとこれだけ安いんだからと安さに目がくらんでしまうともう最悪です。安くするには理由があるのです。 それは、いざ基本設計をしてみてシステム要件を固めてみたらRFP段階にはなかった課題がたくさん出てきて、相当カスタマイズ費用が必要と言い、追加費用を請求するのです。 結果としてフィットしていたパッケージ会社が提示していた金額を大きく超えて、さらに無理やりのカスタマイズを重ねた結果不具合も多く、使い勝手も悪い物が出来てしまう…。 というのは大げさに聞こえますが、このようなケースは非常に多いです。
では、どうすれば正しいパッケージ選定ができるのでしょうか？ それは、RFPを作る時に、最終目標とその為の手段を決定すると同時に、実際の業務に熟知した人（もしくはグループでチームを作る）が、自社の業務を洗い出して、業務フローを作成します。 その後、自分たちで目標を達成できそうで、実際の業務フローにも近そうなパッケージに目星を付けて、声を掛けて具体的な中身をデモしてもらう機会を作り、触らせてもらうなどして感触を確かめます。 このような方法でしたら近い物を選定できる可能性は高まると考えます。この時に外部のシステムコンサルタントに入ってもらっても良いと思いますが、特定の業務パッケージを売り込む前提のコンサルタントは避けた方が良いと思います。
コンペのプレゼンで選定する場合はRFPと一緒に業務フローも提示してどの程度のフィットギャップが出るかを数値化してもらうと、あいまいで理想だけを並べた資料が出てくるの確率は減り、正しい選定が出来ると思います。
ここまでやって選定しても、単純に今のシステムの焼き直しになってしまう可能性は否定出来ません。いかに最初に立てた目標が達成できるかに目を光らせてプロジェクトを進める必要があります。
※ここでの内容は、生産管理の業務プロセスには自社の強みは感じておらず、パッケージに運用を出来る限り合わせるという意思決定をされた場合は不要になります。 その場合は一番理想とする運用が出来るであろうパッケージを選定します。ある意味ではパッケージ導入の一番高い成功パターンかもしれません（私は一度もこのようなケースに遭遇したことはありませんが…）。
２．フィットしない部分がビジネスモデルとあまり絡まない部分であれば
パッケージに合わせた運用に変更できる
これは、パッケージを導入する場合に細かなところまで今の運用と違うと主張しているとカスタマイズ費用がどんどん膨らみます。 プロジェクトを全社的な取り組みと認知させて、多少不便になったりするケースがあっても、損益に影響しないような部分であればパッケージに合わせるという方針が徹底出来ないと厳しいです。
３．導入するパッケージの標準機能を導入企業のプロジェクトリーダが
熟知する位の勉強をしている
標準機能と合わないから運用を変えるかカスタマイズするかという話になった場合に、実は標準機能の組み合わせを上手く使えば合うようになるということは結構あるのです。 担当するSEにもよりますが、こういう動きになってないと困るとユーザに言われると、単純に標準機能では動かないと判断してカスタマイズを…という話になりがちですので、自社の業務とシステムの標準機能の両方を知っていれば自ずと色々なアイデアが出るものです。 標準機能をしゃぶりつくす意気込みが大切です。
４．信頼できる導入担当SEがおり、最初から最後まで担当してくれる
これまた身も蓋もないですが、やはり重要なのは人です。少なくとも長い期間掛けてプロジェクトを一緒に推進するチームになりますので、この人がいればちゃんと話を聞いてくれて、親身に考えてくれるという人がいると安心です。 さらにその人が色々と目標達成のためのアイデアを出してくれる人だとより良いですね。
パッケージ導入すべきケース
パッケージ導入にするかスクラッチ開発にするかケースバイケースと先ほど書きましたが、上記４つに当てはまる場合はパッケージ導入にすべきだと思います。 正直、ここまでのことが出来るのであればスクラッチ開発でも上手くいくと思います。スクラッチ開発に比べてどこまで費用を下げることが出来るかがキーになると思います。
長くなってきたので、今回はここまでとします。次回はスクラッチ開発側を考えています。
文=古関 雄介
