ソフトウェア製品を開発しているエンジニアのモチベーションは、技術力を示したいとか、社会を変えていきたいとか、人それぞれであるが、モチベーションの源泉となる伝統があった。それは Lotus Notes だけではなく、その当時の多くのソフトウェアに組み込まれていた Easter Egg と呼ばれる隠し機能である。それは、あらかじめプログラムされた秘密の動作によってのみ起動する機能で、ドキュメントのどこにも記述されない。その使い方は開発者から口コミだけで伝えられることになるので、ソフトウェアがリリースされてしばらくは、その話題でもちきりとなる。営業担当者の中には、いち早くその起動方法を開発者から聞き出して、お客様にこっそり教えることに命をかける人もいた。しばらくすると雑誌などで取り上げられて、皆が知ることになるが、これこそが開発者の遊び心であり、会社も公然とその機能を埋め込むことを認めていた。
私が開発に関わった Lotus Notes R5 のリリースでは、Easter Egg で、すべての開発担当者の名前が順番に表示する機能が組み込まれた。映画の最後のテロップのように、開発者の名前が順番に表示される。Iris の開発者はアルファベット順に一人ずつ表示され、その後世界中の関係者が５，６人ずつ表示されるように作られていた。しかし、ある開発者が、自分の名前を見るまでに時間がかかるのを嫌って、ログインしているユーザ名と同じ名前がリストにあるときは、最初にその名前を表示するという手の込んだ機能を作った。このため、開発者は自分のユーザ名でログインしていると、すぐに自分の名前を見ることができた。
映画のテロップの例を出したが、まさにその通りで、ソフトウェアエンジニアにとって、製品は映画や絵画と同じ「作品」という意識が強かった。その作品に自分の名前を入れるということは、何にも増して最高のモチベーションであった。しかし、IBM による買収の後のリリースでは、Easter Egg を起動するコードは、すべてが消去（実際はコメントアウト）された。製品に不要なコード、そして自分の名前を入れるなど IBM にとっては、無駄以外のなにものでもないということのようだった。そうして、ソフトウェア開発の伝統の一つが消えた。
今でも Microsoft 社製の製品には Easter Egg が残されている。今もソフトウェア開発の伝統を継続していることは尊敬に値する。かつての Iris のメンバーの多くが、その伝統を残す Microsoft で活躍していることには非常に納得できる。この良き伝統を今後も守り続けてくれることを願っている。
2009-07-24
2009-07-15
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 のグループ、そして最後のリリース版のキットを作成するグループだけで、それ以外のグループはリリースされたというアナウンスを待っているだけとなる。リリースがアナウンスされると、パーティーモードに突入することとなる。
主なマイルストーンには、Feature Freeze とよばれる「機能追加はここで終了」という日付、Code Freeze とよばれる「ソースコードの変更はここで終了」という日付、Release Candidate と呼ばれる「何事もなかったら、その日に作られた物が出荷される」という日付などがある。ただ、これは一般的なガイドラインで、「機能追加はここで終了」と言われても、その機能が重要な機能であったり、その機能がないと別の機能が動かない機能の追加は、その後も行われる。その際は、間に合わなかった機能ごとに評価が行われ、承認されれば、期限を超えての開発が承認されることになる。
ソフトウェア製品にとってバグはつきものであるが、そのバグをいかに効率よく修正していくかが、プロジェクトリーダーの腕の見せ所となる。プロジェクトリーダーはすべてのバグについて、修正するか修正しないかを判断していく。これが Triage (トリアージ)プロセスである。ソフトウェアに付属して提供されるリリースノートと呼ばれるドキュメントには「既知のバグ」という項目があるが、これは直前に見つかって間に合わなかったのでそのまま出したバグを記述しているのではなく、Triage プロセスでプロジェクトリーダーが明示的にバグを修正しない判断をしたものである。これはバグの影響度やその機能の使用頻度などを総合して判断される。Triage プロセスにおいては、プロジェクトリーダーが、担当チームのリーダーと個々にミーティングをもって、ひとつひとつのバグについてそのバグの修正を継続するか、バグ付きでリリースするかを決めていく。修正すると判断したバグは期限付きでエンジニアが修正作業を行うが、期限までに修正されないと、その時点の状況によってさらに修正を続けるか、あきらめるかを決めていく。当然のことながら、リリース日が近づいてくると、どんどん判断が厳しくなっていく。もし、重大なバグの修正が間に合わないときは、その機能ごとリリースからはずすか、リリース日を延ばすかの判断をすることになる。
Triage Meeting は、以前はリーダーと担当エンジニアを呼んで行っていたが、担当エンジニアからの情報が必要になるかどうかはわからない。そこで、途中から Triage Meeting にはプロジェクトリーダーのみが参加して、担当エンジニアは必要になったときだけ、Lotus SameTime のチャットで情報をもらうという方法に変わった。これによってエンジニアは製品の品質の向上の作業により多くの時間を使うことができるようになった。
リリース直前に慌てているのは、絶対に修正しなければいけないバグのある機能の担当のグループと、全体の品質の責任を持つ Quality Assurance のグループ、そして最後のリリース版のキットを作成するグループだけで、それ以外のグループはリリースされたというアナウンスを待っているだけとなる。リリースがアナウンスされると、パーティーモードに突入することとなる。
2009-07-07
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 のリリースのときは近場でパーティが開かれただけであった。
Tシャツは、常套手段である。リリースのバージョン名を書いたTシャツをメンバーに配って回る。時には、グレードアップして、ポロシャツだったりする。
面白かったのは、食材のデリバリーサービスである。スーパーマーケットに買い物に行く時間を節約して働けということで、夕食用などにあらかじめオーダーしておけば、夕方にオフィスに持ってくるというサービスと契約していた。
頭をリフレッシュして働けということで、カフェテリアにアーケードゲームが登場したことがあった。よく遊園地にあるバスケットボールのリングに決められた時間に何回シュートを決めれるかというようなゲームである。
土曜日も働けということで、土曜日の午前中にマネージャがオフィスで朝食を作って、土曜日の朝からオフィスに来たエンジニアに提供するというようなこともやっていた。
最後の圧巻がリリースパーティーであった。Iris Associates ではメジャーバージョンのリリースのボーナスとして、リリースの後リゾートに社員全員で行くというようなことをやっていた。少人数のときはそれで良かったが、Notes R5 の開発は Lotus チームも加わって大規模に開発が行われたので、リリースパーティをどうするかということが問題になった。中止になるとか一部の人だけが参加できるとかいう噂が飛び交っていたが、結局 Lotus の大盤振る舞いで Notes R5 に関係した多くの人が参加できることとなった。しかし、大規模なリリースパーティは Notes R5 が最後となり、IBM への統合が終わった後の Notes 6.0 のリリースのときは近場でパーティが開かれただけであった。
2009-07-04
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 と 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 を一緒に扱われたことで、主要なエンジニアが一斉に質問の手を挙げて矢継ぎ早に質問が出された。当然納得できる回答など得られるわけもなく、この会合は残念な結果に終わった。
登録:
投稿 (Atom)