アーキテクトと哲学者

システム統合の要点となるビジネス−IT−組織のアラインメント
第３回：アーキテクチャとフレームワークの定義

に、Software Designを書いたDavid Budgenの言葉として、

ソフトウェアアーキテクチャ＝要素（element）＋形態（form）＋原理（rationale）

とあるそうです。
アーキテクチャとは何ぞやを表した言葉としてなかなか本質的な定義だと思いますが、他方でここまで抽象化されると、アーキテクチャじゃなくても、あらゆるものが要素と形態と原理からなるとも言えそうです。

実際、古代ギリシャ哲学のアリストテレスは、四原因説として、「質料因」、「形相因」、「作用因」、「目的因」というものを考えました。ものは、そのもの自体を形成する質料と、そのものがどのように形成されるかを規定する形相と、どうしてそのような形相になるかの作用もしくは目的、この4つから成り立っているというものです。

アリストテレスのさらに前、プラトンは、質料と形相では、形相を重視し、形相こそがものの本質であり、それはイデア（理想型）の写しであるとしました。したがって、形相がどうしてそのようになるかは、イデアの善にどれだけ従っているかによることになります。形相（Form）がどうしてそのようなものなのかは、善さを追い求めたからということになります。

あるものがどうしてそのようにあるのか？というのは哲学の根源的問いかけです。これに倣って、あるIT部品がどうしてそのようにあるのか？というのがアーキテクトの問いかけと言えるでしょう。
たとえば、WebのフレームワークとしてStrutsを使う場合、みんながそれを使っているからでなく、どうしてStrutsなのか、さらには StrutsはどうしてMVCの考え方で設計されているのか、さらにさらにどうしてMVCの考え方がよいのか、と問うていくことが重要なのだと言えます。

アジャイルでのチーム間コミュニケーション

前回の"アジャイル"にまつわっておもしろい記事があるのでその紹介をします。

アジャイルソフトウェアプロセスを使ってオフショア開発

マーチン・ファウラーさん自身が数年前にアジャイルでオフショア開発を経験されているんですね。前回の議論とも絡んで興味深かった部分を引用します。

私は、複数サイトのチームを束ねて仕事を進める際の問題に関する話をいくつか聞いた。インタフェースの定義に多くの注力を払っていても統合する際の問題は頭をもたげてくる。多くの場合これは、インタフェースの意味を厳密に指定するのが非常に難しいからだ。従って全てのシグネチャを正しく指定しても、実際にどのように実装が行われるかの仮定で躓いてしまう。

うんうん。

継続的なインテグレーションとテストというプロセスは結合の際に出てくる多くの問題を即座にあぶり出し、その結果問題を見つけるのが困難にならないうちに修正することが可能になる。

なるほど。


最初から我々はUSチームの誰かが常にインドに滞在してコミュニケーションを促進させる、ということを決定していた。（中略）コミュニケーションが改善されることで飛行機代ぐらいはすぐにペイするのだ。（中略）駐在員の任務の中で重要なものはゴシップを伝えるということだ。プロジェクトには非公式なコミュニケーションが多くなされる。ほとんどは全然重要ではないことだが中には重要なものがあり、またどれが重要なのかは分からないという点が問題なのである。だがら駐在員の任務には、正式な連絡経路では全然重要とは思えないようなちょっとした、多くの連絡をすることが含まれるのである。

これは、実は日本国内にいても、大規模プロジェクトでの各チーム間のコミュニケーションに言えることではないでしょうか。代表者（＝駐在員）が、別のチームといっしょにすごしてコミュニケーションをとることは非常に重要だということです。それ専任の人を設けてコミュニケーションを促進することでその人のコストぐらい"ペイ"できるのだ！と言いたいところです。
大規模プロジェクトでは、そういうコスト見積もりが（ほんとうは）必要でしょう。


米国にいる顧客のために、フィーチャ(XPのストーリーに相当)を肉付けして(2,3ページの)短いストーリを書くことだ。その後、インドにいるアナリストやテスターがこのストーリー向けのテストスクリプトを作る。

アジャイル開発ではテストスクリプトが重視されます。このときは、ストーリ・ベースでの検証内容を伝達し、オフショア側にテストスクリプトを作ってもらっているようですね。
チーム間の情報伝達とインタフェースをどうするかというのは難しいのですが、このときは少なくとも「ストーリ」での情報共有を実施しているようです。


