例：工数タイマー

• タスク管理
  • プロジェクト・タスクの作成・編集・削除
  • タスクの見積もり工数の設定
  • タスクを行うのにかかった工数・開始日・終了日を自動で記録
• タイマー機能
  • 行うタスクを指定してタイマーを動かす
  • タイマーは一時停止、停止することができ、経過時間をタスクに自動で記録
  • タイマーを0分に戻す
• その他
  • お問い合わせ
  • プライバシーポリシー
  • ライセンス
  • バージョン表記

アプリを出すことを最優先にしたいため、このアプリのMVPを考える必要がある

ちょっと調べてみたら、やることを自動で提案してくれるようなtodoアプリはなかったので、それをMVPに据えたアプリにしたい

• todo管理
  • 名前、見積もり、優先度、期日を指定してtodoを作成する
  • todoは編集・削除できる
  • todoの完了を記録できるようにする
• ポモドーロ
  • 基本的なポモドーロに限定する
    • 「25minスプリント + 5min休憩」のサイクルを繰り返す
  • todoの見積もりを25分間隔でしか指定できないようにする
• コンシェルジュ
  • タスクをやるのに使える時間をユーザに入力させ、その時間で最適なtodoを提案する

1. タスクをやるのに使える時間 = todoの見積もりを満たすtodoが存在する場合

• そのタスクを選択して終了

2. タスクをやるのに使える時間 = todoの見積もりを満たすtodoが存在しない場合

• タスクをやるのに使える時間 > todoの見積もりを満たすtodoが存在する場合
  • 条件を満たすtodoの中で期日が現在の日付から最も近いtodoを選択する
  • 条件を満たすtodoが複数個存在した場合は、「見積もり - 着手した時間」がより小さい方を選択する
  • それでも複数個存在する場合は、優先度がより高い方を選択する
  • それでも複数個存在する場合は、todoを登録した日時がより古い方を選択する
  • タスクをやるのに使える時間から選択したタスクの見積もりを引いた値を、タスクをやるのに使える時間として1に戻る
• タスクをやるのに使える時間 > todoの見積もりを満たすtodoが存在しない場合
  • 期日が現在の日付から最も近いtodoを選択する
  • 条件を満たすtodoが複数個存在した場合は、「見積もり - 着手した時間」がより小さい方を選択する
  • それでも複数個存在する場合は、優先度がより高い方を選択する
  • それでも複数個存在する場合は、todoを登録した日時がより古い方を選択する
  • 終了

アプリの初回起動時に、todoで何を重要視するかを聞いてみて、それをアルゴリズムの判定に活用するといいかも

• パーソナライズしたものには愛着が湧くためそれを利用できる（出典は忘れた）

完了できるタスクの数を最大化したいんなら、このアルゴリズムは不適ではないのか？

• タスクをやるのに使える時間 = todoの見積もりを満たすtodoが存在する場合それを選ぶようにすると、以下のような状況では目的を達成できなくなる

タスクをやるのに使える時間：120min
タスク候補：タスクA（120min）、タスクB・C・D・E（30min）
選択：タスクA（120min）
完了できたタスク数：1
完了できるタスクの最大値：4

• タスクをやるのに使える時間 = 選択したtodoの見積もりの合計を満たすについては部分和問題で判定可能

• 上の条件を満たす組み合わせはナップサック問題が適用できる

• 参考
  https://qiita.com/drken/items/a5e6fe22863b7992efdb

• ナップサック問題が適用できるかどうかは後で検討する
• 多分できなさそうな気がする

• タスクをやるのに使える時間 = 選択したtodoの見積もりの合計を満たす組み合わせが存在するかどうかは部分和問題数え上げ問題を適用して判定できる

• 判定のパターンが以下の三種

組み合わせが存在する（単体）
組み合わせが存在する（複数）
組み合わせが存在しない

• 組み合わせが複数個存在する場合は、組み合わせの中で個数が最大になる組み合わせを最小個数部分和問題を改変して対応できる？

参考
https://qiita.com/drken/items/a5e6fe22863b7992efdb#問題-5最小個数部分和問題

懸念

• 部分和問題によってtodoの組み合わせを選択すると、todoの見積もりしか判定に使われない。
  • 優先度や期日も判定に加えたいがどうしたらよいか
• 部分和問題では条件を満たす組み合わせが存在するかどうかしかわからないため、組み合わせそのものをどうにかして取得しなくてはいけない

コンシェルジュ機能の暫定仕様

