soda.inc

エンジニア Entrance Book
👩‍💻

エンジニア Entrance Book

⏳
最終更新：2024年2月

はじめに

エンジニア向けに開発組織や使用技術などの情報を掲載しています。

会社全体やサービスについては下記をご覧ください。採用サイト

このページに記載している以上のことが気になる方は、是非カジュアル面談や選考へご応募ください！応募する

他のBookもご覧ください

SODAのことが気になっている方、カジュアル面談を受けようか検討している方

→ このままこちらのEntrance Bookをご覧ください！

最終面談・内定の前後の方、入社を検討中の方

→ 下記のEntry Management Bookもご覧ください！

もっと見る

開発チームの基本情報

📣
チーム体制、開発プロセス、技術スタック、などの開発チームに関する基本情報について紹介します。

image
  • スニダンでのメインとなるユーザ体験をUser Value Streamとして抜き出しています
  • 「出品者の出品〜購入者の購入〜購入者の手元に届く」という一連の取引の流れを示しています
  • 前半の出品や購入、マーケット閲覧などのエンドユーザが触る部分をTeam AとTeam Bでプロダクト開発しています
  • 後半の物流オペレーションにおける社内ユーザが触る部分をTeam Cでプロダクト開発しています
  • エンジニアリングマネジメントの観点でTeam EM、Team SRE、Team QAがプロダクト開発チームをサポートしています

image
  • プロダクト開発を行うチームにはそれぞれ数名のWebエンジニアが所属しており、WebエンジニアがWebフロントエンド（主にVue.js）、バックエンド（主にGo）、インフラ（主にAWS/Terraform）のすべてを担当しています
  • Team AとTeam Bはエンドユーザが使うモバイルアプリの開発も行うためFlutterエンジニアが所属しています
  • Team Cが開発する社内Adminツールは他部署であるCS（カスタマーサポート）、Logistics（物流）、Store（店舗）のメンバーが使用するため、それぞれの部署のステークホルダーがチームに参加しています
  • PdMはチームごとに担当を持ち、同じプロダクト開発チームとして各種定例を一緒に行っています
  • エンジニアリングマネジメントチームとしてTeam EM、Team SRE、Team QAがあり、プロダクト開発チームが質およびスピード高く日々開発を進めていくためのサポートを提供しています
‣
組織デザインの意図などを示すキーワードの補足情報
  • フルサイクル開発：機能開発などによる価値提供に必要なプロセスをチームに閉じて行える体制での開発を指します。WebエンジニアやFlutterエンジニア、DesignやPdMがチームに所属することで実現することを目指しています。
  • バリューストリーム：機能開発などによる価値提供に必要なプロセス全体を指します。あるバリューストリームに対してチームでフルサイクルに開発できる体制を目指しています。いくつかあるバリューストリームの境界はまだまだ十分に探索できていない部分が多いため、組織デザインはまだまだ改善が必要です。
  • Stream-aligned Team：Team Topologiesという組織論の1つに登場するチームの1種で、あるバリューストリームに対してフルサイクルに開発を進めるチームを指します。プロダクト開発を行う各チームはStream-aligned Teamであることを目指しています。
  • Enabling / Platform Team：こちらもTeam Topologiesに登場するチームの1種で、Enabling TeamとPlatform Teamは別々の概念ですが、どちらもStream-aligned Teamが質およびスピード高く開発を進めていくためのサポートを提供するチームを指します。エンジニアリングマネジメントチームはすべてEnabling / Platform Teamになっていくことを目指しています。

image
  • プロダクト開発を行う各チームでの開発プロセスです
  • スクラムを参考に出来るだけアジャイルに開発しようと試みています
    • スクラムを実施すること自体を目的とはしていませんが、開発プロセスの改善を進めていくと自然とスクラムに近づいている部分が多いです
  • 一部チームではSprint Reviewを実施するなど、細かい部分の取り組みはチームごとに異なっており、開発プロセスに対してチームごとに独立して試行錯誤・意思決定をしています
    • チーム間の情報共有も定期的に行っています

image
  • GoとVue.jsが共存しているブロックが1つの大きなECS Serviceになっており、ほとんどの機能を提供するモノリスのようになっています
  • このモノリスをモジュラモノリスとしてコンテキスト境界を明確化していくことを現在進めています
  • モジュラモノリス内のコンテキスト境界が安定したら、その境界でマイクロサービスへ分割していこうと想定しています
  • モジュラモノリス内でのモジュラ間の呼び出しはProtocol Buffersで抽象化しており、将来的なマイクロサービス分割を見据えています
  • GitHub Actionsでは、Goのテスト、ECSへのデプロイ、Terraformの実行、を自動化しています

