Open8

読書メモ : 世界一流エンジニアの思考法

読書メモ
oknokn

手を動かす前に本質的な理解を深めろ

「試行錯誤」は悪である

いきなり手を動かさない。
まずは事実（データ）を一つ見つける。見つけたデータからいくつかの仮説を立てる。
そして、最後にその仮説を証明するための行動を取る

  • 一連の手順が手当たり次第に可能性を試すことによる時間のロスを排除し、圧倒的な効率を生む
  • 単に思いつきでいろんなパターンを試行錯誤して正解を探しているだけでは、時間がかかるだけでなく新しい知識を何も学んでいない。
    • 事実 -> 仮説 -> 検証の思考プロセスを取り組むことで、効率性だけでなく事象の本質的な理解も深まる

「理解に時間をかける」を実践する

どんなに頭がいい人でも理解には時間がかかるもの

  • 頭のいい人が理解が早いように見えるのは、時間をかけて基礎を積み重ねているので、すでに理解していることに関して頭のメモリにコンテキストが載っているからだ

  • 理解が十分で無いまま手を動かして努力しても空回りになるだけで身に付かず、あやふやの試行錯誤は取り組んだことも忘れやすい

    • 「何かを早くできるように急ぐ努力」は皮肉にも本質的な理解を遠ざける、そのため「理解は時間がかかるもの」として、急がず、徹底的に理解する習慣を構築すべき

理解の三要素

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

-> この基準で考えると、今までの自分は速度ばかりを気にして本質的には理解できていなかったんだなって

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

  • 「理解するとはどういう事か」がはっきり見えてくると、次はいかに「感覚」による決めつけを避けるかという課題に直面する

  • 自分でログなどデータを検証して問題解決する様にしないと、「思い込み」の穴に落ちてしまう

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

  • 手を動かす前に理解を深めるもう一つの強力な方法
     
    「ドキュメントはコードを書く前に書くんだ。だって、コード書いた後にドキュメントだけ書くなんて退屈だろ？」

-> これは自分も実践していたので嬉しかった。

  • 思考を整理してやることを洗い出すだけでなく、それがTODOリストにもなる。
  • これを突き詰めてドキュメントをテストコードにするのがTDDなのだろうな。

ここでおける「デザインドキュメント」は簡潔かつ必要十分なものがあれば、それで良い

oknokn

メンタルモデルの構築

メンタルモデルとは、人々が世界を理解し、予測し、解釈し、新しい状況に適用するための、自己の心中のイメージや理論

  • 頭の中で素早く情報処理をするために、何らかの脳内イメージを持っていることが非常に有効
    • フレームワークによって自分の思考の偏りをなくしたり、幅を広げるきっかけになるらしい
      • -> 一つ決めて取り入れてみる -> 意識せずとも使えるようにを繰り返して手札を増やしていきたいな

システム思考

筆者が使っていたフレームワークというかメンタルモデルの構築法

  • ソフトウェアのアーキテクチャ、クラス構造、ソフトウェアのどう言ったパーツかどこにあるかなど、システム全体を頭の中で整理し組み立てることで、「どういう状況でどの様に動作するのか」と言ったシュミレーションができるよう脳内でイメージを構築するらしい
     
    メンタルモデルに関しては固定的な型があるというより、人それぞれなので自分の特性や仕事に合った物を見つけるのが良い。そのためにもフレームワークで先人の知恵を借りるのは大切
oknokn

質問のタイミング

日本では調べてから人に聞くべきと言った文化があるが、必ずしもそれが正解ではない。

  • システム特有のものや、プロダクト特有のものだと特にそう。
    　- この様な場合まずエキスパートにに頼るのベストプラクティス
    • 仕事のパフォーマンスを上げるには、いかに「無駄なこと」をしないからしいので
       

一般的な技術的な問題に関してはしっかり時間をかけて本質的な理解を高めるべきなんだろうな

  • AIに聞いて答えを出させたとしても出力された内容全てに関して本質的に理解してからレビューに持っていく様に今はしている。時間とのトレードオフだけど結果的に生産性が上がることを信じて
oknokn

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

  • 「Be Lazy」
    より少ない時間、労力で価値を最大化するべき
     
    これを達成するための習慣
  • 望んでいる結果を達成するために、最低限の努力をする。
  • 不必要なものや不可価値の無い仕事（過剰準備含む）をなくす。
  • 簡潔さを目指す。
  • 優先順位をつける。
  • 時間や費やした努力より、アウトプットと生産性に重点を置く。

2-8の法則

20%の仕事が80%の価値を生むのだから20%をしっかりやればよくて、100%を全部やろうとすると工数もかさむし、時間も足りない。

  • バックログもそうなんだろうな、真に取り組むべき20%のタスクに専念して少ない労力で価値を最大化させるべき

