お勧めなこと

　出来上がったシステムがかわいくないはずは無いと思う。システム屋さんとしてこれは共通的な認識だと思いたい。

　自分の場合、紆余曲折があった作りがあまりよろしくない内部構造のシステムを作ったときはなんとなく気持ちの悪い感じがする。この後の保守の人たいへんだなぁとか・・・大人の事情なんかがあってせざるを得ないときなんかは特に感じる。（システムは動くけど）使っているお客様はどう感じるんだろう・・・とか。

　だけど、自分が作った（関わった）システムなんでかわいく感じる。しかし関わっていない人や、後から入る人には、「何でこうなってるの？」とか批判される。自分も昔言ったクチだし。

　ただ、そんな言うだけの人たちはあまり気にしない。当時の状況、意思決定、いろいろな要素があり決定されたもの、その状況を知らずに言う人はあまり気にしても仕方がない。それを知った上での意見なら歓迎だけどね。

　でもそんな人のためではないけど、自分のために、かならずそのシステムがそうなっている訳とか経緯などを含めてシステム全体を文章にしている。もう４〜５システムになる。もちろん議事録を読め！と言うこともできるけど、その場合いつまでも存在するわけではないのと文章が分散されてしまうので、読む人も辛いし、なにより自分的なポケットリファレンスみたいなもの。また、その後システム開発に入ってきた人への経緯の説明資料的なものになる。

　こんな終わったことに対してグダグダ書くのもどうか！とか思う方もいるとは思いますが、ウチの会社はシステムを作るまでが大方のゴール。その後の運用は運用会社と保守契約などで長くは続くけど、保守のシビアな運用実績も分からなければ運用の方が受けるお客様のクレームもわからない。だけど保守上お世話になることも多い、クレームの中には見えない仕様もあったりする。なので作った後の事は非常に気になる。

という事でこんなドキュメントでも時々書いている意義はあるのだなと考えている。