日本語ユーザ名

Lotus Notes は、アメリカで作られたため、ユーザ名にもアルファベットが使われることを前提としていた。しかし実際には、Lotus の国際文字セット (LMBCS=Lotus Multi Byte Character Set) のおかげで、ユーザ名に日本語を入れてもほぼ問題なく動作していた。しかし、インターネットが普及してきて、Notes のメールとインターネットメールの間のゲートウェイでは、日本語ユーザ名は大きな問題となった。インターネットのメールでは、メールアドレスに日本語が使えないからである。

Lotus Notes のセキュリティは、ユーザ名とドメインの文字列で保たれているので、インターネットメールでもその仕組みを大きく壊さないようにしたいというのが開発者の考えであった。そのため、Notes で、"Yuji Oda/Amarfy" という Notes のユーザがメールをインターネットに出すと defaut では自動的に "Yuji_Oda@company.com" というようなアドレスへの変換を行うというスペックになっていた（別の設定は可能）。ところが、日本語ユーザ名を使った "織田裕二/Amarfy" というようなユーザ名に関しては、自動的にインターネットメールアドレスを作ることができない。

そこで、日本のチームでは、Notes のユーザ名としてはアルファベットを推奨し、日本のユーザのために１対１対応で別のユーザ名を付けてはどうかという話になった。これが、現在でも使われている「別名」の始まりである。標準の英語では、"Alternate Name" と呼ばれる。日本側としては、別名というようよりも「表示名」という考え方で提案をして、「軽く」実現しようと思っていたが、名前自体の文字列がセキュリティに深く関わっていた Notes のデザイン上重複してしまうかもしれない、"表示名" は受け入れられず、変更は ID ファイルの中にまでおよび、Primary Name と Alternate Name の二つを持つことができるように設計された。この Alternate Name には、「言語」情報も含まれているため、Notes Client は表示時に、そのユーザが選択した自分の言語と Alternate Name の言語を比較して、一致すれば、Alternate name を選択し、一致しなければアルファベットの Primary Name を選択する。

こうして、Alternate Name が出来上がった。しかし、日本ではそれだけでは使い勝手が悪いため、Notes のアドレス帳にまで手を入れた DJX (Domino Japanese Extension) というアドインが使われ続けることになった。

特殊な日本のグループカレンダーへの要望

ソフトウェア製品の多くの物は、それまでの業務をソフトウェアに置き換えた物である。Microsoft Word は、かつては万年筆で書いていた「手紙」や「文書」をコンピュータ上で簡単に美しく書けるようにした物だし、PowerPoint は、OHP (Over-Head Projector) で行っていたプレゼンテーションを置き換えた。

個人のスケジュールは、システム手帳（今はこの言葉も死語かも）を置き換えた物として開発された Lotus Organizer などの独立したソフトウェアが存在したが、現在は Outlook や Lotus Notes などのメール系のアプリケーションに組み込まれていることが多い。Outlook にしても Lotus Notes にしても、メールと共存している以外は、システム手帳のアドレスとスケジュールの機能がソフトウェア化されただけにすぎない。ソフトウェア化の恩恵としては、スケジュール調整のためのやり取りをメールを使ってやれば、それが自分のスケジュールに自動的に反映させることができるようになったことがあげられる。

ところが、「スケジュール」という機能をソフトウェアにするときに、個人のシステム手帳をソフトウェアするだけでは機能不足と考える国がある。その代表的な国は日本である。日本のオフィス（特に外回りの多いオフィス）では、コンピュータが普及する以前からスケジュールはグループメンバーの外出先を書いた「ホワイトボード」で管理されていた。「スケジュール」機能をコンピュータ化すると考えたときに、真っ先に頭に浮かぶのが、「ホワイトボード行き先表示板をコンピュータで管理したい」という要望であった。ソフトウェアを作っている日本のエンジニアは、当然行き先表示板を見たことがあり、その使い方も理解しているので、ホワイトボードが提供していた機能をそのままソフトウェア化した。この行き先表示板の特徴的機能として以下の機能があげられる。

1. 誰でも他人のスケジュールを見ることができる
2. 誰でも他人のスケジュールであっても書き換えることができる
3. 誰が書き換えたとしても、ホワイトボードのスケジュールが「真」である。

