いろいろとやることがあると、次回パソコンを起動したときに忘れてしまっていることがある。RTM で管理すればいいのかもしれないけれど、それはちょっとおおげさだと思うことも。
例えば、翌日、ある Excel のファイル上で作業をしなくてはならないことがあるとする。パソコンを終了する前に、そのファイルを「スタートアップ」に登録しておく。こうすれば、翌日パソコンをつけたときに自動的に起動されるので、絶対に忘れないし、その作業にすぐに取り掛かることができる。他の作業が目に入る前にやってしまうのである。 RTM で「 ○○ の Excel ファイルで作業をする」と書くよりも簡単。
「スタートアップ」フォルダは、以下の場所にある。
C:\Documents and Settings\ユーザ名\スタート メニュー\プログラム\スタートアップ
※ 「スタート > すべてのプログラム > スタートアップ」をダブルクリックして表示させると素早くアクセスできる。
緊急にやることがなくて、今一、何から手をつけていいかわからない。
どのタスクからこなそうか？いずれの課題も、重要度が同じように見える。
どれでもいいから順番に一つづつ処理していけば良いと思える。しかし、そう思えるからこそ、逆に選択できない。 (@_@;)
このような状況のとき、次の 4 つの基準を、5 段階で、素早く・直観的に評価して、意思決定を行なっている。
5 段階評価の内容は、次の通り。例えば、重要度を１点から５点で評価する場合、
重要度以外の基準も、上記と同様につける。
`3’ が「どちらでもない」というように、点数が真ん中に来るようにすればよい。
計算が面倒だと感じたら、3 段階評価にする。
というようなところから評定する。
各タスクごとに評価をしたら、評定値をかけ算して得点を出す。そして、得点の高いものから順に消化していく。
評価値を「かけ算」にした理由は、足し算するよりも、点数がハッキリとバラつくので判断しやすいため。
「得点を変換」の列は、得点を 0 ~ 1 の間になるように、
得点 / 最大の得点
を計算する。
もし、4項目全てに答えるのが難しい場合、「成果」を省くことにしている。
その他、最近では、「法隆寺って、どんな形だったかな？」「椿ってどんな花だったかな？」と思ったときにも使った。
このように、画像検索するときは、人物や建物など、形があるものや特定のものを検索するときが多い。文字情報を検索をするときよりも、良い情報に出会ったり、的確な説明があったりする。画像があることによって、書いてある文章がわかりやすくなるためだ。また、書き手にとってみれば、画像を載せるのことは、文章のみを書くよりも多少手間がかかるので、その分説明に力が入るのかもしれない。
画像検索のコツは、検索した画像の一覧をパッと見渡して、「なかないい写真だな」と思ったサイトを見ることである。たいてい良い説明が書かれている。
画像検索でおもしろいのは、上記のような対象以外を検索するとき。
形があって不特定なもの。一般的な名詞を検索してみる。例えば、いろいろと種類があるようなグッズを検索すると、他の人が使っているものがわかる。思いがけないものが見つかるかも。
では、形のはっきりしない、特定的なものを検索したら、どうだろうか？例えば、場所。
並んでいる写真を見ると、なんとなくその都市を構成するイメージが把握できる。自分の出身地で検索してみてもおもしろい ^^;
次に、対象の漠然としたイメージはあるけれど、形がはっきりしていなくて、一般的なものを検索。
各地の画像に出会える。 ^^ 絵を描くときに、インスピレーションを得たい場合にいいかもしれない。
抽象的な言葉だとどうだろうか？
うーむ、やはり、検索結果に幅がある。
コンピュータのアプリケーションのように、形がない製品はどうだろうか？
知らなかったツールや、解説図がでてきて興味深い。試してみたいものが見つかった。(形がないと言っても、ユーザインターフェイスの部分が、形になるか ^^; )
実際にどんなものがあるかサンプルを見たいとき。
作者はわかるけれど、作品名がわからないとき。
料理が食べたいとき。
画像検索のメリットは、対象がどんなものかわかるということはもちろんのことだが、それに加えて、文字ではすぐにわからないこと、つまり、視覚情報によって、一瞬に把握することができる人間の特性を利用して、検索対象に迫っていくことができることだと実感した。また、検索対象に関連した画像があった場合、文字情報よりも、そちらに注意が向きやすい。そのため、思ってもみなかった事柄に出会える。思考の拡散のためのツールとして活用できると思った。
追記(2008.4.29): 今では、画像を眺めるとき、PicLens | Immersive Views Across the Web が欠かせない。
前回 は、ブログの利用方法が、当初考えていたものから変化してきたことを述べた。メモを書き散らかした集積所から、メモを利用した学習の場へと変化させたい。そのための、概念的な前提を考えた。
今回は、学習のためのツールとしてブログを見たときに、どういった構造を持っているか、意味的なレベルで考えていくことにする。ここで「意味的」というのは、人間から見て有益だと思える情報の単位を対象として捉えるということである。ブログのシステムにおける実装に関心があるわけではない。どういったものが学習に際して有益な情報であり、実際にそれをどのように管理するか考える橋渡しとする。
メモ (一般的に、ブログシステムから見たら「記事」) は、後で検索されることを目的とする。忘れたときに見返すのがメモだ。そのため、検索の手がかりとするために、メモには複数の「タグ」を付ける。
タグは、非常に曖昧な概念だ。使い方によって、意味が変わってくる。メモを分類するためのカテゴリーとして利用することもできるし、メモの中心となるキーワードを列挙することもできる。また、メモの文脈情報を付けると、後で検索がしやすくなったりする。
右図は、一つのメモに対して、複数のタグが付けられ、また、一つのタグに対して、複数のメモが属していることを表現している。 (先に述べたように、タグにはサブタイプを想定しているが、ここでは省略する。)
メモを書いていると、「疑問」に思ったり、「後で考えよう」と思う事柄がでてくる。メモの内容は、一々全ての疑問を調べあげてから書くわけではない。もし、完全に全てのものを明らかにしてから書くとしたら、いつまでたっても書き出せなくなる。
まず、「メモ」は複数の「文」から構成されている。
「疑問」「後で調べる」の目印をつけるのは、特定の「文」に対してである。
メモは、前回のメモの続きを書いたり、後で読むときに同時に参考にするとよいメモを指し示したいことがある。メモは単独で存在するのではなくて、メモのネットワークの中に関連付けられて存在する。つまり、メモとメモの間には何らかの関連が存在し、それを記録することによって、トレーサビリティを高めることができる。
下図は、ある一つのメモが、複数のメモに関連付けられる可能性があることを示している。
メモがたまってくると、特定の視点からまとめたくなってくる。例えば、GIMP のことに関して書いてあるメモがたまってきたとする。そうすると、GIMP という一枚のページから各メモを俯瞰できるようにしたくなる。タグで 「GIMP」 とついているメモを抽出してもよいが、タグによる抽出 (検索結果) では個々のメモが独立していて、情報の流れ・幹というものが存在しない。また、情報へ辿りつくまでのスピードも落ちるし、トレーサビリティも落ちる。そして、メモの知識が頭の中でつながりを持った状態にもなりにくい。そのため、メモの知識を構造化するための「まとめ」のページが必要になる。
下図は、「まとめ」のページが、複数のメモに対してリンクしていることを示している。また、逆に、一つのメモは、複数の「まとめ」ページからリンクされる可能性がある。
「まとめ」同士のつながりは、「まとめ」と「メモ」との関係とは異なる構造になるように考えた。「まとめ」と「メモ」は、ネットワーク構造になっている。ネットワーク構造というのは、全体の構造を理解する場合、把握するのが難しい。ネットワークを辿る経路が複数存在してしまうからだ。これに対して、例えば、ドキュメントのようなものは、目次があり、章があり、個別の説明がある。これはツリー構造だ。部分は、一つの上位概念にのみ所属し、複数の上位概念には所属しない。これにより、部分へ辿りつくための経路が少なくなる。
ある情報が、全体の中でどのように位置付けられるかという情報によって、個別の理解が促進することがある。上記の「まとめ」は、一連の「まとめ」の構造において、ツリー構造となるように考えた。ある「まとめ」は、ある一つの「まとめ」に所属するが、複数の「まとめ」には所属しない。なんでもかんでも好きなように分類できる余地を排除し、分類同士は排他的になるように括っていくという制約をつける。
メモを書いていると、「これに続く内容を考えて、後に続けたい」と思うことがある。「メモに続きが存在する」という意味ではなくて、「このメモから続けたい」という意思だ。往々にして、これを頭の隅にだけ入れておくと、いつの間にか忘れ、考えていたことすら思い出せなくなる。先に、「疑問」「後で調べる」という目印を付けることを考えたが、これと同じように「続きを考える」という目印を、文に対して付けるようにする。
下図は、「疑問・後で調べる」と「続けたい内容がある」を「目印」のサブタイプと考え、それを特定の文に指定すると考えた。
メモに、関連する言葉をたくさんタグ付けていると、タグの間の関係を規定したくなる。先に述べたように、カテゴリー、概念の類似性などを表現したい。これにより、タグから対象のメモへのトレーサビリティを高め、知識の構造化を促進させる。
そんな繰り返しによって、やめどころ、切り上げるタイミングを逃している状態。
ネットが発達したことによって、わからないこと、気になることはすぐ調べることができる。便利な反面、どこまでも深く潜っていけてしまう。誰かがそれを外から眺めていて、辿っている方向が正しいのか、そうではないのか教えてくれるなら、何の問題もない。しかし、そんな都合のいいエージェントはいない。
ブラウザは、通常複数のウィンドウ、タブを開くことができる。そのため、
これには際限がない。
そこに罠がある。いつでも、もう少しでわかりそうな気がする。
「あの一つさえクリアできれば、全てうまくいくはずなのに...」
そんな誘惑になかなか勝てない。現実は、一つクリアしても、次の問題が見えてくることの方が多い。早めにキリをつけ、頭を休めた方が良い。無理をして我慢して続けているも、トータルで効率がいいと思う。
目的は、方向の定まらない、回りだした歯車を止めること。
「もうちょっとで...」
という誘惑に負けないようにしなければならない。
そのためにはどうするか？
かけている時間の割には、成果が上っていないことは、往々にしてある。他のやらなくてはならないことと天秤にかけ、時間に対するコスト意識を呼び覚ます。
ただし、問題を放置するわけではない。 GTD であれば、粒度に応じて「プロジェクト」にしたり、「アクション」にしたりする。当分できそうにない、または、見たくないと思ったら、「いつかやる」。未来のある時点で、再度考えるということをスケジュールしておくことによって、できなかったことに対するストレス緩和させ、「やめれない症状」を抑える。
詳細に書こうと思うと面倒になり、「もうちょっと」という気持ちを抑えられなくなる。この点に注意。
その中で、自分だけでは解決できない要素が、どのくらい含まれていたのか、また、不確定な要素がどのくらいあったのか考える。これにより、できなかった原因を、不当に自分に帰属させるのを回避する。
最後に、やばそうな悪循環にはまりつつあるとき、上記 1 ~ 4 を実行することを思い出す。 (すぐに忘れる... ^^; )
追記 (2011.10.25) : この記事、書いたの忘れてた。
シンプルなものは継続しやすい。継続しやすいものは習慣になる。
「バブルマップ」もそんな手法の一つ。Life Hacks PRESS ~デジタル世代の「カイゼン」術~ で紹介されていた。
バブルマップの手法は極めてシンプル。方法も、普段行っていることから、それほどかけ離れていない。これまで、メモ帳に、やることを箇条書にしていたことを、項目ごとにバブルで囲むだけ。
デジタルなツールを使わず、紙と鉛筆があれば実践できる。やることがわかりやすい。ツールとして、複雑になる恐れがなかったので、読んですぐにはじめるようになった。
丁度その頃、RTM を使ってタスクを管理を試みていた。しかし、
一つのツールで全てを賄おう
と欲を出したために、使用方法 (ルール) が複雑になり、使うのをやめてしまった。
「バブルマップのすすめ ～ ストレスすっきり解消型ToDo管理手法 ～ | IDEA*IDEA」 の使い方を参考に、実際にバブルマップでタスク管理してみた。
「いやーな感じがするToDoは大きく、そうでないToDoは小さく」バブル形式で書いていくのだ。これを朝につくってその日の終わりにレビューする。...
大きなバブルを消したときは自分の頭の中まで実にすっきりする。...
しばらく続けていると、でかいバブルを消せずに、居座られているのを見ることがストレスになった。なかなか消せないので、スッキリしない。
そこで方針を変更した。
「いやーな感じのするバブル」は、たいていやることが、色々と含まれている。これを、他のタスクから少し離して書いておき、
この方法でバブルを少しずつ消していくと、つまらないタスクでも、終えると「やったぞ！」という気になる。
そして、攻めるべき「敵」、つまり、嫌なバブルを、徐々に後略する感じが、視覚的に把握でるようになった。これが意外によかった。
バブルマップのテンプレートは、
を利用することができる。
このテンプレートは、左上に日付があり、用紙の下の部分は、以下のことを書く。
その日にやらなくていいもの、小さすぎるバブルになるものは紙の下部1/5ぐらいを使って普通にリストで書いている。それは終わったら普通に線を引いて消すことにする。...
(同上 より)
自分の場合は、日付と用紙の下の部分は使わず、バブルだけを書くことにした。
また、やることがあったら、すぐに書き込めるように、キーボードの手前においても邪魔にならない大きさにした。 A4 の用紙を半分に切り、それを三等分にした大きさを使っている。
バブルは、早く消すことができるものあれば、そうでないものある。そこで、
ようにした。これにより、タスクの用紙が、たまり過ぎることはなくなる。
嫌なことは、目の前から消す。かと言って、どこかにやってしまわないように管理しているから、なんとなく安心できるところがいい ^^
まず、左右均等になるようにマフラーを首にかける。
左右どちらか一方を顔に沿って巻く。このとき、耳をかぶせるようにすることがポイント。
反対側も同じように巻く。
出ている部分を中に入れる。
完成！
一度巻いたら二度と外せなくなる暖かさ。。。(@_@;)
※ このまま外出するのは控えましょう。
当初、このブログは、後で思い出せないときのために、作業内容をメモしておく目的ではじめた。忘れてしまったり、わからなくなったら、検索して情報を探せばよい。 個別情報の集積所のように考えていた。
メモを書き出していると気がつくことがある。後で読んで自分が理解できるような文章にしているのだが、文章化する前の「走り書き」、「簡単な手書きの図」の説明は曖昧な点が多い。サラサラと書いているときは、どこにも整合性に誤りがないように思える。しかし、いざ書き出すとなると、途端に途方にくれることがある。 (@_@;)
 | 発想法―創造性開発のために (中公新書 (136)) 川喜田 二郎 中央公論社 1967-06 by G-Tools |
思い付きを書き散らしたメモや、頭の中にあるから大丈夫だと思っていることを文章にして一連のストリームにしてみる。そうすると、関連した情報を探す必要があったり、派生してアイディアが浮かんだり、考えを進めなくてはならないところが明確になったりする。以前に、KJ法の本を読んだことがあるが、カードの分類と文章化という作業を Web 上で行っているような感じだ。
後で使えるようにと書いているメモの内容は、今のところ基本的な部分をフォローしているに過ぎない。しかし、こういった内容も長いこと使わないでいると、綺麗サッパリ忘れてしまう。 (o_ _)ｏ 書き出すことによって記憶の定着が促進され、忘れたとしても再学習の時間が短かくなることを期待している。 o(^^)o
ブログ - Wikipedia によると、ブログとは、
「WebをLogする」という意味でWeblog（ウェブログ）と名付けられ、それが略されてBlog（ブログ）と呼ばれるようになった。
Log とは「日誌」という意味だ。コンピュータの世界では、機械が付ける一定の書式を持った「記録」という意味で使われる。ログの各エントリーは静的な構造を持っている。しかし、全体としては構造化されていない。 Apache のログも人が解析しなければ、ある特定の構造を持った文字列の集積に過ぎない。アンケートの結果もデータを解釈するための理論がなければ、ただのデータでしかない。「構造化」とは、全体に対する解釈する側の動的な視点のことだ。
さて、このブログはその名の通り、個別情報の倉庫という利用の仕方をしてきた。まさにログである。しかし、メモを書き出している自分という存在は、機械と違って独自の解釈体系を持つ何かである。メモがたまってくると、メモの方から「まとめろ～」という無言のプレッシャーを感じる。 (@_@;) 目の前に表われるものから、何らかの特徴を抽出して認識し、そこにカテゴリーを作ってしまうのが人の性。
タグ付けるという行為は、そういったカテゴリーによって物事を認識する人間の性質に要請された仕組みと言える。ほとんど全てのブログシステムにそのような仕組みが備わっている。従来の紙に書く日記は、「日付」という順序情報しか持たないことが多い。そういった点から見て、ブログとは従来のログという概念ではなく、構造化を志向する仕組みが備わった日記と言える。
人間は、効率的に情報を保持しようとするとき、色々な情報を関係付けたり、不必要なものを削除したり、抽象化することによって、より多くの価値を持つ情報、つまり、適用範囲の広い情報に変換しようとする。より少ない力で大きなものを持ち上げるテコのようなものだ。意味体系を適用しにくい情報を覚えておくことは難しい。ランダムな数字の羅列を記憶することは苦手だ。しかし、人間はそれ以上に複雑なことを覚えておくことができる。知識を構造化することができるからだ。
一週間前の自分は、既に別人であると感じることがある。自分で書いたメモを読んでも、どういう意図で書いたのかわからないことがしばしば。。。ブログを書いていても、下手をすると、気づかずに同じ内容を繰り返しているかもしれない。 (^^; 記事を書く前に、以前に書いたかどうかを確認するのは面倒。そうすると、ある程度書いた内容を頭の中に入れておく必要がある。
ところで、以下の二つの日記の記述があった場合、そこにどんな意味があるだろうか？
2007.1.1
- A は B だと思う。
2008.1.1
- A は B だと思う。
両者は同じことを言っている。内容に関して意味的に等価だ。日付だけが異なっている。日付がどういう意味を持っているのか？それは「1年後、同じことを思った」という情報が表現されているに過ぎない。
では日付をとったらどうか？
明らかに冗長。
データベース実践講義 の「タプルが禁止される理由」の項において、表の中のデータの重複について次のように述べている箇所がある。
テーブル P には <P1, Screw> 行が3 つあるが、それが 2 つや 4 つや 17 でないことにどのような意味があるのだろうか。きっと何か意味があるはずだ。そうでなければ、そもそも何のためにそこに重複が存在するのか。かつて Codd が言っていたように、「もしそれが本当なら、二度述べたからといって真実味が増すわけではない」のである。 (p51)
データベース実践講義―エンジニアのためのリレーショナル理論 (THEORY/IN/PRACTICE)
C.J. デイト Chris J. Date クイープ
オライリージャパン 2006-02
by G-Tools
このブログにおいても、できるだけそのような事態は避けたい。ある事柄に関するメモは一つであり、それが訂正されるとしたら、誤りを改訂するか、訂正を記録し、改変がわかるようにしたい。
「重複」という言葉から、次の言葉を思い出す。
Don't Repeat Yourself (DRY),
これは以下のように解説されている。
also known as Single Point of Truth (SPOT) is a process philosophy aimed at reducing duplication, particularly in computing. The philosophy emphasizes that information should not be duplicated, because duplication increases the difficulty of change, may decrease clarity, and leads to opportunities for inconsistency.
(Don't repeat yourself - Wikipedia, the free encyclopedia より)
重複があると変更が難しくなり、明確さが失われていく。結果として、一貫性がなくなる可能性を孕むということだ。
例えば、ある記事の内容が重複しており、その内容が後で間違いだと気がついたとする。そうすると、重複しているすべての箇所を訂正しなくてはならない。一貫性を保つのにコストがかかってしまう。プログラミングにおいて、重複は最も嫌われるものの一つだ。同じようなものがあれば、まとめる。まとめたものは参照して利用する。メモも同様な方法で管理したい。
作業場というのは、状況に応じて刻一刻と変化する「場」だ。過去の集積場ではない。現時点から見て過去のメモは、絶えず修正の可能性を残し、全体として一つの知識を表現するという使い方をしようと思う。
人は、いくつかのことを同時に考えていると、その「広がり」と「方向性」を見失ってしまう。ある一つのことに集中すると、他が見えにくくなる。一度何かを考えると、以前の思考の流れに戻すことは難しい。考えると同時に、自分の知識構造が変化するからだ。それが人間の思考の特徴なのかもしれないが、不便なことに変化は抑制を生む。溝ができると、その場所以外を水が伝わりにくくなってしまう。
ブログというのは、その抑制を意識化させることができる。過去のものを読むことによって、以前の地点に引き戻され、そこからの眺めを得ることができる。ブログを書いて、自分の関心対象のマップを作り、さらにそこからまた別の道を見つけていく。マップは道が作られると変化し、辿っている自分自身もその変化の影響を受ける。
ブログは単なる静的な知識表現ではなく、書き手と知識表現とのインタラクションによって、こちら側 (思考する自分) と表現側 (ブログ) が同時に変化していくような「場」にしたい。
前置きが長くなってしまった。 (o_ _)ｏ~† しかも、何が言いたのか自分でもよくわからないことに。。。 ^^; 簡単に言うと、単なるメモの集積所ではなくて、学習の場としてブログを利用したいと、ただそれだけ。そんな欲を出したとき、ブログというシステムの枠において、どのような利用の仕方をすればいいのだろうか。以降、これを次の 3 点から考えてみたい。
問題
複数のタスクをこなしていると、各々のタスクからやらなくてはいけないことが連鎖的に派生し、TODOリストがあふれてしまう。タスク管理のソフトを利用したり、メモを書いたりして、管理しようとするけれど、いつも失敗してしまう。
それはなぜか？
分析
1. いつの間にか便利なツールを探すことに始終している。たちの悪いことに、万能のツールをついつい求めてしまっている。「一つのツールで全てを管理できたらシンプルでいいな」と考え、ツールの使用法を工夫することに心血を注いでしまっていた。その結果、ツールの使い方が複雑になり、最終的には管理が面倒になってしまう。手段が目的となってしまった。
2. 前記の「一つのツールで全て」という考え方により、管理している内容が膨大になり、何がなんだかわからなくなってしまっている。
3. 結局ツールを使わなくなり、管理できてないことに対して、フラストレーションがたまる。それを解消するために、未決の問題を先送りにし、新規の事柄に着手する。または、目の前のするべきことを済ませることによって、フラストレーションを解消している。結局、未決の事項は、TODOリストの死骸の山に埋もれていく。
4. そして、何を自分がやっているのかわからなくなる。
5. 手書き、PCの中のメモが管理しているようで、実は散乱している。
対策
...
いかん！
シンプルに行こう。
まずは、手書きメモを収容するスペースを作ろう！
ということで、ティッシュペーパーの空箱をくっつけて作った。メモ用紙は、A4の紙を半分にしたものを横長になる方向で使っているので、こんな形。
有効に使うことができるだろうか。。。
デジタル時計は、時間を把握しにくい。
分単位のスケジュールをこなしていると、後どれくらい時間を使えるのか直観的に見積もることができない。できれば、常に目の前にアナログ時計を置いておきたい。
PC 上でアナログ時計を表示するには、ウィジェットやガジェットと呼ばれる小さなアプリケーションを使うのが良い。
ウィジェット、ガジェット自体に種類がある。
今回は、 Google ガジェットを利用することにした。
時計のガジェットの上で、
常に前面に表示させるには、時計のガジェットを
「ガジェット」聞いて、最初に連想するものは、Mac の Dashboard 。あの綺麗さと存在感は、はじめて見たとき、とても印象に残った。
Google, Yahoo, Windows のガジェットについて、トレンドを調べてみた。
追記（2012/07/05）： 現在では、Windows のガジェットが圧倒的に多い。
