VScodeのObsidianで作業を管理して、仕事が順調！

Foamは（Obsidianなどの知識管理は）便利だ！ぜひ仕事のパートナーに。

新しい現場に入ることになった。そこで、端末とともに心を入れ替えて、改めて仕事に関する知識の管理を試し直す機会に恵まれた。

苦手としている作業で、気付けない小さな不安があることに気づいた。小さなたくさんの不安が、作業の進みを遅くしているのだ。

Foamを利用してその小さな不安に対処できるようになると実感した……とにかく、ここで読者に伝えたいのは、Foamを利用して仕事の不安を軽減する事ができるということ。少なくとも軽減するパートナーにはなるのだ！と言いたい。

……けど、上から目線なのに当たり前のことを言っていると思われると恥ずかしいので、昔の自分に伝えるという防護服を着て、どうして新たな現場ではうまく機能しているのかをまとめる。

PKMに挑戦したけどうまくいかなかった……という人は意外といると思う。決定的な解決策は提示できないが、せめて１つの支えになれるとよい。

## どのような記事か

この記事は体験からの学びの体裁をなしている。なので、「確実にうまくいく方法」を求めている場合は読まなくてよい。進行形で仕事のやり方を模索している1体験程度の価値しかないことに留意。

私には何回かPKMがうまくいかなかった経験がある。その時と今回を比べることであくまで体験談という形で記事を書こうと思う。

前の現場でもObsidianやFoamを利用して仕事にまつわることを管理しようと思った。前前現場では、知識を覚えるためにobsidianでフラッシュカードを作ろうとしたこともある。2ヶ月ぐらいで頓挫したプロジェクトだったので、フラッシュカードを作るという意気込みもともに消え失せてしまったが……

また、プライベートでもobsidianを利用して知識を管理しようとしている。だがしかし主に使っているのはデイリーノートだけであり、私が想像する世の中のスーパー知識管理人たち（PKMer）には遠く及ばないといううじうじした気持ちがある。

一方今回新たに配属されたプロジェクトではうまく活用できている。少なくとも、活用できている実感はある。これは一回も感じたことがなかった気持ちで、それを共有したい。

仕事で使うのとプライベートで使っているのと、一体何が違うのだろうか？仕事で使っていてもなぜうまくいかない時があるのか？その違いをてこにしてみんなが参考になる小さなことが見いだせると嬉しい。

今回の記事を書くにあたって理解できた私の性質を書いて置こうと思う。それがわかれば、「うーん、ここは俺と全然性格が違うから違うやり方のほうが良いかもしれないな」と考えることができると思う。

- 好きなこと以外に興味を持つことが苦痛で、忘れっぽい
- 細かい不安がたくさんよぎって集中できない（これもまた忘れてしまうかも！？とか）
- 余裕がないために、やるならやる、やらないなら一切やらないみたいになりがち

こんな性質が発現したことがないなら、その分を差し引いて読むと良い。

## 結論

先に結論だけ書く。

なるべく小さく書くこと。これはノートの文字数の話では **ない。** 態度の話である。

## 今回の知識管理でやったこと

Foamというのは、VSCodeで利用することができる拡張機能だ。Markdownで記載したノート同士をWikiのようにつなげて、考えや学んだことをわかりやすくまとめることができる。

まず、5日の段階で書いた記事を大雑把に思い出す。

- 1日目
	- PCをセットアップしながら、うんうんできないと唸っていた、日記未満のもの
	- 今後どのようなタスクが振られるかを聞いたので、まず試しに作ってみることで今後の自分がどこに躓くのかを調べた記録
	- 業務で利用するパスワードの入力方法が特殊だったため、そのやり方を詳しく記載
- 2日目
	- 初日にWindowsのメモ帳に書いた記録をもとに、社内のGoogle Chatに貼り付ける知見未満の文章を作成
- 3日目
	- 1~2日のメモをもとに作業手順書の雛形を作成。
	- 今まで記載した忘れたらいけない物事やサイトなどを記載
- 4日目
	- 実際に作業が振られたので、それに基づいて作業をした記録