そうしてできあがったアプリケーションは、「サイボウズ」をはじめとする日本型グループウェアである。それに対して、個人のスケジュールは個人で管理していて、他人が何の断りもなしに自分のスケジュールを書き換えることなんかあり得ないという意識の外国人のエンジニアは、ホワイトボード行き先表示システムなど見たこともないし、自分のスケジュールが書いた手帳を他人に見せる発想などない。唯一彼らにとって便利だと考えたのが、予定が埋まっている "Busy Time" を他人に見せることで、それによって本人と話をしなくても予定を入れることができるという機能であった。しかし、この機能ではスケジュールが埋まっていることは分かってもその内容はわからない。日本式ホワイトボード行き先表示システムでは、A さんにかかってきた電話をとった B さんが「A は、本日は３時まで新宿でミーティングが入っておりますので、戻りは４時近くになります。」なんていう返事ができていたが、外国製スケジューラではできないことになる。

日本式行き先表示システムシステムのエンジニアへの説明は困難を極め、ホワイトボードの写真を見せて、その使い方まで細かく説明しなけれなならなかった。そうすると次に出てくる質問は、「何で B さんが A さんにかかってきた電話をとるのか？」という質問が必ず出てくる。アメリカでは、オフィス用の電話の機能が発達しており、各人に1台外線電話付きの電話が用意され、すべての電話にボイスメール機能がついているのが普通である。A さんにかかってきた電話を隣の B さんがとるよりも、ボイスメールにメッセージを入れた方が、外出先からでもメッセージを確認できるなど便利なのである。これに対する返答は、通常日本のオフィスでは個人用の電話番号はなくて、代表電話かグループにひとつの電話番号を共用しているという事情の説明が必要になる。さらには、１電話番号あたり月に９００円もチャージする NTT の課金システムの説明までしなけらばならない。

最近では、Lotus Notes, Outlook + Exchange などグループカレンダー機能が高度になってきており、日本の要望を満たせるレベルになっているが、後から付けた機能は最初から設計された機能ほど洗練度が高くなく、まだ「とってつけ」という雰囲気は残されてしまっている。

Lotus Notes を開発した Iris Associates (その９)

Lotus では、毎年１月の最終週にフロリダ州のオーランドにあるディスニーワールドのホテルをいくつか借り切って、Lotusphere と呼ばれるプライベートイベントを開催していた（現在も継続して開催している）。Lotusphere は日曜日の夜に始まって木曜日までの４日間にわたる大規模なイベントで、参加費用も高額であったが、ピーク時には１万数千人の参加者があり、入場チケットも数時間で売り切れる人気イベントとであった。このイベントの特徴のひとつは、参加者が製品を開発しているエンジニアと直接話ができるということで、開発者から直接の情報を得るために、世界中から多くの人が集まってきていた。

Iris Associates のエンジニアにとっても、このイベントに参加することはひとつのステータスであったが、社員の参加人数は限られていたため、参加するための選考が行われていた。参加する資格を得るためには、開発している機能の説明のためのプレゼンテーションセッションを持つか、展示の説明員になる必要があったが、国際化チームは国際化関連の展示を毎年行っていたので、私も一度だけ説明員として参加することができた。

イベントは、準備を含めるとほぼ１週間にわたるため、製品のリリースが近づいているタイミングに Lotusphere が開かれるときは、開発作業とイベントの両方を同時に進める必要があった。ある年の Lotusphere では、開発につかうサーバーをディスニーワールドに持っていき、開発作業を継続しながらイベントで発表をするというような、ことまでやっていた。エンジニアにとって、そこまでやっても参加したい、または参加しなければならないイベントであった。

Lotus Notes を開発した Iris Associates (その８)

ソフトウェア製品を開発しているエンジニアのモチベーションは、技術力を示したいとか、社会を変えていきたいとか、人それぞれであるが、モチベーションの源泉となる伝統があった。それは Lotus Notes だけではなく、その当時の多くのソフトウェアに組み込まれていた Easter Egg と呼ばれる隠し機能である。それは、あらかじめプログラムされた秘密の動作によってのみ起動する機能で、ドキュメントのどこにも記述されない。その使い方は開発者から口コミだけで伝えられることになるので、ソフトウェアがリリースされてしばらくは、その話題でもちきりとなる。営業担当者の中には、いち早くその起動方法を開発者から聞き出して、お客様にこっそり教えることに命をかける人もいた。しばらくすると雑誌などで取り上げられて、皆が知ることになるが、これこそが開発者の遊び心であり、会社も公然とその機能を埋め込むことを認めていた。

