忘年会シーズン真っ盛り。
　筆者も取引先やら友人の送別会や栄転のお祝いなど、まさに走り回る毎日を過ごしています。

　昨日も、吉祥寺の成蹊大学で今年最後の授業を終えた後、そのままクルマで有明のイベント会場まで行ってUEIリサーチが所属するドワンゴの忘年会に少しだけ顔を出し、とるものもとりあえず六本木一丁目のステーキハウス「格之進」で友人の転職記念サプライズパーティに参加するという慌ただしさでした。そして当たり前のように祝日の今日もイベントがあります。

　毎年、年末になるととかくお酒を飲み過ぎて体調を悪くするのですが、昨日は自動車移動だったためお酒を一滴も飲まずに済みました。非常に美味しそうなステーキがどんどん出てくるというのに全くお酒を飲めないというのもなかなか辛いものがありましたけどね。

　さて、年末といえば大掃除です。

　Facebookのタイムラインに古くからの友人が珍しいものを見つけてアップロードしていました。

　それはA4三つ折の小さなチラシです。

　これは16年前、私がまさに平凡なプログラマーを辞めて駆け出しの企画者として覚悟を決めたときの記念碑的作品のチラシでした。

　22歳だった私は、自分のプログラマーとしての能力の限界が案外低いところにあることを知って伸び悩んでいました。

　プログラマーがプログラマーたる所以は、いくつかあると思いますが、そのうち最たるものは、好奇心だと私は思います。

　好奇心こそがプログラマーを駆り立て、そして好奇心の次には挑戦心がプログラマーを時には過酷とも思える開発に没頭させるのです。

　私にとって、プログラミングとは冒険でした。
　未知への興味、そして見知らぬ概念を自分のものとし、征服していく快感。

　当時の私は、7才の頃からプログラミングを初めて15年。ゲーム開発、コンピュータグラフィックス、人工知能、データベース、プログラミング言語の開発・・・一通りの冒険を全て終えてしまって、さあ、次は何をすれば良いのか、といざ考えると、挑むべき目標を見失って呆然としていました。

　Microsoftのゲーム機向けOS、WindowsCE for Dreamcastのヒリヒリするような緊張感に満ちた開発も一段落し、私はプログラミングの最前線から身を引くことを意識していました。

　人間が一人でできるプログラミングの規模には限界があり、その限界を突破するにはチームを組まなければならないこと。そして、チームを組むためには、それに見合うだけの収益を生み出す構造を必要とすること。

　今振り返ればごく当たり前のことですが、大学を中退したばかりの筆者にとっては大きな学びでした。

　そのとき初めて私は、いちプログラマーの視点ではなく、マネジメントとマーケティングの必要性を意識したとも言えます。

　そしてもう一つの疑問がありました。
　様々なゲームの開発現場を見ていた筆者は、ゲームプログラミングが一人の人間によって行われていた牧歌的な時代から考えると遥かに複雑化、大規模化しているというのに、ゲームの面白さという根源的なものそのものは、たいして研究されていないということです。

　ゲームプログラミングやそれにまつわる素材は大規模化しているのに、ゲーム性そのものは進化していないということに非常に大きな興味を覚えました。

　そこでゲーム性そのものを追求するために、必要なものと必要でないものを分離し、本当にゲーム性を実現するために最低限必要なものだけに集中してみようと思いました。

　今思えば、これは「リーン・スタートアップ」で語られている、MVP(Minimum Viable Product)の考え方に似ています。必要最低限の機能だけを持った製品をつくり、顧客に提供していくことで仮説をひとつずつ検証していくのです。

　筆者は当時発売されたばかりのインターネット機能付き携帯電話、iモードを入手して、「これは自分の仮説を証明するのにピッタリのデバイスだ」と直感します。

　当時のiモードの画面は数行の文字と、モノクロ二値のgif画像しか表示できない非常に非力なものでした。

　しかし、インターネットに直接繋がることと、ダイアルアップを経由せずともインターネット経由のEメールが直接リアルタイムで受信できること、などに大きな魅力を感じました。

　今では信じられないことですが、iモード以前の携帯電話では、インターネット接続機能があるといっても、ダイアルアップ・・・すなわち、どこかに電話を掛けて、ハンドシェイクしてからでないとインターネットにアクセスすることができませんでした。ハンドシェイクには通常数十秒かかり、しかも、通信中は通話料を払わなければなりません。これではとても気軽にインターネットができるとは言えませんでした。

　ドコモが全国に整備したパケット網(DoPa網)を活用することで、iモードはこの制約を打ち破り、送受信した情報量に応じたパケット課金を採用して、リアルタイムの通信を実現したのです。

