先日ロングフライトの間に1冊本を読むことができたので、そこで学んだ内容を整理してみようと思います。
なぜこれを読んだかというと、私自身マネージャー思考よりもスペシャリスト思考ではあるのですが、ここ最近プロジェクトのリーダーになる事や後輩に指導するなど、リーダーシップの発揮が求められる機会が増えてきました。
どんなキャリアを歩むにせよ、経験を積めば積むほど多くの人と仕事をする機会が増えるため、リーダーシップの発揮は大事だと考えています。
その中でどのような対応が望ましいのか思考錯誤している中、周囲で評価の高かった「Team Geek」を読むことにしました。
こちらの本はGoogleが良いソフトウェアを開発するために、どのようにしてチームを作っているのか、そのためにどんなアクションが理想なのかが記載されています。
対象読者の前提も本書に次の2点と明記されています。「他のプログラマーとチームで仕事をしている」「ソフトウェアエンジニアリングを楽しんでいてやりがいを感じている」
私は現時点ではインフラエンジニアであるのでやや対象から外れるかもしれないと思ったのですが、技術者で集まって何か一つの良いモノを作り上げるという要素では同じだと思ったため読むことにしました。
次から各章で印象的だったポイント、仕事で実装したいと思った内容を書いていこうと思います。(※既に知っていた内容や実践できていると思った内容は省略しています。）
1章 天才プログラムの神話
この章で印象的だったのは以下の点でした。
・天才なだけでは不十分で、その才能ある人をどのようにチームにアジャストさせるかがより重要
マイケルジョーダンを例に本書は書かれており、ジョーダンがスーパースターで皆から崇拝されるのは当然な一方で、彼が活躍出来たのは監督がジョーダン中心の戦略を作ったからだという旨が記載されていました。
チームスポーツが、実力は非常に高くてもチームに溶け込めず、本来の力を発揮できない選手を多く見てきました。また仕事の場でも、高い技術力を持ちながらマネージャーと対立してしまい、昇給や昇進のチャンスを逃す人を見てきました。そのため、「個人の能力だけでは成功しない」という点には深く共感します。
私は突出した個人の才能を持つタイプでは無いので、「周囲との潤滑油になる力」を磨くことも、今後のキャリアにおいて大事にしようと思います。
・一人で進めるのはリスクのため、情報をオープンに公開することが大事
これは自己啓発系の本でよく書かれている内容と同じですが、ミスに早く気づいて軌道修正するために、途中経過でも現在の進捗は共有した方が良いという内容でした。
細かくプルリクエストするや、ドキュメント完成前でも途中経過をレビューしてもらう等は今後も意識していこうと思います。
・チームで働く3本柱HRT「謙虚」「尊敬」「信頼」
あらゆる人間関係の衝突はこの3本柱の欠如によるものと記載されています。
この3本をもう少し具体的にブレイクダウンすると、以下になると考えています。
・謙虚：ここで言う謙虚とは自分の意見を言わないことではなく、集団の目指す方向性を一番に考えて意見、アクションをするというものだと読解しました。
・尊敬：レビューをする時に、「尊敬心を持った上で成果に対する建設的なアドバイス」と「性格に対する攻撃的な批判」との違いを理解することが大事だと読解しました。
また前者のレビューをするためには「間違っている」「こうするべきだ」と言うよりも、「この方が制御しやすいのでは？」と自分の疑問としてaskすることが効果的
・信頼：上記の2点を意識して大事にした結果、他の人に「この人はプロジェクトに恩恵を与えてくれる」と思ってもらえる＝信頼を得ると私は考えています。
2章 素晴しいチーム文化を作る
・文化とはエンジニアリングチームが共有する経験/価値/目標であり、強い文化があれば新参者にも働きかけチームをより強固なものにするものである。
新しく来るメンバーにも個人の文化や習慣があり、チームの文化が弱いと新メンバーの文化が広まって予測不可能な結果を招くリスクがあると言った旨の記載がありました。
その文化の作り方もこの章では書かれていました。一方で自分も新参者になることはあるので、今から入る部署/チームにはどんな文化があるのかに興味を示す必要もあると思いました。
また余りにも文化が無い若いチーム、ビルディングに失敗していると判断したチームがあれば、新参者がこの章で書かれている事を実践する必要があると思いました。
・優秀なエンジニアに働いてもらうには「合意ベースのチーム作り」が重要である
優秀なエンジニア程自分でチームというバスを運転したいと考えているので、合意ベースのチームであれば運転に参加出来るという内容でした。
この合意とは、プロダクトの成功に強い責任を持ち、リーダーがチームの意見に耳を傾けることであります。
・ハイレベルの同期
コミュニケーションには「ミーティングなどの同期型」「メールやチャットなどの非同期型」の２つに分かれ、同期型は人数を必要最小限に抑え、同期は任数を増やすことが推奨されています。
その中でも同期型をハイレベルにする方法が記載されています。
１．ミッションステートメント
チームレベルの「企業理念」のようなものと私は思っています。
エンジニアリングのミッションステートメントであれば、チームの方向性を定義してプロダクトのスコープを制限したことが分かる内容が良いと書かれています。
2.地理的障害のあるチームで働く
リモートで働くときは様々なツールを利用して積極的にチームとコミュニケーションを取ることが必須という内容でした。
また、オンサイトでのコミュニケーションの価値にも触れられており、昨今日本でもリモートワークは進んでいますが、定期的に会いに行くことも大事だと記載されています。
これは私の経験的にもオンサイトで交流した人は、チャット時にも相手の反応のイメージが付きやすく、コミュニケーションのし易さが実感できるので、ある程度の対面の機会は大事にしようと思います。
3.設計文書
コードを書く前に設計思想を文字や図としてアウトプットしようという内容でした。
こちらはSIerからすると設計文書ありきでプロジェクトは進みますが、引き継がれた文書に設定内容の背景が不足した事が原因で生じたトラブルは私も多く経験しているので、運用面も考えて設計書に落としていこうと思います。
4.エンジニアリングとしてのコミュニケーション
コードレビューはプロダクトのミスを無くすという意識はありましたが、本書ではチームの品質に対しての誇りを育むためにもすべきと書いてあり、その意識でもレビューはしていこうと思います。
3章 船にはキャプテンが必要
ここではマネージャーというポジションは望んでいなくても、リーダーの立場になるときはあるため、その時の対応方法について触れられていました。
まさに今の私の立場だったので大変興味深い内容でした。
・リーダー
印象的だったワードして次のものがありました。
「リーダーは何ができるかを考えて、どうやって仕事を完了させるかはチームに考えてもらう」
これを実践するにはリーダーがチームメンバーを信頼している必要があると思います。
そして何ができるかを考えるのに今まで自分が手を動かしてきた経験が活きるのだと思います。
・リーダーのアンチパターン
1.自分の言いなりになる人を採用する
2.パフォーマンスの低い人を無視する
パフォーマンスの低い原因を知るためにも、成長させるか退席させるかの判断をするためにも早く対応した方が良いことが書かれていました。
一点気になったのが、日本では現状「退席させる」という判断は難しいなというのが正直なところです。
退席させるにしても必ずしもその人が悪ではなく、他のポジションで活躍する可能性もあるので、相手のためにも異動制度は会社としても柔軟に使えるようにしてほしいと考えています。
3.人間の問題を無視する
4.みんなの友達になる
5.採用を妥協する
6.チームを子供として扱う
・リーダーシップパターン（良いパターン）
1.エゴをなくす
2.膳マスターになる
チームメンバーがアドバイスを求めてきたら解決モードになるのではなく、メンバー自身が問題解決するのを手伝い、メンバーの答えが見つかるようにするという記載がありました。
緊急度も考慮した上で答えではなく、その答えにたどり着くプロセスやフレームワークを教えるなどしてサポートしたいと思います。
3.触媒になる
4.先生やメンターになる
5.目標を明確にする
6.正直になる
7.幸せを追い求める
生産的にし離脱者を少ないチームを作るには、チームの幸せを計測すると良いという記載がありました。
一人一人の幸せの基準は違うと思うので、そこは1on1や普段の何気ない会話から基準を理解していく必要があると思います。
4章 有害な人に対処する
・個人を良い悪いと定義するのではなく、悪い振る舞いを除外していくことが大事。
チームの中に有害という感情を抱いた時に、どうしても人に焦点をあてがちですが、まくまで振る舞いを除外するように心がけたいように使用と思います。
・不機嫌の真実を探す
例え棘があるレビューコメントだったとしても、その中に有益な情報が無いかに意識し、感情的にならずに技術的な議論に回帰するように心がけようと思います。
# 5章 組織敵操作の技法
・できるだけ約束は小さくして成果物は大きくした方が良い
出来ない事をやりますと言って出来なかったときの信頼の落とし方は大きいので、成功体験を多く積んで自分に自信をつけるためにも評価のためにもこの方法は意識するようにしたいと思います。
・昇進ゲームへの参加
昇進欲求をガンガン出したアピールは私自身好きでは無いですが、会社で働く以上は割り切って参加するしか無いと思います。
昇進すると仕事のコントロール範囲も増えて自分のやりたい事に近づく可能性も高いため、ここは割り切って参加しようと思いました。
・依頼のテクニック（メールやチャット）
メールを読む人の時間を奪ってしまうので簡潔に分かりやすく記載すべきだという内容が記載されていました。
「3つの箇条書き（現状の説明）と1つの行動要請」というフレームが紹介されており、勿論内容によっては纏めきれないとも思いますが、個人的にも「課題」「依頼」といった項目に纏めて暮れている方が文章は読みやすいので、メールやチャットでは意識しようと思います。
6章 ユーザーも人間
この章ではソフトウェアはユーザーに使ってもらえないと縮小、消滅してしまうためエンジニアもユーザーの視点を知ることの重要性が説かれています。
良いソフトウェア＝ユーザー満足度が高く、永く使ってもらえるソフトウェアだと思っている為、開発者にとっても、ユーザーとのつながりは重要な点だということは強く共感しました。
この章に関しては組織に対してへの働き掛けというより、一人一人が意識して持っておいた方が良い内容だと思います。
次の3フェーズを理解して置いた方が良いと記載されています。
・マーケティング
ソフトウェアがどのように見られているのかに気を配る
それによって使ってもらえるかが決まる
・ユーザビリティ
複雑なシステムだとしても、ユーザーインターフェースはシンプルにし、使いやすさ、レイテンシ、頻繁なエラーなどの問題があればユーザーの利用が無くなり、ソフトウェアの発展が無くなると記載されていました。
・顧客サービス
技術以外にも関わる内容で、顧客が課題に感じたときにサポート出来るかといったサービスの質も良いソフトウェアになるかどうかの分岐点となることが書かれていました。
また、顧客は技術者とは関わらないので、顧客の書いた問題報告を解釈することも重要なスキルであると思いました。
そして部署レベルでカスタマーサポートと開発で分離されていたとしても、こういった顧客サービスに目を向けた開発をするめにも意見を貰えるような場を作って行きたいと思います。
総評
初めインフラエンジニアでも役立つ内容だろうか？と不安に思って読みましたが、問題ありませんでした。
技術力に目が行きがち（大前提として勿論必要なのですが、、）ですが、エンジニアも一人の人間なのでチームの関係性構築もプロダクトを作る上で大事なスキルだと思います。
もちろん中には外資、大企業だから語れる理想論の部分もあるとも思いましたが、そこを自分用にアジャストさせることも一つのスキルだと思います。
個人的には技術者だけでなく、ITプロダクトを販売しているセールス職、エンジニアの採用をしている人事の人などにも読んでもらえると、何にエンジニアは苦悩して仕事しているかを感じとってもらえるとも想い、とても良本だと思います。
本に書いてある＝正解では無いかもしれませんが、ここに書いてある事を自分は実践できているか日々見直ししていきたいです。