はじめに

現在大学院2年生で、内定先の企業でインターン生として開発をしております rito と申します。

インターンは基本的にフルリモートで行っており、毎週メンターの方と1on1があり、計画の立て方や理解負債との向き合い方など、開発の進め方全般についてフィードバックをもらっています。

この1on1では毎回「今日の調子」を10段階で共有することになっています。ただ、自分がそこで出す数字は完全に主観的なものです。7と8の違いを詳しくは説明できませんし、低い日が続いてもその理由を言えません。睡眠が足りなかったのか、割り込みが多かったのか、単に難しいタスクだったのか。分からないまま、同じ日をもう一度過ごすことになります。

フルリモートだと、ここがそのまま問題になります。出社していれば、詰まって手が止まっている様子も、集中して黙々と進んでいる様子も、ある程度は周りから見えます。フルリモートにはそれがありません。自分がどう働いていたかを伝える手段は、自分の口から出る言葉と、この10段階の数字だけです。つまり、いちばん不透明になりやすい部分を、いちばん根拠の薄い数字で説明していることになります。

この「なんとなく」をやめて、主観のままだった部分に客観的な根拠を持たせたい。それが、集中力（生産性）を計測してみようと思った直接のきっかけでした。

きっかけ

そこで思い出したのが、以前 X で流れてきて読んだ「集中して作業する技術」のスライドの内容でした。

このスライドでは、「今日は集中できた」「今日はイマイチだった」「今日は妨害が多かった」という判断はどれも主観にすぎない、と指摘されています。まさに自分がやっていたことだなと思いました。

そして「推測するな、計測せよ」という原則が示されたうえで、集中作業という主観そのものは測れなくても、25分のポモドーロという単位に置き換えれば測れるようになる、という解決策が提示されます。

なおスライドの主眼は、計測そのものよりもむしろ運動と睡眠、そして計測・可視化と内省を繰り返すことにあります。この記事はそのうち「計測・可視化」の部分だけを、自分の環境に合わせて実装してみた記録です。

ただ、そのまま真似するのではなく、2点だけ自分向けに変えたいと思いました。

妨害の数を手で数えたくない: 数えること自体が中断になりますし、集中しているときほど記録が漏れます。ここは自動化したい
内/外の区別は、あとから振り返れる形で残したい: スライドでも妨害を内・外に分けて数えていますが、自分の場合は「なぜその時間に多かったのか」を後で読み返せないと、数字だけが残って解釈できなくなりそうでした

では、妨害をどうやって自動で数えるか。ここで振り返ってみると、自分が開発中に手を止める瞬間は、ほとんどが Slack を見に行くタイミングでした。通知に気づいて開くこともあれば、Claude Code にプロンプトを投げた後、待っている間に自然に開いているなんてこともあります。どちらも中断であることに変わりはありません。

そこで、妨害の数そのものではなく、Slack をアクティブにした回数を代わりに数えることにしました。これならアプリの切り替えを監視するだけで自動的に記録できますし、内/外の区別も、あとから時刻とメモを突き合わせれば読み解けます。この指標を選んだ理由は「なぜ Slack の起動回数なのか」で詳しく書きます。

この記事で書くこと

何を記録して、何が見えたのかを先に書きます。そのあとに、記録項目をどう選んだかという設計の話、最後に実装の要点を短くまとめます。

コードの詳細には踏み込みません。雑ではありますが一通り動くもの（Hammerspoon のスクリプト、Obsidian のテンプレート、週次まとめ用のスラッシュコマンド）は作ってみたので、気になる方は参考にしてみてください。導入手順は README にまとめてあります。

対象読者は、時間管理ツールを入れてみたが続かなかった人、自分の作業ログを自分で設計してみたい人です。

なお記録項目は、この記事のものをそのまま使うことを想定していません。理由は「この記事の記録項目は、そのまま真似しないでください」に書きました。

何を記録しているか

集中力を1つの数字で表そうとするとうまくいきません。「集中していた」は主観であり、主観だけを記録しても後から検証できないからです。

かといって、主観を捨てて自動で取れる数字だけにするのも違うと考えました。Slack を一度も開かなかった50分と、頭が回らないまま画面を眺めていた50分は、自動記録の上ではどちらも「中断ゼロ」です。その差を知っているのは自分だけで、主観の数字はそこを埋める唯一の情報になります。1on1で共有している10段階も、結局はこの主観値です。

逆に、主観の数字だけでは「なぜ今日は6だったのか」を説明できません。どちらが正しいかではなく、両方を並べて初めて読み解ける。そう考えて、性質の違う2種類の記録を別々に取り、あとで突き合わせる形にしました。

