《The Effective Engineer》著者エドモンド・ラウによる解説、インパクトを最大化する！！シリコンバレーのエンジニアが実践していること

夕方の食事時間、VSCode上の抽象化されたコード、ターミナルの厄介なエラーメッセージを眺めていると、Slackから緊急のバグチケット通知が飛び込んでくる。画面右上の時計は、いつの間にかまた1時間経過していた。退勤時間はとっくに過ぎているのに、今日の進捗はようやく始まったばかり。思わずため息が出る。仕事は山登りと同じで、帰り道の方が登り道より大変だ。

こんな時期を経験したことはないだろうか。仕事中は常にやることが尽きず、今日の進捗は次々と後ろにずれていき、毎週金曜日はほぼ夜中の12時まで残業している。心の中で自分を疑い始める。技術力が足りないのか、効率が悪いのか、それとも本当に仕事が多すぎるのか。

最近、複数の技術ブログが《The Effective Engineer》という本を推薦しているのを見かけた。非常に役に立つと言われているので、思い切ってじっくり読んでみることにした。将来、自分もeffective engineerになれることを願って。

まず著者のTalks at Googleでの講演を見た。この講演は《The Effective Engineer》の主要な内容をカバーしている。本記事では講演内容の重要なポイントをまとめる。本を読み終わったら、別の記事で詳しく発表する予定だ。

著者のエドモンド・ラウは、Google などの有名なシリコンバレーの大企業やQuoraなどのスタートアップで働いてきた。彼は連続2年間、毎週80時間以上働き、その後さらに2年間、フルタイムでeffective engineerになるための方法を研究した。

シリコンバレーの科学技術大手企業およびスタートアップ（Facebook、Instagram、Dropbox、Etsyなど）の20社以上のCTOと技術の第一人者にインタビューし、以下の3つの質問をした：

• What separates the most effective engineers you have worked with from everyone else?（効率的なエンジニアを普通のエンジニアと区別する要因は何か？）
• What is the most valuable lesson you have learned in the past year?（過去1年間で学んだ最も貴重な教訓は何か？）
• What investment you have made for your team has paid off the highest returns?（チームへの投資の中で、最も高いリターンをもたらしたものは何か？）

すべてのソフトウェアエンジニアが学べる効率的な仕事のやり方をまとめた。著者はこれを「leverage framework」と呼んでいる。

この本には1行のコードも出てこない。本で述べられているのは、ソフトウェアエンジニアとして、high-leverage activitiesを実行することで自分のインパクトを最大化し、自分の価値と影響力をレバレッジする方法である。

著者は私たちに厳しい現実を理解させる：

effort === impact // False

努力は影響力と貢献に等しくない

スタッフエンジニアの生産性は、ジュニアエンジニアの10倍かもしれないが、前者の労働時間が10倍になることはあり得ない。

著者はここで本書の核心概念「leverage」を提示する。これは増幅器であり、あなたの努力を巨大な産出と影響力に変換でき、同時に日常の開発業務を突破するための支点である。以下はleverageの計算式である：

leverage = impactProduced / timeInvested

エンジニアの日常開発も80/20の法則に従う。20%のタスクが80%の価値と影響を生み出し、80%のタスクはわずか20%の成果しかもたらさない。

著者は、最小限の時間で最大の価値と影響を生み出すことができるものを識別し、優先的に実行することを勧める。これらの影響が重大な事柄をhigh-leverage activitiesと呼ぶ。

講演では、著者は以下の5つのhigh-leverage activityを挙げた。それぞれを見ていこう！

学習を最適化する

最初のhigh-leverage activityは、自分の学習能力を最大化することである。なぜなら、学習は複利効果を持つからだ！だから早く進歩を始めるほど、進歩の幅が大きく、学習能力が高いほど、進歩が速い。

Learning compounds!

学習が複利効果を持つため、能力の成長曲線は指数関数的に増加する。最初はゆっくり上昇し、ほぼ平らだが、ある臨界点を過ぎると、ほぼ垂直に上昇する。

これは実際の事実とも一致している。難しい問題に取り組むときは、異なる側面の知識を蓄積する必要があり、知識が線でつながると、問題を解く解法が見えてくる。

著者は古典的な例を挙げた。毎日1%進歩すれば、1年後には37倍進歩する！

努力して学ぶことは誰もが知っているが、難しいのは、日常の開発業務やバグの爆撃に埋もれてしまうことだ。毎日やることが終わらないのに、どうやって学習の時間を作るのか？

本の中で、著者はGoogleの例を挙げた。従業員の生産性と創造性を向上させるため、Googleは20% Timeを導入した。毎週1日を本職以外のことに充てて、新しい技術を研究したり、興味のあるプロジェクトをしたりする。例えば、Gmailは20% Timeから生まれた。

しかし、一般的な企業の従業員は毎週1日を空けることはできない。そこで著者は、毎日1時間の勤務時間を確保して、自分たちの20% Timeを実行することを提案している。

