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

第1章 世界一流のエンジニアは何が違うのだろう？　生産性の高さの秘密

生産性の高さの違い

• 自分は特別賢い人間ではないが、社内評価のとても高いエンジニアと比べて明らかに脳みその能力が劣っていると感じてはいなかった

トップエンジニアの衝撃的な解決法

• 自分のプログラムが動かないことがあり、自力では何時間？何日？解決にどれくらいかかるかの判断ができない問題が発生した
  • 社内評価のとても高いエンジニアならどのように解決するか気になりペアプロを依頼した
    • ログを見た後の最初の行動に違いがあった
      • 自分
        • ここが原因かも、あそこの不具合かもと手を動かしながら色々触ってみる
      • 社内評価のとても高いエンジニア
        • ログを見て、手を動かさずに仮説を立てる
        • 仮説に沿ったクエリを書く
• プログラミングの仕事の本質は頭脳労働なのでいきなり手を動かしてはならない

試行錯誤は「悪」である

• ある問題が起きた
  • 1日かけて思いつくままに手を動かして試行錯誤をした
    • 思いつきで試しているだけで、新しい知識を何も学べていない
      • 再現性のない手法で解決しているから同じ状況で同じようなことが起こった場合に対応できない
• 闇雲に手を動かながら試行錯誤してはならない
  • 起こった事象からしっかり仮説を立てて対応する

頭が良くても「理解」には時間がかかる

• 理解が早く見える人は基礎学習に時間をかけてしっかり理解している
  • 一度ならず繰り返すことで理解を深めていくアプローチをとっている
• 早くできるように頑張ることで理解が浅くなり生産性が下がる
  • 毎回調べることになる
  • 根本を把握していないからトラブルに弱い
• ここはこういう雰囲気だと読み飛ばすところを、あえて時間をかけて理解に努めるのが重要
  • コードの意図と背後のアーキテクチャをしっかり理解するために時間を使うことを恐れない

著者が考える理解の３要素

• その構造を掴んで人に説明できること
• いつでも即座に使えること
• 知見を踏まえて応用が効くこと

複雑な技術をコントロールできている感覚を得る

• 自分はわかった気になっていて簡単だと感じている基礎は、理解の３要素を満たせているかどうかと向き合う
  • できていない箇所があれば、基礎の勉強を今一度やり直して、理解の３要素を満たすようにする
• できない自分とできる他者を比べたときの違い
  • 時間はかかるが誰でもやったらできる基礎ができていない
• 英文でもじっくり理解しながら読み進める、英文を読むのは時間がかかるがここで粘れるかが重要
  • こうした方が結果的に時間はかかっていない
• ゆっくり理解することで理解を深めることができる
  • 理解が深いことで一直線に問題解決ができるようになる

「感覚」で判断せずファクトを積み重ねる

• 理解を深める重要性がわかるほどに、感覚で判断するのは良くないことがわかる
  • 全体を俯瞰して問題を感覚で捉えていると思い込みが働き、本来よかったやり方も良くないとしてしまうこともある

小さなドキュメントをコードの前に書く

• ドキュメントはコードを書く前に書く
  • コードを書いた後に書くのは退屈である
• 誰かのために書くのでなく自分のために書く
  • 書くことの２つの利点
    • 自分の頭が整理される
    • 抜け漏れに気づける

頭の中に「メンタルモデル」をつくる

• エキスパートに質問するのを恐れないこと
  • どんなタイミングで返答が来るかは人によってさまざまである
  • 人に安易に聞くことに日本人は抵抗感を覚えることが多くありがち
    • チームの生産性の面では聞かないというのは良くない
