# 工数分析PJ 第回mtg
|日付|/ |
| -------- | ---------------------------------- |
| 主催 | 阿部 |
| 参加人数 | 名 |
| 参加者 | 阿部|
| 場所 | Zoom |
| 開始時刻 |:|
| 終了時刻 |:|
# 工数分析PJ スキーマ定義
|日付|/ |
| -------- | ---------------------------------- |
| 担当者 |北河 松田|
ITコードが変更されるという話があった気もするので、その変更に伴ってクエリの細かい部分を修正する必要が出てくるかも知れませんね（北河）
* /time_series
* /existing
* /kensu
* get
* tags: existing
* query_param
* date_from
* date_to
* 表示期間を指定
* 必須
* type_id
* it用コード
* 16進数1桁
* univ_id
* it用コード
* 16進数4桁
* subject_id
* 16進数4桁
* year ← it用コードを作成 year_id(16進数)
* str(2桁)
* 2018年度→18
* 2005年度→05
* daimon_id ← it用daimon_idを作成する
* int
* response
* content-type:application/json
200の場合
```json=
{
data:
[{
date:2021/01/30,
kensu:100,
},
{
date:2021/01/31,
kensu:80,
}]
}
```
* /kousu
* get
* tags: existing
* query_param
* date_from
* date_to
* 表示期間を指定
* 必須
* type_id
* it用コード
* 16進数1桁
* univ_id
* it用コード
* 16進数4桁
* subject_id
* 16進数4桁
* year ← it用コードを作成 year_id(16進数)
* str(2桁)
* 2018年度→18
* 2005年度→05
* daimon_id ← it用daimon_idを作成する
* int
* response
* content-type:application/json
200の場合
```json=
{
data:
[{
date:2021/01/30,
man_hour:20
},
{
date:2021/01/31,
man_hour:17
}]
}
```
細かいですが、man_hourではなくkousuの方が良さそうですね。（北河）
* /capacity
* get
* tags: existing
* query_param
* date_from
* date_to
* 取得期間
* subject
* 日本語を使う？既存のsubject_idを使う？
* it_codeは使わない
* 科目が一意に定まるから
* man_hour_limit
* 工数制限を反映するか
* 0,1
* max_capacity
* 最大可能工数
* オプションに関してはmtgで再度聞き込み
* 添削者評価？
* このオプションについては/input_csvのエンドポイントで行うはずなのでここでは不要ですかね（北河）
* response
* content-type:application/json
200の場合
```json=
{
data:
[{
date:2021/01/30,
capacity:100,
},
{
date:2021/01/31,
capacity:105,
}]
}
```
* /prediction
* /kensu
* get
* tags: prediction
* query_param
* date_from
* date_to
* 表示期間を指定
* 必須
* train_date_from
* train_date_to
* 訓練用データの期間指定
* 必須
* prediction_algorithm
* 予測アルゴリズムの選択
* type_id
* it用コード
* 16進数1桁
* univ_id
* it用コード
* 16進数4桁
* subject_id
* 16進数4桁
* year
* str(2桁)
* 2018年度→18
* 2005年度→05
* daimon_id
* int
* response
* content-type:application/json
200の場合
```json=
{
data:
[{
date:2021/01/30,
predicted_kensu:100,
},
{
date:2021/01/31,
predicted_kensu:80,
}]
}
```
* /kousu
* get
* tags: prediction
* query_param
* date_from
* date_to
* 表示期間を指定
* 必須
* train_date_from
* train_date_to
* 訓練用データの期間指定
* 必須
* prediction_algorithm
* 予測アルゴリズムの選択
* type_id
* it用コード
* 16進数1桁
* univ_id
* it用コード
* 16進数4桁
* subject_id
* 16進数4桁
* year
* str(2桁)
* 2018年度→18
* 2005年度→05
* daimon_id
* int
* response
* content-type:application/json
200の場合
```json=
{
data:
[{
date:2021/01/30,
predicted_man_hour:20
},
{
date:2021/01/31,
predicted_man_hour:17
}]
}
```
こちらもman_hour→kousuにする必要がありそうです。
* /capacity
* get
* tags: prediction
* query_param
* date_from
* date_to
* 取得期間
* train_date_from
* train_date_to
* 訓練用データの期間指定
* 必須
* prediction_algorithm
* 予測アルゴリズムの選択
* subject
* 日本語を使う？既存のsubject_idを使う？
* it_codeは使わない
* 科目が一意に定まるから
* man_hour_limit
* 工数制限を反映するか
* 0,1
* max_capacity
* 最大可能工数
* オプションに関してはmtgで再度聞き込み
* 添削者評価？
* このオプションについては/input_csvのエンドポイントで行うはずなのでここでは不要ですかね（北河）
* response
* content-type:application/json
200の場合
```json=
{
data:
[{
date:2021/01/30,
predicted_capacity:100,
},
{
date:2021/01/31,
predicted_capacity:105,
}]
}
```
* /examiners
* /kensu
* get
* tags: examiners
* query_param
* date_from
* date_to
* 表示期間を指定
* 必須
* examiner_id
* 例： N0012345
* 複数の添削者IDを受け取ると思うので、[N012345, N012346]などとリストで受け取る方が良い気がします。（北河）
* response
* content-type:application/json
200の場合
```json=
{
data:
[
{
examiner_id: N0012345,
data:
[{
date:2021/01/30,
kensu:50,
},{
date:2021/01/31,
kensu:100,
}]
},
{
examiner_id: N0012346,
data:
[{
date:2021/01/30,
kensu:100,
},{
date:2021/01/31,
kensu:50,
}]
}
]
}
```
* /kousu
* get
* tags: examiners
* query_param
* date_from
* date_to
* 表示期間を指定
* 必須
* examiner_id
* 例： N0012345
* 複数の添削者IDを受け取ると思うので、[N012345, N012346]などとリストで受け取る方が良い気がします。（北河）
* response
* content-type:application/json
200の場合
```json=
{
data:
[
{
examiner_id: N0012345,
data:
[{
date:2021/01/30,
kousu:5,
},{
date:2021/01/31,
kousu:10,
}]
},
{
examiner_id: N0012346,
data:
[{
date:2021/01/30,
kousu:10,
},{
date:2021/01/31,
kousu:5,
}]
}
]
}
```
* /capacity
* get
* tags: examiners
* query_param
* date_from
* date_to
* 表示期間を指定
* 必須
* examiner_id
* 例： N0012345
* 複数の添削者IDを受け取ると思うので、[N012345, N012346]などとリストで受け取る方が良い気がします。（北河）
* response
* content-type:application/json
200の場合
```json=
{
data:
[
{
examiner_id: N0012345,
data:
[{
date:2021/01/30,
capacity:10,
},{
date:2021/01/31,
capacity:5,
}]
},
{
examiner_id: N0012346,
data:
[{
date:2021/01/30,
capacity:10,
},{
date:2021/01/31,
capacity:5,
}]
}
]
}
```
* /input_csv
* /kensu
* /kousu
* /capacity
* 上実装は最後、添削者リストがそもそも不確定なので一旦保留
* /certain_period
* /answersheets
* /exams
* get
* tags: answersheets
* query_param
* date_from
* date_to
* 表示期間を指定
* 必須
* 試験種? ← 種別、大学、科目、年度、大問によって一意にきまるもの？（北河）
* type_id
* it用コード
* 16進数1桁
* univ_id
* it用コード
* 16進数4桁
* subject_id
* 16進数4桁
* year ← it用コードを作成 year_id(16進数)
* str(2桁)
* 2018年度→18
* 2005年度→05
* daimon_id ← it用daimon_idを作成する
* int
* response
* content-type:application/json
200の場合
```json=
{
data:
[
{
univ:東京大学,
nendo:16,
kensu:200,
kousu:20
},
{
univ:東京大学,
nendo:17,
kensu:300,
kousu:30
}
]
}
```
試験種が上の定義ならこうなる？（北河）
```json=
{
data:
[
{
type:過去問演習講座,
univ:東京大学,
kamoku:英語,
nendo:16,
daimon:1,
kensu:200,
kousu:20
},
{
type:過去問演習講座,
univ:東京大学,
kamoku:英語,
nendo:17,
daimon:1,
kensu:300,
kousu:30
}
]
}
```
* /examiners
* /details
* get
* tags: examiners
* query_param
* date_from
* date_to
* 表示期間を指定
* 必須
* examiner_id
* 例：N0012345
* こちらは単数で良いんでしたっけ？（北河）
* response
* content-type:application/json
200の場合
```json=
{
data:
[
{//試験種を1つの辞書型オブジェクトで与えました（北河）
exam:
{
type:過去問演習講座,
univ:東京大学,
kamoku:英語,
nendo:16,
daimon:1,
kensu:200,
kousu:20
},
kensu:10,
kousu:1,
},
{
exam:試験種,
kensu:20,
kousu:2,
},
]
}
```
* /capacity
/analisis_tableについて書き足しました（北河）
* /analysis_table
* /answersheets
* /exams
* get
* query_param
* date_from
* date_to
* 期間指定
* type_id
* it用コード
* 16進数1桁
* univ_id
* it用コード
* 16進数4桁
* subject_id
* 16進数4桁
* year
* str(2桁)
* 2018年度→18
* 2005年度→05
* daimon_id
* int
* response
* content-type:application/json
* テーブルに保存されているデータを取得して返す
* post
* query_param
* response
* content-type:application/json
* テーブルに保存したデータを取得して返す
* /examiners
* get
* query_param
* date_from
* date_to
* 期間指定
* examiner_id
* 単数？複数？
* response
* content-type:application/json
* テーブルに保存されているデータを取得して返す
* post
* query_param
* response
* content-type:application/json
* テーブルに保存したデータを取得して返す
* /capacity
* get
* query_param
* date_from
* date_to
* 期間指定
* subject
* 日本語を使う？既存のsubject_idを使う？
* it_codeは使わない
* 科目が一意に定まるから
* post
* query_param
* response
* content-type:application/json
* テーブルに保存したデータを取得して返す
# 工数分析PJ 第16回mtg
|日付|11/22|
| -------- | ---------------------------------- |
| 主催 | 阿部 |
| 参加人数 | 7名 |
| 参加者 | 阿部、瀬尾、吉田、坂上、北河、松田、藤田|
| 場所 | Zoom |
| 開始時刻 |22:00|
| 終了時刻 |24:20|
## TODO
* 要件確認
* エンドポイントの決定
* 今後のTODO
## 要件確認
* 提出件数、工数の取得
* 添削者単位
* 一番下のレイヤーは添削者IDのリスト+期間指定+を受け取るもの
* GETメソッド
* url上はexaminer_id=N0012345&examiner_id=N0012346&date_from=2021-08-17
* request.GETで
* その上のレイヤーでcsvを受け取るように
* こちらで評価を受け取る
* その評価の添削者IDを抽出して、
* 種別、科目、大学、年度、大問での任意の絞り込みでの情報取得
* GETメソッドで
* 様々な予測アルゴリズムをオプションで選択
* 試験種×添削者の一定期間の合計の件数、工数を取得する
* 試験種×添削者の情報を返す
* 添削者の一定期間の合計の件数、工数を取得する
* 試験種×試験種の一定期間の合計の件数、工数を取得する
* 期間指定をできるように
* 種別×大学、年度×大学など
* ある試験種の一定期間の合計の件数、工数を取得する
* 可能工数の取得
* 添削者単位
* 添削者IDのリスト+期間指定+オプション(limit制限等)を受け取るもの
* GETメソッド
* url上はexaminer_id=N0012345&examiner_id=N0012346&date_from=2021-08-17
* request.GETで
* 試験種単位の取得
* 日付×試験種の時系列
* csvのexaminer_list＆絞り込み条件を入力
* 入力を解析して添削者単位のAPIを叩く
* 科目単位
* GETメソッド
* テーブルからまとめて取得
* 時系列データ
* 保持するテーブル
* 試験種×日付の件数、工数テーブル
* content_recceived_date→提出件数、工数
* actual_returned_date→返却件数、工数
* 添削者×日付の添削件数、工数テーブル
* content_received_dateを見る
* 科目×日付の可能工数テーブル
* content_received_dateを見る
* 科目の識別は添削者マスターテーブルを見る
* 詳細なクエリで見たい場合
* 具体的なユースケースを藤田さんに確認
* 優先度は低くてよい
* その上で設計
* この場合、直接DBを見る
## エンドポイントの決定
* 既存時系データ取得
* 件数or工数or可能工数
* 件数or工数は種別、科目、大学、年度、大問での任意の絞り込み
* 可能工数は科目での絞り込み
* 予測データ取得
* 件数or工数or可能工数
* 種別、科目、大学、年度、大問での任意の絞り込み
* 可能工数は科目での絞り込み
* ある試験種の一定期間の合計の件数、工数を取得
* {data:[{univ:東京大学, nendo:16, kensu:, kousu},{univ:東京大学, nendo:17, kensu,},]}
* 時系列データの和を取って並べれば再現可能
* 添削者単位での一定期間での実績取得
* 一定期間で試験種を基準にグルーピング
* {
data:[{exam:試験種,kensu:, kousu:},]
}
* 添削者単位での可能工数取得
* 時系列
* 添削者単位での件数、工数取得
* 時系列
* csvファイル入力で添削者評価、担当試験種などのフィルターをかけた提出件数、工数、可能工数取得
* 添削者評価や担当試験種でクエリ
* queryで検索するやつ決める．複数指定だと
*
* DB操作
* 試験種×日付の件数、工数テーブル
* 添削者×日付の添削件数、工数テーブル
* 科目×日付の可能工数テーブル
### urlの決定
* /time_series
* /existing
* /kensu
* /kousu
* /capacity
* /prediction
* /kensu
* /kousu
* /capacity
* /examiners
* /kensu
* /kousu
* /capacity
* /input_csv
* /kensu
* /kousu
* /capacity
* 上実装は最後、添削者リストがそもそも不確定なので一旦保留
* /certain_period
* /answersheets
* /exams
* /examiners
* /details
* [{examiner_id:N01,total_kens,total_kousu
* data:{}]
* /capacity
* /analysis_table
* /answersheets
* /exams
* /examiners
* /capacity
/time_series/examiners/kensu
/time_series/examiners/{examiner_id}/kensu
これだと通信回数が多くてダメ
## 今後のTODO
* ERD作成
* DBpjのERDと関係を繋げる
* 試験種×日付の件数、工数テーブル
* ITコードの変更に伴い修正
* 科目ID⇔IT用科目+IT用試験番号
* 中井さんが考え直すので，後回し
* 添削者×日付の添削件数、工数テーブル
* 科目×日付の可能工数テーブル
* 担当者：吉田、阿部
* [DBpjER図](https://drive.google.com/file/d/1Q2v7OVIW6Xv0RLjchkNMp0MQBy2CobHL/view?usp=sharing)
* 確認を阿部がやる
* OpenAPI作成
* 上記を基に
* 担当者：北河、松田、阿部
* 確認を阿部がやる
* 詳細設計
* オブジェクト指向で
* DB操作とDB操作から予測に利用する時系列データを作成する部分が重要
* DBpjで律速するので、場合によってはDBpjのAPI作成を工数分析に必要なテーブルに関して受け持つ
# 工数分析PJ 仕様確認mtg
|日付|11/21 |
| -------- | ---------------------------------- |
| 主催 | 阿部 |
| 参加人数 | 2名 |
| 参加者 | 阿部、藤田|
| 場所 | Zoom |
| 開始時刻 |02:10|
| 終了時刻 |02:40|
## TODO
* 要件定義の再確認
## 要件定義の再確認
* 数学科の要望に関して
* 基本的にあったらいいな程度のものを網羅したので、工数に見合わなければ機能として必要ないものもある
* 予測等の絞り込みは試験種と添削者で出来れば十分
* 生徒、校舎、回数などの絞り込みはそこまで必要とはしていない
* 非時系列データも出力できるとよい
* 大学×年度et
この前の要件定義で問題ない
→ ERDとOASを作成し始める
# 工数分析PJ API仕様定義mtg
|日付|11/17|
| -------- | ---------------------------------- |
| 主催 | 阿部 |
| 参加人数 | 4名 |
| 参加者 | 阿部，瀬尾, 北河、中井|
| 場所 | Zoom |
| 開始時刻 |19:00|
| 終了時刻 |22:20|
## TODO
* 科目チームへのヒアリングの確認
* 要件まとめ
* API使用定義
## 科目チームへのヒアリングの確認
[科目チームへの要望調査回答](https://docs.google.com/spreadsheets/d/1gxOa2fHpohnqIb0sa6_GBDSBlUXWylT9iLG1M6HHGkU/edit?usp=sharing)
### 提出件数、提出工数に関する要望
* 数学
* 生徒、添削者、校舎、回数、返却日、科目、種別、大学、試験種番号、年度、大問などについて、複数選択可（ex.この科目での当該10校舎から提出された東大京大阪大理系の工数を校舎別に/合計値を時系列で…など）で絞り込める機能の実装。（「複数」を「複数条件」ではなく「同一条件内で複数選択可」としてお願いしたいです）
* 複数選択可にはする予定
* 試験種番号
* 50,53,54,73,74は全部物理
* 飛び飛びで無理矢理感
* IT用科目(11科目)+IT用試験番号 ⇔ 科目ID
* 物理 1 ⇔ 50
* 物理 2 ⇔ 53
* そもそも生徒、校舎などのユースケースはあるのか？
* DBのパフォーマンスは落ちる
* DBpjで保持しているopsttsから直接作る低速なAPIを別で作る
* 提出日ベースの時系列データだけではなく、提出日以外を基準とした工数データを表示できる機能の実装。（時系列データだけではなく、累積データなどに興味がある場合も多々あるため
* 横に大学，縦に年度を重ねたりとか
* フロント側で調整できる？
* 時系列でないならばAPIとして別で提供した方がよい
* 全試験種の、この期間からこの期間までの総提出工数データといったものもあるとよい。
* 工数分析においては状況に応じて都度アプローチを変えて分析する必要があり（そうしないと繁忙期を乗り切る助けにはならない）、そのためにできる限り幅を広く持たせておくべきだと考えています。
* どういう意味？
* 分析手法の話？
* グラフの表示形式の話？
* その場合フロントで対応
* 絞り込みの条件を多種、表示形式を色々とカスタマイズ
* 件数/工数についてはどちらか一方のみ表示or両方表示が選べるようにしておいてもらいたく思います。
* やる予定
* APIとしては別々であって、両方叩くか片方叩くか
* 英語
* 添削者単位で添削した工数を取得
* 予定
* 添削者×大学まで必要？
* opsttsと同じ粒度になってしまう
* 添削者×大学で必要であればopsttsをそのまま見るような別APIを立てる
* 一定期間での大学：工数
* 一旦保留
* 生物
* 担当大学ごとの提出工数・可能工数を予測できたら嬉しい
* 作成予定
* 国語
* 添削者単位で一定期間に添削した工数を知りたい
* 上記
* 期間の指定は受付日でも返却日でもできると嬉しいです
* 返却数のカラムを追加で対応
* actual_returned_date
* 世界史
* 搭載予定のもの以外の希望なし
* 物理
* 搭載予定の機能は欲しい
* 現在物理科では，定数倍予測を行なっているが，これ以上詳しい予測は必要ない
* 添削者単位，添削者評価単位，新規/既存の工数，件数は欲しい
* csvで入力を受け取れれば識別できそう
csv入力や複雑な入力に対応できるようpostで作成
### 可能工数に関する要望
* 数学
* 可能工数予測については優先度は相当低くてよいかと思います。特に月跨ぎなどで予測工数を出してしまうと、実際は登録がほとんどされていないのに余裕があるものと誤認してしまい大事故に繋がる恐れがあるので、実装しなくてもよいのではと思っています。それよりは、その時点でのICEでの将来の登録工数をそのまま出力してもらったほうがずっとありがたいです。（そもそも予測が「頑張ったらこれくらいまではかき集められるよね」なのか「現状のペースで行けばこれくらいだよね」なのか「このままなにもしなくてもこれくらいはいくよね」なのか非情に曖昧なので、情報としてもあまり役に立たないのではと思っています）
* あってもいいと思う
* 実装上は合っても支障ない
* 予測はフロントで選択できる
* こちらも件数工数取得と同様、幅を広く持たせておいていただきたいです。特に評価での絞り込みは、インセンティブや評価体系設計などにおいても必要になってきます。（添削者の属性による絞り込みはマストで必要になると思っています）
* csv入力でクライアント側が用意する形で対応
* 工数登録人数や、特定条件に当てはまる人のその日その日の平均登録工数なども出せるようになると良い。
* DBから直接引っ張り計算したAPIを提供
* 入力はcsv or リクエストボディ
* 添削者リストの情報を受けて、特定の大学のこの年度を担当に持っている人たちの可能工数はこれくらいだよといった情報もあるとよい。新規添削者への担当配置決めにおいては必須の情報。
* 入力はcsv or リクエストボディ
* 上同様クライアント側で添削者の絞り込み
* 英語
* 添削者評価による絞り込み
* 担当大学単位での絞り込み
* 上同様
* 生物
* 添削者評価での絞り込み
* 期間設定
* 添削者ごとの表示
* 添削者評価による絞り込み
* 担当大学単位での絞り込み
* 上同様対応
* 世界史
* 担当大学別の絞り込み機能があると大変嬉しいです。
* 物理
* 搭載予定，検討中どちらの機能も欲しい
* 可能工数予測は特に必要ない．むしろ今日以降の実際の可能工数状況をみて，少ないから登録呼びかけしなきゃってのが大事
上記を受けて
* 可能工数予測は必要なさそう
* ほとんど役に立たない。むしろ情報としてノイズになりうる
* そもそも可能工数自体、将来のものを登録している
* 選べるのであれば合っても問題ない
* 作成する
* 科目×日付のテーブルは作成
* 添削者で指定できるようにし、メタ情報による絞り込みはクライアント側で行う。
### その他の要望
* データはcsv出力可能にしてほしい
### 工数分析外の要望
* 生物
* 現在、生物チームではパソコンに強い人がそれほどおらず、将来的に現在の環境を整備できる人がいなくなることが危惧されています。スプシやフォームなど整備する、小回りができるような人材をITチームから派遣していただくことを考えていただきたいです。
* 世界史
* 答案の添削遅延botのようなものを共有していただくことは可能でしょうか。可能であれば共有していただけますと大変嬉しいです。
## 要件まとめ
* 提出件数、工数の取得
* 添削者単位
* 一番下のレイヤーは添削者IDのリスト+期間指定+を受け取るもの
* GETメソッド
* url上はexaminer_id=N0012345&examiner_id=N0012346&date_from=2021-08-17
* request.GETで
* その上のレイヤーでcsvを受け取るように
* こちらで評価を受け取る
* その評価の添削者IDを抽出して、
* 種別、科目、大学、年度、大問での任意の絞り込みでの情報取得
* GETメソッドで
* 様々な予測アルゴリズムをオプションで選択
* 試験種×添削者の一定期間の合計の件数、工数を取得する
* 試験種×添削者の情報を返す
* 添削者の一定期間の合計の件数、工数を取得する
* 試験種×試験種の一定期間の合計の件数、工数を取得する
* 期間指定をできるように
* 種別×大学、年度×大学など
* ある試験種の一定期間の合計の件数、工数を取得する
* 可能工数の取得
* 添削者単位
* 添削者IDのリスト+期間指定+オプション(limit制限等)を受け取るもの
* GETメソッド
* url上はexaminer_id=N0012345&examiner_id=N0012346&date_from=2021-08-17
* request.GETで
* 試験種単位の取得
* 日付×試験種の時系列
* csvのexaminer_list＆絞り込み条件を入力
* 入力を解析して添削者単位のAPIを叩く
* 科目単位
* GETメソッド
* テーブルからまとめて取得
* 時系列データ
* 保持するテーブル
* 試験種×日付の件数、工数テーブル
* content_recceived_date→提出件数、工数
* actual_returned_date→返却件数、工数
* 添削者×日付の添削件数、工数テーブル
* content_received_dateを見る
* 科目×日付の可能工数テーブル
* content_received_dateを見る
* 科目の識別は添削者マスターテーブルを見る
* 詳細なクエリで見たい場合
* 具体的なユースケースを藤田さんに確認
* その上で設計
* この場合、直接DBを見る
## 今後のTODO
* OASを作成
* ER図作成
* 藤田さんに要件を再度確認
# 工数分析PJ 第15回mtg
|日付|11/15 |
| -------- | ---------------------------------- |
| 主催 | 阿部 |
| 参加人数 | 9名 |
| 参加者 | 阿部、瀬尾、赤司、吉田、坂上、北河、松田、藤田|
| 場所 | Zoom |
| 開始時刻 |22:00|
| 終了時刻 |23:50|
## TODO
* 進捗報告
* ERDの確認
* OpenAPIスキーマ定義の確認
* 質問等
* 今後のTODO
## 進捗報告
* ERDの作成
* 担当：阿部、吉田
* DBpj側のITコード関連テーブルと合わせて作成
* OpenAPIのスキーマ定義
* 担当：阿部、松田、北河
* mtgを行い各エンドポイントの洗い出しとそのスキーマを定義
* openapi.yamlの作成はこの後の確認が終わってから
* 11/19の21:00～zoomで一気に終わらせる
* [DjangoプロジェクトとREADMEの作成](https://n-contents.backlog.com/git/CT_48/Man-Hour-Analysis/tree/master)
* 担当：阿部
* 詳細設計でインターフェースが決まり次第、スケルトンコードを作成する予定
## ERDの確認
[ER図](https://drive.google.com/file/d/1B-89GeS_DuUVpkzdes2kT04QmxqteTK9/view?usp=sharing)
* it_codeに対してIT用のKOZA_CODEなどをマッピングしている
* ITコードマスタテーブル
* PK(Primary Key，主キー)
* テーブル内においてこの値が決まるとデータとして一意に定められるもの
* opsttsの場合だとASIDに該当する
* 1対多
* 以下を満たす関係を意味する
* Aのテーブルに関して1つ選ぶとBのテーブルは多数存在する
* 逆にBのテーブルに関して1つ選ぶとAのテーブルは1つに定まる
* FK(Foreign Key，外部キー)
* 他のテーブルから参照しているキーのこと
* 例
* 工数分析テーブルにおけるIT用のコードまわりは外部キー
添削者必要であれば別のAPIを作成
→ 添削者評価等に聞き込み
工数分析アプリでどういった機能が欲しいか科目チームに聞き込み
* 現状作成予定の機能を説明
* どういう機能があったら便利か
* itチームからの連絡依頼
* フォーム作成
DBpj側のitコード関連テーブルに関して再度見直しが必要
## OpenAPIスキーマ定義の確認
スキーマ定義の詳細は下の議事録を参照
url定義は以下の通り
* api/man_hour_analysis
* /sheet_number
* /submitted
* 提出件数、工数の取得
* get
* /predict
* 予測件数、工数の取得
* get
* /capacity
* 可能工数の取得
* get
* /analysis_table
* テーブルにあるデータを取得
* get
* /analysis_table/{date}
* 日付単位でテーブル更新
* put
案2
/su{件数、工数or可能工数}
/predict/{件数or工数or可能工数}
/answersheet/
get 既存レコードの取得
post 新しい日時追加
/answersheet/{date}
get
put
delete
/examiner/
DBから整形したテーブルを作成
ER図を作成
検索クエリ(オプション)によってカラムを考える
→ クエリに対応したカラムを作成してグルーピング
/submitted/可能工数or件数、工数
/predict/可能工数or件数、工数
### 修正点等
* このエンドポイント設計で問題ないか？
* 一番上のやつの命名がいまいちなので良さそうなものに変えたい
* 週毎の提出数を返したほうがいい？
* 日数指定できるようにする（複数日のものを返せるようにする）
* 検索クエリを複数指定できるようにする（univ_idを複数指定とか）
* 国公立1,2,3とかのクエリを指定できるようにする？（フロントからのアクセスは厳しい）
* マスタテーブルをapi化？（管理posのexaminer_settingのイメージ）（添削者名→添削者IDの変換と同様のロジック）
* 可能工数とかは聞き込み必要（担当大学での絞り込みは必要そう）
* テーブル設計も考える
* 分析テーブルはAPI経由で取得（クエリ再利用できる）
* 添削者リストを考慮した大学別の可能工数テーブル
* DB側とすり合わせながら設計
## 今後のTODO
* 科目チームへの機能アンケート
* 必要な機能をフォームで回答していただく
* 担当：阿部
* APIの再設計
* 今回の修正点とアンケートを踏まえ、OpenAPI化できるところまで設計
* 担当：阿部、瀬尾(水，金ならいけそう)、(時間が合えば赤司さん、藤田さん、中井さん)、← 可能な人は出切り限り参加
* ER図の作成
* 既存のITコード関連テーブルの確認
* 可能工数用テーブルの作成
* 担当：阿部、吉田
* OpenAPIの作成
* 担当：阿部、松田、北河
* 11/19に21:00～ mtg
* このmtgで一通り完成させる
* 設計に変更が大きく出たのでリスケ
* 詳細設計
* 作業部屋を開いて進めていきたい
* 予測アルゴリズム以外の部分を設計
* インターフェースが決まり次第スケルトンコードを作成
* 12/13が完成目標(4週間程度)
* 完成次第確認mtgを開く
* 12月中にコーディングが一通りできるように
* 予測アルゴリズム
* Backlogに手法をまとめる
chのブックマークにある常設zoomを作業部屋としてどんどん利用していってください！
# 工数分析PJ OpenAPIスキーマ定義mtg
|日付|11 /14 |
| -------- | ---------------------------------- |
| 主催 | 阿部 |
| 参加人数 | 3名 |
| 参加者 | 阿部、北河、松田|
| 場所 | Zoom |
| 開始時刻 |22:00|
| 終了時刻 |24:20|
## TODO
* 要件の再確認
* スキーマ定義
## 要件の再確認
以下のAPIが必要
* 提出件数、工数の取得、予測
* 同期API
* 種別・大学・科目・年度・大問のどの粒度でも
* 組み合わせは2^5=32通り
* 予測のアルゴリズムはオプションで
* 期間指定
* date_fromとdata_to
* 表示する期間
* 提出工数，可能工数でdata_toが未来だったらエラーにする
* 予測に使う学習データの期間の指定
* json形式で時系列データを返す
* 可能工数の取得
* 同期API
* 期間指定
* date_from, date_to
* 科目
* 外れ値の定義
* 工数制限limitを反映
* flag
* オプション
* 添削者評価，新規/既存等の指定
* 余り指定できるようしたくない
* DBpjで作成するテーブルから情報を取得してやる
* 工数分析用テーブルの更新
* 
* DBpjのテーブルを利用して更新する
* 日付指定でその日の情報を指定
* テーブル更新は/{date}/
* 同期API
## url設計
* api/man_hour_analysis
* /sheet_number
* /submitted
* get
* /predict
* get
* /capacity
* get
* /analysis_table
* get
* /analysis_table/{date}
* put
## スキーマ定義
* /sheet_number
* /submitted
* get
* tags: sheet_number
* query_param
* date_from
* date_to
* 表示期間を指定
* 必須
* type_id
* it用コード
* 16進数1桁
* univ_id
* it用コード
* 16進数4桁
* subject_id
* 16進数4桁
* year ← it用コードを作成 year_id(16進数)
* str(2桁)
* 2018年度→18
* 2005年度→05
* daimon_id ← it用daimon_idを作成する
* int
~~ * kensu?
* 0,1
* dafalut:1
* man_hour?
* 0,1
* default:1
* 上二つ必要？~~
* response
* content-type:application/json
200の場合
```json=
{
data:
[{
date:2021/01/30,
kensu:100,
man_hour:20
},
{
date:2021/01/31,
kensu:80,
man_hour:17
}]
}
```
期間内で提出0の日はパディングする
→ どちらか片方ずず指定(pathパラメータ)
* /predict
* get
* tags: sheet_number
* query_param
* date_from
* date_to
* 表示期間を指定
* 必須
* train_date_from
* train_date_to
* 訓練用データの期間指定
* 必須
* prediction_algorithm
* 予測アルゴリズムの選択
* type_id
* it用コード
* 16進数1桁
* univ_id
* it用コード
* 16進数4桁
* subject_id
* 16進数4桁
* year
* str(2桁)
* 2018年度→18
* 2005年度→05
* daimon_id
* int
~~ * kensu?
* 0,1
* dafalut:1
* man_hour?
* 0,1
* default:1~~
200の場合
```json=
{
data:
[{
date:2021/01/30,
predicted_kensu:100,
predicted_man_hour:20
},
{
date:2021/01/31,
predicted_kensu:80,
man_hour:17
}]
}
```
* /capacity
* get
* tags: capacity
* query_param
* date_from
* date_to
* 取得期間
* subject
* 日本語を使う？既存のsubject_idを使う？
* it_codeは使わない
* 科目が一意に定まるから
* man_hour_limit
* 工数制限を反映するか
* 0,1
* max_capacity
* 最大可能工数
* オプションに関してはmtgで再度聞き込み
* 添削者評価？
* response
* content-type:application/json
200の場合
```json=
{
data:
[{
date:2021/01/30,
capacity:100,
},
{
date:2021/01/31,
capacity:105,
}]
}
```
* /analysis_table
* get
* query_param
* date_from
* date_to
* 期間指定
* type_id
* it用コード
* 16進数1桁
* univ_id
* it用コード
* 16進数4桁
* subject_id
* 16進数4桁
* year
* str(2桁)
* 2018年度→18
* 2005年度→05
* daimon_id
* int
* response
* content-type:application/json
* 取得データを返す
* post
*
* response
* content-type/application/json
* テーブルに保存したデータをjsonで返す
*
上のものをしたに合わせる
/capacity/
get
post
リクエストボディにdateを
/capacity/{date}
get
put
delete
## 今後のTODO
* 上記のスキーマ定義を工数分析週例mtgで確認
* 可能工数部分に関して、オプションを詳細に
* url設計がこれでよいか
* リソース指向になってるか
* 上記を基にしてopanapi.yamlを作成
* mtgで一気に終わらせる
* 2～3h程度
* 日程：17～21までの間で
* 阿部
* 17 13:00～
* 19 20:00～
* 20,21 どの時間帯でも
* 松田
* 17 19:00~
* 19 20:00~
* 20, 21 どこでも大丈夫そうです
* 北河
* 17 13:00~16:00
* 19 20:00~
* 20 20:00~
* 21 13:00~16:00, 22:00~
* 19日の21:00～行う
* 上記のOpenAPIの設計が終わったら詳細設計
# 工数分析PJ テーブル設計mtg
|日付| 11/ 13|
| -------- | ---------------------------------- |
| 主催 | 阿部 |
| 参加人数 | 名 |
| 参加者 | 阿部、畑中、吉田|
| 場所 | Zoom |
| 開始時刻 |19:00|
| 終了時刻 |19:50|
## TODO
* ER図の確認
* 修正点等
## ER図の確認
[ER図](https://drive.google.com/file/d/1B-89GeS_DuUVpkzdes2kT04QmxqteTK9/view?usp=sharing)
* it_codeに対してIT用のKOZA_CODEなどをマッピングしている
* ITコードマスタテーブル
* PK(Primary Key，主キー)
* テーブル内においてこの値が決まるとデータとして一意に定められるもの
* opsttsの場合だとASIDに該当する
* 1対多
* 以下を満たす関係を意味する
* Aのテーブルに関して1つ選ぶとBのテーブルは多数存在する
* 逆にBのテーブルに関して1つ選ぶとAのテーブルは1つに定まる
* FK(Foreign Key，外部キー)
* 他のテーブルから参照しているキーのこと
* 例
* 工数分析テーブルにおけるIT用のコードまわりは外部キー
## 修正点等
- コンテンツ受付日のデータ型はdate型
## TODO
* 可能工数周りで必要なDBのテーブルをまとめる
* DBpjでERDを作成
# 工数分析PJ 第14回mtg
|日付|11 / 8|
| -------- | ---------------------------------- |
| 主催 | 阿部 |
| 参加人数 | 名 |
| 参加者 | 阿部、瀬尾、赤司、上田、吉田、坂上、北河、松田、中井、藤田（-23:10） |
| 場所 | Zoom |
| 開始時刻 |22:00|
| 終了時刻 |:|
## TODO
* 要件
* APIの仕様決め
* DBのテーブル設計
* 今後のTODO
## 要件
ざっくりと以下のAPIが必要
* 工数分析用テーブルを更新するAPI
* 提出件数、提出工数、可能工数の時系列データを取得するAPI
## APIの仕様決め
### 提出件数、提出工数、可能工数の時系列データを取得するAPI
* 提出件数工数、予測件数工数、可能工数に関してエンドポイントを切り分ける or まとめて出力する
* 以下の3択
* 提出&予測,可能に切り分け(2つ)
* 全部切り分け(3つ)
* 全部まとめる(1つ)
* フロントで表示する際に扱いやすい
* 一先ず切り分けて、可能かつ必要であれば結合したAPIを用意(3+1)
* 条件指定
* 試験種情報
* 科目、種別、大学、年度、大問まで
* 8通り必要では
* ': '科目'
*
* '04': '大学', # 1423
* '05': '種別・大学', # 021423
* '06': '大学・科目', # 142352
* '07': '種別・大学・科目', # 02142352
* '08': '大学・科目・年度', # 14235212
* '09': '種別・大学・科目・年度', # 0214235212
* '10': '大学・科目・年度・大問', # 1423521201
* '11': '種別・大学・科目・年度・大問', # 021423521201
* paramの数字は桁数を表してる
* 2^5通りでいけばいいのでは
* → 単体が必要
* 異様な組み合わせが混じるぐらい
* 種別・大学・科目・年度・大問でフラグを持って、2^5=32
* 16=01000 -> 大学
* 期間指定
* date_fromとdata_to
* 表示する期間
* 提出工数，可能工数でdata_toが未来だったらエラーにする
* 提出と予測の期間の違い
* APIを切り分けた場合は問題ない？↓
* 予測に使う学習データの期間の指定も必要そう
* オプション(予測の場合)
* どのアルゴリズムを利用するか
* 各アルゴリズムのparamの指定まで行うか
* あらかじめチューニングしておいて，外部からは指定しない
* text/csvとjsonのいずれで返すか
* 二つ用意した方がよさそう
* フロント側でDLと表示の両方がしやすいように
* jsonメイン
* csvはheader見て変えられる
* 簡単にcsvできそうであれば作る
* 同期API or 非同期API
* 従来の工数分析ではops,tgtからのデータを取得して集計する部分で時間がかかっていた
* テーブルを上手く設計して、そちらからデータを取得、集計すればこの部分は10秒以内にできそう
* 時系列化された工数データは学習データが少ないので予測部分はそこまで時間はかからない
* 推論では15秒もかかることない
* データが予め整形されてるのであれば**同期API**で問題ない
* もし時間がかかりすぎるようであれば，非同期に
* できるだけ同期にしたい
* 可能工数取得
* 期間指定
* date_from, date_to
* 科目
* 外れ値の定義
* 工数制限limitを反映
* オプション
* 添削者評価，新規/既存等の指定
### 工数分析用テーブルを更新するAPI
* 日付指定でその日のデータを更新
## DBのテーブル設計
* 上記のAPIの条件指定でselect可能な設計にしたい
↓ 特に正規化していない必要なデータをまとめたもの
| column | データ型 | 例 |
| -------- | ------ | -------- |
| date | datetime | 2020/01/30 |
| subject | str | 物理 |
| type | str | 過去問 |
| university | str |東京大学 |
| year | | |
| daimon | | |
| 件数 | | |
| 工数 | | |
↓ 最小単位で日別に件数と工数を用意するテーブル
| column | データ型 | 例 |
| -------- | ------ | -------- |
| it_code | | |
| date | | |
| 件数 | | |
| 工数 | | |
添削者が入るかも
(現状のit_codeはこれを実現できないらしい)
↓ 検索クエリと対応するテーブル
| column | データ型 | 例 |
| -------- | ------ | -------- |
| pk | | |
| it_type | | |
| it_univ | | |
| it_subject | | |
| it_year | | |
| it_daimon | | |
| date | | |
| 件数 | | |
| 工数 | | |
速度を気にするなら
最後のもので決定
## 今後のTODO
* OpenAPIの作成
* 上記の仕様をもとに作成
* 出力形式とかをもう少しだけ考える必要はあるかも
* 担当者：北河、松田、阿部(確認)
* テーブル更新は/{date}/{pk}
* 阿部を含めてより詳細スキーマ定義をするmtg
* ERDの作成
* 担当者：吉田、阿部(確認)
* mtgで一日で終わらせる
* 詳細設計
* ここが一番重要かつ時間がかかる
* 12月前半までに終わらせることを目標
* オブジェクト指向で
* 振分アプリの設計が恐らく一番参考になる
* 情報量は工数分析の方が少ないので、振分アプリほど多くのオブジェクトは定義しないかも
* アルゴリズムとは別の話
* そこに入れるデータの整形までの設計をする
* 担当者：坂上、阿部、瀬尾、中井(確認)
* 予測アルゴリズムの考案
* 担当者：阿部、坂上
* 12月中旬ぐらいまでに一つ二つ出来れば
上田さん：12月前半ぐらいから動けそう
# 工数分析PJ 第13回mtg(再開後キックオフmtg)
## 開催情報
| 日付 |11 / 1 |
| ------- | -------------------------- |
| 主催 | 阿部 |
| 開始時刻 |22:00|
| 終了時刻 |23:20|
| 場所 |Zoom|
| 参加人数 |10名 |
| 参加者 |阿部、藤田、赤司、上田、坂上、北河、吉田、松田、瀬尾、中井|
## TODO
* 各メンバーのキャパシティの把握
* 工数分析とは
* 開発方針
* 要件確認
* 今後のTODO
## 振分PJのメンバー募集
* コーディング段階
* viewとserializerが書ける人
* 経験がある人
* 非同期処理分かる人
* 他PJのAPIを叩き方
* デプロイ
* 行ける方
* 坂上さん
* 非同期処理いけそう
* 他も調べながらいける
* 北河さん
* 学習しながら
* そんなに他で忙しくないのでいける
* 阿部さん
* 振り分け興味ある
* zoomコーディング
* 振り分けchで今後の指針を共有しようと思います．
## 各メンバーのキャパシティの把握
|メンバー|開発経験|何h程度稼働できるか(11月)|工数分析PJでしたいこと| 補足事項|
|-- |--- | --|-- |-- |
|阿部|管理POSpj,AWS Glueチームでの開発。科目チームでの工数分析等 | 月60h程度 |予測アルゴリズムの作成| |
|藤田| 科目チーム内で様々| ？ |自分の科目運営経験をバリューとして反映 | |あくまで科目運営第一で行かせてください。
|赤司| なんやかんや色々|月5hくらい |時系列予測やりたいんですけど、キャパオーバーです | AIチームの仕事量が安定するまでIT側は控えめにしてます|
|上田|ほぼありません 模試pjで本当に簡単なコードを書いたのみです | 0h |AWSとかに興味があります | |
|坂上|管理POSpj <br> 個人では色々 | 月40~50h | コーディング <br>予測興味あります | |
|北河|管理POSpj | 月30～40h |コーディング <br>予測アルゴリズムに興味があります | |
|吉田| 日報pj、slackpj | 月40前後 | 予測アルゴリズムに興味があります <br>コーディングも頑張ります | |
|松田| 管理POSpj Slackpj <br> 個人：アプリ開発 | 月50~60h | コーディング 予測に興味あります... | |
|瀬尾| 振り分けpj 振り分けアプリ 日報pj 試験種決定自動化 | 月5h<br>mtgだけでも | 時系列予測に興味あります<br>コーディングよりは手法が知りたい | |
中井さん：手伝えたら。AI,時系列分析は滅茶苦茶強い．PyCaretとか．(Prophetでした)
PM：阿部(他にやりたい方がいればお声がけください。)
11月動けるメンバー：阿部、坂上、北河、吉田、松田
## 工数分析とは
[プロジェクト憲章](https://n-contents.backlog.com/alias/wiki/520363)
ざっくりと提出される答案に関して、過去のデータの集計と未来のデータの予測が工数分析の目的
従来の工数分析は以下の流れで行ってきた
* メールで届くas_id単位で答案データが全てまとまったopstts(過去問),tgt(単ジャ)といったファイルを取得
* 主にpythonのpandasライブラリを用いてops,tgtから科目や試験種単位で提出工数を時系列で集計
* 集計した時系列データを用いて予測データを算出
* 最も単純な定数倍予測を行っている科目が多い
* 物理や化学等、ITが進んでいた科目は古典的な時系列モデルや機械学習モデルを利用したケースも
* csvファイルとして出力したり、グラフ化してslackに投稿を行う
* 定期実行で行う科目が多い
また一度赤司さんと中井さんによって、工数分析を行うwebアプリが開発された。
現在はサーバーを落としているため恐らく使えないが、参考になる
[git](https://n-contents.backlog.com/git/CT_48/Exist/tree/master/chem/DemandPredictionWebApp)
## 開発方針
* 基本はITチームの方針に則りウォーターフォールで、詳細設計→テスト駆動でコーディング
* ただし経験上アジャイル的な進め方(振り分けアプリやadpos等)のPJの方が停滞せずに進んではいるので、柔軟に対応
* 詳細設計で停滞するといったようなことがないように
* DRFのスケルトンコードを先に作成するなどしてコーディングを意識する
* 大まかな流れ
* システム設計(OpenAPI,仕様書作成) → DRFのフレーム作成 → 予測アルゴリズムを次々と追加
* まずは提出件数や(簡単な定数倍予測などで)予測件数に簡単にアクセスできる仕組みを作成したい
* 余力があれば予測アルゴリズムも並列して考えてもよいが、優先度はAPIの実装の方が高い
* DBとのやりとりが重要
## 要件確認
一応休止前(7月以前)に要件定義は行ってはいるが、DRFやAPIの知識が余りない状態で定義したものでかなり怪しい部分があるので、一新して考え直す
[休止前要件定義](https://n-contents.backlog.com/alias/wiki/520366)
* 提出件数、工数の時系列データの取得
* 予測提出件数、工数の時系列データの取得
* 予測アルゴリズムはオプションで選択
* 最終的には工数分析PJで作成するバックエンドのAPIを用いてLIMEでフロント作成
* グラフ化もフロントで
* こちらはLIMEフロントpjでやることだが、要件的に工数分析PJのメンバーも携わった方がよさそう
* TypeScriptとmaterial-ui
* 工数予測をどの単位まで行うか？
* 科目単位 or 大学単位 or 年度単位 or 試験種(大問)単位
* 試験種(大問)単位で行うのはきつそう
* 可能工数に関しても取得してやり取りする
* ICEから取得すると負荷になりそう
* DBから取得することも視野に
* 未来のデータは常に変更があることに注意
### 工数分析用の提出件数、工数テーブルを作成する場合
* 毎回DBから全ops,tgtの情報を取ってきて算出するのはかなり実行速度が遅くなるので、工数分析用のテーブルを作成したい
* DBから各答案の情報を取得→件数と工数の計算→工数分析用のテーブルに保存するエンドポイントを作成
* 過去の提出工数や提出件数は不変
* 時系列の提出件数と工数のテーブルを作成
* 単純に提出された件数や工数を見たいだけの場合はそこからデータ取得
* 定期実行で更新できるように
* 予測の際はこちらのテーブルから時系列データを取得する
試験種別で工数を出すとなるとテーブルを作成するのは厳しいかも
* 添削者単位でも利用用途
ITコードの粒度で
### 作成しない場合
* リクエストの度にDBが必要なops,tgtデータを引っ張ってくる
* データが膨大＆過去のデータの計算などは同じ操作のため無駄が大きい
* エンドポイントを統一的にしやすい？
## 今後の流れ、TODO
* 工数分析用のテーブル設計
* APIのインタフェースの要件定義
* 担当者：参加できる方全員
* mtgは週例化する？
* 週例化する
* 月曜 22:00～
# 工数分析PJ 第12回mtg
## 開催情報
| 日付 | 7/15 |
| ------- | -------------------------- |
| 主催 | 藤田 |
| 開始時刻 |22:00|
| 終了時刻 ||
| 場所 |Zoom|
| 参加人数 |5名 |
| 参加者 |阿部、赤司、西村、藤田、東別府|
## 議事録
### 月曜のmtgから
### 本題
3パートそれぞれから今週の進捗等を報告していただけると助かります！
#### データ処理パート
先週の時点でOK
#### 予測パート
出力はpandasデータフレーム、
問題は中身のクラスをどう分けるか。予測アルゴリズムを考えながらクラスを決める。
入出力だけの定義をある程度決め、その後予測アルゴリズムを決める。
#### APIパート
Django Rest Frameワークでひな形を作成する。
フロントはS3に置く。バックエンドとフロントエンドのコンテナ間通信は考える必要なし。
バックエンドはECSにDjango Rest APIで。
### task
Django Rest Frameワークでひな形を作成する。
工数分析のリポジトリにpush(ブランチを切る)
##### APIパートのサーベイについて
Docker， ECS周り
##### views
viewsの流れを決める
##### 予測アルゴリズムをもう少し
- 工数分析学習まとめ
python系
[class](https://n-contents.backlog.com/alias/wiki/500134)
Web系
[Django Rest Framework](https://n-contents.backlog.com/alias/wiki/511443)
[REST API](https://n-contents.backlog.com/alias/wiki/536229)
[request](https://n-contents.backlog.com/alias/wiki/499330)
[link text](https:// "title")
分析系
[pandas](https://n-contents.backlog.com/alias/wiki/517530)
フロントエンド
[React](https://n-contents.backlog.com/alias/wiki/546801)
[超全体](https://roadmap.sh/roadmaps)
#### その他
回答を忘れずにお願いします。
https://forms.gle/9Qg9WNYgmHhZbedA9
https://forms.gle/TaWuWCkXHsgzBmsc9
>今月分の人事からIT人事が切り分けされることが急遽決まりました。(科目の人事を担当されている方にはこのタイミングの連絡となってしまい申し訳ございません)
以下の2つのフォームに7/16 19時までに回答してください。期限が短いので注意してください。
月例報告(6月~7月15日現在までの実績について)
PM, および統括についてみなさんへ調査
(フォームへの回答時間は給与申請OKです)
これらのフォームの目的は以下の通りになっております。
・業務が多様化した今、統括が個人の業務の見落としを防ぐため
・各人が自分の貢献量を確認し振り返る機会を作るため
・各メンバーがどのような問題意識を持ち行動に移しているかを可視化して評価するため
・統括やPMがメンバーが持っている課題意識に目を通し、業務の改善に役立てるため。また、自分を顧みることによりPJやチーム全体のレベルを底上げするため。
・やる気のある方や積極的に働いてくれる方にはどんどん仕事を任せていくため
今月の人事は(特にPJメンバーのみの方は)別で行うPMへの調査を中心に人事を定めますが、今後はここで定めたミッションとその達成度によって人事を決めます。
なので、入力が面倒だという方は来月のミッションに「PJを頑張る」など抽象的な書き方をしてもいいですが、
ミッションをどれだけ具体的に・先を見据えて自分に設定することができるか
そしてそのミッションを有言実行できるか
が評価向上の鍵となります。
PMやってたらリーダー、PMやってなかったらマネージャー以下、というような定め方をすることは一切ないので、その点はご了承＆ご安心ください。
この人事体系については、詳しく知りたい方は職務等級(やっている職務のレベル)、役割等級(期待される職務に見合った能力)で調べてみてください。(今回は職務等級ではなく役割等級を採用するということ)
※科目職階(リーダー)よりITチーム職階が下がるのではと心配な方
多少コーディングレベルが低くとも、科目チームで培ったPMスキルを発揮する事ができていて、かつIT技術の吸収に意欲的なのであればPMリーダーとする予定です。この月例報告と結果で、ぜひ実力を示してください。
# 工数分析PJ 第11回mtg
## 開催情報
| 日付 | 7/8 |
| -------- | ---------------------------------- |
| 主催 | 藤田 |
| 開始時刻 |22:00|
| 終了時刻 |23:15|
| 場所 |Zoom|
| 参加人数 |名 |
| 参加者 |阿部、西村、赤司、上田|
## 議事録
### 月曜のmtgから
特になし
### 本題
3パートそれぞれから今週の進捗等を報告していただけると助かります！
#### データ処理パート
特に何も進捗はない
前回の成果物でそのまま行けそう
#### 予測パート
入出力の部分を詰める
#### APIパート
特に進捗なし
来週までに可能であれば、たたき台のコードを作成する。
Viewsについて
### tasuku
##### APIパートのサーベイについて
Docker， ECS周り
##### views
viewsの流れを決める
##### 予測アルゴリズムをもう少し
#### その他総合的なこと
# 工数分析PJ 第10回mtg
## 開催情報
| 日付 | 7/1 |
| -------- | ---------------------------------- |
| 主催 | 藤田 |
| 開始時刻 |22:00|
| 終了時刻 |:|
| 場所 |Zoom|
| 参加人数 |名 |
| 参加者 |赤司、阿部、上田、西村、藤田|
## 議事録
### 月曜のmtgから
特になし
### 先週の「タスク」に基づいて話を進めていきます
#### 各自、ソフトウェア定義を進めていく
##### 上記3つのパートを統合した上での展望・必要な要素
- データ処理パート：opstts等からデータをAPI通じて受け取って、予測に使える形に成形
- モデルの入出力の仕様(形式)をはっきりさせる。
- 予測パート：データを引数受け取って、予測値(json, png等)を返す役割
- 入出力の形式を、具体的に指定する。
- 最初に使うアルゴリズム・その引数の指定
- API・Docker等の実行環境
- View.pyでは、どういうリクエストを受け取り、レスポンスを返すかを指定する。
- 予測アルゴリズムの進化によって、取り出す引数の数が変わる恐れあり
- まず、バックエンドの実装およびデプロイに集中し、APIを立てるところまでを完了させる
- 分担
- データ処理関連：赤司さん
- 予測パート：櫻井さん、東別府さん、上田さん
- API・Docker等の実行環境:阿部さん、西村さん、藤田
3パートそれぞれから今週の進捗等を報告していただけると助かります！
### データ処理パート
データの出力形式は
* ~Dataクラスからのpd.DataFrameでの受け渡し
* MultiDataクラスからのpd.DataFrameでの受け渡し
上の2つは状況に応じて使い分けることを想定
とりあえずOpsttsTgtDataに関しては
index : date
column : manhour(float)
を考えている
その他のDataの形式はどんなデータかによっても違うと思うので現段階では定義できない。
### APIパート
先週の内容を、図にまとめてみました。
#### APIパートの進捗について
まだ資料化はできていないのですが、サーベイしていく中で、
AWS関連(特にECS, CloudFormation当たり)と、フレームワークで機能が重複しているところがあるため、設計を考える段階で、
- ECS・CloudFormationのサーベイ
- フレームワークと組み合わせる際のベストプラクティス
等を調べる必要があると感じました。
また、フロントエンドのフレームワークとして、Reactを使う必要があるのか、それともDjangoにjavascriptを埋め込む形で対応できるのかの見極めもした方がよいかなと感じました。（これは、後々でいいかと思います。）
##### 問題点
- ブラウザからたたくときと、コマンドからたたくときで挙動が違うが、URLを統一することができいるのか？
- フロントとバックエンドの通信について、どの形にするのが効率がよいのか（サブネットでわける？ コンテナ間で通信する？）
- ほかのプロジェクトと、構造を似た形にしたい→ 振り分けPJの方と、AWS関連のサーベイおよび、使用サービスの共有を進める
#### サーベイを進めていく
Django Rest Frameworkのサーベイと資料作成について
中井さんからは
>石本さんの記事と自分のDRFチュートリアルの記事でDRFの必要な部分は網羅されているはずなので、それぞれのカスタマイズ方法（Filterは書きましたがそれ以外) や、今ModelViewSetsを中心に書かれているのでAPIViewSets中心の記事などがあると良さそうです
とのこと。ITチームにキャパを割ける方中心で作成を進めていただきたいです。
AWSに関するサーベイも進めていく必要があるので、分担して進めたい。
#### Task
サーベイについての確認が取れ次第、西村が割り振り。
#### 勉強会の視聴を、すべて完了させる
>先日は講習会への参加ありがとうございました。
講習会の受講状況管理に関して、次のスプシ（いつもと同じですが）の「IT講習会」シートで行います。
https://docs.google.com/spreadsheets/d/1NTKLIfi5qhE530jF-OE0N-gt--omissl0kHS8_kphgY/edit?usp=sharing
以下3つを【全員】埋めていただくようお願い致します。
3つの講習の受講状況
unittestの回答
ECSの立ち上げの確認 ( http://(ECSタスクのパブリックIP)/api/goods にアクセスした結果をスクショで貼り付けてください)
また、本シートは講習会に参加した人・視聴した人、全員とも埋めていただくようにお願いします。
というのも、リアルタイムでは理解できなかった部分、言われたことを実行するだけになってしまった部分も少なからずあると思うので、
その辺りをおざなりに終了していただきたくないためです。
（合わせて、今回は視聴やその理解に至る試行錯誤にかかる時間があると思うので、**給与申請は各々のかかった分に合わせて行ってください）**
今回説明した内容 (unittestの書き方やdockerコマンド, rest apiの設計) は今後の開発の前提ともなるので、
今一度不明な点がなくなるまで見返し・読み返しを行っていただければと思います。
参考資料や録画は全て関連ページにありますのでそちらご参照ください。
録画 ： https://n-contents.backlog.com/alias/file/12963298
講習会資料 ： https://n-contents.backlog.com/alias/wiki/535431, https://drive.google.com/drive/folders/14ZBFPP2Udxm5Cz_53fpd-yEp59uC9rvF?usp=sharing
※次週について
次週のこの時間ですが、藤田が自科目で絶対に外せない&リスケできないmtgが単発で入ってしまっていました。（全科目に関わる人事関連の内容です）
来週だけ別に日程調整して…というのも面倒なので、藤田を抜きにしてmtgを進めていただきたいと思っていますが如何でしょうか。
# 工数分析PJ 第9回mtg
## 開催情報
| 日付 | 6/24 |
| -------- | ---------------------------------- |
| 主催 | 藤田 |
| 開始時刻 |22:00|
| 終了時刻 |:|
| 場所 |Zoom|
| 参加人数 |名 |
| 参加者 | 赤司(化学)、東別府(物理)、西村（英語）、阿部(物理)、藤田(数学)、上田(物理)、中井(化学)
## 議事録
今日の司会：
今日の書記：
## 議題 22:00-
アジェンダ
1. 月曜のmtgを受けて
2. ソフトウェア要件定義（再発表、完成）
3. ソフトウェア方式設計・ソフトウェア詳細設計へ
## 勉強会 #6 2?:??-
http://elsur.jpn.org/202004MMM/chap7.pdf
https://docs.google.com/document/d/1mueWirrpm1rkhQHbmirU4RrP1w2u67o6cISxIJ5Az5E/edit
次回[状態空間モデル本 p. ~ p.]
→
### 月曜のmtgから
- 工数分析については特になし.
※[情報共有チャンネルでの中井さんの投稿](https://it-ntw8349.slack.com/archives/CHE913295/p1624440667064900?thread_ts=1624352990.064600&cid=CHE913295)にあった通り、AI勉強会の一部題目については視聴必須となっています。録画のurlが上がっているので、そちらから視聴をお願いします。
### ソフトウェア要件定義
先週と同じ要領で発表をお願いします。
（※システム要件定義と違い、こちらについては成果物を個別に作成する必要はないので、あくまで今後のフローにつなげるための準備段階と考えていただければと思います。）
#### データ取り込みパート
#### 予測パート
- Django Rest Apiに合う形で、アーキテクチャに変更を
- データ取り込みパート：Modelに対応させる
- 予測パート：Viewに対応させる
- モデルからデータを取ってくる
- それを処理して、結果を返す
- 予測パートがブラックボックスになるように設計＋疎結合
- 一つの関数で
- 入出力の定義をきれいに
- Django Rest Apiに合わせて、パート間の設計を詰める
#### APIパート
https://qiita.com/kotamat/items/
- フロントエンドのコンテナと、バックエンド(データ処理・予測)のコンテナに2分割する。(データ処理と予測は、一つのコンテナに)
- データ処理・予測コンテナ：Django Rest Api使って立てる。
#### 上記3つのパートを統合した上での展望・必要な要素
- データ処理パート：opstts等からデータをAPI通じて受け取って、予測に使える形に成形
- モデルの入出力の仕様(形式)をはっきりさせる。
- 予測パート：データを引数受け取って、予測値(json, png等)を返す役割
- 入出力の形式を、具体的に指定する。
- 最初に使うアルゴリズム・その引数の指定
- API・Docker等の実行環境
- View.pyでは、どういうリクエストを受け取り、レスポンスを返すかを指定する。
- 予測アルゴリズムの進化によって、取り出す引数の数が変わる恐れあり
- フロントについては、後ほど人員募集
- まず、バックエンドの実装およびデプロイに集中し、APIを立てるところまでを完了させる
- 分担
- データ処理関連：赤石さん
- 予測パート：櫻井さん、東別府さん、上田さん
- API・Docker等の実行環境：藤田さん、阿部さん、西村
#### どこでデータの処理を行うか
- **Modelでデータ処理**：
- 予測アルゴリズムの引数が変わると面倒
- 予測アルゴリズムと引数の対応表があれば、柔軟に対応可能
- 予測側でデータ処理：
- 依存関係が強まるが、予測アルゴリズムの引数の変化に柔軟に対応できる
#### キャパについて
- 阿部さん：管理POSが忙しい。ほどほど
- 赤司さん：ITに時間をさくことが出来るが、 GraphQLを一人でやらなくてはならいのでそちらの方に注力する必要
- 西村さん：英語科の運営の方に時間を割かないといけない.
- 上田さん：時間をさくことが出来るが、コーディングとして戦力になれるかわからない.
- 櫻井さん：大学の課題とAIの方で忙しい。
- 藤田さん：東進には時間を割けるが、科目統括と新制作で忙しい。
https://buildmedia.readthedocs.org/media/pdf/djangoapibook/latest/djangoapibook.pdf
#### タスク
- 各自、ソフトウェア定義を進めていく
- サーベイを進めていく
- 勉強会の視聴を、すべて完了させる
~~### ソフトウェア方式設計・ソフトウェア詳細設計へ（モジュール分割）
#### ソフトウェア方式設計
>ソフトウェア内の処理をさらに細分化する
1つのメソッド・関数が1つの役割を持つような分け方をする
設計のアプローチには **「オブジェクト指向アプローチ」** を取ると良い
データとそれに対する手続き(メソッド)をオブジェクトと呼ばれる1つのまとまりとして管理し、その組み合わせに着目して設計を行う手法
関数の引数は値であるべきなのか、オブジェクトであるべきなのか (= データ構造の定義) この時点でじっくり詰めることにより綺麗な構成に
メソッドの作成は、設計者の観点ではなく利用者の観点で行う
= 必要な操作から逆算的にどのオブジェクトに対応するメソッドを持たせるか考える
役割を分担する際の分割単位となる、この手順が全体で**最も重要**
メソッド同士の因果関係や順序関係、オブジェクト同士の関係などを関係図として書き出す
~~上記の説明だけでピンとこない方もいらっしゃるかもしれないので、添削運営での例えも添えておきます。十分理解されている方は読み飛ばしてもらって大丈夫です
>・東大、京大、阪大、神大の4大学の添削は、それぞれ必要な技量や注意して見るべきポイントが大きく異なり、統一したマニュアルだけでは満足な添削はできない。かといって一人の添削者が全く異なる4大学の添削に必要な情報や出題傾向を全て個々に把握して…というのは効率的にも複雑さ的にもよくない。
・そこで、（既に各科目がやっているように）各添削者に担当大学を割り振り、「東大担当の人」「京大担当の人」…と担当者を割り振る。各担当者がそれぞれの大学の添削に必要な情報のみを持ち、その大学の添削に集中すればよい。また、取り仕切る人（運営）は各大学の添削の情報を細かく管理する必要はなく、各大学の答案数をモニタリングして、それぞれの大学担当に割り振れば良い。
・たとえば京大と神大の出題傾向が著しく似ている場合、この2大学の添削者は取りまとめてしまってもよい。場合によってはどちらかの大学の添削のテクニックをもう一方の大学の添削に活かせるかもしれない。
→上記のように、**「どの人がどのような情報を持っていて、どのような処理をするか」** に着目するのが **「オブジェクト指向アプローチ」**。
大事になってくるのは、**「どの人がどのような情報を持っていて、どのような処理をするか」**、そして **「それぞれの人（担当）同士がどのような関係性を持つか」** の2つ。
※オブジェクト…上記の例では一つ一つの「大学担当の人」に該当する。
※メソッド…上記の例では「大学担当の人が、各々の持っている情報をもとに行う行為（＝添削）」に該当する。
※クラス…上記の例では一つ一つの「大学担当の人」の規格に該当する。「添削者クラス」みたいな感じ。「添削」というメソッドなどもあらかじめ「添削者クラス」の時点で（関数的に）定義されている。
※インスタンス…クラス→オブジェクトに具体化する。（「添削者」というクラスから「東大担当の人」「京大担当の人」といったようなオブジェクトに具体化する、みたいな）
※「必要な操作から逆算的にどのオブジェクトに対応するメソッドを持たせるか考える」…新たに東北大の答案が提出されるようの答案が提出されるようになった→東北大の答案を添削して返却する必要がある→「東北大担当の人」オブジェクトを設けて、そのオブジェクトに「添削」というメソッドをもたせればいい。
~~#### ソフトウェア詳細設計（もう少し先ですがどうせなので一緒に）
>コーディングを行う単位となる個々のプログラム・モジュールの仕様を詳細に決定する
上で分割した各モジュールに関して、その
・メソッド(ルーチン)
・引数
・戻り値
・機能
を完全に示したドキュメントを作成する(= システム仕様書)
メソッド ... 作成したモジュールやオブジェクトが持つべきインターフェース
機能 ... 期待される処理と、処理のフローを示す
~~++ソフトウェア方式設計について++
分担：引き続きこのままでよいか？
期限：1週間or2週間。メンバーの予定に応じて定めましょう
# 工数分析PJ 第8回mtg
## 開催情報
| 日付 | 6/17 |
| -------- | ---------------------------------- |
| 主催 | 藤田 |
| 開始時刻 |22:00|
| 終了時刻 |:|
| 場所 |Zoom|
| 参加人数 |名 |
| 参加者 | 赤司(化学)、東別府(物理)、西村（英語）、阿部(物理)、藤田(数学)、上田(物理)、中井(化学)
## 議事録
今日の司会：藤田
今日の書記：
## 議題 22:00-
藤田アジェンダ
1. 月曜のmtgを受けて
2. ソフトウェア要件定義について（途中報告・たたき台）
### 月曜のmtgから
特になし。
## ソフトウェア要件定義
>システムを構成するソフトウェアごとに、機能や能力など必要な要件を明らかにする
これまでのフローで切り分けた各ソフトウェアに対して、さらにそのソフトウェアが
何をするか (機能)
インターフェース (どのようなデータや値を入力として要するか)
他のソフトウェアやモジュールとの階層関係・依存関係
ソフトウェア同士に順序関係ができてしまう場合。特に、フレームワークなど
どのようにするか
をまとめる
次の段階が最も重要なので、そのための下準備がこの段階
１箇所を変えた際他に影響を与えないような単位で分ける。１つのクラスで分けるイメージ。
1週間で大まかな構想→来週のmtgで発表＆FB
- 取得した時系列データ(提出工数や可能工数)と学習済のモデルパラメータ及び、予測手法に関する3.から受け取ったリクエストを元に予測を行い、データ予測の結果をjson, csv, jpg(予測結果のグラフ)として3.に渡す
- 
データの置き場所についてinput dataはDataLoader内、Model DataはModel Fit内に
DataLoaderにデータ置いといてそこから関数で呼び出せばTransformer挟む必要ないのでは
PredictObj内のDataLoader、Transformerが赤司さんパートとかぶっているのでほぼなくすイメージ
### データ取り込みパート
次週練り直したものを発表
### APIパート
3つの段階は全て同じECSにのせる。よって、システム間の情報のやりとりには、pythonのimport等を用いて行う。
・予測結果をjsonで返すAPI
・グラフの画像データを返すAPI
・Webアプリとして、jabascript持ちいて、予測結果をグラフ化するもの
# 工数分析PJ 第7回mtg
## 開催情報
| 日付 | 6/10 |
| -------- | ---------------------------------- |
| 主催 | 藤田 |
| 開始時刻 |22:00|
| 終了時刻 |23:15|
| 場所 |Zoom|
| 参加人数 |名 |
| 参加者 | 赤司(化学)、東別府(物理)、西村（英語）、阿部(物理)、藤田(数学)、櫻井（物理）
## 議事録
今日の司会：藤田
今日の書記：
## 議題 22:00-
藤田アジェンダ
1. 月曜のmtgを受けてのこれからの方針・追加事項等の確認
2. 講習会の発表メンバーの選出
3. ソフトウェア要件定義について再確認
### 月曜のmtgから
mtg 報告
GUIの作り方、見た目はITチーム内で統一したい。平野さんが進めている振り分けアプリが先にサーベイなどを行っており、Next.jsを使うという方針になっている。GUIを早めに作るなら平野さんと連絡をとってサーベイなども共同で行うことを選択肢として考える。
→平野さんにコンタクト取ってサーベイも共同で進める。
### 講習会の発表会メンバーについて
>中井 優 8:20 PM
@藤田葵 さん
本チームから「DockerとECSに関して」の講習会の発表メンバーを1人以上捻出していただきたいので、
週末目処に募集していただいてもよろしいでしょうか？
講習会の準備は1つの議題に対して3人くらいで行っていただくつもりです
よろしくお願いします。
ということなのですが、どなたかしていただけるかたいらっしゃいますでしょうか…？（他チームの担当の方と合同で行うとのことです）
→Docker:西村さん、阿部さん、お願いします。
unittestとpytest：赤司さん
◯合わせて講習会の日程調整への解答もよろしくおねがいします。
https://chouseisan.com/s?h=f140648f96e4413c8e2a7e3428218016
→この場で全員していただけると..
## ソフトウェア要件定義
システムを構成するソフトウェアごとに、機能や能力など必要な要件を明らかにする
これまでのフローで切り分けた各ソフトウェアに対して、さらにそのソフトウェアが
* 何をするか (機能)
* インターフェース (どのようなデータや値を入力として要するか)
* 他のソフトウェアやモジュールとの階層関係・依存関係
* ソフトウェア同士に順序関係ができてしまう場合。特に、フレームワークなど
* どのようにするか
をまとめる
次の段階が最も重要なので、そのための下準備がこの段階
１箇所を変えた際他に影響を与えないような単位で分ける。１つのクラスで分けるイメージ。
1週間で大まかな構想→来週のmtgで発表＆FB
次週練り直したものを発表
予測の段階でどういうデータが必要か：webアプリで扱ってるデータを元にする。模試の日程データ、生徒別講座取得状況、東進にかかわるようなイベント情報も追加。
opstts_tgtのソフトウェア要件定義草案
https://hackmd.io/lu-X7pslTrGjjpjf5th0PQ
試験種決定最適化の図
<img src="https://i.imgur.com/7tuJirT.jpg" width=500>
- HogeObjは1つのクラス(パッケージ)を表すデータクラス
- 青い四角は1つのクラス(パッケージ)を表すcallableクラス
## 勉強会 #5 2?:??-
http://elsur.jpn.org/202004MMM/chap5.pdf
https://docs.google.com/document/d/1mueWirrpm1rkhQHbmirU4RrP1w2u67o6cISxIJ5Az5E/edit
次回[状態空間モデル本 p.223 ~ p.279]
→ http://elsur.jpn.org/202004MMM/chap7.pdf
# 工数分析PJ 第6回mtg
## 開催情報
| 日付 | 6/3 |
| -------- | ---------------------------------- |
| 主催 | 藤田 |
| 開始時刻 |22:30|
| 終了時刻 |24:40|
| 場所 |Zoom|
| 参加人数 |6名 |
| 参加者 | NaN
## 議事録
今日の司会：藤田
今日の書記：櫻井
## 勉強会（本を読む） #4 22:00-
http://elsur.jpn.org/202004MMM/chap5.pdf
https://docs.google.com/document/d/1mueWirrpm1rkhQHbmirU4RrP1w2u67o6cISxIJ5Az5E/edit
次回[状態空間モデル本 p.223 ~ p.279]
→ http://elsur.jpn.org/202004MMM/chap7.pdf
## 議題 22:30-
## 次回から勉強会とmtgの順序を逆にして頂けるととてもありがたいです。(赤司)
→します
### 月曜のmtgから
gドラりんく
https://drive.google.com/drive/folders/144HNd-2-IxGDetySms_5QfZzV6tCvez8?usp=sharing
あんけーと
https://docs.google.com/forms/d/e/1FAIpQLSeUydrajb0tdTy4v3xqQid3I_Cl7aGb-6jy6O9F0lPguz8_Bw/viewform?usp=sf_link
### 要件定義について
[要件定義書](https://n-contents.backlog.com/wiki/CT_48/%E5%B7%A5%E6%95%B0%E5%88%86%E6%9E%90pj%2F%E6%88%90%E6%9E%9C%E7%89%A9%2F%E8%A6%81%E4%BB%B6%E5%AE%9A%E7%BE%A9%E6%9B%B8)
* システムが「何を」するか
具体的には、
* 扱うデータの種類やそれをどのように入力するか
* 構造
* 処理内容
* ユーザーインターフェース
* 出力の形式
→システムは3つ
DBから時系列データへ→30日後までの予測→公開(APIを立てる)
#### phase1 DBたたいて1つの時系列データに
#### phase2 時系列データを入力として予測を出す
#### phase3 予測を外へ
### [task] 6/3までにbacklogの要件定義書に記入していきましょう。
## システム方式設計にむけて
> システムを構成するソフトウェアの切り分けを行う
> 上記で定義したシステムの要件に対して、内部的にどのようなソフトウェアの構成に切り分けられるかを決定する
ソフトウェア同士は疎結合になってなければならない
共通して用いる要素などはフレームワークの中でもutilityとして実装することが多いが、そのようなモジュールはどれほど必要か
ソフトウェア同士のフローの図や関係図を作成
この段階で要員の割り振りを行うことも可能
# 工数分析pj 要件定義書
> 構築するシステムの仕様を明文化し、成果物のイメージを統一する
> 業務視点とIT視点の両方で、システムの要件を整理する
## システム構成図
### システムのコンポーネント同士の関係性
システムを構成するのはモジュール・パッケージ
それらパッケージの内容とカバーする範囲を明記
ボトムアップで構築されるシステムの全体観を提示
工数分析pjは以下の3つのモジュールからなる
1. データベースpj管理のデータベースから工数分析・予測に用いる時系列データを取得する。
2. 取得した時系列データ(提出工数や可能工数)と学習済のモデルパラメータ及び、予測手法に関する3.から受け取ったリクエストを元に予測を行い、データ予測の結果をjson, csv, jpg(予測結果のグラフ)として3.に渡す。
3. 外部との接続面として、jsonファイル及びjpgファイル(グラフ)の出力に関するリクエストを受け、それを元に2.で作成したjsonファイル及びjpgファイルを出力する。
### 他システムとの関係性
- データベース
- input: opstgtのデータ及び可能工数データを受け取る.
- output: なし
- slack, 試験種分析, 模試に使ってもらいそう？
## ネットワーク構成図
## 機能要件
> システムを実装することで、できること
> データやシステムの種類・構造や、システムが処理可能な内容
### 1. DBから時系列データを取得する。
主な機能は以下
* 工数分析APIのパラメータを解釈し、DBに合わせた条件に変換する
* 条件をもとにDB APIを叩いてデータを取得し、pd.DataFrameにして返す
* pd.DataFrameを日単位で工数のsumをとった時系列データに変換する
* その他予測に必要なデータをDBから取得する
このシステムが返す時系列データの形式
| No. | 項目名 | 型 | 項目説明 | 具体例 | 備考 |
| --- | --- | --- | --- | --- | --- | --- | --- |
|1|date|date|YYYYMMDD 西暦で日付を表す|2021-6-1|なし|
|2|man_hour|float|その日の検索条件を満たす提出の工数合計|255.2|なし|
### 2. リクエストを元に予測し、結果を3.に渡す
細かな機能
* 3.から受け取った分析手法や分析対象データに関するデータを解釈し、1.に必要なデータをリクエストする。それによって得られたデータを元に工数分析及び工数予測を行い、その結果のjson, csv, jpgファイルを3. に返す。
### 3.APIを立てる
#### インターフェース
外部からリクエストを受け,予測工数データや実工数データをjsonファイル,グラフをjpagファイルで返す.
呼び出しはpostメソッド.
#### 入力形式
requestの入力データは以下の通り.
| No. | 項目名 | 型 | 項目説明 | 具体例 | 備考 |
| --- | --- | --- | --- | --- | --- | --- | --- |
| 01 | predictType | str | 予測手法の選択(番号選択) | 1 | デフォルトのものを一つ規定 |
| 02 | datefrom | date | この日以降のデータを出力 | 20200824 | 8桁固定 |
|03 | dateto | date |この日以前のデータを出力 | 20200921 | 8桁固定 |
| 04 | kamoku | str | 科目を表す数字(科目コード) | 30 | デフォルトで全科目 |
| 05 | kakomontanja | str | 両方(1),過去問(2)と単ジャ(3)の選択 | 1 | デフォルトで両方 |
| 06 | kamokuID | str | 科目ID | 52 | フォルトで指定なし(同じ大学の試験種を区別する) |
| 07 | university |str | 大学名 | 東京大 | デフォルトで全大学|
#### 出力形式
jsonファイルにより出力。
| No. | 項目名 | 型 | 項目説明 | 具体例 | 備考 |
| --- | ----------- | ---- | ---------- | -------- | ---- |
| 01 | date | date | yyyymmdd | 20210508 | 8桁固定 |
| 02 | predict/actual_man_hour | float |予測/実提出工数 | 1.234 |先日までのものはactual,その日以降はpredict |
| 03 | potential_man_hour| float | 可能工数 |123.456|大学指定がある場合はNULL |
* jsonファイルで出力する以外にグラフによる出力も想定。横軸にdata、グラフデータとしてpredict/actual_man_hourとpotential_man_hourの表示。処理日の前後で色分け。（jsonファイルによる出力とは別々にエンドポイントを立てる）
## 非機能要件
#### システムの利用者、ユーザビリティ
* 科目リーダー（非ITリーダーからも含む）／工数分析担当からのアクセスを主に想定。
* 利用頻度は手動のものは不定期を想定。自動のものは定時(各日など)でslackに投稿されることを想定。
#### システムの性能、信頼性
* 特に多くリクエストされるような条件については、1回のリクエストごとに一から処理を行うのではなく、予め過去の出力データを何かしらの形で蓄積して即座に出力できるようにすることで処理時間の短縮に
# 工数分析PJ 第5回mtg
## 開催情報
| 日付 | 5/27 |
| -------- | ---------------------------------- |
| 主催 | 藤田 |
| 開始時刻 |22:30 |
| 終了時刻 |23:15|
| 場所 | Zoom |
| 参加人数 | 6名 |
| 参加者 | 藤田(数学)、阿部(物理)、赤司(化学)、西村(英語)、櫻井(物理)、上田(物理)
## 議事録
今日の司会：藤田
今日の書記：櫻井
## 勉強会（本を読む） #3 22:00-
http://elsur.jpn.org/202004MMM/chap5.pdf
https://docs.google.com/document/d/1mueWirrpm1rkhQHbmirU4RrP1w2u67o6cISxIJ5Az5E/edit
次回[状態空間モデル本 p.178 ~ p.222]
→ http://elsur.jpn.org/202004MMM/chap7.pdf
https://www.amazon.co.jp/%E3%83%87%E3%83%BC%E3%82%BF%E8%A7%A3%E6%9E%90%E3%81%AE%E3%81%9F%E3%82%81%E3%81%AE%E7%B5%B1%E8%A8%88%E3%83%A2%E3%83%87%E3%83%AA%E3%83%B3%E3%82%B0%E5%85%A5%E9%96%80%E2%80%95%E2%80%95%E4%B8%80%E8%88%AC%E5%8C%96%E7%B7%9A%E5%BD%A2%E3%83%A2%E3%83%87%E3%83%AB%E3%83%BB%E9%9A%8E%E5%B1%A4%E3%83%99%E3%82%A4%E3%82%BA%E3%83%A2%E3%83%87%E3%83%AB%E3%83%BBMCMC-%E7%A2%BA%E7%8E%87%E3%81%A8%E6%83%85%E5%A0%B1%E3%81%AE%E7%A7%91%E5%AD%A6-%E4%B9%85%E4%BF%9D-%E6%8B%93%E5%BC%A5/dp/400006973X
[次回の範囲]
## 議題 22:30-
### 新メンバー
新しく上田遥介さんにも入っていただくことになりました。よろしくお願いします！
### 月曜のmtgから
西村さん(+上田さん)について
とりあえずこれまでの流れとプロジェクト憲章は最低限見てもらいたい
その他に特記すべきものありますかね？
- backlogの参考資料のpythonの基礎, numpy, pandasを勉強してほしい。
- これまで4回分の議事録と、プロジェクト憲章の確認もお願いします。
- **資料通読に関して、合計で3時間まで時給申請可能です**。
- djangoの学習について
- djiango girls (https://djangogirls.org/) のサイトを進めていく
- 中井さんオススメの本https://www.amazon.co.jp/%E5%8B%95%E3%81%8B%E3%81%97%E3%81%A6%E5%AD%A6%E3%81%B6-Python-Django%E9%96%8B%E7%99%BA%E5%85%A5%E9%96%80-NEXT-ONE/dp/4798162507 もあります。(他の言語でwebアプリ開発経験がないとキツそうでした。by櫻井)
- **djiangoの学習にかかった時間は後ほどまとめて申請するのでとりあえず申請は保留でお願いします。**
- 時系列分析の背景知識について
- http://elsur.jpn.org/202004MMM/chap5.pdf のp.117くらいまで読んでいただけると助かります。
### 要件定義について
[要件定義書](https://n-contents.backlog.com/wiki/CT_48/%E5%B7%A5%E6%95%B0%E5%88%86%E6%9E%90pj%2F%E6%88%90%E6%9E%9C%E7%89%A9%2F%E8%A6%81%E4%BB%B6%E5%AE%9A%E7%BE%A9%E6%9B%B8)
* システムが「何を」するか
具体的には、
* 扱うデータの種類やそれをどのように入力するか
* 構造
* 処理内容
* ユーザーインターフェース
* 出力の形式
→システムは3つ
DBから時系列データへ→30日後までの予測→公開(APIを立てる)
分担
* DBから時系列データ : 赤司,
* 30日後までの予測 : 東別府,櫻井
- 可能工数を出力するためにデータベースにアクセスする必要あり
* 公開(APIを立てる) : 阿部,藤田
jsonファイルを出力するものとグラフを出力するAPIをDjangoで立てる。
predict_allとpredict_uniで共通部分がほとんどであっため、二つをまとめた。また、グラフ生成のAPIの引数は同じにした。
予測と提出件数データをjson形式で出力する
jsonファイルの出力
引数としては以下を受け取る
```
Parameters
predictType : 予測手法の選択(デフォルトのものを一つ規定)
datefrom : この日付以降のデータ(予測or実工数)を出力(yyyyMMdd)。 入力必須
dateto : この日付以前のデータ(予測or実工数)を出力(yyyyMMdd)。 入力必須
kamoku : 科目 デフォルトで全科目
kakomontanja : kakomonとtanja デフォルトで両方
kamokuID : 同じ大学の試験種の区別 デフォルトで指定なし
university : 大学 デフォルトで全大学 入力はリストで複数選択可(大学名)
```
グラフの出力
構造として上記のAPIにグラフ
作成のモジュールを重ねる形。
```
Parameters
predictType : 予測手法の選択(デフォルトのものを一つ規定)
datefrom : この日付以降のデータ(予測or実工数)を出力(MMdd)。 入力必須
dateto : この日付以前のデータ(予測or実工数)を出力(MMdd)。 入力必須
nendo : 年度
kamoku : 科目 デフォルトで全科目
manhour : 可能工数を出力するか否か(ただし、大学単位での場合出力はなし)
kakomontanja : kakomonとtanja デフォルトで両方
kamokuID : 同じ大学の試験種の区別 デフォルトで指定なし
university : 大学 デフォルトで全大学
```
過年度の工数の同時出力
#### phase1 DBたたいて1つの時系列データに
#### phase2 時系列データを入力として予測を出す
#### phase3 予測を外へ
### [task] 6/3までにbacklogの要件定義書に記入していきましょう。
# 工数分析PJ 第4回mtg
## 開催情報
| 日付 | 5/20 |
| -------- | ---------------------------------- |
| 主催 | 藤田 |
| 開始時刻 |22:30 |
| 終了時刻 |24:00 |
| 場所 | Zoom |
| 参加人数 | 6名 |
| 参加者 | 藤田(数学)、阿部(物理)、櫻井(物理)、東別府(物理)<br>赤司(化学)、西村(英語) |
## 議事録
今日の司会：藤田
今日の書記：-
## 勉強会（本を読む） #2 22:00-
http://elsur.jpn.org/202004MMM/chap5.pdf
今回の範囲
- pythonではstatsmodels.apiを用いてRと同じようなことができる
[参考]
https://www.statsmodels.org/stable/tsa.html
https://www.kumilog.net/entry/sarima-pv
- 使うかもしれないライブラリ
lightLGM, statsmodels.api, pytorch, scikit-learn
[次回の範囲]
第3章p118~p177
## 議題 22:30-
### 新メンバー
新しく西村太希さんに入っていただくことになりました。よろしくお願いします！
### 月曜のmtgから
大したことはなかった
人材募集については統括の方にお願いをした
### 要件定義について
[要件定義書](https://n-contents.backlog.com/wiki/CT_48/%E5%B7%A5%E6%95%B0%E5%88%86%E6%9E%90pj%2F%E6%88%90%E6%9E%9C%E7%89%A9%2F%E8%A6%81%E4%BB%B6%E5%AE%9A%E7%BE%A9%E6%9B%B8)
* システムが「何を」するか
具体的には、
* 扱うデータの種類やそれをどのように入力するか
* 構造
* 処理内容
* ユーザーインターフェース
* 出力の形式
→システムは3つ
DBから時系列データへ→30日後までの予測→公開(APIを立てる)
分担
* DBから時系列データ : 赤司,
* 30日後までの予測 : 東別府,櫻井
出力はjsonとcsvも？←webアプリがjsonで受け付けるようにしている。
予測モデルに関するデータ(pklなど)は同じディレクトリに置いておけば良い。
https://imgur.com/
* 公開(APIを立てる) : 阿部,藤田
jsonファイルを出力するものとグラフを出力するAPIをDjangoで立てる。
predit_all(科目ごとor全科目の提出工数と予測を出力するAPI)
request時には以下のパラメータを指定
```
Parameters
predict_date_from : この日付以降の提出工数を予測(yyyyMMdd)。
predict_date_to : この日付以前の提出工数を予測(yyyyMMdd)。
kamoku : 予測する科目
predict : 工数予測
submit : 実提出工数
```
responseでは以下をjsonファイルとして返す。
| column | データ型 | 例 |
| -------- | ------ | -------- |
| date(日付) | datetime | 2020/01/30 |
| kamoku(科目) | str | 物理 |
| predict_kosu(予測工数) | float |200.00 |
| submit_kosu(実提出工数) |float | 203.00 |
predit_uni(大学単位で提出工数と予測を出力するAPI)
request時には以下のパラメータを指定
```
Parameters
predict_date_from : この日付以降の提出工数を予測(yyyyMMdd)。
predict_date_to : この日付以前の提出工数を予測(yyyyMMdd)。
kamoku : 予測する科目
university : 大学
kakomon_tanja : 過去問 or 単ジャ
predict : 工数予測
submit : 実提出工数
```
試験種番号も追加するべき？(同じ大学の違う試験種を区別)
⇒ 特に数学では文系と理系で区別が必要
⇒ 科目IDを情報として残しておく
responseでは以下をjsonファイルとして返す。
| column | データ型 | 例 |
| -------- | ------ | -------- |
| 日付 | datetime | 2020/01/30 |
| kamoku(科目) | str | 物理 |
| 種別(過去問or単じゃ) | str | 過去問 |
| university(大学) | str |東京大学 |
| predict_kosu(予測工数) | float |200.12 |
| submit_kosu(実提出工数) |float | 203.00 |
グラフ生成API
request時には以下のパラメータを指定
```
Parameters
predict_date_from : この日付以降の提出工数を予測(yyyyMMdd)。 入力必須
predict_date_to : この日付以前の提出工数を予測(yyyyMMdd)。 入力必須
kamoku : 予測する科目 デフォルトで全科目
university : 予測大学 デフォルトで全大学
kensu : 実件数をplotするか デフォルトon
predict : 予測をplotするか デフォルトon
```
グラフはslackやWebアプリに出力することを想定
パラメータと出力項目の吟味を来週までに行う。
粒度については後回し
可能工数の出力も必要？
⇒必要なし(振り分けpjの管轄)
#### phase1 DBたたいて1つの時系列データに
#### phase2 時系列データを入力として予測を出す
#### phase3 予測を外へ
時給申請
西村さんの場合はキャッチアップの時間はイレギュラーケースになると思うがどうか？→月曜mtgで確認
＊今日発表しあって、出た意見を元に次の1週間で完成、次のフローへ進む予定です。
# 工数分析PJ 第3回mtg
## 開催情報
| 日付 | 5/13 |
| -------- | ---------------------------------- |
| 主催 | 藤田 |
| 開始時刻 |22:30 |
| 終了時刻 | |
| 場所 | Zoom |
| 参加人数 | 名 |
| 参加者 | 赤司(化学)、阿部(物理)、東別府(物理)、<br>櫻井(物理)、中井(化学)、森田(英語）<br>藤田(数学)
## 議事録
今日の司会：藤田
今日の書記：森田
## 勉強会（本を読む）#1
櫻井さんお願いします！
→藤田補足（櫻井さんが仰っていたリンク）
http://elsur.jpn.org/202004MMM/chap5.pdf
$LaTeX$
$a^2 + b^2 = c^2$
TeX、使えそうです
22:00~輪講(本を読んできた方たちで）, 22:30~全員でmtg
## 議題
### 前々回の全体mtgを受けて
#### 給与申請の範囲
藤田さん不在でしたが、ある程度話し合ったので共有
> サーベイや勉強絡みの日報申請について、ITチーム全員がはっきりと分かるよう明文化・周知しておいたほうがよいと思います。
現状だと（自分の認識している限りでは）「資料を作成するのであればOK」ということになっていると思いますが、その上でどこまで申請してよいのか（調べた内容を100%文字起こしするわけでもないと思いますが、そのような周辺知識についてサーベイしている時間も含めて100%申請してよいのか、それとも周辺知識については省くべきorそれらについても無理やり資料作成しない限り申請不可なのか）、また既に資料が作成されていてもその資料を見ただけで全て理解できるわけではなく、特に不慣れな人やITにあまり強くない人は自分でさらにサーベイする必要があると思いますが、そのようなケースでは既に資料が作成されているためたとえ数十時間かかろうが一切申請できなくなるのかなど、いろいろと曖昧な点が多いように感じます。また、サーベイ自体は必要不可欠だが緊急性が高く、資料まで作成する時間がない(orPJの進行に支障が出る)ことも考えられなくはないはずです。
昨年度の夏に、各科目チームで「業務に要した時間を正直に申請するようにしてください」というアナウンスがあったと思いますが、その原則がそのまま適用できないため、自分の他にも困惑している方が一定数いると思います。ITにあまり強くない人がpj業務についていくために、他の優秀な人であれば簡潔に説明されているbacklog上の資料を読めば分かる内容について、自分でさらに時間をかけてサーベイして理解したのに、いざ何も知らずに日報申請したら虚構だと言われるのも可哀想なので、はっきりと申請できるラインを定めた上で全体にアナウンスするのがよいのではと思いました。
> - 資料作成時の疑問点
> - 資料作成していないけど周辺知識を調べた時間は申請していいか
> - (中井)その周辺知識を知らないと進めないのが自分だけなのか、他の人もなのか、自分だけでないのであれば資料にした方が良さそう、それ以上の境界は難しそう
> - (武田)上限を設けるのも良さそう
> - やり損になってしまうこともときにはあるかも知れないが、力をつけて評価されていけば単価が上がっていずれ報われるので、悪しからず
> - 資料を読む際の疑問点
> - 資料を読むのに（レベル感の違いから)必要以上に時間がかかった場合、どのように申請すべきか
> - (武田)こっちは一律に
> - 初学者であっても、とっつきやすい内容の資料を作成するのがベースであるため
> - すごい難しい技術は資料化していない
> - (中井)基本的にはpjには学習の道筋を明確に立ててもらっているため、飛躍があるのであれば「作成」や「更新」を行う方の申請とする (きちんと初学者が合流できるような布石を敷く)
> - (樋口)積極的にoutputすることにより打開可能。outputは形として見えやすいので。backlogのwikiやout-of-projectのgitに
> - 資料を更新する際のルール設定
> - (樋口)誰でも更新して良いのか、その更新を自由に申請して良いのか
> - 更新は誰でもして良い
> - 更新をしたときの申請ルールが微妙
> - 追い追い決める
> - 例えば、工数分析pjのように1つの本を読むとき
> - (中井)本を読む時間は申請外、業務に直接関わる部分をまとめる+資料化する時間は申請内、そこに飛躍がある場合に補う最小限の資料作成も申請内の認識
> - 読み損になってしまうのであれば、ピンポイントに関わりそうな技術のみのサーベイと資料化を行えば良い
> - 成果物に必要十分な申請を行うと言う観点では、本一冊は十分条件だが、必要十分ではない
> - (武田)大体同じ。本を読む時間を申請時間に入れないのは前提。
> - 工数分析の調査に関する給与申請の境界は藤田と櫻井で話し合って決める
#### 進め方の方針
>①工数分析の幹となる部分はコードブラッシュアップというよりも、大きな構造の部分から再構築の形になりそうなので、そちらを他のPJ同様に企画、設計、開発の流れをとる。
②今はチームを2分割してしまっているが、**企画、設計、開発の流れをメンバー全員が共有、経験するべき**と中井優さんからのアドバイスを受けました。そのため、**1の流れを全員で担当して、手が空いている人で分析方法の資料作成、選定を行っていくのが望ましい**とのことです。僕もそう思います。
③ボトルネックとなる他PJととのインターフェース(特にDB)は他PJと積極的にmtgなどを行ってインターフェース部分の設計を決定し、開発を進めていくべきだと思われます。→
④親切にも1の大まかな構造を提示していただいているので、これを活用させていただけばシステム設計にかける時間の節約になりそうです。
ということなのですが、前回mtgの２チームに分かれて…という点は一旦白紙にして、上記①②の方針に乗っ取る形で大丈夫そうでしょうか。
その上で…（？）
プロジェクト憲章・全体開発スケジュールについてはこちらの内容で提出してしまって大丈夫でしょうか。チェックをお願い致します。
[プロジェクト憲章](https://n-contents.backlog.com/wiki/CT_48/%E5%B7%A5%E6%95%B0%E5%88%86%E6%9E%90pj%2F%E6%88%90%E6%9E%9C%E7%89%A9%2F%E3%83%97%E3%83%AD%E3%82%B8%E3%82%A7%E3%82%AF%E3%83%88%E6%86%B2%E7%AB%A0)
[全体開発スケジュール](https://n-contents.backlog.com/wiki/CT_48/%E5%B7%A5%E6%95%B0%E5%88%86%E6%9E%90pj%2F%E6%88%90%E6%9E%9C%E7%89%A9%2F%E5%85%A8%E4%BD%93%E9%96%8B%E7%99%BA%E3%82%B9%E3%82%B1%E3%82%B8%E3%83%A5%E3%83%BC%E3%83%AB)
opstts_tgtのスケジュールとの調整
https://hackmd.io/1fj62HJfTIeWrBcRUki8Iw
### 次のフロー（要件定義）について
[要件定義書](https://n-contents.backlog.com/wiki/CT_48/%E5%B7%A5%E6%95%B0%E5%88%86%E6%9E%90pj%2F%E6%88%90%E6%9E%9C%E7%89%A9%2F%E8%A6%81%E4%BB%B6%E5%AE%9A%E7%BE%A9%E6%9B%B8)
* システムが「何を」するか
具体的には、
* 扱うデータの種類やそれをどのように入力するか
* 構造
* 処理内容
* ユーザーインターフェース
* 出力の形式
藤田の（個人的な）考えとしては、適宜分担して各人が記入していく形式にしたいと思っています。
→システムは3つ
DBから時系列データへ→30日後までの予測→公開(APIを立てる)
分担
DBから時系列データ : 赤司,
30日後までの予測 : 東別府,櫻井
公開(APIを立てる) : 阿部,藤田
出力について
工数と件数
## 新過去演について
* 過去問の答案は大問単位で提出
* 工数はtgtのもの(現状)
インターフェースの設計段階では問題ないかと思いますが、分析に入る際はこの変更点を留意する必要がありそうです。
生徒の演習方法自体が変更されるわけではないので、工数の対応付けのみ影響？
https://docs.google.com/spreadsheets/d/1Z_1dnZ1crngvyiqXgNKzSCALwMPy3hFK/edit#gid=2071327717
# 工数分析PJ 第2回mtg
## 開催情報
| 日付 | 5/2 |
| -------- | ---------------------------------- |
| 主催 | 藤田 |
| 開始時刻 |21:00 |
| 終了時刻 |22:30 |
| 場所 | Zoom |
| 参加人数 | 6名 |
| 参加者 | 藤田(数学)、赤司(化学)、田中(国語)<br>東別府(物理)、櫻井(物理)、阿部(物理)
## 議事録
今日の司会：藤田
今日の書記：東別府
### 前回の全体mtgを受けて
阿部さんからお願いします。
> 方向性として、予測精度を高めることを考えるよりも、まずは各大学・各科目・各年度の提出数などに簡単にアクセスできる体制を作ると他のpjとの連携ができそう??あとは、slackのbot整備や他のチームのようにapi作成、科目で使用するwebアプリなどの作成など、優先順位を決めると良さそう(中井さん)
(阿部) 中井さんから上記のような提案がありました。振り分け等の他PJでも工数予測データを活用していくことが予見されるため、予測精度を高めることよりも、まずは予測情報に簡単にアクセスできる仕組み(APIやslackbot, Webアプリ等)を作成するのがよいのではないかとのことです。自分としてもアルゴリズム自体は現状のものがいくつかあり、また後からの変更が可能なので、優先度としてはそちらの方が高くした方が良いかと思いました。分析に必要とされる学習は一カ月で完了できるものではないかと思うので、優先度を少し下げた上で並列して進めていけばよいかと思います。
→中井さんのアドバイスを受けて、フロー等に大きく影響が出てきそうです。この件について話し合えればと思います。（今後のスケジュールやアジェンダなどの再整理）
アクセスできる仕組みについて、現在あるもののコードが少し雑。それを参考にしながら綺麗に組み立て直した方が良いかも。
一定人数だけ割けば良くて、分担する方が良いのでは。
チーム分けについて
・コードのブラッシュアップ班
赤司さん、田中さん、阿部さん
・予測分析班
櫻井さん、東別府、阿部さん、赤司さん
分析に必要な知識を得るためのおすすめ図書
・櫻井さんおすすめの２冊。沖本本(阿部さん購入済み)よりは馬場本(難易度低め)の方が良いかも
馬場(2018)『時系列分析と状態空間モデルの基礎』
### スケジュール感
２ヶ月を目処にコードのブラッシュアップ。それに合わせ工数分析についての資料整備し、ブラッシュアップ班もスムーズに分析に進める様にしておく。
予測分析班
1週目:本を購入し1章を読む。
backlogは2週目以降取り掛かる。
ブラッシュアップ班
赤司さん中心にコード修正し
最後にアルゴリズム変更するイメージ
### 各科目からのヒアリングの結果
https://docs.google.com/spreadsheets/d/1lnmtxG6KbqCEdb_l0PgG6py5GnM05NVdOFZ5uW6led8/edit#gid=214112765
各科目の状況を見る限り
・物化以外は定数倍予測にとどまっている。そもそも予測を行わずグラフからトレンドを読み取るにとどまっている科目も多い。
・予測技術がないというよりはそもそも必要性があまり高くない（どの科目も工数に大きく余裕がある）ため、予測が盛んではない？
・物理と化学が工数分析的観点では十歩くらい先を行っている
### データベースpjから
データベースで用いるデータに関して、要件定義の際に必要になるためこちらのフォームに答えていただけると幸いです。よろしくお願いします。https://docs.google.com/forms/d/e/1FAIpQLSepaIo9s8o3bLjfw5g4CS1mLM2IZ4t-cwup4j1WfvvotlhtWg/viewform
とのことです。
# 工数分析PJ キックオフMTG
## 開催情報
| 日付 | 4/22 |
| -------- | ---------------------------------- |
| 主催 | 藤田 |
| 開始時刻 |23:00 |
| 終了時刻 |24:50 |
| 場所 | Zoom |
| 参加人数 | 6名 |
| 参加者 | 藤田(数学),阿部(物理),田中(国語)<br>森田(英語),櫻井(物理),東別府(物理)|
## 議事録
今日の司会：藤田
今日の書記：阿部
### 自己紹介
森田光紀 (英語)
田中紘一郎 (国語)
櫻井仁哉 (物理,科目チームでの工数分析担当)
赤司一真 (化学,科目チームでの工数分析担当)
阿部翔太 (物理)
藤田葵 (数学,PM)
東別府健 (物理)
### プロジェクト方針
あくまで藤田個人の考えですが、ボトムアップ型でこのプロジェクトを進めていきたいです。各人の開発経験やスキルも大きく違いますし、各科目で工数分析への考え方もかなり異なると思います。<br>各々の得意不得意も考慮しつつ、全員がコミットできるようなプロジェクトにしていきたいです。まずは積極的に意見を出していただき、活発な話し合いを目指していければと思います。
### 今後のスケジュールの確認（これから何をしていくか？）
①企画
(1)システム化構想
* 「どんな目的で」「どのような目標で」「どのようなスケジュールで」など、プロジェクトを進めていく上で当たり前のことを予め文書化しておく。（**プロジェクト憲章**と呼ばれる）
* 今日やります
(2)システム化計画
* その名の通り。主に今後の全体開発のスケジューリングをしていく予定です
* この段階で、他のPJと協力が必要になる（可能性がある）部分を洗い出す
②システム要件定義
* 各科目にヒアリングを行った上で、どのようなシステムを作成していくかを明文化
③システム方式設計
* システム内部のソフトウェアはどのように分割できるか？
④ソフトウェア要件定義
⑤ソフトウェア方式設計
⑥ソフトウェア詳細設計
* まだまだ先なので説明は割愛。詳しくは[こちら](https://n-contents.backlog.com/wiki/CT_48/%E3%83%9E%E3%83%8B%E3%83%A5%E3%82%A2%E3%83%AB%2FITPM%E5%90%91%E3%81%91%E5%85%B1%E9%80%9A%E8%B3%87%E6%96%99)を参照。
⑦プログラミング
⑧結合テスト
* その名の通り。
### アイデアブレスト
https://docs.google.com/document/d/1-siXI9TnwEwv5-O2n3hQDdiInKN2qTIjVSZ7HutzRIM/edit
### プロジェクト憲章
1. **プロジェクトの目的**
そもそもなんでこのプロジェクトやってるんだっけ？
・提出工数の裏のパターンを見つける
・提出工数を事前に予測することで、科目運営の崩壊を防ぐ
2. **プロジェクトの目標 (測定可能な成功条件)****
何がゴール？
（高い精度の工数分析）
・実際の提出工数と予測工数の誤差を最小化
・短期と長期で精度が異なるため,それぞれで違う目標を設定
・分析を科目横断的に配属に利用
3. **前提・制約条件**
・赤司さんが既に作成されているWebアプリを積極的に参考にしていく
http://3.142.118.214:8000/
・Webアプリをベースにアルゴリズムを追加し,予測の精度を高めていく
・非ITリーダーでも利用可能な状態にする
→能動的にデータを取る状態ではなく,自動的に工数が危険な日や大学等を自動で知らせるような仕組みが理想
・データの制約
→過年度の提出工数に加え,精度の高い予測には今年度の演習傾向を把握できるようなデータが必要
→2021年は水曜日前倒し・単じゃ返却日短縮が影響してきそう
4. **スケジュール**
（大鐘さん作成のスケジュールは前述。ここでは工数分析PJ独自のスケジューリングをしていく。）
* 第1繁忙期までには実際の運営で活用できるようにする
→今年のデータが色々と必要なため,早期作成は難しい？
→第一繫忙期前には定数倍予測よりも制度の高い予測が目標
・作成して終わりではなくその後モデルの評価と改善を行っていく
* 7月程度までに年度に依らない予測の大枠を作り,演習傾向や今年度特有のものを追加,改善
* opsttsやtgt等の利用していくデータの見方を勉強するmtgを最初に開催
* 各自がそれぞれモデルを構築
→直近,長期的なもの,試験種別など役割ごとに進めていく or 全体で一つの方針で行くか
→同じ目標に対して,それぞれがモデルを構築
→全体で比較してよりよりモデルを構築
具体的な日程
* データの見方を講習(櫻井さん,赤司さんが講師)
* 5月末程度まで,各自が統計処理や時系列処理等の前提知識を学習,学習成果を学習資料にまとめたり,mtgで発表する(輪講形式)
→(古典的手法)
http://elsur.jpn.org/202004MMM/chap5.pdf
https://www.amazon.co.jp/%E7%B5%8C%E6%B8%88%E3%83%BB%E3%83%95%E3%82%A1%E3%82%A4%E3%83%8A%E3%83%B3%E3%82%B9%E3%83%87%E3%83%BC%E3%82%BF%E3%81%AE%E8%A8%88%E9%87%8F%E6%99%82%E7%B3%BB%E5%88%97%E5%88%86%E6%9E%90-%E7%B5%B1%E8%A8%88%E3%83%A9%E3%82%A4%E3%83%96%E3%83%A9%E3%83%AA%E3%83%BC-%E6%B2%96%E6%9C%AC-%E7%AB%9C%E7%BE%A9/dp/4254127928
->機械学習(RNN, LSTM, kaggle)
->状態空間モデル
* モデル構築
5. **予算 (概算)**
0円
6. **リスク**
リスクを仮定し、軽減するための対策をあらかじめ立てておく（必ずしも解決策を立てる必要は無い）
例）・他プロジェクト間の遅延
* 期限が他のPJよりもやや早くなる（4.から）
* データが多すぎるとき、PyTorchを使うときは、サーバーの性能次第でメモリエラーになる可能性があるので対策が必要かも知れません(赤司)
7. **プロジェクトメンバーおよびプロジェクト・マネージャー**
PM：藤田葵
### その他
#### 工数分析とopstts_tgtの境界を決めておきたいです。(赤司)
（mtg出られなくてすみません。opstts_tgtとの調整は阿部さんよろしくおねがします)
* 必要な情報をopstts_tgt側で抜き出そうと思っているので、なんのデータが必要かを教えてください。(もしかしたら使うかも的なやつも一応入れといてください)
opstts_tgtにどんなデータがあるかはこちらを見てみてください
https://www.notion.so/pj-opstts_tgt-10f63bdd1daf48b9ab9b71db24f30c31#0f4b162b645d4de78768008972b286c0
* opstgtで必要なデータ
["ANSERSHEET_ID","SEITO_NO","KOZA_CODE","SHIKEN_NENDO","KAISU","JUKEN_KAMOKU_ID","CONTENT_RECEIVED_DATE"]
私大も数学科では必要
* tgtで必要なデータ
["ANSERSHEET_ID","SEITO_NO","CODE_NUM","DETAILS","TENSAKU_KAISU","CONTENT_RECEIVED_DATE"]
tgt1とtgt2を結合
* 時系列処理を施すのはどちらの管轄にするか
→工数分析管轄
* 漏らしているかも知れないので、他にも接点がないかの確認をお願いします。
#### 添削需要予測と配属バランスの最適値の算出について(阿部)
従来の科目単位での工数予測に加え、工数分析PJとして全科目的に可能工数予測と提出工数予測を横比較することで「各科目の配属バランスの最適値の算出」をしたいと考えています。昨年度の第一繁忙期の物理科と数学科のように、可能工数が多く余っている科目と可能工数が不足している科目を事前に把握することで、移籍や兼任を実施するかの意思決定に繋げ科目運営の崩壊を事前に防ぐことが目的です。
* 制約条件
基本添削料の違い等から各科目で一人当たりの添削者が裁ける工数が異なるため,「平均化した際の一人当たりが一日で裁く工数」のようなものが特徴量として必要
* 必要となるデータ
* 昨年度と今年度の可能工数登録データ
* 提出工数予測データ
例えばある科目について
* 一人当たりの一日の可能工数が2
* その日の提出予測工数が300
としたとき、安定した運営を行うためには提出工数の1.8倍程度の可能工数が必要とすると
* 必要となる可能工数→540
* 必要実働人員→270人
といったような形で算出するようなものを想定しています。
⇒提出工数予測をした上で,余裕があれば着手
⇒他の業務が重く,優先度は相対的には高くない。メインとなる業務が落ち着いてから考える。
### 今後について
* TODO
統計処理や時系列処理の学習資料作成
→ https://www.amazon.co.jp/%E7%B5%8C%E6%B8%88%E3%83%BB%E3%83%95%E3%82%A1%E3%82%A4%E3%83%8A%E3%83%B3%E3%82%B9%E3%83%87%E3%83%BC%E3%82%BF%E3%81%AE%E8%A8%88%E9%87%8F%E6%99%82%E7%B3%BB%E5%88%97%E5%88%86%E6%9E%90-%E7%B5%B1%E8%A8%88%E3%83%A9%E3%82%A4%E3%83%96%E3%83%A9%E3%83%AA%E3%83%BC-%E6%B2%96%E6%9C%AC-%E7%AB%9C%E7%BE%A9/dp/4254127928
上記の本の内容で,工数分析に必要になる知識をまとめる
→次回のmtgで担当決定。また,opsやtgt等のデータの見方を講習,櫻井さん等の各科目の工数分析の手法の解説
5月末程度前に上記の本は終了予定
mtgの周期
2週間に1回程度の頻度
### 関連するPJ
・opstts
・データベース
・slack
・振り分け
Sign in with Wallet
Connect another wallet