猿になって七年余り。痒いか？痛いか？

まだ実感もないうちに、もう年末だ。時の矢がかくも速く過ぎ去っていくのを嘆かずにはいられない。瞬く間に命はまた一つ減る。振り返れば、猿になって七年余り。大成したわけではないが、完全に無駄にしたわけでもない。過ぎ去りし日々を無駄にせぬよう、少しばかり総括をしておこう。それは今後の道のりにも大いに益するだろう。このブログが読者の助けに少しでもなれば、吾はこの上なく嬉しい。

職業は、無数のマラソンが繋がり合ったものだ

小学生の頃、私たちは5年後に卒業するとよく分かっていた（私は当時五年制だった。今でも一部の地域ではそうらしいが）。どんなに先生や同級生、学校が嫌でも、せいぜい5年我慢すれば終わると分かっていた。中学・高校も同じだ。三、四年ほどのもので、あっという間に過ぎていく。どれほどの喜びや悲しみも、すぐに過ぎ去っていく。大学はなおさらだ。入学してキャンパスに入ったその日からカウントダウンが始まり、四年後のある日、去っていくことになると分かっている。どんなに大切にしようが、どんなに無駄に過ごそうが、時間は依然として、いにしえより変わらぬ速さで一つの方向へ走り続ける。

しかし職場はどうだ？ 5年経っても、お前はまだ働いているし、働き続けなければならない。10年経ち、20年、30年、いや40年経っても、私たちはまだ働いている。たとえ会社を辞めても、また再就職しなければならない。そして新しい仕事は以前の仕事と本質のな違いはない。キャリアは40年という大きな周期だと分かった。つまり、これは超長距離マラソンだ。高校受験の追い込みもなければ、大学受験の追い込みもない。ましてや「いい大学に入れば、もう好き放題遊べる」などというものもない。命がけでスプリントする必要はない。そうしても良い結果は得られない。もっと重要なのは、絶え間なく学び続けることだ。そう、数十年にわたって学び続けることだ。

達人、あるいは大物になる唯一の道は、絶え間ない学習だ

大企業に入ったり、すごいチームに入ったり、大物の隣に座ったり、オフラインイベントにたくさん参加したりすれば大物になれる、などと夢見てはいけない。それはすべてトゥーヤング、トゥーナイーブ（若すぎる、甘すぎる）だ。大企業はなぜお前を欲しがるのか？すごいチームはなぜお前を欲しがるのか？まず、お前には少しくらい実力が必要だ。大物の指摘を得たいと思うのは、運次第だ。おそらくテレビドラマの見すぎだろう。谷に落ちて、白猿に出会い、その腹の中に『九陽真経』が隠されていた？あるいは谷を転がり落ちて、大きな鷲を見て、『独孤九剣』を会得した？全国に何百万人もいる名もなきプログラマー猿の中で、大物に出会える確率は何割あると思う？大物が進んでお前と交流してくれる確率はどのくらいある？大物が手取り足取り教えてくれると夢見るのか？お前が彼のセフレでない限り、無理だ。

もちろん、本当に運良く高人の指摘を受けられる人もいる。しかし、私たちはこう思う。大多数の人にとっては、たとえ大物がお前のそばにいても、彼に指摘してもらう十分な機会はない。会社が私たちを雇うのは、働かせるためであり、価値を生み出させ、会社に金を稼がせるためだ。大物たちは任務がもっと重く、やることも多い。どうしてお前まで指導しなければならないのか。

大企業は確かにリソースも資料も多く、研修の機会も多い。しかし、それも自分で見て、聞いて、学ばなければならない。各種オフラインイベントは、宣伝が大多数を占めている。他の講演もほとんど表面をなぞるだけだ。実のある内容を学ぶのは不可能だ。数十分の講演で、彼にどれだけ話せるというのか？お前はどれだけ悟れるというのか？だから、オフラインイベントはプロモーションであり、視野を広げ（多くの概念を聞ける）、人脈を広げる（確かに多くの人——大物や同レベルの人と知り合える）良い機会ではあっても、学習の機会ではない。

一言で言えば、達人になりたければ、やはり地に足をつけて学ぶしかない。本をがりがりと読み込み、コードを読み、コードを書きまくる。それ以外に方法はない。この点については、ある大物の文章が参考になる（毎日業務コードを書いているが、どうすれば技術の大物になれるのか？）、とても理にかなっていると思う。

一つの業界、あるいは一つの技術を選び、深耕する

確かに、ある人たちのように五年計画を立てることは推奨しない。なぜなら、私たちがいる業界、会社、プロジェクト、人事などは変化が速すぎるからだ。これらの変化はすべて不確定要素であり、あらゆる計画を狂わせる。特に長期計画はそうだ。しかし、それでも私たちには目標が必要だ。多くの人にとって、究極の目標は言うまでもなく経済の自由だろう。どうすれば経済の自由を達成できるのか。運も確かに一定の役割を果たすが、もっと重要なのは実力だ。実力とは何か？つまり、他人には解決できない問題をお前が解決できるということだ。例えば、社長が特定の分野の事業をやりたいと思ったとき、お前が業務ルールに特に詳しく、チームを率いて社長の課題を解決できる。また、技術のな問題が発生したとき、お前が解決できる。実力がなければ、運だけあっても、たとえ淘宝（タオバオ）の台頭に立ち会えたとしても、今頃経済の自由を得られているとは限らない。

