開発抽象化レイヤ

From The Joel on Software Translation Project

Jump to: navigation, search

Joel Spolsky / 青木靖 訳
2006年4月11日 火曜


若い男が町にやってきた。彼は見かけも悪くないし、ちょっとは金も持っていた。

過去のことについてはあまり話したがらないが、血の通ってない大企業に長くいたらしいことは明らかだった。

彼は生まれつき人当たりが良く社交的で、自分に自信を持っていながら傲慢ではない。だから地元のプログラマーズ・カフェにある求職の掲示の中からちょっとした仕事を見つけるのは、彼には簡単なことだった。しかし保険データベースプロジェクトや、主婦向けの飾りだらけのWebページや、会計計算エンジンといったものには、やがて興味をなくしてしまった。

1年もたつと、彼の慎ましい生計を1年支えられるくらいの蓄えができた。それで贔屓にしてくれるアルザス人へのコンサルティング仕事の後、食料品店の上にある自分のアパートの陽の当たる部屋にコンピュータを据え付け、選りすぐったツールをインストールした。

友達ひとりひとりに電話をかけて、今後何ヶ月か付き合いが悪くなったように見えるかもしれないが、それは仕事が忙しいからなんだと伝えた。

そして腰を据えてコードを紡ぎ出し始めた。

いったいどんなプログラムを書いているのか。完璧で、美しく、エレガントで、バグがない。ユーザインタフェースはユーザの思考プロセスをそのまま形にしたようなものであり、プログラマーズ・カフェでそれを見た人たちはユーザインタフェースがあることに気づかないくらいだった。まったく素晴らしい作品だった。

仲間たちからのフィードバックに励まされ、彼は会社を立ち上げて注文を取り始めた。

慎み深さから見栄を張ることもできないが、ひと月もすると彼の銀行口座の状態はあまり芳しくなくなってきた。これまでに注文が取れたのは3件だけだった。1つは彼の母親で、もう1つはプログラマーズ・カフェの匿名の後援者、あとの1つはコマースシステムをテストするために自分で入れたものだった。

翌月には、注文はまったく来なくなった。

これは彼には驚きだったし、落ち込みもした。大企業では、新製品がコンスタントに作られていて、それがたとえ洗練されておらず凡庸なものであっても、結構な数が売れていた。彼が大企業で関わった製品の1つはヒット商品になった。

何ヶ月かが過ぎて、彼の経済状況は危険になりはじめた。彼の犬は彼を悲しげに見つめ、何が悪いのかは分からないが、彼の顔が以前より幾分やつれているのには気づいていた。友達と出かける元気もなく、底をついている食料を補充するために買物に行くこともなく、風呂に入ろうとさえしなかった。

ある火曜日の朝、食料品店がもう彼につけでは売ってくれなくなった。銀行が彼の電話に応じなくなったのはずいぶん前のことだ。

大企業というのはいつまでも恨みを抱いているものではない。彼らは才能を認識し、彼を喜んで高い給料で再び雇い入れた。すぐに彼の様子は良くなって、新しい服も買い、昔の自信を取り戻した。しかしどこかが違っていた。何かが欠けていた――あの目の輝きだ。自分の運命の主になるという望みを、彼は失ってしまったのだ。

SCal2.PNG

彼はなぜ失敗したのか? 彼は自分でその理由が分かっていると思っている。「マーケティングだよ」。他の若い技術屋たちの多くと同じように、彼は「Microsoftは製品はまずいがマーケティングがすごいんだ」とよく言っている。

ソフトウェア開発者が「マーケティング」と言う時は、単にビジネス関係のことすべてを指している。つまりソフトウェアを作って売ることについて、彼らが理解していない部分すべてだ。

実際は、これは「マーケティング」という言葉が意味していることではない。ほんとのこと言って、Microsoftのマーケティングはひどいものだ。あの恐竜の広告を見てMicrosoft Officeを買いたくなる人がいるなんて、想像できる?