私が開発に関わった Lotus Notes R5 のリリースでは、Easter Egg で、すべての開発担当者の名前が順番に表示する機能が組み込まれた。映画の最後のテロップのように、開発者の名前が順番に表示される。Iris の開発者はアルファベット順に一人ずつ表示され、その後世界中の関係者が５，６人ずつ表示されるように作られていた。しかし、ある開発者が、自分の名前を見るまでに時間がかかるのを嫌って、ログインしているユーザ名と同じ名前がリストにあるときは、最初にその名前を表示するという手の込んだ機能を作った。このため、開発者は自分のユーザ名でログインしていると、すぐに自分の名前を見ることができた。

映画のテロップの例を出したが、まさにその通りで、ソフトウェアエンジニアにとって、製品は映画や絵画と同じ「作品」という意識が強かった。その作品に自分の名前を入れるということは、何にも増して最高のモチベーションであった。しかし、IBM による買収の後のリリースでは、Easter Egg を起動するコードは、すべてが消去（実際はコメントアウト）された。製品に不要なコード、そして自分の名前を入れるなど IBM にとっては、無駄以外のなにものでもないということのようだった。そうして、ソフトウェア開発の伝統の一つが消えた。

今でも Microsoft 社製の製品には Easter Egg が残されている。今もソフトウェア開発の伝統を継続していることは尊敬に値する。かつての Iris のメンバーの多くが、その伝統を残す Microsoft で活躍していることには非常に納得できる。この良き伝統を今後も守り続けてくれることを願っている。

Lotus Notes を開発した Iris Associates (その７)

Iris Associates は、Notes / Domino という単独製品の開発を行っていたので、各バージョンのリリース前は会社中大騒ぎの状態になっているのではないかと想像する人もいるかもしれないが、全くそんなことはない。リリースの日程には、マイルストーンと呼ばれるチェックポイントが明確に示される。

主なマイルストーンには、Feature Freeze とよばれる「機能追加はここで終了」という日付、Code Freeze とよばれる「ソースコードの変更はここで終了」という日付、Release Candidate と呼ばれる「何事もなかったら、その日に作られた物が出荷される」という日付などがある。ただ、これは一般的なガイドラインで、「機能追加はここで終了」と言われても、その機能が重要な機能であったり、その機能がないと別の機能が動かない機能の追加は、その後も行われる。その際は、間に合わなかった機能ごとに評価が行われ、承認されれば、期限を超えての開発が承認されることになる。

ソフトウェア製品にとってバグはつきものであるが、そのバグをいかに効率よく修正していくかが、プロジェクトリーダーの腕の見せ所となる。プロジェクトリーダーはすべてのバグについて、修正するか修正しないかを判断していく。これが Triage (トリアージ)プロセスである。ソフトウェアに付属して提供されるリリースノートと呼ばれるドキュメントには「既知のバグ」という項目があるが、これは直前に見つかって間に合わなかったのでそのまま出したバグを記述しているのではなく、Triage プロセスでプロジェクトリーダーが明示的にバグを修正しない判断をしたものである。これはバグの影響度やその機能の使用頻度などを総合して判断される。Triage プロセスにおいては、プロジェクトリーダーが、担当チームのリーダーと個々にミーティングをもって、ひとつひとつのバグについてそのバグの修正を継続するか、バグ付きでリリースするかを決めていく。修正すると判断したバグは期限付きでエンジニアが修正作業を行うが、期限までに修正されないと、その時点の状況によってさらに修正を続けるか、あきらめるかを決めていく。当然のことながら、リリース日が近づいてくると、どんどん判断が厳しくなっていく。もし、重大なバグの修正が間に合わないときは、その機能ごとリリースからはずすか、リリース日を延ばすかの判断をすることになる。

