これからご紹介する私の試みはなかなか難しい側面があり、物議をかもすかもしれません。また、お見せするのは初めてなので完璧とは言えないかもしれません。私はソフトウェアエンジニアのスキルとその影響力を評価するシステムを開発しようとしています。少なくとも、プログラマが成長していく理想的な成長過程を大まかに描いてみようと思います。評価スコアは0.0から3.0まであり、それぞれの数字は専門能力を開発していく際の出発点を表しています。

このシステムは主にビジネスの観点から見た、ソフトウェア業界が求めるものに基づく 実務的な スケールです。数学的な才能や高速アルゴリズムを書く能力、Linuxカーネルの内部構造に関するプログラマの理解の深さなどを評価するスケールではありません。もちろんこうした能力は重要ですし、通常、エンジニアのスキルとともに伸びていく能力ですが、私のシステムが焦点を当てたいのはそこではありません。このスケールは、ソフトウェア開発者を評価する上で知るべきすべての事項を網羅しているわけではありませんし、「勤務評価」や「人事上の問題」に使われるスケールの代わりにもなりません。スコア「2.1」の人でもパーソナリティの問題のために解雇しなければならないことがあるでしょうし、協調性のあるスコア「1.2」の人が会社にとって貴重な存在となることもあります。

結局、このスケールはそれぞれの事情にある程度左右されるもので、 スキルと影響力 の間に違いはありません。プログラム言語や使うテクノロジが変われば、満点を取っていた開発者が得点を失うこともあります。また開発者は、自分の能力に応じた影響力を持つレベルに到るまでに、半年から1年（たいていの場合）はチームに所属する必要があります。彼のレベルは「1.5」だ、という具合に、まるで個人のスキルの客観的な評価であるかのように表現してしまいそうですが、より正確に言えば、この数字は個人と仕事上の役割の間における貢献と適用の範囲を表すものです。会社の規模や要求度も大きく影響します。小さな技術系企業はよく、社員に自分のスキルレベルを0.2から0.5ポイント上回ることに「挑戦」するように奨励します。だからこそ企業は急成長するわけですが、一方で大規模でお役所的な企業は通常、社員を各自のスキル以下のレベルに画一的に組み込みます（なぜならリーダーのポストが元々限られているからです）。

私が定義しようとしているスケールは、人間の組織に関する洞察に基づいています。一般的にチームの人材は、個人の貢献度によって4つのカテゴリに分類できます。割り算の人、引き算の人、足し算の人、掛け算の人です。 割り算の人 はがん細胞のような存在であり、広範囲にわたって生産性に悪影響を与えます。これは通常、個人の態度や倫理観の問題によって引き起こされる影響です。「割り算の人」がチームに与える影響としては「無力感」（管理者内での影響は除きます。管理者の職務条件を満たすのは足し算の人か掛け算の人だけです）だけでも十分過ぎます。これは「人事上の問題」（割り算の人は本人が向上するか解雇されるかどちらかです）ですが、信頼関係と向上心を想定して作成しているこの専門能力開発スケールの範囲外のことです。 引き算の人 とは、彼らにかかる費用に比べて生産性が低い人々です。この場合、彼らを教えたり監督したりする人の時間的コストも含めて考えます。一時的に引き算の人であることは問題ありません。ほとんどすべてのソフトウェアエンジニアが、そこからキャリアをスタートさせます。また、新しい仕事に就いた最初の週は、引き算の人であって当たり前です。 足し算の人 は働き者です。多くの実務こなす、貢献度の高い有能な社員です。最後に 掛け算の人 とは、「足し算の人」として貢献すると同時に 他の人々 の生産性も向上させる人です。多くの企業において、管理職こそ 掛け算の人 の仕事だと思われていますが、技術系企業ではそんなことは全くありません。アーキテクチャや基盤に関わる貢献（例えば再利用可能なコードライブラリなど）は企業全体の効率性に広範囲に及ぶ影響を与えるからです。

このスケールで測ろうとしているのは、引き算の人から足し算の人への移行（0.0から1.0）と、足し算の人から掛け算の人への移行（1.0から2.0）、さらに「ローカル」から「グローバル」な掛け算の人への移行（2.0から3.0）です。「割り算の人」（例えば高いスキルを有するエンジニアであるかもしれません。先ほど述べたように、例えスコア2.0以上のエンジニアであったとしても、パーソナリティに問題があれば「割り算の人」となり得るのです）に関連する要素については、現時点では考えないことにします。これはいわゆる「人事上の問題」（本人がタイミングを逃さずに向上できるか、さもなければ解雇されるか）に相当します。今回は純粋にエンジニアの スキル と、長期的な専門能力の開発という観点に基づいて評価してみます。

大まかにまとめると、このスケールにおける各スコアは次のようになります：

