専用ツールと汎用ツールのはざまで

最近検査ツールを作っている。どのようなツールかといえば、端末の中の状態をリモートから取得し、その状態が想定通りなのか確認する検査ツールである。

過去の問題点として、検査ツールを「いろんな人が都度作成する」という問題があったため、過去の検査項目をパターン化・共通化し、パラメータ設定するだけで検査可能とする。設定だけで検査不能なパターンが新たに発生した場合は、検査パターンを追加すればよいという設計にしてリリースしたのだった。

検査ツールは社内にそれなりに広まっており、バグ報告や、検査パターンを増やしたいという要望や、この検査はどのようなパラメータで実装すればよいかといった相談が増えてきており、ツールとして成長してきたところに「既存の検査ツールを本ツールに置き換えたい」という要望があった。既存ツールは検査の都度、新たにコーディングが必要であって、そのコーディングが作成者しかできない、さらにその作成者の退職が間近に迫っているという問題意識から発生した要望であった。その相談の打ち合わせに参加したところなかなかの経験をした。既存ツールの作成者がやたら突っかかってくるのだ。

既存ツールでできるが、こちらのツールでできないことを非難してくる。いやいや、この打ち合わせは「フィット&ギャップ分析」の場であって、ギャップを非難する意味はあるのか?ということを言ってもなんだかんだ言ってくるので、既存ツールの問題点を指摘したところ相手の態度が硬化した。要は「自分のツールの優位性をアピールしたかった」だけなのだろう。ということで、絶賛喧嘩中な感じだ。

既存ツールの問題点はわかりきっている。属人性が高く、条件が変わるたびにコーディングが必要なところだ。さらに言えば「素人プログラムなので移植性と可読性に欠けている」ところも問題だ。一方、長所もわかっており、利用者の意見を取り入れたカスタムがやりやすいところが長所といえる。

こちらのツールは既存ツールの全く逆で、属人性が低くなるが、即時性のあるカスタムは難しい。

汎用SWと専用SWには常に同様の関係性がある。設定で大体のことができるけれども、小回りが利かない汎用SWと、設定変更でできることは極めて限られているけれども、限られた範囲では最大のパフォーマンスを発揮してくれる専用SW。どちらが優れているのではなく、使用する場面で優劣が変わる。

ということを理解していない人とのやり取りはめんどくさいなあと思った次第であった。