　この極端に制限された状況では家庭用ゲームコンソールのようなリッチなコンピュータグラフィックス表現やサウンド、ムービーなどは一切使うことが出来ません。

　しかし、Webサーバー側に十分複雑なプログラムを用意しておけば、アクションゲーム以外のほとんどのゲームは表現できます。

　当時、Webサーバーのプログラムといえば、簡単なアクセスカウンターと掲示板くらいなもので、本格的なゲームプログラムというのはほとんどありませんでした。

　数少ない例外が、バンダイの「トレジャー・オブ・ゲノム」で、これはWebブラウザだけで遊ぶターン制のカードゲームでした。いわば、昨今のソーシャルゲームの原型とでも言うべき作品です。

　それでも美麗なカードの表現などはPCで遊ぶ「トレジャー・オブ・ゲノム」と携帯電話のモノクロ画面で遊ぶゲームでは比較になりません。

　私は知恵を絞り、いくつか実験的なゲームをiモード向けに開発しました。

　そこで気づいたのは、表現力に制約がある環境では、極端に短い期間で開発が完了することです。

　逆に言えば、できることが少ないので、プログラミングがどれだけ複雑になろうと、自分一人で全て出来てしまうのです。

　最初のゲームは24時間で完成しました。
　次のゲームも、やはり24時間です。

　家庭用ゲームコンソールの世界では考えられないほど短時間で一つのゲームが完成します。

　これは凄いことだ、と思いました。
　ほどなくして携帯電話向けのゲームビジネスは莫大な利益を産み始めました。
　最初のきっかけは、このチラシにあるような釣りゲームでした。

　これはiモードのリアルタイムな特性を活かしたゲームで、仕掛けをしたら魚がかかるまで電話を切って待つという奇抜なアイデアが評価されました。そしてこの時こそ筆者は一介のプログラマーをやめ、自分の考えを別の人に伝えて実現してもらう、プランナーへの道を踏み出した第一歩となったのです。

　私は結局、プランニング(企画)と、プログラミングはレイヤー(層)の違う同じ仕事だということに初めて気が付きました。さらに上位の概念として、マネジメント、そしてマーケティング、ストラテジーがあります。

　これらは全て同じ仕事です。
　ただし、上位概念に移行するほど抽象度が高くなります。

　プログラミングは、最も具体的な「思考の整理」作業です。抽象的な指示を受けて、それを具体的なものに落とし込んでいくのがプログラミングです。

　さらに、プログラミングそのものにもレイヤーがあります。

　世の中には一口にプログラミングを商売にしている人がいると言っても、様々な階層のプログラマーが居ます。

　そして面白いことに、プログラマー人口はより抽象度の高いレイヤーの方が多くなります。
　この図では、スクリプトのプログラミングだけを行うプログラマーが最も多くなります。

　ここでいうスクリプトとは、RubyやPython、PerlやPHPといった言語で、多くの場合、大学生のアルバイトにも書けるような単純なものです。他の層に比べると訓練がほとんど不要で、小規模なチームでも大きな成果を簡単に得られることから人気のある職種です。

　スクリプトより少しだけ高度なことをするためには、より具象的な言語、高級言語と呼ばれる階層の言語を使います。

　高級言語とは、C、C++、Objective-C、Java、Lispなどの言語で、スクリプトが大部分の処理を隠蔽しているのに比べると、高級言語はより実際の計算処理に近い部分を意識したプログラミングになります。最近はCPUがパワフルになってきたので高級言語にもスクリプト言語のような抽象的かつ効率的な言語機能を取り込もうという動きもあるので、高級言語とスクリプト言語の境界はやや曖昧になってきました。

　スクリプト言語のプログラマーに比べて、高級言語のプログラマーは少なく、また一般に高給と言われています。それだけ複雑なことをしているからです。また、正しい知識がなければきちんと動作するプログラムを書くことが難しいのもこの領域です。

　全てのスクリプト言語は何らかの高級言語で記述されており、全ての高級言語は、様々なプロセスを経て必ず機械語(マシン語とも言う)で実現されています。なぜならコンピュータのCPUが理解できるのは唯一、機械語だけだからです。

　機械語は、しかし16進数の味気ない羅列です。これを直接読み書きするのは人間業ではありません(でもそれができる人間もいます)。そこで機械語を人間でも扱いやすいように一対一で対応するように単語を読み替えたのがアセンブリ言語と呼ばれるものです。アセンブリ言語によるプログラミングは機械語によるプログラミングと同等のことが出来、コンピュータの持つ潜在能力を文字通り限界まで引き出すことが出来ます。

　今やアセンブリ言語はほとんど使われていませんが、今でもOSの内部など、本当にコンピュータの性能を引き出さなければならないところには使われています。

