Retty Tech Blog

実名口コミグルメサービスRettyのエンジニアによるTech Blogです。プロダクト開発にまつわるナレッジをアウトプットして、世の中がHappyになっていくようなコンテンツを発信します。

社会人2年目の自分に言い聞かせたい3つの学び #22新卒tech_blog

はじめに

22卒プランナーの今井です。
Rettyに入社して早くも6ヶ月が経過し、振り返りTech Blogを書く企画の6人目となっています。

前回は三野田の「新卒アプリエンジニアがRettyのWebチームで修行して学んだこと」でした。

engineer.retty.me

自己紹介

入社して半年間はデータアナリストとしてプロダクトマネージャーの意思決定支援やデータ基盤開発を行なっていました。 例えば以下のような業務を行っていました。

  • paypayキャンペーン効果最大化の課題特定分析
  • ネット予約数を増やすための施策の効果検証
  • 数値モニタリングダッシュボード作成
  • dbtの導入に伴った基盤開発業務

9月以降はプランナー(ジュニアPM)に異動になり、課題発見のみならず施策を考え課題解決する領域にも関わることになりました。 担当領域はRettyのスマホWEBサイトの店舗ページの改善になります。
以前よりも写真などが見やすくなっていると思いますのでぜひチェックしてみてください。

retty.me

より業務内容を知りたい方は以下の記事を参考にしていただければと思います。

engineer.retty.me

社会人2年目になっても意識したい3つの学び

最近、過去の日報を掘り起こして振り返っていたのですが、今日学んだことが数ヶ月前の自分も既に似た学びを得ていたというケースがありました。
新しいことを学びたてのフェーズではそれを思い返す機会がないと忘れがちになります。 そこで今回、今後も意識したい重要な学びを書き留めることで未来の自分が思い返す機会を作れたらいいなと思い「社会人2年目の自分に言い聞かせたい3つの学び」というテーマにしました。

①やれるかどうかで考えすぎない

プランナーへ異動になって間もない頃に大きな壁にぶつかりました。
施策を考えていく中で、自分の中でアイデアをうまく発散できなかったのです。
具体的には、とある施策に効果が生まれた時にそれを抽象化させて横展開させるアイデアなどです。
私はなんて頭が固い人間なんだと落ち込みました。
そこで、その悩みを先輩にぶつけた時に、「話を聞く限りだとアイデアを考える時にそれがやれるかどうかで考えすぎだよ。君が思っている以上に実現可能な施策はあるんだ」と言われました。
その時、アイデアが思いつかない要因は自分の中でこのアイデア実現することが無理だと無意識に選択肢から外してしまっていたことだと気づきました。
それからは、アイデアを考える時は発散と収束を意識し発散フェーズでは実現可能性という観点を考えないように意識しています。

②苦しくても自分と向き合い考え続ける

これはデータアナリスト時代の話です。
dbtというツールをデータ基盤に導入するPJ(詳しくはこちら)がありそこで文系出身ながら開発業務に携わることになりました。
最初はタスク内容や都度発生するエラー文等が分からず悲鳴を上げていました。作業が詰まった時は、先輩に聞くほうが進捗すると思い周囲を巻き込んでいました。
しかしある時、先輩に「目が泳ぎすぎだよ。もっとドキュメントやエラー文を辛くてもかじりついて読む癖をつけたほうがいい。」とFBをもらいました。
そこでFB通りにエラー文や公式ドキュメントと一言一句向き合ってみることにしました。最初は専門用語ばかりで読むのが辛かったものの、時間をかけていると徐々に問題の原因発見や解決を自走してできるようになっていきました。
そして、この経験を振り返ってみると、自分の本音のようなものに気づきました。
その本音とは、作業が詰まった時に先輩に聞く行為は、周囲を巻き込んで業務を前進させるという合理的な考えから辿り着いたものではなく、文章が硬いドキュメントを読むという辛い作業から逃げるためだったということです。
この経験を経てからは何か壁にぶつかった時に人を頼るのも大切ですが、苦しくても自分と向き合い、少しの時間で解決できると思わず考え続けることも重要だと思うようになりました。

③施策は仮説検証であるという姿勢を持つ

これはプランナーとして異動になった頃の話です。
私はとある指標を伸ばすチームに配属されました。 施策をいくつかリリースしていく中で効果検証を担当することが多かったのですが、その検証設計をする時にどんな指標を見るべきかの設計に躓く場面がありました。
行われた施策によって何が変更され、ユーザーさんの行動がどう変わる想定なのか?が事前に言語化されていないとどんな指標を見るべきか?が設計できないことに気づきました。つまり、どんな仮説があって施策を実施したかを意識できていなかったのです。
意識できていなかった原因は、施策が仮説の検証手段という立ち位置ではなく、一か八か当たるかの博打というイメージを頭に持っていたからだと思っています。
それ以降、私は施策を研究という試行錯誤を繰り返すものという捉え方をするようにしています。
いきなり大発見をすることは難しいから未知を既知に変えていくことが重要であり、その地道な仮説検証プロセスを施策を活用して行うという姿勢を今後も意識していきたいと思います。

おわりに

今回の記事を書いてみて、言われてみれば当たり前のことだなと思ったのですが、そういう当たり前を言語化していき振り返れる状態にしておくことが大事だと思っています。
この記事を半年後読み返した時に、自分の学びが定着しているか確認したいと思います。