実力はどこから来るのか？詰まるところ蓄積だ。何を蓄積すれば、ますます価値が高くなるのか？詰まるところ業界か技術だ。

業界とは何か？自動車は一つの業界であり、金融は一つの業界、アパレルは一つの業界、旅行・移動は一つの業界だ、などなど。技術とは何か？セキュリティ、オーディオ、Webkit、画像、ディープラーニングなどはすべて技術だ。ある業界に身を置けば、技術は複雑ではなく、よくある一般的な技術だけを使うかもしれない。しかし、ある業界を深く理解することができれば、そこにはどんなゲームのルールがあるのか、どんな落とし穴があるのか、どんな政策や法規があるのか、どんなリスクがあるのか、どうやれば最大の収益が得られるのか——これらはすべて、その業界で一定の期間従事して初めて分かることだ。技術はもっと理解しやすい。カプセル化された技術を使うのは簡単だ。例えばWebViewは、使うのは非常に便利だが、その技術のな実装——WebKitは非常に複雑で、何年もかけないと理解できない。

もちろん、ずっと同じ分野（業界であれ技術であれ）で深耕し続けるのは容易ではない。運も必要だ。しかし、理解しておかなければならない。一つの業界、あるいは一つの技術を深耕することでのみ、自分の価値を最大化できるのだと。だから、選択肢があるときは、できるだけ目標に近づくようにしよう。

責任は技術よりも重い

プログラマーの仕事は、インターネットであれ、エンタープライズソフトウェアであれ、すべてエンジニアリングであり、技術の応用だ。ほとんどの場合、ほとんどの人は仕事で技術的に解決できない問題や、世界レベルの難問に直面することはない。言い換えれば、仕事で直面する問題は、たとえお前ができなくても、あるいは解決方法が分からなくても、資料や書籍、ネットを調べたり、同僚の助けを借りたりすれば、すぐに解決できる。さらに、コードをきちんと書き、テストを十分に行い、堅牢性を高めるといったことも、それほど高度で最先端な技術を必要とするものではない。真剣にやれば、十分に良いものができる。

逆に、仕事が酷い人は、技術レベルが低いからではない。他人からの評価は必ず「無責任だ」というものだ。まさに「態度がすべてを決める」であり、態度が生み出す結果が責任だ。たとえ技術レベルが普通でも、態度が真面目で、仕事に責任を持てば、それは優秀な社員であり、会社にとってより価値のある社員だ。一方、技術は強いが態度が悪く、無責任な人たちは、ただ飯を食って死を待つだけの人間であり、遅かれ早かれ取り除かれるべき毒瘤（がん）だ。

プロのプログラマー猿になる

ここで言うプロとは、どちらかと言えば形式、物事のやり方を指す。プロとは何かを説明する前に、いくつか例を見てみよう。何がプロではないのか：

電話面接のとき、相手に聞こえているかどうかを確認せずに、blahblahblahと話し始める。10分ほど話したところで、相手がため息をついて「すみません、電波が悪くて聞こえなかったんですけど……」と言う。
例えば電話面接のとき、候補者が「まず都合のいい場所を探します」と言い、見つけた後に電話をかけてきて「見つかりました」と言う。そしてそのまま面接が始まる。あれは候補者からかけてきた電話なのに……
例えば会議に遅刻する、会議中に無駄話をする……
事情の経緯を確かめずに早合点する。特に気の短い人は、罵り始めたりする……

こういう類のことは挙げればきりがないと思うし、私も断言できるが、プログラマーたちは日常の仕事でしばしばこういうことに遭遇する。私たちはこういうことに対してよく「プロではない」と返す。そう、これがプロではないのだ。

逆がプロである：

電話面接の前に、まず相手に聞こえているかどうかを確認してから、blahblahと話す。候補者が「今、都合がいいので面接できます」と伝えてきたら、それは通知だ。一度電話を切って、こちらからかけ直す。会議には明確なテーマがあり、遅刻しない。経緯を確かめてから、罵る……などなど。

道を聞くに先後あり、術業に専攻あり。ただそれだけのことだ。

知識は無限だ。お前が知らないことも、できないことも必ずある。たとえ数十年プログラマー猿をやっていて「何でもできる」と豪語し、人から「万事通（なんでも知っている人）」という異名を取られていても、お前を質問で窮地に追い込むのは難しくない。学校の子供でさえ、お前が知らない知識を持っている。ソフトウェア業界は多くの分野に分かれている。「畑が違えば山を隔てるようなものだ」と言うが、異なる分野にも深い溝がある。例えば、クライアント、バックエンド、フロントエンド、ドライバ、ゲームエンジン、グラフィックス・画像、セキュリティなどだ。だから、私たちは知識を求める心と謙虚な態度を保たなければならない。たとえお前がフロントエンドの大物でも、ドライバの問題に直面したら、お前は素人同然だ。謙虚に学び、他人に教えを請わなければならない。

