ハイノDiary

プログラミングのことや読書記録、日々の日記などを書いていきます。

「できない」を「まだできていない」に思考を変える

何かに挑戦してうまくいかないとき、「できない」と考えてしまうと行動が始まらない。

英語が話せない。コードが書けない。運動を習慣にできない。

「できない」は現在の状態を表しているようで、未来まで決めてしまいやすい。「今はできていない」ではなく、「自分にはその能力がない」と結論づけてしまうからかもしれない。

そこで、「できない」を「まだできていない」と言い換えてみる。

たった二文字を加えるだけだが、「まだ」という言葉ができないから、やってみようという方向へ向けることができるかもしれない。

能力ではなく、現在地として考える

日常で使う「できない」の多くは、本当に不可能なのではない。

  • 方法を知らない
  • 練習量が足りない
  • 必要な時間や環境を用意できていない
  • 一度試して、うまくいかなかった

こうした状態を、まとめて「できない」と呼んでいることが多い。

「アプリを作れない」ではなく、「一人でアプリを完成させるところまでは、まだできていない」。「運動を続けられない」ではなく、「無理なく続けられる仕組みを、まだ作れていない」。

この言い換えは、無理に「自分ならできる」と信じ込むものではない。できていない事実は認めながら、それを最終結論にしないためのものだ。

次の行動まで決める

ただ言い換えるだけでは、状況は変わらない。「まだ」を先延ばしの言い訳にしないために、次の三つを考える。

  1. 何ができていないのか、具体的にする
  2. 知識・経験・時間・環境など、足りないものを一つ選ぶ
  3. 次の一回で試す小さな行動を決める

記事を書き上げられていないなら、「文章力がない」と決める前に、まず見出しを三つ作る。会議で発言できていないなら、次回は伝えたいことを一文だけ準備する。

問題を能力ではなく工程として見れば、次に試せることが見つかる。

おわりに

もちろん、すべてをできるようになる必要はない。今は優先しないことや、やらないと決めることも大切だ。

「まだできていない」は、自分を追い込むための言葉ではない。挑戦したいことを、早すぎる自己否定で手放さないための言葉だ。

「できない」は結論になる。

「まだできていない」は、次の行動につなげる。

インターネットは「便利な技術」を飛び越えて「文明」になっている

はじめに

『インターネット文明』を読んでいて、いちばん印象に残ったのは、インターネットを単なる便利な道具ではなく、文明 として捉える視点でした。

普段の生活では、ネットは「あって当たり前」のインフラです。

検索する。連絡する。動画を見る。買い物をする。仕事をする。学ぶ。移動する。何をするにしても、どこかでインターネットにつながっています。

でも、あまりに当たり前すぎて、それが社会の土台そのものを書き換えた存在だとは意識しにくい。

この本を読んで、インターネットは技術の一分野というより、社会の前提を丸ごと変えてしまった文明なのだと改めて感じました。

インターネットは「道具」ではなく「前提」になった

昔はインターネットがなくても社会は成立していました。

けれど今は、ネット接続が切れると仕事も連絡も情報収集も止まりやすい。止まって初めて、どれだけ依存しているかが見えます。

これは便利なツールに依存しているというより、社会の基盤そのものがインターネット前提で組み直された ということだと思います。

道路や電気や水道と同じように、普段は意識しないが、なくなると困る。

しかもインターネットの特徴は、単なる生活インフラにとどまらず、言語、文化、経済、教育、研究、行政、安全保障まで横断して影響することです。

そう考えると、「文明」という言葉は大げさではなく、かなり正確な表現に思えます。

技術が広がるかどうかは、性能より「自分事になるか」

この本でもう一つ強く残ったのは、技術が広がるときの本当の壁は、技術的に可能かどうかではなく、人がそれを自分事として使う状況になるか だという話です。

これはかなり重要な視点でした。

ビデオ会議、ネット通販、動画配信のようなものは、COVID-19 以前からすでに存在していました。

