サマリー駆動
仕事の仕方の一つで、資料に対する自分なりのサマリーをつくり、以後それを見ながら仕事する、というもの
メリデメ
o 日々の行動がブレない
コンテキストを反映したサマリーを見ながら仕事しているから
たいていの凡人はコンテキストを記録せず、不確かな記憶をもとに元に資料だけ読むので行動がブレブレ
すぐ脱線する
o 仕事に対する進捗の感触をリアルに感じることができる
常にサマリーをつくるという「言語化」をしている
言語化していること = わかっていること
言語化していないこと = わかっていないこと
何がわかっていて、何がわかっていないのかがわかる
o 主体的になれる
言語化の過程で思考する
自分としてはこう思う、こうするという意見も出てくる
x サマリーをつくるのがしんどい
アウトプットする作業が純粋にしんどい
怠けられないのでしんどい
会議でたとえるとこう
議事録を何も残さない ← 普通の人の仕事スタイル
議事録を残す ← ちゃんとした日報や週報を何時間もかけてつくりこんでる人はここかなぁ（これはやりすぎ）
sta.iconのやり方
だいたいこんな感じ
code:summary_driven_example(下から上に書き足している).md
# (この仕事の表題)
## (中盤後半くらいでおわりが見えてくる）
- TODOリストが並び出す
- TODOリストが並び出す
- ……
ここまでくると終わりまで見えているので余裕があることが多い。
数日に一回とか、1日1hとか、ちょっとひやかす感じで少しずつ消化していける。
サマリーを書いているのでコンテキストスイッチングの負担も小さい。
## ...
## こんな感じで見出し単位でどんどんサマリーをためていく
常に過去のサマリーをみながら、次のサマリーを重ねていく。
記憶にはあまり頼らない。
人間の記憶は強いので、トリガーがあればだいたい思い出せる。
サマリーとしてトリガーを残しておく感じ。
自分にとってわかりやすい、最小限の表現を。
...
## (...)
## ここまでのまとめ
「ここまでのまとめ」「まとめ」などと表現するが。
サマリーが溜まってくると把握できなくなってくるので、ここまでのサマリーをつくる。
以後はなるべくここでつくったサマリーをベースにして仕事を進める。
長いプロジェクトになると「ここまでのまとめ」セクションが4〜5個あったりとかする
## (...)
## 2 (このへんでTODO洗い出したりするかな)
## 1 (なんかタイトル)
ブレストしてゴリゴリ
## src
ここに元ネタをまとめる
(元ネタ)
ここに元ネタに対するこの時の所感
↑こういう形で引用ベースで残しておくことも多い
別ファイルに切り出す
最初はbrast.mdなど一ファイルでゴリゴリ書く
長くなってきたときにどうするか
一案として「きりの良い別ジャンルのネタ」は切り出す
ステークホルダをまとめたもの stakeholders.md
情報源系をまとめたもの resources.md
線表 senpyo.md
会議用インプット meeting_input_mmdd.md
……
ファイル名は検索しやすくすると便利
スクリプトでつくる