Category: タスクマネジメント

ルーチンのノロイ

前回:「やることを減らす」というやること


繰り返し。
繰り返しの力。

習慣化。
認知エネルギーの省力化。
素晴らしい。

毎週発行のメルマガ。
5つのコンテンツ。
月〜金で毎日一つ。

月はBizArts。
火はSS。
水は週替わり。
木はエッセイ。
金は今週の一冊。

毎週、毎週繰り返す。
学校の授業のように。
今日何をするのかをいちいち判断しない。
月曜日はこれを書く、と自然に決まる。

それならば。
それであるならば。
どこまでも繰り返していける。
いつまでも繰り返していける。

轍の上を進むのは楽なのだ。

でも。
困ることもある。

たとえば、200回目だとする。
たとえば、新年特別号だとする。
何か変わったことがやってみたい。
そんなことを思いついたとしても。

月曜日にはBizArtsを書いている。
火曜日にはSSを書いている。
水曜日には週替わりを書いている。
木曜日にはエッセイを書いている。
金曜日には今週の一冊を書いている。

気がつけば、メルマガは完成している。
そんなことがよくあった。

意識することなく取り組んで、
意識することなく完了する。

それが轍の力。
それがルーチンの呪い。

ルーチンが悪いわけではない。
むしろ、それはたしかな力を有している。
できれば、積極的に利用していきたい。

しかし、それ以外の視点もたまには持っておきたい。

部屋の空気を入れ換えるように。
クラスで席替えするように。

ルーチン以外のことも、取り組めるように。

▼こんな一冊も:

「目標」の研究
「目標」の研究

posted with amazlet at 17.01.07
R-style (2016-12-11)
売り上げランキング: 2,504
Send to Kindle

プロジェクトの階層がずれる

プロジェクトを管理しようとすると、戸惑うことがあります。階層が揃わないのです。


たとえば、何か単発のプロジェクトがあったとしましょう。≪〜〜さんのKDP出版を手伝う≫のようなプロジェクトです。この場合、そのプロジェクトの項目を作れば、それでOKでしょう。

では、≪「目標の研究」を出版する≫というプロジェクトはどうでしょうか。もちろん、このプロジェクトについても項目を作ればよいでしょう。

screenshot

ただし、若干の引っかかりはあります。このプロジェクトは、もう少し長いスパンの≪「月刊くらした」計画二年目≫というプロジェクトの下位に位置するのです。

screenshot

話はそれだけに留まりません。そもそも≪「月刊くらした」計画二年目≫というプロジェクトは、≪「月刊くらした」計画≫というより大きなプロジェクトの下位に位置するのです。

screenshot

「プロジェクトの全体像を把握したい」

と希求するなら、この構図もまた捉えておかなければなりません。しかしそれをどのように表現すればよいでしょうか。

ベースラインはどこか?

≪「月刊くらした」計画≫を、プロジェクトに設定すれば、その下位はすべてサブプロジェクト(あるいはサブ・サブプロジェクト)になります。

また、≪「目標の研究」を出版する≫をプロジェクトに設定すれば、≪「月刊くらした」計画二年目≫や≪「月刊くらした」計画≫は行き場を失います。あるいは、プロジェクトではなくなってしまいます。しかし、これらもまたその性質から言えばプロジェクトなのです。

Todoistであれば、プロジェクトに階層構造を持たせられるので、たとえば次のような感じになるでしょう。

screenshot

1つのシステムでうまくプロジェクトと、サブ(×n)プロジェクトがまとめられています。しかし、私の実感はこうではないのです。私の実感では、≪〜〜さんのKDP出版を手伝う≫と≪「目標の研究」を出版する≫は同じ階層であり、≪「目標の研究」を出版する≫に関してだけ、その上に階層があるのです。

だから、上記のように構造を表現してしまうと、どうしても違和感が消えません。

何かの位置が揃っているというのは、結構重要な要素なのです。

さいごに

理念あるいはイデアベースで思考すると、階層構造はトップダウンで上から下へと展開していきます。見た目が立派な構造はそれで作れるでしょう。

しかし、実際あるいはアクチュアルベースで思考すると、階層構造は「実際の行動」をスタートラインにして、下から上に展開していきます。

個人的には、後者のようなプロジェクト管理のスタンスを行いたいものです。幸いEvernoteのノートリンクによる管理は、多少近いことができます。ありがたいことです。

Send to Kindle

2トラック・プロジェクト管理

長い間苦しんでいました。

執筆に関わるプロジェクトマネジメントに、です。

数ヶ月といった長いタームを要する、といったこと以外にも、大きな問題がそこにはありました。

性質が変わるのです。

机上のガントチャート

はじめはガントチャート的な構図で管理しようとしていました。

執筆プロジェクトの全体像を、です。

企画着手からはじまり、執筆があり、ゲラチェックがあり、販売促進があり、と一連の流れを一枚のチャートに落とし込もうとしたのです。

もちろん、チャート自体はすぐに書けます。でも、その通りにはいきません。まったくいきません。

すると人は、その手法そのものから離れたくなるものです。私もそうなりました。

工程の切り分け

あるときから、プロジェクトを切り分けるようになりました。

区画整理です。

