例えば、あなたが江湖の中で一定の地位を求めるなら、独孤九剣を習って超一流の達人になることもできるし、医術を習って絶世の名医になることもできる。この両者は江湖の中で地位があり、どちらも希少だ。一つは殺傷力のため、もう一つは、人には誰でも山高水長（人生の前途は長く、何が起こるか分からない）があるからだ。

プログラマーも同様で、価値を高めるにしても、表現力を改善するにしても、最終的には何らかの環境で一定の希少性を達成しなければ、その人は価値がない。希少性は同時に2つの次元での力に影響される。一つは自身の努力、例えば前述の価値向上や表現力であり、もう一つは大きな環境の変化とその変化への適応である。この章で主に注目するのは後者である。

希少性があなたにもたらすもの

希少性が個人にそれほど大きな影響を与えるのであれば、希少性は一体人にどのような影響をもたらすのか。簡単な例を見てみよう。

日本にかつてこんな話があった。ある人が某電気通信会社で大規模システムの保守を担当しており、収入は悪くなかったが、時間が経つにつれて給与の伸びに不満を抱き、最終的に退職を選んだ。すると、彼が去った途端、その大規模システムはすぐに不安定に動作するようになった。仕方なく、その電気通信会社は高い地位と厚い給与で彼を呼び戻さざるを得なくなった。そのために、この会社が収入面でも地位面でも、彼が断れない条件を提示したことは想像に難くない。

これは希少性が作用する典型的な例だ。大規模システムは膨大なユーザー群に関わるため使わざるを得ず、同時にそのシステムの保守にはこの人なしでは不可能である。これにより、この人の希少性は非常に際立ったものになった。

この話は実に興味深い。ここでは実質的に良いソフトウェアではないものが、一人の価値と希少性を成立させているからだ。これはあまり良いことではないが、実際にはこの種の状況は珍しくない。市場の観点から見ると、プログラムの内部ロジックが明確かどうか、十分なコメントがあるかどうかには関心がなく、それがうまく機能するかどうかだけに関心がある。だから、使われているクソコードにも巨大な価値がある。つまり、商業的な考慮が希少性に与える影響はより大きい。

上記の文章が誤解されるのを防ぐため、ここで一点補足しておく。上記の道は決して真似する価値のある道ではない。なぜなら、上記のその人にとって、実際には彼の価値は特定のシステム一式に結びついており、これにより流動性がほぼゼロになり、その人の成就を制限し、未来に大きなリスクをもたらすからだ。

希少性を改善する方法

自分の希少性を改善するためには、通常、2つの側面の作業を同時に行う必要がある。一つは自分を磨くこと、もう一つは時代の流れに従うことだ。自分を磨くことで希少性を得られるのはよく分かるが、時代の流れに従うことが伴わなければ、その希少性をうまく実現できないことが容易に起こり得る。2013年にDOSプログラミングに精通した人は間違いなく希少だが、それだけで価値を生むとは限らない。以下では、この2つの側面から希少性について少し説明する。

1 プログラムの世界の価値の高地を目指せ

投資の達人バフェット氏は広く知られる言葉を残している。「ある企業はそびえ立つ堀を有し、その堀の中には凶暴なワニや海賊、サメが守っている。こそが投資すべき企業である」と。この言葉は価値の高地の外見を非常に生き生きと描写している。

企業にとって、堀は様々なものであり得る。高度な技術（ボーイング機）、破りにくいユーザー粘着性（QQ）、独占的な資源（中石油）、独自の企業文化（アップル）などだ。

堀は企業に代替不可能な価値をもたらす。供給の観点から見れば、これは企業自身の価値の希少性を築くことだ。それがなければ成り立たず、他に選択肢もない。これが価値の高地であり、企業がそこにいるとき、相対的に安全だ。そのため、大企業は最終的に秩序とエコシステムの主導を試みるものであり、そうして初めて大企業は希少性を掌握できるのだ。

この理屈は個人にも同じように当てはまる。希少性そのものには多くの由来があり得て、タイミングに由来することもあれば、高みに由来することもある。タイミングに由来する希少性は偶然に近く、簡単に打ち破られやすく、長期的な価値を持たないことが多い。人の一生という観点から見れば、これは有力な支えではない。例えば、Erlangは比較的希少かもしれないが、単なる言語の壁は思うほど高くない。もし本当に巨大な需要があれば、この世界で1か月の間に何百万人ものErlangプログラマーが増える可能性がある。

