タグ

joelに関するroyzumiのブックマーク (14)

  • Joel on Software - 氷山の秘密、明らかに

    Joel Spolsky ジョエル・スポルスキ 翻訳: Yasushi Aoki 青木靖 2002/2/13 「うちの開発チームのどこが悪いのか分からない。」とCEOは心の中でつぶやく。「プロジェクトを始めたころには何もかもうまく行っていたんだ。最初の2 週間チームは馬車馬のように働いて、ちゃんと動くプロトを作ったんだ。ところがその後は進み具合が這うように遅くなった。単に連中が怠けてるだけということかもしれん。」彼はキャラウェイ製のチタンドライバを選び、キャディに冷たいレモネードを取りに行かせる。「2、3人首を切れば、連中の尻にも火が付くだろう!」 その間、もちろん開発チームの方は何が悪いのか全然見当も付かない。実際何もまずいことはないのだ。彼らはスケジュール通りに進んでいる。 こんなことがあなたの身に起こらないようにすることだ!あなたの人生を百万倍も楽にしてくれる、こういう非技術系マネジ

  • Joel on Software - 二つの話

    Joel Spolsky ジョエル・スポルスキ 翻訳: Yasushi Aoki 青木靖 2000/3/19 よく管理されたハイテク企業と惨憺たるハイテク企業との違いを典型的に示す二つの話を、私自身の経験から紹介したい。その違いはつまるところ、従業員を信頼して仕事を成し遂げさせるか、それともさまよいだして何もかもぶち壊しやしないかとたえず監視し、管理している必要のあるハンバーガー焼きか何かみたいに扱うかの違いだ。 私のはじめての職場における最初の仕事は、マイクロソフトでExcelの新しいマクロ言語ストラテジーを考え出す、というものだった。私はすぐに「Excel Basic」(これは後にVisual Basic for Applicationsに発展したものだが、それはまた別な話である)の最初のドラフト仕様を書いた。すると、「アプリケーションアーキテクチャ」グループと呼ばれる得体の知れない人

    royzumi
    royzumi 2007/06/06
  • Joel on Software - ゲリラ的雇用面接のすすめ

    Joel Spolsky ジョエル・スポルスキ 翻訳: 松村 弘典 2000-03-23 Fog Creek Softwareでは適切にスタッフを採用する事が必須である。我々の業界では対象となる人々を3つのタイプに分類する事が出来る。一方には 未洗のイモ とでも呼ぶべき、この業種に従事するのに基的なスキルさえも持ち合わせていない集団がいる。これらの人たちは履歴書を注意深く確認して2,3の簡単な質問をする事で比較的容易に除外する事が出来る。対極には スーパースター と呼ばれる、パーム上で動くLispコンパイラを週末の暇つぶしにアセンブリ言語で書いてしまうような人たちがいる。これらの中間にあたるのが大多数の「応募者」で、何かしらやってくれるのではないかと思わせる人たちである。ここで紹介する幾つかのトリックはこれら一般的な応募者とスーパースターとの違いを見極めるためのものであり、Fog Cre

  • Joel on Software - ストラテジーレターⅢ: もとに戻してくれ!

    Joel Spolsky ジョエル・スポルスキ 翻訳: Yasushi Aoki 青木靖 2000/6/3 あなたが人々を競合製品からあなたの製品に乗り換えさせようとするなら、あなたは参入障壁について理解する必要があり、それもあなたが思っているよりずっと良く理解している必要があり、そうでなければ人々は乗り換えず、あなたはテーブルが空くのをただ待ち続けることになるだろう。 以前のレターで、私は2種類の会社の間の違いについて書いた:確立した競合を置き換えようとするベン&ジェリー・タイプの会社と、確立した競合のいない新しい領域で「土地収用」しようとするアマゾン・タイプの会社だ。私が90年代の初めにMicrosoft Excel仕事をしていたとき、それは正真正銘ベン&ジェリータイプだった。Lotus 123という確立した競合がほとんど完全にスプレッドシートのマーケットを独占していた。確かに新しく

  • Joel on Software - ストラテジーレターⅡ:鶏と卵の問題

    Joel Spolsky ジョエル・スポルスキ 翻訳: Yasushi Aoki 青木靖 2000/5/24 広告の質は捕まらずに嘘をつくということだ。多くの企業は広告キャンペーンを行うとき、単に彼らの会社の最も具合の悪い事実を取り上げ、それを上下逆さまにし(「嘘」)、そしてその嘘をよく練習するのだ。これを「繰り返される主張による証明」と呼ぶことにしよう。たとえば飛行機旅行というのは窮屈で快適なものではなく、航空会社の従業員は無作法で気に障り、そもそも商用航空システム全体が拷問の手段としてデザインされている。そこでほとんどあらゆる航空会社の広告は、飛行機旅行がいかに快適で楽しいものであり、その中のあらゆる場面であなたがいかにちやほやされるかという話になる。飛行機の座席でバスケットの中の赤ん坊になった夢を見ているビジネスマンの広告を英国航空が見せるとき、すべての合理性の感覚は永遠に消え失せ

  • Joel on Software - ストラテジー・レターⅠ: ベン&ジェリー 対 アマゾン

    Joel Spolsky ジョエル・スポルスキ 翻訳: Yasushi Aoki 青木靖 2000/5/12 会社を作っている?あなたがしなければならない非常に重要な決断がひとつあって、それはあなたのする他のすべてのことに影響する。あなたがどんなことをするにせよ、あなたは自分がどちらのキャンプに属しているのかを知り、あらゆることをそれに合わせて行う必要があり、そうしなければ災難に見舞われるだろう。 何の決断かって?ゆっくりと有機的に収益を上げながら成長するか、それとも非常に早い成長と大量の資金でビッグバンを起こすかだ。 有機的モデルでは限定された目標を設定した小さな会社から始め、長い時間をかけてゆっくりとビジネスを構築する。これを(アイスクリーム会社の)ベン&ジェリー・モデルと呼ぼう、というのもベン&ジェリーがこのモデルに非常によく合っているからだ。 もう一方のモデルは「急成長」モデル(別

  • Joel on Software - やさしい機能仕様 - パート 4: ヒント

    Joel Spolsky ジョエル・スポルスキ 翻訳: 2000/10/15 さて、私たちはなぜ仕様書が必要なのか、仕様書の中身は何か、そして誰がそれを書くべきかについて話してきた。このシリーズの最後のパートでは、良い仕様書を書くためのアドバイスをお話ししよう。 仕様書を実際に書いているチームから聞く最大の不平は、「誰も読まない」ということだ。誰も仕様書を読まない場合、それを書いている人たちはひがみっぽくなる。エンジニアが4インチの厚さの仕様書の山を使ってキュービクルを拡張している昔のディルバートの漫画みたいなものだ。典型的な官僚的大企業では、みんな何ヶ月もかけて退屈な仕様書を書いている。仕様書が出来上がると、それは棚に収められ、再び取り下ろされることはなく、製品は仕様書に書かれていることとは無関係にスクラッチから実装される。それは誰も仕様書を読まないからで、そしてなぜ誰も読まないかと言え

    royzumi
    royzumi 2007/06/06
  • Joel on Software - やさしい機能仕様 - パート 3: だけど・・・どうやって書くの?

    Joel Spolsky ジョエル・スポルスキ 翻訳: Yasushi Aoki 青木靖 2000/10/4 あなたはなぜ仕様書を書く必要があるのかと仕様書に書くべきことは何かについて学んだ。では誰がそれを書くべきかについて話すことにしよう。 誰が仕様書を書くか? こごでMicrosoft歴史について少し話をさせてほしい。Microsoftが急速に成長し始めた1980年代のことだが、ソフトウェアマネジメントの古典である人月の神話はみんな読んでいた(あなたがまだ読んでいないのなら、ぜひともお勧めする)。このの要点は、遅れているプロジェクトにプログラマを増員すると、プロジェクトはよけい遅れるということだ。その理由は、チームにn人プログラマがいるとき、コミュニケーション・パスの数はn(n-1)/2で、これはO(n2)で増加するからだ。 そのためMicrosoftのプログラマたちは、どんどん大

    royzumi
    royzumi 2007/06/06
  • Joel on Software - やさしい機能仕様 - パート 2: 仕様書とはどんなものか?

    Joel Spolsky ジョエル・スポルスキ 翻訳: Yasushi Aoki 青木靖 2000/10/3 (パート1はもう読んだ? 読んでなければ、ここにある。) このアーティクル・シリーズで扱っているのは機能仕様であって、技術仕様ではない。人々はこの2つを混同している。標準的な用語があるのかどうか知らないが、私がこれらの用語を使うときに意味しているのは以下のことだ。 機能仕様書は、ユーザの観点から製品がどのように動くか記述する。それはどのように実装されるかは問題にしない。それは機能を話題としており、画面とか、メニューとか、ダイアログとかいったものの仕様を定める。 技術仕様書は、プログラムの内部の実装について記述する。それはデータ構造、関係データベースモデル、プログラミング言語や開発ツールの選択、アルゴリズムといったものを話題としている。 あなたが製品を隅から隅までデザインするとき、最

    royzumi
    royzumi 2007/06/06
  • Joel on Software - やさしい機能仕様 - パート 1: なぜわざわざ書く必要があるのか?

    Joel Spolsky ジョエル・スポルスキ 翻訳: Yasushi Aoki 青木靖 2000/10/2 The Joel Testを発表したとき、読者から寄せられた最大の不満の種は、仕様書を書かなければならないということだった。仕様書はデンタルフロスみたいなもので、みんな書かなきゃいけないと思ってはいるが、誰も書かない。 なぜ人々は仕様書を書きたがらないんだろう? 人々は仕様書作成フェーズを飛ばせば時間を節約できると主張している。彼らは仕様書作成がNASAのスペースシャトルのエンジニアか巨大な保険会社で働いているような人たちのための贅沢品であるかのように振舞っている。戯言だ。何よりも仕様書を書かないというのは、あなたがソフトウェアプロジェクトに持ち込む、最大かつ不必要なリスクである。それは着替えだけリュックに詰めて、その場になれば何とかなることを期待してモハーベ砂漠の横断に出発するの

    royzumi
    royzumi 2007/06/06
  • Joel on Software - ストラテジーレターV

    Joel Spolsky ジョエル・スポルスキ 翻訳: Yasushi Aoki 青木靖 2002/6/12 大学に行っていたとき、私は初歩的な経済学のコースを2つ取った: マクロ経済学とミクロ経済学だ。マクロ経済学は「低い失業率はインフレを招く」というような理論でいっぱいで、決して現実に根ざしてはいない。しかしミクロ経済学の方はクールでしかも役に立った。需要と供給に関する実際に役に立つアイディアがたくさんあるのだ。たとえば、価格を下げる競合がいるとき、あなたが彼らに追随しなければあなたの製品の需要は減る、というような。 今日のエピソードでは、そのような考え方のひとつが馴染み深いコンピュータ会社についていかに多くのことを説明してくれるか示そうと思う。その過程で、私はオープンソースソフトウェアに関する興味深いあることに気がついた。それが何かというと、オープンソースソフトウェア開発に多額の資金

    royzumi
    royzumi 2007/06/06
  • Joel on Software - 下っ端でも何かを成し遂げる方法

    Joel Spolsky ジョエル・スポルスキ 翻訳: Yasushi Aoki 青木靖 2001/12/25 このサイトではソフトウェアマネジメントを扱っている。しかしあなたは経営命令で組織を変える力を持ってないかもしれない。あなたが階級組織の最下層にいる下っ端のプログラマなら、人々にスケジュールやバグデータベースを作るように命令することができないのは明らかだ。そしてあなたがマネージャであったとしても、開発者を管理するのは牧するようなもので、違いはそんなに楽しくないことだとわかるだろう。「こうしろ」と言うだけではそうはならないのだ。 ジョエルテストで低いスコアしか取れない組織であなたが働いているのなら、それはいら立たしいことだろう。あなたのコードがいかに良くとも、あなたの同僚がああもまずいコードを書き、あなたは自分がそのプロジェクトに関係付けられていることが恥ずかしく感じられる。あるい

    royzumi
    royzumi 2007/06/06
  • Joel on Software -

    プログラマのためのユーザインタフェースデザイン 第 1 章 第 2 章 第 3 章 第 4 章 第 5 章 第 6 章 第 7 章 第 8 章 第 9 章 ストラテジーレターV 2002年6月12日 ミクロ経済学の補完財の原理について考えていて、私はオープンソースソフトウェアに関する興味深いあることに気がついた。それが何かというと、オープンソースソフトウェア開発に多額の資金を使っている企業の多くは、それが彼らにとって良いビジネス戦略だからそうしているのであって、突然資主義を信じるのをやめて、「言論の自由と言うときの自由」に浮かれるようになったわけではないということだ。ストラテジーレターⅤ 5つの世界 2002年5月6日 5つの世界:すべてのソフトウェア開発が同じではない。 追記:インターナルシステム、コンサルウェア、パッケージソフトの間には大きなグレーゾーンがあり、この3つの世界はしばし

  • Joel on Software - ジョエル・テスト

    Joel Spolsky ジョエル・スポルスキ 翻訳: Fukushige Erika 福重 永里香 翻訳チェック: Takeda Toshiyuki 武田俊之 9.8.2000 SEMAについて聞いたことがある?かなり難解なシステムで、ソフトウェアの開発チームがどれくらい良いかを測るためのものだ。ちょっと待った!そのリンクに飛ばない方がいい。きっと書いてあることを理解するだけで6年はかかるだろう。そこで、私は自分で作ることにした。これはソフトウェア開発チームの質を評価するものだが、とっても当てにならないいいかげんなテストだ。このテストの素晴らしいところは、3分程度で終わることだ。節約した時間を使って、医学部に通うことだってできるだろう。 ジョエル・テスト ソース管理システムを使っているか? 1オペレーションでビルドを行えるか? 毎日ビルドを行うか? 障害票データベースを持っているか? 新

  • 1