Skip to content

okonakona/eatables

Repository files navigation

簡易仕様書

公開リンク

https://eatables.vercel.app/parent

テストアカウント

母親ログイン

メール:mother@example.com
パスワード:password123

子供ログイン

メール:mother@example.com
パスワード:password123

アプリ名

EATABLES

“eatable” 食べても安全で,味に関しての満足度もあるもの + 複数形 "s"

コンセプト

子どもが自然に使用し、ママが助かる食材共有・管理アプリ

メインターゲット : 思春期の男子中高生とワーキングマザー

作品の概要

冷蔵庫の食べ物を勝手に食べて / 食べられて 親子喧嘩になった経験ありませんか?

家の中の "食べていいもの" だけをリスト化して共有することで、 毎日の「お腹すいたけど食べていいものがわからない」「なんでそれ食べたの!?」を、もう繰り返さない。

「使って得するのは子ども。 でも助かるのはお母さん。」

→ 家族みんなが自然とちょっと幸せになる、 新しい家庭内コミュニケーションアプリ

対象(推奨)ブラウザ

Chrome レスポンシブ対応が間に合っておらず、 iPhone 12~14 (ウィンドウ幅390)のものが推奨です

開発環境/言語

  • フロントエンド vsCode/HTML、CSS、TypeScript
  • バックエンド vsCode/php

フレームワーク(ver.含む)

  • Next.js : 15.3.4
  • Tailwind CSS : v4

機能概要(機能一覧)

食品追加 機能

忙しいお母さんが食品を登録する負担を減らすため、 "感覚的に""その場で"操作できる設計と、項目を必要最低限にして"簡単だ""すぐできる"と思ってもらえるよう意識しました。 視覚的な手軽さを邪魔せず、便利な機能を追加するのがこれからの展望です。

  • 食べていいものを登録
    "食べて欲しいもの""食べられても問題ないもの"のみを登録してリスト化します。
    これによりお母さん側は食材の予定外消費や食品ロスが減り、ストレスを軽減することができ、
    子供側は許可(LINEで言う返信など)を待つことなく、空腹感を満たすことができます。
    ”食べても問題ない”、"怒らない/怒られない"と明らかにすることで、家庭内のすれ違いや言い合いを減らします。

  • 消費優先度の設定
    調理済みだったり、開封済みだったり、賞味期限が早かったり。
    "なるべく早く消費してほしい"食品と、"べつに食べても困らないよー食べてもいいよー"みたいな食品って、ありますよね。
    当アプリでは優先度を視覚的にわかりやすく表示し、食品にポイントを付与することで優先的な消費を促します。

  • カテゴリーの選択
    出先で追加することや、写真を撮影する労力を考慮し、用意したイラストの中から感覚的に近しいと思うものを選んでいただく形にしました。
    食材のジャンル分けが難しいことや、デザインモチーフが冷蔵庫であることから、冷蔵庫にいる食べ物たち(肉,魚,果物,野菜,乳製品,おやつ,飲み物)、とその他(ミステリーボックス)をイラスト化しました。

  • 写真登録や位置の指定(今後の展望)
    位置の説明が文章では難しかったり、似たような商品が複数あったり、昨日の残り物だったりで判別が難しい場合があるため、
    詳細に画像を追加できる機能だったり、簡単に冷蔵庫の中の図(マッピング的な?)を用意してワンタップで選択できるといいかも...?

  • 個数の設定(今後の展望)
    袋詰めのお菓子や6Pチーズなど内容物が複数個ある場合、何個か残っているのか完全に消費されたかだと全然違いますよね?
    帰宅して見て確認して、残っていたらもう一度リストに追加する、無かったら確認する。なんてクールじゃないので
    最初に指定してシステム側で処理する形を取りたいです。

  • テンプレートや履歴(今後の展望)
    入力をサポートする機能です。

消費報告 機能

