すべてが順調に進んでいるうちはいいんだよね。問題はそうでなくなった時。「なんか作業が遅れてるな」とは分かっても、なんで遅れてるのかが分からない。得られる情報は出てくる個々の成果物と進捗報告。遅れている理由が分からないと、結局「急いでください」「頑張ってください」と言うぐらいしかできない。そんなんでうまくいくなら誰も苦労しない(笑)。
たとえば作業者がこちらが想定した方法を取っていないケース。本人はそのやり方が普通だと思い込んでるので、報告でも特にそれについて言及がない。こちらもまさかそんな方法をとってるとは思わないから、確認もしない。で、時間は流れ気づいた時には驚愕するわけですな。事実は小説よりも奇なり。
* * *
むろん作業者が常に悪いわけではない。実際のところソフト開発は初めて見ないと解決すべき問題が事前には想定しきれないことが多いから、発注する側が打ち合わせの時点では、そこまで考えていなかったということが多い。
その場合に「想定してなかったこういう問題が生じました」「だからこういう方法でやることにします」と報告があれば、スケジュールを調整するなり、「いや、別な方法でやってくれ」というなり、対処ができるのだけれど、独自の判断でやってしまう。
独自の…というのも語弊がある。独自のという自覚があれば、確認してくる。むしろなんの疑問も持たずに、ごく自然にやってしまう。上述のようにソフト開発は事前に生じるすべての問題を想定することができない。だから問題に突き当たれば解決方法を自主的に探し、何事もなかったかのように平然と解決する。プログラマはそれを日常的にやっているので、無意識にやってしまう。
* * *
これはなにも遠隔地での開発に限らず社内での開発でも同じなのだが、社内であれば雑談とかたまたま耳にする会話(あのライブラリってどこにあったっけ?とか)から、なにをやってるかわかることが多い。
んで、出てくるはずのない単語を耳にすると「おい、おまえ今なにやってんだ?」と突っ込むことになる。
* * *
別なケース。外注A社とB社を使っているとして、B社は作業上A社からのこういう情報がないと作業を進められないとする。B社はその旨を俺に伝え、俺は「なるほど、そうか」と納得し、A社に「こういう情報がほしい」と伝える。A社から情報が出てきたのでそれをB社に渡す。
ところが実際には情報が不十分だった場合。明らかに欠落している部分があるなら分かりやすいのだが、「説明が不十分」とか「曖昧な部分が多い」とかだと、なかなかどういう追加情報がほしいのかB社も伝えにくい。結果的にB社は不十分な情報で手探りのまま作業をするから、B社の作業が遅れていく。
でもB社の作業の遅れの原因が、A社からの情報不足というのが、なかなかわかんないんだよね。A社とB社の実際の作業者が「いま、こういう作業をやってて、この情報がほしいんですけど」「あ、なるほど、そこはこうなんです」みたいに会話すれば、一発で解決する。お互い一番詳しい人間同士なんだから、打てば響くようにトントン拍子で会話が進む。
ところが俺は実際に作業をしているわけではないから、そこまで細かなことはわからないんだよね。一生懸命B社がどういう情報が欲しいのか理解しようとするのだが、俺はその部分の作業だけを見ているわけではないので、どうしても理解が浅い。で、その俺が又聞きでA社に問い合わせるから、さっぱり要領を得ない答えが返ってくる。