「あとでやる技術」の正しい習慣がタスクに溢れた自分を救う。

「あとでやる技術」の正しい習慣がタスクに溢れた自分を救う。

まさくに

まさくに

こんにちは。バックエンドエンジニアのまさくにです。

さて、みなさんにとって「こいつは自分の人生を変えたもののひとつだなぁ」と思うものは何でしょうか。モノでもいいですし、作品でもいいですし、概念でも、もちろんヒトでもいいです。

昔、GACKTさんが「売れるために好きなものを断とうと思って、米を食べるのをやめた」とおっしゃっていました。それを思うと、人生を変えるには何かをプラスするだけではなく、何かをマイナスすることも含まれるのでしょうね。

それを聞いた僕は「よし、週刊少年ジャンプを読むのやめる!」と決めました。一回買ったら一週間の間に50回くらい通しで読んでいたジャンプを断つことを決めたのです。そう、制約と誓約です。10年くらい前のことですが、少なくともそれ以来使える時間は増えたと思うので、人生は変わったと言えるかもしれません。

もうひとつ、僕にはジャンプをやめたことのほかに、自分の人生を変えたもののひとつとして「Getting Things Done(GTD)を始めたこと」が挙げられます。GTDはタスク管理術、ライフハックの一種なのですが、ジャンプと違って明確に「GTDがなかったらこの戦局は乗り切れなかった」と思うことが仕事上、多々ありました。

今回はGTDの概念をベースにして仕事をしている僕が、タスクをどう作成し、実行しているかをお話したいと思います。「すぐやる技術」と対比すると、「あとでやる技術」と言えるかもしれません。

Getting Things Doneとは

Getting Things Done、略してGTDとはデビッド・アレンがその著書で提唱した、タスク管理術のひとつです。収集、処理、整理、レビュー、実行というフローを日々繰り返すことによって、タスクの進行をスムーズにするものです。

それぞれ概要は以下となります。

収集 頭の中にあるすべてのタスク、懸念点、問題を一度アウトプットすること。
処理 アウトプットされた情報を、今実施するか、もしくは後で実施するために分類すること。
整理 優先順位を決め、リスト化し、タスクを実行するのに適切な場所へ配置すること。
レビュー 定期的にこのフローを実施し、情報の最新化を行うこと。
実行 タスクに取りかかること。

Remember The Milkというタスク管理ツールと絡めたもう少し詳しい運用の話を、下記の記事なんかで書いたことがあります。

「なんだ、GTDって、ツールの使い方か」と思われたかもしれません。そうじゃないんです。GTDはツール自体の使い方ではありません。実際のところGTDで使うツールは自分が良ければ何でもいい、むしろ紙がおすすめといわれています。

だからWebサービスを使うこと、イコールGTDではありません。僕がたまたまタスク管理ツールのRemember The Milkを使っているだけのことで、GTDとはツールを使う以前の姿勢、タスクの運用方法だと思っています。でもRemember The Milkはとても良いツールなので、ご興味ありましたら使ってみてね。

タスクのほとんどはあとでやらなければならない

デビッド・アレン自身の書籍がありますのでGTDの詳細はそちらに任せますが、GTDの真髄はタスクの「レビュー(見直し)」にあると思っています。これによって情報の最新化がなされ、何も考えなくてもロボットのようにタスクと向き合うことができるようになるからです。

ただ、収集〜実行のルーティーンを一週間で回しているうちに、一回のレビューでは到底追いつかなくなってきました。やはり業界的な特徴なのか、あまりに変化が激しくて、タスクの変化に追いついていけないのです。そこで僕は大きなタスクレビューを土曜日に、小さなタスクレビューを日の終わりにすることにしています。

そのようなフローにしてから、気づいたことがあります。レビューから実行がロボットのようにできるようになってくると、タスクや懸念点、課題をスピーディに収集できていなければ、レビューの時に適切にタスク化ができないということでした。

発生するタスクを単純に割り込みで実行してしまうと、当然優先順位はめちゃくちゃになり、重要なタスクができないという事態になってしまいます。そうなんです。ほとんどのタスクは現実的に、あとでやるんです

そのため、次に僕が考えたことは「どうやってレビューまでこのタスクを覚えておこう?」ということでした。レビューまでそのタスクを覚えてさえいれば、整理の段階でリスト化されて、優先順位を考えることができる。そうすれば何も考えず、タスクを実行すればいい。でも、いまその整理をしている時間がない、という状態です。

そのように、僕は仕事においてタスクをちゃんと「あとでやる」ためにはどうすればよいか考えるようになりました。

前提として大切なスタンス

ここでまったく相反するように思えるかもしれないことを言うのですが、基本的に、社会って、仕事を先延ばしにしてはいけないんでしょうね。GTDでも「2分で終わる仕事はすぐやれ」が鉄の掟なのです。タスクはすぐ完了させることが絶対的に正しい

