【復習】世界一流エンジニアの思考法①
何度か読み直す前提で、その都度、気づいたことを書き留めるためのnoteです
頭のいい人が理解が早そうに見えるのは、そうやって時間をかけて基礎を積み重ねているので、既に理解していることに関して頭のメモリにコンテキスト（文脈）が載っているからだ。
中略
理解が十分でないまま手を動かして努力しても、空回りになるだけで身につかず、あやふやの試行錯誤は取り組んだことも忘れやすく頭に残らない。
「何かを早くできるように急ぐ努力」がかえって本質的な理解を遠ざけてしまうのだ。
何度も読み返したくなる。
基礎を積み重ねることで到達可能であること、自分がやるべきことはアウトカムを急ぐのではなく、日々のL2→L1の取り組みであることを再認識させられる。
今までの癖、アウトカムを急いできた癖を治すためにも、認知療法的に定期的に読み直していきたい。
自分がコードを書いて、既存のデザインを変更し、各種テストもしっかり通して、新たに動くと確信を持てるコードを書いたのであれば、大抵「理解しているだろう」と思い込んでいる。だが、試しに書いたコードについて口頭で説明しようとしても、曖昧模糊として、全然伝えられない。
「そうか、自分がやったからといって、理解できてるとは限らないんだ」という事実に行き着いた。
ペアプロ、ペアで設計作業をすることの最大の利点はここにありそう。
ペアで作業をしている以上、お互い、常に説明可能な状態を維持してタスクを進めていく必要がある。つまり、作業者の理解度の水準について”説明可能なレベル以上”という制約が課されるため、アウトカムの質が良くなる。
ペアプロでよく聞くのが「最初は遅い」という言葉。近視眼的に作業が遅いように感じるかもしれない。しかい、本書で触れられているように、エンジニアという職業においてはコンサルのように日々のアウトカムにとらわれてはいけない。アウトカムを生み出すサイクル、その期間が異なる。
コンサルのような職業と比較すると、もっと長いサイクルで見なければならない。そのサイクルを見定めて、生産性を最大化できるような仕事の進め方を考えて構築する必要がある。
『人に説明可能なレベルで記述することが理解を深め、記憶を定着させるのに非常な有効な手段なのだ』
参画しているチームで「エンジニアから非エンジニアへの説明が分かりにくい」というフィードバックをいただくことがあった。
その一方で、私自身を含めてドメインに対する知識だったり、既存のコードへの理解に難しさを感じている、不十分と感じるところがあるという問題もある。
解決策としてドメイン理解の部分だったり、既存コードの設計だったりを読み解いて、チーム全体に対して説明をするというのを考えてみた。
題材の候補として、、、
・ドメイン知識
・既存コードの設計と実装
・既存コードを修正したときの設計と実装
・試験シナリオの観点と実装
・リリース時に通らなかった試験、通らなかった理由、その修正の設計と実装
直近ではテストの観点不足や、実装に問題が見つかっていて、エンジニアだけではなくPJ全体でその問題に対する優先度が上がっているので、テストについての題材を取り扱うのが良いかもしれない。
個人的に技術共有を普及させる取り組みを行っているので、その枠で自分で実施してみて、運用するときのコツとか具体的な提案にまとめてもっていけたらと思う。