小さなチームの大きな挑戦：「Six」誕生秘話

セキュリティ業界で著名なグローバルプレイヤーとなったKaspersky Labがたどった歴史の中で、重要なマイルストーンの1つといえば、Kaspersky Anti-Virus（KAV）の革新的なバージョン、6.0のリリースでした。2006年に正式リリースされたこの製品は、世界各国のアンチウイルス市場を席巻し、以後長年にわたるテクノロジーリーダーとしてのKaspersky Labの地位を確立しました。自社製品を世界最高のアンチウイルスソリューションと称するのはおこがましいことではありますが、多数の雑誌や第三者ベンチマーク機関がそう呼んでくれました。

KAVと同じエンジンを積んだKaspersky Internet Security 6.0も同時リリース

成功までの道のりは険しく、波乱に満ちたものでした。いつの日か、ハリウッドの脚本家の誰かがこれに気づいてくれるのではないかと願っているのですが、とりあえず、写真やメモ、最初の開発チームに聞いた思い出話をもとに、このサクセスストーリーをつづっていこうと思います。この物語が、新しいアプリケーションやサービスを生み出そうとしている現代の若い開発者たちを導く例となることを願っています – この若者たちが、最初の「Six」を開発したクリエーターたちと同じようにトップになるという目標に取りつかれていることを前提として。

 

2003年問題

「Six」の成功のルーツは、屈辱的な大失敗に終わった前バージョンにあります。実のところ、このバージョン5は日の目を見ませんでした。

この大失敗の本質を理解するには、2002年までさかのぼらなければなりません。Windows XPがようやく市場に出回り始めたころ。CPUのクロック速度は1 GHzにやっと指先が届きました。アンチウイルス業界は比較的若く、まったく見たこともないような種類の脅威にはまだ遭遇していませんでした。どのアンチウイルス企業も製品の機能を拡張しようと躍起になっていたころで、競争力のあるソリューションには、ファイアウォール、常時稼働するファイルシステムモニターなど多数の機能が必須とされていた時代でした。

Kaspersky Labの開発チームは、1990年代に開発された強力なスキャナーエンジンが原因で、製品に新しい機能を詰め込むと耐えられないほど動作が遅くなることを認めました。バージョン4.0でさえ、ユーザーから容赦ない非難を受けていましたから（当時「カスペルスキー製品は遅い」とさんざん言われたことは、世のPC伝説において省略できないエピソードです）。このため、新しいバージョン5.0の開発プロセスでは慎重なアプローチがとられました。新たな最高技術責任者（CTO）の任命、新たな開発フレームワークの採用、新たなアンチウイルスアーキテクチャの選択といった、ビジネスの根幹をなす諸要素が検討されたのです。

このプロジェクトを支援するために、全社的なリソースが注ぎ込まれました。にもかかわらず、1年のうちに、これらの新しい開発ルールに従っても、競争力のある製品の完成は必ずしも保証されないという結論に達しました。結果としてできあがったシステムは、エンタープライズ級のクライアント/サーバーアプリケーション（CTOが選択したアーキテクチャ）を真似たもので、アンチウイルス製品に対する市場要求を満足させられるものではありませんでした。このシステムは遅くて重く、チームがテストを繰り返しても、バグの数は減りませんでした。バグの数は…実のところ増えていきました。

「社内のベテランたちに聞いて回った、どう思うかって。誰もがアーキテクチャがすべてだと答えた。トランプで作った家のようなものなんだ、カードの1枚に手を加えたいと思ったら全部壊さなければならないんだ、とね」とユージン・カスペルスキー（Eugene Kaspersky）は認めました。つまり、プロジェクトをそのまま続けることにはまったく意味はなかったのです。今までのものをすべて破棄して、一からやり直す必要がありました。

やればできる！

Kaspersky Labの開発チームは、2つのグループに分かれました。深く考えずに選択されたアーキテクチャのままでなんとか製品を修正しようとするグループと、バージョン4.0を適切な新製品に仕上げようとするグループと。

