すべての人がテクノロジーを活用し、未来を切り拓ける世界を実現するために、一人ひとりの背景・目標・価値観に応じた学習を共創しています。

IT教育を通して1人でも多くの人生の選択肢を増やし、世界のイノベーションを支えるためにサービス改善を続けております。

【採用ピッチ】　
https://www.docswell.com/s/samurai/K8G2M7-apr-2023

募集要項

サービス内容

・SAMURAI ENGINEER
「1人でも多くの人生をプログラミング教育で変える」ために、1人1人の目的に沿った講師とオーダーカリキュラムを提供、マンツーマン指導により挫折率を圧倒的に下げるプログラミングスクール

・SAMURAI TERAKOYA
プログラミングスクール業界の課題である「挫折率の高さ」と「高額な費用」を解決し、高品質なプログラミング学習を提供するサブスクリプション型プログラミングスクール

・SAMURAI ENGINEER Biz
企業のニーズや達成目標に応じてカリキュラムをフルオーダーメイドで作成できる法人向けIT研修サービス

・SAMURAI ENGINEER Career
SAMURAI ENGINEERの卒業生を始め、エンジニアへの転職を目指す方向けのキャリア支援サービス

・キャリ活
20代の若手ポテンシャル層の就職・転職支援に特化したキャリア支援サービス

・SAMURAI ENGINEER Blog
月間600万PVのプログラミング学習に関する疑問を解決するためのオウンドメディア

株式会社SAMURAIはSaaS型の学習プラットフォームを運営しているEdTechスタートアップです。
EdTech領域で「質の高いIT教育を、すべての人に」というミッションを掲げ、誰もがエンジニアになるためのプラットフォームを創造するべく様々な事業を展開しています。
プログラミング学習の挫折率を少しでも減らし、2030年までに79万人のエンジニアが不足するといわれている社会課題を解決していきます。

業務内容

自社プロダクトSAMURAI ENGINEER/SAMURAI TERAKOYAの開発をお任せします。
現在、サービス拡大にあたりスクラム開発やTDDなどを進めており、更なる開発スピード向上のために技術力でチームを引っ張っていただけるようなエンジニアの方を募集しています。

【具体的にお任せしたい業務例】

GoによるWebアプリケーション開発、API開発
React、TypeScript を用いたSPA開発
アプリケーション要件に基づいた技術選定、アーキテクチャ設計、ミドルウェア選定など
AWS環境の構築・保守
など

事業部側との距離が近いので、要件と設計・実装を状況に応じてすり合わせながら開発を進めることができます。

応募要件

MUST

React・TypeScriptでの開発経験
バックエンド開発経験
スクラムでのチーム開発の経験
SOLID原則やAtomic Designを意識して開発できること
「目的」を分解して「何をどうすればよいか」を考えられる。
複雑なプログラム・データ・ログを調査するのに抵抗がない。
調べたことや考えたことを日本語で整理して伝え、進め方を議論できる。
積極的に助けたり助けを求めたりできる。
指摘をフラットに受け取り、よりよい進め方を考えたり議論したりできる。

WANT

Goでの開発経験
Terraformを用いたAWS環境構築の経験
Next.jsでの開発経験
0→1でのサービスの開発やグロースの経験
プロジェクトマネージメントやプロダクトマネージメントの経験
スクラムマスターの経験
他部署との折衝や開発上流工程の経験
エンジニア教育に興味のある方

開発環境

インフラ：AWS・Terraform・Docker・ECS・MySQL(AWS Aurora)・その他
バックエンド：Go(gin)・GraphQL・Clean Architecture
フロント：React・TypeScript・Apollo Client・ Atomic Design
IDE：Visual Studio Code
CI：GitHub Actions
テスト：Ginkgo・Jest・Cypress
AI：GitHub Copilot・OpenAI
監視：Sentry・DataDog
コミュニケーション：Slack・Meet
その他：GitHub・Azure DevOps・Figma・Miro・Googleドライブ・Wiki

※現在、「Go+React+GraphQL」から「Next.js+Server Function」への刷新を検討しています。

開発スタイル

アジャイルを用いたチーム開発、コードレビューの文化、ドキュメントの整備、TDDなどを強く推奨・促進しています。
サービスをより多くのユーザーに届けるために、QCD（品質・コスト・デリバリー）を高める目的で、開発環境の改善にも力を入れており、最近ではAIを用いたコードレビューの強化を導入しました。

1スプリントを1週間に設定したスクラム開発
デイリーでスタンドアップミーティング、週1回のレトロスペクティブ、スプリントプランニングを実施しています
チーム全体でのコードレビュー文化があります
継続的なデプロイ(毎週数回)を実施しています

また、エンジニア教育のサービスということもあり、現場で開発しているエンジニアがよりサービスに深く携わることの価値を重視しています。
そのために事業部側への提案も通りやすい風通しのよいチーム運営を意識しながら、より多くのエンジニアがサービス作りに能動的に取り組める仕組みを整えています。
2015年の創業以来フルリモート・フレックスでチーム運営をしており、実際に北海道や静岡在住のメンバーも在籍しております。

開発組織

LMS開発チームに参画いただきます。社員2名、業務委託4名の6名体制(2025年11月現在)で、LMS(学習プラットフォーム)の開発をしています。機能改善やバグ修正などを、スクラム開発で高速に回していきます。仕様や実装に不明点があれば気軽にSlackやMeetで連絡をとりあうなど、リモートワークながらチームワークが発揮できる環境を整えています。

LMS開発チームでは、3日間のオンボーディングと3週間のOJTにより、スムーズに参加していただけるような受け入れ体制が整っています。