- 5日目
	- 同じく

今回のFoamの始まりは、とても適当だったということがうかがえる。

何が良かったかなあ、と考えてみると、やっぱりWindowsのメモ帳を使って文章を書いたこと。ただの感想文を書いたことだ。

今回のFoamで重要だったのは、「ノートを使える導線が整ったまま続けられたこと」だ。とりあえず見られ続けるメモを書くのだ。なぜなら、生きながらえていることが一番えらいからだ！

### 以前の現場のノート管理との差異

差異を見ていこう。

前の現場ではデイリーノートを使うことができなかった。実装を任されることが多かった／ないし仕事中の苦痛から逃れるためにたくさん実装のタスクをもらっていた。余裕を持てなかった（余裕を持つことが怖かったとも言える）。なんの言い訳にしていたんだろうな。

それはおいておいて、普段の作業はこんな感じだった。実装に関しては資料作成より苦手意識が薄かったのでこの限りではない。

1. PCを開く
2. 作業がはじまる
3. 特に資料作成のときなどに作業の進め方がわからず、ぼんやりとわからないことにも気づけていない
	1. なんとなくやることを書く
	2. 具体的なわからないことがたくさんありそうに見える
	3. どうやって手を付けたら効率がいいか考える
	4. 更に悩む
	5. 1~4の繰り返し

仕事が異次元に好きな訳では無いので、なるべく仕事の量を減らしたい。だからうんうん悩んで仕事の進め方を考えようとするのだけど、その分仕事において自分への期待値が高まってしまい、手を付けるハードルが無際限に上がる。

不安がある作業の前にデイリーノートを書く習慣がなかった。

前前の現場はどうだろうか？

前前は力が入りすぎて、業務知識をめっちゃ覚えようと思ってフラッシュカードを作ったりしていた。入社一年目のようだ。事実入社一年目だった。

実際の作業フローと違うところにデイリーノートなどの習慣をもってきていた。朝必ずデイリーノートを書く自分で居たいと思っていたし、フラッシュカードを必ず作って業務知識を高いレベルで取り込む人間でありたかった。

### プライベートでのPKMとの差異

プライベートのPKMではobsidianを3年利用して管理をしている。5500のノートがある。だがいっぱいいっぱいな気持ちになっていて、普段はデイリーノートしか利用できていない。

違うのは書いているノート自体への潔癖症的なこだわり。自分のものだから良いものにしたい。

仕事においては、作業をするためだけの落ち着く作業場所だけど、私のobsidianは「いつ私が不満をいってくるかわからない戦場」みたいになっている。自分の城と思ってノートを書くほど、息苦しくなっていく。

……つまり。

1. 不安に圧倒され、ノートを書くことに繋げられなかった（前の現場）
2. ノートの書き方への期待が大きすぎて、適切なところでノートをかけなかった（前前の現場／プライベート）

現実の作業とノートのなかの作業を、あえて対立させて説明するなら、1は現実の作業に埋没して、溺れてしまった事例。2はノートの中の作業が膨れ上がってしまった事例と言える。

秘書としてPKMを利用するのなら、長い時間をかけて対話することが一番重要なわけで、その場でパッと見きれいとかはあまり重要じゃない。ただ使われ続けるところにあるのがよい。

構造は獲得されるもので、助平心で作りに行くものじゃない。きれいなPKMができたら良いな〜と思って作りに行くと、たいてい失敗しているみたいだ。

好まれる表現かはわからないけれど、今回Foamに血が通った感覚がしたのだ。それは、多分少なくとも構造が獲得され始めたということである。ノート群が全体的／有機的に役に立っている感覚があった。

## 良かったこと

以下は具体的な良かった行動である。

最初は何から作ってどういう構造になっていくのか。今回の案件で一番大事だったのは、

「パスワードの入力方法や、よく使うページなども記載したこと」だと思う。

PKMは育っていくほど使いやすくなるので、よく育つ場所においておく必要がある。よく使う流れの中においておけば、Foamはよりはやく、自分の手に馴染むようなものに結晶化するはずなのだ。

## よく使う導線を複数用意する

