Murga

個人的に言いたいコト・主張・気持ち。

6年目のエンジニアが日々のスケジュールを立てて予定どおり実行していくためにやっていること

新卒からレガシーなニホンノエスイーとして4年、モダンなフロントエンドエンジニアとして2年やってきた凡百な SE が、普段どうやってスケジュールを立てたり、タスクを遂行したりしているのか、私見を書いてみる。

僕にとっては至極当たり前にやってきたことばかりだが、僕にとっての「当たり前」は、もしかしたら誰かの役に立つかもしれない?と思って書くことにする。

1日の始め方

平日、仕事がある日。朝起きて、支度をして、電車に乗って、職場に到着するまで、僕は特に仕事のことを考えない。スマホで RSS やはてブを見たり、時にはゲームをしたり、完全にプライベートな時間にしている。仕事のことを考えたくなることもないので、自然な振る舞い。

職場に着いたら、パソコンを付けつつ、フランクリン・プランナーというシステム手帳でその1週間および1日の予定を立てている。これからお話する手法の多くは、フランクリン・プランナーが提唱するタスクマネジメントの手法に基づいている。

↑僕は1日1ページタイプ、A6 サイズのオーガナイザーを使っている。1日2ページタイプだとか、サイズのバリエーションもあったりするので、好みのモノを探してみると良いだろう。

1週間の予定を立てる

フランクリン・プランナーには、

  • 1ヶ月カレンダー
  • 1週間のミッション・ステートメント
  • 1日のスケジュール

を書けるページがそれぞれある。

「1ヶ月カレンダー」のページは、一般的な用途どおり、その日時に入った予定を書いている。なのでコチラは特に触れることなし。

「1週間のミッション・ステートメント」ページは、1日のスケジュールページの間に挟まっていて、1週間の始めに「その1週間でやるべきこと」などを書いたりするページ。フランクリン・プランナーを作ったフランクリン・コーヴィ氏の著書「7つの習慣」でも触れられているが、タスクを1日の予定に当てはめていくだけだと、人生で大切なものに使う時間を中々取れなかったりする。そこで、1週間単位で「自分の人生で重要なもの」を実践する予定を考えておくのだ。そうすると日々のスケジュールに「重要なこと」を組み込みやすくなるのだ。

完訳 7つの習慣 人格主義の回復

完訳 7つの習慣 人格主義の回復

  • 作者: スティーブン・R・コヴィー,フランクリン・コヴィー・ジャパン
  • 出版社/メーカー: キングベアー出版
  • 発売日: 2013/08/30
  • メディア: ハードカバー
  • この商品を含むブログ (9件) を見る

月曜の朝は「この1週間でやるべきこと」をミッション・ステートメントとして立てる。それ以外の曜日は、月曜に書いたミッション・ステートメントを見直して進捗を書いたり、「やべ、やり忘れてた…」などと悔い改めたりしている。

1日のスケジュールの立て方

で、「1日のスケジュール」ページに入る。

昨日の予実を見る

まずは昨日のページを軽く見る。昨日はどんなタスクがあって、どんな風に予定を立てたか、それに対してどんな実績だったかを見る。今日に残っているタスクもココで確認できるし、昨日の振り返りも簡単にできる。「昨日はコレにつまづいたから、今日はこうしてみよう」とか、「昨日やったコレが上手く行ったから今日もやってみよう」とかいう感じだ。

タスクと、重要度・取り組む順番を洗い出す

昨日の予実を確認したら、今日のページに移動する。その日に行うタスクを、

  • 重要度
  • 取り組む順番

とともに書き出す。

重要度は A・B・C で、以下のような分類で書いている。

  • A:その日中にやり終えるべきこと・今日が締切なもの
  • B:2・3日中に完了すべきこと
  • C:近い間に締切がないが、時間が出来たらやりたいこと

着手する順番は中でも Must なモノから書いている。つまり重要度 A の中でもコレはどうしても必須、というようなモノや、打合せなど他人に影響のあるモノが優先だ。ただ、そこまで神経質に項番を決めなくても良い。だいたい重要なモノから、という感じで書けていれば良い。