開発チームをオンショアとオフショアに分ける場合、作業工程に沿って分けるのではなく、機能面に沿った分割を行う。システムを大まかなモジュールに分割し、オフショアチームにこのモジュールのうちのいくつかを任せてしまうのだ。でも、他のグループと異なり、モジュール間のインタフェース設計や仕様凍結に多大な努力を払うようなことはやらない。継続的なインテグレーションとコード所有権を重視しないことで、モジュール間インタフェースは開発が進むにつれて発展するのだ。

おもしろい内容なので長々と引用してきましたが、実はここが今回の投稿の一番のポイントです。
前回は、生産性の高い適正なチーム人数に分けるために、"アジャイル"的に開発対象を分けるか、開発チームを（工程にそって）分けるか、ということを書きました。工程に沿って分けるのは、主に建築業や製造業の方式を見習ったものです。
ここで、ファウラーさんは、さすが"アジャイル"提唱者の1人だけあって、開発対象を小分けにして、1つのチームにはなるべく全工程をまかせることが生産性向上につながる、としています。
たしかに、ITではそういうことも可能なので、おそらくもっとも生産性の高い方式は、"アジャイル"的な開発対象の分割かもしれませんね。
しかも、"アジャイル"では、そういう開発体制と手法に適した、継続的インテグレーションとそのツール、ソースコードの管理手法なども提唱されているので、チームが細切れになってもモジュール間のインタフェースに多大な労力がかかるわけではない、と言っています。にわかには信じがたいですが、うまくやれば、これもまた真なのでしょう。


アジャイル手法では、ドキュメントを作る作業の大部分は無駄に終わるという観察結果から、ドキュメント作成を軽視している。しかしながらドキュメント作成はオフショア開発においては、対面のコミュニケーションを減らすことができるのでより重要になる。（中略）でも、オフショアモデルだと、これはやらないといけない。従ってこれは、オフショア開発を行う上での必要経費なのだ。

これも、日本の縦割り開発体制で言えることなのかもしれません。理想的なチーミングではドキュメント軽視でいけるのでしょうが、同じプロジェクトルームにいながらもオフショア開発のようにコミュニケーションが欠如してしまうような環境においては、ある程度のドキュメンテーションが必要なのです。ただし、

アジャイルプロジェクトで成功するドキュメンテーションには2つ鍵がある。まず1つは、「ちょうど十分な」ドキュメント量を見つけることだ。アジャイルドキュメンテーションを成功させる2つ目の鍵は、ドキュメンテーションを重要視しないこと、あるいはアップデートし続けられるなんて非現実的な希望をもたないことだ。ドキュメントは特定の目的に役立つために作成されなければならないし、その目的に役立った後は、あなた方は誰もがおそらくそのドキュメントを更新しつづけるよりも大事なことがあるはずだ。これは、普通はにわかに信じがたいが、おそらく今度必要になった時に新しくドキュメントを作った方がいい。プロジェクトで、ドキュメントが必要になるたびに、それを作り始めることの副作用は、ドキュメント作業を効率的にしておく大きなインセンティブなのだ！

ドキュメンテーション自体が目的なのではなく、それを何に使うのかが重要だということです。
日本では、ドキュメントをお客さんの納品物とすることも多いので（ページ数とか意味ない尺度で！）、なかなか難しいところもありますが、生産性を高めるという観点では非常に重要なポイントですね。

長々と書いてきましたが、チームでの生産性を高めるということは、開発手法やプロジェクト体制、さらには契約方式やお客さんの文化などにも関わってくる非常に奥深いテーマであることは間違いありません。

生産性の高いチームの適正人数

最近は、IT業界ではアジャイルな開発手法などが流行しています。（いわゆる"アジャイル"自体についてはまた別の機会に。）
（picture: carlosluis' Flickr）

"アジャイル"の特徴はいろいろあると思いますが、少人数のフラットな組織で迅速な開発を行う、というのも特徴の1つだと思います。そこで、

“ステルス攻撃機”開発のチーム運営に学ぶ

という記事がありました。

スカンクワークスは最初、米ロッキードが通称として使った。ステルス攻撃機の開発などが有名で、航空産業の最先端を担っているチーム運営手法だ。能力差が少ない「粒揃い」のメンバーを10人〜15人集めてフラットなチームを構成し、1人のプロジェクトマネジャーがすべてを統括する。少数精鋭のチームがすべての創造的な活動の中心になる。