その一方で、市場の要求に従うだけではなく、いつまでも古びることのない、まったく新しい製品を作ろうと心に決めた4人グループがありました。4人、つまり「Six」の開発チームが設定したこの目標は、説明は簡単でも達成の難しいものでした。新バージョンは、システムに侵入しようとするあらゆるウイルスや脅威をすべて阻止でき、敏捷性や透過性があり、高速で、そして…、見た目のいいものでなければならない。

「僕らはただ、これまでにない最高の製品を作りたかったのです」Sixの開発チームは振り返ります。途方もない課題を抱えたちっぽけなチーム ― 残りのスタッフ200人にはこのように思われていました。この挑戦的な任務を背負った小さなチームが楽観的であったのには、それなりの理由がありました。Kaspersky Labの創設者、ユージン・カスペルスキーとアレクセイ・デ・モンデリック（Alexey De-Monderik）の2人は当時、新しいアーキテクチャとなりうるものを探していました。やがて2人は、代わりとなるアーキテクチャが存在し、その発明者は他でもない自社チームであることを発見するのです。

プラハからの救いの手

バージョン4.0では、2つのアンチウイルスコア（いわゆる「エンジン」）がひとまとめで動作していました。ファイルのチェックは、古いけれども非常に能力の高い、1996年開発のバージョン3.0エンジンが担当していました（このエンジンは、多数の国際的企業へ大規模にライセンス提供されていました。たとえばG-DataやF-Secureなど）。Webトラフィックのフィルタリングの強化という新しいタスクは、1998年にプラハでのブレインストーミングセッション中に生まれた強力な新メカニズムが受け持っていました。

後者のエンジンは、やがて「Prague」（プラハ）と呼ばれるようになりました。実際にはモスクワでアンドレイ・ドゥフヴァーロフ（Andrey Doukhvalov）が開発したもので、彼自身はチェコ共和国の首都で行われたブレインストーミングセッションには参加していなかったのですが。ともかく、キーとなるアイデアはプラハで誕生しました。Kaspersky Labに入社したドゥフヴァーロフがこのアイデアに手を加え、Pragueのコンセプトを実装したのです。

Pragueは、純粋なアンチウイルスエンジンとして設計されていました。しかし、この新開発エンジンには大変意欲的な目標が設定され、その完成形は、より複雑なシステムにさえも十分なパワーを提供できるほどの柔軟性と創造的能力を備えるものでした。「Pragueをベースに製品全体を実装することは可能か」。開発者たちと話すにつれ、この考えがカスペルスキーに重くのしかかってきました。彼は次のように振り返ります。

「あるとき、ヴィクトル・マチュシェンコ（Victor Matyushenko）に、Pragueを製品にうまく組み込めるかと尋ねたら、『バッチリです』と返ってきた。それがブレークポイントだった。そのとき、その考えがはっきり形になったんだ。私はグラフ（デ・モンデリック）とペトロビッチ（ドゥフヴァーロフ）のいる部屋に入っていって、その考えをぶつけてみた。『製品を完全にPragueベースにしてみたらどうだろう？』　とね。グラフは、『Pragueはそのように作られていないから不可能だ』という意味のことを言ったが、ペトロビッチは何か言おうとしてためらっていた。次の朝、ちょっとした紙の束を持ったペトロビッチが私とグラフの部屋にやってきて、『Pragueを使うコードを書いてみました』と言った。グラフはペトロビッチを見上げて『少し話そうか』と言った。しばらく － 少し話を － してから、2人が戻ってきて、試しにやってみる価値があると請け合った」

この試みは非常に小さなチームからスタートしました。後に「Six」となるコードの最初の数行を書いたチームです。

