システム構築プロジェクトの終盤になると、必ずといっていいほど発生するのが「帳票」に関するユーザーの細かな修正要求と、それに対応する開発者の困惑である。
なぜプロジェクトの終盤になると帳票に関する要求が相次ぐのか。それは、新システムで使う帳票をユーザーが実際に見るのは、システム構築の最終工程である受け入れテストになることが多いからだ。帳票を出力するにはデータベースにデータがそろっている必要があり、受け入れテストまではそうした環境が整わない。
そもそも帳票に関しては、開発者とユーザーにはギャップがある。
開発者が最も注目するのは、項目に漏れがないようにすることだ。旧システムの帳票を見たり、新システム用にユーザーが作成した帳票の草稿を参考にしたりして、開発者は必要な項目がすべて含まれているかどうかを注意深く確認する。開発者にとっての「要求通りの帳票」とは、項目に漏れがないことなのだ。
ところが、ユーザーは違う。項目に漏れがなくても、ユーザーは出来上がった帳票を見るといろいろと要求を出す。「この部分をもう少し大きくして上に表示できないか」「フォントが以前のものと違うので違和感がある」「この行は2行になってしまうと格好が悪いので、1行に収まるようにして」といった細かな要求である。
ある営業部門のユーザーは、「顧客に提出する帳票は、ある意味“当社の顔”だ。センスの悪い帳票を出すのはみっともない。顧客の部署名などが途中で切れたり折り返したりするのは失礼である」と言う。ある経理部門のユーザーは、「毎日大量の帳票を見るので、少しでも読みやすいほうが目は楽だし、事務のミスも減る」と話す。ユーザーは項目はもちろんのこと、帳票のレイアウトやデザインに強いこだわりを持っている。
さらに、ユーザーのデザインに対するこだわりは、現状の帳票開発の仕方では対応できないことがある。昨今はプログラムを組むよりも帳票開発ツールを活用することが多い。ツールを使えばユーザーの意見を聞きながら少ない手間で帳票を作成できるが、どんな要求にも応えられるわけではない。ユーザーが「Wordならチョチョイとすぐ直せる」と思って気安く出した変更要求が、採用している帳票開発ツールでは簡単に変更できず苦労する場合がある。
システム構築プロジェクトの終盤で発生する帳票の手直しは予定外であることが多い。大トラブルというほどではないが、開発者にとっては改善したい問題である。とはいえ、その問題を解決する特効薬はないのが実情だ。要件定義書や基本設計書に帳票の項目を盛り込むことはできるが、帳票のレイアウトやデザインの完成案を出すのは困難である。
開発者としては、レイアウトやデザインの問題が発生することを予想してスケジュールを立てること。そして、今後は文字・数字・罫線だけの帳票でなく、図・絵・画像を含んだデザイン性の高い帳票の要求が高まってくることを覚悟し、デザインに対して関心を持つべきだろう。
