Jmailの技術
1998年のウェブメールは、現在のように完成されたものではありませんでした。 サーバー、ブラウザ、文字コード、メール配送、ユーザー管理。 どれも手探りで、どれも壊れやすいものでした。
Jmailの技術は、華やかな発明というより、 日本語を読めるようにし、メールを送れるようにし、利用者が増えても動かし続けるための、 現場の格闘でした。
基本
いまでは、ブラウザでメールを読むことは当たり前です。 しかし、Jmailが生まれた時代には、ウェブメールそのものがまだ新しい体験でした。 メールは専用ソフトで読むもの、プロバイダから与えられるもの、会社や学校の環境に縛られるもの、 という感覚がまだ強く残っていました。
Jmailは、ブラウザからログインし、メールを読み、書き、送ることができるサービスを目指しました。 それは、利用者にとっては便利な自由でした。 しかし、運営側から見ると、多くの技術的な責任を引き受けることでもありました。
メールを保存する。 利用者を認証する。 送信と受信を処理する。 日本語を壊さない。 複数ドメインを扱う。 サーバーを止めない。 そして、それを無料で提供する。
Jmailの技術は、夢を支えるための裏方でした。
しかし、裏方が倒れれば、夢も倒れます。
一
ブラウザからメールを使うという体験は、利用者を特定のパソコンやメールソフトから少し自由にしました。
二
日本語が壊れずに読めることは、Jmailにとって中心的な課題でした。 文字化けは、メールの意味を失わせます。
三
Jmailは、ひとつのドメインだけではなく、多くの .co.jp ドメインを扱うことで、 メールアドレスに個性を与えました。
文字化け
メールは届いている。 けれど、読めない。 文字が意味のない記号になっている。 それが、文字化けです。
日本語のインターネット初期において、文字化けは珍しい事故ではありませんでした。 文字コード、メールソフト、サーバー、ブラウザ、利用者の環境。 どこかの解釈が違うだけで、日本語は壊れました。
英語だけなら見えにくい問題が、日本語では表面化します。 漢字、ひらがな、カタカナを含む文章が壊れると、 そこに込められた感情も、仕事の意味も、約束の内容も失われます。
だから、Jmailにとって文字化け対策は装飾ではありませんでした。 日本語の利用者に対する最低限の責任でした。
文字化けは、文字の故障ではありません。
届いたはずの言葉が、届かないということでした。
送信
利用者が入力した日本語を、相手が読める形で送る。 それはメールサービスとして当たり前に見えて、当時は簡単ではありませんでした。
受信
外部から届いたメールを、ブラウザ上で読めるように表示する。 そこにも環境差と文字コードの難しさがありました。
サーバー
無料メールサービスは、利用者にとっては気軽です。 しかし、運営側には重い現実があります。 新しい利用者が一人増えるたびに、メールボックスが生まれます。 保存するデータが増えます。 ログインが増えます。 送受信が増えます。 問い合わせが増えます。
利用者が十人なら、手作業でも見えることがあります。 百人なら、まだ人間の感覚で追えるかもしれません。 しかし、千人、万人、十万人となると、サービスは別の生き物になります。
サーバーは止まってはいけない。 でも、機材には限界があります。 回線にも限界があります。 ディスクにも限界があります。 資金にも限界があります。
Jmailの成長は、喜びであると同時に、技術運用の重さでもありました。
無料サービスは、無料であるほど軽く見えます。
しかし、裏側では重くなり続けます。
保存
メールは一通ごとに保存されます。 利用者が増えるほど、保存する量と管理する責任が増えていきました。
配送
メールはただ画面に表示されるだけではありません。 外へ送り、外から受け取り、正しく仕分ける必要がありました。
稼働
メールサービスは、利用者の日常に入り込みます。 だから、止まることは単なる不便ではなく、生活の中断になります。
複数ドメイン
Jmailの特徴は、複数の .co.jp ドメインをメールアドレスとして使えることでした。 これは利用者にとっては楽しい機能でしたが、技術的には管理の複雑さを増やしました。
どのドメインに届いたメールなのか。 どのユーザーのメールボックスに入れるのか。 同じユーザー名が別のドメインで使われる場合、どう扱うのか。 アドレスの表示、登録、配送、管理をどう整理するのか。
ドメインを増やすことは、見た目の選択肢を増やすだけではありません。 システムの入口を増やすことでもありました。
しかし、その複雑さこそがJmailの個性でもありました。 メールアドレスを、単なるIDから「選べる住所」に変えるためには、 複数ドメインを扱う必要があったのです。
利用者から見れば
どのドメインを選ぶかは、メールアドレスの雰囲気を決める楽しい選択でした。 Jmailの魅力はそこにありました。
運営から見れば
ドメインが増えるほど、配送、設定、保守、説明、障害対応の責任も増えていきました。
運用
サービスを立ち上げることは大変です。 しかし、本当に難しいのは、その後です。 毎日ログインされる。 毎日メールが届く。 毎日誰かが新しいアドレスを作る。 毎日どこかで問題が起きる。
無料メールサービスは、利用者にとっては気軽な場所です。 けれど、そこに預けられるものは軽くありません。 仕事の連絡、家族との会話、友人からの言葉、恋のメール、保存しておきたい文章。
技術運用とは、そうした日常を支えることです。 画面が出ること。 ログインできること。 メールが届くこと。 文字が読めること。 データが消えないこと。
Jmailは、そのすべてを最後まで十分に守りきれませんでした。 技術の話は、最終的には責任の話になります。
サーバーを動かすことは、機械を動かすことではありません。
利用者の時間を預かることでした。
技術のページにも、謝罪を置きます
Jmailには、面白い技術的な挑戦がありました。 日本語メール、ウェブメール、複数ドメイン、無料サービスの運営。 そのどれもが、当時としては大きな挑戦でした。
しかし、利用者の皆さまから見れば、挑戦していたことよりも、 最後まで安心して使えたかどうかのほうが大切だったはずです。
Jmailを最後まで十分に守りきれなかったこと。 メールアドレスと受信箱を預けてくださった皆さまに、不安と不便を残したこと。 そのことを、心からお詫びします。
いま振り返る技術
現在の基準で見れば、当時のサービスは足りないものだらけだったかもしれません。 監視も、冗長化も、セキュリティも、バックアップも、利用者説明も、 今なら当然求められる基準に届いていなかった部分があったはずです。
しかし、その未完成さは、言い訳ではなく記録です。 インターネットが産業として成熟する前、多くのサービスは走りながら作られていました。 Jmailもその一つでした。
夢が先にありました。 技術が追いかけました。 利用者が増えました。 責任が重くなりました。 そして、守りきれなかったものが残りました。
このページは、その技術を自慢するためではありません。 技術の挑戦と、技術だけでは足りなかった責任を、同じ場所に置くためのページです。
この背景にある本
本の第16章「The Jmail Phoenix」には、 Jmailがどのように生まれ、どのような状況で無料メールサービスとして立ち上がったのかが記録されています。
Jmail.co.jpでは、その技術的な挑戦を記録すると同時に、 利用者の皆さまに対する責任と謝罪を最初に置きます。
起業の物語を読む