「世界一流エンジニアの思考法」を 2,024 年 03 月 16 日に読んだ。
目次
メモ
p5
ソフトウェア開発に限らず、世界から日本を見ると「生産性の悪さ」で“大損”している分野が非常に多い。
それは単にDX(デジタルトランスフォーメーション)化が遅れているといった次元の話ではなく、生産性の要となるマインドセット、チームビルディングにまだまだ大きな改善の余地があるのだ。
p28
どんなに頭がいい人でも理解には時間がかかるものなのだ。
頭のいい人が理解が早いように見えるのは、そうやって時間をかけて基礎を積み重ねているので、既に理解していることに関して頭のメモリにコンテキスト(文脈)が載っているからだ。
私は、理解というものは最初から完璧にはできなくて徐々に身についていくイメージを持っていた。
しかも、私は「とにかく生産性を上げなければ」「どうやったら早くできるだろう」と常に焦燥感にかられ、アウトカム(成果)を出すことに集中してきた。
しかし、皮肉なことに「早くできるように頑張る」ということが最終的な生産性をむしろ下げていたように思う。
p19
Azure Functions はそんな精巧なシステムにもかかわらず、毎日たくさんのエンジニアがものすごい勢いで、機能を追加したり、更新したり、バグの修正をしたりしている。
私が以前勤務していた日本のSIer(システムインテグレーター。システム開発や運用などを請け負う会社)では、今動いているシステムに対して大胆に機能を追加したり変更することは決してしなかったが、ここでは次々と変更していくのだ。
ふと同僚が言ってくれたことを思い出す。
「プロダクトチームに参加したら、1年は役に立たないと思っておくといいよ」
そのくらい中身が複雑で、変化のスピードが速い。
そんな中で私は、周りと比べても実装が遅いほうだし、何をやっても不器用で時間がかかってしまう。
自分の生産性をチームの水準にまで引き上げるのが喫緊の課題だったし、この“自分が何かをできるようになる”感覚に乏しく、自己肯定感も低い、というのは人生で解決したい問題ナンバーワンだった。
p36
「理解は時間がかかるもの」として、急がず、徹底的に理解する習慣をつけていくと、自分の人生でかつて経験したことがないことが起こった。
以前はメモを取りまくっていたコードリーディングもゆっくり理解することで100%挙動が理解できているし、その確信がある。
p54
今やアメリカでは、アジャイルやスクラムの進め方が「常識」としてソフトウェア開発の場で浸透しているが、日本での導入はまだまだ進まない。
日本で私がアジャイルのコンサルタントをやっていた頃、こんな事件があった。
マイクロソフトのソフトウェアプロセスの専門家サム・グッケンハイマーが来日し、私がアテンドする中、大手企業を相手に開発プロセスの説明をしていたときのこと。
「ウォーターフォールとアジャイルのメリット・デメリットは何ですか？」と尋ねたお客さんに、彼はこう言い放った。
「ウォーターフォールは一切メリットがないのでやめておきなさい」
普段私が「顧客が傷つくだろう」と思って言わないでいたことを直言していて大変驚いたが、専門家としての見解は彼と全く同じだった。
ソフトウェアの開発方法として、そもそもウォーターフォール自体が向いていないのだ。
だから、より良いソフトウェアを楽に開発したいなら、不合理な方法は採用せず、アジャイル以降の、チームが楽しく、成果が出る方法の研究をお勧めしたい。
p73
今の時代、検討ばかりして、さっさと「やらない」ことのほうが最大のリスクだということを肝に銘じてほしい。
やらないほうが必ず失敗する確率が増えるのだ。
机上でいくら慎重に検討しても、実際市場に出したらどういう反応が返ってくるか、本当にそのテクノロジーが適切に動作するかは、実施するまではわからない。
だから少なくとも変更がしやすいソフトウェアの世界は、アジャイルのように早く実装して、早くフィードバックを得る方式のほうが合理的だ。
失敗を受け入れる具体的な実践法 p75
失敗はただの結果であり、そこでどんな「フィードバック」を得たかのほうがはるかに重要だ。
ロッシェル・カップさんは、米国ではプロジェクトが中止になったら、成功したときと同じようにパーティをする会社もあると教えてくれた。
なぜなら、その失敗から「学ぶ」ことができたからだ。
この「失敗に学ぶ思考の習慣」は生産性を飛躍的に高めてくれる。
このマインドが身につくと、簡単にライバルに差をつけることができる。
具体的に見ていこう。
p80
これは日本人がもっとも苦手とする分野の一つかもしれない。
我々には「不確実性の忌避」という文化的性質があり、先に予見したり、計画することに丁寧に時間をかけるからだ。
比較的先が見通しやすい産業においては有効な戦略かもしれないが、VUCA(曖昧で不確実性の高い)の時代、とくにソフトウェアのように先の見通しが立てにくい分野ではこの性質が大きなマイナスになってしまう。
一生懸命未来を予見し、緻密な計画を立てることに時間を使ったあげく、商品やサービスが世の中の実態にそぐわなくとも、当初の「計画通り」に遂行しようとして、プロジェクトそのものが炎上してしまう場面はしょっちゅうある。
「計画通り」いかないことは決して「失敗」ではない。
そもそも未来を正確に予見できる人なんてこの世の中に存在しないし、なぜ「計画通り」でなければならないのだろうか？
むしろ、スピーディーに軌道修正をかけていける柔軟性のほうがはるかに大切だ。
その第一歩として、「納期は絶対」の神話は捨てよう。
私が、最初に知って衝撃を受けたのは、「納期(Deadline)」の意味が日米でまるで異なることだった。
日本の場合、納期に、予定された機能がすべて搭載された製品を、予定された品質で納品することが求められる。
しかし米国では、「納期は柔軟」だ。
確かに同僚たちを見ていても日本ほど「納期」に厳しくない。
多くの案件は期日通りリリースしているが、実は中身は予定よりも少ない量に変更されていることはよくある。
納期を守るために、徹夜する人たちも見たことがない。
日本人は納期に厳格すぎて無理をしすぎる傾向にある。
だが、そこにどれほどのバリューがあるだろうか？
Q (品質) C (コスト) D (納期) + S (スコープ) は、トレードオフの関係にある。
納期を短縮したければ、品質を落とすか、お金をたくさん払うか、提供する物量(スコープ)を減らすかのいずれかだ。
エンジニアリング的には予定通りQCDSをすべて達成するというのは非常に困難である。
だから、多くのマネージャは、ゆとりのあるバッファをもって、それを達成しようとするし、私もマネージャ時代は常に30%ぐらいのバッファを残すようにしていた。
それでも、ソフトウェアの場合は変更が多いので、当初の計画通りにはまずいかない。
段階にもよるが、最初の段階で計画したコストの3倍になる確率も十二分にある。
ではどうすればいいのか？
単純化していうと、進捗の「実績」だけで状況判断し、「納期」を固定したまま「スコープ」を出し入れするのが現実的だ。
納期は守り、期日にデリバリしつつも、間に合わないものはそのリリースに入れずに次に回すか、もしくはやめる。
ある機能の搭載が1週間遅れたからといってそれがどの程度インパクトがあるだろうか？
計画は「いまのところは、こういう予定」ぐらいの感覚で見たほうがよい。
p87
もっとも、仕事の案件の中には納期が絶対的なものも存在する。
オリンピック用のアプリの納期に遅れてしまったら、仕事そのものの意味を失ってしまうだろう。
絶対にデッドラインを割りたくない案件だったら、シンプルに「早く始める」しかない。
あるいは、既に動いているものを「リリースする」と約束すればいい。
今では、フィーチャーフラグというテクニックがあり、実際の機能がすでに盛り込まれているが、公開するスイッチをもっており、そのスイッチをオンにしたら特定のユーザーにのみ公開されたり、全体に公開することができる。
先に実装しておき、一部のユーザーに使ってもらって、実際に動くし価値もあると判断してから、スイッチして本当の「公開」をすることもできる。
これは、Azure や、 Windows などでも広く使われている方法だ。
前述のように、納期は固定して、スコープを変動させるやり方もある。
納期に何らかのリリースをするが、実装できたものだけにする。
含まれる機能が増減しても、ユーザーにとって価値のあるものがリリースできるようにしておく。
「楽に達成できる」計画で仕事をする p88
日々の仕事において、他の人にお願いするケースでは(もしくは自分でやるときにも)、その人の能力でいうと、これぐらいの日数でできるという日を納期にするのではなく、プラス何日か余裕のあるスケジュールを設定しよう。
日本では「なるはやで」とか「明日までに」というオーダーで仕事を依頼されることが多いが、海外ではそうした火急の依頼は「マネジメント能力の欠如」と見なされることを覚えておいてほしい。
納期を割る確率が高い賭けをしているようなものだし、依頼先にも相当な負荷をかける。
誰しも日々仕事では割り込みが入らないことのほうが少ない。
だから、自分の仕事も、他の人にお願いするものも、余裕を持った日程で、早めにチェックポイントを設けて、仕事をやってもらうようにしよう。
それがうまくできない場合はどうしたらよいか？
そんなときは思い切って「計画通り」が良いという思考は捨ててしまったほうがいい。
計画は単に「見通しをたてて、仕事を進めやすくするため」のものでしかない。
そもそも納期にどれぐらいバリューがあるかを冷静に考え、自分はどの程度「価値」を定常的に創出できているかを判断基準にするとよい。
そして、「価値」は状況によって頻繁に変わっていく。
なにも「たくさん物量をこなすこと=生産性が高い」わけではない。
生み出すものの「価値」にフォーカスするマインドを身につけよう。
p101
人が「自分にとって難しすぎる」と感じるものには二つのケースがある。
一つは、自分の基礎的な学力が足りていないもの。
これは地道に積み上げるしかない。
例えば私なら証明書の実装を自分で書けと言われたら初歩の勉強から始めないといけないだろう。
でも、こんなケースはまずないし、そもそも手を出さなければ良い。
二つめは、自分が無理なやり方をしているケースだ。
「自分には何かが足りない、才能が足りないから、こんなに大変」と思い込んでいる場合だ。
自分にとって難しすぎると感じるときは、たいてい脳の使い方が間違っているサインだ。
才能の差なのではなく、脳に余裕のない状態で酷使している可能性が高い。
p106
技術は地味な積み重ねにこそ真価が宿る。
「何かを身につける」のは、決して即席ではできない。
時にはじゃぶじゃぶ時間を使うことだって必要だ。
そうやって技術を徹底的に理解し、理解した情報の整理をして、すぐに取り出せるレベル1の状態にしてこそ、長い目で見たさいの生産性は上がる。
だから、アウトカムを急いではいけない。
ポイントとしては、自分が新人だろうがベテランだろうが、うまくいってないものは「わかっていない」。
基礎的なことがうまくできない段階で、下手に試行錯誤して自分流に考えてアレンジすると、かえってめちゃくちゃになって成功しない。
王道を愚直に実行し、ゆっくりと基礎を理解しよう。
p111
この問題をマネージャのプラグナに相談してみたら、技術イケメンたちがやっているある方法を教えてくれた。
単純な話で、毎日4時間をブロックして、Teamsもメールも一切閉じて、自分の作業だけをする。
思えば、Teamsでチャットをすると、すぐに返してくれる人と、一日に1回ぐらいしか返さない人がいる。
自分はすぐ返してくれた方がありがたいのでそうしていたけれど、キャリアが長い人になればなるほど、基本的に一日に1回ぐらいしか返答がない。
彼らはみんないい成果を出している。
自分はレスの速い人に助けられていたので、真似していた。
p112
だから一日4時間を専有的に確保し、その他の時間に、ほかの対応をする時間割とするのは非常に合理的だ。
そこでGitHubの課題やメールをまとめて返す時間にする。
ブロックしている時間以外はレスポンシブに返すようにすれば、他のメンバーの業務が滞ることもない。
大前研一氏は、何かを変えたいときは、「住むところ」「付き合う人」「時間配分」のいずれかを変えるべきで、それ以外は意味がないという考察をしていた。
私自身は今の住まいが気に入っているし、職場の同僚たちが大好きなので、すると残りは「時間配分」しかない。
時間のアサインメントを工夫するしかないのだ。
p118
私のプログラミング師匠かずきさんにプログラミングの上達のコツを聞いたときに言っていたことが、「新しい技術を学んだら、ブログを書く。サンプルコードはそのまま使うのではなく、自分なりに変えたものをつくる」。
つまり、人に説明可能なレベルで記述することが理解を深め、記憶を定着させるのに非常に有効な手段なのだ。
私がよくnoteやブログに雑記を書いているのも、自分の気づきを脳内整理して記憶するためにやっている側面が強い。
p119
さらにこの理論を応用したノートの書き方がある。
「コーネルメソッド」という比較的有名な方法だが、「ノート／キュー／サマリー」の形式で作業を記録し、その日の終わりに整理し、「作業内容を人にそらで説明できるかどうか」を記憶できたかのチェックポイントにしている。
例えばコンピュータの新しい操作方法を覚えたとする。
ただノートに書きとめるだけではなく、アウトプットを意識したコーネルメソッドの方法で書くのがおすすめだ(図11参照)。
p133
同僚とのコミュニケーション一つとっても劇的な違いがあった。
例えばCI(継続的インテグレーション)のパイプラインが突然エラーで落ちて原因がわからないとする。
日本だったら、「こんなエラーメッセージが出て、バージョンがどれで、自分はこれとこれを試して、結果がこうなった。これこれをやると落とし穴にハマるから避けてね。ちなみに、パイプラインのコードはこのPull Requestで追加したものです」とすべての情報を整理して送ってあげると喜ばれた。
しかしアメリカで似たようなことをすると、メッセージを送っても無視されるのだ。
メンターのクリスに相談してみたところこんなことを言われた。
「みんな忙しいだけ。たくさん書いてあると読むの大変じゃない？もっと単純なのでいいよ」
私が絶句して、例えば「これをやったらハマる」落とし穴の情報を伝えなくてもいいのかと聞くと、
「要らないよ。さっきの例だと、このエラーメッセージが出てるけど、なんか知ってる？ぐらいでOK。付加的な情報は聞かれたときでいいよ」
つまり、日本では喜ばれた情報がむしろ余分な情報になっていたわけだ。
思い返せば、インターナショナルチームの人たちの会話は、具体的にはこんな感じだ。
「CIシステムでこんなエラーメッセージが出て困ってるけど、なんか知ってる？」
「ああ、これ前にもあった。この設定、今どうしてる？」
このやり取りでことがすめば、以上。もし終わらなかったら、
「調査が必要だな。このパラメータどうなってる？」
「こうしてるよ。よかったら、Pull RequestのURL送るけど」
「いいね、見てみるわ」
「ちなみに、これやるとバグ踏むから、気をつけてね」
「ありがとう！」といった感じだ。
つまり、最初から全部説明せず、「情報量を減らす」コミュニケーションの仕方がすごく重要だったのだ。
それを知ってからは、会話の中で情報を盛り込み過ぎないよう十分気を使うようになった。
何かの技術を伝えるにあたって、パワーポイントで説明する場合でも、スライドの枚数を極限まで絞って、「これだけはわかって欲しい」と思う一点だけを説明し、質問が来たら追加説明するスタイルに変えた。
これは良し悪しというよりは伝え方の文化なのだが、どちらが脳にとって本質的に楽かを考えると、慣れるとアメリカンスタイルのほうがはるかにストレスフリーだ。
彼らの背景にあるのは、「その場で吸収できることを最大化したい」というスタンスだ。
複雑なものを一気に提供されてもその場で理解しきれないので、単純にリアルタイムに理解できる適切な情報量が好まれる。
インターナショナルチームでは、必要以上に脳に負荷をかけない伝え方がスタンダードになっている。
p160
英語圏で、反対意見を言うときや他と異なる自分の意見を言うときに頻繁に出てくるフレーズが、「In my opinion」。
日本語でいうと、「自分の意見では」とか「自分の意見を述べさせてもらいますね」みたいなニュアンスだ。
このノリで話すと、たとえ相手のアイデアと正反対の意見でも、言われたほうが「心にぐさっとこない」感じになる。
心が痛まないのだ。
p166
ソフトウェアの世界では、2001年にアジャイル開発が登場して以降のパラダイムでは「サーバントリーダーシップ」と呼ばれるタイプのマネジメントが主流になっている。
従来型は「コマンドアンドコントロール」というスタイルで、リーダーが部下に指示を出し、部下の状況を把握、確認し、管理していく。
日本の会社でも一般的な、いわゆる「マイクロマネジメント」だ。
一方、サーバントリーダーシップの場合、リーダーは〈ビジョンとKPI〉は示すが、実にどのように動くかは、チームが主体的に考えて意思決定していく。
この考え方は、古くは1970年に発表されたロバート・K・グリーンリーフ著『The Servant as Leader』のエッセイが元になっている。
もともと私はマイクロソフトに入社する前はアジャイル/DevOpsのコーチをしていたので、サーバントリーダーシップは馴染みの深い概念だったのだが、マイクロソフトに入って驚いたのは、ソフトウェア開発のチームだけでなく、巨大な会社組織全体が「サーバントリーダーシップ」スタイルで動いていたことだ。
ビジョン、戦略、KPIの三つは明確だが、誰も指示をすることはない。
日本企業と比べると、現場のメンバーがかなりの権限を与えられて、どう実行するかを各自で考えている。
他の外資系に勤めている友人に聞いても、このスタイルは増えていて、マネージャが指示するような「コマンドアンドコントロール」型の管理は今ではオールドファッションと呼ばれているそうだ。
私見だが、日本社会もそろそろサーバントリーダーシップ型に移行したほうがよい気がしている。
経営コンサルタントのロッシェル・カップさんの『日本企業の社員は、なぜこんなにもモチベーションが低いのか？』(クロスメディア・パブリッシング)は非常に興味深い本だが、そこでも日本ではマイクロマネジメントが横行し、現場への権限付与のレベルが低いことが指摘されている。
コマンドアンドコントロールはメンバーを「社員」として扱い、サーバントリーダーシップはチームメンバーを「ステークホルダー」として扱うというのが大きな違いだ。
図15を参照してほしいが、アメリカの職場にいると、日本の企業にいたとき、いかに「子供扱い」されていたかを痛感する。
日本の企業では「これをやれ、あれをやるな、○○するときは必ず上司に許可を得てから……」といったスタイルで、主体的に考えて動くことは求められなかった。
大企業に勤めるある人は「事業部長クラスでもたかだか100万円の決裁権もない」と嘆いていた。
こちらでは、各人の裁量権が大きく、規則は最小だ。
会社で自分のPCも使いたい放題だし、本気でやろうと思ったら情報漏洩だってできるだろう。
ただ、我々は大人なのでそんなことはしないし、もししたらものすごい賠償金を払うことがわかっている。
誰もうるさいことは言わず、定期的にBusiness Conductという会社の行動規範教育コースへの参加が義務づけられているぐらいだ(ただし、セキュリティ対策は、「上からのお達し」のようなよくわからないルールではなく、「システム」できっちり守られていて、非常によくできている)。
p172
基本的には、リーダーがいろいろと言えば言うほどチームは指示待ちになって、自分たちで考えなくなる。
いつまでたっても誰かの指示がないと動かない集団になってしまうのだ。
日本では、組織で「我慢できる」のが大人、インターナショナルな職場では、「自分で自分の考えや人生に責任を持つのが大人」であり、雇用制度も全く異なっている。
日本国内にいる限りでは仕事のエンゲージメントが低くても、支障はないかもしれない。
しかし、海外に進出したときはどうか？
近年海外にオフショアしている企業も多いが、現地のエンジニアは、自分が面白くないと当然他のもっと楽しい企業に流れてしまうだろう。
個々のプログラマの生産性には10~25倍の差があるといわれている。
「低いスキルの人」に全体を合わせるマネジメントはもうとっくに終わっていて、全体の生産性を高めていくためにも、メンバーがエンジョイできる環境をつくり出すことが非常に重要になってくる。
p178
サーバントリーダーシップ制の話をすると、決まって、それはすごく優秀な人たちが揃っている環境だからでしょう、経験を積んだ人たちでないと成立しないのでは？と言われる。
かつて私もそう思っていたが、アメリカで実際に働いてみて完全に考え方が変わった。
たとえ新人だったりインターンであっても、マネージャの接し方は同じだ。
見ていると彼らもやればできる。
まだ本人にセンスや能力がなくても、周囲が助けてくれるからだ。
日本では、新人は「できないもの」としてエクセルのスクショとりみたいな簡単な仕事しかふらないが、「できるもの」として大人扱いすると、周囲の助けを借りつつきちんとやれるのだ。
スキルの習得も速く、みな堂々と自信をもった顔をしている。
今の自分の実力以上のことは仲間が助けてくれるという安心感があるからだ。
ボスの役割はサポートすること p179
では、自主的に動く各メンバーを、具体的にマネージャはどうサポートするのか？
ダミアンはそのお手本のような存在だ。
チームとしてのゴールやミッションの共有はしっかりしてくれる。
それは明確に数値で示されていて無理がない。
ゴール設定はかなり親身になって一緒にやってくれる。
私がそのゴールを達成するために困って相談をするといろいろアドバイスをくれるが、「あれしろ、これしろ」と細かく指示することはない。
毎週30分やってくれるOne on Oneミーティングでは、私に共有したいことやチームとしてやってみたいことの相談があり、私からの悩み事や相談に対してはアドバイスをくれ、いろいろと助けてくれる。
「誰かを見習え」といった話は一切されたことがなく、全てのメンバーの個性を発揮する手助けをする姿勢が気持ちよく伝わってくる。
マネージャの主な仕事は「アンブロック」だ。
つまり開発者(IC)がどこかで詰まっている状態になると、ブロックされているものを取り除いて(アンブロック)くれる。
例えば、技術的に困ったことがあってチーム外の詳しいメンバーに尋ねてもなかなか返答がないので仕事が進まないといったケースだ。
生産性を阻害する状況を打破することをマネージャが手伝ってくれるのだ。
人を繋いでくれたり、他の人の協力を要請したり、技術的なサジェスチョンをくれたりして。
常に「仕事の遂行を助けてくれるサポーター」という姿勢なのだ。
何かのデッドラインが近づくと、私にリマインドをしてくれたりもする。
指示をしたり、いうことを聞かせようとする代わりに、メンバーを理解して助けようとしてくれる。
いうなれば、エンジニアたちの扱いが(ステークホルダーよりさらに進んだ)個人事業主に近い。
自分たちを助けてくれるマネージャがいて、「今期はこんなことをやろう」とリードしてくれるが、具体的なことは各個人が決める。
お題に上がっているネタで自分がやりたければそれをピックアップする。
誰かが指導してくれることはないので、自分で考えるが、どうしたらいいかわからないときや、技術的に困ったときは、同僚やマネージャに相談すると、すぐ助けてくれる仕組みだ。
そしてエンジニアたちが中長期的にどうキャリアアップしていけるか、相談に乗って支援もしてくれる。
各人の思い描く将来像に合わせて、どうやってスキルを高め、充実したキャリアを積み上げていけるか親身になってサポートしてくれるのだ。
p182
納期がないなら何があるのだ？と日本の人たちによく驚かれるが、バックログ(今後やるべきことリスト)と、大きな予定だけはある。
戦略(ストラテジー)とカスタマフィードバックに基づいて今期はこれとこれをやろうという計画があって、とても粗い粒度の要素を整理して、開発者たちにアサインする。
p183
考え方として、マネージャは一度仕事をプログラマに割り振ったら(あるいはチーム内でそれは私がやると引き受けた人がいれば)、あとはもう信頼するしかしない。
その選択が最適だったと、その人を信頼し切る。
当人が一生懸命やって時間がかかったなら、それが現時点でできるベストだったのだ。
そもそも知らないコードベースの開発は誰がやったって遅い。
最初のアサインではすごく時間がかかるかもしれないが、そのジョブの次には、そのエリアではもっと仕事が速くできるわけだ。
信頼を出発点にしているからこそのマネジメント法だ。
ただし、あまり成長がなかったり向いてなかったりすると、違う仕事にアサインされたりはする。
だからみな、やりたい仕事は頑張って成果を出そうと思って取り組む。
p184
日本では常々「技術者たるもの、どんな批判も甘んじて受け入れ、まさかりを投げ合って成長するもの」みたいな圧を感じていた。
まるで「願わくば、我に七難八苦を与えたまえ！」と叫んでいる戦国武将のようだった。
そんな辛い思いをしないとプロフェッショナルになれないのかとずっと疑問に思っていたが、アメリカではみんな「ハッピーかどうか？」が重要であって、仕事で「辛さに耐える」という発想が全くない。
前提として、みんな「自分」が一番大切で、自分の幸せを第一に考えている。
自分が「自分以外のもの」になることは期待されない。
そして、自分だけでなく他人も幸せで、「自分らしくいられること」が重視されている。
自他ともにハッピーでいるために生きているのであって、仕事が辛くて心身を病んでしまっては意味がない。
だから、マネージャはチームメンバー全員の幸せを願って接している。
無論、時としてマネージャと意見が対立することはある。
そこで何が違うのかといえば、前章でも触れたように、「決してその人自身を否定しない」ことにある。
例えば、設計や実装方式のディスカッションなどでは、「自分はこう思う」「こういう場面で問題にならないか？」とかなりダイレクトに意見を交わす。
ただ、そうしても、それは「意見が違う」だけの話であって、相手が間違っているというスタンスで話をしていない。
他の人の脳みそを借りて、最適なアイデアを選択しようという姿勢だ。
だから、その人のアイデアが採用されなかったとしても、「ディスカッション」の中でアイデアをブレインストームする過程が喜ばれたりするし、そこに相手を小馬鹿にしたり冷笑するような「人を否定する」ニュアンスは全く入ってこない。
p186
スクラムとは前述の通り、アジャイル開発の手法の一つで、複雑な問題へのソリューションをチームで開発するための方法だ。
私も当初、スクラムを会社全体に入れるという話を聞いたときは、「スクラムは、ソフトウェアの方法なのだから、何にでも適用するのは無理がある」と思っていた。
なぜなら日本では、SIerで開発しているとき、たとえアジャイルを採用している現場ですら「トップダウン」の色合いが強く、「チームで主体的に動く」とか「エンジニアが各自で判断する」という雰囲気にはほど遠かったからだ。
ただ、本気で「自己組織チーム」をつくりたかったら、ソフトウェアチームだけ変えても機能しない。
せっかく開発部隊を自己組織チーム型にしても、その上のマネジメントが「コマンドアンドコントロール」型であれば、やはりチームを管理しようとしてしまうだろう。
あるいは上位マネジメントはそうでもなくても、中間管理職のほうがコマンドアンドコントロールしてしまうかもしれない。
少なくともソフトウェア開発の場合は、全社的に、様々な問題への対処を、小さなチームや個人で自律的に解決していくような自己組織型の体制へとシフトしないと、うまく機能しないのだ。
世界規模のグローバルなシステム開発でも、実際は小さなチームで行う。
多くのテック企業で、開発は25人ぐらいのチームがマックスで、Amazonでも「two pizza team」(2枚のピザを分けられるくらいの人数の意)といわれるように、ソフトウェア開発は少人数でないとまわらない。
マイクロソフトでもたくさんのチームがあるが、チーム自体は10人規模で小さく、それぞれの裁量権が大きく、意思決定のスピードがかなり速い。
世界中で使われている既存のシステムなので慎重なところは慎重だが、それは上の指示というよりエンジニア自身の判断でそういう選択をしている。
p190
メンバーたちに「アドバイス」をするのはよいが、それはあくまで「彼らが求めたとき」だけにする。
その前に「質問しやすくする空気」をつくっておくのは効果的だ。
私は「Ask For Help」の大切さの話を繰り返し伝えている。
するとメンバーたちは「気軽に質問していいんだ！」と思えてくるので、どんどん質問が出てくる。
アーキテクチャの議論をしていても、年上の人に遠慮している人を発見したら、「○○さん、このアーキテクチャの議論で、気になっていることはありますか？小さなことでも結構なのですが、懸念点があれば共有してくれませんか？」といったニュアンスで促すと、少しずつ話をしてくれる。
互いに気軽に質問し、意見をいう環境をつくるのだ。
指示待ち系の人には「じゃあ、○○さん、どのタスクやっときます？」と、こちらが指示するのではなく、あくまで彼らの選択を促すだけにする。
決定するのはあくまで本人だ。
慣れないうちは、自分たちに決定権限があるのに、「会社のルールで決まっているから無理」と自主規制してしまうケースもよくある。
その場合は、上の人を連れてきて、その人から直接「今までとやり方変えちゃっていいよ！」としっかり伝えてもらう。
すると徐々に「会社のルールも変えようと思ったら変えられるんだ、自分で考えて自分で仕事をやればいいんだ」と全員が気づいてくる。
この「プロセスは変えていいんだ」と気づけるバリューストリームマッピングのセッションも有効だろう(85頁参照)。
日々こうしたトレーニングを積むと、1週間もたつと「自己組織チーム」のスタイルにチームが慣れてくるだろう。
あとは、やはりプロで経験のあるアジャイルコーチを雇うのが良い。
この手の「ソフトウェア開発の新しい文化」を学んで社内で実践するのは、本で学ぶだけでは難易度が高いと思う。
チームにアジャイルコーチに来てもらったり、アジャイルスタイルでの開発が得意なパートナーを選定して、一緒に開発をすると、ノウハウを早く吸収しやすくなる。
p193
ダミアンの上司ボルカーも同じで、偉い人と話しているという感じはなく対等にフランクに話せる。
新人だろうがベテランだろうが、社長だって同じ仕事をする仲間。
役割が違うだけで、上の人が下の人をコントロールする、管理するという感覚自体がない。
ボスであっても、私たちに仕事を依頼するときは「お願いモード」だ。
たとえそれが決まっている「月次報告」のようなものであっても、命令口調で偉そうにしている人は見たことがない。
ボスの発言が絶対というイメージもなく、ディスカッションではみんなで遠慮なくフラットに意見を交わす。
上司の意見と違うことを言う場合、「顔をつぶさないように」
細心の注意を要する日本とは全くカルチャーが異なる部分だ。
全ての仕事が「プル(pull)型」――つまり、困ったら主体的に気軽に助けを求めて、他の人がすぐ助ける――それだけなのだ。
p208
ある日ふと、「もう挑戦はやめて日本に帰ろうかなぁ。プログラマが自分に向いてないのはわかってるし……」と思った。
自分は何がしたかったんだろう、自分は本当に幸せなのかな、と壁にぶつかった。
そんな折、メンターのクリスとのメンタリングのセッションがまわってきた。
クリスは友人であると同時に、自分がこんな風になりたいと思う「超一流」の人だったから、私のメンター役を引き受けてもらっていた。
毎日仕事して寝るだけの生活が続いている、でも自分の実力はわかっているから生産性を上げたいという悩みを話した。
すると彼は、「生産性を上げるためには学習だよ。
だから、僕は仕事を定時ぐらいで切り上げる。
その後で、自分のやりたいトピックを勉強したり試したりする。
ずっと仕事していると疲れるし、たとえ同じプログラミングでも、仕事と切り離したものはリラックスしてできるよね」
ああ、そうか……生産性が上がる秘訣は「学習」なのか。
仕事ばかりしていては短期的なアウトプットは上がったように見えても、根本的な生産性が上がらないんだ――。
本当に生産性を上げたければ長時間労働をやめないといけない、というシンプルな事実に気づかされて、衝撃を受けた。
私のチームを観察するとどうか？
技術的にイケてる人たちを見ると、インド人の同僚など、私のように遅くまで頑張る人も多い。
だが、職場で自分が目指しているタイプを観察すると、大抵定時くらいで帰っている。
アメリカ人は極力、時間外労働はしない。
チーム内でもっとも忙しく、技術力に秀でたファビオも「長時間労働はサステナブルじゃないって、よくメンバーにも言ってるんだ」と言う。
友達のデビッドにいたっては、「ずっと仕事をするのは、神の計画ではない」と断言する。
確かに仕事ばかりしているのは動物としてすごく不自然だ。
だから、とても怖かったけれど一念発起して、定時上がりに切り替えることにした。
物理的なエネルギー不足をどう解消するか p227
さてここで、ちょくちょく言及してきた運動について、具体的に触れておきたい。
人生半ばも過ぎて中高年に差し掛かると、どうしても体力と気力が落ちてきがちだ。
私自身は、アメリカに来て車での移動が中心になったことや、コロナ禍でリモートワークが増えたことで、圧倒的に運動量が減り、50代になってテストステロンが減少して、やる気、活気が著しく停滞した時期があった。
その兆候は土日の朝にどうしてもダラダラしてしまうという形で現れた。
ばっと起きて朝からいろいろやりたいのに、一日中ぐったりしてしまい、さっぱり「気力」が湧かないのだ。
こうした加齢からくる身体の不調は、仕事のスキル云々以前のところで、物理的な対策をとるしかない。
同僚たちを見ていると、意外に良い体形をしている人が多い。
アメリカ人っぽいマッチョな人もいるが、運動によって体形をキープしている人が多い印象で、みんな身体のコンディションには気を遣っているようだ。
会社の福利厚生でジムの年会費が無料になるため、私も利用している。
男性の更年期障害的な不調に、一時は本当に悩んだが、運動を高プライオリティにすることと、テストステロンを増やすことの二つが解決策となった。
まず、テストステロン増強のために着手したのは、筋トレだ。
週3回の筋トレは、カーディオのステッパ10分でウォームアップをしたのち、胸、トライセップの日、背中、バイセップの日、足と肩の日とパーツを分けて実施している。
分けている理由は筋肉痛があるときに同じ箇所をやっても無駄だからだ。
筋肉は、筋トレをして筋繊維を破壊し、回復するときに肥大化する。
つまり、休んでいるときに筋肉が育つので、順ぐりに各パーツを休ませるようにしている。
加えて一日10分の高強度インターバルトレーニング、つまりHIIT(High Intensity Interval Training)を実施している。
30~45秒集中してきつい筋トレをやって、10~15秒のインターバルをはさむ。
これを10分間繰り返すだけで、30分ランニングする以上の効果があり、トレーニング後の持続性も高い。
時間があまりとられないのでとても効率が良い。
やり方はYouTubeにいろいろな解説動画が出ているから、好きなメニューをやるとよいだろう。
とくに40歳以降、なにもやらなければ筋肉は年々落ちる一方なので、筋トレは基礎体力の維持に必須だし、基礎代謝を高めてくれるので病気にもなりにくくなる。
ただし、私の場合、筋肉を鍛えるだけでは、気力は復活しなかった。
「元気さ」を取り戻すには、有酸素系運動もする必要があったのだ。
有酸素系は筋肉の増加にはあまりプラスに働かないのでトレーナーでも取り入れない人もいるが、やはり毎日有酸素系の運動は必須だと思う。
私はランニング系があまり得意でないが、次のやり方に絞った。
・毎日30分有酸素系を含む運動をする。
・低負荷でよい(ウォーキングもOK)。
・ランニングしている場合、つらくなったらすぐ歩く。
・毎日30分の運動をすべてのことに対して最優先とする。
毎日必ず30分、朝のランニング+ウォーキングをするようにした。
負荷をかけると、体が「いやだなーやりたくないなー」と訴えるので、そうなる前に、しんどかったら歩いて「心地よい」感覚だけを残すようにした。
朝にしたのは、極力割り込みが入らない時間帯だからだ。
これを1週間以上続けていたら、悩まされていた「気力のなさ」がだんだん解消されてきた。
3ヵ月後の変化は劇的だった。
土日に起き上がれなくてだらだら漫画を読んだりしていたが、どうにも心身が重い……という状態は「体力のなさ」に起因していた。
毎朝30分の有酸素運動だけで、大きくメンタル面が改善されたのだ。
気合でもやる気の問題でもなく、物理的な「エネルギー量」の問題だった。
毎日30分の身体への投資は、必ず行うことをおすすめしたい。
元気があれば何だってできるのだから。
今振り返ると、HIITは筋トレでかつ有酸素運動も兼ねているのでそれでも良い気がするが、リモートワークをしていると体力が極端に落ちやすいので、単純に「運動量」を増やすのも大切な要素のようだ。
なお、個人差はあると思うが、ランニングの習慣によって、頭はクリアに働くが足の疲労はどんどん蓄積していくかもしれない。
筋トレと同じく、毎日同じ箇所を使っていると、疲労が溜まるわりにパフォーマンスが伸びないので、休養も必要だ。
ランニングシューズをしっかりしたものにして足への負担を減らしつつ、週に何回やるかは自分に合ったペースでコントロールするといいだろう。
テストステロンを意識的に増やす p231
食事の面では、肉類や玉ねぎ、加熱されたニンニクなどテストステロンを増やすのに効果のあるものを食べるとよい。
動物性たんぱく質がしっかり含まれた牛肉、豚肉、鶏肉、魚、乳製品、卵、亜鉛が豊富な牡蠣やレバーがおすすめだ。
なかでも鶏レバーや豚レバーはテストステロン産生に密接にかかわるビタミンAがたくさん含まれている。
長時間の仕事中に軽くつまむものとしては、ナッツがよいだろう。
アメリカのエンジニアにナッツ好きは多く、亜鉛やミネラルに加えて、神経伝達物質であるアセチルコリンの原料となるレシチンも豊富に含まれるので、脳の老化防止と集中力アップにもつながる。
サプリメントに関する個人的なおすすめは、もう直球でテストステロンブースターを飲むことだ。
とくに私のように年齢のいっている人は習慣的に摂取するとよい(日本でも同種のものが売っている)。
加齢にともなう様々な不調を一気に改善できる可能性が高い。
一番手っ取り早いのはテストステロンを増やす注射だが、アメリカは医療費が高いので、私はテストステロンのパッチも使っている。
これはものすごく効果てきめんで、私にはテストステロンブースターよりはるかに良かった。
パッチでテストステロンを増強している間に筋トレをすると、恒常的にテストステロンを高められる感覚がする。
運動の得意な人はマウンテンバイクや、長距離のランニングのような負荷の高いメニューと組み合わせてもより効果が持続できるだろう。
テストステロンが高まると、抑うつやイライラや不眠のような更年期特有の症状からも解放されやすい。
もちろん集中力や記憶力の向上にも役立つ。
仕事のパフォーマンスの根底にある身体づくり、脳の休ませ方は生産性と直結するため、ぜひそれぞれの身体に合ったやり方で工夫するとよいだろう。
私は男性なのでテストステロンの話ばかりしてきたが、もし女性も同じように元気がなくなってきたのなら、「筋肉」が増えるような運動と食事を生活に取り入れるのがいいだろう。
同僚たちを見ていても、とくに女性はパーソナルトレーナーの指導を受けることで体調管理や身体づくりがよりうまくいっている。
私自身、筋トレなど自分でやるとどうしても追い込むのが甘くなってしまうが、パーソナルトレーナーに指導してもらうと「俺死ぬんちゃうか？」ぐらいの勢いでぐったりして、筋肉痛三昧になることができる。
これは筋肉が増えるサインなので最高だ。
今はいろいろなタイプのジムがあるので、こうした指導も含めて自分に合ったものを活用するとよいだろう。
p264
だがこれらの理由はすべて、言っている本人以外の外的要因をあげつらうばかりで、自分はどうするのかという話になっていない。
これらの考え方は、「私以外のものに、自分の人生をコントロールされている」という考え方だ。
しかし本当にあなたがそれをやりたいと思ったら、全部がそのままの形でなくとも、できることから自分で変えて、工夫してやればいいのだ。
なぜ、できない言い訳を「他の人」に求めるのだろう？
自分の人生が、自分で決められないと思っている人があまりにも多い。
「会社のルールで決まっているからできない」なら、会社のルールを変えるように動けばいいだけの話だし、どうしても嫌なら、会社を辞めればいい。
今の会社で活路を見いだせないなら、起業したっていいし、海外の会社に行ったっていい。
厳しい言い方をすれば、面倒臭いことをするパワーがないから「自分でやらないことを選択」しているだけなのだ。
海外チームにいて感じる日本の会社との一番大きな違いは、「不幸そうな人がいない」ということだ。
みんな楽しそうに、人生と仕事をエンジョイしている。
どうやったら自分の人生が幸せになるかを主体的に考えて、仕事の仕方を「選択」している。
もし仕事が面白くない、つらいのに「我慢」しているとしたら、そんな我慢はこの本との出会いを機に、綺麗さっぱり捨ててしまえばいい。