2分で終わる仕事を、いちいち見直しして、リスト化して実施するようなことをしていては仕事が進みませんし、同僚がみんな迷惑すると思いますし、評価は下がってしまうと思います。

降って湧いたタスクが、2分で終わるかどうかは即断すべきです。そして終わると判断したものは瞬殺すべきです。すべてのタスクは前のめりで完了させるつもりでいることが、「あとでやる技術」においても、前提として大切なスタンスです。それを忘れてしまうと、ただの仕事をやらないやつになってしまいます。

ですが、2分で終わらない「すべて最優先タスク」とやらが世の中には無慈悲に無限に湧き出てきます。本稿で対象としているタスクはそういったもので、「あとでやるために覚えておくしかない」タスクをちゃんと覚えておこう、というものです。

それでは次項からは仕事に携わる上で、よくあるシーンごと、タスクをあとでやるために、自分がしていることを述べていきます。

「あとでやる」ためのテクニック

メールを「あとで返す」

最近ではGmailやG Suiteで仕事のメールを受け取っている方々が多くなったのではないでしょうか。LIGでもメールはGmailを使用しています。Gmailはたぶんなんですけれど、GTDの考え方が設計に含まれてるんじゃなかろうか、と思っています。たぶんなんですけれど。それくらいGmailとGTDは親和性が高いです。

Gmailを使うにあたって、まず、僕が目指しているのはInbox Zeroです。Inbox Zeroというのは、処理が終わったものを順次アーカイブし、文字通り、受信箱にあるメールをゼロにしていく運用方法です。

メールが届くと、僕の場合、その時点でメールのほぼすべてのメールがフィルタリングされ、newsかworkのタグが振られます。newsはメルマガなど、システムから送られる「通知」を主にしたもので、多くは一度読んでしまえば不要となるものです。つまりそれらのメールの処理というのは、「読むだけ」を指します。読むだけでいいメールは一読し、アーカイブします。

次に、workは主に人から届き、やり取りが発生する可能性の高いメールになっています。まずここで、返信を2以内で終えられるか否かをチェックします。2分で返信が可能なものはすぐに返します。他のタスクに依存するなどで、2分で処理が終わらないだろうものはどうするかというと、場合によっては一次返信を行い、メールにStarをつけます。このStarが「あとでやる」ための重要なポイントです。まだ対応な必要なものについては、必ずStarをつけています。

それから定期的にStarがついているこれらのメールを見返し、他の依存タスクが終わったときなどにここに戻って返信をする、もしくはタスクとして扱うようにしています。このメールのStarによって、どんなにメールが来ても、必要なものを掘り起こし、ちゃんと「あとで返す」ことが可能になりました。そして対応が終わったメールに関してはStarを外すようにしています。

余談ですがこの「Star」って誰が考えた概念なのでしょうか。タグでもカテゴリでもない。ただマークだけをつけるというStarred。素晴らしい発想です。あとでさまざまなものを整理するという僕の運用方法からすると、森羅万象にStarをつけたくなります。

Slackを「あとで確認する」

LIGも基本的にSlackでのやり取りが多くなってきており、メールでのやり取りがなくなってきた代わりに、Slackでのスピーディなやり取りが求められることが多くなってきました。でもすべてのことをすぐ返信できるわけではありません。一日に数度は言いますよね。「承知いたしました。調べます」「承知いたしました。調整します」「マジか、やっとくわ」など。Slackを使っていたとしても、あとでやらなきゃならないことが、わんさか出てくる。

SlackでもGmailと同じ運用ができます。すぐ返信できるものはすぐ返信をしますが、そうではないものについては一次返信をしたあと、Starをつけるようにしています。Gmailに比べると、SlackのStarはあまり使われていないように思えるのですが、とても有用なのでぜひ使ってみてください。Macのデスクトップ用Slackでいうと、右上にStarされているコメントを一覧表示できるようになっていて、返信や処理が終わったものからStarを外していきます。

これによって自分が対応しなければならない情報に素早くアクセスできるようになります。また小さいことなのですが、自分がStarをしたということは人からは見えません。タスクの重要度を自分で分別できるのも小さいながら、大きな利点であるといえます。他人ってみんな自分の頼んだタスクが最優先だと思っているからです

Webページを「あとで見る」

このIT業界で生きていこうとすると、少なく見積もって何かしらのIT系の記事10記事は日々読むことになると思います。僕の場合、目を通しておきたいブログなんかのRSSはFeedlyに登録されていて、それをSlackに流すようにしています。

これによって気になる記事、あとで読む記事は前述のとおり、Slack上のStarがつけられて、適宜読んでいくことになります。この方法のいいところは、Slackを見るだけで、さまざまな「あとで確認すること、したいこと」がまとまっていることです。情報が散らばって保存されていると、それを確認するためのルーティーンも複雑になります。