スコア0.0～0.4： 完全な初心者レベル： いわゆる「プログラミング学習中」の人がこのレベルに該当します。はっきり言うと、コードをコンパイルする時トラブルを引き起こすのはこの層の人です。技術的に未熟なので、監督なしではプロレベルの仕事ができません。一般的にプログラミング入門コースの人がこのレベルと言えるでしょう。プロのプログラマとしてキャリアをスタートする学生インターンは、既に0.5もしくはそれ以上を獲得していなければなりません。

スコア0.5～0.7： 基礎を確実に習得しているレベル： 既に「プログラマ」ではあるが、「エンジニア」レベルにはまだ到達していない人を指します。ちょっとしたシステム（コード数でいうと3000ライン程度）は組み立てることができますが、たいていそれらは粗雑でメンテナンスしにくいものになっています。つまりこの層の人にとっては、コードを「確実に扱う」ことは問題なくできますが、書いたコードが効率的にはなっていないことが多々あるのです。個々におけるアーキテクチュアル・スキルが（経験が不足しているので）まだ発展途上である、とも言えるでしょう。優秀な学校を出て、ソフトウェア業界でインターンシップを始めたばかりの学生に当てはまるのがこのレベルです。

スコア0.8～0.9： 足し算の人になりつつあるレベル： このレベルの人は、ソフトウェア開発に付きものである実際的な課題（メンテナンスのあり方や現実的な実行時間等）にまで気を配ることができます。役に立つスクリプトを実装することができ、ソフトウェアエンジニアリングとはどういうものかということをしっかり理解しています。Googleやオンラインの情報を駆使して、開発に伴うちょっとした問題（例えば、よく知らない言語を使ったファイルの入出力方法等）を解決することもできるでしょう。

スコア1.0～1.3： 足し算の人として独り立ちできるレベル： ソフトウェアエンジニアとして十分に能力を発揮できるレベルの人のことを指します。この層の人は、それほど大きくないプロジェクトにおいて、「フルサイクル」－すなわち設計、実装、テスト、統合という一連の工程をしっかり回すことができる、と信頼されています。大体の場合コードは問題のない品質に仕上がっています。ただし、例えば締め切りを守ろうとする意識やプロダクションチームに対するサポート（「深夜3時に働くヤツ」と言われるのはこのレベルの人のことが多いです）、さらには会社レベルからみた課題解決といったことにはまだ責任感を持って対応できていません。1.3レベルのエンジニアで構成されたチームは、確実に良い仕事をするでしょう。（ 平均的な ソフトウェアエンジニアのレベルはだいたい1.1ですし、ソフトウェア関連の仕事の50%はいわゆる、自主性があまり必要とされない「Javaジョッキー」に位置づけられるものです）。でも実際には、その会社の 最も優秀 と言われるエンジニアがこのレベル止まりだと、質の高いソフトウェアがなかなか開発できず苦労することになるでしょう。

スコア1.4～1.6： 正真正銘の足し算の人レベル： ソフトウェア業界全体の基準に従うと確実に平均以上（トップ10%）、ただし、ベストカンパニー（例えばエリートスタートアップやGoogle、もしくはIBMの研究部門）においては平均（5～10年程度の経験を有する）レベルのエンジニア層です。たいていの問題を、簡潔かつメンテナンスしやすいやり方で、自力で解決することができるとみなされています。このレベルのエンジニアは、合理的な稼働時間を見積もり、ビジネスとテクニカル両方の用語を使って、他のエンジニアたちのみならず経営陣ともコミュニケーションを取ることができます。限られた範囲におけるプロジェクトでは、締め切り／納品といったタイムマネジメントに責任を持って対応し、アーキテクチュアルな決定プロセスに寄与することが求められています（いわゆる「掛け算の人」が対応できる課題）。それほど緊急ではないプロジェクトにおける技術面でのリーダーシップ能力の発揮を確実に求められています。

スコア1.7～1.9： 掛け算の人になりつつあるレベル： ソフトウェア業界のトップ5%に相当します。完全なる「掛け算の人」に向かって歩みを進めているエンジニアを指します。この層の人による成果は直近の課題を解決するだけではなく、会社基盤の向上にまで寄与します。アーキテクチュアル面及びプロセス面での向上策を常に検討、提案しています。重要なプロジェクトにおける「テクリーダー」に成長しつつあるのです。

スコア2.0～2.3：掛け算の人として独り立ちできるレベル： チームに対して計り知れない、目に見えて価値のある貢献をすることができる、誰から見ても掛け算の人と認められるエンジニアを指します。明らかなるテクニカルリーダーです。課題解決、アーキテクチュアル面、リーダーシップスキルといった点におけるトップ2～3%のソフトウェアエンジニアです。

スコア2.4～2.6： グローバルで認められる掛け算の人になりつつあるレベル（いわゆる「フェロー」）： この層に属するエンジニアの業績は幅広くて驚くものばかりです。このレベルのエンジニアによる成果は、会社レベル、もしくは更にそのレベルを超えて（例えばオープンソースコミュニティにまで）影響を与えるようなものとなるでしょう。ソフトウェアエンジニアのトップ0.25%に位置します。（完全に自分の思い描く通りに）独自の研究を進めることができ、主要な戦略を率先して進めることができる、と期待されています。

