オミカレのテックリードになりました

退職...そして独立へ...... - そーだいなるらくがき帳 にある通り、そーだいさんが 副社長兼CTOから退職される事に伴いまして、この度 2月1日付けで オミカレの テックリード となりました。

僕とオミカレ

www.ikkitang1211.site

www.ikkitang1211.site

※ ちなみに 現職エントリ書いてる頃はそーだいさんの退職を知りません。

2018年05月01日付 で入社して 今で約2年弱在籍している事になります。

前職で疲弊してた所をそーだいさんに話しかけて頂き、 『少なくとも今よりは成長、給料、正しい業務時間、全部用意するよ。』 との事で人生初の転職を行い、今に至ります。

転職してすぐの頃は元々仕事の遅れは残業でカバーする文化にいた事もあり、考えられる中の最短の期間で見積もりして スケジュールに間に合わないようなら パワープレイで残業したりリスケしてもらったりなどしており。。。(白目) 1on1の時とか 普通に就業中に Slackの分報チャンネルで怒られるなどを毎週のようにしていました。。(汗)

前期・後期 を通した頃には大体仕事のやり方も覚えて来たり、文化にマッチしてきたりと 1on1 で褒められる事が多くなって来ました。


そしてこの度 そーだいさんの退職を機に そーだいさんのCTOの仕事における 技術の部分を自分が引き継ぐ事となりました。 技術の部分を と書いたのは 実はそれ以外のリソースのマネジメントの部分だったりとかは他の方に引き継がれたりしている為です。

僕の中ではいわゆる 三本の矢 っぽいよなぁ。と思っていて。今までは中心にそーだいさんが居たけれど、これからは逆に各個とのコミュニケーションを取るなどある種民主的なチームというか、束になってチームの運用をしていかないといけないのでは、と思っています。(そーだいさんの一本が容易に折れるか?は諸説ある)

kotobank.jp

逆に言うと 3本束にならないと敵わないくらい、そーだいさんは影響力のある人であったな、と本当に思いますし、この二年間は 本当にそーだいさんの 『少なくとも今よりは成長、給料、正しい業務時間、全部用意するよ。』 という言葉をそのまま受け取れた期間だったな、と思います。

そういえば、そーだいさんからポジションの引継を受けるのは実は二度目で前回は JPUGの中国支部長の時も今ではつい最近みたいですね。

自分が描くテックリード像

そもそも論だけど、自分自身、生まれてこの方 ずっと「プレイヤー」だったので 「マネジメント」 という職種を経験した事がありません。 厳密には 「マネジメント」という仕事で得られた成功体験ってのが無いです。

前職でプレイングマネージャー、ってのを数ヶ月やった事があるものの・・あれは酷くて思い出すだけで恥ずかしいし、チームのメンバーにめちゃくちゃ迷惑を掛けた反省しかありません。。

そんな事もありこの1ヶ月ぐらい、「テックリードって何なんだ? マネジメントってどうやって向き合えばいいんだ?」ってのをずっと悩んでいます。布団に入って2時間悩むみたいな日々を過ごしています。

ripple.ikkitang1211.site

「悩み」ってのは 答えが出ない って前提で 考えるフリをする事

とある通り、答えを出そうとしてなかったなってのが本当に反省点ですね。

考える為の一歩として 一先ず、色んな文献を読んでみました。 そんな中で共感したりだとか これは確かに僕の仕事だなってのが多少浮き彫りになってきたように思います。

僕は割と行動で示しちゃうタイプで自分の気持ちを言語で表すのって言葉が出てこなくて非常に苦手なのですが、明確なビジョンを自分の中に持つことを目的にしっかり言語化する事をしていくのも僕の仕事だ、いう事で書いてみたいと思います。

テックリードが担うマネジメント領域

僕がやるべきであるマネジメント領域というのは次の2軸になると思っています。

  • タスクマネジメント
  • チームマネジメント(ヒューマンマネジメント)

