Noratetsu Lab

• Obsidian日誌：構造ノートとはなんぞや①～構造作りは自動化できない～
• Obsidian日誌：構造ノートとはなんぞや②～文脈には前提・操作・根拠が必要である～

　これまで2回に分けて書いてきた、「構造ノート」とはなんであるか、という話をまとめたい。

　まず経緯を整理しておく。

• Obsidianと縁の深いメソッド「Zettelkasten」の実践にあたっては、「構造ノート」の作成が勧められる。
• 「構造ノート」の存在意義を、以前私は「自分の問題意識に基づいて複数のノートを構造化し、文脈を与えるため」と表した。
• しかしその表現が不十分で実用的でないと自分で気がついたので再考しようと思った。

　そして①～構造作りは自動化できない～（Obsidian日誌：構造ノートとはなんぞや①～構造作りは自動化できない～）では以下のことを書いた。

• 構造化は「探し集める・仕分ける・言い表す」の繰り返しでできている。
• 構造化は自動的・機械的にはできない。
• その工程は「対象を通して自己を綿密に怠りなく観察すること」と言える。

　次に②～文脈には前提・操作・根拠が必要である～（Obsidian日誌：構造ノートとはなんぞや②～文脈には前提・操作・根拠が必要である～）では以下のことを書いた。

• 文脈とは、単独の語・フレーズ・文で表現できない意味合いのことである。
• 構造ノートとは、文脈を保存するものである。
• 文脈の保存には「前提の整理・情報の操作・根拠の明示」の工程が必要である。
• 文脈の保存とは、自分として生きることそのものである。

　以上のことを振り返り、「構造化」と「文脈の付与」のふたつの観点を統合しながら「構造ノート」とは何かを考え直してみよう。
　まず定義としては、「何らかの前提に基づいて複数のノートを集め、操作を加えて適切に配置し、その操作の意図を明示することによって文脈を保存したもの」と言い換えられそうである。前提の第一のものとして、当初の表現に用いた「自分の問題意識」がある。
　そしてその実践のためには「対象を通して自己を綿密に怠りなく観察すること」が必要となり、そうやって構造ノートを作っていくことはつまり「自分として生きること」そのものではないか、ということである。
　毎度新たに構造を考え直すのは非効率に感じられることから、一度うまくいった構造は次回以降も流用したくなるかもしれないが、そのまま使いまわそうとすれば「構造に当てはめるために情報の文脈を作る」という主客転倒が起こりかねない。ゆえに如何に大変であっても、フォーマットはヒント程度に留めてあくまで自己の観察によってその都度構造を構築していく必要がある。
　そのように自己を言語化することは認知資源を大きく消費するものであり、到底すべてに対してそれを実践することはできない。そこで、私はこれに取り組むのだという意識を持って対象を選択する必要がある。その選択と実践が「自分として生きること」であるように思う。
　つまり構造ノートというものは、情報の理解に貢献するに留まらず、自己を観察し、自分として生きる場として重要な意味を持つのである。

　構造ノートについてはひとまず以上です。
　

• Obsidian日誌：構造ノートとはなんぞや①～構造作りは自動化できない～
  あらすじ
• 以前noteの記事にて、構造ノートの意義を「自分の問題意識に基づいて複数のノートを構造化し、文脈を与えるために存在しています。」と表した。
• その表現に対し、自分で不満を感じたので言い直したいと思った。
• 前回は「構造化」の三文字について考えた。
  • 構造化は自動的機械的にはできない。
  • うまくいった構造の型も使い回せるとは限らない。
  • 事例の特殊性に気づくためには自己観察と言語化の努力が必要である。

　今回考えたいのは、「文脈を与える」という表現で言い表したかった意味合いについてである。

