Tasphを考える
タスク管理があまり上手くないの、ツールを使いこなしてないからでは？mrsekut.icon
割と強めの課題感や苦手意識があるから何か作ってみるか
どういう課題があるのか
既存のものでの不備
工数管理、スケジュール管理がおもんなさすぎる問題
ここを楽しくするのは重要
要件
めちゃくちゃ絞るなら
「優先順位の判断できること」
これが一番大事
これを達成するための手段をいくつか発想してみると良い
いま良さそうだと感じているのはタスク同士の依存関係の可視化
FigJamや紙ではできないこととは
タスクの詳細を書きたいとかではない
タスク同士の関係性を可視化したい、というのが大きい
詳細はCosenseとか別のツールに書けば良い
例えば右サイドバーにリスト、左にノードが表示されるとか
スケールすること
量が増えた時に、全体を可視化しないで済む
関係のあるものだけを見えるようにする
人為的に、機械的に
要求や、機能、解決策といったレイヤ
いくつかの抽象度を可視化で表現する
色、位置、とか
タスク同士の依存関係
いろんな作業のタスクの前提になっているもの、つまり非依存数が大きいものは優先順位が高い、というのは機械的に算出できる
タスク同士のクラスタリング、独立具合
複数の群が出来ていて、その間の結合が薄ければ、別のチームで並行して進められることが明らか
opnionatedにする部分と、道具性をもたせる部分の見極めが大事そう
プロジェクトを分ける機能？
クラスタが自動でできるなら別れる必要はない
色々フェーズある
出力する
発散的に思いつくものをただ出力しまくる
スコープを絞って論理的に出力する
ここはテキストが向いているmrsekut.icon
整理する
抽象度、依存関係を見て整理
位置関係、順序関係
ここは視覚情報、GUIが向いていると思うmrsekut.icon
判断する
論理的に道を考える
優先順位の判断
ほぼ同じような手順を、Nつの対象でやらないといけないこともある
その中でも優先順位はある
多くのものから依存されているタスクが必ずしも最重要というわけでもないはず
例えば、実装におけるdb tableの定義など
コレがないと、画面の開発途中にデータが返ってこない、と思える
しかし、実際はそれをダミーやモックを用意すれば同じことができる
「画面の開発のためにtableが必要」というのはまだまだノイズが多い
画面の開発のために、画面に表示するものが必要、ってだけ
こっちのほうが抽象度が高い
DB、というのはかなり具体的
こういう問題点
工数見積難しい問題は何が難しいのかを突き止めないといけない
相対値にすれば解決するものなのか？と言われると別にそんなこともない
そもそも、工数を厳密に見積もること自体を目的化するのもおかしい
実装するものを減らす、人員を増やす、納期を遅らせるなど
工数の割り振りを自動でやりたい
めっちゃ細かく切ったものに対して自分で降るとか、
相対値と過去の実績を加味して、実時間に変換するとか
togglとかと連携しておいてAIに振らせるとか
予算を出すためであり、予算は工数を元に出すから、とか
他の施策とのスケジュール管理のためであるとか、
これも色々パターンある
納期が先に決まっており、それに合わせて取捨選択することもあれば
叶えたいものをすべてやった時にどれぐらいかかるのかを知りたいとか
そういう目的を1つ1つ検討する
この辺はもっと深堀りできると思う
経営視点みたいなのが必要
この辺はあまり問題視していない
工数と実績がずれること
要は優先順位が判断できていないということも大きい
納期を最重視するなら、そこまでにできることをやるだけ
「見積とズレた」という事実は誰にとってもあまり重要でない
顧客から見れば、最優先で達成したかったことが達成できるかどうかが重要
スケジュール管理
何月何日までにこれを作って〜、という風に最初から予定を立てるのは無謀
良い抽象を発見するまで後回しにできる状態にすべきだし、
必要になるのは依存関係で、Aを作らないとBができない、という関係だけ
ただ、マイルストーンのような物はあっても良いかもしれない
が、別にそれは別で管理すれば良いだけかもしれない
仮説として
タスク管理を行うこと
モジュールを設計すること
道を考えること
とかってかなり強く関係していると思うんだよなmrsekut.icon
タスク同士のつながりを見て、それをヒントにモジュールの設計方針も立てられる
実装の例
イメージ的にはFigJamのようなノードベースだけど、
小さく作るならノードを動かせる必要はない
例えば、でか方眼紙みたいなのを用意して
そのマスに載せて行く感じで良い
そうすれば広がりも見えるし、座標を扱わないで住む
DSLを作るとか
Free Monadとか使って
いくつかの記法を用意して、テキストで書いたものと可視化するとか
優先度が決まるというのはどういうことか？
実装する要件の選択ということだろうかmrsekut.icon
「要件」なのか何なのかわからないけど、どこにも参照していないコアの部分の選択になりそう
例えばこういう依存関係があったとすると
https://gyazo.com/8f36ab800f3df4ff33f9825fe7f38bd0
一番右にある要件を選別することになるかな
この要件は優先的に実装するが、この要件は後回しにする
もしかすると、
この要件自体ももっと分割の余地があるかもしれないし
要件自体が何かを参照しているかもしれない
要件も、例えば課題とか要求とかの手段に過ぎない
その参照先に対する仮説と判断が最も重要ということになる
それ以外の機能とかは別に1手段に過ぎない
追加
分割して作るか
nodeを作って、それを線で結ぶか
これをマウスでやるのあまり好きじゃないんだよなmrsekut.icon
FigJamとかノードベースのものだいたいそうなんだけど
どうにかキーボードだけで完結できないかな
例えば、easymotionみたいに、選択先を記号で表示するとか
単純なものであれば上下左右キーだけで特定するとか
分割
https://gyazo.com/eb6226e1260799c7d19a58b79d0c6283
グルーピング
https://gyazo.com/f602e61b06745ce889a13b47036f49ec
様々な軸で抽象化する
たぶんかなり大事
いろんな方向性を検討するのが良さそう
2種類ある
独立しているもの同士のグルーピング
一時的な、見かけ上のグルーピングということになる
親子関係にあるもののグルーピング
分割の逆
依存関係
https://gyazo.com/f64ea8a872eecd9b93cec0ce82682995
rootを選択すれば、関連するすべてのleafが強調される
それ以外を非表示にすればノイズが減らせる
それが自動的に道になる
leafから順番にタスクを進めていけば良い
工数の合計が得られる
leafの総和が、rootの工数になる
優先度低め
ノードベースである必要がない
ノードをすぐに捨てられるような実装にしておこう
ノードというのはUIの一形態に過ぎない
タスクの構成がわかる
トップダウンに分割ができる
要件と手段の区別ができる
親子関係
タスクの依存関係がわかる
これをやる前にこれをやるべき、というのがわかる
次にやるべきことが自動で構成される
これが一番大きいかもしれない
優先度を何らかの基準で自動で決める、あるいは自分で決める
依存関係や、優先度から今からやるべきタスクの順序を自動で計算して列挙する
それを上から順にこなしても良いし、
モチベーションが湧くものから手を付けてもいい
単に以下のようなモデルがあればいい
タイトル
内容
親タスク
小タスク
配分量
大中小
優先度
大中小
裏テーマ
MVP
道具姓
裏テーマ実装
undo/redo
操作で抽象
依存を可視化するノードのようなものをライブラリとして切り出せば、
他の、依存関係を可視化するやつにも使えるかもしれないmrsekut.icon
アイディア
作らなくても、Linearかなにかそういうものを見たり使ってみたりした方がいいかも
こんなもんAIにやらせればよいか
人間が計算するのがおかしい
要件、タスク分割、工数の予想を出して、実績を入力して工数をリアルタイムで再計算する
時間が足りなくなったら、方針転換の提案をする
優先度の高いものを終わらせる
優先度の低いものをスパッと切る
あるいは代案を考える
Cosenseがあまり工数管理に合ってない
工数管理のおもんないところをどうにかしたい
いや作らんでもいい
modeling
UI
Node based
分割時の座標
etc.
select
Node管理
エディタ部分の作成
一旦適当なinputでいいや
あとでエディタは作り込もう
TaskNodeのようなものを作る
タスクを箇条書きにできる
分割できる
Nodeを選択した時に依存関係が見える
色を考える
適当に名前をつけたい
task graph
tasph
永続化
save/load
ショートカットキー
copy/page
edgeに向きを付ける
グルーピングできる
スクボのctrlキーでグループを変更できるぐらいの操作性がほしい
ショートカットキーの方向性
特に線をつなぐのが面倒
cmd-z
alt+クリックで複製
hide
不要なものを非表示
undo/redoの方向性
is done
独立したnodeの追加
優先度の把握
工数フル
Edgeを結んだ時に、親子を作る
読む
utlity
examples
hiddenとか
projectを作る
✅bun
✅biome
tailwindの代わりになるやつ
typia
---
react-flow
jotai
CI構成
type check
test
renovate
ts
better-typescript-lib
tsc
とにかく、見た目や機能が終わっていてもいいからドッグフーディングできる状態にしたい
モデルをJotai等で表現できる様にしたい
できるだけreact-flowに依存しないようにしたい
見た目気になるところ (今はやらない)
handleが常に上に出てる
場所を規定する必要はなくて、近いところに出りゃ良い
分割したときのpositionの位置を良い感じにする
Nodeのデータの部分は永続化するかどうかで区別ができそう
例えば、isSelectedとかは永続化対象ではないのでNode内のデータとして持つべきではない