6
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 3 years have passed since last update.

自身のタスク管理方法の変遷

Posted at

論文の進捗が予想より良いため、空き時間で物書きをやることになりました。
ここ最近は研究がらみの作業が多く、技術的なインプットを怠っているため、表題のようなポエミーな記事となっております。

こんな人向けの記事

  • 企業での業務経験が少ない大学生

はじめに

少し自分の話をすると、1年ほど前から同じ企業に属しております。
そのこともあり、僕より後に入った社員に対しリモートペアプロをやりながらプロダクトのレクチャーを行う。といった機会がありました。

当然自分が手取り足取り教える立場にはあるものの、やはり「コーディングを行う」という面においてはお互い経験者です。
なので、相手がどういうプロセスでタスクを組み立てるのかを知りたく、初めの段階で「まずどういうことをしましょうか?」と質問をしてみました。

僕が期待していた答えとしては、

  • 「この〇〇というフレームワークには詳しくないので、まずは〇〇についてざっと調べます」
  • 「MVCであることは理解しているので、改修画面の実装をRouterから辿ってみてみます」

といった具合でしょうか。
ところが数十秒後に返ってきた答えは「わかりません」。

驚きはしましたが、その時ある思いが浮かび上がりました。

**「課題(タスク)分割"力"は人によって差がある」**ということです。
思えば自分も業務経験がほとんどない時期は、タスクを分割できず、「何をしようか...」と考えて1日が終わるなんてこともあったような...

しかし今は難なくやれていることから、**「課題(タスク)分割"力"はやり方次第で上げられる」**はずです。

今回は自身のタスク管理方法の変遷を辿ることで、うまくタスクを消化できない人にとってのとっかかりになれば幸いと思い、この記事を書くことにしました。

※今回は「プロダクトを完成させる」といった大きく長いタスクではなく、「この機能を実装する」といった小さく短いタスクを対象としています

1: 頭に浮かんだこと(タスク)を逐次遂行

プログラミングを勉強したての時(業務未経験の時)はこのようなやり方で作業をしていました。

  • "あれをやるためにはこれをやらないとだな" → 頭にいれつつキーボードを叩く
  • "次にこれをやったら、あれをやろう" → 頭にいれつつキーボードを叩く

プログラミング関連の知見を蓄えることはエンジニアになりたい人にとって重要ですが、それと同等に「頭の使い方」というのも重要です。
しかしそのことを知らず、自分はこのような手法(脳がスタックする手法)を取っていました。

デメリットとしては

  1. タスク遂行スピードが落ちる(次やることなどを頭に入れておかないといけないため)
  2. "次やること"や"大枠のゴール"を忘れてしまい「あれ、何のためにこれやったんだっけ??」となる

あたりかなと思います。

2番に関しては大袈裟な表現かもしれません。
似たような事象としては上司とかに「今何やってる?」といった旨の問いがきた時に即答できないことがあります。
「タスクの遂行」に脳のリソースが取られていて、「タスクそのものが何か」という記憶を掘り返すのに苦労するためです。
あまり良い印象を持たれないので、すべて脳に抱え込むやり方はオススメしません。

2: 考えていることをそのままメモに書いてみる & その日にやることをメモに書き出す

とある企業でインターンをさせてもらった際、レガシーで複雑なコードを読み込む必要がありました。
1の手法に限界を感じたのか、ひとまず考えていることをメモに手書きで書き出すようになりました。

すると嬉しいことに、脳が比較的スッキリした状態で作業に取り組めるようになりました。

のちに、「思考の整理学」という本を読んでわかったのですが、思考は書き出しておいた方が

  • "今"考える
  • "後で"思い出す

両者の面で良いとされています。
※詳細は忘れてしまいましたので原著を参照ください。30年以上前に刊行されたものですが、今もなお役立つ知見があるはずです。


また、その日にやることを書き出すようになってから、さらに進捗が加速しました。

脳のリソースを使う場面で顕著なのは「迷っている事柄を決める時」ということを理解しました。
一番疲れの少ない朝の段階でその日のやることを書き出すことで、意思決定のための時間が減り、結果的に進捗が加速したのだと思います。
このあたりの情報はDaigoさんの著書「自分を操る超集中力」という本に書かれていたので、気になる方はぜひ読んでください。

3: 個々のタスクの時間を測ってみる

詳細は忘れてしまったのですが、とある動画で「タスクの時間を測った方が良い」という旨の話をされていました。
これがきっかけで、自身も各タスクで時間を測るようになりました。

利用するアプリケーションは「Toggl」というものを利用していました。
※今けっこう機能がモリモリなようですが、自分は「Timer」にあたる機能のみを利用していました

詳細はこちらの記事が参考になるかと思います。

実際に利用してみると

  • タイマーを起動しているので単一のタスクだけを遂行するようになり、マルチタスクを防げる
  • ルーティンワークに対して割く時間を最小限に止めようとする気持ちになれる
  • 自分が試されているようで"やらないといけない感"が出る

といったメリットがあります。

デメリットとしては「複数のツールを利用せざるを得ない」ということです。
Togglを用いてタスク管理を行うことは可能ですが、たとえば軽めのメモを撮りたい場合は他のメモアプリなどが必要となります。
好みはあるかもしれませんが、"ツールをまたぐ"という行為が結構自分にとってはヘビーなものでした。

4: タスクもメモも単一のエディターに集約

紆余曲折あって、最近はエディターに何でも集約するようになりました。
"タスク管理"と"メモ"に当たる情報を逐次追加してごちゃ混ぜにする手法ですね。
たとえばこんな感じになります。

参考文献を考える
    一旦リストアップ//
    ひとまず確認//
        どういうことをやっていて、どういうことができていないか
    〇〇さんの書き方
        こういう論文→これは今後の課題としている
    他の書き方
        こういうアプローチ(複数引用)
    僕の研究
        レビューとユーザーの検索欄を元に推薦
    どういう流れにしようか
        該当者のすでにある情報を元になにがしを推薦するやつ(reviewをもとに)
        何かを実際に入力してもらい、(書籍情報をもとに)推薦するやつ
        自身の位置付けとしては、上記両者をうまいことまとめたやつだよということをいう        

大枠のタスクはインデントがない行になります。
上記だと「参考文献を考える」ですね。

それを達成するための小タスクがインデントの入った行となり、どんどんやることを細分化していく感じです。
しかし変わった点は「タスクだけでなくメモが入っている」ということですね。
これに関しては自分の理解で棲み分けができつつ、他のツールを行き来せずに済むので良しとしています。

終わったタスクについては行末に//を入れることで、簡単に見分けられるようにしています。

なお、図を書く場合は仕方なく手書きのメモをとるようにしています。

おわりに

つらつらと書いてみましたが、まだ確固たる手法を持っていない方は参考にしていただければ幸いです。

6
2
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
6
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?