執筆前の準備段階、執筆そのもの、脱稿後の販売促進活動。それまで得てきた経験からこの3つの区分けぐらいがちょうどよいだろう、と思い至りました。

そこでプロジェクトを「○○○」(本のタイトル)という大きい括りではなく、「○○○-企画準備」「○○○-執筆」「○○○-販売促進」のように3段階に分けたのです。これは少しうまくいくように思えました。また、副産物もありました。

意外な副産物

副産物とは、チェックリストです。

執筆の工程は、それぞれの本によって違うので「魔法の呪文」は存在しないのですが、よくよく考えてみれば、販売促進は__Twitterの固定ツイートを変更する、ブログで告知記事を書く、プレゼント企画を行うなどなど__本が変わっても同じような活動を行います。

プロジェクトの工程を区分けすることで、繰り返し可能な部分が見出され、それをチェックリストに落とし込むことができたのです。

まっすぐには進めない

しかし、問題は残りました。それはやはり執筆工程にあります。なにせ「魔法の呪文」は存在しないのです。

一番厄介だったのは、居座り続けるタスクでした。

執筆がストレートに進むことはまずありません。なにせこの世にこれまで存在しなかった「本」を書こうとしているのです。手本や見本や師匠からの教えはここでは直接的な答えにはなりません。何か新しいものごとを、頭を使って生み出す必要があるのです。でもって、それには時間と試行錯誤が欠かせません。

となると、たとえば、「第二章第一項を書く」という通常ならばうまく機能しそうなブレイクダウンによるタスクが、まったく進捗しないことが起こりえるのです。それこそ、三日も四日も、そのタスクが私の現前に残り続けることになります。それが、あまりにも苦痛であることは、鏡を見るまでもありません。

毎日毎日、デイリータスクリストに「第二章第一項を書く」と書き、プロジェクトノートにはまったく何の進捗も書き込めないのは、苦痛を通り越して拷問とも言えます。人の心は、終わりの見えない行進に長期間耐えられるようにはできていないのです。

そこで私は決めました。自然な決意だったのか、作為による思い込みだったのかはわかりません。ともかく、「これをコントロールするのはやめよう」と決めたわけです。

ここで一つ、大切なことを書いておきましょう。

「タスクリストを見るのが嫌になっているのなら、タスクの管理方法に何か歪みがある」

その歪みがどこから生じているのかはわかりません。現実と理想のギャップなのか、管理の手間の大きさなのか、ツールのUIの不具合なのか、理由はいろいろ考えられます。が、どのような理由であれ、タスクリストを見るのが嫌になっているなら、何かを変えなければいけません。それを「やる気」などといった見えもしない概念のせいにして問題決着を図ろうとすれば、時間を置いて同じ問題が繰り返されるだけです。

ともかく私は、「本を書く」という工程の中心部に位置する「原稿を書く」という工程を、コントロールするのをやめました。それはつまり「タスクリストを作って、上から順に消化していけば、全体が終わる」というような考え方を捨てた、ということです。

もちろん、進捗状況は確認できるようにします。どこまでできているのかがわからないと、それはそれでツライものです。ただ、ガントチャート的進行の信仰はきっぱり捨てました。他の人は違うのかもしれませんが、私にとってそのやり方は苦痛を生むものでしかなかったのです。

2トラック式

では、現状執筆のマネジメントはどうなっているのかと言えば、次のようになっています。

screenshot

まず、「本線」があります。このルートは、通常のタスク管理と同じようにタスクリスト式に進んでいきます。が、途中でトラックの移動が起きます。執筆の工程に入ると、「本線」から外れて「周回トラック」へと移動するのです。

ここでは通常のタスクリスト式の進捗管理は行いません。では、代わりに何をするのかというと、「時間と作業ログ」による進捗確認です。

「企画」の段階では、「メールを送る」というタスクを立て、それを実行すれば消す、というやり方を行います。しかし「執筆」の段階では、「第二章の原稿を1時間書く」とするのです。つまり、あるタスクの項目を成し遂げたかどうかではなく、どのくらいの時間その種の作業をしたのかで進捗を確認するのです。

もちろん、これは成果の直接的なマネジメントにはぜんぜんなりません。1時間作業をして、まるで原稿が進んでいないこともあります。でも、それが現実の姿なのだから仕方がありません。ここが大切なところです。

理想を言えば、1時間作業をしたら、何か一つのタスクが達成されているのが望ましいでしょう。が、その「望ましい状態」をベースにマネジメントを行ってしまうと、辛くなるのは現実の私です。だって、現実の姿は「1時間作業をして、まるで原稿が進まない」のですから。

でもって、私は「本を書く」とは根本的にそういう作業だと認識しています。そして、プロジェクトマネジメントを理想ベースに運用したところで、現実の執筆がその理想に寄るわけではないのです(あと、寄ったら寄ったで嫌ではあります)。

だから、日々のタスクリストには「〜〜の原稿を1時間書く」と書き続け、それを実行します。同じ場所をぐるぐると周り続けるわけです。そして、シンプルながらも作業記録をつけます。その記録の積み重ねは、「自分が何かしらを行っている」という実感の拠り所となってくれます。

