プログラマに殺され続ける

最後に記事を書いてから２年が経った。

あれからおおよそ普通ではない道を歩いて、今は印刷会社の社内ソフトハウスで働いている。 給料は入社当初から前職の1.5倍の契約で人生史上最高額であったが、かなり能力が認められ、4ヶ月で15%程昇給した。入社してからまだ半年だが、近い将来的に役職に就いて欲しいと言われている。 「管理職にはなりたくないです。私と同じレベルで実務をこなしていける人間はほとんど居ないです。大して能力が無い割に仕切りはやりたい人なんて沢山いますから、そういうのはそういう人にやらせておけば良いんです」とは言ってある。

一般的に、印刷業界は時代遅れの業界であって、おしなべてレベルは低い。 元々私は印刷業界出身者であって、あまりのレベルの低さに辟易して出版業界に移り、そこも時代遅れなのでシステム開発で単身独立した。 ところがシステム開発業界も、特にSIの現場のレベルの低さも尋常ではなかった。 まともな人間が皆無で、なんでITなんてやってるんだろう？　コンビニのバイトの方がよっぽど似合ってるんじゃないか？　程度の奴らが普通にコーダとして働いていた。 言い直せば、コンビニの従業員の方がよっぽど優秀な人が見つかるかもしれない。 設計者もいい加減に不勉強が過ぎるし、プロジェクトマネージャがマネジメントをしているのを観たことが無い。

5年間の独立経験の中で、私は本当に他人を信用しなくなった。 特に、プログラマと名乗っている人間の低俗さについて辟易することになった。 彼らは皆、自分に都合の良い事ばかり言って自分を甘やかしてばかりで甘っちょろすぎる。社会というものを全く理解していない。

ITの現場においてはプログラマはほとんど信用されていないし地位も低いが、 それは自分たちが撒いた種による災禍だと思う。

業務の場においてはほとんどまともに話せないくせに、ネットでは（特にTwitter）大口ばかり叩く。 「エンジニアを大切にしない企業はなんたら」と言う割には、大切にされる人間になろうと努力はしない。 「デュアルモニタと16GBのメモリ、SSDは人権だ」とTwitterでぼやいてる暇があったら、上司に論拠資料と費用対効果を添えてそのように報告すればいい。 「経営者意識」については、完全にその意味を履き違えている。 「スーツやネクタイがうんぬん」とか、そんなに着たくないなら着なくて良い会社に自分の能力を認めさせれば良いだろうと思う。 そもそも、彼らの頭の中にあるスーツやネクタイ像がダサ過ぎる所が視野が狭いと言わざるを得ない。挙句の果ては、そこにリュックを背負い出す。もう、センスの欠片もない。

ITに限ったことでなく、私が会社を変わる度にいつも苦しめられてきたのは「先輩の無能さ」だった。 先輩が無能だと大抵の場合、あまり設備にお金をかけてもらっていない。

これまで話をしてきた経営者は皆、「仕事が良く回って会社にお金がたくさん入ってくるようになるなら、いくらでも設備投資をする」と考えていた。 そのための経費など安い物だという事をよく知っていた。 にもかかわらず貧弱な設備で仕事を回しているのは、“単純”に、誰も声を上げないからだ。

「こんなPCでは遅すぎて使いものにならないので、もっと高性能なPCを支給してください」

こんな簡単な声が発せない。理由は至極単純で「自分に責任が発生するのが怖いから」。以上。

バカじゃないかと思う。怖がって自分可愛さにずっと不便なPCで非効率な仕事を延々と続けている。頭がおかしい。 まるで、関係が壊れるのを恐れて「好きだ」と女の子に伝えられない中学生だ。

何で言わないんだろう？　業務の効率化を図るのが仕事のくせに、自分の業務の効率化の提案もできないとか、そんなもの一人前の仕事人では無いだろう。 彼らは仕事をしているつもりでいるようだが、作業をしているだけだ。

  • 作業とは、言われたことを言われたとおりにするもの。
  • 業務とは、言われたことを最善の方法を考えて行うもの。
  • 仕事とは、何をするのかそのものを考えて自分で創り出すもの。

ただの作業工が不自覚に文句だけ言っている様がタイムラインに流れてくるのは、他人の無意識のつぶやきであったとしても蔑視の対象になる。

