読者です 読者をやめる 読者になる 読者になる

megamouthの葬列

長い旅路の終わり

沈黙のプログラマ

プログラマのための練習曲

プログラマと言えば寡黙、というイメージがある。

実際のところ、彼らは寡黙というよりはプログラム以外の話をするのが苦手なだけで、専門分野について話を始めると、こちらが驚くほど饒舌であったりもするものだが、アルゴリズムの計算量の話をしない普通の人間にとっては、無口な人に見えてしまうのも無理はない。

また、彼らは作業中に話しかけられることを嫌う。プログラムという作業は集中を要する仕事であって、その最中に電話や会話で作業が途切れると集中が切れてしまうからだ。作業中のプログラマに簡単な用事を口頭で伝えようとして露骨に不快な顔をされた経験のある方も多いと思うが、そのへんの自制心のなさもプログラマの特徴であるので、プログラマとはとかくコミュニケーションを取りにくいという印象がある。

しかし、システム構築においては、このコミュニケーションの不足が致命的な事態を招くことがある。


知り合い伝手で、その仕事の話が来たのは5月の中頃で、内容は、週に2,3回出社して、現地で構築されているPHPJavascriptで作られたシステムのテスト、バグフィクスを行う、というものだった。報酬は安かったが、内容としては楽な部類に入るし、その時期、他にめぼしい仕事もなかったので、私はそのプロジェクトに臨時に参加することになった。

その会社は建設工事の施工管理を行う会社で、工程ごとの事務作業を効率化するシステムを自社内で構築していたのだが、プロジェクトのメンバーは人材派遣会社から来たという常駐の中年プログラマ一人だけで、ディレクターと言うか、制作管理を行っているのが、この会社の事務部門の課長だった。
彼はシステムについて特に専門的な知識を有しているわけではなかったので、ようするにプログラマーと素人のクライアント二人だけ、という体制でシステム構築を行なっていたわけだ。ある意味アジャイルである。

納期は遅延気味で、というより、はっきりとは言われなかったが、年度末が当初の納期だったのに違いない。5月中旬の現在は、とっくに納期が過ぎている状態で、事務部門の課長は、進捗遅れの理由すらつかめないようで、すっかり憔悴していた。

プログラマの隣の席をあてがわれた私は、早速、現場の先輩である彼に慇懃に挨拶した。彼はこちらを横目でちらりと見ると、「ふん」と鼻を鳴らして、キーボードを叩き続けた。
サポートとして雇われたフリーランスの私のことを特にありがたいとも思っていない様子だった。事前に課長から「彼は(有名なSIer)の出身なのでね」と半ば誇らしげに言われたことを思い出した。

こういう対応には慣れているので、テストサーバーのアカウントや、実行環境など、必要最低限の情報を彼からメールで聞き出すと、さっそくシステムを動かしてみた。とは言っても、仕様がわからないので、何が正しい動作なのかよくわからない。私が困惑していると、「ふん」とプログラマが分厚い紙の束を差し出した。

システムの仕様書だった。Excel方眼紙で作られたと思しきその仕様書は、大手SIer出身の彼らしく、完璧に作られていて、最初に改版履歴のページがあり、システムの各画面にはIDが振られ、Excelアートで書かれたワイヤーフレームの下にはその画面でのUI動作がシステム屋文体で記述されていた。
さらにすごいのは、ご丁寧にもページの右上隅に各担当者(といっても、そのプログラマと課長だけなのだが)の承認の判子を押すスペースが設けられており、全ページに渡ってきちんと2つの判が押されているのだった。

私は少し辟易しながらも、仕様書を見ながらテストを始めた。

どうも課長とプログラマはかれこれ1年近くこのシステムを構築し続けているらしい、ということがわかってきた。PHPのほうはCakePHPフレームワークを使った無難な作りだったが、フロントエンドは、高価な商用Javascript UIフレームワークを使っていて、まるでPCのデスクトップのようにブラウザの画面にアイコンが並んでおり、それをダブルクリックすると、その機能のウィンドウが開く、というような操作感を実現していた。ご丁寧にタスクバーまで実装してあった。

正直なところ、実現すべき要件と比較して、過大なUIだし、もっと言えば、ブラウザの中にPCのようなデスクトップがあるというのは、まるでリモートデスクトップのようで、あまり使いやすそうなUIとは思えなかったが、プログラマはそれを気に入っているらしく、この段階で助言や文句を言ってもしようがないので、私は黙々とテストを行った。

