Introduction
突然だが、
私が以前作成したバンドサークル管理アプリの使い勝手があまりにも悪く、
実用性が皆無だった。
もちろんそんなアプリケーションが実際に使われる事は無く、
ただの転職活動用のポートフォリオとして消費される木偶の坊となる結末。
そこで次は、実用に耐えうる...
いや、ユーザやサークル管理者に寄り添ったアプリケーションを作り、
今度こそお世話になった団体に恩返しをしつつ、
あわよくば全国展開？マネタイズ？と悪知恵を膨らます筆者なのであった...
前回の反省
なぜ前回作成したアプリケーションは失敗してしまったのか。
考えられる要因。
ユースケースを考えられていなかった
このアプリケーションはどんな場面で利用されるんだろうか？
そこを考えずに作った結果、本当に必要とされているシステムの流れには
ならなかった。当然。
開発者目線で作った
各情報を保存するデータベースはこうで...
そこに情報を入力するフォームはこうで...
出力する画面はこうで...
という、開発者目線で作ってしまった結果、
ユーザは自らのユーザIDを覚えていけないといけなかったり、
見にくくて操作しにくいライブ一覧など、
非常に余計な手間の多いシステムになってしまった。
これではユーザは使ってくれないし、
サークルの運営を円滑にするという目的を達成できない。
反省まとめ
目的に対してどういう機能があって、
その機能をユーザがどのように使う事で叶えられるのか、
常に意識しながら開発していかなければならない。
今回はどういう流れで作るか
下記の手順でやってみることにした。
1. 問題提起 - 何が問題？何が悪かった？
2. ユースケース考察 - どこでどうやって使う？
3. 要件定義 - その為にどんな機能がいる？
4. 設計 - 利用シーンを考えてどんな画面が必要？
5. 作成 - UIを考慮した画面・動き・データ
6. リリース - なるべく小さい間隔・小さい規模で
7. ユーザ評価 - 見やすい？分かりやすい？使いやすい？
この一連の流れを短いサイクルで回す。
1→7まで行ったら1に戻り、ユーザ評価に対する問題提起をする。
レビュー内容は何が原因で何が悪かったからその感想が生まれたのか？
そしてまた7まで進める。これを繰り返す。
常に改善しながら小さいリリースを繰り返していく。
正直手探りだが、失敗を１回踏んでいるので、
改善しながら進めていく事にする。
その為、手順も変更になる可能性は十分にあるだろう。
Next
今回考えた流れを踏まえ、１サイクル目は
サークル管理者にアプリケーションを使用する想像をしてもらって
問題点や必要機能を炙り出す
ことをテーマとし、プロトタイプ的な感じでリリースまで進める。
次の記事では1サイクル目の開発の問題提起を行う。
バックナンバー
バンドサークル管理webアプリ製作日記 - 問題提起
バンドサークル管理webアプリ製作日記 - 競合比較
バンドサークル管理webアプリ製作日記 - ユースケース
バンドサークル管理webアプリ製作日記 - 要件定義