もし爆速プログラマーが大企業経営者になったら



と思っていたら、「もし」が現実になっていた。

彼の名は小野和俊。
かつて日本中からスーパープログラマーたちの集まった「未踏ソフトウェア創造事業」で、プログラミング速度で他のプログラマーたちを驚かせたほどの爆速プログラマーである。

『諸君 私はプログラミングが好きだ』という記事 を書いちゃうほどプログラミングを愛してやまない彼は、アプレッソというITベンチャーを起業して成功させた後、今は、3700万人の顧客基盤を持ち、年間5兆円近い取引高のクレジットカード会社、クレディセゾンの常務執行役員CTOをやっている。

その彼が仕事論の本を書いた、という話を聞いて、「私なら、普通の人が読み取れないことも、その本から読み取れるだろうな」と思った。

なぜなら、私は、学生時代から含めて10年ほどプログラマーをやった後、起業して経営者になった経験があるからだ。

プログラマーが経営者になると、世界がどのように見えるか、ご存じだろうか?

私の場合、会社組織の様々な機能や業務が、プログラムに見えた。
法務、営業、人事、広報、企画、デザインなどなど、マネージメントの対象が、プログラムに見えるのだ。

たとえば、法務が上げてきた契約書をレビューするとき。
受託開発したソフトウェアのどの部分に対して、どのような権利を自社が保持することになるのかを記述している契約書の文言が、プログラムに見えた。
法的文書特有の文言で組み立てられたロジックを追いかけて、バグを見つけ、「この文言だと、開発したソフトウェアのライブラリを使って、別の製品を作れないことになってしまう。ライブラリの再利用ができるように、こういう風に修正してみては?」などと法務担当者と議論した。

広報も同じだ。
たとえば、プレスリリースを打つときは、どんな人がそれを読み、読んだ人がどのようなメッセージを受け取り、どのような感情が惹起され、どのようなアクションを行い、それがどのような作用を引き起こすかを計算しながら、プレスリリースの文章のロジックを組み立てていく。
ああ、これは、プログラミングと同じだな、と思った。

デザインも同じだ。
アプリやWebサイトのUIや、パンフレットの色、形、サイズ、配置、余白などの画面要素に、どのような意味や機能を割り当て、導線やUXをどのように組み上げ、最適化していくか。
イケてないデザインのUIやUXは、どこにバグやボトルネックがあるのか。

同様に、企画、ブランディング、マーケティング、営業、人事、総務、経理、財務、どれも、ロジックによって組み立てられた構造に見えるので、それらをプログラムのように組み上げ、リファクタリングし、バグを潰し、ボトルネックを解析してチューニングしていく感覚で、マネージメントしていく。

学習科学においては、「ある文脈で学習した知識・スキルを、別の新しい文脈でも活かすこと」を「転移」と呼ぶが、私の場合、プログラミングで獲得したスキルが、全く別の分野へと転移しまくったのだ。

たぶん、小野さんも、同じだったんじゃないだろうか、と思いながら、彼の本のページをめくると、「やっぱりな」と思うところと、「あ、そうか」と思うところがあった。


まず、「やっぱりな」と思ったところ。

たとえば、彼が管掌することになった部署で、それぞれの社員が、妙に多くのプロジェクトを抱えていた。
そして、成果が出ていない。
成果が出ていないということは、何かがバグってるということだ。
で、社員にヒアリングして、すぐに彼は、「抱えているプロジェクト数がKPIになっている」ことがバグであることに感づいて、将来性のなさそうなプロジェクトをばっさりリストラして、有望そうなプロジェクトに集中してもらうように、KPIを変更した。

もちろん、こういう組織設計バグや人事評価バグは、大企業でよくある話だが、これを実名で本に書くのは、それなりの覚悟がいる。
なぜかというと、こんなことが本に書かれてしまうと、「抱えているプロジェクト数」などというアホなKPIを設定した前任者は、メンツを潰される形になりかねないからだ。
メンツを潰された前任者は、口では何も言わないが、内心は逆恨みしていて、小野さんの過去の失敗や問題発言をほじくりだして、社内の様々な人間に、それとなく言いふらして、印象付けて回るというような、陰湿なことをしはじめるかもしれない。

