日本企業のソフトウェア開発に対する強烈なアンチテーゼ　－　「世界一流エンジニアの思考法」牛尾剛(Ushio Tsuyoshi) 書評

「世界一流エンジニアの思考法」概要紹介

中年になると中々、夢中になって読める本に出会えません。

先日、久しぶりに夢中になって読書できる書籍に出会いました。

「世界一流エンジニアの思考法」牛尾剛(Ushio Tsuyoshi) という本です。

世界一流エンジニアの思考法

著者の牛尾剛(Ushio Tsuyoshi)さんは、シアトルのMicrosoft社でAzure Functions の開発に従事しているシニアエンジニアだそうで、Microsoft社でのソフトウェア開発経験を元に、ソフトウェア開発を円滑に効率良く進める方法論について解説しています。

技術的知識を必要とする内容ではなく、一般の非ITエンジニアの方でも理解できる内容になっています。

　

私にとっても読書をしていて、何度も「ウンウン」と肯いてしまうほど、賛同できる部分の多い書籍でした。

本の内容で、否定する部分も、特に無いです。ほぼ、全ての内容に賛同できます。

　

この本は、ソフトウェア開発における

「生産性の高い開発方法論」

「ソフトウェア開発の心構え(マインドセット)」

「ソフトウェア開発の情報整理や記憶術」

「開発チームの作り方とリーダーシップのやり方」

「ワーク・ライフ・バランスや健康管理」

などのノウハウと方法論を中心とした「ソフトウェア開発の哲学」について書かれています。

どれもMicrosoft社で実際に使用されている方法論ですので、説得力があります。

そして、最後に「AI時代をどう生き残るか」と題して、世界から大きく遅れをとった日本企業の再生戦略について、著者の持論が述べられています。

　

この本の内容は、複数の視点から評論する事ができる幅広い内容で、その多角的視点を一つのブログ記事で、述べることはできません。

　

私としては、この書籍を可能な限り多くの日本の企業人に読んでいただきたいと思いますので、視点を変えて何度も紹介していきたいと思います。

　

その視点の中でも、私が特に印象に残ったのが、「日本のソフトウェア開発との違い」の部分です。

このブログ記事では、「世界一流エンジニアの思考法」の中で紹介された、アメリカと日本のソフトウェア開発の違いにフォーカスして、書籍の内容を紹介したいと思います。

　

ウォーターフォール・モデルは使用されていない

日本のソフトウェア開発は、ほとんどがウォーターフォール・モデルで開発されています。

著者の牛尾剛さんによると、マイクロソフト社でウォーターフォールを採用しているプロジェクトを見たことがないそうです。

ウォーターフォールに対するマイクロソフト社の認識を示すエピソードが書かれています。

マイクロソフト社では、アジャイル開発が主流で、この本のソフトウェア開発効率化のノウハウも開発哲学もチーム構築方法論も、全てアジャイル開発を前提に説明されています。

ウォーターフォール開発を採用している時点で、世界のソフトウェア開発には太刀打ちできない事が良く分かります。

　

「勤勉」と「慎重」へのアンチテーゼ

日本の企業社会では、「必要な仕事を漏れなく全部、頑張って長時間労働でやりきる」ことを美徳としていますが、マイクロソフトに代表されるアメリカのソフトウェア開発では、この点の価値観が真逆である事を、「世界一流エンジニアの思考法」では様々な視点から解説しています。

　

試行錯誤は悪

牛尾剛さんは、「試行錯誤は悪」と説きます。

マイクロソフト社では、必要最小限の労力で効率良く問題を解決する事が尊ばれ、「試行錯誤」などやってはいけない悪手だそうです。

問題が起きたときは、まず事実を確認して、仮説を立てて実証によって、原因を確かめて対策します。

特に、最も少ない労力で、問題を解決する事が尊ばれます。無駄に試行錯誤してたくさん働くことは評価されません。

日本だと沢山働いて、汗水垂らして試行錯誤し頑張った人が評価されますが、この点は真逆です。

急ぐことは生産性を下げる

また、新システムの理解など、優秀な人物でも新しい知識の学習には、凡人と同じように時間が掛かるもので、それを踏まえた計画を立てる必要があるとしています。

