見出し画像

LINE Growth Technology を退職しました!

こんにちは、nako です。普段は nakometal.rocks でブログを書いているのですが、今回はよりたくさんの人に届くといいな、と思って note に書くことにしました。

2022年6月末で、LINE Growth Technology(以下、GT)を退職しました。
GT には 2019年12月に入社して約2年半お世話になりました。
期間だけで見ると短いかもしれませんが、私自身のキャリアの中でも印象に残る経験になったので、その一部を書き残しておこうと思います。


GT ってなに?

LINE Growth Technology の募集要項ページに書いてあるものがわかりやすいので引用します。

LINE Growth TechnologyはLINEがサービスを運営し成長する中で生じる課題解決に取り組むGrowth開発の専門部隊です。
LINEにとってサービスはリリースがスタート地点です。私たちはリリース後の運営フェーズにおいて、サービス成長に向けた施策実施や運営効率化のためのツール開発等の改善活動が非常に重要だと考えています。
LINEグループで使用するツールの新規開発やサービス運用フローの改善など、特定サービスに紐づかない横断的な組織として、サービスの成長過程で生じる課題解決に取り組み、LINEグループのサービスの競争力向上に私たちは寄与しています。

https://linecorp.com/ja/career/position/1103

という感じで、ここに書いてある通りではあるのですが、よくわからないな、という人も多いかもしれません。「要するに LINE の下請け開発会社でしょ?」なんてちょっといじわるな質問を受けたりしたこともなくはないですが、個人的には下請け会社感を感じることは少なかったです。
会社間の壁がまったくないか?と言われると、ゼロではないですが、それは壁というよりも文化的な背景や組織のサイズ・カラーによるものかもしれません。実際に、福利厚生や制度・設備等の面は LINE とほぼ同じですし、非常に恵まれた環境でした。

難しいのは「Growth 領域の開発」にはさまざまなやり方があるので、その分「何をやっている組織か?」が分かりにくいことです。採用活動においても GT がどんな組織か?を説明するのに非常に苦労しました。
具体的な例をあげると、

  • 組織・ビジネスを横断して利用できる業務ツールの開発

  • データの入稿・配信・審査・監視などのオペレーションを安全かつ効率的に行うためのサービス運営ツールの開発

  • 全社横断的に利用できるプラットフォームの開発

などを行うことが多いです。
面白いのは、これらを発注・指示を受けてそのまま開発するわけではなく、課題の発見・あるべき姿の追求など、事業部・サービス運営メンバーとゼロベースで議論しながら開発していけることです。
興味がある人は、採用イベントやカジュアル面談でぜひ話を聞いてみてください。個人的には、大きな組織には大きな組織なりの良があると感じていて、GT は大きな組織と小さな組織のいいところを両方経験できる良い会社だと思います。


エンジニアから PM へ

前置きだけでシリーズ化できそうな長さになりそうで、若干の不安を覚えはじめたものの、背景が気になる人も多いと思うので簡単に GT 入社までの経緯も書いておきます。

2015年に東京から福岡に移住したあと、高速ファイル転送プロトコルを開発している会社で、Web エンジニア+プロダクトマネージャーをやっていました。

そこでプロトコルを開発している凄腕エンジニアと一緒に働いていると、ふと「エンジニアとしての自分は普通だな。普通に働くことはできるけど、もっと上に行くのは難しいな」と考えはじめました。

技術が好きだし、開発環境の整備や DevOps 活動みたいなことも続けていましたが、プロダクトやプロジェクトマネジメントの方が強みを活かせるし、何より「技術バックグラウンドを持った開発 PM」としての自信がありました。

今思えば「生存戦略」という言葉がしっくり来ますが、好きなことをしながら自分の市場価値をより高める戦略として、エンジニアではなく PM としてのキャリアアップを考えるようになりました。
この時の転職活動でも、GT を含めたくさんの会社の方にお話を聞いたり、内定をいただいたりしましたが、当時はリモートワークもそこまで主流ではなく「福岡といえば LINE Fukuoka!」のイメージもあったので、LINE Fukuoka と同じ拠点で働くことのできる GT の福岡拠点で PM としてのキャリアをスタートすることにしました。


GT でやっていたこと

これらの開発プロジェクトの PM に加えて、

  • Technical PM チームのマネージャー

  • 開発チームのマネージャー(サーバーサイドエンジニア・フロントエンドエンジニアのチーム)

  • PM の採用活動

も経験させてもらいました。一つひとつがとにかく大変で、試行錯誤を重ね、失敗と改善を繰り返した2年半でした。すべて細かく語りたい気持ちですが、本当にシリーズ化が必要になってくるのでやめておきます。資料があるものは資料をリンクしておきました。

直近1年間は LINE公式スタンプ運営ツールの開発に注力していました。LINE公式スタンプは LINE の中でも規模の大きなサービスの1つで、急成長をした背景から裏側の運営はかなり複雑化していました。スタンプ運営メンバーと一緒に複雑化した課題を一つ一つ紐解き、どうやったら安心・安全に運営しつつ、スタンプのクオリティを向上させ、サービスに良い影響を与えられるのか?を考えながらシステムを開発することは簡単ではありませんでした。
データの入稿から審査・配信設定までを一連のフローで行えるようにしたのですが、正直言って社内ツールの部類としては、超高いクオリティに仕上がっていると思います。みなさんにお見せできないのがちょっと残念です。

