エンジニア組織の課題を解決するために読んでおきたい必読書3選


実はエンジニア組織は非常に特殊な存在です。
それは現代においては特殊だという意味合いです。
何故かというと、人類が今まで経験したことがない組織であるためです。
それでは今まではどのような働き方や組織があったのか。
そして現代のエンジニア組織とはどういったものなのかを探りながら、エンジニア組織の課題を解決するために学ぶための必読書をご紹介します。

現代のエンジニアとは

今まで技術職と言えば、個人の裁量によって作り上げてきました。
それは職人と呼ばれる職業です。
封建制度の時にはそれぞれの職種においてギルドを構成し、縦割りで生産を行ってきました。

しかし、エンジニア組織ではそうはいきません。
その理由は3つあります。

1. 常に変化し続けるビジネス要件
2. 開発したり、ユーザーが増えるだけ溜まってくる技術的負債
3. 営業やデザイナーといった様々な人たちとコミュニケーションをしながら開発を行う

これはインターネットがもたらした破壊的イノベーションの産物の一つです。
組み込み式などでは一つの方向性が決まれば、それに向かって開発すれば大丈夫でしたが、インターネットサービスにおいてのエンジニアでは上記のような理由からそれが難しくなっています。
だからこそ、現代のエンジニアに適した働き方やキャリアの描き方、チーム作り、マネジメントが必要になっているのです。
まだまだ新興な職種ですし、チームが変わることも多々あるのでこれといった決まった答えはありません。
その状況に即した方法を見つけていくしかありません。
方法を見つけるにはいろんな側面からいろんな事例を知った上で、じゃあどうするのかを考えるのが定石の学び方です。
なので、エンジニア組織の課題を解決するにあたって考えるにあたって必読書として3冊の本をご紹介させていただきます。

Team Geek

エンジニアチームを作るにあたっての必読書です。
フォーカスしているのは「チーム作り」です。
なので、チーム作りに悩んでいる人や、今のチームに対して不満がある方におすすめの1冊です。

この本で大切にしている概念としてはHRTがあがります。
HRTとは以下を指し示しています。

謙虚(Humility)
尊敬(Respect)
信頼(Trust)

素晴らしいチームというのは、チームに属するメンバーがそれぞれ謙虚さを持ち、それぞれに対して尊敬と信頼を持っている状態だとしています。
昨今、よく耳にする心理的安全性がそれにあたるのかもしれません。
具体的な行動などは書籍を読んでいただきたいのですが、例えば一つあげると非難の違いなどが書かれています。
非難はダメなものではないという前提があり、かつ2種類あると書かれています。
それは建設的な非難と攻撃的な非難です。
前者は健全性があり、主にソースコードレビューなどレビューする時などに非難的な視点から物事を捉えることです。
後者は言葉遣いだけなのかもしれませんが、理由もあまり明示せずにただひたすら非難をすることをさします。
これらの一つ一つが大切であり、実践ができた先に心理的安全性が担保されたチームが作られます。

エンジニアリング組織論への招待

昨年にかなり大きな話題になったので読まれた方も多いかもしれません。
この本では包括的にエンジニアリング組織とはなんたるかを解説してくれています。
なので深い話などは別途、それぞれの書籍などで勉強する方がよいと思います。
コーチングに関してはこちらでまとめているので、ぜひ参考にしてみてください。

この本の主題は「エンジニアリングとは不確実性をなくしていく作業」であるということです。
エンジニアリングとは、課題がに対して解決する要求があり、それを具体的な仕様にまとめてソースコードに起こしていく作業です。
なので、コミュニケーション能力がかなり求められる職種だったりするわけです。
その不確実性を減らしていくためにはどういった努力が必要なのかをいろんな角度から書かれています。
ぜひ一度読んでみてください。

エンジニアのためのマネジメントキャリアパス

タイトル通り、エンジニアとしてのキャリアパスに関して記載されている書籍です。
特に管理職としてマネジメントとしていく人にとっては、とても学ぶべきことがたくさんあるかと思います。
同時にマネジメントされる側としても、どういった管理職の人が上司としていたらいいのかの参考になりますし、もし技術畑にいくかマネジメントラインにいくか悩まれているのでしたら、参考として読んでみてはいかがでしょうか?

特に面白かったのが「テックリード」とは何かという定義でした。
筆者は今まで「コミュニケーション能力(特に調整力)がなくても、技術力がもっとも高くて、アーキテクチャの選定や方針を決めれる人」だと思っていました。
しかし、この本で書かれていたのは「コミュニケーション能力が長けており、ある程度技術力をもっている人」だとされていました。
あくまで仕事としてのアウトプットはプロダクトの新しい機能開発だったり技術的負債を取り除くことだったりします。
それをプロジェクトとして推進できなければテックリードにふさわしくないと。
技術力だけに突出した人は相談役として配置しておくのが最適だと書かれていました。
たしかにその通りかもしれません。
アウトプットとして世の中に価値を生み出すためにはいろんなエンジニアやカウンターパートの人たちとコミュニケーションが取れ、合意形成ができなければいけません。
いろいろと学ぶことが多い1冊でした。

最後に

もちろん、これらの本を読んでも答えが決してあるわけではありません。
それぞれ参考となる思考や実例があげられているにすぎません。
それぞれの環境は必ず少なからず異なるので、どうすれば「理想の状態」に持っていけるのかを思考錯誤しながら、そして働いている人たちとコミュニケーションをとりながら行っていくのが一番の近道です。
どれを選んでも難しいこともありますでしょうし、悩むことや苦しいこともあると思いますが、それさえも楽しめるチームになったら最高ですよね。
そんな働き方をしていくために、まずは世の中の成功事例と失敗事例を知ることをおすすめします。