　これは「構造化」から自分なりに更に一歩踏み込んだ表現であって、現時点でも「つまるところ文脈なんだよな」と思うのだが、「つまるところ」と言いたくなるときには大方抽象的過ぎるものである。イメージするには良いのだが、具体的に何をするのかは「つまるところ」だけでははっきりしない。
　「文脈」という言葉にあくまで「文章」のイメージが強いようであれば「コンテクスト」と読み替えてもらえればいいが、要は「脈絡」「筋道」「前後関係」「背景」「論理的・意味的関係」といったことである。接続詞と接続助詞で繋がっていくその繋がりとも言えるだろう。単語だけ、フレーズだけ、単独の文だけでは表現できない意味合いということだ。
　文脈を「与える」と言いたくなったからには、そこには「放っておくと文脈は生まれない」という前提がある。「放っておく」とはつまり、情報を集めない、またはただ列挙するという状態に留まっていることを意味している。並べただけでは文脈は生まれないのである。
　いや、もっと正確に表現しよう。並べられたものを見て、頭の中にはほとんど反射的に何かしらの文脈が生まれる。しかしそれをきちんと書き表さなければ、その文脈が情報として意味を持てないのだ。そこに見出した意味を活用するには、情報の列挙を見る度にいちいち同じ連想をしなければならないことになる。それは不確実で非効率である。
　文脈というのは、構成要素を見れば毎度必ず同じように捉えられるものではない。条件や他の構成要素が増減すれば変わってしまうし、情報の並び順だけでも認識は変化する。生じたその時に姿を留める処理をしなければ、移ろって失われてゆく。ここにこういう文脈が確かにあった、ということを保存するのが「構造ノート」だと私は認識している。
　よって、構造ノートは「ページリンクの列挙」だけではその役目を十分に果たせない。構造とはリストではない。（リストは構造の一部ではある。）

　さて、「文脈を与える」ためには具体的にどうしたらいいのか。前回は「構造化」を考えるにあたって「言語化して明示する」を繰り返したが、まさにその作業はなんであるかということを考えなくてはならない。
　このことについては数多の言説があるし、客観的に見れば敢えてここで私が考える必要があることではないかもしれないが、私には私の言葉が必要なので、私なりに考えて書いていくことにする。
　前回同様、自分が実際に行う行動を整理してみよう。

• 前提を整理する
  • 前提とは：主題に対して影響を与え得る、環境や気分、事の経緯などの状態
• 情報を操作する
  • 操作とは：主に分類・ソート・階層化
• 操作それぞれの根拠を言葉にする
  • 根拠とは：関連知識・連想・気持ちなど

　例えば、「構造ノートとはなんぞや」というテーマには「noteにはこう書いた」「構造化に失敗しがちで困っている」などの前提があり、テーマについて生じたアイデア・情報群に対して「構造化と文脈の付与の二つに分別しよう」「経緯→手順の可視化→現状→検証→結論の順で並べよう」といった操作を加えていく。そしてそれらについて「言葉が表している範囲が違う気がするから」「この順で考えるのが自然だから」というふうに根拠を言葉にする。自明な気がするとしてもきちんと言葉を思い浮かべることが肝腎だが、明らかに「見ればわかる」ものは書き留めるまでしなくともよいだろう。
　そうしていくと、紙面または画面上に並んでいる情報の構造がどういう流れに於いてどういう理由によって形成されたかがわかる形になる。わかる形になるとは、未来の自分が読んでも文脈を再現できるということである。

　文脈は「何を感じたか」「何を思ったか」の世界であり、それを認識の都度、逐一言葉にするのは容易でない。もちろん全ての情報に対して文脈を捉えて書き残すことは到底できない。しかし他ならぬ私が、他ならぬ私のために情報を集めて用いるのならば、それは容易でなくとも取り組まなくてはならないことであろう。それこそが他ならぬ私として生きることそのものであるとも感じている。
　そして「これについてはきちんと取り組まねばならない」という意識を持つためのものとして、構造ノートという場が私のObsidianに存在しているのである。
　

　タイトルに「Obsidian日誌」と示している通り、これは私個人の模索を記録したシリーズとして書くものである。

　以前noteに書いた記事にて、Zettelkastenでノートを作る際には「Index or Structure notes」という役割のページが生み出され、私は（jMatsuzakiさんに倣って）それを「構造ノート」と呼んでいますという話をした。

• 【Obsidian】ノートの三分類―構造・結論・覚書①

