2020年1月から1年ほどKyashでEMをやっています。

今までチームをリードしてきたことは何度かありましたが、いわゆるマネジメントという役割は初めてでした。EMについて抽象化した話ができるほど自分の中で咀嚼できているわけではありませんが、思考整理を兼ねてやってきたこととやっていくことをまとめておこうと思います。

ここに書く内容は当然自分だけでやってきたわけではありません。他のメンバーによって支えられてきたことの方が多いです。文章量の都合で端折ることもありますが、自分だけで色々やってきたみたいに捉えられるとなんだかむず痒い気持ちになるので一応前提として書いておきます。

1~6月 : Android/iOSチームのEM

1月にiOSエンジニアが1名入社したタイミングで、Android/iOSチームのEMをやることになりました。

それまではTechチーム全体を@ymzkmctが見ていましたが、エンジニアの数が増えて1人で見るのがしんどい規模になってきたというのが背景です。また、AndroidとiOSの領域はわりと固有の知識が必要なので、開発経験のある自分にマネジメントを委譲した方がうまく回るだろうという話もありました。

『マネージャーの責務はチームの成果の最大化』という定義をよく見かけますが、自分がEMになった当初KyashではKyash Cardの発行に向けて皆が開発に集中しなければならない時期だったので、集中を阻害する要因に対してとにかく何かしらのアクションを取っていたように思います。

オンボーディングフローの整備

iOSエンジニアが入社するにあたり、受け入れる側と入社メンバーのチェックリストを作成しました。

新メンバーは新しい環境で成果を出せるか多かれ少なかれ不安を感じています。そんな中で入社初日に各種アカウントの作成や招待などに時間を使うのはもったいないので、入社日より前にやるべきことはチェックリストにして終わらせられるようにしました。

また、新メンバーはビルドやデバッグ環境での動作確認などをチェックリストの順にやっていけばAndroid/iOSプロジェクトの基本的な部分をひととおり触れられるようにしています。12月現在までにAndroid2人、iOS2人がチームに加わりましたが、全員入社3日目くらいには初Pull Requestがマージされているのでまあまあ機能していそうです。

もともとはドキュメントツールでチェックリストを管理していましたが、@tamadonがGitHub Issue Templateで管理するように改善してくれました。今では、古い箇所があれば新メンバー自身がPull Requestを送って更新できるようになっています。

定例MTGの実施

チームが自分 + Android1人 + iOS2人の4人になり、チーム内で共有と相談ができる場があったほうが進めやすいだろうという話が上がり、週1で30分定例MTGを実施することにしました。

定期的に「アジェンダ変えたほうがいいところある？」「そもそもこのMTG必要？」といった具合に振り返りながら、今でも少しずつやり方を変えて実施しています。

CI/CDサービスプラン見直し

メンバーが増えてきたので、開発効率向上のためにCI/CDまわりを見直していきました。

具体的には、Bitriseのアップグレードや、Fabric BetaからDeployGateへの移行などをやりました。調査やドキュメントの整理などはメンバーがかなりリードしてくれて助かりました。

QAをベンダーに委託

Kyashではもともとリリース前のテストを社内のメンバーでやっていましたが、当時進めていたKyash Cardプロジェクトは仕様も複雑でステータスも多く、「社内でテストするのは大変だし漏れも出てしまうのではないか」という声が上がっていました。

そのプロジェクトに限らずKyashはアプリの規模も大きくなってきていたため、ベンダーにQAを委託することにしました。費用とスケジュールをすり合わせて4月から正式に入ってもらい、受け入れ体制の整備やフォローアップを行いました。

のちにメンバーと話したとき、「Kyash CardのリリースはQAがいなかったらだいぶ厳しかったと思う」と言っていたので、このタイミングで委託したのはよかったのではないかと感じています。

採用へのコミット

今後事業でやるべきことからチーム構成を考えると、自分 + Android3人 + iOS3人の7人体制くらいは必要だということがわかりました。

そこで、足りないAndroid2人、iOS1人を採用するべく、募集要項の更新、スカウト活動、面談・面接の整理などに結構時間を割きました。

結果として、5月にAndroid1人、11月にAndroid1人/iOS1人を採用できて、12月現在はこの時に思い描いていた体制を作れています。

採用活動に尽力してくれたメンバー、そして入社を決めてくれたメンバーには本当に感謝しています。

7~12月 : サーバーサイドの一部とQAチームのEM

エンジニアの数がさらに増えたタイミングで、サーバーサイド6人とQAもマネジメントすることになりました。主にAPIまわりを担当しているサーバーサイドのメンバーも自分が一緒に見た方が、アサインなど色々とコントロールできる幅が広がってやりやすいのではないかという背景もありました。

QAについてはもともとベンダーのとりまとめをしていましたが、QAエンジニアの採用を進めるところをやっていくことになりました。

担当する領域が増え、自分の仕事の仕方をうまく調整しきれず精神的に余裕のない時期もあったように思います。

