日本の IT は遅れているのか

日本の IT は遅れている、とよく言われます。私の答えは、イエスでもあり、ノーでもあります。

優秀なエンジニアはいる

日本のエンジニアが IT 業界にもたらしたものは少なくありません。QR コードはデンソーウェーブの原昌宏さんが開発を率い、1994 年に発表されました。Ruby は松本行弘さんが 1995 年に公開しました。ソフトウェア開発のリーンやかんばんも、トヨタ生産方式から生まれたものです。日本に優秀なエンジニアがいなかったことはありません。

もちろん、こうした例から平均的な水準は分かりません。日本の IT エンジニアの平均的な水準は、やはりアメリカや中国に及ばないと私は思います。大学教育の影響も大きく、ソフトウェア工学という分野が日本では十分に広まっておらず、重視もされていません。ただ、問題の核心はそこではないと思います。アメリカにも、別の専攻から転身してきたエンジニアは少なくありません。出身の専攻が彼らの妨げにはなっていません。

問題は会社の仕組み

本当の問題は、会社の仕組みが時代の変化に追いついていないことです。

これはデータにも表れています。IPA（情報処理推進機構）の調査によると、2020 年の時点で日本の IT 人材の 73.6% は IT 企業に所属していて、ほかの業種の企業にいるのは 4 分の 1 ほどです。アメリカは逆で、2021 年に IT 企業に所属していたのは 35.1% にすぎず、多くは IT を使う側の企業にいます。つまり日本の多くの会社は自前のエンジニアチームを持たず、システムを SIer に任せ、さらに多重の下請けに出すことも珍しくありません。決める人とコードを書く人の距離が遠く、エンジニアがプロダクトそのものに関わるのは難しくなります。

2026 年 11 月 2 日、GMO インターネットグループは「お名前.com デスクトップクラウド」への不正アクセスについて記者会見を開きました。攻撃者は顧客が使うリモートデスクトップのサーバーから入り込み、管理者アカウントを盗みました。グループのセキュリティ会社は、2024 年の時点でシステムの問題を指摘していました。ただ、私の印象に強く残ったのはセキュリティの失敗そのものではありません。会見の中の一場面です。担当の責任者が記者に説明を始めたところで、グループの代表がそれを遮り、上着のボタンが開いていることを注意したのです。「お詫びをしているのにボタン開けてどうするんだ」と。

Satya Nadella や Elon Musk が、人前でも人のいないところでも、ボタンのことで部下の話を遮る姿は想像しにくいでしょう。多くの人はおかしいと感じるはずですが、本人は何も問題だと思っていないようでした。私は、これこそ日本の多くの IT 企業が遅れている理由だと考えます。権力を軸にした厳しい上下関係は、ソフトウェア開発に必要な、開かれた対等な環境と相容れないのです。

ここで言う上下関係は、仕事上のレポートラインのことではありません。マイクロソフトや Amazon にももちろん階層やレポートラインはありますが、それは仕事の分担であって、命令の階層ではありません。そこでは多くのプロジェクトがボトムアップで生まれます。日本の会社では、こうしたボトムアップの流れはあまり見られません。根本的な原因が日本の社会や文化にあるのかどうかは、この記事の範囲を超えるので、ここでは掘り下げません。確かなのは、強い権力の階層の下では、複雑なソフトウェア開発はうまく進まないということです。

理性的な議論や、議論で知識を確かめ合うことには、対等な環境が欠かせません。Google の Project Aristotle は 180 のチームを調べ、それらのチームでは、成果を左右する 5 つの要素のうち、最も重要なのは心理的安全性だと結論づけました。ミスを認めても、質問や新しいアイデアを出しても、恥をかかされたり罰せられたりしないとメンバーが信じられることです。多様性も同じように大切です。研究をまとめた Harvard Business Review の記事によると、多様なチームは事実をより重視し、事実を見直すことが多く、事実の誤りも少なくなります。どれも、日本の多くの会社に欠けているものです。

リーダーは技術を知っているか

もう一つの違いは、チームを率いる人が技術に詳しいかどうかです。日本の IT 企業では、プロジェクトマネージャー（PM）が階層の上のほうにいることが多いようです。アメリカや中国の IT 企業は違います。マイクロソフトでは、コードを書くエンジニアになりたい PM（プログラムマネージャー）は多く見ましたが、PM になりたいエンジニアはほとんどいませんでした。チームのマネージャーも、多くはエンジニア出身です。

責任をどう考えるか

責任のとらえ方も違います。日本の多くの会社では、決めるときの大事な基準の一つが、組織が責任を負わずに済むかどうかです。「こうしておけば、何かあっても責任を問われない」。気持ちは分かりますが、アメリカの IT 企業でこういう判断基準を感じたことはほとんどありません。

日本が得意なこと

逆に、日本の得意な分野を見てみます。文化産業では、一人ひとりの貢献が大きな意味を持ちます。自動車のような重工業では、チームがどれだけ厳密にルールを守るかが決め手になります。ところがソフトウェア開発に必要なのは、そのどちらでもない第三のもの、つまり対等な議論と、素早く試して改善を繰り返すことです。

日本の IT にも、個人や小さなチームによる革新はあります。たとえば Preferred Networks のディープラーニングフレームワーク Chainer は、2015 年に define-by-run という書き方を打ち出し、この考え方はその後、研究の世界に広く取り入れられました。それでも業界全体が前に進むには、チームの考え方が変わる必要があります。

日本の IT 企業はどうすべきか

一つ目に、アメリカのトップクラスのテック企業に学び、自前のエンジニアチームをつくって外注を減らすことです。システムは会社の中核の力であって、すべてを他人に任せるべきではありません。エンジニアが社内にいてこそ、事業やプロダクトに近づき、結果に責任を持てます。

二つ目に、海外の高度な人材を積極的に迎え入れること。そして、こう理解しておくことです。高い給料で聡明な人を雇うのは、その人にやり方を指示するためではなく、その人にやり方を教えてもらうためだと。

三つ目に、そして最も大切なのは、開かれた対等な職場を受け入れ、権力の階層を弱めることです。職場では仕事の中身だけに目を向けるべきで、GMO グループの代表のように、お詫びの会見でボタンのような取るに足らないことに目を向けるべきではありません。

四つ目に、技術を分かっている人に技術の判断を任せることです。エンジニアにマネージャーと並ぶキャリアパスを用意し、ベテランのエンジニアがマネジメントに移らなくても、それに見合う職位と待遇を得られるようにします。エンジニアリングチームを率いる人も、できればエンジニア出身であるべきです。

五つ目に、問題が起きたら、個人を責めずに振り返ることです。Google の SRE では、これを blameless postmortem と呼びます。振り返りでは事故の原因だけを探し、どの個人やチームも責めず、関わった全員が善意で、その時点で分かっていたことに基づいて正しく行動したと考えます。直すのは仕組みやプロセスであって、人ではありません。責任を問われる不安がなくなってはじめて、判断の基準は「何が一番よいか」に戻ります。「どうすれば一番失敗しないか」ではなく。

これは非難のために書いたのではありません。改善の余地がどこにあるかを示したかったのです。