Orvia Mail の中にタスク管理を作った。
動いた。メールをタスクに変え、期限を追い、作業をアプリの中に置いておけた。
そして削除した。
いまやどのソフトウェアにもありそうな AI チャットも作った。それも動いた。こちらも削除した。
どちらの機能もクラッシュしなかった。テストにも失敗していない。それでも削除したのは、残しておける程度には完成していて、残せば Orvia Mail の目指す姿が変わってしまうからだ。
数年前までは、開発にかかる時間が大まかなフィルターになっていた。機能を作るには十分な時間が必要で、始める前にその考えを擁護しなければならなかった。
AI コーディングツールが、その順番を変えた。
いまは一日のうちにいくつものレイアウトを試し、データの流れを書き換え、スケッチを動くテストに変えられる。製品に本当に必要かを決めきる前に、そこまで進められる。
この速さは役に立つ。同時に、弱いアイデアを本来より長く生き残らせる。
以前なら、弱いアイデアは高くつきそうに見えた。いまは、午後の作業に見えてしまう。
動くコードは、最初のコストにすぎない
一日で作れる機能が、アプリの中に何年も残ることがある。その間、画面の中の居場所、わかりやすい文言、翻訳、テスト、サポート、macOS やメールサービスの変化に合わせた修正が必要になる。
製品のほかの部分を、ユーザーがどう理解するかも変えてしまう。
常に表示されるコントロールは、誰も押さなくても注意を求める。ユーザーはそれを見て、何をするものか考え、目の前のメールに関係があるかを判断しなければならない。
ボタンひとつなら許せる。数が増えれば、シンプルなアプリはユーザーが求めていない選択肢の集まりになる。
メールはもともと、一日中同じ小さな判断を求めてくる。読む、返信する、アーカイブする、削除する、あとで戻る。メールに向き合う前に、アプリからもう一度選ばせたくはない。
Orvia Mail では、メールが左にある。右側は内容に合わせて変わる。
会議の招待ならカレンダーの操作を出す。確認メールならコードを手元に置く。領収書なら必要な明細を見せる。右側に何もいらないメールも多い。
固定されたボタンの列を追加するより、これは手間がかかる。固定ツールバーは作りやすく説明もしやすい。内容に合わせて変わる操作には、ルール、境界条件への配慮、そして節度がいる。
画面がシンプルに見えるのは、ユーザーがメールを開く前に、こちらで多くの判断を済ませているからだ。
画面を小さくする前に、静かにする
メインウインドウを形にするときも、同じ判断をした。
最初の版は、多くのデスクトップメールクライアントにある三列のレイアウトだった。そこで、Orvia Mail に本当に三列が必要かを考えた。
必要なかった。二列に減らした。
隠すなら、すぐ見つけられるようにする
その後、サイドバーにも同じ問いを向けた。
常に表示しておく必要はあるか。メールを読んでいる人の注意を、アカウント、フォルダ、フィルターが競い続ける必要はあるか。
必要ないと判断した。Orvia Mail はいま、サイドバーを初期状態で隠している。
すると別の問題が生まれた。隠したものは、必要なときにすぐ見つからなければならない。
インターフェースの一部を取り除くのは簡単だ。消えていても、見つけにくくしない。その設計こそが本当の仕事になる。
タスクはリマインダーに任せる
タスク管理は、最初は明らかな機能に思えた。
メールには仕事が含まれている。クライアントは金曜までの返信を求める。請求書には期限がある。予約はカレンダーに属する。それをメールアプリに置いておけば効率的に思えた。
そして実際に作った。
二つ目の情報源
機能はすぐに、もっと多くを求め始めた。タスクリスト、優先度、繰り返し、完了状態、フィルター、通知、同期が必要になった。
その先にあったのは、ユーザーがもう一つ維持するタスクアプリだった。
タスクを Orvia Mail、リマインダー、Things、Todoist、あるいはすでに使っている別の仕組みのどこに置くかを決めなければならない。最終版がどのアプリにあるかも覚えておく必要がある。
最初のクリックは解決したが、二つ目の情報源を作ってしまった。
タスクの所有者をシステムアプリに戻す
macOS には、この仕事を任せられる成熟したアプリがすでにある。Apple の EventKit を使えば、アプリからカレンダーの予定とリマインダーを作成・編集できる。リマインダーは iCloud、Microsoft Exchange、Google、Yahoo、AOL などのアカウントを使える。カレンダーはインターネットアカウントや CalDAV に対応する。タスクや予定は、メールクライアントに閉じ込められず、ユーザーがすでに選んだアカウントに従える。[1]
だから、メールが得意な部分だけを残した。
Orvia Mail はメールの中から行動を見つけられる。ユーザーが、タスクにしたい正確な文章を選ぶこともできる。Orvia はそれをリマインダーに追加する。
日付、会議、予定はカレンダーへ渡す。
Orvia はメールを理解して受け渡しを行う。その後のタスクはリマインダーが持ち、予定はカレンダーが持つ。
ユーザーは別のタスクシステムを覚えなくてよい。どのリストが本物かを迷う必要もない。
一つのアプリが一日のすべてを所有する必要はないと思う。Orvia Mail はメールをよくする。リマインダーは覚えておく。カレンダーは予定を組む。
タスク管理を作ると、機能表の上では Orvia がより充実して見えた。
削除すると、製品はより正直になった。
AI を受信トレイにしたくない
AI チャットを削除するのは難しかった。市場が向かっている先に見えたからだ。
Google は Gmail の中に Gemini の要約と文章作成ツールを置いている。Microsoft は Outlook に、受信トレイやカレンダーについて答えられる Copilot チャットを用意している。接続すれば、ChatGPT も内容が関係すると判断したときに Gmail を参照できる。[2]
これらの製品は同じ方向を示している。受信トレイが、汎用 AI アシスタントのための大きな文脈になる。
便利なこともある。ただ、製品の中心が変わる。
普通のメールクライアントでは、ユーザーがメールを開き、読み、何をするかを決める。
AI 駆動の受信トレイでは、ユーザーはプロンプトから始める。どのメールが重要か、どこを見せるか、どんな操作を勧めるかをモデルが決める。
広い問いには、広いアクセスが要る
「先月、このクライアントに何を約束した？」と聞かれたら、モデルには画面上のメールだけでは足りない。数か月分のメール、送信済み、添付ファイル、連絡先、カレンダーの予定を探す必要があるかもしれない。
ある主流の実装では、接続した Google アプリがインデックス化したコピーを作り、内容を同期することで、ChatGPT がより関連性の高い回答を出せると OpenAI は説明している。[3]
AI エージェントに受信トレイを管理してほしい人にとっては、妥当な選択かもしれない。
私は、それがメールアプリを開くための静かな代償になってほしくない。
AI は必要な場所に置く
チャットを削除した理由はもう一つある。ChatGPT などの汎用 AI は、汎用 AI のために作られている。受信トレイ全体を AI アシスタントに通したいなら、メールクライアントに置いた小さなコピーより、そうした製品のほうがうまく仕事をするだろう。
Orvia Mail がそれをまねる必要はない。
AI は引き続き使う。長いスレッドには要約が役に立つかもしれない。別の言語のメールには翻訳が必要かもしれない。荒い返信案には助けがいるかもしれない。
二行のメールには、どれも必要ない。
個人的なメモの横に、AI パネルを常設する必要もない。
ユーザーが求めたとき、またはメールが明らかに役立つときだけ、ツールが現れる。用が済めば離れる。
Orvia Mail で AI は支える役割を担う。受信トレイにはならない。
メールを開き、直接読み、自分で決めたい人もいる。私はその人たちのためにも作っている。
チャットが流行っているからといって、すべての製品がチャットを中心に組み直す必要はない。
一か月のテスト
機能を作る前に、問題がどれほど頻繁に起きるか、誰が困っているか、リリース後にどんな仕事が増えるかを考える。
新しい設定が必要か。
手順が一つ増えるか。
一年後にも、なぜ存在するのかを理解できるか。
そして、いちばん役に立った問いを置く。
一か月かかるとしても、これを作るか。
AI は、最初の版が短時間でできるため、弱いアイデアを無害に見せる。一か月かかると想像すると、問題そのものを判断せざるを得なくなる。
答えではなく、ブレーキ
それでも判断を間違えることはある。
小さく見えた機能が重要になることもある。三日間は不可欠に感じた機能が、その後まったく使われないこともある。
この問いが答えをくれるわけではない。早く作れたことを、リリースする理由にしないためのものだ。
タスク管理と AI チャットは、このテストを通らなかった。
メールに属する仕事を残す
通った機能もある。
Exchange と共有メールボックスの対応は通った。会社が自前の Exchange サーバーを使っていて、仕事で Orvia Mail を使えないユーザーがいた。
小さな見た目の改善ではない。その機能がなければ、そのユーザーにとって製品は本来の仕事をできなかった。
サーバー検索も通った。
ほとんど開かない古い Gmail のメールを何万通も置くために、Mac のストレージを買い足すのは嫌だった。新しいメールクライアントを設定するとき、すぐに使えてオフラインでも読めるよう、最近のメールだけがローカルにあればよい。
何年も前のメールを、常にドライブに置く必要はない。検索するまでサーバーに置いておけばよい。
古いメールを見つけるために、完全なローカルアーカイブを要求するメールクライアントであってはならない。
Safe Reader にはプライバシーと読むリズムが要る
Safe Reader も「作る」側だった。
試したメールクライアントはリモートコンテンツを遮断できたが、多くはそこで止まった。追跡は止まっても、ニュースレターには壊れた間隔、空白、欠けた画像、単独では成り立たない文章が残った。
プライバシー設定は仕事を果たした。読む体験は果たしていない。
Safe Reader には両方を解決してほしかった。開封を追跡できるリモートコンテンツを遮断しながら、メールを読みにくくしない。
リモート部分を取り除き、必要な内容を残し、明快な文字、間隔、行長、視覚的な順序でメールを組み直す。その方法を考えるのに、多くの時間を使った。
Instapaper などの読書アプリを調べ、長い文章の文字、行長、間隔、階層をどう扱うかを見た。そしてその考えをメールに当てはめた。メールの HTML は送信者ごとに大きく異なる。
トラッカーを止めるのは、仕事の半分にすぎない。
メールは、それでも読む価値のあるものにしなければならない。
Safe Reader はまだ半分しか終わっていないと思っている。
メールの HTML は一様ではなく、送信者ごとに内容の組み立て方が違う。あるニュースレターでうまくいくレイアウトが、別のものでは失敗することもある。
もっと多くのメールを試しながら、ルールを調整し続けている。Safe Reader はリモートコンテンツを遮断する以上のことをすでにしているが、目指す水準にはまだ届いていない。
Exchange 対応、サーバー検索、Safe Reader は、どれも長く続く仕事を生む。
同時に、メールに属する問題を解決している。
いま守ろうとしている境界はそこにある。
リリース後は「やめる」が難しくなる
機能をリリースすると、誰かが毎日使い始めるかもしれない。
小さなオプションが習慣の一部になることもある。使う人が少なくても、あとで削除すればワークフローを壊したり、信頼を下げたりするかもしれない。
だから、リリース前に「やめる」と言うことが大切になる。
ある機能が今日の一部のユーザーを喜ばせる一方で、ほかの全員に何年も見せ続けるコントロールを増やすことがある。
テスト版でも問いには答えられる
動くコードを削除するのは、いまでも無駄に感じることがある。設計は終わり、テストも通り、機能は役に立つかもしれない。
それでも、テスト版は問いに答えられる。リリースする機能になる必要はない。
タスク管理は一つの問いに答えた。Orvia Mail は、メールの外へ仕事を動かす手助けをするべきで、管理する場所をもう一つ作るべきではない。
AI チャットは別の問いに答えた。AI は必要な場所に現れるべきで、メインウインドウを乗っ取るべきではない。
その答えには、コードを書いた価値があった。
Orvia Mail はこれからも成長する。リリースごとに、ユーザーに覚えてもらうことより多くの問題を解決したい。
ときには、数日かけて機能を作り、使い、誰かに見せる前に削除することになる。
どちらの機能も動いた。
Orvia Mail がよくなったのは、それらがリリースされなかったからだ。