最終更新：2022年11月
はじめに
エンジニア向けに開発組織や使用技術などの情報を掲載しています。
会社全体やサービスについては をご覧ください。SODA inc. 採用情報
このページに記載している以上のことが気になる方は、是非カジュアル面談や選考へご応募ください！（→応募する）
開発チームの基本情報
チーム体制、開発プロセス、技術スタック、などの開発チームに関する基本情報について紹介します。
- スニダンでのメインとなるユーザ体験をUser Value Streamとして抜き出しています
- 「出品者の出品〜購入者の購入〜購入者の手元に届く」という一連の取引の流れを示しています
- 前半の出品や購入、マーケット閲覧などのエンドユーザが触る部分をTeam AとTeam Bでプロダクト開発しています
- 後半の物流オペレーションにおける社内ユーザが触る部分をTeam Cでプロダクト開発しています
- エンジニアリングマネジメントの観点でTeam VPoX、Team EM、Team SRE、Team QA、Team Securityがプロダクト開発チームをサポートしています
- プロダクト開発を行うチームは基本的に3名の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、Team Secがあり、プロダクト開発チームが質およびスピード高く日々開発を進めていくためのサポートを提供しています
‣
- フルサイクル開発：機能開発などによる価値提供に必要なプロセスをチームに閉じて行える体制での開発を指します。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になっていくことを目指しています。
- プロダクト開発を行う各チームでの開発プロセスです
- スクラムを参考に出来るだけアジャイルに開発しようと試みています
- スクラムを実施すること自体を目的とはしていませんが、開発プロセスの改善を進めていくと自然とスクラムに近づいている部分が多いです
- 一部チームではSprint Reviewを実施するなど、細かい部分の取り組みはチームごとに異なっており、開発プロセスに対してチームごとに独立して試行錯誤・意思決定をしています
- チーム間の情報共有も定期的に行っています
- GoとVue.jsが共存しているブロックが1つの大きなECS Serviceになっており、ほとんどの機能を提供するモノリスのようになっています
- このモノリスをモジュラモノリスとしてコンテキスト境界を明確化していくことを現在進めています
- モジュラモノリス内のコンテキスト境界が安定したら、その境界でマイクロサービスへ分割していこうと想定しています
- モジュラモノリス内でのモジュラ間の呼び出しはProtocol Buffersで抽象化しており、将来的なマイクロサービス分割を見据えています
- GitHub Actionsでは、Goのテスト、ECSへのデプロイ、Terraformの実行、を自動化しています
技術スタック - モバイルアプリ
言語やFW
- Dart / Flutter 2
CI/CD
- Codemagic
- GitHub Actions
テスト
- flutter_test
ライブラリ
- riverpod
- flutter_hooks
- dio
- freezed
- Firebase
VALUE & 行動指針
開発組織が重要視している価値観などを言語化したVALUE & 行動指針の紹介です。
VALUE 1. Growth First
- サービス機能開発などを進める最大の目的は事業が成長すること
- 事業成長に大きなインパクトを与えないことなら妥協することも時には大事
- 事業成長に中長期的に寄与するチーム・個人の成長もスコープに含める
‣
行動指針 1-1. バリューストリーム全体に関わる
- 何を何故作るか、どう作るか、どのような結果が得られたかのバリューストリーム全体にチームで携わる
- バリューストリームを回す上で他チームへの依頼や承認を無くす
行動指針 1-2. バリューストリームによって提供するアウトカムを最優先に考える
- 事業成果を最も優先し、最小限の工数で最大限のビジネスインパクトを生み出す
- バリューストリーム全体に常に関わっていることでアウトカムに繋がらないムダに気づく
行動指針 1-3. どちらかだけではなくDevもOpsも両方を意識する
- フロントエンドからバックエンド、インフラまで一気通貫して開発・運用に携わる
- プラットフォームチームやSREチームはPlatform / Enabling Teamとして動く
VALUE 2. チームでチームの成果を最大化する
- 事業を成長させるために組織をスケールさせ、個人では到達できない水準を目指す
- 質&スピードと育成のトレードオフを常に意識してチーム全体の成果を最大化する
‣
行動指針 2-1. 「質およびスピード」と「育成・学習・挑戦」のトレードオフを意識する
- 高い技術力・開発力があれば「質」と「スピード」は両立できるが、その技術力・開発力を向上させるための「育成・学習・挑戦」とトレードオフになる
- 事業フェーズや組織フェーズと照らし合わせて「質およびスピード」と「育成・学習・挑戦」のどちらをどのくらい優先するかのバランスを常に議論していく
- 参考：質とスピード（2020秋100分拡大版） / Quality and Speed 2020 Autumn Edition
行動指針 2-2. 特定の人物しか出来ないことは移譲していく
- チーム全体の成果を最大化するために属人化は排除する
- 自分しか出来ないことは自分でやるのではなく「やって見せて、やってもらって見て、任せる」
行動指針 2-3. レビューは「指摘・修正」の場ではなく「議論・改善」の場
- レビューコメントは「こう直してください」という意味ではなく「こう直したらこう改善されると思うんですがどうですか」という意味で、議論をするためのトリガー
- 正解が無いこともあるので修正を強要する断定のコメントはせず、議論した上で納得して修正を加える
行動指針 2-4. 1人で悩む時間は最小限にする
- 何かにハマってタスクが進まず「こうすれば解決するかも」という仮説・検証を繰り返すことも難しい場合は、すぐに誰かに相談する
- 相談される側の時間はもちろん消費するが、チーム全体の生産性は高くなるので相談するほうがむしろヨシ
行動指針 2-5. 円滑なチーム開発で高いアウトカムを出す
- バリューストリーム全体に関わる中での分野ごとの得手不得手や経験の深さの差はチーム内でサポートし合う
- 未知の事柄は放置せずチームとしての学びに還元してチームとして学習していく
VALUE 3. 全員リードエンジニア
- リードエンジニア：役職でも役割でもなく、プロダクトや組織に何が必要か考え、相談し、実行できる人（≒自己組織化して自走できるエンジニア）という定性的な概念
- ↑の実行対象は、「プロダクト施策を実装するタスクの実装方針」、「プロダクトに不足している技術的な施策の提案・方針決定・実行」、「エンジニア組織に不足している組織的な施策の提案・方針決定・実行」など、プロダクト・組織にとって有用なものであれば何でも
‣
行動指針 3-1. “課題解決”に対する高い意識を持つ
- エンジニアリングを用いて行うのはユーザやシステム、組織などの課題を解決することである
- 必要以上のオーバーエンジニアリングはせず、課題解決に集中する
行動指針 3-2. チーム全員で改善していく
- チーム開発を改善するための議論はチーム全員が議題を出してチーム全員で議論して改善していく。それが難しい場合はチームのサイズが大きすぎる可能性を考える
- 意思決定コストを下げるためにリーダーの役割を誰かにアサインする場合も、全ての意思決定を行う役職としてのリーダーではなく、ある一定の範囲の意思決定のみを行う役割としてのリーダーをアサインする
今後やっていきたいこと
会社として注力していきたいと考えていることを分野ごとに紹介します。
- エンドユーザに使ってもらうプロダクト機能の開発だけではなく、CSやLogisticsチームが使う社内Adminツールの機能開発も含んでいます
- システム改善も機能開発とバランスを取って進めていきたいと考えています
- DatadogやGitHub Actionsの例はわかりやすいものを挙げているだけで優先度が最も高いものというわけではありません
- プロダクト開発に関わるエンジニアが一番多いため、組織作りへの協力も欠かせません
- 組織作りに興味がある方は是非一緒に進めていきたいですし、苦手意識がある方はフォロワーシップを発揮してくれるだけで十分です
- SREチーム発足前からDevOpsはエンジニア全員で推進してきましたが、水準をさらに上げていくために専任のSREチームが発足しました
- 開発エンジニア全員がインフラやCI/CD周りを触ることは継続しつつ、その水準を上げていくことをSREチームとしてはサポートしていきたいと考えています
- ユーザへの価値提供における品質とスピードを最大にすべく、リリース前の検査に留まらず開発プロセス全体に対してQAの観点を強化していくQAを行っていきたいと考えています
- エンジニアリングマネジメントの4領域のうち、特にピープルマネジメントとプロジェクトマネジメントにフォーカスし、組織成果の最大化を行っていきたいと考えています
- 事業成長を鈍化させるどころか、加速させていくような、セキュリティのシフトレフトを実現していきたいと考えています
課題の全体感
いま開発組織に存在している課題一覧をこちらにまとめています。
「この課題の解決を一緒にやりたい！」という方がいましたら、是非カジュアル面談や選考へご応募ください！（→応募する）
就業環境
就業時間 | 10:00〜19:00（休憩1h含む） |
就業場所 | リモートワーク（地方在住も可） or 出社（渋谷オフィス）を自由に選択可能 |
休日/休暇 | 完全週休2日制、祝日、法定有給休暇、年末年始休暇、夏季休暇（7〜9月にいつでも使用可能な特別休暇3日付与） |
福利厚生
制度 | 概要 |
Learning制度 | 月1万円を上限として業務に関わる自身のスキルアップに繋がる技術書籍購入などの費用を負担します。退職時の返却は不要です。 |
リファラル採用 | 社員紹介により入社したエンジニアの試用期間終了後に被紹介者1名につき紹介者へ50万円を支給します。 |
交際費支援 | 毎月1名につき5000円までの交際費を負担します。また、新しくエンジニアがジョインした際の歓迎ランチにかかる交際費も負担します。 |
希望のノートPC貸与 | 入社時に希望のノートPCを貸与します。特に希望がなければフルスペックのMacBook Proを貸与します。ディスプレイも希望のものを購入し貸与します。 |
Wantedly Perk | Wantedly社が提供するWantedly Perkという福利厚生サービスが利用可能です。様々なサービスで割引などの特典を利用することができます。 |
Smart相談室 | 日常のちょっとした悩みを気軽に社外の方に相談できるサービスで職場や業務のことはもちろん、プライベートな話にも利用することができます。 |
慶弔休暇 | 結婚や出産などがあった際に有給休暇とは別に休暇を取得できます。 |
その他 | 副業OK、社会保険/雇用保険完備、交通費月額5万円まで支給、定期健康診断、インフルエンザ予防接種、髪型/服装自由 |
メディア
![「スニダン」で100億超の調達！SODA社のエンジニア組織が2名→20名に急拡大した裏側とは | SELECK [セレック]](/_next/image?url=https%3A%2F%2Fsuper-static-assets.s3.amazonaws.com%2F668fb5b8-8f3e-4f1a-9494-b15768d4a8d0%2Fimages%2F3ecf9209-3835-43d9-a6aa-e6ab6257fb5b.jpeg&w=3840&q=80)
採用情報
募集ポジション
採用プロセス（ポジションなどにより一部変更が入ることがあります）
プロセス | SODAからの参加者 | 実施内容 | 備考 |
カジュアル面談 | エンジニアリングマネージャー | SODAの開発組織や使用技術などのご紹介および深堀りを通じて、技術や組織に対する考え方などにおけるマッチ度を候補者の方に検討していただく面談です。
マッチ度が高い可能性を少しでも感じたら、是非選考へのエントリーをお願いいたします。
もちろん、カジュアル面談時におけるSODAへの志望度は問いません。 | |
書類選考 | VPoE、エンジニア、採用人事責任者 | 選考エントリー時に提出いただいた書類を確認し、1週間以内を目処に今後についてご連絡を差し上げます。 | |
採用面談 | CTO、VPoE、VPoT、エンジニア | 技術面および組織面において候補者の方とSODAがマッチしているかどうかをお互いに見極める面談です。
技術面においては、エンジニアとしての課題解決力を探ることで、今後SODAで一緒に課題解決を推進していく姿がイメージ出来るかどうかを重要視しています。
組織面においては、組織としての成果への意識を探ることで、今後のSODAの成長にチームの一員として貢献していく姿がイメージ出来るかどうかを重要視しています。 | 2〜4回実施します。 |
オファー面談 | VPoE | オファー条件をお知らせした後に実施します。
オファー承諾を検討するにあたって必要な情報を候補者の方に提供する面談ですので、オファー承諾にあたっての疑問点や不安点などを是非お話しください。
また、SODAへジョインしたあとに期待することをお伝えし、それが候補者の方が今後のキャリアとしてやっていきたいこととマッチしているかどうかをすり合わせます。 | オファー承諾を検討するにあたってまだ話していないメンバーとも話したい場合は出来る限り面談をアレンジするのでお申し付けください。 |
おわりに
SODAやスニダンにご興味を持っていただけた方は、上記の採用情報よりご興味のあるポジションへご応募いただけると嬉しいです！
FAQ
‣
A. フルスペックなMacbook Proとお好きなモニタが貸与されます。
‣
A. 7段階のグレードでエンジニアとしての職務要件が定義されています。IC（Individual Contributor）とEM（Engineering Manager）に途中からキャリアパスが分岐します。半期に一度目標設定を行い、EMとの1on1を通じて目標を追っていきます。
‣
A. 実態としてはほとんどのエンジニアがフルリモートで働いています。ウェルカムランチや飲み会などが開催されるときのみ出社される方も多くいます。地方在住の方もいらっしゃいます。
‣
A. 課題解決力を一番重要な能力として考えているため、技術スタックのマッチは必須ではありません。キャッチアップする力があれば問題なく、Go / Flutter未経験で入社されたエンジニアも多く在籍しています。
‣
A. 大丈夫です。入る前からスニーカー好きだったエンジニアは数名程度で、入ったあとに好きになる人も多くいらっしゃいます。