Drupal 開発ディレクター兼エンジニアが仕事、育児、本など雑多に書くブログ

ノートの右下の角を破り捨てれば、一発で最新のページを開けるというライフハック

バレットジャーナルでも『情報は一冊のノートにまとめなさい』でも、あらゆるノート術で採用すべき超小ネタ。

 

まず使い始めに、ノートの表紙右端を三角形の形に切り取っておく。

これははさみで綺麗にスパンっと切ってしまうのが良い。

f:id:gengo_k:20200831223002j:plain

 

ノートを使いながら、書き終わったページの右下を表紙の型紙に沿って切り落とす。

↓のように表紙に沿って手でビリビリ破いて、破り取ってしまえばOK。

f:id:gengo_k:20200831223403j:plain

 

するとここに親指を置いてノートを開けば、いつでも最新のページを開けるというスグレモノ。たったこれだけですが、これはノートを使うあらゆる人が採用すべきライフハックだと思う。

というか、市販ノートに標準装備しても良いレベル。

 

特に知的生産を目的としたノート術では、思いついてから書き出すまでの速度は超重要なので、必ず取り入れたい。

 

 ↓この本で紹介されてました。

裏表紙にインデックスを付けるとか、ノート術に取り入れられる小ネタが詰まった良書です。

 

では。

卓上カレンダーの裏面で何でもない日に名前を付ける

↓こういう卓上カレンダーには、大抵一行テキストが書ける月次カレンダーが裏面に付いてます。

 

↓こんなやつ。

https://images-na.ssl-images-amazon.com/images/I/61UPlRZm1LL._AC_SL1000_.jpg

 

正しい使い方は知りませんが、裏面にあるため「未来の予定を書く」のとはちょっと違う使い方が良いんじゃないかと思ってます。

未来の予定は表面に書いておかないと見えないので。

 

そうなると、この裏面には「過去を書く」のが正しい使い方なんじゃないかと。

 

そこで、私はこの裏面カレンダーに「その日のタイトルを書き付ける」ということをしています。

 

1週間前に何をしていたかなんてすぐ忘れてしまうので、一日の終わりに今日を振り返って思いつく最も際立ったイベントを書き付けておく。

それでその日に、何らかの名前が付けられます。

 

「その日一番嬉しかったことを書く」というのでも良いと思います。

 

私も「素敵な帽子を買えた」とか、「無事●●の提案が通った」とかそんなことを書き付けていますが、ポイントはできる限り具体的に描写しておくということです。

 

疲れてる日なんかの記述を見返してみると、「たくさん運動した」とか、「たくさん仕事をした」みたいなすごい適当なものが見つかります。

こうなると、その日がどんな日だったのか、全く思い出せない。

 

それよりは大してないことでも良いので、できる限りその日特有のものを書いておくと良いです。

 

最近は『情報は一冊のノートにまとめなさい』という本に沿って一冊ノート術を実践しているので、月をまたぐ際にこの裏面カレンダーを切り取ってノートに貼り付けます。

情報は1冊のノートにまとめなさい[完全版]
 

 

これだけで日記のような形で簡単に残せるのでおすすめ。

あっという間なようで、8月もいろいろありました。

 

では。

サッカーの実況者になりたかったけど、Twitterを使えば誰でもなれると気付いた

最近Twitterアカウントを分けて使ってます。

本垢とサッカー、エンタメ、企業垢ウォッチ兼キャンペーン投稿用、その他用裏垢という5つの棲み分け。

 

大学時代、海外の大学を1年ずつ渡り歩いて留学するというプログラムに入っていました。

結果いろいろあって1年で帰国したんですが、当時なりたいなーと何となく考えていたのはサッカーの実況者。

 

ジャーナリストでもライターでも良かったんですが、要は言葉で自分の好きなものを伝える仕事がしたかった。

アナウンサーはルートが厳しいことは分かっていたので、違う形でもと思い、オランダとイギリスでそれぞれヨーロッパの歴史や文化と、放送学を学ぼうと考えていた。

 

