Whiteのふりーとーく

ツールと情報

本当は完了していなければならないが値引きのために何かが粉飾された見積書通りに事が進むはずはなく勿論絶賛進行中、なプロジェクトにおいて影舞をひょいと使ったら叱られた。具体的には自分の責任範囲を越えた(実装の問題ではなく仕様に関わる)判断をしてそれを(客も見ている)バグ追跡システム(BTS)に流した、ということについて軽いお咎めを受けたわけだが。

_別にそこで叱られたことが云々というわけではない(実際領分を越えて行動してしまったわけなので仕方なかろう)。が、そこでBTSに流すことが困る、と言われるのはどうなのだろう、とは思う。

_迅速に修正・対応を実行しつつも、それに伴って発生する情報の齟齬を埋める、という意味ではこの場合BTSは正しく機能した(実装者が判断を行いそれを報告した→実装者が領分を越えた判断を行ったという「バグ」が発見された)わけで、そういうのを洗い出しつつも対応の速度は確保する、ためにBTSというものが使用されてるんじゃねえのか、とか思う。

もちろん理想は「一元化された情報が迅速に流れる」ことだろう。しかし現実はそううまくいかない。だから「とにかく迅速に流した情報をなんとか一元化」するためにBTSというものがある。ゆえに「一元化してからBTSに書き込もうよ」というのはBTSの使いかたとしてはどうなのだろうか、と思うわけだ。多少錯綜してでも迅速さが必要だからBTS、なわけで、そこで錯綜を0にしたいならそもそもBTSなぞ使わないか、あるいは内向きのBTSと外向きのBTS分けてモデレータが人手でブリッジさせるべきだろう。まあそれは非常に面倒だから一本のBTSなのだけれど。

_確かに体面は大事であんまり内部で錯綜するのをお客さまに見せちゃうのはまずいというのもわかるのだが。だからと言って迅速な対応を求められているものをこっちの体面を理由に遅延させるのは本末転倒でもある。

…実はどうやって客の信頼を得るか、客を含めた開発・対応チームを作っていくか、という話でもあるのか。ということで、システムを作るのは常に「システムを作るためのシステム」なのだ、といういつもの結論に至る。したがってまとまらないままこの段了。