バグをいくつか見つけた。
本来はバグフィクスも私の仕事なのだが、一度私がソースのレポジトリにコミットしようするとプログラマが露骨に不機嫌になったので、面倒くさくなった私は、明らかなケアレスミスの場合のみ、メールで差分パッチを送るぐらいにして、あとは、なんとなく彼が気に入りそうな書式でテスト仕様書とテストマトリックスをそれっぽく自作してみたり、バグレポートを完全な悪ノリで無意味にExcel方眼紙で作って彼にメールしたりした。


1ヶ月ほどたつと、システムのバグもあらかた無くなってきたように思えた。私が課長にそう報告すると、一刻も早くシステムをリリースしていたがっていた課長は、すぐに現場のスタッフにシステムを紹介する説明会をセッティングし始めた。

プログラマは、よくわからない理由をつけて、説明会を行うことに最後まで難色を示していたが、「かれこれ1年もこのシステムを作ってもらってるんですよ。さすがに成果を見せんといかんのです」と課長が焦燥に駆られた表情を浮かべて諭すと、渋々了承したようだった。


かくして、広い会議室に現場のスタッフが集まり、工程管理システムのお披露目が始まった。
私も発表側の末席に座り、PCとプロジェクタの接続などを手伝った。

「かなりの難産となりましたが、ようやく工程管理システムのベータ版が完成いたしました。ここで、現場の皆さんに操作方法などをレクチャーさせていただきたいと思います」

マイクを持った課長が厳かに宣言する。次にマイクを渡されたプログラマが仕様書をめくりながら、プロジェクターに実際の画面を映し出しながら説明を始めた。

スティーブ・ジョブスiPhoneのプレゼンを100点とするなら、この発表は0点かそれに近いものだった。何故なら、彼はシステムの利点や利用シーンごとの操作方法といった一般的なプレゼン手法を全くとらず、仕様書に出てくる順にデスクトップアプリ風の画面を開き、そこにどのような機能があるかをボソボソと順繰りに説明していったのである。

聞いている現場のスタッフは、明らかにざわつきはじめていた。一体こいつは何の話をしているのだ。という表情がありありと見えた。

長い説明が終わって、マイクを渡された課長が言った「何か質問は?」

次々と手があがった。実際の工程管理のこういうケースではどうすれば良いのか?具体的なシステムの利用法についての質問が矢次早にだされる。

その度にプログラマはシステムの難解なインターフェースを操り、その処理を行ってみせた。

聴衆がさらにざわつきはじめた。特に、ある申請をするにはどうすればいいか、に対する答えとして、プログラマが3種類もの画面を行き来し始めた時には、怒りとも悲鳴とも取れぬ不穏な空気が会議室に広がった。

最後に立ち上がった聴衆は明らかに怒っていた。

「工程管理システムが必要だ、そういう話は散々、課長のほうから出ていたと思うんですよ。制作に入って1年ちょっとですか。先ほど見せていただいて。確かに、頑張って作っていただいたとは思うんですが、現場の人間として言わせてもらうと、こんな面倒で難しい作業を我々が実際にできるのか、もっと言えば今のようにExcelに記入して提出するのに比べて、事務方さん含めて、どこが楽になって便利になったのか、さっぱり私にはわからないんですよ」

課長は下を向いていた。私は隣で彼の表情を伺ったが、諦め以外のそれは読み取れなかった。あるいは彼はこうなることを予見していたのかもしれない。

マイクを持ったプログラマはそれでも「データベースに集約する利点」であるとか「このような仕様を統一的に扱うためにはUIとしてこうならざるを得ない」ようなことを、難解なシステム用語を並べて説得しようと試みていたが、私が見たところ、それが成功するようにはとても思えなかった。


紛糾した説明会がお開きとなり、数日後、私の契約も終了することとなった。
課長は「ありがとう、あのシステムも一区切りついたからね。もう少しだよ」と努めて明るく言った。説明会の様子からはとてもそうは思えなかったが、私にはかける言葉が見つからなかった。

最後にオフィスを出る時に振り返ると、あいかわらずプログラマは無言でキーボードを叩き続け、課長はそれに何の関心も払わず別の事務作業に没頭している。私が来る前の光景と、それは寸分違わないように見えた。そこはまるで小さなSIerで、一人のプログラマの王国だった。

彼らはこのままずっと、まともなコミュニケーションもとらずに、仕様書修正や、修正報告書のやり取りだけでシステム構築を続けるのだろうか。


現場のスタッフが改善要望書をExcel形式で彼らに提出できればいいが、と私は思うしかなかった。