ここで冒頭の話に戻るが、「サッカー専用のTwitterアカウントでサッカーについて自分の言葉で語り発信する」というのは、実況者に近いのでは?ということに気が付いた。

もちろん駆け出しのタイミングでは誰も見ていないし影響力は持たないんだけど、やっていることそのものは「言葉でサッカーを伝える」というものだ。

 

キンコン西野さんが近大のスピーチで、「過去は変えられる」という話をしていた。

「解釈を変えることによって」ネガティブな過去はどうとでも変えられるということです。

 

私の場合本当にただ解釈を変えただけですが、ずっと頭の中には置いておいて、考え続けていれば、過去を塗り替える新しい解釈に出会えるのかな、という風に思っています。

 

そして大事なのは、解釈が変わり過去が変わった先に未来があるということ。

過去に縛られてコンプレックスだらけになると、目の前にあるきっかけに気付くことができません。

 

まずはそれを取っ払ううえでも、ひたすらな試行錯誤の繰り返しは無駄ではないのかなぁと。

 

そんな訳で、とりあえずは書くことが枯れ果てるまで毎日ブログを書いていきます。

 

では。

タイトルに結論を書けば、ブログは書けるようになる

8/4にnoteからはてなブログに戻ってきて、もう少しで1ヶ月毎日更新です。

gengo-k.hatenablog.com

 

note以前から別のアカウントではてなブログを書いたり、Bloggergooブログなどいろいろ試してきたんですが、一ヶ月毎日書ききったのはおそらく無いと思います。

 

悪い癖として、書いてる時は良いんですが、話がよくまとまらなくなって出すのをやめてしまうケースが多かった。

言葉を出すこと自体はそれほどおっくうではないんですが、それを「まとめる」とか「締める」のがとにかく難しく、書ききれない日々が続いてやめるというパターンでした。

 

そういった続かない日々で、「書くための本」も結構手にしてきました。

今雑文ながら毎日書き続けていられるのは、↓この本によるところが大きいです。

いますぐ書け、の文章法 (ちくま新書)

いますぐ書け、の文章法 (ちくま新書)

 

 

書くためのエッセンスが散りばめられた良い本ですが、中でも「まず結論を書け」ということをしきりに仰ってます。

 

もう少しこの本で筆者が言いたいであろうことを要約すると、

  • 読み終わった人が「何かが変わった」と感じるのが良い文章である
  • だから、書く側は常にリアルに読者をイメージして書かなきゃならない
  • 読者は「何かを知りたくて」あなたの記事を読むのである
  • であれば、「結論」をはじめに書かないと伝わらない

といった感じ。

 

分かりやすく「タイトルに結論を書く」という最後の具体的な手法にフォーカスしてやってますが、そうすると何かしら文章が書けるようになってくる。

私のブログのタイトルをいくつか見てもらえばわかりますが、だいたいが「●●は✗✗で▲▲だ」みたいにその文章の中で言っていることはつまり何なのかをタイトルに書いてしまうようにしています。

 

分かりやすい効果としては、その文章で書くべき範囲がぐっと定まること。

「●●について」みたいなタイトルだとどうしても脱線してどんどん広がってしまい、どこで切って出せばよいのか分からなくなってしまう。

 

もちろんある主題について語れることがたくさんあるというのは悪いことではない。

でもそこは割り切って、「ブログ一記事で伝えられることなんてたかが知れてる」と思って、狭く深く書くようにしています。

 

綺麗にMECEで構造化されていて網羅性の高い文章なんて、企業や専門家に任せれば良いと思うんですよ。

もちろん私もそういう文章が求められる場面では何度も推敲して構造化された文章を練りますが、雑記ブログはもっと雑多に書いて自分の中から言葉を絞り出すことに主軸を置きたい。

 

とりあえずそんな感じでまだまだ毎日更新を続けていくつもりです。

「言いたいこと」が枯れ果てるまで。

 

では。

みんな本当にチャットで仕事ができると思ってるの?

そのままなんですが、できます?

正直全然無理で、こんなに情報過多になって集中する時間が奪われるくらいなら、ビジネスチャットなんて生まれなかったら良かったんじゃないかくらいに思ってる。

 

