本書は、大きく分けると二つの内容から成り立っている。

一つ目は、「数学的思考に基づく営為は、今後もコンピュータによって置き換えられることはない」という主張である。著者はまずこの主張の根拠を説明するために、コンピュータが計算を行う原理から説き起こして、数学とは何か、数学的思考とは何かについての解説を行う。本書の第1〜4章が、主にこの内容に充てられている。

二つ目は、 著者独自の教育論である。こちらは主に第5章で語られているのだが、客観的な根拠に基づく主張と言うよりは、むしろ経験や主観を背景とする”信念”に近い。

……

本文の構成や、語り口の熱さから見て、著者がこの本を書くことになった最大の動機は、明らかに後者の”教育的信念”に由来している。それは裏を返せば、「仕事を奪われる」という危機感は、著者自身のものではないということだ。著者はあくまで教育者として、子供たちの将来の仕事を心配しているだけなのである。

しかしそういった、悪くいえば当事者意識の薄さが、前半の内容にはプラスに働いている。そもそもまず、「コンピュータがホワイトカラーの仕事を奪う」というテーマに対して、計算機工学の基礎から始めるという発想自体が非凡である。現に危機を感じているような立場からは絶対に出てこない、遠回りのようでいてこれ以上ないくらいに正しい、そういう王道ルートである。そしてその内容も素晴らしい。常に自身が「教える立場」であることを意識しているためだろう、内容の娯楽性に引っ張られて妙な寄り道をしたり、専門外の分野に対して知ったか振りをすることもない。 控え目で、冷静で、誠実だ。

その冷静沈着な語り口を知っているが故に、第5章で教育について熱っぽく語る様は、ある種、異彩を放って見える。しかし同時に、妙に納得もするのだ。「ああ、これだけの熱情があったから、これほどの書物を書き上げることができたんだな」と。 そういう有様こそが、コンピュータには決して置き換えられない、人間の仕事の一つの形なのかもしれない。

だいぶ間が開いてしまったが、前回の続き。

OmniFocus が単なるTODOアプリと一線を画すのが、「プロジェクト」と「コンテキスト」の2つの表示モード(パースペクティブ)を持つことだ。プロジェクトもコンテキストもGTDの用語なので、常にGTDを意識して使っていれば自然と使い分けられるのだが、GTDそのものが初めてだと混乱しやすい。

というわけで、今回と次回は、2回に分けてプロジェクトとコンテキストについて説明する。今回は主にコンテキストについて。

OmniFocus for iPhone
カテゴリ: 仕事効率化
価格: ￥1,700

プロジェクトもコンテキストもアクションの属性

プロジェクトもコンテキストも、画面で見るとちょうどフォルダのように見える。 だからついアクションをその中に入れて、「整理する」ような感覚で使ってしまいがちだが、それだと本来の意味からは少しズレる。GTDの観点からいうと、どちらもアクションの属性、付加情報だと捉えた方が正しい。つまりプロジェクトやコンテキストが独立して存在するわけではなく、あくまでもアクションに付随する情報、という感覚だ。

簡潔に言うと、アクションを実行しやすくするための付加情報がコンテキストで、レビューしやすくするための付加情報がプロジェクトである。

コンテキスト

コンテキストとは、そのアクションが「どういう場所・状況なら実行できるのか」を示すための情報だ。コンテキストは、必ず全てのアクションに対して設定しなければならない。設定しないと、そのアクションはinboxに残ったままになる=実行可能とは見なされない。

OmniFocusの「コンテキスト」メニューを辿ると、コンテキスト毎に分類されたアクション一覧が見られる。つまり自分が「今」いる場所・状況を選べば、「今」実行可能なアクションだけが表示される。あとはその中から、実行したいものを選んで行動に移せばよい。これがOmniFocusによるGTDの、最も日常的な流れである。

コンテキストの階層構造

コンテキストは階層化することができる。例えば次のように：

• 外出
  • X駅前
  • Y繁華街
  • 本屋
  • …