スコア2.7～3.0： 上級フェローレベル： 社内外問わず、現在活躍する優秀なコンピュータ・プログラマの1人と認知されているエンジニアです。新しいプログラミング言語をデザインしたり、すばらしいプログラミング言語を創り出したりすることができるレベルです。

これらのスケールはどのように展開して行けるでしょうか。そしてどんな 現実的な 結論を導くことができるでしょうか。理想を言えば、ここには、ほとんどのプログラマがたどる成長過程が示されているべきです。残念なことに、現在のソフトウェア業界では、 平均的な ソフトウェアエンジニアが1.0以上にたどり着くことはありません。プログラマのスケールの違いは（あくまでも私の推定によれば）、彼らの知能、もしくは好奇心や意欲が考慮されているわけではありませんから、運が悪いとしか言えません。

ソフトウェアは、間違いなく世界で最も 構造的に協力的な システムの1つと言えます。私が「構造的に協力的」と言ったのは、エンジニアの満足度は、この業界にいる他の者の能力と確実に相関性があるからです。彼らが名目上（そして一時的に）「ライバル」であったとしてもです。優秀なプログラマは優秀なプログラマを育てようとしますし、すばらしい技術を作り上げ、オープンソースのコミュニティでそれを公開したりします。反対に 悪い 平均的なソフトウェアエンジニアは、良いソフトウェアエンジニアを苦しめる原因になります。なぜ役立たずの言語（例えばJava）には、関数型プログラミング言語（Scala、Ocaml、Clojure、Haskellなど）よりも、プログラミング（そしてライブラリ）の仕事が多いのでしょうか。なぜなら、Java＋IDEの環境が、個々のエンジニアがスコア1.5以上の影響力を持つことを、非常に困難にさせているからです。過去にJavaでスコア2.0を突破したのは2人だけです。1人は、Scalaを書いたMartin Odersky。もう1人は、Clojureを書いたRich Hickeyです。とはいえ、エンジニアがIDEにとどまり、コマンドライン（しまった！）で コンピュータ （はっ！）を使わない限り、最新技術が0.7や0.9の人を0.1～0.3ポイント上昇させることができます。

悲しいことに、ソフトウェア開発者が「成長できる期間」は約6年です。「平均的な」ソフトウェア開発者のたどる成長過程はこのような感じになります。スコア0.6の頃にJavaスクールを卒業し資格を取得、その後、毎年約0.1ポイントずつ成長していきます。急速な成長ではありませんが（2.0以上であれば、毎年0.1ポイントの成長は非常に速いペースですが、1.0以下の場合はゆっくりなペースです）、教育を受ける場が少なかったり、活気のない環境にいたりすることを考えれば、妥当なペースです。スコア1.2の頃になると、技術の限度に行き着き、個人で貢献できる「プログラミング」の限界を悟るでしょう。ただし、IQが167ある「天才」や（44歳で）プログラミング歴40年という人は別です。これはつまり、Java＋IDEの環境やWindowsのようなオペレーティングシステムは、（0.7から0.9の人を）底上げするようにデザインされているからなのですが、その反面、有能なプログラマの成長を抑え、スコア1.2から1.5の人たちに対して作為的に「限度」を強いているのです。これらの技術は、意図的に それなりの実績 をもたらせるようにデザインされています。つまり、個人で最良のものを創り出すよりも、「平凡な」開発者からなる大きなチームに それなりのもの を創り出すことを可能にしているのです。

もし、『Hacker News』を読む時間があったり、流行りの「関数型プログラミング」を学ぶ時間があったりしたなら、スコア1.5を超えられる信じられない成果過程が（このブログ記事の著者のように天才ではない人でも）見えてくることでしょう。しかし、現実にはそうはいきません。コードを書くだけの「コード・モンキー」として燃え尽き、いずれ管理職の道へと進むでしょう。もしくは、ロースクールやビジネススクールに通うようになるかもしれません。なぜなら、「エンジニアリング」というものには（実際に経験した上で）、限界がありこの先10年続けるには、つまらないものだと誤った結論を出してしまうからです。例えエンジニアとして6年費やしたとしても、まだまだ二流で下位90％にいるプログラマだろうし、いなくなっても誰も悲しむものはいないと考えます。しかし、適切なガイドを得て、優れた技術を打ち出していけば、すばらしいプログラマになれたことでしょう。

これは、「言語戦争」の危機的な現状であり、ソフトウェア業界の構造についての議論です。JavaやC++のような魅力のない言語でコードを書く（ましてメンテナンスではない）のが嫌いだとか、Windowsのようなダサくて品のないオペレーティングシステムが嫌いだということだけではありません。ここにはもっと多くのことが関与しているのです。