Joel on Software

Joel on Software   このページは"ジョエル・オン・ソフトウェア

 

※新しい翻訳はJoel on Software Translation Projectにあります。

その他の "Joel on Software" の記事(日本語)

その他の "Joel on Software" の記事(英語)

著者へのメール(英文のみ)

 

二つの話


Joel Spolsky ジョエル・スポルスキ
翻訳: Yasushi Aoki 青木靖
2000/3/19

よく管理されたハイテク企業と惨憺たるハイテク企業との違いを典型的に示す二つの話を、私自身の経験から紹介したい。その違いはつまるところ、従業員を信頼して仕事を成し遂げさせるか、それともさまよいだして何もかもぶち壊しやしないかとたえず監視し、管理している必要のあるハンバーガー焼きか何かみたいに扱うかの違いだ。

私のはじめての職場における最初の仕事は、マイクロソフトでExcelの新しいマクロ言語ストラテジーを考え出す、というものだった。私はすぐに「Excel Basic」(これは後にVisual Basic for Applicationsに発展したものだが、それはまた別な話である)の最初のドラフト仕様を書いた。すると、「アプリケーションアーキテクチャ」グループと呼ばれる得体の知れない人たちがどこからか私の仕様について聞きつけ、自分たちはマクロ言語ストラテジーのようなものに責任があると何かの理由で思っていたため関心を持った彼らは、私に仕様を見せるようにと言ってきたのだった。

私は人々に、アプリケーション アーキテクチャグループって何だ?と聞いて回った。誰も彼らが大して重要とは思っていなかった。そして彼らはたった四人のグループで、最近雇われた(マイクロソフトでは珍しい)PhD持ちであることがわかった。彼らから何かおもしろいことが聞けるかもしれないので、私は彼らに仕様のコピーを送り、会いに行った。

一人が「何とかかんとか」と言った。「何とかかんとか、かんとか」と別な一人が言った。私は彼らが言うほどのことを何も持ってなかったのだと思う。彼らはサブクラス化の概念や、Excelでマクロを書いている人々が様々なものをサブクラス化したいと思っている、というような考えに夢中になっていた。何にしても、彼らの一人が言った。「あー、これは非常に興味深いね。で、次は?誰が君の仕様を承認するんだ?」

私は笑った。私はマイクロソフトに来てまだ2、3ヶ月にしかならなかったが、誰かが私の仕様を承認する、なんてことがないということはわかっていた。まったく、承認どころか、私の仕様を読む時間すら誰も持ち合わせていない。プログラマたちはコードを書くからもっと仕様をよこせと、毎日私を悩ませる。私の上司(とその上司)は、他の者はみんなマクロを理解していないか、していたとしてもマクロのために何かする時間がないので、私が何をするにしても、うまくやってもらわないと困る、と言っていた。そして奇妙な研究グループで働いているこのPhDは、ものごとがもう少しフォーマルなものだと思っていたのだ。

私はすぐにアプリケーション アーキテクチャグループがマクロについて私よりも知らないということがわかった。少なくとも私は、人々がExcelマクロで実際何をやっているのか—毎日スプレッドシートを再計算するとか、データを何かのパターンに従って整理するとかいったようなこと—を把握するために、何人かのマクロ開発者や古参のExcelユーザたちと話をしていた。しかしアプリケーション アーキテクチャ グループはマクロを単なる学術的な課題と思っており、人々が書きたいと思っているようなマクロの例を実際に挙げることができなかった。答えに窮したあげく、一人が、Excelには下線と二重下線があるんだから、誰か三重下線を引くためのマクロを書きたいと思うかもしれない、と言った。ああ確かに。それ以降私は可能な限り外交的に、彼らを無視することにした。

