AirFlowから依存関係の世界観を推し量る
有向で閉路のないネットワーク構造
階層など木構造もこれに当てはまる
ノードはタスク
エッジは依存関係
例
例1 A-->B
BはAに依存している
Bというタスクの開始は、Aの状況によってコントロールされる
例2
code:_
C
| +----D <--- E
V |
A--> B <---+
Bというタスクの開始は、A,C,Dの状況によってコントロールされる
Dというタスクの開始は、Eによって……
依存関係ネットワークの処理には、プログラムが必要
人手では無理
上記例2で言えば、タスクBにアクセスしたときに「Dがまだ実行されていません」ってのがすぐに分かる必要がある
なんならDを辿ったときにも「Eが実行されていません」が分かりたい
いちいち手作業で目視で確認するなんてやってられないでしょ？sta.icon*2
それに人手なのでミスもする
仕事の自動化とまんま同じシチュやね
依存関係ネットワークという単位は、「繰り返し実行できるワークフロー」を表現する
特に「一月に一回実行する」みたいな定期性の適用が前提となっている
逆を言うと、一度達成したら終わりなシチュでは割に合わないsta.icon
何度も行う処理を綺麗な依存関係でつくって繰り返し実行できるようにする ← これを整備するコストがかかる
何度も行うからこそ、コストをかける価値がある
一方、タスク管理ってルーチンタスクじゃなければ「何らかの目標を達成するために」やるもので、一度達成したらおしまいになる
ので、いちいちネットワーク構造をつくる旨みがない
ITの自動化と同じ（繰り返さないと旨みがないので自動化せず手でやった方が良い）や……
有効なシチュは？sta.icon
1 ルーチンタスク。特に重いやつ
たとえば月末にやることが多い管理職や主婦がいるとする。月末の2日間で35のタスクを行う必要があるとする。それらは「これをした後にこれをする」みたいな依存が結構入り組んでいるとする。
この場合、ネットワーク構造を綺麗につくる価値がある
つくることができたら「このタスクから始めましょう」「このタスクはこれとこれが終わってないのでまだ始めません」みたいなルールが全部可視化されるので、無駄なく取り組める
計画的あるいは禁欲的になるだろうが、「このタスクはこれとこれが終わったら表出させよう」とかする
そういうのを積極的に、日常的にガンガン取り入れる
たとえば「ボクシングやりたいけど、これはブレイブボードとシャッフルダンスをどちらも楽しんだ後にしよう」とか
こんな依存になるだろう
ブレイブボードをマスターする --> ボクシングを始める <-- シャッフルダンスYouTubeで登録者数1000人
そうすると、あとでボクシングタスクを見たときに「あ、シャッフルダンスまだ終わってねえよな」「じゃあ後で良い」とかすぐにわかる
ただなぁ……sta.icon
凡人大多数のBeing型は「シャッフルは飽きたので、もういいや、ボクシングやろ」とかするのよ
依存関係
A-->B<--Cを例にして、「どうなったら」Bを開始するか、のバリエーションをまとめる
全部成功したら
AもCも成功したら
いずれかが成功したら
A、Cどっちでもいい
両方失敗したら
A、Cの両方がしくじった場合
Bはたとえば「失敗時のリカバリ策」だと考えることができるねsta.icon
両方失敗またはスキップしたら
Aがスキップされた、Cが失敗した
Aがスキップされた、Cがスキップされた
Aが失敗した、Cがスキップされた
Aが失敗した、Cが失敗した
↑ どれでも当てはまる
……
要するに「成功」「失敗」「スキップ」がある
依存元が成功したら開始しようとか、失敗したら開始しようとか、スキップでもいいよとか、いやスキップは認めんとか、そういった機微を上手く反映することで、上手い依存がつくれるsta.icon
役割を分ける
1 依存関係ネットワークという表現
2 Scheduler。1の実行スケジュール（定期性）を制御する者
3 Executor。2に基づいて1を実行する者（実行を制御する者。実際は4にお願いするイメージ）
4 Worker。1を実行する者
---
わかりづらいけど、
ExecutorとWorkerは分かれている。現実でも管理者と担当者を分けたりするのと同じ。
で、Schedulerは、そのタスクネットワークの「あるべき繰り返し頻度」を規定する
タスクごとに締切を設定するようなもの
タスク各々に設定する設定値の一つsta.icon