この階層構造には、「これが正解」というものはない。既に述べた通り、コンテキストの存在それ自体には大した意味はないので、とにかくアクションが実行しやすいように作れば良い。そしてもし使いにくいと感じたら、躊躇わず構造を変更しよう。

例えば私の場合、在宅で仕事をすることが多いので、最初は「自宅」コンテキストに仕事もプライベートもごちゃ混ぜに入れていた。しかしこれは非常に使いにくい。仕事中にプライベートのどうでもいいことが気になったり、オフの時間に締め切り間近の仕事が見えてしまったりする。そこで「自宅」コンテキストを分割して、仕事用とプライベート用、2つ持つことにした。物理的には1つの場所でも、内面の状況で2つに分けることもできるわけだ。

「連絡待ち」コンテキスト

GTDで言うところの「連絡待ちリスト」を実現するのに、私は「連絡待ち」コンテキストを使っている。誰かの仕事が終わるまで実行できないアクションには、この「連絡待ち」コンテキストを割り当てておいて、「完了したよ」と連絡があったら、改めて正しいコンテキストを割り当て直す。

他に「連絡待ちリスト」を表現する方法としては、OmniFocus独自の概念である「保留中」を使う方法もあると思う（プロジェクトやコンテキストの編集画面の「ステータス」で設定する）。しかし個人的には、「保留中」は何か理由があって進行不能になった場合に使うもので、連絡さえあれば実行可能な「連絡待ち」を表現するには不適当だと考えている。

複数のコンテキストを割り当てたい？

例えばブログを書く場合、自宅でMacを使って書いても良いが、外出先でiPhoneを使って書いても良い。つまり「ブログを書く」アクションには、「自宅」と「iPhone」両方のコンテキストが該当する。しかし、OmniFocusではコンテキストは一つしか割り当てられない。さあ困った。

実は簡単な解決法がある。外出先で「自宅」コンテキストを見れば良い。自宅でする作業の一部は、iPhoneでできるのだから、自宅コンテキストを見るのは完全に正しい使い方だ。

もちろん、外出先で自宅コンテキストを見れば、本当に自宅でしかできない作業も目に入ってしまう。それは本来GTDでは避けるべき状況である。しかし、当たり前の話だが、完全なコンテキスト設定などできるはずはないし、目指すべきでもない。繰り返し書いてきたことだが、GTDにとって最も重要なのは行動に移すことで、正確に整理整頓することではない。

将来、OmniFocusが複数コンテキストをサポートする可能性はなくはないが、私自身は合理的な制約だと感じている。

次回は今回の続きで、プロジェクトについて説明します。

本書は、統計分析の活躍を語る本である。特に、様々な意思決定に用いられる統計分析を「絶対計算」と呼んで、それらがどれだけ多くの分野で、どれだけ大きな成功を収めてきたかを、実に誇らしげに語っている。何しろ著者自身が、第一級の”絶対計算家”の一人なのだ。その強い自負と責任感が、文の調子からも伝わってくる。

絶対計算の台頭によって、人間の経験や知識や直感、そしてそれらを売りにしていた専門家たちは、意思決定プロセスの現場から弾き出されてしまった（あるいは、弾き出されつつある）。本書は、専門家たちに対する、絶対計算の優位性を、これでもかというくらいに語る。その様は爽快ではあるし、頭では正しいと理解できるけれども、やっぱり、空恐ろしさを感じずにはいられない。なぜなら、ごく普通の意味での「意思決定」とは、「自分の経験や知識や直感をもとに、専門家の意見も聞いて、自分で何かを決定すること」に他ならないからだ。

私は今、この本の感想をiPhoneで書いている。多くの人に読んで欲しいと思って、文章を推敲している。あなたはこの感想を読んでいる。きっと、何か有益な情報が欲しいと思って読んでくれているのだと思う。しかし私たちの行動は、ともに目的に対してベストではない。より適切な行動は、統計分析が知っている。

