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

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

その他の "Joel on Software" の記事（日本語）

その他の "Joel on Software" の記事（英語）

著者へのメール（英文のみ）

「うちの開発チームのどこが悪いのか分からない。」とCEOは心の中でつぶやく。「プロジェクトを始めたころには何もかもうまく行っていたんだ。最初の2 週間チームは馬車馬のように働いて、ちゃんと動くプロトを作ったんだ。ところがその後は進み具合が這うように遅くなった。単に連中が怠けてるだけということかもしれん。」彼はキャラウェイ製のチタンドライバを選び、キャディに冷たいレモネードを取りに行かせる。「2、3人首を切れば、連中の尻にも火が付くだろう！」

その間、もちろん開発チームの方は何が悪いのか全然見当も付かない。実際何もまずいことはないのだ。彼らはスケジュール通りに進んでいる。

こんなことがあなたの身に起こらないようにすることだ！あなたの人生を百万倍も楽にしてくれる、こういう非技術系マネジメントタイプの人間についての秘密をお教えしよう。それはとても簡単なことだ。ひとたびこの秘密を知ったなら、あなたが再び非技術系マネージャと問題を起こすことはなくなるだろう (あなたが彼らのゴルフクラブの弾性係数について議論しない限りは)。

プログラマの思考する言語とMBAの思考する言語が異なっているのは明らかだ。私はソフトウェアマネジメントにおけるコミュニケーションの問題についてしばらく考えてきたが、それはプログラマ語とMBA語の翻訳ができるまれな人間の手にする力と報酬の大きさが明らかだからだ。

私がソフトウェア産業で働き始めて以来、私が関わってきた仕事はほとんどすべて「投機的」ソフトウェアとでもいうべきものだった。つまり、特定の顧客のために構築するソフトウェアではなく、たくさんの人がそれを買ってくれることを期待して作られるソフトウェアということだ。しかし多くのソフトウェア開発者がこのような贅沢を享受しているわけではない。彼らはコンサルタントで、ひとつの顧客のためのプロジェクトで開発をしているのかもしれないし、またはインハウスプログラマで複雑な企業会計システム(あるいは何であれ、インハウスプログラマが作るもの。それは私にとってはむしろミステリアスなものだ)を開発しているのかもしれない。

これらのカスタムプロジェクトで、予算超過や失敗やいろいろな悲惨さのもっとも一般的な原因というのは、いつでも基本的には「あの(×××な)顧客は自分が何が欲しいのかわかってない。」ということに帰着されるのだとお気づきだろうか？

以下はこの病気の3つのバージョンだ：

1. 「顧客は考えをしょっちゅう変える。最初はクライアント/サーバにしたいと言っていた。それからデルタ航空の機内誌でXMLについて読んでXMLがなきゃいかんということになった。そして今じゃLego Mindstormsのロボットを使うように書き換えているところだ。」
    
2. 「私たちは正確に彼らが望んだように作った。契約にはあらゆることが詳細に明記されていた。私たちはまさに契約に書かれている通りのものを渡した。 ところがいざ渡してみると、彼らは非常に失望するのだ。」
    
3. 「うちのお粗末なセールスの連中は、基本的には未定義なものを一定の費用で作るという契約を結び、顧客側の切れ者の弁護士は『顧客が承認する』までは支払いの必要がない、という文言を契約に入れたので、我々は9人の開発者のチームを2年間彼らのプロジェクトに割り当て、たった800ドルしか得られなかった。」

すべての若いコンサルタントが強力な2500回転のデウォルト製ドリルで頭の中にねじ込んで置かなければならないことが一つあるとしたら、それはこういうことだ：｢顧客は自分が何がほしいか分かっていない。顧客に彼らが何を欲しいか知っていると期待するのはやめることだ。｣それはありそうにないことなので、忘れることだ。

代わりにこう仮定することだ。いずれにせよあなたは何か作らなければならず、そして顧客がそれを気に入る必要があるが、しかし彼らは多少驚くことになるだろう。あなたは調査をする必要がある。あなたは顧客の問題を好ましい仕方で解決するデザインを見つけ出す必要がある。