記録	取り方	何を表すか
Slack の起動回数	自動（Hammerspoon）	集中が途切れた回数。本人の申告が入らない客観値
ポモドーロ記録	手動（Obsidian）	どれだけ積み上げたか。タスク内容と、自分にしか付けられない主観値（集中度）、離席回数・スタンディング時間

保存先は Obsidian の Vault です。

FocusVisualization/
├── Slack/           # Hammerspoon が自動で書き込む
│   └── 2026/XX/slack_focus_log_2026-XX-XX.md
├── Pomodoro/2026/XX/2026-XX-XX.md            # 手で書く
└── Reports/2026/2026-WXX.md                  # 週次で突き合わせる

記録する場所（Slack / Pomodoro）と、読み解く場所（Reports）を分けているのがポイントです。記録の最中に解釈を書き始めると、その日の気分に引っ張られた結論が残ってしまいます。

自動で取る側: Slack の日別ログ

Hammerspoon が勝手に書きます。先頭の合計と時間帯別の表は、Slack を開くたびに自動で更新されます。

稼働時間が 10:00-19:00 なので、集計対象はこの範囲に限り、昼休みの 13:00-14:00 は除いています。範囲外のログ自体は残していて、集計から外れるだけです。

手で書く側: ポモドーロ記録

1日1ファイルで、集中した区切りごとに1行足します。ポモドーロと書いていますが、25分ではなく50分作業して5-10分ほど休憩するサイクルでやっています。自分の場合はこの長さがちょうど集中の切れ目に合いました。

1区切り終えたタイミングでその場で書きます。1行書くのに30秒もかかりません。

実際のある日の記録がこちらです。

見てのとおり、運用はかなり緩めです。

メモは雑でいい: 「離席は水入れ」「シンプルに疲れている感じ」程度の走り書きです。きれいに書こうとすると続かないですし、週次で読み返すときは、この雑な一言で十分その時の状態を思い出せます
半端な時間もそのまま1行にする: 基本は50分ですが、夕会前の10分のような区間も、無理に切り上げたり切り捨てたりせず1行として残しています
集中作業でない区切りは - を入れる: 夕会の準備やタスク整理のような区間は、集中度を付けても意味がないので - にして、週次の平均からは外しています。行ごと書かないのではなく「集中作業ではなかった」という記録として残します
タスク欄には実際の PR へのリンクなどを貼る: あとで「この集中度のときに何をしていたか」を辿れるようにするためです

突き合わせる側: 週次レポート

2つの記録は、単体ではほとんど何も言えません。「Slack を44回開いた」だけでは、多いのか少ないのか、悪いことなのかすら分かりません。そこで週に1本、並べた表を作ります。（モザイクで見にくくなっているのはご了承ください...）

日次のまとめは作りません。1日分では傾向が出ないためです。

いまの運用

日々やっているのは、実質この3つだけです。

ポモドーロを1区切り終えるごとに、表に1行足す: 集中度は考え込まずに直感で付けます。メモも思ったことをそのまま書くだけで、体裁は整えません
Slack 側は何もしない: 勝手に溜まります
週に1回、レポートを書く: 2つのフォルダから数字を拾って表に起こす作業は機械的なので、Claude Code のカスタムスラッシュコマンドにしました。対象週の決め方、どのファイルからどの数字を拾うか、読み解く順番を手順として書いておき、/週次まとめ で実行します

AI に任せる範囲

スラッシュコマンドで出力してもらうのは、サマリーの表と気づきの下書きまでです。仮説と「来週試すこと」は自分で決めます。ここまで任せると、自分の記録なのに他人事のレポートになるためです。

そして「来週試すこと」は必ず1つだけにしています。複数書くと、翌週にどれが効いたのか分からなくなります。

レポートを読む順番

レポートを読むときは、見る順番も決めています。

集中度: まず落ち込んでいる区間を探す。ここが起点
離席回数とスタンディング時間: その区間で体をどう扱っていたか。姿勢を変えていない、あるいは一度も立っていない、といった形で説明がつくことが多い
Slack の起動回数: その区間の中断が、自発か受動か
メモ: 最後に、その時間に何が起きていたかを読む

睡眠と場所はこの前に一度確認しますが、後述のとおり自分の場合ほとんど変動しないので、値が動いた日だけ見る扱いにしています。

順番を決めているのは、そうしないと目についた要因に飛びつくからです。集中度が低い区間を見つけると、つい「タスクが難しかったから」で片付けてしまいます。実際には単に何時間も座りっぱなしだった、というだけのこともあります。先に体の状態と中断回数という動かせる要因を確認して、最後にメモで文脈を戻す。この順番にしてから、翌週に試すことを決めやすくなりました。

実際に見えてきたこと

まだ3週間ほどですが、記録を並べて分かったことがあります。