人間の直感に基づく意思決定は、全く当てにならない。本書にはそんな事例が、山ほど出てくる。「でも、絶対計算の結果を専門家の代わりに利用すれば、より良い判断ができるってことでしょう？」という、”直感的な”期待すら裏切られる。ほとんどの場合、何も考えずに、ただ統計分析に従った方が正しい。

しかし本書は、人間の直感の価値を否定する本ではない。例えばワインの事例。どのような気象条件が揃えばブドウが美味しくなるのかは、昔から経験的に知られていた。その背景にあったのは、ごく自然な、直感に基づく推論だ：「夏の気温が高ければ、実が良く熟して酸味が抜ける。雨が少なければ、果汁が実の中で濃縮される」。著者らが行った無線式車両盗難防止装置の調査も、”根拠に基づく医療”を掲げるバーウィックの根拠も、本書のその他あらゆる事例も、そうした例に加えていいだろう。みんな始まりは、ありきたりな直感からなのだ。

だから絶対計算とは、人間の直感にとっては、いわば淘汰圧のようなものだ。淘汰圧がなかった頃は、どんな役に立たない直感も、生き延びることができた。たまたま最初の事例で偏りがあったとか、言い出した人が業界の権威だったとか、全くの誤解だけど理屈だけはもっともらしいとか……いずれにせよ、誰にも間違いを証明することはできなかったから、根拠がないままに信じられていた。そこに絶対計算が登場した。誰にでも分かる形で、直感の本当の価値が示されるようになった。価値のない直感は淘汰された。そして真に価値ある直感、絶対計算という淘汰の力をも利用する直感だけが、生き延びて大きな繁栄を謳歌するようになった。その繁栄の規模は、かつては考えられなかったほどに巨大だ。

無論、この淘汰の圧力は、今後も強まり続けるだろう。コンピュータの処理能力はますます上がり、より多くのデータを、さらに短時間で解析できるようになっていく。人生の多くの意思決定が、誰かの絶対計算の結果によって覆い尽くされていくのだ。そんな世界では、絶対計算家ではない一般の人たちも、統計の基礎的な素養を身につけなければならない。それは不当な扱いから身を守るためであり、同時に自らがチャンスを掴むためでもある。その手始めとして、誰もが使える統計の武器である「2SDルール」と「ベイズ理論」を紹介して、本書は締めくくられる。

補足：プログレッサ計画はバラマキか？

本書の文庫版には追加の訳者付記があって、そこで翻訳者の山形浩生氏が、3章に登場する「プログレッサ計画」に対し、「バラマキ政策ではないのか」と疑問を投げかけている。

要するに、子供が学校に通ったらお金を（それも通常賃金の三分の二というかなりの金額を）あげるという代物だ。所得水準でいえば、日本で小学生に、月に十万円あげるから学校に行こう、と言うに等しい。（略）それだけのお金をあげれば、就学率が上がったり、学校をやめる子が減ったりするのは当然だ。

だがこのプロジェクトの中身を考えると、本当に絶対計算を使う必要があったのだろうか？（略）そしてこれは実は（日本の子供手当など問題にならないくらいすごい）ばらまき政策ではないのか？

これはあんまりな誤読だと思うから、要点を論じておこう。以下の議論は、あくまで本文に何と書いてあるかについての議論であって、現実のプログレッサ計画がどんなものだったかとは関係ない。

プログレッサとは、子供の労働力の市場価値に応じて、親に現金を給付する政策だ。本当に貧しい家庭では、親が幼い子供を働きに出す。親が子供の未来を犠牲にしてしまうのだ。それを防ぐための政策が、プログレッサである。この時点で「日本で小学生に10万円」とは全く違う話だ。

さて、直感的には、子の労働力の市場価値を越えるくらいの現金を給付すれば、問題は解決しそうに思われる。それだけなら、訳者の言う通り、絶対計算など使う必要はなかったかもしれない。しかしプログレッサの考案者たちは、もっと別のことも考えたのだ。「予算はできる限り抑えたい」「給付金が、確実に子供たちのために使われることを、保証したい」。これによって、プログレッサの実施条件は、次のようになった：