これがもしタスクリスト式の管理方法ならば、タスクを一つ消化できないと「何もしていない」ことになるのです。その空虚さは、ほとんど耐え難いものであることは容易に想像できるでしょう。でもって、その空虚さはほかでもない「理想ベースのタスク管理」のせいなのです。

さいごに

執筆作業が終わってしまえば、「周回トラック」を抜け、再び「本線」に戻ってきます。こうなると、タスクリスト式の管理方法でもやっていけます。というか、その方がフィットしています。

というように、私の執筆マネジメントは2つのトラック__2タイプの管理方法__を組み合わせることで実現しています。これは今のところなかなかうまくいっています。

ちなみに、はじめから2トラックという説明を思いついていたわけではなく、たまたまとあるボードゲームを見たときに、「まさに自分がやっているのはこれじゃないか」とひらめいたのがきっかけでした。ラットレースはなかなか悲しいものですが、執筆作業ってまさにそれだと思います。ぐるぐる走り続けるしかないのです。

というわけで、ガントチャート式の方法で「苦しんでいる」人は、こういうやり方を試してみてください。ポイントは「管理方法は一つでなくていいんだ」という発見です。

Send to Kindle

デジタル・チェックボックスの可能性

チェックボックスってありますよね。タスク管理の強力なパートナーです。

たとえば紙なんかだと、こんな風に使います。

img_7093

四角マークを一つ作るだけで、進捗状況を表現できるのですから、記号というのはなかなか凄いものです。

でもって、Everntoeなどのデジタルツールにもチェックボックスはあります。

screenshot

クリックでオンオフを切り替える、という点を除けば、基本的な動作は紙のチェックボックスと同じ。Evernoteでタスク管理、というなかなか珍しいことをしている私としては、便利に使わせてもらっています。もちろん、他のツールでも同じようにチェックボックスを挿入できるものは多いでしょう。

しかし、ストレートに言わせてもらえば、この方面の進化はここでピタリと止まっています。チェックボックスって、オンかオフしかできないのです。0か1か。「それって、どんなデジタル思考?」と問いかけたくなるのですが、「いや、だってデジタルですし」と返されてしまうのがオチでしょう。

でも、デジタルツールなのだから、もっと様々なバリエーションがあってもよいでしょう。いや、あるべきです。

その辺の機能不全を、たとえば、「チェックボックスを二つ使う」というハックでやりくりする手法もあります。

screenshot

タスクに着手したら前者にチェック、タスクを完了した後者にチェック。これでより細かい進捗管理が行える、というわけですが、いささか涙ぐましい努力と言わざるを得ません。デジタルツールの可能性は、こんなものではないでしょう。

というわけで、たとえばこんなアイデアはどうでしょうか。

img_7094

まず、普通のボックス(オフ・オン)があります。でもって、「半分終了した」→つまり、まだ終わっていない状態を表現できるhalf Doneがあります。つまり、着手はしたが完全ではない、を表現できる、ということです。でもって、これを広げると、1/4とか3/4とか、いろいろバリエーションが出てきますね。それを円グラフ的に表現してもいいかもしれません。人間の手でそれを描くのはなかなか面倒ですが、デジタルツールならば簡単です。

でもって、ドット線(あるいは透明度50%ぐらい)のボックスもあってよいでしょう。これは「いまだタスクにあらず」なもので、言い換えれば、「気になること以上、タスク未満」を表現するボックスです。世の中を見渡せば、そういう中間地点にある要素っていっぱいあると思います。それを適切に管理し、さらに表現するツールは絶対必要です。

あとは、赤色のチェックボックスで、重要性を表現したり(逆もありそうです)、紫色のチェックボックスで、そのタスクが事前に設定したものではなく、割り込みで発生したことを明示することもできるでしょう。仮に紫色ばかりであるならば、タスク管理の手法を改めて考え直す、みたいなログとしても使えます。

でもって、これらの要素でタスクをフィルター(検索)できれば、これはもう最高です。

さいごに

今回はチェックボックスの可能性、という視点で管理ツールの進化の道のりを探ってみました。

根本にあるのは、既存のタスク管理ツールが、あまりにも均一的であり、柔軟性に欠ける、ということです。世の中に、「完了前タスク」と「完了済タスク」の二種類しかないならば、それはそれでよいのですが、どうみても世界はそのようにはなっていません。だから、いろいろなものが切り落とされたり、あるいは無理矢理な変換をかまされることになります。

もちろん、ある程度はタグ機能によって柔軟性はサポートされています。しかし、個人的体験からいって、それはUIとしては物足りません。チェックボックスの色・形のように(視覚的)ダイレクトに私たちに訴えかけてくれた方が、より効果的でしょう。

Send to Kindle

必然性について

東京ライフハック研究会vol.16で、佐々木正悟さんが「必然性」についてお話されました。

で、その中で「倉下さんは、必然性のないことばかりやっておられるように見える」と述べられました(だいたいこんな感じだったと思います)。

ふむ、と私は考えます。

そして、「たしかに、そうだな」と納得します。

