Someday is someday

今日は佐々木正悟さんのセミナーを受講してきました。

セミナーのテーマは「時間管理」でした。 最初に

どうして時間が足りなくなるのか?

という問いかけに始まり、そして、「うまく時間をコントロールできていない状態」を大きく2つ紹介していただき、あとは、懐深く質問に答えていくというセミナーでした。

眠たくて眠たくてたまりません。 頭も疲労困憊です。

その中でも佐々木さんは

someday/maybeリストを書くのは時間の無駄だ。

と力説していたことが印象的でした。 普段飄々とされている佐々木さんが、熱くなる数少ないトピックです。

この言に関して、納得できそうな経験がありました。 昔、someday/maybeリストを無くしたことがありました。 その後少し時間が経って、無くしたsomeday/maybeリストが無事に見つかりました。 改めてそれらリストを処理してみたのですが、 ほぼ(九割以上)someday/maybeリスト所属のままでした。

一度someday/maybeリストに登録された事柄 issue は、基本的に生き帰ってこない。 特に「**したい」という願望系のものは。 そのように、上記体験を解釈しました。

そのため、自分はGTDのsomeday/maybeリストは「願望の墓場」リストとして使っています。 「願望があることは忘れてはいませんよー」と安心して忘れることができるために。 リストをみれば願望を思い出せるのだから、それはリストに任せておいて、 今ここですべき事柄に資源を振り分けて、一日をまわしていこう、というスタンスでsomeday/maybeリストを使っていました。 まぁ、そこの多くの選手が戦力外通告される予定のファーム、といったところでしょうか。 いきなり、「クビね」ではショックが大きいので、「まずはファーム行って落ち着いてこい。すぐに帰ってこれるさ」と言って、解雇します。

僕は、この一連の処理をタスクに対しておこなっています。 someday/maybeがタスク・プロジェクトの墓場・安置所であることは大いに賛成します。 ただ、

そう思った事柄をメモしなくても良いのか?

ということには自信がなく、メモする場所としてsomeday/maybeリストを使っていました。 だから、一度someday/maybeリストに入ったものは、なかなかプロジェクトになれないのです。 いきなり願望を切り捨てる覚悟と自信とノウハウがなかったので、 「やったほうが好ましい、でも必須ではない」事柄を非アクティブリストのたらい回しにして、 実質的に考えるリソースを与えなければ良い、という手間をかけていました。

佐々木さんはもっと突っ込んでやっていました。

someday/maybe リストに書き込む時間、それ自体が浪費でしょう。

たしかに、someday/maybeリストを達成できるシステマティックな方法がなければ、 "someday/maybeリストは役に立たない"、それは間違いありません。 そこまでちゃんと考えているので、 someday/maybeリストは書かないと聞いて、「なるほどな」と納得した次第です。

この記事を書いていたら、この話は、バイキングスタイルの食べ方と共通点があるように思えてきました。 テーブルを一回りして、あれもたべたい、これもたべたい、と思います。 ただ、それを全部さらに盛ってしまったら、大体の場合、食べきれずにお皿に残すことに成ると思います。 あれもたべたい、これもたべたい、と手当り次第に皿に盛ることが、 これもしたい(いつか)、あれもしたい(死ぬまでに)、と手当り次第にsomeday/maybeリストに追加することと対応しそうです。 そして、佐々木さんは行儀よく、自分が食べられるだけしかお皿に盛らないのです。 更に「いや、家で夕食があるので」と言って、必要でないモノは食べないことを選ぶかもしれません。 自分の体調、栄養摂取の本来の意図を考えれば、それがまだ合理的です。

僕のように、バイキングの際に、「食べないけど、あれが食べたかったとメモしよう」とするのは頭の良い話ではなさそうです。 その食事を食べて楽しむことも、いつものペースを守って静かな満足感を得ることもできません。 書いいている本人ですらそう感じます。 頭悪いですね。

emacs-evernote-mode

EmacsからEvernoteを操作できないか?と考えていたのですが、ありました。 emacs-evernote-mode というものが存在するようです。

現在備えている機能は、

• ノートを開く
  • 存在しているノートをEmacs bufferに展開する
• ノートをセーブする
  • Emacs buffer内での変更されたノートを更新する
