社内SEから見たシステム導入の難しさ

　システムを4，5年も使用していると、これまでの使い勝手の悪さやそのシステムの保守期限が切れるといった理由から別のシステムに切り替えようといった話が持ち上がります。

　次のシステムを選定する際、最近だと候補に挙がってくるのはパッケージ製品やSaaSのサービスが多いかと思います。パッケージ製品やSaaSのサービスはすでにいくつかの機能が完成されたシステムなので導入期間は短く、導入の難易度も低いと思いがちなのですが、利用する側の考え方次第で難易度はかなり上がってしまいます。

　今回はパッケージ製品やSaaS製品の導入でトラブルが続いたので、導入時の注意点をあげていこうと思います。

新しいシステムをそのまま受け入れる覚悟が必要

　パッケージ製品やSaaSサービス導入のキーポイントはいかにアドオン開発を0に近づけられるかという点です。

　アドオン開発というのはパッケージ製品やSaaSサービスにない機能を追加開発するという意味です。アドオン開発を行うと元々想定していなかった使い方をすることになるので、想定外のデータが発生したり、想定外のエラーが発生したりします。

　なぜこのようなアドオン開発が必要になるかというと、ユーザー側がテスト期間中に試しに使ってみたところ、使い勝手が悪いといった意見や、これまでの挙動と違うといった意見が出てきてそれを受け入れてしまうところから発生します。

　これらの要件を受け入れだすとアドオンの機能が多くなり混乱が始まってしまいます。プロジェクトを開始する前にアドオン開発の数は10以下にするなど決めておいた方がよさそうです。

アドオン開発の影響

　少しの改修だからといってアドオンを受け入れてしまうことが多々あります。少しの改修でも影響は甚大ですので、本当に必要な要件の時だけアドオンを受け入れるようにしましょう。

　アドオン開発が発生するとそれに伴って様々なタスクが付随します。既存機能への影響確認、操作マニュアルの作成、教育、アドオン機能の保守など。

　パッケージ製品やSaaSサービスのメリットは機能間の連携テスト済みであること、操作マニュアルが準備されている、バージョンアップしても正常に動作するというメリットがあります。これらのメリットがアドオン開発によってなくなってしまいます。

　例えば、アドオン０のパッケージ製品を導入した場合はバージョンアップ後の機能も開発ベンダーの方でテストが完了しているため、テスト工程はある程度省略することができます。反対にアドオンがある場合はバージョンアップした後、アドオン機能のテストをやり直す必要が出てきます。

　バージョンアップは基本的に新しい価値を生み出さないので、ユーザーにとってのメリットはないのですが、大量のアドオンを含んだ製品をバージョンアップするとテスト工程だけで数千万円かかったりします。

　アドオン開発は開発費用だけでなく社内のIT部門の運用工数も増えてしまいますので注意が必要です。

これまでの挙動と違うという意見が出だしたら赤信号

　新しいシステムを導入するのにこれまでの挙動と違うのは当たり前だと思いますが、新システム導入時には意外と「これまでの挙動と違うのは困る」という意見が出てきます。

　理由はユーザーがこれまでと異なる運用をしたがらないから、もしくは、運用が異なることで自分たちの負荷があがるのではないかと不安になっているのだと思います。

　ユーザーをいかに説得して、パッケージもしくはSaaSの仕様通りに使ってもらうかがPJ成功のポイントになります。

　アドオン開発を防止するには新システム側にアドオン開発をするのではなく、社内ルールの方を変えていく必要があります。社内ルールを変更する権限のある人をプロジェクトにアサインできるかが重要です。

IT部門のスキルが高いと導入が難しくなる

　パッケージ製品やSaaSサービスを導入する際、実際のユーザと導入ベンダーの間に社内のIT部門が入って導入を進めていくのが一般的かと思います。

　このIT部門のスキルが高いと導入が難しくなってしまいます。

　なぜかというと、スキルが高いとユーザーの要望をかなえるために、「こうしたら実現できますよね」と導入ベンダーに逆提案してしまうことができてしまいます。そうなると導入ベンダー側も断りづらくなり、アドオン開発が増えていってしまいます。IT部門のスキルが低ければ、しかたないとあきらめて、元々のパッケージをそのまま使用するという方針になることがあります。

　最近はSierやSEから社内SEに転職するケースが多いので、IT部門を説得するのが難しくなっているのではないかと思います。

最後に

　パッケージ製品やSaaS導入時のポイントを見てきましたが、いかがでしたでしょうか。

ポイントは
　新しいシステムに合わせて社内ルールを変える
です。

　ベンチャー企業など、発足したての会社だと、社内ルールや運用が決まっていないため、製品の仕様に合わせて社内ルールや運用が決まっていくと聞きました。

うらやましいです。

　話は飛躍しますが、日本の生産性が低いというのは既存のルールを変えられないというところが大きな原因なのかなと思います。

　何も生み出さないバージョンアップにお金や時間をかけるよりは、新しいビジネスにお金をかけられるシステム構成にしていきたいです。

　そのためにはIT部門だけでなく、会社全体の意識改革が必要なんですが、トップダウンで変えていってもらわないと変わらないだろうなと思う今日このごろでした。