概要

エンジニアとして、プロジェクトの中でどのようにチームを形作るべきなのか。
メンバー間でトラブル無く、共通の認識を持って、良いプロダクトを作るにはどうすればいいのか。
実際に働く中で疑問に思い、書籍を読んでみたので、自分の経験も含め、まとめ記事を書いてみた。
こちらの書籍を参考

目次

はじめに
1. 個人として
2. リーダーとして
3. 組織に対して
4. ユーザーに対して
最後に

はじめに

1人のメンバーとして、プロジェクトを渡り歩く中で様々なリーダーの元で働いてきた。

その過程で、それぞれの方が全く異なる価値観・働き方を持っていることに気づき、
リーダーとしての働き方って何が正解なのだろうか？
と思うようになった。

また、ぼく自身チームとして働く上で相乗効果のようなものをすごく大切にしているが、
ときとしてメンバ間で認識の齟齬があったり、ドキュメントの作成・管理方針について、
考え方が異なることがあった。

エンジニアとして、どのようにチームを形作っていくことが良いとされているのか。
体系的にまとめられている本はないかと探し、本書に辿り着いた。

本書は6章による構成となっているが、
大きく4つの観点が込められていると考えた。
内容をピックアップして、以降で論じていく。

1. 個人として

=== 謙虚・尊敬・信頼の三本柱 ===

筆者は、

人間関係を円滑にするだけでなく、健全な対話とコラボレーションの基盤となるもの

として以下の三本柱が必要であると定義している。（以降、頭文字をまとめて"HRT"と呼んでいる）

謙虚（Humility）
尊敬（Respect）
信頼（Trust）

また、

あらゆる人間関係の衝突は、謙虚・尊敬・信頼の欠如によるものだ。

とまで言い切っている。

先輩に対して、尊敬を欠いていたり、
後輩に対して、謙虚さや信頼を欠いていたり、
といった例は散見されるし、自分自身もできていない面が多いにあるかもしれない。

誰に対しても、HRTを意識して接することがとても大切であると思う。

=== 1人でやることのリスク ===

なんでも1人で物事を遂行することのデメリットとして、
筆者から挙げられている内容をまとめた。

失敗のリスクが高くなる
車輪の再発明の可能性に気づけない
フィードバックループが回らない
知識やノウハウが一発で失われる可能性がある

これはプライドが高い人（ぼく自身意識しないとなりがち）ほど陥りやすいのではないか。
確かに最高だと思っているアイデアを誰かに共有して、
批判されたり馬鹿にされたりするのは怖い。

だがしかし、
誰かに話してみて誤りに気づくことがあるし、
素晴らしいと思っていたアイデアが実は陳腐なものであると気づけたこともある。

完璧主義を捨てて、
アイデアや成果物は積極的に共有していこう！

2. リーダーとして

=== 素晴らしいチーム文化を作る ===

チームの文化とは、...それはエンジニアリングチームが共有する経験・価値・目標のことである

なぜ、チーム文化が必要なのか？

それは、チーム文化を大切にできなければ、
チームのアイデンティティや仕事の誇りを作り出せないだけでなく、
新来者がクソみたいな文化に簡単に変えてしまう
からである。

また、文化とは固定のものではなく、変化・発展し続けるものであり、
チームリーダーではなく、チームメンバーが定義・維持・防御に
責任をもつものである。

では、文化を作る上でのリーダーの役割とは？

それは「合意ベースのチーム」を作ることである。
「合意」というのは、チーム全員がプロダクトの成功に強い責任を持ち、
リーダーがチームの意見に耳を傾けることである。

優秀なエンジニアはプロダクト開発に参加するだけでなく、
プロダクトの意思決定プロセスにも参加したいと考えている。

チームの文化がリーダーではなくメンバーによって、
定義・維持・防御されるものであるならば、
優秀なエンジニアは必要不可欠な存在である。

リーダーは、HRTの「尊敬」を重視して、チームの意見に耳を傾けることが求められる。
そうすることで、優秀なエンジニアをチームに招きやすくなり、
それがより良いチーム文化を醸成していくのである。

=== サーバントリーダー ===

サーバントリーダーはチームにアドバイスを与えるだけでなく、
必要であればチームが順調に進めるように穴を埋める。
自らの手を汚すのがサーバントリーダーだ。

上記は、筆者が述べているサーバントリーダーの定義であり、
チームの中でリーダーが担うべき役割であると述べている。

また、個人として意識すべきである謙虚・尊敬・信頼（HRT）の雰囲気をチーム内で作ることもリーダーの役割として必要とされている。
（HRTは、全ての章において重きを置かれている）

プレイヤーとして優秀な実績を納めてきたリーダーほど、
あらゆることに手を出してしまいがちな傾向がありそうな気がする。

