メールはもはや前時代的なコミュニケーションツールですが、依然として主要な手段の一つではあります。
そこにビジネスチャンスを見出す製品もいくつか見られ、新しい仕分け方を開拓し始めています。
どんな仕分け方――つまりは仕分けの戦略があるかを紹介します。
Heyというメーラーがあります。
解説として以下記事が詳しそうです。
https://neue.cc/2021/12/31.html
今までメール一ヶ月放置は当たり前、未読1万件、みたいな状態だったのですが、After Heyでは未読0。すごい。メーラー変えただけでこんな変わるとは。よく出来たツールは人を変えるね。
**
Heyが採用する戦略を、当サイトではSCIと呼んでいます。
メールを以下に三分するものです。
SpamとInformationの扱いを強化することでメールの物量を減らし、またCommunicationの扱いもカスタマイズすることで、より本質に集中できるようにします。
以下詳細を見ます。
Spam（スパム）は、問答無用で無視する・削除するメールです。すでにGmailなど既存のメーラーもスパム判定機能を持っていますし、必要なら自前でフィルタをつくることもできます。
HeyではScreenerという機能があって、「この人からは一切受け取らない」を定義できます。
Communication（コミュニケーション）は、やりとりが必要なメールです。従来のメールでは、ここが多すぎてパンクしていましたが、HeyではImboxという「重要なメール」も定義できます。Screenerが拒否的なら、Imboxは許可的ですね。
Information（情報）は、スパムでもなく、やり取りするものでもない、単なる情報を示すものです。Heyとしては領収書、注文確認、サービス通知などを挙げています。
情報化社会の現代では、ここに当てはまるメールが非常に多くて私たちを疲弊させています。
Heyの革新的な点は、このInformationの捉え方を変えた点にあると思います。「ただの情報なんだから必要なときに見れれば・探せればいい」「受信時に律儀に読む必要なんてない」「ちゃんと仕分けて保存しておけば問題ないだろ？」というわけです。Paper Trail として提供されています。
タスク管理ツールの Asana も、メールの戦略を説いています。
4つのDと名付けられています。
https://asana.com/ja/resources/inbox-zero
メールのトリアージ――つまりは扱い方を決めて、適切な場所に入れることが重要だと述べています。
※記事はAsanaの宣伝なので、≒Asanaに入れる、となっています。
4Dについては、以下のとおりです。
Do, Defer, Delegateについては、適切な場所（Asana）に入れます。Delete については、Asana には入れずに削除なりアーカイブなりして対処します。
いずれにせよ、メーラーに留めておくのではなく、タスク管理ツール（Asanaの言葉ではワークマネジメントツール）でちゃんと管理せよ、ということですね。
Asanaの戦略をより一般化すると、自分なりのインボックス・システムをつくる、とも言えます。
要はメールという単一のインボックス上で完結させずに、他にもインボックスを導入して、メールからそちらに移すのです。そうして、様々なインボックスを導入・連携させることで、「特定のインボックスがパンクしている」状態を防ぎます。
詳細は以下記事を参照してください。
強気の価格設定をしたメールサービスとして Superhuman があります。
日本語の解説記事としては、以下があります。
https://news.mynavi.jp/techplus/article/svalley-843/
開発者体験(Developer Experience, DE)という言葉があります。
ソフトウェア開発者は、生産性だけでなく快適に仕事ができることも重視しますが、その方が結果的に生産性も挙がります。快適性も重視した方が良いのです。それを言語化したのが開発者体験です。
※DEと略すことは通常しないのですが、本記事のテイスト上、あえて略しています。
※当サイトではQoW(Quality of Work) 仕事の質という形で一般化しています。
開発者体験の主な要素は「スピード」です。具体的にはキーボードベースによる高速な操作と、ツール自体の動作の軽さです。
一般人はそこまで意識しない部分ですが、開発者は手を動かす量が多いので、かなり重要なのです。わかりづらい方は、ゲーマーを思い浮かべてください。ゲームでは0.1秒の遅延すら致命的です。そういう世界の住人です。
前置きが長くなりますが、この開発者体験をメーラーに適用したのが Superhuman であり、当サイトではDE戦略と呼んでいます。
たとえばキーボードショートカットが充実していたり、動作がキビキビしていたりします。他にも以下機能があるようです。
こういった工夫を盛り込むことにより、開発者が快適に感じるレベルの快適性を確保できるのです。そういう世界があるのだということを、開発者ではない、一般人の私たちでも体感できるのです。
当然ながらメールを処理するスピードも桁違いに変わるでしょう。
当サイト『仕事術2.0』としても、戦略を一つ提案します。
RACLとはReply, Action, Check, Logの略です。
メールを以下の4種類に分けます。
need Reply。返信が必要なメールです。
手間を掛けずに返事を返します。たとえば:
need Action。アクション（行動）が必要なメールです。
返信はアクションには含めません（need Replyです）が、返信に時間を要する or 時間をかけるべき場合はアクションにします。その場合でも、先に軽いメールを返しておけることはあります。
頭の中だけで管理すると破綻するので、タスク管理ツールを使ってください。成立するならメモやデイリータスクリストを知る程度の簡易的な手段でも構いません。
need Check。確認が必要なメールです。
返信もアクションも要らないメールは、基本的に次のLogにするべきですが、そうもいかないメールもあり、これらは need Check とします。
need Check的なメールはできるだけ少なくしてください。ここをどれだけ少なくできるかが、メールにかかる時間やストレスの軽減に直結します。
Log。受信時の確認は不要で、単に保存しておくメールです。
Logに当てはまるメールは、必要なときにメーラーの検索や一覧を使って探せば読むだけです。受信時には確認しません。
SCI戦略のInformationに相当します。Heyでは領収書、注文確認、サービス通知などがそうでした。メールは “受信時に” 必ず目を通すものだとの固定観念がありますが、そうではないのです。
とはいえ、いきなりLog的に扱ってしまうと、返信やアクションが必要なメールも見過ごしてしまいますので、まずはメール全部に目を通して、そこからLogを増やしていくようにします。つまり最初は大変だと思います。徐々に自分なりのカスタマイズを反映して楽にしていきます。
RACL戦略において、Log的なメールは（受信時ではなく）必要なときに読めばいいのでした。
これをオンデマンドチェックといいます。Ondemand、つまり必要に応じてチェックします。
RACL戦略においては、このオンデマンドチェックの考え方が重要です。別の言い方をすると、メールに占めるLogの割合を最大化せよ、とも言えます。メーラーはもはやコミュニケーションツールではなく、ある種の情報保存ツールなのです。
これは実質的に「通知に踊らされない」「不要なメールは相手にしない」「何が必要・不要かは自分で判断する」「また判断し続ける・カスタマイズし続ける」といった情報摂取リテラシーが要求されているに等しいです。
結局、メールと付き合う上で重要なのは、ツールよりも自分の意思だったりします。ありきたりですが、これができず整理も仕分けもせずに放置しているから溺れてしまうのです。
逃げずに向き合いましょう。RACL戦略では具体的なツールは挙げていませんが、ここまで挙げたHey、Asana、Superhumanは参考になります。
意思決定については、当サイトの仕事術も参考になるかもしれませんので、よろしければ漁ってみてください。