ID:67171さん

# 一言でいうと 介護事業所向けに提供している自社サービス（Aとします）のデータを使い、数理最適化によって訪問介護士のシフトを自動で作成する機能の開発・検証をしました。 詳細は社内テックブログにも書いているので、合わせて読んでいただけると嬉しいです。 [数理最適化によって訪問介護のシフトスケジューリングモデルを作ってみた話](https://tech.bm-sms.co.jp/entry/2023/03/28/120000 ) [【資料公開】日本OR学会 2023年秋季研究発表会での発表資料を公開します](https://tech.bm-sms.co.jp/entry/2023/10/05/140000) # 関係者 - データ活用チーム - 自分 - 自社サービスAのデータに詳しい方（データの仕様や構造などを教えていただきました） - 他部署 - 前職が介護事業所だった方（現場でのシフト作成について教えていただきました） # なぜやったのか 学生時代に専攻していた数理最適化を自社データに活用したいと考え、自由研究的に進めていました。 ※チーム内でもメンバーの自主的な研究や技術検証が推進されていました # やったこと - シフトスケジューリングに関する文献を調査し、必要なデータを整理しました - 自社サービスAで蓄積されたデータのうち、使えそうなデータがあるか調査し、SQLで抽出しました - 具体的には以下の2つのデータ（＋各種マスタデータ）を使用しました - ①利用者ごとのサービス提供予定 - ②介護士ごとの勤務可能日時 - 上記のデータを使い、Python-MIPによってシフトスケジューリングの数理最適化モデルを開発しました - 開発の中で気になることは、介護の現場に詳しい方に相談しました - 結果を整理し、資料を作成して部内外に共有しました - 自社サービスAには「実際にどのようなシフトが組まれたか」のデータもあるので、実際とモデルによる出力も比較しました # どうなったか - おおむね、実際よりも効率的に利用者宅を巡回するような結果が得られました - 考慮できていない観点があったので、改善の方針も立てられました - 一方で、使用したデータ②に以下のような問題があり、実際にサービスに組み込むのは難しそうなため、どのように活用するかを検討中です - ほぼ入力されていない - 入力されていても、不正確な可能性が高い - 社内テックブログで公開したら、数理最適化分野の有名な人に拡散されてそこそこ読まれたので、技術的な需要や注目度の高さを感じました

# 一言でいうと 介護職を中心とした求人広告サイトにおいて、求人の特徴を表す「無資格OK」「夜勤なしOK」など約100種類のタグを、求人内容から自動的に付与する仕組みを作成しました。 - 例）https://www.kaigojob.com/job-postings/294076 # 関係者 - データ活用チーム - 自分 - 上長 - 事業側担当者 - PdM（立ち上げ後に退職、後任不在） - 求人広告作成チームの責任者（ヒアリングに協力してもらいました） - マーケティングチームの責任者（ヒアリング、サイト組み込みに協力してもらいました） - 架電チームのメンバー（ヒアリング、タグと条件のリスト作成に協力してもらいました） - サイト開発チームのメンバー（タグの表示・検索機能をサイトに組み込んでもらいました） # なぜやったのか 自分の所属するデータ活用チームに、PdMから「求人が検索しやすくなるように、求人にタグを付けてほしい」と依頼がありました。 ※直後にそのPdMは退職し、誰にも引き継がれずにPdM不在となったため、主に自分と上長がこのプロジェクトを主導しました # やったこと 上長のリードのもと、自分が中心となって社内ヒアリングによる要件定義～設計～開発～テストを行いました。 - 「どんな求人にどんなタグがついていると嬉しいか？」のヒアリングを社内の複数部署に行い、「タグと条件のリスト」を作成してもらいました - 作成してもらったリストをもとに、主に正規表現で「求人にこの文言が含まれていたらこのタグを付ける」というバッチ処理を開発しました - バッチ処理を行う既存の社内フレームワークを使って実装しました - 簡単に言うと「所定のフォルダにSQLやPythonのファイルを置くと、ファイル名順に実行してくれる仕組み」です - コード量：SQLが約1500行、Pythonが約500行 - 別案として、タグごとに「この求人にこのタグが付くか？」の判別をする機械学習モデルを開発する方法も考えましたが、以下の理由で正規表現を採用しました - タグが100種類以上あるので、タグごとに判別モデルを開発するのは工数がかかる - ある求人にあるタグが付く（or付かない）理由が外部に説明できない（クレームがあったときに回答や修正がしにくい） - 事前に正規表現を試したらそこそこうまくいった - 毎朝処理を行い、その出力ファイルをサイト開発チームに取り込んでもらって、サイトでのタグ表示・検索ができるようになりました - 求人を掲載している法人から「この求人にこのタグは付けないで（or 付けて）」というクレームが来た際には、そのたびに条件修正などで対応しています # どうなったか 本来の目的だった「求人を検索しやすくしたい」が達成できただけでなく、事業の様々な施策で使われる重要なデータになりました - （この施策のみの効果とは言えないが）サイト内の求人検索回数が増え、検索→求人閲覧→応募 という経路の応募数も増えました - 今では様々な施策で使われる重要なデータになっています - 各タグが検索に使われる回数をダッシュボード化し、どのような求人の需要が多いかを可視化 - タグをもとに求人間の類似度を計算し、サイト内レコメンドに活用（プロジェクト2） - 求人の質の改善 - 「このタグが付いたら+○点」のように求人にスコアを付け、スコアが低い求人は書き方を見直す - 「無資格OK」タグが付いた求人特集、などのメルマガ配信 # 大変だったこと - 複数部署との調整、コミュニケーション - 関係者のほとんどが非技術者だったため、「この条件は技術的にできる/できない」などの説明を噛み砕いてする必要がありました - 事業側担当者が作った「タグと条件のリスト」の条件がかなり複雑で、ややこしい日本語を正規表現に直してテストするのは心身ともに疲弊しました - 途中で「担当者が書く条件を正規表現に変換するスクリプト」を書いて、かなり負担が軽減されました

