行動をモジュール化する

過去記事からの質問への回答。

学生と社会人の断絶と生きる目的　コメント欄より
『自分の行動は「気付き」によって、決定される。気が付いたら、オートで実行される。』

気づく→「オートで」実行

ここの展開が理解できませんでした。

だいぶ遠い昔のような気がするけれど、今の考えを書いてみる。

選択するコストの大きさ

基本的にはGTD（後で説明するよ）などの考え方、スケジュールを作る意味と目的を考えていけばわかる。

なぜ、スケジュールを作るか。

普通の考え

一つ目は、予定を忘れないようにするため。
もっと言えば、意識は忘れやすいから、外部記憶に書き出して参照するため。
もう一つは、予定の流れと、実行できた成果の可視化。
つまり、目標にそって予定を立てて、それを実際に実行できたか評価するため。

これが最も一般的だろう。さて、これは何の目的に対して最適化したものだろうか。
一つは人間は、忘れるということ。普通は忘れる。
2つ目は、時系列にそって「目標→実行→評価→フィードバック→目標へ戻る」のフィードバックを使うためだ。

別に間違っていないと思うし、効率はともかく物事は達成できるだろう。だが、この考えはある程度までの仕事の粒度までしか管理できない。つまり5分で終わる仕事が300個あったら、書き出すだけで仕事が終わってしまう。分刻みで管理なんて、秘書でもいない限り無理だし、予定通り終わらせるのは非常に困難。安全率をあらかじめ決めてとっておいたとしても、実際どれくらいで終わるのか分からない仕事はたくさんある。さて、マルチスレッドになりすぎると、この方法がうまく取れなくなる。

何よりうまくいかないから、ストレスばかり溜まってしまう。これは良くない。

GTD(Getting Things Done)の考え

GTDの考えは少し違う。スケジュールというか、BOXを作ってタスクを放り込むわけだが。
説明は他の人に任せておく。
はじめてのGTD
Getting Things Done -Wikipedia

これは、時系列本位ではなく、タスク本位だ。タスクを全部書き出して、脳内メモリから消す。そして、タスクの数だけカード（メモでも何でもいいが）を作る。そして、次にどうするのかという考える事自体を外部モジュール化してしまい、自分は考えない。

これは、外部メモリだけではなく、選択自体を外部モジュールに完全に任せてしまうというやり方。実際にスケジュールを作ってやると一番コストがかかるのが、「次に何をやるか迷う事」である。だから、そこにあらかじめルールを作ってしまうことで、迷う事を省力化することだが、自分の頭の負担、つまりストレスを減らす事だと思っている。

この方法は、多重のタスクに対して迷うことなく実行できるという点で非常に楽だ。また、マルチスレッドにも簡単に対応できる。

自分の考えと方法

GTDにも勿論欠点がある。といっても、バリバリ何年も使ったわけではないので勘違いなのかもしれないのだが。

欠点はいくつかある。時系列の予定に非常に弱いということ。目標と評価の重み付けが難しいということ。直列型タスクに非常に弱いということ。

7つの習慣に書いてあった、手帳のスケジュール管理は、一般的なスケジュールに付け加えて役割（ロールモデル）と大きな石から最初に入れるという手法を使っていた。確かにこの方法は、一般的なスケジュールに対しては有効だが、多重タスク状態にはそれほど役に立たなかったりする。つまり、これから述べる方法は、多重タスク状態で如何にストレス無く、管理を行うかということだ。

7つの習慣-成功には原則があった!

ただ、まだ十分に考証が済んでいないので7割くらいしか完成度が無い。特に時系列スケジューラとしての完成度は低いので、そこのところはご勘弁頂きたい。

３色ボールペン型変形GTD

いま自分が取りあえず使っているスケジュール形式は、３色ボールペン型変形GTDだ。
３色ボールペンとは

三色ボールペン情報活用術 (角川oneテーマ21 (B-43))

で紹介されている。重みのつけ方だ。

赤：客観的に超重要
青：客観的に重要
緑：主観的に重要

というように３色に分けながら書き出す方法だ。かなり何にでも使える方法なので、一読をお勧めしておく。

１日の初めに、まず大きな目標をたて、手帳のスケジュールからスケジュールをノートの左ページに、ジャンルごとに書き出す。勿論そのときに、重要度は色別にする。直列型タスクはインデントしながら書いていく。直列型タスクは、最後まで到達して初めて達成になるので、特に注意が必要だ。３ステップ以上踏む必要があるものは問答無用に、最初から潰して生きたいところだ。

そして、それをひたすら消化しながら、スケジュールを潰していく。終わったらチェックなり、線で消すなりしていく。右ページはひたすらメモや、その関連事項を矢印など使いながら書いていく。

あと、時系列タスクと突発型タスクにも対応できるように、仕事時間の線を引いてそこに矢印を引いておく。突発型タスクは、どうしてもしょうがないので、そのつど対応するしかないが。

外部フィードバックスケジューラ

さらに重要なことに最近気がついたのだけれども。内部フィードバックサーキットは以上で、回るのだけれども。外部フィードバックサーキットは回らない。つまり、人に仕事を渡す事や、報告、人から仕事を請けるなどのときの事だ。これには非常に注意した方がいい。そういうことを自分が苦手だということも勿論あるのだけれど。

一人で出来る仕事は少ない。殆どの仕事は、みんなで行うことだ。そのため、一人でうまくやっていると思っても、組織全体で回らなければ意味が無い。そのため情報の共有と仕事の流れ（誰から誰に）を作る必要がある。組織全体で目標と現状は理解する必要があるし、誰が何をやっているくらいは理解しておく必要がある。ということで組織全体のスケジューラとかGTDが必要になるんだけど。一人だけ変わったことやってると、うまくかみ合わなかったりするわけで。組織のスケジューラを拡張して、自己スケジューラを再構築すればいいのではないかと思うわけでして。

本当は、はてなみたいに、みんなでブログ、ペアプログラミングでやっていければハッピーなのだけれど。実際、それをみんなでやる気になって、行うのは難しいのだろうな。自分はブログを書いているから、どれぐらい効果があるのかは、理解しているつもりだけど。それでも、他の人全てを説得できるかというと、正直難しいわけで。古い風習は、それだけ生き残ってきたのだから、生命力が強く、駆逐するには物凄いエネルギーが必要だ。困ったもんだが、事実ではあるし。

昔よりは、実例も増えているから、導入しやすくなっているのだろうけど。すぐ売り上げに繋がるわけではないし、効果がやってみないとわからない。形骸化しそうに見えるというのが厳しい。あらゆるグループウェアに言える事だけど、そのグループウェアが優れているということと、使えるという事は必ずしも一致しなくて。いっそ、組織の事業にあわせて専用システムを作った方が楽だったりして。

画期的なグループスケジューラを作ってみたいものだ。おそらくそこにあるのは、誰でも理解できる単純さと、入力のコストの低さと外部APIを使った拡張性なのだと思う。人間の意識はそんなに大きくないから、複雑なものは使いこなすのにコストがかかる。理解にコストがかかるとき非常に導入が難しくなる。簡単に理解できて、簡単に使える･･･。お、動的ブログだな。

ダイナミックブログシステム

今思いついた。非常に素晴らしい。後で書いてみよう。