目次
1.はじめに
2.目的
フードロス問題
コンビニのフードロスを選んだ理由
3.サービス概要
1.商品出品
2.買い手側は商品を検索、購入
3.買い手側と売り手側にそれぞれ購入メールが送信
4.購入商品をキャンセル、出品キャンセル
5.賞味期限、価格、都道府県別の検索機能
4.こだわったポイント
1.シンプルなデザインと機能
2.都道府県検索
3.ツイッターシェア機能
5.使用言語
6.使用したライブラリ
7.ER図
8.AWS構成図
9.今後実装したい事
10.反省
11.終わりに
1. はじめに
はじめまして!!
こうすけと申します。
宜しくお願い致します!
個人開発【 haiki-share(コンビニフードシェアリングサービス) 】
現在は転職の為に実務で扱っていたVue.jsに加えLaravelやAWSを学んでいます。
今回は学習した技術を使ってフードロス削減サービスを作りました。
2. 目的
目的は前述した通りコンビニのフードロス削減です。
なぜそのサービスを作ろうかと思ったか、その背景は以下の通りです。
フードロス問題
数年前ぐらいから「フードロス」という言葉をニュースで見るようになりました。
日本の食品ロス発生量は、世界第3位で年間600t以上の食べ物を捨てられている。
およそ東京ドーム5杯分。
捨てるぐらい食べ物が潤っている幸せな国だと捉えれば良いように思いますが、
世界で飢えに苦しんでいるまだまだ多く居る中、これは問題だなぁと。
しかもよくよく考えてみると、生産者はもちろんのこと消費者にとってもデメリットがあります。
理由は、廃棄食品が発生すればそれを運んだり燃やしたり、あるいはリサイクルする場合でも費用は発生するはず。
発生した費用は商品の価格に上乗せされ、僕たち消費者がそれを負担することになります。
昨今、円安の影響で物価が上昇している中この問題を解決することは大きな社会的意味があるのではないかと思い、廃棄ロス問題に関わるサービスを作ろうと思いました。
コンビニのフードロスを選んだ理由
フードロスについて調べてみると、食品ロス削減アプリや通販サイトなどが数多く存在していることがわかりました。
そして、それら多くのサービスは肉、魚、野菜からお菓子といったバラエティ豊富な食品を扱っています。
せっかく作るなら同じようなサービスを作っても面白くないですよね。
なので、まだ無いサービスを作ろうと考え何かのジャンルに特化した食品ロスサービスを作ろうと思い、色々調べているとコンビニの食品ロスも1年間に約20~30万トンの食品が捨てられていることがわかりました。
コンビニはスーパーの食品と比べて、相場より価格が高く設定されている。
(便利、手軽さという付加価値がついているため)
だから、多少賞味期限がギリギリでもコンビニ食品を安く買いたいという需要はあるはず。
コンビニ側も捨てるぐらいなら、安くても売れた方が良いのでお互いにとってメリットがあり、コンビニに特化した食品ロスサービスはありませんでした。
これが「haiki-share」を作ろうと思った決めてになります。
3. サービス概要
1.商品出品
売り手側のユーザー登録後、マイページから商品の出品ができます。
使いやすさ重視のため、ドラッグ&ドロップで写真をアップロードできたり、
vueのプライグインを使い、賞味期限の日時や日付も登録し易くなっています。
2.買い手側は商品を検索、購入
出品商品を条件で絞り込んで閲覧可能。
購入済みでない商品であれば、商品詳細ページから購入します。
購入商品はマイページの購入商品一覧で確認できます。
3.買い手側と売り手側にそれぞれ購入メールが送信
買い手側、売り手側それぞれ文面の違うメールが登録メールアドレスに届きます。
学習用の個人開発とはいえど、購入されて通知がないサービスは存在しないですからね。
4.購入商品をキャンセル、出品キャンセル
自分が購入した商品は商品詳細ページから購入キャンセルが可能。
キャンセル後、マイページから購入商品が消え、商品一覧ページの「購入済」ラベルや購入済みボタンなども無くなります。
売り手側は出品商品の編集画面から出品キャンセルができます。
キャンセル後、マイページや商品一覧ページから出品商品が無くなります。
5.賞味期限、価格、都道府県別の検索機能
買い手側のユーザーフローを考えた時、価格での絞り込みはもちろんのこと、自分の近い地域や賞味期限切れかどうかで商品を選ぶだろうと思いました。
(到着までの時間や賞味期限切れや賞味期限が近いものほどお得に商品が買えると思うため。)
出品店舗の都道府県と商品価格、賞味期限切れか期限内かで絞り込みができます。
4. こだわったポイント
1.シンプルなデザインと機能
コンビニ食品が商品のため、ターゲットは年齢が10代~40代以上。
性別は、男女問わず利用されることを想定。
なので、誰でも嫌悪感なくサービスを使ってもらえるようシンプルなデザインにしました。
メインに紺色を使いサブで青、そのほかは白と灰色と色を使いすぎないよう注意しました。
2.都道府県検索
selectタグのアイテムに47都道府県を入れて表示させることもできますが、
それだと縦長に表示されスクロール量も増え、選択したいアイテムが選びにくくなります。
下記のように初期表示を地方毎のメニューに分けることで縦長問題も抑えられ選び易くなったかと思います。
また、必ず全都道府県、全地方を表示させないようにしました。
画面読み込み時、データベースから出店されている都道府県データを取得後、
取得した都道府県のみ表示させ選択できるようになっています。
理由は、出店されている都道府県のみ表示させれば良いからです。
3.ツイッターシェア機能
認知をしてもらい利用者数を増やすためにも、SNSとの連携は何かしら必要だと考えました。
toC向けのサービスでSNSとの相性も良いので、ボタンひとつでどんな食品がいくらで出品されているかツイートできる
ツイッターシェア機能を付けてみました。
シェア機能を作るのが初めてだったので、難しい実装になるかなぁと思ってたのですが、
数行のコードで実現できるとを知れたのは良い気づきになりました。
他にもSNS関連の機能など積極的に追加していこうかと思います。
5.使用言語
- HTML
- CSS / SASS
- Javascript / Vue.js(v2)
- PHP / Laravel(v5.8)
- MySQL
6. 使用したライブラリ
- vue2-timepicker ・・・時間入力コンポーネント
- vuejs-datepicker ・・・日付入力コンポーネント
- vuex ・・・データを一元管理する状態管理ライブラリ
- Vue-Router ・・・ルーティング制御ライブラリ
7. ER図
8. AWS構成図
9. 今後実装したい事
購入済み商品の自動削除
フリーワード検索機能
購入済み商品を除く検索機能
ソーシャルログイン機能
とにかく早くデプロイすることを中心に設計したため、
最低限の検索機能しかつけませんでした。
こういうtoC向けのサービスはフリーワード検索やソーシャルログインは
やっぱり必要ですね。。。
10. 反省
-
綺麗なコードを書こうと意識し過ぎてしまった。
実務では綺麗なコードを書くことはもちろん必要とされますが優先順位は、動くコードが最優先事項です。
for文やif文を使わずにもうちょっと短いコードが書けないかと考え過ぎた結果、2ヶ月以内にはデプロイすると決めていましたが、70日目にデプロイすることになってしました。 -
DB設計に間違いないかもっと確認するべきだった。
開発途中でDB設計の間違いに気づき、再度設計し直す手戻りが発生してしまった。
(買い手ユーザーと売り手ユーザーそれぞれのテーブルを作らずusersテーブル1つで開発を進めてしまった。)
DBはサービスの根幹なので、ワイヤーフレーム作成時にユーザーフロー図なども一緒に書いたりして入念に確認するべきでした。。。
11. 終わりに
最後まで読んで誠に頂きありがとうございました!
1つサービスを作るだけで、何十、何百と新しい発見や自分の課題が見つかるので
自分の成長のためにも引き続き個人開発は行っていきたいと思います!