　この記事の中で当時の私は、構造ノートの意義を「自分の問題意識に基づいて複数のノートを構造化し、文脈を与えるために存在しています。」と書き、また「シールを集めるための台紙のようなものです。」と喩えている。
　これを書いたときはそれで明瞭に定義できているかのような気分になっていたのだが、それから一ヶ月と少し経ち、なんとなく肝心なことを言えていないような気分がじわじわと滲み出てきた。

　まず「構造化」という三文字であっさり片付けてしまっている部分だが、そこには具体的な行動がひとつ以上存在しているはずである。
　自分で集めてきた或いは生み出した情報を構造化すると言った場合、私が実際に行う行動はおそらく以下の通りである。

• 関連する全情報を探し集める（探し集め続ける）
  • 種類で分別する
    • その分類の定義を言語化して明示する
  • 段階を可視化する
    • その意図と理由を言語化して明示する
• 全体を見渡して不足要素を探す
  • 不足要素を適切な種類と段階に位置づける
    • 位置づけの理由を言語化して明示する
    • 調べるか考えるかして不足要素を埋める
• 全体を見渡して構造の核を見出す
  • 全体像を言語化して明示する

　単純化すると、「探す」「仕分ける」「言い表す」の三種の行動を何周かしていることになる。うまく構造化できていると感じるときはこの一連が無意識に行われているのである。
　しかし、この工程は今自分を振り返って「こうしているということなのだな」と思って書き出したものであり、つまり昨日まで全体をはっきり把握してはいなかった。自覚がないということにより、「前は構造化できた」という成功体験がありながら、「でも今回はうまくいかないなあ」と理由もわからずもやもやと悩んで時間を空費する事態が生じる。
　私が特に陥りがちなのは、「構造化しよう」という意志に引っ張られて、形式的に整えようとするパターンである。一度うまくいった構造を分析して次もそれでやればうまくいきそうに感じるからだ。
　ところが、個々人が多種多様な情報を千差万別の目的意識によって収集して整理するとなれば、構造の種類も多様になって当然のような気がしてくる。一度うまくいった構造が次も使える保証はない。個人の好みや思いが反映される以上は、ビジネス文書や学術論文のような画一的な形式にはなり得ないと言ってもいいだろう。うまくいったものをヒントにはできても、それをそのまま使い回せると無警戒に信じるべきではない。

　自分の関心によって構造の形は変わっているにもかかわらず、そのことがしばしば忘れられてしまうのはなぜか。
　それは、その構造がどうしてそこで成立したのかを自分ではっきり認識できていなかったからだろう。上記の工程でしつこく繰り返している、「言語化して明示する」の部分が欠けているのである。**「今回の場合はこう感じたからこうなったのだ」という脳の動きを把握して記しておかなければ、その事例の特殊性が認識されない。**そうなると、それらしく抽象化して考えることによって使い回せそうな枠組みをでっち上げ、なんとかして他の情報にも同じフレームを当てはめられないかと格闘し始めたりすることにもなる。実に不毛な苦闘である。
　構造化するにあたって考えるべきことのパターンを先んじて用意することはできても、構造そのものはその都度考えていかなければならないし、それはその対象を腑に落ちるまで理解することと同義であって、自動化は不可能なのである。
　したがって構造ノートの作成とは、「構造化」のボタンをポチッと押せば一瞬でできるような簡単なものではなく、言い換えるならば「対象を通して自己を綿密に怠りなく観察すること」と表現できるかもしれない。

　次回は「文脈を与える」ということについて考えることにする。
　

　普段、日記や考え事にはObsidianというMarkdown管理ツールを使っている。
　Obsidianとは何かということについては、簡潔に言い表すのが難しいので以前noteに書いた記事をお読みいただけると幸いである。この記事の最後に素晴らしい解説記事の数々へのリンクも貼ってあるのでご活用いただきたく。
　さて、毎日Obsidianを使ってあれこれメモして考えて熟成させてということをしているのだが、ObsidianはPC用のデスクトップアプリであり、Obsidianの優れた検索・リンク機能はスマートフォンでは使えない。似た環境を用意できるものとしてiPhoneでは「1Writer」というアプリが良いらしいという話は聞くが、当方はAndroidを使っているのでそのアプリには頼れない。ゆえに、スマホからファイルを開きたくなったときにどういう格好であったらよいだろうかということを前から考えていた。
　唸っているうちにはたと思い出したのが、「DoMA式」である。

