リモートワークのネック

今回はメカAGさんのブログからご寄稿いただきました。

リモートワークのネック

ひところ外注会社を複数使ってソフト開発をしてたので、その時の経験を書いてみる。まあやったことのある人なら誰しも感じることで特に目新しい内容ではないと思うけど。

すべてが順調に進んでいるうちはいいんだよね。問題はそうでなくなった時。「なんか作業が遅れてるな」とは分かっても、なんで遅れてるのかが分からない。得られる情報は出てくる個々の成果物と進捗報告。遅れている理由が分からないと、結局「急いでください」「頑張ってください」と言うぐらいしかできない。そんなんでうまくいくなら誰も苦労しない(笑)。

たとえば作業者がこちらが想定した方法を取っていないケース。本人はそのやり方が普通だと思い込んでるので、報告でも特にそれについて言及がない。こちらもまさかそんな方法をとってるとは思わないから、確認もしない。で、時間は流れ気づいた時には驚愕するわけですな。事実は小説よりも奇なり。

　　　*　　　*　　　*

むろん作業者が常に悪いわけではない。実際のところソフト開発は初めて見ないと解決すべき問題が事前には想定しきれないことが多いから、発注する側が打ち合わせの時点では、そこまで考えていなかったということが多い。

その場合に「想定してなかったこういう問題が生じました」「だからこういう方法でやることにします」と報告があれば、スケジュールを調整するなり、「いや、別な方法でやってくれ」というなり、対処ができるのだけれど、独自の判断でやってしまう。

独自の…というのも語弊がある。独自のという自覚があれば、確認してくる。むしろなんの疑問も持たずに、ごく自然にやってしまう。上述のようにソフト開発は事前に生じるすべての問題を想定することができない。だから問題に突き当たれば解決方法を自主的に探し、何事もなかったかのように平然と解決する。プログラマはそれを日常的にやっているので、無意識にやってしまう。

　　　*　　　*　　　*

これはなにも遠隔地での開発に限らず社内での開発でも同じなのだが、社内であれば雑談とかたまたま耳にする会話(あのライブラリってどこにあったっけ？とか)から、なにをやってるかわかることが多い。

んで、出てくるはずのない単語を耳にすると「おい、おまえ今なにやってんだ？」と突っ込むことになる。

　　　*　　　*　　　*

別なケース。外注A社とB社を使っているとして、B社は作業上A社からのこういう情報がないと作業を進められないとする。B社はその旨を俺に伝え、俺は「なるほど、そうか」と納得し、A社に「こういう情報がほしい」と伝える。A社から情報が出てきたのでそれをB社に渡す。

ところが実際には情報が不十分だった場合。明らかに欠落している部分があるなら分かりやすいのだが、「説明が不十分」とか「曖昧な部分が多い」とかだと、なかなかどういう追加情報がほしいのかB社も伝えにくい。結果的にB社は不十分な情報で手探りのまま作業をするから、B社の作業が遅れていく。

でもB社の作業の遅れの原因が、A社からの情報不足というのが、なかなかわかんないんだよね。A社とB社の実際の作業者が「いま、こういう作業をやってて、この情報がほしいんですけど」「あ、なるほど、そこはこうなんです」みたいに会話すれば、一発で解決する。お互い一番詳しい人間同士なんだから、打てば響くようにトントン拍子で会話が進む。

ところが俺は実際に作業をしているわけではないから、そこまで細かなことはわからないんだよね。一生懸命B社がどういう情報が欲しいのか理解しようとするのだが、俺はその部分の作業だけを見ているわけではないので、どうしても理解が浅い。で、その俺が又聞きでA社に問い合わせるから、さっぱり要領を得ない答えが返ってくる。

　　　*　　　*　　　*

ペアプログラミングというものがある。一つのソースコードをプログラマ2人で一緒にコーディングするというものらしい。俺はこれに否定的だけれど、そもそもペアプログラミングは現場での作業をヒントにしてそれを形式化したものだ。

実際に通りがかったプログラマが何の気なしに、別なプログラマがプログラミングしているのを後ろから見てることはあるだろう。仲の良いプログラマ同士だと「へー、いまこんなことやってるんだ」と、そこから会話が弾む。

この会話は有益なことが多い。「ああ、それならこういう方法があるよ」とか、「そこはいくら頑張っても一人じゃ無理だから、ちょっとリーダーに相談して、全体の構成から見なおした方がいいよ」とか。プログラマ同士の雑談というのは、世間一般の雑談とは一味違う。余分なものを排除した、ある意味非常に高密度な会話。初心者ほどこれに助けられるはず。

うまく回っているチームというのは、こういう部分に支えられている事が多い。遠隔地だとこれができないんだよね。一人で悩んだ末に、すごい無理な方法でなんとか解決しようとして、結局スケジュールは遅れ、解決方法もいまいちで作り直し…とか泣きっ面に蜂。

　　　*　　　*　　　*

んで、こういうことをさんざん経験した熟練プログラマなら、遠隔地での作業も可能ではある。過去の経験で「これは、密に打ち合わせをしないと大変なことになるパターンだ」と直感でわかるから、躊躇することなく問い合わせてくる。んでことなきをえて、「早めに手を打ててよかったですね、さすが○○さんです」とかなんとか。

この「やばい」という感覚が大事。それは過去の苦い経験が育てたものだ。以前も書いたけど、自分でプロジェクトリーダができるぐらいのレベルの人なら、遠隔地での作業もできる。でも経験がそれよりも下だと、危険だね…。

執筆：この記事はメカAGさんのブログからご寄稿いただきました。

寄稿いただいた記事は2014年03月19日時点のものです。