システムエンジニアはなぜ、ヒゲをそるべきなのか：あるエンジニア、かく語りき（1）（2/3 ページ）

一介のエンジニアが人生の節目節目で考えたこと、今回は「学生から社会人へ」。立場が変化したことでどのような認識の変化があったのかをつづります。

[松坂高嗣，リブセンス]

　私も就職したてのころは、「他のメンバーに影響がない範囲なら、別に遅刻とか気にする必要はないのではないか」と思っていました。しかし、下請けシステムインテグレータのビジネスは信用商売です。それも「約束を守るかどうか」の世界です。そこでは「遅刻する人間かどうか」が重要な意味を持つ瞬間が確かにありました。

　例えば、複雑なシステムの構築を要求されて「一見問題ないと思えたが、実は実現がとても困難だった」ということは往々にして起こります。または「経験豊富なエンジニアチーム」として業務委託を受けたものの、クライアントの期待する品質を下回ることがあります。

　ソフトウェア開発者なら皆、理解していることですが「そういうことはたまにある」わけです。もちろん全力を尽くすのですが、絶対に大丈夫とは決して言えません。そこで「本当に全力を尽くしているかどうか」について疑われることがあります。モラルを証明する必要があるわけです。恐ろしい話ですが、本当です。そのとき、「遅刻をしない」や「期日を守る」「ウソを言わない」といった小さな信頼感が効いてくるのです。どちらかといえば「だらしないから疑われる」ことの方が多いかもしれませんが。

　つまり、信頼を得られないリスクがあるが故に、信用商売の開発会社にとって「予定上の影響がなくても遅刻はよくないこと」なのです。

　私のこうした「理解」は、決して正しくなかったり、そのときの経験範囲に応じて視野が狭かったりします。「ヒゲ」と「遅刻」についても意見が異なる人は多いでしょう。それでも私にとって「規範には目的がある」という考え方は目から鱗（うろこ）が落ちました。

　適切な規範は、複数人で何かを成し遂げるために有効なツールだと思います。それは価値観と目的の両方に対するコミットを含んでいるからです。

　同僚がコーディング規約をレビューしたときに言った言葉が、強く印象に残っています。いわく「ただ機械的に順守するつまらない規約は、誰にとってもプラスにならない。守ることでメリットが得られ、プログラマが自然と成長するようなガイドラインを目指すべきである」と。

「製造工程」と「Excel方眼紙」との出会い

　サラリーマン的なことばかりではなんなので、エンジニアとしての仕事の話も書きましょう。ありがちですが、「いわゆるプログラミングはシステム開発全体の非常に部分的な仕事である」ということ、そして「元請けと下請けの仕事の違い」についてです。

　私は学生時代、趣味でDelphiを多少使っていました。また、お世話になっていた教授の研究がエンタープライズJavaを題材にしていましたので、「Javaでシステム開発の仕事」というと「さあバリバリJavaでプログラミングするぞ。ゲッターセッターを作ってやるぞ。設計？ よし、UMLだ！ クラス図だ！」というイメージを持っていました。けれども、私が就職した会社ではそうではありませんでした。

　ご存じの通り、伝統的なウォーターフォール・モデルの開発プロセスにおいてプログラミングは実装や製造と呼ばれ、「要件定義」「外部設計」「内部設計」が完了した後に作業を開始します。「設計が完了した後に」がポイントです。

　私が最初に配属されたチームでは、設計から製造に至るプロセスのあちこちで、品質のぶれが出ないような工夫がいろいろされていました。ここでいう品質とは、誤字脱字がないこと、用語や文体の統一されていること、そして体裁でした。

　そこで体験したシステム開発の仕事とは、新聞記事の執筆のようなものだと思いました。目的があり、資料があり、文章についての細かいガイドラインがあります。基本的に匿名であり、文体はすべて合わせる必要があります。念入りに校正し、間違いがないようにします。そして趣旨がちゃんと伝わらなければなりません。提案書を書くこと、設計書を書くこと、プログラミングすること、すべて同様です。

　設計はしばしば非常に細かく行われていました。方眼紙のようにセルを精密に位置合わせしたExcel資料に、そのまま日本語でプログラミングされていることがあります。英単語は全て全角で、数字も1桁であれば全角です。凄い（すごい）ときには、

変数 x に 0 を代入して初期化する

　などと書かれていたりするのです。プログラマはこの「設計書」から、以下のようなプログラムを書きます。

int x = 0;

　どうしてこんな仕事の仕方をしているのだろうと新卒当時の私は悩みました。パンチカードでプログラムを動かしていた、CPU時間がとても高価で実機デバッグが難しかった時代なら分かります。でも、強力なエディタやデバッガが十分普及した現代において、ややこしい日本語プログラミングを設計と称して行うメリットが想像できなかったのです。

　これでは効率が非常に悪いどころか、マイナスの影響がとても大きいと思いました。

　ガイドラインに従って書くのもつらければ、紙でどばっと渡された資料を何度も目grepするのもつらいし、全角で書かれたクラス名をコピペしてコンパイルエラーになったりするのもつらいのです。

　ページ追加を行うたびに（ページ番号がずれるので）全部印刷し直すのもやりきれないものがあります。やがて「印刷し直すのが面倒くさいので、ページ追加が発生しないようにロジックを省略する」とか「メソッドの引数と戻り値があっていれば、後は設計書と違っていても解釈の問題で乗り切る」などという邪悪なハックまでが現場に蓄積されていきます。そもそも、日本語で制御構造まで含めてソースコードと1対1対応する設計書を書けるのであれば、理屈の上では同じ時間で動作するプログラムも書けるはずです。

　いったい、どうしてこうなっちゃったんだ。同僚とそんな風に、いつも嘆いておりました。