日本のように「早く学習できるように頑張る」行為は生産性を下げる有害な行為だとしています。

「頑張っている」「急いでいる」と言った感覚に注目するのではなく、一つ一つの「事実」を積み上げて確認して、最小の努力と作業で結果を出すのがマイクロソフト流のようです。

実際、日本では優秀な人は短時間で学習すると思われがちですが、予備知識の無い新システムの内容など、どんなに優秀な人でも知識のインプットには時間がかかるのは当たり前で、日本ではなぜかこの「当たり前」が通用しません。

「Be Lazy」(怠惰であれ)

プログラマーなら「健全なる怠惰」の概念は知っていると思いますが、日本では経営者や管理職に忌み嫌われ徹底的に無視される概念でもあります。

この本を読む限り、マイクロソフト社の働き方の哲学は、全てが「Be Lazy」(怠惰であれ)という概念を継承しているように読み取れます。

牛尾剛さんは「Be Lazy」の中身を以下のようにまとめています。

・結果を出す為に、最低限の努力をする。

・不必要や付加価値の無い仕事を無くする。

・簡潔さを目指す。

・優先順位を付ける。

・費やす時間より、アウトプットと生産性に重点を置く。

・長時間労働はしない。

・会議は時間内で、価値を出す。

「結果を出す為に、最低限の努力をする」は日本だと「結果を出す為に、最大の努力をする」になってしまいます。

「不必要や付加価値の無い仕事を無くする」は日本だと「全ての仕事を漏れなく寝ないで遂行する」になります。

「費やす時間より、アウトプットと生産性に重点を置く」は日本では「結果より頑張ったかどうかを評価する」になりがちです。

「長時間労働はしない」は日本では全力で否定されます。

「会議は時間内で、価値を出す」などという価値観は日本には存在しないでしょう。だらだらと根回しはしますが、いちまで経っても結論の出ない会議を営々とやっています。

「優先順位を付ける」については日本と同じに見えますが、牛尾剛さんの説明では、その内容は日本とアメリカでは全く異なるようです。

アメリカ人は、2対8の法則(全体の20%の仕事が、80%の価値を生む)に基づき、重要度の高い20%を優先的にやることで80%の価値を生み出し、残り80%の仕事と20%の価値は捨てると言います。

100%の仕事をやろうとしない。

80%の価値を持つ20%の仕事を遂行した後、また80%の価値を持つ20%の仕事を遂行すれば、40%の仕事量で160%の価値になるので、100%の仕事をして100%の価値を得るより合理的だと考えるそうです。

この理屈だと100%分の仕事をすれば、400%分の価値を得ることになります。

言われてみれば「なるほど!」と目から鱗が落ちます。

日本だと「優先順位を付けつつ、全部頑張る」やり方になり、優先順位の高い仕事を朝から取り組み、深夜残業で優先順位の低い仕事を最後までやりきるという、やり方になります。

一流エンジニア達は「いかにやることを減らすか」に頭を使っているそうです。

日本人は全部やろうとするが、「『仕事を減らすこと自体に価値がある」とマインドをリセットすべき』と牛尾剛さんは主張します。

リスクや間違いを快く受け入れる

著者は「成功しようが失敗しようが、まずやってみて、早くフィードバックを得て、早く間違いを修正していく、Fail Fastの精神が重要」と説きます。

アメリカでは失敗や間違いで怒られることが皆無で、失敗によって得られるフィードバックを重要視するそうです。

たくさんのフィードバックを繰り返し、それにより高速で結果を出すことを尊重します。

時間を掛けたからといって失敗をゼロにはできないし、時間を掛けている間にライバルはどんどん次へ進んでしまう。

「リスクや失敗」を恐れる体質は、生産性の面で劇的な低下をもたらしてしまう。慎重になってしまうからだと説きます。

著者のアドバイスとして、

「失敗はただの結果であり、そこでどんなフィードバックを得たかのほうがはるかに重要だ」

「失敗に学ぶ思考の習慣」は生産性を飛躍的に高めるとあります。

　

また、日本人の失敗に対する捉え方については、かなり厳しい指摘をしています。

以下に引用します。

　

不確実性を受け入れる

マイクロソフト及びアメリカのIT企業ではアジャイル開発を採用している事もあり、「計画通り」であることより、「柔軟性」の方がはるかに大切だという考え方になるようです。