• 現金支給額は、子供の労働力の市場価値の、約3分の2
• 支給を受けるには、各種の健康診断を受けなければならない
• 支給を受けられるのは母親のみ

ここまで来れば、もはや成功が明らかな政策とは、言えないだろう。仮に成功したとしても、確かにこの政策のお陰だったと断言するのは、難しいだろう。だからこそ、まず無作為抽出テストを行って有効性を明らかにしたことには、大きな意味があったのだ。もちろん、それが次の政権への引き継ぎにも大きな役割を果たしたことは、本文にある通りだ。

まとめると、プログレッサには、貧困の継承を断ち切るという、明確な目標があった。登校率や各種の健康指標という、客観的に成果を測るための指標もあった。無作為抽出テストで有効性が示されてから全国規模に拡大するという、慎重な導入プロセスをも踏んでいた。それをバラマキではないかと言うのは、流石に違うだろう。

書名の”才能”は「じぶん」と読む。その”才能”の、本書における定義は次の通りだ。

才能とは、無意識に繰り返される思考、感情、行動のパターンである

つまり才能それ自体には良し悪しはなく、使い方次第で強みにも弱みにもなる人格的な偏り、ということである。

どんな才能を持っていてどんな才能を持っていないかは（成人の場合は）変えようがないので、持っていない才能にこだわって弱みを克服しようと必死になるよりは、持っている才能を磨いて自らの強みとし、その強みを活かして生きるべきだ、その方が幸せだし企業の生産性も高くなるよ！……というのが本書の基本的な主張である。

さらに著者らの会社では統計分析を基に、この才能を形作る34種類の”資質”を見出したと主張する。人はそれぞれ、その中の5つ前後を特に顕著な資質として持ち、その組み合わせと強弱が人によってバラバラなので、才能もまた人それぞれ異なる形を取るのだ、と。

その”資質”はストレングス・ファインダーというテストを受けることで実際に確かめることができ、本書を買えば無料で1回受けられる。このテスト目当てで本書を買う人も少なくないだろう。ちなみに私の資質は次の5つだった。

1. 収集心
2. 戦略性
3. 内省
4. 着想
5. 学習欲

こうしたテストは単に「当たってるー！」と喜ぶだけでもそれなりに楽しめるわけだが、真剣に自分の人生を見つめ直す一助として本書を活用するのであれば、2つほど注意すべき点がある。

1つ目。この本自体は基本的に企業のマネージャーに向けた内容になっているということ。ある企業の枠内である人材を最大限活用するには、というのが第一の関心事であり、個々人が（それこそ転身転職を含めた）自分の生き方を再考するというテーマについてはあまり突っ込んだことを語ってくれない。いわゆる自己啓発本を期待していると肩透かしを食うだろう。

2つ目。弱みを克服するより強みを活かすべし、という普遍的な哲学と、著者らが独自に提唱する理論とは分けて考える必要があるということ。特にこれを他人に対する見方にも適用し、良くも悪くもその人に対する先入観として利用するのであれば（それが正式なマネージメントの一環であれ、カジュアルな人間観察であれ）、理論的な根拠にはそれなりに注意を払っておくべきである。

ずばり、この理論は正しいのか。本当に各人に固有で不変な思考感情行動のパターンなるものが存在し、それが著者らの主張するような資質に分解可能なのか。本書における根拠は大きく分けて二つである:

• 神経細胞の連結構造の一意性と不変性
• ギャラップ社が独自に行った200万人分の統計分析

神経細胞の連結回路が加齢とともに減少し、人それぞれ固有のパターンを形成して、一定の年齢以後は変化しなくなるというのは科学的な事実だろう（本当に本当かまでは調べていないが、科学的手法で容易に正否が判断できる類のものなので、著者らを信用することにする）。ただ、その構造が直接、繰り返し現れる変更不能な感情思考行動パターンに対応しており、故にそのパターン=才能も不変である、という部分は多少科学的に飛躍しているのではないかと私には思われる。

