バックエンドエンジニアとして、STORES 予約 の開発を手がける藤生 規広さん。幅広い技術や知識を活かし、開発を牽引しています。その冷静で安定した進行には定評があり、複雑な部署連携や技術の紐解きが必要な機能をリリースしてきました。どのような理由で STORES に入社し、どんなことを心がけて開発をしているのでしょうか。お話を聞きました。

受託開発から STORES へ。転職軸は「オーナーシップを持って開発できること」

──まず、これまでのキャリアを教えてください。STORES にいらっしゃる前は、どんなお仕事をされていたのでしょうか。

未経験から新卒でエンジニアになりました。子どもの頃から工作が好きで、おもちゃの箱などを自分で作るのが好きだったんです。エンジニアリングには、そういうものづくりの印象があり、根拠のない自信がありました。STORES に入社する前のキャリアはソフトウェアの受託開発を行う会社です。主にRubyを使って開発を行っていました。

──そこでのお仕事はいかがでしたか。

バリバリ開発を行って、楽しくはたらいていました。一方で、受託開発特有の悩みもありました。例えば、受託開発におけるプロダクトはクライアントの資産。リファクタリングを行うのもリスクと考えられ、こちらから積極的に行うことができませんでした。また、ライブラリのバージョンを最新にするにも工数がかかり、クライアントに相談しなければならない。仕事をする中で、リスクを取ってでもオーナーシップを持ち自由な意思決定をしたいと思うようになり、事業会社への転職を考えるようになりました。

──そこで見つけたのが STORES だったのですね。 STORES が良いなと思った理由は何でしたか？

事業会社であることを軸に、いくつかの会社でカジュアル面談などを行いました。選考に進む中で、 STORES ではたらきたいという思いが芽生えたのは体験入社です。 STORES の体験入社は、丸一日実際のチームにメンバーとして入り、実際のプロダクトを触りながら開発をするというもの。「こんなにコードを見て良いのかな」と思うほど、リアルな開発現場を見せていただき、おかげでチームの雰囲気を知ることができました。また、実際のコードからどんな課題があるのかがよくわかり、お互いの期待調整ができたので、入社後の具体的なイメージを持つことができました。

多様なメンバーで、わいわい開発できる環境

──実際に STORES に入社してみて、いかがですか。

外から見ると大きな会社に見えますが、入ってみるとそれぞれは意外にも小さなチームで、それならではのわいわいした雰囲気がありました。また、期待していたオーナーシップについては、エンジニアが主体となって課題を見つけたり解いたりしているのがすぐに実感でき、期待通りの転職ができたと感じました。

開発メンバーのキャラクターや強みが多様なのもはたらいて楽しさを感じられるポイントです。色々なプロダクトが集まってできた会社なので、バックグラウンドやキャラクター、技術がさまざまなエンジニアに出会うことができます。それぞれのプロダクトに特色があって、刺激を受けることができます。

歴史の長いプロダクトだから、一筋縄ではいかない。STORES 予約 の新機能リリースの舞台裏

──　STORES に入社してから、もっとも印象に残った仕事は何ですか。

最近リリースした STORES 予約の「指名なし予約」です。これまでの STORES 予約 では、お店のスタッフを選んで予約をすることしかできませんでしたが、この機能により、時間だけを決め、スタッフの指名なしで予約を行うことができます。例えば、ヘアサロンでスタイリストを指名せずに、時間だけ決めて予約することがありますよね。この機能により、それが可能になります。

──オーナーさんにも、ユーザーにも喜ばれそうな機能ですね。どうしてこの開発が印象に残っているのでしょうか。

機能の内容だけ聞くとシンプルで、簡単に開発できそうな印象があるかもしれませんが、その開発プロセスはかなり複雑なものでした。これまでの予約では、指名が入ったスタッフの枠が閉じるようになっていたのですが、指名なしで予約するには、どれかの枠を閉じる計算が必要です。

 STORES 予約における、これまでの予約の概念を考え直さなければならないような大きな開発で、そもそもの実装を考え直さなければならないところが特に大変でした。 STORES 予約 は、これまでにも色々な開発を経て現在のプロダクトや、それに紐づく機能が成り立っています。これまで積み上げられたことを壊さないようにしながら開発するのは至難の技でした。

