Murga

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

「メモ」ではなく「ノート」を取ろう。僕の仕事でのノートの取り方・使い方

自分が日々仕事をしていく中で、仕事や時間に追われて後に何も残らないのは大変もったいない。

  • 「コレって前回の案件でもやったはずだけど、どうやったんだっけなぁ…」
  • 「このエラーメッセージ前にも出たけど、どうやって解決したんだっけ?」

こうした「既に経験があること」を忘れてしまったことで、また同じだけの時間を費やして調べたりするのはバカバカしい。こういうバカバカしい時間を生まないために、日々の業務中に、有用なノートを取ろう、という話。

今回も、僕がどのようにノートを取っているか、そのノートをどのように使っているか、僕のやり方を紹介する。

仕事のミスが激減する「手帳」「メモ」「ノート」術 (アスカビジネス)

仕事のミスが激減する「手帳」「メモ」「ノート」術 (アスカビジネス)

はじめに:メモとノートの違い

本題に入る前に、記事のタイトルにも書いた、「メモ」ではなく「ノート」を取ろう、というところについて。以前以下の記事で書いたが、僕の中では、メモは短期的な記録ノートは長期的な記録、と分けている。

neos21.hatenablog.jp

ポストイットなどに走り書きするような「メモ」は、その瞬間に情報を記録して、少し後に見返して必要な仕事に情報をつなげたら、用済みになる資料、という感じ。一方「ノート」は、「ノートブック」というように、冊子の形式で情報がまとまっていて、しばらく経ってから読み返した時に有用な情報群、という捉え方。

つまり、日々記録する情報は、短期的に役目を終えてしまう「メモ」ではなくしばらく後になって読み返した時にも役に立つ「ノート」として取る方がいいよね、という考え方に繋がる。

では、どうやって「メモ」ではなく「ノート」にしていくか、というところを順に紹介していこう。

ノートの形式:Markdown 形式で、日付ごとのファイルを作る

まず、ノートをどのように取るか。僕は日付をファイル名にした Markdown ファイルを毎日作って、1日の仕事をそこに全て書いている。ディレクトリ構成でいうと、こんな感じだ↓

MyNotes/
├ 2017/
│ ├ 201701/
│ │ ├ 20170101.md
│ │ ├ 20170102.md
│ │ └ ...
│ └ 201702/
│    ├ 20170201.md
│    └ ...
└ 2018/
   ├ 201801/
   │ ├ 20180101.md
   │ ├ 20180102.md
   │ └ ...
   └ 201802/
      ├ 20180201.md
      └ ...

月ごとのディレクトリを作るか否か、などは好みに応じて分ければ良い。個人的には少なくとも年単位でディレクトリが分かれていると、ディレクトリ単位で過去の情報を除外したりしやすいので、こうしている。

重要なのは、Excel などのバイナリ形式ではなくテキストファイル形式で書いていることと、日付以外の分割単位を持ち込まないことだ。テキストファイルだと後述するように検索がしやすいし、変にジャンル分けなどし始めると、「どこに何を書くか」を迷う時間がかかるので、あえて整理をしない。その代わりの「検索容易性」については後述する。

はじめてのMarkdown―軽量マークアップ言語の記法と使い方 (I・O BOOKS)

はじめてのMarkdown―軽量マークアップ言語の記法と使い方 (I・O BOOKS)

図や表などのファイルはどうするか

もしも、図や表など、Markdown で表現しきれないモノが出てきたら、当該日付のディレクトリを作って、その中に入れている。

201802/
├ _20180215/
│ ├ ○○打合せ資料.xlsx
│ └ ○○対比表.xlsx
└ 20180215.md

こんな感じで、ディレクトリ名の先頭にアンダースコアを付けている。ファイル名でソートした時にディレクトリだけ除外しやすいように、ということである。

日々の Markdown ファイルに書くこと

さて、日々の Markdown ファイルにはどのようなことを書いていくのか。まずは心構えから紹介する。

「今日何してたの?」に答えられる資料にする

上司に「今日何してたの?」と聞かれても、その日の Markdown ファイルを見せさえすれば納得してもらえる、そのぐらい「やったこと」を細かく書くようにする。「Markdown を見せながら口頭で補足説明すれば伝わる」ではなく、「Markdown を見せさえすれば伝わる」というレベルまで細かく書くこと。

来週の自分が先週の自分の作業実績を確認できる資料にする

