メガベンチャーでの二年間：カオスと成長の記録

ソフトウェアエンジニアとしてベンチャーからメガベンチャーに転職して、2年ほどが経ちました。そして今再び転職活動をしているわけですが、そこで自分がやったことや感じたことを記録として残しておこうと思います。

一言で表すのであれば、「カオス」の連続でした。しかし、そのカオスの中でタスクをこなす「超人」の集まりという印象も受けました。

課題の具体例：タスク管理の不在

カオスの例として、特に驚いたのが、チームレベルでのタスク管理がほぼ行われていないことでした。なんとなく個人個人がチケットを作成してはいるものの、チームとしての決まりは存在していませんでした。誰がどのタスクに取り組んでいるかは分からないし、そのタスクがいつ完了するかも不明です。

この状況では以下のような問題が発生していました：

負荷の不可視化: 誰にどれだけの負荷がかかっているのか理解できない
キャパシティプランニングが不可能: チームとして何ができて何ができないかが説明できない
無根拠な合意: 根拠もなく「できる」と合意し、直前になってキャパ不足に気づく
アドホックなミーティングの増加: タスク進行状況を共有するための（本来であれば）不要なミーティングが多数存在する
情報格差の発生: DMや1対1で確認し合うため、チーム内で情報の偏りが生じる

「何ができないか」をPM側に説明できないエンジニアチームの状態は非常に危ういと思います。直前になってできないことに気づくことが多いため、プロジェクト遅延や関係各所との調整など、多くの人に迷惑をかける結果となります。

役割に応じた責任の分割も不明確で、落ちているボールを「異常なキャパを持った人たち」が拾うことで回っている状態であり、特定の「できる人」に強く依存していることに危うさを感じました。

テックリードとしての取り組み

そうした課題感から、テックリードに就任してから本格的な改善に着手しました。自分が担当していたのは5人のチームで、各メンバーが個別に実装を進めており、チケットなし・イテレーション計画なしという状態でした。Engneering Manager, Tech LeadやPMからはタスク状況が見えず、遅延リスクも把握しづらい状況にありました

そこで目標は次のように掲げました：「すべてのタスクをチケット化し、誰が何をしているかリアルタイムで可視化できる状態」です。

そのために、以下の3つのアプローチを同時に進めました。

1. JIRAの導入と運用ルールの徹底

まず基盤となるツールとルールを整備しました。チケット作成手順の文書化し、ラベル付けルールの統一などを行いました。また、Target Timelineの入力を必須とし、大雑把でも良いのでタイムラインを見積もれるようにしました。最初の1~2週間は色んな意見もありましたが、意識面での働きかけを繰り返し行うことで納得してチケットの運用を進めることができました。

意識面での働きかけとしては、チケット化のメリットについて粘り強く説明を続けました：

負荷の可視化: 誰にどれだけの負荷がかかっているのかチーム全体で理解できる
キャパシティプランニング: チームとしていつまでに何ができる・何ができないかを根拠を持って説明できる
情報の一元化: カンバンボードを見れば誰がどのタスクに取り組み、どれくらいの時間をかけているかが分かる
不要なミーティングの削減: アドホックな進捗共有ミーティングが不要になる
個人の貢献の可視化: 各自の作業がプロジェクト全体にどう貢献しているかが明確になる

特に重要だったのは、単に「ルールだから」と押し付けるのではなく、個人とチーム双方にとってのメリットを具体的に伝えることでした。抽象的な説明ではなく、「チケット化により、毎週1時間ほど取っているタスク状況共有のためのミーティングをなくすことができる」といった具体例を使って説明しました。

2. 習慣化のためのルーティン作り

継続性を確保するため、2つの定例を導入しました：

JIRAタイムラインアップデート・もくもく会（週1回）

内容: 全員でJIRAを開いて、自分のタスクのステータスとタイムラインを更新
工夫: 堅苦しさを軽減しつつ、実際に作業を行う時間を強制的に確保する。また、この作業を行う時間を同期で行うことで運用に対する意識のズレや違和感があればその場で共有して認識をそろえる。

