PKMの基底にあるもの / 書けるときと書けないとき / 虚しくならないノウハウ

Weekly R-style Magazine ～読む・書く・考えるの探求～ 2023/05/01 第655号

はじめに

ポッドキャスト、配信されております。

◇BC062『習慣と脳の科学――どうしても変えられないのはどうしてか』

BC062『習慣と脳の科学――どうしても変えられないのはどうしてか』

ブックカタリスト、今回は『習慣と脳の科学』を取り上げました。二人ともが読んでいた本だったので、いつもと違って、本についての感想を語り合う回になりました。

よろしければお聞きください。

〜〜〜Macの買い替え〜〜〜

Macを買い替えました。注文したら次の日に届くのはほんとうに驚きますね。

で、到着したMacの電源を入れてiCloudのアカウントにログインして前のMacから移行アシスタントを使ってデータを移動すると、びっくりするくらい「同じ環境」が再現されました。アプリケーションも同じものだし、Pythonなどの環境もまったく同じように使えます。

すごい、楽。

一方で少し寂しさのような気持ちもありました。まっさらなOSに一つひとつアプリケーションを入れ直していくあの作業は、思い返してみると手間でありながら楽しみでもあったのでしょう。

さらに言えば、そのようなアプリケーションの入れ直しやファイルの整理をすることで、自分の心に節目のような気持ちが生まれていたのだとも思います。ある種の儀式。

今新しいMacを使っているときには、そうした節目はまったく感じられません。ものすごくスムーズに、滑らかに行為は連続しています。

それはたしかに効率的であり、しかし本当にそれで良いのかは判然とはしません。不思議な気持ちが残ります。

〜〜〜再読する〜〜〜

たまたま検索していたら、昔の自分が書いた記事が発見されました。

◇第一回　「インターネット的×知的生産の技術」その１ 〜未来に伸ばす線〜｜倉下忠憲｜note

たしかそんな記事を書いた気がするなと思って日付を見てみたら「2015年10月20日」とありました。7年以上前の記事。気分的には「圧倒的過去」です。

で、まっさらな気分で──つまりあたかも他の人が書いた記事を読むような気持ちで──読んでみると過去の自分の気負い過ぎみたいなものが感じられつつも、そこにあったメッセージは今の自分にも共感できるな、という奇妙な感覚が湧いてきました。

どういう表現が適切なのかはわかりませんが、「ああ、自分はこういうものを書きたいんだな」と強く思った次第です。この記事と同じ"内容"のものを書きたいということではなく、こういうテーマが「自分のテーマ」なのだなと思いを強くした。そんな感覚です。

おそらくそうした感覚は、これから仕事を進めていく上で大切になっていくのでしょう。「今」とか「少し先」だけに注意を向けすぎてしまうと、長いスパンで物事を捉えることができなくなります。それは初対面の人の二、三の所作だけでその人の印象を決定してしまうくらいにはバイアスがかかった状態です。

これまで自分が書いてきたものを「再読」することで、自分が見えていなかったものが見えてくる。そんな効果があるように思います。

皆さんはいかがでしょうか。5年以上前に書いたものを読み返した経験はお持ちでしょうか。そのときどんな感覚を抱かれたでしょうか。よろしければ倉下にお聞かせください。

では、メルマガ本編をスタートしましょう。今週はPKMについてと、二つのエッセイをお送りします。

PKMの基底にあるもの

少し間が空いてしまいましたが、PKMの話を続けましょう。PKMとは何であり、何をするのことなのか。それを検討します。

■PKMとTP管理

理念の話はいったんさておき、PKMの実態を観察してみると、一つの議題に気がつきます。それは「タスク管理・プロジェクト管理」（以下TP管理）を含むのかどうか、という議題です。

PKMという行為、あるいはそれを扱うツールの内部にTP管理の要素を入れるかどうかは、人によって違っているようようです。それを含んでシステム全体を構築している人もいれば、TP管理は別のツールや手法に任せている人もいる。なかなか面白いですね。

そうした差異を取り除けば「ナレッジベース」と呼べるものを構築していく、という点はだいたいの主張で合致しています。そのナレッジベースがPKMの主眼ではあるのでしょう。しかし、その主眼に入る前にTP管理について検討しておきましょう。

■統一的な合理性

たとえば、Notionというツールに自分のナレッジを蓄積していき、その上で同じNotionにタスクやプロジェクトも保存するようにする。非常にシステマティックであり、合理的でもあります。情報の分散が起こりません。

しかし合理的であることがすべてを肯定するわけでもありません。

第一にタスクやプロジェクトは「ナレッジ」ではない、という視点があります。その見方をとれば不純物を混ぜていることになり、PKMの純粋性は薄れます。