学習に関する最後の点として、著者は、自分が興味を持つことや、仕事で直面している問題から研究を始めることを勧めている。なぜなら、動機は常に行動を続けるための最も重要な要素だからだ。

イテレーション速度への投資

2番目のhigh-leverage activityは、繰り返し作業の処理速度を加速させることである。これは、コードの一部を関数として書くべきかどうかを判断する方法と同じだ。何かを2回目に繰り返すときは、3回目の作業が自動化できるように工夫すべきだ。

著者が各CTOに、効率的なエンジニアを普通のエンジニアと区別する要因は何かと聞いたとき、彼らは答えた：「自動化ツールを書くために時間を投資するエンジニアは、往々にして最も効率が高い」と。

ここで言うツールは、シェルスクリプトのような小さなものから、CI/CDの自動化インフラ全体まで、すべてを含む。

著者は例を挙げた。彼がQuoraで働いていたとき、平均して毎日40～50回のデプロイを行っていた。CI/CDの自動化プロセスがなければ、どれほど膨大な時間がかかるか想像できるだろう。

多くのシリコンバレーの大企業は、内部開発ツールを構築するための専門チームを持っている。例えば、Facebookはreact.jsを開発した。著者は言う：「私たちは皆、新しいトレンディなフレームワークの作者になりたいと思っているが、実は日常の開発から始めることができるんだ！」

積極的かつ反復的にアイデアを検証する

3番目のhigh-leverage activityは、実装段階に入る前に、機能の実現可能性を検証し、不要な時間と人力の浪費を避けることである。

例えば、Etsyは製品検索結果ページを無限スクロール可能に変更した。上線前に、A/Bテストを実施したところ、クリック率と変換率がそれぞれ10%と25%低下したことが判明した。その結果、この機能は最終的に上線できず、数ヶ月の時間と人力が無駄になった。

この経験を踏まえて、Etsyは製品コンテンツページを修正するときに、段階的なアプローチを採用した。やりたいことを検証可能な前提仮説に分解し、製品に役立つことを確認してから、本当に開発を始める。

著者は、プロジェクトでは、不確実で危険なことほど、最初に実行すべきだと言う。その後、無駄な作業を避けるために。

運用負担を最小化する

4番目のhigh-leverage activityは、日常的なメンテナンスコストを削減することである。著者は講演で複雑性 complexityの議論に重点を置いている。

InstagramがFacebookに買収されたとき、4000万人のユーザーにサービスを提供していたが、従業員はわずか13人で、そのうちエンジニアは5人だけだった。どの角度から見ても、彼らは間違いなく超効率的なチームだ。

著者は彼らのCTOにインタビューし、これを実現した要因は何かと聞いた。CTOの答えは：「私たちは問題を解決するための最もシンプルな方法だけを採用する。エンジニアたちは互いに詰問し、その後のメンテナンスコストを増やさないことを確認してから、開発を進める」だった。

著者は、複雑性の影響は小さいものから大きいものまで存在する可能性があると言う。

code complexity -> system complexity -> product complexity -> organization complexity。

複雑なコードはエンジニアの理解とコミュニケーションコストを増加させ、システムの複雑性はメンテナンスコストを増加させ、製品機能の複雑性が高いほど、将来の機能開発の難度が増し、組織の複雑性さえも開発チームの効率に影響を与える。

著者はかつてハワイで休暇を取っていたが、ちょうど彼だけが理解しているシステムに問題が発生し、火山の上にはバグを処理するためのネットワークがなかったため、彼は直接single point of failureになってしまった⋯⋯

そこで著者はメンタリングを重視し始め、詳細なオンボーディング文書とプロセスを作成した。元々は入社3ヶ月のエンジニアがコードベースを理解していたが、今は入社したばかりのエンジニアが第1週目からプロダクションに貢献できるようになった。これは本当に巨大な効率改善だ！

優れたエンジニアリング文化を構築する

5番目のhigh-leverage activityは、優れた開発チーム文化を構築することである。エンジニアたちは良い環境で働きたいと思っている。leverage activitiesに焦点を当てることは、正のループになり、効率の向上がますます順調に進む。

最後にいくつかのQ&A：

Q: テストを書くことは必要だが、時間がかかる。より効率的なテスト方法はないか？

A: 重要な部分がすべてテストでカバーされていることを確認し、頻繁な変更の下でエラーが発生しないことを目標にできる。

システム全体が100%のテストカバレッジを持つ必要はない。あまり使われない場所にテストを書くことは、時には無駄かもしれない。

Q: あなたが挙げた例はすべてスタートアップまたは小規模な企業だ。複雑性を低減することについて、大企業にも適用できる方法はあるか？

A: スタートアップの利点は、みんなが直接コミュニケーションを取りやすいことだが、大企業にも利点がある。例えば、歴史的データにアクセスしやすい。

Googleの例を挙げると、それは非常にデータ駆動型の企業なので、データに語らせ、意思決定者に影響を与えて leverage activitiesを実行させることができる。