「私たちは、クリエイティブで何らかの貢献をしてくれそうなメンバーを探し始め、チームを拡張しました」とデ・モンデリックは回想します。「まず、パーヴェル・メジューエフ（Pavel Mezhuev）をメンバーに加えました。新人のコーダーでしたが、非常に切れる男でした。それから、マイク・パヴリューシク（Mike Pavlyuschik）。彼とは長いこと一緒に仕事をしていました。自由な発想でアイデアやコンセプトを生み出す能力を持っており、社内で最も才能豊かで勤勉なクリエーターのひとりだと私は思っていました」

2か月にわたるオープンフロア（実験的なコーディング）の後、このプロジェクトは商用製品になるという結論に到達しました。これで、必要なのはプロジェクトマネージャーだけとなりました。

アンドレイ・ドゥフヴァーロフは、当時デ・モンデリックと交わした会話を再現してくれました。「隣の部屋のニコライ・グレベンニコフ（Nikolay Grebennikov）を覚えているかい？たくさん本を読んでいるし、若いし、新人だ。彼をひっぱってこよう！」ドライバーソフトウェアエンジニアのアンドレイ・ソプコー（Andrey Sobko）がチームに参加したのは、もう少し後のことでした。

「Prague」（プラハ）とは

このセクションは、ソフトウェアエンジニアの興味をそそる内容となっています。そそられない方は飛ばして、先に進んでください。

アンチウイルス業界が現れ始めたばかりの1990年代初めでさえ、通常のシグネチャでは検知できないウイルスがありました。たとえば、感染のたびにコードの暗号化方法を変えるポリモーフィック型ウイルスは、シグネチャを使ったアプローチでは検知できません。インターネットの普及率が急激に上昇し、それまでは面白がっていただけだったマルウェアプログラマーが市場にサービスを提供し始めていました。そんな中で、ソフトウェアは複雑さを増し、ウイルスも次第に高度化して多種多様な脅威をもたらすようになりました。シグネチャベースの検知アルゴリズムにその他機能を取り入れたエンジンを使っていても（Kaspersky Labがそうでした）、新しい原理を採用したマルウェアに遭遇した場合には、シグネチャデータベースだけではなく、アンチウイルスエンジン本体も常に更新していかざるを得ませんでした。このため、新種ウイルスへの対応は非常に遅くなります。悪名高いCIH（チェルノブイリ）ウイルスを業界で初めて駆逐したKaspersky Labの成功は、対応時間の短縮は努力に値するものであることを証明しました。

以上を念頭に置いて、カスペルスキーは1998年、新しいアンチウイルスエンジンを目指してよく検討する時期が来た、と同僚たちに持ちかけました。しかし、どこを目指せばいいのでしょう？

「会社には資金が不足していた」とカスペルスキーは言います。「それに、都会の喧騒から遠く離れた場所でじっくり課題を検討したかった。そこで、モスクワに近くて一番安い、さらには完全に世間から隔絶された場所を探し出す必要があった。当時はまだWi-Fiはなかったね。その場所はヨーロッパのある国の首都に見つかったが、まさに、それがプラハだった」

Kaspersky Labチームは、新バージョンのアンチウイルスエンジンに関するブレインストーミングを行い、オブジェクト指向のアプローチがエンジンレイヤーにとって最善のソリューションであるという結論に達しました。つまり、対象となるファイルやオブジェクトそれぞれを構造に基づいて詳細に分析し、その内部オブジェクトを検知、分析、チェックするのです。オブジェクト管理は、最初から最後まで、ランタイムで実行しなければなりません。

あらゆる既存のオブジェクト環境を討議の場に載せましたが、柔軟性がない、メモリを消費しすぎる、遅い、などの理由ですべて却下されました。ディスカッションの途中で、あるアイデアが浮上しました。独自の環境を開発したらどうかと。メモリ管理機能などのサービスプロシージャを搭載し、マルウェアである可能性のあるコードをすばやく効果的な方法で解析する能力をアンチウイルスエンジンに与える環境を。