でも、パンデミックによって「使わざるを得ない状況」が生まれたことで、一気に社会の標準になった。

つまり、技術は存在していただけでは広がらない。便利さが個人の生活や仕事に接続されたときに、はじめて本格的に浸透する。

新しい技術を見るとき、つい「すごいかどうか」「先進的かどうか」で見てしまいがちですが、本当に重要なのは「誰のどんな状況で、自分事になるのか」なのだと思いました。

日本は「周回遅れの先頭ランナー」でいい

個人的にかなり刺さったのは、日本の立ち位置についての話です。

最先端を独走する国や企業がある一方で、日本は必ずしもそういうタイプではない。

でもそれは、単純に劣っているという話ではないはずです。

本の中では、日本の持ち味を 周回遅れの先頭ランナー と表現していて、これはかなりしっくりきました。

誰よりも最初に飛び込んで市場を切り開くのは苦手でも、多くの人が使える形に整えたり、品質を高めたり、置き去りを減らしながら広げたりするのは得意かもしれない。

この視点は、技術だけでなく、仕事やキャリアの考え方にもつながる気がします。

常に最先端を取れなくてもいい。

むしろ、ボリュームゾーンが安心して使えるところまで落とし込む役割は大きい。日本のインターネット普及や日本語処理、多言語化への貢献も、そういう文脈で見るとかなり重要です。

インターネットは多様性を消すのではなく、支える基盤でもある

グローバル化というと、文化や言語が均一化されるイメージを持ちやすいです。

でも本書で面白かったのは、インターネットはむしろ各言語をそのまま扱えるようにすることで、多様性を保ったまま接続を可能にした、という視点でした。

日本語が表示できること、日本語入力ができること、ブラウザで各言語を扱えること。

こうした基盤整備は地味ですが、文明としてはかなり本質的です。

自分の言葉で読み書きできないインフラは、結局は一部の人のものにしかならない。

インターネットが世界に広がった背景には、単に回線や端末が普及しただけでなく、多言語対応のような「使える状態にする努力」が積み重なっていたのだとわかります。

これからは経済だけでなく「人・社会・環境」で見る必要がある

インターネットはこれまで、経済成長と強く結びついた存在として語られてきました。

実際、それは間違っていません。

ただ、パンデミック以降は少し見方が変わったように思います。

物流や人の移動が止まっても、情報の流れは止まらなかった。その経験を経て、インターネットの価値は単なる経済効率だけでは測れなくなった。

人の命にどう寄与するか。 社会の維持にどう役立つか。 環境や地球規模課題にどう向き合うか。

こういう軸で評価される段階に入ってきているのだと思います。

これはAIやデータ活用を考えるときにも、そのまま重なる視点です。便利かどうか、儲かるかどうかだけでなく、それが社会の基盤としてどう機能するのかまで見ないといけない。

読んでいて自分が考えたこと

この本を読んで、自分の中では「技術の話」と「社会の話」を分けすぎない方がいいのだと感じました。

インターネットはプロトコルや回線や端末の話だけでは終わらないし、逆に社会制度や文化だけで語っても足りない。

技術と社会が一体になって初めて、文明という言葉が成立する。

そして、その文明の上で自分たちは日々仕事をして、学んで、発信している。

そう考えると、いま触れているAIも、おそらく同じような位置に向かっているのかもしれません。

まだ「便利なツール」として見ている人も多いけれど、気づいたら社会の前提そのものを書き換えている。インターネットを文明として見る視点は、その次に来るものを考えるための補助線にもなる気がしました。

おわりに

『インターネット文明』は、インターネットの歴史や技術を知る本というより、インターネットが人間社会にとって何になったのか を考える本でした。

便利だから使う、ではなく、すでに前提になっているからこそ、どう向き合うかを考える必要がある。

個人的には、「文明」として捉える視点と、「日本は周回遅れの先頭ランナーでいい」という見方が特に印象に残りました。

最先端だけを追うのではなく、多くの人が使える形で広げることにも価値がある。