また、面接のとき、生殺と奪の権を握る面接官こそ、候補者への尊重を示さなければならない。相手の出自（非科班=専門教育の正規コース出身でない、短大卒など）、経歴（小さな会社、外注会社）、経験（経験が浅い、プロジェクトに目立った点がない）、ミスマッチ（こちらはクライアント側の人材が必要なのに、相手の経験はほとんどフロントエンド）など、技術以外の理由で、面接中にわざと困らせたり、「明らかに採用する気はないが、上司に応えるために面接せざるを得ない」という態度を取ったり、その他の理由で候補者を軽蔑したりしてはいけない（かつて遭遇したことがある。外資系企業の人が国内企業の人を軽蔑して、国内企業はすべて外資系のパクリだと言った）。まさに「疑う者は用いず、用いる者は疑わず」だ。面接官として、この人を見送る（passする）ことはできる。それはお前の権利だ。しかし、他人を尊重しなければならない。たとえその人の能力が確かに大したことがなくても。誰にでも頭を下げる時がある。外資系がすごいのか？国内の外資系だって、結局は本社の下請けで、雑務ばかりやっているではないか。モトローラは当時どれほど凄かったか。待遇も良く、採用もめちゃくちゃ選り好みしていた。今ではみんな木が倒れて猿が散るように、散り散りになってしまったではないか！古いことわざに「イキるな、遅かれ早かれ雷に打たれるぞ」という。

迷いの目を止め、浮ついた心を沈めるには

迷いが生じる時はいつも、未来のことを考えすぎて、現在やっていることが少なすぎるからだ。浮つく時はいつも、期待が多すぎて、達成していることが少なすぎるからだ。将来、お前がどうなろうと、どこへ向かおうと、最も重要なのは、現在から始めることだ。いきなりそこへ飛んで行くことを夢見てはいけない。ヘリコプターもなければ、熱気球だって突然地面から浮かび上がることはできない。現在から始めて、地に足をつけ、一歩一歩、確実に前に進んでいくしかない。

これはまだ少し空虚で、ちょっとお説教くさい。では、具体的にどうするかを話そう：