もっとも効率的なチームの人数というのはやはりせいぜい15人といったところなのでしょうか。それも、スキルのある15人です。たしかに、世の中の優れたもの、革新的なものの多くが、少人数で作られています。

たとえば、最近でいうと37Signals。シンプルで使い勝手のよいWebツールを開発していることで有名です。37Signalsのメンバーの1人が、Ruby on Railsを開発したことでも有名です。彼らのモットーは、使いやすいサイトを小さくシンプルに開発する、というものです。

The 37signals Manifesto: 05 Size Does Matter

上で紹介されているスカンク・ワークスについては、

『ステルス戦闘機—スカンク・ワークスの秘密』 ベン・R・リッチ

がおもしろいです。

スカンクワークスの一員でもあったこの著者によると、スカンク･ワークスの特徴は、

* 超個性的なリーダ（慕われ信頼されてもいるが敵も多い）
* 会社からの独立性、自由（必要最低限のルールを守れば監視されることもなく、必要な報告量も多くない）
* 優秀な技術者の集まり
* 技術者と製造現場がすぐ近く（開発者が製造現場に関われる）
* つねに80%の完成度を目指す（100%をめざさない）
* できるだけ既存品を使いまわす

ということにあるようです。

やはり、高い生産性と官僚主義的生産体制は相反するものだけれども、規模が大きくなると官僚主義的になり生産性が落ちるというのは悩ましい問題ですね。

ちなみに、「スカンクワークス」でも、なにも製造工程もすべて少人数なわけではなく、設計を少人数で行っています。実際の製造は、当然工場です。ただし、工場が設計場所のすぐ横に隣接されていて、何か問題があればすぐフィードバックが来るようにはなっています。

37Signalsなどは、（おそらく）自分たちでコーディングもしてもっとも生産性を高めていると思います。が、ステルス戦闘機を作るような大規模なシステムだとそういうわけにもいきません（実際、37Signalsも大規模なものはやらない、逆にそういう小さなものに特化することで生産性を維持する、としています）。大規模なシステムでは、高い生産性が求められる部分と、そうではない部分を分けて、分担していくしかないですね。

実際、IT以外の世の中のプロダクトは、家電にしろ車にしろ建築にしろ、少人数の設計チームと、大規模な製造、流通体制が協業しあっています。

ITシステムを作るときにも、現実問題は、スキルのある人を多く集められるわけでもなく、実際に作らなければいけないものも巨大で、15人ではとても無理なものも多いと思います。

解決策の1つは、"アジャイル"な考え方にしたがって、大規模なシステムを小分けにして少しずつ反復しながら開発していく、ということになると思います。もう1つは、高い生産性が求められる設計チームと、製造チームを分けた開発体制をとることです。もちろん、そういう体制が目指されてはいると思うのですが。

開発対象を分割するにしろ、開発主体（チーム）を分割するにしろ、いかにチームをスキルのある人による少人数フラットな形に近づけるか、というのが体制作りのキーポイントかもしれません。

GTDGmail

GTD関連で。GMailを使ってGTDしやすくするツールがあるそうです。

ワークスタイル・メモ：タスク・ToDoリスト系
GTDGmail （GmailでGTD）

GTDGmail

このツールを使わなくても、ラベルをProjectやContextでつけてフィルタールールを設定すれば、GmailをGTD的にできますね。たしかに。

このGTDGmailは、そのラベル付けを簡単にしてくれたり自分宛にタスクとしてメールを出しやすくしてくれたりするもののようです。

先日ここにも書いたRemember The Milkを使ったGTD的ToDo管理ですが、いちおうまだ続けています。
プライベートのものも含めてToDo項目を一元的に管理し定期的に見直せるのは便利ですね。もっともRemember The Milkじゃなくてもできますが。

ただ、やっぱり、とっさに出てきたToDo項目の入力はしんどいです。そういうものはいったん手元の紙に書いておいて後で入力となってしまいますね。

Remember The Milkのいいところは、プライベートで外出時も携帯でチェックできたり、1つのタスクに複数のタグをつけられるので複数のビューでタスクを管理できるところでしょうか。

方法論（メソドロジー）について

ものづくりをする上で、どのように作るのか、どのように設計するのか、どのように考えるのか、ということについて考えることは非常に重要です。

