Table of Contents

1. 想定読者
2. 「メモを取れ」とは言うが、具体的には？
   1. HTML5 から垣間見る「文書に求められている要素」
   2. メモ書式の策定
      1. とはいえ書式も多様
      2. 箇条書き 対 横に長い文字列
   3. 記録する時・頻度
      1. 余談：Emacs の Scratch Buffer
3. 書き留めた内容の有効活用法
   1. 自分の「ジャーナル」という足跡を辿るのに使える UNIX ツール
   2. なぜ UNIX ツール・コマンドラインツールなのか
4. まとめ
5. 参考資料
6. 蛇足

(…前略……) 直近のパフォーマンスの状態がわからないと、今回、乗り越えるべきものが何かを知ったり、自分が進歩しているかどうかを分析したりすることができなくなるからだ。

幸い、この問題を克服するための技術がある。

ペンと紙だ。

トレーニングを終えたらすぐに、または、できるだけ早く、トレーニング内容を書き留める。次のセッション前にそのメモを見直せば、今回、なにをすべきか、なにを乗り越えるべきかがわかる。

ポール・ウェイド著、山田雅久訳「圧倒的な強さを手に入れる究極の自重筋トレ ; プリズナートレーニング」::「セルフコーチになるには」の「体を鍛える時の知恵」の「トレーニング記録を取る」(項 306)より

信じられないかもしれないが、優れた監獄アスリートは、獣のようにはトレーニングしない。

上記同著、同大,中章の「消灯!」(項 308)より

人間の記憶というものは、想像以上に揮発したり揮発しなかったとしてもその内容が欠損ないし、欠損を埋める改竄・変更が容易に行われるらしい。

筆者は下等知的生命体どころか人型畜生なので、記憶の欠損やそれを埋める改竄が容易に発生する。それこそ 3 歩歩く前の記憶さえ改竄されたり、揮発する。

そのため、失った記憶を頭の中で掘りおこしたり、その上でそれらの整合を取ったり俯瞰するという脳みその演算能力はつねに無い。 「無かった」と過去系にして宣いたいが、おそらく今もなおそうなので、過去系にはできない

なので苦し紛れに氏の著書も愛読しているブログの「日記でなく日誌をつけよう／独学者のための航海日誌（ジャーナル）のススメ」を読んで がむしゃら に「自分の為の業務ジャーナル」をつけたら、主に精神が安定した、という事をこの間別のブログサービスに書いた。

その後日から妙に Qiita で似た趣向の記事を幾つか見かけ1たので、自分も少し誰かに有益になるか判らないものの知見や小技の類を記しておこうと思った次第でこの文書を書き初めた。

想定読者

• 業務に集中できない人
• 自分が悪い事は判っているものの、何が原因か分からず仕舞いな人

つまり 30 歳と 4 ヶ月になるまでの自分の様な人である。

「メモを取れ」とは言うが、具体的には？

「忘れない様にメモを取れ」
と他人は言うが メモが手元に準備しにくい職場では「心に刻め」と言う事もあるが 、では実際 何 を どの様 にと戸惑ってばかりでメモを取れなかったのが筆者である。

ましてやメモを取っても大抵は上司や同僚など他人から指摘された事を書き留める事に留まり、それはただの「自分への戒め」となって傷ついてばかりで、メモを取っても不快になるだけであった。

HTML5 から垣間見る「文書に求められている要素」

そんな自分が「自分の為の業務ジャーナル」を記すにあたってふと思い返したのは、HTML5 の要素であった。

• <a>: ハイパーリンクを指定する
• <strong>: 強い重要性を表す
• <q>: 引用句・引用文であることを表す
• <code>: プログラムなどのコードであることを示す
• <i>: 声や心の中で思ったことなど、他と区別したいテキストを表す

HTMLクイックリファレンス::「HTML5 リファレンス(目的別)」の「テキストの意味」より抜粋

特に筆者の歪んだメモへの認識に対して救いになったのは <i> 要素である。

この文書を読んでいて察しの良い読者はお気づきかもしれないが、所々斜体表記している文節は「筆者の所感や感想」いわば「筆者の内心」である。

