全体的な感想

主に文化面でどんなことを大事にしてるか、いろいろな考え方が書いてあって参考になった。

ミッションステートメントを明確にしてチームの文化を作り、またメンバの入れ替わりもある中で、どうやって維持していくのか。

時には「有害なもの」の排除は必要だけど、「人」ではなくあくまで「振る舞い」を排除しようとすることが大事なんだなってのが印象深かった。『コードを憎んで、人を憎まず』に似てる気がする。

その裏には、本の中で繰り返し出てくる「HRT : 謙虚、尊敬、信頼」の考え方があって、一番強調されていた部分。

日本語版まえがき

本書とは直接関係ないけど、本書の中で強調されていたひとつの「ミッションステートメント」について、Chromeの例が紹介されていた印象的だった。

私の関わっているChromeというブラウザにおいても、ミッションステートメントとして、Speed, Security, Stability, Simplicityが定められている。

大事にしていることがすごい明確で、しかもその中にSimplicityが入ってるのがすごい好感が持てる。「美はシンプルさに宿る」という、別の本に書かれていた言葉を思い出した。

これ(ミッションステートメント)に合致しない機能は完成が近いものであっても、すべて製品から取り除いた。足すものよりも引くものの方が多かったほどである。

めっちゃいい。特に長年続いてるサービスだと、いろんなものが捨てられなくて複雑さが増していろんな弊害が出てくる。選択と集中のためにもミッションステートメントって大事なんだなって感じた。

検証を重視した「早い段階で、高速に、なんども失敗せよ」の精神を忘れないようにしよう。

結構最終的な答えって分からないし、最初に考えてたものと違う場合がほとんど。だから、早めに切り上げて前に進んで、間違いに気づいたら柔軟にすぐ修正できる方がいいな。

ソフトウェア開発はチームスポーツである。

チームで開発するってのは当たり前のことと思ってたけど、「チームスポーツ」って例えは意外と新鮮だった。

チーム開発の3本柱→謙虚、尊敬、信頼

HRT。これがこの本の一番伝えたいこと。リーダーはもちろん、全員が大事にしなきゃいけないこと。

エンジニアはコミニュケーションを出来るだけ排除して、コードを書かなければいけないと考えている。しかし、チームが合意していなかったり、情報が伝わっていなかったりすると、君が正しいコードを書いているという保証はない。

いくつか具体的な事例が身近でもあるなぁと思う。出来上がるまで共有しないで、最後に全然前提が違うじゃん！みたいなのってママある。一言聞けば解決することはごまんとある。サクッと聞くのもいいし、ペアワークとかで潰すのも効果的そう。

すると彼女は、子供たちは植物のようだと答えた。‥6人の子供たちに同じ水、日光、肥料を与えていたら、平等かもしれないが、誰一人として、本当に必要なものが手に入らない可能性が高い。エンジニアも植物みたいなものだ。日光を必要とする人もいれば、水を必要とする人もいる。

リーダーは、メンバがそれぞれ何を必要としているかを見極めて、それぞれに合わせた接し方をしなければいけないということ。そのために日々の1on1がある。面白い比喩だな。

エンジニアのスキルは、ナイフの刃のようなものだ。刃を研がずに何年もナイフを「使っていれば」、いずれ切れないナイフになってしまう。新しいことを学んだり、技を身につけたりする機会を作ることが、エンジニアを鋭くて、効率的で、効果的にさせるのだ。

シニアっぽい立場でチームにいると、割と心地よくて、気をつけてないと切れないナイフになってしまいそう。自戒の意味も込めて。

普通の人たちを排除するようなエリート指向のフラタニティではなく、ネガティブな振る舞いを拒否するような文化を作る方が健全だ。排除するのはあくまでも振る舞いであり、特定の個人ではない。

えてして、「人」に着目しがちだけど、「振る舞い」自体を排除しようとして、それでもダメなら最後の手段として、「人」の排除を検討する。チームを守るためにはそれも大事。

この章はだいぶ、斜め読みしちゃったな。

優れた設計は簡単なものを簡単に、難しいものをできるだけ簡単にする。複雑なことであっても、簡単なことをしているように感じられるようにするべきだ。

簡単なものを難しく書いちゃうって意外とある。複雑なコード読んで、結局やりたいことって、〇〇と△△だけじゃん！みたいな。で、後半の複雑なことを簡単なことしているように見せることができるようになりたい。カプセル化と抽象化をうまく使うのかな。