## Links
- [簡易設計図](https://docs.google.com/presentation/d/1mv626pJ8xtEqlUeuznppHDCm7YYFlwLp5m7-wP7jkRY/edit#slide=id.gd)
- [各PJに聞いた必要なデータ類](https://drive.google.com/drive/folders/1m9Dy4AGQk1-K40_ORlgFOpiYu5OvHUcU)
- [ER図](https://drive.google.com/file/d/1Q2v7OVIW6Xv0RLjchkNMp0MQBy2CobHL/view?usp=sharing)
- [返却データ](https://docs.google.com/spreadsheets/d/1sAEuUCenrxYdrsquj6oyQRWlGUp9lyUm4C85Qg_mrpg/edit#gid=311008166)
- [GoodNotes](https://goodnotes.com/shares/#aHR0cHM6Ly93d3cuaWNsb3VkLmNvbS9zaGFyZS8wWl93M0FZTFN0QTlJQ3NpMVBHNVJzcGZ3)

# ITチームデータベースpjmtg#8

## 開催情報

| 日付 | 06/09 |
| -------- | ---------------------------------- |
| 主催 | 楠本 |
| 開始時刻 | 22:00 |
| 終了時刻 | |
| 場所 | Zoom （[録画リンク]()） |
| 参加人数 | 名 |
| 参加者 | 楠本(物理)|

## アジェンダ
1. システム要件定義確認、ER図確認、正規化MTG日程確定

## システム要件定義
- [原案](https://n-contents.backlog.com/alias/wiki/534593)として考えています

## システム方式設計

- 次はシステム方式設計だが、使用ソフトウェアなどはシステム要件定義の時点で決まっているので、スルーしても良い...?
- 担当を決定し、ソフトウェア要件定義に移る

> ## システム方式設計(★★☆)

> > システムを構成するソフトウェアの切り分けを行う

> * 上記で定義したシステムの要件に対して、内部的にどのようなソフトウェアの構成に切り分けられるかを決定する
> * ソフトウェア同士は疎結合になってなければならない
> * 共通して用いる要素などはフレームワークの中でもutilityとして実装することが多いが、そのようなモジュールはどれほど必要か
> * ソフトウェア同士のフローの図や関係図を作成
> * この段階で要員の割り振りを行うことも可能

> ## ソフトウェア要件定義(★★☆)

> > システムを構成するソフトウェアごとに、機能や能力など必要な要件を明らかにする

> * 上で切り分けた各ソフトウェアに対して、さらにそのソフトウェアが

* 何をするか (機能)
* インターフェース (どのようなデータや値を入力として要するか)
* 他のソフトウェアやモジュールとの階層関係・依存関係
* ソフトウェア同士に順序関係ができてしまう場合。特に、フレームワークなど
* どのようにするか

をまとめる

> * 次の段階が最も重要なので、そのための下準備がこの段階

---

# ITチームデータベースpjAWSmtg#2

## 開催情報

| 日付 | 06/12 |
| -------- | ---------------------------------- |
| 主催 | 楠本 |
| 開始時刻 | 09:00 |
| 終了時刻 | 12:15 |
| 場所 | Zoom （[録画リンク]()） |
| 参加人数 | 8名 |
| 参加者 | 楠本(物理)、中務(地理)、寺倉(物理)(~10:15)、栗山(数学)(~10:30)、石川(化学)、西村(物理)、赤司(化学)、畑中(物理)|

## アジェンダ
1. システム要件定義作成

## 各種リンク
- [簡易設計図](https://docs.google.com/presentation/d/1mv626pJ8xtEqlUeuznppHDCm7YYFlwLp5m7-wP7jkRY/edit#slide=id.gd)

|service|担当者|
|---|------|
|AWS REST API|赤司|
|S3|楠本|
|Glue|西村|
|AWS lake formation|石川|
|RDS|寺倉、栗山|
|ECS|中務|

## 通例MTGの議事録(DBpj)

方向性に関する質問をしておきました

>* 第6回MTG、AWSに関するMTGを行いました。
* DWH : Redshift -> RDSにする
* S3（Data Lake) : put用のrest apiを使用する
* ここは他プロジェクトと強く関わるので早めにサーベイ
* get用のAWS rest apiがあるか確認する
* ない場合に限って、Django x S3の連携を考える
>* AWSサービスのサーベイがさらに必要なので、調べた上で要件定義を確定させたいと思います。
* ある場合には、
* apiがシンプルなら直接他チームに使ってもらう
* 複雑なら、aws管轄のrest apiの内部でaws rest apiのgetを叩く形でwrap

## S3に関して

調査した結果のアーキテクチャ
- S3で生データとETLでデータを変換したものを保存してもいいと思われる
- RDSに保存してDjango REST APIで叩くのと用途がかぶるのでは
- 前者のほうがAWS Lake Formation側すると目的に沿っている
- S3 rest apiで直接ユーザーがS3にアクセスしては？
- AWSのREST APIで他のPJが取得できればDjango REST API経由じゃなくても直接叩いてもいい
- それが難しい場合はDBpjがDjango　REST APIを構築して提供しやすいように設計する流れとなる
- S3 rest apiを用いたときのメリット
- 汎用性が高くなる
- データへのアクセスするには一元的な方が良い
- 直接getするとデータ量が多い＆時間がかかる
- pushするには問題ない(pythonスクリプトで書く)

## RDSに関して
- 値段
- データ転送とストレージでお金がかかる
- ECSに乗っけたAPIのアクセス頻度で料金がかかる

- 使用するメリット
- データの疎結合につながる

## ECSに関して
- 値段
- 従量課金制度(vCPU・メモリ・ストレージリソースに基づく)
- (ECSが何ができることよりもDjangoで何ができるのかを把握)
- ECSの起動時間・アクセス頻度
- 使うときにはECSは起動しているのでは
- Fargateとの比較
- 細かいことをしない場合はFargateのほうがいい
- public APIの固定化ができないなどのデメリットがある

## ETLに関して
- イメージ
- pythonのjobを定期的に実行する
- アクセス
- lake formationとの対応
-

## lake formationに関して
- 入力
- Glueを実行時にデータカタログを生成

## AWS REST APIに関して
- S3からETLに関してはBluePrintになる

## 質問

- S3からS3 REST APIを直接たたくのは保守性としてどうか
- 直接叩いてもらうのではなくDjango REST APIなとでwarpしてもらう
- その場合RDSの用途とかぶる

- 他のPJが取得したいデータに関して
- 現在のデータがほしい
- S3の場合は時系列的なデータを担保するためにディレクトリ構造などの設計の変更が必要
- 他のPJとS3が密な関連性ではなく疎な状態にしておきたい

- Django Graph QLに関して
- RDS→ECS→Userの過程でDjango REST APIとDjango Graph QLと並列すべきか
- ECSを挟むメリット
- RDS
- 取り出し方に混乱が生じない
- デメリット
- 開発コストが高い
- ECS挟まずDjango REST APIを叩くでもいい
- メリット
- ECSの使用料はなくなるので安くなる
- 開発コストが低くなる
- デメリット
- 取り出し方が場合によってはRDSからとECSからどっちからもAPIを叩く必要性がある

- Post側の処理に関して
- User→S3の間にアーキテクチャを入れる
- Blueprintを挟んで収集を行う
- ECSを乗っける(MongoDBでNoSQLを設計)
- S3には生のデータと構造化されたデータどっちも持っておくのは非効率的な感じがする
- S3にいれる段階である程度構造化→ETLで正規化→RDSにログデータとしてDBに保存しておく
- そのために

- 過去データの保存場所に関して
- 現状、RDSに過去データ保存
- S3に生の過去データを保存しておくことも考えられるがその場合、RDSと情報がかぶる場合があるのではないか

## 結論
- Get側
- RDSからREST APIを叩く
- ECSにDjango Graph QLを載せてopsttsはそこから叩く
- ※料金がかからないのであればECSにどちらも乗っけてもいい
- (追加で調査をお願いしてもらう)
- Post側
- ECSにDjango REST APIを乗っけてタグ付け
- S3にはS3 REST APIで叩く
- ETLで正規化しRDSに保存
- 各PJはデータクレイジングの段階まで依頼
- pandasとは違うので、各PJにETL処理を定義してもらう
- 実装自体はpysparkのライブラリを使用するのでDBpj側管理

## システム要件定義

## ＊＊＊＊要件定義書
> 構築するシステムの仕様を明文化し、成果物のイメージを統一する
> 業務視点とIT視点の両方で、システムの要件を整理する

## 1. システム構成図
### 1-1. システムのコンポーネント同士の関係性
システムを構成するのはモジュール・パッケージ
それらパッケージの内容とカバーする範囲を明記
ボトムアップで構築されるシステムの全体観を提示

→　清書して画像を貼っておく

### 1-2. 他システムとの関係性
他のシステムのどの機能を使用予定か、大まかに

→　全PJからデータをもらい、出力する

### 1-3. 業務フロー図
各モジュール・パッケージの組み合わせとして表現可能な業務フロー図

## 2. ネットワーク構成図
* プラットフォーム(AWS、ITPC)

→　清書して画像を貼っておく

## 3. 機能要件
> システムを実装することで、できること
> データやシステムの種類・構造や、システムが処理可能な内容

### 3-1. ＊＊＊＊（機能）
細かな機能
データ項目、処理方法
- データを非構造化データを含めて保存
- データを正規化することでデータをうまく取得できる。
- RDBを用いてデータを取得できる

#### 3-1-1. インターフェース
> ユーザや外部システムとのデータのやり取りの方式の概要を記述
> データ形式、入出力する機能、送受信の頻度/タイミング、なぜそのデータが必要か、送受信手段(APIなど)、データ量

- データ形式
- 非構造化データ、構造化データ
- 入出力する機能、送受信手段(APIなど)
- Django rest api, Django graphQL, S3 rest api, (RDS rest api)
- 送受信の頻度/タイミング
- S3への保存：任意のタイミング
- ETLの変換：ジョブスケジューラによる。最速でデータを入れてからすぐ
- RDSからの取り出し：任意のタイミング
- なぜそのデータが必要か
- データ量
- 現時点では未定

#### 3-1-2. 入力形式
- 非構造化データ、構造化データに関わらずdjango rest apiで送信可能

→ ドメインモデリング、ER図を写真で添付

#### 3-1-3. 例外発生時
> 入力の誤り、管理POSなどのシステムエラー、Googleの回数上限などが発生した場合の処理

- データ入力時点：S3入力の際にvalidationを確認
- データ出力時点：データ出力時にvalidationを確認

#### 3-1-4. 出力形式

## 4. 非機能要件
> 性能・信頼性・操作性など、機能以外に求めること

### 4-1. システムの利用者、ユーザビリティ
* 科目リーダー／振り分け担当／フレームワークpjのシステムからのアクセスのみ
* １日に何回利用される想定か

- ITチームのプロジェクト全体
- 可能金額、各PJの使用回数による

### 4-2. システムの規模、拡張性
* 扱うデータの規模、

- 現時点では未定

### 4-3. システムの性能、信頼性
* 想定の処理時間、

- 現時点では未定

### 4-4. システムのセキュリティ
* アクセス制限

- Django apiでのセキュリティを、ユーザー認証などを登載することで担保する。
- 現時点では未定

## 5. 備考
### 用語集
> 誰にでも専門用語がわかるように説明を書いておく

| 名称 | 説明 | 参考リンク |
| ------------- | ------------- | ------------- |
| ICE | 統合添削環境<br>添削者の工数登録、添削答案のDL/UP、<br>必要資料の閲覧、リーダーとの連絡が行える | https://www.toshin-correction.com/ |

---

# ITチームデータベースpjmtg#7

## 開催情報

| 日付 | 06/09 |
| -------- | ---------------------------------- |
| 主催 | 楠本 |
| 開始時刻 | 22:00 |
| 終了時刻 | |
| 場所 | Zoom （[録画リンク]()） |
| 参加人数 | 名 |
| 参加者 | 楠本(物理)、栗山(数学)、石川(化学)、田中(国語)、池側(数学)、<br>赤司(化学)、中務(地理)、垣内(返却)、畑中(物理)、西村(物理)、<br>久保田(物理)、中井|

## アジェンダ
1. AWSミーティングの結果
2. AWSの追加資料作成に関して、講習会発表について
3. Django資料作成
4. 今後の流れ

## AWSミーティングの結果
- [簡易設計図](https://docs.google.com/presentation/d/1mv626pJ8xtEqlUeuznppHDCm7YYFlwLp5m7-wP7jkRY/edit#slide=id.gdc8e61acb4_0_0)をもとに説明
- 以前はデータレイク→ETL→DWH→RDB

### DWH or RDS
- DWHのメリット：スプレッドシート上で分析できる。
- RDS：json形式で返すのでDHWを使わなくてもいいのではないか

### Glueの件
- Glue周りの動作に関してはAWSを実際に触って見てみる。

### S3
- S3は通常作成すると３ヶ月かかる
- AWS Lake Formationなるものがある
- 数日で作成できる
- データレイク側のセキュリティを一連管理できる

### AWS Lake Formation
- [作成資料](https://n-contents.backlog.com/alias/wiki/530810)
- Glueの拡張機能
- S3だとポリシーの設定が一番時間がかかる
- アクセス制御管理が一箇所で管理できる
- Glue/S3で使用する分料金がかかる

## AWSの追加資料作成に関して、講習会発表について
> 本チームから「REST APIに関して」の講習会の発表メンバーを1人以上捻出していただきたいので、
週末目処に募集していただいてもよろしいでしょうか？
講習会の準備は1つの議題に対して3人くらいで行っていただくつもりです
よろしくお願いします。
- 稼働不可能：池川さん(~6/17)
- 石川さん

## AWS serviceの各コンポーネントの確認・担当者
|service|担当者|
|---|------|
|AWS REST API|赤司|
|S3|楠本|
|Glue|西村|
|AWS lake formation|石川|
|RDS|寺倉、栗山|
|ECS|中務|
|Redshift|田中|

## Django Girl作成進捗
田中、赤司、石川の三人で完成

## 今後の流れ
- ER図作成の方(@畑中)
- すみません、先週あたりから研究室の用事で動けませんでした。次回のAWS mtgまでには大枠を作成したいと思います。
- 機能要件への書き込みお願いします！

- 土日→AWSMTGを開催。最終目標：システム構成図、ネットワーク構成図、非機能要件を決定する
- [日程調整](http://tonton.amaneku.com/list.php?id=20210609135306_rEuUxV)
- **12日9時〜**(もしくは13日19時〜21時)の予定
- AWS　serviceの担当者中心に参加
- 栗山さんが寺倉さんと協力してRDSに関して調査

## 質問
- 各pjがデータを送ることに関して
- Django REST APIを用いるのではなくAWS REST APIなるものがある
- [PutObject](https://docs.aws.amazon.com/AmazonS3/latest/API/API_PutObject.html)でデータを送れそう
- apiがシンプルなら直接他チームに使ってもらう
- 複雑なら、aws管轄のrest apiの内部でaws rest apiのgetを叩く形でwrap

## 結論
- データレイク(S3, AWS Lake Formation)→ETL(Glue, AWS Lake Formation)→DB(RDS)→Django REST API/Django Graph QL(ECS)
- AWS用のwikiを作成
- ECSはdocker上で動作させる

---

# ITチームデータベースpjAWSmtg#1

## 開催情報

| 日付 | 6/05 |
| -------- | ---------------------------------- |
| 主催 | 楠本 |
| 開始時刻 | 18:00 |
| 終了時刻 | |
| 場所 | Zoom （[録画リンク]()） |
| 参加人数 | 名 |
| 参加者 | 池側、中井、西村、寺倉、石川、田中、中務、垣内|

## アジェンダ
1. [要件定義に関してAWSの関わる範囲を決定する](https://n-contents.backlog.com/wiki/CT_48/%E2%98%85%E6%88%90%E6%9E%9C%E7%89%A9%E3%83%95%E3%82%A9%E3%83%BC%E3%83%9E%E3%83%83%E3%83%88%2F%E8%A6%81%E4%BB%B6%E5%AE%9A%E7%BE%A9%E6%9B%B8)

https://it-ntw8349.slack.com/archives/C01R1LQMQJE/p1622882071060200?thread_ts=1622783079.045900&cid=C01R1LQMQJE
Djangoに関して後程追記するので、まずはAWS関連の話を全てまとめて記入して要件定義として作成していただけると助かります！

## AWSの各機能の発表
- S3
- 飛ばす
- データレイクへのデータの送信方法
- https://docs.aws.amazon.com/AmazonS3/latest/API/API_PutObject.html
- Lake Fromation
- S3を数日で作成できる(通常の方法なら数か月かかる？？)
- データレイクからの取り出しのセキュリティを一元管理できる
- これらのメリットを考えて、既存のネットワーク構成の中に組み込むかどうかを考える。
- Glue
- S3、Redshiftとの接続は、アカウントなどがわかればできる
- https://docs.aws.amazon.com/ja_jp/elasticbeanstalk/latest/dg/create-deploy-python-rds.html

- Redshift
- djangoのライブラリで接続できそう
- RDS

### Redshift?RDS?
- Djangoとの接続はどちらも行ける
- 判断基準
- 取り出しやすいのはcsvでとりだしやすいのか？Redshift上で分析しやすいからか？
- 他のpjでどのようにデータを使いたいか？
- DWHかRDSかは他のpjからはあまり関係ない
- 各pjはcsvではなくDjango REST APIへjsonデータを要求するという理解
- データの処理速度が早いならDWHの方が良い？
- 過去データにアクセスが必要か？
- 過去のデータはS3に置いておける
- データの追加・更新の頻度
- 工数分析では更新頻度は高いため、更新のしやすそうなRDSの方がよい
- 使いやすさはRDBであるRDSの方が良い？
- RDSでいきましょう！

### Django　Rest　API
- 現時点でもjsonスキーマを決めとくほうが良い

### 今後のToDo
- システム構成図
- AWS REST APIのサーベイ
https://docs.aws.amazon.com/AmazonS3/latest/API/API_PutObject.html
- ネットワーク構成図の作成
- Lake_Formationをどうするか
- 非機能要件
- ユーザビリティ
- セキュリティ
- AWS　RESTAPIの方はベーシック認証機能を使う
- Djangoからの取り出しについてはセキュリティ機能を追加する
- データの規模(概算)

---

# ITチームデータベースpjmtg#6

## 開催情報

| 日付 | 6/02 |
| -------- | ---------------------------------- |
| 主催 | 楠本 |
| 開始時刻 | 22:00 |
| 終了時刻 | |
| 場所 | Zoom （[録画リンク]()） |
| 参加人数 | 名 |
| 参加者 | 楠本(物理)、石川(化学)、畑中(物理)、<br>田中(国語)、栗山(数学)、中務(地理)、<br>垣内(返却)、寺倉(物理)、西村(物理)、<br>池側(数学)、久保田(物理)|

## アジェンダ
1. 勉強時間の日報申請に関して周知・依頼
2. AWSの資料作成報告
3. Djangoの勉強の進捗報告
4. 現在のDBPJの状況
5. 連絡事項

## 勉強時間の日報申請に関して周知・依頼(畑中)
- 先日の全体MTGで勉強時間の日報申請に関して質問・確認しました。
- djangoチュートリアルをネット上のものを参考しているが、外部のものを参考にしていると申請は出来ない
- 資料作成、資料を読む時間をマネジメントすれば時間の申請は可能
- 手を動かしながら実装した時間も含めてしまう
- django girlsのコピー版みたいなものをbacklogに作成して今までの分も申請してしまう？
- 田中さんにお願いします
- 資料作成の人員割り振り
- 資料作成にかかった時間は不要: どれだけでも申請可能
- 資料を読み終わる時間（コーディング含む）: 一律の時間
- 他PJ（工数分析）でもdjangoを取り組むので人員が足りなかったら色々とお願いします。

## AWSの資料作成報告（田中さん）
- DWHは月一程度のデータ書き込み
- 取り出し頻度を含めて別MTGで決定する

## Djangoの進捗報告

|name|djangoの経験|
|---|------|
|楠本|rest apiを別途作成中|
|西村|CSSで可愛くしようみたいなところまでやりました(ほぼ終わった気がします)|
|池側|今週は進捗なしです..|
|石川|Django girl一通り終わりました。|
|栗山|一応一通り読みました。HTMLの部分は流し読みしてしまいましたが…|
|田中|進捗なしです（一応Django girl一通り終わりました）|
|畑中|Djangoビューまでです…(Udemyの方です)|
|垣内|rest apiをやり始めました|
|中務|デプロイの直前までやりました。|
|久保田|初めの方の章を少し読みました。|
|寺倉|進捗なしです。学期末なので何もできませんでした|

## 今後の役割分担
- 全く進んでいない人→一人が資料の読む時間を図ってみる
- AWSの業務にかかわっていただく
- ETL
- DHW
- データレイク
- RDBの周り
- テーブルの正規化
- ER図
- Django
- 全員が関わる必要はないと思われる
- 勉強を進んでいる人でREST APIの担当者を決める
- 資料作成
- 田中さんをPMに
- DBpj内人員募集
- 工数分析pjとの連携してもよい(Djangoの勉強をするため)

## DBの進捗報告
- 正規化をする担当者が忙しく完成には至っていない
- ER図の作成程度でとどめておく(全体像の把握)
- DWHを利用する場合は正規化をする必要がないため
- むしろDWH・RDBの取捨選択を決めるほうが大切な気がします。

## AWSに関する追加MTG
- ETL
- DHW
- データレイク

に関して要件定義を決められるように調査。主に、各コンポーネントとのつながり方やAWS側の取り出し頻度や料金について判断材料を決めていく。

赤司さんが全体MTGでこのような質問をしていました。
- aws GLUEを使わずにEC2でETLの加工をしたほうが良い気がするのですがどうですか。
- チーム内にGLUEに関する知見がないので、その点も含めてGLUEに関するサーベイをできますか
- (GLUEっていうサービスがある以上、GLUEを使うメリットもあると思うので、両サービスのpros/consを比較したい)

ですので、AWS周りの調査に関して赤司さんと連携をとってもよさそうです。DBpjと連携をとってくださいと全体MTGでお願いしました。(畑中)
- 西村さんにEC2を追加で調べてもらう？
- 久保田さんにEC2をお願いする
- http://tonton.amaneku.com/list.php?id=20210602141608_MAdGvZ
- 5日18時からやります
- [簡易設計図](https://docs.google.com/presentation/d/1mv626pJ8xtEqlUeuznppHDCm7YYFlwLp5m7-wP7jkRY/edit#slide=id.gdc8e61acb4_0_0)

## 現在のDBPJの状況
- テーブル正規化が終わり次第システム要件定義が可能になると言って1か月くらい経っているのですが、完了しきっていないのでヤバイ気がしています。今週日曜中の完成をします。(というか扱うデータの詳細な正規化はソフトウェア要件定義でやればいい気がするので、一旦扱うデータの全種類だけ大まかに書き出してしまえばいい気はします...)
- [参考イメージ](https://n-contents.backlog.com/wiki/CT_48/%E2%98%85%E6%88%90%E6%9E%9C%E7%89%A9%E3%83%95%E3%82%A9%E3%83%BC%E3%83%9E%E3%83%83%E3%83%88%2F%E8%A6%81%E4%BB%B6%E5%AE%9A%E7%BE%A9%E6%9B%B8)
- システム要件定義(★☆☆): 新しく構築するシステムの仕様をはっきりさせ、明文化する
- システム方式設計(★★☆):システムを構成するソフトウェアの切り分けを行う
- システム要件定義で残っているタスクは
- [×] システム構成図、ネットワーク構成図
- AWSとDjangoの関係を明確にする必要がある→5日のAWSmtgで完成させる
- [△] 機能要件
- テーブルのER図、ドメインモデリングを完成→畑中さん

## 連絡事項

全体MTGで以下の動画を視聴するように周知が来ました。

>* AIの勉強会の録画に関して
* 森本さんのpythonコーディングに関すること ← must
* PM主導で、全員がみて(給与申請ok)コーディングを始めるような状態に
* 自分の機械学習に関すること、時系列予測に関すること
* 石本さんの因果分析に関すること
* [リンク](https://drive.google.com/drive/folders/144HNd-2-IxGDetySms_5QfZzV6tCvez8)

---

# ITチームデータベースpjmtg#5

## 開催情報

| 日付 | 5/26 |
| -------- | ---------------------------------- |
| 主催 | 楠本 |
| 開始時刻 | 22:00 |
| 終了時刻 | |
| 場所 | Zoom （[録画リンク]()） |
| 参加人数 | 名 |
| 参加者 | 楠本(物理)、石川(化学)、畑中(物理)、<br>田中(国語)、栗山(数学)、中務(地理)、<br>垣内(返却)、赤司(化学)、寺倉(物理)、<br>西村(物理)、池側(数学)、久保田(物理)、櫻井|

## アジェンダ
1. aws資料作成共有
3. django進捗共有
4. システム方式設計共有
5. 今後の方針

## AWS資料作成共有
[データウェアハウス（DWH）とは | 定義・データベース（DB）・データマートとの違い](https://boxil.jp/mag/a1657/#:~:text=%E3%83%87%E3%83%BC%E3%82%BF%E3%82%A6%E3%82%A7%E3%82%A2%E3%83%8F%E3%82%A6%E3%82%B9%E3%81%A8RDB%E3%81%AE%E9%81%95%E3%81%84,-%E3%83%87%E3%83%BC%E3%82%BF%E3%82%A6%E3%82%A7%E3%82%A2%E3%83%8F%E3%82%A6%E3%82%B9&text=%E3%83%87%E3%83%BC%E3%82%BF%E3%82%A6%E3%82%A7%E3%82%A2%E3%83%8F%E3%82%A6%E3%82%B9%E3%81%AF%E5%88%97,%E3%81%AB%E5%B7%AE%E3%81%8C%E7%94%9F%E3%81%98%E3%81%BE%E3%81%99%E3%80%82)

|担当者|内容|
|---|------|
|@田中さん |DWH|

## django進捗共有
|name|djangoの経験|
|---|------|
|楠本 |rest apiも別で作成中|
|西村|0です。。|
|池側|DjangoGirl テンプレートの作成まで終わりました！|
|石川|Django Girl デプロイまで終わりました|
|田中|DjangoGirlを一通りやるだけやりました|
|畑中|今週の進捗はnullです。すみません。土日空いているのでそちらで進めます。|
|寺倉|進捗なしです。|
|垣内|昔やったのを簡単に振り返りましたがあまり進んでいません。金曜日に研究が一段落するので進めていきます。|
|久保田|進捗ないです。すみません。。|
|櫻井|中井さんに進めていただいた本を少し読んだのですが、難しくて読み進めるのが大変そうなので、Django Girlの方を読もうと思います。すみません。
|栗山|Django Girlのプロジェクトを作成するまで進みました。|
|赤司|自分で簡単なwebアプリを作るときに使いました。|
|中務|初めて聞いたのでこれから学習します。|

Django girlが終わった方はrest apiの方お願いします。

## システム方式設計共有
[設計図](https://docs.google.com/presentation/d/1mv626pJ8xtEqlUeuznppHDCm7YYFlwLp5m7-wP7jkRY/edit?usp=sharing)

## 今後の方針
設計図の作成

---

# ITチームデータベースpjmtg#4

## 開催情報

| 日付 | |
| -------- | ---------------------------------- |
| 主催 | 楠本 |
| 開始時刻 | 22:00 |
| 終了時刻 | |
| 場所 | Zoom （[録画リンク]()） |
| 参加人数 | 名 |
| 参加者 | 楠本(物理)、石川(化学)、田中(国語)、西村(物理)、栗山(数学)、<br>池側(数学)、寺倉(物理)、畑中(物理)、垣内(返却)、久保田(物理)|

## 議事録

### アジェンダ
1. 現在の状態
2. 池側さんからの説明
3. 資料作成分担
4. システム方式設計に向けて

## リンク集
- [ER図](https://drive.google.com/file/d/1Q2v7OVIW6Xv0RLjchkNMp0MQBy2CobHL/view?usp=sharing)
- [各PJに聞いた必要なデータ類](https://drive.google.com/drive/folders/1m9Dy4AGQk1-K40_ORlgFOpiYu5OvHUcU)

## DBに入れるか入れないか

| 項目 | 名前 |
|:---------------------------------- | ---- |
| 返却情報 | 石川 |
| 日報検証用フォーム情報 | 池側 |
| 日報原本 | 楠本 |
| 添削者評価データ | 畑中 |
| 添削者遅延情報 | 栗山 |
| 工数対応表 | 田中 |
| 採点基準更新データ | 田中 |
| 工数分析の結果 | 櫻井 |
| 可能工数表 | 垣内 |
| 模試日程 | 楠本 |
| 生徒別講座取得状況 | 楠本 |
| 単じゃの演習セットと試験種の対応表 | 楠本 |

- 返却情報(石川)
- 入れるべき
- 日報検証での齟齬の確認に用いるとのことなのでDBで持っていればほしい情報のみをすぐに取り出せる。
- 後からデータの変更、更新などがない。

- 入れないべき
- 全科目分の返却データとなると膨大になりそう。
- 普遍性はなさそう。
- 管理POSなどで返却情報をかくにんできるのであれば、齟齬の確認の件数によっては必要ないのでは。
- （結論）
- 日報検証など日報系の情報を入れるのであれば入れるべき
- 日報検証をスプシに入れるのであれば返却情報もスプシに入れるべき
- 日報検証用フォーム情報（池側）
- 入れるべき
- ログデータなのでスプシでは管理しきれない
- 入れないべき
- 他pjで使われそうになく、日報pj内のみでの利用になりそう。
- データが毎日追加される割に、使用機会が日報検証の際だけだから。
- ==（結論）==
- ==ログデータは入れる方式だった気がするので入れる==
- 添削者遅延情報(栗山)
- クロージング、返却pjとの連携が必要？
- 入れるべき
- 他のpjでも利用されることが予想され、汎用性の高さからDBでの管理下に置いた方が良さそうです。
- カラムを追加する形で添削者リストが包含してもよさそう。column:遅延状況 のように…(添削者リストをDB化する前提での話ですが)
- 入れないべき
- 現状多くの場合添削者遅延情報はスプシ化されている。1日単位で更新されていくため、DBでの管理は困難であると考えられる。
- 遅延による減点は振り分けにも大きく関係しており、振り分けの観点から「添削者リストはDB化すべきではない」という主張と併せると、添削者遅延情報のDB化は不要？
- ==（結論）==
- ==「添削者-大学登録情報テーブル」のようなものはスプシ化して、残りの情報はDB由来で良いのでは？==
- 工数対応表(田中)
- 入れるべき
- 昨年は月に数回新しい工数対応表(csv)が出来ていたので、DBにした方が参照しやすそう
- 入れないべき
- 工数分析PJでしか使わなさそうなので優先度は低い
- ==（結論）==
- ==入れる==
- 採点基準更新データ(田中)
- 入れるべき
- [中井さんのご意見](https://it-ntw8349.slack.com/archives/C01SEKF4Z37/p1620026173140400?thread_ts=1619964903.136200&cid=C01SEKF4Z37)
- 過去問PJからのメールを転送・抽出して用いているだけで、現状スプシ化されていない
- 入れないべき
- リーダーが更新するケースもあるので、そちらは別にスプシとかに記入してもらう必要がある
- 現状あまり使われていないデータなので優先度は低い　
- ==（結論）==
- ==返却との関連性があるかもしれないので入れる==
- ==科目横断的に実用性がある==
- 工数分析の結果(櫻井)
- データベース化すべき
- opstgt同様スプシに収まりきらない大きなデータになる可能性大
- row 日付
- column 科目, 大学, 年度, 提出工数, 予測工数1, 予測工数2, … といった感じ
- かなり疎なテーブル
- データベース化の難点
- データの出力形式が渡舟で変わる可能性
- 新たな予測対象グルーピングの追加
- 予測モデルの追加(columnが増える)
- ==（結論）==
- ==（優先度低）入れる==
- 添削者評価データ(畑中)
- 入れるべき側の意見
- ETLによって毎月の更新頻度ならデータベースにいれてもよいと考えられる。
- 添削者IDと各項目の点数などの各科目共通なカラムにしておく。
- また、添削者評価用のテーブルを作成する際には別途添削者リストのテーブルを作成しておいたほうが、汎用性が高くほかのPJにも活用できる。
- **中井さんから今後自動評価に関するAIの開発も視野にいれたい**：[詳細](https://it-ntw8349.slack.com/archives/C01QVERJWJJ/p1620667159043500)
- 入れないべき側の意見(DB化する上での課題)
- 添削者評価の項目は各項目によってばらつきがあるので、あまり情報量としては格納するのが難しい？
- 添削者FBに対するコメントなど入れても今後分析などで活用することができないものに関して入れる入れないの追加判断が必要そうであるため。
- 添削者評価の項目が変わったときのカラムの追加・修正が大変かと思われる。
- ==（結論）==
- ==入れる==
- 可能工数表(垣内)
- 入れるべき
- 工数分析の結果をデータベースに入れる際には分析もとの可能工数表を入れておいたほうがいいと考えられる
- データの変更はない
- データの形は単純
- 入れないべき
- ICEのプロジェクトがあるためそれによってはDBを用いる必要がない？場合もあるのではないか
- ==（結論）==
- ==過去データのみ入れる==
- 模試日程
- リアルタイムの情報は一次データが管理されているところにアクセスして、それ以外を保存するべき。
- ==（結論）==
- ==過去データのみ入れる==
- 生徒別講座取得状況
- OPSTTS2として取得できるので入れる。
- 単じゃの演習セットと試験種の対応表
- 深野さん対応まち。
- ==（結論）==
- ==過去データのみ入れる==

## 池側さんから概要説明
お願いします！

## 資料作成分担
|担当者|内容|
|---|------|
|@楠本 |データレイク (dynamoDB+S3)|
|@西村拓人 |ETL (GLUE)どういう処理ができるのかin->out|
|@寺倉慶 |DWH (RDS)|

## djangoの経験
|name|djangoの経験|
|---|------|
|楠本 |作成経験あり。rest apiも別で作成中|
|西村|ないです！！！！！！！名前はたくさん聞きました|
|池側|なしです|
|石川|ないです！！！！！！！！！|
|田中|なし|
|畑中|最近Udemyで入門しました|
|寺倉|もちろんないです|
|垣内|Django girlチュートリアルのみやったことがあります|
|久保田|ないです。Udemyは取りましたが、見てないです。
|櫻井|ありません。時間があれば勉強したいですが、時間があまり取れなさそうです。
|栗山|ないです！Udemyの講座は取得しました。手はつけていません。.|

そろそろ各自djangoの勉強もお願いします。

- tutorial
- [django girl](https://tutorial.djangogirls.org/ja/)
- [django rest framework](https://www.django-rest-framework.org/tutorial/quickstart/)
- かかった時間のメモ
- tutorialにかかる時間は申請していいのか

## システム方式設計にむけて
> システムを構成するソフトウェアの切り分けを行う

> 上記で定義したシステムの要件に対して、内部的にどのようなソフトウェアの構成に切り分けられるかを決定する
ソフトウェア同士は疎結合になってなければならない
共通して用いる要素などはフレームワークの中でもutilityとして実装することが多いが、そのようなモジュールはどれほど必要か
ソフトウェア同士のフローの図や関係図を作成
この段階で要員の割り振りを行うことも可能

となっています。原案ができていないので、来週までに考えてくる人を募集or考えてきます。
- 楠本、畑中さん、櫻井さんで考えてくる

---

# ITチームデータベースpjRDBmtg#3

## 開催情報

| 日付 | |
| -------- | ---------------------------------- |
| 主催 | 楠本 |
| 開始時刻 | 20:00 |
| 終了時刻 | 22:00 |
| 場所 | Zoom （[録画リンク]()） |
| 参加人数 | 5名 |
| 参加者 | 楠本(物理)、畑中(物理)、寺倉(物理)、栗山(数学)、西村(物理)|

## 議事録

## 各リンク
- [各PJに聞いた必要なデータ類](https://drive.google.com/drive/folders/1m9Dy4AGQk1-K40_ORlgFOpiYu5OvHUcU)
- [ER図](https://lucid.app/lucidchart/5e7d4503-b483-472f-9385-337231416b66/edit?shared=true&page=0_0)
- [返却データ](https://docs.google.com/spreadsheets/d/1sAEuUCenrxYdrsquj6oyQRWlGUp9lyUm4C85Qg_mrpg/edit#gid=311008166)
- [GoodNotes](https://goodnotes.com/shares/#aHR0cHM6Ly93d3cuaWNsb3VkLmNvbS9zaGFyZS8wWl93M0FZTFN0QTlJQ3NpMVBHNVJzcGZ3)

### アジェンダ
1. 正規化に関して

### 1.正規化に関しての課題点
- 返却データ
- 同じ答案の差し戻し内容に関してテーブルの追加・紐付け方
- 日報原本
- 役職に関してのテーブルとナガセリストとの関係
- 科目とIT(AI)に所属している人がいる
- クロージング
- 当日返却の完了率はPOSにアクセスして計算するのか、振り分けPJと返却PJの結果を元にDBの情報から計算するのか？

## 今後の方針

# ITチームデータベースpjRDBmtg#2

## 開催情報

| 日付 | |
| -------- | ---------------------------------- |
| 主催 | 楠本 |
| 開始時刻 | 16:00 |
| 終了時刻 | 16:30 |
| 場所 | Zoom （[録画リンク]()） |
| 参加人数 | 2名 |
| 参加者 | 楠本(物理)、畑中(物理)|

## 議事録

### アジェンダ
1. スプレッドシートとの住み分け
2. DBの運営目的の確認

### 1.スプレッドシートとの住み分け
先日のスプレッドシート担当と話し合った結果の内容
- ITリーダーが使うデータはDB
- 科目内の非ITが使うデータに関してはスプレッドシート
- 一日一回未満のDBからの取り出す場合のみDBで保存
- それ以外はスプレッドシートで
- 例：examinerリストはスプレッドシート
- 担## 各リンク
- [各PJに聞いた必要なデータ類](https://drive.google.com/drive/folders/1m9Dy4AGQk1-K40_ORlgFOpiYu5OvHUcU)
- [ER図](https://lucid.app/lucidchart/invitations/accept/inv_671ca517-169e-4443-9158-9354887e0e61)
- [返却データ]当大学は時系列的に変化する→結局ログデータとしてDBにバックアップ的な意味合いでDBは必要？
- 大前提のDBの役割が不透明化になってきている気がしている
- ログデータはバックアップもかけてすべてDBに保存すべきかどうか

### 2.DBの運営目的の確認

1. アクセス範囲
- ITと非ITの切り分け
2. DBからの取り出し頻度
- 一日に何回取り出すことができるのかの制限の確認
- 管理POSなどの別のツールから取得できるものとの切り分け
3. ログデータの格納
- バックアップとしてのログデータをすべてDBに保存するのか
- ログデータに関する優先度があるのか
- ここでのバックアップは分析時に過去データを取得するために必要なものとする
- 管理POSからのこれ以上遡って取得できないデータはDB化？
- DBの保存できるキャパシティが気になる
- 膨大にデータが増え続けるだけなのでは？
- AWSのRDBの制限が把握していないので、AWS周りの資料作成もお願いしたい

## 今後の方針

- DBの運営目的に関してDBPJメンバーからの意見を集い、次回のMTGで話し合う
- スプレッドシートとの住み分けなどを通例MTGで改めて確認する

# ITチームデータベースpjRDBmtg

## 開催情報

| 日付 | |
| -------- | ---------------------------------- |
| 主催 | 楠本 |
| 開始時刻 | 18:00 |
| 終了時刻 | 22:00 |
| 場所 | Zoom （[録画リンク]()） |
| 参加人数 | 4名 |
| 参加者 | 楠本(物理)、池側(数学)、<br>赤司(化学、~ 21:00)、畑中(物理、18:15~)|

## 議事録

### アジェンダ
1. テーブル定義

## 各リンク
- [各PJに聞いた必要なデータ類](https://drive.google.com/drive/folders/1m9Dy4AGQk1-K40_ORlgFOpiYu5OvHUcU)
- [ER図](https://lucid.app/lucidchart/invitations/accept/inv_671ca517-169e-4443-9158-9354887e0e61)
- [返却データ](https://docs.google.com/spreadsheets/d/1sAEuUCenrxYdrsquj6oyQRWlGUp9lyUm4C85Qg_mrpg/edit#gid=311008166)
## 方針

## opstts, 工数分析より
### 1. DBからデータをもらうAPI（opstts）
- GraphQLの開発の負担
- REAT APIだとテーブルの数的にカバーできない
- 忙しかったらopstts側が負担する
- Django or Goでの実装になりそう
- Go開発の中にREST API/GraphQL担当を設ける？
- REST API(Django) -> GraphQL(Go)の移行?
- APIを早めに構築することが大事
### 2. ETLの中身
- インターフェースはどうするのか
- データレイクから実データを受け取る(入力)
- データウェアハウスへどのように渡すのか(出力)
- 既存のtoolを作るのか
- 例：AWSのGlue
- opsttsで資料作成・検討→DB側で逆輸入として他PJにも提供

### 3.スプレッドシートとの住み分け
- ITリーダーが使うデータはDB
- 科目内の非ITが使うデータに関してはスプレッドシート
- 一日一回未満のDBからの取り出す場合のみDBで保存
- それ以外はスプレッドシートで

## 今後の方針
- 日曜：畑中さん楠本で正規化
- 月曜14時：畑中さん池側さん楠本で最終チェック

---

# ITチームデータベースpjmtg#3

## 開催情報

| 日付 | 5/2 |
| -------- | ---------------------------------- |
| 主催 | 楠本 |
| 開始時刻 | 24:00 |
| 終了時刻 | |
| 場所 | Zoom （[録画リンク](https://drive.google.com/drive/folders/1EhkhEPTQIaj7mrI_9e_TkCA6-gQh2dkR?usp=sharing)） |
| 参加人数 | 名 |
| 参加者 | 楠本(物理),畑中(物理),池側(数学),<br>久保田(物理),栗山(数学),田中(国語),<br>垣内(返却),寺倉(物理),石川(化学)|

## 議事録

### アジェンダ
1. システム要件定義について

## システム要件定義について

- 扱うデータの種類やそれをどのように入力するか
- 構造
- 処理内容
- ユーザーインターフェース
- 出力の形式

を決定する

## 扱うデータの種類と入力方法

- 各PJから情報を収集しました。
- [データベースPJで使用するデータについて](https://drive.google.com/drive/folders/1m9Dy4AGQk1-K40_ORlgFOpiYu5OvHUcU)
- DBに入れるものと入れないものを区別したいです。
- 判断基準→
- スプレッドシートで扱うものはDBに入れる必要が無い
- 日報などの毎日ログデータを更新するものはDBに入れていいのでは？
- 固定化されたデータ
- 更新頻度が高いもの
- 普遍性がある(多くのPJに跨るものに関して？)
1. 添削者リスト
- 入れないべき
- 振り分けで大変になりそう
- スプレッドシート側でいれたほうがいい
- 更新される頻度が高いので必要性がないかもしれない
- 入れるべき
- 汎用性が高いもの(id等)はあってもいい
- あとからカラムを追加して臨機応変にすれば自転車操業にならないのでは
- カラムの追加は大変らしい
- 何かしらのログデータを紐付けるとなると添削者リストはあってもいい
- 添削者評価は月一の頻度なのでいれてもいいのではないか
- 振り分けは担当者の大学を変更し、多くの添削を偏りなく振り分け
- はじめは色々錯誤しながらの設定なのでDB化するのは難しい
- API化を行えばUPDATEはできそう
- 質問など
- 担当試験種PJにも聞いてみるべき
- **DBとスプレッドシートの両立はありか？**
- DB：固定化されたもの
- スプレッドシート：頻度が高いもの
- このデータたちの取得方法も問題なので、担当を振って次の二項目を決めてもらえたらと思います。
- 取得方法
- DBに入れるべきか入れないべきか
- スプレッドシートとの両立に関して
- 明日以降の全体MTGで確認する
- 吟味するデータ
- **7日中締め切り**
- 寺倉さん厳しい

| 項目 | 名前　|
| -------- | --------|
| 返却情報 | 石川 |
| 日報検証用フォーム情報 | 池側 |
| 日報原本 | 楠本 |
| 添削者評価データ | 畑中 |
| 添削者遅延情報 | 栗山 |
| 工数対応表 | 田中 |
| 工数分析の結果 | 櫻井 |
| 可能工数表 | 垣内 |
| 模試日程 | 楠本 |
| 生徒別講座取得状況 | 楠本 |
| 単じゃの演習セットと試験種の対応表 | 楠本 |

- 入力方法は次項で

## 構造

HTTPリクエスト(+入力データ)
↓
django
↓
SQL⇔DB(AWS)
↓
django
↓
出力データ(json)

- 勉強時間の申請は？
- 勉強した内容をメモ書きとしてBackLogに残しておく

## 処理内容
- テーブルを作成する（これは最初のDB格納時にDBpjがやります）
- テーブルを更新・編集する
- 例：添削者の担当大学が変更したとき
- テーブルを取り出す
- optttsなどの固定化されたデータ
- 外部からデータベースへ入出力をするAPIはSQLですか?それともPythonでAPIを設置しますか
- RestAPIを叩いて取得(python)
- GraphQLでも可能

## ユーザーインターフェース
- Django rest apiにアクセス
→ AWSにアクセス（アクセス回数制限の問題について要検討）

## 出力の形式
- json
- csvでもいい
- インターフェースによって変わるかもしれない

## 今後の流れ
- システム要件定義の終了予定の5/2を過ぎてしまっているので、気持ち早めに進めていきたいですね
- 5/3の週例MTGでスプシPJとの線引きを明確にする
- 次回MTGの日程調整は

---

# ITチームデータベースpjmtg#2

## 開催情報

| 日付 | 4/25 |
| -------- | ---------------------------------- |
| 主催 | 楠本 |
| 開始時刻 | 22:00 |
| 終了時刻 | |
| 場所 | Zoom （[録画リンク](https://drive.google.com/drive/folders/1VYCw1SZkrt7MNtsDS5fmlMcEzkAS9zzB?usp=sharing)） |
| 参加人数 | 10名 |
| 参加者 | 楠本(物理), 森田(英語), 寺倉(物理), 池側(数学), 垣内(返却), 畑中(物理), 田中(国語), 栗山(数学), 石川（化学）, 櫻井(物理), 西村(物理)|

## 議事録

### アジェンダ
1. 全体開発スケジュール決定
2. 各科目に要望などを聞き込む役割の分担決定

### 全体開発スケジュール決定

|日程|目標|
|----|----|
|~5/2|システム要件定義|
|~5/9|システム方式設計|
|~5/23|ソフトウェア要件定義|
|~6/6|ソフトウェア方式設計|
|~6/20|ソフトウェア詳細設計|
|~7/11|プログラミング|
|~7/17|結合テスト|

### システム要件定義に向けて
1. 科目聴取担当
- 現在科目が独自で運用しているプログラムなどで、ログのデータサイズが大きいものが無いかを調査する
- 例えば数学チームの返却chrome拡張機能で、答案情報や返却ログなどをスプシに残していた場合
→ データ構造（どのような列で構成されているか）を聞いてこちらに持ち帰ってくる。
- 独自で運用しているプログラムが無いかを把握した上で、あれば担当者に聞く
- a:細分化したモジュールプロジェクト
- api/kanripos/ice/opstts_tgt/spreadsheet/gdrive/slack/allocation
- c:クロージング
- d:データベース
- e:添削者評価
- f:振り分け
- h:返却
- k:工数分析
- n:pj外it業務から実際にpj化したもの
- 現在日報報告pjがある
- 全体WSに聞きこむ vs 各科目で担当を設置
- 各科目で聞く
- 英：寺倉さん
- 数：栗山さん
- 国：田中さん
- 物：畑中さん
- 化：石川さん
- 社：垣内さん
- マクロ：池側さん

2. 各PJ聴取担当
- 各プロジェクトでどのようなデータが欲しいかを聞きこむ。
例）振り分けPJ→振り分けログ、opstts
- データ構造も聞きこむ
- 櫻井さん

- 今手持ちのデータをこちらで用意しておいて、それ以外に必要なものが無いかを聞く。
- マクロログデータ
- 振り分けログ
- opstts（opsttsPJとの相談込）
- (今後ほしい)差し戻しデータ(slackのログ、slackPJと相談)
- (今後ほしい)添削者評価の評価項目、点数やグレード(添削者評価PJと相談)
- 担当同士で取得したデータをmtgで相談してデータベースに乗せる必要がありそうかを決定する
- 各担当をとりあえず一人ずつ決める
- 期限は4/30とし、それをベースにmtgを開催し、すり合わせとシステム要件定義を決定。
- 各WSへの招待、日程調整は今日中

### Q&A
- 科目聴取に関して
- ITチームで巻き取り切れていないデータや、漏れデータが無いか確認

### 今後の流れ
- 科目聴取担当、各PJ聴取担当が4/30までに大まかに聞き込みをする。
- 5/1,2あたりでmtgを開いてシステム要件定義を決めます。
---
# ITチームデータベースpjmtg#1

## 開催情報

| 日付 | 4/14 |
| -------- | ---------------------------------- |
| 主催 | 楠本 |
| 開始時刻 | 22:00 |
| 終了時刻 | |
| 場所 | Zoom （ [録画リンク]()） |
| 参加人数 | 1名 |
| 参加者 | 楠本(物理), 森田(英語), 寺倉(物理), 池側(数学), 垣内(返却), 畑中(物理), 田中(国語), 栗山(数学), 石川（化学）, 櫻井(物理) |

## 議事録

### アジェンダ
1. メンバー自己紹介
2. 資料について
3. アイデアブレスト
4. プロジェクト憲章について
5. Q&A
6. 今後の流れ

### メンバー自己紹介
楠本(物理), プロジェクトマネージャー, 授業や個人的にDB
森田(英語), 工数PJ
寺倉(物理), 返却PJ
池側(数学), 添削者評価PJ、添削者マクロでDB
垣内(返却), 返却PJ
畑中(物理), 添削者評価PJ
田中(国語), 工数分析PJ、国語科でマクロ
栗山(数学), 添削者評価PJ
石川（化学）, クロージングPJ, 化学科
櫻井(物理), 工数分析PJ、科目内でも工数分析

### 資料について
- [こちらの資料を参照（ITPM向け共通資料）](https://n-contents.backlog.com/wiki/CT_48/マニュアル%2FITPM向け共通資料)
- gitを使ったことがあるかどうか。
- 触ったことがある人が大半
- 軽く触ったことがある人もいる
- 今後使い方をレクチャー？
- [参考（ITメンバー向け共通資料）](https://n-contents.backlog.com/wiki/CT_48/マニュアル%2FITメンバー向け共通資料)
- システム要件や定義から行う

### アイデアブレスト

ドキュメントは[こちら](https://docs.google.com/document/d/1-siXI9TnwEwv5-O2n3hQDdiInKN2qTIjVSZ7HutzRIM/edit)

- AS_IDに対する添削者の情報を保持する
- 差し戻し内容をAS_ISに紐づける（管理POSの拡張機能などから）
- 添削者の遅延、差し戻し回数の記録
- 答案の状態を随時反映（未提出・提出済(点数入力有)・差し戻し中・完了）
- 添削情報（マクロから得られるデータから添削にかかった時間を記録したり、添削時間帯、ミスの数など）の保存

### プロジェクト憲章について

1. **プロジェクトの目的**
そもそもなんでこのプロジェクトやってるんだっけ？
- 各科目間で統一されていなかった膨大な情報をITチームで管理・運用
- 添削者評価などはスプシで管理

2. **プロジェクトの目標 (測定可能な成功条件)****
何がゴール？
例）djangoでデータベース運用する
- ITチームでログデータなどを提供
- 後々は様々なデータも管理して幅広い活用をイメージ

3. **前提・制約条件**
プロジェクトを進めるにあたって、前提とすること
例) 他のチームのデータ定義を最初にする必要がある
RDB、NoSQLなど、どれを用いるか
データベースの運用方法
- AWSでの活用が前提
- pythonのdjango(+α)
- プラットホームの一種
- RESTAPI(get,post,deleteメソッドを用いてjson形式で返す)
- 各PJでも開発をしていく可能性がある
- 同様のプラットホームとしてflaskもある。(マクロで活用)
- **PostgreSQL/MySQL(今後の軸)**
- 他のPJがdjangoを開発するならこのPJではSQL言語のみ使うかもしれない

4. **スケジュール**
- システム要件定義やシステム方式設計で決まるので可能な限りmtgで参加してもらいたい
- ヒアリングしてどのデータが必要かどうかを要件定義で決める
- 会議にでることはマストではない
- 発言は必須ではない
- 一人あたりの時間や負担
- 各々スケジュール調整してプロダクトの調整
- DBの大まかな流れ
1. どのようなデータをDB化するのかを決める
2. データベースの設計(ER図)
3. データ格納
4. テスト運用
5. 本番環境にデプロイ

5. **予算 (概算)**
概算として、「詳しくは後で見積もる、でも上限額はxx円」
- AWS
- ラムダ(定期実行)
- RDS
- ssh用仮想PC一台

6. **リスク**
リスクを仮定し、軽減するための対策をあらかじめ立てておく（必ずしも解決策を立てる必要は無い）
例）・他プロジェクト間の遅延
- 他プロジェクト間の遅延
- 同時操作による保守性（sshアクセスの場合）
- トランザクション処理(OSでいうlock,unlockの意味)
- SQLインジェクション
- 他プロジェクトからの追加要求によるDB設計の変更

7. **プロジェクトメンバーおよびプロジェクト・マネージャー**
必要な人の名前を記載

### Q&A
- どのようなデータを保存できるかどうかを把握してからアイデアを決められるといいかなと思います。
- これまで科目内で使っていたものを東進全体で運用していく際にどのようなデータが必要なのかを考えていく。
- そもそもDBは巨大なスプシみたいなもの？
- それぞれのデータ(例：添削者、答案)を設計して、それらを紐付けることで利用可能
- DBを使うことで、ログを保存することができる(opt,tts,拡張機能)
- IT関連の人が使えそうな情報をDBを用いて提供する
- ITに長けていない人にはそれ専用のインターフェースを提供する
- データの引き渡しの方法は要検討
- スプシとDBとの連携
- どこまでの情報をDBで扱うのか
- なんでもかんでもDBには保存することは現時点ではDBPJの負担が大きい
- 言語は
- PostgreSQL/MySQL
- 東進内でSQLを乱立させたくないようにしたい
- 一般的な使用率でいうとPostgreSQL
- pythonのdjango/flask
- AI教務研究員ではdjangoとMySQLでRESTAPIを用いてjson形式で返す
- このPJ内ではdjangoで使えるDBを提供
- AWS上でDBを活用する予定(DBに直接アクセスしない?)
- 毎朝のops.ttsの情報を保存
- ICEのデータ
- 役割分担
- DBとdjangoのうち得意分野の方を担当
- 散らばっている情報を集めて設計・保存することが主な業務
- その後のカラムの追加によるDB再設計はあまりないと思われる
- 必要な情報
- まずは膨大なデータを中心的に扱いたい
- ops,tts(AWSのラムダで定期実行し収集)
- ops:過去問演習講座の答案の情報（生徒情報や添削者情報などをcsv形式で保存）
- tts:単ジャの答案の情報
- ICE(RDS)
- 振り分けログデータ(RDS)
- 添削者評価(定期的な収集)
- ローカルPCのように任意な時間でアクセスできない
- ssh専用の仮想PC(AWS上)を一台設ける(PJ内の担当者が扱える)
- 借りられないなら他の手段でアクセスするようにする
- RDSに接続できる手段はない
- 勉強時間の申請について
- 東進に直接関わるものに関しては申請可能
- サーベイなどもOK
- 一般的な勉強は含めない?

### 今後の流れ
- **(週)次ミーティングの日程調整**
- 目的：各担当の週次報告・タスク共有
- スプシとDB何が違うのかを把握
- 次回は日程、４月中旬〜定時で
- 現時点では未定、後ほど日程調整
- **backlog**
- 各pjごとにwikiが作れるようになっているので、自由に作成
- 各pjの子ページに成果物をまとめていただく形で
- [ WikiのHome](https://n-contents.backlog.com/wiki/CT_48/Home)の運用ポリシー（案）参照