特定の領域や特定のチームの中のナンバーワンな人、ラストマン
小野和俊氏：今日は3つの話をしますが、1つ目は“ラストマン戦略”です。これは私の造語ですが、だいぶ前にブログに書いて、今でもよくメンバーに言っている言葉です。ラストマンというのは、チームのある人に聞いたけれどわからないので、「あの人もっと詳しそうだな」という別の人に聞いて、一番詳しそうな人に聞いてもわからなければ、もううちの会社にわかる人はいない。
または、チームにわかる人はいないのではないかというラストマンスタンディング、最後に立っている人のことです。ある領域、あるチームの中のナンバーワンな人になっていこうという話です。
いきなり日本でナンバーワンとか、アジアでナンバーワンとか、世界でナンバーワンとか、会社のナンバーワンでもちょっと怖いし、難しい感じがします。しかし、例えば同期の3人、仲良し3人組の中で一番であれば、「これができなかったら、ぜんぜん向いていないということなのでは」と思えるわけです。
最初は小さなグループで、ある領域の一番を目指す。それがクリアできたら課の中で一番を目指し、それもできたら今度は部の中で一番、それもできたら事業部の中で一番、それもできたら会社の中で一番、それもできたら日本の中で一番というように、段階的に向いているかどうかを確認して、合っているならもっと進んでいく。小さなところから始めて、ラストマンになっていくという考え方です。
小野氏の“ラストマン戦略”実体験
この言葉は、すごく実体験かつ失敗談に基づいています。先ほど紹介したように、1999年に新卒でサン・マイクロシステムズに入りました。サン・マイクロシステムズはJavaを作っている会社で、私はJavaをやりたかったので、きっとJavaのソフトウェアを書く日々が待っていると思って受けて、そのまま入社しました。そうしたら、ぜんぜん違う。ハードウェアを売る営業拠点みたいな場所だったんです。それで「え？ うちでソフトウェア開発なんてできると思ってたの？」と言われて「えー?!」となった。要するに間違えて入ったわけです。
これはいわば、野菜が好きなので八百屋を夢見て「八百屋に入りたい」と思って入ったら、肉屋だった。ぜんぜん違う会社だったんです。Javaのソフトを書こうと思ったら、ハードウェア屋さんだった。サンのハードウェア、サーバーを売っている会社だったんです。同期の中にも同じようにJavaのソフトをやりたくて入ってきた人がいましたが、大きく3つに分かれました。
1人目は、間違えたけれど新卒で入ったからしょうがない、「ローマに入りてはローマに従え」ではないが、自分はハードウェア屋を目指す、ハードウェアに方向転換をする人。2人目は「いや、まだやり直しがきくから、第2新卒として本当に自分がやりたい会社をもう一度受ける」と転職活動を開始した人。3人目はわりとラストマン戦略的で、「間違えたがハードの会社なら、その中でソフトの一番を目指すのは比較的やりやすいのではないか」と思う人です。
もし八百屋と肉屋しかない時代に、野菜を売りたい人が間違えて肉屋に入って、肉屋で野菜も売り始めたら、スーパーマーケットという業種・業態が誕生するかもしれません。そういう発想、「ここで一番になれるチャンスかもしれない」という見方が私自身の当時の考えでした。
“谷”は他の人に勝てない、負けちゃうところ。“山”は自分の得意分野。ソフトウェアのナンバーワンを目指すのはそんなに簡単ではないということが、ある程度すぐわかったんです。当たり前の話ですが、当然Javaを作っている会社でもあるので、ハード中心とはいえ、やっている人はゼロではない。詳しい人はUnixもメチャクチャ詳しいわけです。
その人たちにすぐ勝つことなんてできないことが早々にわかりました。しかし、私は大学時代に野村総合研究所でシステム開発のアルバイトをしていて、最後は契約社員になりました。XMLは98年にW3Cのレコメンデーションになりましたが、その前からparserなどをバンバン書いていたので、XMLであれば一番になれるかもと思いました。「じゃあXMLのラストマンになろう」ということで、XMLのラストマンを目指しました。
その結果、私はXMLのメーリングリストを作り、社内の「XMLとは」「XMLはなぜ必要とされるのか」といったこともやりました。ちょうどXMLのW3Cチェアマンをやっていたジョン・ボサクもアメリカ本社にいたので、サン・マイクロシステムズとXMLは無関係ではなかったんです。
「やたらXMLに詳しい新人がいるらしいぞ」と噂になったことで、日本の法人の中でのラストマンになれそうだと思い、XMLのラストマンを目指しました。結果的に、新人研修が終わる頃には「XMLのことならあいつに聞け」というブランディングができていたので、晴れてアメリカ本社の仕事の機会にも恵まれました。このような実体験から、ラストマン戦略を掲げています。
身近な例で言えば、みんな高校生の時に勉強した経験があると思いますが、英語を伸ばしたいと思ったら、まず何人かの仲間の中で「お前、最近英語すごいらしいじゃん」を目指してみる。それができたらクラスのトップ目指す。それもできたら今度は…という感じで範囲を広げていくわけです。
たとえ仲間内でさえ英語のナンバーワンになれなかったとしても、ヒアリングや特定分野の単語は詳しいというように、もっと細分化すればナンバーワンになれる可能性が上がっていきます。いろいろ工夫してもダメなら、要するに「向いていない」ということなので、別の分野にピボットすることを検討したほうがいいと思います。
ラストマン戦略の特徴は、少なくとも仲間内でも一番になれたら「すごいじゃん」って言われるし、私がサン・マイクロシステムズの新人の時にそうだったように、新人でも「お前、XMLはすごいじゃん」と言われれば、「がんばろう」という気持ちになれる。敬意を払ってもらえることが、がんばろうという気持ちにもつながる。（スライドを指して）さらに、この1、2、3のように、最初の目標は低いから「実現できそう」と実感が持てる。
2つ目の低い目標でさえ実現できない場合は、要するに向いていないので、早めに方針転換できる。いつも「無理だ」と言われながら目指し続ける、悲壮なことにならずに済みます。目標は段階的に高くなっていくので、自信をつけながらストレスなく成長できます。決死の覚悟や背水の陣ではなく、カジュアルにナンバーワンを目指せるので、いろいろな方におすすめできる方法だと思っています。
セゾン情報システムズでの“ラストマン戦略”事例
私の事例だけで、具体例がないと説得力がないと思います。5年前の話ですが、セゾン情報システムズの時に「誰がラストマンになる？」というスキルマップを実際に作りました。
おもしろいのが、当時セゾン情報システムズではバイモーダルインテグレーターにならなければいけないということで、（スライドを指して）ここに挙げたことに関するラストマンを募集しました。それまで金融系メインフレームのCOBOLの運用保守しかやったことがない人が、おもしろそうだからブロックチェーンをやってみたいと、この取り組みの中で手を挙げてくれたんです。
結果的にどうなったか。当時Uhuruという会社に、IoTパートナーコミュニティというワーキンググループがありました。ブロックチェーンのラストマンに手を挙げた、これまでずっとCOBOLやっていた人がラストマン戦略によって、半年後にはブロックチェーンの宅配ボックスをUhuruやGMOと組んで作ることになり、開発のかなり中心的な部分を担うところまで一気に成長しました。
当時、Ethereumを使っていましたが、短期間でドン・キホーテやパルコにこのブロックチェーンの宅配ボックスの開け閉めのすべてを、分散台帳に刻む人になれてしまった成功事例もあるんです。
ほかにも続々とこういう人が誕生していました。それまでやってきたことや経験は関係なく、ラストマン戦略がピタッとハマると、実際にこういうことが起きるわけです。ですので、何かに強くなるための作戦や戦略として検討してもらえると、まさにデジタル時代のエンジニアとして活躍していくうえで参考になるかもしれません。これが1つ目の話です。
プログラマー風林火山
2つ目の話は“異なる文化と向き合う”がテーマです。昔ブログに書いて少し話題になった“プログラマー風林火山”。プログラマーだけで考えても、やはり優秀なプログラマーは多様です。例えば、私自身はずっと風のプログラマーを志してやってきました。「とにかく早い」「設計も実装もメチャクチャ早い」。「あの人がいると（私がやると）他社よりも早く新機能が出た」「新製品が早く出る」など、スピードをもたらしてくれるプログラマーもいます。
一方、林のプログラマーは、どちらかというとプロジェクトマネジメントに強い人です。やはりトラブルはつきもので、その時は現場がワーッとなりますが、「まあ落ち着け」と。チームに乱れぬペースや冷静さをもたらして、「まあ落ち着こう」と言いながら、次に何をやるべきなのかを冷静に判断する。静けさと客観性のようなものをもたらす、そういう強みを持ちながらプログラミングができるプログラマーもいます。
ほかに、新しい技術や強さやフレームワークなどをどんどん見つけてきて、ナイトリービルドであろうがなんだろうがどんどん使っていく。情熱を持って新しいものをどんどん見つけて、その強みを自分たちの強みとして取り入れていく。これを火のプログラマーと呼んでいます。また、「あの人が見るとよくバグが見つかる」「本当にすごい」といった、品質・堅牢性に関して、安定性をもたらす能力が高いプログラマーもいるわけです。
「風や火は苦手だが、山でならラストマンになれるかも」というように、プログラマーの中だけでもラストマンになれる要素のベクトルはいろいろあると思うんです。なかなか全部というわけにはいきません。これがプログラミングではなく、もっと文化的なものになると、よりマクロなレベルの違いを認めて、その違いを受け入れていく必要があります。
先ほどの風林火山にもラストマン的にも言えますが、例えば山のプログラマーは風や火がない分、「自分なんて」となりがちですが、まったくそんなことはありません。それぞれの違いと良さを認めていく。まさにダイバーシティ・アンド・インクルージョン的なことが、このプログラマーのベクトルでもあります。
会社全体の文化のモード1、モード2
（スライドを指して）会社全体の文化でいうともっと大きな違いがあります。
（スライドを指して）それがこの2つです。私自身がずっとスタートアップという感覚でやってきた中で、私がもともと持っている感覚は右側のモード2で、ベンチャーのスピード感とアジリティと技術力、風通しの良さ、個々の能力を最大化して事業の強みにつなげるような、そういう世界です。
しかし、セゾン情報システムズに入って私が体験した世界は、どちらかというとモード1でした。今、日本の企業に勤めていて、しっかり堅くやっているSIerの方には、モード1の会社の方も多いと思います。
要は、基本的にウォーターフォールなやり方が主流で、コンプライアンスやガバナンスはしっかりと安全性重視で、IT部門が集中管理しないと危ない。予測可能な業務をしっかりやっていく。ROI（Return on Investment）を一つひとつきちんと見て、稟議書なり決裁書なりを書く。このやり方には強みもあります。トップダウンや個々人の意見ではなく、問答無用でみんなでやる時には、こちらのやり方のほうが合理的です。
「隣の芝生は青い」ので、モード1から見れば「自分たちもモード2みたいに」となりがちですが、両方それぞれに良さがあります。モード2にも弱点があります。やはり安全性や確からしさみたいなものは、モード2よりモード1のほうにあるんです。両方やってきて、本当にそう思います。
モード1は武士に例えられます。鎧を身にまとっているから安全性が高く、手裏剣が飛んできても大丈夫、致命傷には至らない。ただその分、動きは遅くなりがちです。でも、鎧を着ていることが必ずしも短所ではありません。かつ、責任の所在を強く求めるので、何か大事故が起きると「設計者は誰だ」と言われ切腹させられるといった話もありますが、そういうカルチャーがモード1にはあるわけです。
モード2は忍者に例えられます。スピードと柔軟性があり、敵の城壁もバーッとよじ登ったりできるけれど、まきびしを踏んづけて転んで、頭のところにまきびしがあったら死んでしまうかもしれない。やはり、そういう危うさがあるんです。
この両方の良さを認めていくことはすごく美談で正論ですが、簡単にできるかというとそうではありません。なぜなら、この両者を交ぜると喧嘩をするからです。モード1の人はだいたい、モード2の人に対して「なんですか、あの人たちは」「いつも金髪だし、短パンだし、サンダルだし。画面を見るとFacebookで“いいね”しているかslackでチャットしているか。なんですか、あの人たちいつも遊んでて！」となりがちです。
そして、モード2の人がモード1の人を見ても、「なんですか、あの人たちは」となります。「いつも上の命令は絶対で、やたら真面目で個人の意見はぜんぜん言わない。会議でも発言しない。なんなんですか！」となりがちです。
私が聞いた中で一番強烈だったのは、モード2の人がモード1の人に対して「小野さん知っていますか？ うちのチームのあの人たちは、恐竜の化石の中でもとりわけ動きが遅い部類ですから」。「そもそも恐竜の化石って動かなくないか？」と思いました。
それくらい、お互いの短所が目につきがちです。両者を両立できればすごく強い組織になるし、エンジニアとしても、モード1の人がモード2の人とも気持ちよく会話できるよう心がけられたらすばらしい。逆もまたしかりです。
しかし、モード2の人がモード1の人をばかにしてしまうパターンが一番多いです。そうではない。DXはトランスフォーメーションなので、今までのものがあった会社にこそ必要なわけです。今までのものを否定してはダメです。
今までのものを認めて、その良さをきちんとリスペクトしてやっていくことこそが、まさにDX時代に求められるエンジニアの心がけだと思います。スタートアップの人が急に正論を振りかざして周りを全否定することは、ダメなのではないかと思います。
モード1とモード2を共存させた事例
バイモーダルな組織は、モード1とモード2が共存していると強い。調停役にも名前がついていて守護者（ガーディアン）と呼ぼう。二重人格的な要素を取り入れないと失敗するから、文化的な混乱こそが課題だ。これはもともとガートナーの言葉ですが、最初からわかっていたことなんです。これも事例がないと説得力がないので、挙げます。
私が入った当初、HULFTはモード1でした。メインフレームとUnixのための連携ソフトで、HULFTに任せておけばバグがなくて確実に転送できて、パケロスが発生しても再送してくれてすごく便利。安全安心のHULFTと言われていました。
ただ、メインフレームなどUnixの相対的位置が下がっていくと、一緒に落ちていくのではないかという懸念もありました。しかし、そんなものはもう時代遅れだとは一切言わず、バイモーダル的にモード1の価値を全面的に認めたうえで、その強みは必ずしもメインフレームとUnixだけではなく、安全・安心・確実な転送はIoTでもミッションクリティカルに近い。製造業の工場は「転送できなくてちょっと焦げちゃいました」が許されない世界なので、そういうところにこの安全・安心・確実を適用できないかと考えています。
そのメインフレームとUnixを殺すのは誰かといえば、2013年当時から、明らかにクラウドだったので、クラウド時代に必要とされるHULFTになれば、ポートフォリオ戦略、もしクラウドが世の中を席巻しても勝てるという戦略でいきました。
例えば、他の業界でいえばJTがやっています。タバコのJTは健康食品にも張りました。それによって健康意識が高まってタバコの売上が減れば、もう片方の健康事業は上がるはずだと。同じようにクラウドにも張ったわけです。その時に、モード1を否定せずにやりました。
結果的に2年後の2015年には、AWSのre:Inventで、世界の9社に与えられるThink Bigアワード賞を獲りました。
今までの安全・安心・確実なデータ転送をAWSに価値としてフィットさせられたことで、この賞を獲りました。今までの結果をよく見ると、AWSの事例でHULFTやDataSpider Servistaが入っているシステム構成は、メチャクチャ多いんです。まさにバイモーダル的なアプローチで評価されたのだと思います。
心理的安全性を担保するためのHRTの原則
こういうことをやろうとすると、心理的安全性がすごく大事です。（スライドを指して）私はクレディセゾンの自分のチームで、4原則を定めています。先ほどのセゾン情報システムズの事例のように、クレディセゾンにもいろいろな人がいます。モード1もモード2もいます。モード2でもいろいろなスペシャリストが集まっているので、本当に猛獣園のように、毎日みんな好き勝手に発言するわけです。
そうなると、ある人の常識は別の人の非常識なので、場合によっては言い合いになる可能性も出てきます。そこで、私たちは4原則にのっとり必ず“さん”づけで呼んで、上下を意識しないようにしています。
そのほか、HRTの原則を100パーセント守り切る。頭にくることがあっても、絶対に怒らない。言うべきことは言うが、できるだけマイルドになど。短所とはある価値観の物差しで見た時の短所なので、絶対に言ってはいけません。お互いに自分の長所で相手の短所を補えばいいのです。
また、どんなに心理的安全に、いい感じでチームをやっていたとしても成果が出なければ意味がないので、世の中に対していいものを届ける、企業を成長させる。これらを重視しようという原則を掲げながら、クレディセゾンで仕事をしています。
（スライドを指して）HRTの原則をエイチ・アール・ティと呼ぶ人もいますが、これは本にもなっています。下に書いてある『Team Geek−Googleのギークたちはいかにしてチームを作るのか』という、Googleのエンジニアの仕事の仕方を書いた本にも紹介されています。HRTのHはHumility、謙虚さ。RはRespect、敬意を払うこと。TはTrust、信頼することです。これがステークホルダーの中で守られているチームこそが、効果的なチームでありやすい。例のプロジェクトアリストテレスをはじめ、心理的安全性も特にGoogleが言った言葉ですが、あのGoogleがHRTの原則を守っているのは非常におもしろいと思います。
これはとにかく、私たち日本人にもすごく馴染みのある考え方で、なんなら日本の企業の社長室に掛け軸で“謙虚・尊敬・信頼”と貼ってあってもおかしくないくらいです。HRTの原則こそがバイモーダル成功のための勘所であり、2つ目の話の異なる文化を受け入れるエンジニアになることでもあります。
聞いているみなさんがモード1だったとしてもモード2だったとしても、HRTの原則を守っていくことこそが、まさにデジタル時代に必要な心がけなのではないかと思います。
（次回につづく）