まず、自分が何をしているのかをはっきりさせろ。そう、ただひたすらコードを書くだけの猿だ。どの層のコードを書いている？ Androidか？アップル（りんご）か？アプリか？ Frameworkか？ドライバか？どの分野だ？グラフィックス・画像？ Webkit？ネットワーク？ Bluetooth？金融？セキュリティ？何だって？コードは書かずに、保守とバグ修正だけなのか？（かなりの数の人がそうだ。例えばAndroidのトータルソリューションをやっている人は保守とバグ修正ばかりだ）。それでも同じだ。どの層なのか、どの分野なのか、はっきりさせろ。
そして、自分が何をしているのかを把握できたら、話は簡単だ。やるべきことを、きちんとやり、熟知し、半日で一日分のやるべきことを終えられるようになれ。
コードを書くには、いかにしてコードを良く速く書くかを学ぶ必要がある。つまり、指定された要件を素早く完了でき、バグも少なく、さらに言えば、コードをすっきりと分かりやすく、構造が合理的で、命名が分かりやすいように書くことなども含まれる。これは基本的なスキルの修練であり、常に軽視されている。なぜなら、ほとんどすべての会社のKPIにはコードの良し悪しは含まれず、せいぜいバグの多さ、クラッシュ率、パフォーマンスと安定性だけであり、これらはソフトウェアの指標であって、コードの指標ではないからだ。コードの良し悪しを測る最良の方法は、あなたのコードを引き継いだ人の反応を見ることであり、彼があなたを罵る回数を見ることだ。コードの修練には『Code Complete』『Clean Code（クリーンコード）』などの本を読むとよいが、それ以上に重要なのは優れたオープンソースコードを読むことだ。
もう一つは、既存のコードに精通することだ。新しい要件が来るたびに、どのクラスを変更すべきか、どこに新しいコードを追加すべきかを知っているように努める。バグを修正するときには、考えればバグがだいたいどこにあるか、どのクラス、どのメソッドが原因かを把握できるようにする。
さらに、ビジネスロジックに精通することだ。あらゆるソフトウェアはビジネスを実現するために作られている。ビジネスロジックに精通するには、まず自分が担当する小さなモジュールのロジック、次にソフトウェア全体のビジネスロジックを理解する。これは新しい要件の評価やバグ解決に非常に役立ち、全体の視点から考えることができるようになる。具体的な指標としては、要件ドキュメントを整理し、そこからさまざまなテストケースやシナリオを生成できることが挙げられる。これはコードの正しさを検証するのに非常に役立つ。
その後は、よく使うテスト環境、テストデータ、テストケースを準備してバックアップしておくことだ。新しい要件があったり、バグを修正した後も、それらを整理してテストライブラリに追加し、セルフテストやリグレッションに備える。QAがソフトウェアの品質を保証してくれるとはいえ、私たちのソフトウェアはQAに渡す前に少なくとも動作する状態であり、要件を満たしている必要がある。要するに、プロのプログラマーは自分で十分なテストを行うべきだ。そしてテストは、必ずしも便利とは限らない。例えば、クライアント側ではよくあることだが、バックエンドのデータがまだ準備できていない場合、モックデータが必要になる。一部のデータはごくまれなシナリオでしか出現しないため、それもモックでテストする必要がある。リリース前にはテスト環境でテストサーバーを使ってテストする必要がある、などなど。ここで言いたいのは、モックデータやプロキシなど、こういったものが頻繁に必要になるなら、手間をかけて整理しバックアップし、あるいはコードを書くにせよオープンソースライブラリを使うにせよ、使いやすいテスト環境を整えておくことが開発にとって非常に有益だということだ。おそらく経験があるだろうが、バグは修正するのは簡単でも、検証するのが非常に難しいことがある。プロキシを掛け、モックデータを作り、特殊なシナリオをシミュレートし、ネットワーク環境を調整する必要があるなど。
また、よく使う環境設定もバックアップしておくべきだ。例えば、コードが異なるシナリオに応じて異なるカスタマイズを持つ場合、最良の方法はそれぞれをコピーして、各コピーに設定を済ませておくことだ。たとえ別のブランチでも実現できるとしても、だ。理由は二つある。
何年かやってみると、環境設定も開発の一部であり、しかもそれはたいてい面倒で、10分で終わりそうなことが結局2日かけても終わらないこともあると痛感する。現在のコードはどれも複雑だが、その複雑さはコード自体にあるのではなく、依存関係が特に複雑なのだ。みんなオープンソースソフトウェアでよく経験すると思うが、ライブラリ自体は複雑ではなくても、それを使うには大量の依存関係をインストールして設定する必要がある。パッケージマネージャー（apt-get、brew、pipなど）を使わずに、手動でOpenCVをインストールしてみるか、ソースコードを直接コンパイルしてみることを想像してほしい。
- コードのブランチはコードを区別することはできても、環境依存の設定はたいていリポジトリの中にはない。つまり、ブランチを切り替えた後も、やはり環境設定をいじり、依存関係を弄る必要がある。
- もう一つの理由は並行性の問題だ。仮にあなたがAバージョンのブランチで新機能を開発しているとして、その時にBバージョン（AとBは異なる顧客向けで、二つのブランチには違いがあるとする）のバグを修正する必要が生じたとする。ブランチを切り替える方が便利か、それとも別のディレクトリに行ってやる方が便利か。私は物理的に分離されている方が良いと思う。
上記のことができれば、担当範囲の仕事はもうあなたにとって問題ではないだろう。そうなったら、深く学習して、依存しているものをきちんと理解することだ。例えば、OkHttpやRetrofitのようなネットワークライブラリを使っているなら、なぜそれらがネイティブのものより使いやすいのか？その主要な原理は何か？そのカプセル化の考え方は？また、画像読み込みライブラリのUILやPicassoなど、その原理は何か？依存している下位ライブラリは、カプセル化が非常に優れていて、使いやすい。そういうライブラリほど、使い方だけを知っていては終わりだ。なぜなら、使ったことがない人でも、数分チュートリアルを見れば使い方は分かるからだ。実装の詳細を深く理解し、高度な使い方を学んでこそ、これらの優れたライブラリを使った甲斐があるというものだ。
さらに、どの分野であれ、どのレイヤーであれ、パフォーマンスチューニングは熟練者の象徴であり、プロジェクトのパフォーマンスチューニング作業はたいてい熟練者が担当する。だから、もしパフォーマンスチューニングを学び、実践したことがあれば、スキル向上に大きな推進力となるし、面接でも大きな加点要素になるだろう。
最後に、真心を込めて、真剣に仕事に向き合い、一行一行のコード、一つ一つのバグに真剣に向き合うことだ。たとえ今の仕事が好きでなくても、たとえ今が時間の無駄、人生の無駄だと思っていて、毎日バグ修正ばかりで何の楽しみもないとしても、それでも真剣に向き合い、仕事をやり遂げるべきだ。いわゆる「人の金をもらったら、人の災いを代わりに消す」だ。会社から給料をもらっている以上、仕事をきちんとやるべきだ。将来いい会社に移れるかどうかは別の話であり、それは将来の話だ。今日ここにいるなら、やるべきことをきちんとやるべきだ。もし特に落ち着きがなく、目は高いが手が低く、いつもいい加減にやっているなら、あなたが高い地位に就けると思うか？経営者はより重要なことをあなたに任せるだろうか？この世の中は千差万別で、確かにスキル以外の理由でより高い給料やより良い仕事を得た人もいるが、私はほとんどの場合、比例していると思う。待遇があなたより良い人には、やはり正当な理由があるものだ。もし納得いかないなら、なおさら真心を込めて努力し、将来高い地位に就いたときに、みんなに見せつけてやれ：「俺はお前ら全員より強い！」と。

上記のアドバイスを実践できれば、少し続けるだけで、半年も経たずに必ず質的な変化が現れるだろう。

