from <a href="/ja/pRegroup2020">pRegroup2020</a>
<a href="/ja/%E4%B8%8D%E7%94%A8%E7%9F%A5">不用知</a>も<a href="/ja/%E6%A7%8B%E9%80%A0%E5%8C%96">構造化</a>される
<a href="/ja/%E3%83%A6%E3%83%BC%E3%82%B9%E3%82%B1%E3%83%BC%E3%82%B9%E3%83%A1%E3%83%A2%3A%E7%99%BA%E8%A1%A8%E8%B3%87%E6%96%99%E3%82%92%E3%82%BC%E3%83%AD%E3%81%8B%E3%82%89%E4%BD%9C%E3%82%8B">ユースケースメモ:発表資料をゼロから作る</a>のこの図を見ての議論
<img src="https://gyazo.com/7b39ccff2b3972e5dbd5ffae913ef11d/thumb/1000" alt="image">
不用知が構造化されている
<ul>
<li>「不用知＝今回の発表資料には使わなかった断片」
</li>
<li>これも最初は「使うか使わないかわからない」という状態で「使うかもしれない」から作られた
</li>
<li>それが「これは使う、これは使わない」と明確になる前に構造化のプロセスがありました。
</li>
<li>今回の発表資料作成プロセス
<ul>
<li>「どうやってグループ化のメリットを説明したらいいんだ」と戸惑う</li>
<li>別ソースの情報を丸ごと流し込む<ul>
<li>「関係がすごくある付箋」と「そのままでは絶対に講演資料に使わなない付箋」を含んでいる</li>
</ul>
</li>
<li>それを整理する</li>
</ul>
</li>
<li>他の目的のために整理したマップから付箋を流し込み
</li>
<li>それを今回の付箋と混ぜて空間配置
</li>
<li>今回の目的のために有益かどうかがわかってきて、有益でない部分を切り離し
というプロセスが支援されたり、情報が記録されたりできると良い
</li>
<li>不用であることは<a href="/ja/%E4%BA%8B%E5%BE%8C%E7%9A%84">事後的</a>にわかる
</li>
<li>今回の目的に使わなくても、それがわかるまでの構造化のタスクは有益なので再利用されるべきである
</li>
</ul>

不用知も構造化される