Triage Meeting は、以前はリーダーと担当エンジニアを呼んで行っていたが、担当エンジニアからの情報が必要になるかどうかはわからない。そこで、途中から Triage Meeting にはプロジェクトリーダーのみが参加して、担当エンジニアは必要になったときだけ、Lotus SameTime のチャットで情報をもらうという方法に変わった。これによってエンジニアは製品の品質の向上の作業により多くの時間を使うことができるようになった。

リリース直前に慌てているのは、絶対に修正しなければいけないバグのある機能の担当のグループと、全体の品質の責任を持つ Quality Assurance のグループ、そして最後のリリース版のキットを作成するグループだけで、それ以外のグループはリリースされたというアナウンスを待っているだけとなる。リリースがアナウンスされると、パーティーモードに突入することとなる。

Lotus Notes を開発した Iris Associates (その６)

Lotus Notes のメジャーリリースの頻度は、およそ２年に一度であったが、マイナーバージョンアップなどのリリースは、数ヶ月ごとに行われていた。リリースの直前はいつものことながら、どれだけ品質を上げることができるかが勝負になる。Iris Associates のマネージメントにとって、リリース直前は知恵の絞りどころである。Iris Associates のエンジニアは「命令」では決して動かないので、いろいろな仕掛けを用意して、少しでも良い物をリリースするために働いてもらおうとする。

Tシャツは、常套手段である。リリースのバージョン名を書いたTシャツをメンバーに配って回る。時には、グレードアップして、ポロシャツだったりする。

面白かったのは、食材のデリバリーサービスである。スーパーマーケットに買い物に行く時間を節約して働けということで、夕食用などにあらかじめオーダーしておけば、夕方にオフィスに持ってくるというサービスと契約していた。

頭をリフレッシュして働けということで、カフェテリアにアーケードゲームが登場したことがあった。よく遊園地にあるバスケットボールのリングに決められた時間に何回シュートを決めれるかというようなゲームである。

土曜日も働けということで、土曜日の午前中にマネージャがオフィスで朝食を作って、土曜日の朝からオフィスに来たエンジニアに提供するというようなこともやっていた。

最後の圧巻がリリースパーティーであった。Iris Associates ではメジャーバージョンのリリースのボーナスとして、リリースの後リゾートに社員全員で行くというようなことをやっていた。少人数のときはそれで良かったが、Notes R5 の開発は Lotus チームも加わって大規模に開発が行われたので、リリースパーティをどうするかということが問題になった。中止になるとか一部の人だけが参加できるとかいう噂が飛び交っていたが、結局 Lotus の大盤振る舞いで Notes R5 に関係した多くの人が参加できることとなった。しかし、大規模なリリースパーティは Notes R5 が最後となり、IBM への統合が終わった後の Notes 6.0 のリリースのときは近場でパーティが開かれただけであった。

Lotus Notes を開発した Iris Associates (その５)

2001年に前後して、Iris Associates の IBM への統合が実施された。IBM が Lotus を買収したときに Iris Associates は Lotus の子会社であったために、Iris Associates も同時に IBM に買収された。しばらくは Lotus と同様に 100% 子会社として存在したが、2001年前後に Iris Associates という会社はなくなり IBM の１部門となった。統合の前には、数回近くの Westford Regency というホテルのホールに社員を集めて、説明会が行われた。Lotus の統合は、Iris より少し遅いタイミングであったが、同様に統合されて、統合日を境にいろいろな書類で Lotus という社名を使うことができなくなった。

Lotus と Iris の統合に先立って、マネージャだけが隠密に Cambridge にある Lotus の Conference Center に呼び出された。説明もなく集まれという指示だったが、IBM の要人とのミーティングらしいと多くの人は予想していた。はたして、そこには当時の IBM 社長の Lou Gerstner がいた。Lotus 買収後はじめての Lotus の一般のマネージャへのプレゼンテーションであった。Lou Gerstner は予想していたよりも小柄で、IBM の改革という大きな仕事をしているとは思えないような温和な雰囲気であった。内容は詳しく覚えていないが、Lotus 統合を喜んでいることなど、Lotus および Lotus のメンバーに対して非常にポジティブな強いメッセージが伝えられた。メッセージのわかりやすさと、人を引き込む話には、ものすごいパワーを感じた。

