読者です 読者をやめる 読者になる 読者になる

This is a Pen

プログラミングとITと日記

忘れるのは当たり前。 だからこそノートの書き方を見直す

f:id:pierrot-nose:20170121120906j:plain

小学校から高校、社会人までにノートをたくさん書いてきたのに   
未だに正解といえる書き方がわかりません


・・・が、数々の失敗により
「あの時ノートに書いておけばよかった」
「なんで書いていないんだろう」
「どのノートのページに書いたんだっけ・・・」
などの経験・後悔により次はどう書けばよいのかという体験は誰にでもあるはず


自分の経験を振り返って、
俺のノートの書き方の変更点と注意したことを書いていこうかと思います。
現場視点で書いているため、これからの新人エンジニア、または現エンジニアの方の参考になれば幸いです。
学生の方々は将来の参考に使ってください



最低限おさえるべきポイント

とりあえず今までで変更した箇所をさくっと紹介します。


日付(勤務時間)を書くべき

日付を書かなければ「ノート」をいつとったのかはわかりません、
当たり前ですが、書いているページの時系列が前後して良いことなんて何もありません
また、勤務時間も合わせて書きましょう。

なぜ勤務時間をというと、現場に派遣されているエンジニアのほとんどは
自社の勤怠入力以外にも派遣先の会社の分も書く必要があります。

後日「あの日何時間働いたっけ・・・?」なんて悩むのはなんというか、ナンセンスです。

・ 時系列順を綺麗にしたほうが人間は振り返りやすいです。日付は必須

・ 「何時間働いたっけ・・?」を一度でも思った経験があるのならば、勤務時間も合わせて書きましょう


概要(テーマ)を書くべき

ブログや新聞のタイトルと見出しと同じように、
各ページで何が書かれているかがひと目わかるように概要を書くべきです。
ひと目っていうのは、つまり内容を要約することです。

自分の一週間前のノートを見てみてください。
そこで見たページの内容がひと目でわからない
しかも、3分見てもいまいち内容が頭に入ってこないようであればアウトです。

注意点の方でもかいていますが、
ページの内容がわかるように要約してみてください、コツは全体的に、ふんわりでいいです。


作業予定を入れるべき

タスク管理って言う言葉がありますが、
やらなければいけない事をひたすら書いても意味がありません。

INPUTされた作業指示を自分で噛み砕いて、
OUTPUTとして作業予定を書き出す。つまり、自分で組み立てろということです。

人間は自分で考えた範囲内のことしか出来ません。
言われたことをやっているだけの人とはここで決定的な差がでます

スケジュール管理が細かいプロジェクト、もしくは生産性重視の現場とかでは
無理な背伸びをしないで確実に作業をこなせる人のほうが重宝されます。
結局、任されてもあれもこれもやろうとして取りこぼしたら意味がありませんから。

・ ひたすらたタスクを書き出すのはNG

・ 自分の作業を確実に実現範囲内に組み直すこと。背伸びはしないでよい


要所は簡潔かつ具体的に

各ページに全体的な「概要」を書くとは反対に、
1日の要所となるポイントを具体的に、細かく書く必要があります。

ある日、自分が実施していたテストで障害が発生したにもかかわらず、
別の機能を担当していた人のテストで同様の障害がでていたため、一旦OKという場面がありました。
本来はNGになるはずが、その別の機能と同時に修正するという理由でOKになりました。
ここでのやり取りは全て口頭で行っています。

ところが、次のテスト工程で同様の障害が発生し
担当している自分が責められてしまいました。
問題は、この障害の一連のやり取りを私も忘れており、ノートにもありません。
全体的な概要だけではわからない所を細かく書くべきだったのです。

悪いのは私だけじゃないというのもありますが、
よくある5W1Hに沿って細かく書けばよかっただけの話です。

もしコレが大事な会議や打ち合わせだったのならば、絶対忘れないようにしますよね?

  • 問題事象
  • 依頼事項
  • 作業期限
  • 依頼者
  • 口頭のみのやり取り

自分は1日のうち、上記に絡むことを要所として書いています。
内容は社会人としては当たり前のことばかりですが、意外と出来ないものなのです。


一言で書く反省点・気づき・発見ボックス

反省点を書けるスペースを設けてください。
そのまんまですが、反省点を書いてください(正直なんでも良い、思ったことを)

ただ、「反省しています」だとか、「次から気をつけます」はいくらでも言えます。
むしろ文章だとか、容易に言葉にした途端に陳腐化します。
だから、可能な限り具体的に書いてしまえばいいんです。

  • 〇〇が今日は思うように進まなかった
    • 〇〇の前に、△△をしてから作業をすればより効率的になる

こんなんでいいんです。
あと、別に反省点でなくてもいいんです。
日々の気づき、発見でも良いのです。

何が言いたいかというと、1日の行動に意味を見出す、発見することなんです。
明日の自分が成長するために、書きます。

・ 反省点や思ったことの「対策・次の行動」を具体的に書くべきです

・ 「なぜ起きた」ではなく、「次はどうするか」、「意味を見出す」のが重要です



その他の注意点

その他の注意点、別に無くても良いかもしれないけど
知っていても損は無いだろうなところです。


テーマ1つで1ページ

ページの内容がゴチャゴチャしている。
書かれている事の次元が異なるのがごちゃまぜになっている。
統一してみましょう。

簡単にいえば、
単体テスト時の注意事項と結合テスト時の注意事項を同じページに書いていた時など。

「え、どっち?」ってなる原因のトップ3に入ります。


未来の自分は他人である

プログラマーのネタで、
半年前に自分が書いたソースに向かって「何このクソコード」と言う現象と非常に似ている。
むしろ完全一致。

半年前のノートなんてそうそう見ないと思うが、
それでも「他人に向けて書いた」というのは読みやすさを意識 するため、
非常に優しいのです、未来の自分に。


書きなぐった箇所は書き直す

急いでいる場面だとか、スピード感の早い会議・打ち合わせなどでは
文字が書きなぐりっぽくなりがちですが、ぜひ書き直しましょう。

何回もいいますが、後日見た時に「なんだ・・これ?」はやべーです。


ノートをケチるな

ケチるなっていうのはノートの値段というか、
各ページの余白をケチるなって意味です。

ブログなどもそうですが、適切な空白、余白がほどよい読み心地を生みます。
ノートを見るだけでストレスを感じるなんて、私ならいやです。

値段っていう意味でしたら方眼式のルーズリーフ がおすすめです。
マス目で綺麗に縦軸、横軸を揃えられるので簡単に綺麗にノートが書けます。


まとめ

私の場合、今はコレがベストのノートの取り方になっています。
正直正解はなく、自分の現場、経験を元に独自のかきかたを生み出すほうが良いかもしれませんが
少しでも参考になれば!

それでは! Peace!




f:id:pierrot-nose:20170122042012p:plain

自分の文字が読めないっていうのは・・頑張ってくださいとしか。



Related Posts Plugin for WordPress, Blogger...