DEC（デジタル・イクイップメント・コーポレーション）・マイクロソフト・グーグルと、時代を築いた外資系IT企業を渡り歩いた及川卓也さん。マイクロソフトではWindows NT、グーグル時代にはGoogle日本語入力やChrome OSなどのプロダクトに、エンジニアリングマネージャーとして携わっている。
今年5月にプログラマー向けの技術情報共有サービス「Qiita（キータ）」を運営するインクリメンツを経て、今年6月に独立。現在は、国内人材紹介大手のクライス＆カンパニーの顧問に就任し、CTO・IT技術人材の採用支援や組織変革活動に力を入れている。そんな及川さんに、「日本のITをどう見ているのか」という観点から話をお聞きした。
日本のIT産業はどこが残念なのか？
――組織変革やIT活用という面で、しばしば「残念」と評価されてしまうこともある日本のIT産業ですが、いわゆる外資大手IT企業での経験を積んできた及川さんはどう見ていますか？
本来、日本はエンジニアのレベルが基本的には高い。わかりやすいところで言えば、グーグルは東京にエンジニアアリングの部隊を200～300人規模で持っています。一般的に、外資企業は一般的にローカル採用とグローバル採用を分けていて、前者の場合、ある国で採用されても、本国で採用されたわけではないので異動できない、ということがあるんですね。
しかしグーグルの場合、私の知る限りすべてグローバル採用で、採用基準がとても高い。その基準を満たす人材はどこにでもいるわけではないことを考えると、日本の優秀なエンジニアの多さを証明していますよね。もちろん、グーグルの採用基準が最高だというわけではなく、たとえばスタートアップであればまた違う基準があるべきだと思いますが。
いずれにせよ「迅速に対応できる」「プロダクト指向が強い」「フルスタックである」といった、さまざまな基準を満たした優秀な人材が日本にはいる。しかし、産業全体で見ると、なぜか競争力がなかったり、彼らが生き生きと活躍できているように見えなかったりします。その原因の1つが「組織力」だと、僕は考えます。
――エンジニアというと、個人単位で能力を発揮するというイメージもありますが。
いわゆる管理職――僕個人はこの言葉自体はあまり好きではありませんが――の問題も大きいのです。組織にはエンジニアの成長を促すような文化や仕組みがあるべきです。これをわかりやすく言えば、「エンジニアを正しく評価できるような人が、上長になっていますか？」ということ。
そのための組織の作り方はさまざまです。事業会社なら、事業責任者のもとに、エンジニアアリングやマーケティング、セールス部門がぶら下がることが多いでしょう。その間をミドルマネージャーが取り仕切ることになります。では、この人たちがエンジニアに尊敬される存在で、彼らの育成も含めた評価ができるかといえば、残念ながら必ずしもそうではない。こういった場合、このポジションに優秀な人を置くだけで、組織が生まれ変わることもあります。
自分のキャリアを振り返ると、マイクロソフトもグーグルもこのミドルマネージャーに優秀な人が非常に多かったのです。全員とは言いませんが（笑）。たとえば、グーグルはエンジニア力が高いと評されていて、それは正しい。一方で、それを支えるエンジニアアリングマネージャーの存在も大きいのです。ミドルマネージャーが優秀だと、チームの生産性は劇的に上がります。このマネジメント力を日本でも強化していく必要があると思います。
日本で残念なのは、エンジニアが「管理職に就きたくない」と考えていることです。管理職には、一度なってしまうと技術的なことはできず、ずっとお金の計算をして、営業との板挟みになってしまう……といったイメージが定着しているんですね。でも、本当にそうでしょうか？ たとえば、エンジニアが「自分はUIが得意だ」「データベースなら誰にも負けない」と自負するのと同じように、「私は人とのコミュニケーションが得意で、説得などの場面で実力を発揮できる」という人がもっといるべきなんです。本当はリーダーシップやマネジメントに長けているにも関わらず、それがなんだかかっこ悪い、という風に捉えている人が多い。
――管理職をキャリアの終着点のように捉えているエンジニアが多く、そこに就きたい人の少なさに悩む企業の話は耳にします。いわゆる「プログラマー35歳限界説」と関わる問題でもありますよね。
でも、必ずしもそうじゃないはずなんです。技術に優れ、マネジメントの素養もある人が管理職に就かなければ、ITの本当の実力は組織・会社において発揮されません。だから、優秀なミドルマネージャー人材を、もっと発掘していかねばならないと考えています。
ミドルマネジメントのさらに上に位置するCTOもそうです。CTOという役職は、海外でもまだ「何をする人なのか」という定義が、CEOやCIO、CFOのようには明確にされていません。テクノロジーのチーフとはどういうことなのか？ 一つはマネジメントのトップ、という考え方。もう一つは、経営陣に対して技術面から貢献をするという考え方。さらに、「社内のエンジニアのロールモデル（手本）だ」という考え方もあります。この人のようになりたい、と尊敬できるような存在です。
そうなるには、CTO自身が技術的に最先端であることが期待されます。当然、コードも書けるし、レビューもちゃんとしてくれる。トレタの増井さんはそうですよね。「ピープルマネジメントしないCTO」であることを宣言し、エンジニアリング組織の長（VP of Engineering）は別に置いて、自ら技術選定をしながらコードもガンガン書く、そんなロールモデルたらんとしている。
CTOにせよ、VP of Engineeringにせよ、なんとなく人をそこにあてがうのではなく、その人にはどんな資質が必要で、どう育ってほしいか、ということを考えなければいけない。そして彼らのもとで管理職や、プロダクトマネージャー――コードは書かないけれど事業サイドと開発サイドをブリッジする人たちが、もっと必要。それが僕自身、マイクロソフト・グーグルなどでの経験から見えてきた日本の課題です。
僕はこの問題についての認知を高めたい。どんなポジションの人が欲しいのかを明確にする上で、コードは書けるべきか、マネジメント能力がどの程度必要かといった求人の際の要件定義をいいものにしたいし、育成や流動性を高める活動もやっていきたい。そこで今、人材紹介の分野に協力している、というわけです。
日本の会社はまだまだ「すべての企業はテクノロジー企業であり、内製化を進めるべき」
――エンジニアを一から育成するのが難しい状況なら、外から最適な人材をそこに充てるということですね。
そうです。より根本的な問題として、いまの日本の企業には、そもそも「社内」にエンジニアがいないというケースも多いのです。いたとしても、「社内システムエンジニア（SE）」として外部委託先との窓口を担当しているだけで、開発そのものは行っていなかったりする。プログラマーの上にSE、そしてコンサル・ITアーキテクトというヒエラルキーがあり、「コードを書かなくなって一人前」という変な文化もある。
グーグルのようなグローバル企業にはこういった考え方はまったくなくて、プログラミングや実装の技術こそが、差別化要因になっている。そもそも、実装だけを切り離すのではなく、コンセプトや設計と実装を行きつ戻りつして開発するのが、もはやスタンダートです。
日本の会社がそんな時代の流れに乗り遅れまいと内製化を進めようとしても、実はコードを書けるエンジニアがいない。ならば採用だ、となっても、どんなポジション、あるいは人材を採用すればいいかわからない、ということが起こります。
僕はそもそも「IT企業」という呼び方が微妙だな、と思っているんです。すべての企業がもはや広義のIT企業なんです。楽天やZOZOTOWNを運営するスタートトゥデイはIT企業でしょうか？ その本質はリテール（小売）ですよね。それをオンラインでやっているだけです。Fintech（フィンテック）を手がける企業も、一つひとつはいわゆる金融業で、ITを活用している。今後、これまでアナログだった企業がテクノロジーを使うようになるのは自明ですし、そうでなければ潰れてしまう。ならば、どの企業も「テクノロジー企業」になっていく、と考えるべきなんです。
そんな時代に、テクノロジーというコアな部分を「内製化しないぞ」と考えるのは不自然ですよね。誤解を恐れずに言えば、いま多くの会社ではエンジニアが雇用制度に守られながら「死蔵」されています。大手SIerやメーカーのエンジニアが、実力に見合った仕事をできているかといえば、疑わしい。彼らはより高いレベルの仕事ができるはずです。だから、このような人材の流動化も、さらに進めるべきだと思います。
ただ、流動化が進んでも、テクノロジーカンパニー化への舵取りを誤ると、外部委託していたときと同じような体制・組織を社内に作っただけ、ということになりがちです。たとえば、組織を企画と開発に分けた途端、社内SIerに仕事を投げるという形になる。それも1つの形だとは思いますが、内製化した意味が失われるので、僕はオススメしません。
――言われたことだけやればいい、となってしまいますね。アジャイル【※1】でどんどんよくしていこう、ともならない。
※1 小さな単位で、実装→テストを繰り返す開発方法
開発者もモチベーションが下がりますしね……。ウォーターフォール【※2】であることが必ずしも悪ではありませんが、少なくともリーン開発で求められように、現場で素早く改善を行い、ムダな開発コストの排除が求められている。設計→実装→テスト→リリースといった流れを1年かけて進めていく、という時代は既に終わっているのです。まずは世に出して、仮説検証をどれだけ早く回していくか。それを外部に任せていては、コミュニケーションコストもかかるし、迅速に回すことはできない。机を隣り合わせにし、小さなチームで動かなければならないのです。
※2 企画からテストまで複数の工程を段階的に経る従来の開発方法
――及川さんが開発していたグーグル日本語入力も、あれだけの規模のプロダクトでありながら、4～5名前後ととても小さく、機動力のあるチームでしたね。なぜ日本企業ではそうならないのでしょうか？
一つは、企業トップのITリテラシーが低すぎる、という理由が挙げられます。狭義の「IT企業」で見ても、たとえばソフトバンクの孫正義さんのようにテクノロジートレンドをしっかり語れて、なおかつ業界に影響を与えられる人は少ない。本当に自社製品を使っているのかどうかも怪しい社長だっています（笑）。数字を見ることばかりに時間を取られてしまい、世界の技術トレンドを見極めて、自分たちがどこに投資すべきなのか、ビジョンを描けていません。トップがそれでは、その下にいる人たちも「開発こそが差別化要因だ」と動けませんよね。いまだに、ITはコスト削減の道具にすぎないと考えている人がたくさんいます。それでは、ITじゃないとできないことに投資するというマインドセットになかなかなりません。
もう一つは日本の国内市場が「緩すぎた」こと。ずっとGDP2位が続き、国内市場を護送船団方式にしながら5社～10社がパイを分け合えば、十分に食える時代が長く続きました。激しいグローバル競争に向き合わなくてよかったわけです。僕がマイクロソフトにいた2000年当初は、PCベンダーが日本に10社以上ありました。市場規模を考えれば黒字を維持できるはずないのですが、「安定した取引があるから」といった理由でみんななんとなく続けてきた。でも、海外勢が乗り込んできて、さらにはPCがもはやコモディティとなり、みなさん大変なことになって、多くのベンダーは撤退していきました。今、同じことがスマホで繰り返されていますが、この危機感が薄れている時代が長く続いたことで、企業そのもののITリテラシーが高まる機会も失われてしまったのかな、と。
――逆に、そういった状況から脱却して、内製化・アジャイルな組織作りを進めるにはどうすればよいのでしょうか？
外部から最適な人を採用するのが理想ですが、もちろんコストもかかれば、リスクもあります。ただ、仮にそれが難しくてもできることはある。たとえば経営者やミドルマネージャーのITリテラシーが高くなかったとしても、「グーグルってすごい。あんなふうになりたい」という意識は強かったりするんですね。そこを足場にするんです。怪しい本やコンサルに頼るのではなく、社内のエンジニアに尋ねてみてもらいたい。エンジニアにもその機会を生かしてほしいです。
開発者ってクリエイターなんです。創造主であり、魔法使いのようなもの。経営や営業といったビジネスサイドの人から見るとよくわからない人種かもしれませんが、実はすごい人たちなのだから、まずは交わってみる。内製化のための仕組みを考えるのであれば、どんな仕組みがよいのか彼らに聞いてみる。エンジニア側もいくつか成功事例を作ってみて、カルチャーを作っていく。「新しいiPhoneってなんだかすごいよね。これで何かできないかな」という会話から始めたっていい。
開発側も、そういう機会を面倒と思わず、プレゼンの場として生かしてほしい。どうしても管理職に就くのが嫌なら、「管理職以外のポストを用意してほしい」と働きかけるのもアリです。トレタのCTOである増井さんのように、何人を管理しているかという軸以外で会社に貢献できる尺度を提案する。たとえば「エンジニア採用のために、社外の勉強会での自分の知名度が生かせる」といった軸をアピールするのもアリですよね。社内システムをChromeの拡張を提供することで効率化するのだっていい。日本の会社には、「ハックする」余地がまだまだたくさん残されています。
世界で戦えるテクノロジーカンパニー／エンジニアになるには？
――スマートニュースやメルカリなど、海外進出に挑戦する企業も出てきています。
苦労しつつも、そうやって外に出て行かなければ、いずれ日本に上陸するグローバルサービスに、自分たちが負けてしまうリスクを常に考えねばならない時代です。日本はテクノロジーの分野でも鎖国を続けてこられた国なんです。たとえば、文字コード。日本語に対応できないがために、参入できなかった製品・サービスがたくさんありました。
でも、UnicodeやUTF-8が賛否両論ありながらも普及し、その障壁が一気に下がった。翻訳が間に合わなくても最低限、日本語の入出力はできてアプリが動作するようになった。日本人の「英語アレルギー」も海外SNS普及の影響もあって少なくなってきていることもあります。どんなサービスだってすぐ日本に入ってこられる。たとえ日本市場だけをターゲットにしていたとしても、海外ベンダーと戦わなければならない時代がやってきています。
――出て行かないと、あるいは出て行けるくらいの能力がないと、逆に負けてしまうということですね。
そうですね。これまでのように「守られた」状況がいつまで続くかは予断を許さない。そういった障壁は、ある日突然なくなってしまうという危機感を、テクノロジーカンパニー化を進める日本企業は持たなければいけません。
――よくわかりました。企業としてのマインドセットはお話の通りだと思いますが、「HRナビ」読者に多い若手エンジニアは、個人としてどう行動していけばいいのでしょうか？
えふしん（藤川真一さん）たちとの話で、「35歳限界説」とは、そのくらいの年齢になった自分のことを考えて、いまの働き方を考えようということなのではないか、と。
できることは個々人で異なりますが、共通しているのは「技術に対する興味を失わない」ことです。広く「技術職」には、先ほどお話ししたマネジメントも含めて、いろんな貢献方法がある。いずれにせよ、技術が世の中をよくすると信じ、そんな技術に興味を持ち続けることです。
僕は50歳を超えましたが、一番怖いのは技術をおもしろいと思わなくなることです。若いときに上司から「及川に任せておけば大丈夫だ」と言われたことがあって、その理由を尋ねたら「新しいおもちゃを与えられた子どもみたいだから」と（笑）。でも、本質はそういうことだと思っていて、最新の記事を読まなくなったり、新しい技術を自分で試そうと思わなくなったりすることが怖い。それを面倒だと思い始めたらアウト。そうなってしまったら、もう「技術職」からの転換を考えたほうがいいと思うんです。
――LT（ライトニングトーク）やハッカソンが普及したおかげで、そういった刺激を得る機会は以前よりも増えているかもしれませんね。
地方との格差はありますが、東京はそうですね。LTを2時間聞けば最新動向がわかる勉強会もあるし。アーカイブ配信もあれば、SlideShareで資料も見られますよね。
ヨガや座禅もそうですが、勉強も同じで「アウトプットすることを先に」考えてからインプットしたほうがいい。「興味はあるけどあまりその分野に詳しくない」といった勉強会で次回発表する人を探しているなら、まずは手を挙げてしまいましょう。本格的な発表だとさすがに厳しいかもしれませんが、LTなんかだと数分間です。そこを活用してほしいですね。何か試しに作ってみて失敗しても、それをネタにすればいいんですよ。失敗談って貴重なので、だいたい笑って許してもらえます。
一方、アウトプットを続けていると、インプットの総量が減っていきます。たとえば僕の場合、「マイクロソフトやグーグルでの経験をもとに、組織作りについて教えてください」と依頼されることが多いのですが、それだと3時間くらい話したらそれで終わりです。そんなことだけを続けていたら、収入も細くなっていくし、自分の経験談を語るだけの痛いOBになってしまう（笑）。本当は僕、「元グーグル」という肩書は、いつか外したいくらいなんです。
だから、より継続的なアウトプットのために、スタートアップの事例を聞きにいくことを続けています。そうすることで「グーグルはこうだったけど、御社の場合はこのほうがいいですよ」というアドバイスができるようになるのです。息を吐いた後は吸うように、アウトプットを先に考えつつも、次はインプットするという一連の動作を忘れない、ということですね。
そして、とても基本的だけど最後に一番大切なことを。それは「体を第一に考える」ということです。「忙しくて病院に行けなかった」なんてただの言い訳で、自分でその優先度を下げただけですよね。僕は具合が悪くなったらすべての仕事を止めて病院に行くようにしています。実は僕、マイクロソフト時代に軽鬱を経験しているんです。幸いにも、すぐにそこから抜け出せたのは、すぐ病院へ行ったからだと思っています。
――健康第一と言葉にすると簡単ですが、それを最優先にするというのは実はいろんな決断が必要ですよね。
特に技術職は生産性が大きな評価指標になります。それを短期的に上げるなら徹夜すればいい。でも、安定したパフォーマンスを長期的に発揮するには、健康でなければならない。スタートアップも“ブラック企業的”になりがちなのですが、どこかでそれを脱却しなければ組織として継続的な成長は見込めません。
僕の場合、走ると調子の悪いところが直るんですよね。ちょっと調子が悪い時ほど、がんばって時間を作って最低5キロ、週に20キロくらいは走るということを続けています。
