1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

【微経験】独学で動画特化の料理レシピ保存サービスを開発するまで【Rails / Next.js / AWS / Docker / GitHub Actions】

Last updated at Posted at 2025-06-23

はじめに

こんにちは!ちゃんよ(@y4tk8)と申します。

今回、Web系開発企業への転職を目指して独学でWebサービスを開発しました。ポートフォリオが主目的ですが、実サービスを意識して微経験者なりに本気で取り組んだのでインプット 〜 開発 〜 リリースまでの経緯や苦労した点、感じたことなどを書いてみます。

何か役立つことがあれば幸いです。

自己紹介

大学卒業後、新卒で注文住宅メーカーに営業職として入社しました。3年間従事したのち、海外へのプログラミング留学を経て都内の受託開発企業へ入社。PHPでバックエンド開発をしていましたが諸事情で2ヶ月で退職しました。その後は広義のIT業界にはいましたが、エンジニアリングからは完全に離れていました。

改めてエンジニアへ転職するため、ポートフォリオ開発に至りました。

目次

1. ポートフォリオ紹介

top-image.png

サービス名:Yum Keeper
サービスURL:https://www.yumkeeper.net

※ゲストログイン機能を用意しているので是非お気軽にお試しください
 期限重視のため現状、レスポンシブは非対応です

サービス概要

動画特化の料理レシピ保存サービスです。YouTube動画と共に具材や調味料、分量などをシンプルに保存・管理できます。サービス名の由来は英語のYummy(美味しい)の短縮系であるYum + Keeper(貯蔵庫)の組み合わせ。「.com」のドメインは売り切れてました。。

GitHub

開発動機

私は普段から動画(特にYouTube)で料理レシピを探します。ただ、作り方を覚えても料理のたびに材料や分量をYouTube再生して確認するのが非常に面倒でした。そこで、YouTube動画と一緒にシンプルにレシピ管理できるサービスがほしいと思い、開発しました。

開発スケジュール

  • インプット:4ヶ月半
  • ポートフォリオ開発:5ヶ月(内訳は以下)
    • 企画:10日

      • 詳細:アイデア着想、競合調査、要件定義
      • 成果物:サービス概要書、機能一覧表
    • 設計:2週間

      • 詳細:データベース設計、インフラ設計、必要ページ洗い出し
      • 成果物:ER図、テーブル定義書、インフラ構成図 ※画面遷移図は手書き
    • 開発:4ヶ月

      • 環境構築:2週間
      • バックエンド:1ヶ月半
      • フロントエンド:2ヶ月
    • デプロイ:10日

      • 詳細:インフラ構築、CD導入、リリース

er_diagram.drawio.png

infra_prod.drawio.png

2. 機能一覧

1. ユーザーアカウント関連

  • サインアップ
  • サインイン
  • サインアウト
  • アカウント有効化
  • パスワードリセット
  • パスワード変更
  • アカウント認証メール再送
  • 退会
  • ゲストサインイン