とくに、ものづくりでうまくいった過程を1回限りの偶然にせずに、他の人にも共有できるノウハウとして全体の品質を向上していくためには、そのやり方について考え、整理する「方法論（メソドロジー）」はとても重要になってきます。ただし、方法論はただの成功方法の記述なのではなくて、そのものごとの本質を表したものでないといけません。

方法論（メソドロジー）では、具体的な命題に対しどのようにしたのか、というよりも1つ上の"メタレベル"で考えることになります。すなわち、成功するためにはAという作業が必要であるが、そのAという作業が必要であるとどう判断するのか、またAという作業をどのようにすればよいか、について考えさせるものが方法論（メソドロジー）です。

と、話をふっておきながら、具体的なメソドロジーについては、また別の機会で。

今回は、このメソドロジーの元祖とでもいうべきものを紹介します。

「われ思う、ゆえにわれあり。」という言葉はご存知の方も多いと思います。
この言葉は、17世紀の哲学者ルネ・デカルトのものです。
デカルトは、近代哲学の祖であるとともに、近代科学の礎を作った人でもあります。デカルトが物質を「空間の中の延長」と定義したことによって、人の動きも物の動きも等しく"運動"と捉えることができるようになったのでした。もっとも、デカルトは、主に 質量 x 速度 を考えていたようですが。

そのデカルトが上の言葉を書いた本が『方法論序説』です。
タイトルからわかるように、この本は哲学書でもありますが、「方法論（メソドロジー）」でもあります。デカルトは、この本の中で人間の思考についての方法論を考えたのでした。

それによると、人間の思考が真理を求めるときは、

1. 明晰かつ判明に（clara et distincta）精神にあらわれるもの以外は，なにもわたしの判断のなかに含めないこと（明証性の規則）
2. 私が検討する難問のひとつひとつを，できるだけ多くの，しかも問題をよりよく解くために必要なだけの小部分に分割すること（分析の規則）
3. 私の思考を順序に従って導くこと（総合の規則）
4. すべての場合に，完全な枚挙と全体にわたる見直しをして，なにも見落とさなかったと確信すること（枚挙の規則）

の4つの規則を適用することになる。そして

真でないいかなるものも真として受け入れることなく，ひとつのことから他のことを演繹するのに必要な順序をつねに守りさえすれば，どんなに遠く離れたものにも結局は到達できるし，どんなに隠れたものでも発見できる

としています。( 第3部 近代哲学史、第1章 近代哲学の始まり、第2節 デカルトから引用。)

今読んでも、人間がものを考えるときの本質を言い当てて妙ですね。
なにかものを考えるときには、こうした本質的根本的なことを意識して考えたいものです。

そして現代のものづくりのメソドロジーも、その本質を捉えるようなものであるべきです。

ものごとをドライブする力

『』
ジョン サルストン

以前読んだ本から。
ヒトゲノム解読プロジェクトについての本です。

著者であるジョン・サルストンさんは、ヒトゲノムの全塩基配列解読のための国際チームのリーダーとして活躍した1人で、その立場から、同プロジェクトを振り返って書いたものがこの本です。http://draft.blogger.com/img/gl.link.gif

オープンなマインドを持ったヒッピー世代でもある一線虫学者が、次第に遺伝学の学会の中に巻き込まれ、国際間の協調に尽力し、さらには特許によって情報を独占しようとする民間企業（や国）と戦いながら、ヒトゲノムの全塩基配列解読という当時としては「無謀」ともとれるプロジェクトをドライブしていった様が描かれています。

ヒトゲノム情報のような基礎研究成果を企業に独占されてはならない、全世界にオープンなデータベースを作って科学の進歩に役立てなくてはならない、という強い信念には尊敬します。その社会的正義を貫く姿勢は見事です。
そしてそれをうまくドライブしていく姿も。

最大の難関は、予算集めだったようです。とてつもない額の研究費がつぎ込まれています。逆に、サルストンさんらの努力で、いろんな団体から資金が集まりました。はたして実現できるのかどうか、また実現したとして何か（すぐに）役に立つのかどうかわからないようなプロジェクトに対してお金をつけようというのですから、その予算取りの苦労は大変なものだったでしょう。その過程も非常に興味深いです。線虫での実績と、プロトタイプのようなものでの実績を重ねながら、予算を確保していったようです。何よりほとんど「壮大な夢」な目標が資金援助者に対しては有効だったとも考えられます。大きな夢でありながら、それを実現できそうな実績の積み重ね、この2つが重要なポイントと感じました。

