見出し画像

クラシコムに入社して2年経ったのでエンジニアチームを振り返ってみる

こんにちは。クラシコム エンジニアの佐々木です。最近は朝晩ともにグッと寒い日が続き、本格的に冬が来たなというのを感じます。

さて、タイトルの通り僕が入社して2年ほど経ったわけですが、僕が所属するテクノロジーグループは日々変化を続けてきました。それを改めて振り返ってみたいと思います。

社内のエンジニア3人目として入社

僕が入社する前まで、エンジニアのチームは社内にいるエンジニア2人とフリーランスのエンジニア1人の計3人でした。元々いた2人の社内エンジニアは実はもういないので、社内エンジニアとしては僕が今現在一番の古株に。だからどうだというわけではないのですが、当時と比べて今では開発に携わっている人が格段に増えており、改めてそんな時代もあったなぁという気持ちになっています。

今現在、開発チームに関わっている人たちをざっとあげると

- 社内エンジニア4人
- UI/UXデザイナー2人
- フリーランスエンジニア2人
- iOSエンジニア(オフショア)数人
- プロジェクトを一緒にやっている他社さんのエンジニア3人
- プロダクトオーナー(以下PO)として代表の青木
- 社外取締役としてソニックガーデンの倉貫さん

と、関わっている人がググッと増えている状況。当時より10人以上は関係する人増えてます。今実際に数えてみてびっくりしました。採用など人事周りも含めるともっといます。

会社としても、入社当時は社員数自体40人に満たない人数だったと記憶していますが、現在は60人を超えていてますます大きくなってきています。

カートのリライトチーム

上にも書いたとおり、2年前と比べてよりたくさんの人たちが「北欧、暮らしの道具店」というプラットフォームを良いものにするためにワンチームで取り組んでいます。しかし現在にいたるまでにいろんな取り組みがありました。

入社当時はエンジニアの数も多くなく、POというポジションもなければUI/UXデザイナーもおらず本当に少人数の開発チーム。そんな中僕が最初に取り組んだ大きな課題は、Railsで作られたカート機能をLaravelでリライトするというものでした。

当初はDDD経験者もいない中で「DDDで作ろう!みんなわからないならペアプロ/モブプロで意見を交換しながら作ろう!」と作り始めます。

週に一回の読書会でDDDに関する資料を読んだり、知恵熱が出ちゃうのではというくらい一日中アプリケーションの設計とコードに対してみんなで向き合っていました。今思い出してもなかなかハードだったなと思います。

それでできた僕らなりのLaravelでのDDDに関しては、廣瀬が良い資料にまとめて発表してくれています。

また、カートのインフラ部分をどうするかという話があったのですが、僕自身興味があったKubernetesを導入する試みを行いました。しかし、僕しかわからない状態ができあがり保守するのがとても困難な状況を作ってしまいそうだという判断をし、導入を断念することに。

このときに、新しいものや良いと言われているものは無闇に取り込むのではなく、自分たちのチームに合っているかどうかで技術なりアーキテクチャを選択するかがいかに大事かということを改めて学んだ気がします。と同時に、トライする・試すということは知らないものの価値を判断するためには必要なことだなと改めて感じました。
(せっかくなのでKubernetesに対する当時の頑張りはここで供養しておきたいと思います)

そんなカートですが、リリースされてもうすぐ一年経ちます。その一年の間、びっくりするほどエラーは少なくとても良い状態を維持できてると感じます。リードしてくれたエンジニアの腕が確かだったのと、素直に良いものを作ろうと頑張った結果なんだと思います。

大きくではなく小さく開発するチームへ

そんなわけで最初はカートのリライトチームだったのですが、途中からエンジニアも増えUIUXデザイナーも増え、少しずつ体制も変わっていきました。

大きく変わったのはカートリライト中の後半だったのですが、POとデザイナー、それに対しエンジニアが2つのチームに別れ2ラインで開発をしようという体制を作ることでした。

カートのリライトは走り始めから1年弱というまあまあかかるプロジェクトになっていました。それに対し、小さく作ることで手戻りがあってもしやすく、デリバリーも増やしていける体制を作りたいという意図で試みを始めます。

この体制でしばらく開発は続き、大きな開発ではカートのフロント部分をシンプルにするというリニューアルをVue.jsというフレームワークを取り入れつつ行ったり、商品ページがSKU単位だったのを複数SKU表示できるようにするような変更を加えています。これら大きめな開発内容を固めながら、小さく分割しリリースできそうなものは工夫しながらコツコツとリリースを重ねていきました。

別れたチームをまた1つに

チームを2つにわけて半年ほど経ったころ、振り返ってみると色々と課題点も見えてきました。

- 機能の変更内容や知見の共有がうまくいかない
- DBに関わる変更のリリースタイミングの調整がうまくできない
- 他のチームに相談なしで頑張って解決しようとしてしまう。後から共有して修正する羽目になったことも
- 今やっていることが各人のやりたいことにつながっているかどうかがわからない

などです。

そんなある日、各人がタスクに対してしっかりと責任を持ち、チーム全体でマネジメント・レビュー体制を作ることができればチームをわけなくてもよいのでは、という話があがりました。結果、一つのチームへ戻すことに。

現在では、中〜長期的に何をやるかを定期的に特定のシニアメンバーですり合わせ、それに対し週に一度、POとUI/UXデザイナーとエンジニアが全員集まりこの一週間何をやってきたか、次の一週間何をやるかを話しあい開発を行っています。

この体制で半年ほど経ちますが、僕らの現在にフィットしているのかうまくワークしていると感じます。小さく開発することのメリットはそのままに、結果として大きなものを作るという体制が成熟しつつあるのかもしれません。

これからのチーム

僕が入社してからこれまでのチームの変遷をメインに振り返ってみました。2年経って改善されたこと、できたことも多いなと感じてはいますが、やりたいことや改善する余地がまだまだあります。

分析基盤の整備や倉庫との連携の強化、オペレーションの効率化、情シスとの連携、インフラ周りの整備、エンジニアの採用・文化醸成…など、少し出してみるだけでもたくさん。

かと言って、人が増えた場合どうなるのか。すでに10人近くがMTGに参加しておりけっこうギリギリな状態です。これ以上増えたらマネジメント・レビュー機能がうまく働くかどうかわからないので、またチームを見直すことになるかもしれません。

でもチームが変わるということは、よくも悪くも変化があり前に進もうとしていることの現れだと思うので、僕はとてもわくわくしています。

大変だなぁと思うこともありますが、とてもありがたいことだとも思っています。これからこのチームにどれくらい貢献できるのか。エンジニアが精神論的なエモい感じのことを言うのはナンセンスだと思ってはいますが、2年経ち改めて、エンジニアとして頑張り続けたいと感じている次第です。

(この記事を書き始めた当初はチームの見直しが必要になるかもくらいで思っていたのですが、つい昨日チームの体制や会議体に変更が実際にありましたw その辺りに関しては、変更になった体制を改めて振り返るタイミングで記事にできればと思っています)

スキありがとうございます!
27
クラシコムのエンジニアによる、技術者向けのブログです。普段の開発内容や、開発するなかでの気づきなどを発信しています。

こちらでもピックアップされています

#エンジニア 系記事まとめ
#エンジニア 系記事まとめ
  • 717本

noteに投稿されたエンジニア系の記事のまとめ。コーディングTIPSよりは、考察や意見などを中心に。

コメントを投稿するには、 ログイン または 会員登録 をする必要があります。