• 期日が本日から3日以内のtodo(Aグループ)とそれ以外のtodo(Bグループ)に分けて考える。
• Aグループのtodoは期日が若い順に可能な限りすべて選択する
• Aグループのtodoをすべて選択してもタスクに使える時間が残っている場合は、以下の基準のどちらかに従ってBグループからtodoを選択する
  • 期日までの日数が少ないtodoを選択する
  • 選択したtodoの数が最大になるように選択する
    • 選択するアルゴリズムは最小個数部分和問題を利用
  • どちらの基準を使うのかは、アプリの初回起動時または設定からユーザに選ばせる

参考になりそうなサイトのURL

• https://qiita.com/drken/items/0c7bab0384438f285f93
• https://drken1215.hatenablog.com/entry/2018/02/09/003200
• https://qiita.com/drken/items/a5e6fe22863b7992efdb

コンセプト

タスクの見積もり時間をPDCAを通して改善していく

ターゲット

• タスクを行うのにどれだけかかるかを正確に見積もりできるようになりたい新卒一年目の会社員

ターゲットが抱えている課題感

PDCAの各フェーズでやる必要があること

P

• タスクにかかる時間を見積もる

D

• タスクをやる
• タスクが完了するまでの時間を測る

C

• 見積もった時間と実際にタスクをやるのにかかった時間を比較する

A

• 差が生じた理由を考える

PDCAの各フェーズで抱えている課題感

P

• タスクにかかる時間を見積もる際に前回のActionの内容を思い出す必要がある
  • 何かしらの記録媒体にActionの内容を保存したとしてもそれを参照しなければならない
  • 前回のタスクと今回のタスクでやっている種類が違う場合、そのActionを活かせない場合がある
    • Actionにはどんなタスクに対しても言えるようなものと特定のタスクの時だけしか適用できないものがある

D

• 複数のタスクを並行してやっている際に、時間を計測するのが大変
  • タイマーのつけ忘れ、止め忘れなど
  • 手動でかかった時間を記録している場合は、計算が面倒

C

• 見積もりの予実の差を手動で算出するのが面倒

A

• 差が生じた理由を考える際にテンプレートがあると考えやすいかも

抱えている課題感に対するアプローチ

P

• Actionにタグをつけて、どういったタイプのTask、TodoにはこういったActionがありましたみたいなことを提案する

D

• タイマーを開始する際にタスクを選択させることで、アプリ側で自動でかかった時間を記録する

C

• 見積もりの予実の差の計算はアプリ側で自動で記録したい

A

• テンプレートについてはあったらいいな程度（まだ解決策が思い浮かばない）

実装する機能

• Taskの登録・編集・削除
  • 1つのTaskに複数個のTodoを登録できる
  • 名前が登録できる
  • Taskに登録するTodoを追加・削除できる
  • Taskを削除したらそれに属するTodoをすべて削除する
• Todoの登録・編集・削除
  • 名前と見積もりを登録できる
  • 名前と見積もりを編集できる
  • Todoを削除できる
• Notice(Actioinで出てきた振り返り)の登録・編集
  • Task・Todoが完了したタイミングでNoticeを登録する画面を出す
  • Noticeにはtagをつける
  • Task・Todo1つにつき1つのNoticeを登録できる
  • 1つのNoticeには複数個のtagをつけることができる
  • 一度登録したNoticeを編集することができる
• Notice表示機能
  • 見積もりを行う際にそのTask・Todoのtagに該当するNoticeを表示する
  • いくつかだけ画面に表示して、それ以上は別画面で検索機能を提供する
  • Noticeが存在する場合は「過去のTaskで考えたNoticeを活用してみませんか？」みたいな文章を出してみたい

• TaskやTodoを削除する際にそれらに紐付いたNoticeも消すか消さないか聞くようにする

Task

• taskId(String, PK)
• name(String)
• statusId(int, FK)

Todo

• todoId(int, PK)
• taskId(int, FK)
• name(String)
• statusId(int, FK)
• estimate(int): 分単位で保持
• elapsed(int): 分単位で保持

Status

• statusId(int, PK)
• name(String)

TaskNotice

• taskNoticeId(int, PK)
• taskId(int, FK)
• body(String)

TodoNotice

• todoNoticeId(int, PK)
• todoId(int, FK)
• body(String)

Tag

• tagId(int, PK)
• name(String)

TaskNoticeTag

• taskNoticeId(int, PK)
• tagId(int, PK)

TodoNoticeTag

• todoNoticeId(int, PK)
• tagId(int, PK)

• Task:Todo = 1:n
• Task:TaskNotice = 1:1
• Task:Status = n:1,
• Todo:TodoNotice = 1:1
• Todo:Status = n:1,
• TaskNotice:Tag = n:m
• TodoNotice:Tag = n:m