　DoMA式とは、倉下忠憲さんがブログ「R-style」にて編み出していらっしゃったWorkFlowy運用術のことである。ネーミングについては倉下式WorkFlowy運用術 その５: DOMA式 – R-styleにてお書きになっているのでそちらを参照のこと。
　私はリアルタイム（2020年6月）でその連載を読んでいて甚く刺激を受けたのだが、当時は如何せん自己が混乱しておりうまく取り込むことができないでいた（混乱のさまは「アウトライナーの使い方ド下手問題（アウトライナーの使い方ド下手問題～まとめ～）」にて）。
　DoMA式の基本となる要素は以下の三つである。

• 倉下式WorkFlowy運用術 その1:ワンデイリスト – R-style
• 倉下式WorkFlowy運用術 その２:注意オブジェクトモデル – R-style
• 倉下式WorkFlowy運用術 その３: フラットスタイル – R-style

　それぞれの意味するところについては是非倉下さんの各記事をお読みいただきたい。
　なお、DoMA式は主にアウトライナー上で項目を動かし自分の注意に合わせて情報の形を変えていくことがキモであり、今回私がしたいことはDoMA式の思想からインスピレーションを受けてのものではあるが、DoMA式をそのまま採用したものではないことをご了承いただきたい。

　Obsidianのフォルダを管理するにあたり私が思いついたのは、DoMA式の三要素のうち「注意オブジェクトモデル」に基づいて作ったフォルダを「フラットスタイル」で並べるというやり方である。つまり、分類によってではなく自分の関心を基準としてファイルをまとめたフォルダを、階層化せずにルートフォルダ直下に並べるということだ。
　「フラットスタイル」を用いるのが良い理由は二つある。
　ひとつは、取り出したいファイルを最短距離で開くことができるということだ。「あれを見たい！」と思った時にさっと取り出せるのが理想である。分類のために階層が何層にも作られていると、あそこにあるとクリアにわかっていても辿り着くために絶対的に手間がかかる。もちろん「お気に入り」の設定など種々の努力でショートカットはできるが、Obsidianに限って言えば、そもそも分類のための階層をフォルダによって作っておく必要がないため、フォルダ構成自体を単純にすることを考えても差し支えない。
　もうひとつは、今自分が注意を向けたいものが一目で判るということである。これについては必ずしもフォルダ構成によって達成する必要があるわけではないが、「Obsidian上で今何がホットか」を示したいという場合にはObsidianのフォルダ構成でそれを可視化するとシンプルにわかりやすい。
　また、Obsidianのフォルダだからこそ「フラットスタイル」を採用できるという理由もある。
　上でちらりと触れたが、Obsidianはタグ管理と検索、サジェストが強力である。タグはネストさせることができるので、フォルダの分類で試みるような階層管理もタグによって実現できるし、更にタグは複数つけることができるので階層管理をしながら同時に「こうもり問題」も解決される。よって、普段ファイルエクスプローラを使う理由は全くと言って良いほど無い。
　つまり、階層管理をすっかりタグに任せてしまうことで、フォルダの構成についてはスマホからのアクセスの利便性にだけ集中できるのである。

　では、具体的にどうしているのか。以下が普段使っているVault（Obsidianのフォルダ）の状態である。

