### nishio/🔁AIに長期並列プロジェクトのタスク管理をさせたい 🔁AIに長期並列プロジェクトのタスク管理をさせたい AIに長期並列プロジェクトのタスク管理をさせたい [マルチヘッドねりねりシステム]は必ずしも「[長期並列プロジェクトのタスク管理]」に向いてるわけではない 　っていうか多分向いてない、どんどん散らかっていく 　タスクが複雑につながりあったネットワーク上になっているのを、実行可能な単位に切り分けて行動していくことがタスクをこなすということ 　[ねりねりシステム]はどちらかというとどんどんつなげていってしまう 　効率的に「[タスクをこなす]」すべきかどうかには異論がある 　　[タスクを効率的に処理していくと高速にクソアプリを実装してしまう] 　　[不毛なタスクを効率的にこなしても不毛]なので、ネットワークをまずきちんと作って何が本当にやるべきことなのか判断することが必要 　ねりねりの対象はどちらかというとプロジェクトの目的 　　プロジェクトのタスク管理とは違う 　　プロジェクトの目的は遠くにあるゴール 　　プロジェクトの今実行可能なタスクは目の前1メートルの道 　　今実行可能でないタスクは？ 　　　多分あの辺に道があるだろう、その道を通ることになるだろう、というメモに過ぎない？ ### nishio/不明瞭で長期的なタスクをAIにねりねりさせる 不明瞭で長期的なタスクをAIにねりねりさせる from [日記2023-09-12] 不明瞭で長期的なタスクをAIにねりねりさせる 不明瞭で長期的なタスクをAIに🔁ねりねりさせる 　まず「何をやるべきか」が言語化されないといけない 　多分今のアルゴリズムではネクストアクションの決定支援が足りないと思うが、とりあえずやってみる 　[Polisの解説動画を作る] 　[🌀「ハッカーの遺言状」AI化] やってみた結果 後でリンク 関連 [🔁AIに長期並列プロジェクトのタスク管理をさせたい] [AIがタスク管理をしてくれたらいい] ### nishio/🤖🔁人間とAIが目的を共有する 人間とAIが目的を共有するためには、目的をマイクロフォーマットで書くことが有効。Nishioのフラグメント「AIがタスク管理をしてくれたらいい」や「AIとの共同化」からは、人間がタスクの詳細や文脈を見つけ出し言葉にする必要があることが示唆されている。また、「AIとの共同化」では、AIが広い視野を提供できること、また、人間とAIが体験を共有する「共同化」を行うことが重要であることが示されている。 情報の伝達方法については、「書き込む」や「書き込まない方法での伝達」から考察が見られる。情報を手軽に使えるシステムにするためには、書き込みAPIの実装や、情報の自動生成・削除などが考慮されるべきである。 「Nが10~20前後の制約」では、Nの値による計算量の変化が示されている。これは、タスクの量や複雑さによる処理負荷を考慮する際に参考になる。 「技術と問題解決の図」では、技術と問題解決の関係性が示されている。これは、技術選択や問題解決のアプローチに影響を与える。 「エンジニアの知的生産術 全階層目次」からは、タスク管理や優先順位付けの方法についての洞察が得られる。これは、生産性向上のための具体的な手法を提供する。 ### nishio/即座に結果を確認できない改善の回し方 普段、気持ちを持たないコンピュータをマネジメントしているので、気持ちを持つ人間に対して「待ち時間が非効率だから並列でタスクをさせよう」みたいな誤った思考に陥りがち まず全体像を把握しないと、それぞれの修正タスクにどれくらいの時間をかけて良いかがわからない 締め切りにタイトでない仕事をしているとしても、終わりが見えないまま走るのはモチベーションを損ねる デフォルトは「まず全体に目を通して、修正すべき箇所を全てリストアップする」である そのタスクが大きすぎるという場合には「まずは1章全体」のように[量で分割]するのも手 もしくは「今から25分間で修正すべき箇所をリストアップするぞ」という[時間で分割]も手 [エンジニアの知的生産術]の2章で書いた話だ [(1.3.4.3) 時間を区切ろう] すぐ修正したくなるのは、記録をしていないから 記録の粒度は？ 「[寝て起きてわかるか]」 明日の自分にわかるように 適度な詳細度の感覚は訓練によって徐々に身につく やらなければ身につかない 明日の自分がわかる記録があるなら、どのタイミングでも「残りは明日」ができる [https://gyazo.com/fc6a8b16c96626f7f3024b3d38e25966] ### nishio/人間マルチタスクのスタベーション 人間マルチタスクのスタベーション コンカレンシーコントロールの話 長いタスクと短いタスクがぶつかった時に確率的に長いタスクが負けるので 短いタスクばっかりやられてしまって長いタスクがいつまでたっても実行されない っていうスタベーションが起きる、 というのは、 人間のタスク管理で、小さいタスクと大きいタスクがあった時に小さいタスクばっかりやってしまって 大きいタスクが手つかずのまま残ってしまうという問題によく似ていると思った 後者はぶつかってリバートされるわけじゃなく タスク選択のタイミングで一様ランダムではなく大きいタスクを避ける歪みがあることが原因で ということは逆にバイアスを掛ければスタベーションが解決できるのではないか、ってとこまで考えた [マルチタスク]が辛いというケース 表現が曖昧で複数の問題を含んでいるから切り分けが必要 リアルタイムの反応を求められる割り込み(CS用語)が頻発している場合の話は今回はしない 長期的な大きなタスクと、細かいタスクが混在している時に、細かいタスクにばかり時間が取られて大きなタスクが進まないという問題について どのタスクを実行するかを決定する仕組みに問題がある説 ### nishio/マルチタスクをどうすればよいか マルチタスクをどうすればよいか 僕「[マルチタスク]をどう効率よく実行するか」 妻「[シングルタスク]を高速に回せばよい」 僕「暗黙に仮定しているシングルタスクのサイズが違うのではないか」 妻「結局人間は一度に一つしかできないのだからマルチタスクという幻想を捨てよ」 僕「一度に一つしかできなくて、かつ数か月かかるようなプロジェクトが複数ある場合にどうすればよいか」 妻「長期のプロジェクトでも無数の小さいタスクが入っている。できるタスクは1個。」 僕「例えばこの『論文を書く』というプロジェクトについて」 妻「まず何の論文を書くのか明記されていないのが良くなくて『俺はビッグになる！』みたい」 全体像を見通せていないのではないか まず書き出してはどうか どれにどれくらいの時間がかかるかの見積もりができていないのではないか あまり好きではないがガントチャートを書くことによって密集しすぎだとかに気付けるのでは タスクの細分化ができていないのでは タスクの細分化のための時間をmallocしておくべき ### nishio/2015-10-09 それとは別に全然進んでないタスクの方は何が原因か？ これもまた自己顕示欲だ。プロトタイプを作った結果当初の予定ほど上手くいかないことに気づいて阻喪しているのだ。 そしてそれが原因で上手くいきそうな別のプロジェクトを立ち上げることを繰り返して、結果進んでない仕掛かりタスクが増えて、脳のワーキングスペースを食いつぶし、スラッシングが起こる。 自分にはそれらのプロジェクトを並列で走らせられるだけのメモリーが存在しないことを認める、外部記憶に書き出して、一部のプロセスを止めるしかない。 それでどのプロセスを止めるのか。短期的なタスクばかりやっていたのでは長期的タスクが全く進まないぞ、とバインド再び。 自分が長期的視野に基づいてタスクを進めることができない無能であることを認めるしかない。そこを認めないから両方やろうとしてバインドに落ち込むのだ。 馬鹿になって短期的タスクに取り組んでやっつけ、数を減らしていく必要がある。