スクラッチ vs パッケージ

「ウチの業務は特殊だから、合うパッケージはないと思います」

システム導入を検討するにあたり、そうおっしゃる業務部門の方はとても多いです。
今のやり方に不満がなく、変化も望んでいないので、現場はスクラッチ一択の姿勢です。

一方、システム部門は「業務の標準化を図りたい」という思惑があり、パッケージ導入が望ましいと考えています。

双方の立場や意見が対立するなか、どうやって折り合いをつければ良いでしょうか?

既製品が合わなければオーダーメイド

まずは、スクラッチとパッケージ、それぞれの特徴について整理します。

スクラッチは、オーダーメイドの「注文住宅」のようなものです。

ゼロから作るので、相応に時間と費用がかかります。
こちらの要望に対して柔軟に対応できますが、完成品の仕上がりは選んだ業者の力量やセンスに大きく左右されます。

対して、パッケージは「建売住宅」になります。

開発済みの既製品であるため、「低価格」かつ「短納期」です。
多くの企業で使われているパッケージなら、さらに「高品質」まで約束されています。
紹介資料や製品カタログが豊富にあり、使い勝手(住みやすさ)がイメージしやすいことや、トライアル(内見)ができることも特徴です。

昨今のシステム選定においては、「業務に合うならパッケージ、合わなければスクラッチ」という考え方が主流であると言えます。

パッケージに合わない業務、の理由

パッケージに合わない独自の “特殊な業務” については、以下のような論点で掘り下げます。

論点1)業務をパッケージに合わせるつもりがあるか(そもそも標準化する気があるのか)

「合うパッケージはない」という発言に捉われず、可能性を探ってみてください。

「歩み寄る気がまったくない」という様子なら、標準化の必要性について業務部門の方と今一度話し合う必要があるでしょう。

もし譲歩できる余地がなかったとしても、そこだけカスタマイズ対応すれば、業務にフィットする最適なパッケージが見つかるかもしれません。

論点2)特殊でなければならない理由があるか(標準外であることが妥当か)

その “特殊な業務” が「自社の競争優位性を得るために不可欠なもの」であるなら、安易に標準化を推し進めることはできません。

また、標準化することで致命的な不都合が生じてしまう(避けられない)場合も、その特殊性が妥当であると言えます。

逆に、妥当と思える理由が特にないなら、パッケージ(業界標準)に業務を合わせていく方向で検討できそうです。

議論すること自体が有意義

急いでどちらかを選ぶ必要はありません。
迷っているなら、まずはパッケージ導入の可能性を探りながら考えてください。

なぜなら、パッケージ導入を諦めてスクラッチ開発に舵を切ることは可能ですが、逆は難しいからです。

システム導入の検討は、各部の関係者が業務について真剣に話し合える大変貴重な機会です。

パッケージ(業界標準)に目を向けることで、新たな気づきがあるかもしれません。
結果、スクラッチという結論に至ったとしても、十分検討したことで理解が得られ、合意形成がなされた状態で次のステップに進むことができます。

せっかくのチャンスなので、客観的な視点で業務を見直しつつ、自社にとって最適なシステムは何かを探りましょう。