• ノートを新規作成する
  • まっさらなバッファを新しいノートとして
  • 現在のバッファを新しいノートとして
• Post region
  • (画像の?)選択範囲を含んだノートの作成
• タグの編集
  • ノートに付加されたタグを変える
• ノートのタイトル名変更
• ノートの削除
• ノートの検索

…基本的な機能は揃っていますね。 これはすごい。

これを利用すれば、EmacsでEvernoteを扱うことも可能になる。 使い慣れたキーバインド、キーレスポンス というのは魅力です。

テストの対象です。活動が活発で、楽しそうなプロジェクトに見えますし。

18分だそうです。

Keep track with Evernote?

Evernoteのニュースレターで Tim Ferriss が「どうEvernoteを使っているか」インタビューされています。 How Tim Ferriss used Evernote to write The 4-Hour Body ちなみにTim はEvernote のアドバイザーになっています。

インタビューでは、

Evernoteがなかったら"The 4-Hour Body"を書けなかった

と言っています。 今回の著書"The 4-Hours Body"では、 様々な健康法、トレーニング法をTim自身の身体で試験し、 効果や身体への影響を紹介しているそうです。 その執筆となれば、まずはTimのデータを取ることになるでしょう。 日々の状態をデータに取り、それをまとめていったようです。 その記録時・執筆時の両方でEvernoteを使っているようです。

Timがアウトプットの道具としてEvernoteを推す理由は

• 時刻が自動的に記録されるから

だとしています。 情報カードに自分で日時を書き入れなくても良いのです。 日時データが自動挿入されることによる利点を、 プライベートな日記の使い方として紹介しています。

Evernoteのクリッピング機能は魅力です。 非常に手軽なので、お世話になっています。 1アクションで少なくとも以下の2つの情報が作られます。

• テキスト
• 日時

それも、どのアプリケーションを使っている最中でも、です。

この後に、

Evernote をEmacsで使えないか?

といったことを考えて、探しながら記事を書けないかと思ったのですが、これで20分です。 23分です。

前振りが長すぎたと言うことですね。

EvernoteをEmacsで使える方法があれば、喜ぶのですが。 最低限はキーバインドで。 できるなら、置換などの各機能やモードでの扱いを。

これで25分です。十分にオーバーしました。

20 minutes blogging trial: I have no extra time. [2011-01-18 Tue]

相変わらずTaskChuteみたいな表を埋めることで、一日を過ごしています。

先日、繰り返しタスクを一度パージしました。 登録したルーティンの数と時間が増えた結果、 いつになっても作業が終わらないため就寝できなかったので。

この状況を僕は次のように認識しました:「やった方が良いこと」を満載した結果、自由に動けなくなった、と。 あれもこれもと装備した結果、で動けなくなったのだと。 だから、「必要なこと」のみをリストアップし直して、もう一度荷造りをし直そうと思いました。

まず全てのルーティンを、別のワークシートに移動しました。 ルーティンにまみれて、もみくちゃにされて生活するのが嫌になったからです。 まずは一度、全ての繰り返し作業を取り外しました。 タスクだけが表に残りました。

最初は、生存に必要な項目をルーティンとして追加しました。 睡眠、朝食、昼食、夕食、風呂です。 これに時間を1秒も割かなければ、生活に支障がでるでしょうから。

次に、自分のしたいことを1つ追加しました。 これは、是非とも時間を確保して、時間を使いたい事です。 そもそもこれのために、時間管理、行動管理をしているわけです。 これに時間を割けるだけの資源を割り振るのが、時間管理でのゴールです。

それから、自分に割り当てられた繰り返しタスクを、ルーティンとして登録しました。 これは、仕方がないと考えました。 今後改善するにしても、とりあえず今それが必要とされているものでしたから。

以上3つのルーティンの追加のみで数日回しています。 一日見積最大34時間という、どうやっても無理な状況から、 一日見積最大26時間という、まだ対応可能な状態に近づきました。 達成可能な見通しを得られる時間帯が増えました。

記録に費やす時間も削りました。 記録した内容を利用できていなかったので。

ルーティンの漏れが無いか不安がありますが、まだ致命的な不具合は確認されていません。

