バイト先のシフト作成業務を効率化したい話～前編～
はじめに
皆さんこんにちは！ayaponzuです！
本記事は大阪ハイテクノロジー専門学校のロボット学科が作るアドベントカレンダーの21日目の記事です。ほかの記事もよければご覧ください。
現在、私はスーパーでアルバイトをしています。（現在3年目）
半月の自由シフト制なので半月ごとに店長がシフト作成しなければならないのですが、毎回、店長が「あ～またつくらないと」と言っているのをずっと見てきました。
そこで私は IT の力を使って効率化できないかなと考えました。
今回考慮するのは正社員以外の従業員のシフトとします。
(正社員はほぼ曜日で決まっているためそんなに悩まないから。)
シフト作成の流れと考慮すべきポイント
現在のシフト作成の流れ
例：12月後半（12月16日~31日）のシフトを作る場合
- 12月10日までに従業員にシフト希望を出してもらう（紙媒体）。
- Excelにシフト希望を転記する（手入力）。
- 時間帯やスキルでの上限・下限人数を満たすように調整する。
- 印刷する（12月15日までには完成させる）。
シフト作成における考慮すべきポイント
1. 最大人数・最少人数について
- 時間帯ごとに人数の上限・下限を考慮します。
- 基本の時間帯区分：
朝（9:00~14:00） / 昼（14:00~17:00） / 夜（17:00~20:00）
| 平日 | 朝：最少5人 / 最大7人 昼：最少5人 / 最大8人 夜：最少3人 / 最大5人 |
|---|---|
| 土日祝 | 朝：最少6人 / 最大8人 昼：最少6人 / 最大10人 夜：最少4人 / 最大6人 |
2. レジ担当の割り振り
- 基本の交代時間：朝（9:00~14:00） / 昼（14:00~17:00） / 夜（17:00~20:00）
-
レジ数：4つ
- 1レジ：土日祝のみ
- 2・3レジ：常時稼働
- 1・4レジ：混雑時のみ（ヘルプ）
| 平日 | 朝：3人 昼：3人 夜：3人 |
|---|---|
| 土日祝 | 朝：4人 昼：4人 夜：4人 |
3. スキルについて
- 品出し：研修中を除き、全員対応可能。
- レジ：レジスキルがある人の中から担当を選定。
- 冷蔵作業：夜の時間帯には必ず1人配置（1レジ・4レジの人が兼任可能）。
4. 休憩時間のルール
| 勤務時間 | 休憩時間 |
|---|---|
| 4時間以下 | 休憩なし |
| 5時間以上6時間未満 | 15分 |
| 6時間以上7時間未満 | 30分 |
| 7時間以上 | 45分 |
5. 連続勤務の制限
- 連勤は最大3日までが理想。（店長の方針）
できれば考慮しておきたいこと
1. 休憩回しの自動配置
- レジ担当者が休憩に行く際に、品出し担当者を自動で配置。
- 例：休憩に行った時間帯に空いたレジを埋めるよう調整。
柔軟な対応の方針
- シフト希望がそもそも必要人数に足りていない場合は、シフト希望を優先する。
- 相談なしにシフトを勝手に入れることは避ける。（当たり前）
- 必要人数が不足している場合、アプリでは「警告を出す」機能を実装予定。
どうやって作っていくか（技術選定）
これは長期インターンに行かせていただいた際に、担当の方に一緒に考えていただきました。（感謝です。）
Webアプリかネイティブアプリか
アプリケーションというとブラウザ上で動くWebアプリとインストールしてローカルで動くネイティブアプリがあります。
今回はWebアプリにしました。
シフト生成アプリを開発する際に、Webアプリを選んだ理由は以下の４つです。
1. どこからでもアクセスできる
Webアプリの最大の利点は、インターネットさえあれば、どのデバイスからでもアクセスできることです。これによって、スタッフが自宅やスマートフォンからシフト希望を簡単に登録できたり、管理者が外出先からでもシフトを確認したり調整したりできるので、すごく便利だなと感じました。
2. シフト希望のオンライン登録
従来の方法（紙やExcelでのシフト提出）だと、スタッフがバイト先に来て希望を出す必要がありましたが、Webアプリなら24時間いつでもどこでもシフト希望を提出できます。さらに、リアルタイムで希望を登録できるので、転記ミスなどの人的ミスも防げ、管理者の手間も大幅に削減できます。
3. インストール不要で使いやすい
Webアプリは、ユーザーが特別なソフトをインストールする必要がありません。ブラウザがあればすぐに使えるので、スタッフ全員が手軽にアクセスできます。しかも、アプリのアップデートもサーバー側で一元的に行えるので、スタッフは常に最新機能を使うことができます。
4. 複数ユーザーが同時に利用可能
Webアプリでは、複数のスタッフが同時に希望を登録したり、管理者がシフトを調整できるため、チーム全体でリアルタイムに利用可能です。みんなが同時にアクセスしても問題なく使えるのは大きなポイントです。
Webアプリの課題（デメリット）
1. インターネット接続が必要
Webアプリは、インターネット接続が必須です。もしインターネットが利用できない環境だと動作しません。
2. セキュリティ対策が必須
Webアプリでは、シフトデータやスタッフの個人情報をサーバーに保存するため、セキュリティ対策が必要です。暗号化や認証システムを導入すればリスクを軽減できますが、セキュリティ面に関する知識がないと正直不安です。
3. 運用コストが発生する
サーバーを運営するためには、サーバー費用やドメイン費用が定期的に発生します。さらに、システムに障害が発生した時の対応なども考慮しないといけません。
4. 動作速度の制限
通信環境やサーバーの負荷によっては、ローカルアプリに比べて動作が遅くなる可能性もあります。データ量が増えてきたときにどうなるかはちょっと心配です。
Webアプリとネイティブアプリで悩んだポイント
実は、最初はネイティブアプリにする案もありました。理由は単純で、「セキュリティ面もあまり考慮しなくていいし、インターネットがなくても使える」という点が魅力的だったからです。
しかし、ローカルアプリにはいくつかの課題がありました。
ネイティブアプリの課題
-
デバイスごとにインストールが必要
スタッフ全員のデバイスにアプリをインストールするのは手間がかかりますし、アップデートのたびにまた全員に対応してもらう必要があるのが大変そうでした。 -
データの共有が難しい
シフト希望や生成結果を共有するには、ファイルのやり取りが必要になりそうで、リアルタイム性が失われる点が気になりました。
最終的には、「どこからでもアクセスできて、スタッフ全員が簡単に使える」というWebアプリの利便性が勝ち、こちらを選ぶことにしました。やっぱり、シフト希望をオンラインで簡単に登録できるのは大きなメリットですよね！
フレームワークを使うことに
Webアプリのフレームワークを使ったらいいよ！と担当の方に教えてもらったので使うことにしました。
そもそもフレームワークが何かわからない人もいると思うのでライブラリとの違いも含めて解説してみたいと思います。
そもそもフレームワークとは？
ex) ラーメンを作るとき
麺を作りたい職人がいるとします。
麺を作るには小麦粉、水などをまぜてこねて切らないとだめですよね。
でも、一から作るのはすごく大変ですよね。
そこで、中華というライブラリの中華麺をもらってくると、お湯沸かして麺ゆでるだけでいけます。これがライブラリです。
Pythonで有名なものはnumpy、matplotribとかです。
これに対して、
フレームワークはこのようになっています。
器、麺、スープ、具材を選ぶと勝手にラーメンができます。
必要なものを追加していくことで、大きなシステムを開発できます。
セキュリティ面だとか、連携とか勝手にやってくれるのですごい便利です。
簡単に言うとこれがフレームワークです。
今回選択したフレームワーク
今回はPythonのWebアプリケーションフレームワークの中からDjangoを選びました。その理由は以下の通りです。
-
Pythonに慣れていたから
専門学校でずっとPythonを学んでおり、一番慣れている言語だったため、Djangoを選ぶことで学習コストを抑えられると考えました。 -
セキュリティ機能が優れているから
Djangoにはユーザー認証や管理画面、CSRF対策といったセキュリティ機能が標準で備わっており、これを活用することで安全で信頼性の高いアプリを効率的に構築できるからです。 -
フルスタックフレームワークであるから
Djangoはフロントエンド、バックエンド、データベース操作を一貫してサポートしているため、Webアプリ開発全体の知識を幅広く学ぶことができます。この点は、今後の成長を見据えて非常に重要でした。 -
複雑なシステムに適しているから
シフト生成アプリのように多機能で管理が複雑なシステムには、Djangoのようにあらかじめ多くの機能が揃ったフレームワークが適していると判断しました。
検討したほかのフレームワーク
Djangoと同じくPythonベースのフレームワークとしてFlaskがあります。それぞれの特徴を比較してみました。
共通点
-
Pythonベース
どちらもPythonをベースにしているため、Pythonの知識がそのまま活用できる。 -
Webアプリケーション向け
HTTPリクエストやルーティング、テンプレートエンジンなど、Webアプリ開発に必要な機能を備えている。 -
オープンソース
無料で利用でき、コミュニティも活発で情報が多い。
相違点
| 項目 | Django | Flask |
|---|---|---|
| 目的 | 大規模で複雑なアプリ向け | 小規模でシンプルなアプリ向け |
| 設計思想 | 標準機能が充実 | 標準機能は最小限で必要な機能だけ追加 |
| 機能の充実度 | フルスタックで認証や管理画面など標準装備 | 必要な機能をプラグインで追加 |
| 柔軟性 | 設定や構成に制約がある | 開発者が自由に設計可能 |
| 学習コスト | やや高い | 比較的低い |
例えるなら…
-
Django：オールインワンのツールボックス
必要な道具が最初から揃っており、大規模で複雑なプロジェクトに適している。 -
Flask：必要な道具だけを自由に選んで使えるキット
自由度が高いため、シンプルで小規模なプロジェクトやプロトタイプに向いている。
FlaskではなくDjangoを選んだ理由
- シフト生成アプリは多機能で複雑な構成が求められるため、Djangoのように標準で多くの機能を備えたフルスタックフレームワークの方が適していました。
- また、Djangoを選ぶことで、フロントエンドからバックエンドまでを一貫して学ぶことができ、Web開発全般のスキルを効率的に向上させられると考えました。
こんな感じで、開発の効率性と学習効果の高さを重視してDjangoを選びました。
ちなみに現在は、、、
どこまで開発が進んでいるかというと、
- ユーザーのログイン機能
- シフト希望登録
- 店長がシフトを手動で調整する機能
は実装済みです。
チョット見せます。
シフト希望登録画面
シフトを登録するモーダル
シフト希望からシフトに入る確率表示（ランダムフォレスト）
あと実装したい機能は
- AIのアルゴリズムの二つ目（現在ランダムフォレストを最初に通しています。そのあと最適化関数に通す予定）
- シフトを手動で調整する画面のUI調整。
- 完成したシフトをExcel等にエクスポートする機能
- （できれば）スタッフに完成したシフトを通知
技術選定終わり！
ここまで読んでいただき、ありがとうございました！
この記事では、シフト作成の背景や技術選定の選択理由についてまとめました。技術選定はプロジェクトの成功を左右する重要なステップであり、慎重に検討する価値があります。次回は、実際にDjangoを使った開発プロセスについてご紹介する予定です。
もしこの記事を読んでアドバイスやご意見をいただける方がいれば、ぜひ教えていただけると嬉しいです！今後も試行錯誤を続けながら、より良いアプリを目指していきます。
ではまた～👋
Discussion