Developer's Perspective―海外エンジニア/ブロガー 直撃インタビュー+翻訳エッセイ

第1回 「Joel on Software」Joel Spolsky:翻訳エッセイ編―プログラムマネージャになるには

この記事を読むのに必要な時間:およそ 5 分

議論

プログラムマネージャがいないと,頭の良いプログラマたちは,スタートレックに出てくるバルカン人向けとでもいうようなまったく難解なユーザインタフェースを作りがちだ(例: git)⁠優れたプログラマというのは頭脳明晰で,16個ばかりの1文字からなるコマンドライン引数も記憶できないというのがどんなことなのか想像もできない。そしてそういったプログラマたちは自分の最初のアイデアに執着する傾向がある。コードを書いてしまっている場合は特に。

プログラムマネージャがソフトウェアデザインプロセスにもたらしうる最良のことが何かというと,どのようにデザインすべきかについてのセカンドオピニオンだ。manページを読んだり,カスタマイズのためのemacs-lisp関数を書いたり,頭の中で数値を8進数に変換したりしなくてもアプリケーションが使えなきゃ困る知恵遅れのユーザに共感できる人間の意見だ。

良いプログラムマネージャはユーザインタフェースがどう機能すべきかについて自分の考えを持っている。それは開発者の考えより良いものかもしれないし,まずいものかもしれない。そして長い議論が行われる。一般にプログラムマネージャは何かシンプルでユーザにわかりやすいものを求める。テレパシーで操作できることとか,ポケットにすっぽり収まる30インチ画面とかいったものだ。一方開発者のほうはコードで容易に実現できることを求める。コマンドラインインタフェースとか(⁠どこが使いにくいって言うの?」⁠Pythonバインディングとかだ。

私が覚えているExcel 5プロジェクトにおけるもっとも大きな議論は,ピボットテーブルをスプレッドシートの上のドローイングレイヤに置きたいプログラマと,ピボットテーブルはスプレッドシートのセルになきゃいけないというプログラムマネージャの間の議論だ。この議論は本当に長い間続き,最後にはプログラムマネージャのほうが勝ったのだが,最終的なデザインはもともとのデザインよりずっと良いものになった。

議論が敬意を持って,事実に基づいて理性的に行われるためには,プログラムマネージャと開発者が対等であることが絶対的に重要だ。プログラムマネージャが開発者の上司だとしたら,議論のいずれかの時点で,プログラムマネージャはめんどくさくなって単に「もう議論はたくさんだ,俺のやり方でやるぞ」と言うかもしれない。対等であれば決してそういうことにはならない。法廷のようなものだ。一方の弁護士が判事を兼ねたりはしない。そして真実は対等な者の間の議論を通してもっともよく明らかにされるのだという考えに基づいて我々は働いている。どちらも不公平な利点を持たないときにのみ議論は公正になり得るのだ。

これは重要なことだ。高校2年のとき同級生だったサリーは今どうしてるんだろうと空想にふけっていたのなら,目を覚ましてもらいたい。彼女ならスコッツデールで生物療法士をしていて共和党員だ。さあ,ちゃんと注意して。プログラマがプログラムマネージャの部下であってはいけないということは,すなわち,開発リードやCTOやCEOは,仕様書を書く人間ではありえないということだ。

多くの会社が犯している一番の誤りは,プログラマのマネージャに仕様書を書かせ,製品のデザインをさせるということだ。これが間違いであるのは,デザインが公正な審判を受けることなく,対立と議論を通して生み出されないためだ。そのためあり得べき最良のデザインとはならない。

私はこのことを苦い体験を通して学んだ。Fog Creek Softwareにおいて,私はプログラムマネージャの仕事の多くを私自身がこなしてきた。私が間違ったことをしているときには,私と議論しなければならないのだとみんなに思い起こさせるのに苦労した。私たちの会社は大きくないが,今やようやく,DanとJasonという,本当のプログラムマネージャを持てるくらいに大きくなった。そしてプログラマたちは彼らとよろこんで議論している。

もちろん,プログラマがプログラムマネージャと対等な場合には,プログラマのほうが主導権を握ることも多い。プログラムマネージャとの議論に決着をつけてくれるようにとプログラマが私に頼みにくることがときどきある。

  • 「コードを書くことになるのは誰?」と私は尋ねる。
  • 「私です…」
  • 「じゃあ,ソース管理にチェックインするのは?」
  • 「私,でしょうね…」
  • 「それなら何が問題なの?」と私は言う。⁠君は最終製品のあらゆる点について絶対的なコントロールを握っているわけだけど,あとほかに何がいるの? 王冠かい?」

このやり方はプログラムマネージャにプログラマを説得するという重荷を負わせることになる。プログラマがうんざりし,やりたいようにやるようになるというリスクがあるのだ。だから力を持ったプログラムマネージャになるためには,⁠a)正しく,⁠b)プログラマからの尊敬を勝ち取る必要があり,そうでなければ自分が正しいことを認めさせることはできない。

