# ハッカソン(3/20)

### 要件定義

- これを作る理由
- 現状の課題
- 漫画を描いてる人のツイートからそれだけを見たいけど、日常ツイートなどに紛れて本来の目的(漫画)に辿り着きにくい
- 本来どういう状態であれば良いのか？
- 漫画を他のツイートに紛れないように見れると良い
- これを解決するためにはどうあれば良いのか？
- 漫画だけを抽出できるようなものを作ることができれば良い

- どのように解決するのか
- これを導入してどう使うのか？
- ツールを利用して漫画のみを閲覧できるようにする
- 機能要件
- スコープ
- 入力されたユーザー名に紐づいた漫画の表示
- その漫画が閲覧できる
- 処理フロー(これに関しては暫定 話し合いをする)
1. ユーザー名を入力する
2. その対応するユーザーのメディアを取得(画像とか)
3. その取得したものを機械学習モデルに取り込む
4. 機械学習モデル内で漫画とその他で振り分け
5. 漫画と判定されるものをサーバーに出力
6. 出力されたものをフロントに送り画面に表示
- 非機能要件
- 信頼性要件
- このツールは24時間365日原則的に稼働すること
- メンテナンス中はアクセスされた際にメンテナンス画面を出力
- メンテナンス中はその画面以外は表示されないように制御すること

- 性能要件
- ツイートの取得時間は可能な限りレスポンス時間を短くする。もし、長くなってしまうはユーザーのことを考えた実装をすること
- 機械学習モデルに取り込み判定の際の速度と判定後のレスポンス速度においても可能な限り短くする。もし、長くなってしまう場合はユーザーのことを考えた実装をする。精度と速度はトレードオフであるはずなので検討してみる。

- セキュリティ要件
- 公開すべきでないファイルを公開しないこと(ex:APIキーが入ったファイルなど)
- 不必要なエラーを返さないようにエラーハンドリングをする
- アクセスログに関しては記録してlogファイルに貯められるようにする(できれば)
- 基本的なセキュリティ対策
- SQLインジェクション
- XSS
- XSRF
- 基本設計
- 画面設計(UI設計)
- 各画面で何をするのか？(SPAでやるのか？)
- 表示する情報は何か？(文字・画像・レイアウトは？)
- これらを画面遷移図にまとめる
- 機能設計
- 裏側の処理はどうするのか？
- 基本的にフロントから受け取った情報に基づいて処理のリクエストをTwitterAPIに送信し、その情報を機械学習モデルに送信(画面から入力された値)
- 機械学習モデルで判定されたものを再び受け取りフロントに返す(画面に表示)
- データ設計(データフロー書かないとまずいかも)
- プログラムに入力されるデータ
- Webの画面からユーザーによって入力されるデータ
- プログラムから戻ってくるデータ
- 入力されたデータを機械学習モデルに入れて判定された後の返ってくる画像データ
- DBにユーザー単位で漫画を保存する形なら必要
- 漫画をそもそもユーザー単位で分けるのかどうか？
- その場合は簡単な認証機能の実装が必要になる
- 詳細設計
- システムアーキテクチャどうする問題
- レイヤードアーキテクチャ(これが無難)
- もしくはアジャイル開発っぽく作りながら考える形でもOK(まずは動かすところから)

- 誰がどこを担当するか？(手が空いたら次やる感じでも良いかも)
- たなこー
- 機械学習周り
- しゅう
- TwitterAPIを利用して画像を拾ってくる
- フロントにレスポンスを返せる処理
- フロントから値を受け取る処理

- タスクの優先順位と今やるべきこと
- golangで使いたい検索の値をformから受け取れるようにする
- デプロイ周りをどうするか問題(AWS?(ECS?)/firebase?/heroku?)
- CI/CDは導入する？
- たなこーのタスク
-エラーが起きたときの処理
-画面レイアウト
-機械学習モデルを実際に動かす

### ツールかサービスどっちにするか？

- ツール系の方が良い理由
- ユーザーを必要としない
- ユーザーありきのものじゃないからアクセスが少なくても需要さえ見込めれば一定層利用してくれる人はいる
- ツール系はターゲット層を絞って形にしやすい
- これは1にもつながる話で共有系とか、ユーザーありきのプロダクトにした場合にありがちだけど、上手くターゲットが絞れてなくてどの層にも刺さらなくて結局何がしたかったの？ってなりがち

- ユーザーありきのサービスはマーケとか営業ありき
- 正直個人開発ではきつい・・・
- ツールの方だと上記でも書いたように1人でも使う人いたら価値とか魅力はそれで伝わる
- 人の流動で価値が変わるのは魅力的ではあるけど、個人レベルだと諸々あってないよね
- 基本的にアクセスは少ないものと考えての実装が普通だからそこは考えた方がいい

- デメリットとしていくつかある
- ユーザーありきのサービスはコスパが悪い
- 良くも悪くも機能が多くなりがち
- やっぱり、自分も含むユーザー最近のサービスとかプロダクト機能豊富だからどこかで比較しがち
- そもそもユーザーどうやって集めるの？
- ハッカソンの発表の際に数十人程度のアクセスは見込めると仮定した場合、投稿型だったとするとそのうちの何人が投稿するだろうか？予測としてあげられるのが、大体数人~10人前後これってそもそもサービスとして成り立つか？
- 特に投稿型の場合は利用人数にサービスの魅力や良いところが詰まっている。(これは良いことでもあり、悪いところでもある)
- 実装が大変
- これに関してはコスパにつながる話だけど、ユーザーありきのサービスをちょっと想像して欲しい。(ex:TwitterなどのSNS・ソシャゲなど)
- こんなに大規模になるわけではないけど、機能が複数あるのが分かるよね。基本的なCRUD(Create/Read/Update/Dlete)処理は必須でその他多くの機能が備わってる事が前提
- なので、開発に割ける時間と自分の今の出来ることの兼ね合いでやることが大事(今回だと多く見積もっても2日(実働時間))

### 技術選定

- 技術選定する上で考えること
- 技術優位性
- この技術がどういう使われ方をしていて、同系統の技術と比較した際に何が違って、どういう部分で優位性があるのか？
- これに関しては決める際にある程度情報収集してから実装するべき
- プロダクトを作る際に必要なデータ(DBを使う場合)
- 例えば、ツールならそれに使うデータの保存の仕方とかどこで取り出すのか？など
- これに関してはER図とかをまず書く
- 要件定義とか設計の部分で必要になってくる

## 参考リンク
https://qiita.com/Saku731/items/741fcf0f40dd989ee4f8