実際、一見、過激でアナーキーな発言を繰り返しているかのように見えるインフルエンサーも、自分の所属組織内の権力者のメンツをつぶしかねないツイートをほとんどやっていないが、これが理由の一つだろう。

私の知人に、かつていくつかの企業の経営陣として仕事をしていて、今でも、大勢の経営者に対してコンサルティングをしている男がいる。
彼は、ベストセラーのビジネス書をたくさん書いているが、彼の書いた本より、彼自身と直接会って話した方が、100倍面白いし、100倍役に立つ。
なぜかというと、本に書くことができない、生々しくリアルな話がたくさん聞けるからだ。

小野さんの本も、事情は同じはずで、「彼が本に書けることは、当たり障りのないことでしかないだろう」と思っていた。
ところが、いきなり本の冒頭で、こういう前任者批判ともとられかねない話がいきなりでてきたので、「え? いいの?」と驚いた。

実は、ここに、大企業経営者が本を書く時のジレンマがある。
たしかに、彼らは、読者にとって有益なエピソードをたくさん持っている。
しかし、そのほとんどは、立場上、本に書くわけにはいかないのだ。

そう言う事情を鑑みたうえで、小野さんの本を読むと、その踏み込みの深さが、よく分かる。
ただ、それでも、彼が本に書いたことより、書けなかったことの方が、はるかに多いのは、間違いない。
だから、彼の本を読むとき、「彼が書けなかったこと」を、行間から読み取りながら読むと、この本を、さらに楽しめると思う。


次に、彼の本を読んで、「あ、そうか」と思ったところ。

実は、優秀な爆速プログラマーというのは、ほぼ例外なく、単にロジカルなだけではなく、ロジックを超えたセンスを持っている。
たとえば、原因不明のバグに遭遇したとする。
その場合、論理的に問題を切り分け、さまざまな可能性を一つ一つ潰していくことで、原因を特定し、バグを修正することができる。
しかしながら、それをやると、膨大な時間がかかってしまう、やっかいなバグが、ときどきある。
バグの原因の可能性の範囲が広すぎて、探索コストが莫大になってしまうケースだ。

そういう場合でも、センスのいいプログラマーは、バグの原因を、ほんの数分で見つけたりする。
「どうやって見つけたのか?」と問い詰めても、「いや、この辺が怪しそうだと思ったから」という説明になってない回答しか引き出せない。
いくら論理的に考えても、そこを真っ先に疑った理由がわからない。

一見、長年のプログラミングで培われた職人的な勘のようにも見えるが、それだけでは、とうてい説明できない。
なぜなら、同じだけのキャリアのあるプログラマーのほとんどは、そんなに早くバグの原因を特定できないからだ。

じゃあ、この能力はなんなのか?
いろいろ考えてみたのだが、結局分からず、何か超能力のようなものだと思うしかなかった。

じつは、プログラミングの時間の、けっこうな割合が、この手のやっかいなバグの原因特定に費やされている。
そして、私の知る限り、爆速プログラマーのほとんどは、論理を超えた、超能力じみた直感で、バグを高速に特定する能力を持っている。
彼らの桁違いのプログラミングスピードは、その超能力なしには成立しえないと言ってもいいほどだ。
しかも、彼らは、呼吸をするように自然にそれをやっているので、ほとんどの場合、自分が超能力を使っていることを自覚してない。

そういうエスパーが経営者になったのだから、その超能力を経営にも使うのは、自然な成り行きというものだろう。

たとえば、小野さんは、業務命令でビットコインを配布した。
そして、社員にビットコインを使ってもらった。

そこが事業のボトルネックだと、直感的に気づいたからだ。

もちろん、プログラムのボトルネックと同じように、事業のボトルネックも、要素分解して、ロジカルに突き詰めていけば、特定できる。
しかし、多くの場合、要素数が大きすぎ、探索範囲が広すぎて、ボトルネックを検出するのに、えらく時間がかかる。
というか、ボトルネックに気が付かないまま、非効率な経営をしている経営者は多い。

しかし、彼のことだ、そのボトルネックを検出した速度は、他の経営者よりも、だいぶ速かったんじゃないかだろうか。

ところで、なぜ、ビットコインを配ることが、会社組織のバグ修正になるのだろうか?
いったい、バグの原因は、なんだったのだろうか?

