シフト希望管理サイトを作ったはなし
こちらはCPS Lab Advent Calendar 2019 12月5日の記事です。
12月4日の記事はこちら
自己紹介
僕は実空間コンピューティング研究室のB4のいとゆうです。
普段はUnityでゲーム開発やWEBフロントとかの個人開発などをやっています。
最近はやっと電子工作やセンサーに興味が出始めて挑戦中です(今更)
本題
ここでは僕が約３年アルバイトしてきた中で、シフト提出手法に嫌気がさして無償かつ勝手に製作し運用まで持っていったシフト希望管理サイトの話をしたいと思います。
また今回の運用が自分史上初であることや運用してからまだ１か月しか経っていない中で学んだ(苦しんだ)ことについても話せたらと思います。
背景
僕はゲームセンターでアルバイトをしているのですが、そこでの今までのシフト希望の提出手法は以下のような様子でした。
- 事務所に置かれた用紙1枚に全員分の希望を記入
- 半月ごとの提出で締め切り日は不定期
- 用紙が掲示されるタイミングも不定期
- 未記入、記入ミス等が多発しすぐにシフト作成に取り掛かれない＆短時間で作成を強いられる
効率が悪く、数多くの問題が発生していた！
以上の点を踏まえて、
- インターネット上で登録管理が可能
- 年中いつでも利用可能
- 締め切り等のシフト希望の収集を自動化
この３点をテーマとしてシフト希望管理サイトを作成に至りました。
システム概要
ユーザ登録＆認証
ユーザ認証にはLINEアカウント(LINEログイン)を利用します。
⇒ 従業員をはじめとした多くの人がLINEを利用しているため導入コストが低い
また今までの連絡事項の際にはLINEを利用していたため
認証をLINE公式の技術を利用することでセキュリティレベルを上げる
初回ログイン時にLINEアカウントの利用についてユーザに権限の許可を伺います。
登録時にはサイトで使用するユーザ名と勤務区分を設定します。
シフト登録
シフトの集計は半月周期で行います。集計期間内であればいつでも希望の登録変更が可能となっています。
基本的に出られない日付や条件付きで出られる日付を提出する形式になっており、各日付に✕、△、時間指定のいずれかを選択し登録することができます。
管理者権限
サイトを利用するにあたって社員やバイトリーダー等の一部の人を管理者として権限を与えます。
管理者が行える機能は以下の通りです。
- 全ユーザのシフト希望一覧
- お知らせの配信
- 各日付への予定の登録
- ユーザ操作ログの閲覧
- 登録者一覧の閲覧、削除
- 管理者一覧の閲覧、追加、削除
システム構造
このサイトの全体構造は以下の構成です。
フロントエンドにReact.js、MaterialUI、react-modal等、
バックエンドをexpress.js、
DBはPostgreSQL、
LINEアカウントの利用のためLINEログインを利用しています。
そして現在はHerokuのフリープラン内で運用しています。
ユーザのセッションの管理にはexpress-sessionを利用しています。またセッションを保存するためにRedisを利用しています。インメモリで保存されるのを防ぐため。
さらにこのサイト用にLINEBotを作成し、Herokuから提供されているHeroku Schedulerを連携させることで、簡単な応答および締め切り日当日における通知の送信を可能としています。
サイトを取り入れて得られた結果
まず初めに挙げていた問題点より、
- 用紙が不要になった。
- 締め切りや管理の自動化により、締め切り日や提出サイクルのルーティーン化および社員の手間を省くことを可能にした。
- 提出日が一定であり、LINEBotによる締め切り通知により記入ミスや忘れを減少させることができた。
またテーマから
- ネット上での管理を可能にした。
- Herokuでの運用によりほぼ年中いつでも利用可能。
- 締め切りや収集を自動化することができた。
大方の問題点を解決することができた！
運用から得られた知見
ここまでは”問題提起⇒提案⇒解決”といった具合にきれい話だったと思うのですが、失敗談および初運用から学んだことを話したいと思います。
１．登録ができない（cookieが消される）
僕の開発環境は主にWindowsでAndroid端末複数でもテストを行っていました。その中で登録ができないことはなかったのですが、運用開始直後、何人かLINE認証後トップページに戻されるといった登録ができない人がいました。
結論から言うと、リダイレクトの使用によるcookieの削除、safariのITP*1機能によるものでした。
初めの構成はLINE認証のコールバックをexpress側で受け取り、内容をもとにreact-router-domで指定したパスにredirectさせていたのですが、改善策としてreact側でコールバックを受け取り、内容をexpressにPOSTからの判別にしました。
またchromeを使用してもらうことでも解決はしました。
結果的には解決しましたが、iOS環境が無くエラーを自身で確認できないことに大変苦労した上に今でも解決したのか、改善策が適切なのかわかってないです。
圧倒的知識不足を感じました…
２．シフト登録の不具合（非同期処理や処理速度など）
ユーザが希望入力後、登録ボタン押すことで登録処理が行われるのですが、当初の登録処理構造は追加、削除、更新を同期処理で走らせ、すべての処理終了後に再レンダリングするといったものでした。
しかし、登録ボタン押下後すぐに再レンダリングされないことから、ボタンを連打してしまったり、処理終了前に変更を登録してしまうことにより整合性が取れずエラー終了してしまうことで、本来の希望と登録されている希望が異なってしまうことがありました。
そこでそれぞれの処理を非同期処理に変更した上で、処理が行われている間はカレンダー等を非表示にし代わりに読み込み中を示すアニメーションを表示させ、処理終了後には登録内容をモーダルウィンドウで表示させることでユーザに認識させやすくしました。
こうして処理内容や速度を含めた構成を理解し、ユーザ第一の製作を行うことの重要性を感じました。（通信速度が上がっている現代において人はとてもせっかちだなと思いました。）
３．ユーザ目線の構成（UI、UXとか）
運用するにあたって、必要と思われる機能等を実装しユーザマニュアルも作成したうえで、自分が成しえる最高の出来として取り掛かったですが、最初の約２週間はエラー＆改善対応に追われ続けました。
まず作成したマニュアルについてですが、
ところで皆さんは様々な説明書をしっかり熟読しますでしょうか？
おそらく多くの人がさらっと見るもしくは見ないであると思います。ましてやWEBサイトであればいちいち使い方を確認することのほうが少ないのではないかとも思います。
その点からマニュアルを読んでもらうことを前提とした設計になってしまっていたことや説明が開発者目線で分かりにくくなっていたことが悪かったと感じました。
逆にもっと説明なしに使いこなせるような設計にすることが求められていることを痛感しました。
さらに運用開始後、連日ユーザから機能要求が飛んできました。
自身もユーザの一人とはいえ機能不足や改善を行っています。この事態をなるべく避けるためには使用環境の分析、調査が重要だと感じました。
最後に
今回初めて製作物を運用したということで多くの知見を得ました。
まだ運用1か月で安定してないですが、将来的には僕自身が手を触れずに運用し続けられるように完結させたいです。
運用したことがない人へ…
学生のうちに絶対体験したほうがいいと思います！開発だけでは得られないものがあります！やって損なし、おすすめです！
とはいえエラー対応の日々は地獄、よきコードを書けるよう精進せねば...