彼らの立場で考えてみることだ。あなたはYahoo!にあなたの会社を1億ドルで売ったばかりで、キッチンをそろそろリフォームしてもいいころだと思っているとしよう。それであなたはプロの建築家を雇って、「ウィル&グレースに出てくるキッチンみたいにかっこよくしてくれ」と言う。どうやったらそうなるのかあなたには分からない。あなたはバイキングストーブやサブゼロ製の冷蔵庫が欲しいことを知らない—それはあなたのボキャブラリにはない言葉だ。あなたはその建築家が何かいいことをしてくれるのを望んでいて、それがあなたが彼を雇った理由だ。

エクストリームプログラミングの連中に言わせると、これに対する解法は顧客を部屋に呼んで、デザインの過程の各ステップで彼らに開発チームの一員として関わってもらう、というものだ。これは私に言わせると、ちょっとエクストリーム(極端)すぎる。それは私の建築家がキッチンをデザインするとき私に立ち会わせて、あらゆる微細な点について私の意見を聞くようなものだ。それは私には退屈だし、もし建築家になりたかったのだったら自分でなっている。

何にしても、ほんとのところを言うと、彼らをチームに入れたくはないんじゃない？顧客から任命された人間は経理部門のうすのろで、彼がプログラマと一緒に働くように送られてきたのは、彼が最も仕事が遅くて居なくても気づかれないような人間だからだ、と言うようなことになるのがオチだ。そしてあなたはデザインの時間のすべてを彼に1音節の単語で説明するのに費やすのだ。

あなたの顧客は何が欲しいのかわかっていないと仮定しよう。その領域についてのあなたの理解に基づいて、あなた自身がデザインすることだ。あなたがその領域について学ぶために時間を使ったり、その領域の専門家の助けを借りるのは構わないが、ソフトウェアをデザインするのはあなたの仕事だ。あなたがその領域について下調べし、良いUIを作るなら、顧客は喜ぶだろう。

私はあなたのソフトウェアの顧客(あるいは非技術系のマネージャ)の言語とプログラマの言語の間の変換について、秘密をお教えすると約束したんだった。

あなたは氷山の90%は水面下にあるのを知っているだろうか？そう、多くのソフトウェアもそうだ— それは作業の10%を占めるこぎれいなユーザインタフェースと、プログラミング作業の90%を占める隠れた部分からなっている。そしてバグ修正が作業時間の半分を占めるという事実を勘定に入れると、UIは5%の作業にしかならないのだ。そしてあなたがPowerPointで見るようなUIの見た目の部分だけに限ったなら、それは1%未満の作業でしかない。

これは秘密ではない。秘密なのは、プログラマ以外の人々がこのことを理解していない、と言うことだ。

氷山の秘密にはとても重要な系がある。

重要な系の1．プログラマでない人間に90%まずいユーザインタフェースを持った画面を見せたなら、彼らはプログラムが90%まずいと思う。

私はことことを、大きなWebベースのプロジェクトでクライアントの経営陣にデモをしているときに学んだ。プロジェクトはほぼ100%コードコンプリートしていた。あとはグラフィックデザイナがフォントと配色を決めて、クールな3Dのタブをつけるだけだった。それが出来るまでは、画面は白黒で標準フォントだけを使い、無様で無駄な余白がたくさんあって、つまるところあまり見栄えが良くなかった。しかし機能は100%出来上っており、かなりすごいことがやれたのだ。

デモの間にどんなことが起こったか？ミーティングの間中ずっと、クライアントは画面の見た目について文句を言い続けたのだ。彼らはユーザインタフェースの話さえしなかった。単に見た目の話だけだ。彼らのプロジェクトマネージャは「画面がどうも見苦しい。」と不満を口にした。それが彼らの考えるすべてだった。私たちは彼らが実際の機能について考えてくれるようにすることが出来なかった。グラフィックデザインを直すのには一日しかかからないのにだ。それはまるで彼らが雇ったのが画家ででもあるかのようだった。

重要な系の2．100%素晴らしいユーザインタフェースの画面をプログラマでない人間に見せると、彼らはプログラムがほとんど完成していると思う。

プログラマでない人間は画面とピクセルしか見ない。そして何かをするプログラムがピクセルからできているのなら、「あとそれを実際動くようにするのがいったいどれだけ難しいというんだ ？」と考えるのだ。

ここでの大きなリスクは、おそらくは顧客と会話する目的であなたがUIのモックアップを最初に作ったなら、彼らはみんな、あなたが大方作ってしまったのだと思うということだ。そして次の年をずっと中身を作るのに費やしたとしたら、人々はあなたが何をしているのかわからず、何もしていないと思うということだ。