また、毎月「コミュニケーションタイム」や「オンラインランチ」があり、チーム内で業務以外の話をしてチームワークの土台を強固にしています。

開発の例

受講生やインストラクターが使うLMS(学習プラットフォーム)の保守開発を行います。

開発の例：

受講生が提出した課題をAIが自動レビューする機能を開発。
教材検索で一部の教材が表示されない不具合を修正。
画面への表示項目追加など、UI/UXを改善。

様々なタスクがバックログ上に優先順位を付けて並べられており、スクラムのスプリントで計画を立てて対応していきます。
各メンバーの得意領域や挑戦したい内容なども踏まえて、みんなで相談して主担当を決め、助け合いながら進めています。

開発内容のカテゴリーは下記のイメージです。(％は作業時間の割合)

既存機能の不具合修正：25％
既存機能の改善：35％
新規機能の開発：5％
開発環境の改善：10％
- CI/CD改善
- 自動テスト対象領域の強化
- PRテンプレート改善　など
運用・保守：25％
- ライブラリ更新
- インフラ・ミドルウェア更新
- 監視対応
- 問い合わせのエスカレ対応　など

タスクレベルだと、下記のイメージです。(％は作業時間の割合)

既存実装の調査：70％
要件定義・詳細設計：2％
実装：8％
リファクタリング：4％
自動テスト作成・手動テスト実施：8％
レビュー＆レビュー指摘対応：8％

調査・実装対象の言語などは下記のイメージです。(％は作業時間の割合)

Go：60％
React・TypeScript：28％
DB：6％
ログ(AWS CloudWatch)：2％
AWS：2％
GitHub Actions：2％

※現在、「Go+React+GraphQL」から「Next.js+Server Function」への刷新を検討しており、開発内容が変更になる可能性があります。

一週間の流れ

スプリントプランニングで、その週に誰が/何を/どのように進めるかを相談します。
- 1つのチケット(タスク)は メイン担当とレビュー担当の2名 で進めることが一般的です。
- スプリントでの各チケットの目標は、下記のどちらかになります。
  - そのスプリントで、できるところまで調査する。
    - 調査は実施してみないと大変さが分からないため「やりきる」とは言えません。
  - 改修・テストをやりきる。
    - 調査済みのチケットは、何をどうすればよいか分かっているため「やりきる」ことができます。
デイリースクラムで、 予定に対して状況が問題ないかを確認し、よりよい進め方を相談 します。
- 必要に応じて担当を変更することもあります。
スプリントの最後にはレトロスペクティブ(振り返り)を行います。
- この1週間を踏まえて、 次の1週間で具体的に何を改善できるか を話し合います。

一般的なタスクの流れ

チケットは様々な部署から起票されます。
- 事業部からのシステム改善の要望・質問・相談。
- ユーザーやインストラクターからの改善要望のエスカレーション。
- ユーザーからの問い合わせのエスカレーション。
- 開発チーム(自分達)からの改善提案。
起票されたチケットは、プロダクトオーナーやスクラムマスターが確認し、起票者に質問・相談して大枠の方針を固めます。
- 内容はチケットに反映されます。
- 問い合わせなどは、このタイミングで回答して完了になることもあります。
背景・内容・状況などに応じて、プロダクトオーナーがチケットの優先順位を設定します。
- 対応是非・対応方針・優先順位などは相談して決めますが、 最終決定権は開発チーム にあります。
- ROIを踏まえて、実施を見送る場合もあります。
次のデイリースクラムでプロダクトオーナーから開発者に内容が説明されます。
状況に応じて優先順位は随時調整します。
チケットの優先順位が近づいてきたら、具体的な進め方を検討します。
- 必要に応じてチケットを分割します。
- デザイナーにUI(Figma)の作成を依頼します。
改修に向けて、 詳細な調査 を実施します。
- 既存の挙動・実装・データ・運用がどうなっているのか。
- どうすれば実現できそうか。
- そのように改修しても他に悪影響が発生しないか。
調査結果はチケットにまとめ、チーム内でレビューを実施して、不足している内容などがあれば追加で調査します。
- 調査はたいてい複雑です。 分かりやすくまとめる論理的思考や日本語力が非常に重要 です。
- 難しい場合は、随時相談しながら進めます。調査以外でも同様です。
調査結果を踏まえて、対応方針やテストの方法を検討します。これもレビューを実施します。
ここまで完了すると「あとは改修・テストするだけ」になります。
- スプリントに組み込む(＝そのスプリントでやりきる)のはこの状態のチケットだけです。
まずは改修予定の箇所に対してUTを書きます。 これによってデグレが発生した場合は検知できるようになります。
- フロントエンドはコンポーネントのレンダリング結果や挙動をテストします。
- バックエンドはサービスやリポジトリの挙動をテストします。
改修しやすいように リファクタリング します。
- 必要に応じて、さらにUTを補充します。
チケットの目的通り改修し、それに合わせてUTを変更します。
PRを作成します。
- UT以外の、手動で実施したテストの内容(エビデンス)などを記述します。
レビュー を受けます。
- レビュー担当はメイン担当と同等の責任で品質を担保します。
  - 分からない箇所があれば、Meetなどでやりとりします。
- 必要に応じて修正します。
レビューが通ったらマージします。
毎週数回デプロイしています。マージしておけば次回のデプロイで自動的にリリースされます。

チームのWorking Agreement

以下はLMS開発チームのWorking Agreement(抜粋)です。私達はこれに従って開発を進めています。

━━━━━━━━━━━━━━━━━━━━━━━

私達はチームワークで事業に価値を提供しようと努力する。
そのため、積極的に発言し、コミュニケーションを行う。

個人としての成果よりもチームとしての成果を求める。