　まずフラットスタイルではないフォルダについて書いておくと、「_DailyNotes」と「Zettelkasten」はそれぞれ「デイリーノート」と「Zettelkastenプレフィクサー」のプラグインによって作られるファイルの居場所であり、「Boards」は「Notice Board（掲示板、立て札）」の意味で、使用頻度の高いリストが入っている。「Attachment」は画像類で、「Config」はObsidianの運用そのものに関するメタな位置づけのファイル置き場である。「」だけのフォルダは、それら以外の様々なファイルが分類したりしなかったりでごちゃっと入っている場所である（タグとリンクが機能しているのでObsidian上では整っている）。
　そして灰色で塗り潰してしまっているのがフラットスタイルによるフォルダなのだが、現在たまたま人に見せにくい情報になってしまっていたので（それっぽいダミーを作る手間を横着して）隠している。ここには例えば「確定申告」とか「○○執筆」とか「引越用資料」とかいうフォルダが、自分にとってホットである間の期間限定で並ぶことになる。
　先にフラットスタイルを用いる理由として、「あれを見たい！」と思った時にさっと取り出せるのが理想と書いたが、逆に言えば「あれを見たい！」と思う可能性が明らかに低いファイルは、目立つところやわかりやすいところにある必要がない。だから、取り出したい期間だけルートフォルダ直下に出張し、そしてその期間が過ぎれば「」フォルダの中のどこかにしまわれることになる。

　実のところ、過去の何かしらのフォルダ管理に於いて、そういう形で「今使うもの」を直下に置くということをしなかったわけではない。むしろ、いつも"そうなってしまっていた"。しかしそれは常に不本意だった。なぜなら、既に作り上げた分類に今使っているファイル群を収めていくのが面倒であるがために適当に仮の場所を作ってやっている感覚だったからだ。そのフォルダの粒度は、既存のフォルダ構成のどの部分とも合っていないのだ。
　システムとしてフラットスタイルが成立するのは、全体が「注意オブジェクトモデル」つまり「客観的分類ではなく自分の主観に基づいた塊の作り方」に沿っているからだろうと感じている。「客観的分類からのはみ出し」としてとりあえず一時フォルダを作るのではなく、今向けている注意の塊はその前もその後もその塊のままあって良いのであって（もちろん適宜解体しても良い）、その塊のまま自分の注意のランクに応じて移動できる必要があるのだ。
　常に自分の注意に合わせてフォルダを作ってしまいながら、結局それが整理上の混乱の元になるか、それともそれこそが整理に成功する要となるかという正反対の結果があり得るのである。DoMA式に対して感じるひとつの大きな意義は、自分の注意に基づく塊を作るということを、「分類が面倒くさい」という怠惰の結果ではなく「そういうシステムである」と考える発想の転換をもたらしてくれたことである。大袈裟なようだが、私にとってそれは確実にコペルニクス的転回であった。

　ということで、今回はObsidianのフォルダ構成に「フラットスタイル」そしてその前提として「注意オブジェクトモデル」の考え方を採用してみたという話をした。
　これについては今後「やっぱり違うやり方が良い」と思う可能性はあまりないような気がしている。
　

　「アウトライナーの使い方ド下手問題」を締めてから、どういう括り方で書いていこうかと考えていたのだが、私にはやはり人様への提案ではなく自分のトライアル・アンド・エラーの吐露が合っていそうである。
　よって、今後は「アウトライナー日誌」というシリーズで書いていくことにした。うまくいっているかもしれないし、いっていないかもしれないが、誰かの何かの参考になれば幸いである。
　さて、今回は「アウトライナーを何のために使うのか」という話である。