いかにやることを減らすか？

  • 一つだけをピックアップする
    • 優先順位を簡単につけるためのプラクティス
    • 全体を整理して優先順位をつけるのも大事だが、そこが難しくて時間をかけてしまうくらいなら一番大切なものに全てを専念することを繰り返せばいい
  • 時間を固定してできることを最大化する
    • あれもこれも「すべき」というマインドだと、どうしても時間をダラダラと延長してしまいがちだが、「すべき」から時間を計算するのでがなく時間は固定して、その中で価値を最大化するという行動を取ってる
oknokn

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

生産性を加速する上での重要なマインド、リスクを受け入れるとは欧米のビジネスシーンにおいて下記のことを意味する

  • 間違いを厳しく批判したり懲罰したりしない
  • 失敗から学ぶ態度
  • Fail Fast(早く失敗する)
  • 実験が推奨されている
  • 全員に「現状維持や「標準」を要求せず、臨機応変が推奨される
  • 非難や恐怖感のない環境
     
    失敗はただの結果であり、どこからどんな「フィードバック」を得たかの方が遥かに重要
    今の時代、検討ばかりしていてさっさと**「やらない」ことの方が最大のリスク**である。
    • これ、仕事だけでなく人生において全てそうだよなって

失敗を受け入れる具体的な実践法

1. 「フィードバック」を歓迎するムードを作る

  • チームメイトが何か成功したら当然喜ぼう、失敗してフィードバックをくれたら失敗する方法がわかったので感謝しよう。
  • 失敗に対して怒ったり、批判するのはチームメイト「子供扱い」しているのと同じ。
     
    ここにおいて些細なことでも感謝や賛辞のアクションを自分から取ることが大切なんだなって
    • 自分が変わらないと相手は変わらないので

2. 「検討」をやめて「検証」する

机上や脳内の「検証」に時間をかけずにさっさと「検証」の段階に進み、フィードバックの恩恵を得るべき
 
もしあなたがマネジメントなら下記を心がけないとモダンな開発スタイルのマネジメントは不可能である

  • マネジメントは詳細まで細かく練られた計画を期待しない
  • 予算と報告のプロセスは精密な結果の予測を要求しない
  • 内部プロセスは計画や優先順位の変更に柔軟である
  • 事前に全ての問題分析が完了せずとも新しいことに挑戦する姿勢を持つ
  • システムとプロセスは柔軟で複数の頻繁な変更を受け入れられる
  • 学びに基づいて、変化を精力的に行う
     
    これらはプレイヤーの心構えとしても大切

「無理・断る」練習をする

鏡の法則
~心理学~

  • 自分に適用しているルールを無意識に他人に適用してしまう
    • 日本人には「納期厳守」というルールが染み付いている
       
      寛容になりたかったら自分自身んへのルールも緩やかにした方がいいのだ。
      「無理を承知で」のお願いの連鎖はみんなの疲弊を生み、チームや組織の業務改善に全くつながらない
  • 手一杯の状況は把握した上で、どうしたら楽に達成できる計画に落とし込むことができるか
  • または、「ここまでだったら協力できるよ」と言ったラインについてチームで話すのがいい
     
    無理をして品質がトレードオフになったら本末転倒ということ実体験で学んだので強く同意
  • そもそも現実を見て、フィードバックを受けて納期や仕事が変わっていくのはむしろ善なのだ

「結果を出す」から「バリューを出す」へ

「たくさん物量をこなす」ことが生産性が高いわけではない。

  • 生み出した物の価値に視点を置く
    • リファクタリングでもこれ結構あるな。すぐ治せるけど、見た目の問題で別に価値がない場合は次にそこを触れる際に直せばいいんだよな
       
  • 定時でできる量になるようにシンプルに「作業量」を今の実力できる範囲内に調整する
    • 予定されたアウトプットよりも少なくなっても気にしないらしい
  • 目標はあくまで目標
    • 進捗よりも「やってみてどうだったか？」、「ベストプラクティスは？」 より価値がある事柄に

こういうマインドセットをチームでシェアしておくことで、負荷軽減の具体的な施策に繋がりやすい

oknokn

いかに脳みその負担を減らすか

  • 「コードリーディングのコツは極力読まないこと。他の開発者のことを信頼して実装はちゃんと動くものとする」
    • 理解するために端から端まで実装を読むと脳みそのCPUをフルに使ってしまうので、インターフェースと構造を理解する様にする。

-> これホンマか？

  • せめてAIにレビューさせて明らかなミスはキャッチする様にするとかできればまだ使えるのかな

  • 自分だけのレビューで通ってしまう時には流石にちゃんとまだ見たい気がする自分は

  • 「自分にとって難しすぎる」と感じる物には二つのケースがある。

    • 一つは自分の基礎的な学力が足りてないもの。これは焦らず地道に頑張るしかない。そもそも手を出さなくていい領域かもしれんね
    • 自分が無理なやり方をしているケース
    • 才能の有無などではなく、自分にとって難しすぎると感じる時は、大抵脳の使い方が間違っているサイン