プログラムマネージャになるには

From The Joel on Software Translation Project

Jump to: navigation, search

Joel Spolsky / Fujimoto訳
2009年3月1日 月曜


優れたプログラムマネージャを持つことは本当に良いソフトウェアを作るための秘訣の一つだ。あなたのところには多分いないだろう。こういう人はほとんどのチームにはいないからだ。

チャールズ・シモニーはWYSIWYGなワープロを共同開発した頭のきれるプログラマで、マーサ・スチュワートとデートし、さらにマイクロソフトの株式で10億ドル儲けて宇宙へ行った男であり、また巨大なソフトウェアチームの人月の神話問題を、最上位の関数を書く超一流の上級プログラマを一人置いて、低いレベルの関数を必要に応じて下級の単純労働プログラマのチームに書かせることで解決しようとした最初の人でもあった。彼らはこの最上位の関数を書くプログラマのポジションをプログラムマネージャと呼んだ。シモニーは確かに頭が良かったけど、このアイデアはそれほどでもなかった。誰も下級の単純労働プログラマなんてものにはなりたくなかっただろう。

この経緯についてもっと知りたい人は、ウィリアム・パウンドストーンの「How Would You Move Mount Fuji?」を読んでほしい。

1980年代後半にMac版Excelチームにいたプログラマのヤーべ・ブルーメンソールは、この肩書を別の役職の名前として再利用した。彼はソフトウェア開発が複雑になりすぎていて、使いやすい/役立つソフトウェアを作るにはどうしたらいいのかを考える余裕のあるプログラマが全くいないことに気がついたのだ。マーケティングチームは顧客のニーズについて大ぼらを吹いたりたわごとをわめいたりしていて、誰も彼らと話したり、MBAの言葉を実際の製品の特色となるように翻訳したりする余裕などなかった。一方で、製品のデザインについては手のかかる仕事が山ほどあった。つまり、ユーザーと話し、ユーザビリティテストを行い、競合製品のレビューをし、そして「どうしたらもっと役に立つ製品が作れるのか」について知恵を絞って考えなくてはならなかった。しかし、ほとんどのプログラマには端的にそうする時間が無かった(それに彼らはこの仕事があまり得意ではなかった)。そこで、ブルーメンソールは「プログラムマネージャ」という名称を使いつつも、その仕事を全く新しく発明し直したのだ。

プログラムマネージャはどんな仕事をするのか?

この時より、プログラムマネージャは次の仕事をすることとなった:

  1. UIをデザインする
  2. 機能仕様書を書く
  3. チームをまとめる
  4. ユーザーの代弁者として仕える
  5. Banana Republicのチノパンをはく

小さな製品なら1人のプログラムマネージャで済むだろうけど、大きな製品となれば2人以上のマネージャがチームに入ることになるだろう。その場合はそれぞれが製品の機能の一部を担当するようにしてもいい。経験から言うと、だいたい4人のプログラマにつき1人のプログラ厶マネージャが必要になる。仕事を分割するのが難しいなら、これはマイク・コンテから学んだことなのだけど、製品をユーザーがやることの種類によって分けるのも一つの方法だ。例えばTwitterはこのやり方で4つに分けることができる:

  1. ユーザー登録して、Twitterをはじめる
  2. メッセージを投稿して返信を読む
  3. アカウントの設定をする
  4. ニュースを探す
09Meeting-thumbnail.JPG

私のマイクロソフトでの最初のプログラムマネジメントの仕事はExcel関係のもので、そこでは「カスタマイズ化」という名前で呼ばれていたもの——要するにスクリプト言語やマクロに取り組んでいた。最初に私がしなければならなったのは、顧客が何を求めているのかを把握することだった。そこで私は同じことを毎回聞いているせいで退屈になるまで、できるかぎり多くのユーザーと話してみた。それから、多くの時間を使って開発チームと話し合い、18ヶ月のリリースサイクルの間に実装できて、かつ合理的なものは何なのかを探り出そうとした。またVisual Basicチームともたくさんの時間を費して打ち合わせ、彼らがExcel上で使える、私達のマクロ言語のためのコンパイラやコードエディタやダイアログボックスエディタを用意できることを確かめた。さらに、AppleScriptという独自のユニバーサルなマクロ言語を開発していたAppleとも話し合わなければならなかったし、マイクロソフトの他のアプリケーションチーム(主にはWord、Access、Project、Mail。この連中は大抵の場合、Excelチームが取り組んでいることと全く同じことに取り組んでいた)とも話をした。この間ずっと私は会話したり、ミーティングを開いたり、メールしたり、電話で話したりしていたので、それ以来私はこれがトラウマになってしまった。今も電話が鳴りはしないかとオフィスで身をすくめているところだ。