flutter_social_textfieldのsampleを動かしてみたが、あらかじめ用意してあるものにしか#hashtagのリコメンドが表示されない

新しく追加したhashtagもリコメンドで2回目以降に出してほしい

tag専用の入力フィールドという限定ならflutter_taggingというパッケージが使えそう

iPhone標準のメモのタグの挙動について

• 文字数制限はなさそうだが、20文字以上の長さになると、はじめの10文字と終わりの10文字だけ表示され残りは...になる
• タグのリコメンデーションはキーボード直上に2つだけ横にならんで表示される
• 1つしかないときはキーボード直上中央に表示される

pubdevで調べてみたけど単一のパッケージで対応できているものはなかったので組み合わせ前提で考えたほうがよさそう

1. #hashtagを入力したら、hashtagだけべつのfontStyleにする
2. #hashtagの候補を表示する
3. 新しく追加したhashtagも2回目以降入力する際には候補の中に含まれるようにする

• タグの入力欄とNoticeの入力欄を別にするならflutter_tagging使えばすべて解決できる
• iPhone標準のメモの使い勝手が良すぎるからこれを再現したい

• Noticeへのタグ付けは必須機能ではあるが、付ける方法は妥協してもいいのでは？

• Flutter Taggingのsampleコードが動かないで困ってる

• hashtagableでどうにかできないか見てみる

参考
https://github.com/santa112358/hashtagable/issues/52
https://medium.com/flutter-community/implementing-auto-complete-search-list-a8dd192bd5f6

• どうにもならなそう

• flutter_social_textfieldのここ でリコメンドするhashtagを出すようにしているから、ここの表示にflutter_taggingを組み合わせられないかやってみる

• まずはflutter_taggingの動作確認ができるコードを書くところからやる。
• 20:00までには終わらせたい

最小限のコードどころかimport 'package:flutter_tagging/flutter_tagging.dart';しただけでエラー吐くから
これ使うならこのバグ修正からやらないとヤバそう

• リポジトリを見ていたら同じ現象に対して言及しているissueがあったためこれを読んで見る

https://github.com/sarbagyastha/flutter_tagging/issues/32

• 問題を解決するPRは出ているがマージがされていない
• マージされるまでは以下のようにすればうまくいくそうだ

 flutter_tagging:
    git:
      url: https://github.com/mejdi14/flutter_tagging 

• 本家はnull safetyに対応していないためnull safetyに対応した方をつかうように変更

https://github.com/bradintheusa/flutter_tagging

こいつはflutter_typeahead: 3.2.1（バージョン固定）に依存しているのでバージョンを指定してpub getする必要あり

• とりあえず動かせるようにはなった

• でもこれ新しいタグが2回目以降にリコメンドされてこない
• これは仕様？それともfork元と先で仕様が違う？それとも変な書き方をしているせい？

• 入力に対してリコメンドしてくれる文言が変わるのはいいが、なんかもっさりしてる
• シミュレータ固有の問題か？（実機ならもうちょい早く動く？）

アプリ名はImploop(インプループ)

• PDCAを回して改善していくことからImprove + Loopの造語

• AppStoreとGooglePalayStoreで同じ名前を持つアプリはないから問題無し

• これを参考にする
• NoSQLは正直ぜんぜん理解できていないため今回はRelationalを採用する
  https://docs.flutter.dev/cookbook/persistence/sqlite

複数個のテーブルを作る際には以下の方法でできそう
https://qiita.com/takaking216/items/9a0b9b8349be13369228

UIもへったくれもないけど、Taskの一覧表示とTaskの新規追加を画面でできるになった

このタイミングでテストをぶち込みたい

sqflite公式が用意しているテスト用のモックを使ってみるsqflite_common_ffi

テストは後回しにしてまずアプリの完成を目指す。
正直敗北感がすごい

型の不一致が原因やった

GlobalKey<FormFieldState>のcurrentStateがnullになるのは、以下の条件のいずれかにあてはまるとき

• there is no widget in the tree that matches this global key
• that widget is not a [StatefulWidget], or the associated [State] object is not a subtype of T.

今回は下の方に該当していた。

TextFormFieldではString型しか受け付けないにも関わらず、GlobalKey<FormFieldState<int>>としてしまったためにフォームの現在値が受け取れなくなっていたことが原因

要求

• カウントアップで時間を測定できること（タイマーというよりはストップウォッチみたいな扱い）
• タイマーの時間を取得できること
• pause機能が存在すること

stop_watch_timer

• カウントアップもダウンも行ける
• pause機能もデフォルトで実装されている
• タイマーの時間もhours,minute,secondごとに取得できる

