SMARTCAMP Engineer Blog

スマートキャンプ株式会社(SMARTCAMP Co., Ltd.)のエンジニアブログです。業務で取り入れた新しい技術や試行錯誤を知見として共有していきます。

カジュアル面談でよく質問されることとその答え

こんにちは! スマートキャンプで開発組織の責任者をしている米元です。

コロナ禍によって激動の1年となった2020年も残りわずかとなりましたが、皆様いかがお過ごしでしょうか。 読者の皆様が心身ともに健やかに年末年始を迎えられれば幸いです。

さて先日の記事にも書かせて頂きましたが、弊社では採用活動の一環で選考に入る前のエンジニアの方に向けて、会社や開発組織のご説明をするカジュアル面談を行っています。

tech.smartcamp.co.jp

そのカジュアル面談での時間をより濃い内容にするために、当記事では候補者の方々から頂く質問の中でも特によく聞かれることについて書かせて頂こうと思います。

面談の前にこの記事を読んで頂いた方は弊社の理解度が高い状態で面談に臨めますし、そうでない方も面談時に聞けなかった部分を補完する情報になれば幸いです。

また、そもそもスマートキャンプってどんな会社?という方はこちらの会社説明資料をごらんください。

speakerdeck.com

目次

よく聞かれる質問

それではさっそくよく聞かれる質問とその回答を紹介していきましょう。

どんな人を求めていますか

技術面に関してはその時々の求人内容によるので割愛します。

エンジニアに限らず、候補者に共通して求めるものとして、弊社の行動指針である「SOCS」の体現があります。

「SOCS」とはSmartThinking、Ownership、Collaboration、Speedの4つの行動指針の頭文字です。

  • SmartThinking
    • 仮説思考・本質思考
    • 先見性と創造性
  • Ownership
    • リーダーシップ
    • 主体性
  • Collaboration
    • 社内・社外共創
  • Speed
    • 実行スピード
    • 生産性(質/時間)

社内では更に詳細な定義があり、評価や選考基準の1つとして利用しています。

複数の開発チームがあるとの事ですが、どのようなチーム分けなのでしょうか

BOXILとBALES CLOUDというプロダクトがあり、それぞれにプロダクトマネージャー、デザイナー、エンジニアなど複数職種のメンバーが所属しています。

エンジニアはBOXILが業務委託とインターンの方を合わせて9名、BALES CLOUDは2名です。

BOXILの方はエンジニアが多いので更にエンジニア内でサブチームに分けています。

サブチームの数やメンバーの分け方は、

  • その時点の案件の内容と優先度
  • メンバーのスキルややりたい事

によって2〜3ヶ月ごとに組み合わせを見直しております。

例えば直近の例だと、インフラが得意な中堅メンバーとインフラを学びたい若手メンバーでサブチームを組んでインフラの改善作業をしています。

現在は3つのサブチームに分けた体制で安定した成果が出ており、当面はこの体制でメンバーを組み替えながら開発していきます。

BOXILのこれまでの変遷はこちらの記事にも書いています。

tech.smartcamp.co.jp

タスクがエンジニアにアサインされるまでの流れを教えてください

まず前提として弊社ではスクラム開発を行っており、1週間で1スプリントのサイクルを回しています。

少し前の記事になりますが、スクラムやリモート下での開発の様子は以下の記事をご覧ください。

tech.smartcamp.co.jp tech.smartcamp.co.jp

弊社でタスクの元になる案件の発生パターンはおおまかには以下の3つがあります。

  • 事業戦略に基づいて関係部署から企画や施策が提案される
  • Slackの開発リクエスト用チャンネルで調査依頼や不具合報告が送られる
  • 開発チーム自身がシステム改善や機能改善の案を提案する

※重大な不具合対応など緊急性が高いものは除く

それらのタスク案をProduct Backlogに積んで、プロダクトマネージャーが中心となり優先順位付けをします。

仕様についての確認やすり合わせはリファインメントとして朝会の中で行い、着手出来る状態になったものが次のスプリント以降のタスク候補となります。

週次のプランニングの際に開発チームで話し合いを行い、タスク候補の中から翌週のSprint Backlogに入れるものを選び、誰が担当するかを決めるという流れになっています。

入社をしたら最初にどのようなタスクをアサインされるのでしょうか

まずはプロダクトの仕様や開発フローに慣れて頂くために、比較的小さめのタスクからお願いします。

1人で作業するというより複数人で1チームとして作業を進めることが多いので、モブプログラミングやペアプログラミングなどでコミュニケーションをとりつつ進めて頂くことになると思います。

これはリーダーやマネージャー候補の方でも同じです。

弊社のオンボーディングについては以下の記事が参考になるかと思います。

少し前の記事のため現在は変わっている部分もありますが、「入社した方に出来るだけ早く活躍していただくための支援をする」という基本的な考え方は変わっていません。

tech.smartcamp.co.jp

リリースの頻度はどれくらいでしょうか

時期によって異なりますが、だいたい週に3〜4回はリリースをすることが多いです。

1回のリリースに複数の変更が含まれており、週に5〜15件程度の変更が行われていることになります。

Railsやミドルウェアのバージョンアップを積極的に行っているとのことですが、どのように進めているのでしょうか

基本的には通常の開発と並行して進めています。

