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