自分の技術情報の収集についての考察

2022-05-09

この記事について

私の技術記事などの収集と読むタイミングについて考察した記事です。
自分のこれまでやってきたことの考察や現状をまとめたもので、他の人向けの記事ではありませんので、ご了承ください。

これまで試してきたこと

結果 (失敗)

どれも続かなかった。
色々原因はあるが、大きい理由の一つに「いつでも読める(読めてしまう)」というのがあったように感じた。

どういうことかというと、随時記事が追加されていることで、いつも何かしら読めるものがストックされていることがストレスに感じる。
例えば、Gmail は可能な限り受信トレイを空にしておきたい衝動があったり、なるべくアプリの通知系はすべて既読にしないと気になってしまう。

そういう意味では、読んでもメッセージが残り続けてしまう Slack が一番相性が悪かった。
また未読でしかどこまで読んだか管理できないので、読み終わった感じはしないし、後で読もうとしても未読チャンネルが残り続けるのは気持ち悪い・・・
(Slack の機能で工夫はできると思うが、手動で管理しないといけないので、面倒なことも嫌いな自分には向いていなかった)

Twitter との相性の悪さ

Twitter で情報収集もしているが、フィードを見続けるのも合わない。
基本的に流れてくるものを全部見たくなる性格なので、本当に張り付いて見ようとしてしまい、他のことに集中できなかったり疲れてしまったりする。

これも一日一回とか決めたタイミングで収集するようにしたい。

現在の収集方法

なんだかんだ Gmail (というかメール) は切っても切り離せないので、メールを活用して収集している。
現状はこういった流れになっている。

  1. 毎朝 05:00 に AWS Lambda を使って RSS や Twitter の情報を収集し、新着をメールで送信する
  2. 新着記事ごとにリンクになっているので、気になる記事があればそれをクリックする
    • こんな感じのシンプルなメールが毎朝来る
    • 記事情報のメール
  3. 受信トレイに記事情報のメールが届くので、任意のタイミングで見る
    • リンククリック後に送られるメール

これとは別に、調べ物中や Slack などで気になる記事が流れてきたら、とりあえず自分にメールしている。
(この辺は、自分用のChrome拡張を作って、3アクションでできるようにしている。もっとステップを減らしたいけど・・・)

こうすることで、とりあえずメールの受信トレイに読みたいものが必ず集まるようにしている。

読むタイミング

基本的に、メールの受信トレイは空にしないと気になるので、最低でも1日の終わりには空にするようにしている。
すぐに読めないような長文記事やハンズオンなどは、GitHub Issue などにしている。

ちなみに、アサインされた GitHub Issue も一日一回は見るようにしているので、自分の TODO リスト的にも使っている。
(専用のTODOアプリは使っていない)
Assigned Issues

溜めることによる失敗

一時期、後で読む記事にラベルを付けて、受信トレイにはおかず溜めておく運用をしていたが、これは失敗した。
溜め込みすぎてしまい、読む気力が失せてしまうので、積ん読状態になってしまう。

本であればそれでも良いかもしれないが、セキュリティ系の記事とか早めに読まないと意味が薄くなってしまうような記事もあるので、せっかく情報収集している価値が薄れてしまう。
なので、溜めずにとにかくさっさと読んで消化するようにしている。

まとめ

現状は一日一回に制限して自動収集することで、あまり手間を掛けずかつ余計な注意を奪われずにできるようになった。
すでに運用して数ヶ月経っているので、当分はこのまま運用していこうと思っている。

ただ収集方法だけではなく、結局何を見て 何を見ないか が重要で、何でもかんでも収集するとキャパオーバーになってしまい、燃え尽きてしまう。
(しかも、いきなりではなく徐々にやる気が失われていくので難しい)