🤔

チームリーダーになったら大事にしたいこと

2022/04/30に公開

ポエム

チーム開発

idea

これは何？

チームリーダーの観点でプロダクト開発を上手く進めていくために重要だなぁと感じたことをまとめました。

背景

最近、自身の所属しているチームでチームリーダーを担当させて頂くことになりました。チームリーダーを担当するようになり今までは見えてなかったことが沢山あるなぁと感じる日々です。特に「プロダクトを成長させていくにはチームとしてどのように活動していくのが良いのだろうか」という観点を頻繁に考えるようになりました。そんな中で考えたことをつらつらとまと書き綴りました。

※新米チームリーダーであり今まさにダニング＝クルーガー効果もニッコリな状況ですので、生暖かく見ていただけますと幸いです。

前提

クラウドインフラエンジニアの観点から記載しています
いわゆる技術的な観点には触れていませんが、技術力が不要ということでは一切ありません
分野毎にチームが存在する規模の組織を前提にしています
あくまでも自分が大事そうだなと思ったことを記載しているだけであり、「これらの観点を誰もが絶対に100%持ち合わせているべきである！」という意図はありません
「ここに挙げていないことは重要ではない」ということでは一切ありません

プロダクト開発は団体競技

プロダクト開発は個人競技ではなく団体競技であると思っています。これを読んで「そりゃそうでしょ。何言ってんだ？」と思う方は多いかと思いますが、現実世界で巻き起こる事象を見ると意図の有無にかかわらず意外にも「個人競技」をしている方も多いです（もちろん立ち上げ初期のスタートアップにはこのような状況に迫られている可能性もありますが、今回の対象外なので触れません）。

プロダクト開発が団体競技である（もしくはそう考えた方が組織としてより幸せになれる可能性が高くなる）理由は単純に 扱う対象が自分だけでは完結しない規模・複雑さであり、チームとして活動する方が効率的だから です（理由は他にもありそうですが）。
例えば「プロダクト開発・運用のために複数チームが存在（例：フロントエンド,サーバーサイド,クラウドインフラでそれぞれチームが存在）し、各チームは5名程度で構成されている」といった組織構成をとっているプロダクト規模で「チームリーダーが1人で仕切り、重要なタスクは全てチームリーダーが実施し、チームのレビューは全部チームリーダーを通すようにし、チーム間のやり取りも全てチームリーダーが実施する」といったムーブをし始めたらどうなるでしょう？
もしもその人が他の誰よりも技術力・馬力などを持っているとしたら短期的に上手く回るかもしれませんが、長くは続かないであろうことは想像に難くないかと思います。そもそも1人で対応できない規模であるからチーム構成をしているわけですし、チームリーダーが（半ば監視者や独裁者のように）全て管理すればいいというものでもありません。またチームのモチベーションや属人化などの観点もすっぽりと抜けています。

チームリーダーの役割は チーム活動におけるアウトプットを最大化すること であり、チームリーダーが技術面などで一番になることではないと考えています。チームが個人競技ではなく団体競技となるように努めることでチーム全体のアウトプットが向上することが重要であると思います。
そのためにも、以降に挙げるような事項を意識・実践していくことが大切ではないかと考えています。

共通認識の構築は偉大

組織で活動する以上、共通認識を築くことは必須です。小さなタスクをこなす時でさえタスクを依頼する側と実施する側の両者で「ゴールはなんであるか」の共通認識を持っている必要があります。

チーム運営において「我々は今どんな状態にあるのか（物事は順調にいっているのか？今抱えている問題は何か？）？今後どういった方向へ進んでいくのか？」をチーム内の共通認識として備えることは非常に重要であると思います。チームのみんなが同じ方向を向いて取り組まないと組織としての成果も出てきません。
特にクラウドインフラにおいてサービス基盤を構築した後は（サービス拡大によって追加開発もありますが）専ら運用とそのブラッシュアップが中心となりがちで、今後どのような取り組みを実施していくかを自分達で考えていく必要があります。自由度が高い分、何をやっていいのか掴みどころのない話にもなりがちです。
もちろんタスクレベルでやりたいことは既に沢山あるかもしれませんが、そこから一歩引いた視点から「プロダクトの成長にクラウドインフラがどのように貢献していけるのか？そのためには何が必要なのか？」の共通認識を持っていないとプロダクトはより良い方向に成長しません。またその手の話はなんとなくの課題感などはあるがフワッとしていたり、日常業務をしているだけではチーム内で共通認識を持つ機会が少ないかと思います。

このようにフワッとしているがチームの足並みを揃えるために必要な事項に対しては、明示的にそれをみんなで考える時間を取るべきであると思います。暗黙の了解が本当に暗黙の了解であればいいのですが、往々にしてこの手のものはチーム内での認識が違ったり他の人の視点が見えていない状態にあります。
このための取り組みとしては定期的なプロダクトのロードマップ見直しや運用の振り返りの実施が挙げられます（howについてはチーム毎に合う方法を採用するのが良いと思います）。これらは直接的な機能開発/運用改善にはなりませんが、ここから出たチームの意見・課題認識の共有は今後の向かうべき方向付けに重要であり、時間をとってやる価値があると思います。

チーム間の壁を越える

プロダクト運用をしていく上でチーム間の協力や調整は必須です。プロダクトの拡大に伴ってチームは増加し、チーム間のやり取りも活発になる（もしくはせざるを得ない）ことでしょう。
チーム間でのやり取りにおいて、責任分解点の観点としては「これは自分達のチームの責任で、あれはxxチームの責任です」という切り分けは重要ですが、だからと言って「だから他チームのことには一切関与しません。当人たちだけで解決してください。」といった姿勢ではプロダクトを成長させていくことは難しくなります。（サービスが成長してる限りにおいて）プロダクトに関わる人は多くなる一方であり、チーム間のコラボレーションは避けて通れません。
もちろんチーム毎の役割分担・責任分担は存在しますが、「何かあればいつでも相談に乗るね！」といったサインを出すことはチーム開発において非常に重要であると思います。

また普段関わらないチームのところへ行き相談・依頼をすることは少なからず心理的障壁もあります（権限を多く持つチームに対する相談や依頼は特に）。そのためもし余裕があれば他チームのdaily meetingなどに顔を出したり、一緒に勉強会などを行うことで「我々と彼ら」といった関係からお互いを「共にプロダクトを成長させる仲間」としての関係へレベルアップさせていくことが大切だと思います。

心理的安全性は全ての礎

チームとしてやっていく以上、心理的安全性が高くないと上手く回りません。どれだけ優れたエンジニアであろうと分からないこと・知らないことなどはありますし、他チームとの連携をする必要もあるでしょう。そんな中「対人関係におけるリスクを取っても大丈夫である（貶されたり馬鹿にされたりせず、お互いの意見を尊重し助け合える）」という考え方がチーム内で共有・実践されていることは非常に重要です。心理的安全性が欠如した環境では、先に挙げたような活動も全く意味を成さないものになってしまうと思います。

※心理的安全性に関する詳しいことは心理的安全性のつくりかた「心理的柔軟性」が困難を乗り越えるチームに変えるを一読されることをお勧めします。

雑感

チームリーダーを担当して日が浅いですが、パラダイムシフトが起こったかのように新しい視点が沢山入り込んでいます。また記載した事項を完璧に実践できているわけではないため日々精進といった感じです。
意気込んで色々と挑戦していきたい気持ちもありますが、プロダクト開発は短距離走ではないため無理のない範囲でやっていきたいと思います。