image
  • 「エンジニアリングマネジメント」の定義は「管理すること」ではなく「管理しなくても成果が出る状態を作ること」と捉えています
  • エンジニアリングマネジメントはプロダクトマネジメント、テクノロジーマネジメント、プロジェクトマネジメント、ピープルマネジメントの4つの領域に分けて整理しています
  • 4つの領域をそれぞれのエンジニアリングマネジメントチームが分担して改善を推進しています
  • Team EM自身はピープルマネジメントに注力していますが、他の領域を含め組織全体の意思決定に関わっています

技術スタック - モバイルアプリ

言語やFW

  • Dart / Flutter

CI/CD

  • Codemagic
  • GitHub Actions

テスト

  • flutter_test

ライブラリ

  • Riverpod
  • Flutter Hooks
  • dio
  • Freezed
  • Firebase

VALUE & 行動指針

📣
開発組織が重要視している価値観などを言語化したVALUE & 行動指針の紹介です。

VALUE 1. Growth First

  • サービス機能開発などを進める最大の目的は事業が成長すること
  • 事業成長に大きなインパクトを与えないことなら妥協することも時には大事
  • 事業成長に中長期的に寄与するチーム・個人の成長もスコープに含める

‣
VALUE 1 に対する行動指針

行動指針 1-1. バリューストリーム全体に関わる

  • 何を何故作るか、どう作るか、どのような結果が得られたかのバリューストリーム全体にチームで携わる
  • バリューストリームを回す上で他チームへの依頼や承認を無くす

行動指針 1-2. バリューストリームによって提供するアウトカムを最優先に考える

  • 事業成果を最も優先し、最小限の工数で最大限のビジネスインパクトを生み出す
  • バリューストリーム全体に常に関わっていることでアウトカムに繋がらないムダに気づく

行動指針 1-3. どちらかだけではなくDevもOpsも両方を意識する

  • チームでフロントエンドからバックエンド、インフラまで一気通貫して開発・運用に携わる
  • プラットフォームチームやSREチームはPlatform / Enabling Teamとして動く

VALUE 2. 組織の成果を最大化する

  • 事業を成長させるために個人では到達できない水準を目指し、スケールアウトできるかどうかを意識する
  • 質&スピードと育成のトレードオフを常に意識して組織全体の成果を最大化する

‣
VALUE 2 に対する行動指針

行動指針 2-1. 「質およびスピード」と「育成・学習・挑戦」のトレードオフを意識する

  • 高い技術力・開発力があれば「質」と「スピード」は両立できるが、その技術力・開発力を向上させるための「育成・学習・挑戦」とトレードオフになる
  • 事業フェーズや組織フェーズと照らし合わせて「質およびスピード」と「育成・学習・挑戦」のどちらをどのくらい優先するかのバランスを常に議論していく
  • 参考：質とスピード（2020秋100分拡大版） / Quality and Speed 2020 Autumn Edition

行動指針 2-2. 特定の人物しか出来ないことは移譲していく

  • チーム全体の成果を最大化するために属人化は排除する
  • 自分しか出来ないことは自分でやるのではなく「やって見せて、やってもらって見て、任せる」

行動指針 2-3. レビューは「指摘・修正」の場ではなく「議論・改善」の場

  • レビューコメントは「こう直してください」という意味ではなく「こう直したらこう改善されると思うんですがどうですか」という意味で、議論をするためのトリガー
  • 正解が無いこともあるので修正を強要する断定のコメントはせず、議論した上で納得して修正を加える

行動指針 2-4. 1人で悩む時間は最小限にする

  • 何かにハマってタスクが進まず「こうすれば解決するかも」という仮説・検証を繰り返すことも難しい場合は、すぐに誰かに相談する
  • 相談される側の時間はもちろん消費するが、チーム全体の生産性は高くなるので相談するほうがむしろヨシ

行動指針 2-5. 円滑なチーム開発で高いアウトカムを出す

  • 個人の成果の最大化にとらわれず、他のメンバーのタスクを自分のタスクと認識してお互いにフォロー・ヘルプする
  • 未知の事柄は放置せずチームとしての学びに還元してチームとして学習していく
  • 仕事に必要なことを権限や関係性や付き合いに捉われずにオープンで透明性の高いコミュニケーションを取る

行動指針 2-6. チーム目標を設定して目標達成のために行動する

  • チームの成果を最大化するためには、まずその成果量を可視化する必要がある
  • 成果の定義はチーム内で合意を取り、チーム成果の最大化に向けて改善する
  • 検証のために、定性・定量に捉われず必要なメトリクスを計測して改善していく

