リーダー1年目の僕がチーム開発において気をつけてきたこと|WILLGATE tech blog

チームで談笑している図

こんにちは！サグーワークスの開発リーダーをやっている池添（写真右奥）です！

この記事はウィルゲート Advent Calendar 2019 - Qiita の3日目の記事です。

昨日は @cocoeyes02 の PHPカンファレンス 2019 に、ウィルゲートのエンジニアが登壇しました！ #phpcon でした。

ばりばりコードを書くエンジニアからマネジメント寄りなリーダーの役割に変わり１年ほど経ったので今までの学んできたことを元に今、僕が気をつけていることをまとめたいと思います。少しでもエンジニアからマネジメント職を目指している人の助けになればと思います。

リーダー以前のバックグラウンド
リーダーに対する想い
気をつけていること
まとめ

リーダー以前のバックグラウンド

僕は2015年に新卒で入社してからサグーワークスの開発に携わってきました。入社時点では Web 開発の経験は全く無く当時の上長やチームメンバーに優しくときに厳しくサーバサイドを中心に様々なことを教えてもらいながら開発してきました。また、インフラ領域にも挑戦してみたいと思い、会社の制度である兼任チャレンジと言う制度を使い、インフラチームとの兼任をしていた時期もありました。

サーバサイドの開発では、PHP5.3 → PHP7.0、CakePHP1.3 → CakePHP3.2 という大規模アップデート対応の指揮をしたり、インフラチームでは Terraform、 Ansible を使ってのダイナミックインフラストラクチャなサーバ構築をしたりしていました。

リーダーに対する想い

そんな僕がリーダーになろうと思ったきっかけとしては３つあります。１つ目は自分が入社してすぐのリーダーが僕に色々なことを教えてくれ、そのおかげで今の僕があるということです。リーダー業務で忙しいはずなのに、Web 開発もわからなければ社会人としての基本もなにもわからない僕に本当にたくさんの時間をかけ、丁寧に教えてくれたリーダーがいました。もちろん自分だけではなく、他のメンバーも多くいたので他のメンバーにも寄り添いながら常に優しく厳しく指導してくれていました。そんなリーダーの姿を見ているうちに、自分も後輩やメンバーに対して恩送りがしたいと考えるようになりました。

２つ目はメンバーの教育に関心があったからです。ウィルゲートではそもそもメンバーの教育に熱心ですが、そのメンバー教育に対してもっとコミットしたいと考え、リーダーになりたいと思うようになりました。リーダーはメンバー教育に一定の責任があると考えており、責任と同じだけ、メンバーの成長を身近に感じられると思っています。原体験としては高校のときに数学が得意だった僕が友人やクラスメイトに数学を教えたときに、自分の知識を表現を色々変え、工夫し、やっと伝わり理解してもらったときの快感。自分の知識が他の人の役に立つことができ、他人が成長できることが素敵だと感じました。社会人になってからも他人にプログラミングを教えたり、設計を教えたり、または一緒になって議論している時間がとても楽しかったためです。

３つ目は、自分ひとりがばりばり頑張ってバリュー（生産性）を出すよりも、自分の経験やノウハウをチームや組織にインストールして、みんなで開発したほうがバリューを出せると思ったためです。自分は超凄腕エンジニアというタイプではないので、小さく積み重ねてきたものを何らかのエコシステムとして周りに提供するようなそんな開発が好きでした。なので、技術領域としても自動化や仕組み化というような作ったものによってレバレッジが効く、そういうものが大好きでした。（システムの自動化や仕組み化が大好きで勝手に CI や自動テストを導入したりしていました。）これらのことを当時明確に言語化できていたわけではないですが、これらのようなことを考えてリーダーになる決心をしました。

気をつけていること

ここから本題ですが、エンジニアからリーダーになってたくさん失敗もしてきました。そんな僕が今気をつけていることについて4つの観点でまとめてみました。

1. 開発

リーダーとして開発に接していくと自然と要件を詰めたり、他部署との調整や、メンバー教育などの稼働が増え、結果的に開発できる時間が減っていきがちです。もちろん開発の稼働時間が減っていくとともに、自分の開発時間をうまく使わないと技術のキャッチアップは遅れていきます。また、リーダーになりたての場合チームの生産性が思うように出ず、自分の開発時間で帳尻をあわせがちですが、チームの生産性は中長期的に見るとむしろ下がっていく可能性があるのでやめるべきです。常に全体効率と中長期的な生産性の向上を考えて開発を考えていく必要があり、メンバーとして開発していた頃よりも難易度が上がってきます。

原則自分の開発稼働は工数として勘定しない

自分が生産工程に入った場合、チームの中長期的な戦略を考える人がいなくなってしまう恐れがあるので基本的には自分の工数は勘定していません。自分が生産工程に入るときは、チームとしてもプロダクトとしても緊急のときと考えています。

エンジニアとしてワクワクするか

これも大事にしていることの一つです。ビジネス要件ももちろん大事ですが、エンジニアを名乗ってる以上は技術的にもワクワクできるかどうかを考えたいと思っています。そのためには開発から技術的な提案をしたり、新しい技術のキャッチアップやチームメンバーの興味領域の技術習得もしたりしています。幸いにもプロダクトの課題はいっぱいあるのでそれらに対してこういう技術を使えば解決できそうだよね、というようなことを日常的にチームで話しています。

