■2004年5月から1年間，「Visual Studio 2005」の開発者の方々に，リレー・エッセイを執筆してもらった。今回はベータ2が春に完成し，連載が一巡したこともあり，お互いの感想や書き足りなかったことを語ってもらった。
————昨年（2004年）春から1年間，マイクロソフト プロダクト ディベロップメント リミテッドの皆様に，『Visual Studioの開発現場から』というエッセイを書いていただきまして，ありがとうございました。 開発作業真っ只中の大変お忙しい時に，当事者の方が現場の話を書くのはとても珍しいことだったのではないでしょうか。最近，これらのエッセイが，小誌が編集するムック「完全詳説！Visual Studio 2005＆SQL Server 2005」（該当サイト））にも収録され，発売されました。 今回は，改めてこのリレー・エッセイを振り返っていただいて，原稿を書いてもらった時の感想をお聞きしたいのと，みなさんの同僚のエッセイに対するご意見を聞きしたくて集まっていただきました。 さらに，現在も開発が続いております「Visual Studio 2005（VS 2005）」の進捗状況もお聞きできたらと思います。 ［鈴木氏］ベータ2のダウンロードが4月から始まりました。また先ほど紹介のあったムックにも「Visual Studio 2005 Team Suiteベータ2日本語版」と「SQL Server 2005 CTP日本語版」が付録DVD-ROMとして付いています。
いよいよ11月7日にラウンチ ［鈴木氏］「2005」という名前なので，今年中には出すぞと…（笑）ダウンロード開始とRTMはほぼ同じ，その約1～2カ月後に店頭に並びます。 ————2005年中に店頭に並ぶためには，11月末にはRTMするわけですね。 ［鈴木氏］ん～少なくともダウンロードは年内に…でも箱にはVS 2005年度と書いてあるかもしれません。もちろん年度と言う文字は読めないぐらい小さいフォントで。 ————Yukonが先に出るんですか？ ［鈴木氏］内部的な事情をいうと，うちが.NET framework 2.0を完成させない限り，Yukonは物理的に出せないはずです。しかし，われわれの開発がストッパーになることはないでしょう。ほぼ同時に出ると思います。
トップバッターは“理想的な組織論”
読者の反響が大きかった ［鈴木氏］他の会社のやっていることは，なかなか見られませんから。書いてある内容に同意するかどうかは別にして，この内容はためになったんじゃないでしょうか。自分の会社の方式が良ければ満足だし，他の会社の方式が良ければ，マネをすればいいんです。だから公開したことは良かったと思っています。 社内的にも反響がありました。営業部門やマーケティング部門の者が読んで「QAの仕事はああやっているのか」と分かってもらえました。 ————制御系の開発をしている読者の方は，自分のところが「その場しのぎ的町工場的な開発体制である。マイクロソフトの開発体制がうらやましい。ちゃんとした“ものづくり”をするには開発体制を見直していきたい」とコメントしてます。
［桜井氏］組織改革とかあって，方法論はよく変わりますよね。流行もあります。やってみて「これ必要ない」と分かったらやめます。 ［鈴木氏］うちはダメだとなったら，すぐに戻すよね。うん。 ［佐藤氏］それが早過ぎるという話があるけどね。 ［一堂］笑い ［頃末氏］読者の方のコメントで面白いなと思ったのは，この方はハードウエア・メーカーですよね。ハードウエアは，開発→テスト→製造という流れがあるんでしょうけど，ソフトウエアとなると，なかなかそういう手法が確立されていないのかもしれませんね。それが“日本の実情”なのかもしれませんね。 ［桜井氏］米国でもソフトウエアの開発は，なかなかそういう分業にならないところはあるよね。 ［一堂］うんうん。 ［根岸氏］いかにうちが分業体制をしているかという話ですが，これだけ大きな組織で，長いマイルストーンで，仕事をしていると，テストを何度も何度もやるんです。10分くらいで終わるテストを，まず20分くらいのミーティングから入ったりするんですよ（笑）。1人で職人的な考え方でパッとやってしまえば，終わるんですけど，組織でしっかりしたプロセスを立てて，何度も繰り返したり，同じことがあっても，同じに使えるようにするためです。同じ手法を他の製品のQA部隊にも伝えていって，統一したプロセスで動けるようにする。なかなか他の会社で見なかったことです。
製品とともに成長するテスト・ツール
————VS 2005にもテスト機能があります。それと社内で使っているテストの仕組みなどは似ていますか？ そのものではないですが，似ています。コードを書く開発者向けのテスト機能がありますが，それは近いものがあります。VSはソフトを作るソフトなので特殊ですよね。基本的な考え方は同じですけどね。 ［鈴木氏］テストの方式は，VSでも2005と2003で違うし，2003と2002でも違うんですよ。新しいものが加わって，毎回レベルアップして行くんです。しかし，考え方のベースは一緒です。オモテに出せるところは出していく。やっているものの中には，不安定なものもあるんですよ。それは社員が苦労しています。 ［橋本氏］内部的なテスト・ツールというのは，製品と同時に開発するんですよ。最後のRTMのころに，一番素晴らしいテスト・ツールになるんです。 ————なるほど… ［桜井氏］どうしてもプラットフォームや開発ツールの開発は，未完成なものの上で，未完成なものを作るというジレンマがあるんですよ。 ［鈴木氏］C#をテストするスクリプトを，C#で書いてあったりするんですよ。卵が先か鶏が先か… ［頃末氏］そもそもライブラリ自体が，C#なんですから。ジェネリックスをサポートしたコンパイラでないと，ジェネリックスをコンパイルできない。っというのをずっと繰り返してます。開発ツールはどうしてもそれをまぬがれないですよね。 ［橋本氏］開発と同時にテストしていると，どういう結果が正しいのか，判断するのが難しいことがあります。推測しながら開発を進めていて，あいまいな問題があったら，しかるべきところに話を上げて，結論をスクリプトやツールに反映させます。 ドキュメントに関しても，製品が完成してから書けば楽なんですけど，開発途中の製品のドキュメントを同時に書いているんですよ。開発途中でも参照しますし，製品完成と同時にドキュメントも完成していなければならない。同時に走りつついかに精度をあげるかが，各チームのノウハウです。 ————読者の反応に「QAはデバッグ部門」ではないというのがありました。 ［鈴木氏］製品を出す立場の人はRPMというのがいるんですよ。QAとは別なんですよ。バグを直すかどうかを判断する人が別にいるんですよ。 ［頃末氏］汎用機の世界では，開発手法というのはある程度確立されています。バグ出しをしながら，修正して，スペックを変えてというのではありません。テストをして，バグを認定して，次の工程が認めてくれなければ先へ進めないというものです。 一方で，2～3人でガッと作る世界もあって，うちは，中間的な位置付けにいるんでしょうね。うちも製品が完成に近付くと，汎用機的な手法に近付いてきます。
テスト環境作りはシステム作りに通じるノウハウがいっぱい
————Sysprepを使ったテスト・システムを構築する話で，日経Windowsプロでもなじみのある話でした。Dドライブを使ったりと，いろいろ工夫をされていました。 ［福崎氏］社内でベスト・プラクティスという制度があるんですよ。いいものがあると共有して，他の部門で使えるようにするという制度です。テストを自動化するフレームワークを公開しています。
バグの数だけでなく重要度，深刻度も評価
肉眼で見て分からないくらい小さな文字が見えているとします。それだけで済むのか，それをクリックするとクラッシュするのか——によって違うわけです。 製品管理のために，どのテストが，どれだけ行われているかを表やグラフで数値化して，各部門のステータスを見えるようにするわけです。 ————本物のデータを出すとまずいんですよね。 ［根岸氏］実データを出してはいけないけど，ある程度本当の話にしなければいけないので，似たような傾向になるようにしています。 ［鈴木氏］あの企画が一番書いてほしかった企画なんだよ。品質の計測。 ————リアルな話でしたね。うちの会社にもあんなものが欲しいですよ。記者Aの原稿は，論理的な矛盾がいくつあって，誤字脱字がいくつあって，初校再校と校正が進むに従って，バグが減っていくというものです。 ［鈴木氏］そういうシステムがあればうちも採用したい（笑） ［根岸氏］他にも原稿を書く時に苦労したことがあります。用語が社内でしか通用しない言葉で，しかも英語なので，それを日本語にするのに苦労しました。 ［佐藤氏］社内で使っている用語は難しいよね。新入社員が入ってくると分からないですよ。OGFとかいわれても何の略か分からない。昔は用語集を配られたけど，今はどうなったかな。
どのバグを直すかという優先順位
よく知っているつもりでも，書くと大変でした。かかわっている人が多いので，莫大な人数がいます。それをどうやってマネージメントするのかに興味を持ってもらえるように書きました。分かってもらえたでしょうかね。 ————VS 2005ではないんですね！ ［鈴木氏］本当はここで，製品出荷1週間前のことを書いてほしかったんです。最後の最後にQAからバグが挙がってきて，それを直すのか直さないのか，そういうのをメインで書いてほしかった。そのバグは「ショー・ストッパー」なのかどうかと。 でもそんなことを書いていいのかなぁと… ［一堂］（笑） ［鈴木氏］そこでベータ版の話ならいいかなぁと。バグがあったら，次のベータ開発に生かせばいいという話になっています。本当に製品版でそんな判断をしているのだろうかと，お客さんは思うでしょうかね。 ［佐藤氏］そういうのを「トリアージ」というのですけど。病院にケガ人がたくさん担ぎこまれて，だれを先に治療に当たるかという話です。どのバグを先に直すかという話です。 グループごとに開発を進めていますが，製品出荷の2カ月前くらいになると，毎日代表者が50人くらい大部屋に集まって会議をするんですよ。バグの報告があって，それを直すとどのような影響があるかを議論して，直すとなったら，どの部門が明日何時までに何をするかを決めるわけです。 マイクロソフトのスタイルがベストかどうかは分からないんですけれども。少なくとも自分たちにとって一番合うやり方なんです。 1つの開発が終わった後に，開発スタイルがガラッと変わってしまうと，一人ひとりがどう対処していいか分からないと思います。開発スタイルを決めて，サイクルを決めて進めれば，「いまのマイルストーンはこれです」と言えば，開発者はパターンで分かります。この時期は「コードを一生懸命書かなければいけないんだ」とか，この時期は「コードを書くよりも1つでも多くのバグを消さなければいけないんだ」とか，1つのスタイルを提示できます。
隣は何をする人ぞ ［佐藤氏］1998年ごろは本当にそのような感じでしたね。マイクロソフトのスタイルは常に変わるんですよ。常にギリギリだし，常に変えている。全員が集まってうまくいっていたパターンが，今後使えるかどうか分かりません。もう一堂に会して自己紹介というのはないでしょうね。VSだけでも，ものすごい規模です。さらに製品同士の連携があります。 ————隣が何をやっているか分からないというのは具体的にどんな感じですか？ ［佐藤氏］コンポーネントを作っている人たちは，自分たちのコンポーネントの品質を上げることにフォーカスしていて，そのコンポーネントがどの製品に入るのか知らない人もいるわけです。一方で，製品の枠から見ていて，「何々エディション」にどのコンポーネントがそろっているかを見ている人もいます。 VSだといろいろなエディションがあります。プロジェクトの始めからどのエディションもビルドを作っていて，それが成長していくわけです。 現在どこの部門もいままでなかった問題に直面していると思います。そのたびにパターンを変えているんですよ。そうじゃないとエキサイティングじゃないですけどね。 ————いままで直面しなかったことにぶつかるというのはどんなことでしょうか ［佐藤氏］具体的にはいえませんが，例えばビルドのやり方をいろいろトライしていますね。ところが，新しいやり方をトライしたゆえの，予測できなかったいろいろな問題が出ることがあります。改善されると思ってやったんですけど，かえって別の問題がたくさん出たりもします。「そういう使い方は想定してなかったなあ」ということが見つかりますね。 ［根岸氏］やり方を変えてそれで成功することもありますよ。 ［佐藤氏］反省会というのをやって，トライしたことを評価して，トライして良かったとか悪かったとか，目的は良かったけどやり方は変えたほうがいいとか，いろいろあります。 ［鈴木氏］反省会を年に何度もやりますよね。「年に～」どころではないですけど。 ［佐藤氏］反省ばかりしている…（笑） ————反省会で，毎回挙がってくるけど，毎回解決できないこともありますか？ ［佐藤氏］8割くらいはそうですね ［根岸氏］なんだか人生論みたいですね。 ［桜井氏］日常生活にも役に立ちますよ。 ［佐藤氏］危険予知というか，リスク・マネジメントというか……出荷が近付くと，何が起こるか分からない。ちょっと直すと，直ることは分かっているけど，何が起こるか分からないので，直さないこともあります。 ［鈴木氏］直さないという決定は難しいですよね。昔，テスト・ツールでわがままを言って直したことがあります。初歩的なミスだったんですけど。結果として出荷が少し遅れました。いまはもうそんなことはできないですよね。 ［一堂］できないですよね。 ————雑誌の特集記事では「ちゃぶる」という言葉があります。「ちゃぶ台をひっくり返す」の意味で「ちゃぶる」というんです。 記者が特集記事を書いて，副編集長がそれを大幅に直して，ある程度完成が近付くと，編集長がチェックして調整する。ところが，編集長が「こんな特集ダメだよ…」ということがあってですね（笑）。めったにないですけど（笑）。ギリギリになってそう言われると，2日間くらいで一から書き直すことになるんです。 ［鈴木氏］うちも「ちゃぶる」を使おうか。RTM2日前ではダメだね。2年くらい前ならいいけど（笑）。 ————今回あきらめた機能には，どんなものがありますか。 ［頃末氏］あきらめたものはないですね。計画段階であったもので，やめたものはいっぱいありますが…（笑）
翻訳の苦労，日本語化の苦労 ［鈴木氏］いまは米国本社に行ってしまいました。書きはじめることは日本にいたんですけど… ————翻訳の話が面白かったですね。翻訳するべき項目がデータベース化されていて，誤った文字コードや，許されない語句を入れられないようになっているとか…。翻訳者とそのお膳立てをするローカリゼーション・エンジニアが分かれているところなどです。 ［鈴木氏］ローカリゼーション・エンジニアは，バグが出ると一番大変な部門ですね。一気に作業が集中します。 ————第7回「VS 2005日本語ベータ版ができるまでの裏話」は星 明弘さんでした。米国本社との橋渡しの話でしたね。
［鈴木氏］日本語版の開発は，英語版の開発と一緒にぴったりくっついていかないとだめなんですよ。 ［星氏］米国では人事異動が結構多くて大変です。去年，日本語版のためにこういう開発にしてほしいと，米国人に説明していても，異動で人が変わって改めて同じことを説明しなければいけないこともあります。英語版が出来て2カ月後に「それでは日本語版としてはダメだ」と言っても遅いわけです。 日本語版のためにトレーニングを組んだり，ドキュメントを配布しているんですけど，難しいところがありますね。日本だと引継ぎが常識ですけど，なかなか米国では人が変わると，自分のやり方で開発するように変わってしまう。ちょっと放っておくと，日本語化が難しいものが出来てしまいます。常に彼らに，日本語版というのを視線のどこかに映っているようにしなければいけない。 ［根岸氏］VSは，日本語化がきちんとしている方だと思います。米国人はローカリゼーションのことが頭から抜けてしまっていることがありますね。小さい製品ほどそうですよね。どんどん新しいテクノジが開発されているので，大変ですよ。 ［桜井氏］初期段階の日本語がきちんと通らないころから，取り組まないといけないですね。 ［頃末氏］汎用機的な，ウォータ・フォール型の開発だと，一度離れて見られて，日米で同期を取りやすいですけど。うちみたいな開発スタイルだと同期は課題ですね。 ————単純に文字のエンコーディングをユニコードにすればいいということではないんですね。 ［頃末氏］もう全然違いますね。 「xxxxを印刷します。プリンタxxxx上で」というヘンな日本語になってしまう。「This」という言葉が出てきて，それを訳していいのかどうか。エラー・メッセージを2つつなげると上手くいかなかったり。エラー・メッセージは2つに切ってはいけないというガイドラインはあるんですけどね。それを守らない奴が出てくるんです。
開発手法を製品化したTeam System ［鈴木氏］今日はいないですね。 ————Team Systemやコンサルティングの話でした。マイクロソフトのコンサルタント部門がコンサルティング・モデルとして「ソリューション・フレームワーク」を提案していて，その話が出てきます。 ［鈴木氏］Team Systemを今開発中なんですけど…それとソリューション・フレームワークは結構重なるところはあるんですね。それに沿っているというより，エッセンスが生かされているというところです。 実際の開発は毎年変わっていて，トライ＆エラーをやっています。一方，ソリューション・フレームワークは学術的なものですから。 ［佐藤氏］Team Systemは実際に運用するもので，まさに僕らがやって，成功していることを商品化しているわけです。 ［鈴木氏］われわれの開発手法を，他の部門がマネして採用することもありますよね。ただし，われわれはいつも新しいことに挑戦しているので，Officeの開発でわれわれと同じように新しいことに挑戦すると，エライことになるのでしょうね。実験的なことに挑戦するのは，われわれの仕事です。VS部門が，新しいことをやっていることが多いですね。
次々世代のことでお客様の声を聞く
［鈴木氏］桜井と頃末は，ちょっと時期が違うんですよ。僕らがVS 2003をやっているときに，彼らはVS 2005をやっているんですよ。僕らがいまVS 2005をやっている時に，その次をやっています。 ［桜井氏］ベータ1のころまでは重なっていますよ。 ————じゃあ「VS 2007」とか，「VS 2008」とかをやっているわけですか？ ［鈴木氏］番号はよく分からないですけれども…今回のVS 2005に入れられなかった機能をどうするか考えているんです。 ［頃末氏］いまお客様のところに行くと，2003を使っています。すると「それは前のバージョン。いや前の前のバージョンのことでぇ…」と会話が混乱して，分からなくなってしまいますよ。 ［桜井氏］Microsoftは米国の会社なので，日本法人は海外のものを輸入しているだけだろうと，誤解されてしまいます。そうじゃないことを伝えたかったわけです。 ————お客と話をされてご苦労されたことは？ ［桜井氏］お客様のところにいくと，技術的な啓蒙と思われてしまい，話が合わないことがありますね。われわれが「お客様の困っていることを教えてください」ということで，逆なんですよね。 ［鈴木氏］今使っている製品の使い勝手について，次のバージョンで解決してくれるわけでもないのに，そこで答えてくれるお客様がいるというのは，すごく感謝するべきことだよね。開発ツールのお客様は，自らも開発しているから事情を分かってくれるのかな。お客様から見ると，次の次のバージョンだもんね。ベータ1も出てないのに… ［頃末氏］ありがたいことですね。「今お答えいただいたことは，5年後に直ります」って言うわけです…（笑）。「5年間は直りません」というわけです。それでも話してくれるのは貴重ですね。VSを愛してくれる人だからですね。日本人はあまり文句はいいませんけどね。
日本文化も考えて日本語化する
［桜井氏］アメリカに乗りながら，日本化しなければいけない。本社に対して，前向きな調整をしていかなければいけないんですよ。答えていただけるお客さんがいる，それを米国に伝えるという仕事は幸せなことです。 どういった長期的なビジョンなのか，といった話から，すぐQAに伝える話があったりとかです。 ［頃末氏］ワールド・ワイドの製品ですから，日本では良くても，他の外国語版でダメだったりすることもあります。とてもストレスのたまる部署です。 10個リクエストして，1個入ればかなりいい——というくらい狭き門です。アメリカ人が言うことを聞いてくれないわけではなくて，いろいろなニーズを考えると，やっぱり入れないという結論になるわけです。 だからこそ，お客様に聞いて，どの機能が本当に重要なのか，ちゃんと聞いて，裏付けを取らないといけない。 日本のお客様が「印刷がどうも…」というと，アメリカ人からは「これからはペーパーレス時代ですよ」という答えが返ってきたり。「印刷でこの文字が出ない」と言うと。「それくらいいいんじゃない」と言われてしまったりします。 そこで「日本人は印刷が好きなんだ」と言うのではなくて，通勤中に読んだりするから，印刷できたほうがいいんだとか，そういう文化を伝えていかないと，米国に納得してもらえないわけです。すごく難しいんです！ ［桜井氏］上手く通ったときはうれしいね。 ［頃末氏］アメリカ人も，本当に大切なものは通しますよね。 ［桜井氏］本当に文化の違いを納得させるのは大変です。
［鈴木氏］新しい人は，まず，パスポートをとって日本に来てお客様に合ってもらうというのがいいなじゃなかな。そうしたら興味が沸くと思うんだよ。 ［頃末氏］お客様に会わせる前に，せめて名刺の渡し方くらいは，教えないとなぁ（笑）。 |
◆会社紹介◆
|
| 「マイクロソフト プロダクト ディベロップメント リミテッド」は，日本のマイクロソフトの中で研究開発を担当する会社。日本のマイクロソフトの組織は，2つの会社で成り立っており，ほかにマーケティング，製品の流通，サポート業務を担当している「マイクロソフト株式会社」がある。 |
