PARAメソッドをがっつり読む
part1,2,3まである
PARA
Project
「ゴール」と「期限」を持つ一連の作業
Area(Area of Responsibility)
長期間維持すべきこと
「基準」を持つ
この基準を下回らないようずっと維持し続ける必要がある
活動、状態、持ち物などあらゆる概念を含む
Resource
今現在関心があるネタ
概念や方法論であること（topicやthemeと書いてある）
Archive
PAR以外
一度PARとして扱われたものが用済みになるとここにくる
Project vs AoR
ProjectはAoRによって駆動される
例
本の出版というprojectは、執筆というAoRによって
マラソン大会というprojectは、健康というAoRによって
ProjectとAoRは分けてリストにすることが不可欠である
分けてないと以下3つの弊害が生じる
1: 自分がどこまでコミットしているかがわからない
たとえばリストに「生産性をなんとかする」と書いてあっても、これは何の情報ももたらさない
コミット対象とは「具体的な成果」を「端的に」記したリストである
これがproject
自分が何にコミットしているのかがわからないと、何を変えればいいのかわからない。そして、あなたがコミットしていることは、漠然とした責任の集合体ではなく、具体的な成果の短いリストなのです。つまり、プロジェクトです。
2: 今の取り組みと長期的目標を結びつけることができない
リストにProjectとAoRが書いてあるとノイジーだったり進捗感がなかったりする
Projectのみリストであれば、端的だし、進捗感も生まれやすい
3: 目標に向かって進んでいるかがわからない
Projectの進捗は定量的に測り、AoRの進捗（基準を満たしているかどうか）は定性的に判断するもの
両者が混ざってると、前者を定性的に見てしまったり、後者を定量的に測ろうとしたりして混乱する
Project vs Goal List
以下をつくれ
projectの一覧
goalの一覧
Q: goalとAoRの違いは？sta.icon
わからん
sta.iconはいったん別物として扱ってみるか
Goalとは達成したいこと
AoRとは維持し続けたいこと
Goalに至った後にAoRに移る（達成したので次は維持する）、はありそうだな
つくったら、projectとgoalを結べ
https://gyazo.com/32ff3cbe229c5adae04eda78aae7c5d0
以下の原則を心に刻め
projectはgoalに結び付けなければならない
goalはprojectに結び付けられなければならない
趣味や夢も悪いことではないが、projectやgoalと混同するな
Projectをつくる
まずは自分が持つprojectを、自分で洗い出せ
人やツールの制約にとらわれない手段が良い
紙とか、白紙文書とか
以下の原則を心に刻め
一つのツールだけでproject管理をカバーすることは不可能
n個のツール（プロジェクト管理などn人で使うもの含む）を使うのが当たり前
どのツールにも同じ整理体系でprojectを入れろ
ツールAには整理体系Xで、ツールBには整理体系Yで、みたいに切り替えて使い分けるとしんどい
この原則を支えるために、PARAは3の基本原則に基づいている
単一の整理体系でnツールを使うための3の原則
1: 4-based
4という数字を採用している
PARAも4だし、サブ階層も4段まで
例: evernote
application
stack
notebook
note
OneNoteもそうだなsta.icon
notebook
section
section group
page
4の根拠は色んな研究結果を踏まえて
人のワーキングメモリ含む
2: 何言ってるかわからんsta.icon*2
The second principle is that P.A.R.A. perfectly mirrors your task management and project management systems.
タスク管理とプロジェクト管理システムを完全にミラーリングする？
3: 5% focus
直近実行する情報とそれ以外を区別するシステムになっている
たとえばタスク管理でいう「デイリータスクリスト」もこの5%の方に入るsta.icon
Archive
the Archives are your portfolio of completed projects
archiveとは完了したプロジェクトのポートフォリオである
再利用しやすいし、再利用できるシチュが多いことも経験則として知られている
GTDレビューとの対応
Review Projects daily
Review AoRs weekly
Review Resources Monthly
Review Archives Yearly
-------- ここまでが part1 --------
Project vs AoR
分けて記載することと、直近やることをProjectの一箇所に束ねることを強調している
ProjectとAoRの結びつけはさほど重要ではない
Projectはがっつり取り組んでるので、何と絡んでるかは自明
それよりもProjectの目標を見失いがちなので、ProjectとGoalを結びつけることは重要
AoR≠Goal？sta.icon
原意だと「Areas」と「Goals」
AoRの中にAreasとGoalsがある？
AoR vs Resource
AoRは「責任」
Areas of Responsibility are the roles you take on in life and the hats you wear (Spouse, Mother/Father, Team Leader, Soccer Coach), the ongoing standards where the buck stops with you (Product Development, Company Newsletter, Legal), and things that take a certain amount of constant attention (Exercise, Finances, Apartment, Pets).
被っている帽子（配偶者、母親・父親、チームリーダー、サッカーコーチ etc）
自分が負っている役割（～～製品開発担当、社内報更新担当、社員としてのコンプラ意識 etc）
常に注意を払う必要があるもの（健康、家、ペット etc）
Resourceは「関心事」全般
その他
Resourceの方が情報量は膨れ上がる
個人的な事柄はAoRに入れる
というより他者にも使えるもの、見せていいものはResourceに入れる
Resource＝他者にも共有できる、だと便利なので
AoRのページからResourceのページにリンクを張ることで、両者を繋げることができる
Flow control
Project to A | R | A
to AoR
projectが長期的・継続的な責任になった場合
to Resource
project進めてて発生した中間成果物や再利用できるもの
再利用性のために積極的に切り出すのが良いと言っているsta.icon
to Archive
一般的なフロー（完了したprojectはarchiveする）
AoR to P | R | A
to Project
新しい行動やサブプロジェクトが思いついた・見えたときなど
to Resource
他の人にも使えそうだなと気付いたときなど
to Archive
滅多にないが、延々と維持するのが当たり前だったことに終止符が打たれることがある
筆者は「長年やってたウェブサイトの閉鎖」を挙げているsta.icon
Resource to P | A | A
to Project
ただの興味関心に火がついた場合
to AoR
自分が持つ責任に対して恒常的に適用できそうだとわかった場合など
筆者は興味として集めてたレシピを「家族の健康的な食事のために使える」と判断してAoR化した例を挙げているsta.icon
to Archive
興味関心がなくなって邪魔になった場合
消してもいいが、Archiveだと消さずに済むので心理的に楽sta.icon
Archive to P | A | R
to Project
これも一般的なフロー（元々archive projectは再利用したい・できるものなので）
to AoR | Resource
archiveした（終わった）もの中で「これ必要そうだ」とわかったとき
あるいはAが（AoRやResourceとして）必要だとわかった後、Archiveを探してみて発見したとき
情報整理（移すとか）は都度やる
筆者曰く、
定期的にやるのはおすすめしない
整理整頓用の時間は通常確保されていない
人間は整理整頓したがらない生き物
だから息するように、都度やるしかない
just in time organizationと呼んでいる
FAQ
Q: すべてのツールに対してP, A, R, Aの領域は全部最初からつくってしまった方がいい？
Ans: ケースバイケース
基本的には必要になってからつくればいい
が、モバイルから使う場合などは「新しいカテゴリをつくるのが面倒」なときもあるので、その場合は最初からつくっておけばいい
Q: ある情報をどのツールに乗せるかはどうやって判断してる？
Ans: そのツールの性質
たとえば
Evernoteは「色んなファイルを扱える」「すぐ公開できる」
Dropboxは「大きなファイルでも扱える」
Google Driveは「同時編集できるドキュメントを扱える」
Q: なんでAoR直下に22個もフォルダがあるの？（作者は22個分けてるらしい）
Ans: 私にとってはこれが良いから
具体的であればあるほど特定しやすい
が、多すぎるともちろん破綻する
そのあたりのバランスが、著者の場合は22ってことなんだろうと思うsta.icon
Q: 各ツール間でフォルダ構造が乖離していくんだけど、そういうもん？
Ans: そういうもん
ちょっと違うだけでも別に把握できるので問題ない
ちなみに「このツール上にしかないフォルダ」的なものも例外的に存在することがある
たとえばZoomのrecording folder
筆者の場合、ローカルコンピュータのResource\ZoomRecordingに保存される
このフォルダは他のツール（のPARA配下）には無い
Q: Evernoteのノートブック数250の限界来たらどうしたらいい？
Ans: しゃーない
ノートブックを集約するなどして数を減らすしかない
Q: バックアップどうしてます？
Ans: 特別なことはしていない
MacのTime Machine
クラウドに保存されている + ローカルPCにも保存されている
バックアップ用の外付けハードディスク
3rt partyツールは使っていないとのことsta.icon
-------- ここまでが part2 --------
part3は関係ないネタなのでいいや