　もちろん何に使ってもいいのだし、他の人の使い方に対して何か言いたいのではない。
　ただ、自分がアウトライナーを使うにあたって混乱を回避するためには、ひとまず用途を明確にしたほうがよいだろうと考えた。すべてを突っ込んで目玉ぐるぐる大パニックという事態はすっかり過去のものにしてしまいたい（ド下手問題④（アウトライナーの使い方ド下手問題④～オールインワンという幻想～）参照）。
　扱いたい情報というのは様々あるが、リストを作る類のものはとりあえずアウトライナーでなくてもいい。ログの類は常に記録場所を一瞬で開けるようでないと継続できないから、極力他の用途と兼ねない場所にしたい。思いつきの類はアウトライナーに置くと構造化できないまま溜まっていったときに気持ち悪くなりがちである（ド下手問題①（アウトライナーの使い方ド下手問題①～「きちんとしている感」との格闘～）参照）。
　そう考えて、やはり第一の用途として考えたいのは「意味内容の構造化」をすることである。つまり、自分の思索を組み上げていったり、自分以外の存在について解き明かしたりするためにアウトライナーを使うということだ。
　ド下手問題⑤（アウトライナーの使い方ド下手問題⑤～事前アウトラインと事後アウトライン～）にて、文章を綴る、あるいは読むためのものとして、「事前アウトライン」と「事後アウトライン」と名付けた二種類のアウトラインについて語った。
　今回は、文章に留まらずもう一歩広い範囲を対象として考えたいと思う。
　といっても、考えるべきことはほとんど変わらない。まだ存在していない何かを作り上げるために作るアウトラインと、既に存在している何かについて自分または他者に理解を促すために作るアウトラインということである。この場合前者には「設計図」、後者には「説明図」のイメージを当てはめることができるだろう。
　基本的に文字で構成されているものであるから「設計書」「説明書」と書いたほうが正確かとも思ったが、アウトライナーでやることは「文章化」の手前とその先の段階であるから、「書」というよりは、構造に視覚的効果があることも含めて「図」としておくことにした。
　文章なので淡々と書いているが、ここで「よし、アウトライナーは設計図と説明図のために使おう！」という意識が生まれているわけである。

　さて、設計図や説明図として使うという意味をもう少し掘り下げよう。
　設計図としてのアウトラインとは、つまりプランニングの場ということである。ド下手問題⑤で書いたように「文章をどう書いていくか」ということも含まれるし、プロジェクトの計画を立てていくこともそうだし、ツールの使い方の検証もそうだし、今日一日をどう過ごすかの検討もそうである。
　含まれる内容としては、

• 最終的に何が達成されるべきか？
• それについて今どの程度達成するか？
• そのためにはどういう手順が必要か？
• 実際に私がすることは具体的に何か？

　といったこと（見栄え良く抽象化すると逆に私はわからなくなるのでこう書いた）が整理されることを念頭に置きながら、形式には囚われずに自由に書いていくものである。
　なお、ここで削ぎ落としてはならないのは自分の「気持ち」である。最近は思索をまとめるにもまず「気持ち」「前提」「経緯」といった欄を作るようにしているが、私自身のベクトルの記録というのはいつも忘れられがちだった（ド下手問題①（アウトライナーの使い方ド下手問題①～「きちんとしている感」との格闘～）参照）。
　一方で、事実と気持ちと計画とがあまりにもごちゃごちゃと混じるとアウトラインは秩序を失い、思考をクリアにすることに貢献しなくなるだろう。自由と混沌は区別される必要がある。気持ちの記録用の見出しを用意する、色を変える、記号をつけるなどの工夫で「これは気持ちである」とわかるようにすると良いかもしれない。
　とはいえ、アウトラインの規模が然程大きくないとか、文体で区別がつけばそれでわかるとか、とにかく自分が必要と感じなければわざわざ違いを強調することはない（私も混在していたり分けたりしているし、どちらかというと混在している方が多い）。
　ちなみに、アウトライナーで一日の過ごし方のプランニングをすることについては、「気持ち」を織り交ぜるという点で、piece 0：アウトライナーとデイリータスクリスト｜Tak. (Word Piece)｜noteから始まるTak.さんの連載が大変に参考になったので、そちらを是非ご参照いただきたい。
　設計図的要素のうち、実際に私がアウトライナーで行っているのは「ブログ記事執筆のプランニング」である。「Blog」というファイル（あるいは上位項目）にテーマやアイデアを並べ、ズームして作業している。