画像

どうすれば尊敬を勝ち取ることができるのか?

プログラムマネージャ自身がプログラミングに優れているということは役に立つ。これはフェアでないかもしれない。プログラムマネージャは本来コードを書く人間ではないからだ。しかしプログラマは,頭の良し悪しとは関係なく,プログラマでない人間よりプログラマにずっと敬意を払う傾向がある。プログラムが書けなくとも力のあるプログラムマネージャになることは可能だが,プログラミングチームから尊敬を勝ち取るためのハードルはずっと高くなる。

プログラミングチームの尊敬を勝ち取るもう1つの方法は,議論において知性と心の広さと公正さを示すことだ。プログラムマネージャが間抜けなことを言うと,プログラマはボゾビットを立てる注4)⁠プログラムマネージャが何かのやり方に個人的,感情的にこだわり,合理性を欠くなら,信頼を失うことになる…。どちらの側にも言えることだが,とくにプログラムマネージャは,議論に感情的にならず,新たな証拠を進んで検討し,事実が示す場合には考えを改める必要がある。そしてもしプログラムマネージャが政治的に振る舞い,事実に基づいて議論するのでなく,上司と秘密裏の会合をしたり,人々を分断することで議論に勝とうとしたりするなら,プログラマたちから信頼をすっかり失うことになるだろう。

そしてプログラムマネージャは,プログラミングチームからの信頼を失ったら,それで終わりだ。そのようなプログラムマネージャが力を発揮することはない。プログラマたちは背を向けて自分のしたいようにする。これはまずいプログラムと無駄な時間をもたらす。機能しないプログラムマネージャの招集するミーティングでみんな時間を奪われることになるが,それでプログラムが少しでもよくなることはないからだ。

注4)
flip the bozo bit[動詞]ボゾビットを立てる。誰かをヘボであると決めつけ,無視すること。

著者プロフィール

Joel Spolsky(ジョエル・スポルスキー)

WebサイトJoel on Softwareにより世界で広く知られているソフトウェア開発プロセスのエキスパート。Fog Creek Softwareの創業者CEOであり,Stackoverflow.comをJeff Atwoodとともに立ち上げた。以前にはMicrosoftでExcelチームのメンバーとしてVBAをデザインし,Juno Online Servicesで数百万人が使うインターネットクライアントを開発している。著書に『User Interface Design for Programmers』(Apress,2001),『Joel on Software』(Apress,2004),『Smart and Gets Things Done』(Apress,2007),『More Joel on Software』(Apress,2008),編著書に『The Best Software Writing I』(Apress,2005)がある。

URL:http://joelonsoftware.com


青木靖(あおきやすし)

ソフトウェア開発者/翻訳家。訳書に『Joel on Software』(オーム社 2005年), 『Best Software Writing』(翔泳社 2008年), 『ソフトウェア開発者採用ガイド』(翔泳社 2008年), 『Eric Sink on the Business of Software 革新的ソフトウェア企業の作り方』(翔泳社 2008年),『More Joel on Software』(翔泳社 2009年)がある。

URL:http://www.aoky.net/