まず、使うことが大事だし、できることなら無理やりではなく自然に使ってしまうようなところを、観察して見つけることが大切だ。そのためには、「何も考えず書くフェーズ」と「どういうやり方が案件や環境に適しているかを考えるフェーズ」を行き来する必要がある。

今回のやり方で、うまく働いたやり方は3つ。3つが補いあっていると思う、多分。

1. デイリーノートを書く（種まき）
2. 業務ルール・リンク集を書く（「必要」の基盤を作る）
3. 小さなナレッジを書く（育てる方向性を確認する）

### デイリーノートを書く

デイリーノートを書くのは大事だ。それは、毎日書かなければ行けないというわけではない。とにかく書きなぐる"楽な場所"を作ってあげることが大切なことだった。

まだ最初は自分がどういう作業をしていくかわからない。だから、安全に書ける場所があるのが大切だ。適当に書き散らしていく安心感をもってくること。これは、「何も考えず書くフェーズ」を支えるものだろう。

最初に書いたデイリーノートはデイリーノートという体裁をなしていなかった。

「画面仕様書を作ったほうがいいんじゃない？」という自分との対話や、PCのセットアップまでの申請がまだできていないのかい、という愚痴など。個人的かつ誰にも見せない対話を作ることで、Foamを利用することに抵抗がなくなっていく。

これは、手段を補強する。気軽にかけるから、初動が楽になる。適当にまずデイリーノートを開こうか、に仕事が集約されるから、考えることに労力を割く必要がない。

それに、楽に書けば書くほど予想よりFoamが育ってご満悦になる。最初のたった5日間で、26個すでにノートを書いていた。使いやすいな、と感じられている。

デイリーノートは種まきかも。

### 業務ルール・リンク集を書く

業務ルールやリンク集を書くことは、Foamを使っていくことにおいて高いレベルのバフになっているように感じる。

通常何も考えないとリンクはブラウザにブックマークしがちだけど、それをやめた。ブラウザはあくまでサイトを閲覧するためだけのものだ。サイトを管理するものではないので、今までうまく管理できていなかったのだ！

パスワードや、普段仕事で利用するページ、そして開きたいフォルダですらリンク集を用意する。

```
# 画面仕様書

vscode://file/C:~~~~

# 要件定義書

vscode://file/C:~~~~
```

:::note
**file:/// スキームが利用できない場合のファイルリンクの設定方法**
**セキュリティ上の理由**から、ブラウザやVS Codeなどが `file:///` 形式のリンクでローカルファイルを直接開くことを制限していることがある。
その場合、**VS Code独自のプロトコル（`vscode://file/`）** を使うと、エディタ内で安全にリンク先ファイルを扱える。
:::

これは、Foamのバフだと言った。自分が確実によく使う場所を作ってあげる。そうすると、これからよく使うんだからきれいに書こうかなという気に自然となる。

#### 利点

よく使うリンク集はよく使う割に、メンテナンスコストがひくい。だから、きれいにしやすく、きれいにした満足感も続きやすい。

かつ、忘れることがないという安心感がおおきい。

だから、愛着を得るためにとっても便利だった。

あんまり理解するの速くないなーってベテランがいた事があるが、実装の知識はないし、簡単な英単語も全然調べず理解しない。でも業務知識は誰より覚えていてとても頼りになった。経緯を含めて覚えてくれていたので、設計の判断のときにとても助かった。

その人は、秀丸エディタでパスワードの場所から何から全部記録していた。今考えるとそれはとても大切なことだったんだと思う。ここに必ず書いてあるという安心感がきっとあった。

秀丸エディタだと質素でダサいからFoamを使えばテンションも上がるし、忘れることもない。

趣味のobsidianでは、それが足りなかった。デイリーノートは作るけど、それがやりたいファーストで「必要」に根ざしていない。デイリーノートからノートを派生して作っても、あんまりそれを継続して参照する基盤がない。

だから、よく使うリンク集を書くことは毎日Foamを利用することにつながっている。日々のノートと生活を近づけるために。日々のノートで書いても、その結果を私が使わないと意味ない。

