こんにちは2025年内定者の千木良です。現在は東京国際工科専門職大学4年生で、２０２５年４月に弁護士ドットコムに入社予定です。
２本目の記事では、チーム開発では欠かせない思考を学べる「Team Geek」について大切だと思った点をまとめました。
学生と社会人の大きな違いは、チーム開発を行うかどうかだと思います。本書を読むと、チーム開発を円滑に進めるための知識が身につくためぜひご覧ください！
この本が必読書である必要性
Team Geekを読んで私が感じたことは、Team Geekで大事にしている考え方がないとチーム内で余計な衝突が起きたり信頼し合える関係を築くことができなかったりすると感じました。
チームで開発するメリットは多くありますが、一番は大規模な開発を短期間で実装できることだと思っています。そのためには、チームが協力して信頼し合える環境じゃないと意味がありません。
そのためには、Team Geekで大事にしている考え方HRT (謙虚(Humility）、尊敬(Respect)、信頼(Trust))を理解することが最善であるため、必読書に選ばれたのではないかと思います。
Team Geekとは
本書の目的は、プログラマーがソフトウェア開発を効果的かつ効率的にするために、他人の理解・コミュニケーション・コラボレーションの能力を向上させることです。
プログラマーは、最新の言語が扱えたり高度なコードを書けるだけでは成功できません。プログラマーは常にチームで仕事をするため、技術的な能力と同じだけ対人関係の能力が必要になります。
本書は、対エンジニアとのコミュニケーションにおいて重要なことが記されています。本書を読めば、より良いチーム開発ができるようになり、より良いプロダクトをローンチできるでしょう。
こんな人におすすめ
本書では、ソフトウェア開発者を対象にしていると記述されています。しかし、昨今のIT企業はエンジニアとビジネス側との交流が盛んであるため、エンジニアと少しでも関わりがあるビジネスマンは読んだ方がいいと思いました。
エンジニアが過ごしやすい開発環境とはどういうものなのか、どういった環境づくりが大切なのかぜひ本書を一読してみて考えてみて欲しいです。
Team Geekの重要ポイント
「ソフトウェア開発はチームスポーツである」*1
チーム開発における重要な考え方
優れたソフトウェアチームを作るには、大事にするべきものが３つあります。この三本柱は、人間関係を円滑にするだけではなく、健全な対話とコラボレーションの基盤となります。
- 謙虚（Humility） ： 世界の中心は私たちではありません。私たちは全知全能ではないし、絶対に正しいわけでもありません。常に謙虚でありましょう。
- 尊敬（Respect） ： 一緒に働く人のことを心から思いやりましょう。相手を一人の人間として扱い、その能力や功績を高く評価しましょう。
- 信頼（Trust） ： 自分以外の人は有能で、正しいことをすると信じましょう。そうすると、安心して仕事を任せることができます。
この３つを合わせて本書では「HRT」と読んでいます。なぜこの３つなのかというと、あらゆる人間関係の衝突は、謙虚・尊敬・信頼の欠如によるものだからです。
面倒もしくは不快な人間関係を思い浮かべてみてください。誰もが謙虚ですか？相手を尊敬していますか？お互いに信頼しあっていますか？
この原則が最も重要であるため、まずはHRTを受け入れることが大事です。
君は君の書いたコードではない
プロのソフトウェアエンジニアリングの世界では、批判は個人的なものではなく、優れたプロダクトを作るためのプロセスの一部に過ぎません。したがって、成果に対する建設的な批判と、性格に対する攻撃的な非難との違いを理解しておく必要があります。
前者は役に立ち、後者は役に立ちません。最も重要なことは、批判に尊敬が含まれているかどうかです。
そして、批判を耳にする側は批判を受け入れる方法を学ばないといけません。自分のスキルに謙虚になるだけでなく、他人が恩恵をもたらしてくれることを心から信頼することが大事です。
自分の価値を自分の書いたコードと結びつけてはいけません。君は君の書いたコードではありません。もう一度言います。君は君の書いたコードではありません。
影響を受けやすくする
影響を受けやすくなれば、それだけ影響を与えやすくなります。相手に話を聞いてもらうためには、まずは相手の話に耳を傾ける必要があります。
素晴らしいチーム文化を作る
文化とは
チームの文化は、サワードウパンのようなものです。スターター（創業者）がパン生地（新来者）に菌（文化）を植え付けます。イースト菌と乳酸菌（チームメンバー）が発酵（成長）すると、美味しいパン（いいチーム）ができあがります。*2
チーム文化とは、エンジニアリングチームが共有する経験・価値・目標のことです。チームの文化を作る要素は様々で、コードレビューや事前の設計書のようにソフトウェアに関係するものもあれば、毎週木曜日のランチには決まったレストランに行ったり、金曜日は飲み会をしたりなどの人間関係にまつわるものもあります。
これらの文化は、創業者や初期の従業員が作った文化がルーツとなっていますが、会社が成長するにつれて文化も進化していきます。
文化を気にかける必要性
文化を気にしないといけない理由は、意識しないと文化に気を配らないからです。
文化を気にしていないと、強烈な個性を持つ新来者が現れたら、その人の文化がチームに根付いてしまいます。より良い文化になる可能性もありますが、ほとんどの場合は負の方向に向かっていくでしょう。
これまでは設計やコーディングに使っていた時間が、口論や揉め事に使われるようになります。そのため、チームが大切にしている文化を守ることが重要です。
エンジニアは、チームリーダーがチームの文化を作ると勘違いしている人が多いですが、チームの文化の定義・維持・保守の責任を持つのはチームメンバーです。
誰か新しくチームに参加した時には、チームリーダーから文化を教えてもらうのではなく、チームメンバーから文化を学ぶからです。
成功する文化のコミュニケーション
うまく行っている効率的なエンジニアリング文化では、メーリングリスト・ミッションステートメント・コードコメントなどの多数のコミュニケーションチャネルを使っていることがわかります。
チームメンバーがチームの方向性に合意して、全てを正確に理解することは相当手間がかかります。しかし、この手間は生産性の向上とチームの幸せのために必要な投資になります。
コミュニケーションの原則は、同期コミュニケーション（ミーティングや電話など）の人数や回数を減らし、非同期コミュニケーション（メールやSlackなど）の人数を増やすことです。できるだけ多くの人が、文書から全ての情報を取得できることが重要です。
ミッションステートメントを定義してプロダクトの方向性に合意する
エンジニアリングチームのミッションステートメントは、チームの方向性を定義し、プロダクトのスコープを制限することです。
ミッションステートメントを決めるには時間がかかりますが、やること/やらないことを明確にしておけば、年単位で仕事が節約される可能性があります。
ただし、ミッションステートメントは、絶対に変更できない存在になってはいけません。環境やビジネスプランに大きな変更があれば、ミッションステートメントを再評価する必要があります。
外発的動機と内発的動機
モチベーションは２種類あり、それは外発的動機と内発的動機です。外発的動機とは、外からの力（お金や名声など）で生まれるもので、内発的動機は自発的なものです。
人を幸せで生産的にするものは外発的動機ではなく、内発的動機であると言われています。そして、内発的動機には、自律性・熟達・目的の３つの要素が必要と言われています。
自律性とは、誰かがマイクロマネジメントするのではなく、自分で考えて行動できることであり、熟達とは、新しいスキルを学ぶことに加えて、既存のスキルを向上させることになります。
自律性と熟達は、理由もなく仕事をしている人のモチベーションにはつながりません。そういった人には、仕事の目的を与えなければなりません。仕事の目的が見つかれば、モチベーションと生産性が驚異的に向上します。
さいごに
Team Geekは、エンジニアの環境づくりには欠かせない一冊になっています。
今回の記事では全ての内容に触れることができなかったため、本書を読んでより良い文化を作っていきましょう。
来年度からは新卒エンジニアとして弁護士ドットコムで仕事をするので、Team Geekを参考により良いチームを作れるよう頑張っていきます。
