まえがき
先日、うちの大学の某サークル様向けにとあるアプリを作った。よそにアプリを納品するのは初めての経験で、(主に失敗から)学んだことが多くあったので備忘録的にまとめてみる。
ちなみにアプリの表向きな開発元はここ
作ったアプリについて軽く紹介
納品先は学祭や地元のイベントでコーヒーのドリップ販売を行っているサークル。今までは紙の番号札で注文を管理していたため、コーヒーを購入したお客さんは必ず列に並んで長時間待つ必要があった。今回作成したアプリは、注文管理やコーヒーの作成を全てシステム化し、待ち時間を可視化して列に並ぶ必要をなくすのが目的だった。
アプリの操作フローは
レジが注文を追加する。
バリスタ(コーヒーをドリップする人)が手持ちのスマホで注文された商品のステータスを「作成中」に変更すると同時に、商品を作り始める。
バリスタが商品を作り終えると、端末から商品のステータスを「完成」に変更する。
お客様に商品を渡すと同時に、注文を「受け取り済み」に設定する。
失敗した点
アプリが使われなかった
アプリが使用される予定だったのは、11/3から11/5にかけての学祭で出店される屋台。その3日間のうち、実際にアプリが使用されたのは1日目と2日目の午前だけ。その後はアプリの使用方法の周知が行き届いていなかったために使用されることはなかった。
仕様の考察が不十分だった
本質的な失敗はこれに尽きると思う。学祭では、納品先の屋台に例年100人単位でお客さんがやってくる。ピーク時には何十人分の注文を待つ場合もある。そんな中で、前述した操作フローはあまりに煩雑すぎた。
アプリの動作が不安定だった
操作フローを見ればわかる通り、このアプリは複数端末で同じデータを参照するため、リアルタイム更新を実装した。でもわたしの実装が悪かったのか、ときたまリアルタイム更新が動かなくなることがあった。また慣れないアニメーションを実装したためか、端末によってはアプリの動きが重くなってしまった。
反省点
クライアントの状況を想像する
今回わたしは「いかにきれいなロジックで実装するか」を重視してシステムの設計を行った。でも実際大切なのは「需要にどれだけマッチしているか」「運用されるときにどれだけ使いやすいか」だった。今考えると当たり前のことだけど。
仕様と設計をよく考察する
開発中、仕様変更が何度もあった。これに合ったシステム設計にするため、リリースの1週間前にDBの構造含めロジックを大幅に変更したのだが、結局その後の仕様変更で設計を変更した意味が薄れてしまった。必要な仕様について、それが本当に必要なのか、ベターな案はないかを考えるべきだった。設計も私がメインでやったけど、もっとチームメンバーと議論するべきだった。
おわりに
私の拙い文章を読んでくださってありがとうございました。技術的な失敗点はまた別の機会に書こうと思います。
ｚ
z (┛)
z
＜⌒／ヽ-､＿
／＜_/＿＿＿＿／
￣￣￣￣￣￣￣