「全部のせ」を作るのはつらい

 情報システムをつくる際、利用者からの要望を聞きとっていると、ともかく色々なデータ出力形式に対応できるようにしてくれ、という話になりがちだったなあと筆者は記憶します。

出力形式、と固めに表現してみましたが、もっと具体的に言い直せば、帳票やラベル印字の形式とか、どこか他のシステムに投入するためのデータフォーマットのことです。とくに帳票なんかは、公機関で定められたようなフォーマットがたくさんあるために、ユーザー側の選択次第でどのフォーマットにも正しくデータが転記できる、という仕組みを作ることを求められます。

それらの出力形式のうちいくつかはとても頻繁に使われ、いくつかは年に数回の出力頻度だったりします。また、ちょっとしたルール改変でフォーマットに微妙な変更があると、そのつど、それに対応するためのカスタマイズが発生します。

大きな基幹システムのイチ機能、としてこれらの出力機能を捉えるなら、これらはみんな、そのシステムの改修あるいはカスタマイズということになり、たぶん大きなコストを払わされることになります。開発業者の側としても、もとの大きなシステムと同じようなサポートをこの改修部分に対しても行わないといけませんから、当然、それなりの費用を請求せざるをえないのです。

もしも、利用者側のほうで、基幹システムからはそれなりに再利用できるデータだけを得られればいいよ、といえるのなら、今挙げたような悩みはかなり軽いものになります。基幹システムとは別に、データの利用方法のひとつとしてユーザー側で勝手に工夫するから大丈夫、と考えることができるなら、そうなるでしょう。ちょっとした印刷位置の修正や文言部分の修正とか、年号が変わったのでそこらへんの対応をするとか、そういった微調整の自由を得ることができるわけです。

「いいや、ユーザー側でそんな器用なことはできないよ」という意見がすぐに聞こえてきそうです。もちろんこれもその通りで、できないからこそ、実装業者にこれを作ってもらっているわけですもんね。

ユーザー側で帳票作成くらいの作業ならできるかも、という幸運なことも、時にはあるかもしれません。実際のところ、ちょっとしたプログラミングができるなら、データを帳票や別形式のデータに変換するようなことは、多少のセンスがあればやれる程度の仕事だと筆者は考えます。ただし、その器用な人物がいなくなったあとで、誰もコントロールできない謎の仕組みが残されてしまう、ということも、また起こりうることです。器用に作ったとはいってもプロの仕事ではないのですから、それを改めて実装業者に渡し、これを今後サポートしてくれ、と言うのは難しいでしょう。

基幹システムのカスタマイズなら高くなるし、内輪だけで試行錯誤で作ってみた仕組みでは後が続かない、というジレンマです。

これを解消するのは、仕組みの文書化、それもできるだけ詳細な文書化であると筆者は考えています。基幹システムに頼らない仕組みで帳票出力の仕組みを作ったいきさつ、それのために選定した技術、実装方針、仕組みの操作方法、そして、このために作ったプログラムがあるなら、それのすべての部分について、何のためにこの行を書いたかというコメント。つまり、困ったときは、別のプロ開発者に向けてこれを見せれば詳細がすっかり伝わる、というレベルまで整えられた文書です。

「ではその文書を作ってくれるのは誰なのか」と問われれば、実際のところ、訓練による、としか言いようはないのですが…　ともあれ、ここでは、自力でプログラムを作って何か仕事を便利にしよう、という気概には大いに賛成しつつ、それを誰かに説明できる言葉で文書に残しておこう、という準備も同じくらいに重要なのだ、ということを述べておくまでです。