無味乾燥の、ただの事実の羅列だけれどもよく使うものを書くのが大事。

#### 作業手順書

同じ理由で、作業手順書を作るのはよい。ただし、欲張らずによく使われる作業のみにすること。

使われて参照することではじめて光る。

新しい現場は基本設計フェーズで（ただし要件定義もまだ済んでいない）、大雑把にキャッチアップしやすい画面仕様書からタスクとして振られることになる。残り16画面ほどあり何度も行うことになる作業だったため、作業手順書を作った。

それはどちらかというと作ったというより、できた。作業している間のメモから、何をやったのか抽出しただけだったため。

「こうするべき」より「こうやった」という行動ベースのノートがよい。使いやすい知識管理ベースは過去にある。過去から生み出すノートが、汚らしくて使いやすいものだ。新しくきれいなものは使いづらい。

汚く、親しみやすく。高級料理より、まずは余り物で作った野菜炒めを作るしかない。

### 同僚のために小さなナレッジを書く

小さなナレッジを書く。「ナレッジ」という名前もつけないような、ほんの小さなものだ。ナレッジか報告／雑談かどちらか？と聞かれたら、多分雑談っぽいな〜〜って言ってしまうようなレベルのものを作るのが大事だ。

例えば報告調にしてみる。

「状態管理のためのライブラリを調査したんですが、こっちのほうがこういう理由でいいと思います」

とか。

チームに溶け込むような、つまらないものがいい。つまらなければつまらないほど、よく使うことになる。使えば使うほど、Foamに溜まっていく。そこからどんどん使えるノートができてくるのだと思う。

いきなり、ガツンとしたナレッジを作る必要はない。むしろそういう欲望とは距離を取ったほうが良い。個人的にもそうやって書こうと意気込むことはあまり良くないし、チーム的にもあまり良くない。チームにナレッジを書く習慣がなければ、他人にとって負担になってしまう。徐々に慣れる意味で、つまらない当然のものをやっていくほうがよい。

つまらない当然のものをやる。

## 再度結論

まとめると、こういうことだ。PKMを利用するには、力まずに使い続けられることが大事である。

そのために大事なのは、

デイリーノートを開くことで種まきをする。業務リンク集などを管理することで、PKMに必要性の基盤を導入する。小さくつまらないと感じられるナレッジを書いて、PKMの育つ方向性を確認する。

それらをやるために重要なのが、小ささだ。

## あるエンジニアの小さな気付き

以下は余談。

やっていったことで気づいたこと。私の細かな気づきを記しておく。そうすることで、読者との性格の違いからどうすればいいか軌道修正できるかもしれない。

### Windowsの音声入力使いやすい

そもそも音声入力という方法自体とても便利なものだ。気軽にメモができるし、もう大雑把に使い倒したい。だが、セキュリティ上Whisperなんて使えないし……と考えていたのが、Windowsのデフォルトでももうとても使いやすい。Officeを使えるならWordなどなど。

メモを書く敷居を下げるほど、Foamは楽に使える。

音声入力があると結構違う。手を動かすより「あー、だるい」って発話するほうが楽で、そこから「何をやんなきゃいけないんだっけー？」とはなし始めるのはとても楽。

### Excelの資料は、csvを作るよりちょっとずつ作り足す方が結局楽

確かに、csvをプログラマブルに作ればぬけもれは少なくなるかもしれない。でも、ちょっとずつ作り足す方が圧倒的に楽。頭だけでどうにか速く作ろうと努力したところで、対して速くならない。

だから、もっと適当に手癖で作ったほうがいい。

### 静的な値や汎用的な繰り返し作業だけしか効率化しなくて良い

静的な値や、vimの繰り返しコマンドなど汎用的な繰り返し作業だけでいい。他の作業は些末なので、ただ愚直に行ったほうが良いかもしれない。

#### 効率化を求めすぎて作業が止まる

効率的に作業ができるように、スクリプトを作ってから資料作成を一気に終わらせようとしがち。そのために結構時間をかけてしまうというか、いつの間にか時間が食われてしまう。

