たまたま見かけたのですが、とても示唆に富む記事だったので頑張って和訳してみました。延べ2週間近くかかった・・・。
ITを武器にする企業は、ベンダーやユーザーに関わらず｢program manager｣と呼べる人たちが必要だと思っています。37Signalsの｢Getting Real｣に近しいことをJoel自身も語ってくれていますし、今後僕らがどのようなキャリアを積んでいけばいいのか、技術力を梃子にしていく組織を作るのにはどうしたらいいのか、そういうヒントが込められています。
Joelの英語は、同じような意味の言葉を複数の言葉を使い分けて言っていたり、ぐるっと回り込んでから要点を記述することが多いので、正確な意味を伝え切れていないかもしれませんが、大きく意味が外れないように留意したつもりです。
原文はHow to be a program manager - Joel on Softwareにあります。原文と同じ段落構成を取っているため、何かこの日本語怪しいと思われたら是非原文にトライして頂ければと思います。
それでは、どうぞお楽しみ下さい。
どうすればプログラムマネジャーになれるのか
優れたプログラムマネジャーを有することは、真に優れたソフトウェアを作るための隠された秘訣のひとつだ。多くのチームがそうであるように、あなたのチームには恐らくそういった人はいないだろう。
WYSIWYGワードプロセッシングを共同開発した聡明なプログラマCharles Simonyiは、Microsoftの株で10億ドル儲け宇宙に行ったMartha Stewartと出会い、彼らは上位機能を実装する一人のとびきり優れたプログラマと、必要に応じて単純な作業をするジュニアプログラマのチームによって構成された真に大きなソフトウェアチームを編成することで、初めて人月の神話問題を解決しようとした。彼らはこの地位のことをプログラムマネジャーと読んだ。Simonyiは聡明だけれども、このアイデアはそうでもない。誰も単調な作業をするジュニアプログラマには成りたがらない、僕はそう思う。
80年代後半にMacのExcelチームのプログラマだったJabe Blumenthalは、違った職種としてこの肩書きを再利用した。彼は既にソフトウェア開発があまりに複雑化しているために、どのプログラマも使いやすい、もしくは、使う意義のあるソフトウェアをどうやって作ったらいいのかを理解する時間を持てないことに気づいていた。マーケティングチームは顧客ニーズなるものをがなり立てては熱弁をふるい誰も彼らと話す時間もなかったし、彼らのMBA的な言葉を実際の機能に翻訳することもなかった。そこには多くの仕事、つまりユーザーと対話し、ユーザビリティテストを実施し、競争力のある商品なのかをレビューし、どうやったらやりたいことを簡単にできるかを真剣に考えたたくさんの製品設計の代物があった。ほとんどのプログラマはそういったことを考える時間がなかったんだ(別に彼らが特別得意だってわけじゃなくてね) Blumenthalは”Program Manager”という肩書きを採用したが、その職種は完全に再発明された。
プログラムマネジャーは何をするのか
これ以降、プログラムマネジャーってのは、
- UIをデザインしたら、
- 機能仕様を書いて、
- チームを編成して、
- 顧客の支持者として仕え、そして、
- Banana Republicのチノパンを履く
ような人たちのことになった。
小さな製品ならたった1人のプログラムマネジャーがいることになるだろうけど、より大きな製品では複数のプログラムマネジャーがいることになると思う。各々が機能サブセットの単位で責任を持つ。ある良い経験則によれば、1人のプログラムマネジャーに各々4名のプログラマがをつけるそうだ。もし作業を分割することが困難にならば、僕がMike Conteから学んだ製品をユーザーアクティビティによって分割するというアプローチがいいかもしれない。例えば、Twitterは４つのユーザーアクティビティに分割されるだろう：
- 登録し、Twitterを始める
- メッセージをポストし、repliesを読む
- アカウントの設定を行う
- ニュースを探す
Microsoftでの僕の初めてプログラムマネジメントの仕事は、Excelでスクリプトやマクロなどで"カスタマイズすること"と呼ばれたアクティビティだった。僕が最初にやらなければならなかったことは、顧客が必要としているものが何かを理解することだった。それは、同じことを聞かされ続けるのに僕が飽き飽きし始めるまで、出来る限り多くの顧客と対話をすることでやろうとした。僕はたった一つしかない18ヶ月後のリリースまでに何が可能で、何が実装するにふさわしいかを理解するために、開発チームとの対話に多くの時間を費やし、Visual Basicのチームが僕らのマクロ用言語で使えるであろうコンパイラ、コードエディタ、ダイアログボックスエディタを提供できるかどうかを見極めるために、彼らとも多くの時間を費やした。僕は、AppleScriptと呼ばれた普遍的なマクロ言語を開発していたAppleとも話をしなくてはならなかったし、Microsoftの別のアプリケーションチーム、主だってはWord,Access,ProjectそしてMailといった、Excelがやっていることは何でも普通に考えてやっていた人たちとも、話をしなくてはならなかった。打ち合わせ、Eメール、電話。僕はこういったことで人生を傷つけられたし、今では電話が鳴ってしまうと怖くてオフィスでちぢこまってしまうんだ。
第2関門は、ビジョン記述書を書くことだった。どうやればVisual BasicがExcelで動くかとか、これがマクロが実際に動くいつかのサンプルですよとか、これらが僕らが何を作る必要がある主な部品ですよとか、そして、どうすれば顧客の問題を解決することになるのかといった、広範囲にわたる書類のことだ。そんなに多くの反対が無ければ、最も詳細な部分まで落とし込み、ユーザーの目に映ることの全てを説明する、もっと詳細な仕様書を作り始めた。
これは技術的な仕様ではなく、機能的な仕様のことだ。何を意味しているかというと、全てがどうやって実装されたではなく、ユーザーが何を見るかという視点で語られたもののことだ。（機能的仕様については、ここで全部読むことが出来る)プログラムマネジャーは開発チームが内部的にどうやって実装しているかには注意を払わないんだ。僕が開発チームのトップであるBen Waldmanに仕様の何章かを送ったら、彼と彼のチームは座り込んで、彼らがそれを実現するために内部的に何をしなくてはならないかを算定した。彼らは僕に内部的なExcel機能を明示するためにかなり聡明でとてもコンパクトなオブジェクト指向的なインターフェイスにマッピングされたテーブルと一緒にやってきたけど、そういったことは真に僕の仕事じゃなかった。僕はExcelの中のことはよくわからなかったし、どうやってそういったものが実装されるべきかも本当によくわからなかった。
正直に言えば、僕はなんにもわかっていなかった。大学を出たてで、コードを開発し、コードをテストし、ドキュメントを作成し、製品を市場に出すか、ユーザビリティテストを行うことに対して十分な経験が無かった。幸運なことに、Microsoftには今日の僕が知っている全てを教えてくれて畏怖的な製品を作るための本当の仕事をしてきた、上述した各々の分野で真摯に経験を積んだ天才がいた。例えば、僕はユーザーがスプレッドシートのセルにある値を変数にコピーしたいときは、このようにやることを知った。
x = [A1]
こいつを動くようにしなくてはならなかった。問題は１つのセルは数値か文字列を保有できるのだが、Basicは既にこういう制約があった。「DIM x｣は実際にその値を使う前に整数型、小数点そして文字列が宣言できた。
Basicはいくつか動的片付けを保持できなくてはならかったけど、僕はどうやってそれを実現するかについてそんなに頭が切れるわけじゃなかった。問題にはならなかった。VisualBasicチームのプログラマ Tom Corbettが解決してくれた。こうして｢Variants｣と｢IDispatch｣が生まれ、Basicは今日"duck typing"*1と呼ばれる特徴を持った動的言語になった。重要なのは、僕の仕事は問題を解決をするのに必要ではなかったことだ。その仕事というのは、顧客が必要としていたことを理解し、そしてプログラマがどうやってそれを解決するかを理解したかを確認することだった。
ひとたび仕様が完結すれば、開発チームは実装に取りかかった。僕は2つのことについて責任を負っていた。設計について生じる全ての課題・質問を解決すること、開発者が行う必要のない他の全てのチームと対話をすることだ。僕はどうやって想定された通りに動くのかを説明するためにテスターと打ち合わせをして、どうやって彼らが全てをテストしたらよいかを手伝った。ドキュメント作成チームとも、彼らがどうすればExcelBasicについて良いチュートリアルとマニュアルを書くことが出来るかを理解してもらうために、打ち合わせをした。ローカライズの戦略を理解するために、ローカライズの専門家とも打ち合わせをした。VBAのマーケティング上の利点を説明するために、マーケティングチームと膝をつき合わせた。ユーザビリティテストを作るために、ユーザビリティの専門家とも仕事をした。
プログラムマネジャーはたくさんの打ち合わせをこなすけど、仕様を書く以外のことは何も生み出さなかった。なんででかと言えば、学校を出たばかりのバカができたのは今でもそれぐらいだからだ。プログラムマネジャーとして働くのに14年間のベテランプログラマーである必要はないんだ。(実際の所は、14年のプログラミング経験があれば、良きユーザーの支持者になるには知りすぎてしまっているかもしれないけれど）
葛藤
プログラムマネジャーを欠いていることで、普通のすごく頭の切れるプログラマが完全に不可解な「キミがVULCANならば」(バカと比較しての話だけど)完全に意味を為すような、意味不明なユーザインターフェイスを生み出すことになるだろう。素晴らしいプログラマは悪名高く聡明であり、16ビットの1行のコマンドライン引数が記憶できないことを想像することはいささか困難だ。特に既にコードを書いている場合は、プログラマは自分の最初のアイデアに愛着を持つ傾向がある。
プログラムマネジャーがソフトウェアの設計プロセスで与えられる最高のことの１つは、どのような設計によって動作すべきかについてのセカンドオピニオンだ。幸運なことに彼らは、manページを読むことなく、カスタマイズしたEmacsでlispのファンクションを書くこともなくもしくは脳内で数値を８進数に変換することなしに、アプリケーションが使えるように要求するようなメンタルの弱さをもっている｢ひどく知恵の遅れたユーザー｣に対して、より親身になってくれる。
優れたプログラムマネジャーは、開発者のそれよりも良くも悪くもあるだろうが、UIがどのように機能すべきかについて自身のアイデアを備えているだろう。そして、それから長い間議論をする。典型的に、プログラムマネジャーはシンプルでテレパシーでも通じるかのようなUIでもってユーザーが理解しやすいものを求めるにもかかわらず、そのUIはポケットに収まるような30度角の液晶だったりする。一方で開発者はCUI(何がそんなに使いにくいのかい？)やPythonの型付けのような、コードを実装するための瑣末な何かを求めるのだけれど。
｢Excel 5｣プロジェクトから私が思い起こす最も意義のあった議論は、スプレッドシート上の描画領域にピボットテーブルを浮かせたかったある開発者と、スプレッドシートのセルの右側にピボットテーブルを生かそうとしたプログラムマネジャーとの間で起こった。この議論は本当に本当に長い間続いたが、ついにはそのプログラムマネジャーが説き伏せた、しかしお目見えした最終デザインは、今まであった個々人が考えたデザインよりも、もっともっと優れたものだった。
その議論で起こったことを慎重に確かめる意味で、そして、そこで起こった事実の合理的な原理原則に拠れば、プログラムマネジャーと開発者は同等の地位であることが絶対的に重要である。開発者がプログラムマネジャーに何かを報告すれば、何かの点においていくつか議論を行った後、プログラムマネジャーは何もかもにうんざりして、ただこう言うだろう。｢OK、十分な議論をした。では今から我々は僕のやり方でやっていく｣、と。もし彼らが同等であれば、決してこんなことは起こりえない。ちょっと裁判所に似ているのかもしれない。即ち、我々は裁かれるためにどちらか一方の弁護士を認めるわけにはいかないし、同等なもの同士の間で一連の議論を通じて真実が最も暴かれるであろうというセオリーに基づいて動く。議論が唯一公平になるのは、どちらも不公平なアドバンテージを持っていない場合だけだ。
大切なことを言うから、11年次のSallyに対して妄想しちゃって彼女が今どこにいるかをあれこれ思っているとしたなら、とっとと目を覚ましてくれ。彼女はスコットデールの理学療法士で、共和党の支持者だ。さぁ、ちゃんと聞いてくれよ。プログラマーはプログラムマネジャーに対して報告が出来ないことの意味は、開発者のトップとか、CTOとか、CEOとか、そういった人たちは仕様を書くことが出来ないってことなんだ。
ほとんどの会社が犯すNo.1の失敗は、仕様を書いたり製品を設計するプログラマーたちのマネジャーを持っていることだ。なぜなら、そのデザインは公正な試用機会を得ることはないし、葛藤や議論から生まれたものでもないから、それより良くなりようがないから、それは失敗なんだ。
こういったことを、僕はキツいやり方をもってして学んだ。Fog Creek Softwareでは私自身で多くのプログラムマネジメントを行っていたし、僕が何か間違ったことを言った時に僕を翻させるであろう人たちを思い出す定常的なバトルだった。僕らは大きな会社じゃないけれど、最終的には本当のプログラムマネジャーであるDanとJasonを持つには十分に大きくなれたし、プログラマーたちは彼らと議論することをとても楽しんでいる。
もちろん、プログラマーとプログラムマネジャーが対等である場合は、プログラマーが優位になりがちになる。こういったことは何度も起こっている。プログラムマネージャと共に仕事をしているあるプログラマーがある議論を仲介して欲しいと僕に尋ねてきた。
｢誰がコードを書くんだい｣、と僕は尋ねた。
｢私です・・・・」
「そうか、では管理されているソースをチェックするのは？｣
「私です・・・、多分・・・」
｢だったら、正確には何が問題なんだい？｣と僕は尋ねた。｢キミは最終版の製品に対してどのビットの状態に対しても絶対的な管理が可能だ。他に何が必要なんだい？ティアラかい？｣
ごらんの通り、このシステムがプログラムマネジャーがプログラマを説得する時に負担になることがわかる。なぜならば、ある意味プログラムマネジャーはプログラマーがギブアップしてやりたいように何でもやってしまうリスクを負っている。なので、プログラムマネジャーとして効果的でいるためには、あなたは(a)正しくて、(b) プログラマから信頼を獲得すれば彼らはあなたが正しいことを認めるようになる。
では、どうやってこの種の尊敬を獲得するのか？
プログラムマネジャーとしても、コードを書くことが得意であることがその手助けになる。確かに不公平だ。プログラムマネジャーはコードを書くことを期待されているわけではないからね。でも、プログラマーはどんなにプログラマーでない人がスマートであろうとも、彼らよりずっとプログラマーを尊敬する傾向にあるんだ。コーダーにならなくても有能なプログラムマネジャーになることはできるけど、プログラミングにおいて尊敬を勝ち取る負担のほうが大きくなるだろう。
プログラマーのチームの尊敬を勝ち取る他のやり方は、知性とオープンなマインドとそして発生するどんな議論においても公平であることだ。もしプログラムマネジャーが間抜けなことを言ったら、プログラマーは彼らに｢不要ビット｣を立てるかもしれないね。もしプログラムマネジャーが個人的もしくは感情的に仕事を進める一定のやり方に執着するようになると、それらが不合理と言えるものならば多くの信頼を失うことになるだろう・・・、両者共にね。特にプログラムマネジャーは議論から離れた所で感情的になり、新しい証拠を進んで考慮し、実際に起こってることがその証拠に照らし合わせ検討に値するなら自身の意見を変える必要がある。ついには、プログラムマネジャーが上司と内密にミーティングを持ったり、メリットを議論する代わりに議論を分断して征服しようとするような政治ゲームをやっていると見られてしまうと、プログラマーからたくさんの信頼を失うことになるだろう。
そして、プログラムマネジャーがプログラマーチームの信頼を失った時が、終焉の時だ。もう機能しなくなる。プログラマーたちは彼らを無視して自分達がやりたいと思うことを何でもどうにかやろうとするだろう。これはコードを悪化させ時間を浪費させることにつながり、役に立たないプログラムマネジャーに給料を支払うだけでなく、実際にコード品質をよりよくすることがないのにミーティングに呼び出し他のみんなの時間をひっかきまわすことになる。
仕様書？本気かい？それじゃ遅すぎる
仕様書が全体の流れがそれを書かないというアイデアで編成されているんじゃないかと疑いたくなるような、愚かな役人的事務処理の典型になっている開発部隊はとても多く存在する。こういう人たちは間違っている。機能仕様書を書くことはアジャイル開発のまさに肝となるものだ、なぜならあなたがコードを書く前に多くの実装できうる設計を素早くイテレートさせられるからだ。コードに比べたら、書かれた仕様書など変化を生むには取るに足らない。正しく仕様書を書くことは頭に浮かんだ設計を通じて素早く欠陥を見つけさせてくれるので、もっと多くの設計をイテレートすることが出来る。機能仕様書を持つチームはより良く設計された製品を持っている、なぜなら彼らは素早くより多くの実現可能な解決策を探索する機会を持ったからだ。また、より早くコードを書くことになる。なぜなら彼らが何が必要になるのかという所からスタートするにあたり、より明確な絵があるからだ。機能仕様書はとても重要なので、Fog Creekではほどんど辛くも早くも無いルールの１つが｢仕様がないなら、コードも無い｣である。
機能仕様書の正確な形式というのは、色々と種類があるかもしれない。機能仕様書がやらなきゃいけないことはプログラムがどうやって振舞うのかを説明することだけだ。コードが内部的にどう動くかということは一切説明されない。最も上位レベルである｢ビジョン記述書｣、1ページ以内でその新しい機能の骨子を説明するもの、から取り掛かる。ひとたびそれが明確になれば、ストーリーボードの開発ができる。そこには、アプリケーションがどういう働きをするのかを詳細に書かれたノートと共に、アプリケーションを通じてユーザーが歩む行程を示した画面のモックアップなどがある。多くの機能群、特にUIが重要な機能は、一度これらのストーリーボードがあれば、もう大丈夫だ。それがあなたの仕様書だ。今キミはJason Friedのように進むことが出来る。
隠された振る舞いにあるより複雑な機能群については、UIのストーリーボードに書くのではなくもっと詳細に書き記したくなることだろう。どんな場合においても、本当に仕様書を書くということはコードの最初の一行が書かれるずっと先立って問題・葛藤を発見し、そして課題をデザインする手助けになるので、正にコード書いている時に再実装もしくは改悪になるかもしれない準最適な設計を強いるような急に振ってくる予期しない問題がとても少ないものになるのだ。
どうやってプログラムマネジャーになることを学ぶのか？
大抵の場合、プログラムマネジャーになることはまさに学習だ。技術、人間、政治的な組織においてどうすれば役に立てるのかを学ぶことだ。優れたプログラムマネジャーは政治家としての手腕を技術を持ってして設計するというエンジニアのやり方に結び付けてコンセンサスを構築し、一緒になって人々を導いていくものだ。こういう仕事をしたいという一方で、キミが読むべき本は数冊しかない：
僕が伝えられる範囲では、Scott BerkunのMaking Things Happen: Mastering Project Management (Theory in Practice (O'Reilly))がプログラムマネジャーがやらなくてはならないことを広範囲に正確にカバーされて書かれている唯一の本なので、まずここから始めるといい。Scottは長年IEのプログラムマネジャーをやっていたんだ。
プログラムマネジャーのもう1つの大きな部分は、ユーザーインターフェイスの設計だ。Steve KrugのDon't Make Me Think: A Common Sense Approach to Web Usability (Voices That Matter)、それから私の著書User Interface Design for Programmersを読んで欲しい。
最後になるが、古臭く思えるのはわかっているけどDale Carnegieが1937年に書いたHow to Win Friends and Influence Peopleは実際に対人能力おける素晴らしい入門書である。何を差し置いても、Fog Creekでは全てのマネジャー訓練者に最初にこれを読ませているし、僕がコレを読めというといつも嫌な顔をするんだけど、読み終わったらとても満足しているよ。
