はじめに
みなさまこんにちは！
株式会社プラハでエンジニアをしていますAwataです。
早いもので、プラハに入社して1年が経過しました。
そして直近の案件からリーダーを務めることになり、つい先日無事にリリースまで完了しました！
とても学びの多い機会だったので、振り返ってみたいと思います。
また、会社のPodcastでもリーダーとしての振り返り会を行っていますので、興味がある方はぜひそちらも聞いてみてください！
TL;DR
かなり長い記事になるので、リーダーをやってみて感じたことを最初にまとめておきます。
- 実際のスプリントが始まる前に、そのプロジェクトの成功の定義と失敗の定義を決めておきましょう。
- そしてなるべく早く、失敗の要因になりえる懸念は取り除けるようにリーダーとして必要なことをやりましょう。
- 全体での振り返り以外にも、個別の1on1は必ずやりましょう。
- どうして？何を話すの？という疑問はエンジニアリングマネージャーの仕事を読めばきっと分かります。
- 恥ずかしい気持ちは捨てて、社外の有識者に知恵を借りることも検討しましょう。
- リーダーになると様々な決定権を持ちますが、間違った判断をして取返しがつかないことになるくらいなら、誰かに頼りましょう。
- 自分やチームにとって学びになるだけでなく、より正しい判断を下せることになり、プロジェクトの成功につながります。
- リーダーとメンバーでは、求められるアウトプットが異なります。そのため、立ち振る舞いや仕事への取り組み方も変える必要があります。
- 最初は戸惑うかもしれませんが、プロジェクトの成功のために臆せず変化しましょう。
- リーダーの経験は誰にでも得られるものではありません。臆せずチャレンジしましょう。良いメンバーが集まったチームのリーダーはとても楽しいものです。
どんな案件だったか
株式会社アガルートが提供しているアガルートアカデミーというサービスの法人向けサービスの新規開発を行いました。
チームメンバーは自分を含めて4人、開発期間は5ヶ月ほどの想定でした。
最初の1ヶ月は自分だけが週5稼働で他のメンバーは週2~3稼働、翌月から他のメンバーの稼働も増えるような少し特殊な状態のチームでもありました。
技術的な話でいうと、既存のアガルートアカデミーのシステムとの連携もあり、完全な新規開発とはいえない案件でした。
既存のシステムのコードはかなり荒れ果てており、あまり手を入れられないため今回の新規サービスもその負債の影響を多少受けてしまったりということもあり、最初にしてはなかなかに難易度の高い案件だったなと思います。
なぜリーダーになったのか？
大きく分けると、以下の2つです
- CEOが自分を推薦してくれた
- プラハのメンバーを信頼しているため、リーダーになっても大丈夫だと思った
他にもタイミング的に自分がやるのが一番良いだろうという時の運みたいなものもありました。
正直、リーダーをやりたい！という強い気持ちがあった訳ではありませんでした。
過去にSESで働いていた時に、経歴詐称の新人のタスクを巻き取ったり、上からも下からも文句を言われて困っていたりと、嫌なイメージも多くあったことも事実です。
ただ、プラハには信頼できる人が集まっているし、何よりもリーダーという貴重な経験をできるタイミングを逃すべきではない！という判断をして、最終的には引き受けることにしました。
やったこと
ここからはリーダーとしてやったことを振り返っていきます。
今回のチームは自分を含めて4人でしたし、みんな自立して動けるメンバーが揃っていました。
そのため「こういうことやります！」とか「こういうルールでやりましょう！」みたいにリーダーっぽいことをせず、なんとなく進めてもきっとなんとかなったと思います。
ただ、やはり1つのチームとして最大の成果を出すためには最低限のルールは必要だと思ったので、いくつかルールを決めました。
MTGの頻度や進め方を決めた
今回は大枠としてスクラムのやり方に則ることにしたので、まずはMTGの頻度や進め方などを決めました。
MTGの頻度を決めるにあたって、チームとして以下のような共通認識を持っていました。
- 極力MTGは少なくして作業に集中できるようにしたい
- 週5稼働ではない人もいるため、全員にMTGを強制させると作業時間が取れない
- 顔を合わせるMTGが少なすぎると、チームとしての雰囲気が悪くなりそう（一体感が生まれない）
これらを踏まえて、今回は以下のMTGを定期で実行することにしました。
また、メンバーがこれらのMTGに集中できる環境を用意することもリーダーとして必要な仕事です。
自分はそのために、それぞれのMTGのアジェンダを決めたり議事録を取る準備も進めました。
この辺りのチーム作りに関しては以下のPodcastも参考にさせていただきました。
77. リモートワークにおけるファシリテーション（前編）
78. プロジェクトスプリント（後編）w/ motoi, kedamatti
デイリースクラム
こちらは情報共有の場としてももちろん大事ですが、自分たちのチームにとってはメンタル面においても大事だったなと思っています。
プラハはフルリモートでもあるので、極力1日1回は顔を合わせてチームとしての意識を持って仕事をやっていこう！という一体感が生まれました。
ちなみに以下のようなルールで開催していました。
- 毎日やる
- 稼働日以外は任意で参加
- 15分で終わらせる
成果発表会
今回は1スプリント2週間でやったので、2週間に1度のペースで開催されていました。
どういう成果が出せたのかをPOに発表する場で、メンバーの参加は任意としていましたがやはり気になる人が多いのかほぼ参加率は100%でした。
実際のフィードバックや今後の課題について話し合うことができる貴重な場だったかなと思います。
振り返り
こちらも同様に2週間に1度のペースで開催していました。
振り返りはメンバー全員でやりたいため、全員必須参加としていました。
進め方はこちらの記事をかなり参考にさせて頂きました。
Bad/Factなどについては真面目に対策を検討しますが、Good/Emoな項目には超プライベートな内容を書いてみんなでワイワイ話す、みたいなゆるい雰囲気で進めてました。
せっかくなので、実際の議事録を一部ご紹介します！
楽しそうにやっている雰囲気は伝わるかなと思います！
Good/Fact
Bad/Fact
Bad/Emo
Good/Emo
感謝
プランニング
こちらも同様に2週間に1度のペースで開催していました。
MTGの内容はタスクのストーリーポイントの見積もりをして次のスプリントのタスクを決める、これだけです。
こちらもメンバー全員の知識が集まる方がより正確なポイントの見積もりができると思ったため、全員必須参加としていました。
PRレビューのルールを決めた
チームが大きくなればなるほど、PRレビューについては様々な問題が発生します。
例えば、
- 〇〇さんしかレビューしていない（〇〇さんはレビューを全くしない）
- レビューが溜まっていて、新しい作業をしようにもどうせコンフリクトすることが目に見えている
- レビューしなきゃいけないのは分かっていても、作業に集中したいときもある
などです。
今回は、これらの問題を解消できるかもしれないルールをチームで考えて採用しました。
詳細についてはこちらの記事で紹介しています！
初期段階に不安要素の洗い出しをした
冒頭に軽く紹介しましたが、これをやっておくことでかなりチームの開発効率は良くなったのではないかと思っています。
具体的なやり方などはこちらの記事で紹介しています！
システム構成、アーキテクチャの決定
今回の案件は簡単に新技術を取り入れることができる文化というのを採用の際にアピールするための案件でもあったので、どのような技術を使うかは慎重に選ぶ必要がありました。
また、既存システムとの連携も必要だったり、既存システムを将来的にどうしていくかの布石にもなるような意味があったりと、かなり色々な事情が絡み合っている状態でした。
マイクロサービスで作るか、モノリスで作るか
まずはこのテーマから検討する必要がありました。
最初に結論ですが、今回の案件ではモジュラモノリスを採用しました。
経緯についてはこちらの記事で紹介しています！
何の言語、フレームワークを使うか
先に書いた通り、今回は新技術を使える文化ということをアピールしたいという狙いもあったため、極力新しい技術を使って実装していきたいと考えていました。
そのため、チームメンバーが興味を持っている新しい技術から、良さそうなものを選んで採用しました。
最終的には以下のような技術スタックを使って開発しました。
RustでAPIを開発したことはかなり攻めた選択だったのではないかなと思っています。
DDDやモジュラモノリスと組み合わせてAPIを開発するとなると、前例がほとんどなく情報収集にも苦労しました。
個人的にはRustという言語はとても好きな部類に入りますが、Webシステムで使うとなるとエコシステムが弱いなと感じることが多く、一筋縄ではいかないことも分かりました。
こちらの記事で詳しく紹介しています！
インフラの構成はどうするか
ここもかなり悩んだポイントのうちの1つです。
というのも、自分が過去にBeanstalkを使ってインフラ環境を構築したことがある程度で、他にチーム内にインフラ構築をしたことのあるエンジニアがおらず、圧倒的にインフラが弱いチームだったためです。
そこで、自分が以下の2つの候補を上げました。
- AppRunnerやBeanstalkを使ってパパっと構築
- ECS+Fargateを使ってそこそこにちゃんとしたものを構築
インフラの構築をしてみたいというメンバーがいたこと、今回は新しいことにチャレンジしよう！というプロジェクトだったことを考慮して、今回は後者を選択しました。
構築に失敗するという最悪のケースを想定しても、自分がBeanstalkを使って構築することもできるので、最終的なリスクは低いと考えました。
構築の際はAWS Copilot CLI を使うことで、手で一つずつリソースを作成する必要がなくなり、かなり楽に構築することができました。
ただそれでも色々な部分で詰まることがあり、自分もサポートに入ったりしてチーム一丸でなんとか構築できました。
リーダーをやってみて
苦労したこと、心がけたこと
メンバーの時とは立ち振る舞いを少し変える
これはそれぞれの役割において必要とされている立ち振る舞いが違うのではないかという考えからきています。
例えば何かの議論をする際、議論を発散させるよりも収束させる立ち位置になってみたり、色々なメンバーから意見を引き出せるような質問をしてみたり、などです。
リーダーとメンバーでは、アウトプットするべきものが異なるため、当然立ち振る舞いも違うのではないかと考えています。
こちらの記事で詳しく紹介しています！
開発とマネジメント、他の作業との両立
これは誰もが苦労することかなと思いますが、マネジメントや雑作業に追われて、集中して開発する時間が取れませんでした。
ただ、先にも書いた通り自分はここで無理して開発の時間を取らない方向にシフトしました。
自分はスーパーマンではないので、できないことはできないですし、プロダクト開発はチームでやることなので、ここに拘るのはマネージャーとして逆に悪手だと自分は思っています。
メンバーを信頼して作業を任せ、自分はその補佐をメインに進めるというのが、今回の案件での自分の役割だったと思っています。
コードを作りこんでいきたい気持ちと、そこまでする必要がないという気持ちのせめぎあい
これはリーダーになって納期を強く意識するようになったからこそ、自分の中で起きたことかなと思っています。
これまでの自分は多少過剰な設計であっても将来必要になるかもしれないならやろう！という考え方の方が強かったです。
しかしリーダーになって残りタスクや期間など色々な情報を多く得るようになると、もっと厳しくYAGNIの原則に従うべきだなと思うようになりました。
そのため以下のような点を考えて、コードを作りこんでいくかどうかを判断するようになりました。
- 後回しにした場合、そのツケはいつ回ってくるか？またツケが回ってくるまでに解消ができるか？
- 先に時間を取った場合、そのリターンを得られるのはいつか？またそのリターンはどれくらいの価値があるか？
- 最終的に顧客に提供できる商品の価値向上に繋がるか？エンジニアの自己満足になっていないか？
これらはもちろんフェーズや規模によっても変わると思うので、柔軟に検討して対応することが必要だと思っています。
この辺りは経験を積んで、より精度の高い判断ができるようになりたいです。
情報共有
チームのメンバーが増えると、情報共有が難しくなってきます。
また、プラハは基本的に稼働時間も決められていないため、全員が同じ時間に必ず働いているとは限りません。
そのため、極力何かに書き残してそれを共有することで情報共有が不足しないように心がけていました。
とはいえ、資料作りに全ての時間をつぎ込むわけにはいかないのでバランスを取るのが難しかったです。
今回は以下のようなことを意識していました。
- 適材適所でツールを使い分ける
- MTGの議事録はコンフルに残す
- コードに関する議論はPRかSlackで行い、Slackで行った際はPRやIssueにSlackへのリンクを貼る
- 構成図などはdraw.ioなどで図を書く
- あの資料ってどこにあったっけ？とならないようにSlackの関連ページにリンク集を用意する
- 資料を残すのが難しい場合は、Slackに作業ログを残す
- 何かに困ったらSlackで気軽に「〇〇で詰まってる」と投稿する
最後の2つに関しては、どちらかというとそういう投稿がしやすい環境を作る方が大切な気もしているので、リーダー自身が率先してそういう行動をできると更に良いなと思います。
成長できたこと、良かったこと
人に意見を求めることがうまくできるようになった
リーダーになると様々な意思決定をする必要があり、その際に誤った決定はできないという意識が強くなりました。
そうすると、自分だけの知識では到底分からないことも出てくるので、その際に色々な人に意見を求めることがとても大事だと思っています。
分からないことを分からないと言う、恥ずかしがらずに有識者に質問する、という動きをちゃんとできたのは自分にとっても大きな成長だったと思っています。
そしてこれらの情報からその時のベストであろう意思決定を下すことがより精度高くできれば自分はもっと成長できるのではないかと思います。
色々な資料を用意して、チーム全体の開発速度の向上に繋げられた
これはエンジニアにとって苦手意識が強いであろう資料作りです。
自分は元々そこまで苦手意識がなかったので苦労せずに取り組むことができましたが、苦手な人にとってはかなりしんどい作業になると思います。
また、自分は以下のようなことを意識して資料を作りました。
-
図や絵に関してはメンテナンスはしない
- 全てをGitで管理するべきだという人もいると思いますが、自分は最初の情報共有を円滑にするためなど、目的を絞って書けば使い捨てでも良いと思っています
- 資料の内容が古くなることは仕方ないので、その資料は最新の状態を表したものではないということを周知しておく
- 例えば、以下のようなインフラの構成を検討する用の図を用意したりもしました。
- これは全くメンテナンスされておらず、最新の構成とは違う部分があります。
- ただ、こういう図があるのとないのでは議論のしやすさという点において大きな差があると思っています。
- 無理にツールを統一しない
- ある程度であれば、メンバーが使いやすいツールを使っても良いと思っています
- 今回は技術的な資料はREADMEに、議事録的なものはコンフルに、絵や図はdraw.ioのように、それぞれのツールを使い分けました
- 原則メンバーなら誰でも編集できるようにしておく
- たまにメンバーが資料を編集してくれることがありました
人と話すことに対しての苦手意識が少し減った
自分は1対1はまだ大丈夫ですが、大人数の前で話すことがかなり苦手でした。
リーダーになると色々なMTGに参加したり、ファシリテーションをすることが多くなり、少しずつ苦手意識が減ってきたと思います。
ただ、自分は喋るのが遅い方なのですが、そこは相変わらず遅いままでした。
これは直すにはまた別のトレーニングが必要そうです、、、！
1つ上の視座からの仕事ができるようになった
リーダーをやっていると、仕事の内容だけでなく得られる情報の内容も変わってきます。
例えば、このプロダクトはどれくらいの売上を想定しているとか、これくらいのランニングコストがかかっているなどです。
これによって、やるべき、やらないべきの判断基準に、これまでなかった情報を増やすことができ、より合理的な判断ができます。
具体的な例を挙げると、インフラの冗長化をどこまでやるか？という議論をしていた時に、以下のようなPRのコメントを書きました。
これは色々な情報を得たりサービス全体のことを考えられるようになったからこそ書けたコメントではないかなと思っています。
失敗したこと
1on1の時間を取らなかった
今回はスプリントごとのチーム全体での振り返りしか行っていませんでした。
そのため、少し振り返りの場が足りず、チームとしてうまく動いていないように感じる時期がありました。
なぜ1on1の時間が必要と感じたのか？についてはこちらの記事で紹介しています
タスクの委譲に失敗した
今回失敗したなと反省しているのは、インフラ構築のタスクをほぼ丸投げで委譲してしまったことです。
メンバーの持っているインフラに関する知識や、今回構築しようとしている環境がどれくらいの難易度なのか、具体的にどういう作業が必要なのか、などが不明瞭なままタスクを委譲してしまいました。
もっと事前にこれらの情報を調査した上で、タスクを委譲するべきだったなと思っています。
自分が想像できるタスクであれば、ある程度のタスクの見積もりができるので適切な委譲レベルを選択できますが、今回のように誰も正確な見積もりができない状態だったらまずは一番詳しい人間が調査した上で、ある程度の見積もりが出せる状態にしなければいけなかったなと反省しています。
後半急いでしまった
質を下げてもスピードは上がらないとよく言われますが、リリース直前の1週間や2週間に限定すれば、自分はスピードが上がると思っています。
もちろん長い目で見たときに必ずどこかでリファクタリングをしないとどんどんスピードは低下していってしまうと思いますが。
今回はリリース直前の1週間強に限定して、必要最低限のリファクタリングのみを行いつつ機能追加をひたすら行うフェーズを作りました。
そして将来の自分たちに負債を残しすぎないよう、リリースの後にリファクタリングの時間も取りました。
質が悪いコードを見逃してください、というのはメンバーにとって不満だったかもしれませんが、なんとか協力してもらえて無事にリリースすることができました。
全体のまとめ
かなり長くなってしまいましたが、いかがだったでしょうか。
今回のリーダー経験は自分にとってとても貴重なものでしたし、なんとかなるだろう精神で引き受けたことは正解だったなと思っています。
これまではリーダーをやる自分の姿を全く想像できなかったですが、最近は意外とリーダーも楽しいなーなんて思ったりもしています。
そのためもう少しリーダーについて勉強したいなと思い、最近はエンジニアリングマネージャーの仕事の輪読会を社内で開催しています。
こういうことが気軽にできるのもプラハの良い文化だなと思います。
最後にリーダーになるか迷っているエンジニアの方に向けて、迷っているならぜひやってみてほしいなと思います。
こちらの記事ではやったことの一部しか紹介できませんでしたが、それでもこんなに色んなことにチャレンジできます。
リーダーをやってみたら？と言われること自体が中々ないと思いますし、実際にリーダーをできるタイミングというのも限られていると思います。
もちろんメンバーによってリーダーをやってみての満足度は大きく違うと思いますが、自分はリーダーをやってみてとても楽しかったです。
皆さんがリーダーをやろうか迷ったときのために、この言葉を置いておきます。
「きっとうまくいきますよ」 (エンジニアリングマネージャーの仕事より)
Discussion