bon now

突然だが僕の最近を紹介しよう。

最近の僕はエンジニアではなく、マネジャーの仕事をもっぱら中心としている。 マネジャーといっても小さなチームのリーダーをやっているだけで、基本は兼務みたいなものだ。 でも僕は自他ともに認めるコピペエンジニアなので、別に最高にプログラミングが好きなわけではない。 なので、実際のところあんまりモチベーションを保てない、ということでもなくそれなりにやりがいを感じている状況だ。

ただし、システム開発においてはそうではなく、若干ナーバスになってる面もある。 特に最近は技術的な嗜好を凝らしてトリッキーもとい複雑かつオブジェクティブなソリューションに対して、 理解が追いつかないため懐疑的になっている。 この現象は僕が年を取ったとかプログラミングに対した情熱が湧かなくなったとかいう事象も含まれているんだろうけど、 一番の影響はチーム全体のシステム品質やスキルの追従などにどんどん差が出てきてしまっていることだ。 それが結果的に自分の仕事の範囲、責任を持たなければならない範囲を侵害してきていることに不安を感じている。

なぜこんな話をするかというと、以下の記事を読んだためである。

プロダクトマネージャーの3分類 - Yamotty Blog
テックリードはオワコンなのになぜジャップは今頃？ -はてな匿名ダイアリー

僕の今感じている悩みに対して一番腑に落ちることは、結局テックリードというか、技術で牽引するとは言え、 それがチーム全体の幸福につながるのだということを啓蒙できるかどうかが重要なのだということだ。

個人的に僕は功利主義な考え方を持っているので、全体幸福がまず第一に確保されるべきだと思うし、 そうでなければチームとして機能しないと思っている。 で、その点において不幸な少数派が生まれるのであれば、それは権限や役割としてそこを救済する部分を用意すべきだとも思う。

例えば上述したブログでも言われているとおり、抜きん出た技術を扱う場面においても、 それはチーム全体のシステム品質やアーキテクトレベルでの保守性、堅牢さにつながっていくことが望まれるわけで、 裏を返せば新しくチームに入ってきた誰かにとっても、それが「すごいね、最高だね」と言えるほどの確固たる事実がなければならないということだ。 おそらくそれはドキュメントやアーキテクト図、あるいは業務における設計・コーディング・テストなどの作業から伝わる抽象的な何かが存在しているはずであり、 どえらい改修量のプルリクやブランチ、Githubリポジトリに申し訳程度に書かれたREADMEとかいうレベルじゃないはずである。 そうならないようにするには、そのような仕組みも業務の範囲もしくは評価の範囲として組み込むことが必然だし、 そうであることを他社がすでに証明している。であれば、倣うは必然である。 では、それを誰がやるのかという話になるけど、 それについては先の通りそれを専門的に実践する役割の人材を配置すればいい。それが組織全体の評価や目標に合致すれば何ら問題もない。

以上より、組織全体の在り方にそもそもブレがある場合は、やっぱりテックリードという枠は要らないんじゃないかと僕も思う。 だってそれは、暴走する特定個人に対して、技術的に劣っているがためになすがまま、なされるがまま流されていく多くのエンジニアが、 将来に渡って難解なパズルを紐解いていくという作業を繰り返しながら、気づけばまた新しい難易度の高いゲームが用意されている状況が続くことになるからだ。 全員がそこにモチベーションとやりがいを感じて取り組んでくれたら良いだろうけど、それで最良のパフォーマンスを生み出せるとは到底思えない。 (もしいずれ最高になるとしても成長曲線としてはかなり鈍化だと思う)

まとめると、チームを１つの単位と考えた場合、そのチームのパフォーマンスを最大限に発揮させるには、 正しい評価制度と権限・役割の割当、および全体的な目的の統一が必要ということ。 そして、それをチームに共有し、１つの目標・指標として全員で考えあるべき姿を模索していくことが重要だということだ。 もちろんそれが最初からばっちり完璧に運用できるわけはないと思う。 だからこそチームを単位として１つ１つの課題をチームが考え、チームで改善に取り組む姿勢が大切なのだ。