2000年6月にはクリントン大統領と同じ日に民間ベンチャー企業セレラ・ジェノミクス社もヒトゲノムの全遺伝情報解読終了を宣言しました。サルストンさんにとっては、こうした企業との戦いも重要だったようです。企業活動としては、遺伝情報をライセンス販売するなどして利益を上げ、研究費を回収しさらには利益を上げることになると思いますが、サルストンさんとしては、このような人類みんなに役の立つような基礎情報は、望む人すべてに解放すべきだという大きな思いがあったようです。そうした、ビジネスに巻き込まれながらも（サルストンさんチームも予算を必要としています）、オープンさを守り抜く様もまた非常に興味深いです。

アイディアを言うだけは難しくないですが、それを信念を持ってやり遂げる、しかも不可能に近いようなアイディアを実現してしまう、という痛快な物語を味わいたい人はぜひどうぞ。なかなか読みやすくもあります。

ものづくりの美学

花や空など自然界のものも美しいですが、人が作ったものが"美しい"ことも多々あります。

スポーツカーに美しさを感じる人もいれば、ジェット機に美しさを感じる人もいます。もちろん、美術作品に美しさを感じる人は多いでしょう。

たとえば、スポーツカーに美しさを感じるのは、すごく速そうに見えるとき、"速さ"という目的に適った姿かたちをしているときではないでしょうか。展示されているスポーツカーは停まっていますし、もしかしたらエンジンもつけられてないかもしれないので、実際に速いかどうかはわかりません。でも、人がその形に速さを感じ、それも他とは比較にならないくらいの速さを感じるとき、そして、その速さをあたかも実現しそうな無駄のない姿かたちを見るとき、美しさを感じます。

たとえば、一流スポーツ選手のプレー。それにも美しさを感じます。イチロー選手の流れるようなグラブ捌きとそこから瞬時に繰り出される矢のような送球。そこに美しさを感じる人もいます。この場合も、捕球や送球という目的に適った動き、無駄のない動きに美しいと感じているのでしょう。

一般的に言って、ある目的に適った無駄のない形や動きに、それもその形や動きが同類の一般的な形や動きに比べて突出しているとき、人は美しいと感じるようです。

そういう意味では、ものづくりの究極は、もしかしたら美しさの実現にあるかもしれません。
人によって作られる「もの」は、多くの場合、なんらかの目的を達成するためのものです。その目的を他とは比べ物にならないくらい見事に無駄なく実現するようなものを作れたとき、それはものづくりの究極の姿ではないでしょうか。そして、そのようにつくられたものに、人が美しいと感じてくれるとき、それはものづくりをする人の冥利につきるでしょう。

ちなみに、"美しい"とは？というのは、古くからの哲学的（美学的）テーマでもあります。"善い"などと並んで、規定できないカテゴリー化できない概念としてさまざまに語られてきました。
たとえば、18〜19世紀ドイツの哲学者カントの考える美しさについては、

カント『判断力批判』　-美のメカニズムについて-
http://asianblue.info/kitaro_nisida/panduanli.htm

詳しくは、また別の機会に。

自分をプロデュース

うーん。さっそく3日坊主になってしまいましたが。
気を取り直して。

『表現したい人のためのマンガ入門』
しりあがり寿

を読みました。

しりあがり寿さんによると、自分の中には、奇妙なことを思いつくケダモノと、そのケダモノを手なずける調教師の2人がいるのだそうです。
新しいものを生み出す自分と、そういう自分をプロデュースし"しりあがり寿"というブランドネームを管理する自分がいる、と。

実際、アイディアを思いつくだけでなくて、それを現実の世の中に出していくということは本当に難しいことです。ほとんどがアイディア倒れになるのが普通でしょう。もしくは、せいぜい一発屋。

アイディアを世に出すということは、そのアイディアが、自分以外の複数の人に共感や興味を持ってもらい、さらに多くの場合はなんらかの役に立つということです。
生み出されたアイディアを世の中に受け入れられるような形にするというのはほんとうに難しいことですね。そこに定石のようなものはないようです。努力＋時代の流れ。

電通の鬼十則

電通を戦後すぐに世界的企業に育て上げた吉田秀雄さんのことばです。
まずは、そのまま。