Railsのバージョンアップなど工数がかかるものについてはノウハウのある外部の方にスポットで協力をお願いし、短期間でリリースまで一気にやりきる場合もあります。

それらに工数をかけるべきかの判断は誰が行うのか?という質問もよく頂くのですが、弊社では開発チーム自身にその裁量が与えられています。

その分、開発チームも中長期の事業に与えるインパクトに責任を持ち、いつどのように行うべきかを判断しています。

技術的な課題はどのようなものがありますか

BOXILについて

インフラはEC2でRailsのアプリケーションを直接動かしていますが、歴史的背景によりオートスケールが出来ない状態になっているなどの運用上の課題をいくつか抱えています。

これに関しては1,2ヶ月後を目処にECS Fargateに移行して複数の課題をまとめて解決する方向で対応を進めています。

また、フロントエンドに関しては数年前の構成と直近1,2年の比較的モダンな構成が混在しており、今後はこれらをモダンな構成に統一することを検討しています。

アプリケーションのアーキテクチャとしては、BOXILとBOXILのメディア機能が同じアプリケーション内に同居していて設計上も密結合しています。

こちらもやや負債となっているため今後改善していきたいと考えています。

BALES CLOUDについて

比較的新しいサービスであることや日々リファクタリングを進めていることもあり、大きな技術的負債はありません。

ただ少人数で開発をしていることもあり、UIの変更に伴うバグを回避するための影響範囲の調査やテスト工数が大きな負担になっていました。

直近ではこの問題を解決するためにmablというテスト自動化ツールの導入を進めています。

技術選定はどのように行っていますか

新しい技術やツールを導入する際は、基本的にはチーム内で裁量を持ってボトムアップで決めています。

特にルールなどはありませんが、大きな技術導入の場合は他のチームにも相談や情報共有を行いながら進めることが多いです。

組織の規模が大きくなると複数チームで同じ技術検証をするなどの無駄も発生しそうなので、今後はチームごとの裁量を維持しつつ情報共有の仕組みを作っていく必要があると考えています。

今後Rails以外の技術を使うことはありますか

あります。

弊社では主力事業であるBOXILがリリースされた2015年頃からRailsを利用してきました。

RailsとRubyの優れたエコシステムを利用することで、当時のまだビジネスが不確実な状況でもスクラップアンドビルドを繰り返しながら素早く事業を立ち上げ、ここまで成長することが出来たと考えています。

フロントエンドに関してはVue.js + TypeScriptを利用する機会が増えてきましたが、バックエンドは依然としてRailsが中心となっています。

一方でこの数年でフロントエンドのフレームワークの進化と周辺のエコシステムが整備されたことで、バックエンドにRailsのようなフルスタックなWebアプリケーションフレームワークを選定する理由が以前より少なくなっています。

実際に他社の事例でもバックエンドはGoなどの静的型付け言語あるいはサーバーレスでAPIを書き、フロントはVue.js/React.jsとTypeScriptといった構成が選ばれる事がかなり増えております。 エンジニアの中でもこれらの技術に対する人気がかなり高まっており、採用活動への影響も無視出来ないものになってきました。

また、弊社のVISION/MISSIONを実現するために中長期でどの技術に投資していくかを考えた時に、

  • ユーザーに価値を提供し続けるために最適な技術を選択できる状態にすること
  • 社内のエンジニアが技術的なチャレンジをすることができる環境を用意すること

が重要だと考えています。

これらに対する施策の1つとして、弊社でもバックエンドはGo・フロントエンドはVue.js/Nuxt.jsやReact.js/Next.js + TypeScriptといった構成を積極的に採用していく予定です。

実際にサーバーレスでAPIを作成した事例は以下の記事で紹介しています。 tech.smartcamp.co.jp

Railsに関しては今後も弊社の中で主力技術の1つとして利用し続けますし、事業の内容やフェーズ・開発メンバーによっては最適な選択肢の1つであり続けると考えています。

今後、開発組織はいつ頃にどれくらいの規模になりますか

現在は業務委託やインターンの方を合わせて15名程度の規模です。 職種や役割別の内訳としては以下のようになっています。

  • プロダクトマネージャー 2名
  • プランナー 1名
  • デザイナー 1名(開発専任の人数。1月に2名になる予定です)
  • エンジニア 11名

今後については事業の状況やその他の外部要因などで変わりますが、今のところ2年後の時点で30人前後にする想定でいます。

リモートワーク中心の働き方は今後も続くのでしょうか

今は週1出社・週4リモートが基本となっていますが、今後のコロナの状況次第で週2〜3の範囲で出社する割合が増える可能性はあります。

弊社ではコロナ禍以前も全社的に週1のリモートデーがあり、オフラインとオンラインの両方の働き方の良い点を理解しています。

そのため、仮にコロナ禍が終わったとしてもリモートワークを完全に無くすことはなく、逆にフルリモートのみにすることも考えにくいです。

業務内容や事業フェーズ、チームやメンバーの自立度によってリモートの向き不向きは変わってくるため、個人的には週1以上の出社頻度をどうするかは部署やチーム単位で選び、必要に応じて全体での出社タイミングを設けるのが良いのではないかと考えています。

まとめ

カジュアル面談でよく聞かれる質問とその回答についてまとめてみました。

面談をするしないに関わらず、少しでも弊社に興味を持って頂いた方の参考になれば幸いです。

ここまで読んで頂いてありがとうございました!

smartcamp.co.jp