領域は決めたもののまだ大きいのでその領域で自分に出来そうな所として上記の領域から深堀りして大きく以下の4つの行動指針を考えてみました。

  • チームのメンバーが最大限に力を発揮出来るようにする
  • メンバーの意見に傾聴しつつチームとしての意思決定を行う
  • チャレンジが失敗した場合は自分がフォローをする
  • チームメンバー一人一人の「人となり」を知る

これは僕の今の気持ちなのでこういうビジョンは数ヶ月サイクルでアップデートされていくものだとは思いますが、今はこんな感じで置きます。

チームのメンバーが最大限に力を発揮出来るようにする

これはまあ当然の責務ではあると思います。だけど、少し目的が大きいです。 「何をすればチームのメンバーの仕事は最大化されるのか」

そこで より深堀って 以下の事で チームのメンバーの効率化を図っていくとしました。

  • 自社サービスへの豊富なドメイン知識を持って適切なコードレビューを行う事でプロダクトの水準を担保する努力をする(継続的にバリューが出せる為の工夫)
  • 困ってる運用フローを技術で解決する

少し、それぞれについてフォーカスしてみます。

自社サービスへの豊富なドメイン知識を持って適切なコードレビューを行う事でプロダクトの水準を担保する努力をする

弊社は軸となるWebサービスに加えて アプリ、及びその他付随のサービスと (僕の職歴的に)多くのレポジトリが運用されてる状態です。 幸いJOIN時期が良かった事もあって(そもそもそういう目的だったからこそ採用されたってのもありますが)、自分は自社サービスにのドメイン知識に長けてる、と思います。

これは 僕がそこに対して一番向き合ってきた(障害対応とか含めて)って自信があるってのが大きいとは思いますが、自社で作った スキルマップでも他の方の現状を見ると傾向的にそこは自分が エース となる領域なのかなと感じています。

www.ryuzee.com

テックリードとして最も大切な仕事として僕はこのドメイン知識はしっかり伝えていく必要があると思っていて、メンバーに長期的なバリューを出してもらう為にも コードレビューの機会は大切に、適切なフィードバックや 共有をしていく、という行動をしていきます。

勿論、社内のドメイン要素だけではなくて 一般的なプログラミングの話においても日々研鑽を積んで適切にフィードバックしていく必要があるのはそうだと思います。

困ってる運用フローを技術で解決する

これは日々の仕事の効率化を行って生産性を上げていくもの、と思っています。 主にルーチンワークとなってる運用についてそれを技術で解決していきます。

これはプレイヤーの時からやってきたもので、この部分のコミットは今後も僕の強みとして継続していきたい所です。

例えば これの 59 スライド目。

speakerdeck.com

レビューがやりづらい と思っていたので Slack のbotで review と叩くと 今のレビュー待ちのPRを連携してくれるように改善を行いました。

結果、レビューは以前に増して活発になり、レビューに携わって来なかった人たちもレビューに参加してくれるようになるなど、普段使ってるSlackというツールが少し便利になりました。

エンジニア全体の効率化が出来たと思いますし、今後もそういう行動を続けていきたいです。

メンバーの意見に傾聴しつつチームとしての意思決定を行う

ここはチームマネジメントの部類。

僕は割と甘めに物事を捉える悪い癖があります。。というか「失敗から学ぶ」を地で行きがちです。(誰に似たんだ。。) また 決断する事 に苦手意識があり 物事の決断がとても遅いです。 (どれぐらい遅いかっていうと、このブログを書いて公開して良いかってのを判断するのに 5日間かけてしまった。)

その悪い癖を認識して苦手な部分はチームのメンバーを頼っていく必要があってコミュニケーションを取りつつ克服していく必要があるなって思っています。割とそーだいさんの時はそーだいさんの決断に対するコミットメントが高かったのでここがチームにとっての大きなギャップになるんじゃないかな、って思います。(別にそーだいさんが傾聴してくれなかったとかでは無い) だけど、チームの一員として自分の中の問題解決の手札を増やしていく努力はしていくべきだと思いますし、していこうと思います。

