Create  Edit  Diff  FrontPage  Index  Search  Changes  History  Source  RSS  Note  wikifarm  Login

日程調整アプリを作ろう-1-

モデリング

日程調整アプリっていうけどどんなのをつくるの?

このチュートリアルで作るのは、日程を調整するアプリです。

飲み会の日程調整だったり、会議の日程調整、釣りなんかの日程調整、色々ありますよね?そういう日程を調整するアプリです。

で、早速作っていくわけですが、そもそもどういう物が欲しいのかがないとはじまりません。

普通は顧客なりから、色々と要望を伝えられ、それに基づいて作成となるかと思います。

今回はRails勉強会@東北のMLで行っている、各回の日程調整を題材として進めていきます。下記のようなやつです。

Rails勉強会@東北第5回日程調整
片平藤岡大久保宗形咲間小林
10/13×××
10/14
10/20×
10/21×
10/27
10/28

現状の流れを確認

上記だけじゃ、実際にどんな流れで調整を行っているのか等もわからず、ちょっと作り進めていけないですよね。まず現状の流れを確認してみます。

1.誰かがMLに次の開催予定日(土日祝日)と自分の予定を投稿。

Rails勉強会@東北第5回日程調整
片平
10/13
10/14
10/20
10/21
10/27
10/28

2.各自が自分の予定を追加したものを投稿。

Rails勉強会@東北第5回日程調整
片平藤岡大久保
10/13×
10/14
10/20
10/21
10/27
10/28

3.ある程度予定が登録されたら、その中から一番参加者が多く、良さそうな日にちを選択。

Rails勉強会@東北第5回日程調整
片平藤岡大久保宗形咲間小林
10/13×××
10/14
10/20×
10/21×
10/27
10/28

↑27日に決定。

4.決定した開催日をMLに投稿、通知。

片平です。
27日がよさそうですね。第5回は27日で行きましょう。

これでオッケーでしょうか?何か足りない気がしませんか?

もう一度流れを確認

上記はいきなりRails勉強会@東北第5回というイベント名と、ユーザーのメンバ名が出てきちゃってます。これは、勉強会の世話人である筆者が、自分の目線で考えてしまったためにこのようになってしまいました。

ユーザーはMLのメンバーという前提で、いきなりユーザ名が出て来てしまっていますが、本来は勉強会参加者のMLへの追加という工程が必要になります。 この処理を行うことで、初めてMLのメンバーというユーザーリストが作成されます。

また、Rails勉強会@東北第5回というイベント名も毎月開催という事で、ぽんと出てきておりますが、本来は次月もイベントを行う予定ですというアナウンスが前提条件として必要になるはずです。

以上を踏まえての流れは以下の様になります。

  1. 勉強会MLへのユーザー追加
  2. 勉強会イベントのアナウンス(暗黙的)
  3. 誰かがMLに次の開催予定日(土日祝日)と自分の予定を投稿
  4. 各自が自分の予定を追加したものを投稿
  5. ある程度予定が登録されたら、その中から一番参加者が多く、良さそうな日にちを選択
  6. 決定した開催日をMLに投稿、通知

ユースケース?

ところでこのアプリを使用するのは誰でしょう?流れから確認すると、勉強会のメンバーですね。

他にはいないでしょうか?勉強会参加者以外の一般ユーザーとか。 メンバーの日程調整アプリですから、対象は勉強会メンバーだけで良さそうです。

では、勉強会メンバーという役割だけで問題ないでしょうか? 例えば、勉強会のメンバー中で、役割が分担されていたりしないでしょうか?

開催予定日を投稿する、開催日を通知するという作業を筆者がなんとなく毎回行っており、システムに落とし込む時には、世話人という役割も発生しても良いような感じがします。しかし、この作業は別に筆者でなくても出来る作業です。また、他の作業については、勉強会メンバーという役割だけで問題なく出来るでしょう。

こうしてみますと、アプリの操作対象は勉強会メンバーというフラットなユーザーだけで 問題なさそうです。

要件をあげてみよう

