いろいろと厳しいご時世の中、確実に以前よりもお仕事の数は減っているようで、ウチの部門の人たちもプロジェクトから突如解任されたり、プロジェクト自体が自然消滅したりして、部門の席に帰ってきて暇している人がちらほらいる。同じ部門で、かつてトラブルプロジェクトを共に闘いぬいた某後輩くんもそんな中の一人で、つい最近帰ってきたんだが、しばらく暇らしい。

その彼が、何の前触れもなく言った。

「設計書を表記の揺れとかなく書くには、どうしたらいいんですかねぇ?」

作業に熱中していたところに不意打ちを食らった俺。意図をはかりかねて彼を見つめて黙って待っていると、彼は続けた。

「どういうツールがあればいいと思います?例えば、Javaのコード補完みたいに、決められた辞書から入力を補助するツール、あったらよくありません?」

俺ねぇ、そういう、人間の創造力を捨てて機械的にものを作るアプローチ、信じないんだよね。ツールは人の能力を増幅するものであって、足りない能力の補完はしてくれないんだぜ。話、聞く相手間違ってない?

「うーん、WordとかExcelでっていうこと?あるじゃん、IMEが。ツールなんか作んなくてもプロジェクト専用の単語詰めたユーザー辞書つくって、それメンバーに配ればそれでいいんじゃないの?ツール非依存だぜ」

俺は彼の出した要件を120%満たす完璧なソリューションだと確信した。しかも超汎用性が高い。

「えー、それは違うじゃないですかぁーw」

正解のつもりだったんだが…ギャグかなんかだと思われているらしい。「もーむす」って書いたら「モー娘。」になるとか、「あｋｂ」って書いたらもしかして「AKB48」って変換してくれる、あれと今の話はいったい何が違うというのだ(なお彼の名誉のために言っておくと、彼も別の人から同じ話題を振られただけで、俺の意見を聞いてみたかっただけみたい。本当はとても優秀な人だ)。

まぁそんな雑談してたのだけど、この業界で繰り返されるこの手の話は本当に根が深い。いつも思うのだが、この議論の背景には必ず、プログラムを日本語で書いた「詳細設計書」がある。彼らはあえて口にしない、あるいは気づいていないが、これには以下のおかしな前提がある。

1. コードを書くことは基本的に設計を伴わない単純作業である。コードを書き始めるということは、設計が終わったということ。
2. プログラマーは「詳細設計書」がないとコードが書けない。単純作業をするためのほとんど考えない人たちだからな。
3. だから要件を理解している上流担当の人が、日本語でプログラムをかくための説明書を作ってあげる必要がある。それが詳細設計書だ。

設計者は、処理の流れをExcelで書く。まぁExcelで書くかどうかはここではどうでもいいのだが、とにかくExcel、それがルールだ。で、入力情報はどこからどうやって持ってきて、どういう順番でどういう計算をして、監査記録をどこに残して最後にどこにどういう結果を出力するか、とかを、小学生の読書感想文以上につまらない感じで淡々と書く。愛とか感動とかそういう要素は一切ない。

プログラマーは、それを見てJavaとかのプログラミング言語に一字一句変換していく。この変換作業こそが、彼らのいう「実装」だ。ちなみに、プログラマーが親切心から設計書に書いていないことを実装なんかした日には「設計書と違う、勝手なことをするな」とか怒られかねないので、多少(いや、かなり)変だと思っても設計書に書いてあるままに作ることが多々ある。なにしろ、どんなに正しく作っても、スケジュール内に作らないとメチャクチャ怒られるからな。仕様が間違っていようが書いたプログラムが動かなかろうが、スケジュールに間に合わせることが全てだ。インド人や中国人と仕事をするならその辺どう考えているか、聞いてみてほしい。

SI業界はこの、「詳細設計書+実装」プロセスで長年やってきているが、どうしても良い品質のものが上がってこない。そこで彼らは、どうしたら「設計書」に書いてあることがうまく「コード」に間違いなく変換されていくか、ということを考え始めたわけだな。本人たちからは聞いてないけど、多分そうだ。

そこでまず、表記揺れがターゲットになった。同じ意味の言葉を何種類もの言葉で表現すると、正直よくわからない状態になる。だから、あまり設計者が意識しなくても、言葉があらかじめ決められた単語のセットに標準化されるようにしたい。辞書に載っている言葉しか使わなければ、誰が読んでも誤解はしないだろうし、入力ミスもなくなるから、つまらない誤植も減る。設計書の品質があがり、実装に伝わる際のコミュニケーションエラーも大幅削減。すばらしい!(…のか?)

しかし、だな。

俺からすると、どれだけ遠回りしてるんだあんたらは、って感じがしてならない。そんな無駄な苦労するくらいなら、最初からコード書け、と。

EclipseでJava書いてみろよ、クラス名間違ってタイプした数秒後には赤線が引かれている。途中までかいてCtrl+spaceすれば補完してくれるだろ?IMEの辞書に登録しなくても。しかもdeprecatedとか現在のContextで使えないエレメントは候補に出ないようにもできる。

クラス名変えたい?Refactor-renameすれば、間違いなく該当クラスのクラス名だけをほぼもれなくリネームしてくれるよな。ExcelでContextやらData Type意識した置換ができるか?

前のバージョンから何が変わったのか、Excelで正確に表現できるか?変更履歴シートを作る?その履歴人が書くんでしょ?正しいの?SCMのHistory diffするのとどっちが楽なのよ、それは。

もちろん、いきなり何でもかんでもコード書けっていっているわけではない。ただ、コードが得意としている分野を、なぜにそれを最も不得手とする自然言語とExcelで無理してやろうとするのか、そこが俺には全くもって解せない。全プロジェクトメンバーの中で、一番スキルレベルの低い人に合わせて作業しているとしか俺には思えないんだが、それは客から金もらって働くProfessionalな仕事の仕方なわけ?

それに、プログラミング能力のない人がプログラムの書き方を、Excelでプログラマに指南して、なんかいいことあるか?しかも、なんで、同じことを日本語とJavaにわけて、2人で2回も書いてるのよ?1人が1回Javaで書けばコスト半分だろ?GDつかってコスト1/3ってあんたらちゃんとトータルコスト計算してるのかよ。

…などとイロイロ一人で考えた一日だった。不毛だよな、SI業界。