1週間の始まりに、「先週何やってたんだっけ…?」となった時に、先週の Markdown を読み返せば完璧に思い出せるように書く。そのためにはその時取り組んでいた作業の経緯、きっかけ、目的なども明記しておく必要があるだろう。「何でこんなことやってたんだっけ?」とならないようにするためだ。

自分と同じトラブルに遭遇した人のためのトラブルシューティング・作業手順書にする

何かエラーや問題が発生して、それを解決できた、という時に、キチッと書き留めておいて、のちのち同じ事象に遭遇した人がその Markdown を見て解決できるような、そんな解説文書になるようにしておく。

  • エラーメッセージ、スタックトレースなど、事象が確認できる情報をコピペしておく
  • 何をしたらどうなったのか、コマンドや設定変更の操作などを細かく正確に書く
    • どのメニューの何の項目を開いたのか、値はどうしてどのボタンを押したのか、その操作順など
  • 何をしたら問題を解消できたのか
  • 結局何が原因だったのか。暫定対応した時の表面的な原因と、恒久的な対応をするための根本原因とを探る

こうした情報を書くようにしている。

きちんと書けていると、同じトラブルに遭遇した人がいた時に、実際に Markdown ファイルの内容をコピペして展開するだけで役立ててもらえる。

「自分のため」ではなく「他人のため」に書くつもりで

今の自分のことだけを考えて情報を記録しようとすると、どうしても「メモ」になってしまう。単語の走り書きだったり、「なんかエラーが出たけど直せた」などという文章だけでは、何の役にも立たない。

そうではなく、「来月の自分はもはや他人だ」「他の同じような人が読んだ時に役立つようにしよう」「今後引き継ぎする時に見せられるようにしよう」といった意識を持って、ブログを書くような、何か報告書をもってプレゼンをするような、そういった書き方にすると、有用性が高まると思う。

実際にどんな風に書いているかサンプル

こんな心構えで、自分がどんな風に日々の業務をノートに取っているか、サンプルを作ってみた。中身はその場でデッチ上げたモノで、実際の記述量よりはるかに少ないが、あくまで雰囲気ということで。

# 2018-05-08 (火)

雨降ってた。

## 朝の定例

- リーダが午後帰社 → 午前中に○○の質問しておこう

## (昨日の続き) `HOGE is not found` エラーが出た件

- (おさらい) ○○システムに HOGE コンポーネントを組み合わせると、コンソールに以下のエラーが出る。

```
Exception : HOGE is not found.
```

- ファイルが特定できないのかな?と思い、`HOGE.js``./src/components/` 配下に配置したが、変わらず。

- ネット検索
  - http://github.com/...
    - > This message is ... cause .... (参考文献からの引用)
    - ココによると、`Module.js` に設定追加が必要らしい
    - → 文献どおり `import : [ HOGE ]` を追加したが解消せず
- M さんに聞いてみた
  - `import` ではなく `provide` に書くとのこと
  - → やってみたら解決した
  - なぜ `provide` を使うかというと、HOGE は○○に属していて、□□ではないから、ということだった
  - もしも□□だったら、`import` で指定するのが正しい

```
// うまくいったコード
Module: {
  import: [ /* 省略 */ ],
  provide: [
    AlreadyItem,
    HOGE  // ← ココに追加した
  ]
};
```

- まとめ
  - コンポーネントを新規追加する時は、`Module` に追加する必要がある
  - 対象のコンポーネントの属性が○○なら `provide` に書く
  - 対象のコンポーネントの属性が□□なら `import` に書く

## ○○会議参加

- 出席者:M さん、O さん
- ○○の手法について検討
- 内容は「○○打合せ資料.xlsx」と「○○対比表.xlsx」を参照のこと
- 個人的には○○は△△の方が良いと思う。△△なら HOGEHOGE できるし、◇◇にはバグがあるし…。

大体こんな感じ。

ポイント

このサンプルで見せたいポイントは以下のとおり。

  • 1行目は日付を入れておく
  • 「雨降ってた。」みたいな業務に無関係な情報も、その日の記録として書いておくと、見返した時にちょっと楽しくなる。w
  • タスクごとに見出しを作る
  • 作業をしながら、やろうとしていること、やったことを、箇条書きベースで書いていく
  • 昨日から引き続きやっている作業は、「あらすじ」的な項目を書いて、経緯や目的を明らかにし直す
  • その瞬間の推測や予想も書き留めておくと良い
  • 読んだ文献は URL や引用と一緒に書いておく
    • それを参考にやったこととその結果も書いておく
  • うまくいかなかった方法、失敗したやり方も消さずに残しておく
  • 最終的に上手くいったら、原因や理由とともに、「まとめ」を書く
  • 外部ファイルがある場合は、そのファイル名を記載しておく
  • あとで grep しやすいように、検索したくなるであろうキーワードを含んで書いておく