自分の希少性を経営するとき、確かにワニや海賊、サメが守っている場所を見つけるべきであり、それが価値の高地だ。もちろん、ワニなどを自分で放つことは難しい。企業とは異なる。この点で、マネジメント方向のプログラマーと技術方向のプログラマーが直面する選択肢や取るべき対策は異なる。

技術方向のプログラマーにとって、上述のような価値の高地に向かう方法は基本的に2つある。

一つは、一定の高さに達してから横に展開する方法だ。例えば、プログラミング言語、（金融）業務ロジック、外国語、ネットワーク知識などを組み合わせることで一つの高地になり得る。ここで、プログラミング言語では天才プログラマーに及ばないかもしれないし、業務ロジックでは銀行員に及ばないかもしれないし、外国語では専業の翻訳者に及ばないかもしれない。しかし、フィルターが一つ増えるごとに、高地の標高が一段ずつ高くなり、最終的に希少性に転換される。

もう一つは、徹底した専門家の道だ。ある職種では、領域を広く広げる必要がない場合もある。例えば、TTSやOCRのアルゴリズムを担当する人の中には、プログラミング言語にもあまり詳しくない人もいるが、確かに特定分野の専門家になり得る。これも同じく価値の高地である。この方向では、いったん本当に一定の高さに到達すれば、単純な数量の蓄積で追い越せるものではない。例えば、100人かあるいは何人の凡庸な科学者がアインシュタイン一人に等しいと考えるのは、間違いなく愚かだ。

どの方向であれ、最終的には次のような効果を達成する必要がある。すなわち、商業的価値の高い一つのことを完全にやり遂げられるが、そのことは大多数の人にはできない、ということだ。例えば：

• 私はソフトウェアもハードウェアも分かるし、良い製品をどう開発するかも知っているので、スマートフォンの開発を主導できる。今の視点で見ると、本当にすごいなら、锤子（Smartisan）の問題を解決しに行ける。
• OCRの認識率を1%向上させることができる。
• 100万単位の同時接続を支えるウェブサイトを自分が主導して構築できる。
• チームを率いて、この銀行のシステム全体をやり遂げることができる。
• … …

このようなとき、単純な技術的観点で自分を測らないほうがよい。例えば、Javaが得意だ、PHPが使える、TCP/IPプロトコルを知っている、などだ。これらに価値がないというわけではないが、そういう視点はややレベルが低い。物事を完全にやり遂げることができて初めて商業的利益に直接結びつき、真の希少性を持ち得るのだ。

マネジメント方向のプログラマーにとって、上述のような価値の高地に向かう方法はおそらく一つしかない。

人々に記憶される成績を努力して作り出す必要がある。その成績は製品であってもよいし、何らかの業績であってもよい。今日、微信（WeChat）と言えば、誰もが張小龍を思い浮かべるだろう。それは微信が2年足らずで2億人のユーザーを集め、しかも評判が非常に良かったからだ。まさに奇跡である。

価値の高地に関して、典型的な罠がある。複雑さを含まない、特定の企業に固有の経験は、往々にして価値の高地だと誤解されがちだが、実はそうではない。なぜなら、環境が比較的開かれていれば、そのようなものは短期間で攻略されてしまうからだ。例えば、ある会社が独自のプロセスを定義しているとする。その中には曖昧なものが多く、新人がやるとすぐに壁にぶつかる。これにより、プロセスを把握すること自体に高い価値があると誤解しやすいが、実際にはこれはプロセスが不完全であることによるもので、特定のシナリオにおける偶然にすぎない。これが確かに希少性を生むことはあるが、基本的に流動性がなく、大抵の場合、良い選択とは限らない。

要件開発は価値の高地と言えるだろうか？

アジャイル寄りの組織では、プログラマーはしばしば要件に近い立場にある。しかし、比較的伝統的な開発手法では、要件を担当する人とプログラマーは距離があることが多い。要件開発をする人はプログラムをあまり書けないかもしれないし、プログラムを書く人は要件をあまり書けない。

では、要件開発は価値の高地と言えるのだろうか？

多くの純粋なプログラマーは、単なるドキュメント作業には技術的な中身がなく、誰にでも書けるように思えるため、価値の高地とは言えないと考えるかもしれない。しかし、商業的価値の観点から見ると、ある業界の業務を徹底的に理解している場合（技術も分かればさらに良い）、これは確かに価値の高地なのである。