次のステップはヴィジョン・ステートメントを書くことだった。これは大まかな内容の文書で、「このようにしてVisual BasicはExcel上で機能する予定です。マクロのサンプルをいくつか挙げると、こんな感じになってます。それから、これらが作らなくてはならない主な機能です。それでこれはこのようにしてユーザーの問題を解決します」というようなことを書くものだ。この文書に対してあまり反対が出なかったので、今度はもっと詳細な仕様書を作った。これは、製品の各部がユーザーにどのように見えるのかを、最も細かい部分にいたるまで説明するものだ。

ただし、これは機能仕様書であって技術仕様書ではない。だから、ユーザーから見たらどんなものになるのかは書いてあったが、どうやって実装するかについては書かかれていなかった(機能仕様書の全てを知りたい人はこちら)。プログラムマネージャは、開発チームがどのように機能を内部で実装するのかには関わらないのだ。私は開発チームのトップだったベン・ウォルドマンにこの仕様書を章ごとに送り、そしてウォルドマンのチームは腰をおろして、これを実現するために内部で何をすればいいのかを考える。実際、ウォルドマンのチームは私が定義していたオブジェクト指向なインターフェイスをExcelの内部関数にマップする、非常にコンパクトで優れたテーブルを考え出したのだけど、これは私とは何の関わりもないことだった。私はExcelの内部についてあまりよく知らなかったし、機能をどう実装すべきかなんてことは全く分からなかったからだ。

率直に言えば、私はどんなことについても全く分かっていなかった。大学を出たてで、コードを書いたり、テストしたり、ドキュメントを書いたり、製品のマーケティングをしたり、ユーザビリティテストを行ったりするだけの経験がなかった。幸運なことに、マイクロソフトのこの各ポジションには経験豊かなグルがいた。私は彼らから今日私が知っていることを全て教えてもらったのだ。しかも、彼らはすばらしい製品を作り出すという本物の仕事をやっていた。例えば、私はユーザーがスプレッドシートのセルの値を変数にコピーしたがるだろうということを知っていた。つまり、

x = [A1] 

これが動かなくてはならない。問題は、セルには数字や文字が入りうるということだ。しかし、Basicは静的型付けの言語で……まず先にxが整数なのか浮動小数点数なのか文字列なのかを宣言しなくてはならなかった。

つまり、Basicに動的型付けを導入しなくてはならなかったのだけど、私は当時どうやったらそんなことができるのかが分かるほど賢くはなかった。けどそんなことは問題じゃない。Visual Basicチームのトム・コーベットがやり方を見付けだしたのだ。そしてVariantsとIDispatchが生まれ、Basicはあなたがた若い連中が「ダック・タイピング」と呼んでいる機能を備えた動的型付け言語となった。要するに、私の仕事においては問題を解く必要が無かった。やるべきことは、ユーザーが何を求めているのかを探り出して、プログラマ達がその解決法を見付けられるかどうかを確かめることだけだった。

仕様書ができあがるとすぐに開発チームが本腰をあげて動き出した。私は次の二つのことに責任を負っていた: デザインに関して出てきた疑問点を全て解決することと、開発チームの代わりに他の全てのチームと話し合っておくことだ。私はテスターと会って機能がどう動くのかを説明し、あらゆる部分をテストするためのプラン作りに協力した。ドキュメント作成チームに会って、彼らがどうやったら優れたExcel Basicのチュートリアルやリファレンスを書けるのかを理解できているかどうか確認した。ローカライゼーションの専門家と会って、ローカライゼーション・ストラテジーを把握した。マーケティングチームと膝を交えてVBAのマーケティング上の利点を説明した。ユーザビリティの専門家と一緒になって、ユーザビリティテストを組み立てた。