メンバーを信頼して、謙虚な姿勢で、
チームの潤滑油のようになることが
リーダーに求められている。

=== アンチパターンを避ける ===

筆者は、リーダーの対応としていくつかのアンチパターンと
それを防ぐための方策を提示してくれている。
（成功者の真似をするより、失敗者が辿った道を避ける方が大切だとよく聞く）

提示されているものを、いくつかピックアップして紹介する。

アンチパターン：パフォーマンスの低い人を無視する
...
パフォーマンスの低い人には早めに対応しよう。そうすれば、成長させるかまたは退席させるかを判断できる。早めに対応できれば、その人には指示や支援が必要なことがわかるかもしれない。

パフォーマンスが低いと考えられる人に対して、
放置や無視をするのではなく、
早めに真摯に向き合うことで双方にとって有益な選択肢が得られるのではないかということである。

もちろんパフォーマンスの低い人に対してもHRT（特に尊敬）を持って接することは大切であるし、
数か月の期間を設けて明確な期待を伝えたうえで見守ってみることが大事である。

アンチパターン：チームを子どもとして扱う
...
人は自分が扱われるように行動する。
...
信頼できる人を採用し、信頼していることを伝えれば、相手は普段見せないような力を発揮してくれる。

これは耳が痛い...
新人の方が入ってきたときにできていなかったことの1つである。

相手が知らないことが多く、こちらから教えることが多い場合、
マイクロマネジメントしがちになっていた。

しかし、そのように相手を扱うことで相手は更にこちらへの依存度を高める
という負のループに陥っていたのかもしれない。

"信頼できる人を採用し"というのは立場上、難しいかもしれないが、
信頼していることを伝えてあげて見守ることはみんなできる。
そうすることで、驚くような成長をしてくれる可能性は大いにありそうだ。
（ただし、レビューはしっかりしよう...）

=== リーダーシップパターン ===

筆者は、リーダーのアンチパターンの次に、
成功するリーダーの振る舞いを集めたリーダーシップパターンも提示してくれている。
特に共感できたものをいくつかピックアップして取り上げる。

エンジニアが相談を持ちかけるのは、君に問題解決をしてほしいからではない。
彼が問題解決するのを手伝ってほしいからだ。

これを言われてドキッとする方はかなり多いのではないだろうか。
いわゆるティーチングとコーチングの違いであり、真に求められているのはコーチングの方であるということだ。
ティーチング：指示・命令型のマネジメント
コーチング：相手の自主性を尊重しつつ、成長を促すマネジメント

フィードバックや批判を伝えるときは、メッセージが正しく伝わっているかどうかが重要だ

これは、後輩や部下に対して、難しいフィードバックや批判を伝えるときは正直に正しく伝えるべきだということである。

「率直に伝えることは、後輩や部下を傷つけることになるのでは？」

そう思う人も多いだろうが、
それでも筆者としては、オブラートに伝えようとして、
メッセージを正しく相手に伝達できないリスクを危惧しているようだ。

伝える際にはHRTを十分に意識し、
相手自身ではなく相手の振る舞いに問題があることを強調し、
どうすれば理解してもらえるか伝え方を工夫すべきである。

=== 有害な振る舞いへの対処法 ===

なぜ有害な振る舞いがあるといけないのか？

それはチームの数少ないリソースである注意と集中が持ってかれてしまう危険性があるからだ。
有害な振る舞いにより、チームは口論を始め、注意散漫となり、興奮して疲れ果ててしまう。
ソフトウェア以外のことに注意と集中を浪費してしまうことになる。

有害な振る舞いとは？

筆者は、有害な振る舞いとは以下であると述べている。

他人の時間を尊重しない（時間泥棒）
エゴを主張し、チームが前へ進めない
執拗に要求し、最終的に不平・不満を言う
未熟なコミュニケーションと複雑なコミュニケーション
パラノイア（被害妄想）
完璧主義を発揮し、チームが前へ進めない

有害な振る舞いへの対応方法は？

これはまとめると以下の2つになると思う。

感情的にならず、「振る舞い」「事実」にだけ目を向けてコミュニケーションをとる
人よりも文化を重視して、長期目線で判断する

特に2つ目の対応方法について、優秀なエンジニアはコモディティ化しているため、
チームの文化と天秤にかけたときには、文化を優先すべきということである。

3. 組織に対して

=== チームがうまく機能している会社 ===

マネージャー

理想的なマネージャーとは、

HRTのあるサーバントリーダーであり、君の成功を支援してくれる

と筆者は述べている。

このようなマネージャーの下であればメンバーは、

生産的になり、メンバーとしての価値を上げ、責任範囲を広げることができる
リスクを取り、早めに失敗して素早く学習できる