「メモは事実のみを書き記すもの」と認識していた筆者は、「他者から言われた客観的意見を留める事」にばかり囚われ、「自分がその時抱いた心情」は記録する前に脳内で殺していた。

しかし殺した感情の怨念なのだろうか。殺した情は後々、自他共に認める誤ちの種となるのである。そしてその誤ちの原因を探ろうにも、記録が無いため、自分の事を「無能で狂ったもの」と戒め続ける結果となる あくまで筆者個人の話だが 。

自分のその時の感情も臆せず書き出し記録しよう 。それが自分の誤ちの動機を知るキッカケになるし、少なくとも建設的で論理的な 「理屈っぽい」とも言えるかもしれないが 自己批判や自暴自棄は思うほど自分を傷つけない。

ただ一つつけ加えるとするなら、他人への愚痴は斜体よりも弱い表記の方が良いと筆者個人は思う。

あくまで筆者の感覚に依るものだが、どうせ他人の愚痴を書いても 2,3 週回れば自分の汚点に突き刺さる。
書いておいても良いが、その愚痴の分析を書き連ね終える頃には自分を卑下するものになることが多い。

メモ書式の策定

できるならば書式はプレーンテキストでも手書きでも統一したい。
その方が後でまとめるにしても、まとめる前の殴り書きを見返すにしても、頭の中の構文解析機を切り替える手間が多少は軽減される。

太字や斜体を手で書くのは骨が折れ2るので速記という観点では余計な労力が必要になる。手書きであれど、各種マークアップ言語の様な「記号で囲んで文節に意を持たせる」方法を取り入れた方が楽ではと筆者は思う。

とはいえ書式も多様

幸い今日は多様なマークアップ言語がある。Markdown, reStructuredText, Asciidoc, etc3…

ごく個人的には
「アウトライン(構造化)、TODO、表もプレーンテキストで表せ、他の書式への変換出力も標準搭載(pandoc を利用する事で更に出力先を広げられる)」
の「Org-mode/org syntax」を推し薦めたいが、Org-mode は Emacs という
「テキストエディタの姿をしたキャラクターユーザーインターフェイス(CUI。CLI ではない)の、実質基本オペレーションシステム」 \\ があってこそ真価を発揮する書式と言っても良い代物である。

なので無理強いはしない。が、過去にその素晴らしさについては語ったつもりである。

箇条書き 対 横に長い文字列

「であるならば(構造化)箇条書きの方が速記という点では優れているのでは？」
と思われる読者も多いだろう。確かに箇条書きは簡素に書ける上に構造も表せる。

ただ筆者個人としては、箇条書きは縦幅を多く取るものと感じる。横書きならば右側、縦書きなら下側の空白に後から注釈を書き込むという自由さはあるが、その場で脳内に表れた感情を含む言葉を簡素に切り分けるという手間が発生する。

この「構造化する」という手間は筆者個人は地味に疲れる工程であり、それを「とりあえず即座に記録する」という観点ではいささか一工程増える感覚を覚える。

それなら一度だらだら横一列にほぼ等しい状態で書き出した上で、後でマークアップ記号をいれてしまった方が早いと思うのである。

とは言え、ここは好みで別れると思うので各自のやり易い様に書き留めるのが一番である。

記録する時・頻度

トレーニングの記録は、すばやく、効率的に行う。時間がかかる面倒に変わると、続けることが難しくなる。

ポール・ウェイド著、山田雅久訳「圧倒的な強さを手に入れる究極の自重筋トレ ; プリズナートレーニング」::「セルフコーチになるには」の「体を鍛える時の知恵」の「トレーニングジャーナルの書き方」(項 308)より

率直に言ってしまえば、これに尽きる。 自分の感情に何かがひっかかった事に気づいたら、自分が何かに迷ったり、その何かが言葉にできなくても、書き出した方が良い 。 「良いに決まっている」と、筆者個人の体験では思う 。

それは最初、グラフ図でも良いしポンチ絵でも良い。とりあえず残さないと後で思い出す苦労と比べれば、断然マシだ。

さらに言えば、書き残した安心で気づいた事を忘れられ、忘れた事で空いた脳みその領域を他の演算に使用する事ができるというものだ。

