仕様という魔物

仕様というのは何か。
今回は結論を先に述べておくことにすると、双方の取り決めごとであって、お互いの接点である。いや、そういう前提で物事が進んでいたというのを仕様という。

昨日のトラブルはある機械との通信仕様の相違によって引き起こされた。その機械の担当者とのやり取りでは、 Windows によるファイル共有でファイルのやり取りをするという取り決めであった。
接続試験に備えて、実物を見た際にその担当者と話をすると「前提」が違っている。 FTP を使う仕様だと言う。私なら、その時点で「おい、話が違うやないか」と言ったであろう。
今回のトラブルは特にそれ以上の問題を引き起こさなかった。この経緯は最後に。ここまではよくある話である。仕様違いというのはよくある話なので、改めて取り上げる。
今回取り上げる問題はここからの人それぞれの対応である。

私たちの業界では、技術部門が客先に出ることが多い。営業上の話とそれを実現するための現実問題とのギャップが激しく、ギャップを緩和する客との距離も少ないからだ。ギャップの問題もよくある問題なので、後で取り上げるが、今はその話を聞いた人が起こす行動についてである。

その仕様の違いを聞いた者としては、この手の仕様の食い違いを埋めるのには二通りある。

技術屋: 言われた通りに作り直す
七面倒な経緯の確認より、それにあわせて作り直した方が早いというパターン。技術を持っていて、話が面倒という人に多い。違っていると聞いて、仮に全くそれまで聞いたこともない仕様を聞いても、それを実現する手段は持ち合わせているので、ともすれば感情に流される話に小一時間か付き合うより、作ってしまえと思うわけである。
この場合、問題は作り直すのに必要な時間である。その仕様の食い違いの程度と技術者のレベルが折り合えばうまくいく。
食い違いがひどいほど時間がかかるし、技術屋のレベルが低いほど時間がかかる。この判断が実は技術屋には出来ない場合が多い。
技術としてはできるのは判っている。と、思った時点で、もう、出来たつもりになってしまう。それにかかる時間を忘れがちなのだ。
このような技術屋を抱えたなら、その人が高レベルな技術者であろうとも、バランスを判断して抑える人が必要である。後で恨み言は聞くだろう。言った通りしていればもっと早く済んだと。
でも、それは賭けであり、確実性に欠ける。今欲しいのは指定時間までにあがる実績である。技術屋がそれを受け入れない限り、バランスを持った判断は出来ない。判断をする人は別に必要で、それこそ、小一時間ほどそのことに関する説明を食らわせれば技術屋は黙る。その話自体が面倒であり、聞く耳をそもそも持ち合わせていないからだ。
作業屋: 困る
天変地異が起きたかのように固まるパターン。技術は持っていないが、言われたことを時間内に確実にこなす作業屋に多い。作業屋にとっては想定外のことは存在しないのが前提である。自分の能力を推測しながら計画性を持って作業をスケジュールできるからこそ、決まった仕様に則って、確実に動くようにしたものを覆された日には、心中穏やかではない。かといって、そこから何をすべきか困るのである。
ここで問題になるのは作業屋の話術である。
仕様というのは取り決めであると述べた通り、その場で取り決めが変更される可能性があるのだ。ここで作業屋が黙っていると相手の話術次第で、もともとなかったはずの取り決めが増えることは明らかである。
ここでは、作業屋は何があっても突っぱねないといけない。そういう作業を確実にこなすべきである。でないと、さらに作業が増えるぞと脅してやるとよい。判断自体を恐れていることが多いので、自分の勝手な判断で作業が増えるとなれば黙るはずだ。

非常にざっくりと二分したが、仕様の食い違いの成り行きに関しては、大方がこの二つを対極とした線上に乗るであろうと思われる。なるほどと思われた方がいれば、ぜひ、プロジェクトマネージャとして迎え入れたい。その両方を理解することができるなら、そのバランスも判断できるであろうと思うからである。

私自身は技術レベルはなくとも性格としては前者であり、それこそ勝手に突き進む方なので、抑えてくれる人が欲しい。

今回の作業担当は技術屋であった。よって、採った行動は前者である。仕様の食い違いに気付いたのは接続試験の一日前。機械の搬入が終わった時点で設置環境を見に行ったところ、先方の担当者との話で仕様の食い違いに気付いたわけである。
彼は気づいたとたんに戻ってきてコーディングを始めた。しかも、これまでどの顧客にも提供したことがない機能を半日で仕上げた。接続試験も滞りなく進んだ。彼は、大満足である。
しかし、これは賭けであって、しかもかなり大きい賭けであった。プロジェクトマネージャは気が気で仕方なかったはずだ。一度も経験していない機能を試験の直前まで製作していて、仮にもうまく行かなければどうする。もう、既に期限は来ているので今回は賭けたが、結果オーライであり、よくはないと呑みに連れて行かれた先で言っていた。
そのあたりまで予測のつく管理ができればそれに越したことはないが、基本的に人手不足の状態であり、技術屋の技術力を計りながら、肝を冷やしながらのシステム作りがまだまだ続く。
今回のトラブルは私自身にも他山の石とすべきトラブルであった。

仕様という言葉に戻ると、始めにお互いの接点だと述べた。表現する時には点であるということに注意していただきたい。線、あるいは面ではないのである。その点が外れてしまえば、もう接していないのである。接していないのであればどこに行くかは判ったものでない。少し時間をかけてでもお互いが納得できるものに仕上げることが、後の面倒を起こさない基であるのを再認識すべきだと思った次第。

[←PREV] [↑HOME] [↑UP] [→NEXT]