このブログははてなブログからの移行記事です。
2021/8/16入社だったので1年とちょっと、経ってました。
この期間、個人として新たにチャレンジさせてもらいたくさんの成功と失敗から色々学んだので思い出せる範囲でざっくばらんに記録しておこうと思います。
書きながら、これはうまくまとまらんというか別記事に切り出したいと思うものもたくさんあったのでそういうものは別記事でコツコツまとめていこうかなと思ってます。
あと私自身、結果はどうあれたくさん頑張ったなぁと思って書き始めた記事ではあったんですがやっぱりチームメンバーにもめちゃくちゃ恵まれてたよなという気持ちもあり巧妙なチームメンバーへの感謝記事になった感もあります。10Xいい会社デスヨ。
サマリ
- Software Engineerとして入社して機能開発をコツコツやった
- 色々あってTeam Leader兼Managerになった
- 優秀なメンバーの大いなる成果のもと、走れるチームになってきた
- 家庭の事情でお休みに入るため、Managerからメンバーに戻った
という感じの1年とちょっとでした。
Software Engineerとして入社した
入社の経緯やモチベーションは過去に書いた通りなんですが、入社時の私から会社への期待値を一言で言うと「自身が体験したことのない体制や雰囲気の中でゴリゴリ開発を進めていく」という環境でした。
入社してからの実態としては期待と概ね同じ、もしくはそれ以上で各々が各々でひたすらIssueを解きままくる侍スタイルな環境で、気持ちとしては一刻も早く成果を出さねば…！という気持ちで最初の最初の2、3ヶ月は過ごしてました。
自分は性格上、自分自身にプレッシャーを過度にかける傾向があるので特に入社してからの一定期間は不安が強かったんですが、10Xメンバーが積極的に私自身の良いポイントと改善していくべきポイントを大人なコミュニケーションで伝えてくれたので心理的安全性が高かったなぁと思います。
また、各メンバーが会社のClutureやValueを強く体現しているので自分がそれに染まれるスピードも早くて、このサイクルは維持していきたいなという気持ちです(こういうのは何も手を打たないと基本的には採用の加速やメンバー増加に比例して薄まっていってしまうと思う)。
本当にダイジョウブカナーと思っていたDart/Flutter開発に関しても言語自体の敷居もそこまで高くないことと、サンプルコードが山ほど社内にあるのでそこまでつまづかずにキャッチアップできたかなと思います。Flutterに関してはWeb Frontendをやっていたのがかなり良かったなーという所感だったのと公式ドキュメントをなぞれば3, 4日くらいで完全に理解した状態になれると思います。
いろいろあってLeader兼Mangerになった
2021/08 - 2021/12までの間は1人のSoftware Engineerとしてゴリゴリ働いてましたが、2022/01からは組織が新しい体制に移行し、Platform Development TeamというチームのLeader兼Managerにアサインされました。
組織変更の経緯は弊CEOの下記記事がわかりやすいです。
アサインされた理由は結構シンプルで当時、システムの守備面周りでやいやいうるさく言っていて、じゃあLeadershipを持って色々進めてくれ！という感じかなと思ってます。Tech Leadの経験はありましたが、組織によってLeaderに求められる役割は変わっていくし、Managerは初だったので抵抗が無いわけではなかったですが任されたらやる気を出してしまう単純な性格ではあるのでちょっと頑張ってみるか！という気持ちで引き受けました。
僕が思う10Xの良さであり、大好きな文化の1つとして「抽象度の高いIssueをメンバー、チームに降ろしていく」スタイルがあります(この辺り、いつか 言語化.fmで話します)。
この時も例に漏れず、「開発・運用基盤を整えることを目指すチームを組成する」という壮大なミッションと解決すべき具体的なIssueのいくつかがチームに託されました。
最初の3ヶ月(2022/1~3)
チームミッションとIssueの整理
まずはチームに託された「開発・運用基盤を整えることを目指す」とはどういうことなのか。ミッションとIssueの整理から取り掛かりました。
壮大に見えたこのミッションですが、当時Stailerの機能開発・運用保守を進めていくにあたって既に発生していたIssueを解決する手段として一番抽象度の高い表現が「開発・運用基盤を整える」だった、という整理を私の脳内ではしています。
じゃあ具体的に発生しているIssue、これから発生するIssueってなんだっけ？を整理していくと以下のような感じでした。
- 既に発生していたIssue
- これから確実に発生するIssue
- システムの成長に合わせてエンジニアリング組織も成長する必要があり、それを見据えたアーキテクチャやインフラ、リリースから運用、監視までの設計をしていかなければいけない
- セキュリティ面の要求がより高まり、内部ガバナンスの強化やプロダクト自体のセキュリティレベルの向上およびそれを実現するための体制構築が必要になる
Leaderとして最初に取り組んだ仕事は、チームメンバーと協調しこれらのIssueをどういう形で打ち返していくのか。このような類のIssueを継続的に解いていくチームに求められるミッションとは、を定義していくことでした。
チーム体制の検討
これらのIssueを並べた時、それを解くために求められるスキルセットや進め方の最大公約数は少なく専門性が必要だと感じました。
そこで当時のチームではサブチームという形で専門性を切り口にチームを3つに縦割りし、各サブチームごとに独立しながら動く体制を構築しました。
具体的なサブチームは以下の3つです。
- Reliablityチーム
- いわゆるSREチーム
- Securityチーム
- いわゆるセキュリティチーム
- 参考: 10X セキュリティチームが立ち上がってから半年以上経過しました - 10X Product Blog
- Development Processチーム
- 開発の生産性と品質のトレードオフを調整しながら両方の改善を目指していくチーム
この体制で走ってみてどうだったか。結論から言うとこのサブチーム体制はある程度、意図した通りに作用した側面があったかなと思っています。チームを割って意思決定の人数を減らすことで各サブチームの動きは相対的には素早く動けていたと思います。
一方で以下のIssueも顕在化しました。
- 各チーム、未来に向けた取り組み以外のタスクに多くの時間を取られていた
- 過去に積んできた負債改善、チーム体制変更に実態が追いついていないことによる兼務の常態化、チーム変更の過渡期ゆえの割り込みタスクの多発が主な原因でした
- Development Processチームの取り組みはAs Platformではなく、機能開発チームの一部として実装されるべき役割であることがわかってきた
- このサブチームが具体的に取り組んでいたのは開発サイクルの改善(仕様を作ってからリリースされるまでのプロセス改善)が主でした
- この取り組みは一部はPlatform Team的な立ち回りが最適ではあったものの、いくつかは実際に機能開発チームに所属し、内側から改善していく方が良い取り組みもありました
また、自分のチームだけではなく組織全体としてもチームの切り方や責務の配置が最適ではないというIssueがありました。
これに対し、次のQではチーム体制の刷新、メンバーの再配置を行うことになりました(後述します)。
初めての評価
私はLeaderであるとともにManagerでもあったので、人事評価も担うべき責任の1つでした。
それまでの10Xでのエンジニアの評価はCTOが全て担っていました。この状態では評価者が1人のため、評価者ごとに評価基準の解釈がずれて社内で評価の整合性がずれるということは起きづらいです。そのため、評価基準は良くも悪くも精緻に言語化する必要がない状態でした。
この背景を踏まえると私含めた当時のManagerの評価における重要なミッションの1つは「会社の評価制度を踏まえて、どのように評価を行っていったのかCTOの脳内を開示し、言語化し、エンジニアリング組織として整合性を担保した適切な評価を行う」ことでした。
これが上手くいったのかどうか、どれだけ上手くいったかはここでは語りませんが(聞きたかったらご飯誘ってね)、少なくとも最適な成果を上げることはできておらず、エンジニアリング組織としていくつかのIssueが浮き彫りになったタイミングだったと捉えています。
- 組織の拡大、事業の成長に評価制度のアップデートが追いついていない
- (私個人)評価の適切さを説明するための言語化ができておらずメンバーに納得感を持ってもらうための材料をマネージャーとして用意しきれなかった
「チームの成果」へのFocus
チームLeaderである以上、何よりもFocusすべきなのは私個人がうまくやれるか、ではなくチームが目指すべき方角へ最速で走れているかを常に確認し、それを実行しきるために必要な全てのことを成し遂げることです。
今はこれを明確に意識することができますが、当時は私にこの意識が持てておらず、3ヶ月終わった時にはチームが出した成果と会社としてチームに期待したGoalのAlignができていないというIssueが発生しました。
このIssueは内部的に以下の2つのSub Issueが含まれていました。
- チームがボトムアップで必要だと思い、成し遂げた成果を組織にraiseしきれておらずQ末にゴールとずれていた
- 組織からの期待値を整理、言語化しきらずにチームを走り始め会社からの期待値とチームのゴールがAlignできていなかった
このIssueは明確に私が改善すべきポイントであり、かなり反省しながら次Qに望むことになりました。
最初の3ヶ月のIssueまとめ
最初の3ヶ月で顕在化したIssueをまとめます。
- 組織全体で見た時、チームの持つ責務の一部が最適な配置になっていなかった
- 開発プロセスの改善は私たちのチームではなく、機能開発チーム内で実装すべきではという仮説が有力だった
- チームがFocusしたいことにできていない状況があった
- 負債改善、兼務の常態化が主な原因
- 評価制度が組織・事業のフェーズに追いついていない、もしくは調整が必要だった
- 私自身もAs Managerとして評価に関する説明責任を十二分に果たすための振る舞いができていなかった
- 会社から期待されるチームの成果とチームとして目指したい成果のAlignが十分にされていなかった
次の半期(2022/4~9)
前回の3ヶ月間のIssueに対して
前回の3ヶ月間で顕在化したIssueに対して、まずは私の立場でできることを順に行っていきました。
- 組織全体で見た時、チームの持つ責務の一部が最適な配置になっていなかった
- これは私のチームだけでなく、他のチームでも一部顕在化していた
- CTO-Manager間で協議の上、新しいチーム体制を検討しメンバーの再配置を行った
- 結果として私のチームはReliability, Securityサブチームはそのまま。Development Processサブチームのほとんどのメンバーは機能開発チームへ異動した
- ただしQA(Quality Assurance)の領域はメンバーが入社前だったこと、As Platformとして開発チームに関わっていくことがBestと判断し私のチームのサブチームとして新しく設立した
- チームがFocusしたいことにできていない状況があった
- 評価制度が組織・事業のフェーズに追いついていない、もしくは調整が必要だった
- 実際の評価プロセスでメンバーからもらったfeedback、私自身が感じたIssueをCTO-Managerの会議体でraiseし、評価制度のアップデートの検討を開始した
- 会社から期待されるチームの成果とチームとして目指したい成果のAlignが十分にされていなかった
ここに書いたことに取り組みつつ、この6ヶ月間はチームとしての実りが生まれ始めた期間だったと思います。
Reliabilityサブチームの立ち上がり
厳密にはReliabilityサブチーム(a.k.a SREチーム)は2022/1に立ち上がっていましたが、チームらしく絶え間なく成果を生み出し始めたのはこのタイミングだったかなと思います。
これが成し遂げられたのは私の力ではなく、2022/1-3の期間でチームアップの仕込みを愚直に行ってくれた@_tapihさんと、4月からReliabilityサブチームのLeaderとしてチームロードマップ作成のLeadから足元の取り組みのLead、戦略策定をOwnershipを持って取り組んでくれた@babarotさんのおかげです。
また、ソフトウェアエンジニアでありながら自身の強い課題意識からReliabilityサブチームに所属してもらい、かなり色々と無茶なIssueを任せているにも関わらず成果を出し続けてくれている@horimislimeさんにも本当に助けられました。
Securityサブチームの立ち上がり
再掲にはなりますが、Securityサブチームは2022/1に立ち上げたものの、最初の3ヶ月間は実際に手を動かすより社内のIssue集めの箱や、スポットでのIssue解決を行うような動きが主でした。
この動きから、メンバーの兼務を解消したこと。私自身が少し小慣れてきて手を動かす時間を作れるようになってきたことから徐々にProactiveな取り組みを行えるようになりました。
特に10X初期からソフトウェアエンジニアとして活躍している@swdyhさんにはセキュリティの専門知識がない状態からスタートしたにも関わらず、いろいろなキャッチアップを進めながら、他チームのサポートもしながら少しずつ成果を出してもらいました。
それもあって2022/7-9の3ヶ月間では会社としてセキュリティ上のリスクとその実態を正しく認識できる状態になり、会社の目標にセキュリティに関連した目標を設定され、事業としてもチームが明確に必要であることを証明できたタイミングでした。
Qualityサブチームの立ち上がり
最初の3ヶ月間、開発の品質と生産性にFocusしてくれたDevelopment Processチームから一部切り出される形でQualityサブチームを2022/4のタイミングで立ち上げました。
このチームはこのタイミングで0から立ち上げた、というよりは入社前から業務委託としてコミットしてくれていた@tarappoさんが入社して、本格的に立ち上げてくれたチームです。
その立ち上げの爆速っぷり、素晴らしさはすでにたくさんの記事があるのでそれを読んで欲しいですが、「10Xの開発組織のアウトプット品質を事業の未来を見据えながら担保していくチームを作ってくれ」という抽象度も難易度も高いIssueに対して明確な回答を1つ1つ積み上げてもらいました。
また、途中で入社してくれた@iizima(twitterわかりませんでした)さんも@tarappoさんが積み上げたものを解像度高く爆速で理解した上でゴリゴリ成果を出してもらいました。
振り返ってみると
こうやって書き出してみると、この6ヶ月間は「私がこうしたからチームが劇的に良くなった」ということはあまり無くて、各サブチームに権限をほぼほぼ移譲しつつ、各所で生まれる大小様々なブロッカーをひたすら取り除いていくというのが主な立ち回りだったと思います。
一方でチームを早いタイミングで縦割りにして、責務を明確に分けたのはThink 10xないい手だったと思います。
この立ち回りができたのはひとえにメンバーがひたすら優秀だったのが一番だなと思ってます。感謝…！
評価制度は改善されたか
Managerの立場として決して蔑ろにしてはいけない評価制度のIssueについてですが、結論から言うとエンジニアリング組織だけでなく10X全体として評価周りの類似したIssueが顕在化しており、エンジニアの評価制度だけ改善するのではなく組織全体として評価制度を大きく刷新されることになりました。
詳しい内容はCEO yamottyの以下の記事が詳しいです。
Managerの立場として、この制度の更新や解きたいIssueの設定とそれに対する手段は相対的には間違いなく良くなっており、実際の評価プロセスも最初の評価時よりは良くなっているのではないかと思います。
一方で現状が最適化というと決してそんなことはなく、この先もIssueを検出し、1つ1つ対処してきつつ事業や組織の変化にも対応していくことが求められるので、引き続き自分の見える景色でのIssueは会社にraiseし続けたいなと思ってます。
まとめ
全然まとめられずに時系列で取り組んだことを書いてきたんですが、書いてるうちにもっと他にも書きたいと思うことが山ほどあるくらい色んなチャレンジをした期間だったなと思います。
失敗も山ほどしましたが、優秀なメンバーと共に働けたこともあるし、自分が引いたいくつかのレバーのおかげでチームが良くなった部分もあるのかなと思える楽しい期間だったなと思います。
昔は「EMって忙しそうだし調整めんどくさそうだし人間扱うの絶対めんどくさそう…」と言う偏見に満ち溢れた意見を持ってましたが実際やってみると扱うべきIssueの抽象度が上がっただけで問題解決をしないといけない、と言うのはソフトウェアエンジニアとそこまで本質的に違いはないんじゃないかなと思いました。
※ 自分自身の意識付け次第で単なる調整者に陥ってしまうことも十二分にあるかなとも思います
余談：Managerとしての成果
9ヶ月間、Managerとしてやってきた中で結構悩んだのは「私がManagerとしてチームにいることで出たインパクトって何があるんだろう…？」ということです。
例えば「この取り組みは自分が関わってたけど、実際の成果を出したのはメンバーの能力のおかげだったり、他チームが頑張ったからだよな…」みたいに考えたりします。
ManagerはICと比べてリリースしたPull Requestの数、ApproveされたDesign Docの数みたいなアウトプットが少ないです。
今、立ち止まって理由を考えてみると解くべきIssueの形や性質、領域が変幻自在というのがある気がしていて、ある月は評価制度に思いを馳せ続けることもあればある月は採用計画、ある月はメンバーの兼務タスクの解消の調整をしているし、ある月はPlaying Managerとしてコードを書いてたりします。
また、Managerとして評価を受けられる場面もICに比べると少ないと思ってます。コードレビューみたいに指摘がもらえるチェックポイントがあればいいんですが、実際にはいろんなプロセスで問題解決に臨むし、時にはClosedな場所で動く必要があるし、またICに評価を求めた際、ICの置かれる状況次第で「いいマネージャー像」も大きく変わっていくと思います(し、実際はその像が明確な人はほとんどいなくてフィードバックすべきことが思い付かないことが多いと思います。自分もそう)。
個人的にこの答えはエンジニアリングマネージャーのしごとの回答がしっくりきています。
マネージャーのアウトプット = あなたのチームのアウトプット + あなたが影響を与えた他のチームのアウトプット
マネージャーは自分一人で完結して動いて、その結果大きな成果が来るパターンよりチーム内外のメンバーとコラボレーションすることで成果にどれだけ大きな係数を掛けられるかというパターンが多いと思います。これを認識しておくとこの先、Managerをやるときに自分が出すべき成果と求められる振る舞いをより精度高く認識できるはずと個人的には思ってます。
Managerからメンバーへと戻った
そんなこんなで9ヶ月間Leader兼Managerをしましたが、2022/10からICに戻りました。
理由は後日公表しますが、家族の事情(Good Newsの方)で、まぁ後日公表します。
最後に
何かを伝えたいPostというわけでもないですが、もともとManagerをやりたいと思っていなかった立場からManagerにチャレンジした上で感じたことは以下です。
- Managerの立場でも、責務が問題解決であるうちは楽しく働ける。むしろ課題の難易度が上がるのでやりごたえがある
- 一度Managerをやっておくと視野がかなり広がる
- Managerをやるチャンスは世の中の構造上、決して多くない。チャンスがあればチャレンジを推奨したいです
- Managerとしてどう走り出すべきか、のいい資料が無くて最初は苦労しました
- が、今はエンジニアリングマネージャーのしごとを読む + 会社のあなたへの期待値を言語化してもらう、で初手は十分だと思いました
- マジで良本なので読んで。Managerで無くても読むと学びがあります
この記事でアカウント名を上げてないメンバーにも、チーム外の一緒に仕事してくれたメンバーにもとても感謝しています。まだまだ未熟ですが今後ともよろしくお願いします。