[体験談] 未完成な社内図書館アプリ
はじめに
この記事では、社内の有志メンバーで社内図書館アプリを開発しそこで得た体験談をまとめております。
下記画像は、社内図書館アプリの開発中のものになります。
背景
1. 社員のスキルアップ
プログラムを学習する方法は、参考書や動画など多岐に存在します。
しかし、上記の方法で得た知識や技術を現場等で活用する場がないという事で会社負担で何かアプリを作ろう!という事でアウトプットの機会を頂けました。
2. 社内図書館の運用管理コストの軽減
福利厚生の一環で社内図書館というのは以前から存在しておりました。
借用者が多くない為、下記アプリを駆使し管理者2人で対応しておりました。
しかし、借用者が増加したら管理コストが増加すること容易に想像できます。
そこで下記アプリを駆使しするのではなく削減した運用に切り替える事を目標になりました。
| ツール名 | 用途 | 今後 |
|---|---|---|
| Microsoft Teams | 管理者同士のコミュニケーションツール | 引き続き利用 |
| Microsoft Form | 借用者からの貸し出し申請フォーム | アプリから申請 |
| Microsoft Outlook | 管理者と借用者のコミュニケーションとクリックポストの共有 | アプリからクリックポストのアップロードとダウンロード |
| Google カレンダー | 貸出書籍の返却管理 | アプリから貸出状況を一覧化 |
| リブライズ | 書籍情報管理アプリ | アプリへ移行 |
| クリックポスト | 書籍輸送 | 引き続き利用 |
結論
どんなことができるWebアプリ？
- 書籍の貸出しが
郵送配達と本社から持ち出しのフローに対応を可能 - アプリからの通知を
Microsoft Teamsに連携が可能
技術選定
フロントエンド
| 技術名 | 選定理由 |
|---|---|
| TypeScript | 現職で使用言語のためスキルアップ |
| Redux |
状態管理が可能ということで挑戦してみたかった |
| Next.js |
React機能を導入したいため |
| tailwindcss |
Next.jsをインストール時にカスタマイズで導入できるため |
バックエンド
| 技術名 | 選定理由 |
|---|---|
| Python | 前職でPythonの実務経験(2年)他のメンバーにも経験者あり |
| Django REST framework |
Djangoで一度実装したかった |
その他
| 技術名 | 選定理由 |
|---|---|
| GitHub | 会社で使用していたため |
| Miro | 会社で使用していたため |
このWebアプリで力を入れた箇所
1. アイコンを活用し直感的な操作可能なアプリ
各ボタンの操作をイメージしやすいように関連するアイコンを併せて表示
下記画像では郵送:🚛, 持ち出し:🖐のアイコンを表示
ローディングが分かるようにサークルが回転するアニメーションを追加
2. アプリの状態がわかりやすいように表示する
表示するデータない時は、単に「データがありません」と表示するのではなく
具体的にどんなデータがないのかアプリ利用者に伝える言葉を選びました。
下記画像では借りている書籍がないため、
現在 貸出されている書籍はありませんと表示
3. JWT認証システムでログイン機能を実装
ログイン機能の実装の自作は難易度が高いため、ライブラリーを活用しました。
自作よりもセキュリティ対策が施されたアプリを作成することができました。
4. 冗長なテーブル構造にならないような工夫
有識者に相談しながら 冗長なテーブル構造にならないようにメンバーと相談して作成しました。
テーブル設計
書籍マスターテーブル
| カラム名 | 用途 |
|---|---|
| ID | 書籍マスターテーブルのIDを管理 |
| 登録日 | 登録日を管理 |
| 更新日 | 更新日を管理 |
| 書籍タイトル | 書籍タイトル情報を管理 |
| 書籍概要 | 書籍概要情報を管理 |
| 出版社 | 出版社情報を管理 |
| 発売日 | 発売日情報を管理 |
| ISBNコード | 13桁のISBNコードを管理 |
| 書影 | Google Books APIの画像リンクURLを管理 |
書籍情報テーブル
| カラム名 | 用途 |
|---|---|
| ID | 書籍情報テーブルのIDを管理 |
| 登録日 | 登録日を管理 |
| 更新日 | 更新日を管理 |
| 書籍マスターID | 書籍マスターテーブルのIDの紐づけを管理 |
貸出管理テーブル
| カラム名 | 用途 |
|---|---|
| ID | 貸出管理テーブルのIDを管理 |
| 登録日 | 登録日を管理 |
| 更新日 | 更新日を管理 |
| 利用者 | ユーザーテーブルのIDの紐づけを管理 |
| 貸出対象 | 書籍情報テーブルのIDの紐づけを管理 |
| 貸出日 | 貸出日を管理 |
| 返却日 | 返却日を管理 |
| 返却予定日 | 返却予定日を管理 |
| 貸出状態 | 貸出状態(数値)を管理 |
| 手段 | 書籍の移動手段(数値)を管理 |
ユーザーテーブル
| カラム名 | 用途 |
|---|---|
| ID | ユーザーテーブルのIDを管理 |
| 登録日 | 登録日を管理 |
| 更新日 | 更新日を管理 |
| 氏名 | ユーザーの氏名を管理 |
| メールアドレス | ユーザーのメールアドレスを管理 |
| 住所 | ユーザーの住所を管理 |
| 郵便番号 | ユーザーの郵便番号を管理 |
5. 実装コストの軽減案の検討
-
社内専用アプリのためスマホやタブレットからアクセスは考えにくいと判断し、レスポンシブ対応をPC画面のみ絞り込む事で、フロントエンドのコードとデザインの工数を軽減 -
あったらいいな!機能の実装優先順位を落とし、社内専用アプリにとって必須な機能のみ絞り込み
6. 開発目標がぶれないようにメンバーで議論
「なぜ？このアプリが必要なのか?作成する必要があるのか?」メンバーで明確化し、方針がぶれそうなときに振り替えるために下記目標を考案しました。
-
社内専用アプリを通じて社員のスキルアップ/社員の自己実現をサポートする - 読みたい本を読みたい時にすぐに見つけられるアプリ
- 直感的な操作可能なアプリ
7. アプリからの通知をMicrosoft Teamsへ
アプリを見に行かないと貸出し状況が把握できないのはすごく不便だと感じたので
Microsoft Teamsの通知で必要な時に確認する楽な運用を可能にしました。
今回の学び/反省
1. カタチにするを優先しすぎた
コード整理や設計を飛ばして動くアプリを関係者に見て貰い、細かいフィードバックをアプリ開発を進める予定でした。
しかし、出戻り作業 (作業フローの考慮もれ) が発生し、コードを1から作成する作業を何度も繰り返しコーディングするのがしんどくなってしまいました。
2. モダン技術に安易に手を出さない
今回の技術選定で比較的にモダンな技術を選択しました。※誰もモダン技術の実務経験なし
結果的に開発の半分以上は学習期間だったため、開発する期間をあまり確保する事が出来なかった
特に参考になる資料を集めるのが大変でした
3. やっぱり開発作業は学びが多い
記事/書籍を読む、チュートリアルを進めるでは得られない経験が多く良い体験になりました。
Django REST frameworkで意図的にネストした形式にデータ成形するのが難しく、当時情報も少なく苦労しました。
また、通信量を減らすために必要なキーバリューのみを返す設定も実践的な学びでした
Discussion