###### tags: `HOKUTO`

HOKUTO求人サイト設計
===

## 01/30MTG
- 進捗状況キャッチアップ
- [HOKUTOキャリア プロジェクト管理シート](https://docs.google.com/spreadsheets/d/1t5sneI-kZhq8oM3Duml6sQex5Ufo0aH94uD2_pbJw4g/edit#gid=118911535)
-
- 確認事項
- サイトの速度が遅い問題を解決する
- 中身が空でも遅い問題は解決できなかった
- 下記のどの問題なのかの切り分けを行う

## 01/23MTG
- 進捗状況キャッチアップ
- [HOKUTOキャリア プロジェクト管理シート](https://docs.google.com/spreadsheets/d/1t5sneI-kZhq8oM3Duml6sQex5Ufo0aH94uD2_pbJw4g/edit#gid=118911535)
- 来週までに荒々で新規追加分の工数を見積もっていただく
- 確認事項
- サイトの速度が遅い問題を解決する
- 中身が空でも遅い問題は解決できなかった
- 下記のどの問題なのかの切り分けを行う
- ホスティングサービスの問題なのか（heroku等で試す）
- dockerの問題なのか
- nextの設定なのか
- コードの問題なのか（これはなさそう）
- → nishitaniさんが調査
- ダイナミックルーティング
- 最初に各画面分のhtmlを返しているわけではないはず
- rootingのマッピングはクライアント側で持っているはずだけど、htmlまでは作成されないはず
- 会員登録の仕組み
- firebaseAuthを使って医師に関してもエージェントに関しても登録する予定
- Authの作成をトリガーにしてFunctionsを走らせて会員作成をするようにする？
- データが不足してそうなので会員作成時に作成した方が良いのでは
- ただ、この方針だとデータの整合性に懸念があるため、Authをトリガーに会員情報を作成し、アップデートする方が良いのではないか？
- 上記方針だと重そうな気もするので、そこはケアした方が良い
- 会員登録画面に関して
- こちら側でAuthも含めエージェントを作成しちゃって、パスワード再設定メールを送ってログインしてもらうのが良さそう

## 01/16MTG
- 遠藤さんから共有
- [ロードマップ](https://docs.google.com/spreadsheets/d/1t5sneI-kZhq8oM3Duml6sQex5Ufo0aH94uD2_pbJw4g/edit#gid=746115791)
- 5月以降に引き続きお二人に稼働していただけそうか？
- 異常に時間拘束の大きい科になっちゃったら2週間くらい稼働できない、みたいなことがあるかも
- ER図
- jobs のステータスは何があるのか？
- 公開、非公開、マッチ済み、削除
- 公開のみ表示
- お問い合わせが会った求人だけは削除した後でも見れるようにしたい
- CSV のインポートに関して
- インポート時のエラーが必要になりそう
- CSV インポートがやったことがないので詰まる可能性がある
- 進捗状況キャッチアップ
- [タスクリスト](https://docs.google.com/spreadsheets/d/1l5Bndj2CE9ccw2gat8qTVzjmw3I22c5tCbPbjF-SRmk/edit#gid=0)
- [HOKUTOキャリア プロジェクト管理シート](https://docs.google.com/spreadsheets/d/1t5sneI-kZhq8oM3Duml6sQex5Ufo0aH94uD2_pbJw4g/edit#gid=118911535)
- こちらに移行していきたい
- 来週までに荒々で新規追加分の工数を見積もっていただく
- 確認事項
- 各ページの情報の取得の仕方
- 基本的に Firestore から都度取得する（SEO で直接ランディングすることが多いため）
- サイトのスピードが遅い問題
- まっさらなページでの速度はどれくらいの速度か？を確認してどこがボトルネックになっているのかを特定する
- GCP のスペックを上げても遅かった
- 技術的に困っていることはあるか？
- 今週はない

## 01/14MTG

- 求人サイトの管理画面の説明
- 病院名は非表示にする。
- デザインは作ってしまう
- role
- 会社単位
- 自社の求人を管理できる
- 求人に対して、担当者が紐づく
- hokutoアカウント
- admin
- agent
- agent内admin
- 担当者
- CSVアップロードで病院との紐付けは要注意

- 情報共有は、スプレッドシートで保存

- コンサルタントの登録は、手動でやる予定
- 管理画面作るほどではない

- パスワードは、ユーザーが管理できるようにする
- できるだけ、工数かからない形でやる

- 開発
- material uiを使わずに、新井さんにデザインを作ってもらって、next.jsでフロント同様に作る
- mapをセカンドリリースにしたほうが良いかも

- 医療機関非表示の場合は、画像はコンサルタントが上に来る（？）

- デザイン
- 管理画面のデザインは2月いっぱい

## 01/09MTG
- 進捗状況キャッチアップ
- [タスクリスト](https://docs.google.com/spreadsheets/d/1l5Bndj2CE9ccw2gat8qTVzjmw3I22c5tCbPbjF-SRmk/edit#gid=0)
- 予定通りの進捗
- 次週見直しする
- 確認事項
- 非常勤アルバイトの曜日・時間帯の仕様はどんな感じか？
- セレクトボックスで良い
- ★ https://career.m3.com/home/parttime?pf=top_tab&tab_from=fulltime
- https://www.recruit-dc.co.jp/hijokin/search/
- 病院・求人の検索
- 病院の情報も重複して求人に持たせる
- 病院の情報更新時には、求人情報も同時に更新する
-

## 12/19MTG
- 進捗状況キャッチアップ
- [タスクリスト](https://docs.google.com/spreadsheets/d/1l5Bndj2CE9ccw2gat8qTVzjmw3I22c5tCbPbjF-SRmk/edit#gid=0)
- 順調
- 議事録
- 懸念
- ジョブと病院の項目が確定しないとDBと各ページのUIがFIXできない
- → 1/2までに決める yamamo
- deployできるのかという懸念は潰せた
- CIに関してはまだ不確定要素がある
- firestoreとの連携もできた

## 12/12MTG
- 進捗状況キャッチアップ
- [タスクリスト](https://docs.google.com/spreadsheets/d/1l5Bndj2CE9ccw2gat8qTVzjmw3I22c5tCbPbjF-SRmk/edit#gid=0)
- バッファを見て3月末〜4月上旬
- ただ、デザインも完成しておらず、firebase周りの実装も進めていないので不確実性が高い状況
- また、deploy周りに懸念あるため、早めにdeployまでやる
- 議事録
- Cloud Runいけそうだが、いけなそうだったらGKE等も検討
- PagingのライブラリーはReact Paginateで良さそうだが、もう少し検討
- 試す時には3つくらい選択肢を出して1つ進める
- 検討時にnishitaniさんに相談

## 12/06MTG
- 進捗状況キャッチアップ
- トップページのcssは完成
- 議事録
- デザインスケジュール
- 12/9 スマホ1ページ
- 12/16 PC残りページ
- 12月いっぱいでスマホ残りページ
- [タスクリスト](https://docs.google.com/spreadsheets/d/1l5Bndj2CE9ccw2gat8qTVzjmw3I22c5tCbPbjF-SRmk/edit#gid=0) 作りました
- 一旦こちらにタスクのリストアップをしていただければと
- リリースまでの全貌の把握と不確実性の高いところの洗い出しが目的
- 12月中旬くらいにテストサイト上げて触れると理想
- 来週再来週くらいにdeployまでやっていただく
- 最初からCloud Runでやる
- 次週以降土曜日19時〜定例化する

## 11/28MTG
- バックエンド
- firebase
- クライアントからDBに対して直接クエリ叩ける

- 作業手順
1. 環境構築したものをgithubにpush
- 西谷の環境構築したソースをpushする
2. firebase consoleの初期設定
- auth
- firestore
- 各コレクションの作成
- functions
- storage
4. next.jsにfirebaseを導入
- ライブラリを入れる
5. 全画面のページ遷移を作る
- タイトルだけで良いくらい
- 1人
6. デザイン反映
- 1人
7. ロジック作成
- DBに初期データを入れる
- まずは手動
- 1人
- 二手に分かれそうなタイミングで管理画面作り始めて良さそう
- ただ、管理画面の優先度は低い
- モデル(DB周り)
- 基本はstatic generationで作成
- ビジネスロジック
- cloud functions for firebase
- 何が必要か整理
- ほぼいらないはず
- バックアップは必要
- 優先度低い
- algoliaにインデックスを張る
- firestoreが更新されたら、algoliaに同期する

8. デプロイ
- cloud runが第一候補
- dockerまるまるいける
- GAEが第2候補
- dockerじゃない
- 1人

## 方針
- contentfulの使い方
- https://satoruakiyama.com/blog/building-blog-with-nextjs-and-contentful-ja
- https://qiita.com/syumatsuyoho/items/bf34baaa4c42ed382975
- https://engineer.crowdworks.jp/entry/2020/04/10/174736

- algolia
- hospitals
- recruitment_agencies
- regular_jobs
- part_time_jobs

- ログイン機能
- 最初はいらない
- お気に入り
SEOにとっては関係ない
最初はいらない
- 履歴は最初はいらない

- DB
- 後でIDaaSのような、グローバルIDサービスを作ったほうが良さそう
- まずはHOKUTOアプリとは別のDBで作る
- IDaaSでできなければ、HOKUTOアプリへの移行も可能だが、できればやりたくない
- DB設計に関しては、まだ途中だが大枠のイメージを記載したので参考にしてください。

- できるだけハードコーディングせずに、DBにデータをもたせる
- バナー部分や、静的ページも含めて。
- 変更する時にDB or 管理画面で変更できるので楽（ソースコードを変更しなくて良い）
- 拡張・保守しやすくなる
- 半年以上変更しない情報はソースコードに書いても良いイメージ

## 画面と機能
- 01 TOP画面
- 常勤・非常勤検索
- 常勤はregular_jobsコレクショングループの検索
- 非常勤はpart_time_jobsコレクショングループの検索
- 転職・アルバイトのご相談はこちら
1. LINE@へ飛ばすリンク
2. アプリの告知
- 1-3個の範囲でバナー設置
- 期間で変更するためにDBで管理必要
- 後から？
- スマホのデザインも合わせられるならOK
- 新着求人
- ロジックは？
- 新しいものから5件検索して表示
- おすすめ求人
- ロジックは？
- カテゴリ
- クリニック
- 女性医師
- ...
- 求人にcategoryフィールドがあるので、そこで振り分け
- is_recommended, 年収順、都心(駅から近い)、limit: 3, のように絞り込む。あいうえお順。なければ、残りを埋めるために新着のものを出す
- google analyticsでクリック数カウントする
- これを元にどんなロジックにするか等を改善する
- ユーザーのエリアに合わせる重要かも？
- GPS位置情報を取得必要
- SUUMOがこの作り方をしている
- googleの検索上で場所を出し分けている

- 求人を探す（病院だけでなく、案件ごとに科目・エリア・施設形態情報をもたせるのが良さそう）
- 科目から
- エリアから
- 条件から
- 施設形態から
- 転職お役立ちコンテンツ
- contentful
- 求人紹介企業
- recruitment_agencies
- どういう順番で出す？
- m3の場合は、求人を更新したエージェントが左上に出てくる
- 固定でも良い
- orderフィールドが必要
- それでsortする
- HOKUTOキャリアについての説明エリア
- 固定テキスト？
- 利用規約
- contentful
- プライバシーポリシー
- contentful
- HOKUTOレジデントのリンク
[ホクトレジデント](https://www.hokto.jp/)

- HOKUTOアプリのリンク
[HOKUTOアプリ/初期研修の口コミ・評判｜ホクトレジデント](https://www.hokto.jp/lp)

- 03 検索画面
- 条件入力フィールド
- 募集科目
- 勤務地
- 年収
- 特徴
- 施設形態
- このエリアを地図で見る
- ニーズは、自分の家にpinを立てて、病院までの通勤距離を知りたい
- 自分の勤務している病院からアルバイトする病院への距離も出したい
- ボタン押したら、「あなたの位置情報を取得してよいですか？」->はい
- 地図にpinタグされているイメージ
- これは以下のライブラリでうまく表示する必要ありそう
- https://github.com/google-map-react/google-map-react
1. 通勤時間はAPIで実装する
- 通勤時間のAPIがあるかどうか？
- navitime api, 乗換案内API、駅すぱあと
- 表示速度がどのくらい遅くなるか確認
- 2秒以内じゃないと厳しい
- 通勤時間出すのは、1対1の場合じゃないと重くなるはず
2. 通勤時間はgoogle mapアプリで表示
- 住所を別途入力する場所があり、通勤時間を調べるボタンが1つ1つ突いている
- 押すと、google mapに飛ぶ
- 離脱になるので、めちゃめちゃ良くない
- noindex, nofollowにするか、botで辿れないようにする必要あり
- 通勤時間出せる

- 求人検索結果一覧
- sort
- 新着順
- 給与
- エージェントの情報は表示しなくて良い
- 詳細を見る
- 04 求人詳細ページへリンク
- 無料で問い合わせる
- どこに飛ばす？
- 申し込みformに飛ばす

- 04 求人詳細ページ
- 表示する求人情報
- 転職エージェントが登録した案件の中から1番質の高いもの
- 必須・尚可の点数分けを全部リストアップしておく必要がある
- 遠藤さんと一緒に話す
- どんなロジック？
- たくさん入力
- 全項目のうち、入力した項目数が多い求人情報
- 求人枠を運営が作るのではなく、名寄せで同じ求人だと認識する必要がある
- 名寄せのアルゴリズムが必要
- 病院名、募集科目、常勤・非常勤、（非常勤の場合は曜日）
- 無料で問い合わせる
- 申し込みページに飛ばす
- この案件を取り扱うその他のコンサルタント
- 同じ案件ドキュメントを取り扱うecruitment_agenciesドキュメント
- どうやって案件の一致を見る？
- 名寄せのアルゴリズムが必要
- 病院名、募集科目、常勤・非常勤、（非常勤の場合は曜
- 同じエリアの他の求人を探す
- どんなロジック？
1. 非常勤の場合は曜日
- must
2. 募集科目
- must
3. 都道府県、位置情報（GPSまたは市区町村のテキスト）
- must
4. 給与条件
- 他の条件必要？
- この病院のその他の求人
- 同じhospitalドキュメント配下のregular_jobsサブコレクション内のドキュメントを表示

- 05 転職事例
- contentful

- 転職事例詳細
- contentful

- 06 病院一覧
- hospitalsコレクション
- 都道府県から探す

- 病院詳細
- hospitalドキュメント
- この病院の医師求人情報
- 配下のサブコレクション
- 同じエリアのその他の病院・クリニック
- 都道府県から検索？
- 同じ市区町村。ない場合は都道府県
- 10件表示。とりあえず、順番はあいうえお順でも良い

## DB設計（firestore）

- users/{user_id}

`フロント画面の会員`（会員登録機能がある場合）

uid

希望勤務形態

希望勤務地（都道府県）

希望科目

名前

ふりがな

生年月日

性別

メール

電話番号

住所

郵便番号

都道府県

市区町村

番地/建物名

ご希望条件・お問い合わせ

メール受信設定

- hospitals/{hospital_id}

lat 住所情報から変換

lon 住所情報から変換

name 病院名

- hospitals/{hospital_id}/regular_jobs/{regular_job_id}（collection group）
画像
- image_paths: array

`勤務地`

交通 transportation: string

自動車通勤 allows_car_commute: boolean

通勤交通費 transportation_fare: string

業務内容 work_content: string

募集科目 subject: string

歓迎される科目経験 welcome_experience: string

取得できる資格 gettable_qualification: string

勤務条件 condition: string

週勤務日数 work_days: string

勤務時間 work_time: string

早番 is_early_shift: boolean

遅番 is_late_shift: boolean

給与諸手当 what is this?

給与 salary: integer

昇給 promotion: string

賞与 bonus: integer

退職金並びに支給条件 retirement_allowance: string

福利厚生 benefits

保険 insurance

休日 number_of_holidays: integer

有給休暇 number_of_paid_holidays: integer

休暇 number_of_vacation: integer

定年 retirement_age: integer

施設情報 general_information: string

施設種別 hospital_type: string

病床数 number_of_sickbeds: integer

救急指定 first_aid: integer(0, 1, 2, 3)

学会認定状況 certified: boolean

- hospitals/{hospital_id}/part_time_jobs/{part_time_job_id}（collection group）

勤務地 location

交通 transportation

通勤交通費

勤務条件 transportation_fare: string

勤務日 work_day: string

勤務時間 work_time: string

休憩時間 rest: string

給与・諸手当

給与 salary: integer

業務内容 work_content: string

募集科目 subject: string

必要な経験・スキル skill: string

カルテ carte: string

施設情報 general_information: string

施設種別 hospital_type: string

病床数 number_of_sickbeds: integer

救急指定 first_aid: integer(0, 1, 2, 3)

学会認定状況 certified: boolean

- hospitals/{hospital_id}/users/{user_id}

- recruitment_agencies/{recruitment_agent_id}

- recruitment_agencies/{recruitment_agent_id}/regular_jobs/{regular_job_id}（collection group）

hostpitalsと同様

- recruitment_agencies/{recruitment_agent_id}/part_tIme_jobs/{part_time_job_id}（collection group）

hostpitalsと同様

- recruitment_agencies/{recruitment_agent_id}/users/{user_id}

- recommend_job_categories
- clinic ドキュメント
- jobsサブコレクション
- 地域医療 ドキュメント
- jobsサブコレクション
- 産業医 ドキュメント
- jobsサブコレクション
- 美容 ドキュメント
- jobsサブコレクション
- 女性医師 ドキュメント
- jobsサブコレクション
- 病院グループ ドキュメント
- jobsサブコレクション
- 当直なし ドキュメント
- jobsサブコレクション

- application/{application_id}

id

userRef

recruiterRef

hospitalか、recruitment_agentのdocument reference

- app_settings/{app_setting_id}

is_mentenance_mode: boolean

- admin_users/{admin_user_id}

`HOKUTO管理画面のユーザー`

uid

name

role

- roles

id

name

display_name

- notifications/{notification_id}

これはいらないかも？

- sitemaps/{sitemap_id}

サイトマップのurlをDBに入れておくと良さそう

id

url

order

## 実装の流れ

1. DB構築
- firestore
- algoliaにindex張る
- hospitals
- recruitment_agencies
- regular_jobs
- part_tIme_jobs
- セキュリティルール作成
- マスターデータ保存
2. フロント画面開発
1. デザインを反映
- figma （→ zeplin） → next.jsに反映
2. ロジック実装
3. API開発
- cloud functions
3. HOKUTO管理画面開発
1. 画面実装
- material ui
2. ロジック実装

admin sdkを利用

ユーザーはadmin_usersコレクションに保存

3. API開発
- cloud functions
4. 転職エージェント・病院管理画面開発
1. 画面実装
- material ui
2. ロジック実装

admin sdkは利用しない

3. API開発
- cloud functions

## スケジュール

医学生エンジニア2人の稼働予定日数

- 11月
- 11/21くらいから本格的にスタート
- 週3くらい
- 12月はずっと空いている
- それぞれ40時間
- 12月にフロント側の開発ざっくり終わらせる
- 1,2,3はポリクリが1月の途中から始まる
- 土日はまるっと
- それぞれ、週で30時間
- 1月に管理画面開発ざっくり終わらせる
- 2月にフロント、管理画面の残りの修正終わらせる

- リリース目標は3月か4月

## 宿題
- githubプロジェクト作成
- firebaseプロジェクト作成
- algoliaプロジェクト作成
- GAEプロジェクト作成