その感覚は、インターネットだけでなく、これからの技術全般を考える上でもかなり大事な気がしています。

没頭できる何かが欲しい

はじめに

どうも、ハイノです。

毎日を惰性で過ごしている気がする。大きな不満があるわけではないけれど、「今日はやり切った」と思える感覚もない。そんな中途半端な状態になることがあります。

こういうときに欲しくなるのが、寝食を忘れて没頭できる何かです。集中している間だけでも、何も積み上がっていないような感覚から離れられる気がするからです。

ざっくり言えば「趣味を作ればいい」という話なのかもしれません。ただ、いざ没頭できるものを探そうとすると、そこにいろいろな意味を詰め込みたくなってしまいます。

たとえばゲームに没頭すればいいはずなのに、「配信したら収益になるのでは」とか「どうせやるなら何か成果にしたい」と考えてしまう。そんなに簡単な話ではないとわかっていても、そういう考えが頭をかすめると、目の前の楽しさに集中しきれなくなります。

結果として、受動的な娯楽に流れてしまう。動画を見たり、SNSを眺めたりして、「とりあえず今日はこれでいいか」と時間だけが過ぎていく。

そんな自分を少し変えたいと思うことがあります。

どうすればいい?

没頭する対象が何でもいいのであれば、仕事に没頭するのが一番わかりやすい解決策かもしれません。平日は少なくともかなりの時間を仕事に使っているので、そこに没頭できれば生活全体の充実感も上がりやすいはずです。

ただ、それが簡単ではないのもわかります。好きか嫌いか、得意か不得意かによって、仕事に向かう感情は大きく変わります。頭では「仕事なんだから感情に左右されずにやればいい」と思っていても、感情がついてこないことはあります。

理屈では動けても、気持ちまで同じ方向を向いてくれるとは限らない。ここが難しいところです。

受動的コンテンツも没頭ではある

受動的なコンテンツも、ある意味では没頭している状態だと思います。時間を忘れて動画を見続けてしまうのは、それだけ意識が向いているということでもあります。

ただ、ふと我に返ったときに「自分は今まで何をしていたんだろう」という気分になりやすい。何も残っていない感覚があり、喪失感も大きい。しかも睡眠時間が削られたり、生活リズムが崩れたりするので、後味があまり良くありません。

強いて言えば、いつか使える知識や視点が少しずつ溜まることはあるかもしれません。それでも、自分で選んで前に進んでいる感覚とは少し違います。

結局どうしよう

では、没頭するにはどうすればいいのか。

今のところは、興味のあることを小さく分割して、すぐ手をつけられる状態にしておくのが現実的なのかなと思っています。大きな趣味や人生を変えるような対象をいきなり探すのではなく、「少し気になること」を細かく並べて、触れ続けられる環境を作る。

本を読むなら1章だけ読む。ゲームをするなら1つの目標だけ決める。記事を書くなら見出しだけ作る。そうやって小さく始めることで、結果的に集中している時間を増やせるのではないかと思います。

この考え自体は、たしかホリエモンの本で読んだ内容に近い気がします。興味のあるものを細切れにして、次々と手を出せる状態にする。完璧な没頭を待つより、そのほうが現実的なのかもしれません。

結論

没頭できる何かは、いきなり見つかるものではないのかもしれません。

だからまずは、目的に沿って物事を小さく分割し、興味が切れないうちに触れ続けられる状態を作る。そうすることで、擬似的にでも没頭している時間を増やせるのではないでしょうか。

もちろん、それを続けること自体も簡単ではありません。それでも、惰性で時間を消費してしまうよりは、少しだけ納得できる過ごし方になる気がします。

AIに出力させる前に、まず10分で作る。爆速プロトタイピング

はじめに

今回は下記の研究会に参加して学んだ内容を自分の備忘録を兼ねて書いていきます。

(増枠)シリコンバレー事業開発者が語る AIに出力させる前にやってほしい爆速プロトタイピングのすゝめ - connpass

