テックリードという役割を半年やって気づいた「伝え続ける」ことの重要性

ソフトウェアエンジニアとして働き始めて数年、今年から初めてテックリードとしてチームを持ち、プロジェクトを進めてきました。

半年ほどが経ったので振り返りと気づいたことについて書いておこうと思います。

チームの大半を経験1、2年ほどの若手や最近入ってきた人が占めているようなチーム構成であったり、兼任でチームマネージャーのような役割もやっているので、一般的なテックリードとは少し違うようなところもありますが、テックリードの役割として期待される「技術選定・アーキテクチャ設計」「システム品質の担保」「チームの生産性の向上」について次のようなことを意識してきました。

「技術選定・アーキテクチャ設計」の際に意識していたこと

・プロジェクトのゴールに沿った技術・アーキテクチャを選定すること
・持続的に開発可能で、筋の悪くなさそうなものを選ぶこと
・アーキテクチャは理想に拘りすぎず、チームの状況を鑑みて現実的な最善解を落とし所にすること
・「なぜ」それに決めたか、「どう」実装に落としていくのかをドキュメントにできるレベルまで落とし込むこと

「システム品質の担保」のために意識的に行なっていたこと

・事前にアーキテクチャ設計を行い、それに沿って実装できるようにしておくこと
・実装前に仕様や実装方針などの擦り合わせを行うこと
・コードレビューで品質を高めること
・事前に危なそうな部分やハマりそうな部分を把握しておくこと

「生産性の向上」のために意識的に行なっていたこと

・アーキテクチャや方針を決め、掲げること
・事前に躓きそうな部分を把握しておくこと
・仕様の確認・調整などを実装途中にする必要がないように事前に対応しておくこと
・1つのタスクに集中できるように進め方を工夫すること
・「待ち」が発生しないようにすること

「伝え続ける」ことの重要性

半年間テックリードをやってきて、上記の3つに対して意識していたことは概ね間違っていなかったかなと思っています。きちんと実行できていたかについては反省すべき点ももちろん多々ありますが、メンバーの尽力のおかげでプロジェクトは順調に進めることができています。

ですが、見落としていたなと反省していることもあります。それは「伝え続ける」ことの重要性です。

プロジェクトの開始から数ヶ月が経ち、実装も進み軌道に乗ってきたなという頃に新しいメンバーが加入してくる機会がありました。

この時に既存のメンバーに新メンバーへのアーキテクチャの説明をお願いすると、「アーキテクチャ上のとあるコンポーネントがどういう役割を持っていてるのか・何のためにあるのかをうまく説明できない」ということが起きました。

PRなどコード上ではアーキテクチャに則った良い実装ができているように見える、つまり「どうやって実装するべきか」は理解してくれているものの、「なぜそうするのか」といった根本的なところを自分が伝えきれていなかったのだなと気づかされました。

振り返ってみると、初期にアーキテクチャを設計してドキュメント化し、メンバーに数回説明をしたっきりで、（実践を経てメンバーと一緒に多少手を加えるようなことはあったものの）意識的に「なぜ」を伝え続けるということはできていませんでした。普通に考えると、他人の考えたアーキテクチャを数回の説明を聞いただけで正しく漏れなく理解することなんてできないですよね。

対して「どう実装するべきか」はなぜ理解してもらえていたのか？についてはコードレビューなどで何度も繰り返し伝える機会があったのできちんと理解してもらえていたのだろうと思っていて、メンバーにヒアリングをしても同じような答えが返ってきました。

今のところ、あまり問題として表面化していませんが「会社・サービス・プロダクト全体の中でのプロジェクトの立ち位置」であったり、「プロジェクトのゴール」や「プロジェクト全体の進め方」、「メンバーに期待する将来的な役割」などについても繰り返し語り続けなければいけないなと感じています。

少し話が脇にそれますが、「採用基準」という本でも

リーダーがなすべきことは①目標を掲げる、②先頭を走る、③決める、④伝える、の四つに収束します。
(中略)
逆に言えば、決断をしない人はリーダーではありません。伝える努力をしない人も、先頭を走る覚悟のない人も、成果目標を掲げて見せてくれない人もリーダーとは言えないということです。
(中略)
目標を掲げ、先頭に立って進み、行く道の要所要所で決断を下し、常にメンバーに語り続ける、これがリーダーに求められている四つのタスクなのです。

引用: 伊賀 泰代. 採用基準