鬼十則
一、仕事は自ら創るべきで与えられるべきでない。
二、仕事とは先手先手と働き掛けて行くことで受身でやるものでない。
三、大きな仕事と取り組め。小さな仕事は己を小さくする。
四、難しい仕事を狙え。そしてこれを成し遂げることに進歩がある。
五、取り組んだら放すな、殺されても放すな、目的完遂までは。
六、周囲を引きずり廻せ。引きずるのと引きずられるのとは長い間に天地のひらきが出来る。
七、計画を持て。長期の計画を持っていれば忍耐と工夫とそして正しい努力と希望が生まれる。
八、自信を持て。自信がないから君の仕事には迫力も粘りもそして厚味すらない。
九、頭は常に前回転。八方に気を配って一分の隙もあってはならない。サービスはその様なものだ。
十、摩擦を怖れるな。摩擦は進歩の母。積極の肥料だ。でないと、君は卑屈、未練になる。

チームで、組織でものづくりをするときに肝に銘じておきたいことばです。
半分精神論ですので、あくまでチームや組織に所属する"個人"が胸に秘めるべきことばですが。

「摩擦を怖れるな」などは過激なルールですが、日本人によるチームや組織ではとくに気をつけたほうがよいことですよね。摩擦を起こす側も、摩擦を受ける側も。
無駄な摩擦や、人間攻撃の摩擦はよくないですが、摩擦を起こし受け止めることこそ、チームの力を人数倍以上にする要素でしょう。

アイディア作りの処方箋としての『一億三千万人のための小説教室』

LifeHacks系のWebサイトや「アイディアなんとか〜」という本ではぜったいに紹介されていないけれども、アイディアを生み出すための王道を書いた本として個人的にもっともお勧めしたい本がこれです。

『一億三千万人のための小説教室』
高橋源一郎

この本は、一見タイトルからすると小説を書くためのハウツー本のようですが、「いかにアイディアを生み出すか」、「クリエイティブになるとはどういうことか」ということが書かれた本です。小説好きでなくても普通のビジネスマンでも読めます。

本来の小説家は、新しい言葉を、新しい語り方を生み出すことがその仕事なのだと言えます。では、新しいものを生み出そうとするときどうするのか？というと、高橋氏曰く、
・その対象を好きになり
・繰り返し真似ることだ
と言います。
その対象について考え、真似をし、考えに考えつくしてもう頭の中が真っ白になったときにこそ、フッとアイディアが生まれてくるのだと言います。
もちろん、もっとうまい表現でその部分について説明しているのですが、新しい発想が出てくるその瞬間をうまく言葉として定着させています。

先に書いたジェームス W.ヤングの『アイデアのつくり方』ともつながる部分がありますね。

最後に、Amazonにあったこんな読者レビューを紹介しておきます。まさにその通りだと思います。

　　私が思うに、すべての「素敵な」ハウツー本には、
　　それが文学でも音楽でも美術でも
　　結局同じ事が書かれています。
　　そしてこれはその「素敵な」ハウツー本の一冊でることに間違いはありません。

Remember The MilkでGTD

デジタルで管理した方が便利なToDo項目と、紙で管理した方が効率的なToDo項目があるため、GTDが中途半端になるというのが先の投稿での悩みでした。
ここへ来て、

　　Remember The Milk

というサービスを使えばかなりのことがデジタルでできるんじゃないか？と思い出しています。

そのきっかけとなった記事が、
Business Mobileの「モバイルTPO検索術 第2回 話題の「GTD」で頭も心もスッキリさせよう」
です。

実は、Remeber The Milk自体は、去年ぐらいにアカウント作って試してみていたのでした。でも、けっきょく、
・PCを起動していないとToDo項目がわからない
・ToDo項目をどうGTD的に管理してよいか分からない（そもそもRTMはGTDのために作られたものではないので）
ということもあり、すぐに使わなくなったのでした。

が、先の記事により、「なるほど」と思えるGTD的RTM活用方法が紹介されています。リストを、プロジェクトやいつかフォルダとして使ったり、タグをコンテクストとして使ったりするのはうまいやりかたですね。

さらに、RTMはなんとi-modeに対応しました。つまり、PCを起動していなくても、PDAのようなデジタル・デバイスを使わなくても、手元の携帯電話でToDo項目が確認できるのです。出先で携帯でToDo項目を確認できるのはすごく便利です。

