Pick Up Entry from "Joel on Software"

翻訳エッセイ編―プログラムマネージャになるには

優れたプログラムマネージャを擁しているということは，素晴しいソフトウェアを生み出すための秘密の公式だ。あなたのチームにはそういう人がいないかもしれない。ほとんどの開発チームには優れたプログラムマネージャがいないのだから。

Charles Simonyi は優れたプログラマであり，WYSIWYGワープロを生み出し，Martha Stewartと付き合い，Microsoftの株で何十億ドルという金を手にして宇宙にまで行った男だが，彼は大きなソフトウェア開発チームの管理における『人月の神話』（注1）の問題を解決しようと，超優秀なプログラマを1人置いて最上位の関数を書かせ，下位の関数の実装は必要に応じてチームの下っ端プログラマにやらせるという方法をとった。この超優秀なプログラマの役職がプログラムマネージャと呼ばれた。Simonyi自身は優れた人間であるにしても，彼のこのアイデアはそうでもなかった。誰だって下っ端の下請けプログラマなんかにはなりたくない。

80年代後半になって，Mac版Excelの開発チームにいたJabe Blumenthalが，この役職を別な役割に再利用した。ソフトウェア開発は非常に複雑なものとなっており，使いやすく役に立つソフトウェアを作るにはどうすればよいか考えている時間がプログラマにはないということに彼は気付いた。マーケティングチームは顧客の求めていることについて喚わめいたり呻うめいたりしていたが，彼らの話すMBA語を実際の機能へと翻訳している暇のある人間は誰もいなかった。製品デザインのための仕事はたくさんあり，多くの作業が必要だった。ユーザと話をし，ユーザビリティテストを行い，競合製品を評価し，物事をより簡単にする方法を熱心に考えなければならなかったが，ほとんどのプログラマにはそのための時間がなかった（それにまた，そういったことが得意でもなかった）。Blumenthalは「プログラムマネージャ」という名前をこの役割のために使ったが，中身は前とすっかり違ったものになっていた（注2）。

注1）

『人月の神話―狼人間を撃つ銀の弾はない』／Frederick Brooks 著／ISBN4-7952-9675-8／ピアソンエデュケーション／1996年2月発売

注2）

この辺の歴史についてもっと詳しいことは，William Poundstoneの『 ビル・ゲイツの面接試験―富士山をどう動かしますか？』（ISBN4-7917-6046-8／青土社／2003年6月発売）を見てほしい。

プログラムマネージャは何をするのか？

このとき以来，プログラムマネージャたちがやっているのは，

1. ユーザインタフェースをデザインし，
2. 機能仕様書を書き，
3. 開発チーム間の調整をし，
4. 顧客の声を代弁し，
5. バナナ・リパブリックのチノパンを履く

ということだ。

小さな製品であればプログラムマネージャは1人でよいかもしれないが，大きな製品となると，何人ものプログラムマネージャが必要になる。それぞれの人は，機能の一部分を受けもつ。プログラムマネージャ1人についてプログラマが4人というのが目安だ。仕事を分割するのが難しい場合には，これは私がMike Conteに教わったことなのだが，製品をユーザのアクティビティに応じて分割するとよい。たとえばTwitterは次の4つのユーザアクティビティに分割できる（注3）。

1. ユーザ登録して使い始める
2. メッセージを投稿し，返信を読む
3. アカウント設定をする
4. ニュースを検索する

Microsoftで私がした最初のプログラムマネージャの仕事は，Excelの「カスタマイズ」というユーザアクティビティ，すなわちスクリプティングとマクロ機能の開発だった。私がまずしなければならなかったことは，顧客が何を必要としているかを明らかにするということで，その方法は，できるだけ多くの顧客から話を，同じことばかり耳にするようになってうんざりするまで聞くということだった。メジャーリリースの間の18ヵ月間にどれだけの機能を実装することが可能であり妥当であるかを見極めるため，多くの時間を使ってExcel開発チームと話をした。そして多くの時間をVisual Basicチームとの会話に費やし，Excelのマクロ言語で使えるコンパイラ，コードエディタ，ダイアログボックスエディタを提供してもらうための相談をした。私はまた，当時AppleScriptという汎用のマクロ言語を開発していたAppleとも話をした。そのほかいくつものMicrosoft 内の開発チームとも話をした。主なものを挙げると，Word，Access，Project，Mailだ。これらのチームはだいたいにおいてExcel チームのやっていたことは何でもやっていた。このプロセスは，話すということがほとんどを占めていた。ミーティングにメールに電話。このとき以来，私は電話が鳴りはしないかオフィスの中でびくびくするようになった。