私はたしかに、他の人から見たら必然性のないことをやっているでしょう。毎日ブログを更新しなくても、死ぬことはありませんし、毎月一冊電子書籍を出さなくても、ショットガンで頭を吹っ飛ばされることもありませんし、ブロガーを集めて電子マガジンを出版しなくても、地獄の業火に焼かれることはありません。というか、別に誰も困らないのです。冷静に考えれば、私自身ですら困らないのです。

でも、もちろん私からすれば、そこには必然性があります。いや、必然性が感じられるのです。

感じること

タスク(何かしらの行動)と自分との関係性を考えるとき、そこで重要になってくるのは、そのタスクに必然性が「感じられる」かどうか、です。ぶっちゃけて言えば、それは感覚の問題でしかありません。

感覚の問題。

夏休みの宿題を、早めの内から毎日コツコツやった方が楽に終わらせられるのは、小学生でも理解できます。しかし、夏休みに入ったばかりの天気の良い日に、その必然性はリアリティを持って感じられないのです。それはつまり、当人にとっては必然性がないのとイコールです。

逆に言えば、何かしらの演算とUIで、その感覚にリアリティを与えられるならば、行動を促せるかもしれません。たとえば、タスクシュートのように。

感覚の問題。

高層ビルの間に掛けられた鉄筋を渡るのと、地面の上に置かれた鉄筋を渡るのは、たとえ風の影響を揃えたとしても、まったく同じようにはいかないでしょう。状況をどう感じるかが、踏み出す一歩を変えてしまいます。

不確実性

私はよく、何の成果も確約されていないことにバンバン首を突っ込みます。クレイジィです。

仮に、「プロジェクト信用会社」みたいな空想の会社に判定を持ち込めば、D判定以下がバンバン返ってくるようなことばかりに手を出すのです。その意味では、つまり客観的な指標では、それぞれのプロジェクトには、私がやる必然性はどこにもありません。

でも、そうです。私にはそれが感じられるのです。

喉が乾いた人が、塩分まみれの海水を飲み干すように。

冷静に考えて、私は若かりし頃からギャンブルに手を染めています__と書くといかにもたいそうですが、パチンコとか麻雀とか、まあそういうことです。で、ギャンブルとは常にリスク、つまり不確実性との付き合いです。

あまりにも長く(あるいは深く)それと関わっていたせいで、私の思考OSの奥深くには、その「不確実性との付き合い方」が強固にインストールされています。

そのような人間にとって、「何の成果も確約されていないことに首を突っ込むこと」には必然性が感じられるのです。いや、察しの良い方ならばおわかりでしょうが、「何の成果も確約されていない」からこそ、その感覚が生まれるのです。あるいは、不確実性が強いほど、その感覚は強まります。クレイジィです。

さいごに

とまあ、大げさに書きましたが、ようするに私は不確実性に慣れているし、むしろそれを好む傾向がある、ということです。そういう人間にとっての「必然性」は、そうでない人にとっての「必然性」とは少し違った見え方をするでしょう。言い換えれば、それぞれのリアリティが違っている、ということです。

でも、それは表層の違いであって、根本は変わりません。必然性は感じられているのです。

ある種のプロジェクトを見たとき、「なんかしらんけど」な感覚を伴いながらも__つまり合理的に実行する理由は説明できないながらも__、私はそれをする必然があると感じます。私はそれを「面白そうだから」という言葉で説明しますが、それは「私がそれを面白そうだと感じていることには何かしら意味があるに違いない」という背景を後ろに含んでいるのでしょう。ここが、案外大切なことなのかもしれません。

で、この話が一体何なのかというと、私がタスクシュートを使わなくてもそれなりにタスクを進められている理由なのだと、私は感じるわけです。

Send to Kindle

リストのクローズドとオープンの切り替え

前回:R-style » タスクリストのオープンとクローズドについて

クローズドリストについて引き続き考える。

今回問いたいのは、「リストをクローズドする」とはどういうことか、だ。

デイリータスクリスト

空っぽのタスクリストがあるとしよう。一日分のタスクを書き込むデイリータスクリストだ。

screenshot

仮にこのリストが「クローズド」だとしよう。であれば、このリストは永遠に空白のままである。よって、このリストを使えるものにするためには、一度オープンにしなければいけない。閉じていた門を開くのだ。

screenshot

朝の計画で、3つのタスクが追加された。これはサンプルなので、もちろんあまりにも少ないが、とりあえず一日分のタスクだとしておこう。そして、実行開始だ。この時点で、このリストを閉じることになる。どうやって? 残念ながら具体的な方法はない。今のところできるのは認知的な操作だけだ。

何か新しい「気になること」が発生したとしよう。「Amazonの発送状況を確認する」でもなんでもいい。そうしたものを、思いついた瞬間に、タスクリストに追加してしまえば、そのリストは閉じていないことになる。ここがポイントだ。

そのリストが閉じているならば、そのリストには新規で要素を追加できないのだ。そして、最初にリストを閉じたならば、基本的にそのリストは閉じっぱなしになっているはずだ。よって、何か「気になること」が思いついても、それをリストに追加してはいけない。

いけない、というか、追加してしまうとそのリストは閉じていないことになる。逆に、追加しないならそのリストは閉じていると呼べる。

もちろんそれは机上の空論というか、一つの理想状態を示している。追加のタスクが発生することは山のようにあるだろう。そのとき、どうすればいいのか。