と「伝える」ことの重要性が説かれています。ちょうど「うまく説明できない」ことが起きた直後くらいにこの本を読んでいたので、「まさしくその通りです…」と反省して自分の「リーダー」への認識を改めました。

採用基準

「伝え続ける」ことを怠ることで起きる問題

プロジェクトチームは外から見ると、以下のような状態になっており、チームの大半を経験1、2年ほどの若手や最近入ってきた人が占めているチーム構成を考えると上手く進んでいるように見えるのかなと思います。

・アーキテクチャに沿ったある程度品質の高い実装ができている
・ある程度スムーズにプロジェクトが進行している

ですが、軽視とまでは言わないものの、「伝え続けること」「語り続けること」を意識して行ってこなかったことで実際はこのような状態なのかなという風に感じています。

・「テックリードがいる間は」アーキテクチャに沿ったある程度品質の高い実装ができている
・「テックリードがいる間は」ある程度スムーズにプロジェクトが進行している

括弧書きを加えるだけで見るからにダメな状態ですが、大きく3点問題があると思っています。

① テックリードの能力的な限界 ≒ プロジェクトチームの能力的な限界になってしまう
② メンバーの自発的な成長を阻害してしまう恐れがある
③ テックリードの属人化が起きる

全てそれぞれがリンクした問題ですが、自分の中で一番大きな問題だと捉えているのが②です。

大半が若手で構成されているチーム構成上、伸び盛りのメンバーの成長を阻害してしまってはそのメンバーに対して悪影響があるだけでなく後々、今のチーム・プロジェクト・プロダクト・会社ひいてはエンドユーザにまで悪影響が及んでしまいます。

「伝え続ける」取り組み

ここまで「伝え続ける」ことの重要性と、軽視した際の問題点について自分の気づきを書いてきましたが、「気づいたのはつい昨日」のような話ではないので、どうやって「伝え続ける」ことに取り組んでいるのかを書いて締めようと思います。

気づく前に実施していた主な取り組みは下記のようなものです。

・実装前に仕様・方針の擦り合わせを行う
・PRでのコードレビューを行う
・週次の技術共有/相談会を行う

気づいてから追加で実施するようにしたこととしては以下のようなものがあります。

・実装前に仕様・方針の擦り合わせをしてから、ある程度のところまでペアプロを行う
・(ほぼ)毎日モブプロを行う
・コードレビューを対面で行う頻度を増やす
・1 on 1などでメンバーに期待していることを伝える
・日々のミーティングでプロジェクトのゴールや進め方を意識的に何度も伝える

「伝える」頻度と濃度を高めることを重視して取り組んでいます。

特に効果があるなと感じているのがモブプロで、機能実装を行うこともありますし、リファクタリングをしたりテストコードを書いたりもします。

モブプロを始めるに当たって、自分もやったことがなかったので、「モブプログラミング・ベストプラクティス」という本を購入し、どうやって進めるのか？や参加する全員が何を意識して取り組むべきか？、何のためにモブプロをするのか？という点を言語化するために参考にしました。

モブプログラミング・ベストプラクティス ソフトウェアの品質と生産性をチームで高める

モブプロをやってみると、テックリードだけでなくメンバー全員が「なぜこう実装するのか」や「どうやって実装するのか」を説明・理解する機会や、「他に良い方法はないのか」と議論する機会が段違いに増えることに気づきました。また、フィードバックがリアルタイムに行われるのも良いところです。コードレビューでのコメントでは伝えきることができない部分などについても、実際にコードを書きながら伝えたり質問に答えながら進めることができるため、納得感が強いようです。また、コードレビューと違い「どういう思考を辿って開発を進めていくのか」のようなソフトスキル的なところを伝えられるのも良い点だと考えています。

モブプロももちろんメリットばかりではなく、「短期的な生産性は低くなりがち」のようなデメリットもあるなと感じているので状況とバランスを見ながら無理のない範囲で積極的に進めています。

まとめというか感想

半年やってきましたが、自分の中では可もなく不可も無くという成果しか出せてないなーという風に思っています。ただ、少なくとも不可にならなかったのは今までの経験が活かせているからなのだとも思うのでその点に関しては良かったのかもしれないです。

もっと自分自身成長しないといけないですね。

反省を踏まえて色々書いてきましたが、また半年後くらいにどうなったのかとかを書ければ良いなと思います。

もし内容良かったら、スキを押しておいていただけると次を書く糧になるので嬉しいです。