プログラムマネージャはたくさんの会議に出席するけど、実のところ、仕様書を除いてはあまり多くを生み出さない。だからこそ、大学出たての未熟者であった私でもこの仕事が勤まったのだ。プログラムマネージャの仕事をこなすのに、14年の経験を積んだベテランプログラマとなる必要はない(むしろ14年のプログラミング経験があると、ユーザーの代弁者となるにはちょっと多くを知りすぎている感がある)。

対立

09DevUI-thumbnail.PNG

プログラムマネージャがいないと、すごく賢いプログラマというものは大抵スタートレックのバルカン星人でなければ使いものにならないような、全く不可解なインターフェイスを考え出してくれる(gitを参照のこと)。一流のプログラマというのは、よく知られているようにものすごく頭が良くて、1文字のコマンドライン引数を16個記憶することができないってことがどんなものなのか想像すらできない。それから、こういうプログラマは最初思い付いたアイデアに執着しがちで、特にそのコードを既に書き上げてしまった場合はそうだ。

ソフトウェアをデザインしていく過程においてプログラムマネージャができる最良のことの一つは、「いかにデザインされるべきか」についてセカンドオピニオンを加えることだ。それもできれば、厄介なほど頭が弱いおかげでmanページを読んだり、emacs-lispで拡張関数を書いたり、頭の中で数字を8進法に直したりしなくてもいいようなアプリケーションが必要な「低能なユーザー」の立場に立った意見を。

優れたプログラム・マネージャはUIがどう機能すべきかについて自分なりの意見を持っている。それは開発チームの意見より良いものかもしれないし悪いものかもしれない。そしてそこで長い議論が戦わされる。典型的には、プログラムマネージャはシンプルでユーザーにとって理解しやすいものを望み、また、心を読んだように反応してくれるインターフェイスとか30インチもあるのにポケットぴったり収まるスクリーンとかに重点を置く。一方で開発者は何か取るに足らないものをコードに実装したがり、それに加えてコマンドラインのインターフェイス(「一体こいつのどこが使えないって言うんだい?」)とPythonバインディングをつけたがる。

Excel 5プロジェクトで起こった議論で記憶にある中でも最も長大だったものは、ピボットテーブルをスプレッドシートの描画レイヤーの上に乗せるようにしたいと主張した開発者とスプレッドシートのセルに埋め込むべきだと主張したプログラムマネージャとの間で起こった議論だ。この議論はどこまでも長く長く続いてゆき、結局プログラムマネージャが勝ったのだが、できあがったデザインは一人一人が考えていたどの案よりも良いものになった。

議論がちゃんとした根拠に基づいて紳士的になされるようにするためには、プログラムマネージャと開発者達が対等であることが絶対に必要だ。もし、開発者がプログラムマネージャの下の立場だと、議論のどこかでプロジェクトマネージャは何もかもに嫌気がさして、「わかった。もう議論は十分だ。では、このことは私の案でやることとする」と言って議論を終わらせてしまうだろう。もし両者が対等なら、こんなことは絶対に起こらない。これはちょっと法廷に似ている。どちらの弁護士も裁判官を兼任することは許されず、「真実は対等な者同士の議論を通じて明らかになる」という原理に従って事を進めていく。どちらの側にも不公平なアドバンテージがあたえられてないときにのみ議論は公平なものになるのだ。

これはとても重要な点だ。だからもしあなたが高校2年生の時にいたサリーのことを思い出して、彼女は今何をしているんだろうとぼんやり考えていたなら、しっかり目を覚まして! 彼女は今スコッツデールでバイオセラピストをしていて、しかも共和党員になっている。さあちゃんと注意して聞いて。プログラマをプログラムマネージャの下においてはならないんだ。つまりこのことは、とりわけ開発チームのリーダーやCTOやCEOは機能仕様書を書いてはならないということを意味している。