先に断っておくと、以下の気づきの多くは手で書いたメモから出てきたものです。この仕組みの目的はあくまで Obsidian 上で集中力を可視化することで、Slack の起動回数は、そこに客観的な数字を1つ添えるために自動化した部分にすぎません。数字が「その日を読み返すきっかけ」になり、メモが解釈を与える、という役割分担になっています。

起動回数は「自発か受動か」で意味が変わる

これがいちばん大きな学びでした。そして、きっかけになったスライドで妨害を内・外に分けて数えていた理由が、記録を取ってみて初めて腑に落ちた部分でもあります。

同じ「Slack を10回開いた」でも、中身は2種類あります。

自発: 手が止まって見に行った、通知が気になった → 集中の問題。ポモドーロの区切り方や通知設定で対処する
受動: メンションされた、レビュー依頼が来た、ハドルに呼ばれた → 環境の問題。回数が多くても自分の集中力の評価を下げる必要はない

実際、ある日は12時台に11回の起動がありましたが、内訳は夕会の時間変更に関する連絡でした。回数だけ見れば集中できていない時間帯ですが、実態は違います。

自動計測で取れるのは回数までで、その回数の意味は手で補うしかない。ここは割り切って、多かった時間帯の理由をメモに残すようにしています。

眠気はスタンディングで解決することがある

集中度が6に落ちた区間で「いつもより若干眠気を感じる」と書いた日、後半にデスクを上げたところ持ち直しました。眠気を感じたら休憩を取るという対処しか持っていませんでしたが、姿勢を変えるだけで済む場合があると分かりました。

レビュー待ちの時間の使い方が効いている

PR を出してレビューを待つ間、不明点を質問したり次の実装を読んだりしている区間は、集中度が安定していました。逆に「待ち」として過ごした区間は落ちています。

これは記録を取る前には自覚していませんでした。振り返りに書いた一文が、次の週の仮説になっています。

この記事の記録項目は、そのまま真似しないでください

ここでいちばん伝えたいことを書いておきます。

ここまで挙げた記録項目に、厳密な根拠はありません。 何が集中に効くのかを事前に知っていたわけではなく、「たぶんこれは効くだろう」と思ったものを並べただけです。

なので、この記事の項目をそのままなぞるより、自分が変数として置きたいものを足していくほうが、ほぼ確実に有益です。

いま記録しているタスク内容・集中度・離席回数・スタンディング時間の4つも、「自分の場合はこのあたりが怪しい」と思って置いただけで、効く変数は人によって違うはずです。

実際、前日の睡眠時間と場所も一応記録していますが、こちらは思ったほど効いていません。自分の場合はどちらも日によってほとんど変動しないので、集中度と並べても差が出ず、変数として機能しないためです。ほとんど動かないものは、記録しても読み解く材料にならない。 これはやってみて分かったことでした。

また、最初は食事も記録していましたが、途中でやめました。「昼に〇〇を食べた」と書き残しても、量などが日によってばらばらで、集中度と並べたときに比較できる形になっていなかったためです。数値として置ける形を用意しないと、記録しても変数として使えません。普段から食生活を気にしていて、カロリー計算などをしている人はその情報をそのまま入力すればかなり良い判断材料になるかとは思います。

たとえば、思いつく範囲でもこれくらいの候補があります。

カフェインを摂った時刻と量
BGM の有無・種類
気温や湿度（在宅なら効いていそう）
その日のタスクの種類（実装 / 設計 / レビュー / 調査）
運動したかどうか
会議の本数

心当たりのある変数を1つ足すほうが、他人の項目を完璧に再現するより情報量が大きくなります。 逆に言えば、この記事を読んで「自分の場合は何が効いていそうか」を考えるところまでが本題です。

ただし、最初から項目を増やしすぎると記録が負担になって続きません。まずは自動で取れるものを1つと、手で書くものを1〜2個から始めて、足りないと感じたら足す。 これくらいが現実的だと思います。自分もスタンディング時間は後から追加しました。

後から集計できる形で書く

項目そのものより参考になるとすれば、こちらのルールのほうだと思います。

区間ごとに変わる値だけを列にする: 集中度・離席・スタンディングは区間ごとに変わるので列に置きます。前日の睡眠や場所は1日を通して同じ値なので、列にすると全行に同じ数字が並ぶだけです。表の外、ファイルの先頭に1行だけ置いています
数値の列に文章を混ぜない: 最初は集中度の欄に 7(後半スタンディングが良き) のように書いていました。あとで平均を出そうとすると、これが取り出せません。理由や補足はメモ列に回します
離席とスタンディングを分ける: 「デスクの前にいるかどうか」が離席、「その姿勢が座りか立ちか」がスタンディング。立ったまま作業した時間を離席に数えると、集中している区間ほど離席が多いという逆転が起きます

なぜ Slack の起動回数なのか

前提: 職種や役割によって意味が変わります

