見てくれの良いインタフェイスに左右されるようなので、せめて電算化の統括係としては提案業者の業務理解の深さと関連業務への配慮を読み取るよう努力し、それを重視してシステムを推薦しています。必ずしも要求機能の有無や原課側の評価を優先するのではなく、アプリケーション・パッケージの根底に流れる「業務かくあるべき」という設計者の思想を重要視しています。ところが「線をつなげば簡単に他のシステムとつなげる」という誤った認識をしている職員もおり、個別システムの総合的利用といった面を理解してもらえないことが多く、対応に苦慮しています。
5-3カスタマイズ範囲の検討について
いままでの実務経験から考えて、こういう入力画面が便利で、こういうデー夕の表示が必要だ、という提案を原課からもらいたいのですが、なかなかそうはいきません。といっても、なにもないところから論議を始めると、夢物語になりがちです。現在の要求確認手法は、プロトタイプといわれる形をとっています。あらかじめパソコンに画面イメージを作って、それを実際に見たり操作してもらって、原課職員に確認してもらっています。画面変更の編集作業は、まるで福笑いのようなものです。ボタンや入力フィールドの移動は、マウスでクリックAndドロップすることでその場で見せることができます。こういった手法で簡単にできるのも、クライアント・サーバ型の利点の一つだと思います。ただし、「既に出来ている入力画面では何故満足できないか」「その要求はローカルルールではないか」「作成したメーカー側の意図は納得できるか」「原課ならではの提案なので、ベースのアプリケーション・パッケージが対応し改修すべきではないか」などを評価検討し、できるだけ市独自版にならないように留意しています。
出力帳票などは、様式変更することで効率の上がることが明確ならば、システムに合わせる価値もありますが、むしろシステム化によって運用手順が変わるわけですから、見慣れた帳票が出る方が、使う人は安心するのではないでしょうか。こういった考えから、帳票類は市のそれまでのイメージをできるだけ踏襲し、カスタマイズしています。実際に様式の変更は規則にからんだものもあり、難しいところです。ただし出力帳票は、紙に出力すべきか、画面で見るだけで十分かを、最後の最後まで検討しました。従来のやり方はバッチ処理に頼った業務手順でしたので、いつでも最新の情報をオンラインで検索して利用する、という業務手順をイメージしにくいようです。しかし