小野さんは、最初はセゾン情報システムズのCTOになり、その後、クレディセゾンのCTOになった。
彼がビットコインを配ったのは、セゾン情報システムズのCTOをしていた時の話だ。

以下、小野さんの本より引用する:

セゾン情報システムズでは、金融関連の事業部でクレジットカードのシステムを作っていたので、FinTechやビットコイン、ブロックチェーンなどは見て見ぬふりはできない領域だった。だが、「本を読んでブロックチェーンの勉強をしておくように」と指示を出したところで、すぐ理解できるものではない。実際に本を読んでみたが「暗号通貨が……」と冒頭に書いてあり挫折した、という声もあった。
だから私は、事業部180人全員に、ビットコインを〝体験〟する場を作ることにした。具体的には、30 人ずつに分けて体験会を6回実施した。

(小野和俊『その仕事、全部やめてみよう』P.36-37より引用)


バグの原因を調べるとき、「これが原因じゃないかな」と思っていても、それを調べるコストが大きいとき、それを調べるのを後回しにして、調べやすいところから先に調べてしまうことが多い。

このビットコインの体験会の話も、それと同じなのではないかと思う。
「これ、もしかして、このテクノロジーを体験していないから、食わず嫌いになってるだけじゃないの?」と、役員同士の雑談で話すことはあっても、たいていは、雑談だけで終わってしまう。
なぜなら、実際に社員に体験させるのは、それなりにコストがかかるからだ。

ここが、優秀な人と、凡庸な人を分ける分水嶺なのだと思う。
凡人が「ここがバグの原因じゃないのか」とぼんやりと思うだけでなにもしないところを、優秀な人は「ここがバグの原因である可能性は、かなり高い」と、より敏感に感じとり、「体験会をやってでも、たしかめてみる価値はある」と判断し、実行に移せるのだ。

凡人にとっては、バグの広大な探索範囲の他の部分と変わらない一項目にしか見えないものが、優秀な人には、「広大な探索範囲の中でも、特に怪しいポイント」に見えるのだ。

プログラミングにおけるデバッグと、問題の構造は同じなのである。

「なぜ、凡庸な人はアイデアを思いつくだけで実行しないのに、優秀な人は、思いついたアイデアを実行するのだろうか?」
という問いに対する答えの一つが、ここにある。

多くの人は、これを「やったもの勝ち」理論で説明する。
「成功しない人は行動しないから成功せず、成功する人は行動するから成功するのだ」という理論だ。
「ようは、やるか、やらないかの違い」だと、彼らは説明するのだ。

しかし、本当に、そうなのだろうか?

優秀な人が、思いついたアイデアをすぐに実行するのは、行動力があるからというより、「そのアイデアに、すぐ実行するだけの価値があること」を見抜く能力が高いからだ。

多くの人が、思いついたアイデアを実行しないのは、そのアイデアが、本当に実行するだけの価値があるかどうかの判断がつかないからだ。

アイデアを思いつくことと、そのアイデアにどれだけ価値があるかを見抜くことは、全く別のことだ
優秀な人材は、アイデアを思いつく能力も高いが、それ以上に、思いついたアイデアに、どれだけの価値があるかを見積る能力が高いのだ。
それが価値のあるアイデアであることが分かっているなら、そのアイデアを実行する決断を下すのは、簡単だ。
当たることが分かっている宝くじなら、誰だって、買うのに躊躇したりはしない。
だから、彼らは、アイデアを実行に移す能力が高いように見えるのだ。

これを、「単に、やるか、やらないかの違いだけだ」と解釈すると、しばしば、悲惨なことになる。
アイデアの価値を見抜けないまま、思いついたアイデアを片端から実行しても、アイデアの価値を見抜いて実行する人と同じように成功できるわけではないからだ。

もちろん、「やるか、やらないかの違い」も大きいので、やらないよりはやった方がマシだが、アイデアを思いついたら、そのアイデアの価値をよく見極めながら実行するようにした方が、はるかに成功率は高くなる。



話を元に戻す。

よく、企業のDXを推し進めるためにITに強い人材を経営陣に迎える企業があるが、それによって実現されるのは、単に業務オペレーションやビジネスのデジタルトランスフォーメーションではない。