ソフトウェアというのはソフトウェア開発者とユーザとの間の対話だ。しかしこの対話を可能にするためには、たくさんのソフトウェア開発以外のことが必要になるのだ。マーケティングはもちろん必要だが、そのほかにも広報活動とか、オフィスとか、ネットワークとか、インフラとか、オフィスの空調とか、カスタマーサービスとか、会計とか、それにサポートの仕事が山ほど。

それでソフトウェア開発者のしていることはなんだろう? 彼らは設計し、コードを書き、画面のレイアウトを決め、デバッグし、統合し、ソース管理リポジトリにチェックインする。

プログラマの作業しているレベル(たとえばEmacsの上)というのは、ビジネスを支えるためにはあまりに抽象化されている。開発抽象化レイヤで作業している開発者には、実装レイヤ――開発者のコードを製品へと変える組織――が必要だ。ドリー・パートンは「素敵な歌を歌う」レイヤで仕事しているが、彼女も膨大な実装レイヤを必要としている。レコードの制作、コンサートホールの予約、チケット販売、オーディオ装置の設置、レコードのプロモーション、ロイヤリティの回収。

SCal3.PNG

成功しているソフトウェア会社では、ソフトウェアを作る開発者の薄いレイヤが、抽象化を提供する大きな管理的組織の上に広がっている。

抽象化の存在意義は、プログラマの日々の活動(設計し、コードを書き、コードをチェックインし、デバッグし、といったこと)がソフトウェア製品を作り、マーケットへと届けるのに必要なすべてだという幻想を作り出すことにある。これは私がこのエッセイで伝えたい最も重要なポイントにつながっている:

ソフトウェアチームのマネージャの優先度第一の仕事は、開発抽象化レイヤを構築することである。

多くの新米のソフトウェアマネージャはこの点を理解していない。彼らがいつも考えているのは、ハリウッド映画を見て覚えた伝統的な命令統治型の管理だ。

命令統治型では、マネージャ/リーダーがビジネスがどこへ向かうべきか決め、部下の将校たちに適切な命令を下し、ビジネスを推し進める。一方それぞれの将校たちはタスクをより小さな部分へと分割し、部下たちに実行を命令ずる。これが組織図を上から下へと、底辺にいて実際の作業をする人間に行き着くまで続いていく。このモデルでは、プログラマは機械の歯車であり、マネジメントの命令の一部を実行するタイピストにすぎない。

会社によっては実際このように運営されている。話している相手がそういう会社の人間であればすぐにわかる。何か人を憤激させるようなことをしても何とも思わず、彼ら自身そのことが分かっており、気にしてすらいない。彼らがそれについてできることは何もないのだ。家族の緊急時にかけつけようとする人の航空券の変更の求めを拒む航空会社が、何百万マイルの顧客を永遠に失っている。サービスが上がっているよりも落ちていることの方が多いISPが、アカウントを解約してもいつまでも課金を続け、苦情の電話をかけようと思うと市外局番にかけることになり、そこで1時間も待たされた挙げ句、払い戻しを拒否され、彼らがいかにひどいかブログで書くまで払おうとしない。人々が欲しがる車をデザインする方法をとうの昔に忘れたデトロイトの自動車会社が、かわりにマーケティング戦略からマーケティング戦略へと渡り歩き、私たちが連中のクズみたいな車を買わない理由はリベートが十分でないせいだと思っている。

SCal1.PNG

たくさんだ。

そんなのは捨てることだ。マネジメントの命令階層システムというのはずっと試みられてきて、1920年代には、手押し車の行商人との競争でしばらくは機能するように見えたが、21世紀においては満足のいくものではない。ソフトウェア会社には異なったモデルが必要なのだ。

ソフトウェア会社でマネジメントが最優先で作るべきものは、プログラマのための抽象化なのだ。

プログラマがガタつく椅子に煩わされていたり、新しいコンピュータを注文するためDellにかけた電話で待たされているとしたら、この抽象化が漏れていることになる。