上にも書いたようにテックリードの独断ではなくて 束となったチームとしての決断が出来るように、まずはメンバーを信頼してメンバーの意見を聞いていきたいな、と思います。

チャレンジが失敗した場合は自分がフォローをする

上にも書いたように、決断はチームとしては行うもののその判断には自分が責任を持つ必要があるなと思います。

これは弊社で例をあげると具体的に障害対応の文脈の時ですね。

僕は今までプレイヤーとしてやってきた事ではありますが、これまでは そーだいさんが司令塔の部分を担ってくれていました。今後は、障害対応の際は自分がまず第一線に立って司令塔となって行動していきます。

障害対応の時には迅速でかつ冷静に復旧を目指していくような行動をするべきだなと思いますし、障害復旧後は今後のチームの学びとなるように 「今後どうするか」についても共有をするような行動をしていきます。

まあ、一般的には、チームがスケールする為には 当然ここは僕が居なくても回るようにすべきってのはあるかと思っています。次の行動指針からまだ僕は当分ここからは外れないかなと思って一旦これはフルコミットしていこうと思いました。 まあ、最終目的としてはしたいですね。

チームメンバー一人一人の「人となり」を知る

これはチームマネジメントのフィールドの話であり、より厳密にいうとヒューマンマネジメントの部類の仕事。

僕はメンバーについて そーだいさんを通したメンバーしか知りません。 プレイヤーとしての信頼はあるかもしれないけど 役職のテックリードというのが付いてしまうとまた話が別だと思います。今後僕はゼロからチームメンバーとの信頼関係を作っていく必要があって一番リソースを割くべき所かなって思っています。 特に行動指針の 困ってる運用フローメンバーの意見を聞く などは信頼関係が無いと把握出来なかったり思ったことが言えないみたいな事が起こりうると思います。

1on1...とまでいってしまうと 僕はどうしても身構えてしまい緊張してしまうので...そこまではいけないけど トークテーマを絞った上でカジュアルに話をする機会を自分から作っていきたいなと思っているし、弊社で行っている朝会を上手く活用して「褒める」事で小さいコミュニケーションを日頃から心がけて行動していきます。


といった感じで一先ず 自分がしてきた事 の視座を上げてみて、テックリードとしての仕事に取り組んでいこうっていう所存です。

「じゃあ、君はどんなDevチームにしていきたいの?」って所は僕はまだもやもやしていて、そんな状態でこのエントリを公開しても良いのか?と思いつつもそれは一旦別のエントリとしてどんなチームにしたいか、ってのを書こうかなと思います。

まとめ

まあ、こうやって書いてみたけれども、現状マネジメント1年生。 そもそも仕事のやり方が分かりません。。 仕事は失敗して学んできたのですが、マネジメントって失敗して良いんですかね。。。(´・ω・`) などなど不安もとっても多いです。

チームやチームメンバーは生き物なので 大小様々な問題は日々起こっているなと感じているし、そこにコミットしないと。。!という焦りも正直あります。

www.firstlogic.co.jp

そんな時こそ、 「愚者は経験に学び、賢者は歴史に学ぶ」 という言葉をキモに命じて 先人達の マネジメントの仕事の仕方の本を読んでまずは自分の手札を増やしたり、 またはコミュニティの人に 「食事代は僕が出すので相談乗ってください」みたいな 何かチャンス的な奴だったり結局僕が出来るのって 行動して泥臭く取り入れていく事なのかな、とも思います。

テックリードとして始まって 2週間。 まだ何も成果は出せてないかもしれませんが 焦らず周りの人と問題意識を共有しながら 成長していこうと 思います。

高橋くんのテックリードキャリアはここからだ、という事で長文になりましたが終わります。