AIが普及してから、「まずAIに出力させてみる」という動きはかなり一般的になりました。文章、コード、デザイン、調査メモまで、以前よりずっと速く形にできるようになったのは間違いありません。

ただその一方で、実際には別の詰まり方をよくあります。AIに何を出力させればよいのかが曖昧なままで、プロンプトだけを何度も調整してしまう状態です。 何を作りたいのか、何を検証したいのかが固まっていないと、AIの出力速度が上がっても前に進みにくい。今回の研究会では、その停滞を破る鍵として「爆速プロトタイピング」が強調されていました。

印象的だったのは、AIがある時代だからこそ、むしろ人間が先に小さく作って試すことの価値が上がっている、という視点です。完成品を目指す前に、まず10分で触れるものを作る。この考え方は、AI活用の前提としてかなり重要だと感じました。

AI時代でも、最初と最後は人間の仕事

講演の中で特に納得感があったのは、AIは途中工程を大きく省略できる一方で、最初と最後は人間の役割として残る、という話でした。

ここでいう最初とは、「何を問いにするのか」「何を確かめたいのか」を定めることです。最後とは、「その体験が本当に成立しているか」「相手にどう受け取られるか」を見届けることです。AIは中間の生成や整理、展開は得意ですが、問いそのものの切れ味や、体験としての違和感までは自動で保証してくれません。

だからこそ、AIに出力させる前に、人間がある程度ラフでもいいので形を持った仮説を作る必要があります。全部を頭の中で詰め切ってから指示するのではなく、まずは雑でもいいから試せる単位に落とす。その一手があるだけで、AIの出力も現実に接続しやすくなります。

爆速プロトタイピングは「学ぶため」にある

爆速プロトタイピングという言葉だけ聞くと、「とにかく速く作る技術」の話に見えるかもしれません。しかし、今回の話の本質はスピード自体ではなく、学習の速さにありました。

プロトタイプの目的は、正解を一発で当てることではありません。仮説を早く試し、ズレを見つけ、学びを得ることです。その意味で、プロトタイプは失敗しないためのものではなく、失敗を学びに変えるための仕組みだと言えます。

登壇者の話でも、失敗というより学びとして回数を重ねる姿勢が繰り返し語られていました。日本ではまだ失敗に厳しい空気が残っている一方で、シリコンバレー的な実践では、未完成なものを早く出して検証することが前提になっている。その差はかなり大きいと思います。

考え込みすぎるより、まず作ってみる。しかも数週間ではなく、10分から1日で作る。この時間感覚の違いが、そのまま学習速度の違いになります。

「失敗ではなく学びを得た」と考えると聞いてエジソンの下記名言を思い出しました笑 『私は失敗したことがない。ただ、1万通りのうまくいかない方法を発見しただけだ』

雑でも触れるものがあると、議論の質が変わる

講演では、紙、段ボール、粘土、Googleスライドなどを使ったラフな試作の話が出ていました。ここで重要なのは、技術的にきれいに作ることではなく、相手が触れて反応できることです。

企画だけを言葉で説明すると、人によって頭の中のイメージがずれます。提案者は見えているつもりでも、聞き手は別のものを想像していることが多い。一方で、たとえ雑でもプロトタイプがあると、会話の前提が揃います。どこがよくて、どこが違和感なのかを具体的に話せるようになります。

ベンダーや開発会社に依頼する前に、提案者自身が簡単な試作を持っていることの意味もここにあります。丸投げではなく、仮説を見える形で持ち込めるので、会話の精度が一気に上がるわけです。AIの登場で、このハードルはさらに下がりました。以前なら作れなかった人でも、今はスライドやノーコード、生成AIを使って最低限の体験を用意しやすくなっています。

Googleグラス初期プロトタイプの話が象徴的だった

今回の研究会で特に印象に残ったのは、Googleグラスの初期プロトタイプの話でした。最初期の試作は、ほぼ工作レベルのものを1日で作ったそうです。

