ADHDエンジニアの通知管理実践ガイド｜集中を守り重要を逃さない設定法

通知をすべてオフにすれば集中できる——そう考えて試したことがある人も多いはずです。短期的には効果がありますが、全オフは万能の解決策ではありません。ADHDエンジニアにとって最も実用的な選択肢は、重要な通知だけを受け取り、残りをまとめて処理するハイブリッド戦略です。

この記事では、実際の失敗経験をもとに、通知設定の判断基準・戦略比較・実践手順・効果測定の方法を順に解説します。

なぜ全オフをやめたか：失敗から学んだこと

かつて私は通知をほぼすべてオフにしてコーディング時間を守っていました。最初はコンテキストスイッチが減り、バグ修正や設計作業に深く集中できるようになりました。

しかし実際に起きた失敗は3つあります。

• ある朝、CIの致命的なビルド失敗に気づかないままリリースを進め、チームに大きな迷惑をかけた
• 夜間の自動デプロイ失敗を受け取れず、問題の発覚が翌日になり手戻りが発生した
• プルリクエストで「緊急修正」を要求するコメントを全オフ中に見逃し、重大な欠陥を含んだままリリースしてしまった

このとき実感したのは「一律オフは短期的な救済に過ぎず、運用上のリスクを抱える」という事実です。通知への反応はADHD傾向と密接に関わっているため、設定戦略は個人特性と職務要件の両面から設計する必要があります。

通知を絞ることの4つのメリット

通知を重要なものだけに絞ることで、以下の効果が期待できます。

• 集中時間の確保：コンテキストスイッチが減り、バグ修正・設計作業・深いデバッグの質が向上する
• 精神的負荷の軽減：刺激の過多を抑え、燃え尽き・過負荷状態を回避しやすくなる
• 決断疲れの軽減：「この通知に今すぐ反応すべきか」という小さな判断を繰り返す必要がなくなる
• ルーティン化の促進：「決めた時間にまとめて確認する」習慣が身につきやすい

Slackで@hereや@channelが頻繁に飛んでくる環境では、重要なもの以外をフィルタリングするだけで体感の作業品質が変わります。

通知を切りすぎることの3つのリスク

メリットと表裏一体のリスクも、戦略を選ぶ前に把握しておく必要があります。

• 重要アラートの見落とし：CI失敗・本番障害・緊急PRコメントを見逃すと、チームへの影響が大きくなる
• 対応遅延による信用低下：顧客やチームメンバーからの急ぎの連絡に気づかないまま放置する形になりかねない
• 事後の自己否定感：重大な問題が後から発覚したときの心理的ダメージが大きくなりやすい

「完全オフ」を長期運用するリスクは、一時的な集中効果では補えません。上述の失敗事例がその現実を示しています。

3つの通知戦略を比較する

主な通知戦略は「完全オフ」「重要のみ」「時間帯バッチング」の3種類です。役割と業務特性に合わせて選択してください。

戦略を選ぶ3つの判断軸

1. チームのレスポンスSLA：返信や対応の期待時間が短いほど、完全オフは避けるべき
2. 業務の緊急度・重要度：本番運用やオンコール業務がある場合は「重要のみ」が基本
3. 自己管理の得意・不得意：バッチ確認のルーティンを守れる自信がなければ設定はシンプルに保つ

なお、オンコールや即時対応が求められる役割（SRE・インフラ担当など）では、「完全オフ」や「バッチ確認メイン」の運用は避けるべきです。少人数チームで情報伝達の遅延が致命的なプロジェクトや、通知チェックのルーティン自体が続けにくい場合も同様です。ただし「重要のみON」の変形として本ハイブリッド戦略は、役割に応じた重要度定義を変えることで幅広く適用できます。

設定を始める4ステップ

大きく変えるのではなく、小さく始めて1〜2週間かけて調整することを前提にした手順です。

ステップ1：通知源を一覧化する（1日目）

Slack・メール・CI・監視ツールなど、現在通知が来るすべての発生源を書き出します。下記のワークシートをそのまま使って整理してください。