2. 対事業・対プロダクト

リーダーをしていくとビジネスサイドの人との調整やヒアリングなどの機会が増えてきます。その際に開発サイドとビジネスサイドという対立構造に陥りがちですが、このような構造にならないようにすることがとても大事です。

同じ課題を解決する仲間になる

ではどのようにしてこのビジネスサイドとの対立構造を回避すれば良いでしょうか？ビジネスサイドの人とどのようにしてうまく協業していくかという話につきるとは思いますが、本質をたどれば同じプロダクトを開発している仲間です。意見が衝突することもありますが、見えてる課題や情報量に差があることが多いです。意見が衝突したときは、なぜ意見が衝突しているのかを冷静になり俯瞰的に考えてみると案外対立する必要がなかったりします。またビジネスサイドの人と対等に意見を言い合えるようになるためには、ビジネスサイドの人が見ているものや感じてるものを一緒に見たり感じるのが一番はやいです。一緒に見て考えることでより身近に感じられ、仲間意識もついていきます。また、一緒にプロダクトを考える仲間を作る際は一度に仲間を増やすという思考よりは、仲のいい人を徐々に増やしていく思考の方がやりやすいかと思います。

方法を知る

事業の改善をしようと思っても、ただがむしゃらにやってもなかなかうまくいきません。なにしろ事業の改善はすごく小さな針の穴に糸を通す作業をやるようなもの。それを何も参考にせずにやるということは目を瞑りながらやるようなものです。様々な手法、やり方を身に着け必要に応じやり方を変えてやることで針の穴に糸を通す作業もずっと楽になるはずです。具体的には、最近は GV が推奨している Design Sprint などのやり方を学び実践したりしています。

3. 教育

リーダーの重要な役割の一つにチーム、メンバーの成長というものも包含されていきます。なぜならリーダーは、チーム生産性の最適化をミッションに持っているためです。高い大きな目標を成し遂げるためには高い生産性が必要ですし、そのためにはチーム、メンバー双方の高いレベルでのスキルが求められます。また、チームに求められる成果も常に上がっていきますので、常にチーム、メンバーの成長ができるようリーダーは動いていくことが求められます。

メンバーひとりひとりと向き合う

当然ながら、チームにはそれぞれ得意分野や考え方、特性、感性などの違ったメンバーがいます。同じことを言ってもそれに対する受け取り方はメンバーによって全く違います。目指す目標や得意なことやりたいこともみんな違うものです。そのため、個々人の違いをいかに多く気付けるか、それに合わせたコミュニケーションや役割分担ができるか、チームに対する画一的なマネージメントだけではなく、メンバーひとりひとりにあった最適なコミュニケーションができるか。これの難しい点は所属してるメンバーのタイプによっては、 たまたま うまくできてる可能性があるということです。なので、僕はいつまで経っても慣れた気にならず初心に戻って全力でメンバーと向き合うようにしています。

チームで目標、現状を共有すること

メンバーひとりひとりは違うものの、チームとしては一丸となって進んでいきたいものです。そのためには、チームメンバーみんなでみんな納得する目標を立て、それに向かって全力で突き進むことが大事です。僕達のチームではチームの目標をメンバー主体となって決めてもらってます。また、目標は高すぎても、低すぎてもだめで達成できるか達成できないか半々の目標設定をすることが重要です。

4. 自分の成長

これも当たり前ですが、チームを引っ張るリーダーがいつまでも成長しないと、チームの成長も打ち止めになってしまいます。チーム、メンバーの成長に合わせて自分もどんどん成長していく必要があると思ってます。特にリーダーに成りたてだった1年目はチームをどう率いていけばいいかもわからず、自分の成長が真っ先に求められていることを感じました。

セルフマネジメント

リーダー業務はチームマネジメント、メンバーマネジメント、場合によっては進行中のプロジェクトのプロジェクトマネジメント、プロダクトの中期戦略を考えたりなど多忙になっていきます。求められることの量が多いので、うまくタイムマネジメント、セルフマネジメントをしていかないとあっという間に一日、一週間、一ヶ月と時間が経って行きます。気がついたら、数ヶ月経って何も成長できていないなんてことも……

僕が意識的に行っていることとしては基本のキですが、日次・週次でのタイムマネジメントを行い自分が何に時間を使ってるのか、使えてないのかの可視化と分析を行っています。また、前項の自分の成長の話にも繋がりますが目標に対しての振り返りを月ごとに行ってます。あとは、メタ認知をうまく使い自分自身をメンバーマネジメントするようにマネジメントすることです。自分をメタ認知してメンバーマネジメントするとメンバーマネジメント力もつき、メンバーの気持ちもわかるので一石二鳥でおすすめです。

成長に貪欲になる

プロダクトのフェーズやチームのフェーズ、メンバーの状態などによってリーダーに求められることも大きく変わってきます。そのためリーダーはいろんなことに興味関心を持ち、成長につなげるハングリー精神が必要です。技術のこと、マネジメントのこと、プロダクトのこと、幅広い観点で成長していく必要があります。そのためには今の課題だけを考えるだけではなく、半年先、一年先、三年先と先々のことを考えるといいと思います。