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

目次

• 拡大期の会社には割とよくある話
• ユーザーが目に見える「機能」開発
• そして調子に乗る
• そして転ぶ（人もいればそうでない人もいる）
• つまんないプログラミングのお作法
• 「信頼感を持って仕事を任される」＝「ちゃんとお金を稼げる」
• みんな、礼儀正しく、ね。

おはなし。

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

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

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

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

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

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

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

そして調子に乗る

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

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

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

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

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

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

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

つまんないプログラミングのお作法
「自動処理はいちいちログ吐いとこう」

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

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

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

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

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

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

ちなみにどの辺で転びやすいか

わざわざnoteからQiitaに転載したのであれば、さすがに味付けは必要だろうということでここ追記。

件数が多い時に転ぶ

まあわかりやすく負荷で死ぬと思っていただければ。単発の負荷が上がりすぎて死ぬこともあるし、思ってたよりも全然ユーザー数が多いとかで死ぬこともあります。もしくは更にその掛け算。まあ確かに、機能開発する時わざわざ毎回「100万回回してみた」とかするわけでも無いですが、習慣化されているとなんとなく回避行動されているものです。

継続性で転ぶ

恐ろしい話ではありますが、「24時間365日、全く同じ時間と日にちは存在しない」というのもシステムでは実は考慮しておくべき事項だったりします。過去に私が引き起こしたバグでは、「年に一度、3月30日にだけ起こるバグ」なんてものも有りました。
「date関数とかの作り込みが甘かったせいで◯◯」
みたいなことの回避は、やはり継続的なサービス開発にあたっては必要なことです。

異常系で転ぶ

「データ型のバリデーションをかけてなかったせいで、intのカラムにstr入れようとした結果、特大の数値が格納されてしまった」
みたいなやつです。開発側からすると「そんなの入れないでくれよ」って思うんですが、長く運用するサービスであればあるほどそこらへんを考慮できてこそ持続可能なサービスというもの。

環境で転ぶ

「普段はDB設定だけど、この機能はここに格納されたファイルを参照して機能する」
なぜか昔の人のやり方への単なる右へ倣えでだけでこんなの実装してしまったりすると、「サーバーごとに同期されんやないかい」という本番環境のみで起こる謎の仕様が出来上がったりします。全体像、想像して作りましょう。

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

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

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

おわり。