記録項目と同じく、ここも先に断っておきます。自動計測の対象として Slack を選んでいますが、これが誰にとっても妥当な指標かというと、そうではありません。

自分はインターン生で、基本的には割り当てられたタスクを実装する立場です。この場合、Slack を開くのは多くが自分の判断によるもので、「開いた＝作業から目を離した」とみなしてもそれほど無理がありません。

一方で、役職や職種によっては話が変わります。マネージャーのようにメンバーからの相談に即応する立場、カスタマーサポートや運用当番のように通知への反応そのものが業務である場合、あるいは障害対応中など、開き続けているのが正しい状況もあります。こうしたケースでこの指標をそのまま当てると、真面目に仕事をしている人ほど数字が悪く出るという逆転が起きます。

さらに、同じ人でもその日の作業によって前提は変わります。仕様の認識合わせが必要なタスクや、レビューを何度も往復するタスクでは、Slack を開く回数は必然的に増えます。回答待ちで作業がブロックされている時間も同じです。

これも先ほどの「自発か受動か」と同じで、メモで補うしかない部分です。「この区間はレビュー待ちで質問していた」と一行書いておけば、あとで数字を見たときにその区間を切り分けられます。そのうえで、実装に集中していたはずの区間で、起動回数がきちんと少なくなっているかを見る、という使い方です。

そのうえで、自分の働き方において「開いたら中断」と言い切れるアプリは何かを考えて選ぶのがいいと思います。人によっては X（Twitter）やブラウザのほうが適切かもしれません。監視対象はアプリ名の変数1つで指定しているので、そこを書き換えれば別のアプリに切り替えられます。

Slack を選んだ理由

集中の中断とほぼ1対1で対応する: エディタやブラウザは作業中も切り替えるので、切り替え回数がそのまま中断にはなりません。1つのアプリに絞っているのも意図的で、複数を監視すると、どの切り替えが中断でどれが作業の一部なのかが混ざります
主観が入らない: 集中度を自己申告すると、疲れている日は全体的に低く見積もるといった補正がかかります。起動回数はその補正を受けません。主観の記録と並べたときに、ずれ自体が情報になります
追加のツールを入れなくていい: すでに常時起動しているアプリなので、計測のために新しい習慣を作る必要がありません

なお、数えるのは「起動」ではなく「アクティベート」です。Slack は一度立ち上げると常駐するので、プロセスの起動回数を数えると1日1〜2回にしかなりません。数えるべきはフォアグラウンド化（activated）の回数です。

仕組みは、アプリの切り替えを監視しているだけ

自動計測に使っているのは Hammerspoon です。macOS を Lua で自動化するツールで、hs.application.watcher を使うとアプリのフォアグラウンド化を監視できます。

中核はこれだけです。Slack が前面に来たら、時刻を CSV と日別 Markdown に追記します。

appWatcher = hs.application.watcher.new(function(name, event, app)
  if name ~= "Slack" then return end
  if event == hs.application.watcher.activated then
    local now = os.time()
    if now - lastActivated > 2 then   -- 2秒以内の連続切り替えは除外
      log("activated")
      lastActivated = now
    end
  end
end)

appWatcher:start()

Cmd + Tab で行き来すると同じイベントが何度も飛ぶので、2秒以内は1回として扱っています。あとは、追記のたびにファイル先頭のサマリーを作り直しているだけです。

導入手順（Hammerspoon のインストールとアクセシビリティ権限）、設定できる項目、つまずいたときの切り分け、Windows で同じことをする場合の代替案は、簡潔にではありますが、リポジトリの README にまとめました。動かしてみたい方はそちらをご覧ください。

まとめ

作ってみて、設計上効いたと思うのは次の点です。項目や対象アプリは自分の環境に合わせて決めたものなので、そのまま真似する部分ではありません。参考になるとすれば、以下の考え方のほうだと思います。

客観値（自動）と主観値（手動）を分けて取る。片方だけでは検証できない
自動計測の対象は「開いたら中断」と言い切れるアプリを選ぶ。職種によってそれが何かは変わる
記録項目は最小から始めて、心当たりのある変数を1つずつ足す。この記事の項目をなぞる必要はない
記録する場所と、読み解く場所を分ける。記録中に解釈を書かない
数値の列に文章を混ぜない。集計できるかどうかが決まる
読み解く順番を固定する。目についた要因に飛びつかないため
「来週試すこと」は1つだけ

計測は目的ではなく、翌週に変える1つを決めるための手段です。指標を増やしすぎると記録自体が負担になり、続きません。自分の場合、自動で取れるものを1つ、手で書くものを最小限、というこの構成がちょうど良さそうです。

今後は、Slack の起動を自発・受動で自動的に分類できないか（メンション通知の有無との突き合わせなど）を試したいと考えています。

参考

Hammerspoon 公式ドキュメント — hs.application.watcher を使っています