食べた後に報告をしてもらう設計上、"お腹が空いたからご飯を食べる"という一番大きなゴールを達成しているため子供のやる気を保つことが難しく、 ゲーミフィケーションを取り込み新しい行動理由を作ることを意識しました。

  • 食べた報告を送信
    食品が消費されたあと、報告がないとお母さんが困ってしまいます。
    しかしめんどくさいですよね。
    なので1タップのみで報告が完了する仕組みと、報告完了時にポイントが付与される設計で目的達成後(お腹が満たされた後)の子供のやる気を保ちます。

  • 好き度の設定
    思春期真っ只中、どうしても会話が減ってしまうと思うので、「あの子ピーマン苦手だったのに食べられるようになったんだ」とか「これ好きなのね」など子供の成長や好みを把握することができます。
    星5つで評価する形にした理由として、静かでマイルドなコミュニケーションを取るためです。
    「あれ美味しかった、好き」って素直に褒めるのが恥ずかしかったり、悪い方向だと「あの料理不味い」だとか言われるとお母さん傷つきますよね...
    なので送る方は手軽で、受け取る方は自分の想像で咀嚼することができるよう、双方が快適に使用できる設計を意識しました。

  • 残量の報告(今後の展望)
    複数個あったり、量が多かったりすると全部食べ切らないですよね?
    そこで、残した場合やお母さん側が報告を申請している場合に、どれくらい残っているのか提示する(写真など)機能があればいいなと考えています。

履歴確認 機能

子供の食べた報告を通知だけでなく履歴としてまとめて表示する機能です。

  • 報告一覧をカード型で表示
    食品名、好き度、消費された日時を一目見てわかりやすいよう表示しています。
    買い出しなどの関係で、消費された日時が明確である方が良いと考えました。

  • 好みの分析やソート(今後の展望)
    過去の報告を分析してパーソナライズしたい。それをもとにおすすめ食品提案したり好きそうな順番に並べ替えるソート機能とかあったらいいなと考えています。

以下未実装

リクエスト 機能

上記の消費報告機能で少し説明したゲーミフィケーションの続きで、ポイントを貯めることで得られるリワード(報酬)の部分です。 食材ごとに割り振られたポイントは食べた報告をすることで経験値として取得することができ、一定ポイント貯まるとユーザーのレベルが1上がる仕組みになっています。 1レベル上がるごとに1つおやつリクエスト券が付与される仕組みです。

  • おやつリクエストを送信
    難しいリクエスト(インドのお菓子、ホールケーキ1個、など)を弾くため、複数(3つ以上)必ず送信する仕組みにしています。
    お母さん側はリクエストの中から一番実現性が高いものを選んでリストに追加していただけます。
    再リクエストの申請も送れたらいいな

  • ブックマーク機能(今後の展望)
    リクエストされたものをブックマークやフォルダ分けできたらいいなと考えています。("好きなお菓子"フォルダに"ポテチコンソメ"など)
    今後の買い出しや頑張っている時のちょっとしたご褒美などに役立てて欲しいです。

アンケート 機能

なくてもいいけどあったら嬉しいおまけ機能です。 週に1回アンケートを送信できて、送信すると追加ポイントが付与される仕組みにするつもりです。

  • ご飯アンケートを送信
    献立に悩むお母さんのお助け機能
    あくまでも何が食べたいですか?というアンケートで、必ず実行されるわけではないという設計。
    この子この料理好きなんだ、作ってみよう/作ってあげよう的なお母さんの匙加減な機能です。

  • ブックマーク機能(今後の展望)
    上記のリクエストと同じくアンケート結果をブックマークやフォルダ分けできたらいいなと考えています。

こだわったポイント

一つ目は、企画面、設計にかなりこだわったことですかね。
思春期の子供と、お母さんの衝突を減らして、関わり(知る)を増やす。家庭内をちょっとハッピーにする、という意識を一貫して取り組みました。
子供が使用してくれたら自動的にお母さんが助かる設計なので、
子供に繰り返し使用し続けてもらうためのHookモデルを考えたりなど今回かなり力を入れました。


