はじめに
プログラミングスクール「RUNTEQ」で学習を始め、
ポートフォリオとしてパンの在庫を管理するためのアプリをリリースしました。
開発背景やアプリ制作の学びをご紹介します。
なおアプリに関して改善点などございましたら、ご連絡いただけますと幸いです。
どのようなアプリを作ったか
GitHubリポジトリ
パン派の人が、パンの在庫や消費期限を手軽に管理できるよう開発したサービスです！
パンを食べようと思ったら、カビが生えてしまっていて仕方なく廃棄してしまった。
パンを食べようと思ったら、在庫を切らしてしまっていた。
そんな経験から、もっと手軽にパンの状態を確認できたら、同じような悩みを持つ人にも使ってもらえるのではと思いこのアプリを作ることにしました。
機能一覧
MVP
- ユーザー登録・ログイン機能
- ゲストログイン機能
- パスワード再設定
- 購入したパンの情報を登録
- ホーム画面にパンの状態・消費期限・残り数を表示
- 1日の消費数から在庫数を自動計算するロジック
- パンの状態が分かる動的な表示
- スマートフォンでの利用を前提としたレスポンシブUI設計
- パン登録を簡略化するため、いつも食べるパンを登録できる機能
- パンの情報をLINE共有
本リリース
- グループ機能
- 家族間でパン情報を共有
- OCR機能
- カメラによる消費期限読み取り
- 通知機能
- アプリ内通知
- LINE通知
- 通知ON/OFF設定
アプリ概要
基本の使い方
①パンを購入
②パンの情報を入力
③カードでパンの状態（消費期限や残りの在庫数）を確認
はじめに入力した消費数に応じて残り数が減ります。
手動での調整も可能です。
これでパンの期限や在庫状況を一目で確認することができます。
④食べ終わったら完食ボタンを押すことでカードが消えます。
便利な機能
-
いつも食べるパンの設定
会員登録していると、いつも食べるパンを登録することができ、パンの登録時に消費期限の入力だけでパンを登録できます。 -
LINEで通知を受け取る
LINEと連携するとパンの消費期限が近づいたり、在庫がなくなりそうになるとLINEでPankabiアプリからメッセージを受け取ることができます。
差別化したポイント
- 冷蔵庫全体ではなく「パン」に特化
既存の在庫管理アプリは多機能なものが多いですが、
ズボラな自分にとっては入力の負荷が高く、いずれ使わなくなるだろうと感じました。
では、パンだけだったらどうでしょうか。
パンは食材の中でも消費期限が短いですが、消費ペースが安定しやすく、習慣的に食べるものでした。
パンに特化することで入力負荷を減らし、継続して使いやすいサービスを目指しました。
技術的に工夫した点
ユーザーの入力の負担をなるべく減らしたいと考え、
いつも食べるパンの情報をあらかじめ設定できるようにしました。
しかし、消費期限だけは毎回入力が必要になるため、カメラで読み取れたら楽になるのではと考え
消費期限をカメラで読み取る機能（OCR機能） を実装しました。
消費期限の表記の仕方はパンの製造会社によって微妙に違うので
さまざまな表記に対応できるよう、OCR後の判定ロジックを調整するのが大変でした。
詳しくは別記事に書き起こしました。
使用技術
| カテゴリ | 技術 | 選定理由 |
|---|---|---|
| バックエンド | Ruby on Rails 7.1.6 / Ruby 3.2.2 | CRUDに加えて通知などの処理まで一貫して実装できるため。学習中の技術であり、理解した上で安定した開発が可能なため。 |
| フロントエンド | JavaScript / Hotwire（Turbo, Stimulus） | Rails標準技術を利用することで、フロントとバックエンドを分断せずに開発できるため。部分的な画面更新によりUX向上が図れるため。 |
| CSSフレームワーク | Tailwind CSS / DaisyUI | コンポーネントベースで直感的にUIを構築でき、ポップで分かりやすい画面を短時間で実装できるため。 |
| データベース | Neon | サーバーレスでRenderと相性が良く、無料枠で個人開発に向く |
| 認証 | Devise | 安全なユーザー認証機能を短時間で実装でき、将来的な家族共有機能の基盤として利用できるため。 |
| 外部API連携 | LINE Messaging API | 日常的に利用されているLINEで通知を行うことで、ユーザーが気付きやすく、家族間での共有にも適しているため。 |
| 文字認識（OCR） | Google Cloud Vision API | 消費期限入力の手間を減らし、ズボラなユーザーでも使いやすいUXを実現するため。 |
| インフラ / デプロイ | Render | 個人開発でも安定した本番運用が可能なため。 |
| 環境構築 | Docker | 開発環境差異によるトラブルを防ぎ、誰でも同じ環境を再現できるようにするため。 |
| CI/CD | GitHub Actions | プルリクエスト時に自動でテストを実行し、品質を保ちながら開発を進めるため。 |
開発振り返り
2025年 12月：どういったアプリを作るか考える
2026年 1月：issue作成、具体的な設計と実装スケジュールを作成
環境構築、実装スタート
2月：ひたすら実装、issueを切っていく
3月：MVPリリース、RUNTEQ生に使ってもらう
4月：機能追加、FBからUX改善、テストの追加
5月：本リリース
本リリースで予定していた機能は想定以上に実装コストが高く感じました。
特にAPIを利用した外部連携では、便利な反面、認証や設定周りの理解、エラー調査などに時間がかかり、調査に多くの時間が必要でした。
アプリ開発からの学び
タスク管理とスケジュールを見積もることの大切さ
開発ではGitHub Projectsを活用し、実装前にissueを作成して、おおまかなスケジュールを立てながら進めました。
事前にタスクを整理しておくことで、
- どの機能に時間がかかりそうか
- どこで詰まりそうか
を把握しやすくなり、開発全体の見通しを持つことができました。
実際には、想定より時間がかかったり、追加タスクが発生したりすることもありましたが、やるべきことを可視化していたことで進捗を確認しながら進められ、最後まで継続できたと感じています。
AIを活用する中で感じたこと
聞いたらコードを教えてくれる大変便利なAIですが、やっぱり使い方には気をつけるべきだと感じました。
早く形にしたいという思いと、とても楽であることから、どんどん実装もAI任せにしたくなります。
実際コードを書いてもらったりもしたのですが、中身を理解せずに進めると、
- 設計意図と異なる実装をしていた
- 振り返った時にどういうことを実装したのかよく分かっておらず学びになっていない
- 頭に残らない
といったことがありました
AIに頼りきるのではなく、自分で理解しながら活用することの重要性を感じました。
おわりに
プログラミング初心者の自分が、Webアプリを0から作り上げることができたのは、RUNTEQの皆様や、相談に乗ってくださった卒業生・講師・同期の方々、そしてAIツールの進化に支えられたおかげです。感謝申し上げます。
このアプリの開発は終わりではなく、今後も改良していきたいと思っていますので、実際に触っていただけると嬉しいです！
最後までお読みいただきありがとうございました。