これで30分かかったようです。

20 minutes blogging trial [2011-01-09 Sun]

blogger.com 経由でアップロードした画像ファイルの direct link が取得できました。 googleclはwindows版でのコンパイル済みのモノを使っていたので、開発待ちという状況でした。 python の gdata を取ってきて、ドキュメントを見ていくと、 (画素数を指定されていない)オリジナル画像のURLは photo.content.srcで出力されることが分かりました。 こんな感じです。

picasa-direct-url.pyの内容。

#!/usr/bin/python2.5

import gdata.photos.service
import gdata.media
import gdata.geo

gd_client = gdata.photos.service.PhotosService()
gd_client.email = 'change.me@gmail.com'     # Set your Picasaweb e-mail address...
gd_client.password = 'change.your.password'  # ... and password
gd_client.source = 'api-sample-google-com'
gd_client.ProgrammaticLogin()

albums = gd_client.GetUserFeed()
for album in albums.entry:
  print 'Album: %s (%s)' % (album.title.text, album.numphotos.text)

  photos = gd_client.GetFeed('/data/feed/api/user/default/albumid/%s?kind=photo' % (album.gphoto_id.text))
  for photo in photos.entry:
      print 'Photo:', photo.title.text, '\n', photo.content.src

これを起動すると、

path/to/gdata-2.0.13/samples>picasa-direct-url.py
Album: Chemical-X (16)
(snip)
Photo: conventional-way-converting-html2blogger.png
https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjSujdlSS4LJQKZX_vHVzmqgV6_mXcuTGzzL6wdL09XHVRm0SzBuPM8DO4U2XL5knR4yRxU8InB10WoxAA7Lxpuo9Oi0NQNZvskO9c11n3xzMKOhy812WtTy74yhFvR17BkM3li_GBG7eo/
al-way-converting-html2blogger.png
(snip)

長いURLが出力されています。

これで、org-modeでのテキスト作成->emacsからblogger.comへの自動投稿 への道が更に開けそうです。 画像も対応してblogger.comに自動投稿してくれたらそれはとても便利になります。

ただ、org-googlecl.elのみを利用するかというと、それはちょっと分かりません。 現状のorg-googlecl.elで文字列を送る機能を実装して、 画像を挿入したいときには、そのdirect-link のURLを api で取得、それをelispでhtmlのAタグまで整形。 この方法が、一番感性が早そうです。

googleclに画像を含めたポスト機能を求めるのは結構時間が必要になりそうです。 org-mode内でorg-babelを使って生成した画像を含めて、googlclが全部をポストするには、今の情報では足りなさそうだからです。 直リンクするためのアドレスを取得しなければいけません。 その機能をgoogleclが作られるのを待つしかないわけです。 googlecl wikiで探しても、希望は一件のみで、それに対応するチケットが切られていない用です。

Comment by gialloporpora, Jul 23, 2010

Is it possible to have an option to print the url-direct after posting an image on Picasa? I would like to see the direct link to the image that I have posted, better if I could select output format (html, BBCode) to embeed it. Another thing, is it possible to accept also URL (remote images) as input, not only local images?

Sandro

残念なことに何も反応がありません。

ですので、google apiが用意されていて、gdataで操作できるなら、自分で直接やった方が早そうです。 何が知りたいかはもう分かっているわけですから。 phthonはほとんどいじったことがありませんが、まぁ、何とかなるでしょう。。

最初に想像したこと、

XMLのやりとり全てをelispで書いて実現する

という悪夢の様な状況¹と比べれば、よっぽど楽になりそうです。

python勉強時間確保の優先順位が上がりました。 楽しいことを勉強できるのは最高に幸せな時間です。

今日はemacsとblogger.comとの周りの状況を説明するのに、35分もかかってしまいました。 20minじゃないですよね。 全然時間が足りませんでした。

Footnotes:

¹ atom-blogger.elというライブラリがあります。2006年に公開されております。詳しくは@ Blogger 投稿用の Emacs パッケージをご覧下さい。

20 minutes blogging trial [2011-01-08 Sat]

久しぶりに「20分でどれだけのブログ記事が書けるのか?」というタイムトライアルをやっています。 こんなことをはじめたのも、昨日あたりから、