https://pub.dev/packages/stop_watch_timer

simple_timer

• カウントアップもダウンも行ける
• pause機能もある
• タイマーを起動する前に時間を決めてタイマーを動かすことしかできないため、採用できない

https://pub.dev/packages/simple_timer

flutter_timer_countdown

• シンプルで良さげかと思ったが、カウントアップでの計測ができないため不採用

https://pub.dev/packages/flutter_timer_countdown

• 公式でstopwatch機能がAPIとして公開されているので、それを使って実装するっている手もある

https://api.flutter.dev/flutter/dart-core/Stopwatch-class.html

とりあえず、stop_watch_timerを採用することにした。
これでだめなら、APIを使って自前で実装する

ユーザーストーリーを考える

1. Task,Todoの追加
2. Todoの実行
3. Todoの振り返り
4. Taskの振り返り
5. 新しいTask,Todoを追加する際にタグに応じた振り返り内容を表示する

Task -> タスクの名前、タグ
Todo -> Todoの名前、見積もり時間[min]、タグ

タグは「新しく作る」と「すでにあるものを使う」の2種類の方法で選択できる
1行だけの入力ができるTextFieldにタグの名前を入力させる
入力させた文字列に部分一致するタグをTagテーブルから読み込んでリスト形式で表示（リアルタイム）
ソフトウェアキーボードのsubmitを押すとその時点で入力された文字列をタグとして設定する
その文字列と完全一致するタグがTagテーブル上になければ、新規追加する
完全一致するものがあれば、新規追加しない

そのTagをTaskやTodoをこなす前につけて、こなした後に振り返りをやるんだよな

こなした後でやっぱりこのTodoに付けるTagはこれじゃないと感じたらどうする？

振り返りを行うタイミングで変更できるようにするか？

TagをTaskやTodoの内容を抽象化したものの名前をつければ問題無しか？

それならTagよりもTypeのほうが良くね？

Tagは振り返りベースな考え、TypeはTask、Todoベースな考え方

TaskやTodoの「タグ」と聞くと、情報を追加したり補足したりするイメージ
TaskやTodoの「タイプ」と聞くと、抽象化したもののイメージ

タグやタイプを振り返りに付ける理由は、同じようなTaskやTodoをやる際に、過去にやったTaskやTodoの振り返りを活用してほしいからである。

タグやタイプがなくても、全文検索で引っ張ってくればよくね？という考えには、前提として振り返りの内容を断片でも覚えておく必要があるために、すっかり振り返りの内容が抜け落ちていればどうしようもない

タグの存在意義は、振り返りの要約・ヘッダー
タイプの存在意義は、振り返りがどういった種類のTask、Todoから生まれたのかを提示する

同じような種類のTaskやTodo間では、振り返りの内容が共有でき、参考になるといった前提で動いている

• 振り返りの入力ページでTagを入力させていた部分は消す
  • 振り返りの入力だけやる

- Taskに含まれているTodoがすべて完了したら、Todoを追加するかTaskの振り返りを行うかを選択できるダイアログを出す

• Todoを全部やりきったとしてもやっぱりこれも必要となる場合があるから

  • でもそれを許容すると、見積もりもくそもなくならないか？
  • このアプリはあくまで見積もり精度向上させるために、PDCAサイクルをぶん回す補助をするアプリだから
  • 後から追加したTodoだとわかるようにすればいいのか？

• Taskに含まれているTodoがすべて完了したら、Taskの振り返りを行うページに遷移させる

見積もり精度向上には

• タスクを実行可能なレベルまでに過不足なく細切れにする
  • なぜ？
    • あとはやるだけの状態にまで準備しておくことで、タスクをやってる最中にあれもこれも考えずに済み、目の前のタスクに集中できるため
• 細切れにしたものに対して見積もりを行うことで、大きなタスクに対して見積もりをするよりも精度が向上する
  • なぜ？
    • 人間は規模が大きいものよりも小さいもののほうが精度よく見積もりができるため
    • 仮に見積もりを大きく外したとしても小さいタスクに対して割当た見積もりであるため全体的に見たときの誤差が小さくできる

• 素朴な疑問としてバッファはどうする？

• TodoごとではなくTaskに対して最後にバッファを加えるとかするのが定石だがどうする

  • 初回リリースは見送る
  • TaskとTodoをやるのにバッファは必要不可欠ではあるが、実装の時間が足りるかわからん

少なくとも今日・明日で実装
明後日にストアへ出すための諸々準備

であるため実装に使える時間があまりない
前々からやってればこんなことにはならなかったが、サボりすぎた