なので、自分の身を守る為のナイフを懐に忍ばせるが如く、懐にペンと紙を忍ばせておきたい。

しかしながら、ペラ紙だとペンが紙を破く事が多いので、A8 サイズのメモ帳をスマホやパソコンの前に居なく、かつ手帳の類いも持ち歩いていなかった時の為に常備しておくと良いだろう。

余談：Emacs の Scratch Buffer

Emacs には Scratch Buffer というものがある。

設定によっては閉じても次に開く時にも、その編集内容は保存されている。

これが地味に重宝するもので、
「ファイル名は決まらないものの、書いておきたいコード片やメモを書き残したい」
時がしょっちゅうある筆者は、Scratch Buffer の恩恵にあやかっている。

「ファイル名が決まらない時は日付時刻で保存する」
というのが定石とは知るものの、筆者はそこまで器用ではないし飲み込みも遅いので、
「現日付時刻を確認して ISO8061 書式でファイル名をつけて保存」
という事ができないため、とても助かっている。

Emacs に限らず、テキストエディタであれば新規作成ショートカットを叩く事で白紙は容易に生成できるが。

書き留めた内容の有効活用法

ここまでは書き方、書き留め方の持論を戯けさせていただいたが、その記録も見返せなければ効果は半減まではしないものの、有効活用できているとは言い難い。少なくとも、先程書き留めた事を意味の解釈までしなくてもいいので見返した方がジャーナルの有用性は発揮される4と共に、自分の思考過程の不足やその過程の含意5に対する矛盾に対するマサカリ6を、必要以上に自分を痛めつけない鋭い刃で投げる事ができる。

とはいえ、多量に書き溜めた文書群からある文字列を探し出し、それに関連した情報やその調査過程を振り返り次の行動を見出すのに、筆者の様なドせっかちは
「探している時間がもったいない」
と思うのが常である。ましてやそれを目視で行うというのは大変骨の折れる作業であり、その心労を思い浮べるだけで憂うつな気分になる。

なので自分のジャーナルもできる限り素早く探したいものである。

幸い、今日のスマートフォンやパソコン 2020 年現在であれば RAM が 8GB では人権未満だが、無いよりはましと思う なら、人間が 「1 日 1 ファイルに書いた 1 ヶ月分のテキストファイル群」から目的の語句文字列を目視で探し出すよりも圧倒的な早さで見付けられる。

しかし、その「探す際に使う道具の名の一つくらいとその使い方」くらいは、完全に説明書を頭に叩き込むまでは行かなくても、少しは把握して使えた方が良い。

して、その道具は GUI の方がとっつきは良いかもしれないが、筆者個人としては CLI を薦める。もちろん UNIX 由来のコマンドである。

自分の「ジャーナル」という足跡を辿るのに使える UNIX ツール

以下に挙げるツール達は、数多のドキュメントやそこから発展した知見が WWW 上にある。なのでここでは名前だけ挙げる:

• find7
• grep8
• cut, tr, paste 必須ではない9

特に「grep」の名は「あるディレクトリ(フォルダ)に保存されているテキストファイル群から特定の文字列を探す機能」の代名詞なので、覚えておいて損は無いだろう。

なお「grep」は「複数条件(「ほげ」と「ふが」の両方を含む。「ほげ」と「ふが」のどちらか両方を含む)」や「否定(その文字列を含ま無い)」での該当行を導き出す事も可能である。

なぜ UNIX ツール・コマンドラインツールなのか

完全に筆者の体感の話でしかないが;

• 検索するにあたって余計なものが目に付かない
• 検索するにあたって余計な事を考えず、必要な事に集中できる
• キーボードからマウスやトラックボールに持ち替えずに文字列・表の様な表現をした文字列の検索や検索結果の加工を行い、自分の欲しい情報に絞り込みやすい

という具合である。

プログラミングの学習を高等専門学校や大学、2年生の専門学校で学んだ人なら「木構造」は知っていると思い込んで戯けると、筆者の頭でもファイルディレクトリ(フォルダ)構成はままそれに似た図で展開されがちなのだが、CLI ツールを使うと、その木構造の想像を文字列にも適応するのが容易で。
「切り離す枝葉を意識せず、欲しい情報に当たりやすい」
のである。