これは類比で考えると分かりやすい。天猫（Tmall）はプラットフォームだけを提供し、各出店者が商品を売る。では、天猫に価値があるか？当然ある。天猫の11/11セールの売上高は100億以上で、アメリカのブラックフライデーよりも高い。価値がないはずがない。

では、なぜ天猫に価値があるのか？エンドカスタマーの目には、まず天猫があり、その次に各出店者があるからだ。天猫が入口を独占しているので、天猫のほうがより価値がある。

要件と開発の関係もこれに似ている。ある人が製品の要件を担当するとき、外部の人の目には、その人が作った要件がその製品を象徴しており、製品を通して初めてプログラマーの貢献が見える。外部の人が考える思考の流れは、まず要件開発者、次にプログラマーという順序だ。

その中でも比較的極端な実践として、要件開発者がプロジェクト全体を主導し、他の全員が要件開発者のリーダーシップの下で働くというものがある。

こういうときに細かいことにこだわるのは意味がない。例えば、プログラマーがいなければ製品などないと考える人もいるかもしれないが、それは店がいなければ天猫もないと議論するのと同じで、全く意味がない。現実にはもちろん両方に存在価値がある。ここで議論しているのは、これが価値の高地に当たるかどうかだけだ。

2 技術の大波の先頭または中を歩く

ITの世界では、城頭の旗が変わり、大王の旗印が入れ替わるように、主役の交代が特に速い。そして、その入れ替わりのたびに、実際には何らかの技術の興隆や衰退が引き起こされる。

当時、WPS97の開発期間は非常に長かった。これについて百度百科には次のような記述がある。「Windowsには多くの新しいものがあったが、私たちがまだ十分に慣れないうちに、マイクロソフトはまたアップグレードした。技術資料もなかなか見つからなかった。マイクロソフトはWindowsを掌握しており、私たちは何から何まで自分たちで一から始めなければならず、それがWPS97の難産を招いた。もしWPS97が1995年にリリースできていたら、Word 6.0と直接競争していたはずで、Word 6.0は絶対に勝ち目がなかっただろう。」

これは、新しい技術が興るときに生まれる希少性を非常に生き生きと記録しており、1995年当時、企業が高度なWindows開発者をどれほど渇望していたかが伺える。この希少性は、業界サイクルの背後にある技術の世代交代によってもたらされたものだ。そして今日では、検索エンジンを利用すれば、業界に入ったばかりのプログラマーでもWindowsプログラミングの問題の大部分を解決できる。

このような技術の潮流に直面したとき、比較的適切な方法は、現実に基づいて勇気を持って新しい技術を受け入れることだ。

現実に基づくとは、スキルの流動性を考慮し、実践と学習が切り離せない特性を考慮し、自分が将来性が良いと思う新しい技術を選び、時間を投入することである。しかしここには落とし穴があり、新しい技術と聞くと多くの人は新しいプログラミング言語を思い浮かべるかもしれないが、プログラミング言語はあまりにも基礎的で、参入障壁が低すぎるため、十分に大きな検討領域ではない。視点がこの尺度に限定されると、見えるものが多すぎて焦点を絞りにくくなる。このとき、自分が検討する単位を適度に拡大する必要がある。英語ではよくTech Stackという言葉でこの一連の技術を表現する。

例えば、LAMP(Linux+Apache+MySQL+Perl/PHP/Python)は一つの検討単位になり得るし、Windowsプログラミング+ASP.NETも一つの検討単位になり得るし、ビッグデータ処理に関する様々な技術も一つの検討単位になり得る。

10年を振り返ってみると、まずPCクライアントプログラムの全盛期があり、次にインターネットの興隆、そしてモバイルクライアントの隆盛があったことがわかる。現在の状況で言えば、間違いなくモバイルクライアントとインターネットは従来のPCクライアントよりも魅力のである。そしてクラウドの時代において、境界が比較のはっきりしている2つのTech Stackは、クローズドソースの一連の技術（主にマイクロソフトが提供）とオープンソースの一連の技術である。この中で、どちらかのTech Stackの技術が徐々に優位に立つならば、間違いなく対応するTech Stackで蓄積のある人々は比較の良好な希少性を持つことになる。