日本のITにおいてエンジニアが軽視されているのは、自分たち自身に覚悟がないからだ。いい加減にそのくらいの事には気づいてほしい。

今の印刷会社については、比較的満足している。 所属しているソフトハウスでの仕事は印刷物制作ではなく、それにあたっての技術支援が目的となっている。 私は、重要取引先の印刷物制作システム構築のためのプロジェクトと、自社のWEBシステムの“再構築”が現在の主な仕事。

“再構築”と書いた意味は言う必要もないと思う。とにかく酷い。 時々、あまりのカオスぶりに頭がおかしくなりかける。 プロのプログラマですらクソみたいなコードしか書けないのだから、印刷会社の間に合わせのコーダが書いたら、それはもう、壮大な負債にしかなるわけがない。

常務や社長には、その酷さについて伝えてある。 初めて伝える時は、やはり躊躇した。なにしろ、その実態は「これまでの会社そのものの批判」であるから。 それを良く認識した上で、それでも尚伝えなければならないと判断し、覚悟して伝えた。

社長についてはほんの少しだけは不快に感じたようであったが、口利きしてくれている常務のおかげで私の能力についてはある程度認めてもらってあったので大筋では好意的に捉えていただいている。

結局、言わなければ何も変わらない。 たとえ嫌われるかもしれないとしても、言葉を発しなければ誰もそれに気付かない。

会社にとっての本当の害悪とは、有る事を無い事にして隠蔽される事だ。それが溜まりに溜まって溢れ出た時、大抵、その隠蔽者は会社を去っている。そいつこそが石を投げるべき本当の咎人だ。

回顧

超初心者向けの解説ページを書いていると、昔を思い出す。

そう、昔はこんな下等なコードを書いていた。

本職プログラマじゃなかったから、プログラムなんて動けばいいんだと思っていた。

起業した時も、馬鹿みたいなお金をとって重厚なシステムを作るんじゃなく、ちょっとした便利なプログラムを安価に提供したらいいんだと思っていた。

でも、お客さんというものは上を上を要求する。

だから、どうしてもしっかりしたプログラム設計が必要になってくる。

「動けばいいやコード」から「分かりやすいコードを」になって「安全なコード」や「メンテナンス性の高いコード」になっていく。

３ヶ月前の自分が他人である事を思い知る。

あまりの劣悪なコードに、自分以外のプログラマを信じられなくなったりもした。

超初心者向けの解説ページでは、一歩ずつ歩いていく方式で記事を書いているが、譲れない部分については難しくても随時説明していくつもりだ。

どれだけ理解してもらえるだろうか？

それでも書かなければならない。それがコンピュータプログラムを書く者の務めだと思う。

英語はそのまま書け

どうも和製英語が嫌いだ。

勿論「保留心」を使うべき、というレベルの話ではない。日本語にはカタカナがあるのだから、適切にカタカナ表記にすればいいという話。

例えば「シュミレーション」。本当に物を考えていないカタカナ化だと思う。

元単語は simulation 。どうしてこれが「シュ」と読めるのか不思議だ。多分、初めてこれを「シュミレーション」と呼んだ人は頭が悪い。

一昔前には「ファーストフード」という劣悪なカタカナ化が巷を席巻していた。

元単語は fast food 。頼んだらすぐ出てくるからこの名前が付いている。決して最初に食べる食事 first food ではない。当時はまだ朝マックなど無かった。

困るのは、その間違った読み方が強制されてしまうこと。

昔働いていた会社で業界紙をつくっていたが社内に英語を扱う部門があって、新聞を作る際に「ファーストフードはおかしいからファストフードと表記すべき」と進言した。ところが「ファーストフードが一般的なのでファーストフードにします」と押し切られた。この頭の悪い表記を発信しなければならない現実は、さぞかし英語部門の人の羞恥心をくすぐったことだろう。

「パラメーター」という人も山のようにいる。

元単語は parameter 。どう読んでも「パラメター」で、発音は「ラ」にアクセントがある。

「パラメーター」と発音すると何がまずいかというと、プログラムコードで変数を定義したりコメントを書いたりする場合に、うっかり「paramater」と書いてしまうところ。英語がどういうものか分かっている人ほど materと書いてしまう。

「パラメター」またはJIS Z 8301を適用して「パラメタ」と呼ぶべき。アクセントは「ラ」、絶対に「メー」と伸ばしてはいけない。伸ばした奴はヤギ確定。

