私はかなり謙虚な人間なので、ほとんどの人は私についてのこの非常に印象的な事実を知りません。あのレイモンド・チェンが、Windows開発の古典的ブログである『The Old New Thing』で、一度だけ私のことに言及してくれたのです。

いえ、彼は私の名前を出したわけでも、私を特定できるような形で触れてくれたわけでもありません。でも、この素晴らしい偉業についてほとんど自慢しないのですから、私はやはり称賛に値するでしょう。

解決しようとしていた問題

記事の中でレイモンドは私のことを「ある顧客」と書いていましたが、実際は当時同じマイクロソフトの社員でした。私は23歳で、大学を出て最初の職場であるマイクロソフトで開発者として2年目を迎えようとしているところでした。

私はBitLocker、すなわちWindowsのドライブを暗号化する機能を担当していました。当時はWindows 8の開発が始まったばかりで、私のプロジェクトはBitLockerの設定体験を改善することでした。

BitLockerには、管理者が組織全体の設定（Windowsの用語でいうグループポリシー）を通じて構成できる、数多くの設定項目がありました。たとえばIT管理者が「組織内の全員のBitLockerパスフレーズは12文字以上でなければならない」といったルールを組織全体に適用すると、BitLockerはユーザーに12文字以上のパスフレーズの作成を強制するのです。

BitLockerの設定で頭を悩ませていたことの一つは、エラーメッセージが曖昧だったことです。たとえば、パスフレーズは最低でも1000文字必要だといったルールを設定しようとすると、BitLockerは「いや、それは長すぎます」といったエラーを返すだけで、上限が何なのかは教えてくれないのです。

マイクロソフトでは、C++のコード内にエラーメッセージを直接書くことはできませんでした。ローカリゼーションチームがユーザー向けのテキストをすべて他言語に翻訳する必要があったからです。そのため、ユーザー向けのテキストはすべて次のような.mcファイルに置かれていました。

SymbolicName=ERROR_BITLOCKER_PASSPHRASE_MINIMUM_TOO_LONG
The BitLocker minimum passphrase length is too high.
.
SymbolicName=...

そしてC++コードのどこかでは、次のようなチェックを行っていました。

#define MAX_PASSPHRASE_MINIMUM 20

UINT32 minimumPassphraseLength = ReadGroupPolicy(GP_BITLOCKER_MINIMUM_PASSPHRASE_LENGTH);
if (minimumPassphraseLength > MAX_PASSPHRASE_MINIMUM) {
  ShowError(ERROR_BITLOCKER_PASSPHRASE_MINIMUM_TOO_LONG);
}

私はBitLockerのエラーメッセージを、エラーが発生した理由について具体的な情報をユーザーに伝えるものに変えたいと思いました。つまり、こう表示される代わりに、

The BitLocker minimum passphrase length is too high.

ユーザーにはこう表示したいと思ったのです。

The BitLocker minimum passphrase length cannot exceed 20.

C++コードにある20という値を.mcファイルにコピーしたくはありませんでした。なぜなら、後でMAX_PASSPHRASE_MINIMUMの値を変更したときに、.mcファイル側と同期が取れなくなり、エラーメッセージが誤ったものになってしまうからです。

レイモンド・チェンが関わることになった経緯

.mcファイルを処理するMessage Compilerというツールについて、私はあまり詳しくありませんでした。C++の値を.mcファイルで参照している例も見つからず、それでも何か方法があるはずだと思っていました。

私は社内のメーリングリストで、.mcファイルを次のように書けないかと質問しました。

SymbolicName=ERROR_BITLOCKER_PASSPHRASE_MINIMUM_TOO_LONG
The BitLocker minimum passphrase length cannot exceed ${MAX_PASSPHRASE_MINIMUM}.

レイモンド・チェンはこれらのメーリングリストに頻繁に投稿していました。2009年の時点ですでにマイクロソフトに長く在籍し、Windows開発に関するあらゆることに百科事典のような知識を持っていました。彼の返信は役に立ち、権威がありましたが、自分で十分に調べずに質問したと彼が判断した場合は皮肉っぽくもありました。

記憶が正しければ、レイモンドは私のスレッドに「プリプロセッサを使ってはいけないという決まりはない」と素っ気なく返信し、プリプロセッサのコマンドで.mcファイルを生成する例を示してくれました。

彼が何を言おうとしているのかを理解するのに、しばらく時間がかかりました。C++コンパイラに前処理のステップだけを実行させることができるなんて、知らなかったのです。

レイモンド・チェンの時間を無駄にしたこと

この話の恥ずかしい部分は、偉大なレイモンド・チェンからアドバイスをもらったにもかかわらず、私が怖気づいてそれを使わなかったことです。

レイモンドのブログ投稿では、Makefileの数行を書き換えるだけで、ソースファイルを.mcファイルではなく.mcpファイルにするのがいかに簡単かが示されていました。簡単そのものです！

Windowsのビルドシステムは、Makefileとは比べものにならないほど無限に複雑でした。どんな見た目だったかはもう覚えていませんが、恐ろしくて混乱させられるものだったということだけは覚えています。

さらに悪いことに、ビルドを壊してしまうと、翌朝「ナイトリービルドを壊しました」と知らせるメールが届くまで気づかないこともありました。そしてあなたのせいで、その日のWindowsビルドを何十人、何百人もの人が入手できなくなってしまうのです。

そこで私は選択を迫られました。ビルドシステムで誰もやったことのない新しいことを最初に試し、予期せぬ問題の修正に1、2週間を費やすリスクを負うか。それとも、BitLockerのエラーメッセージに具体的な数値を入れるというアイデア自体なかったことにして、設定を簡単にする別の方法に集中するかです。

私は後者を選びました。

今でも解き方はわからない

当時は「うわ、Cプリプロセッサをこんなふうに使えることを知らないなんて、自分はなんてバカなんだ」と思ったのを覚えています。

たいていの場合、何年も前に悩んだソフトウェアの問題を振り返ると、今では解決策がよりはっきりと見えます。たいてい、より良い解決策を思いつくことができます。

しかし16年経った今でも、CプリプロセッサをC/C++以外のファイルに対して実行するというレイモンドの解決策は、やはり意外に感じられます。レイモンド・チェンのこの記憶だけを除いた今までのすべての経験を持った状態で、もう一度この問題を解けと言われても、2009年と同じくらい苦労すると思います。

今との違いは、この問題の解き方を知らなかったからといって、自分をバカだとは思わなくなったことです。今ではそれを、マイクロソフトの社内ツールの弱点だと捉えています。マイクロソフトの看板製品で、なぜ開発者がエラーメッセージとC++コードの両方で定数値を参照するための標準的な方法がなかったのでしょうか。

ソフトウェアエンジニアとして、嫌な問題でも歯を食いしばって練習し、上達していくべき問題もあります。一方で、引き受ける仕事やプロジェクトを慎重に選ぶことで、ただ避ければいい問題もあるのです。

難解なビルドシステムを理解することは、私が避けてきた問題の一つであり、それで構わないと思っています。Nixを使うときを除いては。