この話が示しているのは、優れたプロトタイプとは洗練された試作品のことではない、という点です。大切なのは完成度ではなく、「この未来を一度体験してもらえるかどうか」です。見た目が粗くても、体験の核が伝われば検証は進みます。

むしろ、早い段階で過剰に作り込むと、引き返しにくくなります。時間もコストもかけた分だけ、「この方向で正しかったことにしたい」という心理が働きやすくなるからです。だからこそ、最初は工作レベルでいい。未来の輪郭だけを、最短距離で触れる形にする。この感覚はかなり重要だと思いました。

ちなみにGoogleグラスのプロトタイプがこちら、これを見た時はこのレベルでいいんだと思いました。

テストで説明しすぎないことにも意味がある

プロトタイプを作った後のサイクルとして、講演では「考える → プロトタイプ → テスト → 改善 → 再テスト → マーケティング」という流れが紹介されていました。この中でも特に大事だと感じたのが、テスト時に説明しすぎないという話です。

作り手はどうしても「ここを見てほしい」「こう使ってほしい」と言いたくなります。しかし、それを補足しすぎると、本来の使いにくさや伝わりにくさが見えなくなります。ユーザーには、どこで誰がどう使うものかという最低限の文脈だけ渡して、あとは自然な動きを観察する。その方が、実際の体験に近い学びが取れます。

もし思った通りに使ってもらえなかったなら、それはユーザーが悪いのではなく、デザインや導線に改善余地があるということです。この視点を持てるかどうかで、プロトタイプの価値はかなり変わります。

10分で作る制約が、本当に必要な機能を浮かび上がらせる

個人的に実践しやすいと感じたのは、「10分で作る」という制約の考え方です。時間が十分にある前提だと、人はすぐに機能を足したくなります。あれも必要、これも必要と発想が広がっていき、結果として何が本質なのかがぼやけていきます。

一方で、10分しかないとしたら、本当に必要な要素しか残せません。ユーザーに何を体験してほしいのか。どの一機能だけ見せれば仮説を検証できるのか。その問いに自然と向き合うことになります。

この制約は、単に作業時間を短縮するためのテクニックではなく、アイデアの輪郭を鋭くするための方法でもあります。AIに依頼するときも同じで、まず10分で作れる単位まで削ると、指示の解像度が上がり、出力の質も上げやすくなるはずです。

企画書中心の進め方との対比

講演では、大企業では企画書を出してから新規性や収益性を問われ、進むまでに長い時間がかかる、という話も出ていました。もちろん大きな組織では一定の確認プロセスは必要ですが、初期仮説の段階でそれをやりすぎると、学びの速度が落ちます。

企画書だけでは、結局は言葉の解像度でしか判断できません。けれど、簡単な試作品があると、議論は一気に具体的になります。「それは伝わらない」「ここは面白い」「この使い方なら刺さるかもしれない」といった反応が出やすくなるからです。

爆速プロトタイピングは、単に開発を速くする方法ではなく、意思決定の材料を早く集める方法でもあります。議論のための議論を減らし、実物ベースで対話するための手段としてかなり有効だと感じました。

AI時代の競争力は、出力速度より学習速度にある

今回の研究会を通じて強く残ったのは、AI活用の本質は「たくさん出力させること」ではない、という点です。出力のスピードは確かに重要ですが、それ以上に大きいのは、どれだけ早く学びを得られるかです。

AIは途中工程を一気に圧縮してくれます。だからこそ人間側には、問いを立てること、体験を設計すること、反応を観察することがより強く求められます。ここを曖昧なままにして出力だけ増やしても、結局は遠回りになりやすい。

雑でもいいから小さく作る。触ってもらう。反応を見る。直す。この循環を速く回せる人ほど、AIをうまく使えるのだと思います。競争力は、単なる生成速度ではなく、学習速度の差として現れるのではないでしょうか。

おわりに