たいていの会社が犯している過ちのナンバーワンはプログラマのリーダーに仕様書を書かせたり製品のデザインをさせてしまうことだ。こうすると、デザインは公正な裁判を受けず、また対立と議論を通じて形作られることもない。だからこれは考えられる限り最も良くないことなのだ。

私は大変な苦労の末にこのことを学んだ。Fog Creek Softwareで私は幾度も自らプログラムマネジメントの仕事をしたのだが、その時は「私が間違ったことを言ったらいつでも反論しなくちゃならないよ」と何度も何度も促さなくてはならなかった。私達は大企業では無いが、ようやく本物のプログラムマネージャを持てるぐらいには大きくなった。ダンとジェイスンの2人がそうだ。そしてプログラマ達は彼らと議論するのが大好きなのだ。

もちろん、プログラマがプログラムマネージャと対等だと、プログラマが議論に勝つことが多い。ここで、次のようなことが何回か起こった事がある。あるプログラマが私にプログラムマネージャとの議論の仲裁に入ってくれないかと頼んできたのだ。

09Tiara-thumbnail.JPG

「誰がコードを書くんだい?」と私は尋ねる。

「私ですけど……」

「OK、じゃあ誰がバージョン管理システムにファイルをチェックインさせるんだい?」

「私です、多分……」

「なら、一体何が問題なんだ?」と私は尋ねる。「君には製品の最後の一ビットにいたるまで好きにできる絶対的な権限があるじゃないか。他に何が必要だって言うんだい? ティアラとか?」

ここから分かるように、このシステムはプログラムマネージャにプログラマを納得させる責任を負わせることになるのだ。というのも、どこかの時点でプログラマが議論をあきらめて何であれ自分がやりたいようにしだすかもしれないからだ。だから、プログラムマネージャとして有能でありたいなら(a)正しい意見を持ち、さらに(b)プログラマ達の尊敬を勝ち得なければならない。でなければ、彼らはあなたの意見の正しさを認めてはくれないだろう。

では、尊敬を得るにはどうしたらよいのか?

あなたがプログラムマネージャなら、立派にコーディングできるようになることが尊敬を得ることにつながる。これは不公平なことだと言える。だってプログラムマネージャはコードを書かないことになっているのだから。しかし、プログラマはコードが書けない連中よりも書ける人の方をはるかに尊敬する。たとえ、そのコードが書けない人がどれだけ賢い人物であったとしてもね。もちろん、コードが書けなくても有能なプログラムマネージャにはなれる。しかしその場合、プログラミングチームの尊敬を集めることの負担はもっと重くなる。

プログラミングチームの尊敬を得るもう1つの方法は、どの議論においても知性や心の広さや公平さを見せることだ。プログラムマネージャがマヌケなことを言えば、プログラマはボゾビットをフリップするだろう。プログラムマネージャがむきになったり感情的になったりして一つのやり方に執着し、それが非理性的と言えるほどまでに高じると、多いに信頼を失うことになる……。これはどちらの側にも言えることなのだが、しかし特にプログラムマネージャは議論に感情をはさまないようにしなければならないし、また新しい根拠があれば積極的に吟味し、意見を変えるに足る事実があれば改めなければならない。最後に、もしプログラムマネージャが公正な議論の代わりに、議論に勝つために上司とプライベートな会議を持ったり分断戦略を試みたりして、プログラマから政治に走っていると思われたなら、信頼はどんどん失せていくだろう。

ボゾビットをフリップする: [動] 馬鹿者だと決めて,言うことを聞くのを止める

もしプログラムマネージャがプログラミングチームの信頼を失ったら、そこでもう終わり。もう有能にはなりえない。プログラマは彼に注意を払わなくなり、どうであれ自分達のやりたいようにしだす。こうなると質の悪いコードが生み出されることになり、時間も無駄になる。役たたずなプログラムマネージャに給料を払わなくてはならないばかりか、こういう無能なプログラムマネージャは会議を開いて皆の時間を奪いはじめるからだ。たとえ、皆がもはやコードをもっと良いものにしているわけではないにしろね。

仕様書? 本当に? そんなもの書いてたら先に進まないよ

09InternDesk-thumbnail.PNG