次のステップはビジョンを書き出すことだった。Visual Basic がExcelの中でどのように機能するのか，マクロの例はどんなものか，作らなければならない主立ったものは何か，それは顧客の問題をどのように解決するのか，そういった概要を書いたドキュメントを作るのだ。そこであまり異議が持ち上がることもなかったので，私はより詳細な仕様書の作成に取りかかった。ユーザから見てどのようなものになるかを詳細に渡り記述したドキュメントだ。

これは機能仕様書であって技術仕様書ではない。つまり，ユーザから見てどうかということだけを扱い，どのように実装するかには触れない（機能仕様書については「やさしい機能仕様」を参照してほしい）。プログラムマネージャは開発チームが中身をどう実装するかは気にかけない。私が仕様書の1章を開発チームのリーダーであるBen Waldmanに送ると，彼のチームが腰を据えてその実現のために内側でしなければならないことを考えるのだ。彼らは私の定義したオブジェクト指向インタフェースをExcel の内部の関数へとマッピングするとてもコンパクトで見事なテーブルを考え出したが，その辺のことは私の関与するところではなかった。私はExcel の内部についてはあまり知らなかったし，どのように実装すべきなのかもあまりよくわかっていなかった。

本当のことを言うと，何に関してであれ，あまりよく知らなかった。大学を出たばかりであり，プログラムを書くことにも，テストすることにも，ドキュメントを書くことにも，製品のマーケティングをすることにも，ユーザビリティテストをすることにも，十分な経験を積んではいなかった。幸いにして，Microsoftにはこれらのそれぞれについて深く経験を積んでいるグルたちがおり，私が今日知っていることはすべて彼らが教えてくれた。そして彼らは素晴しい製品を作り出す実際の作業を行った。たとえば，ユーザはスプレッドシートのセルの値を変数にコピーしたいだろうことはわかっていた。

• x = [A1]

こうできる必要があった。問題は，セルには数値も文字列も格納できたが，Basicのほうはアーリーバインドだということだった…。変数xを使う前に，それがIntegerなのかFloatなのかStringなのかを，あらかじめDIMで宣言しておく必要があった。

Basicにある種の動的型を導入する必要があったのだが，どうすればいいか考え出せるほど私は頭が良くはなかった。しかしそれも問題なかった。Visual BasicチームのプログラマであるTom Corbettがその方法を考え出してくれた。そうしてVariant型とIDispatchが生まれ，Basicは今どきの人たちが「ダックタイピング」と呼んでいるものを持つ動的言語となった。ここでの要点は，私の仕事は問題を解くことではなかったということだ。顧客が何を必要とするかを見極め，プログラマたちがその解決方法を見出せるようにするのだ。

仕様書が完成して開発チームが仕事に取りかかるようになると，私の果たすべき役割は2つになった。デザインについて持ち上がる疑問は何であれ解決することと，（開発者がそうしなくて済むように）ほかの開発チームと話をすることだ。テスタたちにプログラムがどのように動くべきであるかを説明して，どのようにテストするか彼らが計画する手助けをした。ドキュメンテーションチームと話をし，Excel Basicの良いチュートリアルやリファレンスをどう書けばよいかを把握してもらった。ローカライズの専門家たちと会って，ローカライズのための戦略を決めるために話し合った。マーケティングの人たちと話をし，VBAのマーケティング上の利点について説明した。ユーザビリティの専門家たちと一緒になって，ユーザビリティテストの準備をした。

プログラムマネージャはたくさんのミーティングに出ることになるが，仕様書以外にはあまり作るものがない。私のような大学を出たてのぼんくらでもやり遂げられたのはそれが理由だ。プログラムマネージャをやるためには，14年の経験を積んだベテランプログラマである必要はない（実際のところ，14年のプログラミング経験がある人間は，ユーザの良い代弁者となるにはものを知り過ぎているだろう）。

注3）

「製品デザインプロセス」