またそれが科学的事実だとしても、そのパターンが「34種類の資質に分解でき」「特に顕著な5種類を持つ」ということ、そしてその資質の具体的な内容については、あくまでこの会社独自の主張である。ギャラップ社がその主張をベースにしてコンサルタント業を営む会社だということも忘れるべきではないだろう。

もちろん、この本で説明されている各資質の説明を読み、実際に自分でストレングス・ファインダーを受けて結果を見、自分の経験則に照らして考えれば、かなりな程度”正しそう”には感じられると思う（個人的には自分の分析結果も含め、大いに納得できる点は多い）。しかし単に確からしさだけを問題にするなら、血液型占いにすら信憑性は宿るのだ。

こうした点を踏まえれば、34の資質だとか5つの強みだとかの具体的な内容にあまり捉われすぎるのは得策ではないだろう。本書で解説されている内容およびストレングス・ファインダーで示された結果は、むしろ日々の実践の中で自らの本当の才能――無意識に繰り返される思考、感情、行動のパターンに目を向けるための補助線として活用すべきものだ。ストレングス・ファインダーの分かりやすさについ目が行きがちだが、それこそが才能を見つける王道であると本書にもある（第3章）。

そしてまた、理論面での精確な根拠はさておくにしても、著者らが主張する哲学の面に関しては、自分の生き方や働き方、他人との関わり方を見つめ直すための一種の「問いかけ」として、誰にとっても役に立つものと思う：

• 自分に向いていないこと、弱みを克服しようともがき苦しむよりは、強みに目を向けてそれを伸ばしていく生き方の方が幸福になれるのではないか
• 自分にできないことを率直に認め、他人と協力し合うべきではないのか
• 理解不能な他人の言動にただ腹を立てるよりは、表裏一体の長所に気を向けるべきではないか

VimでCoffeeScriptを快適に書くための環境作り。

• Mac OS X Lion
• Vim 7.3（Lionに標準で入っているもの）
• CoffeeScript 1.2.0

VimはMac標準のターミナル.app上で使用する。Lionからは256色表示に対応したので実用性が高くなった。

ppathogenのインストール

まずvimのプラグインを管理しやすくするためのプラグインであるpathogenを導入する。手順は配布ページに書いてある通り。

mkdir -p ~/.vim/autoload ~/.vim/bundle
curl 'www.vim.org/scripts/download_script.php?src_id=16224' \
  > ~/.vim/autoload/pathogen.vim

.vimrcに次の1行を追加してインストール完了。

call pathogen#infect()

vim-coffee-scriptプラグインのインストール

インストール自体は.vim/bundle以下にgit cloneするだけで完了。

cd ~/.vim/bundle
git clone https://github.com/kchmck/vim-coffee-script.git

タブの設定をCoffeeScriptの推奨値にあわせて変更。次の1行を ~/.vim/after/ftplugin/coffee.vim に追加する。

setlocal shiftwidth=2 expandtab

さらに最も使用頻度が高い:CoffeeCompileコマンド（編集中のファイルをJavaScriptにコンパイルして、結果を別ウィンドウに表示するコマンド）にはショートカットキーを割り当てる。私はC-cに割り当てることにした。以下の2行を ~/.vim/after/ftplugin/coffee.vim に追加する。

" CoffeeCompileコマンドにvertオプションを付けることでウィンドウが縦に分割され、
" splitrightオプションによってコンパイル結果が右側に表示されるようになる
nnoremap <silent> <C-C> :CoffeeCompile vert <CR><C-w>h
setlocal splitright

vim-indent-guidesプラグインのインストール

CoffeeScriptはインデントで構造を表すので、インデント量の違いを見やすくするためにvim-indent-guidesプラグインを導入する。これもインストール自体はgit cloneで完了。

cd ~/.vim/bundle
git clone https://github.com/nathanaelkane/vim-indent-guides.git

