Para整理法の整理
分類する
重要事項
- 4段階以上を超えないようにします。(application → stacks → notebooks → notes)
- 継続的にモニタリングできる必要があります
- あまりに多くのカテゴリ、あまりに多くのレベリングを避けること
- できることとできないことを分けること - すぐにできることだけを見やすく整理すること
プロジェクト - Project
プロジェクトは締め切りと期限、そして目標が定まっているTaskたち
例) 開発プロジェクト、カンファレンス参加、ハッカソン参加、執筆
領域 - Area of Responsibility
時間をかけて持続するアクティビティ領域 プロジェクトとの違いは期限や締め切りが定まっておらず、Areaと関連する数多くの下位Projectが存在しうる
例) 運動、投資勉強、開発勉強、趣味活動、読書
リソース - Resource
持続的な関心と興味をもって続くトピックの集まり ProjectとAreaと関連度がなくても構わない
例) SEO、ノート作成、オンラインマーケティング、グルメ検索
アーカイブ - Archives
3つのカテゴリに入らない、現在は非アクティブなトピック ノートは絶対に消さないようにする
例) すでに終わったプロジェクト
違い
-
プロジェクト <-> 領域
- プロジェクトは目標と期限を持っており、達成され終了することができます。反対に領域は目標と期限がなく、持続的に関心が必要なトピックです。
- プロジェクトは常に領域の下位カテゴリです。
- 領域からプロジェクトへ移されると進行状況と目標が与えられ、これまでの努力が長期目標へ向かうのに役立ちます。
- 単一の領域ではなくプロジェクトと領域を分ける理由
- 目標を行動可能な小さな領域に分けて達成することができます
- 視覚的な混乱(Visual Clutter)を減らします。
- 現在のプロジェクトを集めて一目で見ることができます。(目標だけを別に集めて見ることができる)
-
領域 <-> リソース
- 個人的な内容と関連があればArea 単なる興味の収集であればリソース
- 領域とリソースは相互連結が可能
-> 開発AreaではウェブタイポはResourceではないだろうか？ - 領域を成す要素
- Areas of Responsibility という言葉に表れるように Responsibilityがあります。 (配偶者として、チームのリーダーとして、コーチなどなど)
- 現在進行中であり、あなたに持続的な責任と関心を求めます。
- 持続的な努力を必要とします。
- リソースを成す要素
- あなたの興味
- 明確な分野
- 資料(写真、タイポリンクなどなど)
注意事項
- 目標のないプロジェクトは Hobby
- 目標はあるがプロジェクトがないなら Dream
デジタル整理のための核心ルール
- 行動の有無で整理する プロジェクトはほとんどが行動可能な単位であり、アーカイブは行動が不可能である
- 隙間ごとに整理する。
- 行動は速く軽く - 即座に対応するようにしつつ、多くの時間が消費されるものはできるだけ避ける。
- 変化に柔軟に対応 - 特定のノートブックでしか使わないフォーマットを避け、できるだけユニバーサルなフォーマットを使う
- 複雑なシステムは作られるのではなく成長するものである
- 整理が終わることよりも、整理が外へ拡張し成長するようにせよ
- 持続的に失敗せよ - 問題点を補完？
- 少ない階層構造を持て
フロー
PARAは流動的なシステムであるため、いつでもプロジェクトと領域、リソース間の移動が自由です。
- From プロジェクト
- To 領域
- プロジェクトが長期的に着実に持続すべき場合
- To リソース
- より多くの学習が必要なとき
- 未来のProjectのための資料調査をする場合
- To アーカイブ
- プロジェクトが終わった場合
- To 領域
- From 領域
- To プロジェクト
- 十分な資料調査がなされた後、新しいプロジェクトを始める準備ができた場合
- To リソース
- 単に自分の興味と関連する内容(特別な責任が必要ない場合)であると気づいた場合、このとき自分が習得した情報を共有することができます。
- To プロジェクト
- from リソース
- to プロジェクト
- 単なる興味から本格的な計画になったとき
- To 領域
- 単なる情報ではなく、着実に持続的に責任を持って行うべき内容だと気づいた場合
- to アーカイブ
- 興味を失った場合 ( 絶対に消したりはしません。)
- to プロジェクト
- from アーカイブ
- to プロジェクト
- プロジェクトを再び始める場合
- to 領域
- 昔の情報がアーカイブされたが、新たに責任が付与された場合
- to リソース
- 興味が再び生じた場合 ( 終わったプロジェクトがリソースになることもあります。)
- to プロジェクト
Just-In-Time整理法
- 整理する時間を決めず、時間があるときに隙間ごとに整理します。
- 小さな部分を中心に修正し、大きな変化を避けます。一度の大きな変化ではなく漸進的な変化を追求します。
- 次のような状況のときは整理することを避けてください
- プロジェクトを終えるために努力している最中なら
- プロジェクトが終わった直後なら(整理によってすぐにまたプロジェクトができるので)
- 時間が多くかかる整理はできるだけシステム崩壊まで先延ばししてください
- システム崩壊とは効率性の低下を意味します。
データを加工する
Code - collect, organize, distill, express
集める - Collect
情報と資料を収集する過程 本やArticle、すべての場所になりうる GTDでいえばInboxに情報を集める過程
分類する - Organize
上で言及したPara整理法に従って4つのカテゴリに分類し、資料を保存します。
抽出する - Distill
集めた情報が膨大になると資料の管理が難しくなります。これまで集めた資料は原石(Raw Material)に該当し、この原石を私たちに必要な形に加工(Distill)する必要があります。この過程のうち paraのprogressiveノート整理法という方法を通じて抽出することもできる
表現する - Express
集めて抽出した情報は自分だけの言語に加工されています。これから加工された内容を現実世界へ表出させなければなりません。知識と情報が他の人々に共有されなければ、第二の脳は作られません。知っていることとそれを説明する過程には大きな隔たりが存在します。この情報を表出することで第二の脳が作られるようになります。
Reference
Para整理法
分類する
重要事項
- 4段階以上を超えないようにします。 (application → stacks → notebooks → notes)
- 継続的にモニタリングできる必要があります
- あまりに多くのカテゴリ、あまりに多くのレベリングを避けること
- できることとできないことを分けること - すぐにできることだけを見やすく整理すること
プロジェクト - Project
プロジェクトは締め切りと期限、そして目標が定まっているTaskたち
例) 開発プロジェクト、カンファレンス参加、ハッカソン参加、執筆
領域 - Area of Responsibility
時間をかけて持続するアクティビティ領域 プロジェクトとの違いは期限や締め切りが定まっておらず、Areaと関連する数多くの下位Projectが存在しうる
例) 運動、投資勉強、開発勉強、趣味活動、読書
リソース - Resource
持続的な関心と興味をもって続くトピックの集まり ProjectとAreaと関連度がなくても構わない
例) SEO、ノート作成、オンラインマーケティング、グルメ検索
アーカイブ - Archives
3つのカテゴリに入らない、現在は非アクティブなトピック ノートは絶対に消さないようにする
例) すでに終わったプロジェクト
違い
-
プロジェクト <-> 領域
- プロジェクトは目標と期限を持っており、達成され終了することができます。反対に領域は目標と期限がなく、持続的に関心が必要なトピックです。
- プロジェクトは常に領域の下位カテゴリです。
- 領域からプロジェクトへ移されると進行状況と目標が与えられ、これまでの努力が長期目標へ向かうのに役立ちます。
- 単一の領域ではなくプロジェクトと領域を分ける理由
- 目標を行動可能な小さな領域に分けて達成することができます
- 視覚的な混乱(Visual Clutter)を減らします。
- 現在のプロジェクトを集めて一目で見ることができます。(目標だけを別に集めて見ることができる)
-
領域 <-> リソース
- 個人的な内容と関連があればArea 単なる興味の収集であればリソース
- 領域とリソースは相互連結が可能
-> 開発AreaではウェブタイポはResourceではないだろうか？ - 領域を成す要素
- Areas of Responsibility という言葉に表れるように Responsibilityがあります。 (配偶者として、チームのリーダーとして、コーチなどなど)
- 現在進行中であり、あなたに持続的な責任と関心を求めます。
- 持続的な努力を必要とします。
- リソースを成す要素
- あなたの興味
- 明確な分野
- 資料(写真、タイポリンクなどなど)
注意事項
- 目標のないプロジェクトは Hobby
- 目標はあるがプロジェクトがないなら Dream
デジタル整理のための核心ルール
- 行動の有無で整理する プロジェクトはほとんどが行動可能な単位であり、アーカイブは行動が不可能である
- 隙間ごとに整理する。
- 行動は速く軽く - 即座に対応するようにしつつ、多くの時間が消費されるものはできるだけ避ける。
- 変化に柔軟に対応 - 特定のノートブックでしか使わないフォーマットを避け、できるだけユニバーサルなフォーマットを使う
- 複雑なシステムは作られるのではなく成長するものである
- 整理が終わることよりも、整理が外へ拡張し成長するようにせよ
- 持続的に失敗せよ - 問題点を補完？
- 少ない階層構造を持て
フロー
PARAは流動的なシステムであるため、いつでもプロジェクトと領域、リソース間の移動が自由です。
- From プロジェクト
- To 領域
- プロジェクトが長期的に着実に持続すべき場合
- To リソース
- より多くの学習が必要なとき
- 未来のProjectのための資料調査をする場合
- To アーカイブ
- プロジェクトが終わった場合
- To 領域
- From 領域
- To プロジェクト
- 十分な資料調査がなされた後、新しいプロジェクトを始める準備ができた場合
- To リソース
- 単に自分の興味と関連する内容(特別な責任が必要ない場合)であると気づいた場合、このとき自分が習得した情報を共有することができます。
- To プロジェクト
- from リソース
- to プロジェクト
- 単なる興味から本格的な計画になったとき
- To 領域
- 単なる情報ではなく、着実に持続的に責任を持って行うべき内容だと気づいた場合
- to アーカイブ
- 興味を失った場合 ( 絶対に消したりはしません。)
- to プロジェクト
- from アーカイブ
- to プロジェクト
- プロジェクトを再び始める場合
- to 領域
- 昔の情報がアーカイブされたが、新たに責任が付与された場合
- to リソース
- 興味が再び生じた場合 ( 終わったプロジェクトがリソースになることもあります。)
- to プロジェクト
Just-In-Time整理法
- 整理する時間を決めず、時間があるときに隙間ごとに整理します。
- 小さな部分を中心に修正し、大きな変化を避けます。一度の大きな変化ではなく漸進的な変化を追求します。
- 次のような状況のときは整理することを避けてください
- プロジェクトを終えるために努力している最中なら
- プロジェクトが終わった直後なら(整理によってすぐにまたプロジェクトができるので)
- 時間が多くかかる整理はできるだけシステム崩壊まで先延ばししてください
- システム崩壊とは効率性の低下を意味します。
データを加工する
Code - collect, organize, distill, express
集める - Collect
情報と資料を収集する過程 本やArticle、すべての場所になりうる GTDでいえばInboxに情報を集める過程
分類する - Organize
上で言及したPara整理法に従って4つのカテゴリに分類し、資料を保存します。
抽出する - Distill
集めた情報が膨大になると資料の管理が難しくなります。これまで集めた資料は原石(Raw Material)に該当し、この原石を私たちに必要な形に加工(Distill)する必要があります。この過程のうち paraのprogressiveノート整理法という方法を通じて抽出することもできる
表現する - Express
集めて抽出した情報は自分だけの言語に加工されています。これから加工された内容を現実世界へ表出させなければなりません。知識と情報が他の人々に共有されなければ、第二の脳は作られません。知っていることとそれを説明する過程には大きな隔たりが存在します。この情報を表出することで第二の脳が作られるようになります。