久しぶりにゆっくり休む期間をもらってる。
いい機会なので振り返ってみる
テックリードというロールとの向き合い
社内でも初めてのテックリードって試みでもあって、僕自身もこれまで テックリード
って職種の人を見た事が無かった。
「ロールモデルはこういう人」というのを描くのが難しかったので、自分はこういう事をしていきたいってのをブログとして書いてみた。
当時のチーム状況として CTOのロールの方が会社から抜けてチームの中からプレイヤーの自分がテックリードとして抜擢される
という状態だったので、CTOがやってた事から僕がやらない事を引いて ロールモデルと置くみたいな事で走ってみる事にした。
振り返り
ブログでは以下の4つの行動指針を考えていた。
- チームのメンバーが最大限に力を発揮出来るようにする
- メンバーの意見に傾聴しつつチームとしての意思決定を行う
- チャレンジが失敗した場合は自分がフォローをする
- チームメンバー一人一人の「人となり」を知る
総括というよりかはまずは一個一個について考えてみようと思う
チームのメンバーが最大限に力を発揮出来るようにする
割とここが一番手厚くやってきた部分だったりしたと感じている。 元のブログでは、更に詳細に コードレビューからプロダクトの水準を担保する努力をする
・ 困ってる運用フローを技術で解決する
という2本の柱を掲げてた。 まあ 良い所、反省すべき所 があったな、という感じ。
良い所
まず良い所としては チームで発生したバグに対して、技術で解決する手立てを取った事だろうと思う。 例えば先日ブログを書いた以下の対応。
当時は結構な頻度で粒度の大きいリリースがされており、リリース後にデータが不正に作られるようなバグが出る事が度々あった。
バグが出る事はしょうがない事とは思っているけど、バグを出した人は結構責任を感じていているようだったし、チーム内でも 「どうにかしないとね」 みたいな空気があったのを感じ取っていた。
そこで、リリース後にデータが不正かどうかをチェックして確認するみたいな仕組みをMackerelで作り、デプロイ後に何かあった時は速やかにアクションが出来るような監視の仕組みと、かつ 一先ずこのアラートがならないなら多少は安心しても良いのではというチームからストレスを減らす取り組みをした。
(他にも一応バグ出した所を書いてたエンジニアの人と1on1したりだとか、テスト項目みたいなのを社内共有ドキュメントのesa に残してチームの共有知とする、みたいな事はやったけど、まあその辺は技術ではないので割愛 )
一旦、今はうまく動いてるなという気持ちがしている。
反省すべき点
大きく2点あるな、と思っていて。
性格の問題でもあると思うけど、先程のバグが発生した時に必要以上に自責の念を感じ過ぎてしまった事とかがある。 それを開発チームの朝会の場でチームに伝えた事も含めて。
「リリースが少し億劫になる」 みたいな感覚がチームに芽生えた感があった。僕の反省含めてこういうのはチームに伝搬していくんだな、ってのが学びとしてあったし あまり良くない文化が生まれてしまった。 僕自身が「バグは出るもので仕方ないもの。 起こってしまった事はしょうがないので再発防止策を考えていこう」 という起こった事に固執しない文化を積極的に作り出す必要があったと思うし、そこがまず反省点。
これまでは 1人のプレイヤーの発言だったものがチームのリーダーの発言になるというのは絶えず意識しないといけないと痛感した。
もう一点は上記にも繋がるが、それによって今まで以上にレビューに力を入れ過ぎるようになった事だったりする。
コード品質を預かる身としてもっと注意深くみないとやばいって結構強く思ってそれを行動に移した。全てのPRに目を通さないとっていう気持ちになっていたし、積極的にレビューをしていた。 その結果、元々チームに中々定着しなかったコードレビューの文化が更に鈍化したし、自分自身 日中はタスクが全く進まなくて、夜間子供を寝かしつけた後にコードを書くみたいな長時間労働の問題が出てしまった。
現状はチームの方の提案によりコードレビューが当番化されるなどして、半ば強制的にレビュー文化を定着させる試みがされていて、好転し始めているのでウォッチしていきたい。
結果自分がコードレビューを頑張りまくった事で好転した事ってそんなに無いと思うので、ある種自分にそこまで期待をしないっての大事かな、って感じている。
メンバーの意見に傾聴しつつチームとしての意思決定を行う
ここはあまりうまくいってない感があるなー。。って感じがする。
元々、自分が決断するのが苦手だから積極的にチームの人を頼って、議論しつつチームとしての意思決定をしようという行動指針だった。
最初の方は多少の実践は出来てたけど、議論の反論(?) というか意志をより深堀りして質問されていった時に割と答え切れずにグダグダする、って場面が散見された。
その対策として、ミーティングまでにめちゃくちゃ考えて結論出してくるみたいな事をやって、アジェンダで 結論と考えを書ききって提出するみたいな事が増えた。その結果として、議論の方向性が 「自分が提出した案でやって良いか or 悪いか」 みたいな所からスタートするようになって、「良さそう」 で結論着く事が多かった。
それもチームとしての意思決定を言えばそうだけど。。「バックボーンが自分に偏る」 とか諸々含めて「声でかい人の意見が反映されてるだけ」という問題が無いか?という課題が残ってると思う。
チャレンジが失敗した場合は自分がフォローをする
ここは、出来たか?というと出来た。 障害対応時はissueを書くフローがあるが、大体僕の名前がある。 まあ、成功か?と言われると非常に怪しいゾーンだなと認識している。
まあ、一般的には、チームがスケールする為には 当然ここは僕が居なくても回るようにすべきってのはあるかと思っています。次の行動指針からまだ僕は当分ここからは外れないかなと思って一旦これはフルコミットしていこうと思いました。 まあ、最終目的としてはしたいですね。
割とやりすぎてて チームの成長機会を奪ってるのでは、という迷いがずっとある。 ・・・とはいえ、僕が障害対応入らない選択肢も無いしな、って思ってる部分もあるので手を動かしてもらう部分とかは委譲しつつ また向き合っていこうな、という段階。
チームメンバー一人一人の「人となり」を知る
これは、まあ一番思ってたのと違うみたいな状態で、先々月ぐらいからチームのメンバーと月1で1on1を始めた。
こんな口下手な僕が1on1を・・って思うのは結構不安要素が大分大きかった。 不安要素をなるべく取り除くために予めテンプレートを用意しておいたりして聞きたい事を聞いて話を引き出しつつみたいな進め方をするようにしてみた。
「やってもらってよかった」と言われる事もあるのでまあそれなりに出来てる方なのかな? という自己評価はしている。
1on1自体は1日に3人〜4人と各1時間ずつやるので非常にエネルギーを使うものも自分も得るものが多いのでこれも継続していくべきだな、って気持ち。
今後のやる事
これまでは、「手を動かしたものだけが世界を変える」ってのを凄く共感して生きてきた。なので問題点は割とハードワークして解決してきたけど、プレイヤーの頃はそれで会社として良い影響が与えられる事もあったんだけど、もう少し自分がマネージャーロール寄りの位置にいる事を自覚して仕事をしていくべきだな、というのを感じる。 適切に委譲をしたり、オーバーワークになりそうならその現状を受け入れて別の何かを諦めるという選択が必要なんだろう。
とはいえ、何か問題にぶち当たった時に解決する為のHowを持ってないって所がいっぱいあってキツいって感じる事が多い。先人に学ぶというか、本とかを見ながら テンプレートを当てはめてみてアップデートしていくみたいなのが必要なんだろうな、って思う。
全然、本とか知らないんだけど、まずはおすすめしてもらったこういうのから読んでみようかな、と。
- 作者:James O. Coplien,Neil B. Harriosn
- 発売日: 2013/08/23
- メディア: Kindle版
- 作者:JonathanRasmusson,西村直人,角谷信太郎
- 発売日: 2017/07/14
- メディア: Kindle版
ぼやき
理論としては分かるけど 「俺マネージャーだからコード書く時間減らすんだ」みたいな割り切りはぶっちゃけ急激なモチベーション低下を招くのでしっかりプライベートをコード書く時間にあてたいな、という気持ちです