バッドノウハウカンファレンス開催

bricklife.weblog."世界初？「バッドノウハウカンファレンス」開催決定"
覚えたくないけど覚えなきゃいけないノウハウである「バッドノウハウ」に関するカンファレンスが、Shibuya.pm 主催、高林さん共催で開催されるようです。

参加エントリしてみました。こういったカンファレンスに参加するの初めてなだけに、どんなが人達が集まるのか楽しみです。良い刺激を受けられる事に期待。

高林さんのバッドノウハウ記事より
計算機を使っていると、何でこんなことを覚えないといけないのだ ろうか、とストレスを感じつつも、それを覚えないとソフトウェア を使いこなすことができないためにしぶしぶ覚えなければならない、 といった類いのノウハウは多い。そうした雑多なノウハウのことを、 本来は知りたくもないノウハウという意味で、私はバッドノウハウ と呼んでいる。

なるほど... 自分の仕事環境でもすぐに幾つかそれらしい事例が思い浮かびます。自分の周囲限定で考えると、それらにあてはまる共通点としては「昔に作られたシステム／仕組みであること」と「皆からの評価が高いこと」の２つ。10年前に開発されたシステムで、その当時に高い評価を受けた為、今でも使いつづけられている...　って事です。10年経った今でも、昔の仕様そのままで動いているので、今となっては「何でそんな仕様？」みたいな事を幾つも覚えないと扱えない。例えば：

　【10年前】ネットワークの転送速度が今と比べて極めて低かった
　【10年前】なので転送するデータは出来るだけ容量を減らす必要があった
　【10年前】他システムとのインターフェースファイルはアスキーデータでなく、バイナリデータで持つ

　【現在】ネットワークの転送速度は極めて速くなった
　【現在】転送するデータの容量にそれほど神経質になる必要がなくなった
　【現在】でもインターフェースファイルはバイナリデータのまま

10年前の経緯を知らずにこのシステムに初めて触れる者にとって、「何故バイナリデータ？統合テストしづらいんですけど」みたいな嫌悪感の対象になるわけで。でも以後10年の間に作られてきた周辺のシステムも皆、バイナリのインタフェースファイルを取り込む前提で作られていたりして、そうやすやすとファイル形式を変更するわけにもいかず...　みたいな。こんな事例もバッドノウハウの一例なのかな？と思います。

自分の仕事環境にはそんな悪しき仕様が幾つかあって、偶然にも 自分自身の向こう半年の目標が「これら悪しき仕様を改善して、使いやすい／開発しやすいシステムにしていこう」みたいなものだったり。対上長に申請したコミットメント目標なんだけど。そんなに乗り気でもないのだけど（/w）。