ァーストユーザーの幸運と、開発業者さんの努力に感謝しています。当然ながら、完成したシステムは思いどおりのものとなり、原課からも非常に好評でした。ところが、あまりにも原課業務が整理され効率的になったので、以後システム化する業務に同様な成果を期待され、本当にアプリケーション・パッケージを利用するようになった時に辛い思いをしました。
(3)アプリケーション・パッケージ利用の目的
電算担当課は負の評価が多いようで、検討段階にも他の地方公共団体の電算課員から「委託のままがいいのでは？」という意見をよく聞きました。コンピュータが処理するものはすべて電算課の仕事で、原課の担当ではないという風潮が原因のようです。コンピュータ操作を専門家に任せるというのはメインフレームのシステムでは仕方のない面もありますが、私達のような分散型のシステムになると、システムの運用も機器の操作も原課職員に対応してもらわないと効率的になりません。ユーザーが操作できる機器の数が多くなり、集中して管理すること自体が難しくなるからです。エンドユーザー自らがシステム運用を行うには、専門家でなくても対応できるシステムを構築する必要がありました。そこで、せっかく始めるなら従来の流れをシステム化するのではなく、システム導入を機会に業務のやり方を見直すべきと考え、アプリケーション・パッケージを基本にワークフローも参考にして、BPRも目的の一つにシステム化を進めることにしました。
5-2 アプリケーション・パッケージ選定における体制について
予算要求を含めシステムの開発は原課主体ですが、業務手順やシステム化要求を電算担当がヒヤリングし、機能要求仕様書にまとめます。原則的には、それを業者に提示し提案を受け、その内容を原課とともに評価し選定します。評価の際は、アプリケーション・パッケージに要求機能があるかを確認するのではなく、要求機能を満足できるなら、費用低減と開発期間短縮のためアプリケーション・パッケージを使っても良いとしています。ただし、提案者から合理的な説明がされ納得できる場合、要求機能の仕様変更を行うことがあります。これは、原課の要求には、自分達のやり方が基準になっているものが多く、根拠や必然性に疑問のあるものも「あらねばならない」要求になりがちだからです。そういった要求はシステム化の際、大胆に見直し、パッケージのワークフローを採用することもあります。原課の皆さんの評価は、
