見出し画像

小3の娘向けに家庭内ポイント制度を作ろうとしたら、ほぼ要件定義だった話【ATS開発日記#01】

こうちゃんの個人開発ノート

小学3年生の娘向けに、家庭内ポイント制度を作ろうと思った。
最初の発想は、かなりシンプルだった。

勉強やお手伝いをしたらポイントが貯まる。
貯まったポイントでごほうびと交換できる。

いわゆる「がんばりポイント」のような仕組みである。
しかし、実際に考え始めると、これは単なるポイント表では済まなかった。

  • 何にポイントを付けるのか。

  • 何ポイントにするのか。

  • ごほうびはいくらにするのか。

  • やらなかった日はどう扱うのか。

  • 誰が記録するのか。

  • 親の管理負担はどこまで許容できるのか。

  • そもそも、この制度の目的は何なのか。

考えれば考えるほど、これは家庭内の小さな制度設計であり、ほぼ要件定義だった。
この記事では、Adventure Token Systemという家庭内ポイント制度を作り始める前に、まず何を考え、どこで詰まり、どう判断したのかを整理する。
技術詳細はまだ書かない。
LINE Bot、DB設計、Notion連携、TypeScript実装などは後続の記事に分ける。
今回は、あくまで出発点の話である。

背景：不登校の娘と「できたこと」の見える化

小学3年生の娘が不登校になり、家での勉強、お手伝い、生活習慣を少しずつ前向きに積み上げられる仕組みを作りたいと考えた。
ただし、目的は「勉強させること」ではない。
親が一方的に、

  • やりなさい

  • できていない

  • ちゃんとしなさい

と言っても、本人にとっては負担や圧力になりやすい。
むしろ必要なのは、

今日はこれができた
昨日より少し進んだ 自分にもできることがある

という感覚だと思った。
つまり、やらせる仕組みではなく、"やったことを見える化する仕組み" を作りたかった。
そこで考えたのが、家庭内ポイント制度である。
勉強、読書、お手伝い、生活習慣などを「クエスト」として扱い、やったらポイントが増える。
ポイントが貯まったら、ごほうびと交換できる。
ゲームっぽく見せつつ、実際には日々の行動ログを残す仕組みである。

最初はポイント表を作ればいいと思っていた

最初は、次のような表を作ればよいと思っていた。

$$
\begin{array}{|l|l|}

\hline
\textbf{行動} & \textbf{ポイント} \\
\hline
\hline
\text{プリントをやる} & \text{5pt} \\
\hline
\text{読書をする} & \text{3pt} \\
\hline
\text{お皿洗いをする} & \text{10pt} \\
\hline
\text{早く寝る} & \text{10pt} \\
\hline
\end{array}
$$

これを紙に書いて、週末に集計して、貯まったポイントでごほうびと交換する。
これなら簡単に始められそうだと思った。
しかし、少し考えるだけで問題が出てきた。

  • ポイントが高すぎると、すぐにごほうびへ到達して制度がインフレする。

  • 逆に低すぎると、目標が遠すぎてやる気が続かない。

  • 行動の種類が多すぎると管理できない。

  • 少なすぎると、本人が選べない。

  • ごほうびが高すぎると現実感がない。

  • 安すぎると、親の金銭負担や交換頻度が増える。

そして何より、親が毎日計算して管理する運用にすると、たぶん続かない。
この時点で、ようやく気づいた。
これはポイント表の問題ではない。
制度設計の問題 である。

詰まったこと1：ポイント単価が決められない

最初に詰まったのは、ポイント単価だった。

  • 1ポイントを何円相当にするのか。

  • 1日に何ポイントくらい貯まる設計にするのか。

  • Switchのソフトのような大きなごほうびには、何ポイント必要にするのか。

ここを雑に決めると、制度が壊れる。
たとえば、1日で大量にポイントが貯まる設計にすると、大きなごほうびにすぐ届いてしまう。
一方で、到達までに何ヶ月もかかる設計にすると、小学生にとっては遠すぎる。
大人なら「3ヶ月後の報酬」を目標にできるかもしれない。
しかし、小学生にとっては、3ヶ月後はかなり遠い。
そのため、大きな目標だけではなく、短期で届く小さなごほうびも必要になる。

```mermaid
flowchart TD
    A["日々の行動"] --> B["ポイント獲得"]
    B --> C["小ごほうび<br/>短期で届く"]
    B --> D["中ごほうび<br/>少し頑張る"]
    B --> E["大ごほうび<br/>長期目標"]
```

この時点で、単なる「1pt = 〇円」という換算だけでは不十分だと分かった。
必要なのは、金額換算ではなく、到達までの距離感の設計 である。

詰まったこと2：親の運用負荷が重すぎる

