※この記事は、2024 Speee Advent Calendar17日目の記事です。 昨日の記事はこちら
はじめに
こんにちは。24卒エンジニアの木下です。 学生時代は個人開発や友達と高専プロコンなどのハッカソンに参加しており、実務経験などは特にない状態でSpeeeに入社しました。 現在はイエウールという不動産売却の一括査定サービスの開発をしております。
この記事では、個人開発・ハッカソンなどの開発経験しかなかった自分が入社して、自分自身の課題の解像度が上がった話を書ければと思っています。 実務経験がなく、業務のイメージがつかない学生さんに読んでいただけると幸いです。
Speeeに入社したきっかけ
自分は高専出身で学生時代はプロコンやハッカソンなどのチーム開発に取り組んでいました。 チーム内では「こういうものを作りたい」、「ユーザーにとってこういう機能があると体験が良くなるはず」という観点で本気で議論をしている中、自分は「先生やみんながこの機能あった方がいいって言ったから作ろう」という思考でユーザーに必要な開発や自分が作りたいと思えるプロダクトにしていこうとする行動が足りていませんでした。 高専プロコンでは優秀なアプリ・アイデアなどに対して賞があるのですが、賞を取れず悔しがったり、取って喜んでる他の学生がとても楽しくアプリ開発しているように見え、自分も「ユーザー価値」という観点で考え開発できるエンジニアになりたいと感じました。
そんな中就職活動を通して色んな企業を見ていくうちに、多くの面談・面接で自分自身の過去や経験から考え方などを深掘っていただき、最も自分の考え方に成長を感じることができたSpeeeに入社しました。
実際に入社してみて
学生時代にユーザへの価値を考慮できていないことに課題感を感じていたものの、プロコンやハッカソンなどで物を作って動かすこと自体はできていたし、それさえできればエンジニアとしての仕事もなんとかなるのでは？という状態で仕事を始めました。 仕事が始まってすぐの頃は自分の先輩方がリファインメントの際に施策の意図や懸念点をプランナーさんと会話している中、自分は会話についていけず何がわからないのかもわからない状態が続きました。 リファインメントとはプランナーさんから開発して欲しい施策・機能の説明をしていただき、プランナーさんと開発者の間で認識を揃える会議のことです。
そんな中でも先輩方を頼って開発自体はなんとか進めることができ、そのうち施策の内容についても会話できるようになるのかなと思いながら仕事をしていました。 しかし、徐々に自分で調査を行い開発計画を立てるフェーズになってもなかなか疑問というものが湧かず、「何か気になる点はありますか？」とプランナーさんから聞かれても正直技術的に多分作れるし、特に問題なさそうぐらいの感覚で開発を進めていました。
そんなスタンスで仕事をしていてうまくいくはずもなく、たくさん失敗しました。 例えば、
- 認識・調査が浅いことによって、リリース直前に周りを頼りスケジュールを遅らせてしまう
- 認識が違うままリリースしてしまう
- 自分の確認不足で意図しない挙動を本番で起こしてしまう
などです。
これらの失敗が起きた理由を深掘ると、会話についていけていなかったのにそれを放置していたことが一番の要因でした。
学生時代のチーム開発と実務の違い
学生時代のチーム開発や個人開発ではほとんどが自分が書いたコードやレビューしたコードでした。 把握していない機能やコードについてはほぼゼロで目標を達成するために必要な機能なども数えられる程度です。 達成するべき目標も仕様も単純なため、疑問を放置していても特にミスることはないですし計画自体を遅らせてしまうこともありませんでした。
しかし実際の実務では、ほとんどが自分が入社する以前に先輩たちが書いたコードです。今でも開発する際に知らない仕様やコードがどんどん出てきます。 新しい機能の仕様だけではなく、これらの機能にデグレを起こしてはいけないという条件もついてくるので学生の頃に考えるべき仕様の数とは段違いでした。 ここまで違う環境の中、学生の頃と同じ受け身のスタンスで開発を続けたためこれらのミスが生まれたと思っています。
これに対してどういうことに取り組んだのか
具体的に
- 朝会・昼会やタイミングで実装イメージを共有することで開発者同士の認識違いを減らす
- リファインメント前に準備会を開き、懸念点・疑問点をリファインメントで潰す
- 受け入れテスト項目を作成し、デグレや認識違いが発生していないかを確認する
などのアクションを起こしました。 自分と先輩との差分は、経験値やプロダクトに対する知識量がとてつもなくあることと仕様に対する調査量だと感じたからです。
それぞれのアクションの意図や始めたきっかけは以下のとおりです.
朝会・昼会やタイミングで実装イメージを共有することで開発者同士の認識違いを減らす
これまでも朝会や昼会は存在していたものの、主に自分の進捗状況の共有に留まっていました。 しかし、不明点の共有を行うようになってから、レビューラリーが発生しなくなり、結果として開発計画が順調に進むようになりました。 そこから試行錯誤し、今ではテーブル設計や実装のイメージをIssue上に記載し、説明を行うことで認識の違いがその場で明確になり、スムーズな意思統一が図れるようになりました。
リファインメント前に準備会を開き、懸念点・疑問点をリファインメントで潰す
本来リファインメントで話すべきだった内容が自分の知識不足や調査不足で会話できず、認識違いが発生することが度々ありました。 リファインメントで必要な知識・情報不足が課題と感じ、自分の調査した内容で十分なのか、それ以外に懸念点はないのかを先輩に確認していただくようにしました。 最初は準備が不足し、準備会での会話自体もなかなか細かな部分まで会話できていなかったのですが、今ではリファインメントで認識の違いやより細かな内容を会話するための準備ができるようになりました。
受け入れテスト項目を作成し、デグレや認識違いが発生していないかを確認する
受け入れテスト項目は、施策の達成条件である仕様とデグレが発生していないか懸念のある部分をあげたシートです。 リリース直前に認識が違うことが発覚し、計画を遅らせてしまうことが何度かあり、実装前に自分視点のテスト項目を作成しプランナーさんに共有することで認識をそろえるようにしています。
これらのアクションを取ることで、認識違いなどによる開発計画を遅らせることが減り、少しずつ計画に対する余裕と事業に対する知識がついてきたことで「ユーザーにとってこういう仕様であれば体験がよくなるはず」という考え方が少しずつできるようになってきました。
今後の目標
学生の頃のスタンスではリファインメントや開発開始前の段階で疑問を生み出すためのアクションを取ることができていませんでした。 リファインメント前にコードレベルで調査し、懸念点・実装イメージを出すことで自然と疑問が生まれてくるようになってきました。調査のレイヤーを低くすることで既存のシステムや議論するための知識がつくと考えていますし、少しずつその実感を感じています。 今後は、自分が開発した機能や施策がどう事業に影響を与えているのかを考え、ユーザー価値を最大化するためのアクションを取れるエンジニアになりたいと考えています。
最後に
Speeeでは一緒にサービス開発を推進してくれる仲間を大募集しています！
新卒の方はこちらより本選考に申し込みが可能です！
キャリア採用の方はこちらのFormよりカジュアル面談も気軽にお申し込みいただけます！
Speeeでは様々なポジションで募集中なので「どんなポジションがあるの？」と気になってくれてた方は、こちらチェックしてみてください！もちろんオープンポジション的に上記に限らず積極採用中です！！！
