同じ帳票を作るのだから、同じシステムが使えるはずだ。
そう考えていた時期があった。
農産物検査の帳票を作成するシステムを開発したときの話である。
農産物検査では、検査結果を記録し、所定の様式で帳票を作成する。提出先も決まっているのだから、必要なデータも集計方法も、おおむね共通しているはずだった。
会社ごとに違いがあるとしても、せいぜいExcelのどのセルに何を出力するか、その程度だろう。
一度作ってしまえば、ほかの会社でも使ってもらえる。
なかなか合理的な計画だったと思う。
少なくとも、作り始めるまでは。
実際に別の会社へ導入しようとすると、想定していなかった違いが次々に現れた。
検査依頼を受け付ける単位が違う。
ある会社では、特定のグループごとに検査依頼をまとめて管理している。
月次の締め処理も違う。
提出する帳票には、あらかじめ承認を受けた独自の様式が使われていることもあった。
そうなると、単にExcelの出力先を変更すればよいという話ではなくなる。
集計する単位が違えば、データを取り出すSQLも変わる。
場合によっては、画面の構成や処理の流れまで調整しなければならない。
同じ業界で、同じ目的の帳票を作っている。
なのに、システムの中身は同じにならない。
こちらが考えていたほど、世の中は単純ではなかったらしい。
当初はオンラインミーティングで業務の説明を受けていた。
ところが、話を聞くだけでは、なかなか実態を理解できない。
お互いに同じことを話しているつもりでも、頭の中に思い浮かべている仕事の流れが違っている。
そこで、実際に使っている帳票のコピーを郵送してもらうこともあった。
ITシステムの開発なのに、紙の帳票が郵便で届く。
もっとも、紙でなければならないわけではない。大切なのは、説明のために作られた資料ではなく、実際に仕事で使っているものを見ることだった。
それでも分からないところは、ひとまず画面を作ってみる。
そして、実際に確認してもらう。
「ここは、こういう使い方をしています」
そうした説明を聞いて、また修正する。
最初からすべてを理解して設計するのではなく、作りながら理解を深めていく。
技術者としては、もう少し格好よく進めたいところである。
しかし、格好のよい設計書が、正しい理解を保証してくれるわけでもない。
ソフトウェア開発では、共通化やモジュール化が重視される。
同じ処理を何度も書かない。違いは設定値で吸収する。変更に強い構造を作る。
もちろん、それらは大切な考え方だ。
だが、会社ごとに集計単位も処理手順も違うとなると、少々事情が変わってくる。
すべての違いを設定で吸収できるようにすることは、技術的には可能かもしれない。
しかし、そのために複雑な設定機構や汎用的な集計エンジンを作ることが、本当に合理的なのだろうか。
数社のために巨大な仕組みを用意するくらいなら、それぞれに専用のSQLを書いたほうが、開発も保守も簡単な場合がある。
共通化するための仕組みが、個別に作るより複雑になってしまっては、何のための共通化なのか分からない。
結局、顧客が増えるたびに、その会社の仕事を理解し、その会社に必要な処理を追加することになった。
横に広がるはずだったソフトウェアが、なぜか縦に伸びていく。
横に広がるなら、遠くなっても、ある程度は見通しが立つ。
ところが縦方向は、登ってみなければ次の段が見えない。
一段上がるたびに、それまで知らなかった業務が現れる。
それを理解して、新しい処理を追加する。
また一段、高くなる。
顧客が増えるほど、システムだけでなく、それを理解するために必要な知識まで積み上がっていく。
最初は横展開できる製品を作っていたつもりだった。
いつの間にか、自分でもてっぺんが見えないものを作っていた。
同じ業界なのだから、業務の進め方を統一すればよいのではないか。
そう考えることもできる。
しかし、会社ごとの業務手順には、それぞれ事情がある。
長年の取引関係、社内の役割分担、過去に決めた運用方法、外部との取り決め。
それらが積み重なって、現在の仕事の形になっている。
もちろん、見直したほうがよい部分もあるだろう。
ただし、業務を変えるということは、システムの設定を変えることとは違う。
変更を決定する権限が必要であり、その結果に対する責任も生じる。
外部の技術者が、少し話を聞いただけで「この仕事は非効率なので変えましょう」と言えるほど、簡単な話ではない。
だから、まずは今の仕事を理解する。
改善の可能性は否定しない。
しかし、改善することを最初から目的にすると、今ある仕事を理解する前に、変えるべきところを探し始めてしまう。
それでは、見落としてしまうものがあるかもしれない。
振り返ってみれば、最初の見立てが甘かったことは間違いない。
同じ帳票を使うのだから、同じシステムで対応できる。
その前提を、十分に確かめていなかった。
では、最初にもっと詳しくヒアリングしていれば防げただろうか。
ある程度は防げたかもしれない。
しかし、実際の帳票を見たり、画面を作って確認してもらったりして、初めて分かったこともある。
使う側にとっては当たり前すぎて、説明する必要を感じないこともある。
開発する側は、その当たり前を知らない。
だから、作ってみる。
違っていたら、直す。
その過程で、ようやく互いの理解が近づいていく。
思えば、私は最初から「同じもの」を探していた。
同じ業界。同じ検査。同じ帳票。
だから、その途中にある仕事も同じだろうと考えた。
けれど、実際には会社ごとに違う手順で依頼を受け付け、違う単位でデータをまとめ、それぞれの事情に合わせて処理をしていた。
その結果として、同じ目的の帳票にたどり着いていたのである。
同じ帳票を作るのだから、同じシステムが使えるはずだ。
そう考えていた私は、少々思い違いをしていたらしい。
共通だったのは、入口ではなく出口だった。
このコラムは、実際の開発経験とAIとの対話をもとに構成しています。文章の構成と執筆はAIが担当しています。