gVimで使用する場合はインデントの色も自動で設定されるようだが、私はターミナルで使用したいので手動で色を指定した。色見本はこちらのページを参考にした。

let g:indent_guides_enable_on_vim_startup = 1
let g:indent_guides_auto_colors = 0
 
" indent guides
augroup indentguides
    autocmd!
    autocmd VimEnter,Colorscheme * :hi IndentGuidesEven ctermbg=236
    autocmd VimEnter,Colorscheme * :hi IndentGuidesOdd ctermbg=235
augroup END

最終的な表示は次のようになる。

参考

• vim pluginとgitで強まった開発環境を手に入れよう！〜coffeescript編〜
• Vimテクニックバイブル　～作業効率をカイゼンする150の技

今更こんなことが問題になるケースは稀だと思うが、『パーフェクトJavaScript』の中でも紹介されていたので注意として書いておく。

IE8以前でDOMContentLoadedイベントをエミュレートする方法として、doScrollを使ったハックは広く知られている。例として『パーフェクトJavaScript』230ページのリスト8.9より引用。

function IEContentLoaded (callback) {
    (function () {
        try {
            document.documentElement.doScroll('left');
        } catch (error) {
            setTimeout(arguments.callee, 0);
            return;
        }
        callback();
    })();
}

しかし実際に試してみればわかるが、これだとwindow.onloadより実行が遅くなる場合がある。

テスト1（画像なし） テスト2（画像あり）

具体的には

• 画像など外部から読み込まれるリソースが少ない場合
• リロードした時にキャッシュがきいている場合

こういったケースではwindow.onloadとdoScrollハックの実行順序は逆転する場合がある。もちろん逆転しない場合もある。doScrollハックはあくまでハックであって正式なイベントシステムの一部ではないのだから、一貫した動作をしなくても当然だと言える。

この実行順序の逆転を防ぐために、世の中のライブラリではdocument.onreadystatechangeイベントを併用するのが習わしとなっている。例えばdoScrollハックを世に広めたDiego Perini氏の実装を見れば、trying to always fire before onload というコメントとともにreadyStateをチェックするコードが入っているのが分かる。

document.onreadystatechange = function() {
    if (document.readyState == 'complete') {
        //コールバック関数を実行し、以後はdoScrollハックが動かないようにしておく
    }
};

テスト1（画像なし） テスト2（画像あり）

現実問題としては、わざわざ自前でdoScrollハックを書くような状況では、この順序の逆転が問題になることはまずないと思われる。しかし以下のような教訓を読み取ることはできるだろう:

• 広く知られていようがハックはハック。使うときは慎重になろう
• 可能な限り信頼できる既存の実装を使おう
• 自分の手で実験しよう

UIViewControllerのviewWillAppear:、viewDidDisappear:等のメソッドはviewの表示状態が変化した時に呼ばれるが、なぜ変化したのかという理由までは分からない。つまり以下のようなイベントが簡単には区別できない：

• UINavigationControllerの中で画面遷移が起こった（戻った・進んだ）
• modalダイアログが開かれた・閉じられた
• UITabBarControllerでタブが切り替えられた

今作っているアプリでは特にUINavigationControllerの中で「進んだ」「戻った」といったイベントを検出したかったので、それらをサポートするための抽象クラスを作ってみた（UIViewControllerのサブクラス）。

NavigationSupportController.h
NavigationSupportController.m
（iOS 4.3と5.0で動作確認）

このNavigationSupportControllerのサブクラスでは、viewWillAppear:、viewDidDisappear:等の代わりに次のメソッドをオーバーライドする。

• viewWillAppear:(BOOL)animated direction:(NavigationDirection)direction
• viewDidAppear:(BOOL)animated direction:(NavigationDirection)direction
• viewWillDisappear:(BOOL)animated direction:(NavigationDirection)direction
• viewDidDisappear:(BOOL)animated direction:(NavigationDirection)direction

NavigationDirectionは列挙型で、次の3種類の値をとる。

