第二百十九回「タスクをしなかったら20000ダイス（＝二百円相当）を誰かにあげるサービスを作る その３」
’２３年１２月２２日
前回の記事
前回はこんな感じのものを作るよと言うのをメンターの方にお知らせする形でnoteに公開したら、今回返事がもらえたので、その全文と、それに対する回答の方を考えたので、ここで公開する。ところどころでですますになったりだった・であるになったりするのはご愛嬌を。
なんだかんだで作ろうと決めたものは最低でも７個、作りたいサービスのアイディア自体は３０個以上あるので長丁場になるのは必至です。
とりあえず最初に作ろうと思ってる７個のアイディア概要と夢に描いていた絵に描いた餅の制作スケジュール等はこちら。
前回の作る予定のものの気になるところを指摘された文章全文
noteのレビューになります。
最低限設計しておいた方が良いと思う点について記載していますので、ご確認の上、
仕様の見直しをし、note, notion等にまとめてみてください。
開発を始める前に仕様を整理しておいた方が良いので、着手いただければと思います。
【サービスの設計について】
仕様を把握したい点・設計すべき点があるため、箇条書きにて内容を記載しています。
ご確認いただき、全て回答できる状態にしておいてほしいです。（すぐにでなくても構いません）
MENTAメッセージのやり取りでは、記載した仕様が流れてしまうため、
仕様に関しては、note あるいは notionにまとめていくのをオススメします。
・タスクが成功になるのは、どういうアクションが起きた時ですか？
（タスク画面でユーザーが成功ボタンを押す。でしょうか？）
・１個登録したタスクの成功・失敗が確定していなくても、もう１個のタスクの登録は可能ですか？
（その場合、今持っているタスク一覧画面が必要です）
・ランキングをつけるのは、「タスクの成功数」との事ですが、「ダイス数」はランキングに影響はしますでしょうか？
タスクが成功しないと、自分のダイスが他ユーザーに渡る仕組みなのであれば、ダイスを死守するゲームだと言えます。
そうすると、ダイスを多く持っている人に対して、何かしらの特典があった方が良いと思いました。
これについての案をお持ちでしたら、ご教示ください。
（そのダイスを使って、他のサービスで何かができる。であれば問題ないと思います）
・タスクが失敗した時、ダイスが0を下回ってしまう場合は、どういう挙動を想定していますか？
・タスクの削除は行える形にしますか？その場合、BETしたダイスは戻ってこない形で検討されていますか？
・タスクの編集機能がある場合、タスク成功・失敗前であれば、BETするダイスは変更できるようにしますか？
・タスクの編集・削除機能がある場合、タスク成功後・失敗後は編集・削除ができない形とした方が良いと思いますが、いかがでしょうか？
・ダイスをあげるユーザーが決まった時、渡す側の画面と受け取り側の画面はどういった表示になる想定ですか？
・ダイスを渡した場合、渡す側の画面と受け取り側の画面はどういった表示になる想定ですか？
【DBテーブル設計について】
不要だと思うものと、追加した方が良いと思うものを記載しましたのでご確認ください。
ユーザーテーブル
・ID
・名前
・E-mail
・パスワード
・自己紹介（１６０文字程度のプロフィール）
・ダイス（ポイント)
タスクを成功した回数
タスクを失敗した回数
=> これはユーザーに紐づくタスクの「タスクの成功・失敗」のレコード数の合計で算出できるため不要です。
タスクテーブル
・ID
・タスクをするユーザーID
・ダイスをあげる可能性のあるユーザーID（null許容）
・タスクの内容
・タスクの締め切り時間
・BETするダイス
=> ダイスのみの設計で進める事をオススメします。つまり、課金処理は一旦抜きにして進めた方が良いです。
考えるべき事が多いのと、お金がからむとちょっとしたミスも許されないため、まずはサービスが成り立つレベルになってから課金処理の追加を考えた方が良いです。
・タスクの成功・失敗フラグ（null許容）
・タスクの成功した時間 <= 追加
=> こちらあった方が良いと思いますがいかがでしょうか？
（タスクの成功履歴を表示する画面のデザイン次第ではありますが、いつ成功したか？という情報は見たいはず、と思います）
【画面について】
追加した方が良さそうな画面を太字で追記しました。↓
①簡単なプロフィールとポイントの累積が表示される画面
②現在やっているタスク（何時までにそれをやるのか）が表示される画面
今持っているタスク一覧画面
③タスクの達成が失敗した画面
④成功した画面
⑤その履歴
⑥タスクがどれくらい成功したのかを表示する画面
タスクがどれくらい失敗したのかを表示する画面
⑦タスクを何回達成したのかをランキングで評価する画面
⑧ポイントを購入する画面
⑨ログイン画面
⑩サインアップ画面
11ダイスをあげるユーザーを決める画面
文章への返答
最初の質問
Q１タスクが成功になるのは、どういうアクションが起きた時ですか？
（タスク画面でユーザーが成功ボタンを押す。でしょうか？）
A1 その通り、タスク画面でユーザーが成功（達成）ボタンを押した瞬間です。
将来的にはコンテンツの公開する締め切りとしての利用を考えているのですが、僕の現状でできそうなのはここら辺で手一杯です。
Q2 １個登録したタスクの成功・失敗が確定していなくても、もう１個のタスクの登録は可能ですか？
（その場合、今持っているタスク一覧画面が必要です）
A2 なるべく可能にしたいです。ダイスをベットする際にポイントを一旦預かる形にすれば、二つ以上同時に進行して同時に失敗してもダイスがマイナスになるということはなくせると思います。
今書いてて思ったのは、タスクを一度にできる個数を無制限にしてしまうといくらでも成功数を増やすことができてしまうので、一度にタスクを別途する個数は成功数が例えば十回成功すれば一つ増やすといった形で制限したいと思います。
Q3 ランキングをつけるのは、「タスクの成功数」との事ですが、「ダイス数」はランキングに影響はしますでしょうか？
A3 あくまでタスクの成功数のみでランキングをする予定です。
また、今の段階ではタスクの成功失敗だけを表示するサイトですが、将来的には、同じダイス（ポイント）を使った複数のサービスを立ち上げる予定であり、その総合評価としてダイス数単体でランキングをする予定を考えています。
Q4 タスクが成功しないと、自分のダイスが他ユーザーに渡る仕組みなのであれば、ダイスを死守するゲームだと言えます。
そうすると、ダイスを多く持っている人に対して、何かしらの特典があった方が良いと思いました。
これについての案をお持ちでしたら、ご教示ください。
（そのダイスを使って、他のサービスで何かができる。であれば問題ないと思います）
A4 成功した時に人からダイスをもらえるという流れにしてしまうとギャンブルになり法律に引っ掛かる恐れがあります（将来的にダイスをお金に変えられると言う流れがあればですが）ので、現在の失敗した時に誰かにあげるというギャンブルっぽくない流れを考えました。
またダイスは他のサービスで利用できることを考えております。上の方に書いた兄貴にプレゼンするとかいうリンク先にどんなアイディアを考えているのか書いておいているのでご参考までにどうぞ。
Q5 タスクが失敗した時、ダイスが0を下回ってしまう場合は、どういう挙動を想定していますか？
A5 今考えている案ではベットできない（タスクを制作できない）ようにする予定です。ポイントが入らないと面白くないので、いつやめるのかは未定ですが、ログインボーナスが入ってくるようにしたいと思います。
Q6タスクの削除は行える形にしますか？その場合、BETしたダイスは戻ってこない形で検討されていますか？
A6 削除できない予定です。現在では穴があるので、一つのタスクの成否を決めるのが自分なので、いくらでも成功させることができるので、相手から結果を確認した同意の反応がないとダイスが返ってこないようにするとか考えていますが、相手に反応がないとタスクを新たに作れなくなるという問題点もあるので、最初のうちはきちんと動かすのが大事だと思うので、ザル仕様になります。
Q7 タスクの編集機能がある場合、タスク成功・失敗前であれば、BETするダイスは変更できるようにしますか？
A7 タスク編集機能はつけない予定です。ただ、ベットするダイスを大きくするメリットがないので、そこら辺は考えたいと思います（この解決策としては、ベットが大きいほどダイスがもらえると言う方法にしてしまうのがいいのですが、全体的にダイスを多く上げてしまうと、課金することになった際に持ち出される額が増え過ぎて不可能になってしまうという問題点もあります。スパッとあるとき使えなくなりますよと言ってしまえばいいのかもしれませんが。
Q8タスクの編集・削除機能がある場合、タスク成功後・失敗後は編集・削除ができない形とした方が良いと思いますが、いかがでしょうか？
A8 タスクの編集・削除機能はつけません。
Q9 ダイスをあげるユーザーが決まった時、渡す側の画面と受け取り側の画面はどういった表示になる想定ですか？
A9 画面予定図に関しては明日ないし明後日あたりにクリスタで作ります。
（画像処理をするエディタではこれが一番使い慣れているからです）
Q10ダイスを渡した場合、渡す側の画面と受け取り側の画面はどういった表示になる想定ですか？
A10 A9と同様です。
【DBテーブル設計について】
不要だと思うものと、追加した方が良いと思うものを記載しましたのでご確認ください。
ユーザーテーブル
・ID
・名前
・E-mail
・パスワード
・自己紹介（１６０文字程度のプロフィール）
・ダイス（ポイント)
タスクを成功した回数
タスクを失敗した回数
=> Q11これはユーザーに紐づくタスクの「タスクの成功・失敗」のレコード数の合計で算出できるため不要です。
A11 了解しました。
タスクテーブル
・ID
・タスクをするユーザーID
・ダイスをあげる可能性のあるユーザーID（null許容）
・タスクの内容
・タスクの締め切り時間
・BETするダイス
=> ダイスのみの設計で進める事をオススメします。つまり、課金処理は一旦抜きにして進めた方が良いです。
考えるべき事が多いのと、お金がからむとちょっとしたミスも許されないため、まずはサービスが成り立つレベルになってから課金処理の追加を考えた方が良いです。
・タスクの成功・失敗フラグ（null許容）
・タスクの成功した時間 <= 追加
=>Q12 こちらあった方が良いと思いますがいかがでしょうか？
（タスクの成功履歴を表示する画面のデザイン次第ではありますが、いつ成功したか？という情報は見たいはず、と思います）
A12 了解しました。
ただ、この場合に少し問題があります。もしタスクを同時に作る個数を制限する場合、タスクを最初に取り掛かった時間（最後というか最初というか現行のタスクが一つなくなる瞬間）を出す上でこのカラムが必要になる可能性があるなと感じました。ただ、その設計をすると、このカラムだけではnull以外の方法でタスクに取り掛かり中か終わったかを判断する方法を設定するのが難しいと言う問題があります。この部分はもうタスクを同時に進められる時間の締め切りは、タスクの締め切りのカラムに絞った方がプログラムは煩雑にならないかもしれません（二つだとまだプログラミングできそうな感じがしますが三つ以上だととても無理です）。
【画面について】
追加した方が良さそうな画面を太字で追記しました。↓
①簡単なプロフィールとポイントの累積が表示される画面
②現在やっているタスク（何時までにそれをやるのか）が表示される画面
今持っているタスク一覧画面
③タスクの達成が失敗した画面
④成功した画面
⑤その履歴
⑥タスクがどれくらい成功したのかを表示する画面
タスクがどれくらい失敗したのかを表示する画面
⑦タスクを何回達成したのかをランキングで評価する画面
⑧ポイントを購入する画面
⑨ログイン画面
⑩サインアップ画面
11ダイスをあげるユーザーを決める画面
※了解しました。こちらに関しては明日ないし明後日にクリスタで作ります。
今日のTwitter
サボらないようにと１日１時間に一回呟いてましたが、最近では面倒くさくなってサボっています（本末転倒ですね）。
明日の目標
Railsチュートリアルの第１２章まで終わらせて
画面の構成を考える。
これからやることを細かく分解してみる。
この記事が気に入ったらサポートをしてみませんか？