次に詰まったのは、親の運用負荷である。
家庭内ポイント制度は、親が頑張れば一時的には回る。

  • 毎日チェックする。

  • 紙に記録する。

  • ポイントを計算する。

  • ごほうび交換を管理する。

  • 例外対応を判断する。

しかし、これは長続きしない。
制度を作る側の親が疲れてしまったら終わりである。
特に危ないのは、以下のような運用だ。

$$
\begin{array}{|l|l|}

\hline
\textbf{危ない運用} & \textbf{起きそうな問題} \\
\hline
\hline
\text{親が毎日記録する} & \text{忙しい日に止まる} \\
\hline
\text{親が毎回ポイント計算する} & \text{面倒になって雑になる} \\
\hline
\text{例外対応を毎回判断する} & \text{交渉が増える} \\
\hline
\text{ごほうび価格が曖昧} & \text{交換時にもめる} \\
\hline
\text{記録が残らない} & \text{成長が見えない} \\
\hline
\end{array}
$$

これは、子どもの継続力だけの問題ではない。
親側の運用設計が悪いと、仕組みそのものが破綻する。
だから、最初からこう考える必要があった。

親が頑張らなくても回る形にする。

これはかなり重要な判断だった。

詰まったこと3：減点を入れると制度の意味が変わる

もう一つ大きかったのが、減点をどう扱うかである。
ポイント制度を考えると、ついこういうルールを入れたくなる。

  • やらなかったら減点

  • 約束を守らなかったら減点

  • ゲームしすぎたら減点

  • 宿題をしなかったらごほうび没収

一見すると、ルールとしては分かりやすい。
しかし、今回やりたいこととは違う。
今回作りたいのは、行動を責める仕組みではない。
できたことを見える化する仕組みである。
減点や罰を入れると、制度が一気に「管理」や「支配」に寄る。
そうなると、ポイント制度そのものが親子の対立材料になってしまう。
これは避けたかった。
だから、基本方針は明確にした。

加点のみ。減点なし。

やったら増える。
やらなくても減らない。
この方針にしたことで、制度の性格がかなりはっきりした。

判断したこと：目的を「学力向上」にしない

最初に決めたのは、目的である。
この制度の目的は、学力向上ではない。
もちろん、結果的に勉強時間が増えたり、生活リズムが整ったりすれば嬉しい。
しかし、それを主目的にすると、親は成果を見たくなる。

  • 何ページ進んだか。

  • 何点取れたか。

  • どれだけ勉強したか。

そうなると、評価の目線が強くなる。
今回の目的は、そこではない。
目的は、自己効力感の回復 である。

自分でもできた。
今日も少し進んだ。 やったことが残っている。

この感覚を作ることを、まず優先する。
だから、評価するのは成果ではなく行動にする。

```mermaid
flowchart LR
    A["成果を評価する"] --> B["点数・量・達成度を見る"]
    C["行動を記録する"] --> D["できたことを残す"]

    B --> E["プレッシャーになりやすい"]
    D --> F["自己効力感につながりやすい"]
```

この整理で、制度の方向性がかなり決まった。

判断したこと：いきなりアプリ化しない

自分はアプリ開発にも興味があるので、最初はAndroidアプリ化も考えた。
しかし、最初からアプリを作るのは危険だと判断した。
理由は、制度そのものがまだ固まっていないからである。
制度が固まっていない状態でアプリを作ると、あとから必ず作り直しになる。

  • ポイント単価を変える。

  • 行動カテゴリを変える。

  • ごほうび価格を変える。

  • レベル設計を変える。

  • アイテムの扱いを変える。.

こうした変更が大量に出る状態で、いきなりアプリを作ると、実装が制度変更に振り回される。
だから、順番を決めた。

```mermaid
flowchart LR
    A["紙で試す"] --> B["Notionで管理する"]
    B --> C["LINE Botで報告する"]
    C --> D["アプリ化を考える"]
```

  1. まず紙で始める。

  2. 紙で体験を確認する。

  3. 運用が見えてきたらNotionに移す。

  4. 報告の手間が見えてきたらLINE Bot化する。

  5. 最後に、必要ならアプリ化する。

この順番が一番安全だと判断した。

判断したこと：子ども側のUIと親側の管理を分ける

もう一つ決めたのは、子ども側のUIと親側の管理を分けることだ。
子どもにとって、Notionはたぶん難しい。
親にとっては便利でも、子どもが毎日操作するUIとしては重い。
一方で、親側は記録や集計を見たい。
週単位でどれくらいできたか、どのカテゴリが多いか、ごほうびまでどれくらいかを確認したい。
つまり、子ども向けUIと親向け管理画面は、役割が違う。

$$
\begin{array}{|l|l|l|}