Iris の統合の直後には、ソフトウェア事業担当副社長の Steve Mills が、Iris の拠点の Westford にやってきた。今度は、Westford にいるメンバー全員をカフェテリアに集めてプレゼンテーションがあった。Steve Mills のプレゼンテーションは、通り一遍の内容でまったく面白みのない物であった。統合の結果、Westford の全員が Steve Mills の配下に入った訳であるが、普段は会うこともない雲の上の人である。新しい自分の部下に初めて話すのであるから、ポジティブなメッセージを伝えることが重要だと思うが、そういう雰囲気は全くなかった。そして、「 Notes はすでに投資モードではなく、利益を刈り取るフェーズの製品と位置づける。すなわち、投資を押さえる」という意味の説明があった。これは予想していた内容であったが、多くの Iris のエンジニアの落胆は見て取れた。そこまでなら、まだ良かったが最後の次の一言が、エンジニアに火を付けた。「OS/2 のように」。技術的な面はさておき、ビジネスとしては失敗であった OS/2 と、世界のグループウェア市場で１位の Lotus Notes を一緒に扱われたことで、主要なエンジニアが一斉に質問の手を挙げて矢継ぎ早に質問が出された。当然納得できる回答など得られるわけもなく、この会合は残念な結果に終わった。

Lotus Notes を開発した Iris Associates (その４)

Iris と最初に関わりを持ったのは、Lotus Notes の Internet 機能開発のひとつである、Web Navigator が Iris で開発されていると聞いたときだった。それまでも Lotus で SMTP Gateway や Domino の全身の Web Publisher などの Internet 対応機能を見ていたので、Cambridge にある Lotus のメンバーとは一緒に動いていたが、Web Navigator は Iris で開発が始まっていたので、大急ぎで Iris の担当マネージャの Dave Newbold と電話で話をして、国際化の必要性を話し、その開発をするためにエンジニアを送り込むことに同意してもらった。Dave Newbold はその後 Search Team のマネージャになったので、Verity に代えて、日本製の検索エンジン GTR を Notes に組み込むときにもお世話になった。

とりあえず、国際化されないままの製品が、そのままリリースされることは避けられそうであったが、エンジニアを送るといったものの、どういう仕組みで作られているかというような情報を入手している時間はなかった。そこで、どういう仕組みで開発されているかを推測して、それの国際化のための対策を立てた。結果的には、推測したデザインとほぼ近いデザインで開発されていたので、リリースまでに国際化対応を完了することができた。

Dave Newbold は、あまり目立つ機能を担当することはなかったが、新しい Web Navigator を担当したり、Verity から訴訟されたことで、Verity の検索エンジンが使えなくなったときに、GTR の組込みを決断するなど、重要な局面で頼りになる、非常にすばらしいマネージャであった。

Lotus Notes を開発した Iris Associates (その３)

Notes のアーキテクチャには、数々の画期的な仕組みが組み込まれていた。それが、古くなったと言われながらも今日でも通用している理由である。アーキテクチャのうち重要な物をあげておく。

1. セキュリティ - Notes には公開鍵方式を使った強力なセキュリティの仕組みが組み込まれている。重要なのは、ユーザはセキュリティを意識することなく、ソフトウェアを使うことができるということで、Notes のメールデータベースをローカルの PC にレプリケーションするときは、指定しない限り自動的に暗号化され、ID ファイルとパスワードがないと読むことはできない。
2. レプリケーション - サーバー上のデータベースを他のサーバー上やクライアント上に複製する機能である。Notes ができた当時はインターネットは広がっていなかったため、各リモートオフィスにそれぞれサーバーを置き、サーバー間を電話線を使った通信でつなぎ、レプリケーションを行っていた。現在は、インターネットがつながったが、複数サーバーによる負荷分散、複数コピーを持つことによる安全性、リモートアクセスの遅延防止などの目的で、レプリケーションは有効に使われている。
3. データと表示の分離 - 現在ではデータと表示の分離は XML と CSS の分離のように常識的に行われているが、Notes では、データと表示は最初から分離されていた。そのため、ユーザはデータに無関係で、データベースの表示を設計することができた。
4. マルチプラットフォーム - Notes はこれまで、Windows 16bit, Windows 32bit, OS/2, Macintosh, HP/UX, Sun Solaris, IBM iSeries (AS/400), IBM zSeries (S/390), IBM pSeries (AIX), Netware, Linux などの各種 OS をサポートしてきた。Notes のアーキテクチャの下位レイヤーで OS 依存の部分が明確に分離されているため、多くの開発者は OS の違いを意識することなく、アプリケーション開発に専念することができた。
5. 国際化 - Notes は、Unicode が提唱される前から国際化を意識して開発されており、その過程で Lotus 独自の国際文字セットが使われた。現在も内部コードには、独自の国際化文字セットが使われているが、Unicode とのマッピングにより外部システムとの互換性がとられている。

