###### tags: `オークション`
# オークション企画
## ユーザー体験
開催者
1. サービスを知りユーザー登録をする
2. 出品するものを決めてオークション開催を設定する
3. 配信時にURLやQRコードを使って入札者を会場に誘導する
4. オークション中も配信を続けオークション状況を実況する
5. 落札者が決まり入金を確認後商品を発送

入札者
1. 配信を見ているときに出品することを知りURLから会場に入る(オークションを見る分にはユーザー登録は必要ない)
2. 見るだけの人も楽しめる仕組みやUIは？
3. 入札する場合はユーザーを登録し即時決済できるようにクレカやキャッシュレスを登録し入札(オークションを成り立たせるためには入金をする制限時間を設けたほうが良い)
4. 落札者は商品の発送を確認し商品到着を待つ

## プロダクトのページごとの機能
= ホーム
- 一目でどのようなことができるアプリかがわかる見た目
- 出品者にも購入者にもアプリを使うメリットがあることを訴えかけるコンテンツ。ほとんどのビジターは何ができるアプリかわかりづらいと思うので動画などで一連の流れを見れるようにしておくとよい。
- ほとんどのサイトが入会金や会員費を取ったりしているのでそこが一切ないことを強調する、つまり差別化要素を強調(すぐ始められる、お金かからない)
- ネイティブがあることを前提にするならばアプリダウンロードへのリンク
- 開催中及び開催予定のオークション一覧を閲覧または検索できる機能
- フッターに規約書や会社概要へのリンクなどを貼っておく

= 個別ページ
== 購入者画面
- ライブ感を重視するために動画を埋め込めるまたはライブ配信できる機能
- ライブ映像のほかに商品の詳細説明や写真などを閲覧できる機能
- 金額がブラウザ更新なしに遅延なく更新される機能
- 値段をクリックすることでオークション価格を更新できる機能
- 落札時に落札したことを伝え決済へ導くモーダル
- チャットができる機能？?(例.画家が絵を売るときに絵について説明欄には乗っていない知りたいことを質問することができる)

== 出品者画面
- 入札誰が何回したかなどのアナリティクスが見れる
- 時間を調整できる機能
- 落札者決定機能(メッセージも一緒に送れる？)

= ユーザー登録ページ
- 出品者も購入者もストレスなく会員登録ができる仕組み
- 最初にメールアドレスまたはOAuthからの登録をさせる。その後出品者または購入者の詳細の情報を登録する。

= 出品登録ページ
- 出品物の写真
- 商品名(例.サイン入りTシャツ)
- 商品の説明
- 配送関係の情報
- 販売開始価格
- 希望価格
- 出品ボタン->確認

= マイページ
- 出品履歴
- 閲覧履歴
- ユーザー情報
- いいね情報
- 売上金管理
- 出品物管理機能

## 現在の問題点と考えるべき点

- 出品者と購入者の区別をどのように行っていくか(登録時やログイン時) ==done==
- 入札時に会員登録だとすぐに入札したい場合に時間に間に合わない。どのタイミングで会員登録するのがよいか。理想は会員登録をしなくても入札できることだがいたずらの数が増える。入札の気楽さといたずらの数のトレードオフをどのようにコントロールするか。
- オークション機能が最終入札から10秒後に終了だと既存のものと同じような仕組みで新しさがない(せっかくライブでやっているので特有の終わらせ方がほしい)
- 落札から出品者にお金が届くまでの詳しい仕組み
- 出品者から落札者に品が届く仕組み(プライバシーを守る、出品者の負担を最小限に)

## タスク(Wataru)
- スケジュール感を合わせる
- 各ページの詳細設計
- ER図(データモデルの設計)
- API設計(オペレーション設計)それぞれの地域
- 出品者と購入者の区別をどのようにすればユーザーに負荷がかからないか

## 差別化
- 入会費・年会費がなく入札までのハードルが低い
- 出品者がインフルエンサーであるため物自体に価値があるわけではなく出品者と物がセットで価値が出る
- 出品者に価値があるため権利など無形物を出品することができる
- リアルタイムでオークションを行うことができる

### それぞれのユーザーの必要情報
- 出品者
メールアドレス
本人確認書類
銀行口座情報
- 購入者
メールアドレス
クレジットカード情報
- 見学者
ログイン必要なし

## スケジュール
#### 10月
- 仕様書の完成
- ワイヤーフレーム、ER図、API設計
- 参考になるサイトを集めてよいところはパクる
https://www.mercari.com/jp/
https://fril.jp/
https://www.mbok.jp/?
https://auction.eco-ring.com/
https://www.straight-japan.com/
- API設計の参考資料と例
https://qiita.com/mserizawa/items/b833e407d89abd21ee72
https://developer.github.com/v3/gists/#list-gists
- ビジネス面におけるコンセプトや方向性の確定
- googleドキュメントの残りの部分を埋める
- (デザイン)
#### 11月
- 使う技術の大まかな決定(プラットフォーム、開発環境、フレームワーク)
- オークションサイトやリアルタイム性を重視するサイトはどの技術を使っている？(AWSの設計例などをみる)
https://aws.amazon.com/jp/solutions/case-studies/cookpad/
https://aws.amazon.com/jp/solutions/case-studies/monex/
- 環境の構築と今後誰でもできるように環境構築方法のドキュメント化
- コーディングにおけるルール決め(変数や関数名、gitのルール)
- エラー処理の設計
- ディレクトリ構造
- コーディング開始
- コーディングの予定についてはワイヤーフレームができ次第作るべき順番を定め予定に組み込んでいく
#### 12月
#### 1月
#### 2月
#### 3月
#### 4月
- リリ-ス

## 使用技術の候補
- firebaseまたはAWS lambda。webとネイティブアプリで統合プラットフォームとして利用することは可能か？
- Flutter ネイティブアプリとWEBのクロスプラットフォームで両方同時進行
- ExpressやララベルなどのMVCモデルフレームワーク(WEB方面をとりあえず安定して作ることができる)
- フロント→Vue API→Go インフラ→firebase(認証、データベース)