二つ目は、明確な学習目標を設定し、自己の成長につながる取り組みを意識したことです。特に、これまで経験のなかった新しい技術への挑戦を重視し、積極的に導入しました。
具体的には、フレームワークの使用とデータベースおよびAPIの設計・実装に注力しました。
フレームワークに関しては、React・Next.js・Tailwind CSSといった授業で扱ったことのない技術を独学で学び、実際の開発に活用しました。導入や立ち上げ、使い方の習得を一から調べながら進める必要があり、慣れていないため多くの困難がありましたが、その一方で便利な機能や開発効率を高める可能性を実感することができました。
データベースとAPIについては、授業で得た基礎知識を応用しながら、個人制作としてゼロから設計・実装を行う経験を積みました。自ら考えながら進める過程は難しく、特に設計の段階で多くの試行錯誤を伴いましたが、実践的な理解を深める貴重な機会となりました。

デザイン面でこだわったポイント

管理アプリってどうしても重く感じてしまうんですよね、例えば入力画面のコンテンツが多いと「あーーーーーーーめんどくさい!」って私は思ってしまいます。
当アプリのデザインではいかに「簡単そうに見えるか」をかなり意識しました。
表示するものを必要最低限に、それでいて感覚的に操作できるuiを目指してデザインしました。
文字の増減でレイアウトが崩れやすいことと、今後の追加機能(今後の展望の部分)をどう組み込むかが今後の課題だと認識しています。

自己評価

制作全体を通じて、知識不足や時間的制約(期間としては5~9月)による苦労を強く実感するとともに、「もっと工夫できたのではないか」という反省点も残りました。しかし、その中でも新しい技術に挑戦し、自分なりに調べながら形にできたことは大きな成果だと感じています。
今回の経験を通して得た学びを、今後の制作活動に活かしていきたいと思います。

テーブル定義(ER図)などの設計ドキュメント

eatables_families

カラム名 属性 説明 初期値
id INT PK 家族ID なし
name TEXT NOT NULL 家族名 なし
created_at TIMESTAMP 登録日時 now()
updated_at TIMESTAMP 最終更新日時 now()
delete_flag BOOLEAN NOT NULL 論理削除フラグ false

eatables_users

カラム名 属性 説明 初期値
id INT PK ユーザーID なし
family_id INT FK, NOT NULL 家族ID(eatables_families.id) なし
name VARCHAR(100) NOT NULL ユーザー名 なし
email VARCHAR(255) UNIQUE, NOT NULL メールアドレス なし
password VARCHAR(255) NOT NULL パスワード(ハッシュ化) なし
role ENUM NOT NULL 'mother' or 'child' なし
experience INT 経験値 0
level INT レベル 1
created_at TIMESTAMP 登録日時 now()
updated_at TIMESTAMP 最終更新日時 now()
delete_flag BOOLEAN NOT NULL 論理削除フラグ false

eatables_foods

カラム名 属性 説明 初期値
id INT PK 食材ID なし
name VARCHAR(100) NOT NULL 食材名 なし
category ENUM NOT NULL 食材カテゴリ なし
exp_points TINYINT NOT NULL 獲得経験値(1 または 3) 1
is_priority BOOLEAN 優先的に食べるべきかどうか false
message TEXT メモや補足メッセージ なし
family_id INT FK, NOT NULL 家族ID(eatables_families.id) なし
created_at TIMESTAMP 登録日時 now()
updated_at TIMESTAMP 最終更新日時 now()
delete_flag BOOLEAN NOT NULL 論理削除フラグ false

eatables_eaten_history

カラム名 属性 説明 初期値
id INT PK 食べた履歴ID なし
food_id INT FK, NOT NULL 食材ID(eatables_foods.id) なし
rating TINYINT CHECK (1〜5) 星評価 なし
created_at TIMESTAMP 登録日時 now()
updated_at TIMESTAMP 最終更新日時 now()
delete_flag BOOLEAN NOT NULL 論理削除フラグ false

About

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published