全般的なアイデアは、デ・モンデリックとアンドレイ・クルィコフ（Andrey Krykov）がプラハで生み出しました。それを後押ししたのが、ドゥフヴァーロフとクルィコフが提供した最初のコード行だったのです。

その後、1年間にわたり、ドゥフヴァーロフが中心となって、Pragueの作り込みが続けられました。これぞ、Kaspersky Labが彼を採用した目的だったのです。アーキテクチャの専門知識を持つドゥフヴァーロフは、柔軟で拡張性が高く、製品へ簡単に展開でき、アーキテクチャの制限を呼び起こすこともないようにPragueを作り込みました。最終的には、マルチプラットフォームソリューションの構築が目標に据えられました。

オブジェクト階層のデバッグには多少の困難が伴いましたが、使いやすいオブジェクト間メッセージ交換システムや、必要最低限に抑えられたプログラミングインターフェイスにより、Pragueは必要に応じた利用が可能な統合しやすいアーキテクチャとなりました。

「コンポーネントアプローチを目指していたのです」　と、ドゥフヴァーロフは誇らしげに語ります。「つまり、既存のプログラムにコンポーネントを追加できるシステムを目指したのです。このシステムは非常にオープンで、エレメントの追加や動作パターンの変更が可能でした」

コンポーネントベースのアーキテクチャであること、コンパクトでリソースを大量消費しないこと、いずれも共通認識のもとで。根本的に新しい一連のテクノロジーをKaspersky Anti-Virus 6.0に導入するにあたっての基本原理は、このようなものでした。実装は簡単でした。さらに、アンチウイルスエンジンとしてだけではなく製品全体の基盤として機能するようにPragueへ手を加えるにあたっては、パーヴェル・メジューエフがアーキテクチャの細かなチューニングに大きく貢献しました。

Kaspersky Anti-Virus 6.0のプロジェクトマネージャーを務めたニコライ・グレベンニコフは、次のようにコメントしています。「ビジネスロジックとインターフェイスを分離するモデルを導入して、アーキテクチャソリューションをもう1つ実装しました。また、ドゥフヴァーロフとメジューエフは、製品内のあらゆるプロセス1つ1つを制御可能なタスクマネージャーを開発しました。プロセスの相互関係は非常にシンプルでした」

「Six」の原理

開発のトライアル段階と初期段階が小さなグループで遂行されたことを踏まえると、巨大プロジェクトを管理するためのアプローチがこのチームに当てはまらないことは明らかでした。結果、採用されたのはSCRUMに似たアプローチでした。開発者は、常に対話のできる、1つの広い空間に集まって仕事をします。こうすることで、全員が開発プロセスのあらゆる側面をすぐに把握できます。「Six」の開発チームはこの方法で仕事を進めていきました。

概要:SCRUM

SCRUMは、アジャイルソフトウェア開発環境で使われるプロジェクト管理アプローチの1つです。元になっている原則は、「顧客（ユーザー）は、自分たちが何を必要としているかを正確に知っている必要はなく、プロセスの中で要件を変更できる」というものです。そのため、この開発プロセスには、当然ながら多数のサイクル（構築、デモ、フィードバックの分析、バージョンの更新）が存在するという特徴があります。

しかし、SCRUMでの役割分担は大いに見直されました。カスペルスキーが設定したのは、次の6つの役割です。

アーキテクト
何をどのように構築するかを理解している人物。コードの記述プロセスに積極的に関与します。

テクニカルデザイナー
この役割を端的に定義することはできませんが、言ってみれば、特定のソリューションを確実に実現する責任を持つ人物です。おそらく、それよりも重要なのは、テクニカルデザイナーは物事をどのようにしてはならないかを知っている必要があるということです。

インベンター
インベンターは、慣例にとらわれないソリューションを適用して問題を解決します。「Six」の場合、問題は無数にありました。最終的なソリューションは、最高レベルの保護を提供しつつ、コンピューターのリソース消費を最小限に抑えるものでなければなりませんでした。

