日本の一人当たり労働生産性は85,329ドル、OECD加盟38ヵ国中31位で、アメリカ（160,715 ドル）と比較すると約半分だ。時間当たりの労働生産性（52.3ドル）も、OECD加盟38カ国中30位と低迷する（「労働生産性の国際比較 2023」）。7万部超のベストセラー『世界一流エンジニアの思考法』の米マイクロソフトエンジニア牛尾剛さんが解決策のヒント示す。

◆◆◆

日本のビジネスパーソンは「重荷」を背負わされている

――他の先進諸国と比べて、日本の生産性がこれほど低い要因はなんだと思われますか？

牛尾　まず、今回のインタビューは所属会社とは関係のない、一個人の意見であることをお断りしておきたいと思います。僕は現役のエンジニアなので、ソフトウェア中心の、現場からの視点になることはご承知おき頂きたいのですが、日本のビジネスパーソンは大変な「重荷」を背負って戦わされていると感じています。

　アメリカに来てから実感するのは、日本の企業には権威的な構造や、面倒な慣習や社内文化が山のようにあって、なにかひとつ行動を起こすにも非常に負荷が高いということ。「こうやったら生産性が上がる」「みんな楽になる」とわかっていることでも、「部長を説得できない」「他部署に角が立つから難しい」……と様々な面倒くささが先に立ってしまう。

　ソフトウェアの世界でいうなら、世界中で使われるようなすごいソフトを効率よくリリースして他の先進諸国と勝負しないといけないシーンで、古い開発手法や組織体制にこだわっているのは、米俵を背負ったまま走ろうとするようなものです。

――耳が痛い話ですね。

牛尾　例えば、DevOpsという手法を使うと、日本の大手SIerでリリースまで8.5ヵ月かかるような開発がわずか1週間～1ヶ月で出来てしまったという事例もあります。従来のウォーターフォール方式――要件定義に3ヵ月、設計に4ヵ月、製造に6ヵ月、テストに2ヵ月、それからリリースなんてやっていれば、そりゃ時間がかかります。一つひとつの段階で上席が承認しないと次のステップに進めず、承認をとるために分厚いドキュメントをつくらなくてはなりません。しかも、途中でなにか間違いに気付くたびに工程を巻き戻して修正するので、とにかく時間がかかってしまう。　

「やり方」をアップデートしなければ、竹槍で戦闘機と戦うようなもの

――8.5ヵ月と1週間、馬鹿馬鹿しいほどに生産性の差が出ますね！

牛尾　例えばDevOpsの手法を使うと、プロジェクトによっては1日に10回リリースすることも可能です。コードのデプロイ速度（開発したアプリを本番環境で走らせてみるまでの時間）が従来比で30倍上がり、障害復旧は24倍速くなり、変更時の失敗率も3分の1に減るという調査報告もあります。

　世界の最先端では日進月歩でより合理的な「やり方」にアップデートしているのに、日本はオールドファッションで「承認手続き」や「品質管理」に多大な時間を費やしている。はっきりいってもう竹槍で戦闘機と戦っているようなもので、これでは勝てるはずがありません。

　僕はマイクロソフトに入る以前、日本の大手SIerにいましたし、アジャイルやDevOpsという開発手法のコンサルティングを様々な日本企業を相手に行っていました。そこで必ず言われるのが、「いや、弊社は特殊で……」「それは、うちでは絶対無理です」「アメリカとは商習慣が違いますから……」。「余分なこと」をやめるだけで簡単に生産性が上げられるのに、みんなやる前から無理だと思い込んでいるんです。

　でもソフトウェアのような、明日ライブラリのバージョンが変わったら全く動かなくなるかもしれない世界で、開発現場が非効率でスピード感がないというのは致命的なんです。さすがに、クラウドサービスがここまで本格化した時代になって、ようやく従来のやり方でソフトウェア開発をやるのは厳しいという認識が日本でも広まってきて、いま過渡期にあるように思います。

各国の文化の違いによる新技術導入の難度