screenshot

一時的に、別の場所に置いておくのだ。その場所はinbox(受信箱)であってもいいし、私のように「欄外」であってもいい。なんであれ、閉じているリストに直接追加をしないのだ。むしろ、直接追加しないことをリストが閉じていると呼ぶ。

人間の認知は重要度よりも緊急度に重きを置く。何かを思いついた瞬間は、それがすごく大切なことのように思える。しかし、ちょっと考えてみれば「別に、今日やらなくてもいいよな」と思えることは多い。その、「ちょっと考えてみる」ことが重要なのだ。それがリストのコンテキストを維持してくれる。

メタファーを使えばこうだ。

まず、門がある。一日の最初に門が開き、そこに何人かが入る。その後、門番はその門を閉じ、閂をかける。その後、新しい人がやってくるが門は閉まっている。人々は仕方がないので、その門の前で並ぶことになる。昼の鐘が鳴ると、門番がやってきて、列に並ぶ人々を確認し始める。「よし、お前は通れ」「だめだ、貴様は入れない」 そのようにして列が「整理」されていく。門の中は完璧な静寂とは言えないものの、ある程度の秩序が保たれている。

これがリストを閉じる、ということだ。難しいことは何もない。基本的には認知上の操作である。あるリストにほいほい要素を追加するのか、いったん置いておいて、判断してから追加するのか。この「判断し、追加する」とき、そのクローズドなリストは、一時的にオープンになる。でも、追加が終われば、再びそのリストは閉じる。その繰り返しである。

さいごに

この操作には二つのメリットがある。一つは、リストのコンテキストを制御できることだ。「一日のやることリスト」を言葉通り、「一日のやることリスト」に保てる。たいていほいほい要素を追加していると「一日のやることリスト」は「一日にできたらいいなリスト」へと変身してしまい、そのリストに掲載されている行動に取りかかろうという意欲(取りかからなければならないぞというモチベーション)を阻害してしまう。リストについての一番の警句は、「混ぜるな危険」なのだ。

もう一つのメリットは、「コントロールしている感覚」である。これは、タスク管理を含むセルフマネジメント全般において重要だ。周りの状況に反応するままにタスクリストにタスクを追加していると、主体的な感覚がどんどんと消えていく。何に身を任すのか、身を任さないのかの感覚すら消える。これはあまりよろしくない。

どうあがいても「やらなければいけないこと」はやらなければいけないのだが、それでもそこに僅かばかりのコントロール要素を入れるのは、そんなに悪いことではないだろう。

Send to Kindle

タスクリストのオープンとクローズドについて

次の記事を読みました。

クローズドリストでプロジェクトを管理する – ForGetting Things Done

タスク管理について知識のある方は、「これじゃオープンリストじゃなくてインボックスじゃないか」とお思いになるかと。おっしゃる通りで、今の私にはこの2つの違いがいまいち分かっておりません。

基本的にこの二つは同じですね。同じ、というか片方がもう片方の説明になっています。

オープンリスト

「オープンリスト」とは、オープンなリストということです。直訳すれば、「開いた(閉じていない)リスト」の意味で、いくらでも自由自在に項目を追加できるリストを指します。

このオープンリストは、リストの性質を示しているに過ぎません。「オープンリスト」という具体的な機能を持つリストがあるわけではないのです(もちろん、作ることは自由にできます)。

パソコンの中にあり、そのパソコン内でしかアクセスできないものを「ローカルファイル」、などと呼んだりしますが、もちろん「ローカルファイル」というものが具体的に存在するわけではありません(もちろん、作ることは自由にできます)。

ローカルは、そのファイルの一つの性質(属性)を示す言葉であり、オープンもそれに対応します。

オープン(/クローズド)は、そのリストが開いているかどうか(自由に項目を追加できるかどうか)についての性質に言及しているだけであり、そのリストにどんな項目が並んでいるかはまったく無関係です。

インボックス

インボックス(受信箱)は、新規のタスクが入ってくる場所です。でもって、これはリストでもあります。

「inbox zero」という思想は、「受信箱をタスクリスト代わりにしてはいけない」というコンセプトが背景にあるわけですが、逆に言えば、受信箱がタスクリストの代わりとして使えてしまう、ということでもあります。なぜなら、受信箱はリストだからですね。受信したものが、一列に並んでいる。もうこれだけで、「リスト」と十分に呼び得ます。

インボックスはリストなのです。

では、どんなリストかと言えば、「新しいタスクがどんどん入ってくる」リストなので、必然的にこれはオープンになります。クローズドなインボックスというのは、概念的に矛盾するのです。

よって、インボックスは、たしかにオープンリストです。オープンリストな性質を持っています。

さいごに

ちなみに、「チェックリスト」も、名前から分かるとおりリストの一種ですが、これは概念的にはクローズドな存在です(あるいは、クローズドであるべき存在です)。

名前を整理して整えておくと、

・インボックスリスト→オープンリスト
・タスクリスト→?
・チェックリスト→クローズドリスト

となっていて、「じゃあ、タスクリストってどう運営するのよ?」という話に対し、「You、クローズドでいっちゃいなよ」と言ってくれているのが、『マニャーナの法則』なわけです。これが大変有用な提言であることは間違いありません。