Syncミーティング（隔日15分）

参加者: エンジニア全員 + PM
内容: JIRAのカンバンボードを見ながら進捗共有
効果: PMはこれまでエンジニアメンバーがどのようなタスクに取り組んでいるのか把握できない点に課題を感じていた。小さなSyncミーティングを実施することで、PM側はエンジニアの状況を把握でき、PM側は優先度を上げたいアイテムがあれば差し込めるようになり、エンジニア側はリソースが足りないと判明した時に早期の調整が可能になった。

3. サポートタスクの管理統一

見落としがちだったのが、他チームからの問い合わせ対応です：

改善前の課題

Slackでのサポートリクエストが埋もれる
誰が対応するか曖昧で、気づいた人にタスクが偏りがち
対応漏れや、同じサポートリクエストに対して複数人が同時に作業を開始してしまうなどの無駄な重複が発生する

改善後の仕組み

全てのサポートリクエストをJIRAでチケット化
担当割り当てをチームで判断: リクエスト対応に数時間以上時間がかかる場合、デイリーSyncで担当者を決定
対応履歴の蓄積: 同様の問い合わせに対する効率的な回答が可能

達成できた成果

この取り組みにより、以下の具体的な成果を得ることができました

タスク状況可視化の実現
- 全タスクのチケット化完了: カンバンボードを見るだけで担当者・進捗・期限が把握可能
- リアルタイムな状況共有: マネージャーが「今何が進んでいるか」を常に把握できる状態
プロジェクト管理の向上
- 遅延リスクの早期発見: 期限に対する進捗遅れを事前に把握し、PMに報告
- プロジェクト間の調整: 複数プロジェクトのリソース配分を可視化し、早期に調整
チーム運営の効率化
- サポート対応の品質向上: 担当者明確化により回答の質と速度が向上
- 情報共有の簡素化: アドホックなミーティングの削減
- メンバーの負荷分散: 特定の人への依存を回避し、適切な作業分担を実現

地道な活動の価値と発見

ここで挙げた取り組みは、一般的に想像されるテックリードの動きとしては少し異色かもしれません。ただ、こういった地道な活動ができる人、そしてそこに課題を見つけて働きかけ続けることは、メガベンチャーのような優秀な人の集まりであっても価値を生み出すことができるのだと実感できたのはよかったと思います。

優秀な個人のパフォーマンスに依存した組織であっても、プロセスや仕組み作りによってチーム全体の生産性を底上げできるという実感を得ることができました。

キャリア志向への気づき

この経験から感じたのは、やはり自分は一般的に言われるテックリードよりも組織や人により興味を持っているのだな、という点です。

技術で何かを解決することにも興味はもちろん持っているのですが、他のエンジニアと比べると組織や人そしてプロジェクトマネジメントで課題を感じることが多く、そこに対して取り組む熱意もあると感じました。

技術から離れたくはありませんが、将来的にはいわゆるエンジニアリングマネージャーのような方向性も自分に合致しているのかもしれない、と感じることのできるきっかけとなった2年でした。

技術力的な成長と今後の課題

その一方で、技術力的には自分の伸び代は強く実感しました。マイクロサービスを一つ立ち上げるという貴重な経験をすることができましたが、多くのインフラやCI/CD周りは優秀なプラットフォームチームが抽象化してくれているモジュールを使用することで、詳細まで理解せずとも開発・運用ができるようになっていました。

これから先は自分もその抽象化されていた中身に興味を持ち、自分でそこも開発ができるように実力を伸ばしていきたいと強く感じるきっかけとなりました。

最後に

メガベンチャーでの2年間は、カオスな環境の中で多くの学びを得た期間でした。組織的な課題の発見から改善への取り組み、そして自分自身のキャリア志向への理解まで、さまざまな気づきがありました。

次のステップでは、この経験を活かしながら、技術力の向上と並行して組織・人への関わりの両方を追求していきたいと思います。