「日本はものづくりをリスペクトし過ぎている」　及川卓也氏×葛岡宏祐氏からみた、海外のエンジニアリング組織との違い

及川卓也氏と葛岡宏祐氏のプロフィール

司会者：それではスピーカーを紹介します。まずベンダー企業からは、株式会社ハイヤールー 代表取締役の葛岡宏祐さんです。よろしくお願いいたします。

葛岡宏祐氏（以下、葛岡）：よろしくお願いいたします。

司会者：続きまして専門家としてお迎えしているのは、外資系IT企業にてソフトウェア開発からプロジェクトマネージャー、エンジニアリングマネージャーと、幅広く従事したのちスタートアップを経て独立。有名な書籍『ソフトウェア・ファースト』の著者でもある、Tably株式会社 代表取締役 Technology Enablerの及川卓也さんです。どうぞよろしくお願いいたします。

及川卓也氏（以下、及川）：はい、よろしくお願いいたします。

司会者：ディスカッションに移る前に、まずはお二人それぞれの企業の事業内容を教えていただけますでしょうか？　まずは葛岡さんお願いします。

葛岡：我々は株式会社ハイヤールーという会社でして、主にエンジニアを採用する際に適性検査みたいなのが必要だと思いますが、その際にエンジニアのスキルを見極めるソリューションを提供している会社です。なので、エンジニア採用をされる企業さんは、今後おそらく必要になってくるのかなと思います。

司会者：ありがとうございます。続いて及川さん、お願いします。

及川：私はTablyという会社を自分で経営しています。このTably、まず大事なのが「タブリー」と読んじゃう人が多いのですが、「テーブリー」なので、ぜひ名前を覚えていただきたいなということ。あと私の会社でやっているのは、基本的にはITの支援なんですが、プロダクト開発支援ということで、先ほどちょっと司会の方が「プロジェクトマネージャー」と言っていたんですけど、実は「プロダクトマネージャー」なんです。

司会者：失礼いたしました。

及川：いえいえ。それで「プロダクトマネジメント」ということで、プロダクトの戦略立案やその実施、および技術面でそれをサポートすること。あとは人と組織。今日はこの人と組織というところで、主にいろいろお話できるんじゃないかなと思っています。よろしくお願いします。

DXで事業を変革することが、企業にとっての生死を分ける

司会者：あらためましてよろしくお願いいたします。そんなお二人に本日お話いただくテーマがこちらです。テーマは「及川氏と語る、強いエンジニアリング組織の作り方」というテーマで進めていきたいと思います。今回のディスカッションなんですが、どうでしょうか。及川さん、どんな方々に注目してほしいですか？

及川：やはり今の日本は、日本といわず世界的にDXと言われていて、デジタルテクノロジーで事業を変革することが、企業にとって生死を分けるとか明暗を分けるとかぐらいになっているわけですが。スタートアップなどの方々は、もちろんテクノロジーで事業をいかに伸ばしていくかということに気づかれているんです。

だけれども、やはりその動きがやや遅いような、一般の事業会社であったり今までこれからも日本のITを支えていくSIerであったり、そういった方々にも特に聞いてもらいたいなと思います。

司会者：ありがとうございます。葛岡さんはいかがでしょうか。

葛岡：私はもともとスタートアップとかそういうメガベンチャー出身だったりはするんですが、やはりこれまでのものづくりの日本を支えてきたのはSIerの会社なども割合としては非常に多かったりはするので、そういった会社さんなどはこれから自社のプロダクトなどを作ったりする際に必要なノウハウだったりを知っている範囲で届けたいなと思っているので、そういった方をターゲットにしたいと思っています。

司会者：みなさんにはたくさんのヒントを受けとってもらって帰ってほしいと思います。タイトルにもある「強いエンジニアリング組織の作り方」について、今後企業はどう向き合っていくべきかと、気になる人も多いのではないでしょうか？　今回はさらに議論を深めるために、3つの小テーマをご用意しました。それがこちらです。

1つ目が「日本のソフトウェア開発の現状」。そして2つ目が「自社に最適なエンジニアリング組織とは？」。3つ目は「明日からできる、成長し続けるエンジニアリング組織を作るための施策」ということで、どれも気になりますよね。ではさっそく1つ目のテーマに参りましょう。