\hline
\textbf{利用者} & \textbf{目的} & \textbf{向いている手段} \\
\hline
\hline
\text{子ども} & \text{行動を簡単に報告する} & \text{紙、LINE Bot、将来アプリ} \\
\hline
\text{親} & \text{履歴や集計を見る} & \text{Notion システム 正確にポイント計算する DB、アプリ側ロジック} \\
\hline
\end{array}
$$

ここを分けて考えると、設計がかなり整理された。

判断したこと：ポイント・レベル・アイテム・ごほうびを分ける

ポイント制度を考えていると、ゲーム要素を入れたくなる。

  • レベルアップ。

  • スタンプ。

  • ポイント2倍。

  • ボーナス。

  • ごほうび交換。

これらは楽しい要素だが、全部を一緒に考えるとすぐ複雑になる。
そこで、役割を分けることにした。

$$
\begin{array}{|l|l|}
\hline
\textbf{要素} & \textbf{役割} \\
\hline
\hline
\text{ポイント} & \text{ごほうび交換に使う} \\
\hline
\text{レベル} & \text{成長の見える化に使う} \\
\hline
\text{アイテム} & \text{一時的なボーナスに使う} \\
\hline
\text{ごほうび} & \text{達成の出口として使う} \\
\hline
\end{array}
$$

特に重要なのは、レベルとアイテムを分けることだった。
たとえば、レベルアップで「常時ポイント2倍」にすると、制度がインフレしやすい。
一度2倍になったら、その後のポイント価格やごほうび価格をすべて調整する必要が出る。
それよりも、「次回だけ2倍チケット」のような消費型アイテムにしたほうが制御しやすい。

```mermaid
flowchart TD
    A["行動する"] --> B["ポイント獲得"]
    B --> C["ごほうび交換"]

    A --> D["条件達成"]
    D --> E["アイテム獲得"]
    E --> F["次回2倍など"]
    F --> B

    B --> G["累積・可視化"]
    G --> H["レベルアップ"]
    H --> I["称号・見た目の変化"]
```

この分離は、後のシステム設計にもかなり効いてくると思っている。

実装・設計への反映

今回の整理は、後続のAdventure Token System設計にそのまま反映する。
まず、行動は「クエスト」として扱う。

行動する
↓
報告する
↓
ポイントが増える
↓
履歴として残る
↓
ごほうび交換につながる

また、ポイントは基本的に加点ログとして積み上げる。
減点処理はMVPでは入れない。
ポイント消費は、ごほうび交換時の明示的な処理として扱う。
紙運用であっても、将来的には以下のようなデータ構造が必要になる。

$$
\begin{array}{|l|l|}

\hline
\textbf{概念} & \textbf{意味} \\
\hline
\hline
\text{行動マスタ} & \text{どの行動に何ポイント付くか} \\
\hline
\text{ポイントログ} & \text{いつ、何をして、何ポイント得たか} \\
\hline
\text{ポイント残高} & \text{現在使えるポイント} \\
\hline
\text{ごほうびマスタ} & \text{何ポイントで何と交換できるか} \\
\hline
\text{交換履歴} & \text{いつ何と交換したか} \\
\hline
\end{array}
$$

このあたりは、後続の記事でDB設計やLINE Bot実装に落としていく。
この記事では、そこまで踏み込まない。
No.1は、あくまで「なぜこの仕組みを作るのか」と「何を大事にするのか」を整理する回である。

関連する技術記事

  • 設計ドキュメント作成フロー：要件→フロー→データ→API→実装の型

  • ゲーミフィケーションの数値調整：ポイントバランスを崩さない方法

今回の記事では、技術の詳細には深入りしない。
Webhook、DB、Notion、TypeScript、制限ロジックなどは、No.2以降の開発日記や技術記事で扱う。

まとめ

家庭内ポイント制度は、ポイント表を作れば終わりではなかった。
実際には、

  • 目的をどう置くか

  • 何にポイントを付けるか

  • 減点を入れるか

  • ごほうびまでの距離感をどうするか

  • 親の運用負荷をどう減らすか

  • 子どもが納得できる形にできるか

  • 将来的にシステム化できる形にできるか

を考える必要があった。
つまり、ほぼ"要件定義"である。
今回決めた基本方針は以下だ。

  • 目的は学力向上ではなく、自己効力感の回復

  • 加点のみ、減点なし

  • 親が頑張らないと続かない設計にしない

  • いきなりアプリ化せず、まず紙で試す

  • 子ども側のUIと親側の管理を分ける

  • ポイント、レベル、アイテム、ごほうびを分けて考える

ここから、Adventure Token Systemとして少しずつ形にしていく。
次回は、今回整理した家庭内ポイント制度をもとに、
LINEで行動を報告し、ポイントを付与し、ごほうび交換までつなげるAdventure Token System構想 について整理する。

いいなと思ったら応援しよう！