だいたいこういったことに注意して書いている。

最後の「検索したくなるであろうキーワード」というのが、後で読み返す時のために重要。例えば「プロキシ設定の変更方法についてノートを取ったのに、『プロキシ』という文字列が一回も出てこなかった文章」になってしまうと、あとですごく探しづらい。だから、「あとでその文章を探したくなった時に、どんなキーワードを想像するだろうか?」を考えて、そのキーワードを含んでおくと良いだろう。

僕はこのようなやり方で、1日平均8000文字分ぐらいの Markdown ファイルを書いている。コードやコマンド、エラーメッセージのコピペや URL なども含んでの文字数ではあるが、だいたいこのぐらいは書いている。

他人のために書くと、ブログのネタにもなる

実は僕のブログは、こうしてまとめた日々の業務ノートをベースに、ちょこっと加筆修正したモノを記事として上げていることが多い。

他人に読んでもらうような前提で書いておくと、そのままブログだとか、Qiita だとかのネタにできる。そうするとさらに自分のノートが他人の役に立つし、ブログをうまく運営していけば収益だって上げられたりする。

紙資料・システム手帳との使い分け

紙でしか持っていない資料だとか、紙のシステム手帳に記録したことだとか、どうしても「自分ノート」以外の記録媒体を使う場面は出てくる。

そんな時は以下のように対応している。

可能な限りノートに転記する

システム手帳にメモした内容のうち、大事そうなものはノートに転記する。紙資料も、書き写せれば書き写して、紙資料を捨ててしまう。

「この紙資料に書いてある」とノートに書いておく

紙資料が充実していたり、手帳との併用が必要そうな時などは、「○○会議で話題になった△△モジュールに関しては、システム手帳の P180、5/8 のページに書いた」という風に、ノートに書いておく。

あとあと「△△モジュールの件はどうなっていたっけ?」と思ったら、まずはノートを検索して、そこから情報が書いてある紙資料にたどり着けば良い、という考えである。どこに書いたか分かれば、あとはその資料を探すだけ。

紙資料には日付やページ番号を書く

このように、できるだけ「ノート」に情報を寄せておくことが大事。その際、紙資料を探しやすくするため、紙資料の方には日付を書いておくと良いだろう。1・2年はあっという間に経過するので、ぜひ西暦から書いておこう。日付を書く位置を揃えておくと、紙資料をまとめておいた時も探し出しやすい。

ノートの探し方

僕はこうしてノートに全ての業務記録を書いているので、「以前と同じ事象に遭遇した」といった時は、ノートを引っ張り出してくるだけで解決できる。

しかし、ファイルを日付単位で分割していると、ファイル名からでは内容が想像しづらい。

そこで grep である。僕はいつも以下のコマンドで、自分のノートを探している。

# ノートを置いているディレクトリに移動する
$ cd ~/MyNotes/

# カレントディレクトリ配下から、「プロキシ」を含むノートを検索する
# 大文字・小文字を区別せず、サブディレクトリまで検索する
$ grep -inR 'プロキシ' .

grep -inR '検索文字列' .。コレでワンセットなので、別途 Function にしておくと良いだろう。

…なんのことはない、コレだけである。必要になったら grep で検索すればいい。ただし、ココで検索してヒットしたファイルを読んだ時に、目的の情報が書ききれていない可能性はあり得る。だから日頃から細かく書かないといけないのだ。

以上

コレが僕の普段の業務記録の取り方だ。ノートは業務中に自然に取る癖をつけよう。ノートを書く時間をあとでまとめて作る、といったやり方は大抵失敗する。記録しながら仕事をするスタイルを身につけておけば、さほど時間は取られない。そして記録したことがあとあと必ず自分の役に立つはずだ。未来の自分のために、今の時間を適切に投資して、効率よく仕事をしてほしいと思う。

最速の仕事術はプログラマーが知っている

最速の仕事術はプログラマーが知っている

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件) を見る