はじめに
ご挨拶
皆さんこんにちは。
工業大学3年のすーどぅーです。
今回は、私が所属している課外活動「CirKit(サーキット)」にて毎年実施しているエンジニア研修について、「研修内容を変更することに対する是非」という観点で考えてみたので、ここでアウトプットします。
CirKitについては、こちらを参照ください。
この記事について
この記事は、学生団体における次年度のエンジニア研修を検討した記録です。毎年作成されている研修ページと実際の開発体制を前提にしていますが、プロダクト固有の詳細、個人名、非公開情報は扱いません。
学生団体で新入生向けのエンジニア研修を運営していると、「現在使われている技術を、そのまま研修へ採用すればよいのではないか」と考えがちです。しかし、研修は単なる技術の導入ではありません。研修生がフロントエンド・バックエンド・インフラ寄りの役割を理解し、次に深めたい方向を考える場でもあります。
私たちの団体では、Web制作、学内サービスの保守、カフェ営業を支える仕組み、独自のPOSレジなどを扱っています。開発チームの技術スタックもRuby/Rails、React、Go/Swift、TypeScript、Flutter/Goと複数あります。現在の研修では、HTML、CSS、JavaScript、WSL、Docker Compose、Git/GitHubを共通基礎とし、その後にRuby/Railsでアプリケーションをつくっています。
一方で、Flutterを使うチームは今後増える見込みがあり、Ruby/Railsを使うチームにもNext.jsまたはFlutterへの技術変更の可能性があります。そこで、次年度の実装研修をRuby/RailsからFlutterへ変更するべきかを考えました。
この記事での「フロントエンド」は主にUI・クライアント側の実装、「バックエンド」はAPI・DB・認証・業務ロジックなどのサーバー側実装を指します。実際のプロダクトでは境界が重なることもありますが、研修では役割を意識して体験することを重視します。
まずは結論
Ruby/Rails研修をFlutter単独の研修へ置き換えることは、現時点ではあまり妥当とは言えないと判断しました。
Flutterの導入自体には賛成です。FlutterはDartを使い、単一コードベースからモバイル、Web、デスクトップなどを対象に開発できるため、モバイルを含むUI開発の入口として有力です。1 ただし、Flutterだけを主軸にすると、研修がフロントエンド、またはクライアントアプリ開発に寄りやすくなります。
現行のRails研修には、画面だけでなく、Controller、Model、DB、認証までを一続きで扱える価値があります。研修生が「画面をつくること」と「データやAPIをつくること」の両方を経験し、どちらを深めたいかを考えるためには、この価値を失うべきではありません。
Flutterを導入することと、Flutterだけを共通研修にすることは別の判断です。前者には賛成できますが、後者はバックエンド経験を失うおそれがあります。
そのため、私の考える「次年度の本命案」は次の通りです。
共通研修は、Reactをフロントエンド、Rails APIをバックエンドとする小さなフルスタック開発へ段階的に移す。Flutterは共通必修の置換先ではなく、後半の選択トラックまたはFlutter系チームへの入口として位置付ける。
この案であれば、既存のRails教材・メンターの知見を活かしながら、Reactチームにも接続できます。将来Goの教材とメンター体制が整えば、バックエンドをGo APIへ段階的に広げられます。
現行のRails研修は、何を実現しているのか
技術選定を議論する前に、現行研修の役割を言語名から切り離して整理します。公開されている研修ページでは、環境構築やWeb基礎を学んだ後に、Ruby/Rails、DB、チーム開発へ進み、3〜4人で簡単なアプリケーションを開発する流れが示されています。
この構成で研修生が得ているのは、RubyやRailsの文法だけではありません。
| 現行の要素 | 研修生が得る経験 | 技術が変わっても残すべき理由 |
|---|---|---|
| HTML / CSS / JavaScript | UI、フォーム、イベント、非同期処理の基礎 | Web・モバイルを問わず、画面とユーザー操作を考える土台になる。 |
| WSL・Docker Compose | CLI、開発環境、複数サービス、DBを起動する経験 | 現場の開発環境を再現し、チームで揃えるための共通言語になる。 |
| Git / GitHub | Issue、Pull Request、レビュー、コンフリクト解消 | すべてのチームに共通する、最も重要な協働スキルである。 |
| Rails View・Controller | 画面とリクエスト処理がつながる感覚 | フロントエンドとバックエンドの境界を理解する入口になる。 |
| Model・DB | データを設計し、保存・検索・更新する経験 | 「画面の裏側」を自分で実装する経験になる。 |
| Deviseなどの認証 | ユーザー、権限、個人データを守る考え方 | 本番開発で認証・認可が必要になる理由を理解できる。 |
| チーム開発 | 分担、統合、仕様共有、レビュー | 個人学習からプロダクト開発へ移るための橋渡しになる。 |
このように、現行のRails研修はフロントエンドとバックエンドを体験するための研修として機能しています。Railsチームの技術変更があり得るとしても、研修が担ってきたこの機能まで手放す理由にはなりません。
Flutter導入が魅力的に見える理由
Flutterを候補にすることには十分な合理性があります。FlutterはDartを使うUIフレームワークで、同じコードベースから複数のプラットフォームを対象にできます。1 UIを構成するWidget、フォーム、状態、画面遷移、HTTP通信を段階的に学べるため、小さなアプリをつくる研修に向いています。公式の学習経路も、環境構築、Dart基礎、小さなアプリの段階的な作成という順序を示しています。2
団体の側から見ても、Flutter/Goを使うチームがあること、Flutterを採用するプロダクトが増える見込みがあることは大きな利点です。研修後の参加先が見えている技術を扱うと、学習内容と実際の活動が結び付きやすくなります。
| Flutterを導入する利点 | 団体にとっての意味 |
|---|---|
| モバイル・Webを意識したUI開発を学べる | Web制作だけでなく、アプリや業務支援ツールへ関心を広げられる。 |
| Flutter系チームの入口になる | 研修直後に既存チームへ参加する導線をつくれる。 |
| 画面の変化を確認しながら学べる | 初学者が実装結果を視覚的に捉えやすい。 |
| Dart・Widget・状態管理を学べる | クライアントアプリの設計を体系的に学ぶきっかけになる。 |
ただし、これらはFlutterを導入する理由にはなりますが、Flutter単独へ全面置換する理由にはなりません。
最も大きな懸念：研修がフロントエンド中心になる
Flutterを主軸にした場合の本質的な懸念は、研修生が画面実装とAPI利用だけを経験し、バックエンド側の実装に触れずに終わることです。
Flutterから既存APIを呼び出せば、通信、JSON、ローディング、失敗時のUIは学べます。しかし、次のようなバックエンド側の問いを自分で扱う機会は減ります。
| バックエンドで考えること | Flutterから既存APIを呼ぶだけでは得にくい経験 |
|---|---|
| API設計 | URL、HTTPメソッド、リクエスト、レスポンス、エラー形式を決める。 |
| 入力検証 | 空文字や不正な値に対して、どのようなエラーを返すか決める。 |
| DB設計 | テーブル、主キー、必須項目、データの関係を考える。 |
| 永続化 | 受け取ったデータを保存し、一覧・詳細として返す。 |
| 認証・認可 | 誰がどのデータを見て、更新してよいかを制御する。 |
| テスト・運用 | APIテスト、環境変数、ログ、Dockerでの再現性を整える。 |
バックエンドは、既存APIを「使う」だけでは十分に体験できません。 研修でフロントエンドとバックエンドの適性を考えてもらいたいなら、全員が小さくてもAPI・DB側を自分で実装する必要があります。
研修生にバックエンドを専門にしてもらう必要はありません。しかし、UIとデータの間にある仕事を一度自分で実装してみることには大きな意味があります。
研修の目的は、短期間で「フロントエンド向き」「バックエンド向き」と判定することではありません。両方の仕事を小さく経験し、次にどちらを深めたいかを本人が考える材料をつくることです。
この目的を置くなら、Flutterのみを共通研修にする案は適しません。
検討した研修方式
フロントエンドとバックエンドの両方を経験でき、団体の既存スタックにも接続しやすい方式を比較しました。
| 方式 | フロントエンド | バックエンド | フルスタック体験 | 初年度の運用難度 | 団体との接続 |
|---|---|---|---|---|---|
| React + Rails API | React / JavaScriptまたはTypeScript | Ruby on Rails / DB | 高い | 中 | Reactチームと既存のRails教材・メンターの両方に接続できる。 |
| React + Go API | React / JavaScriptまたはTypeScript | Go / DB | 高い | やや高い | React、Go/Swift、Flutter/Goの設計理解に接続しやすい。 |
| Next.js + DB | React / TypeScript | Route Handler等のサーバー処理 | 中 | 低〜中 | RailsチームがNext.jsへ移行する場合に接続しやすい。 |
| Flutter + Go API | Flutter / Dart | Go / DB | 高い | 高い | Flutter/Goチームへ最も直接的につながる。 |
| Flutter + BaaS | Flutter / Dart | BaaSの設定・ルール | 低〜中 | 中 | Flutter導入の検証には向くが、バックエンド自作の経験は薄い。 |
各方式の評価を開く
React + Rails API
次年度の第一候補は、Reactをフロントエンド、RailsをAPIバックエンドに分ける方式です。
現行研修で蓄積してきたRuby、Rails、Model、Controller、DB、Docker Composeの教材を利用しつつ、Rails ViewをReactコンポーネントへ置き換えます。これにより、研修生は「画面をつくる層」と「API・DBをつくる層」を明確に区別して体験できます。
training-app/
├── frontend/ # React
├── backend/ # Rails API
├── compose.yaml
└── README.md
この構成の重要な点は、Railsを「過去の技術」として残すのではなく、API・DB・認証を学ぶための安定した教材基盤として再配置することです。Railsチームが将来技術変更しても、既存教材とメンターが機能する限り、研修のバックエンド側を支える価値があります。
React + Go API
React + Go APIは、長期的には非常に有力です。Reactチーム、Go/Swiftチーム、Flutter/Goチームのいずれにも接続しやすく、フロントエンドとバックエンドの責務も明確です。
一方で、初学者にとってはReactに加えてGo、HTTP、SQL、Dockerを扱うことになります。Goを採用するなら、並行処理や高度な設計まで教えず、JSON、HTTP、CRUD、SQL、Docker Composeまでを必修範囲に絞るべきです。
Go経験者が複数人いて、教材の更新・質問対応・Pull Requestレビューまで担えるなら有力な選択肢です。そうでなければ、移行初年度に無理に採用せず、Rails APIから始めて次年度以降に発展させる方が安全です。
Next.js + DB
RailsチームがNext.jsへ移行する可能性が高く、TypeScriptを見られるメンターもいるなら、Next.jsを使う方法もあります。一つの言語でUIとサーバー側の処理を扱えるため、短い研修期間でも完成に到達しやすいことが利点です。
ただし、画面、サーバー処理、DB操作が一つのプロジェクトに集まりやすく、初学者にはフロントエンドとバックエンドの境界が見えにくくなります。Next.jsを採用する場合は、UI、API、データアクセスの役割を教材・ディレクトリ・レビュー観点で明示する必要があります。
Flutter + Go API
Flutter + Go APIは、Flutter/Goチームへの接続という意味では最も直接的です。しかし、DartとGoを同時に学ぶため、移行初年度に共通必修として導入するには研修負荷が高くなります。Flutterを必修にするなら、バックエンド側を極めて小さくし、十分なメンターとスターターリポジトリを準備する必要があります。
この方式は、モバイル開発を明確な主目的にする場合、または共通研修を終えたメンバー向けの選択トラックとして適しています。
推奨する研修設計：全員が両方を触り、Flutterは選択肢にする
次年度は、技術を一度に全面移行するのではなく、次のように役割を分けるのが現実的です。
| 区分 | 扱う内容 | 目的 |
|---|---|---|
| 共通基礎 | HTML/CSS/JavaScript、WSL、Docker Compose、Git/GitHub | すべてのチームへ共通する開発の土台をつくる。 |
| 共通フルスタック研修 | React + Rails API + DB | フロントエンドとバックエンドの双方を、全員が実装する。 |
| チーム開発 | UI、API、DB、レビュー、発表 | 個人学習を、実際の協働開発へつなげる。 |
| 選択トラック | Flutter / Dart、Flutter Web、Android対応 | モバイル・Flutter系チームに関心がある研修生の入口にする。 |
| 発展トラック | Go API、認証、テスト、CI/CDなど | 研修後の興味や配属先に応じて深める。 |
カリキュラムの進め方
公開されている現行研修の「座学の後、3〜4人のチームでアプリをつくる」という構造は維持します。その上で、座学部分を次のように整理します。
| フェーズ | 内容 | 到達条件 |
|---|---|---|
| 0. 共通基礎 | HTML/CSS/JavaScript、WSL、Docker Compose、Git/GitHub | リポジトリを取得し、開発環境を起動し、Pull Requestを作成できる。 |
| 1. React基礎 | コンポーネント、props、state、フォーム、画面構成 | タスク一覧・作成フォームなどのUIを実装できる。 |
| 2. Rails API・DB基礎 | JSON API、Controller、Model、DB、CRUD、入力検証 |
GETとPOSTのAPIを自作し、DBへ保存できる。 |
| 3. 結合演習 | ReactからAPIへ通信し、成功・失敗・ローディングを扱う | 入力したデータをDBへ保存し、再読み込み後も表示できる。 |
| 4. チーム開発 | Issue分割、仕様共有、UI・API実装、PRレビュー、発表 | 全員がフロントエンドとバックエンドの両方で少なくとも1件のPRを出す。 |
| 5. 振り返り・選択トラック | 役割の振り返り、FlutterまたはGoなどの発展学習 | 次に深めたい技術・参加したいチームを説明できる。 |
チーム開発で「完全分業」を避ける
研修の目的に適性を考える機会も含めるなら、最初から「この人はフロントエンド担当」「この人はバックエンド担当」と固定しない方がよいです。
たとえば、最初の機能では一人がReactの一覧画面とGET /tasksを、次の機能では別の人が作成フォームとPOST /tasksを担当します。短い単位で役割を入れ替えることで、全員がUIとAPI・DBの双方に触れられます。
| 機能 | フロントエンド側 | バックエンド側 |
|---|---|---|
| タスク一覧 | 一覧画面、空状態、ローディング表示 |
GET /tasks、DBからの取得、JSON変換 |
| タスク作成 | フォーム、入力中の状態、送信後の更新 |
POST /tasks、入力検証、DB保存、エラー応答 |
| タスク編集 | 編集画面、更新後のUI反映 |
PATCH /tasks/:id、存在確認、更新処理 |
| タスク削除 | 確認UI、削除後の一覧更新 |
DELETE /tasks/:id、削除可否、適切なステータス |
研修生が実装したPull Requestと、最後の振り返りを配属相談の材料にします。短期間で適性を断定するのではなく、「画面の状態を追う作業が面白かった」「API仕様やDB設計を考える方に没頭できた」といった本人の感覚を、次の活動選択につなげるためです。
Flutterはどこで使うべきか
Flutterを研修から外す必要はありません。むしろ、共通研修でAPI・DB・HTTP・Docker Composeを経験した後なら、Flutterは良い選択肢になります。
Flutterは環境構築に加えて、Android向けに実行する場合にはAndroid Studio、Android SDK、エミュレータまたは実機の準備が必要です。3 そのため、移行初年度から全員にモバイル環境を求めるよりも、まずはFlutter WebでUIとAPI連携を経験できる入口をつくる方が安定します。
| タイミング | 全員が扱うもの | Flutterに関心がある人が扱うもの |
|---|---|---|
| 前半 | Web基礎、Git/GitHub、Docker、React、API、DB | なし |
| 後半 | チーム開発、API仕様、DB設計、レビュー | Dart、Widget、Flutter Web |
| 発展 | 要件・設計・運用の基礎 | Androidエミュレータ・実機、Flutterでのモバイル対応 |
この位置付けなら、Flutter/Goチームへ進みたい研修生に明確な導線を渡せます。同時に、バックエンドやWebフロントエンドに関心を持った研修生にも、十分な選択肢を残せます。
移行を決める前のチェックリスト
次年度にこの方式を導入するなら、技術名より先に運用面を確認する必要があります。
- React、Rails API、DBのそれぞれで質問対応・レビューを担えるメンターがいる
- React + Rails API + DBを起動できるスターターリポジトリと、Docker Composeの手順がある
- チーム開発の題材を、本番データ・実決済・個人情報に触れない範囲まで絞っている
- Rails教材を、現行案件向け・API教材・発展学習として残す方針がある
- Flutter選択トラックを支援できるメンターと、Flutter系チームへの参加導線がある
- Go APIへ広げる場合の条件として、教材・模範実装・メンター人数を明文化している
まとめ
Flutterを使うチームが増えるなら、Flutterを研修へ導入すること自体は有意義だと私は考えています。しかし、Ruby/Rails研修をFlutter単独へ置き換えると、研修が持っていたフルスタック経験の価値を失うおそれがあります。
研修生にフロントエンドとバックエンドのどちらが得意・好きそうかを考えてもらいたいなら、両方を自分で実装できる設計を残すべきです。
これまでの研修と同じように、チーム開発でそれぞれやりたいほうを選択し、そこで頑張ることができるのであれば、そのほうが確実に身につくことが多いはずです。
次年度はReact + Rails APIを共通のフルスタック研修として採用し、Flutterは後半の選択トラックへ置く。Go APIは教材とメンター体制が整った段階で段階的に導入する。
この形であれば、既存の教材資産を無駄にせず、React・Flutter・Goといった将来の技術構成にも接続できます。そして何より、研修生が一つの技術に早く固定されず、自分の次の学び方を選べる研修になります。
まぁ結局、Flutterを使うか使わないかを判断するのは私ではないので、この記事がその人たちに届けばいいのですが...