業務用ソフトウェアパッケージを導入するときに考えること

2020年2月23日2022年10月26日

市販の業務用ソフトウェアパッケージを活用する

今日、おおよその業務には業務用ソフトウェアパッケージ（以下、業務パッケージ）が存在しています。例えば会計ソフトであれば、「弥生会計」や「freee」がありますし、顧客管理であれば「Salesforce」が有名です。
一昔前では買い切りの業務パッケージが一般的でしたが、最近では月々の料金を支払い、サービス利用の権利を購入するサブスクリプション型のWebサービスもさまざまなものが展開されています。
ITシステムを１から構築していくと、仕様の策定から、コーディング、テストなどさまざまなプロセスを完了していなければなりません。そのため、『人月の神話』にあるように、「購入できるものをあえて構築しないようにするためのマスマーケット（市販製品）の利用^[1] フレデリック・P・ブルックス Jr.、滝沢徹 (訳) 、牧野祐子 (訳) 、富澤昇 (訳)『人月の神話　【新装版】』、丸善出版社、2014年、168頁。 」をしていく意識が何よりも大切です。

独自カスタマイズ・外付けプログラムのデメリット

業務パッケージでは実現できないこともある

業務パッケージを導入しようとすると、現在の業務プロセスと適合しない部分があり、パッケージに手を加えて独自にカスタマイズしたり、外付けのプログラムで足りない部分をカバーしようとすることもあります。
しかし、こうした独自カスタマイズや外付けプログラムは往々にして業務パッケージの保守性を下げてしまいます。
その理由を見ていきましょう。

独自カスタマイズ・外付けプログラムは保守性を下げる

業務パッケージのバージョンアップができなくなることも

業務パッケージはバグやセキュリティの脆弱性などが見つかると、定期的にバージョンアップされていきます。
業務パッケージを利用するメリットとしては、このようなバージョンアップが行われるため、保守性を高く保てることにあります。
しかし、独自にカスタマイズして、業務パッケージの根幹部分を変更してしまったりすると、バージョンアップがうまく実行されないこともあります。
また、バージョンアップにより外付けプログラムが稼働しなくなってしまうおそれから、バージョンアップができず、バグやセキュリティに問題がある状態で業務パッケージを使用し続けないといけなくなるということもあります。

不具合に悩まされるようになる

独自にカスタマイズしたり、外付けプログラムを開発しようとすると、ITシステムを１から構築する際と同じく、さまざまなバグや不具合が発生してしまいます。
上述の通り、業務パッケージはこうした不具合が発見されたら、製品提供元がその不具合を修正し、バージョンアップ版をリリースするのが常です。そのため、市販の業務パッケージにはバグや不具合がほとんどありません。 しかし、独自カスタマイズや外付けプログラムはその限りではありません。
独自カスタマイズや外付けプログラムをどこまで念入りにテストしても、いざ実際に業務で使ってみると、開発当初は想定していなかった動きに対して不具合が発生してしまうことはよくある話です。
こうした不具合対応が面倒で業務パッケージを利用するという側面もあるのに、 カスタマイズや外付けプログラムによって不具合に悩まされてしまうというのは業務パッケージの魅力を損ねてしまうことになります。

責任の所在が不明瞭になる

業務パッケージに外付けプログラムを開発すると、責任の所在が不明瞭になってしまうことがあります。
例えば上述の通り、外付けプログラムが業務パッケージのアップデートによって機能しなくなることがあります。
いざそのような事態が発生し、外付けプログラムの開発者と業務パッケージの提供元が異なる場合、両者ともに「その不具合は自分の責任ではない」と言い張り、なかなか不具合の解消が進まないということもあります。
こうしたトラブルを避けるためにも、業務パッケージに独自カスタマイズや外付けプログラムは加えず、どうしても必要になったとしても、業務パッケージの提供元ができる範囲にしておいたほうがよいでしょう。

保守料金が高くなる

業務パッケージを独自にカスタマイズしたり、外付けプログラムを開発すると、多くの場合保守料金が高くなります。
カスタマイズした部分だけ特別なメンテナンスが必要であったり、外付けプログラムだけ別の業者に保守を依頼していくと、業務パッケージの利用料とは別に、保守料金が発生します。

どうしても独自カスタマイズ・外付けプログラムが必要になったら考えること

以上のように、すでに確立されている業務パッケージを組織にあわせてカスタマイズしたり、外付けプログラムを開発したりするというのは得策ではありません。
しかし、どうしても独自カスタマイズや外付けプログラムが必要となった場合は、以下の手順をもって導入を検討していきましょう。

他に業務プロセスにあうパッケージはないか

もし独自カスタマイズや、外付けプログラムの必要性がプロジェクトで論じられはじめたら、他に使える業務パッケージがないか再度調査することをおすすめします。
手間ではありますが、独自カスタマイズや外付けプログラムを行うより、はるかに時間を削減できることができます。
「外付けプログラムを作ってでも実現したい」という機能にフォーカスして、業務プロセスにあった業務パッケージをもう一度探してみましょう。

業務パッケージに業務プロセスを合わせられないか

もう一度業務パッケージを探しても、独自カスタマイズや外付けプログラムで要望されている機能を満たせない場合は、その機能を求めている業務プロセスを改められないかを検討していきます。
つまり、「今この業務プロセスだから、この業務パッケージはこのままでは使えない」と考えるのではなく、「これからこの業務パッケージを使うのだから、これにあわせた業務プロセスにする」という対応ができないかを検討していきます。
これまで必要と無批判に考えていた業務プロセスであっても、上記の独自カスタマイズ・外付けプログラムのデメリットを話し、改めて業務を見つめ直すと、そこまで必要でなかったということも多々あります。最後まで希望を捨てず、再度業務プロセスを見直していきましょう。

独自カスタマイズ・外付けプログラムもパッケージ提供元に依頼できないか

どれだけ検討しても、業務プロセスに適合するような業務パッケージがなく、またその業務プロセスも必須であるのであれば、独自カスタマイズや外付けプログラムで対応しなければなりません。
その場合、業務パッケージの提供元に、カスタマイズや外付けプログラムの開発を依頼できないか確認してみるとよいでしょう。
既述の通り、独自カスタマイズや外付けプログラムを行うと、バージョンアップがしにくくなったり、責任の所在が不明瞭になったりと、保守性を低下させます。
しかし、提供元にカスタマイズや外付けプログラムを依頼することにより、バージョンアップを妨げない設計にしたり、責任の所在を１つの組織に集約したりすることができ、保守性への影響を軽減することができます。
こうしたカスタマイズや外付けプログラムは業務パッケージの提供元以外でも対応できることがありますが、できるだけ提供元に依頼していくとよいでしょう。

業務パッケージにあわせた業務プロセスを考える

今回は業務パッケージを導入する際、独自カスタマイズや外付けプログラムが必要になった場合に考えるべきポイントを解説していきました。
昨今では様々な業務パッケージが販売されており、それらを導入することも簡単になってきました。
しかし、いざ業務パッケージを導入しようとすると、どうしても現在の業務プロセスにあわない部分がでてくることもあります。
そうした場合の対処法を今回は検討していきましたが、なんといっても最善なのは、業務パッケージにあわせて業務プロセスを変更することです。
あくまで独自カスタマイズや外付けプログラムは最終手段として考えていたほうがよいでしょう。