プロジェクトマネージャー
SCRUMにおけるプロジェクトマネージャーは、厳密にルールに則ることはしません。リソースプールと納期をコントロールしますが、直接のリーダーではありません。コーダーに何をしろと指示を出すことはありませんが、コーダー自身が主導権を握るようにやる気を起こさせます。

「小規模なチームでしたから、最初はリーダーもいませんでした。マネージャーは計画と報告は行いましたが、プロジェクト自体に対する決定はメンバーの総意でした」（ドゥフヴァーロフ）

マーケティングマネージャー
製品はクライアントのために作成されます。開発チームのためではありません。見込みユーザーが製品の判断材料として何を期待しているか、どのように使おうとしているのかを理解することは極めて重要です。動作原理は、アンチウイルス機能の性質を理解している人物が定義します。しかし、設定やメッセージ、UIなど無数のこまごまとしたことについては、ユーザーの要望を考慮する必要があります。

サイコロジスト
プレッシャーがかかった状態での作業、睡眠不足、グループ内での衝突、不安定さ… 誰かがチーム内の雰囲気を友好的かつ生産的に保つ必要があります。この役割はカスペルスキーが受け持ちました。当然ながら彼はまた、チームへ資金とリソースを提供し、外界の影響からチームを守る「スポンサー」の役目も担いました。

実は、SCRUMプロジェクトに重要不可欠な役割がもう1つあります。プロセスに関する記録を残すスクライブ、つまり書記です。しかし、誰もこの役割にはつかず、それが問題を生み出しました。

「なぜこうしたのか、なぜこの決定をしたのか、わずか半年前のことなのに誰も覚えていなかった」と、カスペルスキーは証言します。

SCRUMの原則によると、役割の数をチームメンバーの人数に対応させる必要はありません。1つの役割を複数のメンバーで分担することもできますし、1人のメンバーが複数の役割を担当することもできます。

「私たちは形式的な組織を維持しながら、1つのチームとして活動していたので、役割と役割の境界は曖昧でした。特にブレインストーミング中、メンバーはさまざまな役割を果たしていましたね。たとえば、あるメンバーはコーディング担当でしたが、設計に関する自分の意見を主張しましたし、その意見が考慮に入れられていました。私自身はプロジェクトマネージャーでしたが、ディスカッションにも参加していました。つまり、この曖昧な境界線が私たちの成功に大きく貢献したのです。誰もがプロジェクトの1つ1つの要素を気にかけていましたから」（ニコライ・グレベンニコフ）

デ・モンデリックによると、コーダーは柔軟に入れ替えできたそうです。「チームのメンバーはそれぞれの専門分野では神でした。でも、そのスキルの半分は、チームにいる他の誰かのスキルと重なっていました。ソプコーがいなければ、パヴリューシクがドライバーのコードを書けました。UIのスペシャリストは、エンジン関連のタスクに対処できましたし、その逆も可能でした。私はマックス・ユダーノフ（Max Yudanov）の代わりに設計できましたし、コーリャ・グレベンニコフ（ニコライ・グレベンニコフのこと）もたまにスキンのデザインをしていました」

よく理解しておくべきは、それぞれの役割がプロジェクトの特定段階でリードをとるのだということです。スタート段階はアーキテクトが中心に立ちます。インベンターは開発プロセスの中ごろ、機能が創造され開発される時期に行動を開始します。最終段階では、綿密な管理を必要とするリソースでプロジェクトがいっぱいになっていますから、マネージャーが中心に立って、納期に間に合うようチームをけん引します。

理想の追求

SCRUM的なアプローチと全体を通じての熱意が前提となっていた「Six」には、確固たる要件リストはありませんでした。基本要件によると、この製品には次の機能が必須とされていました。

• セキュリティ上の最新の脅威に対抗する本格的なサポート
• PCリソース使用量の最適化
• 拡張性向上のための、コンポーネントをベースにしたインフラストラクチャ
• 各種プラットフォームに簡単に適応できるコンポーネント

