昨年末のリストラの波で、友人の何人もが避けられなかった。私も同じで、補償金をもらって家に帰り、最初の2週間はなかなか快適だった。自然に目が覚めるまで寝て、ゲームをしたりドラマを見たり。でも3週目になると、銀行口座の残高が減る一方で増えないのを見て、心がざわつき始めた。住宅ローンも車のローンも、失業したかどうかは関係なく、期日が来れば引かれる。
仕方なく、各受注グループで仕事を探し始めた。以前は会社でコードを書いていて、技術がすごければいいと思っていた。アーキテクチャ、アルゴリズム、パフォーマンス最適化、口をついて出てくる。ところが初めての副業を受けた途端、現実に思い切り平手打ちされた。
顧客はECをやっている小さな社長で、友人の紹介で私を見つけ、バックエンド管理システムのプロジェクトがあると言った。工期は1ヶ月、価格はかなり低く抑えられていた。当時は早く始めたくて、深く考えずに引き受けた。プロジェクト自体は難しくなく、ただのCRUD作業で、ReactとAnt Designを使えば慣れたものだった。書き終えてローカルで動かし、テストも問題なく、パッケージして顧客に送った。
半日後、顧客がWeChatでスクリーンショットを送ってきて、「兄弟、このコードはあまり理解できないんだけど、もっと整った形にできない？」と聞いてきた。
その時は呆然とした。コードをどう整えろと？彼が送ってきたスクリーンショットを開いて、もう息が止まりそうになった。なんと彼は私がパッケージしたbundle.jsファイルを直接開いていて、中身はWebpackで圧縮・難読化されたコードで、1行に何万行もびっしり、変数名は全部a、b、c、dだった。彼の目には、これはただの文字化けだった。
私は彼に説明した。これは圧縮されたもので、本番用で、サイズが小さく読み込みが速いと。彼はよくわからない様子で、さらに聞いてきた。「じゃあ、見られるものをくれない？後で何か変更したいとか、他の人に保守を頼むときに、これでは無理だよ。」
その瞬間、私は突然気づいた。私にとって当然の「圧縮・難読化」は、顧客にとっては「この人は信用できない、コードがクソみたいだ」ということなのだ。彼はTree Shakingも、AST抽象構文木も知らない。彼が認める理屈は一つだけ：コードは人間が読めるものでなければならない。
その後、私は賢くなった。納品前に毎回、JSフォーマット圧縮ツールでコードを整理し直すようにした。ツールは簡単で、圧縮されたコードをインデント付き、改行あり、変数名はまだ短いが少なくとも構造が明確な形式に戻し、顧客に見せるドキュメントを生成する。時には自分からソースコードをprettierでフォーマットし、コメントを付けて一緒に送ることもある。
どうなったと思う？その後の受注では、顧客満足度が急上昇した。自媒体をやっている女性が小さなツールの作成を依頼してきて、コードを受け取った後とても喜んで、「よくわからないけど、見た目がプロっぽい」と言った。別の顧客は私を友人に直接推薦し、「この若者は仕事が丁寧だ」と言った。
このことは私に長く考えさせた。私たち技術者は、新しいフレームワークを使ったとか、巧妙なアルゴリズムを書いたとかで凄いと自己陶酔に陥りがちだ。しかし顧客が求めているのは実に素朴だ：使えること、問題が起きたら連絡できること、コードが天書のように見えないこと。特に技術を理解しない発注者は、あなたが信頼できるかどうかの判断基準が、時にはコードが見た目に整っているかどうかだったりする。
今では私の受注フローで、コードのフォーマットは必須のステップだ。どんなに小さなプロジェクトでも、納品前にツールで一度通し、読みやすいバージョンを生成する。時には簡単なREADMEを書いて、顧客にデプロイ方法や設定の変更方法を伝える。これだけの追加の手間で、何人かの長期顧客を獲得できた。
だから、大手企業のリストラは怖いか？怖い。でも時には別の角度から考えると、KPIとOKRだけを見る環境を離れたからこそ、技術は最終的に人のためにあると本当に理解できた。顧客が気にするのはあなたのコードがどれだけ高度かではなく、あなたが彼を楽にさせ、安心させられるかどうかだ。そしてコードフォーマットという小さなことが、まさに顧客に「あなたは彼を大切にしている」と感じさせるスイッチなのだ。