くそったれなキャリアプランや長期計画なんて、どうでもいい。

キャリアプランは方法論的なもので、デザインパターンよりも当てにならない。長期計画に至っては人を害するものだ。1年を超える計画、いや6か月を超える計画でさえでたらめだ。あの大物たちに聞いてみろ、明確なキャリアプランや長期計画を持っている人はほとんどいない。彼らの共通点は、深く掘り下げるのが得意で、本を読み込め、コードを読め、思考が活発で、考え方が明晰で、問題を解決する際に、彼らの考え方はあなたよりエレガントだということだ。

なぜこれが役に立たないかと言うと、現実の生活は変化が本当に速すぎるからだ。プロジェクトは、数か月やったらもうやらないかもしれない。人員は、今日は張三が退職し、明日は李四が異動する。あなたがやり終える前に、要件が変わったり、この運用キャンペーンをやらなくなったりする。なぜなら上司が予算を承認してくれないからだ……

具体的な身近な例を話そう。去年チームにインターンが来た。Androidクライアントとして採用され、来て最初の1週間はAndroidの仕事を任されたが、2週目に新しい大きな要件が来てH5（Mobile HTML5）が必要になり、その子はH5をやることになった（JavaScriptをゼロから学ばなければならなかった）。そして約3か月後、会社の方針が変わり、そんなに多くのインターンを使えなくなったため、その子は学校に戻らなければならなかった。もしあなたがその子だったら、1か月の学習計画すら実現できない。なぜなら来週、いや明日何が起こるかさえ分からないからだ。

より良い成長・学習環境を得るには、大企業に行くことだ。

大企業に行くか小企業に行くかは、CとC++の論争、GNOMEとKDEの論争、VimとEmacsの論争に並ぶ不朽のテーマだ。私が思うに、キャリア初期、例えば卒業したばかりか、卒業後2、3年以内であれば、大企業は間違いなく非常に良い選択だ。ここで言う大企業には、BAT、NetEaseなどの中国の一流企業、そしてIntel、Microsoft、Facebook、Googleなどの大きな外資系企業が含まれる。

次に理由を説明する。会社が私たちを雇うのは、働かせるためであり、会社に価値を生み出させ、会社に金を稼がせるためであり、あなたに学ばせ、視野を広げさせ、優秀な人に近づかせ、問題を議論させるためではない。大企業は、非常に大きいため、安定した収入源と収益力を持っている。だから、そのリズムは規則ので、比較の余裕がある。そのプロジェクトは成熟して安定しているか、短期のな利益のために行われていないかのどちらかだ。だから、人材育成に計画があり、言い換えれば、あなたが学ぶことを許容し、さらには仕事のタスクを少し遅らせること（少し遅らせるだけだ、と言っておく）も許容できる。なぜなら会社もあなたが学び、技術と能力を向上させることを期待しており、会社にはより良いあなたを受け入れる余地もあるからだ。要するに、あなたが向上し昇進するための十分な余地があり、このプロセスを完了させるための時間と忍耐もある。小企業にそんな余地があるだろうか？「まず数か月勉強させてくれ」と言えるだろうか？もしかすると、数か月後に学び終えて戻ってきた頃には、会社はもう潰れているかもしれない。

また、大企業には人が多く、良い人も多く、優秀な人も多く、悪人もいれば、使えない人も少なくない。あなたはより多くの人と知り合える。大企業がどのように運営されているか、大企業が何によってここまで大きくなったのか、そして大企業がどのように運転を維持し衰退しないのかを理解できる。大企業では、学ぶための時間と空間があり、視野を広げ、人脈を築くことができる。これらはすべて小企業ではできないことだ。

一言で言えば、職業の急速な学習期にあるなら、大企業が最良の選択だ。そして、学び終えたと感じたり、新しいボトルネックに直面した時には、小企業があなたの力を発揮するのにうってつけの場所だ。だから、BATを離れた人々は、起業するにせよ、起業に加わるにせよ、非常に良い行き先だ。これはウィンウィンだ。私たちにとっては、小企業の方がスペースが広く、人は少なく仕事は多い、あなたが才能を発揮する絶好の舞台だ。そして小企業こそ、一人で十人分の働きをする、CTOでありプログラマーでもあり、開発であり運用でもある複合型人材を必要としているのだ。

コミュニケーションとコードの保守性は、作者が他人のことを考えられるかどうかにかかっている。

もし他人のことを考え、相手の立場に立って考えることができるなら、その人のコミュニケーション能力はきっと悪くないし、彼が書くコードの可読性もそう悪くはないだろう。もし他人を顧みず、自分が話したいだけ話して、話し終わったらそれっきりなら、どうやっても意思疎通はできない。もしあなたが他人が自分のコードを保守することを考えられず、さらには将来の自分が今書いたコードを見ることさえ考えられないなら（ほら、自分のことさえ考えていない）、このコードが保守可能だとしたら、私はこの人生を無駄に生きたということだ。

外を攘うには、必ず先に内を安んずる。