org-mode からのblog投稿がホットなんだ

と頭の中をグルグル回っているからです。

まぁ、今日のスタートはそんなところからです。

CUIの環境が恵まれているわけではないWin環境ですが、 以下の道具を使って、日常の最低限必要なことはできているようです。

• Emacs(Meadow)
  • org-mode
  • ESS-mode
  • YaTeX-mode
• pLaTeX
• R
  • Sweave
• Excel
• Firefox
• Google Chrome
• FoxItReader

便利極まった訳ではありませんが、致命的な不自由をめったに感じることもなく過ごしています¹。 ありがたい限りです。 なんとか普段の作業はそれで済んでいます。

今日は時間を持てて、 個人的に知りたかった blogger API の資料に目を通すことができました。 知りたい機能のapiが見つからなかったことは残念でした。 blogger.comにアップロードした画像の直接リンクを返すapiを探そうとしたのは、探し方として下手だったのかも知れません。 それなら picasa api を調べることで見つかるかも知れない、ですね。 探してみます。

Footnotes:

¹ 相手が使っているソフトを変えてやることができたらどれだけ楽だろう?とかは考えないことにして。

20分耐久テスト-都合とSWOTと時間割引-

今回も性懲りもなく20分だけ書いてみることにします。 やっと書いてみることができそうです。 なんか自分はイベントとかの締め切りがないと動けない人間ということを再認識させられます。 というのも、明日11/14がライフハック研究会Vol.5 コミュニケーション・ハックだからですね。 たぶん、それで焦って今何かを書いている、それも昼休みに。 なかなか変なコトです。 これができるなら、もっと前からも出来たでしょうに。 コンスタントに出来るかはまた別の問題ですが。

さて、 先日のエントリー で

2軸目を見つけられない

と書きました。 が、後で考えてみたら見落としていました。 自分の都合を1軸目、そして2軸目は他人の都合にすれば良かったのです。

で、更に考えてみたら、この考察はSWOT分析になっちゃうんだな、ということに至りました。 なぜかというと、外部環境と内部要因の各条件に対してシナリオを作るということですから。 それを前回のエントリーに焼き直すと、外部要因(=他人の都合)と内部要因(=自分の都合)の各条件に対するシナリオ(=得られそうなアウトプット、怒ってしまいそうな不都合)、を出力することになりますから。

ということを夜散歩しながら気がついて「これは何も新しくない、けどネタにしておこう」と思いつつ随分と時間を浪費してしまいました。 気がついたらあっという間に時間は過ぎているのです。 それも気がついたときにしか気がつけないというのが恐ろしい。 気がつくだけの余裕がないとき、つまり何かに手一杯の時というのは、時間が流されているということ自体すら気がつけていないんですね。 だから「時間が大事」とあちこちで言われるわけです。 で、時間が浪費されていないかをチェックするのですが、その管理コストが問題になるわけです。 「時間に対する行動管理が大事だ」ということに納得して、行動管理・時間管理をおこなおうとするとそれに必要なコストを消費することになります。

ただ、なにかやる気があるときと無いときとでのコストの価値が違うように感じるんですね。 評価に時間的な一貫性がない、と言えるでしょう。 僕はどうも双曲性を持った時間割引率を持っているのかも知れません。 本当にそうだとしたら随分と理解に苦しむ行動指針を持っていることになりますが。 たぶんそれを補正するために、その時点での価値を書き出して自分から離れさせて、後から参照するんでしょうね。

あ、あと4分だそうです。

そういえば、この20分耐久テストではトータル2000文字くらい書いている人が普通みたいです。 僕はというと、 前回のエントリー は大体1700文字くらいでした。 ちょっと頭の回転が遅いかな。 今回は何文字になるんでしょう？ 前回よりももっと少なくなりそうです。 不思議ですね。あらかじめ考えたことをタイプしているはずなのに。

そういえば風邪を引いて散々なめにあいました。 後に引きますし、お肌もぼろぼろになります。 こういうコトを体験すると、やっぱり動きやすい「普段のコンディション」というのはよっぽど良いモノだな、と痛感します。 そのときは、健康維持コストが多少割高になっても納得できるわけですよ。 なかなか現金なモノだと・・・・あ、時間です。現金なモノだと思いますね。