こうしたメタ要件を元に、製品に対する技術要件は何度か変更されました。その結果、リリースは絶えず延期されたものの、一般市場の要求よりも数年早く、革新的なソリューションを開発することができました。このソリューションは、スピードの面でも前バージョンより優れていました。

Kaspersky Anti-Virus 6.0のリリース後、UI設計を担当したマキシム・ユダーノフは次のように語っています。「このプロジェクトが他と違っていた要因の1つは、『石に刻まれた（変更不能な）』要件リストがなかったことです。私たちはプロトタイプを作り、製品についてディスカッションし、技術要件や機能のリストをアップデートし、黄色いポストイットに主要なポイントをメモしてディスプレイに貼り付け、あれを忘れ、これを思いだし、最初からやり直して、観客（ベータテストコミュニティ）に助けを求めました。従来の要件リストに従って作業しようとしていたら、最終的な製品は今のようなものではなかったと思います。おそらく、最初に想像したとおりの製品を作って終わっていたことでしょう。その場合、製品は今よりも劣るものになっていたことは確実です」

エクストリームプログラミング

このアプローチは、現在では目新しいものではありません。しかし、10年前、この方法を大規模なプロジェクトに適用することは革新的で型破りなことでした。俗に言う「エクストリームプログラミング」（当時、広く使われていた用語で、現在はこれに類似する複数の方法が「アジャイルソフトウェア開発」という言葉でまとめられています）とお役所的な能力成熟度モデル（現在、これはほぼ絶滅しました）の大きな違いは、その先何年もの間プロジェクトの唯一の基盤として世間一般に認められた、伝統的な要件リストの有無にありました。開発プロジェクトを外注する場合にはCMMは適切なアプローチだったかもしれませんが、大量消費市場向けプロジェクトでは役に立ちません。

現在、Kaspersky LabのCTOであるニコライ・グレベンニコフは、これに同意します。「もし、私たちが最初に、開発の過程で変更を許されない機能セットを考えついていたら、ユーザーが何を必要としているのか正確にはわからなかったでしょうし、ユーザーからこれほどのサポートは望めなかったでしょう。最初のビルドバージョンは、あまり使い物にはなりませんでしたし、問題も山のようにありました。これらの問題の解決には長い時間をかけました。アルファリリースからテクニカルリリースまでの期間は5四半期。今日の社会ではとてもぜいたくな話ですが、当時は非常に有益な経験でした」

この点について、カスペルスキーの見解は実に単刀直入です。「新しいものを生み出すときには、納期を破り続ける覚悟を持つことだ」

仕事中心の生活

Kaspersky Anti-Virus 6.0開発チームの主要メンバーは、当時の生活を懐かしく振り返ったものです。睡眠、家族と過ごす時間、自由に過ごせる週末のすべてが不足していた当時、メンバーは皆、精神的ストレスの下にあり、仕事の進捗と質に報いを見いだしていました。

当時、プロジェクトの最中にニコライ・グレベンニコフが書いた1通のメールは、その様子を詩的に表現しています。

「いつか、これは単なるプロジェクトではなくなる。まるで、ものすごいスケールとパワーのゲームに巻き込まれたようなものだ。一度飛び込んだら、スタート画面から最後のクレジットまで生き残らなければならない。通勤途中の地下鉄では、前の日に保存したゲームで勝ったことや敗けたことを思い出し、職場に着いたら、次のレベルに到達するにはどのようにプレイすればいいかを考える。子どもを寝かしつけたら、またゲームの世界の住人に戻る。その世界では、想像したことすべてを実現でき、不可能なことなど何もないのだ」

「実際、一生に一度の楽しいひと時だった」とカスペルスキーは振り返ります。「熱意に輝く目、ポストイットのメモ、寝不足のチームメンバー。アイデアと行動で煮えたぎるスープだった」