委座（蒋介石）のこの言葉はかなりレベルが高く、深い意味があり、指導的意義もある。私のこの言葉の理解は、個人、チーム、部門という小さな単位から、会社や国家という大きな単位まで、二つ以上の大きなことを同時に行うことはできず、一つをやり遂げてから初めて他のことに取り掛かれる、ということだ。少し分かりにくいかもしれないので、私がゆっくり説明しよう。

いわゆる「温かく満ち足りれば淫欲を思う」だ。次の食べる当てもないのに、女の子を口説くことを考えるか？一つの技術、一つのプログラミング言語、一つのプラットフォームも十分に理解していないのに、クロスプラットフォームや技術の広さを考えるなんて、すべてでたらめだ。あちこちに井戸を掘っても、深く掘れず、結局一生水を掘り当てられない。「10個の10%は1つの100%には等しくない」という通りだ。

さらにチームを例にとっても、リリースのたびにてんやわんやしているのに、XP（エクストリームプログラミング）だの技術革新だのを語っても意味がない。まずは業務に必要な技術をしっかり熟知し、徹底的に理解し、自分の担当をきちんとこなし、余裕を持ってこなすことだ。毎回のリリースに余裕で対応でき、さらには元々10人分の仕事を5人でこなせるようになって初めて、技術革新やUT（ユニットテスト）、XP、技術主導、エンジニア文化などに取り組むべきなのだ。

大きな会社でも同様だ。現在の分野で安定した市場シェアを占めてもいないのに、他人の真似をして布石を打とうとする。相手が金融をやれば自分もやり、自動車をやれば自分もやり、映画事業をやれば自分もやる。これでは遅かれ早かれ自滅する。例えば今の贾布斯（ジャー・ブス／楽視の賈躍亭氏）を見てみろ。楽視のテレビ、携帯、スポーツ、どれが安定した市場シェアを占めている？どれが家計を支える重責を担えている？このタイミングで布石を打つ？自動車をやる？これこそ「No zuo, No die（余計なことをやるから自滅する）」というものだ。馬老師（馬雲氏）は布石が得意だが、それはある分野で独占のな地位を築いた時のことだ。当時淘宝（タオバオ）を始めたのは、B2Bが足場を固め、家計を支えられるようになっていたからだ。言い換えれば、B2Bはすでに軌道に乗り、市場シェアの大部分を占め、利益を上げていた。淘宝が失敗して金を失ったとしても、大した問題ではなかった。後に阿里雲（アリクラウド）を始め、今の映画事業だの、菜鳥（ツァイニャオ）だの、双H（ダブルH）だの、これらは継続的に金を注ぎ込む必要があるものだ。なぜか？淘宝と天猫がアリババ全体を養えるからだ。たとえこれらが全て赤字になっても、損失を負担する余裕があるのだ。

大きな国も同様だ。国民がまだ満足に食べることも着ることもできない時に、精神文明建設だの科学技術革新だのを語っても仕方がない。例えば1970〜80年代の中国、十数年前の東南アジア（四小龍ではなく、比較的弱い国々）で、環境保護をやれというのか。人類にとって、人類自身の生存と環境保護の選択に直面した場合、前者を選ぶしかない。だから、発展途上国が中進国へと歩みを進める過程では、経済発展が常に最優先だ。人類の発展プロセスはどこも同じで、先に汚染し、発展を求め、それから治理（環境整備）をするのだ。

ここまで話せば、孤（私）の言いたいことを理解していただけたと思う。

競争力を高め、価値を増やす

競争力とは何か。私が思うに、それはGoogleで一度検索すれば解決できるような問題ではない能力をどんどん養うことだ。要するに、知識体系のことだ。Googleで一度検索して解決できる問題は、必ず一つの点だ。StackOverFlowでもブログでも、語られているのは一つの点の問題で、それほど大きなものではあり得ない。なぜなら、大きければ、一つの記事でどうして説明し切れるだろうか。複数の点がつながって体系になる。これには長い時間をかけて何度もGoogleで検索し、さらに思考と総まとめが必要だ。これこそが競争力であり、ベテラン（老鳥）の価値があるところでもある。

多くの人が、「30歳を過ぎたらコードを書くべきなのか」「40歳を過ぎたらどうするのか」と論じている。確かに、年齢を重ねるにつれて、人の身体や精力は衰えていく。若い頃のように夜更かしはできなくなる。だから30代の現場の人間の立場は非常に厳しい。卒業して最初の数年は急速な成長期で、本気で勉強しようと努力すれば、スキルも収入も一直線に上がっていく。しかし30歳に近づいた現場のプログラマーが、さらにスキルや収入を一気に上げようとするのはかなり難しい。家庭や生活、身体の事情で、それほど多くの時間を勉強に割けなくなるからだ。この時、自分にできることは、卒業して2、3年の人にもできることだ。彼らは精力がより旺盛で、身体もより健康だ。だから多くの人は管理職か転職を選び、残った人たちもいつ転向するかばかり考えている。