例えば今画面仕様書を作成している。

画面仕様書で言うと、画面一覧やイベント一覧をどのように効率的に貼り付けるかが気になってしまう。なるべくExcelで作業したくない。効率が悪いし、一々Excelの俺様ショートカットキーがたくさんあって癪に障るのだ。効率の悪さ耐えられない。内容と関連のないエクセル方眼紙にも耐えられるほどの余裕がない！

繰り返し作業っぽいものがすこしでも出てくると、効率化したくなる。そしてその作業に時間がかかり全体の作業が遅れる本末転倒的なものを持っている。

まず、その作業がやるべきことなのかどうかがいちばん大切なのに。どうやるべきかより、それをやるべきかどうかのほうが大切だ。時間がかかることに耐えられないから、早く手を付けたり効率化を考えようとしているけど、それは不安によるものだ。

- 正規表現
- CSV生成
- vimの繰り返し作業

頭を使うのは、書いたあと。書いた紙の上で頭を使えば良い。

時間が余っている時はbabashkaを利用してスクリプトを作ったりしていた。たのしかったけれど、勉強のために使える時間が失われてしまった。

### でも、細かな具体的な値は書いておいたほうが楽

例えばリンク集や使うページ、編集するファイルがどのフォルダに存在するかなどを書いておくこと。

特に私は仕様書群を開くことの心理的な摩擦が大きいので、なるべく楽にファイルを開けるようにフォルダまでのパスを記載する。

```
# 画面仕様書

vscode://file/C:~~~~

# 要件定義書

vscode://file/C:~~~~
```


言語化しないと気づかなかったことだが、動的なことって、自動化するのにコストが掛かる。反対に、パスワードやよく利用するページみたいな静的なものを集めて置くのはとても楽だ。

動的なことは「身体を使って楽に行う」。

まず馬鹿みたいにやってみる。そこから、頭を使ってみる。そして、馬鹿みたいにやってみる。その繰り返しだ。

ただし、vimの「汎用的に利用できる動的な繰り返しパターン」などはノートに記述して良いかもしれない。なぜなら、効率化して身体的な技術にしたら便利だから。

### 通知で集中力は途切れるというが、予想の何倍もだった

通知で簡単に集中力は途切れ、1時間はほぼ牛歩になってしまう。そして、これからやろうとしていることを思い出すのに15分ぐらいかかる。明確なタスクを与えられていなかったので効率化に走ってしまった側面もある。

だから、通知を切る時間を設定しておく必要あり。手順書は作業にははいらない。（頭ではわかっているが、そんな事を言ってもいつの間にか時間が経っているのだ、どうにかして環境を整えないといけない。気合や根性でなんとかなるような簡単な問題じゃない）

## おわりに

今回の新しい現場で感じた「うまくFoamを使えているかもしれない」という感触は、突き詰めてみれば「小さく始める」ことに尽きると思う。まずは日々のメモを書き散らす・パスワードやリンクなど“よく使うもの”をまとめる・何でもないような雑談レベルのナレッジを書いてみる。

気負わずにそういった“当たり前の種”をまき続けると、自然とノートの構造が獲得されて、仕事中に「これ書いといてよかった！」と思える瞬間が増えていく。

そして、自分の作業の流れのそばに“すぐ使えるノート”がある安心感は、思いのほか大きな支えになっている。細かい不安や「覚えてられないかも……」というプレッシャーから少し解放され、仕事に向かうハードルが下がったのだ。昔は「完璧に覚えなきゃ」「きれいに整理しなきゃ」という意識が先立って結局続かなくなっていたことを思えば、かなりの変化だ。

どんなシステムやツールでも、押し付けがましく「こう使わなきゃ」と思うと一気に苦しくなる。それよりも、失敗しながらでも身近な「必要」から始めて、ちょっとずつ書き足していくほうが、最終的にまるで血が通ったかのようにノートが動き出す。もし同じように小さな不安やモヤモヤを抱えている人がいたら、力まずに“ちょっとだけ書いてみる”し、書いているならいつも見逃していることを見つめてみないといけないサインかも知れない。