はじめまして、山中です。
入社から3か月が経ち、プライベートでは魚を捌くことと業務ではRuby on Railsに少しずつ慣れてきました。少し遅いですが入社エントリとして、これまで取り組んできたことや学びについてお伝えします。
中途入社ですが、スキルセットとして即戦力とは言えません（詳しくは後述）。その中で、どうすればチームや会社に貢献できるかを考え、実行してみました。
転職直後の人にはどんなことができるのか？そんなことを考えている山中をウーオはどう受け入れてくれたのか？ということを紹介します。
自己紹介
あらためて自己紹介です。
プロダクトチームに2024年9月に入った山中といいます。
前職は小売業の会社で主にECサイトのバックエンドの運用保守をしていました。
具体的には、ECサイト用のWebAPIと、そのWebAPIが参照するDBや検索システム、DBや検索システムを更新するバッチを担当していました。
担当システムのミドルウェアやOSのアップデート、システムリプレースをするときにアプリケーションが正常に動くように修正して、テストをすることが多かったです。
EOL対応を数年連続していたので直近は、半分冗談半分本気で「俺がEOL対応エンジニアだ」とか言ってました。
経歴を見直すと、新卒のときから今まで携わってきたプロダクトはすべて、作られてから10年以上のものでした。
開発スピードを維持しながら長くサービスを提供するうえで、ソフトウェアも運用作業も設計とテストは大事であり、そこはさらに磨いていきたいスキルだと考えていました。
加えて、まだまだ新しいことにも挑戦したいと思って転職することにしました。そのうえで、ウーオの事業や考え方が好きだったので、面接をお願いして今に至ります。
入ったばかりの場所でどう貢献するか？
さて、こんな私ですがウーオでなにをすることになったのかというと、Ruby on Railsで作られているプロダクトのバックエンドで機能開発を主にすることとなりました。
水産業の市場で例えるなら、以前は魚の売買に携わっていたのが、しばらくは冷蔵設備の入れ替えや間接資材の整理などの業務に専念しており、今回久しぶりに魚の売買を再開する状況でしょうか。
ごめんなさい、この例えはわかりにくいかもしれませんが、ご容赦ください。（言ってみたかったのです。）
つまりはソフトウェア開発という仕事の流れはおおよそわかっているが、詳細なところは慣れがないという状態です。
機能開発も数年ぶりです。
RubyもRuby on Railsも業務経験はなく、入ったばかりのときは業務で使えるレベルではなかったため、他のメンバーからたくさんサポートをもらいました（これは本当に感謝）。また、業界が変わったため、ドメイン知識も不足しています。
中途採用でここまでガラッと変わる人はあまりいないかもしれませんが、多少は変化があってパフォーマンスや成果を出しにくい人は多いと思います。
一方で何もできないのかと考えると、そうではなく、できることがあって実施してよかったことを紹介します。
ポイントとして、以下の3つのステップで取り組んでいくとよかったです。
- 簡単で実績がある方法を導入してみる
- 途中から入ったからこそ見えたことを伝える
- 少しストレッチして実績がある方法を導入してみる
入って3か月間でやったこと
【ステップ1】簡単で実績がある方法を導入してみる
Slack絵文字にネコチャン絵文字を導入する
ウーオではSlackを使っています。前職でSlackやDiscordで使えるネコチャン絵文字が使われていて、コミュニケーションがいい感じになっていたので、入れました。
これは今思うと勢いで入れた感じはありますが、振り返ると、良い成果が得られたと感じています。
ウーオは常に皆がオフィスにいるわけではありません。
リモートで働くときもあれば、市場や営業先にいくこともあります。オフィスにいることが多い人もいます。
そのため、少しでもテキストコミュニケーションが良い感じになったのはよかったと思います。
1on1を総当りでやってみる
水産業界では、漁師さんから消費地市場を経由して消費者に届くまででいろいろな職種の人が関わります。
ウーオ社外だけではなく社内にもさまざまな仕事をしている人がいます。
人によっては仲買人さんや荷受けさんと主に接したり、小売・飲食店と主に接する人もいます。
入社前にウーオのブログ水産流通のしくみ を読んでいたのですが、それでもわからないことが多かったです。
どうキャッチアップしていくかと考えていたときに、以前読んだブログの記事オンラインでも一人目職種のオンボーディングを成功させる知見を紹介しますを思い出しました。
わたしは一人目職種なわけではないのですが、
仕事の話をしようにもお互い「知らない人」だとうまくコミュニケーションを取れないことが多いので、1on1で人となりをまず知る / 知ってもらうことが大事です。
という点は同じだと考え、やってみました。
ちょうど入社して2週間目に広島本社出張があって、対面でできる方とは対面でリモートや東京本社の方々とは、オンラインで実施しました。どの方も当初予定の時間45分オーバーするくらい話をしてもらえて、どういうところで連携できそうか、新しく入った山中というやつはどんなやつかっていうのをざっくり知ってもらえました。
また、自分自身も他の人の業務の具体や、考え方を知ることで、MTGで顔を合わせて話しかけるときの心理的なハードルは低くなったと思います。
パラメータ化テストを書く
さて、ようやくここから、ソフトウェアエンジニアっぽいことの紹介をします。
別にそうやらなくても困らない、けど知っているとちょっと楽というものはあります。
細かいところで言えば、なにかのショートカットコマンドやシュガーシンタックスなど。ウーオはテストコードを書く習慣があって、テストケースも充実しています。
ただ、意外にも以下のように書いているテストコードがありませんでした。
[
%w[SendGridがJSONのTOPレベルから仕様と異なるものを送ってきたとき SendGridの署名が有効なとき],
%w[SendGridが仕様通りのパラメータを送ってきたとき SendGridの署名が無効なとき],
%w[SendGridがJSONのTOPレベルから仕様と異なるものを送ってきたとき SendGridの署名が無効なとき]
].each do |event_type, signature_type|
context '異常系のとき' do
include_context event_type
include_context signature_type
it '400を返す' do
post webhooks_sendgrid_path, params: send_grid_request_param, headers: stub_headers
expect(response).to have_http_status(:bad_request)
end
end
end
別にこれは、以下のように書いても大きな問題になりません。
context '異常系のとき1' do include_context 'SendGridがJSONのTOPレベルから仕様と異なるものを送ってきたとき' include_context 'SendGridの署名が無効なとき' it '400を返す' do post webhooks_sendgrid_path, params: send_grid_request_param, headers: stub_headers expect(response).to have_http_status(:bad_request) end end context '異常系のとき2' do include_context 'SendGridが仕様通りのパラメータを送ってきたとき' include_context 'SendGridの署名が無効なとき' it '400を返す' do post webhooks_sendgrid_path, params: send_grid_request_param, headers: stub_headers expect(response).to have_http_status(:bad_request) end end ...
この書き方はライブラリを入れずとも導入できるコストの低いことであり、 テストコードが見やすくなると言っても少しずつです。それでも大事だろうと考え、書いてPRをだしたら、すっと承認されてちらほらと他にも同じ書き方のコードが見えたのは嬉しいところでした。
【ステップ2】途中から入ったからこそ見えたことを伝える
言葉の認識合わせをしていく
プロダクト開発に何年か携わっている人であれば「アジャイル開発のスクラム」と言うと、おおよそどんなことをやるのかイメージは一致すると思います。
ある言葉や、やり方が組織内で使われるうちに、もとは一般的な意味だったのに徐々に別の意味に変わることがあります。
これは必ずしも悪いことではありませんが、同じ言葉でも指すものが異なるとコミュニケーションに支障が出ることがあります。とくに新しい人が入ったときに問題になりやすいです。
そういったことを解消していくためにも、違和感があったら
というのは確認していくようにしました。
自分自身もチームに馴染めるように理解を深めるのと、チームの人にもなにかしらプラスになると思うので進めていきました。
前職での事例を紹介する
業界が違うと言っても、大きな括りで言うとeコマースに関わる仕事という点では同じです。
たとえば振り返りとしてこんな取り組みをしていたということを以下のように共有しました。
ちなみに前職でやっていた事例を紹介するときに、どこまで話していいかは法務にくわしいコーポレートチームに相談してから、共有しました。
分報チャンネルで悩みをポツリと呟いていたら、スッとコーポレートチームのメンバーが現れて相談に載ってもらえました。ありがたかったです。
【ステップ3】少しストレッチして実績がある方法を導入してみる
GitHub Copilotを導入する
最後は、少しストレッチして実績がある方法を導入してみた例の紹介です。
GitHub Copilotは前職でも学ぶのにも業務を進めるにもすごく便利でした。前職では、GitHub Copilotを導入すると受けられる恩恵のポイントをスーパーなエンジニアの人がサッとまとめて、あっという間に導入してくれました。
正直当時の自分ではそんなにうまくはやれないと思います。
ただ、今の自分なら少しスキルはあがっているし、導入先の組織や状況は違いますがそれをお手本とできます。自分も他のメンバーも業務効率改善にもなるため、これならば頑張ればいけそうだと考えてメンバーにアンケートをSlackで取って、CPOの土谷さんに相談してお試しで導入しました。2か月ほど試用してもらい、アンケートをとり、（厳密に時間を測ってはないですが体感で）平均1日30分以上は作業時間の短縮ができたとアンケートで回答をもらえて、それならばOKということで導入できました。
こういうのは、転職して働く場を変えたときだからこそできることだと思います。
企画、導入、検証までの1サイクルを体験できるのは、個人としてもスキルアップにいいです。
また、新しい環境で一連の流れを実施するにはどんな感じで進めるのかを知る良い機会にもなるので、転職したての方はなにかしら、やってみるチャンスだと思います。
振り返りと感謝
たった3か月、されど3か月。
上記以外にもいろいろとチャレンジさせてもらえました。 転職したばかりだからできるチャレンジがけっこうできて、充実した3か月を過ごせました。
これは決して自分の力だけではなくって、そういうチャレンジを受け入れてくれる環境がウーオにあるからできたのだと思っています。 わかりやすいところだと、1on1とかアンケートは絶対に独力ではできません。 それ以外も全部自分で考えたのではなく、アドバイスを適切にもらえたので実現できました。
チャレンジしたいことを詰め込みすぎて、混乱を招いたところもあります。（1on1で予定いっぱいになった日とかあったり・・。） そこは優先順位の付け方で大いに反省すべきところなので、冷静に見直しつつ、メイン業務でも貢献できるようにします！
まとめ
入ってから3か月間で何をしてどうなったのか？ということで、自分自身が今まで周囲の人から学んだことや良いと思ったことを実践したことを紹介しました。
ポイントは、導入・実施コストやリスクが低いものからしていくことです。 個人としてはなにかを導入するファーストペンギンとなる経験を積めます、 周囲のメンバーに効果は低いかもしれませんがマイナスになりにくいです。
これは、ウーオのValuesの「まずは小さな1ケース」に近いと思っています。
これからケースをたくさん積んで、成果が出せたときにはまた記事を書きます！
最後に最近作った魚料理です。富士山サーモンを自分で捌いてパン粉焼きにしました。めちゃくちゃおいしかったです！