チームの規模が拡大されると、開発グループの中心メンバーは、新しいメンバーにチームスピリットを伝授しました。デ・モンデリックは次のように振り返ります。

「チームメンバーすべてがうまく機能するかぎり、情熱を刺激する『コアグループ』の力に任せる必要がありました。『コアグループ』がいる、重要な目的と難題を抱えている。これまでにない最高の製品を作り上げる、という目的と難題ですよ。私たちにとって一番の目標だったのです。コーリャ（グレベンニコフ）、パーヴェル・メジューエフ、ドゥフヴァーロフ、私自身、マイク・パヴリューシク… 私たちは、自分の情熱を他のチームメンバーに吹き込むことができました。同じ部屋にいる周りの人がみな熱心に働いているときに、何がどんな風に実現されたのかを目の当たりにすれば、知らずと全力を傾けたくなるものです」

まったく型にはまらないプロジェクト管理にも、収穫はありました。

「私の記憶が正しければ、最初はステータスミーティングをしていました。朝、グループで部屋に集まって、コーリャが要点をまとめて連絡するというようなことをしていたのです。こんなリソースがあるとか、今日はこんなことをするとか。上手でしたよ。それから、巨大なホワイトボードがあって、そこに自分たちが発見したことを書いていました。大規模なチームではなかったので、それで十分でした」（デ・モンデリック）

グレベンニコフは、この経験から学んだのは、プロジェクトで作業を組織的にまとめる手段として、ステータスミーティングはさほど重要ではないということだ、と認めています。ミーティングがプロジェクトに利益をもたらす場合にだけ、チームを招集すればいいのです。

範囲の拡大

2003年9月から2006年3月、時が経つにつれてプロジェクトが進化すると、チームは規模を拡大し、リリース日には約30人のグループとなっていました。さらに増え続ける要求に応え、「アルファ」段階へ移行するために、デザイナーのマキシム・ユダーノフ（Maxim Yudanov）とソフトウェアエンジニアのパーヴェル・ネシャエフ（Pavel Nechayev）、デニス・グーシン（Denis Guschin）、ユージン・ローシン（Eugene Roschin）、アンドレイ・ゲラーシモフ（Andrey Gerasimov）をチームに迎えました。彼らは「スキン」ベースのUIや内蔵ファイアウォールなどの革新的な機能を実現しました。さらに、インストールのスペシャリストやベータテストのスーパーバイザーもグループに加わりました。しかし、Kaspersky Anti-Virus 6.0を変更し、磨きをかけるために取られた最も決定的なステップの1つは、「Six」開発チームによって新たに考案された、フォーラムベースのベータテストというアプローチでした。

フォーラム

関係者が口をそろえて認めるのは、Kaspersky Anti-Virus 6.0がよく設計され丁寧にテストされた製品となったのは献身的なテスターフォーラムのおかげである、ということです。後にKaspersky Labでは恒例となる公開ベータテストは当時、まさに斬新な考えであり、リスクでもありました。リリース前の製品の機能を知るチャンスを競合企業に与えてしまうからです。

「ベータテストは事実上、ハッカーや競合他社にベータコードを公開することになりますから、みな真剣に考えました。賛成も反対もありました。反対意見の内容は基本的に今言ったとおりです。賛成者も、確実な証拠を挙げて支持を表明しました。社内のリソースは限られていて、割り当てられるテスターは2人だけでした。それ以外のテスターはバージョン5.0のテストに当てられていましたから。私たちの製品は何もないところから作られたので、テストを行うには大規模なグループを割り当てる必要がありました。このとき私たちは初めて、まずは週に一度、のちに毎日のペースでビルドを定期的にアップデートするアプローチを採用しました。これらのビルドをフォーラムでテストすることで、社内リソースを大量に使わなくとも、質の高いテストを行うことができたのです」（グレベンニコフ）

開発者は全員、フォーラムでテスターたちとのディスカッションに積極的に参加しました。