これはアプリケーション アーキテクチャグループを率るグレッグ・ウィッテンという男を怒らせたようだ。なにしろグレッグはMicrosoftのナンバー6か何かだ。彼はずっと昔からいた。誰も彼の業績を知らなかったが、彼は明らかにビル・ゲイツとよく食事をいっしょにしていたし、GW-BASICは彼にちなんで名付けられたのだった。グレッグは「大会議」を招集し、Excelチーム(これは私を意味していた)がいかにマクロストラテジーを台無しにしているか不満を言い始めた。私たちは具体的な理由を挙げるように求めたが、彼の答えには説得力がなかった。私はここにいて良かったと思った。大学を出て採用されたばかりのヒラが、ナンバー6と議論して明らな勝利を収めたのだから (こんなことがグレイ・フランネル・スーツを着ているような会社で起こると想像できるかい?) ベン・ワルドマン(現マイクロソフト副社長)率いる私のプログラミングチームは、完全に私をバックアップしてくれており、実際それが必要なすべてだった。というのも、コードを書いていたのは、そしてものごとがどうなされるかについての最終決定権を持っていたのは、プログラミングチームだったからだ。

私はそのままでも十分幸せだったと思う。もしアプリケーション アーキテクチャグループが世話と餌とを必要とし、議論がしたいというのであれば、それはOKだ。彼らがプログラマたちを仕事ができるようにそっとしておいてさえくれるなら、好きなだけ議論につきあってやるさ。しかし私を驚かせるような、もっとおもしろいことが起こった。レドモンドの太陽の下、ピート・ヒギンズが私のところへやって来たとき、私は同僚たちとランチをとっていた。その当時、ピートはOfficeの総括マネージャだった。私はもちろん彼が誰か知っていたが、彼が私のことをよく知っているとは思っていなかった。

「どうだね、ジョエル?」と彼は聞いた。「君とアプリケーション アーキテクチャ グループとの間で何か問題があると聞いたが。」
「いいえ、」私は答えた。「処理できないような問題は何もありません。」
「言わなくていい、」と彼は言った。「わかってるから。」 彼は立ち去った。翌日、アプリケーションアーキテクチャグループが解体された、と言う噂が飛び込んできた。そればかりでなく、グループの各メンバはできる限り離れた別の部署に配属されたのだ。私は彼らから再び何か言われることはなかった。

もちろん私はぶったまげた。Microsoftでは、もしあなたがExcelマクロストラテジーの仕事をしているプログラムマネージャであるなら、たとえあなたが会社に来て6ヵ月に満たなかったとしても、そんなことは問題ではない。あなたはExcelマクロストラテジーの神であり、誰であれ、たとえナンバー6だろうと、あなたの邪魔をすることはできない—以上

これは非常に強いメッセージだ。ひとつには、誰もが自分の仕事により意識的になると言うことだ。彼らは「マネジメントが承認したから」という考えの陰に隠れることはできない、というのもマネジメントは仕様を実際にはよく見ないからだ。マネジメントのすることは、優秀な人材を雇い、何か彼らのする仕事を与えることにつきる。もうひとつは、それが働くのにきわめていい場所だということだ。彼の領分における王になりたくないと思う者がいるだろうか?ソフトウェアはその性質上、より小さなコンポーネントへと簡単に分割していくことができ、したがって責任を人々に分配し、彼らにある領域を所有させることがいつだって可能だ。これがたぶんソフトウェア屋がMicrosoftで働くのが好きな理由なのだ。


その何年か後、オンラインサービスとフリーメールサービスの事業者であるJunoで私は働いていた。このときの経験はMicrosoftの時とまったく逆であった。私には私の下で働くプログラマが二人いたが、私のマネージャは、時にはまったく断りもなしに、私の部下のところへ直接行って彼らに仕事を指示し、私の(限られた)権限をたえず侵害していた。休暇のような些細な要求でさえ、それを承認したり却下したりするのは自分の仕事だと私のマネージャは思っていた。

Junoで働きはじめて二年になったとき、私は新しいユーザ登録機能を開発していた。メジャーリリースであるJuno 3.xで、私はユーザ登録プロセスの完全なオーバーホールを担当することになっていた。このときまでには、私は技術チームの比較的上級のメンバとなっていた。私は高い勤務評定を受けていたし、私のマネージャは私の仕事を気に入っているようだった。しかし彼らは私を信用することができなかった。そこにあったのは指揮統制だ。