• メンタルモデルとは
  • 人々が世界を理解し予測し解釈し新しい状況に適応するための自己の心の中のイメージや理論のこと
  • 例としてMVPがある
    • フィードバックをもらって改善するのを前提に実用最小限に最初から作り込まないやり方
      • こういったフレームワークを他でも活用して思考の偏りをなくし幅を広げるきっかけになる
  • 著者はシステム思考を独自にアレンジしている
    • ソフトウェアのアーキテクチャ・クラスの構造・どういったパーツがどこにあるか
      • システムの全体像をイメージしてから部分の状況、相互作用を考慮に入れていく
    • 新しい機能追加・修正時に、理解するのに時間がかかるところを、脳内ですぐにイメージできるようになる
    • メンタルモデルは作るのが大変で作ってしまえばその後の仕事を効率化できる
  • なぜなぜ分析
    • 問題を発見したらなぜを5回繰り返して根本原因を炙り出す手法
      • これもメンタルモデルである
  • ホワイトカラーの仕事の９割は考えることなのでメンタルモデルがあると作業効率を上げる効果は高い

まずエキスパートを頼る

• わからないことはエキスパートに聞くのが一番合理的である
  • 未経験の箇所のコード変更をすることになった時
    • いつもなら自分なりにコードを読みドキュメントを探していた
      • 今回はエキスパートに速攻で「この部分をこう変えたいんだけど参考になるPRとかない？」と尋ねた
        • 回答を待っている間、全く別のタスクを進めておく
          • いつもなら自分で答えに辿り着けるかもしれないと調査をしたりしていた
            • 結果的にパーフェクトな回答が来て、自分で進めていたら長い時間のかかったタスクを２・３時間で終わらせることができた
              • エキスパートの助言からきちんと理解できたのでメンタルモデルも作れた
• 仕事のパフォーマンスを上げるには無駄なことをしないこと
• エキスパートから情報がシェアされれば、重要なところにフォーカスでき、理解が深まる

「偉大な習慣を身につけたプログラマ」になる

• 特殊なことはなく、じっくり時間をかければ深く理解ができる
• できる感覚がなかなか得られなかったが、根本原因は頭の良し悪しではなく思考の習慣にあった
• 早く成果を欲して目先の結果を求めて頑張ることで、かえってできなくなっていた
• どんな人も最初は難しく理解には時間がかかる
• 頭が悪いからと理解を諦めていたことも、時間をかければ理解できるという自信もつく

COLUMN アジャイルとは何か？

• 開発手法のことで、素早い・機敏なという英単語で、以下の特徴がある
  • 計画に従うより変化に対応する
  • プロセスとツールより個人とのコミュニケーション
  • 包括的なドキュメントよりも動作するソフトウェアを重視する
• 機能ごとに分割し、優先順位の高いものから、短いスパンで以下５つをくり返す
  • 要件定義
  • 設計
  • 実装
  • テスト
  • リリース
• ウォーターフォールとの違い
  • ウォータフォールは
    • 要件定義
    • 設計
    • 製造
    • テスト
      • 滝が上流から下流に流れるように実行するもの
        • 長い時間をかけ何百人も人を集めて、巨大なドキュメントを定義する
          • 手戻りが発生したときのロスが大きいため、ソフトウェア開発には不向きである
  • アジャイルは変化すること前提で短い開発期間で自動化されたテストを繰り返し顧客を巻き込んでチームで一体となり製品を生み出すため仕様変更に強い
• アジャイルの有名な手法でスクラムがある
  • ラグビーのスクラムに因んだ5~10名からなる体制でチーム全員がオーナーシップを持って進めるためチーム内のコミュニケーションが重要になる

一章を読んだ所感

• 自分はこの書籍でいうところのアンチパターンをしていたと気づいて、これから以下の点を改善することにします。全て当てはまっていたので、この書籍を読んでよかったと思いました。
  • まず手を動かして試行錯誤をすることはせず、どのように進めるかをしっかり考え・チームと認識合わせをした上で、タスクに取り掛かること
    • コードを書く前のドキュメントを書いてレビューをもらうこと
  • 自分なりに考えるのはエキスパートの意見を聞いてからにすること
  • 感覚で進めることが多かったが、理解に時間をかけることを恐れないこと
  • 改めて基礎の勉強をすること
  • 開発を進めるフレームワークについて学んで実践した上で、自分のアレンジも加えたメンタルモデルを作ること

実は読んだ日から実践していて効果を感じているので継続していこうと思いました！！まだやり始められていない項目もやっていきます！！