Joel on Software - やさしい機能仕様 - パート 4: ヒント
Joel Spolsky ジョエル・スポルスキ 翻訳: 2000/10/15 さて、私たちはなぜ仕様書が必要なのか、仕様書の中身は何か、そして誰がそれを書くべきかについて話してきた。このシリーズの最後のパートでは、良い仕様書を書くためのアドバイスをお話ししよう。 仕様書を実際に書いているチームから聞く最大の不平は、「誰も読まない」ということだ。誰も仕様書を読まない場合、それを書いている人たちはひがみっぽくなる。エンジニアが4インチの厚さの仕様書の山を使ってキュービクルを拡張している昔のディルバートの漫画みたいなものだ。典型的な官僚的大企業では、みんな何ヶ月もかけて退屈な仕様書を書いている。仕様書が出来上がると、それは棚に収められ、再び取り下ろされることはなく、製品は仕様書に書かれていることとは無関係にスクラッチから実装される。それは誰も仕様書を読まないからで、そしてなぜ誰も読まないかと言え
Joel on Software - やさしい機能仕様 - パート 3: だけど･･･どうやって書くの?
Joel Spolsky ジョエル・スポルスキ 翻訳: Yasushi Aoki 青木靖 2000/10/4 あなたはなぜ仕様書を書く必要があるのかと仕様書に書くべきことは何かについて学んだ。では誰がそれを書くべきかについて話すことにしよう。 誰が仕様書を書くか? こごでMicrosoftの歴史について少し話をさせてほしい。Microsoftが急速に成長し始めた1980年代のことだが、ソフトウェアマネジメントの古典である人月の神話はみんな読んでいた(あなたがまだ読んでいないのなら、ぜひともお勧めする)。この本の要点は、遅れているプロジェクトにプログラマを増員すると、プロジェクトはよけい遅れるということだ。その理由は、チームにn人プログラマがいるとき、コミュニケーション・パスの数はn(n-1)/2で、これはO(n2)で増加するからだ。 そのためMicrosoftのプログラマたちは、どんどん大
Joel on Software - やさしい機能仕様 - パート 2: 仕様書とはどんなものか?
Joel Spolsky ジョエル・スポルスキ 翻訳: Yasushi Aoki 青木靖 2000/10/3 (パート1はもう読んだ? 読んでなければ、ここにある。) このアーティクル･シリーズで扱っているのは機能仕様であって、技術仕様ではない。人々はこの2つを混同している。標準的な用語があるのかどうか知らないが、私がこれらの用語を使うときに意味しているのは以下のことだ。 機能仕様書は、ユーザの観点から製品がどのように動くか記述する。それはどのように実装されるかは問題にしない。それは機能を話題としており、画面とか、メニューとか、ダイアログとかいったものの仕様を定める。 技術仕様書は、プログラムの内部の実装について記述する。それはデータ構造、関係データベースモデル、プログラミング言語や開発ツールの選択、アルゴリズムといったものを話題としている。 あなたが製品を隅から隅までデザインするとき、最
Joel on Software - やさしい機能仕様 - パート 1: なぜわざわざ書く必要があるのか?
Joel Spolsky ジョエル・スポルスキ 翻訳: Yasushi Aoki 青木靖 2000/10/2 The Joel Testを発表したとき、読者から寄せられた最大の不満の種は、仕様書を書かなければならないということだった。仕様書はデンタルフロスみたいなもので、みんな書かなきゃいけないと思ってはいるが、誰も書かない。 なぜ人々は仕様書を書きたがらないんだろう? 人々は仕様書作成フェーズを飛ばせば時間を節約できると主張している。彼らは仕様書作成がNASAのスペースシャトルのエンジニアか巨大な保険会社で働いているような人たちのための贅沢品であるかのように振舞っている。戯言だ。何よりも仕様書を書かないというのは、あなたがソフトウェアプロジェクトに持ち込む、最大かつ不必要なリスクである。それは着替えだけリュックに詰めて、その場になれば何とかなることを期待してモハーベ砂漠の横断に出発するの
間違ったコードは間違って見えるようにする - The Joel on Software Translation Project
Joel Spolsky / 青木靖 訳 2005年5月11日 水曜 私が最初の本当の仕事をはじめたのは1983年9月に遡る。それはオラニムというイスラエルの大きな製パン工場で、16台の飛行機ほどもある巨大なオーブンで、毎晩10万個のパンが作られていた。 はじめて工場に入った時、そのあまりの汚さに信じられない思いだった。オーブンの側面は黄ばんでいるし、機械は錆びていて、そこらじゅうが油だらけだった。 「いつもこんなに汚いの?」と私は聞いてみた。 「なんだって? なんの話をしてるんだ?」とマネージャが答えた。「掃除したばかりだから、今が一番きれいな状態なんだ」 なんてこった。 毎朝の工場の清掃を何ヶ月か続けて、ようやく彼らの言っていたことが理解できるようになった。パン工場では、きれいというのは機械にパン生地が付いてないことを言うのだ。きれいというのは、ゴミ箱に発酵したパン生地が入ってないこと
Joelに聞く、「優れた開発者」の要件・心構え・努力すべきこと：CodeZine
世界的に認知されているソフトウェア開発プロセスのエキスパート。彼のWebサイトJoel on Softwareは、世界中のソフトウェア開発者に人気があり、30以上の言語に翻訳されている。ニューヨークにあるFog Creek Softwareを創業し、ソフトウェアチームのためのプロジェクトマネジメントシステムとして人気のあるFogBugzを作った。JoelはMicrosoftでExcelチームのメンバーとしてVBAをデザインし、Juno Online Servicesでは数百万人が使うインターネットクライアントを開発した。 優れた開発者の要件――まず、「優れた開発者にはどのようなことが求められるか」についてお聞かせください ああ、大変だ。それなら12箇条ありますね。(笑) まじめに答えると、見方が二つあって、ひとつは成功するチームを作る上で誰を選ぶかということです。私はそういうとき、頭がよく
記憶に残るようなカスタマサービスへの7ステップ - The Joel on Software Translation Project
Joel Spolsky / 青木靖 訳 2007年2月19日 月曜 自力で立ち上げたソフトウェア会社であるFog Creekには、最初の2年くらいの間カスタマサービス専任のスタッフを雇う余裕はなかった。それでマイケルと私がカスタマサービスをやっていた。顧客を助けるために費やされる時間は、私たちが製品を改善するのに使うべき時間を奪うことになったが、私たちはその中で多くのことを学び、今ではカスタマサービスをずっとうまく運営できるようになった。 以下では記憶に残るようなカスタマサービスを提供するために私たちが学んできたことを述べようと思う。ここで｢記憶に残る｣と書いたのは文字通りでの意味だ。目指しているのは、あまりにすばらしくて人々の記憶に残るようなカスタマサービスを提供するということなのだ。 1. 問題はすべて2通りの方法で解決する テクニカルサポートの問題はほとんどすべて2通りの解決法があ
開発抽象化レイヤ - The Joel on Software Translation Project
Joel Spolsky / 青木靖 訳 2006年4月11日 火曜 若い男が町にやってきた。彼は見かけも悪くないし、ちょっとは金も持っていた。 過去のことについてはあまり話したがらないが、血の通ってない大企業に長くいたらしいことは明らかだった。 彼は生まれつき人当たりが良く社交的で、自分に自信を持っていながら傲慢ではない。だから地元のプログラマーズ・カフェにある求職の掲示の中からちょっとした仕事を見つけるのは、彼には簡単なことだった。しかし保険データベースプロジェクトや、主婦向けの飾りだらけのWebページや、会計計算エンジンといったものには、やがて興味をなくしてしまった。 １年もたつと、彼の慎ましい生計を1年支えられるくらいの蓄えができた。それで贔屓にしてくれるアルザス人へのコンサルティング仕事の後、食料品店の上にある自分のアパートの陽の当たる部屋にコンピュータを据え付け、選りすぐったツ
Javaスクールの危険 - The Joel on Software Translation Project
Joel Spolsky / 青木靖 訳 2005年12月29日木曜 近頃の若い者ときたら。 勤勉はいったいどこへ行ってしまったんだ? 「近頃の若い者」は我慢がないと不平を言うようになったのは、私も年を取ったということなのかもしれない。 そりゃ恵まれてるね。私は3ヶ月汚水浄化槽の中の茶色い紙袋に住んでいたよ。朝6時に起きて、袋を掃除し、固くなったパンの耳を食べ、工場まで歩いて行くと、1日14時間、毎週毎週働きつづけ、家に帰ると親父にベルトでたたかれて寝床についていたんだ。 ——モンティ・パイソンの空飛ぶサーカス 4人のヨークシャー人 私は若い頃、パンチカードでプログラムを作る方法を学んだ。ミスをしたら、それを訂正するためのバックスペースのような近代的な機能は存在しなかった。カードを捨ててはじめから打ち直すのだ。 私は1991年にプログラマの面接をするようになった。コーディングの問題に答える
Japanese - The Joel on Software Translation Project
[edit] カリフォルニア 2007年10月5日 [edit] FogBugz On Demand 2007年7月9日 [edit] マネジメントの本 2007年6月29日 [edit] 記憶に残るようなカスタマサービスへの7ステップ 2007年2月19日 [edit] ファウンダーズ アット ワーク 2007年1月30日 [edit] Copilot 2.0リリース! 2007年1月26日 [edit] ビッグピクチャー 2007年1月21日 [edit] 新年の抱負: もっといい仕事につくこと! 2006年12月20日 [edit] 50万件のバグ! 2006年12月20日 [edit] 新作! 2006年12月18日 [edit] エレガンス 2006年12月15日 人々がソフトウェアをいじるのは、多くの場合、それで遊びたくてそうしているわけではない。彼らがソフトウェアを使うの
はじめてのBillGレビューのこと - The Joel on Software Translation Project
Joel Spolsky / 青木靖 訳 2006年6月16日 金曜 かつてExcelは名もないまったく無様なプログラミング言語を持っていた。私たちはそれを「Excelマクロ」と呼んでいた。はなはだ機能不全なプログラミング言語で、変数もなく(値はワークシートのセルに入れる必要があった)、サブルーチンもなく、つまるところ、ほとんど保守不能なものだった。「Goto」みたいな先進的な機能も持っていたが、ラベルは実質不可視だった。 それがまっとうなものに見えていた唯一の理由は、Lotusのマクロに比べたらずっとましということだった。Lotusマクロはワークシートのセルに長々と入れられたキーストロークの並び以外の何物でもなかった。 1991年6月17日、私はMicrosoftのExcelチームで働きはじめた。私の肩書きは「プログラムマネージャ」だった。私にはこのマクロの問題を解決する方法を作り出すこ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
議論: アーキテクチャの書き直しは避けるべきか?