# 20220825 第1回MTG
## 参加メンバー
- kondo
- kaizuka
- miramira
- knj
- maruyama
- furukawa
- kubota

## 要件
Q&Aサービスを開発したい

社内向けYahoo知恵袋のようなもの。

###
質問が飛び交う。Wi-Fiのパスワードなんだっけ、とか。それらをまとめたい。

登場人物
- 会社
- 社員(管理者)
- 社員（ユーザ）

欲しい機能
- キーワード検索
- タグ検索

タグ機能が欲しい
- 検索しやすい、同じような質問を防ぐという目的
- タグのつけ忘れが考えられるため、フリーワード検索も欲しい
- タグの具体例: 「工場ライン」
- タグを作れるタイミング
- 質問作成時に作れると嬉しい。最初はいらない
- タグだけでも作れると嬉しい
- 1つの質問に対して、５個までタグを付与できる
- あまりたくさんつけるとわかりづらくなるため
- タグはつけなくても投稿できる
- 絶対つけないとならないと、適当な（「あああ」）とかのタグをつけられる恐れがあるため
- 誰でもタグは作成できる
- 質問にタグを付与できる人は誰でも
- タグの編集・削除をできるのは管理者のみ
- タグの文字数
- 1文字以上
- 30文字以下
- タグの説明
- 1000文字まで
- 具体例
- タグ：経理
- 説明：経理に関するタグです
- タグ：至急
- 説明：
- タグ：XXさん宛の質問です
- 説明：
- タグをまとめる機能
- 今はいらない
- 管理者が消せる

ユーザ
- 名前
- 英数字のみ
- 1文字以上
- 100文字以下
- 同姓同名OK
- ホバーした時にメールアドレスが出て来れば良い
- メールアドレス
- 退職者は見られない
- いらない
- 社員番号
- アイコン

管理者
- 退職者のユーザ削除
- 入社した人のユーザ追加
- 1人以上

会社
- 会社間では投稿は見れない
- 請求
- ユーザ数に応じて課金できる情報はほしい
- 会社より細かいグループは無さそう（部署とか）

投稿
- 構成要素
- タイトル
- 本文
- タグ
- 画像は今は不要
- URLを乗せられるようになると嬉しい
- URLを貼ると、リンク飛べるようになっていたら嬉しい
- 質問を削除できるか
- 自分の投稿は自分と管理者のみ削除できる
- 質問は編集できるか
- 自分の投稿は自分と管理者のみ削除できる
- メンションは不要
- いいね・投票機能は不要
- 存在するタグのみ、質問に投稿したい
- タグがなくても投稿できるようにしたい

トップページ
- 最新の質問が表示されると嬉しい
- 提案機能は必要ない

投稿頻度
- 1日10件を想定

ユーザはチーム(会社)を組める
副業先のチーム(会社)にもユーザは所属できるようにしたい

チーム(会社)
- 会社の人がメイン。たまに他社の人や業務委託の人もいる
- チームという概念は間違い。チーム＝会社と捉えて良い
- ゆくゆく外販するときに会社ごとに分けたい

売りたい
- 会社は１０社程度使いたいって言われた
- 同等の機能で、使いたいらしい
-

部署横断した質問ツールにしたい

社員は１００人
うまくいったらSaaSでDX。主力製品にしたい

社内だったら誰でも見れて、誰でも回答する

やめた人は閲覧できないようにしたい
匿名機能はなし

口頭か電話で現在利用している
社員は普段PC利用している

いろいろなパスがある
営業 -> 企画
企画 -> 経理

ベストアンサーもいいねも不要

### 背景・課題

- 他の人に伝わっていないことがある
- 社内で質問が飛び交っている
- ドキュメントはまとめてくれない
- 今は口頭や電話、メールで質問

## 開発体制の整理

## その他
- 1期・3期のメンターセッションは可能であれば時間を合わせて実施する。
- 次回以降はデモもあるので、ヒアリングだけできるわけではない。
- 3回目のスプリントでデザインファイルをもらえる
- とはいえ、認識の齟齬が起きないように最低限は画面イメージのすり合わせしたほうがいい

## 今後やること
- 開発環境構築
- GitHub
- リポジトリ誰が作成するか？
- 決まり事ツール
- ユビキタス言語集
- ユースケース図
- ！！！Rustしかかたん！！！　
- 次のアクション
- リーダーの選定(いるなら)
- 開発リーダのこと
- 技術的な決定権を持つ
- 技術選定
- 使いたい人の意見を採用
- 設計
- 要件が決まらないとどうしようもない
- 9/7（水） 第2回MTG
- より詳細なヒアリング
- デモ（画面イメージのすり合わせ）