1つ目の「日本のソフトウェア開発の現状」についてです。ここで見ているみなさんに、さっそくですがアンケートを実施したいと思います。みなさん、エンジニアリング組織づくりの一番の課題は何だと思いますか？　3つの選択肢からお選びください。1つ目は「採用」、2つ目は「評価」、3つ目は「育成」。ということで、ご覧になっているみなさんは回答をよろしくお願いいたします。

さぁ、選んでいただいている間に、お二人はどれが多いと思いますか？　及川さんはどうでしょう？

及川：3番かなと思っているんですけど。

司会者：3番の「育成」ですか。葛岡さんはいかがですか？

葛岡：私は1か2かなと思っています。

司会者：ちょっと割れましたね。お二人はご自身の経験から「こうかな？」という感じですか？

葛岡：そうですね。特に私は採用のところの事業をやっていると、いろいろなそういったディープな課題とかを聞いているので、そこらへんが多いのかなとちょっと思っています。

司会者：どれも大事な要素ではありますが、（結果は）どうでしょうか。エンジニア組織の一番の課題は「採用」か「評価」か「育成」か。さぁそろそろ結果が出ましたので、発表したいと思います。

エンジニアリング組織づくりの一番の課題

司会者：結果です。エンジニアリング組織づくりの一番の課題。1つ目の「採用」だと思われる方は26パーセント、「評価」だと思われる方は13パーセント、そして育成が63パーセントという結果になりました。

及川：私、合っていましたね。

葛岡：圧倒的でしたね。

（一同笑）

司会者：及川さん正解です。これを受けてどうですか？

及川：そうですね。これは私自身が、今まで外資系のMicrosoftやGoogleにいたのですが、そういった企業で感じていることとは、実は違うんですね。このあとずっと話すことにもつながるんですが、私は採用が一番大事だと思っているんです。今いろいろな日本企業の支援をしている中で、特に大企業は育成が大事だと思われているところが多いと。

もちろん、これはすべて大事なんですね。でもやはり日本は育成が大事だと思われているんじゃないかなと感じたので、先ほどは3の「育成」とお話しした感じですね。

司会者：葛岡さんはどうお考えですか？

葛岡：そうですね。私も間違いなく1の「採用」なんですが、たぶん今及川さんがおっしゃったとおり、そういった組織の中で私が今まで所属していた組織は、けっこう採用のところでの課題が多かったから「採用」と言ったんです。やはり日本はもともと終身雇用とかそういった中長期的な雇用形態などもある中で、やはり育成というのはすごく大事だなと思うので、今は納得しています。

司会者：ありがとうございます。納得の結果が出たところで、現状が見えてきたので、次のテーマに移って参りたいと思います。続いてのポイントは2つ目の「自社に最適なエンジニアリング組織とは？」ということで、ここからはいよいよエンジニアリング組織について掘り下げていきたいと思います。

今信じたくない・認めたくない現実は「日本の国力低下」

及川：ちょっとすみません。1のところでもうちょっと主張したいところがあるので、少しだけお話ししてもよろしいですか？

司会者：ぜひ、お願いします！

及川：この日本のソフトウェア開発の現状というのは、先ほど司会の方からも紹介してもらったように私の著書『ソフトウェア・ファースト』という中で、「これでもか！」というぐらい書いています。要は我々が、今信じたくない・認めたくない現実は何かというと、日本の国力低下だと思うんですよね。やはり我々は、国際競争力が落ちてしまっていることを、このコロナの状況下において肌身で感じてしまって、悔しい思いをしているわけです。

でも別にコロナの時に始まったわけではなく、私はちょうどバブル世代、バブル後期の人間なんですね。最初「失われていた10年」と言われていたのが、20年になり、30年になり、最近は言わなくなりましたよね。もはや日本は、ずっとこうだったかみたいになってしまっていると。実は自分の母校の大学で、あるIT産業史みたいなものを講義したことがあって、その時に裏付けで調べたんですよ。

実は日本が強かった時代、私がまだ中学生や高校生だった時は、その時はITと言わなくてコンピューター産業と言われていたんですが、そのコンピューター産業がメチャクチャ強かったんですよ。今の米中貿易戦争と同じようなものが日米貿易戦争にあって、半導体の話は聞いたことがあると思いますが、スーパーコンピューターも日本は強くて、米国の国防総省などに使われることになって、米国はこれを安全保障上の問題などといって高い関税をかけるようなことをやってきたと。

でもそのあとに1990年代に入り、2000年代になり、だんだんITの産業力がなくなっていった。これが日本の国力低下につながっているんですね。このまましゃべっちゃっていいですか？

