😇
SIerからスタートアップに転職して気付いた本当の自分らしさ
はじめに
私が入社してから約2年での挫折と学びを紹介したいと思います。
転職のきっかけ
経緯
前職では新卒でSIerに入社し、転職サイトの機能改善のバックエンド開発を担当していました。
業務フローは、プランナーが企画し、私を含めたエンジニアチームが設計〜リリースまでを行っていました。
当時自分がリリースした機能の効果検証で売上やCVRが下がることがあり、自分が企画した内容ではないのに大きくショックを感じたことを覚えています。敗北感を感じました。
その経験から、インクリメントしていくプロダクトへの思いが強まり、ユーザーが本当に嬉しいと思っている機能や本質的な課題解決を目指すようになりました。
自分の野望を叶えるために、企画・要件段階から自分の意思を反映し、一貫した開発をしたいと思うようになりました。
当時は企画〜リリースまでの開発リードタイムを短くすることにモチベーションがあったのですが、エンジニアチームの中では改善するものの、大きな改善をしたい場合はチームの枠を超える必要がありました。
SESの制約や会社間での説明責任など、乗り越えないといけないハードルがいくつもあり、当時の自分の力では野望を実現できず環境を変える決意をしました。
シェルフィーに入社した理由
シェルフィーに入社したのは、エンジニアの責任範囲が広く、「どんな課題を解決すべきか」「どんな価値を提供すべきか」など、ユーザーが根本に抱いている課題をしっかりと理解し、実現していたことが非常に魅力的に感じたからです。
プロダクトチームだけではなく、セールスチームやグロースチームが一つのプロダクトに向かっている姿から、組織としての目線合わせをとても大切に捉えていると思いました。
OneTeamで向き合っている環境が今までのSESとは真逆のように思え、ここでなら自分の野望を叶えられると思いました。
シェルフィーに入社してから
入社当初
自分の野望を叶えられると息を巻いて入社をしたものの、自分で要件を決めることの難しさに直面しました。
今までは要件が決まったタスクの設計・実装をしてきましたが、シェルフィーでは「なぜその機能が必要なのか」、「どんな課題があるのか」、「どのように解決すべきなのか」といった今までの何倍も抽象度が高い問題を解決する必要がありました。
最初は、はやる気持ちからふわっとした要件で進めてしまい、最後に大きな手戻りになることもありました。
上手くいかなくて、日報で反省してました
前職でのやり方は通用しないと感じ、実際の業務フローや建設業界での法的ルールなど、ドメイン知識を頭に詰め込みました。ドメイン知識が揃うとやりたい事と目的の背景が明確になり、自ずとあるべき理想の状態の解像度が高まります。
そのあるべき理想に近づけるイメージを持ちながら、仕事を進めることができるようになりました。
同期入社したメンバーがだんだん遠くなっていく事への焦り
機能要件を決めることがシェルフィーに入って一番大変だったことではありません。ふと周りを見渡すと同期入社したメンバーが次々にタスクやプロジェクトをリードしていく姿から、自然と自分と比較するようになりました。
私と同じ時期に入社した同期が5人いました。技術力の差よりも、スタートアップとして0→1を生み出したり、整っていない構造を改善していたり、みんな自らの力で道を切り開いていました。
同期が活躍する姿を目の当たりにし、自分ができる範囲の狭さを痛感しました。
当時は自分も少なからず成長できていると思っていましたが、同期の非連続的で急激な成長を間近で見て劣等感を感じ落ち込みました。
他者比較からは何も生まれないのは分かっていますが、自信が無いが故の行動だったと思います。
ターニングポイント
自分を見つめ直すきっかけ
劣等感に苛まれる中、外部連携バッチシステムの0→1開発を担当することになりました。
3人制のチームで、DDD設計を監修するLennonさん、PjM＋開発をHyuga、開発を私が担当しました。
DDD設計を進めているLennonさんの姿、同期でバリバリマネジメントするHyugaの姿から、自分の無力さを感じ心が折れそうな時もありました。
非常に悔しかったです。
今までの行動や経験も着実に力になっていると思っていたのに、全然足りない、追いつけないのはなぜなのか。。。色々考えを巡らせました。
そこで気づいたのは、やりたいことに夢中になっていないことでした。
自分がバリューを発揮できることは何か、そもそも何がしたいのか、何を求めて転職したのか、ゼロから考え直しました。自分のやりたいことは、プロダクトを通してユーザーが求める本質的な課題解決をすることでした。
自分が本当にやりたい事と向き合う
自分のやりたいことを実現するために、ユーザーが求める事とは何かをプロダクトの思想や戦略を通して考え直しました。
当時プロダクトは過去の技術負債と向き合うべく長期施策を重要視し、ビジネスや市場の変化に強い開発組織を目標に動き始めたところでした。
プロダクトの状況と自分が本来やりたかった本質的な課題解決から、今できることは何かを深堀りました。
ユーザーにとって嬉しいことは、効率的で作業フローにあった機能をいくつも提供し、プロダクトのクオリティを上げ続けることだと思います。
しかし、継続的に提供することは難しいことです。開発において、時間の経過とともにビジネスで目指す価値やシステムに関わる組織の変化、テクノロジーの進化など、たくさんの変数があるため、将来技術負債にならない構造にすることは不可能です。それにも関わらず、負債は後続の価値提供を遅らせる大きな要因になります。
負債に真正面から相対し、継続的に価値提供できる状態にすることが大切だと気づきました。
今までは正しい機能を素早くリリースすることが一番だと思っていました。しかし、負債になりにくい構造にすることが長期的なユーザーの課題解決の土台となり、そこにバリューを発揮することはユーザーが求める本質的な課題解決に繋がります。
自分の中で事業ミッションを落とし込み、自分のやりたい事・できる事を照らし合わせ、自分が本当にやりたかったことを事業を通して明確にしました。
もやが晴れたあと
自分のやりたいことをプロダクトを通して考えた結果、自分のモチベーションがよりシンプルになりました。
エンジニアとして自分がプロダクトを前進させるために、どんなバリューを発揮できるかを自ずと考えて行動できるようになりました。
ファーストステップで始めたのは、テストコードの設計です。
当時、アプリケーション側のテストコードは書き方がばらばらだったり、不要なデータが共通化されていたり、メンテナンスしづらい状態でした。
一緒にプロジェクトをしていたLennonさんやHyugaに相談しながら、バッチシステムで得た知見を活かしテストコードガイドを作り、展開しました。そこで初めて、自分がチームや組織に対してバリューを発揮できたと実感しました。自分で選んで行動することで、初めて自分らしさを出せたと思います。
その後も技術負債の解消プロジェクトがチーム内で走りはじめ、スクラムマスターとしてチームのスキルの底上げに関わったり、採用活動に参加して組織拡大に努めたりしました。
自分のやりたい事・発揮したい事の方向性が見えると自分に合ったバリューの発揮の仕方が分かります。
これからも、事業貢献と自分のやりたい事を照らし合わせ、自分らしくシェルフィーのエンジニアとしてユーザーの本質的な課題解決に寄与していきたいと思います。
最後に
誰しもが何か思いがあってエンジニアになったと思います。
少なくとも、何らかの体験から得られるやりがいや幸福から、エンジニアを続けているのではないでしょうか。
それでも、年齢や周りとの差、環境から焦燥感を感じ、本来自分が抱いていた野望を忘れたり、諦めたりします。自分がなりたい姿から外れていても気づかないことはあるあるだと思います。
大切なことは、その状況で自分のやりたい事と向き合うことだと思います。
自分の本当にやりたい事を深ぼる中で、プロダクトを通して自分はどんな価値が提供できるのかに気づき、自分らしいバリューの出し方に出会えるかもしれません。
エンジニアとしてくすぶっていた自分の挫折と成長の経験談が誰かの参考になれば幸いです。