ユーザ登録プロセスのある部分で、ユーザに誕生日を問うようになっていた。これはJunoが収入、好きなスポーツ、子供の数、子供たちの年齢、そのほか 100あまりのことについてユーザを質問攻めにする30画面もつづく長い登録プロセスの中のほんのちょっとした部分だった。この登録プロセスを少しでも楽にするために、私は誕生日フィールドを、「74/8/12」でも「August 12, 1974」でも「12 Aug 74」でも、あるいはほかのどんな形でも入力できるフリーフォーマットに変更したいと思った。(Outlookを使ったことは?ほとんどあらゆるフォーマットの日付の入力を受け付けるOutlookのように、これは機能するはずだった。)

あまり詳細を見ることもなく、私のマネージャは、これは気に入らないということに決めた。彼にとってはエゴの問題であった。最初彼はこのページの作業をしていたデザイナのところで悲鳴を上げた(私に断ることもなく)。次に彼は私のところへ来てわめき立てた。そして彼は、私がの望むように何でも変更しなければならなかった日々を思い起こさせた。それから彼はこの会社のCEOにそれを見せ、CEOに私の新しいデザインを批判させるというビッグ・ショーを演出した。JunoではCEOでさえ、会社の最下層で行われる作業にも干渉することに非常に満足しており、事実それが標準的な作業手順なのだった。

言うまでもないが、私は頭にきた。それはまったくのところ小さな、好みの問題だった。私の方法を好む人も、彼の方法を好む人もいるだろう。いずれにしても、メッセージは明らかだ:ここじゃ言われたとおりにやるんだ、馬鹿ヤロー。これは命令統治型のメンタリティーであり、ユーザインタフェースデザインの議論と言うよりは突っ張り合いだった。

これが私がJunoを去った理由だとは言わないが、しかしこれは私がJunoを去った理由を物語ってはいるだろう。それは、いかに熱心に働こうと、いかに頭が切れようと、何かについて責任を与えられていようといまいと、もっとも小さな問題に対してさえ権限がまったくないんだ、という思いだった。あなたのアイディア、トレーニング、頭脳、知性、そのために人々があなたに支払うところのものすべて、みんな無意味なのだ。そしてJunoでは、全従業員の1/4ほどにもなるたくさんのマネージャがいて、そのため彼らにはあらゆる決定に首をつっこむ時間があり、そうやって彼らはコントロールを握っていることを確認するのだ。あなたにものごとを成し遂げるための権限があることを明確にするため、副社長が第9ビルから追い出されたMicrosoftとの対比は際立っている。

Hanging Tree in Jaffa, Israel

ある程度までは、Junoの救いがたくまずい管理プロセスは、それが西海岸の企業ではなくニューヨーク・シティの企業であり、現代的な管理スタイルがあまり浸透していないことにもよるのだろう。それはまた、Junoのマネージャたちの世間知らずが引き起こしている問題でもあり、それはトップの、よそでは働いたことがなく、エラーメッセージの言い回しを含め、首を突っ込めることには何でも干渉する29才のCEO、D. E. ショーに起因していた。CTOはマネージャたちが彼の知性に疑問を差し挟もうとしようものならいつもわめき散らしたし、マネージャたちといえばプログラマたちに八つ当たりをし、プログラマたちは家に帰って飼い犬を蹴っ飛ばして憂さを晴らすのだ。これをMicrosoftと比較するといい、そこではものごとは最下層で行われており、多くのマネージャは、彼らの最も重要な仕事が部屋を駆け回って家具が邪魔にならないようにどかし、人々が仕事に専念できるようにすることであるかのように行動している。



この記事の原文(英語)は Two Stories です。 

ジョエル・スポルスキは、ニューヨーク市の小さなソフトウェア会社  Fog Creek Software の設立者です。イェール大学を卒業後、マイクロソフト社、Viacom社、 Juno社でプログラマとして働きました。


このページは著者の個人的な意見を掲載したものです。
All contents Copyright ©1999-2005  by Joel Spolsky. All Rights Reserved.

FogBUGZ | CityDesk | Fog Creek Software | Joel Spolsky