とは書いたが、正直この感覚を上手く言語化できるほどの語彙力が筆者には無い。 昔に上げた Qiita の記事を見ても明らか
なので、読者を納得させれるとは思えていない。

まとめ

と、好きっ放題書き散らし、戯けさせて頂いたが、志しある読者の皆様は、
「メモやジャーナルは自分の頭の中を俯瞰したり、忘れる為の安心も得て忘れ、その開放された頭でもっと深く考える為の余裕を確保できるようになるんだな」
と感じていただき、あわよくば自分自身の自分自身の為のジャーナリンクをはじめたり、継続していただければ幸いである。

さて、今この文書を書いている筆者としては、
「して、『自分に自分を痛めない鋭い刃のマサカリ』を投げるには？」
という事を抱いた読者 と過去の自分 の為にとは言いつつも、最近学び始めたばかりなのに沢山の感動を得た「数理論理学」についてだらだら戯けようと思う次第である。

参考資料

• 黒板太字 | Wikipedia 日本語版
• Markdown | Wikipedia 日本語版
• reStructuredText | Wikipedia 日本語版
• AsciiDoc | Wikipedia 日本語版
• Standard Generalized Markup Language | Wikipedia 日本語版
• それ PowerShell でできるよ | Qiita
• 日記でなく日誌をつけよう／独学者のための航海日誌（ジャーナル）のススメ | 読書猿Classic: between/beyond readers
• チリを積もらせ山にする→人生航海日誌（ログ）と動機付けの技術 | 読書猿 Classic: between/beyond readers

蛇足

この文書も原文は org-mode/org syntax で書きました。原文は Gist で上げてみました。

脚注

1 例えば、「【不安解消】未経験が GitHub で issue 管理をしたら、モチベ UP した話。」や「エンジニアが効率よく仕事を進めるためのメモ術」である。 拙いが、応援の意も込めてコメントもした。

2 少々高度な数学の書籍では「黒板太字」もしくは「中抜き文字」という「白抜きの太字」の様な表記があり、これを応用して「一度書いた文字の上から微小ずらして改めて文字を書く」という方法もあるが、文節の両脇に記号を書き入れる労力と比べると、こちらの方が労力が大きい→速記に適さない と筆者は感じる

3 もちろんだが、HTML や XML と言った Standard Generalized Markup Language(SGML)も立派なマークアップ言語である。

4 これを述べるに当っての記事そのものは失念してしまったが、nemo 氏の embryo というブログの記事だったと記憶している。

5 数理論理学でのみ扱われる用語かもしれない。「Aならば B」という、「何らかの事が成り立つのであれば、別の事も成り立つ」という関係を示す語。

6 こちらも IT 界隈限定の用語かもしれない。「他者の誤認や誤解といった誤謬(ごびゅう)に対する有識者の指摘が、初学者には『人格否定』とも捉えられてしまい、その『有識者が初学者の志しを折る』様が、さも漫画『北斗の拳』でならず者達が非力な人々を殲滅する様」に似ているからか、そういった指摘を「マサカリ」と呼ぶ 「完全に筆者がインターネッツを眺めていて得た推測」につき、要出典 。

7 ただし 2020 年現在の「Windows」だと、「コマンドプロンプト」では where, dir が代替となる(出典)。
筆者としては Windows10 以降を使用しているならば PowerShell を薦めるものの、PowerShell では Get-ChildItem に -Recurse オプションをつけた上で Where-Object コマンドに受け渡す(出典) 確かに find においては PowerShell の方が「一つの事を上手くやってる、UNIX 哲学的」とは思うが…… 。

8 ただし 2020 年現在の「Windows」だと、「コマンドプロンプト」では find, findstr が、PowerShell だと Select-String が代替コマンドとなる。

9 しかし知っていると、「カンマ( , )で列を、改行で行を表現した表(CSV)」などから特定の列だけ抽出したり、もし少しばかりスクリプト・プログラミングが書けたら、その集計まで持っていける。ソースは「シェルスクリプトの中でjoin()とsplit()相当の事をやる | Qiita」