AIを使いこなすことは、上手なプロンプトを書くことだけではありません。その前に、自分が何を試したいのかを小さく形にし、他者に触れてもらい、そこから学ぶことが重要です。

今回の話を聞いて、AI時代こそ「まず10分で作る」という姿勢が効いてくると改めて感じました。完成度を上げる前に、まず体験の核を作る。説明を増やす前に、まず反応を見る。この順番を守るだけでも、ものづくりや事業開発の進み方はかなり変わるはずです。

自分自身も、考え過ぎて止まるくらいなら、紙でもスライドでもAIでも使って、まずは小さく作ってみるところから始めたいと思います。

GitLab式ドキュメント運用を個人に移植する。いつでも参照できるハンドブック

はじめに

「必要なときに、必要な情報にすぐ辿り着ける状態を作りたい」。
この課題意識から『GitLabに学ぶ パフォーマンスを最大化させるドキュメンテーション技術』を読んだ。 読後の学びは、ノートを増やすことではなく、判断の基準を1か所に集約した「運用型ハンドブック」を作ることの重要性だった。

今回読んだ書籍

『GitLabに学ぶ パフォーマンスを最大化させるドキュメンテーション技術 数千ページにもわたるハンドブックを活用したテキストコミュニケーションの作法』 amzn.to

今回の学び

  1. ハンドブックは「知識の保管庫」ではなく「意思決定の基盤」
  2. SSoTを作ると、探す時間と手戻りが減る
  3. 完璧な文書より、更新される文書が強い
  4. 伝わるドキュメントは、書き手ではなく読者で設計する
  5. 目標は「きれいなノート」ではなく「迷わない状態」

1. ハンドブックは「知識の保管庫」ではなく「意思決定の基盤」

印象的だったのは、「かすれた鉛筆は鮮明な記憶に勝る」という考え方。
覚えているかどうかに依存すると、判断の品質が不安定になる。
だからこそ、個人でも「迷ったらここを見る」という参照先を決める必要がある。

2. SSoTを作ると、探す時間と手戻りが減る

情報が複数箇所に散ると、検索コストと認識ずれが増える。
GitLabの学びを個人に置き換えるなら、次の3点が核になる。

  • 公式情報は1か所に集約する
  • 同じ内容の重複ページを作らない
  • 更新責任を決め、古い情報を放置しない

「どこが正なのか」を決めるだけで、日々の判断がかなり速くなる。

3. 完璧な文書より、更新される文書が強い

「すべては下書き」という原則は、個人運用でも効く。
完成度を待って公開を遅らせるより、短く出して改善するほうが知識は育つ。
重要なのは初稿の出来より、更新の回転率。

4. 伝わるドキュメントは、書き手ではなく読者で設計する

未来の自分は、今の自分ほど文脈を覚えていない。
その前提で、次を徹底する。

  • 対象読者(未来の自分 / チーム)を先に決める
  • ファクトとオピニオンを分ける
  • SDS(Summary → Details → Summary)で要点先出しにする
  • 検索される語をタイトルに入れる

これだけで、再利用性が大きく上がる。

5. 目標は「きれいなノート」ではなく「迷わない状態」

ドキュメント作成の評価軸は作業量ではなく影響。
個人なら「どれだけ書いたか」より「どれだけ早く決められたか」で測る。
私にとってのハンドブックは、知識の棚ではなく、行動を決めるためのインフラに変わった。

学びからの実践

  1. まず「正本ノート」を1つ決める(SSoT化)。
  2. 迷いが発生しやすいテーマから、短い下書きを作る。
  3. 1ノート1テーマで、ファクトとオピニオンを分離して書く。
  4. 週1回、重複・古い記述・曖昧表現を見直す。
  5. 「参照して意思決定が速くなったか」を毎週振り返る。

まとめ

この本から得た最大の学びは、ドキュメントを「残すもの」ではなく「回すもの」として扱うこと。
いつでもどこでも参照できる自分用ハンドブックを作る鍵は、SSoT・継続更新・読者起点の3点にある。
まずは完璧を目指さず、下書きを公開し、更新し続けるところから始める。

