システム開発チームのリーダとはなんなのか
この記事は、OpenLogiアドベントカレンダー用に書いた記事です。
何年かプログラマをつづけています。
新卒で入社した会社でも開発チームのリーダをしていた時期がありますが、その他経験を経て、またしてもチームリーダというポジションをしています。
その中で、チームリーダとはなんなのか、そして実務的にはどうあるべきなのか、実体はどうかなど、現状をまとめてみたいと思います。
僕の考え的にもチームリーダの範疇を超え気味だよなーと思うこともあります。
しかしそれは自分のキャリアのためにしていることであり、必要だからやろうと思ったことです。
ただ、そういったものの責任範囲が、もっと明確な組織にしていきたいですね。
チームリーダとは
チームリーダとはなんなんでしょうね。いくつか意味があると思っています。
また、あくまでシステム開発におけるチームについてです。
組織を階層化した際のポジション
これは人数が多ければ、一人の人間が管理できる限界人数があるので、ある程度グルーピングして管理したい際に、中間管理職を置くというものかなと思います。
組織と個人をつなぐ役割なので、開発者というよりは、人事的な部分が多いでしょうか。
僕個人は、組織に合う合わないという表現は好きではなく、相互の信頼関係が結べることが大事だと考えているのですが、組織がメッセージを発信し、個人は聞くだけでは信頼関係は得られないと思っています。
相互の理解のためには、こういった中間管理職が間に挟まるべきなのかなと思います。
開発のリード
これは読んで字のごとく、開発をリードすることです。
やることとしては、開発者の相談にのったり、アドバイスすることで効率のよいやり方を進めたり、または大きく開発手法を変えることで、生産性を上げたりなどです。
技術の選定なんかはわかりやすいやることかなとは思いますが、それよりも大事なのは、どういった技術がビジネスや組織にふさわしいか、言語化できる力だと思っています。
開発をリードする上で、それをチームの外にも話していかないと行けないので、そういった意思決定のプロセスを表現できないようではリードとしてはふさわしくないなと思います。
雑用係
メンバーには開発に集中してほしいので、その他の雑用は引き受ける形になるかもしれません。
逆にこういった雑用に名前をつけて、誰がやるべきか定義して行くのも仕事の一つなのかなと思っています。
このような職務があるのかなと思うのですが、それらの中で僕がどんな仕事をしているのかを書いて行きます。
実務
プロダクト開発について
これはリーダとしての仕事の中心の話です。
コーディング
よく言われるように、コードを書いているのか？みたいな問いですが、最近はコード書いてないです。
手が空いたらコードを書くことはありますが、メインタスクとしてコードを書くことは現在ありません。
ただし、コードに触れる機会はどちらかというと増えている気がします。
レビューがめちゃくちゃ来るので、それを見ないと行けないからです。
対象のコードベースでコードを書いたことがない状態で、レビューをするのは辛かっただろうなと思います。
もちろんこれは、新規で作り始めたコードベースについてはそうとは言えませんが。
ただコードは書きたいなと思うときはありますね。
最近はprivateで勉強時間が確保できないことも多いので、そこで充足してないのも関係していそうです。
レビュー
レビューはとにかく多いです。これが仕事の半分くらいのイメージ。
ただ、レビューをたくさんするようになって、レビューの意味は非常によく考えるようになりました。
レビューというか、開発プロセスの中で担保したいこととしては、複数の人間がコードが問題ないであろうという合意のもとでリリースしたい。
また、基本的にはプログラマ間の技術的ドメイン的な情報格差があるので、それを埋める活動が必要ということです。
それは正直レビューのみに頼らなくてもいいことなので、その辺りに何か施策を入れて改善し、レビューも減らして行きたいです。
レビューに限らず、開発プロセスの改善は、今後の自分の課題になりそうです。
あんまり開発プロセスを固定化して、やりづらい環境にはしたくないのですが、特に複数の人間によるコミュニケーションが発生する部分はきちんと定義したいです。
プロダクトマネジメント
会社にPdMというポジションがあるので、プロダクトマネジメント業務は僕はやっていません。
この辺りは会社によっては、プログラマがかなり能動的に要件を決めるところからやることもあるでしょう。
PdMとのコミュニケーションでは、バックログに上げたものを、僕がリソース配分の上でスケジュールし、PdMに連絡するという形を取っています。
これで、開発の依頼をうけて、その状態を全社に公開できる状態となっています。
困り事の解決
これはメンバーに何かトラブルがあった際にサポートする役割です。
メンバーの能力や経験年数によって、サポートの質は違っていて、経験が少ないメンバーには開発手法を伝えたり、一緒にコードを読んだり。
経験があるメンバーについては、特に社内のコミュニケーションで困ることは多いので、そのサポートなどです。
これはレビューでの話とつながるのですが、こういった困りごとを解決するスキームをもっとしっかり組んだら、開発速度が上がりそうだなと思っています。
人事的な活動について
人事的な活動については、リーダの仕事かなーという部分もありますが、これは会社によっては必要とされる要素かなとは思います。
採用面接なんかは、リーダに限らず駆り出されるべきかなとは思いますが、面接スキルというものが一定異常必要なので、どこかでスキルの補完をする必要があるかなと思います。
チーム目標の設定
チームとしての目標を決めていきます。
各人の意見をすり合わせて妥当なものを設定する必要があるので、けっこう大変な作業ですが、チームという体裁を保つためには、共通の目標があるべきなので、大事な取り組みだと思っています。
メンバー評価
以前からやっていたこととしては、採用面接ですが、評価のみならず、可否の判断への発言力も少したかまってきている感じがしています。
また、チームメンバーの評価支援も業務に入っています。評価を決定するところまではしないので、精神的な負荷は低いです。
今期から、リーダが評価の支援をするということで、メンバーの個人目標なども見る形になっています。
その人にとってちょうどよい目標であるか、簡単すぎないか、大変すぎないか、それでいてチャレンジングであるかは確認していく必要があります。
評価に対する考え方を説明したほうがいいと思うのですが、僕は評価をしない組織というものをあんまり信じられません。
なぜなら、誰しもコイツと働きたくないとか、この人とはやりやすいなという評価を、心のうちに秘めているからです。聖人君子とかじゃなければ。
それらの集積が、被評価者への評価であり、それをせずに仕事を割り振ることはできません。
ただ、評価が給与に反映されるか否かは別の話で、そこを一緒にしてしまうとわかりづらくなってしまいます。
弊社では、もちろん僕自身のメンバーへの評価が多少なりとも給与に反映されてしまう(と思ってるけど)ので、そこはややこしいですね。
1on1
1on1はチームリーダ開始時からしており、1on1というと個人間や組織との信頼形成に使うものですが、基本的にタスクの管理やそれらのトラブル検知に使われています。
もちろん、雑談やその他の相談をしてもらってもいいのですが、なかなかそういう感じにならないですね。これは僕が雑談苦手なせいもあると思います。
翻って、個人と組織との信頼関係の醸成は管理者の業務なので、チームリーダの役割としては少しオーバーかなとは思っています。
1on1の中では、経営会議の内容(僕も参加はしてないです)の共有はしており、これに関しては上に書いた通り、個人と組織の信頼関係構築の一貫かなと思っています。
1on1を実施している理由としては、僕自身はあんまりチームというのは個人の集合として捉えているのが理由です。
あくまで個人の感情や考え方が先にあり、それを元にチームを作るということなので、個人にフォーカスして仕事やその他の状況を把握するまとまった時間があるべきだと考えています。
採用面接
これはチームリーダをする前から行っていました。
最近は採用面接にも慣れてきていますが、弊社の採用プロセスとして、ちょっとした事前提出のコーディングテストがあり、そちらの評価も行うので、面接前の資料読みが少し時間がかかります。
やり方としては、事前に職務経歴書やコードを読んでおき、その人のイメージをつけて、質問を考えておきます。
実際に実施する際には、話してもらったことから取っ掛かりを見つけて質問していくので、事前に考えておいた質問を使わないことも多いですが、事前にイメージをふくらませて置くとスムーズに感じます。
雑用
雑用とするべきかはわからないですが、チームリーダ間でこぼれ落ちるタスクはいくつか拾っているものがあります。
たとえば、phpのversion upで大きな変更があり、警告が増えたのですが、それらを放置しておくと次期versionでエラーとなってしまいます。
それらをまとめた上で、修正の必要があるか検討するなどの仕事をしています。
この辺りは、チーム内のスコープで収まることであれば、誰かにお願いすることもできるし、そういったスキームを組むのですが、チーム間で発生するとどうしてもやらなくてはならない仕事がでてきます。
立場で変わったこと
リーダになって僕自身の意識的に変わったことです。
いろんなタスクを知る必要があり、どの仕事がどこでどう動いているかは、自分を中心として情報が集まっていなくてはならないという認識が強くなりました。
そういう意識に至ったところとしては、やはりたくさんのタスクをさばかなければ行けないが、その主体にはなれないという立場だからだと思います。
したがって、細かくしっかり調べることは少ないのですが、レビュー時にコード上に視点が書けていた場合は、どのように実装すべきか指針を示したりするので大変です。
メンバーの際は、特定の事象について深くしっかり調べて仕事を進める形だったので、それとは脳の使っている部分がだいぶ違うイメージです。
脳の切り替えが必要ということは、分業したい傾向はあるが、しっかり分業できてないということだと思っています。
とは言え、チームリーダは切り替えが必要な場面は多いんだろうなとは思っています。
終わりに
そんなところですが、2022年も頑張っていきたいです。