さて、流れの確認、操作対象も定まったので、要件をあげてみます。

  • ユーザを登録出来る
  • イベント(上の例でいえばRails勉強会@東北第5回)を登録出来る
  • 複数の開催候補日に対して各ユーザが参加可否を登録できる

開催日の決定処理、認証、開催日の通知等、他にも要件を定義した方が良さそうな項目があります。しかし、必要になったら付け足し、見直していけばいいという事で、とりあえずこれぐらいの要件でいってみます。

画面(UI)イメージ、ページフロー

要件もとりあえず用意できました。アプリの画面を実際に考えてみましょう。

まず、ユーザーとイベントですが、単純なCRUD(create,read,update,delete)が出来ればそれで良さそうですね。

考えてみましょうと言っておいてなんですが、ユーザーとイベントについてはscaffoldを使用し、画面もそのままscaffoldのを採用ということで、画面設計を省略する事にします。

次にこのアプリの肝、日程調整画面です。これはたびたび出てきている表のままの画面イメージを用意し、イベントのリスト画面からその画面へのリンクを用意で行けそうな気がしますがどうでしょうか?

なんだか少し足りないような気もします。しかし、とりあえず、これぐらいで次に行くことにします。

上記を図にするとこんな感じです。

adjuster_pf1.png

図では抜けておりますが、ユーザーやイベント、スケジュールへのメニュー画面(トップ画面?)も必要になるでしょう。

それから、日付とユーザーが表と逆になってしまいましたが、単純なミスです(^_^;)。が、どちらでもあまり影響はないので、今後はこの表示で進めていきます。

データモデルの洗い出し

さあさあ、データモデリングまで到達しました。

これまでの流れで、ユーザ、イベント、スケジュールという言葉が頻出していますね。

今までの要件、画面(UI)等から、勉強会(ML)参加者を表すUser、各勉強会を表すEvent、各Userのスケジュールを表すと共にEventの候補日を表すSchedule、以上3モデルを考えてみました。

各モデルに必要な要素を洗い出す

次に各モデルに必要な構成要素を洗い出してみましょう。

まず、User。メンバーの名前が必要ですね。それからメールアドレスも通知に必要かと思います。

Schedule。開催予定日とメンバーの出欠可否の状態が欲しいかと思います。

最後、Event。イベントのタイトルは必須ですね。それから必須ではないですが、メモが出来る備考があるとうれしいかもしれません。また、勉強会の開催日(決定日)も記録できるといいかもしれません。

まとめると、大体以下のような感じになりました。

User

  • name 名前を表示させるために必要。
  • email メールアドレス。結果を通知するために。

Schedule

  • schedule_date 開催予定日の為に必要。
  • attend ○,△,×などの状態の為に必要。

Event

  • name イベントのタイトル
  • note 弁当持参して下さいねー。とか会場どこそこ等のメモ用
  • date 勉強会の開催日。

本当にこれで問題ないでしょうか?Eventの勉強会開催日、dateは必要でしょうか?

勉強会の開催日は目で確認して、この日で行きましょうというメールを出す流れになっています。そうすると、別にシステム的に決定しなくても良さそうですね。この項目は削除することにします。

各モデルの関係を考える

表や画面イメージを見たとき、片平というUserに対して、10月13日、14日といったように複数のScheduleが存在している為、UserとScheduleの関係は1対多の関係と考えました。また、Rails東北勉強会@第5回というEventからスケジュールを見たときもやはり、1対多の関係であるように見えます。

したがって下記のようにリレーションシップを設定してみました。

User 1 ----- n Schedule n ----- 1 Event

ER図

データモデルのまとめです。ER図にしてみましょう。

adjuster_model_rev1.png

updated_atというカラムが入っていますが、気にしないで下さい。

一応準備出来たけど?

さて、必要最低限叩き台になるような所までモデリングが出来ました。しかし、スケジュールの日付部分の扱いがどうもしっくり行かない気がします。日程調整画面でうまく行く為には詰めが甘いような・・・。

引っかかりはありますが、これ以上どうも考えが進まないので、実装してみましょう。

目次次ページへ