司会者：お願いします！

葛岡：どうぞ。

及川：その「IT力」といった時に、何かというと、実はソフトウェア力なんですよ。明らかにソフトウェアなんですよ。ITの中にもいろいろな要素があって、もちろんハードウェアも大事です。今言ったようにスーパーコンピューターもパーソナルコンピューターもスマートフォンも大事かもしれない。でもこういったハードウェア、我々の知っているコンピューター機器だけじゃなくてさまざまなものが、実はソフトウェアを動かすことに最適化されたハードウェアになっていて、その本質はソフトウェアにあるんです。

特に見てわかるように、今やWebやスマートフォンなどは、もうソフトウェアが本質なものとして日々勝手にアップデートしていくんですよ。ですから買ってきた時の状態ではなく、利用者のニーズに合わせたかたちで進化していく。

我々は最初これをスマホでリアルに感じたわけですけが、実はこれはそういったIT機器だけではなく、「走るスマホ」と言われているテスラが、今までいったん作ったならばそのあと完成品で3年、5年の償却期間の間は一切進化しないと思われていたものを、進化させ続けられると証明してしまいました。現在は、さまざまな他のものがソフトウェアをいかに進化させ続けるかということで、そこの競争力を高めているわけですね。

結局はやはりソフトウェアであり、ソフトウェアの中でも実装力なんです。日本というのは、先ほどSIerみたいな話をしましたが、SIerさんのことをこの『ソフトウェア・ファースト』の中では、子どもたちが先祖代々殺されたのかみたいに、僕は恨みがあるような言い方をしちゃっていますが、これは愛憎の憎しなところがあって、実際はすごく期待しているわけです。

何かというと、日本はそのSIerさんをトップとした異常なまでの分業体制があり、SIerさんは設計まではやるけど実装は後継にやらせるかたちになっていると。でも海外を見てみると、私がいたMicrosoftやGoogleは、もちろんそういった企画や設計をする人はいますが、実装する人間が山ほどいて、大枚をはたいてそういった優秀なエンジニアを採用しているわけです。

なぜかというと、実装力こそがソフトウェア力であり、ソフトウェア力こそがIT力であり、事業力であり、国力になっているからなんですよね。ということをちょっと言いたかったんですけど、葛岡さんの感想をどうぞ！

葛岡：そうですね。まさに及川さんが言っているとおりだと思います。日本とアメリカできれいに真逆になっている構造が事業会社、自社でプロダクトを作っている会社で、実は日本って30パーセントしかないんですよね。70パーセントがSIerさんだったり受託開発企業さんだったりするんです。まさに今及川さんが言っていたことが、それを物語っているんじゃないのかなと思っています。

アメリカを見ると、これが逆なんですよね。そういったGoogleやMicrosoftなど自社のプロダクトを作っている企業の割合が70パーセントみたいなところがあるので、そうかなと。以前、ちょっと及川さんとお話しした時も、私は非常に興味深いなと思ったところが、そのカルチャー的なところで、納品して終わりみたいなところって、日本はあるのかなと個人的に思ったりしているんです。

だけど基本的にソフトウェアというのは、さっきテスラの例がありましたが、最近はSaaSという言葉があったりしますけど、基本的にはずっとアップデートをして良くしていく。そこの認識の違いがあるのかなと。納品してお金をもらって終わりじゃなくて、アメリカでは事業会社などは基本的にプロダクトはずっとアップデートされるもの。そういう認識の違いとかも、国力が低くなっている理由のひとつにあるのかなと思っています。

日本はものづくりをリスペクトし過ぎている

及川：そうなんですよ。それって背景が2つあって、1つは日本が強かった産業は製造業、もしくは設備産業的なところでした。どちらも基本的には作って終わりでよかったところなんですよね。あと製造業は、家電にしても車にしても、その同じものの原材料費が、ほぼコストなわけですよ。その原材料費が、今見てもわかるように、ウクライナの問題があったり何かの問題があったりすると、これが上下するわけですね。

それをいかに平準化するかに知恵を絞らなきゃいけなくて、モノ自身は同じものでいいんですよ。同じクオリティのモノをそのプロダクトのライフサイクルの間にずっと作り続けていくことこそが、大事だったんですね。コストコントロールが競争力だったんです。設備産業も一緒じゃないですか。