それは、コンピューターサイエンスの知見が、コンピューターがなくても活用できることに似ている。
小学生がランドセルにその日に使う教科書を詰め込んで登校するのは、コンピューターサイエンスにおける「プリフェッチ」である。
財布を落としたら、落とした場所を最短時間で特定するためのアルゴリズムは、コンピューターがなくても実行できる。

それと同じように、小野さんのような優秀なIT人材が大企業や政府の中枢に入り込むと、単なるDXをはるかに超えることが起きる。
デジタル化できない部分も含めた、組織全体が、プログラミングの対象として、最適化されていくからだ。

よく、天才プログラマーがIT担当相の台湾のことが話題になるが、優秀なITエンジニアを権力中枢に迎えるというのは、そういうことなのだ。

その意味で、小野さんの肩書が、ただのCTOでなく、「常務執行役員CTO」であるのは、象徴的である。
「常務」とは、「経営幹部として社長を補佐する役割を行う」役職だ。

逆に言うと、大企業や政府の中枢にIT人材を迎え入れる側は、これを念頭に置いた上で、役職と権限を与える必要がある。
デジタル庁を創設するのはいいが、「お前はデジタルが担当なのだから、デジタルだけやってろ。他の省庁の本業には口を出すな」というやり方では、せっかくのIT人材のポテンシャルを引き出すことはできないし、肝心のデジタル化すら、雲行きが怪しくなる。

なぜなら、それぞれの省庁の「本業」のデジタル化をしない限り、本質的なデジタル化など、できやしないからだ。

本業のデジタル化は、トレードオフとの戦いだ。
どんなデジタル化をすれば、何が得られて、何を失うか、得られるものと失うものを天秤にかけて、ぎりぎりのトレードオフを解決しながらでないと、本質的なデジタル改革など、できやしないのだ。
そのトレードオフのつじつまを合わせる責任は、それぞれの部署の責任者にあるのだから、外部のデジタル化担当がいくら正論を唱えても、現場は動かない。

結局のところ、デジタル化を担当する別部署を設けるより、実業務を行っているそれぞれの部署のトップにIT人材を据えた方が、はるかに深く、本質的なDXができるし、DX以上のことができるようになる。

この意味で、小野さんよりもむしろ、小野さんのような優れたIT人材を経営陣に迎え入れ、大きな裁量権を与えたクレディセゾンの経営陣の英断が際立つ。
不足しているのは、千里の馬よりも、伯楽の方なのだ。

もちろん、「IT人材だけが唯一の優秀な人材で、それ以外は優秀な人材たりえない」などということは全くないし、そんなことを主張するつもりも全くない。
そうではなく、「優秀なIT人材」なるものが、具体的にどのような特質を持った人材なのか、案外、その実態が知られていないし、IT人材を活用するつもりなら、それをよく把握した上で活用した方が、はるかに物事が上手くいくということを、知ってほしいのだ。

日本の未来は、ある面では、各自治体や政府のトップが、そこまでふまえた上で、クレディセゾンの経営陣のような英断をしてくれるかどうかにかかっている。

つまり、我々有権者が、そういう英断をしてくれる政治家に投票するかどうかで、日本の未来は変わる。
未来は、我らの手の中にある。

さあ、みなで、よりよい未来を選ぼうではないか。






この記事は、 面白文章力クラブ のみなさんに添削していただきながら、書きました。

筆者(ふろむだ)のツイッターは こちら



ちなみに、小野さんの本は、Amazon1位(投資・金融・会社経営の参考図書・白書)になりました。




また、偶然ですが、私も、最近、本を書きました。
以下の科学的学習法の本で、おかげさまで、Amazon総合1位(無料)になりました。



英語学習者、教師、受験生、小学生~大学生の親御さんが対象です。
さまざまな科学研究の知見を駆使して、学習効率をチューニングしていく方法が書いてあります。

これは、いわば、プログラマが書いた科学的学習法の本です。
私には、論文がプログラムに見えるので、プログラムを読むように論文のロジックを追いかけ、さまざまな学習法もプログラムに見えるので、プログラムをチューニングするのと同じ要領で学習効率をチューニングしています。
その結果、出来上がったのが、本書です。

平易に書かれており、中学生や高校生にも好評です。
第1巻は、Kindleで無料で読めますので、ご興味のある方はどうぞ。










©2020 ふろむだ