【書評】『世界一流のエンジニアの思考法』（牛尾剛）
お薦めの本の紹介です。
牛尾剛さんの『世界一流のエンジニアの思考法』です。
|
|
牛尾剛（うしお・つよし）さんは、ITエンジニアです。
現在は、米マイクロソフトAzure Functionsプロダクトチーム シニアソフトウェアエンジニアとしてご活躍中です。
「思考法」（マインドセット）が高い生産性を形づくる！
自らを、エンジニアガチの「三流」
だという牛尾さん。
そんな牛尾さんが、世界でも最高峰のIT開発チームの一員として長年働くことができている理由。
それは、偶然と小さなチャレンジの積み重ね
てきたからだと述べています。
元来、私は、幼少の頃から何をやっもできない“要領の悪い”子供だった。とにかくパソコンが大好きで、シャープのポケコンやMZ-2500をいじっては、雑誌に載っているゲームのコードを丸写ししたりして遊んでいたが、何かに取り組むときは、人の3倍ぐらい努力してようやく「人並み」になれる程度だった。
とくに才能があるわけでもないのに子供の頃からずっとプログラマに憧れていた。日本で就職した最初の会社では，「UNIXのコマンドを担当したいです！」と意気込んだが、希望かなわず5年間営業職を務めた。あるときようやくシステムエンジニアとして働くチャンスを与えられたが、全くプログラムが書けない不甲斐ない日々が続く・・・・・・。
実は大人になってからADHDと診断された私は、自分の不器用さや記憶力の低さ、頭の中で思考が乱れ飛んでまとまらず、ぐったり疲れてしまう感覚に、長年悩んでもいたのだ。だから、どうやったら不得意なことでも効率よく人並みのことができるのか、仕事の生産性を上げる方法を意識的に研究してきた。
そのおかげで、できる人だと構造的に見落としてしまうであろう部分ーー初心者はどこでつまずき、何に無駄な時間を使ってしまうのか、どうやってなるべく楽に「底上げ」してマシにするのか、への感度が人一倍高まった。
そんな頼りない私でも、社会人経験を重ねるうちに、いくばくか才能を発揮できる分野があることを発見した。それはすべて「誰かにやってもらう仕事」だった。
2001年頃、「アジャイル」（Agile）というソフトウェアの開発スピードを飛躍的に高める手法に出会って心底衝撃を受け、自分なりの武器がほしくてそのコミュニティに参加したりして徹底的に学んだ。そこで経験を積んでアジャイルのコーチをする中で、コンサルティングやプロジェクトマネジメント、エバンジェリスト（ITのトレンドや技術についてわかりやすく説明し、啓蒙する職種）などの立場で「人にやってもらう」仕事を仕切ると成功することがわかった。マイクロソフトではエバンジェリストとして採用され、国際カンファレンスでの講演なども多数行って評価を受けてきた。
ところが、「プログラマ」だったから、プログラマの仕事に何度もチャレンジした。そのたびに、「牛尾さんは、PM（プロジェクトマネージャ）だったら才能あるんだからそっちをやれば？」「なんで、エバンジェリストに特化しないの？」と言われてきた。
でも、本当に心からやりたい仕事は、ソフトウエアのクリエータである「プログラマ」なのだ。憧れの火が消えることはなかった。自分でも才能がないのはわかっているが、どうしてもなりたかったから、努力と工夫を重ねて44歳でマイクロソフトに転職し、4年前からは本場アメリカで、数少ない日本人のクラウドエンジニアとして今こうして働いている。
所属チームはグローバル規模のクラウドの中身を開発しているから、文字通り「世界一流」エンジニアたちばかりだ。彼らが楽しみながら、トップニュースになるようなサービスを次々と生み出していく姿に何度も衝撃を受けた。
なぜ彼らは圧倒的に仕事ができるのか？
実は、彼らはなにも全員が常人と比べて著しく頭の回転が速いわけでも、天才的記憶力を持つわけでもない。
主に「思考法」（マインドセット）が高い生産性を形づくっているのだ。小手先のテクニックでもなければTipsでもなく、その圧倒的なパフォーマンスは思考法から生まれているという事実。彼らと共に働いてこの本質を理解したとき、私の仕事のスタイルは激変し、文字通り「人生が変わった」。
日本ではろくに「プログラマ」として通用しなかった私が、彼らの思考法を注意深く真似て実践することで、本場のアメリカの世界最高峰のドリームチームの一員として活躍することができている。長年、自分はできていないと思い込んでいた三流エンジニアに、奇跡が起きたのだ。
（中略）
ソフトウェア開発に限らず、世界から日本を見ると「生産性の悪さ」で“大損”している分野が非常に多い。それは単にDX（デジタルトランスフォーメーション）化が遅れているといった次元の話ではなく、生産性の要となるマインドセット、チームビルディングにまだまだ大きな改善の余地があるのだ。
本書の裏テーマとして、日本でアジャイル、DevOpsをはじめとする最新技術やプロセスの導入を米国並みのスピードにしたいという思惑もある。AIというゲームチェンジが本格化してきたこの時代、これは喫緊の課題とも言えるだろう。技術革新は待ってくれない。
とくにグローバル企業のスピード感で技術導入を目指すビジネスパーソンや企業にこそ、生産性を加速するための西洋文化のマインドセットを学んでほしい。
ツールは目まぐるしく変わり、超速で進化する。だが現場で使うのは人間なのだ。人間がテクノロジーとどう向き合い、どう使いこなすのかが問われている。
この本の核心にあるスキルは、〈AI時代を生き延びる思考法〉といってもいい。
本書の知見を体得して、日本人の強みを生かせれば、ソフトウェアの世界でもきっと日本は輝ける存在になると私は信じている。実例などに専門的な話題も多く出てくるが、業界・業種を問わず、考え方のエッセンスを生産性アップのヒントにしていただけたらと願っている。少しでも皆さんが、自分自身の「夢」に近づけますように！
『世界一流のエンジニアの思考法』 はじめに より 牛尾剛：著 文藝春秋：刊
本書は、牛尾さんが、どうやって、一流エンジニアたちの思考法にもまれて、仕事の質と効率をテクニカルに高め、ソフトウェア開発の最前線で働いているか、現場で掴んだ技
をわかりやすくまとめた一冊です。
その中からいくつかピックアップしてご紹介します。
スポンサーリンク
[ad#kiji-naka-1]
「生産性の高さ」の違い
牛尾さんがマイクロソフトのAzure Functionsというクラウドサービスの開発チームに入ってまず驚いたこと。
それは、その圧倒的な「生産性の高さ」
で、一部の優秀な人が突出して頑張っている様子ではなく、チーム全員のベーシックな生産性が異様に高い
と指摘します。
あるとき、同僚のポールと仕事をする機会に恵まれた。ポールは初期からアーキテクチャ（情報システムの設計）をつくり上げてきたメンバーで、私が人生で出会った中でもっとも賢い男だ。何をやっても高速で丁寧、どんな問題が発生しても短時間で解決するその技術力はため息が出るほど素晴らしく、新しいアーキテクチャに関する論文をいくつも執筆している。
彼と仕事をし始めたとき、私のスキップマネージャ（2つ上の上司）が「世界一流のエンジニアと仕事できてうれしいだろ？」と誇らしげに声をかけてきた。自分は「もちろん」と即答したが、それほどまでに彼は社内評価も高いエンジニアなのだ。
ポールは私より頭の回転も速いし、記憶力も抜群に良かったが、同時にこう確信した。
「彼は人生で自分が会った中でもっとも賢い人だけど、それでも、自分と比べてとても追いつけないほど脳みその性能が違うわけではない」
衝撃を受けつつも、私でも真似のできた、彼の思考回路をたどっていこう。ある日、私のプログラムが上手く動かないときがあった。もちろんこれを自力で直しても良いのだが、今までの経験からすると、原因究明に何時間、もしくは何日かかかるだろう。
ポールだったらどういう風に思考するのだろうと思って、「ペアプログラミング」をお願いすることにした。ペアプログラミングというのは、2人１組で1台のPCを共有し、一緒にプログラミングする手法で、互いの技術を学んだり、コードのコンテキスト（背景）を理解・共有するのにものすごく有効だ。私はポールに言った。
「私のプログラムで問題が起きている。私はいつも生産性がよくないので、何か悪い癖があると思うんだ。君だったらどうやるのかを学びたいと思っているから、ペアプログラミングをしてくれないか？」
「君が何を求めているのかはわからないけど、いいよ」
私は自分のプログラムに問題があることを示す「ログ」を表示していた。ログとは、プログラムが内部でどのように動いているかを示す記録だ。それを見ることでプログラムが正しく動いているのか、問題が発生しているのかをチェックすることができる。
普段の私なら、ログで問題を見つけたら、「ここが原因かもしれない」「いや、あそこの不具合だろうか」と試行錯誤をする場面だ。あたりをつけて修正して、プログラムをサーバーに移動させて、動かして、またログを見る。ログは反映されるまでに15分くらいかかるから、いくつか試すのもかなり時間がかかる。
ところが、ポールがとった行動は、私と真逆のアプローチだった。彼は最初の一つのログだけを見て「仮説」を立て始めた。手は一切動かさない（下の図1を参照）。
「このログが出ているということは、自分の推測では、内部でこういうことが起こっている可能性が非常に高い。そこを鑑みると、調べるべきは・・・・・・」とぶつぶつと独り言を言いながら、データベースを閲覧するソフトを起動し、クエリ（システムへの命令文）を一つだけ書いてこう言った。
「ここだろう」
なんとそのクエリの結果は、私のプログラムの問題の根本原因をズバリ指し示すものだった。彼が手を動かしたのはその一回きりだ。
自分だったらああでもない、こうでもないといろいろクエリしたりコードを見たりして数時間かかる問題を一瞬で魔法のように解いてみせたのだ。私は雷に打たれたような気分だった。恐ろしいことに、そのコードベースに関して、彼は経験がほとんどない。そのプログラムが書かれたサービスのコードは、むしろ私のほうが知っている。
ソフトウェアの世界では、できるプログラマとできないプログラマの差は25倍あると言われているが、こういうことなのだと実感できる出来事だった。ただ、彼は人間に不可能なことを実行したわけではない。同僚のバーラが言っていたことを思い出した。
「障害を調査するとき、いきなり手を動かして、試行錯誤していろいろクエリを投げてはダメなんだ。ログを見て、自分で多分こういうことが起こっていると推測して、その推測に合ったクエリを投げてそれを証明するんだよ」
いきなり手を動かさない。まずは、事実（データ）を一つ見つける→いくつかの仮説を立てる→その仮説を証明するための行動をとる。
つまり、むやみやたらに試行錯誤するのではなく、まず自分の頭のメンタルモデルを使って仮説を立て証明する。メンタルモデルの構築については後ほど詳述するが、この一連の手順が、手当たり次第に可能性を試すことによる時間のロスを排除し、圧倒的な効率を生んでいるのだ。
プログラミングの生産性というのは「頭脳労働」であるということを実感した瞬間だった。頭の使い方によって、生産性が天地ほど違うというのはこういうことなのだろう。日本では、まず自分の力で試行錯誤することが尊ばれるし、まわりからも評価される。だが、IT技術者には試行錯誤がとても良くないのである。もう一つ例を挙げよう。
あるとき日本に一時帰国中に作業していると、ログを管理するプラットフォームで、ログファイルを見ると完全に正常に動いているようにしか見えないのにクラウドのポータル（最初に表示されるWebサイト）のほうには、遠隔からのデータ（テレメトリ）が来ていないという奇妙な現象が生じた。
チームのメンバーにTeamsで画面共有をして、「ほら、出ないでしょ？」と見せると、なぜかそのときは、テレメトリがポータルに来ている。その後自分で何回試しもやっぱり出ない。もう一回別のメンバーに助けを求めるチャットを書いて「Fiddler（ネットワークのモニタリングを行うツール）使って分析したらいいんじゃね？」とアドバイスをもらった瞬間にポータルを見ると、今回だけテレメトリが出ているというまるで呪いのような症状だ。
そこで私は、いろいろと試行錯誤した。パケットがたくさん送られたときにカットされてしまうのが原因か、ポータル側でフィルターがかかったのか等、様々なアイデアが錯綜する。スクリプトの実行パターンを数個だけにしたり・・・・・私は各パターンを試して問題解決をはかろうとした。
だが、丸一日つぶしたあげく、これらの試行錯誤はすべて失敗に終わった。ふと、チームの一人が「ちゃんとデータは出ているよ」と説明してくれたことが脳裏をよぎった。そう言えば、彼女は、スクリプトを使わず手動でテストしていた。
問題は「スクリプト」だったのだ！ そこから意味不明の挙動の正体を特定し、問題を完全に解決した。
問題は解決できた。一日以上使ってやっと。
しかも振り返ってみれば、丸一日かけたのに、私は「何も成長していない」のだ。単に思いつきでいろいろなパターンを試して正解を探しているだけなので、とても時間がかかる上、新しい知識を何も学んでいない。
まったく同じ状況で、同じ問題が起こったら、メモをとっておけば、次回の解決に役立つだろうが、問題が少しでも違えばお手上げだ。似たような問題が生じれば、また同じだけ時間を使ってしまうことも十分あり得るのが残念すぎる。
プログラマとして問題を一瞬で解決する達人のトラスクが、私にアドバイスしたのは、試行錯誤するのではなく「Fiddlerで分析したら？」だった。
Fidllerを使えば、Application Insightsからどういうデータが出ているかはチェックできる。私はそれをどうやって適用するのかがわからず、どうにもならなくなったらやろうと考えて、最後にとっておいたのだ。
私のとるべき行動は、ますFidllerでモニタリングすることだった。Fidllerを見たら、WSL2側からテレメトリが来ていないことか一発でわかったはずだ。
もしもそのルートを選んでいれば、問題の原因にかなり早くたどり着けただけでなく、「FiddlerをWSL2と一緒に使う」やり方を試すこともできた。つまり、特定の状況に限定されす、さまざまなケースで使えるツールの使い方を学ぶ機会となり、「未来の生産性」が向上したはずなのだ。
思いつきによる試行錯誤は「悪」なのだということを、身をもって実感した出来事だった。『世界一流のエンジニアの思考法』 第1章 より 牛尾剛：著 文藝春秋：刊
それだと、原因の可能性をすべて潰せない恐れがあります。
また、たとえ解決しても、後になって何が原因だったのか分からなくなる恐れもあります。
手間でも、頭の中で仮説をつくりながら、一つひとつ可能性を消していく。
実は、それが回り道のようで、一番の近道なのですね。
「Be Lazy」というマインドセット
一流エンジニアたちが身につけている、仕事を加速させるマインドセットの一つに「Be Lazy」（怠惰であれ）があります。
「Be Lazy」とは、端的にいうと、より少ない時間で価値を最大化するという考え方
で、できるだけ最小の労力で楽をする方法を探ろうというマインドセット
のことです。
Be Lazyを達成するための習慣は、次の通りだ。
｜・望んでいる結果を達成するために、最低限の努力をする。
｜・不必要なものや付加価値のない仕事（過剰準備を含む）をなくす。
｜・簡潔さを目指す。
｜・優先順位をつける。
｜・時間や費やした努力より、アウトプットと生産性に重点を置く。
｜・長時間労働しないように推奨する。
｜・会議は会議の時間内で効率的かつ価値を提供する。この一覧を見ると、たいていの人は「当たり前じゃないか？」と思うだろう。だがそこに意外な落とし穴がある。
例えば「優先順位をつける」という項目について考えてみよう。よくスクラム等で言われる言葉で「バックログ（やるべきことリスト）に優先順位をつけて、優先順位の高いものに集中しよう」ということがある。この言葉を聞いて、日本人一般の頭に浮かぶのは図6の左側のようなイメージだ。リストに上がっているタスクが五つあるとして、「全部はできないから、優先順位をつけて、どうしてもできないのは無理だから実施しないようにしよう。でも時間が許せば全部実施したい」と（下の図6左を参照）。
ところが、同じ言葉に対して海外のメンバーなら、図の右のようなイメージをもつ（下の図6右を参照）。
「最初の1個をピックアップしてやったら他はやらない。その一つにフォーカスしよう」という感覚だ。
こういう場面はインターナショナルチームにいると頻繁に目にして、そのたびに驚いてきた。
例えば、私がエバンジェリスト時代に「バリューストリームマッピング」（詳しくは後述する。83頁参照）という、メンバー間でプロジェクトの無駄を発見するセッションを同僚のデビッドとやったとき、彼は「リリースマネジメント」というDevOpsプラクティス（開発担当者と運用担当者が連携してスピーディーにシステム開発を行う手法）の一つしかアドバイスしなかった。メインのプラクティスだけでも7個ぐらいあるのに。
「DevOpsプラクティスのAutomated Testingもできていないし、他にもいろいろあるじゃない。なんで一つだけしか言わなかったの？」と尋ねたら、「だって、たくさん言ってもできるかな？ まず一番インパクトのある一つを確実にすることが大切なんだ」と言う。
我々日本人はすぐに「あれも、これも」やらないといけないと思いがちだが、「すべき」より、「実際にできるキャパ」を考えるほうが生産性には有用だ。いわゆる〈2-8の法則〉でも、20％の仕事が80％の価値を生むのだから、20％をしっかりやればよくて、100％全部やろうとすると工数もかさむし、時間が足りない。
100個のタスクがあったら、本当に重要なのは20％程度なのだ。海外チームのメンバーを観察すると、20％のタスクを終えて80％の価値を出したら、残りの80％はやらずに、次の80％の価値を生む20％の新しいタスクに取り組んでいる。そうすれば、100％の仕事に時間を費やしたケースに比べて、40％の工数で160％の価値を持つ仕事ができることになる。
ざっくりとしたイメージでいうと、彼らが無理なく生産性が高いのは、こうした理由による。実施すべき「物量」が少なく「価値」が高いものを如何につくっていくかの工夫を常日頃からしているのだ。一流エンジニアたちは「いかにやることを減らすか？」に頭を使っている。一般的にたくさんの機能を速く実装することはいいことだと思われがちだが、本当は「悪」だ。なぜなら、統計によると実際はソフトウェアの機能のうち40％ぐらいしか使われないからだ。100％を全力でつくっても60％は使われないし、しかもそこでバグが発生したらその都度直さないといけなくなり、コードベースが多くなるので、変更があったときにコードを読む量が増えてしまう。
つまり、Be Lazyの精神で「やることを減らす」のは大変素晴らしいことなのだ。ところが日本人の感覚からすると、全部やらないのは何となく悪いことのように感じてしまい、現行の手続きやすでに決まっているタスクを「減らす」のがとても苦手だ。しかし重要なのは、「減らすこと」自体に価値があると、マインドをリセットすること。
例えば、私がマイクロソフトに在籍しはじめてから、すでに2回報告システムが変わっているが、その度にどんどん手続きが楽になっている。ミーティングも毎週だったものが不要になってきたら2週間に1回になったり、1年に4回あったレビューが少なくなったり等、業務上の負荷が減っている。
すると、そこに使っていた時間的・体力的リソースを他のより優先順位が高いことに使えるようになり、「より短い時間で、価値を最大化できる」。
完璧主義傾向の強い人は、相対的にさほど重要でないものも同じ感覚で「ピカピカ」に磨き上げてしまうため、時間がかかってしまいがちだ。むろん、これにはいい点も悪い点もある。例えば欧米人は細部までピカピカに磨いて完成度を高め能力が日本人に比べて乏しい。
問題なのは、重要ではないことまで、過大な工数を使ってしまうことだ（例えば、文章を書くときにExcelの細かいレイアウトまでこだわるとか）。優先順位の低いことはやめ、重要なことだけをピカピカに磨くことで、競争力は飛躍的に高まるはずだ。
プロダクトオーナーからマネージャ、チームメンバーまで、全員がこの意識を共有することで、ストーリーの優先順位づけや、機能のどれを実装するかという場面で合理的な判断がスピーディーにできる。
プロジェクトにかかわる人全員で、本当に必要な機能は何か、不要な機能は何かを見極め、プロセスの改善を実施していかに「楽」をしてより高い価値を生み出せるかをディスカッションする必要がある。では、その手順を具体的に見ていこう。1．一つだけピックアップする
インターナショナルチームで周りを観察すると、一番実践しているプラクティスだ。私は優先順位をうまくつけるのが本当に苦手で、あれもこれも大切に見えてしまう。だから思い切って、「一番重要なのはどれか？」を考えてそれだけをやるようにした。
最終的に三つピックアップするケースでも、まず最初に一つだけピックアップしてから、あとの二つをピックアップする。残りをスルーするのは最初は恐怖だろうが、結局はユーザー側もたくさんあると理解できない。よく使う機能はせいぜい三つくらいだろう。
まず、一番重要な「一つだけ」をピックアップする癖をつけると、時間がないときも、少なくともポイントを外さない仕事を高速で回せるようになってくる。そうすると、案外「やらないといけない」と思っていたことをやらなくても、問題にならないことがわかってくる。
無論すべてのケースで「一つだけピックアップ」方式が通用するわけではないが、これを3回繰り返せば三つピックアップできる。重要なのは、10個のうち1〜3個しかやらないことは決して悪ではなく、そのほうが「バリュー」として効果的なことを体感することだ。2．時間を固定して、できることを最大化する
あれもこれも「すべき」というマインドだと、どうしても時間をだらだらと延長してしまいがちだ。海外のチームメイトを観察していると、「すべき」から時間を計算するのではなく、時間は固定して、その中で価値を最大化するという行動をとっている。
例えばロッシェルさんと打ち合わせをするときも、「あれも、これも課題だな」と思っても、時間が延びることはまずなく、この時間でできる範囲の中で、最大限バリューが出ることにフォーカスして、「今日はこの二つだけやろう」といった思考に切り替わりる。
時間が最大の制約なので、時間内に確実にできる数に絞って、最大の成果を出せることに集中する。皆さんも、なんにも準備できていないのに急に明日プレゼンをすることになったら、無理なものは諦めて、バサバサと要素を切り捨てているはずだ。きれいなドキュメントをつくる暇はなく、「やること」の数を減らし、本当に重要なことのみ時間内に伝えられるように意思決定せざるを得ないだろう。
「まだ完璧じゃない」と最初は怖くなるかもしれないが、そこで「抜けていく」ようなことは大抵あまり重要ではないし、必要なことなら他の誰かからフィードバックを得られるので、臆せずスピーディーに実施するといい。3．「準備」「持ち帰り」をやめてその場で解決する
日本では、会議というと、事前の準備をし、終わった後に、議事録を書いたりして様々な課題を検討しないといけない状況だった。
インターナショナルチームを観察していると、彼らは常に「会議の場」だけで完結する。ざっくりしたアジェンダ（検討事項）はあるが、準備に時間をかけて会議に臨ことは一切しない。議事録もその場で要点だけをノートアプリのOneNoteにとって共有される。プレゼンテーションの会議なら、「後で書き直します」みたいなことはせず、その場で資料を修正する。そうすれば終わった後に作業時間を取らなくてよく、会議の時間内に必要なことを共有できる。さらに、会議後の「宿題」や「持ち帰って検討すること」も滅多にない。必要な「意思決定」は、極力その場で行う。
つまり、会議に出たら「会議の時間内だけで完結」するよう訓練すると、非常に生産的だ。
昔、私がコンサルタントをしていたとき、ソニックガーデンの創業者・倉貫義人さんからもらった一言は忘れられない。
「牛尾さん。会議の準備をしないでくださいね、無駄だから。そうじゃなくて、会議の時間を価値の高いものにしましょう」
倉貫さんとの会議は常に生産的で、その場ですべてを解決するスタイルだった。会議の前にも、後にも時間は不要だった。その潔さが、濃密な価値を生んでいた。
最初どれぐらい準備をしなくてもいいのかが掴めなかったら、いっそ「準備なし」でどこまでできるか試してみるとよいだろう。そして、できるだけ「会議の時間内」のみで完結できるように努める。案外かなりの程度「できる」ことに気づくはずだ。
できない場合は「余計なこと」を頑張り過ぎている可能性が高いので、日頃の業務から不必要なものをできるだけ減らしていく練習をするとよいだろう。4．物理的にやることを減らす
マイクロソフトの開発チームでは「スプリントプランニング」という定例のミーティングがあり、2週間で実施するタスクの整理をマネージャと一緒に行う。日本の進捗会議といえば、何ができていてどれが遅れているという報告の場であったと思う。マネージャから、予定していた要素を外す話はまずなく、人を投入してどうやって全部やるか？ に頭を使っていた。
こちらでは、マネージャ自身が「このタスクあんまり重要じゃないから、2週間でやる必要ないね」と言って簡単にスコープ（予定していた機能）から外す。どんどん仕事が減っていくし、そのまま二度とやらなくなったタスクもある。みんなが絶対的に重要なタスクにフォーカスできるように気を配ってくれている。
物理的にできないものは頑張ってもできない。だから、自分の仕事の中で「何をやらないか」をどんどん決めていこう。計画なんてものは当初の予測であって、正解とは限らない。予測不能のことは起こるものだし、優先順位は刻一刻と変わっていくもの。仕事は「どれだけやったか？」ではなく、「どれだけ会社にインパクトを与える仕事ができたか？」のほうが重要なのだから。以上の四つは、いきなり実践するのは簡単ではないだろうし、経験を積まないとさじ加減が理解できないかもしれない。しかし意識的にBe Lazyの思考法を実践していくとだんだん上達してくるし、限られた時間内での価値の高め方が個人としても組織としても上手くなっていくだろう。
『世界一流のエンジニアの思考法』 第2章 より 牛尾剛：著 文藝春秋：刊
「手を抜くのは良くないこと」という意識も強いですね。
本当に重要なことだけに集中する。
それ以外は、潔く切り捨てる。
私たちも「Be Lazy」のマインドセットを身につけたいですね。
「マルチタスク」は生産性が最低なのでやらない！
現代の働く環境において、避けて通れないのが「マルチタスク」です。
同時にいくつもの業務をこなさなければならない「マルチタスク」は、生産性を低下させる元凶です。
私自身はマルチタスクがとても苦手だ。マイクロソフトでは、「電話番」と呼ばれるマルチタスク業務が尋常でない期間がある。普段はソフトウェアの開発に集中できるが、数週間に1週程度、お客さんから上がってくるインシデント（システムの問題や障害レポート）にのみ対応する期間があって、そうなると、複数のインシデントに対応しなければならず、いろいろな人から連絡が入り、開発側からのリリースもやらないといけなかったり等、マルチタスクが一気に押し寄せる。
そんな環境を乗り切るヒントをくれたのは、私より2つ上のポールという同僚だ。彼は世界トップクラスのプログラミング力の持ち主だが、一日がほぼ会議で埋まるほど忙しいはずなのに、驚くべき生産性で「電話番」もバンバンこなしていく。
彼を観察して気づいた私との大きな違いは、「WIP＝1」だ。
WIP（Work In Progress）は、今手を付けている仕事のこと。つまり、「WIP＝1」とは「今手を付けている仕事を一つに限定する」ということだ。アジャイルコンサルタントだったときによく学んだ概念だ。ポールはどんなに忙しくても、一度に一つのことしかしないし、他の人以上に一つへの集中力が半端ない。
私の場合、例えばインシデントの解決支援のための会議が毎日ある。その間、自分に関係ない話は聞き流しながら別の作業をやっていたりする。正直なところ、さほど進まないのだが、仕事がたまっているから不安に駆られてつい手を動かしてしまう。
ところが、ポールは会議で自分に関係ない話が続くところでも、一切ほかの作業をやらず、チャット返信すらしている様子がない。彼はその場で問題のあたりをつけたり、あたりがつかない場合も「これはほかの部署に転送しよう」「誰々さんに聞いてみよう。よしメールを書こう」と、とにかく「何かを進めよう」とする。
必ず問題をその場で解決する、もしくはステップを一つ進めているのだ。ここで学んだことは、次のポイントだ。｜・どんなすごい人でも、時間がかかることはかかる。焦らずに時間をかける。
｜・30分から1時間を割り当てたら、そのこと「のみ」に取り組む。すぐに終わらないものは、人に問い合わせるなど、物事を進めておいて、待ち状態にして、次のタスクに進む。
｜・一つのことをやっているときは、他のことは一切せずに集中する。
｜・一つのタスクを中断する場合、次に再開するときに、すぐにその状態に戻れるように記録したり、整理しておいたりする。
｜・タスクの残骸は消しておくーー例えばブラウザのタブは、そのタスクが終わったら閉じて、必要なものは記録する（そうしないと、気移りしてしまう）。つまり、「マルチタスク」はどんな人にとっても生産性が悪いので、「マルチタスク」をしないことが解なのだ。
人間の脳の発達を研究するワシントン大学の分子発生生物学者ジョン・メディナ氏によると、マルチタスクにより、「生産性が40％低下」「仕事を終えるまでにかかる時間が50％増加」「ミスの発生が50％増加」するという。
人間の脳はマルチタスクに向いた仕様になっていないのだ（下の図10を参照）。
PCも一見マルチタスクに見えるが、基本的に、CPUのコアが同時にやっているのは一つの作業なので、一つの作業をして、中断するときは、そのコンテキストを記録して、再開時に復活して作業を再開するのと似ている。確かに起動しているソフト（仕事）は複数ある。でも脳（CPU）のリソースはそのときどきで一つのことに使うほうがよい。
会議の時間なんてたかが知れている。その間に内職したってやれることは限られているし、ほかの人からチャットが来ても、30分、1時間後にまとめて対応する時間をとれば十分早いレスポンスじゃないか？
「マルチタスク」はしないほうが絶対に脳の生産性が高まる。優先順位の高い仕事には、それだけに集中する時間を意識的につくり出す必要がある。
私はある時期、組織改編にともない、技術エリアの引き継ぎが非常に多くて、同僚からの質問対応などによる中断か増え、自分のプライオリティが高いタスクの進捗が悪いと感じていた。そこで、一日の中でどのタスクに90分しか使えていないことがわかった。
この問題をマネージャのプラグナに相談してみたら、技術イケメンたちがやっている方法を教えてくれた。単純な話で、毎日4時間をブロックして、Teamsもメールも一切閉じて、自分の作業だけをする。
思えば、Teamsでチャットすると、すぐに返してくれる人と、1日に1回ぐらいしか返さない人がいる。自分はすぐに返してくれた方がありがたいのでそうしていたけれど、キャリアが長い人になればなるほど、基本的に1日に1回ぐらいしか返答がない。彼らはみんないい成果を出している。自分はレスの速い人に助けられていたので、真似していた。
だが、彼女は教えてくれた。「マジックはない。自分の時間を確保するのは全然OKよ！」（There is magic. It’s ok to book your time.）と。
正直、レスポンシブでなくなることに罪悪感があったが、思い切ってやってみることにした。
すると、驚くほど仕事が進捗する。その4時間に脳がシングルタスクで最大限集中できるから、効率がいいのだ。
キャリアか長くなればなるほど、自分がコンテキストを持っている分野が増えるから、他の人をサポートする仕事も増える。それを他の人にシェアしてあげるのは立派な仕事なのだが、自分のプライオリティの高い仕事が進まないのであれば、意味がない。
だから一日4時間を専有的に確保し、その他の時間に、ほかの対応をする時間割とするのは非常に合理的だ。そこでGitHubの課題やメールをまとめて返す時間にする。ブロックしている時間以外はレスポンシブに返すようにすれば、他のメンバーの業務が滞ることもない。
大前研一氏は、何かを変えたいときは、「住むところ」「付き合う人」「時間配分」のいずれかを変えるべきで、それ以外は意味がないと考察をしていた。私自身は今の住まいが気に入っているし、職場の同僚たちが大好きなので、すると残りは「時間配分」しかない。時間のアサインメントを工夫するしかないのだ。
同僚に技術力ナンバーワンのバーラという秀才がいる。彼はあまりに何でも知っていて優秀だから、周りからは「オラクル」と呼ばれているほどだ。
リモートで働いている期間、彼は1回もビデオをオンにしないので、誰も顔を知らず、Botじゃね？ と冗談が交わされるほどであった。ところが、最近そのバーラが会社に毎日来るようになった。彼は毎日夕方ぐらいに来て、そこからプログラミングをしている。
今までリモートで彼の働き方がわからなかったが、普段から彼は異常にレスポンスが良い。彼に質問したらいつでもすぐに回答をくれるし、大量にメンションされるE-mailにも丁寧に返答している。いつもどうやって開発しているのだろうと思っていたが、私が「なんで夕方に来るの？」と尋ねたらこう返ってきた。
「今ぐらいの時間までたいていミーティングよりも家のほうが効率が良い。だからだよ」
えっ、それって人の2倍働いているってことか！ 昼間は会議とか質問対応で仕事にならないから、夕方から来て誰にも邪魔されない時間に開発していたとは・・・・・・。
彼ほどの秀才もマルチタスクを避けて、プログラミングに集中する時間をアサインメントしているのはちょっとした衝撃だった。『世界一流のエンジニアの思考法』 第3章 より 牛尾剛：著 文藝春秋：刊
意識の向け先が分散されればされるほど、集中力が落ちるため、生産性が下がるということ。
やるべきタスクがたくさんあると、一度に手を付けたくなります。
しかし、1つずつ確実にこなしていく方が、集中力が増して、全体の効率は上がります。
「シングルタスク」を意識したタイムマネジメントを意識したいですね。
「サーバントリーダーシップ」とは何か？
牛尾さんは、ソフトウェアの世界では、2001年にアジャイル開発が登場して以降のパラダイムでは「サーバントリーダーシップ」と呼ばれるタイプのマネジメントが主流になって
いると述べています。
サーバントリーダーシップとは、リーダーは〈ビジョンとKPI〉は示すが、実際にどのように動くかは、チームが主体的に考えて意思決定していく
考え方です。
一方、従来型は「コマンドコントロール」というスタイルで、リーダーが部下に指示を出し、部下の状況を把握、確認し、管理していく
、日本でも一般的な，いわゆる「マイクロマネジメント」
です（下の図14を参照）。
「サーバントリーダーシップ」と「コマンドコントール」。
牛尾さんは、この両者には、コマンドコントロールはメンバーを「社員」として扱い、サーバントリーダーシップはチームメンバーを「ステークスホルダー」として扱う
という大きな違いがあると指摘します（下の図15を参照）。
私は日本にいるとき、アジャイルやDevOpsと呼ばれる開発の進め方を企業に導入するコンサルタントを長年務めていたが、アジャイルは2000年頃から、DevOpsは2009年頃から提唱された方法で、近年日本でも多くの企業が取り組むようになってきた。
その大きな特徴の一つが「自己組織チーム」と呼ばれる方式だ。日本の会社は上司が指示を与え、部下は上司のやりたいことをくみとって仕事をするのが一般的だが、アジャイルスタイルが主流になっている。スクラムマスターと呼ばれる職種が円滑に進行できるようチームをサポートし、プロダクトオーナーという職種がインタラクティブに開発チームとしてどういうものを何のためにつくるかということを考えていく。
自己組織チームの三つの特徴を見ていこう。｜1 生産性が高い。
｜2 チームのエンゲージメント（満足度）が高い。
｜3 よりよいソリューションが選択されやすい。1の生産性の高さに関していうと、「コマンドアンドコントロール」型では、リーダーの承認、説得、あるいは合議や根回しの必要があって、とかく何を決定するにも時間がかかる。これは、減災のソフトウェアのデリバリのスピードを考えると致命的だ。
チームを信頼して、チーム内でビジネスの仮説や仕様、そのアーキテクチャや使用する技術を決定していくほうが圧倒的に速い。タスクの割り振りもチームが自らやっていく。基本的にメンバー各自がやりたい仕事を「自分がやるよ」と選択していく。
2のエンゲージメントの高さに関していうと、インターナショナルチームでは基本的に、メンバーが「楽しんでいるか」が非常に重要視される。メンバーは楽しめる仕事をプロとして実施して、主体的に考えて仕事をする。そのほうが指示を受けて「やらされる」仕事より何倍も楽しいし、自分が面白さを感じてコミットする仕事は、生産性が何倍も高くなるだろう。
最後の、よりよいソリューションが選択されやすいという点だが、これはシンプルな話で、日進月歩の技術の最前線を一番把握しているのは、そのツールや言語で毎日コーディングをしたり運用したりしている最前線のメンバーである。何年も前にプログラマを引退したマネージャでは鼻が利かないのだ。
だから、現場で様々な選択をしてもらうのが一番質がいい。もちろん稀にリーダーでも、最新技術に対して超人的に鼻が利く人もいる。グルーヴノーツの最首（さいしゅ）秀裕社長はその例だ。自分で多岐にわたる技術をハックしたうえで、チームに技術を推薦している。ただしそれも決して押し付ける形をとらない。
基本的には、リーダーがいろいろと言えば言うほどチームは指示待ちになって、自分たちで考えなくなる。いつまでたっても誰かの指示がないと動かない集団になってしまうのだ。
日本では、組織で「我慢できる」のが大人、インターナショナルな職場では、「自分で自分の考えや人生に責任を持つのが大人」であり、雇用制度も全く異なっている。日本国内にいる限りでは仕事のエンゲージメントが低くても、支障はないかもしれない。
しかし、海外に進出したときはどうか？ 近年海外にオフショアしている企業も多いが、現地のエンジニアは、自分が面白くないと当然他のもっと楽しい企業に流れてしまうだろう。
個々のプログラマの生産性には10〜25倍の差があるといわれている。「低いスキルの人」に全体を合わせるマネジメントはもうとっくに終わっていて、全体の生産性を高めていくためにも、メンバーがエンジョイできる環境をつくり出すことが非常に重要になってくる。私が米国マイクロソフトの開発チームメンバーになったときは、これらアジャイルや、DevOpsで学んだようなチーム構成になっていると想像したが、実態はさらに進化していた。いってしまえば、私の職場は、まるで「個人商店の集まり」であった。
マイクロソフトには作業上の統一プロセスはなく、基本的にチームをどう回すかもそのチーム次第だ。どんな大きなプロジェクトであっても、少人数から成るスモールチームの集まりで構成される。日本で大規模プロジェクトというと大勢の人がいるのが普通だが、の世界的な巨大なクラウドを開発・運用するのに各チームは10人程度と本当に少ない。しかも、実際それぞれの機能を開発するのは、「各個人」にまかされている。
図16の「IC」というのはIndividual Contributor（開発者）だが、それぞれ個人商店みたいなものだ。マネジャーからアサインされるバックログ（やるべきリスト）が基本的にふわっとしているので、ICがそれを明確にする。仕様を自分で明確化し、デザインして、実装する。右端の点線で囲んだペアはスケールコントローラーをやっていて、他のメンバーはプラットフォームの中の基盤をやっている、といった具合だ（下の図16を参照）。
チームには同じマイクロサービスをメンテする役割の人がいて、バディのような存在だ。例えば「スケールコントローラー」を開発していたら、そのチームのバディに質問するとすぐに答えてくれる。他のチームではやはりみんなのそれぞれ違う仕事をやっているので、質問を投げてもレスポンスは一日に1回程度だ。
チームの単位はマネジャーが管理できる最大以下の人数で構成されている。ベテランも新人も、責任を持って各自でやる。基盤はかなり巨大なので、内部でいくつか分かれているが、同じマネージャーが見ていて、誰かがつまずいたら助ける仕組みだ。マネージャの存在は、日本とはかなり性質が異なる。日本のマネージャは進捗管理や課題管理をして、プログラマや開発者を指揮するイメージだが、サーバントリーダーシップ制のもとでマネージャが重視するのは、各メンバーのメンタル面だ。
「ツヨシ、仕事をエンジョイしているか？」
マネージャのダミアンが私とOne on One（一対一の面談）をするときに必ず投げかけるのが、この言葉だった。彼は私のマイクロソフトの日本時代の上司で、同僚も上司のダミアンも出身国が分散していて、私だけ日本人だった。私の答えがノーだったら、職場をエンジョイできるようにいろいろと相談にのってサポートしてくれる。いかにメンバーたちが幸せに働けるかに高い関心を寄せ、エンパワーしてくれるのだ（多分チームメンバーから喜ばれているか、というのもマネージャ職の一つの評価基準なのだろう）。
だから我がチームでは、「仕事がつまらない」「納得いかない」と言っているメンバーを見たことがない。マネージャが率先してメンバーそれぞれに「エンジョイしているか？」と確認することで、仕事は“楽しんでなんぼ”の心地よいムードが生まれているように思う。
これは自分の所属チームに限らず、他のインターナショナルチームや、イギリスに行って仕事をしても、楽しそうにしている人が非常に多い。他社の人たちと話してみても、何かに悩むことはあっても「仕事が辛くて・・・・・」と言っている人にはまず会ったことがない。前提として「仕事は楽しむもの」というカルチャーがあるのだ。
日本では、仕事は“我慢してなんぼ”の空気が濃厚にあって、「楽しい！」と言っている人は多くない。私は日本にいる母からも「好きなことを仕事にできるのはそうそうないから、お前は幸せや。でも世間様はそうやないんやで、みんな我慢してるんや」と言われる。
でも、本当は誰だって、エンジョイできる環境のほうがパワーを発揮できるのではないだろうか？ 各メンバーがゴールに向かって個性を発揮して走り、ボスは達成を助けるというマネジメントスタイルでは、他の人に命令して「いうことを聞かせる」必要がないので、とても生産的だ。
ダミアンは、私が今まで出会った中でも最高のマネージャだが、彼は自分の夢をいつもこう語っていた。
「私はいつかこのチームが世界でもっとも素晴らしいワークプレースだと言われるようにしたいんだ」
そんなマネージャのもとで、先日、小さなことだが自分にとってとても感動的な体験があった。
年次レビューがあって、ダミアンは、日本での私の成果をとても喜んでくれている様子だった。彼がとても褒めてくれるので、私が彼に「私の力じゃないよ。ダミアンがすごく助けてくれたからだ」という話をしたら、彼はこう言った。
「誰が、ハッカソンをやったんだ？ de:codeや他のイベントですごいインパクトを出したのは？ みんな君がやったことじゃないか！」
本当は、ダミアンはすごく私の至らないところをカバーしてくれているのだが、そんなことはおくびにも出さず、「みんな君がやったことだ」と言い切ってくれたのだ。そのときはSkypeでのミーティングだったがミーティングだったが、それまでのいろいろな思いが去来して不覚にも泣いてしまった。このプロジェクトで彼は、初対面の私を信じて一切を任せてくれた。過去も素晴らしい人に囲まれてきたが、これほどのことは初めてだった。
あれはダメ、これはダメと子供扱いされる職場と比べると、ものすごい差だ。
こんな温かい気持ちになれる会社と「言われたことをただやればいい」という会社では、採用できる人材に大きく差が出てくるのは当然だ。こうした事実に気づいた人から、グローバルに楽しい職場環境を求めてどんどん日本を去っていくのではないだろうか。サーバントリーダーシップ制の話をすると、決まって、それはすごく優秀な人たちが揃っている環境だからでしょう、経験を積んだ人たちでないと成立しないのでは？ と言われる。かつて私もそう思っていたが、アメリカで実際に働いてみて完全に考え方が変わった。
たとえ新人だったりインターンであっても、マネージャの接し方は同じだ。見ていると彼らもやればできる。まだ本人にセンスや能力がなくても、周囲が助けてくれるからだ。日本では、新人は「できないもの」としてエクセルのスクショとりみたいな簡単な仕事しかふらないが、「できるもの」として大人扱いをすると、周囲の助けを借りつつきちんとやれるのだ。スキルの習得も速く、みな堂々と自信をもった顔をしている。今の自分の実力以上のことは仲間が助けてくれるという安心感があるのだ。
新人も、経験豊かなシニアも同じ同僚扱いされることがもたらす教育的効果は高い。チームにとっても自立した意識をもつメンバーが増えるのはとても喜ばしいことなのだ。では、自主的に動く各メンバーを、具体的にマネージャはどうサポートするのか？
ダミアンはそのお手本のような存在だ。チームとしてのゴールやミッションの共有はしっかりしてくれる。それは明確に数値で示されていて無理がない。
ゴール設定はかなり親身になって一緒にやってくれる。私がそのゴールを達成するために困って相談をするといろいろアドバイスをくれるが、「あれしろ、これしろ」と細かく指示することはない。
毎週30分やってくれるOne on Oneミーティングでは、私に共有したいことやチームとしてやってみたいことの相談があり、私からの悩み事や相談に対してはアドバイスをくれ、いろいろと助けてくれる。「誰かを見習え」といった話は一切されたことがなく、全てのメンバーの個性を発揮する手助けをする姿勢が気持ちよく伝わってくる。
マネージャの主な仕事は「アンブロック」だ。つまり開発者（IC）がどこかで詰まっている状態になると、ブロックされているものを取り除いて（アンブロック）くれる。
例えば、技術的に困ったことがあってチーム外の詳しいメンバーに尋ねてもなかなか返答がないので仕事が進まないといったケースだ。生産性を阻害する状況を打破することをマネージャが手伝ってくれるのだ。人を繋いでくれたり、他の人の協力を要請したり、技術的なサジェスチョンをくれたりして。
常に「仕事の遂行を助けてくれるサポーター」という姿勢なのだ。何かのデッドラインが近づくと、私にリマインドをしてくれたりもする。指示をしたり、いうことを聞かせようとする代わりに、メンバーを理解して助けようとしてくれる。
いうなれば、エンジニアたちの扱いが（ステークスホルダーよりさらに進んだ）個人事業主に近い。自分たちを助けてくれるマネジャーがいて、「今期はこんなことをやろう」とリードしてくれるが、具体的なことは各個人が決める。お題に上がっているネタで自分がやりたければそれをピックアップする。誰かが指導してくれることはないので、自分で考えるが、どうしたらいいかわからないときや、技術的に困ったときは、同僚やマネージャに相談すると、すぐ助けてくれる仕組みだ。
そしてエンジニアたちが中長期的にどうキャリアアップしていけるか、相談に乗って支援もしてくれる。各人の思い描く将来像に合わせて、どうやってスキルを高め、充実したキャリアを積み上げていけるか親身になってサポートしてくれるのだ。『世界一流のエンジニアの思考法』 第5章 より 牛尾剛：著 文藝春秋：刊
そんな“機関車”のような役割というのが一般的でした。
サーバントリーダーシップでは、リーダーは下から支えて、進むべき方向を指し示す。
まさに“レール”そのものの役割を担う存在となります。
メンバー個人個人のやる気や可能性を最大限に引き出す。
これからの時代にマッチした組織マネジメントといえますね。
スポンサーリンク
[ad#kiji-shita-1]
☆ ★ ☆ ★ ☆ ★ ☆
本書の仕事術は、あれもこれもやるという足し算というよりは、むしろ「〇〇をやめる」ーー身を軽くすることに真髄
があります。
牛尾さんは、仕事の枷（かせ）となるものを一つひとつ荷下ろしていったときに、驚くほど脳にスペースが生まれ、心身は楽になって、仕事は飛躍する
とおっしゃっています。
変化が激しく、技術の進歩も目覚ましい現代社会。
荷物が多く、身動きが取りにくい状態では、何かの拍子に行き詰まってしまう恐れもあります。
普段から、身軽に、フットワーク軽く。
どんな変化にも、即座に対応できることが、これからの時代を生き残るカギになります。
どうすれば極限で生産性が上がり、変化に強くなり、フレキシブルに対応できるか。
それを思考法から組織のあり方まで、徹底的に追求しているのが本書です。
皆さんも、本書という“未来の望遠鏡”で、ぜひ、最先端の働き方、10年後の組織を覗いてみてください。
|
|
スポンサーリンク
スポンサーリンク
スポンサーリンク
Comments are currently closed.