以上20分耐久テストでした。

20分耐久筆記

ただいま20分書き出し訓練をやっています。 初めてです。

これははてなで見て、「お、使えそうなトレーニングだ」と思ってチェックして、自分で試してその効果をチェック使用と思います。

さて、20分間ひたすら何かをしゃべり続けることができるのだろうかとちょっと考えているのですが、これは自分の考える速度、それを言語に直す速度、そしてタイピング速度の直列の処理になっていると考えられます。ですからその3つの作業の中で、作業速度が一番小さいところが、この20分書き出し訓練の処理速度のボトルネックとなります。

この20分書き出し訓練を始めようとした理由というのは、上記のもの以外にももうひとつありました。それは、ブログの投稿数を増やすことです。これなら書き出し20分、情報確認5分、整形＋アップロード5分のトータル30分で1エントリー出来上がるのではないか、という甘いも黒も見です。。を描くのには数時間単位かかったものが少なくなかったので、エントリー作成への敷居を下げようと考えてのことです。

さて、この方法にも問題があります。情報漏洩ですね。 自分の意図しない情報まで垂れ流してしまっている可能性が捨て切れません。 この20分書き出し訓練をやってみると、自分は基本的に垂れ流しですので、情報の取捨選択ができたものではありません。 そのうち研究内容とか生活管理の改善方法とかがごっちゃになることでしょう。 そうすると、意図しない場所、意図しないコミュニティでの個人特定がなされてしまい、ちょっと困ったことになるかもしれません。 Lifehacking.jpのmehoriさんがいうような「ネットに個人を出してその緊張感を活かしていこう」という高みまではまだ到達できていないようです。

そういうことを考えても、まだ「頭にあることを書き出してみる」ということの魅力を捨てきれない、捨て切れなかったのでこのようなテストに挑んでいるわけです。 どうやら、個人特定への恐怖よりも、自分の考えていることを吐き出すこと、に魅力を感じているのかもしれません。 ひょっとしたら、さらに欲張りで、自分の考えたことに対するフィードバックを期待している、それを否定するだけの材料が無いことも認めなければいけないようです。 思ったよりも孤独で耐えられる人間ではないのかも知れません。ひょっとしたら他人からの承認を必要としているのかもしれませんから。

今、残り9分くらいのですが、とうとう筆が止まってしまいました。打鍵がとまってしました。あ、頭がつながりました。

思いつくことに関してただひたすら情報を垂れ流すということは、どういうことか？どういう可能性を持っているのか少し視点を変えて考えてみたいと思います。 先ほどは、「自分にとって書き出すことのメリット/デメリット」という視点で話を進めました。 今度は「Webを介して読む人へのメリット/デメリット」を創造してみたいとお思います。

このブログを読まれる奇特な方がどれほどいらっしゃるのかさっぱりわかりませんが、そして、どのようなキーワードがヒットしてこのブログにたどり着かれた方々がいらっしゃるのかわかりませんが、おそらく読み手としては「検索でいらっしゃった一見さん」と「物好きなリピーター」という分類ができるでしょう。 これでマトリックスの１軸が出来上がりました。

もうひとつの軸を設定使用かと考えていたのですが、思いつきませんね。あれ？ マトリックスを作成して、それぞれの領域でメリット/デメリットを作成できるはずなんですが。

あ、残り３分になりました。犬がやってきて僕とラップトップとの間で寝始めました。 いや、これから散歩しないといけないんですが、寝てもらうと困ります。

話がまとまらないので、マトリックスでの分類はあきらめて、一見さん/リピーターの 2元的な分類で対応しようと思います。

まずは一見さんがこの垂れ流しブログをみてのメリットは、あるでしょうか？ 非常に疑わしい。おそらく無いでしょうね。 デメリットに関しては時間の無駄になることでしょう。もっともキーワードにヒットするかどうかすら怪しいものですが

リピーターの方へのメリットは、僕の頭の生な状態が見れることでしょうか。 万が一興味を持っていらっしゃる方がいたとして。 デメリット

あ、時間切れです。今回はこんな感じでした。 さっぱり論理的にはかけませんね。