――なぜ日本では新しい技術導入にそこまで時間がかかるのでしょうか。

牛尾　興味深い資料があって、アメリカのコンピューター科学者アリスター・コーバーンによると、文化の違いによるアジャイル導入の難度を106ヵ国ほど比較した調査で、実はもっとも難度が高かったのが日本でした。

　図は、彼の分析を僕が日本向けに簡易に整理したものですが、例えば、権力の差、お偉いさんのパワーが強いのはフランスが圧倒的で日本はそこまでではありません。でもなにが一番阻害要因になっているのかというと「個人の自立」です。アメリカやイギリスと比べて、自分の頭で判断して動く自律性が著しく乏しい。もうひとつは「不確実性」を極度に避けたがる文化です。失敗や変更が大嫌いで、綿密に計画・管理しないと不安になる気質です。

　文化圏の違いという要因は根深くて、歴史的に日本文化は儒教の影響を強く受けてきました。目上の人を敬いなさいという儒教はモラルとしては正しいのでしょうが、封建主義的にお上が意思決定して庶民は唯々諾々に従うというノリが社会全体で行き過ぎてしまったように思います。上の人がカラスを白と言うなら「はい、白でございます」というのが社会人としての当然のマナー、絶対顔をつぶしてはいけません、みたいな日本企業多すぎませんか？

　僕はクリスチャンですが、キリスト教の文化圏で面白いのは、人間はキングだろうがホームレスだろうが、神の前ではみな完全に平等という感覚です。だから、企業のなかでボスやマネージャー職が「偉い」という概念がほぼない。意見は対等に交わします。上が間違っていると思えば、下の人でも“In my opinion～”でフランクに意見を表明します。自分と異なる意見を言われたからといって、上が「顔をつぶされた」なんて思うこともない。なぜなら現場の人たちが「ハッピーに」効率よく仕事ができるよう「障害」を取り除くことがマネージャーや管理職の役割というマインドが行き渡っているからです。

――確かに日本企業の多くはまだまだ封建主義的ですね。

「バグが出てこないのは品質が悪い！」と叱られ…

牛尾　今となっては笑い話ですが、昔ある企業でやっとの思いでアジャイル開発の導入が認められたんですね。「絶対失敗するからやめなさい」「品質保証できない」と管理職から猛反対されたのを押し切って。

　で、チームが当時の新しいやり方でコードを書きました、テスト駆動開発というのですが、それをしたらものすごくバグが少なかったんです。そしたらなんて言われたか？

「バグが出てこないのは品質が悪い！」

　上の人たちはコードが読めるわけではないので、当時このくらいのコード量を書いたらこのくらいのバグが出るばずだという統計資料があって、「お前らがちゃんとテストしていたら、統計上もっとバグが出るはずだろ！」とお叱りを受けた。

　埒が明かないので、通常はバグに含めない微細なエラーもカウントに含めたデータを再提出して、「失敗しました。どうですか？」「おっ、よくやったな」と（笑）。

――本当にバカバカしい話ですね！

牛尾　実際、日本の開発現場はこんなのばっかりなんですよ。だから日本にいる時は、政治半分・技術半分の働き方を余儀なくされました。上の人の承認やら説得にものすごく労力をとられ、そりゃ優秀なエンジニアが活かされないし、チームとしての生産性が低迷するのは当たり前の気がします。

　先ほど「不確実性」の話が出ましたが、上がガチガチに現場やスケジュールを管理してコントロールしようとするマインドを捨てたらいいのになと思います。詳しくは本書に譲りますが、現場のチームが主体的かつスピーディに判断できるよう権限委譲したらもっと結果が良くなりますし、とくにソフトウェアのような変化の激しい世界で、緻密な計画なんて要らないと思います。AIが超速で進化する時代に、1年後の未来なんて誰もわからないのだから、変化にすぐ対応できる力のほうが不可欠ではないでしょうか。