## 気になっていること
- イベント
- デイリー
- デイリーではなく、Slack上で必要に応じて共有する
- スプリントレビュー＆ヒアリング
- 隔週水曜20-21時
- レトロスペクティブ
- 非同期でも良い体験を得られたので、非同期が良い
- スプリントプランニング
- 毎週 21-22時
- 次回のスプリントまでにどこまでやるか？
- チケットの管理のツールとかどうしますか？
- 技術選定（スキーマ駆動開発？）
- times的なのってみなさんあります？(普段のコミュニケーションとかどうしようかなぁって)
- MTGのファシリテーションは持ち回り？
- 各回ごとか
- スプリントごとか

- スプリントレビュー
- 持ち回りが良さそう

- 稼働目安
- knj 週8時間
- kaizuka 週8時間
- maruyama 週8時間
- kondo 週15時間
- kubota 週15時間
- furukawa 週8時間

次回: 8/26（金） 21:00 -
## 話したいこと

- ワーキングアグリーメント的なのいる？
- 稼働する時はGatherにいる？
- SlackのChanel作ってもいいかも？（勤怠とかわからないこと呟くためとか）
- ファシリくらいは当番制でもいいかも？
- みなさんChromeで開発します？
- ヒアリングで対応ブラウザ確認し忘れました
- kondo, furukawa, umeda, tomita
- ドキュメント管理ツール
- 決まり事、議事録、ユビキタス言語集、...
- 議事録（共同編集目的）
- HackMD
- それ以外（決まり事、議事録リンク集、ユビキタス言語集、などなど）
- docディレクトリに確定したドキュメントを格納
- チケット管理ツール
- GitHub Projects
- 技術選定
- フロントエンド
- React/TypeScript
- Next.jsを使うかどうかは意見が割れる？
- CSS周りはデザインファイル貰ってから、という作戦も...
- ライブラリの選定
- テストフレームワーク
- バックエンド
- node.js/TypeScript
- NestJS(Fastify)
- ORマッパーはPrisma
- Jest
- API
- REST
- DB
- PostgreSQL
- マルチテナントを実現するRow Level Securityの点でpostgresに分がある？
- CI
- GitHub Actions or CircleCI（？）
- どこまでDockerfile作るか
- DBだけ
- 認証どうするか
- Firebase
- GitHubのリポジトリ
- モノ/マルチリポ
- [GitHub Actionsの支払いについて](https://docs.github.com/ja/billing/managing-billing-for-github-actions/about-billing-for-github-actions)
- Issue/PRのテンプレート
- Issue/PRのラベル
- 設定
- ブランチ保護ルール
- デフォルトブランチへのpushを禁止する等
- Update Branch
- デフォルトブランチを取り込むボタン
- auto-mergeの要否
- n人approveしたら自動でマージするやつ
- [GitHub上のマージ方法について](https://docs.github.com/ja/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/about-merge-methods-on-github)
- マージしたら自動でheadブランチ削除するやつ
- 通知
- Slackで受けるのが楽？

- 今日決めること
- リポジトリ誰が作る、モノ/マルチか
- ルーレット
- 
- モノ
- 水曜日までにやること・アサイン
- 水曜日までにやること
1. フロントの技術選定とサンプルプロジェクト miraさん maruyamaさん
2. バックエンドの技術選定とサンプルプロジェクト kubotaさん furukawaさん
3. ユーザストーリ（テキストベース）・ユースケース図・ドメインモデル図・ER図 kondoさん, kenjiさん, kaizukaさん di
4. チームの人3期のdiscordに入れてほしい
5. CI/CD
6. 次回のヒアリング内容を用意する
7. ＝＝＝これより上は次回のヒアリングまでに完成させたい＝＝＝
8. ユビキタス言語集
9. Githubの設定（Issue/PRのテンプレートとか

ドメインモデル図上の言葉をユビキタス言語とすれば、言語集は別途作らなくて良いかも？
> ユビキタス言語はどのように残すのが良いでしょうか?
色々な方法が考えられますが、ドメインモデル図を電子化し、そこをマスターとするの
は効果的な方法です。
ユビキタス言語はドメインモデリング、特にドメインモデル図作成の過程で発見され、 定義されます。また、より適した概念を発見して言葉を更新する時も、ドメインモデル図 を起点に行うと認識を揃えやすいです。
そのため、別途テキストの用語集を管理するよりも、ドメインモデル図自体がユビキタ
ス言語を定義するものとした方が、自然にメンテナンスをしていきやすいです。
（ドメイン駆動設計_モデリング_実装ガイド_V1.0.3より引用）

###### tags: `poとsprint`