私が思うに、このような気まずい境遇を招いた最も重要な原因は、やはり継続的に学習せず、十分な競争力を形成できなかったことだ。たとえ管理職になれなくても、達人レベルの人物になれなくても（現実の生活で、30歳を過ぎた全員が管理職や達人になれるわけがない）、継続的に学習し、絶えず競争力を高めていけば、必ず価値は高まっていく。たとえ会社が毎年一律の昇給しかしてくれなくてもだ。

給料は、単位時間当たりで計算すべきだ。仮に月給2150元だとする。これは実は21.5×100で算出される。1日休むと100元差し引かれる。さらに換算すると、8×12.5＝100、つまり時給は12.5元だ。二人の月給がどちらも2150元だと仮定しよう。しかし一人はレベルが高く、1日の仕事を2時間で終わらせ、1か月分の仕事を1週間で終わらせる。もう一人は毎日残業してようやく終わらせられる。どちらの給料が高いか？もちろん、ここではかなり単純化しており、現実の生活はこれより複雑だ。誰にでも急速な成長期があり、会社にも急速な拡大期があるが、最終のには皆、安定に達する。いわゆる安定とは、ボトルネックにぶつかることだ。例えばBATなどの大手企業の大多数の人々。アリババを例にとると、大多数の人はP7に昇進したら、まず間違いなくそこで止まる。主管にならずにP8に昇進するのは非常に難しく、そしてますます難しくなっていく。そういう人々は、毎年一律の昇給があるだけだ。給与水準を上げたければ、自身の仕事効率を高めて価値を高めるしかない。

「それは現実のじゃないだろう。仕事は必ずしも均等に割り振られるわけではなく、古株にはより多くのタスクが割り当てられるかもしれない」と言う人もいるかもしれない。実は、この決定権は自分自身にある。もう古株になって、上がる見込みが見えないのなら、なぜ余計に働く必要があるのか？これは「屁股決定脑袋（立場が頭を決定する）」の時代であり、「給料が責任を決定する」時代だと理解してもいい。従業員がどれだけ努力するかは、いくら給料をもらうか次第だ。はっきり言って、新卒の給料しか払わないのに、アーキテクトの仕事をさせ、CTOの責任を負わせることを期待する。そんなことは、キャリア初期の急速に学習・成長する時期にしかやらない。そして、ひとたび学ぶものがあったと感じたら、すぐにより良い条件の職場へ移っていく。

要するに、絶えず学習し総まとめをし、どんどん競争力を養ってこそ、年を取れば取るほど価値が高くなるという状態を実現できるのだ。

重要なことは必ずしも優先しなくてもよい

複数の大きなタスクがある場合、例えば新機能の開発、リリース済みバージョンのいくつかのバグ修正、来月の運営イベントの技術方案の設計。この三つのことが目の前にあれば、まず最も重要なことから選んでやるしかない。これは確かに「重要なことを優先する」原則を適用すべきケースだ。

しかし、他にもやるべき小さな用事があるとしよう。例えば、携帯にチャージする、ネットで何か買い物をする、ソフトウェアをアップデートするなど。これらは10分以内で片付く小さなことだ。こういうものは先にやってしまった方がいい。そうすれば頭がスッキリして、「携帯にチャージしなきゃ」といつも考えずに済む。こういった小さなことはそもそも忘れやすいので、脳が無意識に私たちへ注意を促すのだ。これは通常の仕事の思考を妨げ、思考の集中度に影響を与え、ひいては重要な仕事の効率に影響を及ぼす。さらに、「重要なことを優先する」方式では、夜になってもこうした小さな用事が終わらず、翌日に持ち越すことになる。

区別の基準はこうだ。もし小さなことを10分以内で片付けられるなら、素早く片付けてしまえ。理解しておくべきことは、ToDoリストは短ければ短いほど良いということだ。半日や1日かかるようなことは、もちろん「重要なことを優先する」原則に従って対応すべきだ。

残業して業務をこなすことに力を注ぐな。むしろ残業して学べ

ソフトウェア業界では残業は避けられない。特にインターネット業界では、現在のモバイルインターネット時代において、996（朝9時から夜9時まで週6日勤務）はさらに普遍のな現象だ。充実感を感じることもあるだろうし、達成感を感じることもあるだろうし、疲れを感じることもあるかもしれない。しかし、牛のように黙々と毎日残業して業務をこなすことは、少なくとも個人の成長にとって最も致命のだ。今は年末だ。振り返って考えてみてほしい。この一年で何をした？どんな成長があった？気づくはずだ。たくさんのことをやったが、成長はほとんどなかったと。できないことに直面しても、ネットで調べて、コピーして、それで終わり。業務をあれだけやったのに、達成感はあるだろうか？プログラマーの達成感は、どちらかといえば自分の成長、以前はできなかったことをできるようになることに由来するのであって、毎日レンガを積む（単純作業）ことには由来しない。

