新規開発プロジェクトのリードエンジニアを初めて経験しました。その中でいろいろ悩んだり考えたりしたことを書いてみます。
注意
この記事では技術のことには一切触れません。
世の中の一般的な「リードエンジニア」とは定義や解釈が異なるかもしれません。
ひとつの体験談として眺めてもらえたらうれしいです！
簡単なプロフィール
こんな人が書いてます
- 株式会社Relicのフロントエンドエンジニア
- 前職ではLP制作を一年半ほど
- その前は全然違う仕事してました。当時はエンジニアなんて職種知らなかった..
- Relicに入って初めて「Webサービスを開発する」「チームで開発する」いうことを経験
- 一年ほど経て、この新規プロジェクトのリードエンジニア（フロントエンド）やってみません？と打診されて今に至る
Relicは新規事業の支援をする会社です。興味のある方はコーポレートサイトを見てください！
リードエンジニアとは？
一般的な定義
リードエンジニアってそもそも一般的にはどんな役割を指すんだろう？
ということでとりあえずググってみます。
以下は検索結果から抜粋
リードエンジニアとは、開発チームなどにおけるリーダーのような立場のあるエンジニアです。リードエンジニアはチームを牽引し、プロジェクトを推進していったり、エンジニアチームのプログラマーが書くコードの、品質を担保したりする役割も持っています。
リードエンジニアとは、エンジニアチームをまとめるポジションのことです。具体的には、エンジニアチームを束ねる技術面のリーダー役であり、同時にチームの窓口役も担っています。
ふむふむ..
超ざっくり言うと「エンジニアチームをまとめるリーダー」といったところですかね。
これだと正直あまりイメージが湧かないですが、細かい部分は各企業や組織、チームで変わってくるのでしょう。
一般的な定義を抽象化すると、「マネジメントっぽいこともするし技術的な担保もするよ」という感じなのがなんとなく分かりました。
Relicでの定義
Relicでの「リードエンジニア」は下記のように表現されています。
「こういう事業を作ろう」となったときに形にしてくれる人
Relicという新規事業を作る会社の中で、アイディア、戦略、企画を具現化するためには欠かせない要のポジション
新規事業の支援をするというRelicの事業内容に沿ったものになっています。
初見での正直な感想は「結局ピンとこない..」でした（小声）🤫
が、求められるものとしては主に下記の3点とされています。
※もう少し詳細の定義もあるがここでは割愛します
- 開発力
- マネジメント力
- 事業家目線
前述した一般的なリードエンジニアの役割に、Relicならではの「事業家目線」が加わったものになりそうです。
ひとまず定義されている役割についてざっくりイメージを持ちましたが、やり方やアプローチの方法は人それぞれだろうな〜と思いながらチャレンジしました。
自分の考えるリードエンジニア像の変遷
あらゆる段階での考えや気持ちを振り返ってみます。
注意
繰り返しますが、超個人的解釈なのであしからず
当初のイメージ
- タスクを割り振る
- 仕様を把握する
- フロントエンドエンジニアの窓口になる
- 実装もして、エンジニアとしてもレベルアップする
開発初期の頃は前述の一般的な役割に近いものをイメージして取り組んでいました。
「タスクを割り振る」は私（フロントエンドのリードエンジニア）の場合、PMが作ってくれたチケットをフロントエンドメンバーに割り振る。
「誰に」とか「どの順番で」とかを考えてパズルする感じです。
- 同じようなコンポーネントが必要なタスクは同じ人に割り振る（別々の人に割り振ると作業がバッティングする可能性大）
- デザイン/APIが既にできていて進められるタスクか？
「仕様を把握する」はリードエンジニアに関係なく必要なことだと思いますが、開発メンバーをまとめる立場として特に自分は全体を把握しておく必要があるな〜と考えていました。
工数の少ないメンバーも複数いたので、スムーズに伝達できるようにするためにも自分がしっかり全体を把握せねばと思っていました。
「エンジニアの窓口になる」はPMやバックエンドエンジニア、お客さんとのやりとりをする際に基本自分が前に出て話をするという感じですね。
それらに加えて、実装もやって知識やスキルも身につけるぞ！！と意気込んでいました。
不安はめっちゃあった
「リードエンジニアやったるか！」と引き受けたわけですが、内心まぁめっっっっちゃ不安でした！！
「自分がリードエンジニアで大丈夫なのか?」という漠然とした不安（これはまぁ今も少なからずありますが）。
プロフィールにも記載した通り、自分はスキルが高いとか経験が長いとかいう方では全くなく、そんな自分がやっていけるのだろうか..?というのは常に思っていました。
ただ一方で、「ほんまに無理そうならそもそも打診されてないか」「なんとかなるでしょ！」という図太さも持ち合わせていました。これはある意味大事なマインドだと思っています（笑）
そんなこんなで不安を抱えつつも、とにかく状況に応じて臨機応変に動いていくかー！って感じででトライしていきました。
行き詰まった
さっそく行き詰まりましたw
これは実際に問題があったというよりは、行き詰まったと感じていたのはおそらくは自分だけで、とはいえ不安や焦りでパンクしそうな状態だったので「行き詰まった」と表現しています。
リードエンジニアあるある（？）
いざ本格的に開発が始まって1ヶ月くらいで、不思議な現象が起きていることに気がつきます。
- 何もしてない（感覚的には）のにもう夕方じゃん！
- 自分のタスクが進まない！ てか自分の進捗だけ悪くない？!
開発メンバーからの質問や仕様確認、お客さんやチーム内への確認、と色々対応していると実装の時間が全然取れない！
故に自分の実装タスクが遅れ、毎度すいません..という感じに🥺
メンバーへのタスクの割り振りや仕様把握、必要な説明などはそれなりにやっていたわけですが、自分の（実装の）タスクの進捗が悪いというのがまぁ精神衛生的に悪かったですね..
リードエンジニア経験者の話を聞いたところによると、これは割と陥りやすいものだそうです。
決断恐怖症
また、ありがたいことに開発メンバー間では設計や実装ルールの議論が活発でした。大まかなルールや方針は決めていても、実際に開発を進めてたら「こういうケースはどうなの？」っていうのが出てくるのは良くあることです。
そんな時に「このプロジェクトではこっちでいきましょう！」っていうのをリードエンジニアである自分がある程度示すべきだったのですが、最初の頃はどっちつかずな態度をとってしまっていたなと思います。これは猛反省です..
そのため、せっかく実装のルールや方針のアツい議論が起こっても、後半で「...」と微妙な空気に。それだけじゃなく、「これ結局どっちなん？！」って実装に迷う時間も少なからず生まれていたのではと思います。
振り返ると最初の頃は自分への自信のなさから、「決断する」ということがめちゃくちゃ怖かったですね（今も得意ではないですが）。
そんな感じで、この頃は全部自分が把握して、確認して、実装もやって、...という感じでいっぱいいっぱいでした。そのくせ自信はないという..w
「あーなんかこのままだと良くない気がするなぁ..」と悶々と悩んでました。
吹っ切れた
その後少しやり方を変えていったら吹っ切れたというか自分の中でうまく回り出した感覚がありました。それを振り返ってみます。
「こうあるべき」より、自分で決めろ
そもそもなんで苦しんでいたかというと、理想とする自分と現実自分のギャップが大きかったことだと思います。
なんとなく「リードエンジニアは技術でサポートできるべき」「だから自分もみんなと同じくらい実装ゴリゴリ進めなきゃ」という考えに囚われていました。
Relicの他のプロジェクトで今までにリードエンジニアをやっていた方は、重いタスクを率先して巻き取るなど技術的に活躍されている方が多いイメージがありました。でも、自分は違うやり方でもいいんじゃないかなと考えるようになりました。
自分は何に注力すべきかを考えた
最初の頃は全部自分が把握して、確認して、実装もやって..と全部自分がやらなきゃ！と思っていたわけですが、残念ながら私はそんなに器用な人間ではないし、キャパもありません。
自分がリードエンジニアとして何に注力するべきか？と考えた時、なんでもこなすことではなく、まずは第一フェーズの開発を完了することが大前提じゃないか！と思い、開発がスムーズに進められることにコミットしようと決めました。
「いやそりゃそうだろ！」ってツッコミが入りそうですが、
恥ずかしながらそれまでの私は「なんとなくこういう感じかな？」というイメージだけでやっていて、「自分の役割はこれだ！」というのはこの段階で初めて意識した感覚でした。
責任を全うするならまわりを頼れ！
自分は開発がスムーズに進められることにコミットしようということで、実装に関しては難しそうなもの・重めのものは他のメンバーに任せ、自分はある程度方法が分かっているものなど比較的軽めのものに寄せました。
それまでは、マネジメント的なタスクをやっている時には「この実装が..」とか、実装している時には「あれ整理しなきゃ..」といった感じで一つの業務に集中できておらず、常に焦っている感じでした😅
「これは自分が責任持って対応すること」「これはメンバーがやってくれること」と、自分の役割とメンバーに任せる役割をきちんと認識することで、不思議とそれからは一つのことに安心して集中して取り組めるようになった気がします。
それまでの自分には「責任感を一人で抱え込むことと履き違えるな！」と言いたいですね..笑
自分のスキルを磨く意味で実装もなるべくやりたかったのですが、メンバーのコードレビューを通して学べる部分がかなりたくさんあったので結果的に良かったです！
方針は共有しよう
そんな自分の意識の変化があったわけですが、これは自分の中だけで完結させずにメンバーに改めて伝えました。
「今さら改めてなんだろうとか思われるかな..」とか個人的に勇気が入りましたが、各自の役割について全員で再認識することで自分の意識にも根付いたので、改めて伝えて良かったなと思っています。
その後
そんなこんなで、無事に開発の第一フェーズのリリースをすることができました！
今回リードエンジニアにチャレンジする中で自分の中の分岐点のようなものがあったわけですが、これは急にやってきたわけではなく、色々と悩んでいた時に、リードエンジニア経験のあるメンバーがアドバイスをくれたり相談に乗ってくれたりしたからこそです。
悶々と悩んでいた時は本当に救われました。ありがとうございます！
フェーズによって定義も変わるのかも
話が少し逸れますが、Relicで説明されているリードエンジニア像や求められる役割について冒頭の方で紹介しました。
Relicで説明されている「リードエンジニア」
「こういう事業を作ろう」となったときに形にしてくれる人
Relicという新規事業を作る会社の中で、アイディア、戦略、企画を具現化するためには欠かせない要のポジション
Relicのリードエンジニアに求められるもの
- 事業家目線
現在も私はこのプロジェクトを担当していますが、今はだいぶ少人数でやっています。
そんな今意識しているのは、「ユーザーはこれで使いやすいか?」「そもそもこの機能を入れたい理由はなんだろう?」といったことで、「〇〇の機能のあるサービスを開発する」という視点から「サービスそのものの価値を考える」という視点に変わってきたなと感じます。
そして今やっていることがRelicのリードエンジニア像の部分なのかな〜と感じています。
当初はこれに正直ピンときていなかったのですが、フェーズが変わった今はとてもしっくりくるので、プロジェクトのフェーズによっても定義や役割は変わるものなのかもしれません。
チャレンジして良かったこと
リードエンジニアをやってみて感じたことを振り返りましたが、良かったことのひとつは当事者意識が爆上がりしたことです。
それまでも全体の状況を想像するといったことはしていましたが、実際にリードエンジニアとして関わって全体を俯瞰してみたことで、見える景色が全然違いました。
この視点に立ったことでよりやりがいを感じたり、プロジェクトを進めていく面白さを感じたりしています。
まとめ
つらつら書いてきましたが、この経験を通して私が伝えられることがあるとすれば以下の3点です。
- 自分はどういう形で役割を全うしたいのか考えよう
- やりたい方向性をチームに共有しよう
- ひとりで抱え込まずにまわりを信じて頼ろう
これはリードエンジニアだけでなく、あらゆることに言えそうですね！！
読んでくださりありがとうございました！
おまけ
ワイが奮闘してるRelicは仲間を絶賛募集しとるやで！
地方にもどんどん拠点を増やしてんねん！
少しでも興味があったらカジュアル面談しませんか🙌