パッケージのカスタマイズ

2011年7月6日

IT部門でよくある質問として、機能を提供する際にカスタムソフトウェアを構築するか、パッケージを購入するかがあります。私がプログラミングを始めて以来、この選択方法に関する議論は続いてきました。これに対する私の基本的な立場は、ユーティリティ対戦略的二分法に基づいています。要約すると、サポートするビジネスプロセスが競争優位性の一部である場合はカスタムソフトウェアを構築し、そうでない場合はパッケージを購入してビジネスプロセスをパッケージの動作に合わせるべきです。

私の意見の素晴らしさにもかかわらず、多くの企業がこの方法をとっていないようです。多くの場合、彼らは二分法を無視しており、これが1つの問題です。しかし、ここで注目したい問題は、パッケージを購入する際のよくある落とし穴です。

上記で「パッケージを購入してビジネスプロセスを合わせる」と述べましたが、これには2つの理由があります。第一に、ユーティリティビジネスプロセスをサポートするためにパッケージを購入する場合は、ビジネスプロセスに差別化がないため、パッケージに合う方法でビジネスプロセスを実行しても構いません。もちろん、これは非常にソフトウェア中心的な見方です。チームが差別化された作業を行っていないという事実にもかかわらず、彼らは独自のやり方で作業することを、くだらないソフトウェアパッケージが望むやり方よりも好むでしょう。プロセスよりも人材を重視する者として、私は自然とこの見解に多くの共感を抱きます。

しかし、この自然な行動の結果として、企業はパッケージの重要なカスタマイズを開始します…そして、これが問題の始まりです。実際、ほとんどのパッケージは、少なくとも大規模には、カスタマイズを本当に実現可能にするような設計になっていません。通常、同僚のスコット・ショウが「デリバラビリティ」と呼ぶもの、つまりバージョン管理、テスト、展開パイプラインのサポートなどが不足しています。これにより、変更が脆くなり、制御が困難になります。

カスタマイズが小規模であれば耐えることができますが、多くの状況ではそうではありません。最近、同僚が30万行のカスタマイズコードに及ぶパッケージカスタマイズに出くわしました。これは、当社のStudios製品スイート全体のコードベースよりも多く、10年間戦略的ビジネスを実行してきた大規模クライアントプロジェクトのコードベースの2倍です。そのような規模になると、カスタムソフトウェアで使用する場合と同じツールとプロセスなしで管理することはできません。

この問題は、ベンダーがパッケージのアップグレードをリリースし、カスタマイズがアップグレードで破損するため、アップグレードに膨大な作業が必要になることが判明したときに、最も顕著になります。ガートナーは最近、企業システムを最新バージョンにアップグレードするには5000億ドルかかると推定しました（2015年までに1兆ドルに増加）。これは大きな数字ですが、真のコストは、価値のないカスタマイズや、純粋にカスタムルートの方が安価だった可能性のあるカスタマイズにどれだけの資金が無駄に費やされたかです。

では、どうすればよいでしょうか？まず、ユーティリティビジネス機能のパッケージカスタマイズについては、ある程度厳格な姿勢を持つことが重要だと思います。ソフトウェア側の費用は本当に価値がありますか？アジャイルアプローチはユーティリティ機能ではそれほど重要ではありませんが、小さなステップを踏むという概念は価値があります。最初はカスタマイズなしでパッケージを使用し、実際にどの程度うまく機能するかを確認してみませんか？人々は変化に自然に不快感を抱きますが、それは人々の自然な反応です。しかし、ある程度の時間が経てば、重要だと思っていたことがそれほど重要ではなくなることに気づくかもしれません。

カスタマイズの実行方法を真剣に検討できます。いくつかのアプローチは、他のアプローチよりもデリバリーが困難です。パッケージの古いバージョンで同様のレベルのカスタマイズを行った他のユーザーを探し、アップグレードに何が必要だったのかを調べましょう。これにより、コストのより正確な見方が得られる可能性があります。一般的に、パッケージについては、アップグレード可能性を第一級のクロスファンクショナル要件として扱う必要があります。

ベンダーにパッケージのカスタマイズを依頼する場合、顧客のデリバリープラクティスに従わせることは非常に困難です。彼らがそれらのプラクティスに従わないリスクは高く、リスク計画の一部として考慮する必要があります。

多くの組織は、使用する言語やフレームワークの数を制限しようとします。これらのカスタマイズ可能なパッケージの多くは、事実上、別の言語またはプラットフォームであることを覚えておく必要があります。その結果、新しい言語の採用に反対する主張は、パッケージのカスタマイズ作業にも同様に適用されるはずです。

実際、新しい言語の導入に反対するよくある主張は、その言語の開発者を発見するのが困難になることです。この問題は、パッケージでは特に当てはまります。なぜなら、パッケージは多くの場合、限られた雇用機会しか提供しないからです。さらに、多くのパッケージカスタマイズ作業の性質は有能な人を阻止するため、多言語プログラミングに慣れている優秀な人材を見つけることがさらに困難になります。人材採用が難しいことによるコストは、メインストリームのプログラミングプラットフォームでのカスタム開発よりもパッケージを使用することによるコスト削減よりも大きくなる可能性があります。

パッケージをカスタマイズするのではなく、パッケージが効果的なAPIを介してデータと機能を公開できるかどうかを確認し、カスタム機能用のカスタムアプリケーションを作成します。多くの場合、人々は同じワークフローの異なる部分に個別のアプリケーションを使用する必要があるため、これを嫌います。それはより小さな負担であり、Webインターフェースでさらに小さくすることができます。ロックインを減らすことができるため、ベンダーがこれを困難にする可能性がありますが、コラボレーションの容易さは、どのベンダーを選択するかを決定する上で重要な要素です。

しかし、ここに落とし穴があります。カスタマイズの大きな原因の1つは、異なるベンダーのパッケージ間の統合です。これは、ベストオブブリードを選択するのではなく、複数のパッケージに単一のベンダーを優先する大きな理由です。単一のベンダーを選択すると、それが正しく行われることが彼らの利益になるため、統合が容易になります。それがユーティリティビジネス機能である場合、ベストオブブリードパッケージの価値は限定されます。

要約すると、パッケージ環境は通常、ソフトウェア開発にとって非常に貧弱なプラットフォームを提供します。そのようなパッケージのカスタマイズと最新の状態を維持するには、多くの人が考えるよりもはるかに多くの費用がかかります。