Tech Leadの配置

5月にAndroidエンジニアが1人入社したことでAndroid2人、iOS2人になり、自分が開発タスクを持つことは極力やめることにしました。

サーバーサイドのメンバーのマネジメントも担当することになって自分のキャパを超えそうだったのと、そういうルールを作らないとどうしても成果を出しやすい開発タスクをやってしまいがちだったからです。

当時自分はプロジェクトとピープルマネジメントに手一杯で、技術面はほとんどリードできていませんでした。自走できるメンバーが揃っていたとはいえリード役を置いたほうがうまく回るだろうということで、7月からAndroid/iOS/サーバーサイドそれぞれ1人ずつTech Leadをお願いすることにしました。

今では、技術課題の洗い出しはもちろん、プロジェクト進行上の課題をPdMやQAを巻き込んで解決したり、採用活動にもコミットしてくれたりと幅広くチームを見ていただいていてとても助かっています。

例えば最近だと、PdM/エンジニア/QAがうまく連携できていなかったという課題意識をAndroid Tech Leadの@kkagurazakaがSlackで投げ入れてくれて、そこからの議論や改善アクションのとりまとめまでリードしてくれました。

複数走るプロジェクトの調整

エンジニアの人数が増え、複数のプロジェクトを並行で走らせることが多くなりました。そういう状況で問題になりがちなのが情報共有です。それぞれのチームやメンバーが何をやっていてどう自分と関連するのかわからなくなると、タスク自体にも影響が出ますし何より少しずつ精神に負荷がかかっていきます。同じ経験をしたことがある方も多いのではないでしょうか。

自分も正直うまく情報共有できているとは言い難いんですが、まず事業上どれが重要で何をやっていくのかを把握した上で、それを定例MTGなどでチームメンバーに伝えるようにしています。

アサインの調整はPjMがやってくれたりもするのですが、メンバーとコミュニケーションをとる機会の多い自分がやることが多いです。

また、リリースに関わる仕様やスケジュールの調整が必要な場合には情報を整理して解決までリードすることもあります。そういうことを何度か繰り返して、ファシリテーションは少しだけ慣れてきたように思います。

一方で、自分がコミュニケーションのハブになってしまっているなあという感覚もあり、各人の役割をもっと明確に定義してレポートラインを整えるべきだと感じています。

プロジェクト以外のエンジニア主導の改善

Kyashでは4半期に1度1週間エンジニアがやりたいことやるべきことに取り組む期間を設けています。

例えば、Androidエンジニアの@_Cordeaはこの取り組みで『実験的機能』をリリースしています。

おや！？Kyash のようすが……！ pic.twitter.com/IPww2sXNVl
— こにふぁー (@konifar) 2020年1月16日

9月に実施した時には『登録カード/銀行に名前をつけられるようにする機能』や『Androidパスコードロックの生体認証』などを作ってリリースしました。自分がサーバーサイドのメンバーも担当するようになったことで、モバイルとサーバーサイド両方が必要な取り組みにも手をつけられてよかったです。goバージョンアップやgo mod移行、Codecov導入など今までやりたかったサーバーサイドのタスクも進めることができました。

サーバーサイドのメンバーをiOSチームにコンバート

サーバーサイドのメンバーの1人が「技術の幅を広げたい」という話を1on1の中で伝えてくれていました。こういった自身の意向を伝えてくれるのは本当にありがたいことです。

色々と相談した結果、10月からiOSチームに入ってもらうことにしました。もともとサーバーサイドと比較してiOSチームの人数が少なかったのと、メンバー自身がプライベートでiOSアプリをリリースしていたことからコンバートしても成果を出してもらえると考えたためです。

iOS Tech Leadの@tamadonがうまくフォローしてくれたのもあって、初週から2つのPull Requestがマージされていました。iOSのメンバーとして全く問題なく働けていて、今のところiOS開発自体を楽しめているようで嬉しいかぎりです。

QAチームの立ち上げ

Android/iOSに加えてQAエンジニアの採用も進めるべく、募集要項を作成して採用ブログ記事を書きました。

blog.kyash.co

この記事を読んでくださったQAエンジニアの方とつながってQAの役割や組織について伺うこともできたので一応効果はあったと感じています。

最終的にはリファラル経由で10月に1人入社してくれました。自分がQA関連でやっていた業務をSpreadSheetに書き出して引き継ぎを進めています。QAの経験を色々と積んできた方で、自分も日々勉強させてもらっています。

現状は自分 + メンバー1人 + QAベンダー4人の6人チームで、2週間サイクルでリリースするAndroid/iOSのQAをしながら『QAの状態の見える化』に取り組んでいます。2021年にはテストの自動化に手をつけ始める予定です。

採用へのさらなるコミット

Techチーム全体で成果を上げていくために、採用にも今まで以上に力を入れていくことにしました。

採用担当とEMで定例MTGを開いて現状を数字で確認し、課題に対するアクションを決めています。

そのうちの1つが採用リポジトリの公開です。

