はじめに
この記事は、「Leafletを使ってオンラインでインタラクティブな座席表を作る 」の続きの話です。
座席表の更新を怠り、総務部門から怒られ、80人分の座席Excelで取りまとめ、二度とこんな作業するもんかと誓った2019年GW前の最終営業日。10連休のGWにLeafletを学んで社内向けに座席管理システムを作りました。
その後、社内向けのシステムをベースに、ちょっと変更を加えてインターネットに公開するまでのお話です。
10時間くらいでできたらキャッチーでよかったのですが、プロトタイプから公開まで軽く100時間くらいかかっています。
作ったもの
ドメイン契約を終了してサービス終了しました
座席表を作って共有するサービス「しーとむ」
座席表の英語seatmapからドメイン名を先に決めたので、こんな名前です。データがリセットされるデモが置いてあるので遊んでみてください。
なぜ作ったのか
プロダクトマネジメントの経験のため
歳も歳なので、自分の好きなものを自分の好きなように企画して作ってリリースして改善していく機会って、悲しいかな仕事の場にはそんなにないのです。ないなら自分でやればいいかと思ったのが1つ目の理由です。
同じように困っている人のため
座席表の管理なんて、企業が100あれば50くらいは困ってるんじゃないかという楽観的な観測から、重厚な社内版ではなく簡易版を公開してみて、反応を見ようと思いました。他の誰かのヒントになるだけでもよいかなと。
公開するにあたって考えたこと
今回は、会社で使っている座席表システムをそのままオンライン公開をしていません。ネットに公開するために、考えを巡らせて作りかえました。その過程で考えた書いておきます。
ちなみに、会社版の座席表は
- フロアデータがマスター化されていて、
- フロアに座席がマッピングされていて、座席は管理者以外は自由に動かせない
- 社員は、社員番号でマスター登録してあるのが前提であり
- 管理者が作った席データに社員を紐づける
- 席に社員の乗せるのは誰でもできる
というようなガチガチにデータ管理をしています。
プロダクトとして考えたこと
１．使ってもらえるものを作る
会社の座席表の管理者は（今のところは）僕自身です。自分が困っていることを解決するために最低限で実装しています。重要な部分から作るようにしたため、会社版もまだ未実装な機能がたくさんあります。例えば、会社に人が入るたびにSQLを流したりしています。
同じ状態で公開するのは無理があります。足りていないところを機能化することは、会社版にも使えるので問題はないのですが、作る前に以下のことが思いつきました。
- 機能化するのはよいのだけど、使うだろうか？
- 機能が複雑になったときに、自分以外が使いこなせるだろうか？
- 説明書を書いても読むだろうか？
- 使うまでの準備段階で挫折しないだろうか？
特に、使う前段階の挫折は、新しいツールにとって命とりになります。使うところまでたどり着いていないのですから。必要性が未知数なので、オンライン版では捨てる機能を考えました。
２．やらないことを考える
会社版とは違うオンライン版を作ると決めたので、必要ないと思う機能を消していきました。何ができればよいか（何ができなくてもよいか）決めておきます。
今回はこんな感じで決めました。
ツールでできること
- 難しい手続きがなく使うことができる
- 自分のもっている資産（図面の画像）を使うことができる
- 座標など難しいことを考えず、簡単に使える（ピンが置ける）
- 地図に置いたピンを自分自身で調整することができる
- 地図に置いたのモノ探すことができる
- 自分のURL（パーマリンク）を作れる
- URLから簡単に表示ができる
ツールではできないこと
- ログイン／ログアウト、ユーザ登録
- アクセス制御（見える・見えない、見えるけど変更できないなど）
- URLを忘れた時の機能
- ゴミデータに対する機能
- データ量が増えたらどうしようの考慮
- 人や部署などのマスター管理
やらないと決めるのは難しいですね。作りたい気持ちが強いと、あとちょっと、あとちょっとと機能が膨らみがちで、おなかなか終わらなくなります。
技術的なこと
次は作りたいものをどうやって作るかですが、悩み過ぎて止まるくらいなら手を動かすスタイルでいきました。まぁ、社運を賭けたプロジェクトというわけでもないので、お気楽に。
１．自分の得意な方法を選ぶ
クラウドにしてもプログラム言語にしても今は選択肢がたくさんあります。今回は使い慣れたものを選びました。何か学習が必要なことがあっても1つに絞るように心がけています。Leaflet自体が学習対象だったので、それ以外の部分にできるだけ時間は使わないようにします。
実際に使ったもの
- Heroku(dev)
- Postgres(hobby)
- PHP＋Laravel
- Cloudinary
- Bootstrap
- Fontawesome
Firestorage使えたらかっこいいだろうなと思いますが今のタイミングでチャレンジすることは避けて、普通にRDBとSQLです。Vueもやりたいですが、今じゃない。
２．変な工夫をしない
今回はHerokuのPostgresなのでデータ件数10000件が上限です。Pinが1つできればデータが1行できる設計なので、10000席が上限です。50席ｘ100フロアなので、心もとない気がします。
GeoJSONの形式にしてテーブルに入れるとかデータ量を節約する工夫に思いを巡らせることはできますが、実装にも検証にも余計に時間がかかることは避けました。足りなくなったら考えましょう。
あと、テーブル分割するかとか、キャッシュどうしようとか、、、これも手が止まるので経験がないものは選ばないようにしました。今回はHerokuのPostgresなので、いざとなったら＋1000円払って時間稼ぎすることは決めました。現時点ではそれ以上のことは考えないことにします。
３．実装方法を考えすぎない
会社版とオンライン版ではソースコードが似ている部分が結構あります。同じようなことをできるだけ書かないようにしたほうがいいのは分かっていますが、割とあきらめてコピペも結構あります。
リポジトリの構成やクラス構成で悩みすぎて手が止まるなら、あとで変えればいいので、まずは作ってみようという方針です。ちょっと汚いコードもありますが、目をつぶりました。
４．デザインはあきらめる
これはもう自分のスキルとしては絶望的なので、Bootstrapでカバーできない部分はあきらめます。良さを求めると限界がなく時間ばかり必要になるので、3つくらい先のフェーズで誰かに助けてもらいます。この辺をさくっとできちゃう人はうらやましいです。
フェーズ分け
個人開発なのでやる気が維持できるか分からないですが、足りないものを埋めるのも何となく計画しておきます。計画があるほうが無い場合よりやる気が継続しやすい気がします。
０．リリースまで
まずはアウトプットすることに重点を置いてリリースしました。最初にやると決めたことはやりきったつもりなので自己満足感はあります。難しいことを考えずに使える状態を目指しましたので、遊んでください。
遊んでもらう工夫としては、自動でリセットされるデモページを用意することでハードルを下げました。
リリース後のプラン
オンライン版は可能性が見えてくるまでは、遊び重視の方向性でいこうと思います。
１．オンライン版のプラン
-
アクセス制御
オープンな座席表という位置づけだとしても丸見えはよくないなぁと思っているので、ユーザ登録抜きで見える・見えない、見えるけど編集できないくらいは付けたいです -
フロアの削除
使い終わったら削除できれば、こちらも余計な情報を抱えずに済みます。放置されたものを消すくらいの仕組みはちゃんと作ろう -
入力を簡単に
50人分を入れるのは面倒だし、もっとサクッと入れられるUIを考えたい -
右側リストの改善
ずらっと並ぶだけなので、フィルタ・並び替えくらいは必要かも -
席のシャッフル
飲み会や会議などで使えるかも -
公開施設（ショッピングセンターなど）の地図の取り込みと共有
アクセス制限を作らず見えることが前提でやるのであれば、共有されてよいものをターゲットにするのがいいかも
２．もともと考えていた座席表の正しい方向へのプラン
遊びではなく会社の座席表として使う方向で機能を拡充をするなら、ざっとこのような機能が必要になりそうです。最初に捨ててきたものに真面目に取り組む感じですね。
- ログイン、閲覧制御のアクセス制御の仕組み
- 会社マスター、部署マスター、人マスター、席マスターの概念と機能を入れる
- 異動・退職への対応
- 組織変更、大規模席替えへの対応
- 変更履歴や部門ごとの席利用のレポートを充実
自分の会社用にもないものが多いので、出てくる要望の中で特殊すぎる要件を捨てながら追加していくことになります。
まとめ
こんな感じで、2019年のGWのほとんどを費やした座席表プロジェクトは、オンライン公開にこぎつけました。会社版はGWのあとに2回ほどバージョンアップをし、毎月の座席表提出は労力80％OFFくらいになりました。
アウトプット重視で進めたので、まだまだ作っていない機能がたくさんあります。気持ちを切らさずに足していくと思います。最終的には、データ管理がしやすくて、見やすくて、人を探しやすい座席表を作れればなと思います。
疲れた。