　さらに奥に行くと、ハードウェアとソフトウェアの中間層、ファームウェアがあり、さらに追求しようとすると、最下層には電子回路があります。この場合の電子回路とは、CPUを構成する内部の論理構造を含みます。最新のCPUには56億トランジスタという膨大な数のスイッチが使われており、それを全て設計するのがこの層です。

　当然、そのレベルの回路を設計できる人間は全人類の中でもほんの一握りしかいません。

　
　こうして考えると、この業界全体の人口比でこの構造を俯瞰するとこんな感じになっています。

　最高レベルのエンジニアは言うまでもなくこの図の最下層に位置するハードウェア(電子回路)の設計者です。

　そして平均的なエンジニアはこの図の中間層にあたるスクリプトのプログラマーです。
　プログラマーとペアになって束ねるプランナーは、直接エンジニアリングを担当しないものの、プログラマーに対して具体的な仕様書や企画書を示すという意味ではかなり具体的な仕事です。

　これが非エンジニアとしては最下層の仕事ですが、人数が最も多いのもこの領域です。
　より抽象度が高くなり、マネジメントになると複数のプログラマーまたはプランナーからなるチームを組織し、さらにマーケティングは複数のチームを組織してどのように市場を開拓していくかというより抽象的な思考が必要とされます。これは明らかにプランナーやマネージャーよりは難易度の高い仕事で、当然、人口は減ります。

　そしてどのような製品を作り出すべきか、そもそもどのような仕事をするべきかという全体の戦略(ストラテジー)を決める経営陣がその組織では最も人口が少なく、最も抽象度が高い仕事をしていると言えます。

　この直線的な構造を意識する限り、どのレイヤー(層)に属する人も、実際にやっていることは「プログラミング」でしかないことに、筆者は気付きました。

　この図で最底層に示されるような電子回路を設計する、ごく一握りの最高レベルのエンジニア(エンジニアの世界では低層に近づくほど難易度が上がるので、低レベル処理のエンジニアの方がより敬意を払うべき存在として尊敬されます)でさえ、機械語を物理法則に則った組み合わせに変換する、いわばプログラミングを行っているにすぎないのです。

　エンジニアとしては最も難易度が低いスクリプト層では、ほとんど全てのものがなんの不安定性(フラジャイル)もなく動作することが前提とされます。これは人類が長い年月を経て勝ち得た安息の地です。しかし低層に行けば行くほど、予想外の事態が置きます。割り込み、電子回路の不調、宇宙線による回路への干渉、温度変化による抵抗値の変化、などです。

　非エンジニアとしては、上位層に行けば行くほどやはり不安定性が増していきます。

　マネージャーはチームメンバーの仲違いやパワハラ、セクハラ、急な欠勤や病欠、身内の不幸などでスケジュールが遅延したり、新たにハイアリングしたりすることに頭を悩ませます。この様は、まるで低レベルのエンジニアが宇宙線の干渉や物理的なハードディスクの破損、一時的な電圧降下に悩まされることを彷彿とさせます。

　マーケティングやストラテジーを決定する層になると、もはや社内ではなく社外の社会情勢や競争相手の動向、思わぬ競合の出現といった不安定要素に悩まされることになります。

　つまり、マネジメント層もエンジニア層も突き詰めれば同じ組み合わせ問題を解決するプログラミングという仕事であり、私は平凡なプログラマーとして生きるよりもプログラマーたちに対して彼らの立場を理解した上で抽象的な指示が出せるマネージャーになることはできるかもしれない、と思い至ったのがまさにこの頃でした。
　

　たとえスクリプトを書く層のプログラマーであったとしても、より下層の知識、高級言語やアセンブリ言語、ハードウェアの知識があるとないとでは書けるプログラムの質に大きな違いがあります。スクリプト言語しか書けないプログラマーと、下層の言語も使おうと思えば使えるが、敢えてスクリプト言語を使うプログラマーとの間には大きな差があります。

　いわば、児童文学の作者と、小学生の作文くらいの違いです。

　児童文学の作者は小学生でも読めるような平易な日本語で物語を書くことができますが、実際には大人が読めるような本格的な文章の書き方も心得ています。

　小学生はあくまで自分の乏しい経験と語彙から作文を書くしかないので、児童文学者の書く文章と似てはいても決定的に質が違います。

　エンジニアがより下層の知識と経験を持っていたほうが有利というのはまさしくそういうことです。
　

　だとすれば、プランナーやマネージャーが、そしてマーケッターや経営者が、エンジニアの知識を持っていた方がより質が高い指示が出せるのではないかと考えるのはごくごく自然なことでしょう。

　そして筆者はまさしくそれを確かめるために、現場のプログラマーを引退し、専業プランナー、そしてマネージャー、マーケッター、経営者への道を志すことにしたのです。