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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

もしも、図や表など、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日平均8000文字分ぐらいの Markdown ファイルを書いている。コードやコマンド、エラーメッセージのコピペや URL なども含んでの文字数ではあるが、だいたいこのぐらいは書いている。

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

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

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

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

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

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

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

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

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

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

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

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

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

ノートの探し方

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

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

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

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

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

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

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

以上

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