ステップ2：重要・非重要を分類する（2日目）

判別基準は「業務への即時影響」と「対応のSLA」です。以下の2問に両方「はい」と答えられる通知を「重要」に分類します。

1. 対応が4時間以内に求められるか？
2. 見逃した場合にチームや本番環境に影響が出るか？

どちらか一方でも「いいえ」であれば、バッチ確認に回して問題ありません。迷う場合は「4時間ルール」を優先してください。

ステップ3：通知設定を変更する（3日目）

重要な通知のみON、それ以外はサイレントまたはバッジのみに変更します。主要ツールでの操作例は以下のとおりです。

Slackの設定

• 「環境設定」→「通知」で「ダイレクトメッセージと@メンション」のみ通知をオンにする
• 重要チャンネル（例：#incidents、#deploy）は個別に「すべての新規メッセージ」に設定する
• 「おやすみモード」を集中作業の時間帯（例：10:00〜12:30）に設定し、DMのみ例外許可にする

GitHub / GitLabの設定

• 「Settings」→「Notifications」で「Participating」のみメール通知をオンにする
• 自分がレビュアーに指定されたPRは「Watching」に設定し、メンション通知を有効にする

CI/CDアラートの設定（GitHub Actions・CircleCIなど）

• 失敗時のみSlackに通知するようWebhookを設定する
• 成功通知はバッチ確認用チャンネルに集約するか、メールのみにする

ステップ4：評価と調整（1〜2週間後）

次のチェックリストで効果を確認し、見逃しが発生した通知の種類だけ設定を復活させます。大幅な変更は避け、1項目ずつ調整するのが原則です。

• □ 見逃した重要なアラートはあったか
• □ 作業中の中断回数は体感として減ったか
• □ チームやマネージャーから対応遅延の指摘はなかったか
• □ 通知確認のルーティン（昼・夕のバッチ確認）を継続できているか

チェックで問題が見つかった項目だけ設定を戻し、残りはそのまま継続してください。1〜2週間ごとに同じチェックを繰り返すことで、自分に合った設定に収束していきます。

まとめ：今日、重要の定義を3分で決める

通知設定の最適解は「職務の要求」と「自分の特性」のバランスで決まります。全オフは一時的な集中強化には使えますが、長期運用には向きません。

多くのエンジニアには、重要通知のみON＋定期バッチ確認のハイブリッド戦略が現実的で安全な出発点です。

よくある質問（FAQ）

Q. 完全オフは短期的に効果がありますか？

短期的には集中力が高まる効果があります。ただし重要なアラートを見逃すリスクが伴うため、短期実験以外での長期運用は推奨しません。

Q. 「重要な通知」の判別基準を教えてください。

「業務への即時影響」と「対応のSLA」で判断します。「対応が4時間以内に求められるか」「見逃した場合に本番やチームへの影響があるか」の2問に両方はいと答えられる通知が重要です。ステップ2の基準をそのまま使えます。

Q. ADHDで通知管理が続かない場合はどうすればいいですか？

続かない主な原因は「設定が複雑すぎること」です。ステップ1〜4を小さく始めることが先決です。加えて、カレンダーへのルーティン固定（昼・夕の2回のバッチ確認をブロック）、通知ルールのテンプレート化（上記ワークシートをそのまま使う）、チームとの代替連絡手段の合意（緊急時はDM・電話可など）の3点を組み合わせると継続しやすくなります。

Q. オンコール業務と両立するにはどうすればいいですか？

オンコール日は必要なチャネルの通知を受け取り、それ以外はミュートにします。PagerDutyやOpsGenieなどのインシデント管理ツールを使うと、通常のSlack通知と本番アラートを明確に分離できます。

Q. チーム全体に通知ポリシーを広げるコツはありますか？

個人の実験結果を簡潔にまとめ、期待するレスポンス時間と緊急連絡手段をセットで提示すると導入しやすくなります。「緊急はDM・通常はバッチ確認OK」のようにシンプルな合意を先に作ることが前提です