VALUE 3. 全員リードエンジニア

  • リードエンジニア：役職でも役割でもなく、プロダクトや組織に何が必要か考え、相談し、実行できる人（≒自己組織化して自走できるエンジニア）という定性的な概念
  • ↑の実行対象は、「プロダクト施策を実装するタスクの実装方針」、「プロダクトに不足している技術的な施策の提案・方針決定・実行」、「エンジニア組織に不足している組織的な施策の提案・方針決定・実行」など、プロダクト・組織にとって有用なものであれば何でも

‣
VALUE 3 に対する行動指針

行動指針 3-1. “課題解決”に対する高い意識を持つ

  • エンジニアリングを用いて行うのはユーザやシステム、組織などの課題を解決することである
  • 必要以上のオーバーエンジニアリングはせず、課題解決に集中する

行動指針 3-2. チーム全員で改善していく

  • チーム開発を改善するための議論はチーム全員が議題を出してチーム全員で議論して改善していく。それが難しい場合はチームのサイズが大きすぎる可能性を考える
  • 意思決定コストを下げるためにリーダーの役割を誰かにアサインする場合も、全ての意思決定を行う役職としてのリーダーではなく、ある一定の範囲の意思決定のみを行う役割としてのリーダーをアサインする
  • 現状維持は「衰退」を意味する。変化を恐れず試し、より良いものを取捨選択する

行動指針 3-3. 役割にとらわれずに仕事の領域を越境する

  • プロダクトに対する強い好奇心を持って組織の課題解決のために役割にとらわれずに仕事の領域を越境する
  • 自分の専門領域以外の技術に関しても興味を持ち感度を高くキャッチアップする

今後やっていきたいこと

📣
会社として注力していきたいと考えていることを分野ごとに紹介します。

image
  • エンドユーザに使ってもらうプロダクト機能の開発だけではなく、CSやLogisticsチームが使う社内Adminツールの機能開発も含んでいます
  • システム改善も機能開発とバランスを取って進めていきたいと考えています
    • DatadogやGitHub Actionsの例はわかりやすいものを挙げているだけで優先度が最も高いものというわけではありません
  • プロダクト開発に関わるエンジニアが一番多いため、組織作りへの協力も欠かせません
  • 組織作りに興味がある方は是非一緒に進めていきたいですし、苦手意識がある方はフォロワーシップを発揮してくれるだけで十分です

image
  • スニダンWebフロントエンドのこれまで：
    • 現在のスニダン開発チームでは、専任のWebフロントエンドエンジニアはいません。
    • HTML/CSSの実装をデザイナーが、Vue.js周りの実装をWebエンジニアが担当しています。
    • Webエンジニアはほとんど全員がバックエンド寄りのバックグラウンドを持っているためフロントエンドに詳しいエンジニアは少なくなっているのと、デザイナーが2名しかおらずスピードが出しづらいことが現在の課題です。
  • スニダンWebフロントエンドのこれからと募集背景：
    • デザイナーとバックエンドエンジニアだけでWebフロントエンド側の開発も推進してきましたが、サービスの急拡大および開発組織の拡大に伴い、現在の体制ではWebフロントエンドを品質&スピード高く進めることが難しくなってきました。
    • そこで、Webフロントエンド領域の開発を品質&スピードともに高く推進していただける1人目のWebフロントエンドエンジニアを募集しています。

image
  • SREチーム発足前からDevOpsはエンジニア全員で推進してきましたが、水準をさらに上げていくために専任のSREチームが発足しました
  • 開発エンジニア全員がインフラやCI/CD周りを触ることは継続しつつ、その水準を上げていくことをSREチームとしてはサポートしていきたいと考えています

image
  • ユーザへの価値提供における品質とスピードを最大にすべく、リリース前の検査に留まらず開発プロセス全体に対してQAの観点を強化していくQAを行っていきたいと考えています

image
  • エンジニアリングマネジメントの4領域のうち、特にピープルマネジメントとプロジェクトマネジメントにフォーカスし、組織成果の最大化を行っていきたいと考えています

image
  • 事業成長を鈍化させるどころか、加速させていくような、セキュリティのシフトレフトを実現していきたいと考えています

課題の全体感

いま開発組織に存在している課題一覧をこちらにまとめています。

開発組織の課題リスト

「この課題の解決を一緒にやりたい！」という方がいましたら、是非カジュアル面談や選考へご応募ください！応募する

就業環境

就業時間
10:00〜19:00（休憩1h含む）
就業場所
リモートワーク（地方在住も可） or 出社（渋谷オフィス）を自由に選択可能
休日/休暇
完全週休2日制、祝日、法定有給休暇、年末年始休暇、夏季休暇（7〜9月にいつでも使用可能な特別休暇3日付与）

福利厚生