仕事は依頼 → 受領 → 遂行 → 承認の繰り返し 

仕事って、ざっくりプロセスを分けると依頼 → 受領 → 遂行 → 承認の繰り返しだと思うんですね。

依頼というのはそのまま仕事の依頼。

受領は依頼された仕事を「了解しました」ということ。つまり「やります」と言うことですね。

それを実際に「遂行」して、

遂行した結果生み出されたアウトプットが「承認」されればその仕事は完了する。

承認されなければまた依頼に戻るといった感じ。

 

どんなに細かい仕事でも、基本的にはこうやってプロセスがあるわけです。

それがチャットでやっちゃうと、

  • 依頼したものが受領されたか
  • 受領されたものが遂行されているか
  • 遂行したものが承認されたか

これらをどうやって管理するの?という問題が必ず残る。

 

依頼したものが受領されたか?

よくあるのは、依頼したけど受領が成立していないパターン。

それを防ぐために、「依頼したチャットのスレッドをお気に入り登録して、定期的に見返してリマインドする」みたいなことをやってる。

いやいや非効率すぎでしょう。

データ的に考えると、「受領したという合図がいつまでにこなければリマインドが必要か」というシンプルな日付情報を持たせられれば、毎日全部の「依頼」を見返すみたいなバカなことはしなくて良いに決まっている。

 

受領されたものが遂行されているか?

これもちゃんと管理できてる人って、どのくらいいます?

たまに「何日くらいほっといたらこの人は気付くのかな」と試したくなるくらい、たぶんできていないんじゃないかなーと思います。

 

チャットに日付情報を管理する機能が無いんだから、当たり前といえば当たり前です。

チャットに書いた情報を管理しようとすれば、別の何かで日付情報として管理しなければならない。

理由はたったこれだけのシンプルなもので、仕事をしている場所に日付管理をする仕組みが無いから、それを何かしら別の方法で何とかできる人と、できない人に分かれてしまうわけです。

 

コミュニケーションと管理を分断させるな

ここまで書けば大体見えてきたと思いますが、要は「依頼ベースのコミュニケーション」と「管理」は分解しちゃダメってことです。

コミュニケーションの中で仕事が生まれ、「依頼」が発生した時点から、我々は何らかの方法でそれを「管理」していかなければならない。

そうした時に、そこに管理する仕組みが備わっていなければ、管理できる人とできない人が現れる。

そうすると、管理できる人が全てを管理しなきゃいけなくなって、ぐちゃぐちゃの大変なディレクションが生まれる、という訳です。

 

これを解決するシンプルな方法は、もう分かりますよね?

「コミュニケーション」と「管理」を分断させないこと。

そのために「コミュニケーション」と「管理」をまとめてできるツールというのがもうたくさん出てきている。

Asanaしかり、Wrikeしかり、monday.comしかりといったところです。

 

チャットで仕事をしている企業は絶対に勝てない

これらを駆使している企業は、要は「管理」に必要なコストを極力削減しているわけです。

もちろんこれらをぶち込めば誰でも仕事ができるとか、そんな訳はない。

でも仕事ができない人の取りこぼしを確実に検知して、チームでカバーすることはできる。

少なくともチームで一番優秀な人間のリソースを、「他者の仕事を管理すること」に割いてしまうような事態は無くなる。

 

さらに、仕事がタスク単位で履歴化されているというのも非常に重要で、どのプロジェクトのどんな仕事で何が達成されたかが残っているため、検索性が圧倒的に高くなる。

 

「フロー情報が自然とストックされていく」ため、これができていない企業は長い目で見て絶対に引けを取ります。今はまだ明確な差が可視化されていませんが、それは優秀な人間がカバーしているからです。

 

でもこの旨味を知った人間は、いずれより無駄な仕事の無い環境を選択するようになるでしょう。だってしんどいし、人生の時間は貴重だもん。

 

ビジネスチャットの時代は終わる