──開発プロセスはどのようなものだったのでしょうか。

考えて実装することの繰り返しでした。まず考えられるパターンで設計してみて、可能性がありそうなら実装する。けれど、それでは対応できないユースケースなどが出てくるので、またその対応を考えて実装する、という作業の繰り返しでした。予約時の全てのパターンを網羅する必要がある一方で、QA段階でPdMにテストバージョンを触ってもらったら、修正する箇所が見つかるということもありました。

リリースも一筋縄では行かず、リリース後に修正しなければならない箇所が見つかりました。これによりダブルブッキングができてしまう状態になり、オーナーさんから指摘をいただいた時には焦りました。オーナーさんのお商売への影響を最小限にとどめるため大急ぎで対応し、1、2日で修正が完了したのですが、最後まで苦労の絶えない開発でした。

──実際にリリースした時の感動はひとしおだったのではないでしょうか。

と、言いたいところなんですが、この機能はオーナーさん側で有効化するタイプのものなので、一気に変更されるのではなく、じわじわとリリースの実感が湧いてくるようなものでした。それでも、リリース後しばらくしてから、オーナーさんから「これによって便利になった」「実はこの機能を待っていた」という声が届いた時にはやはり嬉しかったですね。この機能は、今後注力していきたい業種向けの機能のファーストステップ。これからも便利な機能をどんどんリリースしていきたいです。

──この開発を成功させられたのは、なぜだと思いますか。

 STORES の「とりあえずやってみよう」という文化です。 STORES には良くも悪くも保守的な人が少なく、リスクについて語るよりもまずは形にするムードがあります。このリスクに対して適切に対処し、チャレンジするマインドに助けられてこれまでの開発ができたのではないかと思います。

短期より長期の成果。
チーム開発で大切にしていること

──お話を聞いていると、大変な局面にも冷静に対応し、確実に成果を残している様子が印象的です。仕事で気をつけていることはありますか。

仕事中に気持ちの浮き沈みを出さないようにしています。仕事をしている時に、あからさまにイライラしている人がいると話しかけづらいし、気を遣いますよね。そう思われないように、気をつけているつもりです。もちろん人間なので気持ちの浮き沈みはあるのですが、それが見えないようにしています。

また、チームで開発することを意識しています。これまでの受託開発では、工数に対する成果物が評価軸だったので、いかに機能を実装するかが最優先でした。しかし、 STORES でチーム開発をするようになってからは、ひとりで短期的な効果がある機能を開発するよりも、長期的に意義のあることにみんなで取り組む方が大切だと考えられるようになりました。期間が限られている受託開発と違って、事業開発はこれからずっと続いていくもの。それならば目の前の「10pt」を拾うより、脇道の「5pt」を集める方が大切なこともあるのです。

もっとも、転職当時はこの頭の切り替えに苦労しました。今も完全にできているかはわかりませんが、常に思考をアップデートすることで、チームで開発することを前提に優先度を立てられるようになったと思います。

──開発で成果を出すコツや、決まりのようなものはあるのでしょうか。

とにかくレスポンスを早くすること。Slackをはじめとするコミュニケーションはもちろん、プルリクエストやGitHub上でのレスポンスもなるべく早くできるように心がけています。

ジェネラルなエンジニアとして、機能も事業も伸ばしていきたい

──これからについて教えてください。どんな仕事をしていきたいですか。

これからは、 STORES のそれぞれのプロダクトがより強固に連携していきます。それにより、さらにユースケースが広がり、解決したい課題や必要な機能が出てくるはずです。いちエンジニアとして、自分自身の技術の幅を増やし、それらの課題解決ができるようになっていきたいです。

理想は、ジェネラルなスキルを持って機能数も売り上げも上げられるエンジニア。エンジニアリングを通して、これからの STORES の事業にさらに貢献し、オーナーさんのお商売のよろこびを作っていきたいと思います。

（写真・文：出川　光）

＼ STORES では一緒にはたらく仲間を募集中です！／