　実際にはこんな感じである（使用ツールはTransno）。
　（別に隠すほどのものはないのだが、なんとなく未確定のものを出すのは憚られたので一部塗りつぶした。）
　また、このアウトラインを使い始めたのは比較的最近のため、アイデアの多くはまだ別の場所にある。それらをもし全部ここに移したとすれば不本意な混沌が生じるかもしれず、そうなった場合にはどうするか、あるいは量を増やしても混沌にはならないのか、といったことはそのうち考えていきたい。　記事執筆以外の設計図的要素は、それもアウトラインの形で整理しているが、場所としてはアウトライナーではなくmarkdown管理のObsidianに置いている。
　資料やログと直接リンクしたいという要求が生まれるものはアウトライナーだとやりにくさを感じるので、ScrapboxやObsidianのようなツールが便利である。Scrapboxはサーバーに障害があったりインターネットに繋がらない環境になったりすると開けないので、そうなると困る度合いが高い種類のものはObsidianのようにファイルをローカルで管理するツールだと安心感がある。
　アウトラインとしての見た目と機能性はやはりアウトライナーが強いと感じているので、集中が必要な文章作成に於いてはアウトライナーを使ったほうが捗っている。

　次は説明図の方だが、説明図としてのアウトラインとはつまり、「これは何か」の解説または読解である。自分が作ったものを誰かに解説するためのものと、誰かが作ったものを自分が理解すべく読み解いていくためのものを併せている。
　本や記事の見出しとまとめ、ツールの仕様の整理、調べ物のノートなどが含まれる。また、議事録や週次レビュー（週ごとの自分の生活の振り返り）などもここに分類される。
　人に見せるものでないなら、どう作るべきかというのはあまり難しく考えなくてよいだろう。必要な情報を書いて自分の感覚に合うように動かしていけばいいし、自分のためのメモならそもそもそんなにきっちり構造化しなくともメモとしての役目は果たすので、神経質になる必要はない気がしている。
　例えば紙にメモを取った場合には当然構造化ということはそうそうされないが、大体は書いてさえあれば事足り、美しく構造化されていないせいで困ることはあまりない。どうしても手本がほしいなら本やWikipediaや解説系ブログ記事の構造などを参考にすれば良いだろう。
　しかし構造化したい時に自由に構造化できることは非常に重要なことなので、構造化しなくてもどうにかなるからアウトライナーの必要はないという話にはならない。
　重要なのはアウトラインの形式ではなく、「説明図を作る」という心がけである。
　本を読んだら、目次を写すなどしながら読書メモを取って残す。ツールを使い始めたら、それでできること、できないこと、ホットキーなどを整理する。話し合いをしたら、誰が何を言って結局どうなったのか記録する。一週間生きたら、自分の生活がどういうものであって気分はどうであるかを書き残す。
　記事を書いたら、どういう構造なのか人にわかるように整理する。ものを作ったら、どういう機能と仕様なのかを説明書を作る。人に何かを説明することになったら、説明対象の情報を予め整理する（ただし話の内容を練るのは設計図の役目）。などなど。
　つまり、「何かをしたら、その情報を書き残す」ということを、「説明図を作る」というフレーズに集約することで習慣化しようという試みである。この言い換えによって私の頭の中はだいぶ整理された。「記録」という言い方をすると、事実の整理をする作業からはイメージが離れてしまって範囲が限定的になる気がしたため、あくまで「これは何か／何であったかを自分／誰かに説明する」という捉え方をしている。
　他者への説明と自分への説明を区別することにはあまり意味を感じていない。他者に説明する前には大抵自分への説明が必要だろうし、説明図を他者に見せるかどうかの違いがあるだけである。説明図の取り出しやすさの都合で置く場所は変わるかもしれないが、別種のものとはみなしていない。加えてド下手問題②（アウトライナーの使い方ド下手問題②～アウトライナーは「今」のものである～）でも書いたように、未来の自分はもはや他人であるとも言える。

　まとめると、

• アウトライナーをスッキリ使うために用途を明確にしようと考えた。
• アウトライナーならではの用途を考えると「意味内容の構造化」が第一だろうと思った。
• それを「設計図」と「説明図」の二種類であると解釈した。
• 「設計図」とは、まだ存在していない何かを作り上げるために作るアウトラインである。
• 「説明図」とは、既に存在している何かについて自分または他者に理解を促すために作るアウトラインである。
• 形式の如何より、それらを作っていくということの習慣化が大事なのだと考えている。

　ということである。
　今回は以上だが、反省が生じたり劇的な効果が生まれたりしたらまた経過報告を書くつもりでいる。