「納期は絶対」の神話は捨てようとあります。

「マネジメントは詳細まで細かく練られた計画を期待しない」

「予算と報告のプロセスは精密な結果の予測を要求しない」

など、アジャイル開発を前提とした、「計画変更への柔軟さ」を重視する提案をしています。

アメリカでは、スクラムをソフトウェア開発だけでなく、組織運営にも導入されていて、組織全体がアジャイルの価値観で動いているようです。

そのため、「納期は絶対」の価値観は無く、納期は守り期日にデリバリしつつも、間に合わないものはそのリリースに入れずに次に回すか、もしくはやめるという仕事の進め方になるようです。

「ソフトウェア開発は計画通りには行かない」とプログラマー常識を堂々と言えるところは羨ましくもあります。

間違える事を恐れず、気軽にディスカッションを繰り返す

また、初歩的な事でも気にせず、エキスパートに質問したり、意見が違うときは、遠慮せずにディスカッションを繰り返す事を重視せよと言います。

意見が違っても、いちいち相手の人格を否定しない事を指摘します。

この辺は、非常にアメリカ人らしい点です。

「リスクや間違いを快く受け入れる」考え方とも整合性がとれています。

サーバントリーダーシップ

チーム構築やリーダシップのやり方も日本とはかなり違うようです。

日本では上司が部下を支配して、指揮命令して管理する「コマンドアンドコントロール」というスタイルでチーム構築しますが、このやり方を「メンバーを子供扱いしたマイクロマネジメント」と評して批判的です。

アメリカでは、スクラムを採用しているが故に「サーバントリーダーシップ」を採用していて、リーダーはビジョンとKPIは示すが、実際にどのように動くかは、チームが主体的に考えて意志決定して仕事を進めるそうです。

サーバントリーダーシップはスクラムの手法でもありますから、ある意味当然とも言えます。

日本からアメリカに来たマネージャはパワハラで訴えられる事が多いそうで、このリーダーシップ手法は、日本の管理職には馴染みにくいやり方のようです。

「大企業で勤めるある人は『事業部長クラスでもたかだか100万円の決裁権もない』と嘆いていた」というエピソードも紹介され、日本型組織の組織運営手法で国際競争を生き残れるのか不安になる解説もしています。

ワーク・ライフ・バランスや健康管理

日本の長時間労働は日本人の方が良く知っているので、この点では日本型組織がアメリカに大きく劣っていることは、わざわざ解説も必要無い現実です。

特に日本のIT業界は、建築業界の2倍以上も精神疾患の発症率が高いことを厚生労働省が公表していますから、否定できない事実でしょう。

マイクロソフトでは、各人が自由に勤務形態を選べるので、ライフスタイルに合わせてみんな違う働き方をしているそうで、この部分はただただ羨ましいばかりです。

　

日本再生への道筋

著書の最後に牛尾剛さんは日本のIT産業と、日本企業のソフトウェアの扱い方について、かなり厳しい指摘をしておられます。

この部分は以下に引用させていただきます。

　

この意見には、100%同感です。

デフレ脱却と多重請負丸投げ体制

私見ですが、日本でSIer業界に代表されるソフトウェア産業の多重請負構造が出来上がった原因として、30年という長期にわたるデフレ経済があると考えています。

開発工程を下請けに丸投げにする慣習も、デフレ不景気による「人余り」があるからこそ成立する方法論であり、人手不足のインフレ経済では必要な時に、下請けに必要な人材が確保できなくなりますから、実現不可能になっていくでしょう。

以前の記事でも書きましたが、日本のデフレは終了し、もうすぐ本格的なインフレ経済が始まります。

デフレ脱却とSIer業界の関係についての考察

人手不足のインフレ経済になれば、これまでの多重請負丸投げ体制は維持するのが困難になり、現在の体制はゆっくりと崩壊していくものと予想しています。

　

そして、多重請負体制の後には、インフレ人手不足経済に合った体制が必要になります。

そのとき、日本のIT業界がどんな体制になるかは、予想できませんが、この「世界一流エンジニアの思考法」に書かれた様な世界になれば良いと切に願います。

上の画像クリックでAmazonの販売サイトへ移動します。