最近、つくづく自分がプログラマーで良かったな、と思うことがよくありました。

経営者をしていると、自分がプログラマーであることがとても異質に感じられる時があります。

もちろん私自身は、もう製品にするためのプログラミングをすることはありません。

私が製品のプログラムを直接いじることになれば、それは私自身がプロジェクトのボトルネックになってしまうからです。

しかし、だからといってプログラミングを全くしないというわけではなく、私自身は会社の方針を決定するために常に簡単なプログラミングをしています。

意思決定のためにプログラミングをすることが必要なのです。

この業界は新しいことが次々に起きます。

Microsoft のHolo LensやOculus RiftなどのVRヘッドセット、そしてディープラーニング。

UEIでは、社長の私自身も、副社長の水野拓宏も、経営陣は二人ともプログラマーです。

そして実際に自分の手を動かして、最先端の技術動向を掴み、事業化していくのです。

先日ビックサイトで行われた「スマートフォン&モバイルEXPO」にて発表したVR(仮想現実感)コンテンツ制作ソリューション、「VRider(ブイライダー)」は非常に大きな反響を呼びました。

これは、副社長でCTOの水野が、自らプログラミングと撮影、データの再構成を担当したからこそ実現できた事業です。

こういう形の、奇妙なカメラを使い、これを独自の方法でつなぎあわせ(スティッチ)して動画のまま仮想現実空間を作り出します。

実際に体験してみるとわかりますが、これまでVRと呼ばれていたものとは次元が一つ違った感じになります。

実際、この分野では先端を行く理化学研究所の藤井直敬博士にも大変驚いていただき、各方面への応用が期待されています。

これは直近の代表的な例に過ぎませんが、弊社で手がけているディープラーニング(深層学習による人工知能)の事業も、やはり私自らが手を動かしてディープラーニングにできることと出来ないことを見極めた上で、初めてビジネスとして成り立っています。

技術には2つの側面があります。

ひとつはどのようにそれを実現するか、ということ。私はこれを「HOW」と呼んでいます。

もうひとつは、その技術によって、何を解決するか、ということ。私はこれを「WHAT」と呼んでいます。

現場のプログラマーが集中するのは、主にHOWの部分です。

VRをどう実現するか、ディープラーニングによる人工知能をどう実現するか、それは全てHOWの技術として集約されていきます。

しかしWHATということに関して、これを決めることができるのは経営マインドだけです。

つまり、HOWを抑えた上で、どのようなWHATとエンゲージメントすれば、それがビジネスになっていくのか。

さらに言えば、そのWHATを実現するためにはどのようなHOWをエンジニアがマスターしなければならないか。

時代に適応した新しいビジョンを示し、エンジニアたちに「次に取り組むべきはこのHOWである」と語りかけ、そして同時にどのような仕事に結びつけるかというWHATを探し当てるのが、私達経営陣の仕事です。

気が付くと社内のあちこちにVRヘッドセットやドローン、Kinectなどの空間認識装置、ディープラーニング用の大容量メモリとCUDA対応のGPUを搭載したマシンがいくつも深層学習を始めていました。あっと言う間です。

私達の強みは、経営陣が二人ともプログラマーであることなのだ、と改めて認識しました。

経営層もマネジメント層もプログラマーです。

プログラマーは問題の複雑さを適切な単位まで分解して理解することが得意です。

悩んだり躓いたりして、手を動かし、汗をかきながら現場のエンジニアとディスカッションをして、あるべきビジネスの方向性を考えていくのです。

こういう経営の仕方は、おそらくプログラマー以外にはできないでしょう。

プログラマーとそれ以外の人ではビジネスに対する視点が違うというのもそうかもしれませんが、これだけ時代がめまぐるしく動いている時に、時代の先を読むには、先を読もうと目を凝らすよりもむしろ積極的にその先を創りだそうとしていかなければなりません。

奇しくもアラン・ケイが断言したように、「未来を予測する最善の方法は、それを創りだすことだ」ということなのでしょう。

プログラマーの強みは、無知の知があることだと私は思います。

プログラマーほど、自分に何が出来ないかを自覚する職業はないからです。

ある新技術があったとき、それを習得していない自分は「無知である」とハッキリ自覚できます。

次に、それを使いこなそうとしたとき、「使いこなせていない自分」もまた自覚できます。

プログラミング言語ひとつとっても、C、C++、Java、PHP、Ruby、Haskell、Objective-C、JavaScriptといった定番的な言語から、Swift、Erlang、Elixir、Coq等など、新しい言語、変わった言語がどんどん出てきます。

こうした新しい言語や環境が出てきた時、現場のプログラマーは二つに分かれます。

ひとつは、新しい言語や環境を積極的に使いたいと考える一派と、逆に新しいものを毎回覚えていたらきりがないと保守的に考える一派です。

新しい言語や環境は、従来の手法の問題点が改善されているため、上手く使えばとても有効ですが、そのかわり、過去に動いた実績が乏しいため、情報が少なく、きちんと動かなかったり、新人を教育するのが大変すぎて誰も引き継げなかったりします。もっと最悪なのは、その新しい言語や環境を作っている人が飽きてしまってプロジェクトを投げ捨ててしまうことです。これは意外とよくある話で、これに巻き込まれると非常に大きなロスとなります。

しかし一方で、保守的になりすぎると、非常に非効率的な仕事のやり方を続けることによって時代に取り残されてしまいます。

経営者が自ら技術的な判断をせず、プログラマーに任せきりにしておくと、技術系企業は簡単に方向性を見失います。

気が付くとチームごとに異なる環境と異なる言語、異なる方針でプログラムが作られ、新しいチームを作る度にプログラミング言語の習得からやり直さなければならない、などということが容易に起こり得ます。

また、時代遅れな設計は、そのプロジェクトが失敗したときはあまり問題になりませんが、成功したときには大問題になります。

プログラムというものは、少人数しか使わないもの(つまり成功していないもの)はどれだけ中身が適当でも動いてしまうのですが、大人数が使うようになる(つまり成功してしまう)と、途端に細かい設計ミスがアダとなってプロジェクトは成功しているのに技術的負債が膨大に膨らむ、という性質を持っています。

これを適切に判断できるのは経営層だけです。

だから技術系企業の経営者はプログラマーであるべきなのだと思うのです。

ある新技術を取り入れるべきか、そうでないか。

それを使ってどのようなビジネスができるか。

それを判断できるのは、やはりプログラマーだけだからです。

プログラマーでないとその仕事がどの程度大変なのかわからないわけです。

そして実際に手を動かしてみないと、その技術が他社に対して優位性を持てるかどうかも判断できません。

優位性が判断できなければ、そもそも勝負にならないわけです。