仕様書がお役所じみた形式的ペーパーワークのモニュメントみたいになっている開発チームが世の中にたくさんあるおかげで、仕様書を書かないということを基礎とする、ありとあらゆる開発手法が生みだされている。そういう人たちは見当違いのことをしている。機能仕様書は迅速な開発のかなめとも言うべきものなのだ。なぜなら仕様書を書くことで、コードを書く前にデザインの案を素早く次々と検討することができるからだ。コードに比べれば、仕様書を直すのは影響が小さい。しかも仕様書を書くとなれば、頭の中でははっきり掴めていると思っているデザインを現実にじっくりと考えなければならなくなり、そのデザインの欠点も素早く見付けられるようになる。それでさらに多くのデザインを次々検討できるようになる。機能仕様書を書くチームは、より多くの解決法を探ることができるから、より良くデザインされた製品を作り出せるようになる。それに、何が必要になるかをはっきり理解した状態で始められるから、コードも早く書けるようになる。このように機能仕様書はとても重要なものなのだ。現に、Fog Creekの数少ない絶対厳守のルールの一つは「仕様書無くしてコード無し」だ。

機能仕様書の形式そのものは変化しうる。しかし、どの機能仕様書もプログラムがどう動くかについては説明しないといけないし、コードが内部でどう動くのかについては触れはしない。一番抽象的なものから始めるといい。つまり、新しい機能の要点を1ページ以下にまとめて、ヴィジョンステートメントを作るんだ。それが十分に明確なものになったら、絵コンテ……つまりユーザーがそのアプリケーションを操作していく場面ごとのスクリーンショットのモックアップを作り、どう動くのかを説明する詳細なメモも付けておく。多くのタイプの機能、特にUIに力点を置いた機能であれば、その絵コンテができあがったらなら、はい終わり。それがあなたの仕様書だ。さあ、ジェイソン・フリード君、先に進みたまえ。

優れた機能仕様書を書く方法を学びたいなら、私が書いた文章(全4部)を読んでほしい。私が書いた典型的な仕様書が見たければ、Copilotの仕様書を全部ダウンロードできる。

UIの絵コンテには書いてないような隠れた挙動を持つ、より複雑な機能については、もっと詳細に書きたいと思うようになるだろう。どんな場合であれ仕様書を書くことは、コードの一行目を書くはるか前に問題や対立点を浮かびあがらせ、デザインに関わる論点を見つけ出す手助けになってくれる。だからコードを実際に書きはじめた時、思いもよらない問題が現れて書き直しをしなくてはならなかったり、もっと悪ければ最善のデザインをあきらめなければならなくなったりするということが目に見えて少なくなるのだ。

プログラムマネージャの仕事を学ぶには

大抵の場合、プログラムマネージャになるということは物事を学ぶということでもある。テクノロジーについて学び、人々について学び、政治のある組織でどうやって影響力を持つかということを学ぶのだ。優れたプログラムマネージャは技術者の観点からテクノロジーをデザインし、政治家の手腕をもってコンセンサスを形成して人々をまとめる。そうやって仕事をこなして学んでいけばいいのだが、一方で読むべきと言える本もいくつかある。

私の知る限り、「プログラムマネージャは一体何をすべきなのか」ということについて良く書けてる本はスコット・バークンの『Making Things Happen』だけだ。だからこの本から始めるといい。スコットはInternet Explorerの開発チームで長年プログラマを勤めていた人物だ。

もう一つのプログラムマネージャの大きな仕事はユーザーインターフェイスのデザインだ。これについては、スティーブ・クルーグの『Don’t Make Me Think』を読んでから、私の『User Interface Design for Programmers』を読むといい。

最後に、くだらない本に見えるかもしれないけど、デール・カーネギーが1937年に出した『人を動かす』は本当にすばらしい対人関係スキルの入門書だ。私はFog Creekのマネージャ見習いには何よりもまず先にこれを読ませている。読むようにと言うと彼らはいつも鼻で笑うのだが、読み終えたときにはみんなこの本が好きになっているのだ。

(オリジナル: How to be a program manager)

戻る

Personal tools