ニコライ・グレベンニコフはさらに続けます。「フォーラムでのテスト中、数千人のユーザーがテスター要員となり、このうち約500人が積極的に討議に参加してくれました」。毎晩、グレベンニコフはフォーラムで数時間を過ごし、コンピューターの前で眠りに落ちることもありました。テスターたちは新しいビルドを楽しみにしていて、毎晩、実行してくれました。まったくの無償で。

フォーラムの住人は、バグ情報と、製品をよくするためのアイデアの両方を提供してくれました。この集団的なフィードバックの大部分が考慮され、Kaspersky Anti-Virus 6.0の価値の向上に役立てられました。また、アイデアはオフラインでも集められました。カスペルスキーによると、開発者たちは定期的に社内を歩き回り、セールスマネージャーからテクニカルサポートスタッフまで、あらゆる社員をベータバージョンのテストに巻き込んだそうです。社員からのフィードバックに基づいて、製品はさらに進歩を続けました。たとえば、テクニカルサポートチームからの提案に基づいて、言語を1回のクリックで英語に切り替える機能が追加されました。

それでも、フォーラムのディスカッションがもたらす機能改善にはそれなりの代償もついてまわりました。その多くは納期遅延です。

ニコライ・グレベンニコフがドラマチックに回想します。「私たちは、フォーラムユーザーからのフィードバックに基づく、膨大な数の改良提案リストを受け取っていました。しかしある日、いくら提案が魅力的でも、今ある機能の上にはもう何も加えられなくなっていることに気づきました。2006年第2四半期中、というリリース期限が迫っていたのです。これはギリギリのところで達成できました。リリースは3月31日午後6時30分でした」

 

リリース

成功

最終的には他チームからの力を借りましたが、それでも非常に小規模なチームが、並はずれてコンパクトなインストーラーと、入れ替え可能なスキンをベースにしたスムーズなユーザーインターフェイスを持ち、PCのパフォーマンスに与える影響が小さい製品を開発したのです。なにより重要なのは、アプリケーションの動作パターンに基づいて疑わしいアプリケーションをブロックするプロアクティブディフェンスをはじめ、強力で革新的な機能がぎっしり詰めこまれていたことでした。

「米国の雑誌が当社の製品を優秀な製品として評価し始めたとき、Symantecの人々は驚いていたね。我々はそこかしこで最高得点をマークしていたから」ユージン・カスペルスキーは嬉しそうに認めました。

ヨーロッパ、米国、中国に確立されたパートナーネットワークのおかげで、完成した製品は即座にサプライチェーンに乗り、オンラインストアのベストセラーランキングは緑色に染まりました。

「Six」の成功をもたらしたのは、革新的な技術をすばやく展開しつつ高いパフォーマンスを提供できる賢く選択されたアーキテクチャと、熱意のあるコンパクトなチームに100%マッチした開発アプローチでした。Kaspersky Anti-Virus 6.0の市場投入へ向けた取り組みから得られた主な教訓は、まとめてみれば次のようになるのではないでしょうか。「プロジェクトを100%成功に導くには、アーキテクチャと開発テクニックの両方を、開発チームと仕事のスケールに合わせてうまく調整しなければならない」

 

6つの役割と1台のコーヒーメーカー

「当時、チーム内で回していたSCRUMプレイブックに興味深いルールが載っていることに気づいた。今でも、開発以外のさまざまな分野で、このルールを念頭に置いているんだが」と、カスペルスキーは語ります。「開発プロセスの邪魔をするものがあったら、それを取り除くのを最優先にすること。以上。それが何であろうと、だ。別の言い方をすれば、開発者は必要とするものをただちに手にできなければならない、とも言える」

「プロジェクトの初日、私はこう訊いたんだ。『最優先の要件は何だい？』ペトロビッチが『コーヒーメーカー』と答えた。翌朝、高価でぜいたくなコーヒーメーカーが彼らの元に届いた。で、我々は成し遂げたよ！」