「この部分の設計資料はありますか？。」
と、ある方から尋ねられた。設計資料はないが管理書はある。というのも、このシステムを作ったのは私じゃないからだ。いろいろな経緯で引き継いだだけだからね。初代に構築した人が作った古い設計書はあるんだが、もう随分サービスインから時間も経っていてしかもたくさんの変更を行っている。元々の設計資料の内容は風化しているし、私の手元に来た時にはすでに歴史上の書物であった。
そんなシステムでも私の範疇に来た以上はしょうがねぇなぁと思い、私の代で今あるシステムを見ながら管理書を作り、今まさに管理しなければいけないポイントをまとめることにした。現代のソフトウェアはかなり複雑になっていて、すべてのパラメーターを全部設計書に転記するなんてナンセンスだ。デフォルト値がそもそもよくできていて、それらはありがたく使う。変更が必要なものだけを把握しておけばよく、それを管理書にまとめた。それで足りなかったとしても、後の細かい情報は、もう直接動いているソフトウェアを確認すればいいじゃないか。
関係者の意思疎通するためのメディアとしての管理資料。細かい情報はまるっとソフトウェアのバックアップを取りつつ、現時点の動いているそのものを確認する。
最近はもうこの管理方法こそがモダンだ、と思い込んでいたんだが、そうじゃない方もまだ存在するようだ。きっと、大規模構築プロジェクトで、すべてのソフトウェアはすべてExcelやWordで文書化しなければならない、という縛りを背負ってしまった人なんだなと推察。そういう場所もあるだろう、世界には（私はごめんだけど）。
あるソフトウェアがパラメーターの塊だとして、その塊をExcelに書き写すことって何か意味があることなんだろうか。それが設計資料というのだろうか。誰がその成果物を使い、そして最新化し続けられるのだろうか。
もはや、そんな設計手法を取ったら、複雑極まりないソフトウェアをどうExcel化するかの工数だけで構築時に大幅に料金が膨らみ、大した品質もないのにやけにお金がかかるみたいになって当然だろう。だって、書き写すことに何の価値がある？。しかもそのパラメーターは運用しながらどんどん変わるし、変わった内容をすべて把握することなど、人間ではできない量と複雑さなんだから。
カスタマイズした差分が大事なのであって、それは、文書化すればよいだろう。なんでまた、全体が書かれた資料が存在し、最新化されていくと思うのか。
これはもう哲学なのかもしれない。「あなた」という人格を実装したソフトウェアがあるとする。あなたの設計資料はあるか？。とりあえずは履歴書や職務経歴書などで、文書化することはできるだろうが、すべてを言語化すること自体が無駄だというのはわかるだろう。その文書は、必要な情報を書き出したに過ぎないのである。
必要なのは、必要なことをまとめることであって、世界をすべて言語化することじゃない。それを設計とは言わない。
