『世界一流エンジニアの思考法』を読んで、一流のエンジニアに対するイメージが少し変わった。
読む前は、技術力が高くて、難しいものを作れて、頭の回転も速い。そんな人たちをイメージしていた。もちろん実際に技術力も高いのだと思う。
でも本を読んで強く感じたのは、技術でものを作ること以上に、行動で質の良いものを作っていく人たちなんだな、ということだった。
一流のエンジニアは、技術力だけで良いものを作るのではなく、行動し、フィードバックを受けながら価値を高めていく。この姿勢が、自分にはかなり印象的だった。
自分は「完成してから見せる」に縛られていた
自分はこれまで、たくさん作業して、考え込んで、結果が出るまでひたすらやる、ということが多かった。それがたとえ苦しくても、とにかく完成まで持っていく。
振り返ると、たぶん自己評価をかなり気にしていたのだと思う。評価してもらえるように、ちゃんとしたものを出したい。指摘されたくない。「ここまで考えたのに、そんなことにも気づかなかったのか」と思われたくない。
そうすると自然と、完成度を上げてから出そうとする。結果として溜め込む。時間をかける。フィードバックが遅くなる。そして、手戻りも大きくなる。
長く自分を縛ってきたルールだけど、今考えると、いいことはほとんどなかった。
早く見せたほうが、結果的に早く進む
最近、ある開発の設計で、ある程度案を考えた段階でチームメンバーに投げたことがあった。すると、自分では考えていなかった視点から穴を指摘してもらえた。
そのおかげで、実装に入る前に修正できた。もし一人でそのまま進めていたら、あとから大きな手戻りになっていたと思う。
逆の経験もある。
ある程度実装してからチームに共有したものについて、「こっちのサービスを使ったほうが楽だよ」と言われて、そちらに乗り換えたことがあった。これは完全に手戻りだった。
相談自体はしていた。でも細かく伝えられていなかった。だから、作る段階でもっと見せるべきだった。
この経験から、「相談したかどうか」だけでは足りないんだと思うようになった。どの段階で、どの粒度で見せるか。 そこがかなり大事なのだと思う。
未完成で出すことは、自分のハードルも下げてくれる
早めに出すことには、もう一つ大きな意味がある。それは、自分の心理的なハードルを下げられることだ。
完成品として出して指摘を受けると、自分は「うまくやれなかった」と落ち込んでしまいやすい。ある種、理想が高いのだと思う。
でも早めに出せば、「まだ早い段階なので、考えきれていない部分もあります」という体で出せる。これはかなり大きい。
未完成であることを前提にしているので、穴があっても不思議ではない。その状態で他者の視点をもらう。そうすると、自分のハードルを下げつつ、チームとしてはより良い方向に進める。
自分も楽になるし、チームも早く正解に近づける。こうすれば、自他ともにハッピーじゃん、と思った。
一流のエンジニアたちに感じた「軽やかさ」
本を読んでいて、著者が見てきたエンジニアたちは、とにかく軽やかだと感じた。
自分の中では、たくさん作業して、長く考えて、結果が出るまでひたすらやる。それが苦しくても続ける。そんなやり方がどこか普通になっていた。
でも本に出てくる人たちは違う。楽しんでやることを大事にしている。コミュニケーションはクイック。結果だけにこだわるのではなく、価値を出すための動きを優先する。だから成果物を溜め込まずに見せる。フィードバックをもらう。それを善とする。
ひたすら残業することもなく、集中して成果を出しているように見える。一つ一つの行動のハードルを小さくしているから、その流れが生まれているのだと思う。
同時に、「価値を出すためにまず動く」という大きな指針があるからこそ、行動を起こしやすいのかもしれない。ものを作る仕事において、この軽やかさが非常に羨ましく感じた。
「仕事をした」の基準も変わってきた
最近、自分の中で「今日は仕事をした」と思える基準も少し変わってきた。
以前なら、どれだけ作れたか、どれだけコードを書けたか、どれだけ完成度を上げられたか、というところを見ていた気がする。
でも今は、他者と話して、自分にない視点のアイディアを組み込めたか。成果物を更新できたか。行動を起こして、周りや全体の進捗を変えられたか。そういうことをもって「仕事できた」と感じるようになってきた。
実際、Slackのメッセージが多かった日は、充実感がある。単にメッセージ数が多いからではない。
めちゃくちゃスレッドで議論して、方針が決まった時。自分一人では出てこなかったアイディアが交差して、進む方向が変わった時。そういう日は「仕事したな」と思う。
生成AIがある今、コードを書くだけが人の仕事ではない
この感覚は、生成AIが出てきたこととも関係している気がする。
今は、コード自体はかなりAIが書いてくれる。もちろん人間が理解する必要はあるし、責任も人間側にある。
でも「コードが書けた」という成果物自体は、以前ほど「自分が作ったもの」という感覚が薄くなってきた。
だからこそ、自分は全体の舵取りに寄与できた時のほうが充実感があるのだと思う。
人と人の間にある情報をつなぐ。議論を前に進める。自分にない視点を取り込む。より良い方針を決める。生成AIがある今、こういうことの価値はむしろ上がっている気がする。
「完成してから見せる」を手放したい
この本を読んで、自分が一番手放したいと思ったルールは、「完成してから見せる」だった。
本当に新規のものなら、案は3割でもいいと思う。場合によっては、目次レベルから出してもいい。
大枠を見せる。一部を見せる。さらに細かいところを見せる。大枠から細かいところまで、レイヤーごとに見せながら進める。
もちろん細かいところも、なんとなくイメージはしておく。でも全部を完成させてから出す必要はない。
これからは、チャットややり取りの回数を増やしたいと思っている。
今までなら、依頼を受ける。作る。返す。で終わっていたものを、目次で見せる。一部を見せる。もう少し進んだところでまた見せる、という形にする。
新人でもないのに、いちいちフィードバックをもらうのか、という感覚もある。でも毎回レビュー依頼をする必要はないと思う。
チャットスレッドに途中経過を出すだけでもいい。誰かが反応をくれる。大抵は。
これは判断を他人に委ねたいわけではない。流れを開いておきたい。 そのほうが、結果として良いものになると思う。
仕事以外でも、だらだらやらずに集中する
本を読んでいて、「集中して成果を出す」という部分は仕事以外にも使えそうだと思った。
友達がジムに行く時、「30分だけ集中してやる」を実践していた。子供もいるのに、ちゃんと続けていて、実際かなりいい体になっていた。すごいなと思った。
彼らに共通しているのは、だらだらやらないことだと思う。自分は多趣味なので、この考え方を取り入れるとかなりハッピーな気がする。
ただ、時間を固定化しすぎることには少し気をつけたい。楽しくて夢中になっているなら、ずっとやることがあってもいい。
仕事の場合は、自分というリソースをきちんと使う必要がある。楽しくても、休憩を入れたり、どこかで止めたりする必要がある。
でも個人でやることや、他人に迷惑をかけない範囲なら、夢中になる時間まで無理に固定化しなくていい。
大事なのは、「30分で切ること」そのものではない。自分のリソースをどう使うかを意識することなのだと思う。
良いものは、行動の中で育てていく
『世界一流エンジニアの思考法』を読んで、一流のエンジニアに対するイメージが変わった。
技術力でものすごいものを作る人、というよりも、行動して、周りとコミュニケーションを取り、フィードバックを受け、その中で質を高めていく人。そんなイメージに変わった。
良いものは、一人で完成させるものではないのかもしれない。
途中で見せる。他者の視点を取り込む。方向を修正する。また動く。そうやって、行動の中で育てていく。
だからこれからは、「完成してから見せる」を手放したい。
もっと途中で出す。もっと人と話す。もっと軽やかに動く。
そのほうが、自分もチームもハッピーだし、結果として良いものが作れる気がしている。