「クーロン」もかなり酷い。

元単語は cron 。どう読んだら「クー」になるのか理解できない。九龍城の影響だと思うが映画の見過ぎだ。「クーロンタブ」までいってしまうと、それ逆に発音しにくいだろ？と思う。

前に仕事で view の事を「ヴュー」と書いたらそれを見た上司が大笑いして「ビューだよ」と言った。実に知能が低そうだ。だから日本人はいつまでたっても v と b の区別がつかない。

なお、「保留心」って何だ？　と思った人はこち亀を参照されたし。

プログラマは敵ではなく、身内に殺される

プログラマの辛さはプログラミングが難しいことではない。

劣悪なコードを書くプログラマが沢山いて、彼らがそれを劣悪だと感じておらず、また、それを劣悪だと評価出来る人間もほとんどいない事こそが辛さの極みだ。

ゴミを出す人間がゴミを出していることを自覚しておらず、ゴミが出されていることを認識できる人もいないということだ。

まっとうな人ほど辛いのがプログラミングの世界。

劣悪なコードには２タイプ有る。

１．知識と技術が共に欠如しているいわゆるクソコード

本人ですら、何を書いているのかわかっていない、なんとなく動いているコード。とにかく無駄なコードが多く、整頓もされていない。大抵の場合潜在的なバグを含んでいるので、機能追加や改修の際にその潜在的バグが炸裂したりする。知識が無いために先回りができず拡張性に乏しく、要素が１つなら動作するが２つ以上になる事が全く想定されていないといった、自由度の低い場当たり的なコードが頻出する。

２．知識だけつけて使い方を間違っているコード

本人は何をしているのか理解して書いていたが、知識だけが先歩きして奇っ怪なコードになっている。間違った、あるいは過剰な抽象化がなされることが多い。モデルは永続化データにアクセスするためものとして実装された結果、モデルが呼ばれた段階でトランザクションを開始したりする。結果、ビジネスロジックの行き場所がなくなってコントローラーに詰め込まれることになるのは使い方を間違っている好例。同様に、ビューはモデルを参照してはならない、ビューにはロジックを書いてはいけないというのも間違い。もしそれが正しいならそれはただのテンプレートである。

なぜビューがテンプレートではだめかというと、分業ができなくなるから。テンプレート内で複雑な分岐を行うとデザインを行う非エンジニアがさわれなくなってしまう。これらのために、やはりコントローラーにロジックが書かれる結果になる。分業のためにもテンプレートは必要であり、使うテンプレートを選別したり表示のためのロジックを書く場所としてのビューという立ち位置が必要になる。

モデルクラス毎にそれぞれのDTOクラスを作成してセッター・ゲッターを作りクラス呼び出しのたびに新しいDTOオブジェクトを作ってバケツリレーする、あるいは、DAOのような過剰な抽象化を行ってSQLをビジネスロジックから遠ざけ、コードの可読性を損なわせるのはJava使いのようだ。 コードを書いた時点で少なくとも本人は理解しているが、その複雑怪奇さから半年後には誰も容易に理解できなくなる。

この２タイプは技術力こそ子供と大人ほど違うが、害悪であるという点ではどちらも凶悪だ。

彼らは自分が技術的負債を作り出していることに全く気づいていないし、周りの誰も、それに気づかない。マトモなコードを書いている者だけがそれをゴミと認識して掃除にあたっている。

新天地

会社を精算してからまた宮仕えを始めているが、とても居心地が良い。

広くて綺麗なフロア、少し暑いくらいの行き届いた暖房、加湿器。

あちこちに花がいけてある。トイレは温かいお湯のでるウォシュレット。

先輩方はみなとても優秀で、自分が小さく感じる。

会社の仕組みはとても効率的につくられていて、いろいろな事が新鮮で勉強になる。

本当によく出来た会社だと思う。

もし10年前にこんな会社に入っていたとしたら、僕は多分、独立起業しようなどとは思わなかっただろう。

でも、独立起業をしたからこそ、今この会社にいるのでもある。

世の中上手くはいかない。

この会社、先輩方が優秀すぎて、僕はいつか追い出されるのかもしれないという不安にかられる。

そうなってもいいように、腕だけは磨いておかないといけない。