制度
概要
Learning制度
月1万円を上限として業務に関わる自身のスキルアップに繋がる技術書籍購入などの費用を負担します。退職時の返却は不要です。
資格取得支援制度
資格を取得したい従業員をサポートするため、資格取得時に奨励金として会社から受験料をお支払いする制度です。
リファラル採用
社員紹介により入社したエンジニアの試用期間終了後に被紹介者1名につき紹介者へ50万円を支給します。
交際費支援
毎月1名につき5000円までの交際費を負担します。また、新しくエンジニアがジョインした際の歓迎ランチにかかる交際費も負担します。
希望のノートPC貸与
MacBook Proを貸与します。ディスプレイは希望のものを購入し貸与します。
Wantedly Perk
Wantedly社が提供するWantedly Perkという福利厚生サービスが利用可能です。様々なサービスで割引などの特典を利用することができます。
Smart相談室
日常のちょっとした悩みを気軽に社外の方に相談できるサービスで職場や業務のことはもちろん、プライベートな話にも利用することができます。
慶弔休暇
結婚や出産などがあった際に有給休暇とは別に休暇を取得できます。
その他
副業OK、社会保険/雇用保険完備、交通費月額5万円まで支給、定期健康診断、インフルエンザ予防接種、髪型/服装自由

メディア

Engineering Blog

採用情報

募集ポジション

採用プロセス（ポジションなどにより一部変更が入ることがあります）

プロセス
SODAからの参加者
実施内容
備考
カジュアル面談
エンジニアリングマネージャー
SODAの開発組織や使用技術などのご紹介および深堀りを通じて、技術や組織に対する考え方などにおけるマッチ度を候補者の方に検討していただく面談です。 マッチ度が高い可能性を少しでも感じたら、是非選考へのエントリーをお願いいたします。もちろん、カジュアル面談時におけるSODAへの志望度は問いません。
書類選考
エンジニアリングマネージャー、エンジニア採用人事責任者
選考エントリー時に提出いただいた書類を確認し、1週間以内を目処に今後についてご連絡を差し上げます。
採用面談
エンジニア、エンジニアリングマネージャー、CTO、VPoE、VPoT
技術面および組織面において候補者の方とSODAがマッチしているかどうかをお互いに見極める面談です。 技術面においては、エンジニアとしての課題解決力を探ることで、今後SODAで一緒に課題解決を推進していく姿がイメージ出来るかどうかを重要視しています。組織面においては、組織としての成果への意識を探ることで、今後のSODAの成長にチームの一員として貢献していく姿がイメージ出来るかどうかを重要視しています。 技術面、組織面問わず具体的には下記のようなことをお伺いします。 - 前提として、どのような問題が発生していたのか。 - 問題を解決するにあたって、どのような理由でどのような方針を決めたのか。 - 解決策を実施してみてどのような結果になったのか。 エピソードを共有いただく際には、できるだけ直近の事例で、かつ、候補者の方の中でよりインパクトの大きいものをお話いただけると幸いです。 また、定量的な値があるのであれば、差し支えない範囲で共有いただけますと幸いです。
3〜4回実施します。
オファー面談
CTO
オファー条件をお知らせした後に実施します。 オファー承諾を検討するにあたって必要な情報を候補者の方に提供する面談ですので、オファー承諾にあたっての疑問点や不安点などを是非お話しください。 また、SODAへジョインしたあとに期待することをお伝えし、それが候補者の方が今後のキャリアとしてやっていきたいこととマッチしているかどうかをすり合わせます。
オファー承諾を検討するにあたってまだ話していないメンバーとも話したい場合は出来る限り面談をアレンジするのでお申し付けください。

おわりに

SODAやスニダンにご興味を持っていただけた方は、ご興味のあるポジションへご応募いただけると嬉しいです！

採用情報

FAQ

‣
Q. 開発環境はどのようなものですか？

A. Macbook Proとお好きなモニタが貸与されます。

‣
Q. エンジニアの評価制度はどのようなものですか？

A. 7段階のグレードでエンジニアとしての職務要件が定義されています。IC（Individual Contributor）とEM（Engineering Manager）に途中からキャリアパスが分岐します。半期に一度目標設定を行い、EMとの1on1を通じて目標を追っていきます。

‣
Q. リモートで働いているエンジニアの割合はどのくらいですか？

A. 実態としてはほとんどのエンジニアがフルリモートで働いています。ウェルカムランチや飲み会などが開催されるときのみ出社される方も多くいます。地方在住の方もいらっしゃいます。

‣
Q. Go・Flutterの実務経験がなくても大丈夫ですか？

A. 課題解決力を一番重要な能力として考えているため、技術スタックのマッチは必須ではありません。キャッチアップする力があれば問題なく、Go / Flutter未経験で入社されたエンジニアも多く在籍しています。

‣
Q. スニーカー好きじゃなくても大丈夫ですか？

A. 大丈夫です。入る前からスニーカー好きだったエンジニアは数名程度で、入ったあとに好きになる人も多くいらっしゃいます。