てな訳でこのコロナ禍でそろそろ大衆が「チャットで仕事するのってしんどくね?」ということに気付き出したはずなので、遅かれ早かれビジネスチャットで仕事をする日は終わりを迎えます。

そうなった時に、新しい働き方にいかに早く適応してきたか、骨の髄レベルで理解して実践できるかに価値が生まれてきます。

 

なので皆さん、騙されたと思って新しい働き方にどんどんチャレンジしてみましょう。

いくら読んで見て聞いたところで、自ら違いを実感しないと本当の理解はできないですから。

 

 

では。

OmniFocusのレビュー機能を使うと、高度に沿った適切な頻度でレビューできる

もう10年くらいGTDをベースにしたタスク管理をしています。

 

To doリストはかなりいろいろ試しましたが、ここ数年はOmniFocusに落ち着いています。

OmniFocus 3

OmniFocus 3

  • The Omni Group
  • 仕事効率化
  • 無料

 

少々値が貼りますが、長く使っていれば十分元は取れます。

とにかくGTDに忠実に作られていて、UIが綺麗なため使っていてストレスを感じない素晴らしいプロダクトです。

 

OmniFocus自体がレビューの概念を持っている 

GTDには「レビュー」という概念があるんですが、これもOmniFocusの機能の中にちゃんと組み込まれています。

このレビューは、プロジェクト毎にレビュー期間を設定できるという特性を持ちます。タスク単位でレビュー期間は設定できないようです。

この仕様から考えると、レビュー期間が短いものと長いものでプロジェクトを分ければ良いというのが設計思想にあるようです。

 

この「レビュー期間で分ける」というのが、GTDの高度と非常に良くマッチします。 

プロジェクト=GTDの高度で考えると上手くいくというのは、下記にも書かれています。

yuchrszk.blogspot.com

 

僕もこれがベストプラクティスだと思っていて、 現在プロジェクトは下記のようになっています。

f:id:gengo_k:20200826222327p:plain

OmniFocusのプロジェクト一覧

 

高度に沿ってプロジェクトを分ける

GTDの高度について完全に理解して実践できているとは言えませんが、それぞれどのような内容が入っているか簡単に解説します。

 

0m

まず細かいタスクは全て0mに入っています。

単発タスクもルーチンも、インボックスでコンテキストを付けたものは全てここに入るようになっています。

 

1,000m

1,000mには取り組んでいるプロジェクトが入っています。

とかそういうもの。

 

2,000m

2,000mにはもう少し上の、自身がコミットする領域を書き連ねてある。

「家族」「プロジェクトマネジメント」「デジタルマーケティング」のような大きなキーワードから、「Asana」「Drupal」「DTC」のような今のキャリアにおいてコミットして意識的に情報を取りに行くべきキーワードが入っている。

 

3,000m

3,000mはもう少し先の目標で、

  • 大型のテレビを買う
  • 年収XXX万を達成する

みたいな割と具体的な内容が入っている。

 

4,000m

4,000mはもう一個先の中長期的ビジョンのようなもので、

  • オランダを再訪する
  • 自身の名前が業界で一定認知されている

など少しふわっとした夢のような目標のようなものが入っています。

ここはもう少し具体化して、仕事だけじゃなくプライベートも含めていろいろ考えていきたいところですね。

 

5,000m

5,000mは人生に一貫して持ちたい信念のようなもののリストで、

  • 家族を大切にする
  • 探究心を持ち続ける

といったマインド的なことから、

みたいな行動指針のようなものを書いています。

 

Someday

Somedayは今特に考えなくて良いけど時期がきたら考えなきゃいけないことや、別に決まってないけどなんとなく想像している未来について一応書き残しているくらいの感じです。

  • 住宅ローン控除が終わるタイミングで新築戸建てを買う
  • イギリスに移住する
  • WiMAXを別会社契約に切り替える

とかそんなこと。

 

プロジェクトごとに適切なレビュー期間を設定する

このように高度に沿ってプロジェクトを分けておけば、あとはそれぞれのレビュー期間を良い感じに調整してやれば良い。すると、

  • 目の前のタスクは細かい周期で見て調整する
  • 中長期的な視点は長めの周期で見て再考する