開発抽象化レイヤをはんぱでなく強力なモーターを積んだ美しく大きなヨットだと考えるといい。申し分なく整備されている。当たり前のようにグルメ料理が振舞われる。客室には日に2度ルームサービスがある。航海図はつねにアップデートされている。GPSとレーダーはいつも機能しており、壊れた時には予備がデッキの下にある。ブリッジに立つあなたの元には、スピードと、方角と、それにランチをツナにしようかサーモンにしようかということしか考えていないプログラマたちがいる。一方デッキの下では、すべてがうまく動き続けるよう、糊のきいた白いユニフォームを着たプロフェッショナルたちの大きなチームが、静かにつま先立ちで走り回っている。ガソリンタンクを補充し、船に着いたブジツボをこそぎ落とし、ランチのためにナプキンのアイロンがけをする。サポートスタッフたちは何をすべきか分かっていて、時折老練のじいさまが、シンフォニーの全体がうまく協調するよう、わずかに合図を出すくらいだ。そうしてプログラマたちは、スピードと方角とランチに何を食べるか以外のヨットに関わる雑事からは切り離されている。

ソフトウェア会社におけるマネジメントの主たる責務は、プログラマのための抽象化を作り出すことだ。我々はヨットを造る。我々はヨットを保守する。我々こそヨットである。しかしヨットの舵取りはしない。すべてはプログラマのために漏れのない抽象化を提供するためなのだ。そしてそれはすべて、プログラマたちが素晴らしいプログラムを作り、そのプログラムから恩恵を受ける顧客の元へと送り届けられるようにするためなのだ。

プログラマはSubversionのリポジトリを必要とする。Subversionのリポジトリが使えるためにはネットワークとサーバが必要だが、それは購入し、インストールし、バックアップし、無停電電源を供給する必要があり、また、サーバは熱をたくさん出すので、部屋には特別な空調が必要で、空調はビルの外部に接する必要があり、40キロのファンのビルの外壁への取り付けが必要になるのだが、それにはビルのオーナーが不安になって、エンジニアを集めて空調ユニットをどこに設置するか協議させることになり(決定: 18階の外壁、およそ最も居心地の悪い場所)、ビル側は弁護士を呼ぶが、それはこの実施のために長子を人質に出すようにサインさせるためで、そうこうするうちバービー人形の家にいても場違いな感じがしない格好をした空調設置業者が道具をがちゃがちゃ言わせながら現われ、神経質になった建築現場の監督が1/2インチのピンク色のプラスチックでできたマテル製のハーネス(あれはディスコバービーベルトに違いない)をつけた連中が18階の窓によじ登るのを許可しないので、誰かがまたビルの管理業者に電話することになり、クリスマス前から知ってはいたけど今になってやっと理解した契約書を、このくそったれの空調のために新たに改訂しなきゃいけないということに、建築プロジェクトの12週目になって始めて彼らは気付くわけだが、もしこのことについてあなたのプログラマが1分間でも頭を悩ませたのだとしたら、それは長すぎるのだ。

コマンドラインにsvn commitとタイプしているチームのソフトウェア開発者たちからは、これらはすべて抽象化し去る必要がある。

それがあなたがマネジメントを持つ理由なのだ。

マネジメントはどんな会社も避けることができないことに対処するためにある。プログラマがそういったことを気にかけなければいけないのだとしたら、マネジメントは失敗しているのだ。100フィートのヨットのオーナーの億万長者が、エンジンを組立てるためにエンジンルームへと降りていかなければならないのと同じくらいに。

元ソフトウェアのセールスマンが始めた典型的な会社では、すべてがセールス、セールス、セールスだ。我々はただより多くのセールスを上げるために存在している。そういった会社は、バージョン1.0を(どうにか)作った後、新しいソフトウェアを作ることにまったく興味を失うことで分かる。彼らの開発チームは飢えているか、存在しないかのいずれかで、バージョン2.0を作ろうなんて考えは誰の頭にも上らない・・・マネジメントがやり方を知っているのは、いかにセールスを後押しするかということだけだ。

