はじめに
あっという間に年末ですね。
ここ2年ほど、数名規模のスクラムチームでPO・テックリード・スクラムマスターを兼任しながら開発を推進してきました。フルリモート、メンバーは全員外国籍という、なかなかカオスな体制でした。
破綻せずにここまで来られたのは正直運も大きいですが、その中で意識してきたことや、うまくいかなかったことを振り返ってみます。
体制の概要
- 数名規模のスクラム開発体制で、プロダクトオーナー・テックリード・スクラムマスター・開発者・運用担当者を兼任
- 自分以外は外国籍、メンバーとは基本フルリモート
- 全て英語で各種イベントを運営
- 開発対象は社内向けサービスで、クラウドインフラからフロントエンドまでフルスタックに対応
チームをリードする上で意識したこと
初めて複数メンバーをまとめて開発を推進するにあたり、主に「チームのモチベーションをあげること」と「メンバーの開発速度をあげること」を意識していました。自分が何かするよりも、メンバーができることを増やす方が良いだろうという判断です。
2級市民を作らない
諸般の事情で完璧とはいかなかったものの、可能な限りメンバー全員を対等に扱うことを基本姿勢としました。日本が主導ではありつつも在海外のメンバーがマジョリティーという状況だったので、むしろ「みんなが主役です」という話を常々していました。
また、メンバーには英語ネイティブはおらず、英語にそれほど慣れていないメンバーもいました。そこで「たまたまみんなで英語を喋ってるだけで、必要なら各母国語で互いに話をしても良いし、チャット＋翻訳を使っても良い。理解が進むことを第一優先に、できることは全てしよう」ということも伝えていました。
動機づけに時間を割く
プランニングやリファインメントの時間を中心に、なぜこのスプリントゴールやストーリーをやるのかについて、かなり多くの時間を意識して割いて説明しました。チケットをとる開発者にとっては直接関係ないかもしれませんが、「とにかくやれ」みたいなのは自分が死ぬほど嫌いなので。
ただその分タイムスロットを守れないこともあったので、もっと効率的なハンドリングができても良かったかなとは思っています。
メンバーが動きにくい部分を取り除く
各種権限が足りなければ可能な範囲で設定したり、必要なクラウドリソースがあればどんどん使ってもらうようにしました。常識のあるメンバーばかりだったこともあり、最初はかなり遠慮がちに利用されることもあったのですが、「自分の人件費に比べたらどうか？割に合うならどんどん使って」と伝えるようにしていました。
効率を上げる仕組みを積極的に導入する
組織が用意しているツール群に加え、翻訳系のツールや、今年に入っては開発エージェントの導入なども行いました。
スキルアップの時間を明確に作る
祝日の違いなどでメンバー間の同期が取れないタイミングについては、スプリントをお休みし、自分が学びたいことを学んでチームにシェアする時間にしていました。また、チームとして経験がない技術については調査チケットを切り、ある程度探索的に情報収集や手を動かす機会を設けました。
自分が資格を取り「学ぶことが良いこと」という雰囲気を作る
個人的に資格を取ること自体にあまり意味を感じておらず、最初は忙しさを言い訳に放置していました。ただ、自分より忙しい同僚がちゃんと取得しているのを見て、「言い訳してるのもダサいな」と思い、kubestronautsを取得しました。
直接的には体系的な知識を得られたのが収穫でしたが、同時にメンバーが学ぶことを良いことだと捉える雰囲気ができ、多くの方が資格取得に取り組んでくれました。
業務の中で全てを賄えるのがベストですが、ソフトウェアエンジニアリングは変化が激しく、それだけでは難しいと考えています。基礎知識はすぐ業務に生きるわけではないですが、学ぶ習慣がつくことで今後のキャリアで良い選択ができるようになれば、という気持ちでした。
意識的にやらなかった判断
開発者としてチケットを取ること（途中から）
当初は「自分も開発者だからチケット取るぞ」と宣言していたものの、徐々に自分がボトルネックになることが頻発しました。プレイングマネージャー的な修羅の道もありますが、割と早々に諦めました。
代わりに、チームの速度を上げることに注力しました。新しいサービスの利用規約確認や法務部門との調整、ツールの見積もりや契約締結など、地味に面倒なところを引き受けていました。また、フルスタックに開発チケットがある中で属人化を避けるため各自いろいろなチケットを取っていましたが、初めての領域ではスピードが落ちがちです。そこで、全体を把握している自分が技術ブリーフィングや方向づけ、手に負えなくなった時の支援者としての動きをしていました。
残業してなんとかする
自分が開発・運用しているもので基本的に人は死にません。よって、自分が死ぬようなことはやめました。一人が残業して稼げる時間は、効率低下も相まってたかが知れています。不具合で迷惑をかけている時などを除き、無理にやりきろうとするのはやめました。今も働き続けていられるのが一番の成果かもしれません。
また、なるべくユーザーと接点を持ち、「このぐらいの時期に使いそう」といった情報を拾うようにしました。それに基づいて早めに準備して備えていたのも良かったと思います。
振り返り：できたこと・できなかったこと
できたこと
破綻なくチーム・サービス運営ができた
兎にも角にもこれだと思います。この体制になった時は「マジでどうなるの？」と思っていましたが、みんな生きていて、チームが健全に存続し、サービスが継続しています。
着実にユーザーが増え、目標数値を達成した
ありがたいことに期初に設定した利用数の達成を継続しています。正直、目標通りにいかないことの方が過去の社歴的には多かったのですが、数字として見えるのはとても嬉しいです。
なぜできたか
前述の様々な取り組みが奏功した、というのは誇っていいと思っています。ただそれ以上に人に恵まれました。優秀で前向きなメンバー、自分を活かしてくれる上司、兼任している各ロールに関する支援者、協力的なユーザー。運は当然ありますが、その土台を作ってくれた先人や組織のおかげだと感じています。
できなかったこと
プロダクトの価値提供が思いのほかうまくいかなかった
進捗が全くないわけではないのですが、特に最後の方は停滞が見られたように感じています。
なぜできなかったか
一つは、チケットの提供価値と技術難度のバランスが悪い対象をロードマップ上で選定してしまったことです。新しい技術を使いこなす割合がそれなりにある開発対象で、やや楽観的になっていました。チームで経験者が乏しい新しい言語・フレームワークに挑戦したことで工数がかかり、価値提供につながるチケットに時間が割けませんでした。
もう一つは、複数のロールを兼任することで意思決定の質が落ちたことです。単純に忙しく各ロールにかける時間が不足しました。勤務外でぼんやり「こうした方がいいな」と考える時間も大事だと思っていますが、それも分散してしまっていました。
また、意思決定の役割が集中しすぎてメンバーの自立性が損なわれていたようにも思います。開発チケットの優先順位も、技術的方向性も、チームの健全性改善も、全て同じ人が決めるというのは、自立性を重んじるスクラム開発としては一人に依存しすぎでした。素早く動けるメリットはありましたが、何が大事かをちゃんと話せていたかというと、なんとも言えません。
学びと今後
チームをリードすることの面白さと孤独
自分はキャリアとして開発者を一生やっていきたいと考えています。そして、別にロールなんでなんでもいいでしょ、やるべきだったら同僚でも上司でも関連部署でもロジック組んで説得し協力を得ていけばできることは変わらない、ぐらいに思って今までやってました。
ただ、小規模のチームとは言え、その範囲で意思決定ができることで自分が思うようなスピード感で開発を推進することができ、そのあたりは面白いなと思いました。
一方で、決める人は孤独だと感じました。良い人に囲まれたことで、いろいろなアドバイスや意見を貰えるものの、最終的に決めるのは自分ひとりしかいないんだな、と強く感じました。
より大きな組織になればなるほど、この2つの面は膨れ上がっていくように直感的に思います。開発者としてのキャリアにおいて、組織に対してどう関与していくのは正直決めきれませんが、考えるうえですごく良い経験をさせて頂いたなと思います。
人でスケールさせることとその難しさ
チーム開発を進めることで、大変さはありつつも一人ではできない成果を挙げられました。まさに「早く行くなら一人で行け、遠くに行くならみんなで行け」です。
一方で、やっぱり考えることもやることも多くて大変なのは間違いありません。直近はテックリードとして5プロダクトを見る体制になりましたが、1チーム以上にスケールさせるには別のやり方が必要だと感じています。今の体制でコードレベルで状況を把握して適切なディレクションをしていくのは限界があります。
プリンシパルエンジニアやCTOのレイヤーでは中間レイヤーのエンジニアを配置して責任を委譲するのかもしれませんが、上位に行くような人はちょいちょいネジが飛んでいて力技な気もします。怖い。
英語
ややおまけになりますが、TOEICが900点を超え、特にリスニングが満点近くになりました。途中あったアメリカ出張で講演をある程度理解したり、質問してやり取りしたりできるようになりました。ほぼ毎日英語を喋り、スクラムイベントで長時間ファシリテーションを続けたのは確実に力になったと思います。
ただ、ネイティブが速く喋っているのを理解するのは、イディオムの語彙不足もあり、まだ無理です。これ以上は別のトレーニングが必要だと感じます。
今後
現行の体制は組織的な事情による一時的なもので整理されつつあります。自分としてもスコープを狭めたいし、もう少し技術に集中したい。この辺りは叶う見込みがありそうです。いままでやりたいけどできてなかった部分とかチーム横断で規模が大きくなかなか手が出せてなかったところをぼちぼちやっていくつもりです。
一方で、もっとスケールするような技術に取り組みたいという気持ちに対して、その機会は現状あまりなさそうに見えます。また、チームが成熟しつつある中で、自分が技術スペシャリストとして貢献できる領域が狭まりつつあるようにも思います。
こういう席は人に譲り、自分はより難しい対象に取り組んでいくのが正しいのでは、と思ったりそうでなかったりします。k8sやAzureをコアにしつつ、競プロなどで鍛えた常軌を逸したコーディング速度やWebアプリチューニング能力を活かして、困った時に全部なんとかする人が役立ちそうなところをぼんやり探していこうかなと思う今日この頃です。