なにかを書こうと思うけど何も書けない

アウトプットしたいのに、考えるだけで立ち消えることが続いた。インプット不足だと思って量を増やしたこともあるが、薄まった情報が溜まるだけで活かせず、知識欲を満たす以上にはならなかったです。

AIとの壁打ちで「完璧性を求めすぎているのでは」と指摘され、含蓄のある記事を書こうと意気込んではお蔵入りさせるパターンを繰り返していると言われてハッとしましたね。

打開策として、雑記としてラフに書き出す。思いついたときに3行でも出し、世に出す前の自己検閲を減らし、まず書いてから整える。日々のネタ探しやインプットの質向上は副次効果と捉え、目的は「雑でも形にする」ことに置く。

雑に書いて言語化の筋力をつけ、そこから方向性を見出していくという形で行こうと思う今日この頃です。

中途半端に残っているタスクは無駄にリソースを削ぐ

「あとでやる」を積み上げるほど、知らないうちに集中力が削られる。この記事では、頭を軽くしつつ、やり残しを減らすシンプルな回し方をまとめる。

今回の結論を3行で

  • 未完のタスクが増えるほど注意資源が削がれる
  • 2〜3分で終わることはその場で処理する
  • 残す場合は「忘れる前提」の仕組みを持つ

なぜ中途半端がリソースを奪うのか

タスクは完了するまで脳内で「開いたタブ」のように居座る。未完了が増えるほど切り替えに負荷がかかり、判断力まで落ちる。

  • 未完了のタスクはゼイガルニック効果で頭に残り、注意が分散する
  • 「あとでやる」が積み上がるほどメモリを圧迫し、重要な判断が鈍る
  • 手を付けないままのタスクほど、再開時の「思い出しコスト」が大きい

※ゼイガルニック効果 = 完了したことよりも中断・未達成のことを強く記憶しやすい現象

すぐ終わるものはその場で潰す

思考の切り替えや再開のコストを考えると、短時間で終わるものは「今やる」が最適。後回しにしても得をしない。

  • 目安は「2〜3分以内に終わるなら即処理」
  • 即処理の対象例: 簡単な返信、日程の確定、ファイル名変更、コピー提出など
  • やらない場合でも、必要なものと手順をメモしてから離れる(再開準備を済ませる)

忘れるための仕組みを持つ

全てを覚えておこうとしない。記憶の代わりに「外部脳」を持ち、安心して忘れられる状態を作る。

  • 頭に残さず「外部脳」に投げる。受け皿(Inbox)は1つに固定する
  • 期限はカレンダー、作業はタスクリストへ振り分ける
  • 止まった理由と「次の1アクション」をセットで書き、再開コストを最小化
  • 日次・週次で見直し時間を取り、期限切れや不要タスクを遠慮なく捨てる

個人的には、日々のこまごました用事は Obsidian のデイリーノートに投げ込み、中長期タスクは別のタスク管理アプリで管理するようにしている。

実践フォーマット

「受け皿を1つ決めて、定期的に捨てる」を軸に回す。

  1. 受信箱にすべて放り込む(メモ、メール、チャットの「あとでやる」)
  2. 2〜3分で終わるものは即処理
  3. それ以外は「期限」「次の1アクション」を書いてリスト化
  4. 日次で5分、週次で15分の整理タイムを確保し、不要なものを捨てる

まとめのチェックリスト

  • 受け皿を1つ決めているか
  • 2〜3分即処理ルールを守っているか
  • タスクごとに「次の1アクション」を書いているか
  • 定期レビューで溜まった中途半端を捨てているか

おわりに

やり残しをゼロにする必要はないが、「覚えておかないと不安」な状態は避けたい。受け皿を固定し、短時間で処理し、定期的に捨てる。この3つを続けるだけで、脳のリソースを本当に使いたいことに回せる。