といった仕組みができるようになっています。

 

どの高度をどの周期で見るべきかというのは人によっても違うと思うので、私の場合は下記のように倍々的に期間を伸ばして設定しています。

  • 0m = 3日
  • 1,000m = 6日
  • 2,000m = 2週間
  • 3,000m = 4週間
  • 4,000m = 8週間
  • 5,000m = 16週間
  • Someday = 32週間

これで概ね半年に一回くらいは全リストを見直せるといった感じでしょうか。

 

ちなみに1週間ではなく6日としているのは、通常土曜にするレビューが日曜に後ろ倒しになった場合、1週間にしてしまうと次の土曜に出てこず週次レビューの周期が狂うためです。

 

0mは3日ということにしていますが、基本的には週次レビューの一回くらいしかレビューしません。

 

0mタスクが多すぎる人は、ここを仕事/家事/プライベートくらいで分けるのも良いかもしれません。

パースペクティブ上の並びに反映させて、仕事タスクをやって→家事をやって→好きなことをやるといった流れを作りやすいメリットなどもあります。

 

週次レビュータスクを設定する

ここまで設定すれば、あとは「OmniFocusプロジェクトをレビューする」というタスクを一個、週次繰り返しで設定しておけばOKです。

毎週土曜など設定したタイミングで現れるので、レビューボタンをぽちっと押してあがってきているプロジェクトを順にレビューしていくことになります。

 

まとめ

ちょっと長くなりましたが、まとめると、

  • OmniFocusには標準でレビュー機能が備わっている
  • レビュー期間はプロジェクト毎に設定できる
  • プロジェクトを高度として考えると、この仕様が正しく機能する

ということです。

 

高度それぞれの詳細や考え方については、またじっくり考えた方が良さそうですね。ここを考えてGTDをやるか0mだけを見てGTDをやるかでは、数年後の結果が全然変わってくると思うので。

 

あと、レビューなども含めてOmniFocusでフルにGTDはを実践するなら、Mac版アプリも必須です。

高いですが、個人のタスク管理はもうこれで一生良いんじゃないかと思ってます。

OmniFocus 3

OmniFocus 3

  • The Omni Group
  • 仕事効率化
  • 無料

 

GTDの原著はやはり一通り目を通しておいた方が良いです。

「インボックス」だけやってもそれはGTDとはちょっと違いますからね。

 

では。

「野菜の揚げ浸し」が意外と簡単で汎用性が高い

最近ちょくちょく妻の料理を手伝ったり、教えてもらいながら自分で作れる料理を増やそうと挑戦しています。

 

妻は野菜が好きで、実家も農家のため、たまにどっと野菜が届いたりします。

 

中でも好きなのが「茄子の揚げ浸し」。

こんなの↓で、スーパーの惣菜コーナーでもよく置いてますが、ご飯にも酒にも合うので好きなんですよね。

cookpad.com

 

この揚げ浸し、作ったことが無かったので一緒に作ってみたらそんなに難しくない。

野菜にもよりますが、茄子だと大体下記くらいの手順で良い。

  • 食べやすいサイズに切る
  • 皮に包丁で筋を入れる(なんていうか忘れた)
  • 水気を取る
  • 皮の方から油で揚げる
  • 裏返して全体に火を通す
  • 浸し汁を作る
  • 浸す

 

自分用に少し細かめに書いてますが、要は「揚げて浸す」という超シンプルな手順です。

そして他の野菜でも下ごしらえの部分だけ覚えていけば手順は変わらないので、汎用性が高い。

 

下の記事なんかでも色んな野菜が使われてますが、茄子以外にもズッキーニ、おくら、ししとう、アスパラとか結構いろいろいける。

www.sirogohan.com

 

ちなみに浸し汁は、うちでは「めんつゆを薄めただけ」くらいの感じでやってます。

本当はもう少し手間かけた方が良いのかもしれないけどね。

 

今日は茄子、ししとう、パプリカ、おくらをいただきました。

 

では。