が、それはそれとして、「オープン/クローズド」は、性質(属性)の一つであると書きました。そして、この考え方は実はパソコンのファイルにもあります。

set fn to open for access file fpath with write permission
set fn to open for access file fpath

この二つは「ファイルを開く」という行為自体は同じですが、write permissionの有無に違いがあります。そして、write permission がなければ、どれだけファイルの中身を取得できても、それを書き換える(書き加える)ことはできません。つまり、 write permissionなしの状態はクローズドであり、 write permissionありの状態はオープンなのです。

「オープン/クローズド」が性質(属性)の一つであるならば__つまり絶対的な役割を意味しないのなら__、それらは変更(切り替え)可能なはずです。でもって、それがタスクリストを含めたリスト全般を運用していく上に必要な考え方だと、最近考えております。

▼こんな記事も:
R-style » オープン・リストとクローズド・リスト

▼こんな一冊も:

仕事に追われない仕事術 マニャーナの法則・完全版
ディスカヴァー・トゥエンティワン (2016-10-22)
売り上げランキング: 27
Send to Kindle

誰ガ為のタスク管理

次の記事を読みました。

タスク管理は「できる社会人の仕事ツール」ではない | Todoist Blog (日本語)

タスク管理は「できるビジネスマンの仕事術」ではなく、その逆、「要領が悪い人のサバイバルツール」なのです。わたしも、自分の電話番号を覚えられなかったり、仕事が多いと混乱して投げ出したくなるタイプなので、そういう人を応援したくなります。

もちろん、タスク管理は「できるビジネスパーソンの仕事術」であってもよいのです。というか、まさしくそれが当てはまるでしょう。それと共に、「要領が悪い人のサバイバルツール」でもあります。ここが重要なところです。

一見両極端に見えるこの二つのタイプの人にとって、タスク管理が役に立つこと。それが、タスク管理の根源に至るための道です。でも、別に多くの人はそんなところに至りたいわけではありません。それぞれの人が、自分が求めるものに応じてタスクを管理していけばいいだけです。

逆に、タスク管理が必要ない人は、「今のままの状態で十分」な人でしょう。そういう人には、ありとあらゆるノウハウは必要ありません。なにせ、ノウハウは変化をもたらすものなのですから。

あなただけではない問題

ときどき、「もうちょっとメモを取った方がいいよ」とか「やることを管理したら」というようなことをやんわりアドバイスすると、怪訝な目で見られることがあります。まるで、普通に手を伸ばせば届くところに吊り下げられているバナナを取るために、足を載せる台とバナナを叩く棒を使えと指示されたかのような目つきです。

たぶん、「あなたは記憶力が悪いですね」と言われているように感じるのかもしれません。それは半分正解で、半分間違いです。たしかにその人は記憶力が悪い。でも、それを言う私も記憶力が悪いし、なんなら全人口の99%は記憶力が悪いのです(ごく稀に記憶しすぎる人もいます)。

別にその人だけが記憶力が悪いわけではありません。

「タスク管理」という言葉

「タスク管理」に類するものを嫌う人は、ようするにそのままの状態で問題を感じていないか、あるいは上記のような自分の能力の欠損を指摘されることに対する嫌悪感を持っているのかのどちらかなのでしょう。

しかし、タスクを管理をすることは、ごく簡単に言えば「まっすぐな線を引きたかったら、定規を使った方が良いよ」という程度のことでしかありません。きわめて普通のアドバイスです。

ただ「タスク管理」という言葉の語感が、必要以上の印象を与えていることはあるでしょう。それと同じことは「知的生産の技術」においても起きています。「知的」という言葉が必要以上に「知的」な雰囲気を生み出しているのと同様に、「タスク」という言葉が意識の過剰な高さを彷彿とさせ、「管理」という言葉が、管理者(マネージャー)的雰囲気を生み出しているのかもしれません。言葉というのは、なかなか扱いが難しいものです。

おそらくGTD本が日本で売れたのも、「ストレスフリーの整理術」というタイトルだったからでしょう。このタイトルには間口の広さがあります。なにしろ、仕事でストレスを感じていない人など1%ぐらいしかいないでしょうから。

だからタスク管理も、「やること整理術」ぐらいに言い換えれば、今よりは認知が広がるのかもしれません。なにせ、仕事や生活で「やること」を抱えていない人などほとんどいないでしょうから、射程は広そうです。

さいごに

たぶん、「要領が悪い人のサバイバルツール」という文脈でコンテンツを作っても、そこそこ支持されるでしょう。そういう本は、案外今のビジネス書では出ていなくて(もちろんゼロではありませんが)、掘り下げがいがありそうです。

それはそれとして、私はもう少し広い「やること整理術」の視点でまとめてみたいかなとも思います。

Send to Kindle

プロジェクトについて あるいはタスク管理概論第12回

のきばトーク第九回収録しました。テーマは、プロジェクト管理ツールについて。


たとえば、こんな講義があったとして

では、タスク管理概論第12回の講義を開始する。

今回のテーマは「プロジェクト」について。おそらく、タスク管理の中でも一番扱いが難しい概念だろう。

