松田 幸裕 記
沖縄県以外で緊急事態宣言が解除されました。しかし東京では、その週からいきなり新型コロナウイルスの新規感染者数が増加してきています。先週、先々週あたりからの人の緩みによる結果が、今出てきているのでしょうね。
直接的に人の行動の緩みを抑制する法律がないこと、飲食店なども時短要請を守らない店が増えていて制御が効かなくなっていることなどを考えると、いっそ自己責任という手法に切り替えてもいいかもしれませんね。ワクチンを接種したい人は接種し、接種したくない人は感染リスクを受容して接種しないという判断も尊重します。店舗も自由に営業できるようにし、「ワクチンを接種した人だけ入店可」という経営も自由とします。そして病院も自分たちが過労に陥らない程度にキャパシティを維持し、無理な受け入れは行わないようにします。
細かいことを考えると「この場合はどうすればいいの？」など議論すべき点はあると思いますが、、、国民が自由を求めるのであれば、自由と責任はセットとして、自己責任の路線に転換する方が良いのではないか、と思う今日この頃です。
本題に入ります。前回・前々回の投稿「JUAS 企業IT動向調査報告書2021から今を読む その１／その２」では、JUAS（一般財団法人 日本情報システム・ユーザー協会）から公開された「企業IT動向調査報告書 2021」より、経営課題にまつわる傾向、そしてセキュリティについて考察しました。本投稿ではさらに視点を変えて、アプリケーションについて考えてみたいと思います。
既製アプリケーション活用は日本企業における重要な取り組み
「デジタル化に向けた既存システム改革の取組み状況」についてのアンケート結果があります。この結果によると、既存システム改革の三大取り組みは、「①セキュリティ強化、②既製アプリケーション活用、③IT基盤のクラウド活用」とのことです。
デジタル化に向けた既存システム改革の取組み状況
セキュリティ強化、クラウド活用はすんなり頷けますが、既製アプリケーション活用が三大取り組みに入るというのは、少々違和感がありますね。既製アプリケーションを有効活用すべきという話はかなり前から言われてきたことであり、もう一通りのシステムがこの考え方に基づいて最適化されていてもおかしくないため、今も既存システム改革の三大取り組みに含まれていることが少し不思議です。
既製アプリケーション導入における課題
「開発するのではなく、パッケージを導入したほうが良い」と考えられるようになってからずいぶん経ちます。このグラフでも「実施済み」が39.3％と多く、既製アプリケーション導入は進んでいることがわかります。
ただ、私が企業ITを見てきた中では、既製アプリケーションを導入したからといって幸せになれてはいないように見えます。既製アプリケーションには既製アプリケーションの課題があり、それを解決できなければ既製アプリケーション導入の効果は半減となってしまいます。私が感じる既製アプリケーションにおける課題は、主に以下のようなものです。
- 業務をパッケージに合わせようとしない。
- 現行踏襲の意識が強い。
- システム連携部分でコストを削る。
既製アプリケーション導入で陥りがちなパターン
製品と導入ベンダーが決定し、社内稟議も通し、要件定義へと進みます。その中で細かい要件の確認がされるのですが、ユーザーや情シス部門からの「現行のシステムではこういうことができるけど、新システムではできる？」という確認は多く、導入ベンダー側もその要望に応えようと必死になります。要望に応えるためにアドオン開発のみでなく、細かい設定での工夫なども多く、検証作業などを含めた導入工数は増え、要件定義後に出てきた設計フェーズ以降の見積は予算オーバーに。顧客企業としては稟議で承認された金額を超えるのは都合が悪いため、どこかで作業を削って帳尻を合わせる必要があります。そして調整の結果、システム連携など必須ではない機能が削られます。しかしシステム間の連携がされていないことによる非効率は残り、導入による効果は薄くなってしまいます。日本でRPA（Robotic Process Automation）のニーズが多いのは、もしかするとこういう背景もあるかもしれませんね。
既製アプリケーションを導入する上での考慮ポイント
今までも言われてきていることですが、既製アプリケーションを導入するのであれば、業務をパッケージに合わせるべきです。前述の「現行のシステムではこういうことができるけど、新システムではできる？」というニーズは、もちろんそれが業務上の真のニーズである場合は応えるべきですが、「私たちは新しいシステムを導入する」ということを忘れずに、既製アプリケーションに業務を合わせることを基本指針とすべきです。もし「ここだけは譲れない」という業務上のニーズがあるのであれば、その機能を有している製品を選定し、あとはその製品に業務を合わせるのがよいでしょう。
また、無理やりな設定変更でニーズを満たそうとするのではなく、できる限り標準構成で利用するのが望ましいと言えます。そもそも既製アプリケーションは業務のベストプラクティスを想定してつくられたものなので、まずは標準構成で利用できるかを考えるべきと思います。また、標準構成での検証は製造元でしっかり行われていることが多いため、標準構成で利用することでシステムは安定し、仮に問題があってもその形で使用している顧客は多いため、早期解決も期待できます。
単純に既製アプリケーション導入へ進むのではなく、上記のように既製アプリケーション導入における課題、既製アプリケーション導入のポイントなどを十分に考慮したうえで、「既製アプリケーションを導入し、業務を合わせる」、「既製アプリケーションは導入せず、業務に合ったシステムを開発する」などを検討することをお勧めします。
開発での失敗体験を持つIT関係者は多く、なんとなく「開発は悪」のように語る人は多いですが、正しく開発プロセスを進められれば開発の方が良い場合も多いと思っています。開発は開発で、また特有の課題やポイントはありますので、その考慮はもちろん必要ですが、開発も一つの選択肢として検討するべきと感じています。