こんな感じで判定する。

- (void)viewWillAppear:(BOOL)animated direction:(NavigationDirection)direction
{
    if (direction == NavigationBack) {
        //「戻る（= pop）」の場合
    } else if (direction == NavigationForward) {
        //「進む（ = push）」の場合
    } else if (direction == NavigationNone) {
        //NavigationControllerによらない画面遷移の場合
    }
 
    //共通の処理はここに書く
    //つまり viewWillAppear:(BOOL)animated の方はオーバーライドすべきではない
}

検出ロジックの都合上、コントローラのインスタンスはpushするときに作成され、popされるときに破棄されることを前提としている。普通はこれで問題ないはず。

もっと確実・簡単な方法があれば教えてください。

今更ながら、mod_dosdetector-forkをApache 2.0で動かすための方法をまとめておく。少しだけソースコードを編集する必要がある。

必要なもの：

• mod_dosdetector-forkのapache-2.0ブランチ
• Apache 2.2 のソースコード Download – The Apache HTTP Server Project
• ソースコードを編集するためのエディタ（手動で編集する場合）
• Linux（他のUNIX系のOSでも動くかも）

一応、自動で編集するスクリプトも作ってみたが、先に手動で編集する場合の手順をざっと説明しておく。

手順1.

mod_dosdetector.c をエディタで開き、/* code for apache 2.0 */ というコメントが書いてある部分に次の1行を書き加える。

#include "apache20.h"

手順2.

Apache 2.2のソースを展開して srclib/apr/shmem/unix/shm.c をエディタで開き、関数apr_shm_removeの定義部分をコピーして、手順1で編集した部分の直後にペーストする。最終的にこんな感じになる。

/* code for apache 2.0 */
#include "apache20.h"
APR_DECLARE(apr_status_t) apr_shm_remove(const char *filename,
                                         apr_pool_t *pool)
{
//..略..
}

以上で必要な編集作業は終わり。ここまでの手順を自動化するスクリプトがapache20.plという名前で入っているので、これを実行してもいい。

# 展開したApache 2.2のソースディレクトリを指定する
perl apache20.pl path/to/httpd-2.2.x

あとは通常通りのインストール手順でOK。

#apxsが/usr/sbinに入っている場合
#コンパイル
make PATH=/usr/sbin:$PATH
 
#インストール
make PATH=/usr/sbin:$PATH install

動作確認は次の環境で行った。

• ソースコードのコピー元: Apache 2.2.21
• 動作: Apache 2.0.64 on CentOS 5
• 動作: Apache 2.0.52 on CentOS 4

今後どの程度メンテナンスを行っていくかは不明なので、そこは予めご了承いただきたい。あと2.2側のコード変更によっては自動化スクリプトは動かなくなる可能性があるので、そのときは適宜手動で対応のこと。

前回の続き。

GTD本を読んで、OmniFocusを買ったら、いよいよGTDの実践。今回のテーマは実践にあたっての心構えと、OmniFocusへの向き合い方。

全ては行動するためにある

まずGTDの全ては行動するためにあるという大原則を忘れないこと。決して整理分類マニアになってはいけない。GTDもOmniFocusも「気になること」を行動に移すための手段に過ぎない。もしうまく行動に移せていないと感じたら、躊躇わず自分のやり方を見直そう。

OmniFocus一つで全てをまかなおうとしてはいけない

OmniFocusはGTDを念頭に作られた、非常に多機能なソフトだが、決して万能ではない。これ一つで全てをまかなおうとはしないこと。例えば以下のような用途には使えない:

• カレンダー/スケジューラ
• 大量の資料の整理・保存
• 「旅行に持っていくもの一覧」のようなリスト

こういった用途には別のアプリ（もしくはアナログなリスト）を使うべきである。GTDは複数の異なるリストを使い分けることを前提としているので、全てを一箇所で管理する必要はない。

OmniFocusの機能とGTD本の関係