情報については、できる限り、この「SlackのStarで保存しておく」を心がけていて、RSS経由でないあとで読みたい記事に出会ったとしても、僕の場合はSlackに自分で一度投稿して、Starをつけておく運用にしてあります。

文書を「あとで書く」

以前、こんな記事を書きました。

この頃は殴り書きをするためのアプリを探していたのですが、もう少し考えて、「殴り書き」がしたいときって、たとえばSlackやメール、あるいはEvernoteなどへ「清書」する前にバッファとして書く場所があればいいんだと気づいたんです。

そのため、上記記事にも書いてあるアプリ、「エディ太郎」をホットキーで起動できるようにしておいて、ふと何かの文書を残したいときはこれを素早く起動して書き込むようになりました。

エディ太郎は極限まで機能を削ったシンプルなアプリです。思いついたことをここに書く、必要であれば、これをまた必要なときに見直して、適切な場所へ「清書」をするようになりました。今のところ、「あとで書く」ことについては、この手法がもっともしっくりきています。

タスクを「あとでやる」

Remember The MilkのInboxに入れましょう。

いや、僕はRemember The Milk使ってるからなんですけど、タスク管理ツールに入れるのであれば何でも構いません。ホットキーでそれを起動できるようにしておきましょう。少なくとも脳内に残していてはいけません。前述の「エディ太郎」でも構いません。作成時の文言は、あとで見返して内容を思い出せる粒度であれば入力するスピード優先で何でもいいです。これらを後で整理して、優先順位をつけてタスクにとりかかれるようにしましょう。

また「あとでやる」タスクとして意外と重要なのが、人に任せたタスクを回収することです。自分でも思ってしまっているのではありませんか? 「自分が任せたタスクを人は最優先でやってくれるだろう」いいえ、No、そんなわけがないんです。人に任せたタスクはすぐには返ってきません。回収するタスクも忘れる前に「あとでやる」ものとして入れておきましょう。

プロジェクト内のタスクであればプロジェクト管理ツールで共有されているかもしれませんが、会社員である限り、プロジェクトには紐付かないさまざまなタスクが実は発生していて、それを人にお任せしたとき、適切にリマインドや予定調整をしなければ、後々大きなリスクとなって降ってかかります。

もうひとつ、これはあまり人に言いたくない、おすすめのタスク作成術なのですが、たとえば人から「7月末に大きなリリースがある」などと同僚から雑談レベルで話されたとします。相談ですらない、雑談レベルで同僚の仕事状況を聞くこと、よくありますよね。

これは自分には直接関わりがないけれど、自分が覚えておくと誰かが助かるかもしれないタスクですその同僚が大変になるであろうときに、声をかけることをタスク化してしまいましょう。自分から声をかけることをタスク化してしまうのは、とても有意義に働きます。優しい世界に近づけますし、なにより、事故を減らせるからです。

タスク管理がゴールではない

タスクが整然と並んでいると、とても気持ちがよくなります。これまで書いてきたタスクを「あとでやる技術」は、タスクの漏れをなくすためのルーティーンといえます。

しかし、「あとでやる技術」を過信しないでください。まず、絶対に2分ルールを忘れてはいけません。タスク管理は、タスクを管理することがゴールではありません。タスクを期日内にしっかり終わらせることがゴールです。GTDはタスクを簡単に終わらせる技術ではなく、目の前のことに集中し、一つひとつ、着実に完了させるための技術です。完遂できなかったら、仕事ができないやつです。

さらにGTDはタスクの優先順位や締切を定期的に見返しますが、タスクのほとんどには超えられない締切が存在します。自分の都合を優先し、期限に間に合わないのも仕事ができないやつです。「あとでやる」ことが自分にとって甘えにならないように気をつけましょう。

モチベーションや気分、体調や時間的余裕などで常に不安定になっている自分に自分から指示を出して、漏れなく安定的なパフォーマンスを出せるよう、習慣を常に改善していきたいと考えています。

最後に、この場をお借りして謝罪したいのですが、管理部様、この前、経費精算の期日を過ぎてしまって申し訳ありませんでした。ちゃんと上記のような対応策をもって、改善していきたいと考えておりますのでどうか

それでは、皆さま、暑さに体調を崩されないよう。夏休みの宿題って8月31日まで手をつけなかった、まさくにでした。

この記事のシェア数

まさくに
まさくに バックエンドエンジニア / 伊藤 正訓

漢字で書くと正訓。バックエンドのエンジニアです。静岡と石川に住んだことがあり、現在は千葉に住んでいます。誰かが作ったシステムに対しては、正常系だけを通るように並列処理やデッドロックが起きそうな処理を避けて操作する職業病があります。好きな色は紫、好きなキーボードの位置は「i」、好きなご当地ヒーローはセッシャー1です。

このメンバーの記事をもっと読む
デザイン力×グローバルな開発体制でDXをトータル支援
お問い合わせ 会社概要DL