ホーム > 読んだ > 国内

Life Hacks Press
デジタル世代の「カイゼン」術

書誌

taglifehack
text唯野
author技術評論社
publisher技術評論社
year2006
price1,520+tax
isbn7741-2728-0

目次

1感想
2抄録

履歴

2007.10.16読了
2007.10.16公開
2007.10.16修正

感想

lifehack を専門に扱ったムック本で GTD の概要から始まり、Web 2.0 を代表する Google のサービスガイド、効果的なプレゼン・マインドマップの使い方、文房具などの Tips までを広く浅くという感じで扱った本。lifehack の旬を知るには割と手軽かつ手頃なものとなっている。個人的には GTG の概要がなかなかよかったので、これをまとめた。

lifehack は名前の通り、元をたどれば hacker の hack 的手法をライフスタイルにまで広めたもの――と私は解釈しているが、いうまでもなく hack は目的に対する手段であって hack 自体が目的というわけではない。lifehacker が肝に銘ずるべきはその点だと思う。

抄録

3

lifehacks の定義にはさまざまなものがあります。最初に lifehacks のコンセプトを提唱したのはカリフォルニアのテクニカルライター、Danny O'Brien 氏と言われています。

彼は lifehacks のコンセプトを思いついたときのことを、次のように語っています。

<em>lifehacks のコンセプトは、技術者たちと雑談しているときに思いつきました。</em>

<em>技術者たちは日々の仕事を片付けるために小さなプログラムを書いていることが多いわけです。でもそれらは本当にささいなプログラムなので、売られていたり公開されているわけではありません。</em>

<em>お互いにどんなプログラムを書いて仕事を片付けているのかを教え合っていたら、いくつか共通のパターンがあるのではないかと思えてきました。</em>

<em>そこでもうあと数人にいろいろ聞いてみたところ、驚くべきことにみんな似たようなやり方で仕事を片付けていることがわかったのです。</em>

実際に Danny 氏が技術者たちに「仕事のやり方」を聞いてみたら、それは小さなプログラムというよりも、あるシンプルな習慣というべきものでした。

たとえば彼は(lifehack を発表した:唯野注) Emerging Tech のスピーチの中で、技術者たちの習慣について、次のような共通点を紹介しています。

<em>「技術者たちは複雑なアプリケーションを使いません。シンプルなテキストファイルを好みます。みんな todo.txt を持っているのです」</em>
<em>「技術者たちは 11 時間かかる単調な作業を片付けるために、10 時間かけてスクリプトを書きます。彼らは反復作業を嫌います。たとえ 10 時間かかっても、スクリプトを書くほうがおもしろいならそうするのです」</em>

lifehacks 系のブログでは数多くの便利なソフトウェアや、仕事のやり方、情報管理の仕方、モチベーションの上げ方などが取り上げられています。

もちろんそこに取り上げられているそれぞれのやり方が lifehacks なのですが、その根底に流れるのは「仕事をシンプルかつ楽しくするような習慣を生み出そう」という考え方です。

lifehack についてが非常に簡潔にまとめられている。この頭から余計なものを追い出すというのは私も メモの効能

4

やる気を出す 10 の方法(Top Ten Motivations)

  • 目標は細かく設定しよう !
  • 目標達成のために 1 日 15 分使おう !
  • 目標を定期的に復唱できるようにマントラを作ろう !
  • 目標達成をサポートしてくれる仲間を見つけよう !
  • みんなにあなたの計画を知らせよう !
  • 自分を追い詰めよう !
  • 目標達成率を高めるためにそれを紙に書こう !
  • 目標を定期的に見直そう !
  • 目標達成したときに自分にごほうびを与えよう !
  • 目標達成したらそれを振り返る時間を持とう !

5

いやな To Do を片付ける方法(Cringe-Busting your TODO list)

  • To Do リストを印刷する
  • 上から下まで読む
  • また上に戻って、いやーな気分のする To Do に○をつける
  • ○をつけた To Do について「なぜいやな気分がするのか ?」をじっくり考えてみる
  • その To Do を片付けるために必要な、新しい To Do を追加する。新しい To Do はいやな感じのする To Do よりも気分的に軽いものにする
  • いやな気分がした To Do に横線をひいて消す
  • 新しく追加した To Do にすぐに着手する

12-31

GTD とは David Allen 氏の著作『Getting Things Done』の頭文字で、その特徴は手法の効果・機能だけでなく、それで作業する人の感情面にまで配慮している点にある。要は「便利だけど大変そう」ではなく「とにかくやってみよう」の違いにあり、これはシンプルかつツールを選ばない点を含め自分に合わせた方法を実践すればよい点としても表れている。

その上で Allen 氏は知識集約型の現代では仕事の終わりが曖昧(Open Loop : 閉じない輪)となる結果、終わりの見えないが故の達成感のなさを生んでいるといい、それを解決するため(Closed Loop とするため)のメソッドとして GTD を提案している。即ち、信頼できるシステムへの Task のアウトプット(これは自分の頭ではない、なぜならそれを気にしている限り頭は本来のことに集中できないから、また頭では簡単に忘れることがあり信頼できない)、Task に対する具体的なアクションの定義、アクションの実行と定期的なレビューである。そして、GTD によるストレスから解放されることによる余裕が新しい創造を可能にすると説いている。

この上述のフローを具体的なプロセスに置き換えると以下のようになる。

  • Collection (収集) Task を全て書き出す
  • Procesing (処理) 書き出した Task を以下のフローで切り分け
  • Organizing (整理) 切り分けた Task をいつでも参照可能にする(PDA/紙など)
  • Reviewing (レビュー) Task のリストを見直す
  • Doing (実行) Task を行う

Processing でのフロー。但し、これは元のチャートを私の場合にアレンジしている。

In-Box
↓
その Task はやる必要がない -> 消す(delete)
↓
その Task はアクションではなく情報である -> メモ(memo)して消去
(自分以外の人の成果物でありアクションを補助するものならば)
↓
その Task はすぐできる -> その場でやって(do)消去
↓
その Task は相手からの Input 待ちである -> 待つ(wait)

  • (他の人に頼めるのなら頼む
    • 

  • Input がなければ、催促の Task を実行
    • 

  • Input があれば、その次に行うべき Task を定義
    • 
↓
その Task は時間が決まっている -> 予定する(Schedule)
↓
その Task は急がなくていい -> プール(pool)
↓
今日の Task に追加
完了したら消す(必要なものは作業ログを残す)
実行して完了しなければ消して次の日の Task に追加(達成率をプラス)
実行しなければ残して Task を見直す(細分化)

    36-64

    GTD を実践するためのアナログ/デジタルを問わないツールについて。私は OneNote 2007(デジタル)をメインに、それの印刷したもの(アナログ)と付箋を併用している。本書で紹介されている Remember The Milk も少しかじったことがあるが、自由度の高いツールの方が私には相性の良い気がするので、結果的に上記のツールを使っている。本書では筆記具類も扱っているが、個人的にそういうものにはそれほどこだわっていない。むしろ、高性能なスマートフォンで手軽に Task List を持ち出せないかというのが、目下のところの関心事である。

    Up