2. レシピ関連

  • レシピ追加
  • レシピ詳細
  • レシピ編集
  • レシピ更新
  • レシピ削除
  • レシピ一覧
  • レシピ並び替え
    • 最新の更新順、追加日(新しい順)、追加日(古い順)
  • YouTube動画取得(YouTube Data API
  • YouTube動画埋め込み

3. その他

  • ページネーション(Pagy
  • 認可
    • 未認証ユーザーのアクセス制御
    • 他ユーザー保有レシピへのアクセス制御
  • バリデーション & エラーメッセージ表示
    • 空文字、長さ、フォーマットなど
    • YouTube Data APIから動画取得時、レスポンスに応じたバリデーション
  • フラッシュ
    • ユーザー操作に応じて成功 / 失敗の各種メッセージ
  • モーダル
  • 404エラー
  • 500エラー

3. 使用技術一覧

  • バックエンド
    • 言語: Ruby 3.3.7 / Ruby on Rails 7.2.2.1
    • テスト: RSpec
    • 静的解析ツール: Rubocop
  • フロントエンド
    • 言語: TypeScript 5.8.2 / React 19.0.0 / Next.js 15.1.6
    • テスト: Vitest / React Testing Library / MSW / Cypress
    • デザイン: Tailwind CSS / Shadcn UI
    • 静的解析・整形ツール: ESLint / Prettier
  • インフラ: AWS(Route53 / ALB / ECS on Fargate / ECR / RDS / ACM etc) / Nginx / Vercel
  • CI / CD: GitHub Actions
  • 環境構築: Docker / Docker Compose / Dev Containers
  • 外部API: YouTube Data API

4. 開発で苦労したポイント

  1. レシピの編集ページ
    編集ページは「DBに追加済みのレシピを初回マウントしてから、新たに登録する材料 & 調味料を追加 + 不要なデータは削除した上でそれらを全てPATCHでRailsに送る」という構成です。つまり、PATCHリクエストといっても中身は「既存データの更新 or 削除」「新しいデータの登録」が混在していたので、各データのID管理とデータベースとの整合性を取るために非常に苦労しました。

  2. フロントエンドのE2Eテスト
    CypressでシナリオベースのE2Eテストを導入しました。認証系のテストは書けましたが、メインのレシピ機能のE2Eが「ユーザーのトークン認証 + 非同期処理 + useEffectでの副作用管理」という色々な挙動が混合して、Next.js特有のタイミングのズレが頻発しました。加えて、それをCypressという独自環境で再現するのでとても難しく、どうがんばっても書けませんでした。

  3. 本番環境でのNginxとRailsの疎通
    環境構築時点でNigixとRailsをコンテナ化しました。環境差異を吸収するのがDockerの大きなメリットなので、デプロイはスムーズに進むだろうと思いましたがそんなことはなく。本番ではPumaサーバーをNginxより先に起動する必要がありますが、その対応が大変でした。ALBからのヘルスチェックが失敗したり、本番で成功したと思ったら今度は開発環境でエラーが出たり。最終的にComposeファイルもDevとProdで分離しました。

※工夫ポイントはGitHubリポジトリのREADMEに書いています

5. インプットに使った教材

サービス開発前にインプットに用いた教材を以下にまとめます。
これから学習する方の参考にもなれば幸いです。

書籍(敬称略)

Udemy

Techpit

その他

6. 振り返りと感じたこと

とにかく理解する

最初はわからないことだらけですが、理解の「点」が増えると次第に「〇〇ということは△△の可能性があるから□□をやってみよう」と自分で仮説を立てられるようになります。後から楽になるので、序盤に理解から逃げないことが非常に重要だと思いました。

期限を決める

期限 = 総工数 + バッファ。開発中、節目ごとに期限を設けてきましたが「これならいけるだろう」と余裕を持って〆切を決めても予期せぬバグや色々なイレギュラーは付きもので、何事もなくスムーズに完遂したことは一度もありませんでした。ただ、期限を守る前提があると、本来不要だったタスクを消したり優先順位や時間配分を組み替える知恵が生まれます。リスケは最終手段。

ChatGPTの使い方を工夫する

今のChatGPTは非常に高精度なので、公式ドキュメントを読んだ上で適切に質問すれば高確率で解決しました。回答精度が落ちてきた場合はメモリ全消去 & 新チャットで質問し直せば正しい答えが返ってくることもしばしば。これで問題の8割は解決しました。残り2割はググる(日本語も英語も)+ 自分で処理を追う。それでも解決しない場合はStack Overflow または teratailで質問してました。余談ですが、Stack Overflowは日本語で質問書いてDeepLで全英訳して投稿すると海外エンジニアもがんがんコメントくれるのでおすすめです(たまにスパム扱いされるのでカジュアルに英文直すと投稿できます)。

7. 最後に

2024年8月にProgateを始めて、サービス開発からリリースまで完遂できたことにひとまずホッとしています。私は年齢的に後発なので、微経験からエンジニアに戻ることに非常に葛藤しました。営業なら元の人柄やコミュ力で短期間で大きな成果を出すプレイヤーがちらほらいますが、技術の世界ではあり得ないと思いました。「通用するのか」「きちんと価値を出せるのか」を本当に悩みましたが、エンジニアとして再チャレンジすることを選びました。

私は事業やプロダクトをスケールさせる戦略などの上流に興味があるので、自分なりに価値を出せるようがんばります!

以上、長文ですが読んでいただきありがとうございました。

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?