その反対の極端にあるのが、元プログラマの起こした典型的なソフトウェア会社だ。そういった会社は見つけ出すのが難しいが、それは多くの場合、彼らが静かに、どこかの屋根裏でコードを磨き上げているからで、誰にも見つけられることなく、すごいRubyでの書き換えをしたあと、静かに忘却の彼方へと消えていく。彼らの地を揺るがすようなリファクタリングされたコードは、どうしたものか人々に認められなかったのだ。

プログラマによって駆動され、プログラマを運転席に据え、しかしデッキの下でコードを製品に変換する重労働はすべて抽象化しているような会社であれば、そのような会社を簡単に払拭できる。

プログラマが最高に生産的になるためには、静かな個室と、強力なコンピュータと、無制限の清涼飲料と、20度から22度に調整された気温と、ぎらつかないディスプレイと、あるのが感じられないほど快適な椅子と、郵便を届けマニュアルや本の注文をしてくれる管理人と、インターネットを空気のようにあたりまえに使えるようにしてくれるシステム管理者と、プログラマが見つけられないバグを見つけてくれるテスタと、画面を素晴らしいものにしてくれるグラフィックデザイナと、人々が製品を欲しくさせるマーケティングのチームと、人々が製品を確かに手に入れられるようにするセールスのチームと、顧客が製品を使えるように助け、プログラマにはサポートへの電話の原因となっている問題を伝える忍耐強い聖者のようなテクニカルサポートと、そのほか何ダースものサポートや管理を行う人々が必要になるのだが、典型的な会社では、それらの人々は従業員の80%にもなる。ローマの軍隊で兵士1人につき奴隷が4人いたのは偶然ではない。別に退廃していたわけではないのだ。近代的な軍隊では、この比率はたぶん1:7くらいになっている。(プラディープ・シンが今日教えてくれたことがある。もしプログラマがスタッフの20%しかおらず、プログラマのインドへのアウトソースでその給与支出を半分にできるとして、その10%の節約によって得られる競争優位とはいったいどれだけのものだろう?)

マネジメントの主たる責務は、ソフトウェア会社がコードを書くことで運営できるのだという幻想を作り出すことだ。なぜならそれがプログラマのしていることだからだ。プログラマがセールスでもグラフィックデザインでもシステム管理でも料理でもうまくやれるのならそれは素晴らしいことだが、あまり現実的ではない。ブタに泳ぎ方を教えようとするようなものだ。時間を無駄にするだけで、ブタの方こそいい迷惑だ。

Microsoftはこの抽象化を作り出すことに非常にたけており、Microsoftの卒業生たちが会社を起こしてもなかなかうまくいかないことはよく知られている。彼らはデッキの下でいかに多くのことが行われているかを単に理解できず、それを再現することができないのだ。

SCal4.PNG

ドリー・パートンがマイクロホンの接続の仕方を知っていることを誰も期待していない。マネージャや、ミュージシャンや、レコーディング技術者や、レコード会社や、公演マネージャや、ヘアメイクや、広報担当者が彼女の後ろにはいて、ただ彼女が歌うことが、何百万もの人々が彼女の歌を聴くために必要なすべてだという抽象化を作り出している。サポートスタッフとマネジメントは、ドリー・パートンを実現するために、可能な限り完全な抽象化を作り出そうと最善を尽くしている。ドリーが私のために歌っているという最高の幻想を作り出すために。彼女の歌がすべてだ。iPodで彼女の歌を聴く時、それを可能にするために膨大なインフラが必要となるが、インフラのなしえる最善のことは、完全に見えなくなるということだ。そうしてドリー・パートンが私のために個人的に歌ってくれているという、漏れのない抽象化を提供するのだ。


(オリジナル: The Development Abstraction Layer)

戻る

Personal tools