# 一言でいうと 上記のプロジェクトで付与した求人へのタグをもとにレコメンドアルゴリズムを開発し、Webサイト内での求人レコメンドで活用しました。これによって、レコメンド枠の変更前後1ヶ月で応募数が1.5倍になりました。 - サイト内での求人レコメンド - タグをもとに求人間の類似度を計算し、閲覧や応募した求人に応じて求人をレコメンド - 例）この求人を見た方にはこの求人もおすすめです # 関係者 - データ活用チーム - 自分 - 上長 - 事業側担当者 - 求職者向けサイト改善の責任者、メンバー（サイト内のどこでレコメンドをするのかをすり合わせました） - サイト開発チームのメンバー（レコメンドAPIをサイトに組み込んでもらいました） # なぜやったのか 既存のレコメンド機能に以下のような課題があり、データ活用チームでレコメンド機能を継続的に改善したほうが良いと（上位レイヤーで）判断されたため。 - レコメンド機能をサイト開発チームが管理しており、「特定条件で抽出した求人をランダム順で表示する」など簡易的なものだった - 各レコメンド枠の応募数などが計測されておらず、改善が滞っていた # やったこと 上長のリードのもと、自分が中心となって要件定義～設計～バッチ処理・APIの開発～評価を行いました。 以下の2つの仕組みをそれぞれ開発しました。 - バッチ処理（SQL）：「ある求人に対する、類似求人リスト」のKey-ValueファイルをRedisに格納する - Redis格納のみ別チームの方が担当 - アルゴリズムは下記参照（※） - API（Python）：ある求人が与えられたとき、Redisを参照して類似求人リストを返す - 社内ライブラリ（AWS Lambda、API Gatewayのラッパー）を使って開発 ※アルゴリズム概要 - ある求人が与えられたとき、その求人と同じ市区町村・雇用形態・職種の求人のみを抽出する - 与えられた求人と、抽出された求人のタグに関してJaccard係数を計算し、求人の類似度とする - 類似度＝2つの求人で重複しているタグ数／2つの求人の少なくともどちらかに付与されているタグ数 - 他の指標（コサイン類似度など）も考えましたが、以下の理由でJaccard係数を採用しました - 他の指標とJaccard係数による結果があまり変わらなかった - Jaccard係数は他と比べると計算コストが小さく、SQLのみで計算できる - ある求人と、それに対する類似度トップ100求人をCSVファイルとして出力し、Redisに格納する # どうなったか レコメンド枠の変更前後1ヶ月で応募数が1.5倍になりました（見た目は同じで、アルゴリズムだけを変更）。 # 大変だったこと - 求職者向けサイト改善のメンバーとコミュニケーションが上手くとれず、責任者を経由したり図表を多用してやり取りしました - その方とのコミュニケーションにはいろんな方が苦労されてるようでした