重要な系の3．見た目がクールで磨き上げられた4ページくらいのWebサイトを持つドットコムは、デフォルトのグレーの背景と3700年分のアーカイブを持つ非常に機能的なドットコムよりも高く評価される。

おっと、ドットコムはもはや何の価値もないので、気にすることもない。

重要な系の4．非技術系のマネージャや顧客がプロジェクトを承認することを政治が要求しているのなら、グラフィックデザインを何バージョンか用意して彼らに選ばせることだ。

何かの配置を変える、フォントやルックアンドフィールを変える、ロゴの位置を変えたり、大きさを変えたりする。彼らがいじくれるように、鶏に口紅をつける類の差し支えのないものを与え、何か重要なことをしているように思わせておくことだ。そういったことであれば彼らがあなたのスケジュールにダメージを与えることはない。よいインテリア装飾家というのは、布見本やらサンプルやらをしょっちゅうクライアントの所に持ってきては選ばせる。しかし彼らは皿洗い機の置き場所については決してクライアントに相談しない。それはクライアントがどう思おうとシンクの隣だ。皿洗い機をどこに置くか議論して時間をつぶすのは意味がなく、それはシンクの隣に置く必要があり、それについては話題にすらしないのだ。クライアントにはカウンタートップをイタリア産みかげ石にしようか、メキシカンタイルにしようか、それともノルウェー材の寄せ木にしようかと200回も考えを変えるというような 、差し支えのないことをさせておくのだ。

重要な系の5．あなたがソフトウェアを披露するときにはスクリーンショットがすべてだ。それを100%の出来にしておくこと。

これがどれほどクールが想像してみてほしいと言って済ませられるなんて、一瞬たりとも考えないことだ。彼らが機能を見てくれるなどと期待 してはいけない。彼らはそんなことはしない。彼らはきれいなピクセルが見たいのだ。

スティーブ･ジョブズはこのことを理解している。そう、彼はこのことを理解しているのだ。アップルのエンジニアたちは、貴重なスクリーン上の不動産を無駄にしてでも新しいゴージャスな1024x1024サイズのアイコンをドックに入れるというような、素晴らしいスクリーンショットを作るための方法を学んでいる。そしてLinuxデスクトップの連中は半透明なxtermを作ることまでし、それはスクリーンショットを見栄えよくするが、使うのはわずらわしいものだ。GnomeやKDEが新しいものをリリースするとき、私はいつもまっすぐスクリーンショットを見に行って「ああ、彼らは惑星を木星から土星に変えたんだ。素晴らしい。」と言う。そして彼らが実際何をしたのかは全然気にしない。

このアーティクルの始めに出てきたCEOを覚えているだろうか？彼が不幸なのは、彼のチームが最初に素晴らしいPowerPointを見せたからだ—それはPhotoshopで作ったモックアップで、VBすら使っていない。そして彼らは今実際の中身を作っているところで、はたからは何もしていないように見えるのだ。

これに対して出来ることは何だろうtか？あなたがひとたび氷山の秘密を理解したなら、それと折り合っていくのは難しいことではない。暗い部屋でプロジェクタを使ってやるデモはピクセルがすべてだと理解すること。もし可能なら、まだ出来てない部分のUIはまだ出来ていないように見えるように作ることだ。たとえばツールバーのアイコンを、その機能が出来るまでは走り書きにするとか。Webサービスを作っているなら、機能ができるまでホームページからその機能をはずしておきたいと思うかもしれない。そうすれば人々は出来上っていくにつれて、コマンドが3つから20に増えていくのを見ることになる。

さらに重要なのは、人々がスケジュールについて考えることをしっかりコントロールすることだ。詳細なスケジュールをExcelで提供する。完成度が32%から35%に上がり、12月25日の出荷に向けてスケジュール通りに進んでいるというような自画自賛のメールを毎週関係各位に送ること。プロジェクトが適正なスピードで前に進んでいるかどうかの判断が事実に基づいて行われるようにすること。そしてボスにキャラウェイ製チタンドライバを使わせないこと。あなたが彼をどれくらい勝たせたいと思っているのか知らないが、USGAはそれを禁止しており、フェアじゃないのだ。