手順書に仕事ぶりが現れる

 ここ1週間弱ぐらい、あるプロセスを別のプロセスからAPIを使って制御するみたいなことをやっていた。単なるプロセス間通信ではなくてもうほんと同じプロセスの関数みたいに叩けるやつ。しかも酔狂なことにOS間通信をそれでやるってんでものすごい。
 やり方にも複数あって、今回はCommon APIともう一つ別の方法の性能を比べるということがミッション。んで、Common APIの方を1週間弱ずっとやってたのだけれど、にっちもさっちもいかない。外注さんが前期に納品してきたテストプログラムを使っているのだけれど、なぜか通信できない。QAを出すもそっけない上、次から次へと新たな手順でてくる。と言っても手順書は存在しないので空気を読んで自分で手順を確立している。ソースコードが間違っていてそのままじゃビルドも通らない。これを納品してきた外注さんはちょっと僕たちを舐めすぎだと思う。と思ったら他社さんからもQAきたよ。ほらー、みんなできないんだってこれ。ふざけろ。ということで本格的に問題になってきたのでひとまず外注さんが解析と手順確立で火を吹いてる。ついでに僕の方も解析してくれるって。ありがたい。いや、よく考えたら当然のことなのだけれど。
 その間に。別の会社が出してきた方の方法でプロセス間通信の測定を開始。こちらは手順書があり、多少行間を読む必要があったけれどもすんなりとできた。可変のデータをAPIに乗せて叩くとプロセス間で自由に送信できるようになった。これは気持ち良い。試しに10Mのテキストとか送ってみる。意外と早い。もうこっちの圧倒的な勝ちじゃね? 手順の容易さから見ても、仕事の丁寧さから見ても。
 できる会社は手順書で分かると思った1週間。手順書はきっちり書きましょう。さもないと信用を失うことになる。まあ前者は手順書すらないけど。論外ですわ。

コメントを残す

メールアドレスが公開されることはありません。