プログラマが騒ぐ時

あるシステムの開発プロジェクトにおいて、実装を任されているプログラマがいるとしよう。そのシステムでは、他のシステムのサーバとの通信を行なうことが必要あり、プログラマは、そのサーバとの通信部分を実装しなければならない。サーバとの通信仕様は曖昧で仕様書や資料を見てもよく解らないし、周りに聞くが誰も事実を知らないようだ。仕方が無いのでサーバ側の人間にお願いして、実際にサーバにアクセスしている、他のシステムのプログラムのソースコードを送ってもらい、独自に調査を開始する。
こうして細かいサーバとのやりとりはある程度判ったので、プログラマは実装を開始した。実装はほぼ期待通りの仕様であり(調べたので当たり前だ)サーバとの通信部分は問題無く動いた。

よくいる立派なプログラマのケースだが、この進め方は駄目だ。

サーバとの通信の方法を知っているのは、プロジェクトメンバ中あなただけだ。おそらく今後も、未来永劫そうだろう。

仕様が曖昧だったり、不明だったりした事が判ったら、気を効かせたつもりで(ひょっとしたらそのように期待されているかもしれない)自分だけで進めてはいけない。プログラマはそこで一度騒ぐべきだと思う。騒いで、一度仕様が明確になっていないことを訴えてプロジェクトの中で問題として採りあげてもらうべきだ。その結果プログラマの仕事が増えるかもしれないし、実装に詳しくない人が解るような、平易な書き方でドキュメントを書くように、と命じられるかもしれない。でも、それは最初から必要だった作業である。そうしないと、プログラマはその会社を辞めない限り、そのシステムのサーバとの通信の担当であり続けるだろう。