以上

Lotus Notes を開発した Iris Associates (その２)

Iris Associates の組織は、機能別のチームメンバー、チームのリーダー、複数のチームを束ねるプロジェクトリーダーが基本構成となっていた。当初は、Notes Client と Domino Server の区別がなくプロジェクトリーダーは一人であったが、プロジェクトに関わるメンバーや関連チームが増えてきた段階で、クライアント側とサーバー側にそれぞれプロジェクトリーダーが配置されて、リーダーミーティングも別々に行われるようになった。2000 年くらいのタイミングでは、Russ Holden がサーバー側のプロジェクトリーダー、Jen Kidder がクライアント側のプロジェクトリーダーであった。

エンジニアたちの多くは、優秀だがプライドの高い面々であった。リーダーは自分の担当している機能に関しては全面的な権限をもっており、次のバージョンで実現する機能の選択は、リーダーが行っていた。前のリリースで積み残した機能と、エンジニアとして実現したい機能が優先的に新バージョンの機能として扱われるため、新しい機能要望を追加することはタフなネゴシエーションが必要であった。開発チーム外から新しい機能を要望するときは、一つ一つの機能に対して要望責任者 (Champion) が要求され、機能ごとに詳細まで説明しなければならなかったので、中途半端な知識で、受け売りの機能要求をすることはできなかった。

Lotus Notes を開発した Iris Associates (その１)

Iris Associates は、Lotus Notes を開発した会社である。IBM が Lotus を最終的に統合するまで、製品は、Lotus Notes のブランドで販売されていたが、製品は Iris Associates という別会社で開発されていた。Iris Associates は Lotus から出資を受けていたため、できあがった Notes の販売権は Lotus にあったと思われる。

Iris Associates の社員のほとんどは、製品開発エンジニアだったため、実際の製品を完成させるための、テスト、ドキュメンテーション、製造などの周辺の作業や、製品販売後の技術サポート、Unix 系のプラットフォームへの移植作業は Lotus が担当していた。

Iris Associates があった Westford, Massachusetts は、Lotus のオフィスがあった Cambridge, Massachusetts から車で４０分以上かかり不便であったが、1997 年に Iris Associates が同じ敷地内にある別のビルに移転したと同時に、Lotus Notes のテストやドキュメントのエンジニアや、Product Management チームが Westford の同じビルに移転したことで、不便は解消した。

しかし、同じビルになっても Iris Associates の中心メンバーはビルの２階にオフィスを持ち、Lotus のメンバーがいる１階とは、隔離された雰囲気があった（実際は、Iris Associates のメンバーの一部は１階にいたので、隔離していた訳ではなかった）。

Unicode 前夜

コンピュータは、主にアメリカで開発されたため、コンピュータで使える文字は、英語で使われるアルファベット２６文字、数字、その他の限られた記号類だけであった。文字のエンコーディングも各社ごとに定義されていたために互換性がなかったが、アメリカで ASCII (American Standard Code for Information Interchange) という規格が定められたことで、文字表現が標準化された。ただ、IBM だけは今でも一部のコンピュータでは EBCDIC と呼ばれる独自表現を使っている。

ただ、ASCII には、英語以外の文字が含まれていないため、アメリカ、イギリス以外の多くの国では、ASCII を基本にした文字コード拡張が国（言語）ごとに行われていた。そのため日本語などの漢字圏だけでなく、フランスやドイツなどの国においても、各国ごとに文字セットを用意しなければならず、言語を超えた情報のやり取りができにくくなっている。

Unicode は、国ごとに別の文字コードを作って管理するのではなく、それまでとは違う世界共通の文字コードとして開発された。