公開している資料から抜粋。既存の運用を miro で可視化しながら整理した時に、その複雑さを開発チームと運営チームの双方で認識することができました。

大変だったけど、なんとか形にできたこと、そしてこれからも継続してシステムと業務を改善し続けられるのは、サービスが愛され・成長し続けているからであり、なにより、運営チームと開発チームがお互いを信頼して意見を交わし合ってプロジェクトを進めることができたからだと思います。


仕事も PM も楽しくて、忙しくて、そして難しい

社内では、良くも悪くもハードワーカーだと思われていました。そして自分でもそうだな、と思うことが多いです。泥臭く・粘り強く・時にしつこいほど課題と人間に向き合って仕事をしてきました。

それ自体が評価されることもあれば、ちょっとしたバランスの崩れから、うまく行かないこともあります。そもそも「ハードワークでカバーするのはズルだ」と、尊敬する元同僚が言っていたことを時々思い出します。

LINE グループには、半年ごとの360度レビュー制度があり、周囲のメンバーからフィードバックを受ける機会があります。このレビュー結果を振り返ってみると、身に余るほどの良いレビューをもらっていたな、と感慨深くなります。ポジティブなものもネガティブなものもすべて糧になっているのですが、特に嬉しかったのは、

  • 情報整理・課題発見・資料作成・問題解決の能力・ユーザー視点

  • 率直な意見を言うスタイル・会議での調整能力・周囲を巻き込む力

  • 推進力・リーダーシップ

  • 周囲への気遣いやユーモア・丁寧なコミュニュケーション

  • miro や Figma、JIRA や Confluence などのツール理解と使いこなし力

  • 技術的知見・設計への理解やレビュー能力

などを高く評価してもらっていたことです。書いていて少々恥ずかしくなりましたが、本当にたくさんの良いフィードバックをもらったので、一生大切にしようと思います。そしてなによりも嬉しかったのは、

「一緒に仕事をできてよかった」「nako さんがいたからここまでできた」「また一緒に仕事をしましょう」「尊敬しています!」

と言ってもらえたことです。一緒に働いていたメンバーに、また一緒に働きたいと思ってもらえることより嬉しいことはなかなかありません。

一方で、尖った強みは少しでもバランスを崩すと大きな弱みにもなるということを強く感じた2年半でもありました。

率直に意見を言うスタイルが、相手の好むスタイルと反していることもあります。高速にアウトプットをすることは、時に周囲のスピード感・雰囲気と合わないこともあります。
私はチーム内で積極的に意見を交わし合い、課題解決のために全力を注ぐスタイルを好みますが、率直な意見を交わし合うことは実はそんなに簡単なことではありません。信頼貯金、みたいな話もありますが、信頼の基準も人それぞれ違うのです。

そもそも、気づいたこととして「だれでも・いつでも、議論をしたい」と考えている人は意外と少ないということです。
「自分の好むスタイルで、自分のコンディションの良い時に、自分の好む人たちと議論をしたい」と無意識に思っている人はかなり多いような気がします。もちろん自分だってそういう時があります。
人それぞれにコンディションがあり、好みのコミュニュケーションスタイルがあり、信頼関係の作り方や距離感に正解はないのです。

360度評価でも「もっと自分や周囲の話を聞いてほしかった」と厳しいフィードバックをもらうことがありました。
GT でのキャリア後半はマネージャーをやっていたこともあり、自分の意見を言うよりも周囲のメンバーが意見を言える環境を作ることに注力しました。これは実はかなりの時間と労力をかける必要がある仕事で、日中のほとんどがミーティングで埋まることも多かったです。結果として自分のやりたい作業・やらなくてはいけない仕事は早朝や夜にやる、というハードワークルーチンが生まれてしまって、本当によくなかったな・・・と反省しています。

なんでそこまで頑張るのか?って聞かれたら、仕事をすることが好きだからです。目の前に課題があれば解決することに情熱を燃やしたいからです。それが楽しくて仕方がないからです。


マネージャーを経験して得たもの

最初に Technical PM チームのマネージャーとして PM 組織のマネージャーを経験した後、組織改変などもあり、開発チームのマネージャーをやることになりました。

正直言って、マネジメントよりもプレイヤーとして仕事をする方が合っていると思っていました。上司には「マネージャーは向いていないからプレイヤーとして頑張りたい」と相談したりもしたのですが、
「マネージャーをやらなくても nako さんへの期待値は変わらないよ」と言われて諦めましたw 文字で書くと辛辣な感じもしますが、それを正直に伝えてもらったことには感謝していますし、納得感もありました。

開発チームのメンバーは、普段同じプロジェクトで一緒に働いているメンバーでした。つまりエンジニアメンバーは常にマネージャーと一緒に働くことになり、マネージャーはエンジニアではなく PM という状態です。これってメンバーにとっては嫌じゃないのかな?とか、エンジニアリング能力を正しく評価できるのだろうか?と不安がありました。

