WEBアプリケーションエンジニアがぶつかる「プログラミングお作法」という壁

　なんか、最近やたら「妥当」という言葉を連呼連発しているうちに、この言葉なしには生きられない体になってしまった。それと同時に「エンジニアの熟練度」について、プロジェクトマネージャーやプロダクトマネージャー的な観点で、知ってる人は知ってるような観点を最近よく思うのでそちらについてちょっとまとめてみる。

拡大期の会社には割とよくある話

　ユーザー側を延々やり続けて、ちょっと調子に乗ったWEBアプリケーションエンジニアがある時、開発案件の属性が突然変わってしまい混乱するなんて話は、フェーズが移り変わる拡大期の会社には割とよくある話なんじゃないだろうかと思った。

というか、近々で間近で起きた話である。
（「私の知り合いの話なんだけどね」という流れで始まる話は、大抵が自分の暴露話であると、そういえば高校時代の現国の先生が言っていたな）

ユーザーが目に見える「機能」開発

　至極当たり前の話であるが、アプリ開発はユーザーが目に見える「機能」を作るところから始まる。チャットメッセージを送るだの、ファイルをアップするだの、情報を編集するだの、まあ色々。

　プログラムを変更すればそのまま画面上に反映される機能は、「正しい動作」かどうか、目の前で起きる事象として目で見てわかるので、品質を保証しやすいという特性をもつ。（前提の構造の複雑性は今は一旦おいておく）

　この畑は、若い新人のエンジニアとしては手応えを感じやすく、人気のある領域なのだと認識している。属に「フロントエンドエンジニア」のほうが若くてキラキラしてるっぽい雰囲気を醸すのは、参加する人の属性によるものな気がする。

そして調子に乗る

　さて、そんな領域で3～4年もやっていると、一通り言語の習得や上手なコードの記述方法にも慣れて「俺ってこのあたりの言語の開発はだいたいできるようになったな」みたいに調子に乗り始める。そこで多くのエンジニアは「じゃあいっちょ次はコッチの言語かな」とか「AWSやインフラ周りでも触ってみるか」と新しい領域にチャレンジしてみたくなったりするわけ。

そして転ぶ（人もいればそうでない人もいる）

そんなエンジニアがふとした拍子に「サービスのスケール」に出くわす。途端にどうだろうか。

「あれ、100万レコード入ったら動かなくなったぞ…」

「あれれ、なんだろう、たまに自動処理がしくじってるな…」

「あれれれ、WEBAPIの全件更新で件数が合わない…」

「サービス規模がでかい」という状態になった途端に、処理の中身がブラックボックス化し、「正体不明の不具合」にさらされ、為す術なく沈んでいくことになる。そしてそういうときに大事なのが、実はつまんないお作法なのだ。

つまんないプログラミングのお作法

「自動処理はいちいちログ吐いとこう」

「変数の定義はマメに、データ型も指定しとかんとね」

「DBのコネクションはいちいち接続して、いちいち閉じる」

など、など。小うるさくレビューで言われたりするやつである。実際のところ、ちっちゃい規模の機能開発レベルでは違いなんてほとんど（むしろ全く）現れない。

　しかし、サービスが大きかろうが、小さかろうが、「ちゃんと常に動くものを上げてくる」ビジネス上で信頼感を持って仕事を任される熟練エンジニアはこの辺がきっちりできているのだ。売れる営業が、スーツの着こなしをビシッとしているのと同じだろうか（自分は営業じゃないのでそのへんは知らないけど）。

「信頼感を持って仕事を任される」＝「ちゃんとお金を稼げる」

　そしてビジネス上で「信頼感を持って仕事を任される」というのは言い換えると「ちゃんとお金を稼げる」というふうに言い換えることができると思っていて、「若手でガリガリ書けますよ！」というエンジニアじゃなくて、「コツコツやってきました」というエンジニアに自分が魅力を感じる理由になっている気がする。

　プロジェクトマネージャーとしては、納期的に手戻りになるのがホント恐ろしい。ましてや「できました！」なんて言っておきながら「結局修正に倍の時間かかりました」なんてのは、経験が浅いエンジニアの開発にはざらにある。手戻りどころか倍の工数である。

みんな、礼儀正しく、ね。

　営業マンが身だしなみを整えて、定期接触でラポールを築いて毎月コンスタントに契約をとってくるかのように、細かなプログラミングのお作法を覚えてくれるエンジニアが、自分の観測範囲に増えてくれることを祈るばかりな今日このごろです。

（書き出しと締めが一致しているだろうか、不安だけど眠いので終わり）

おわり。