---
# System prepended metadata

title: 15 イテレーション01 計画ゲーム
tags: [FUN, りとるme]

---

###### tags: `りとるme` `FUN`

# 15 イテレーション01 計画ゲーム

> [time=Tue, 10, 08, 2021] [name=小林陽昭]

---

## 今日までの課題

フロント：フレームワークの調査

iOS:
- swift ui
- UIkit
  - https://developer.apple.com/tutorials/app-dev-training#uikit-essentials

Android:
- [調査まとめ](https://hackmd.io/t27_RgIFRYmDRm8qu1j3dQ?view)
- サーバーサイドもかける
  - Spring Boot
- 軽量
  - Javalin
  - Jooby

バック：SQL，Go言語，Dockerの調査
- SQL：無料資料があったから勉強中
- Docker：今週入れてみる
- Go：SQL操作の方法を調べ中

デザイン：アプリのワイヤフレームの調査
いない

ビジネスモデル：類似サービスのビジネスモデルの調査，中間報告のフィードバック共有


- ビジネスモデルについて
  - データマネタイズ：
    - その情報のニーズはどこ？
    - ニーズの調査をしっかりする
  - 子供が天気痛になりやすい根拠となる資料を提示する
  - 予報の確実性
  - アバターだけで子供が言うことを聞くのか
  - 全部の理想を詰め込んだアプリを考える（理想を高く持つ）

- 類似サービスのビジネスモデル
  - 有料会員になって追加機能が使える
    - 頭痛ーる：予報日数が伸びる
    - WeatherNews：天気以外の情報が見れる
    - ninaru baby：
  - アプリマスコット販売の展開
    - LINE

> 〇〇のビジネスモデルを採用すると
> 顧客の反応はどうなのか
> 収益がどれくらい見込めるか

---

```mermaid
  gantt  axisFormat  %m-%d
  title  イテレーション 01 企画書完成
  excludes    weekends
  
  section 全体
  イテレーション 01     :active,  08/10,  08/17
  企画書 ver2          :crit, active,  08/10,  08/17
  today               :crit, 08/10,  24h
  計画ゲーム           :active, 08/10,  24h
	執筆(開発)        :08/11, 08/13 
	レビュー(コードレビュー)	:08/13, 24h
	執筆(開発)        :08/14, 08/16 
	完成 振り返り					:08/16, 24h
```

## 今週やること

### 企画書ver2
- 計画ゲーム(08/10)
- 執筆(開発)(08/10 ～ 08/13)
- レビュー（コードレビュー）(08/13)

---

### 前期の振り返りのまとめ


#### 06/29 コンセプトの変更の確認

体調ぱっと見！親子で不安バイバイ
↓
アバターで体調確認 親子で楽しく対策を


#### 06/29 インセプションデッキ

「天気痛の予測」をするかどうか
> 将来性
> - 天気痛予報がシステム化できるようになったミライで使うから今正確な予報ができなくていい
> - 気圧の変化から予報するための根拠は適当でいい


#### 06/29 花粉症対策

[アレジオンサイト](https://www.ssp.co.jp/alesion/hayfever/forecast/)
によると
花粉症は症状が出る前の薬の服用で症状が軽くなるらしい
> **前日にりとるmeで服用を促すのは効果的かもしれない**


#### 07/09 スキルチェック・WBS・複合マップ

2回目 夏休み終わり

それ以降 毎回イテレーション終わりの振り返りフェーズで


#### 07/09 子供がアプリに抵抗する可能性

中間発表で出た質問
薬飲まされるかもしれないドキドキでアプリが嫌になるかも
> ラジオ体操スタンプ的な報酬があるといいのかも

余裕がないので入れないけど展望としてあり


#### 07/09 Github Projects

まだ使わなくていい


#### 07/13 サービスリリースは難しい

これでOK


#### 07/13 OBがSwiftの課題作ってくれる

夏休みに課題を作ってくれるかも



#### 企画書 完成 (08/31まで)

> wordで書かなきゃならない
> githubで共同編集かoverleaf
>> githubでできるかわからん

> 外部システムがまだ検討中

> 機能も若干確定していない部分がある

-    [去年のサービス企画書・設計書まとめ](https://hackmd.io/@sasakin/B18ev5dhO/edit)

- [githubリポジトリ](https://github.com/miraikeitai2021/LittleMe)

---


### 計画ゲーム
企画書を詰めるうえで必要な議題

#### 06/25 天気痛の中身

紫外線・花粉による症状についてあまり言及してこなかった
頭痛にフォーカスしすぎている気がするけど紫外線・花粉・気圧による症状にするか

[アレジオンサイト](https://www.ssp.co.jp/alesion/hayfever/forecast/)
によると
花粉症は症状が出る前の薬の服用で症状が軽くなるらしい
> **前日にりとるmeで服用を促すのは効果的かもしれない**


> 紫外線・花粉
> 季節的なものだから二の次にしてた感
> 世の中的にメジャーになってるからテレビでもやってる

> 差別化を図るなら全部盛り
> 新しめ

> 入れてきたい 設計書の時にもう一回決める


#### 06/29 インセプションデッキ

親子で楽しく前向きに天気痛の対策をして 親の悩みを減らす

> 後半部分でターゲットが親まで絞られているから親子に広げたい


**決定：
「親子で楽しく前向きに天気痛の対策をして悩みを減らす」**


#### 07/06 アバターの機能をどれくらい作りこむか

フロントの目標
> 子供が理解するようにアバター機能の実装

で

デザインの目標
> 目で見て、音として聞こえる
> 遊びながら学ぶデザイン

をどれだけ実現できるか

- アバターをタッチ
  - アバターが話す
    - 対策情報とか？

#### モチベはどこ？

- アプリが形になってくると楽しくなってくる
- ターゲットからのフィードバックをもらう
- 手動かす


#### 07/06 予報地域：
or位置情報

調べてみて楽な方に決める
> 多分アンケートで初期設定するのが楽

> ビジネスモデルとの兼ね合いでデータとして保存したいから初期設定で入力させたい

**決定：
「アンケートで初期設定」**
> 備考：ユーザ任意のタイミングで地域情報の変更ができたほうがいい
> 旅行の時とかのため



#### 07/06 どうやって評価する？

顧客満足度を妨げていないか
> ユーザーテストはするのか（評価実験）
> あったらいい
> あやふやならなくてもいい

持続的に収益が得られる
> どう評価する？
> > 集客力
> > 利用率
> > 利益率


#### 07/20 企画書決まってない部分

アクティビティ図
- ゲストログインがいるかいらないか
  - メールアドレスでのアカウントの紐づけはいらないかもしれない
    - メルアドの必要性はなんだろう
  - **決定：「メールアドレスの登録はなし」**
- 体調変化予測ボタン
  - アバター表示時に天気痛常態か，ボタンを押して天気痛状態になるか
  - **決定：「ボタンを押して天気痛状態になる」**
    - 子供にボタンを押させることで「遊びながら学ぶ」ができる

- 「予測できる天気痛を投影したアバター情報を取得」
  - **変更の提案**
  - バック「ユーザの地域の天気痛予報を取得」
  - バック「予測した天気痛データをフロントに送信」
  - フロント「取得した天気痛データをもとにアバターの状態を選択・表示」

ユースケース図
- 天気痛情報の取得と対策の提示方法が固まってないから固めないと書けない
  - バックでデータ取得しておいてフロントがそのデータ引っ張ってくる感じ
- ゲストログインを想定していなかったから組み込む
    - **決定：「なし」**

を
> 08/10 の前半に確定させて 後半に修正作業

> 08/13 の前半も使って修正作業完了 後半にレビュー

> 08/17までに直して企画書完成

#### 決まってない理由

イメージがふわふわしてる

- アバターの表示の仕方
  > アニメーション
  > コマ送り
  > 音声

- 対策方法の提示の仕方
  > 対策情報で必要なデータ群
  > どんな提示の仕方か

> 08/10 の前半に確定させる



#### 計画ゲームの詳細

- リリース計画
  > このイテレーションのリリースに必要な要件を決定することに焦点を当てる。顧客と開発者の両方が参加する。
  - 探索フェーズ
    > 顧客が要件のリストを作る
  - コミットメントフェーズ
    > リリースに必要な機能と日付を決める
  - ステアリングフェーズ
    > 計画を調整したり、新しい要件を追加したり、既存の要件を変更・削除できる。

- イテレーション計画
  > 開発者のアクティビティとタスクを計画する。このプロセスでは、顧客は関与しない。
  - 探索フェーズ
    > 要件をタスクカードにする
  - コミットメントフェーズ
    > タスクをプログラマーに割り当て、工数を見積もる。
  - ステアリングフェーズ
    > イテレーションの境界で、計画されたリリース日までの進捗状況を追跡し、調整を簡単に加えられるときに発生します。


---

## 懸念点


---


## 議事録


### 08/13 までの課題

フロント
> アプリ画面のアバターアニメーション．音声再生周りの機能がフレームワークにないか調べる

かんた
> ユースケース図の直し 8/13まで
> overleafの環境整備

バック


法政
> アクティビティ図の修正
アクティビティ図
- ゲストログインがいるかいらないか
  - メールアドレスでのアカウントの紐づけはいらないかもしれない
    - メルアドの必要性はなんだろう
  - **決定：「メールアドレスの登録はなし」**
- 体調変化予測ボタン
  - アバター表示時に天気痛常態か，ボタンを押して天気痛状態になるか
  - **決定：「ボタンを押して天気痛状態になる」**
    - 子供にボタンを押させることで「遊びながら学ぶ」ができる

- 「予測できる天気痛を投影したアバター情報を取得」
  - **変更の提案**
  - バック「ユーザの地域の天気痛予報を取得」
  - バック「予測した天気痛データをフロントに送信」
  - フロント「取得した天気痛データをもとにアバターの状態を選択・表示」


ビジネスモデル
> ユーザ初期設定時のアンケートに必要な情報の調査
> 例：年齢，性別
> 書ききれてない部分は渡辺さんメモ参照

---

## その他