プロジェクトとは、一番広い意味では複数のタスク、あるいはステップが集まったものを指す。厳密に定義すれば、複数の実行日を持ち、かつ終了日・締切日を有する、異なるタスクの集合体となるだろう。当然、それらのタスク群は、ある一つの結果・成果を目指すためのものであり、それがプロジェクトの目的と呼ばれることもある。

なにか具体例を上げてみよう。

私はこの講義を行うために、講義ノートを作成した。そのために図書館に行って、いくつかの本も借りてきた。ノートが完成したら、それに合わせたスライドを作った。そして、今こうしてその講義を行っている。プロジェクト的視点でこれらを整理すれば、

タスク管理概論第12回の講義
・12回目の講義ノートを作成する
・必要な資料を図書館で借りる
・ノートを参照してスライドを作る
・実際に講義を行う

となるだろう。この場合、「タスク管理概論第12回の講義」がプロジェクトであり、またプロジェクト名として扱われることになる。

ここまではいいかね。何か質問は? 

「なぜ、プロジェクトという概念を用いるのでしょうか。タスクだけだと問題があるのでしょうか?」

良い質問だ。君、名前は? じゃあ、田山くん。一緒に考えてみよう。

* * *

なぜプロジェクトを用いるのかと言えば、むしろすべてをタスクとして扱うためだと言える。混乱するかもしれないが、ゆっくり進めていこうじゃないか。

田山くん、いま何か気になっていることはあるかね。前々回のときに話した「やるべきこと」だよ。

「えっと、アウトライナー実践入門のレポート提出が来週にあります」

なるほど。あの講義にも出ているわけだ。なかなか熱心だね。さて、君は今「やるべきこと」をイメージして「アウトライナー実践入門のレポート提出」を思い浮かべたわけだ。では聞くが、これは「タスク」かね?

「タスクのような気がします……」

そうだろう、そうだろう。私もそうだと思うよ。だからそれをタスク管理ツールに入力するわけだ。「アウトライナー実践入門のレポート提出」と。何なら締切日を入力してもいい。それでどうなるだろうか。

もちろん、直前までその「タスク」は放置され、ギリギリで大慌てすることになる。身に覚えのある人はちょっと手を上げてみて。うん、良かったね。田山君ひとりではないようだよ。そして、かくいう私も似たようなことをさんざんくり返してきた。

いいかい。これが大切なことだ。「やるべきこと」は「タスク」だとは限らない。

さて、「タスク」の定義を誰か覚えているかね。Google先生に尋ねるのは禁止だよ。

はい、そこの君。

「実行できる最低限のアクション、だったと思います」

その通りだ。名前は? うん、華山さん。端的な表現をありがとう。

セルフマネジメントにおけるタスク管理は、行動を管理することが目的だ。そして、その行動単位が「タスク」と言える。「レポート提出」は、たしかに「やるべきこと」かもしれないが、それは単一のアクションではない。でも、それは言葉で表現すれば、いかにもタスクっぽいたたずまいをしている。ここにトラップがあるんだ。

ちょっと考えてみれば、レポートを提出するためには複数のアクションが必要になることがわかる。さらにそれが複数の日にちをまたぐことも珍しくない。それをたった一行入力した「レポート提出」というタスクで管理できると思うかね。難しいだろう。

そこで「プロジェクト」という概念が登場するわけだ。

* * *

さっき、「ちょっと考えてみれば」と言ったね。実はこれが鍵なんだ。

結論から言ってしまえば、「プロジェクト」とは、「やるべきこと」について考えるためのフレームだ。ここが少しややこしい。何しろ、現実に≪プロジェクト≫というものが存在するからね。君たちはまだそんなに遭遇していないかもしれないが、会社にでも勤めればそこら中で、プロジェクト、プロジェクトと言い合っている風景が目に入るだろう。

そういう文脈における≪プロジェクト≫は、確固たる存在だ。言い換えれば、≪プロジェクト≫として存在している。しかし、タスク管理における「プロジェクト」はそうじゃない。あくまで、「やるべきこと」を「プロジェクト」として扱うだけだ。それは極めて恣意的な操作に過ぎない。

言い換えれば、「プロジェクト」としての存在が先にあるのではなく、まず「やるべきこと」があって、それを「プロジェクト」として扱う判断を下すだけなんだ。

ちょっとわかりにくいかな。

「具体的には、どのような違いがあるのでしょうか?」

もっともな質問だね。まず言っておきたいのは、会社の≪プロジェクト≫は、自分のタスク管理における「プロジェクト」に一致することが多い、ということだ。

たいていそれは複数の行動の複合体であり、数ヶ月先を見据えた企画だからこれは当然だろう。しかしだからといって、会社の≪プロジェクト≫の考え方をタスク管理に持ち込む必要はない。それらは基本的に別の考え方なんだ。たまたま合致するところがあるに過ぎない。

で、具体的にどのような違いがあるかと言えば、会社における≪プロジェクト≫は万人にとっての≪プロジェクト≫になるが、タスク管理ではそうではない点があげられる。同じ「やるべきこと」が思い浮かんでも、ある人にとってはそれは「プロジェクト」になるかもしれないし、別の人にとってはそうではないかもしれない。