解決方法として正しかったかどうかはわかりませんが、私はそれらの不安や自分の強み・弱みをすべて包み隠さずに、最初にメンバーに伝えました。
メンバーからしてみれば「マネジメントは苦手なんです・・・」と言ってくるマネージャーに不安があったかもしれませんが、チームのメンバーとより良い信頼関係を築くきっかけになりました。

マネージャーがマネジメントを苦手としている分、チームメンバーみんなでフィードバックをしあって助け合おう、というシンプルなルールを持ちながら、良いチームを目指しました。
エンジニアリング能力の評価については、他のエンジニアリングマネージャーにも協力をお願いしたり、私自身もできる限りコードを読んだり、設計やアーキテクチャを深く理解しながら進めるようにしていました。メンバーも私自身の技術的素養や理解ついて一定の評価をしてくれていたので、これについては思ったほど問題にはなりませんでした。

これはただのチーム自慢ですが

チームで必ず1日1回はプロジェクトの課題について議論する時間を作りました(Zoom でやっていました)
はじめたばかりの時は「何かありますか?」と聞いても誰も意見を出さないことも多かったのですが、驚くことに1年後には全員が毎朝意見を交わし合っていました。誰かがアイディアや課題を出したらそれを実現・解決するためにみんなで議論をするし、反対意見もどんどん出すし、自然と全員が自ら仕様・設計を深く考えるようになっていました。誰もがミーティングの準備をするし、事前にドキュメントに書いて整理するようになりました。
私たちのチームは、メンバーそれぞれが家庭のこと・自分のことを一番に考えていたし、みんな休みも取るし、フルリモートで入社したメンバーには会ったこともないし、朝型の人もいれば夜型の人もいました。オンラインコミュニュケーション施策や飲み会もほとんどやりませんでした。雑談はするけど、必ずしもプライベートなことを話す必要はない、としていました(もちろん、したい人はして OK)
それでもとても仲が良かったし、助けあうことができたのは、みんなが課題に対して真面目に取り組み、プロジェクトのことについて毎日議論していたからだと思います。
この変化は本当に素晴らしいし、周囲の人からも「いったいどうやってそういうチームになったの?」って聞かれますが、まだ言語化できていません。

1on1 は苦手

1on1 はあまりたくさんはやりませんでした。クローズドなコミュニュケーションに苦手意識があったし、余計なことを言ってしまいそうで怖かったからです。でもメンバーのことをきちんと評価できるようにしたかったし、できればみんなに良い評価ができるようにしたかったので、苦手ながらも時々 1on1 をやりました。

1on1 ではメンバーが自己開示をしたり、モヤモヤしていることを言語化したり、整理するためのサポートをしました。技術が好きで真面目で優しく控えめなメンバーが多かったので、より良い評価につなげられるように、成果やアピールポイントの言語化を一緒にやったりしました。

メンバーが組織の中で必要な経験をして成長していくために、それぞれのキャリアや目指す方向性などについても話をしました。エンジニアのキャリアは1種類ではなく、ざっくり分けても7つくらいあるよね、とかを話しました(思いつきで分けたこの7つが結構良い感じで、その後 GT 内でよく使いまわされていました。正確な内容は忘れてしまいましたが、気になる人は GT のメンバーに聞いてみてください)

1on1 の時は、会社で提供されている Boxnotes にリアルタイムにノートを取りながら話をしました。実は 1on1 やミーティング・リモートワークのノウハウは結構たくさん持っているのですが、経験や感覚でやってきてしまったので、いつか言語化してアウトプットしたいです(メンバーから note 書いてくれたら購入します!、と言われたので、やらないと・・・)

プロジェクトはこれからも長く続きます。開発チームのメンバーと一緒に仕事をすることは楽しく、まだまだ解決したい課題もたくさんあったのでずっと続けたいと考えていました。


New Chapter へ

New Chapter って言ってみたいだけだったのですが、楽しくてやりがいのあるプロジェクトを卒業し、今後のキャリアややりたいことに向き合うために、転職をすることにしました。

本来、退職エントリはもっと実績的なことを書いた方がいいと思うのですが、本当に大変で楽しい経験だったのと、時々こんなダメなマネージャーがいるよって記事もあった方がいいかな、と思って書いてみました。

また、意外なことに今回の退職を機に社内のたくさん人から個別に連絡をもらったり、会うことができたり、キャリアの相談を受けたりしました。
こんな私でよければ、いつでも相談にのります。気軽に Twitter DM とかください。
エンジニアから PM へのキャリアチェンジに悩んでいる人、IT 業界で働く女性でキャリアに悩んでいる人、PM ってなんだろう?って悩んでいる人などの力になれたらうれしいです(福岡移住の相談でもいいです)

転職活動についてや、新しく入社する会社のことは、入社エントリに書きました!nako の New Chapter に興味がある人がいたら、こちらもあわせて読んでみてください。


この記事が参加している募集

退職エントリ

この記事が気に入ったらサポートをしてみませんか?