ユーザインタフェースをデザインし、
機能仕様書を書き、
開発チーム間の調整をし、
顧客の声を代弁し、
バナナ・リパブリックのチノパンを履く
ということだ。
小さな製品であればプログラムマネージャは1人でよいかもしれないが、大きな製品となると、何人ものプログラムマネージャが必要になる。それぞれの人は、機能の一部分を受けもつ。プログラムマネージャ1人についてプログラマが4人というのが目安だ。仕事を分割するのが難しい場合には、これは私がMike Conteに教わったことなのだが、製品をユーザのアクティビティに応じて分割するとよい。たとえばTwitterは次の4つのユーザアクティビティに分割できる[3] 。
ユーザ登録して使い始める
メッセージを投稿し、返信を読む
アカウント設定をする
ニュースを検索する
Tyler Griffin Hicks-Wright
Microsoftで私がした最初のプログラムマネージャの仕事は、Excelの「カスタマイズ」というユーザアクティビティ、すなわちスクリプティングとマクロ機能の開発だった。私がまずしなければならなかったことは、顧客が何を必要としているかを明らかにするということで、その方法は、できるだけ多くの顧客から話を、同じことばかり耳にするようになってうんざりするまで聞くということだった。メジャーリリースの間の18ヵ月間にどれだけの機能を実装することが可能であり妥当であるかを見極めるため、多くの時間を使ってExcel開発チームと話をした。そして多くの時間をVisual Basicチームとの会話に費やし、Excelのマクロ言語で使えるコンパイラ、コードエディタ、ダイアログボックスエディタを提供してもらうための相談をした。私はまた、当時AppleScriptという汎用のマクロ言語を開発していたAppleとも話をした。そのほかいくつものMicrosoft 内の開発チームとも話をした。主なものを挙げると、Word、Access、Project、Mailだ。これらのチームはだいたいにおいてExcel チームのやっていたことは何でもやっていた。このプロセスは、話すということがほとんどを占めていた。ミーティングにメールに電話。このとき以来、私は電話が鳴りはしないかオフィスの中でびくびくするようになった。
次のステップはビジョンを書き出すことだった。Visual Basic がExcelの中でどのように機能するのか、マクロの例はどんなものか、作らなければならない主立ったものは何か、それは顧客の問題をどのように解決するのか、そういった概要を書いたドキュメントを作るのだ。そこであまり異議が持ち上がることもなかったので、私はより詳細な仕様書の作成に取りかかった。ユーザから見てどのようなものになるかを詳細に渡り記述したドキュメントだ。
これは機能仕様書であって技術仕様書ではない。つまり、ユーザから見てどうかということだけを扱い、どのように実装するかには触れない（機能仕様書については「やさしい機能仕様」 ） 。プログラムマネージャは開発チームが中身をどう実装するかは気にかけない。私が仕様書の1章を開発チームのリーダーであるBen Waldmanに送ると、彼のチームが腰を据えてその実現のために内側でしなければならないことを考えるのだ。彼らは私の定義したオブジェクト指向インタフェースをExcel の内部の関数へとマッピングするとてもコンパクトで見事なテーブルを考え出したが、その辺のことは私の関与するところではなかった。私はExcel の内部についてはあまり知らなかったし、どのように実装すべきなのかもあまりよくわかっていなかった。
本当のことを言うと、何に関してであれ、あまりよく知らなかった。大学を出たばかりであり、プログラムを書くことにも、テストすることにも、ドキュメントを書くことにも、製品のマーケティングをすることにも、ユーザビリティテストをすることにも、十分な経験を積んではいなかった。幸いにして、Microsoftにはこれらのそれぞれについて深く経験を積んでいるグルたちがおり、私が今日知っていることはすべて彼らが教えてくれた。そして彼らは素晴しい製品を作り出す実際の作業を行った。たとえば、ユーザはスプレッドシートのセルの値を変数にコピーしたいだろうことはわかっていた。
こうできる必要があった。問題は、セルには数値も文字列も格納できたが、Basicのほうはアーリーバインドだということだった…。変数xを使う前に、それがIntegerなのかFloatなのかStringなのかを、あらかじめDIMで宣言しておく必要があった。
Basicにある種の動的型を導入する必要があったのだが、どうすればいいか考え出せるほど私は頭が良くはなかった。しかしそれも問題なかった。Visual BasicチームのプログラマであるTom Corbettがその方法を考え出してくれた 。そうしてVariant型とIDispatchが生まれ、Basicは今どきの人たちが「ダックタイピング」と呼んでいるものを持つ動的言語となった。ここでの要点は、私の仕事は問題を解くことではなかったということだ。顧客が何を必要とするかを見極め、プログラマたちがその解決方法を見出せるようにするのだ。
仕様書が完成して開発チームが仕事に取りかかるようになると、私の果たすべき役割は2つになった。デザインについて持ち上がる疑問は何であれ解決することと、（ 開発者がそうしなくて済むように）ほかの開発チームと話をすることだ。テスタたちにプログラムがどのように動くべきであるかを説明して、どのようにテストするか彼らが計画する手助けをした。ドキュメンテーションチームと話をし、Excel Basicの良いチュートリアルやリファレンスをどう書けばよいかを把握してもらった。ローカライズの専門家たちと会って、ローカライズのための戦略を決めるために話し合った。マーケティングの人たちと話をし、VBAのマーケティング上の利点について説明した。ユーザビリティの専門家たちと一緒になって、ユーザビリティテストの準備をした。
プログラムマネージャはたくさんのミーティングに出ることになるが、仕様書以外にはあまり作るものがない。私のような大学を出たてのぼんくらでもやり遂げられたのはそれが理由だ。プログラムマネージャをやるためには、14年の経験を積んだベテランプログラマである必要はない（実際のところ、14年のプログラミング経験がある人間は、ユーザの良い代弁者となるにはものを知り過ぎているだろう） 。
議論
プログラムマネージャがいないと、頭の良いプログラマたちは、スタートレックに出てくるバルカン人向けとでもいうようなまったく難解なユーザインタフェースを作りがちだ（例: git） 。優れたプログラマというのは頭脳明晰で、16個ばかりの1文字からなるコマンドライン引数も記憶できないというのがどんなことなのか想像もできない。そしてそういったプログラマたちは自分の最初のアイデアに執着する傾向がある。コードを書いてしまっている場合は特に。
プログラムマネージャがソフトウェアデザインプロセスにもたらしうる最良のことが何かというと、どのようにデザインすべきかについてのセカンドオピニオンだ。manページを読んだり、カスタマイズのためのemacs-lisp関数を書いたり、頭の中で数値を8進数に変換したりしなくてもアプリケーションが使えなきゃ困る知恵遅れのユーザに共感できる人間の意見だ。
良いプログラムマネージャはユーザインタフェースがどう機能すべきかについて自分の考えを持っている。それは開発者の考えより良いものかもしれないし、まずいものかもしれない。そして長い議論が行われる。一般にプログラムマネージャは何かシンプルでユーザにわかりやすいものを求める。テレパシーで操作できることとか、ポケットにすっぽり収まる30インチ画面とかいったものだ。一方開発者のほうはコードで容易に実現できることを求める。コマンドラインインタフェースとか（「 どこが使いにくいって言うの？」 ） 、Pythonバインディングとかだ。
私が覚えているExcel 5プロジェクトにおけるもっとも大きな議論は、ピボットテーブルをスプレッドシートの上のドローイングレイヤに置きたいプログラマと、ピボットテーブルはスプレッドシートのセルになきゃいけないというプログラムマネージャの間の議論だ。この議論は本当に長い間続き、最後にはプログラムマネージャのほうが勝ったのだが、最終的なデザインはもともとのデザインよりずっと良いものになった。
議論が敬意を持って、事実に基づいて理性的に行われるためには、プログラムマネージャと開発者が対等であることが絶対的に重要だ。プログラムマネージャが開発者の上司だとしたら、議論のいずれかの時点で、プログラムマネージャはめんどくさくなって単に「もう議論はたくさんだ、俺のやり方でやるぞ」と言うかもしれない。対等であれば決してそういうことにはならない。法廷のようなものだ。一方の弁護士が判事を兼ねたりはしない。そして真実は対等な者の間の議論を通してもっともよく明らかにされるのだという考えに基づいて我々は働いている。どちらも不公平な利点を持たないときにのみ議論は公正になり得るのだ。
これは重要なことだ。高校2年のとき同級生だったサリーは今どうしてるんだろうと空想にふけっていたのなら、目を覚ましてもらいたい。彼女ならスコッツデールで生物療法士をしていて共和党員だ。さあ、ちゃんと注意して。プログラマがプログラムマネージャの部下であってはいけないということは、すなわち、開発リードやCTOやCEOは、仕様書を書く人間ではありえないということだ。
多くの会社が犯している一番の誤りは、プログラマのマネージャに仕様書を書かせ、製品のデザインをさせるということだ。これが間違いであるのは、デザインが公正な審判を受けることなく、対立と議論を通して生み出されないためだ。そのためあり得べき最良のデザインとはならない。
私はこのことを苦い体験を通して学んだ。Fog Creek Softwareにおいて、私はプログラムマネージャの仕事の多くを私自身がこなしてきた。私が間違ったことをしているときには、私と議論しなければならないのだとみんなに思い起こさせるのに苦労した。私たちの会社は大きくないが、今やようやく、DanとJasonという、本当のプログラムマネージャを持てるくらいに大きくなった。そしてプログラマたちは彼らとよろこんで議論している。
もちろん、プログラマがプログラムマネージャと対等な場合には、プログラマのほうが主導権を握ることも多い。プログラムマネージャとの議論に決着をつけてくれるようにとプログラマが私に頼みにくることがときどきある。
「コードを書くことになるのは誰？」と私は尋ねる。
「私です…」
「じゃあ、ソース管理にチェックインするのは？」
「私、でしょうね…」
「それなら何が問題なの？」と私は言う。「 君は最終製品のあらゆる点について絶対的なコントロールを握っているわけだけど、あとほかに何がいるの？ 王冠かい？」
このやり方はプログラムマネージャにプログラマを説得するという重荷を負わせることになる。プログラマがうんざりし、やりたいようにやるようになるというリスクがあるのだ。だから力を持ったプログラムマネージャになるためには、（ a）正しく、（ b）プログラマからの尊敬を勝ち取る必要があり、そうでなければ自分が正しいことを認めさせることはできない。
どうすれば尊敬を勝ち取ることができるのか？
プログラムマネージャ自身がプログラミングに優れているということは役に立つ。これはフェアでないかもしれない。プログラムマネージャは本来コードを書く人間ではないからだ。しかしプログラマは、頭の良し悪しとは関係なく、プログラマでない人間よりプログラマにずっと敬意を払う傾向がある。プログラムが書けなくとも力のあるプログラムマネージャになることは可能だが、プログラミングチームから尊敬を勝ち取るためのハードルはずっと高くなる。
プログラミングチームの尊敬を勝ち取るもう1つの方法は、議論において知性と心の広さと公正さを示すことだ。プログラムマネージャが間抜けなことを言うと、プログラマはボゾビットを立てる[4] 。プログラムマネージャが何かのやり方に個人的、感情的にこだわり、合理性を欠くなら、信頼を失うことになる…。どちらの側にも言えることだが、とくにプログラムマネージャは、議論に感情的にならず、新たな証拠を進んで検討し、事実が示す場合には考えを改める必要がある。そしてもしプログラムマネージャが政治的に振る舞い、事実に基づいて議論するのでなく、上司と秘密裏の会合をしたり、人々を分断することで議論に勝とうとしたりするなら、プログラマたちから信頼をすっかり失うことになるだろう。
そしてプログラムマネージャは、プログラミングチームからの信頼を失ったら、それで終わりだ。そのようなプログラムマネージャが力を発揮することはない。プログラマたちは背を向けて自分のしたいようにする。これはまずいプログラムと無駄な時間をもたらす。機能しないプログラムマネージャの招集するミーティングでみんな時間を奪われることになるが、それでプログラムが少しでもよくなることはないからだ。
仕様書？ マジで？ アジャイルじゃないね
仕様書が無意味な官僚的ペーパーワークの結果であるような開発組織はあまりに多く、仕様書を書かないという考えを中心とした運動が起きた。しかしこれは見当違いだ。機能仕様書を書くことはアジャイルな開発の中心であり、それはコードを書く前にたくさんの可能なデザインを素早く検討できるからだ。コードと比べ、仕様書はずっと簡単に変更できる。仕様書を書くという行為自体が、頭の中にあるデザインについてじっくり検討することを強い、デザインにある欠陥を素早く見つけ出すのを助け、より多くのデザインを試せるようになる。機能仕様書を使う開発チームはより良くデザインされた製品を生み出す。より多くの可能な解法をすばやく探索するチャンスがあるためだ。彼らはまたコードをより早く書けるが、それは何が必要になるかについてより明快なイメージを持っているからだ。機能仕様書は非常に重要であり、「 仕様書なしにはコードを書かない」というのがFog Creekにおける数少ない絶対的ルールの1つになっている。
機能仕様書が具体的に取る形態はさまざまであり得る。機能仕様書がすべきことは、プログラムがどのように振る舞うか説明するということだ。内部的にどういうしくみなのかについては何も言わない。機能仕様はもっとも高いレベルのビジョンの記述（ 1ページに収まる新機能の説明） から始まる。ビジョンが定まったら、ストーリーボードを作成する…。ユーザがアプリケーションをどう使うかを示した画面のモックアップと動きについての詳細な説明だ。多くのタイプの機能、特にユーザインタフェースが中心となる機能については、このストーリーボードができれば仕様は完成する。Jason Fried、もうプログラムを書いてもいいよ 。
良い機能仕様書の書き方については、私の4部作[5] を読んでほしい。私の書く典型的な仕様書が見たければ、Fog Creek Copilotの完全な仕様書がダウンロード できる。
ユーザインタフェースのストーリーボードでは表現できない隠れた振る舞いを持った複雑な機能については、もっと詳細に書き留めたくなるだろう。いずれにせよ、仕様を書き出すという行為自体が、問題点や矛盾や設計上の問題を、コードを書き始めるずっと前に見つけ出せるようにしてくれる。だからコードを書く時点では、予想しないような問題が現れてコードを書き直したり、最適でないデザインに甘んじるというようなことはずっと少なくなる。
どうしたらプログラムマネージャになれるか？
プログラムマネージャになるために必要なことの大部分は学習だ。テクノロジについて学び、人間について学び、政治的な組織にあってどうすれば力を発揮できるかを学ぶ。良いプログラムマネージャは技術的なデザインを行うエンジニアのアプローチと、コンセンサスを築き人々をまとめる政治家の能力を併せ持つ。これに取り組む上で読んでおくべき本がいくつかある。
プログラムマネージャがする仕事についてよくカバーしている本は、私の知る限りではScott Berkun の"Making Things Happen" だけだ[6] 。この本から始めるといい。Scott はInternet Explorerチームのプログラムマネージャを長年務めていた。
プログラムマネージャのもう一つの大きな仕事は、ユーザインタフェースのデザインだ。これについてはSteve Krug の本"Don't Make Me Think: A Common Sense Approach to Web Usability"（翻訳『ウェブユーザビリティの法則』 ／ソフトバンククリエイティブ、2007年）と、それに私の本"User Interface Design for Programmers"（Apress, 2001 年）を読んでほしい。
最後に、安っぽく見えることは承知しているが、Dale Carnegie（デール・カーネギー）が1937年に書いた「人を動かす」（ 創元社 1999年）を、対人スキルを磨くための素晴しい入門書として挙げておこう。Fog Creekにおけるマネジメントのトレーニングで最初に読ませている本がこれだ。読むように言うとみんな笑うのだが、読み終わったときにはみんなこの本が好きになっている。