重要度と着手する順番をセットで書くので、以下のような感じでタスクを洗い出せることになる。

  • A1:13〜14時 □□に関する会議に出席する
  • A2:○○機能を実装する
  • A3:○○機能のレビュー依頼を出す
  • A4:▽▽ツールの検証をする
  • B1:▽▽ツールの検証結果を共有する
  • C1:共有フォルダを整理する

僕はタスクを書く時、体言止めで書かないようにしている。アクションが曖昧になるからだ。

タスクをタイムスケジュールに当てはめていく

こうして1日のタスクと重要度、ある程度の着手順を洗い出したら、タイムスケジュールにタスクを配置して、時間配分を決めていく。

13〜14時は A1 タスクの会議があるから、午前中に A2 タスクを終わらせ、昼休み15分前には A3 タスクを少しだけ着手しておこう。昼休み後は A1 タスクの会議後、A3 タスクに戻って15時30分から A4 タスクに入ろう。…という感じだ。

タイムスケジュールに予定を書く際は、左半分だけ使うように書く右半分は実績を書くために空けておく。

なお、B・C 群のタスクは基本的には「予定」には組み込まない。「A 群のタスクが早く終わったらスキマ時間にやること」の備忘として書いておくのだ。だから B・C のタスクはそうそう終わらないので、大抵は毎日タスクリストに書き出すことになる。B タスクは締切が近付くと A タスクとして扱うようになり、C タスクも重要になれば B タスクに格上げ、もしくはスキマ時間で片付けて、最終的には全タスク片付けられる、という算段だ。

タスクは細かく分割する

洗い出したタスクの粒度が大き過ぎると、「1日に1タスクも片付かない」かのように見えてしまうこともありうる。タスクは細かく分割して書いた方が良い。例えば上述の例で「A2:○○機能を実装する」といったタスクを作っているが、例えばこの実装タスク一つが3人日かかるタスクなのであれば、作業内容からタスクを細かく洗い出す必要があるだろう。

  • ○○機能を実装する
    • まずは画面が出来ていないと分かりづらいので、HTML から組む … 3時間くらい (新しい CSS フレームワークの使い方を勉強しながら作るので、普段よりは時間かかりそう)
    • 次に、画面操作で実行される関数をコンポーネントに実装する … 1時間くらい (関数の中身は空っぽ・イベントの洗い出しに留める)
    • コンポーネントから呼び出すサービスクラスのうち、登録機能を作る … 3時間くらい (前に作った◇◇登録機能がそれぐらいで作れたので)
    • サービスクラスのうち、更新機能を作る … 4時間くらい (トランザクション処理が入るため)

…などというように、あるタスクの内訳を超概算で想像するのだ。どんな作業があるか、それぞれどのぐらい時間がかかるか、その根拠や、そのタスク内でやらないことなどを書いておく。後はコレを順に A1・A2・A3… とタスク化すれば良い。

1タスクの粒度は2・3時間を上限に分割しておくと、作業中に進捗が確認しやすいだろう。

これらの作業は始業10分以内にやる

このように1週間のミッション確認と1日の予定を立てるのは、始業後5〜10分くらいで終わらせている。

実績を付ける

予定を立てたら、予定どおり各タスクに着手する。

作業をしながら30分ごとぐらいに、予定を書いたタイムスケジュールの隣に実績を書いていく。作業中のタスクを書いて、予定どおり行っているか確認する。

予定どおりなら OK

予定どおりの時間で終わったら OK。予定の見積が正しくできていたということだ。問題ないので次に進もう。

予定より遅れていたら

予定よりも時間がかかっているようであれば、あとどのくらいかかりそうか、その場でチェックする。見積が甘かったのか、途中に想定外のタスクが入ったせいなのか、原因を明らかにする。理由がどうであっても、次回からはそれらの原因を予定に組み込んでおくことが大事。

突発的な作業が発生しやすいようであれば、突発作業がタスクの間に挟まることを考慮して、そのタスクの終了時刻を想定するのだ。

事前に予測する術があったのに、それを見落としていたという場合は、見積の甘さが原因。タスクをより細かく分割して書き出し、具体的な作業イメージを付けられるようにする必要がある。