blog.kyash.co

面談・面接前にこのリポジトリを見てくれている方も多く、採用時のコミュニケーションコストは下げられたと感じています。

また、継続したスカウト活動の結果11月にはAndroid1人/iOS1人が入社してくれて、自分の担当チームはかなりよい体制が整ってきました。

採用で成果が出せているのは入社を決断してくれたメンバーのおかげです。入社後にうまく成果を出して楽しく働ける環境を整備していきたいと思います。

オフボーディングの整備

EMになって初めてiOSメンバーの退職を経験しました。

ポジティブな理由だったので笑って送り出すことにしたものの、有休消化を考えるとスケジュールがタイトだったため、引継ぎなど退職に向けた準備を急いで行う必要がありました。

入社時のオンボーディングは整備されてきていましたが、退職時のオフボーディングはわりと属人的に行われていました。あまりない機会なので、今後のことを考えてオフボーディングフローをチェックリスト化しました。

作ってからまだ活用されたことはありませんが、退職前にGitHubチームから外してみたりSlackのアカウントをdeactivateしてみたりするのはオススメです。

ブラッシュアップの機会がこないことを望みつつも、オフボーディングの項目を意識することで普段から属人化をなくす意識も生まれると考えています。

1on1の目的再定義

複数チームのマネジメントで成果が出せている実感がなかなか持てず、全ての問題が自分の責任のように感じてしんどくなった時期がありました。たしか10月頃だったと思います。

例えばメンバーのモチベーションが落ちてそうだったり、情報共有がうまくできていなかったり、仕様やスケジュール関連で動きづらそうにしていたり、そういった日々起きる問題全てが「自分が先回りして手を打てていなかったことが原因」という気持ちになっていたんですね。けっこう辛くて、今振り返るとモチベーションもだいぶ落ちていました。

マネジメント関連の本を読み返したり、経験の長い他のメンバーに相談したりして色々考えた結果、「今すぐにはどうにもならんからチームメンバーに助けてもらうしかない」と自分の中で結論を出しました。自分が一番メンバーと対話しやすいのは1on1だったので、1on1の目的を『課題と期待のすり合わせ』と定義して進めることにしました。

メンバーには「チームの成果を最大化するのが自分の責務だけど、組織・個人の課題をうまく抽出しきれていないから教えてほしい」「言語化できていなくてもいいからどんなことでも歓迎する」といった形で伝えています。自分が伝えたと思っているだけで伝わっていないということはよくあるので、今後も期が変わるタイミングなどで何度か話そうと思っています。

また、課題に対するアクションの話が出た時に、メンバー自身が解決に向けて動けそうであればなるべくお願いするように意識しています。課題の解決まで持っていける力があるチームメンバーが多いので、「できれば解決までリードできる時はやっちゃいますね的な動きも期待している」と明確に伝えています。ここも伝えたつもりになっているかもしれないので、今後も繰り返しすり合わせていこうと思います。

明確に期待を伝えると自分で動いてくれるメンバーが多いので、このメンバーに頼るスタイルの1on1をやり出してから少し気持ちが楽になったと感じています。

これからやっていくこと

色々とチームの課題に取り組んできたものの、構造的な解決はあまりできていないところに課題を感じています。

そこで、2021年1~2月は以下をやってきこうと思います。ざっくり考えている内容なので細かい部分は変えるかもしれません。

プロジェクト進行の課題
- 各メンバーの役割とレポートラインの明確化と浸透
- デリゲーションボードの作成
Techチームの課題
- 目線を揃えるためのロードマップの作成
- 中長期の成果を大きく引き上げるための開発生産性向上の取り組み
採用の課題
- 母集団形成のためのMeetup開催、採用関連ブログ記事公開
- 面談の質向上のためのよくある質問リスト公開

また、自分自身もっとマネジメントの勉強をする必要があると感じているので、今はとにかく本を読む量を増やそうと思います。

マネジメントに専念していることについて不安はないのかとカジュアル面談で聞かれることがありますが、キャリアに関しては大きな不安はありません。もともと6年前くらいにAndroid開発を始めた時も知識がない状態から先人の知恵をキャッチアップしてやってきたので、もしまたプレイヤーに戻るとしても同じように勉強していけばいいだろうと半ば楽観的に考えています。

マネジメントは組織にいなければ経験できないことですし、まだまだキャッチアップすることばかりなのでもう少しやっていこうと思っています。成果を出すべきところをうまく定義できなかったり、定義できてもなかなか成果が出なかったりすると不安になることはあります。それが積み重なって精神的に辛くなることもあると思いますが、自分は10月くらいに一度モチベーションが底の方まで落ちて戻ってきたのでまあ何とかなるだろうとここも楽観的に考えています。何事も経験ですね。

もしKyashのTechチームに興味がわいたら下記から気軽に連絡ください。カジュアル面談では自分もお話させていただきます。

では、最後はいつものようにこれを置いておきます。Let's Kyash!

kyash_id: konifar