でもプロダクト、今我々の言っているITを使ったプロダクトは、違うんですよね。そこに、なかなか発想の転換ができないし、設備産業も製造業も非常に優秀な産業だと思うんですが、日本は他の産業も含めて、それをリスペクトし過ぎているんですよ。リスペクトするところはリスペクトして、でも違うところは違うと判断しなければいけないのが、できていないところがある。

あともう1つは、これを言うとちょっと炎上するかもしれないんだけど、変化させ続けなきゃいけないということをあまり好ましく思わない国民性があるんだと思うんですね。1回安定したものは、基本的に安定したままずっと続けるという、その慣性の法則が極めて強く働く国民性があると思うんですよ。この2つにより、日本はなかなか変化させる・進化させるというところに思いがいかないのかなと思いますね。

葛岡：そういった認識の違いみたいなところがあると思うんですけど、及川さんはそれをGoogleやMicrosoftなどの企業で、属にいう事業会社というところで経験を積まれたと思うんです。どのようにすると、ソフトウェアみたいにずっとアップデートしていって価値を提供し続けるみたいな認識を浸透させられるんですかね。どうお考えですか？

及川：これはいわゆるある界隈、最近の日本でも言われるようになったんですけど、アウトプットとアウトカムの違いを明確に理解する必要があるんですよ。

葛岡：なるほど。

及川：アウトプットというのは、もう機能として何が載っかっているか。それでそれが製造業的な発想でいうとQCDでどのぐらいの品質を満たしているか、どのぐらいのコストに抑えられたか。これがアウトプットなんですよ。でも使われない機能ってゴミなんです。それで実際に使われたかどうか、その顧客に対して何の価値をきちんと提供できたかというところまで計ろうとしたならば、絶対に最初から全部が100パーセント顧客に満足されて使われているものなんてないんですよ。

もしくは一時そうなったとしても、社会情勢がどんどん変わり顧客のニーズがどんどん変わる中では、どんどん満足度が下がる可能性があるんですよね。それで我々は、幸いにして顧客の利用状況を把握する手段をテクノロジーで持っているわけです。それを持ったならば、やはり「もっと使われるようになりたい」と思うので。

だからよく昔から言われるマーケティングの言葉で「マーケットイン」というのがあるじゃないですか。要は顧客をよく知ると。よく知らないといけないと。顧客を理解すればするほど、ユーザーファーストで顧客ファーストになりさえすれば、そういった発想になっていくと思いますね。

自社に最適なエンジニアリング組織とは？

司会者：ありがとうございます。そういったお話を聞いてきたところで次のテーマへいきましょう。2つ目です。2つ目は「自社に最適なエンジニアリング組織とは？」ということで、ここからは組織について掘り下げていただきたいと思います。自社に最適なエンジニアリング組織、及川さんはいかがでしょうか？

及川：これは、ちょっと今は私や葛岡さんも賛成したように、ITの中でのソフトウェアであり、その中でも実装力だと思ってはいます。いったん自分たちの思いをあまり押し付けるのではなく、と考えた時に、まずエンジニアリング組織に限らずですが、その組織デザインをする必要があるんですね。

どういうような役割を果たすのか。さっき言った言葉でいうと、どういったアウトプットだけでなくアウトカムを組織として生み出すかみたいなことを考えた時に、じゃあどういう構成員というかメンバーが必要であり、どういう職種の人が必要であり、その職種の人はどういうようなスキルを持っているべきであり、もしくはマインドセットやポテンシャルを見るならば素養を持っているべきでありと。

どんどんそのデザインから1つずつの職種、そこに参加する社員の要件みたいなものが細分化されてくると思います。やはりそれをしっかり見なきゃいけなくて、これがいわゆる今の日本でも大企業を含めて、徐々に浸透しつつある「ジョブ型雇用」、ジョブディスクリプションをベースとしたかたちのものになると。なので、まずはここからだと思いますね。

司会者：まずはデザインと。葛岡さんはどうお考えですか？

葛岡：そうですね。やはり自社で強いエンジニアリングを作って持ちながら、そのプロダクトを開発していくみたいなところも、もちろん1つの方法だと思うんです。ただ、今の及川さんが言ったとおり、それだけが方法ではないかなと思っていまして。ジョブ型雇用のところも、最近の有名なところではヤフーさんがやられたりしているのかなと思うんです。