などのメリットがある。

また、メンバーもリーダーに対して積極的に質問をして、マネージャーが知らない情報や経験を提供したり、仕事の進捗や障害、マネージャーへ期待していることなど積極的に報告することが良いとされている。

一方、悪いマネージャーの要素とは、

失敗に対する不安から保守的
チームの外部とのやり取りのハブになろうとする
情報を溜めこんで、部下の手柄を自分のものにする

などが述べられている。
いずれも避けたいものである。

組織内の雰囲気

ここでは主にエンジニアの働きを阻害するような組織内部の特徴が述べられている。
まとめると以下である。

影響力の高い人に擦り寄る政治家のような人がいる
技術に疎い経営者が非現実的な要求を作り出してしまう
封建制度のような指揮系統型の構造をしている

確かに官僚制が導入されていて、肩書や組織階層のことで頭がいっぱいな人が多く、果てしない権力闘争が巻き起こっているような会社は、容易にイメージできる。

だが、そのような会社の多くでは、エンジニアが働く環境は軽視されており、道具のような扱い方をされ、すぐ終えられるような意思決定に途方もない時間がかかる効率がすこぶる悪い。

=== 居心地がいい場所を作り出す ===

もし自分達の働いている環境が上記であげたような好ましくない環境であったとしても、お手上げではないと筆者は述べている。

むしろ、組織はそういうものであると認めたうえで、その中でも効果的に仕事を進めるための戦略はいくつもあるはずだとし、その方策をいくつか挙げている。

組織で許されていることを把握する
アイデア（特にリスクのある）について、信頼できる仲間にセカンドオピニオンを求める
草の根レベルで多くの人にアイデアを受け入れてもらう
攻撃的な仕事（後述）で成果をあげ、信頼残高を貯める

これらはMECEではなく、各々がつながっているのではないかと思う。
1→2→3→4の順で行っていくことで、官僚的な組織の中でも意見を浸透させられる可能性が大幅にUPするのではないだろうか。

また、ぼく的には、上記で示された1~4はいずれも少々難易度が高めだなと思った。
しかし、官僚的な組織にいたとしても文句ばかり垂れるのではなく、例えば4を意識することで自分自身のスキルアップにもつながるし、社内での自由度も増え、一石二鳥なのではないだろうか。

筆者はプランBとして、「逃げる」という選択肢も提示している。
自分には合わないと判断したらすぐに逃げるのではなく、まずは組織内で試せる様々な戦略を試し、それでもダメだと思った場合は素直に撤退するという選択も賢いのではないだろうか。

=== 攻撃的な仕事・防御的な仕事 ===

攻撃的な仕事と防御的な仕事について、紹介する。
これはぼくの中ではかなり目から鱗であり、これまで概念として持っていなかったものである。

攻撃的な仕事とは、

ユーザーに見えるものである。見た目の輝かしいものであったり、興奮してもらえるものであったり、プロダクトのセクシーさを伝えるものであったりする（UIの改善・スピード・相互運用性など）。

一方、防御的な仕事とは、

プロダクトを長期的に健全にするためのものである（リファクタリング・機能の書き換え・スキーマの変更・データマイグレーション・モニタリングの改善など）。

ぼくは、防御的な仕事こそ、のちのちの手戻りを減らしてくれ、保守性を上げてくれるものであり、
総合的にコスト的メリットが大きいものであると考えていた。

しかし、社内ではどちらかというと攻撃的な仕事の方が評価され、信頼も獲得できるという。
考えてみれば、会社に利益を与えるのは、確かに攻撃的な仕事のようにも思う。
双方のバランスを考え、これまでより攻撃的な仕事を意識して取り組んでいきたい。

4. ユーザーに対して

=== エンジニアの真の役割とは何か ===

エンジニアの真の役割とは、
ユーザーに対して価値を提供できるようなプロダクトを
作成し、改善していくことである。

つまり、全てはユーザーに集中すべきなのである。

ぼくはこれまで、

技術への造詣を深めたい
チームとして最大のパフォーマンスを発揮したい
自分のキャリアを強められる仕事をしたい

と考えている節がかなりあった。

しかし、まず考えるべきはユーザーのことであったと感じた。
ユーザーが無ければ、エンジニアもひったくれもない。

ぼくらエンジニアは専門家である。
ユーザーに対して複雑さを見せないようにし、ユーザーの感情に耳を傾け、真摯に対応していくことこそエンジニアの真の役割であると改めて思わされた。

最後に

この記事はあくまでも本書を読んだうえで、特に共有したいと思うことをピックアップして、ぼくの経験や考えを交えて論じているものである。

詳しくは、本書をぜひ手に取って読んでいただければと思う。

最後まで読んでいただき、ありがとうございました！！！