いいかい。何か「やるべきこと」が思い浮かんだとするね。そして、それについて考える。その内側に、いや下にと言った方がいいかな、ともかくその「やるべきこと」に属する複数のアクションが思い浮かんだら、その瞬間にそれは「プロジェクト」になる。

それは初めから「プロジェクト」として存在していたわけではない。君たちが「考えた」結果として、それがプロジェクトになるんだ。

* * *

ここから三つのことが言える。

第一に、「やるべきこと」は、単に保管するだけでなく、それについて考えることも必要だ。

第二に、だから「やるべきこと」について考えるツールも必要になってくる。そのツールは、ある要素の内側、あるいは下に別の要素を発生させられなければならない。「やるべきこと」について考えるとは、まさにそういう類の行為だからだ。

第三に、プロジェクトは定型ではない。よって、「やるべきこと」を扱うツールには一定の柔軟性が求められる。「プロジェクト」一つとってみても、属性や粒度は複数存在するし、それによって情報の扱い方も変わってくる。

さて、そろそろ時間なので、今回の講義はこれまでとしておこう。

次回は、そうしたツールに求められる要件と、「プロジェクト」の属性についてもう少し突っ込んだ話をしよう。では、また来週。

Send to Kindle

脱線はやる気の近くで起こる

原稿を書こうとテキストエディタを立ち上げる。そのうち調べ物が出てきてWikipediaなんかにアクセスする。当然ブラウザを開くことになるので、そこでついついTwitterのタブを立ち上げる。そして失われていく5分、10分。

ええ、よくありますよね。日常的な風景です。

そういう失われ方をしていく時間を一日トータルすれば、きっと30分以上になるでしょう。嗚呼、なんたること。

でもふと考えます。たとえば書くべき原稿があるとことを意識した上で、それをまったく無視して本棚から漫画本を取り出し、それを30分読み漁るとしましょう。きっと、罪悪感はものすごく大きいのではないかと思います。だから、そういうことはあまりしないでしょう。

これを逆から眺めます。

テキストエディタを立ち上げ、そこからTwitterを覗いているとき、私は「作業をしている」気持ちの近くにいます。でも、漫画本を取り出して腰を据えて読み始めるのは、そうではありません。そこには明確な「自分は作業をしない」という決意の表明が伴うのです。

もし、Twitterのリプライが盛り上がって10分ほどが消費されたとしましょう。それは、机から立ち上がり、タバコ休憩している人たちに近づいていって10分ほどおしゃべりするのと、消費された時間で見れば同じ行為です。しかし、心理的にはそうではありません。後者は「やる気」の近くにはいないのです。

原稿を書いているときについついTwitterを見に行ってしまう行為は、「脱線」と呼ばれます。見事なネーミングです。本線を走っているときに、急に別の路線にズレ始めるのです。でも、まだ電車は走っています。ここがポイントです。

脱線しているとき、私の意識ではその行為は「作業の中」に含められています。それは脱線している最中にはほとんど罪悪感を覚えないことから確認できます。もし作業の外にあるなら、漫画版を読みふけるような罪悪感が生じるはずだからです。気分的には、脱線していてもそれは「作業中」なのです。

これはなかなか厄介な問題です。たとえばある会社の建物に入るとき、社員証を警備員に提示しなければならないとしましょう。厳重な警備に思えます。しかし、それは逆に言えば社員証さえ偽造できればいくらでも潜入できるということでもあります。パス、というのはそういう機能を持っています。

作業の脱線が心理的に作業に含められるとすれば、そこではいくらでも脱線的作業が発生する可能性があります。作業をしていないという罪悪感のブレーキが働かないので、いくらでも時間が浪費されていくのです。

しかしながら、生産性的観点からいえばそれらは実際には作業ではないわけで、「やる気を持って作業をしたけども、あまり成果は上がらなかった」ということになります。言うまでもありませんが、これは非常に疲れます。

だから、まあ、仕事術でよく言われる対策が出てきます。

  • 絶対に脱線的作業ができないようにしておく
  • 作業中はタイマーを使う
  • 行動の記録を取る

脱線的作業が行えないなら、脱線的作業を行いようもありません。ポメラが人気なのがわかりますね。

またタイマーをセットするのもそれなりに効果的です。当然、自分の行動を強制することまではできませんが、意志の力を発揮させる助力にはなってくれます。

最後の行動の記録は__たぶん一番面倒ですが__認知的な力強さがたしかにあります。行動の記録をきちんとつけると__家計簿がそうであるように__脱線が脱線とはっきり認知されはじめます。これまで「作業中」に含められていたものが分離されていくのです。つまり、罪悪感を覚えるようになります。

もちろん、それを覚えた後でその人の行動がどう変わるかはまではわかりません。家計簿を付けていても浪費を繰り返す人は山のようにいるわけですから。

こういうのはちょっと堅苦しいような、自分を締め付けるような感じを与えるかもしれません。でも、よくわからないまま30分を失ってしまうくらいなら、腰を据えて漫画を読む方が精神的満足度は高いような気がします。

仕事をきっちりこなして「今から30分は漫画を読むぞ」と宣言する。

まあ、毎回そんなにうまくいくとは限らないでしょうけれども。

Send to Kindle

WordPress Themes