――もっと主体的に動いて生産性を高めたいと願いつつ、会社の管理システムや請負が多い事業構造などで思うように動けないと感じている人も多くいます。この点についてはどう思われますか？

ソフトウェア開発の内製化が世界的なトレンド

牛尾　日本にいる時によく聞いていた悩みが「うちは請負契約なので無理」でした。日本でウォーターフォール方式が根強く残っているのは、みな企業が必要なソフトウェアを外注していたり、大手SIerも自分たちで手を動かさず、実装を外に安く丸投げしているから、上が管理しやすい方式として都合が良いという事情があります。大量にドキュメント書かせて、チェックします、みたいなのが。

　でも、いま世界的なトレンドでいうと、ソフトウェアは内製化する会社が増えています。SIerもあるにはありますが、別にIT企業でなくても自社でエンジニアを抱えてモダンな開発をする企業が増えました。ウォルマートしかり、ネットフリックスしかり……、とくに後者は技術力の高さで有名ですが、自社サービスの根幹を担うソフトウェアを、外注なんてしてたら勝てなくなってくるのでは？ と思います。

　戦後日本はハードウェアが優れていた分、ソフトウェア開発は長らく下に扱われてきました。でも今や、ありとあらゆる分野にソフトウェアの力が必要になり、グローバルに通用するプロダクトやサービスをつくりたかったら、ソフトウェアの技術力が圧倒的にものをいう時代になった。

　よくみんな「イノベーションが大事だ」っていうじゃないですか。でも世界にないものを生み出すイノベーションって今どき技術もなくどうやってやるんですか？ と感じてしまいます。ソフトウェア技術を軽視して、その現場の効率を高めようともせず、いくらイノベーションをうたったところで絵に描いた餅のような気がします。

　もしあなたの会社が請負仕事ばかりで、現場が理不尽なやり方を強要されているなら、さっさと辞めてしまったほうがいいと思います。合理性のない場所から優秀なエンジニアがどんどん辞めていけば、日本のソフトウェア業界にも流動性が出て各企業による内製化も進み、結果的に日本のためにもなる気がします。

　日本は個々人でみたら技術力の高い素晴らしいエンジニアも多い。そういう方々は英語を勉強するだけでグローバル市場では年収が4～5倍に跳ね上がります。逆にいうと優秀なエンジニアを引き止めておくだけの改革を日本企業はしなくてはいけないし、仕事の請け負い方や開発方式、現場のマネージメント法などは喫緊に取り組むべき課題でしょう。

現場で働く人々の生産性と幸せを高める改革を

――日本ではエンジニアの扱いが低いですからね。

牛尾　大手SIerの中ですら、びっくりするような安月給ですよ。5次請、6次請けで働かされているプログラマーもざらです。僕は子供の頃からプログラマーが憧れで、自分にとってのヒーローでした。だから大人になって、その人たちの実情が安月給で働かされていて、よく分かってない人に命令されているのを見て、ものすごく嫌な気持ちになりました。そうとう勉強して努力して今の仕事に就いているはずなのに、敬意をもって扱われていない現状に。ある年齢を超えて管理職になれなかった技術者の扱いもひどいですね。

　アメリカでは、エンジニアが年を取っても本人が望む限り、生涯現役です。『デザインパターン』という本で有名なエリック・ガンマという技術者が社内にいますが、彼は60代の今でも自らプロダクトをつくっています。人前に出て語っているだけじゃなくて、今もみんなに使われるようなソフトウェアを書いていて、高く評価されている。

　あるいは世界中の企業が使っている「Kubernetes」というプラットフォームの開発者ブレンダン・バーンズという人が社内にいて、非常にリスペクトされて、彼もすごい報酬をもらっています。そういう方々を目の当たりにしていたら、現場の技術者たちはみな「ああなりたいな！」って思えるじゃないですか。

　日本企業は、旧態依然とした因習にとらわれず、さっさと重荷を下ろして、現場で働く人々の生産性と幸せを高めるために改革していったらいいなと思います。本書がその後押しになればこれほど嬉しいことはありません。