PIVOT TALK TECH
世界一流エンジニアの自己変革法
(293)
1.6万回視聴
2024年12月16日
日本のソフトウェア開発の問題点とは? 効率的なマネジメントとは？米マイクロソフトの現役ソフトウェアエンジニアの牛尾剛が超巨大クラウドの開発の最前線で学んだ仕事術について話を聞いた。 ＜ゲスト＞ 牛尾 剛｜米マイクロソフト シニアソフトウェアエンジニア 1971年、大阪府生まれ。シアトル在住。関西大...
世界一流エンジニアに聞く！日本人はなぜ変化が苦手なのか？
日本人はなぜ変化に弱いのか？アメリカマイクロソフトのエンジニアであり、ベストセラー「世界一流エンジニアの思考法」の著者である牛尾剛氏が、日本とアメリカの仕事文化の違いや、変化への対応方法について語る。牛尾氏によれば「みんなができないと思い込みすぎ」なのが問題だという。日本人が変化に強くなるためのヒントとは？
Q. 日本人はどうやったら変われるのでしょうか？
普通に変われると思います。みんながただ「できない」と思い込みすぎているだけです。それが問題なのです。
例えば、アメリカに行った時の体験を話しましょう。私が英語の勉強のために雇っている先生は高齢の女性なのですが、彼女は普通にPCを使いこなし、オンライン決済ツールで支払いを請求してきます。ITに強いわけではないのに、ビジネスに必要だからという理由で普通に使いこなしているのです。
日本の場合、「パソコンが難しい」と言われますが、実際にはボタンを押したり文字を打ったりするだけで、本質的には難しくないはずです。むしろ高齢者こそ頭を使うべきでボケ防止にもなるはずなのに。アメリカのおばあちゃんができるように、苦手な人でもできないわけではなく、単にやっているかやっていないかの違いだけです。
Q. 日本人は変化に対する抵抗が強いのですか？
各国で変化に対する抵抗がどれくらいあるかを分類した調査では、G7の中で日本がダントツのナンバーワンです。ただ、日本人だからできないということではなく、環境が変われば日本人も変われます。アメリカで働いている日本人は変化の激しい環境にちゃんと適応しています。
Q. IT業界では計画と変化の関係はどうなっていますか？
日本の場合、計画をしっかり立てて、それを守るよう頑張りますよね。しかしアメリカでは、特にソフトウェア開発の現場では見積もりすらしないことも多いです。「納期」という概念もほとんど存在せず、「このくらいの時期に出てきたら嬉しい」程度の認識です。
計画がそのまま遂行されるものとは思っていません。なぜなら変化があるからです。例えば突然新しい技術が発表されたり、使っているライブラリが更新されて動かなくなることもあります。誰も想像できない世界なのです。そういう状況では、無駄に計画を立てるより、変化に対応する方が重要です。
Q. アジャイル開発とウォーターフォール開発の違いは何ですか？
ウォーターフォールは昔からある開発方法で、要件定義、設計、コーディング、テストというフェーズを滝のように順番に進めます。一方アジャイルは、そういったフェーズに分かれず、繰り返し開発して設計や要件定義を行ったり来たりしながら製品を作っていく方法です。
実は、ウォーターフォールは最初から間違って広まったものです。原論文には繰り返しの記述があったのに、それが削除されて広まってしまったのです。ソフトウェア開発では、フィードバックを受けないと非常に難しいので、アジャイルの方が向いています。
私はアジャイル的な開発を2002年の時点で日本の大手SIで自分のチームに取り入れていました。だから「今の日本では難しい」という言い訳は半分嘘だと思います。
Q. アメリカと日本では開発スピードに違いがありますか？
実は日本の方がスピードは早いと思います。アメリカでも最新の開発手法を使っているわけではなく、各チームが自分たちのやり方を考えています。マイクロソフトでさえ標準的な開発方法を定めておらず、各チームに任せています。
一番重要なのは、ある固定的なやり方が正しいという考え方ではなく、常に変化することです。今の時代、例えばAIの新しいモデルが発表されれば世界が変わってしまいます。そんな時に開発方法論を3ヶ月考えて定義しても、時代遅れになってしまいます。
Q. 優先順位の付け方にも違いがありますか？
日本では「優先順位をつけましょう」と言ったら、1番、2番、3番とやり、4番、5番もできたら頑張ろうという感じです。しかしアメリカでは、P0(最優先)、P1(次点)という風にして、基本的にP0しかやらないくらいの感覚です。他はやらないか、状況が変わって優先度が上がったらやる程度です。
これが重要な理由は、人間は物理的にたくさんのことはできないからです。パレートの法則で言えば、2割のタスクが8割の価値を生み出します。重要なものだけをやって8割のリターンを得るか、全部やって100%にするかで考えると、同じ時間でより重要な別の仕事に取り組む方がインパクトが大きいのです。
Q. 会議や不要な業務の扱いはどう違いますか？
アメリカでは会議がもう必要ないとなれば、その週からなくなります。日本の組織は一度始めたものをやめられないという傾向があります。これは「変化に弱い」ということの具体例でもあります。
実はこれにはお金もかかりません。マインドの問題です。日本は肩書きへのこだわりが強く、標準化された方法があると安心するようです。しかしIT技術は常に変わっていくので、それに合わせてやり方もちょっとずつ変えていくべきなのです。
Q. 日本では手を動かす人が下に見られる傾向がありますか？
日本の場合、手を動かす人に対して下に見る傾向があると感じます。コンサルタントや指示するマネージャーが偉いというイメージがありますね。アメリカでは手を動かす人へのリスペクトがあります。
マイクロソフトのような大企業でも、みんな最後までコーディングをします。プログラミングが簡単だと言う人は誰もいません。実際にやるから難しさも分かっているのです。障害が起きれば夜中に起こされることもありますが、そういうフィードバックを得てエンジニアとして強くなります。
日本では「プログラミングは簡単です」と言いながら、少しでもプログラミングに興味がある人をエンジニアにして「下の層」を増やす傾向があります。一方アメリカでは、エンジニアは医者と同じくらいの社会的地位があります。
Q. アメリカではマネージャーの役割はどう違いますか？
アメリカのマネージャーは指示するのではなく「アンブロック」することが主な仕事です。プロジェクトで最もコストがかかるのは何かに「ブロック」されている状態です。例えば「このライブラリではこの機能を実装できない」とか「この人が承認してくれないとリリースできない」といった状況です。
マネージャーはこうした障害を取り除いてくれます。必要な人を紹介したり、自分が承認したり、専門家につないでくれたりします。あくまでサポーターの役割なのです。
また、アメリカのマネージャーは技術バックグラウンドを持っていることが多く、自分でもコードを書いたりテストしたりします。日本のような「発注屋」になることはなく、実際に手を動かす文化があります。
Q. 日本の企業の「中間業」の多さについてどう思いますか？
日本にはSI業界や広告代理店など「手配師」的な業種が多いですね。例えばソフトウェア業界では「20次受け、30次受け」のような多重下請け構造があります。しかし、これでは技術力はなかなか上がりません。
アメリカでは、エンジニアとしての道とマネージャーとしての道が同等に評価され、どちらを選ぶかは本人次第です。プログラマーとして極めていってもきちんと給料が上がり、「プリンシパル」「パートナー」といった上位職階もあります。どちらが上という感覚はなく、バランスが取れています。
日本のように「マネージャーになれば給料が上がる」という構造だと、優秀な技術者もマネージメントに回ってしまいます。