例を挙げよう。あなたは家を建てられる。しかしこの一年、ずっと同じような規格の家を建てていたら、どれだけ成長できるだろうか？いつか素敵な城を建てる仕事が来た時、受け止められるだろうか？会社が私たちにお金を払うのは、価値を生み出させるためだ。会社にとっては家こそが価値であり、私たちがより多くの家を作り出せれば、支払った給料に見合う価値があるということだ。そして、いつかあなたが年を取り、病気になり、家を建てられなくなったら、会社はすぐにより若くて力の強い人を探してあなたの代わりにするだろう。一方、あなたがどうやって城を建てられる人へとレベルアップするかについて、会社は一切関知しない。

だから、もし毎日レンガを積んでいると感じ、数か月、あるいは半年経っても、まったく進歩がなく、新しいことを学んでおらず、直面した問題も解明できていないなら、この時は注意が必要だ。レンガを積むスピードを落とすべきだ。たとえKPIを放棄することになっても、立ち止まって学び、どうすればもっとうまくできるかを総まとめし思考すべきだ。例えば、パッケージングやリリースのような反復作業は、スクリプトを使えないだろうか。例えば、プロダクトや運営から来る要求は、合理的に断るべきだ。例えば、反復的な運営イベントには、設定テンプレートなどを作れないだろうか。

毎日残業して業務をこなしていては、進歩はない。進歩したければ、学ぶしかない。

賢く仕事をすることを学べ

試験の時、最善の方法は何か？当てずっぽうではなく、自分で解くのでもなく、正しい答えを写すことだ。仕事が割り当てられた時、最善の方法は何か？自分でやることではない。たとえあなたがすでに手慣れた仕事であっても、他の人に代わりにやってもらうことだ。最も力を省け、最も楽に仕事をする方法は、他の人にやらせることだ。物事を成し遂げる方法はたくさんある。私たちは最もコストの低い方法を選ぶべきだ。

ここで言いたいのは、ずる賢く立ち回って、本来自分がやるべきことを他人に押し付けるということではない。もちろん、他人に押し付けるだけの能力があり、相手も引き受けてくれるなら、それでも構わない。しかし本当に言いたいのは、賢く仕事をし、本来は他の人が責任を持つべきことに精力を費やしてはいけないということだ。例えば、現在のソフトウェアの依存関係はかなり複雑で、問題は通常、上位レイヤーを通じて表面化する。もしこれが下位レイヤーに起因すると分かったなら、調べるのはやめよう（時間に余裕があり、学習や研究のためであれば別だが）。担当者に調べてもらえばいい。彼の方がその分野に詳しいので、あなたが丸一日かけても理解できなかったことを、ひと目で解決してしまうかもしれない。

さらに、煩わしい手動操作や反復操作は、スクリプトを書いて実行させるべきだ。コンピュータの最大の利点は、繰り返し実行でき、かつ間違いを犯さずにタスクを完了できることだ。その最大の強みは反復性にあり、人間の反復能力はコンピュータに及ばないし、スペルミスのような間違いも犯す。パッケージングやリリースなど、多くのことはスクリプトで実行できる。

プログラマーの強みを活用することを学べ

ソフトウェアはもはや、大学の実験室の中で人々に不可解で、とても神秘的に見えていたものではない。すでに人々の生活に溶け込んでおり、広場ダンスのおじいちゃんやおばあちゃんまでがスマートフォンを使い、微信（ウィーチャット）や淘宝（タオバオ）を使っている。ソフトウェア関係者にパソコンの修理を頼む人がどんどん減っていると私は確信している。これは、私たちが毎日ソフトウェアと向き合い、ソフトウェアなしではいられなくなっていることを意味する。ソフトウェアを作れる人間としては、自身の強みをしっかり活用すべきだ。以下に例を挙げて説明しよう。

さまざまなフィッシングSMS、詐欺SMS・電話を見抜けなければならない。プログラマーでありながら通信詐欺に騙されたなら、その猿（プログラマー）はあまりに不出来だと言うしかない。
さまざまなソフトウェアについても、どれが本物で、どれがパチモノ・偽物で、どれにウイルスがいる可能性があり、どれにトロイの木馬がいる可能性があるかを見抜けなければならない。さらにセキュリティ意識を持つべきだ。現在、モバイルアプリやウェブサイトでの個人情報流出は非常に深刻だ。だからこそ、モバイルアプリの権限管理により一層注意を払い、ウェブサイトへの登録はできるだけ少なくするなどすべきだ。自身が情報セキュリティに注意するだけでなく、周りの人にも注意を促すべきだ。
さらに例えば、普通の人が情報を得る方法は、ウェブサイトにアクセスし、検索エンジンを使うことだ。しかし、猿媛（プログラマーたち）はクローラーを使えるのではないだろうか？
例えば、紅包（お年玉）争奪戦、チケットの奪い合い、秒殺（月餅の秒殺はやめてくださいね）、投票の水増し、コメントの水増しなど、普通の人は人海戦術、手作業、WeChatモーメンツへの投稿に頼るしかありません。我々猿媛（プログラマー）は必ず技術に頼るべきです。スクリプトを書き、コードを書いて、これらのことを代行させるのです。これも我々が従事する職業がもたらす利点の一つです。

出典：浪人の星空
作者：alexhilton
リンク：http://blog.csdn.net/hitlion2008/article/details/54089376