もう1つ、最近私が聞いておもしろいなと思ったキーワードとしては、「スキル採用」みたいなのがあって。けっこう概念的にはジョブ型雇用に似ているのかなと思っていて、ジョブ型雇用だったりスキル採用で共通しているところだったりというのは、まずどういう人を採用して、どういう組織を作るのかみたいなところ。

なので、ダイエットする時に自分の体重を知らないのと同じかなと思っていて、まずどうなりたいのかみたいなところを定義して、どうそこを埋めていくのかが大事になってくるんだろうなと思っています。

良いパフォーマンスを出せる最少人数は？

司会者：例えば一番大きなパフォーマンス、良いパフォーマンスを出すには、プロジェクトによってはもちろん人数が違うと思うんですが、1つの最小単位としてはどのくらいの人数でやっていくというのが一番良いとお考えですか？

葛岡：それはプロダクトとかチームとして動くということですか？

司会者：はい。最小単位のチームとしてはいかがですか？

葛岡：間違いなく及川さんはご存じだと思うんですが、有名なところだったらAmazonの「Two-pizzaルール」ですよね。7人とか。

司会者：7人。

葛岡：はい。それが最小で一番価値を提供できるチームの規模なんじゃないのかなと思っています。

司会者：それはやはりコミュニケーションという意味でも7というのが1つの数字なのかなというところですか？

葛岡：そうですね。いろいろな開発手法や、いろいろなプロダクトを作る方法はあると思うんですが、特に私の経験だと最近流行りの、というかそういった流れがあると思うのがスクラム開発ですね。スクラム〇〇みたいな。スクラム採用じゃないですけど、スクラムでプロダクトを開発するみたいな流れは、いろいろなところで出てきているかなと思うんです。

そうなった時に、1人のマネージャーみたいな人、リーダーみたいな人が出てくると思うんですが、その方が1人で監視、というとちょっと言い方が悪いかもしれないですが、メンタリングできる人数は限界があるのかなと思っていて。そうなった時に、7人が最適。確かこれはGoogleが出していたあれだと思うんですけど、1 on 1を毎週・毎日とした時に、1日それで埋まらないように7人、8人で設計されているみたいな話を僕は聞きました。それって本当だったりするんですか？

及川：知りません！

（一同笑）

及川：でもGoogleの場合は、私がいた時代はいわゆるピープルマネージャーとしてのチームの話と、あとはその最小単位としてそのプロダクトチームというかプロジェクトチームが何人構成であるべきかというのは、必ずしもイコールじゃないんですよ。それで要は、例えば私はマネージャーだったわけですが、自分の下にこの最小構成の、先ほどの例えば「Two-pizzaルール」でもいいんですけど、これが何個もあるんです。

それぞれのところに、テックリードというピープルマネジメントをガチでやっているわけではないが、メンタリングやあとはテクニカルに方向性を示すという人間がついていて、マネージャーはその何個もあるところの上に就けばいいのです。

マイクロマネジメントをさせないようにしている

ちょっと脱線するかもしれないんですが、実はけっこうこのマネージャーの下にいる社員数が多かったりするんですよ。1 on 1で埋まらないようにするというのがルールであったら、私はどんなに楽だったかはしらないんですけれど（笑）。私がGoogleにいた時は、けっこう1 on 1でスケジュールが埋まっちゃうぐらいだったんですね。

なんでこうしているかというと、ちょっと話がズレるかもしれないんですけど、でも組織設計だからけっこう近いかな。マイクロマネジメントをさせないようにしているんですよ。要は自分の下に、極端な話50人部下がいるとしたら、マネージャーはマイクロマネジメントができないんですよ。要は社員が基本的には自律的に動いている組織じゃないとダメなんですね。それで採用が大事だというところにつながるんですが、Googleはそういう人間しか雇っていないんです。

なのでやるべきことというのは、ミニマムなマネジメントで良いはずであると。でもマネージャーって、私がそうであったかどうかや他の人がそうであったかどうかはわからないんですけども、普通に考えちゃうと、なんだかんだ権力者なんですよ。そうすると、権力を使いたくなっちゃうんですね。だからGoogleの場合は、あえて権力をはく奪しちゃうんです。

というかたちで、なのでチームは「Two-pizzaルール」ぐらいで、テックリードという技術側のリーダーがいて、それと組織を見るマネージャーとは、ちょっと別のかたちで設計されていたりするのがGoogleですね。

司会者：ご自身のお話もしていただきまして、ありがとうございました。

（後半につづく）