基本はこの試行錯誤を繰り返し、速く精度を上げていくことが、タスクマネジメント・見積スキルの向上に繋がるであろう。

予定より早く進んでいたら

予定より早く進んでいるとか、予定より早く終わった、とかいう時は、どうやって早く終わらせられたのか、その要因を書き留めておこう。特に工夫をしていないのに早く終わったという時は、見積が自分に対して甘いかもしれない。

予定を組む時にやるべき仕事量を減らしておいて、予定どおり行った、予定より早く終わった、と喜んでいても、成果が少ないのは事実。そうではなく、予実の乖離が少ないことが望ましい。短時間で終わる作業は短時間で終わると正しく見積もれるべきだ。

エンジニアたるもの、繰り返しの作業に毎回同じだけの時間をかけるような働き方はしてはならない。だから、予定より早く進んだ時は、「前回の実績を踏まえてこういう工夫をしたから早く終わったのだ」と説明できることが望ましい。


こうした振り返りを、30分〜1時間おき、各タスクが終わった時に、実績を手帳に書き込みながらサラッと行う。振り返りに何分もかける必要はないが、「何が遅れの原因だったか」「早く進められた効果的な取り組みは何だったか」といった内容は書き留めておきたい。

予定にないタスクが出てきたら

予定にないタスクが出てきたら、その瞬間にタスクの重要度を見極め、タスク一覧に追加する。そしてタイムスケジュールのしかるべき場所に差し込み、前後のタスクをズラす。こうした書き直しが発生することもよくあるので、僕はフリクション・ボールペンでフランクリン・プランナーに書き込みをしている。

予定は1回決めたら最後まで Fix するのではなく、遅延や割り込みタスクの発生に際しては適宜調整するべきだ。既にズレることが明らかになっている予定を、あえてそのまま変えずに置いておく意味はない。

以上。予定と実績の記録が大切

おさらい。重要なポイントは以下あたりだろう。

  • 1日の予定は2・3時間単位のタスクに分割して、細かくタスク一覧に書き出す (アクションが明確になるよう体言止めは避ける)
  • タスクの重要度を先に見極めてから、時間 (タイムスケジュール) に当てはめていく
  • 30分〜1時間おき、およびタスクが1つ終わった時に、予定の隣に実績を書き込む
  • 遅れた原因、もしくは「巻き」で終わらせられた工夫はメモしておく
  • 割り込みタスクもタスク一覧に追加し、タイムスケジュールを調整する

恐らくあまり仕事の能率が良くない人は、タスクをただ順にこなすだけなのではないだろうか。タイムスケジュールに順にタスクを書き込んでいって、1日8時間分になったら終わり、という短絡的な思考で1日の過ごし方を決めているのではないだろうか。それではダメで、何が重要で緊急か、それを先に見極めてから、大事なモノ順にスケジュールに組み込んでいくのだ。

一つひとつの予定作成・実績確認の作業には時間をかけず、サッサと行う。じっくり考えてもあまり効果はなく、「直感」に近い感覚で判断する。ただしその「直感」が正しかったかはきちんと振り返りを行い、次のタイミングでは軌道修正すること。振り返りと軌道修正を速いスパンで行い、「早く失敗する (そしてその失敗から課題を見つける)」のが大事だと思う。

これらのやり方のベースは、ホントにフランクリン・プランナーの推奨する内容そのまんま。オリジナルのやり方でもないし、銀の弾丸も別にない。こういうことを苦行と捉えず、日々淡々とこなしていれば、そのうち慣れて精度が上がってくると思う。ただ、頭を使わない反復では何ら成果を上げないので、ちゃんと頭は使うこと。

タスク管理に関してやっていることはこれが全て。実行力・効率を上げるための細かな取り組みは別途紹介するとしよう。

エンジニアのための時間管理術

エンジニアのための時間管理術

  • 作者: Thomas A. Limoncelli,株式会社クイープ
  • 出版社/メーカー: オライリー・ジャパン
  • 発売日: 2006/10/19
  • メディア: 単行本(ソフトカバー)
  • 購入: 11人 クリック: 322回
  • この商品を含むブログ (153件) を見る