当面は両者に明確な差がないように見えるが、この点については、個人的には将来的にオープンソースのTech Stackが徐々に優位に立つと思う。Quora(quora.com)やHigh Scalability(highscalability.com)では、Flickr、Pinterest、Instagramなど、海外の新興で時価総額10億ドルを超えるWeb2.0サイトの技術アーキテクチャを調べることができる。これらの技術アーキテクチャを注意深く読めば、根本的な共通点が見えてくる。それはすべてオープンソース技術に基づいて構築されているということだ。

この暗黙の一致とも言える選択の背後には、一定の必然性がある。一定のカスタマイズ性を望み、かつ高額なコストを支払いたくない場合、オープンソースのTech Stackはほぼ唯一の選択肢である。特にオープンソース技術に成功事例がますます増えれば、この優位性はますます明確になる。

どうしてもクライアント（iOS、Android、WinRT）とインターネットの間で選ばなければならないなら、個人的にはインターネットの方がクライアントより優位だと思う。

技術の退潮に伴うリスク

多くの人は、マイクロソフトが2002年から2012年までの10年間、ほとんど何も成し遂げなかったと言うだろうし、株価の観点から言えば、10年前にマイクロソフト株を買っていたら今は30〜40%しか儲かっていないが、アップル株を買っていたら3倍以上儲かっていただろうとも語るだろう。私は個人的に時々思考が飛躍するが、考えるのはそれだけではない。もしマイクロソフトがさらに10年を失えば、潰れるのはマイクロソフトだけではなく、マイクロソフトと結びついている様々な企業や個人、多くのベテランWindowsプログラマーも道連れになるということだ。

PCの世界ではマイクロソフトは間違いなく覇者だが、もしPCの時代が終われば、その覇者が転身に成功できなければ、間違いなく共倒れになるだろう。そしてその時、マイクロソフトのプラットフォームに半生を費やした無数の人々はまだそこにいる。彼らはどこへ向かうべきなのか？

技術の大波が興ると、波頭に立つ多くの人が眩いスターとなるが、ある波が引く時、それに伴って一部の人々の栄光も持ち去られる。異なるのは、前者は派手で華々しいのに対し、後者はひっそりと静かだということだ。

このような状況下では、本当に時代とともに進むしかない。

自分の希少性をチェックする

社会的ニーズの観点から自分の希少性を検証するのは非常に難しい。なぜなら、関連する様々なデータが常に非常に不足しているからだ。しかし、すぐに自分の希少性を認識させる簡単な方法がある。卒業生が非常に努力して学んだ場合、どれくらいの期間であなたの仕事を代替できるか？例えば、卒業生が努力すれば1、2年であなたを代替できるのに、あなたの年齢がもう30歳に近いなら、希少性は間違いなく非常に悪い。

それとは逆に、卒業生がとても努力しても、あなたの技術レベルに達するのに5年かかり、同時に特定の縁がなければ、どうやってもあなたを代替できないなら、たとえあなたがすでに30歳でも、希少性は非常に良いものになる。ここでの縁とは、特定の特別な実践機会を指すことができる。

自分の希少性を比較的体系的に評価したいなら、以下の問題を順に検討する必要がある：

• 自分が習得している技術は、まもなく時代遅れになる技術だろうか？

技術の大波は常に定期的に様々な技術を淘汰するが、時点によって淘汰の対象もかなり異なる。完全に淘汰されるわけではないものもあるが、少なくともかつてのような輝きはない。2013年を境に10年を振り返ると、そのような技術には、Flash、MFC、Delphiなどがある。

技術動向への感度を保つためには、定期的に他人のアーキテクチャを読むことが非常に重要である。

もちろん、時代遅れになる可能性のある技術とは汎用技術だけでなく、新しいソリューションに取って代わられる可能性のある古いシステムも指す。例えば、かつて多くの企業が知識管理にLotus Notesを使用していたが、今ではそのようなシステムを使う人はほとんどいない。

• 自分が習得しているスキルを、一体どれだけの人が持っているだろうか？

この点を検討する際には、前述したように、個人の視点ではなく、より会社の視点から考える必要がある。単に何かの言語やフレームワークを使えるという程度では、希少性は間違いなくない。例えば、単にASP.NETでWebページを開発できるだけでは、高い技術的参入障壁はほとんどないが、データベースの設計を相当程度習得し、ロードバランシングやキャッシュなどの手段を通じてシステムのパフォーマンスをしっかり保証できれば、自分の希少性を一段上のレベルに引き上げることができる。

記事の出典：http://blog.csdn.net/leezy_2000/article/details/38278309