一方で、上の視点への反論もあり得ます。タスクやプロジェクトはナレッジだ、あるいはナレッジに転化できるものだ、という視点を取ればいいのです。

たしかに単純作業のタスクはナレッジとは言い難いものがありますが、100個や200個にも及ぶタスクの実行結果を一つのデータとし、そこから何かしらのナレッジを抽出すること自体は可能でしょう。

あるいは複数個のプロジェクトから共通項を取り出し、プロジェクトのひな形を作るような作業もナレッジを扱っていると言えます。よって、こうしたことを行うのであればTP管理もまたナレッジマネジメントに加えられるでしょう。引いては、この視点は「人間の活動全般」をナレッジマネジメントの対象に広げることにつながっていきます。

ただし広げることが必ずしも良いことなのかは別途検討が必要です。対象が広がりすぎて管理が収拾がつかない、という事態も起こりえます。むしろ、ある程度小さい規模で留めておくのが賢明である、という可能性も考慮した方がよいでしょう。

■手法の密な結合

第二に、TP管理をPKMに含めてしまった場合の「結合」の強さの懸念がありえます。具体的には、あるPKMの手法が確立され、その手法が多くの人向けに開示されたとき、そこにTP管理の手法も必然的に含まれてしまう、という状況が持つ問題です。ようは「セット販売」ということです。

PKMの内部にTP管理が滑らかに取り込まれていればいるほど、別種のTP管理を導入するのが難しくなります。そうなると、もしそこにあるTP管理のやり方が合わなければ、そのPKM手法全体が合わない、ということになってしまうでしょう。

その点、PKMからTP管理が分離されていれば、その部分については個々人が自由に選べるようになります。もちろん「PKMと自分のTP管理をいかに接続するのか」という別種の苦労は立ち上がるでしょうが、はじめから選択の余地がないことに比べればマシだと言えるでしょう。

■何を目指すのか

別段ここで上の議論に決着をつけようというのではありません。ただTP管理を含めるかどうかはPKM界隈においても未確定であり、むしろ「PKMとは何か？」をどう考えるかによってその答えが変わってくる、という点が重要です。だからこそ「PKMとは何か？」をしっかり考えておきたいわけです。

そこで前回に確認した、KM（PKMではなく）の目指すところをもう一度挙げておきましょう。

・KMの目指すところ：知識の循環環境を整える
・KMの目指すところ：新しい知識を生成する

知識の循環構造を整えることで、新しい知識の生成を助けること。これがKMの目的でした。PKMはこれを「個人」というレイヤーにおいて実践することだと言えます。「個人が」ではなく「個人というレイヤー」なのがポイントなのですが、それは後ほど確認しましょう。

ともかく、KM/PKMの目的は、知識を増やすことではありません。たしかに情報環境を整えれば蓄えられる知識は増えるでしょうし、その結果新しい知識が生成されやすくもなるでしょうが、それ自身が目的ではありません。

というか、それ自身を目的としてしまうと、上記の目的は不達成に陥ります。知識を蓄えることに夢中になって、自分から知識を外に出したり、新しく生み出したりする活動の量が減ってしまうからです。知識を増やすことはあくまで、途中の段階の目標であり、場合によってはそれを限定的に諦めることすら要請されます。

この点が、昨今のPKMの盛り上がりについて倉下が抱いてる懸念と関係しています。PKMと立派な言葉を掲げているものの、その内実は単なる「勉強」と同じになっているのではないかと勘ぐってしまうのです。

別に「勉強」という行為が悪いわけではありませんし、人によっては「勉強」の中に新しい知識の創出を含めている人もいるでしょうから、「勉強」という言葉のチョイスがどれほど適切かはわかりません。ここで焦点をあてようとしているのは「外にある情報を、自分の頭に増やすことだけを目的とした行為」くらいに理解してもらえばいいでしょう。

そうした行為によって知識は増えるかもしれませんが、そこで留まっているならPKMがうまくできていないと言うべきでしょう。PKMのツールを使っていても、PKMができていないというねじれの状態が起こりえるのです。

「いや、そうして知識を増やすことが自分にとってのPKMだ」という視点はいつだってありえます。そうしたものを排斥しようというのではありません。ただ、常に結果から目的を再設定してしまうと、何の基準も生まれません。だから、先に目的を確認しておくのです。

もちろん、後からその目的を変えても構いません。むしろ後から目的を適切に変えるために先にそれを確認しておく、という言い方もできるでしょう。ギアチェンジのように、何をどう変えるのかを意識して、事後的な目的の改変という「スムーズ」さを妨げるわけです。