こんばんは。Milkです。
実は、Renaは私と同じ業界で働いています。
もともと、Renaの本職は全然別の業種でしたが、再就職を行う際に私のようなIT業界に入りました。
そこで幾つか私に質問をしてくることがあるのです。
あくまで、私の意見ででしか答えることは出来ませんがね・・・
あのね。パッケージについて質問があるんだけど・・・
共通パッケージがあるんだけど、それを各会社向けにカスタマイズして売っているみたい。なにか引っかかるんだけど。
それはね。恐らく、共通パッケージを崩しているからだよ。
最早パッケージではなくなっている。
パッケージ化は誰もが夢見てきたこと
これを話す前に、パッケージとは何かということを簡単に説明しましょう。
各会社向けにシステムを構築するのは、オーダーメイドなので使い勝手が良くなりますが高価にもなります。
ですから、もっと安価に導入したいという会社があるのも事実です。
自分用のシステムを構築するのは高くつく。でも、システム化は進めたい。
そこで始まるのが、各会社に提供しているものから共通部分を抽出して、パックにする。つまり、「共通パッケージ」というものを作って売ればいい。という発想に至ります。
この発想は決して間違いではありませんし、真新しい考えでもありません。
メリットとしては以下の点が挙げられます。
- 最初からシステムを構築する必要がない
- 短期間で導入可能である
- 同じシステムを利用できるので開発費をそのまま利益化できる
端的に申し上げると、幾度とこの「共通パッケージ」化をトライしながらも、無残に残された屍が多くあるのも事実なのです。
これには、陥りがちな落とし穴が幾つかあるからです。
共通化が出来ない
はっきり言って、現在のシステムから共通部分を抽出するのは不可能と言っても過言ではありません。
何故なら、各会社で仕事の作業手順や方法は異なるからです。
別々のものから共通項を見出そうと言う事自体が間違いなのです。
とあるモデルをパッケージと称する
ここでし始めてしまうことは、既に適用しているシステムを「共通パッケージ」と称して、売ろうとするパターンです。
さて、先ほどの話から、これは無理があることが分かるでしょう。
つまりは他社は、このモデルとなっている会社のシステムと作業手順や方法が異なるので、そのまま適用出来ないのです。
と言うことは、カスタマイズが必要になります。
カスタマイズではなく再開発である
営業マンがこの部分で誤って伝えてしまうことが大問題です。
それは、「御社に対して弊社のパッケージをカスタマイズして適用出来ますから、導入コストを抑え期間短縮が可能なのです。」とセールストークしてしまうのです。
私でしたら、その営業マンをぶち殴ります。
カスタマイズと言っていますが、それはフルスクラッチ（再開発）と何も変わらないからです。
そもそも、そのパッケージは売り込み対象の会社に「合致する」ものではないのは最初から分かっていることです。
それを「カスタマイズ」という、調子の良い言葉を使ってごまかすのです。
では、もう少し手前の部分を考えてみましょう。
そもそも「パッケージ化」する場合に、「オプション」という考え方を導入していたとしたら、この「カスタマイズ」は意味を持ちます。
つまりです。機能ごとに分離可能な設計にしてパッケージ化します。
売り込む対象の会社に対し、必要なオプションを選択してもらい、これを組み合わせて納入します。
これなら、再設計は必要ありません。そもそも、機能として独立していますから、付替え可能になっているからです。
なぜパッケージ化は失敗するか
さて、パッケージをマーケティングとして成功させるには1つ重要な要素があります。
それは、お客様の仕事の仕方を変革させること。
パッケージを崩した時点でメリットが死ぬ
先ず、先に述べたように各社の共通項を見出して、パッケージ化するという発想ではパッケージ化は実現出来ません。
何故なら、これは異なる問題から見当違いの解を得ようとしているからです。
言ってしまうならば、サッカーとテニスと野球、どれにも適用できる必勝パターンを答えなさいと問うているのと同じです。
これは出来ません。
ですから、仕事の仕方として一番効率の良いと思われる形を、我々が設計します。
その途中過程として、その業界の方々の意見を頂戴する機会はあるでしょう。
また、機能として分離し、本来の意味のカスタマイズが可能な状態にします。
「パッケージを導入し、御社に必要な機能を付け加えていきましょうね。」という販売スタイルにするためです。
ここまでやって初めてパッケージ化が可能です。
そして、一番重要なのはセールスです。
この時に、カスタマイズを「御社にピッタリ合うように改造します。」という意味で言ってしまったら最悪です。
せっかく、機能として分離したモノたちを破壊したり、そもそものパッケージの破壊が始まります。
大事なのは、「御社がこのパッケージに合わせて作業の仕方を変革することで、より効率を上げることが出来ます。」とセールス出来るかです。
そうでなければ、パッケージ化のメリットは死にます。
最初からシステムを構築する必要がない（×）
最初からシステムの再構築を行うことになります。
最悪は、パッケージを無理に改造し、メンテナンスできない状態になります。
バグの発生を高確率で誘発しますし、結局はパッケージを弄るよりも、フルスクラッチで専用に作ったほうが良いという結論になるでしょう。
使い勝手はその方が断然良いはずですから。
短期間で導入可能である（×）
そのままパッケージを導入できるから短期間で納入出来るのです。
改造を行うなら、時間がかかるに決まっています。
お客様との打ち合わせを重ねて、再設計を行う必要が出てくるからです。
これも同様に、結局はフルスクラッチで作っているのと変わりない状態になります。
同じシステムを利用できるので開発費をそのまま利益化できる（×）
システム会社からすると一番の旨味はここのはずなのです。
しかし、改造を入れた時点で人件費がかかります。
本来はフルスクラッチで作るとかかっていた費用が、そのまま利益化出来る。それがメリットであったはずです。
ですが、改造すれば、その費用は当然ながら人件費に流れます。
また、最悪なパターンは、パッケージ化した時点で値段を下げているパターンです。
本来は、フルスクラッチで作った場合の値段を維持したまま販売するべきなのです。
それが営業マンの腕が問われる部分です。
パッケージ化し開発費がかからなくなったから、値下げする。これは本末転倒です。
何のためにパッケージ化したのか分かりません。薄利多売の泥試合に自ら持ち込んでいくことになるのです。
また、改造が発生したら、人件費を確保出来ません。もう赤字決定です。
このマーケティングや、何を目的としてパッケージ化したかを理解せずに売るセールスマンが多すぎます。
最後に
今回はシステムのパッケージ化について話をしました。
私は、技術者として以下の言葉を胸に刻んでいます。
機能的なものが美しいのではない。
貴方の指針となる言葉はなんですか？ - Milkのメモ帳
美しきもののみ機能的である。
美しさ（設計美）を失ったものは、必然的に使いにくいものになります。そして、逆にコストがかかるのです。
フルスクラッチで開発するならば、お客様の問題を解決するために、要望を盛り込んで設計することが大事でしょう。
しかし、我々が開発するパッケージが利益を生み出すものになるかどうかは、我々がどれだけの美しさを表現出来るかにかかっているのです。
そして、その美しさを壊さない。
つまり、我々がIT戦略の相談役としてコンサルティングの立場で、パッケージを導入してもらい、その形で仕事の仕方の変革を促すという役割にならなければならないのです。
誰にでも適用できるものは、誰にも必要ないものとなります。
これが理解できなければ、パッケージという分野の成功は成し得ないでしょう。