さらに、こちらは元々あった機能ですが、
・携帯などで特定メールアドレスに特定フォーマットでメールすればToDo項目が追加できる
・期日や時間が来たら、メールやIM、携帯メールなどでToDo項目が送れる
・リストやタグなどいろんなビューでToDo項目をリストできる（たとえば、当初分類したカテゴリとは別に、「家でやる作業」とかいろいろなビューが作れます）
・期日の入力フォーマットが自然言語に近く入力しやすい（たとえば、「Every week until 1/1/2007」など）
・操作がAjaxでスムーズ
・入力のためのキーボードショートカットが多数用意されている
などなど。

携帯をPDA代わりに使えそう、というのがいいですね。

というわけで、しばらくの間、またRemember The MilkでToDo管理してみようと思っています。

GTDについて

アイディアを作っていったり、ものを造っていったりするのに、個人の生産性の向上というのは重要なテーマです。

最近、"Life Hacks"というものが流行っています。

　　『Life Hacks PRESS ~デジタル世代の「カイゼン」術』
　　田口 元

要するに、ToDoリストのつけ方や各種ツールの使い方など個人の生産性を上げるための工夫を紹介したものです。

そのLife Hacksで教科書とされているものが、

　Getting Things Done
　『仕事を成し遂げる技術——ストレスなく生産性を発揮する方法』
　デビッド・アレン

です。

内容について詳しくは、次のサイトがわかりやすいです。

ワークスタイル・メモ：GTD・Lifehacks　「GTD (Getting Things Done)とは」
自己実現寺　「GTDそしてLife Hacksが面白い」

去年出張したときに滞在したホテルの近くの本屋に置いてあり、ちょうど読みたいと思っていたので買って読んでみました。
なるほどと思いつつ、どこかで聞いたことあるなぁという感じでした。おそらくアレンさんの本の内容をそれまでに又聞きしていたのでしょう。でも、この手のことに興味のある人は一読の価値があります（もしかしたら最近出た『Life Hacks PRESS』の方がわかりやすいかもしれませんが）。

実践しようとしてみて思ったことは、
・ToDo項目をすべてIn-Boxに書き出すのがめんどう
・毎日／毎週のToDo項目のレビューがめんどう
・多くのToDo項目がメールで来るのに紙で管理するのはめんどうだし、かといってデジタル･ツールを使っても痒いところに手が届かない
・紙とデジタルとでIn-Boxをなかなか1つに統合できない
ということでした。
やり始めた当初は、ToDo項目がしっかり管理されてたしかにすっきりするのですが、忙しくなるにつれてToDoをきちんと管理できなくなっていきます。ほんとうは忙しいときほどきちんとすべきなのですが。

というわけで、三日坊主になりがちなのが問題です。個人的には。
それでもこういう仕事の効果的なやり方というのは工夫していく必要がありますね。

『アイディアのつくり方』

ジェームス W.ヤング

「つくる」ということを考える最初のエントリは"アイディアの生み出し方"について書かれた古典から。1965年出版だそうです。
広告業界にいた著者が、どのように新しいアイディアを生み出してきたかについて書いた本です。アマゾンのレビューから引用すると、アイディアを生み出すステップは、

　　(1)資料収集
　　(2)情報の咀嚼http://draft.blogger.com/img/gl.link.gif
　　(3)考えることをやめる
　　(4)アイデアが浮かぶ
　　(5)アイデアを世に出すための努力

からなるそうです。

「考えることをやめる」というのがミソですね。情報を集めまくって、いろいろ脱線しつつも自分なりに理解していって、考えに考えて、それでもやっぱりアイディアなんか出てこなくて自信喪失して、考えるのをやめてしまう。。。そうこうして別のことに取り組んでいたり気晴らししていたりすると、あるときフッとアイディアが浮かんでくる、そういう瞬間があります。

ヤングさんによれば、新しいアイディアとは過去の知識と知識の結び合わせ、新しいリンクのさせ方のことだそうです。
人間の脳は、集中しているときはロジカルに明晰に理解する力が発揮され、散漫なときに関係のないもの同士を勝手に結びつけたりする動きがあるのかもしれませんね。

薄い本ですが、アイディアを生み出すコツの王道が説かれている本です。

ちなみに、この後最近になっても続々と"アイディア"本が出版されていきますが、やはり広告業界の人のものが多いように思えます。彼らの仕事の大部分がいかに"アイディア"に占められているか、ということでしょうか。