OmniFocusではGTD本に出てくる概念を多少アレンジしているので、 本に登場する各種リストと、OmniFocusの機能は完全には一致しない。本に従ってGTDを実践するなら、この差異をうまく埋める必要がある。

以下に対応関係の例を示す。あくまで私が考えた対応関係なので、他にもあり得ると思う。

この分類に従うなら、OmniFocus を買って最初にやることは

• コンテキスト「連絡待ち 」を追加
• プロジェクト「いつかやる、多分やる」を追加

この2つになる。

「連絡待ち」「いつかやる・多分やる」について

次回以降に詳しく説明する予定。

OmniFocus は誰にも見せない

最後に、とても大切なこと。OmniFocusは誰にも見せてはいけない。

昨今は何でも共有するのが流行りだが、OmniFocusは誰にも見せないものだと常に意識しよう。他人の目を気にするとつい格好つけて、本当は大してやりたくないことを入れてしまったり、本当はやりたいんだけどみっともなような気がするアレやソレを省いてしまったりする。それではGTD本で言う「水のように澄んだ心」にはなれない。

GTDで扱うのは気になること全て。どんなに大それた野望も、ちょっと公にはしたくないような望みも、全てを集めよう。

続き：プロジェクトとコンテキスト・その1

OmniFocusを使ったGTDを始めて1年近くが経った。自分なりに使いこなすコツが集まってきたので、ブログにまとめていこうと思う。これからGTDを始める方、OmniFocusを買おうか迷っている方、OmniFocusのより良い使い方を探している方などの参考になれば幸い。

最初はなるべく大きな話題、基本的な話題から始めて、徐々に細かい使い方の話に移っていく予定。

OmniFocusまたはその他の専用アプリを買うべき？

まずGTDを始めるにあたって、OmniFocusなど専用アプリを買うべきか？結論からいえば、絶対に買うべき。根拠は二つ。

• GTDは、まともに取り組もうとすれば、かなり複雑な方法論である
• GTDの本質は習慣付けや精神論ではなく、システムを構築して運用することである

GTDが複雑であることは否定し難い。GTDでは役割の違う「リスト」を何種類も使い分けて、それぞれを適切に運用して、しかも全体を秩序だったシステムとして維持していかなければならない。各リスト間の整合性を保つ作業などは、典型的な「人間には難しいが、コンピュータには易しい」仕事だ。スマホ全盛のこの世の中で、手元のコンピュータ資源を活用しない手はない。

実際、GTDの原著ではこの「リスト」を作るのにアナログなツールを使うことを基本の想定としているため、デスクの再構築までがセットになっている。それこそGTD本の著者デビッド・アレンさんをコンサルとして雇うならともかく、普通の人はいきなりそこまでやりたくはないというか、できないだろう。

それにGTDとは本質的にシステムの運用論であり、テクニックである。だから「形から入る」ことに罪悪感を覚える必要はない。形を作って維持するのがGTDなのだから、出来合い品を買って使い方を覚えれば、それで十分機能する。

逆にいうと、GTDのコツと使っているアプリの使い方のコツとはほとんど不可分になる。私はOmniFocusを使っているので、 このブログに書く内容もOmniFocusの使用を前提としている。

どのOmniFocusを買うべき？

OmniFocusにはMac版、iPhone版、iPad版がある。いつでもどこでも使えるという意味でiPhone版は必須、あとは個人の好みだろう(私はMac版も持っている)。このブログでもiPhone版をメインにまとめていく。

原著Getting Things Done（邦訳『ストレスフリーの仕事術』）は読むべき？

もちろん読むべきだが、はっきり言ってわかりにくい本だということは覚悟した方がいい。この本は体系だった方法論を説明するというより、著者が自分のクライアントに対する時の説明の手順をそのままなぞっているようなところがある。

私がこうやってブログにまとめようと思ったのも、本の内容がわかりにくくて、自分なりに体系付けたいと思ったからだ。だからGTDの本に書いてある内容と重複する内容も多くなると思う。

続き: OmniFocusを使い始める