# 一言でいうと 社内独自の地理データや、国が集計しているデータ（メッシュごとの小売販売額など）を使い、以下の2つのレコメンドアルゴリズムを開発しました。 - ①ショッピングセンターなどの商業施設に対して、その地域の特色に合ったブランドをレコメンドする - ②商業施設に出店したいブランドに対して、そのブランドの過去の出店情報などから商業施設をレコメンドする # 関係者 - 自分 - 副業先の業務担当者（CTO兼COO） - 副業先は大学3年生のときにインターンしていたベンチャー企業で、そのときにお世話になった方に誘われて業務委託として参加しました # プロジェクトの目的 自社サービスとして商業施設とブランドのマッチングプラットフォームを運営しており、それに対するレコメンド機能改善のPoCとして行いました。 # やったこと ①②ともに、以下のような流れで進んでいました。 1. 担当者）商業施設やブランドとPoCの契約をする - その際に「こういうブランドに来てほしい」「過去にこの施設に出店したことがあるので、そこと似た特色のある地域に出店したい」などをヒアリングする 1. 担当者と自分）ヒアリングした条件をもとに、どのようなレコメンドが望ましいかを議論し、使うデータや手法などをすり合わせる 1. 自分）すり合わせた内容をもとにアルゴリズムを実装し、結果を整理する 1. 担当者と自分）得られた結果を見ながら、改善の方針を決める（以下繰り返し） ※詳細なアルゴリズムは煩雑なため省略しますが、以下のような流れになっています - 各商業施設の1km圏内で、年代構成比や小売販売額などを集計し、商業施設の特徴量ベクトルを作る - 各ブランドの各店舗の1km圏内で、年代構成比や小売販売額などを集計し、ブランドの特徴量ベクトルを作る - 正確には、ブランドごとに店舗をいくつかのカテゴリ（都心部、都市近郊、郊外など）に分け、カテゴリごとに特徴量ベクトルを作った - 商業施設とブランドでベクトルのコサイン類似度を計算し、それを相性度とする - 商業施設[ブランド]に対して、相性度が高いブランド[商業施設]をリスト化する # どうなったか 商業施設・ブランドともに約10企業におすすめリストを持っていった結果、おおむね好感触でした（と聞いています）。 担当者も直後に退職してしまったため、実際にマッチングが行われたのかは不明で、おそらくレコメンド機能も改善されずじまいだと思われます。 # 大変だったこと 平均して月に約40時間（多い月は約60時間）稼働していたため、本業との両立に苦労しました。 本業では今まで以上に効率的に仕事を終わらせることを意識し、月の残業時間をほぼゼロにしました。 本業と副業を合わせると月の仕事時間は増えましたが、土日はなるべく休むようにして心身の健康を維持しました。

# 一言でいうと お気に入りの芸人を登録すると、その芸人さんの新着ライブを毎日LINEで教えてくれるシステムを開発しました（現在Webサービス化を検討中）。 詳細はこちらを参照ください。 https://qiita.com/oddgai/items/b37b98b6721c3a375fac # 関係者 - 自分のみ # なぜやったのか 好きな芸人さんのライブ情報を低コストで漏らさずチェックしたいためです。 もともとお笑いが好きなのと、在宅ワークで時間に余裕ができたので、1,2週間に1回ほどのペースで配信ライブを観るようになりました。 一方で、自分の好きな芸人の出演ライブを漏らさず見つける手段は「定期的にサイトで検索する」「Twitterを見張る」くらいしかなく、よく使うサイトに通知機能もありません。 人力でのサイト巡回はコストが高いので、機械にやってもらおうと思って作りました。 # やったこと 以下の2つのシステムをAWS Lightsail（VPS）上に構築しました。 - ライブ情報サイトのクローラー（毎朝実行） - Scrapyで各チケット販売サイトをクロールしてS3に保存 - 新着ライブを検知して通知するBot（毎朝実行） - ライブ情報を読み込んで新着ライブを検知し、LINE Messaging APIで新着ライブ情報を個人アカウントに送信 # 技術選定の理由 - AWS Lightsail - 安いVPSであればどこでも良かったが、ストレージにS3を使う予定だったのでAWSのVPSにしました - Scrapy（Python） - 最も慣れている言語で、Scrapyも業務で使ったことがあったため - LINE Messaging API（主にSlackとの比較という観点で） - （今は自分だけが使っているサービスだが）公開することも考えると、多くの人が使っているLINEが望ましかったため - メッセージの見た目も自由に決められるため # どうなったか 2023年1月現在、2年近く大きなエラーもなく毎朝動いており、非常に重宝しています。 そろそろ勉強も兼ねてWebサービス化もしたいです（Webでお気に入り芸人を登録するとLINEで通知してくれるシステム）。 # 大変だったこと やり方に自由度があり過ぎる中で、技術選定やシステムの設計をするのが楽しくもあり大変でした。