#1で書いたように、ちょっとお堅い業務システムを例に少しずつ開発をしながらそのことをブログに書いていこうと思います。
題材
さて、題材は何にしようと思いましたが、今回は、「受付システム」にしようと思います。
2010年頃だったと思いますが、とある1000円カットのお店にいくと、待ち時間がディスプレイ上に表示されていて、発券をすると「何分後に来てください」と表示されたシステムを初めて見ました。
今ではこの手のシステムも珍しくありません。スマホが発達した現在では通知をメールなり、LINEなりで送ってくるものもあるくらいです。
すでにそのようなサービスは商用にリリースされているでしょうから作ったところで収益化できるわけではありませんが、題材としては十分でしょう。あくまでサンプルアプリなので、ゆくゆくは最新版をherokuで公開としようと思います。
（※この記事を書いている時点では下記の検討が最新状況です）
開発スコープ
開発初期のゴールは何といっても、
開発スコープや、機能一覧＋機能概要の確定
だと考えています。この開発でもまずは機能一覧まで落とし込みたいのでどういうことができればいいのかを考えていきます。
受付システムの概要
私がこれまで生きてきて、受付を受ける側に回ったことはあまりありません。従って、受付でサービスを受ける側で思いつく例で概要を考えます。
ここでは飲食店のウェイティングリストを見てみましょう。
受付の申込者
今この状況下で、1組の来店があった場面を考えます。この時、この来店した1組は、どのくらい待つのかを知りたいところです。それによっては受付もせずに店を出るという判断もありえます。
システムで「ズバリ何分待つ」という情報が提供できるのが理想です。しかし上記のようなウェイティングリストを置いているだけでも、「何組が待っているのか」という情報からおよそのあたりがつけられ、十分意味がありそうです。
次に、今この状況下で、受付済の「ウイス」さんの立場でどのような情報が必要か考えてみます。基本は先ほど受付をせずに帰った1組と同じことが言えます。
あと何分待つのかがわかればそれに越したことはありませんが、「何組が待っているのか」という情報からおよそのあたりがつけられ、十分意味がありそうです。待ち時間が相応にありそうだと判断すれば、その場を離れて待つなり、キャンセルして立ち去るという判断になりえます。
最後に、受け付けたはいいものの、飛ばされてしまった「ナッパ」さんを考えてみます。
受付したものの気が変わってキャンセルつもりだったのであれば、店舗スタッフによって無効にする必要があります。相当な時間、連絡がつかない場合もこのように考えるほかありません。
次に、ごくわずかな時間反応ができなかった程度だけだったケースはどうでしょうか。その場合、タイミング悪く「天津飯」さんたちが先に通される可能性がありますが、少なくとも「ウイス」さんたちよりは、優先度が高いように考えられます。一度飛ばしたからといっても戻せる余地は残しておく必要がありそうです。
店舗スタッフ（受付の対応者）
店舗スタッフとしては、座席の状況から通せるか、通せないかの判断をしていると考えられます。片付けが完了している条件もあるでしょうし、厨房側の状況からあえて通せないということもあるでしょう。
この辺りはシステム化は厳しいと考えます。
飲食店の場合システムへの入力強制は難しい
上記の「座席に通せるか通せないか」を判断する機能の重要度は低いと考えます。ただでさえ注文を取る端末を携帯している店舗スタッフが、別端末を持ち歩いて状況の更新をするというのは手間でしかありません。通せるか通せないかは現実の状況を見れば一目瞭然です。
エンジニアの性として、機能にばかり着目して設計しがちですが、現実に使われるか、使う人の状況はどうか？を考えると無理だろうなということもありえんですよね。
基幹システム開発のようなもっとお堅いシステムでもありがちです。「その職種の人の本来業務なのか、そうではないのかをちゃんと考えましょう」ということがあります。この辺りは、また別途記事に書いてみようと思います。
ということなので、現実の状況とウェイティングリストから通すべき人を受け付けます。受付結果を入力すると、ウェイティングリストが更新される、程度でよいでしょう。
その場で待っている場合にはそのまま声かけをすればよいですが、その場にいない場合は飛ばさざるを得ません。
次回
今回は飲食店を例に受付の申込者と対応者を例に考えてみました。比較的、1人1人の申込者は受付にエントリーしてから対応者によって受付られるまでの時間が早い例です。
次は、もう一例として、携帯ショップの受付で考えてみます。理容室などの受付でも似たようなことだと思いますが、こちらは1人1人が受付にエントリーしてから対応者によって受付けられるまで時間がかかります。
その場合、システム面から考えるべき機能も異なる可能性がありますよね。
いくつも考えても仕方ないので、次回以降、「携帯ショップ」を例に考えてみて、開発機能をおよそ確定したいと思います。