"Joel on Software" からの私的引用集
会社の業務システムは全てが誤りの産物であるように思え,いつも僕を非常に不安な状態にする. なんでこんなことになっているのだろうか? 最近,それを考えている.
有名なエッセイ集 "Joel on Software の日本語版" を読んで,ヒントになりそうな部分を抜き出してみた.
-
すべての若いコンサルタントが強力な2500回転のデウォルト製ドリルで頭の中にねじ込んで置かなければならないことが一つあるとしたら、それはこういうことだ:「顧客は自分が何がほしいか分かっていない。顧客に彼らが何を欲しいか知っていると期待するのはやめることだ。」
代わりにこう仮定することだ。いずれにせよあなたは何か作らなければならず、そして顧客がそれを気に入る必要があるが、しかし彼らは多少驚くことになるだろう。あなたは調査をする必要がある。あなたは顧客の問題を好ましい仕方で解決するデザインを見つけ出す必要がある。
(中略)
あなたの顧客は何が欲しいのかわかっていないと仮定しよう。その領域についてのあなたの理解に基づいて、あなた自身がデザインすることだ。あなたがその領域について学ぶために時間を使ったり、その領域の専門家の助けを借りるのは構わないが、ソフトウェアをデザインするのはあなたの仕事だ。あなたがその領域について下調べし、良いUIを作るなら、顧客は喜ぶだろう。
-
あなたが超高収益のレストランを持っていた場合に、あなたはすぐあることに気づくだろう。たとえあなたが毎晩店をいっぱいにし、オードブルで $19、コカコーラで$3.95ふんだくったとしても、一人のシェフにはそんなに多くの料理は作れないので、あなたの収益は自然な限界に達するということだ。そこであなたは別なシェフを雇い、別な町にも支店をいくつかオープンするかもしれない。
そうすると問題は拡がり始める: 私たち技術畑の人間がスケールの問題と呼んでいるものだ。
このスケールの問題を扱う一般的な方法は、何も知らない安いシェフを雇い、それぞれの料理の作り方について、失敗し得ないほど緻密なルールを彼らに与える、というものだ。そのルールに従ってさえいれば、すばらしいグルメ料理が作れる!
問題: それはあんまりうまく機能しない。良いシェフがすることは何百万とあり、それは即興で行われるものだ。良いシェフは市場ですばらしいマンゴーを見つけ、その日の魚料理のためにマンゴー・シラントロ・サルサを即興で作る。良いシェフは一時的なポテトの不足をタロイモチップなるものを作って補う。手引書に従っているだけのロボットシェフは、すべてが完全に機能しているときには与えられた料理を作ることができるが、本当のスキルと才能がなければ即興というのはできず、それがあなたがマクドナルドでクズイモを見ることのない理由だ。
(中略)
ここまでのまとめ:
- . ある種のことは本当にうまくやるには才能が必要だ。
- . 才能をスケールするのは困難である。
- . 人々が才能をスケールしようとしてやるのは、才能ある者に作らせたルールに才能のない者を従わせる、ということだ。
- . 結果として得られるものの品質はとても低い。
(中略)
何がこの物語の教訓だろう? メソドロジーには気をつけろ。それは陰鬱だが誰をもまずまずのレベルのパフォーマンスに引き上げるすばらしい方法だ。しかし同時に、もっと才能のある人々はその制約にイライラする。
-
よく管理されたハイテク企業と惨憺たるハイテク企業との違いを典型的に示す二つの話を、私自身の経験から紹介したい。その違いはつまるところ、従業員を信頼して仕事を成し遂げさせるか、それともさまよいだして何もかもぶち壊しやしないかとたえず監視し、管理している必要のあるハンバーガー焼きか何かみたいに扱うかの違いだ。
(中略)
Microsoftでは、もしあなたがExcelマクロストラテジーの仕事をしているプログラムマネージャであるなら、たとえあなたが会社に来て 6ヵ月に満たなかったとしても、そんなことは問題ではない。あなたはExcelマクロストラテジーの神であり、誰であれ、たとえナンバー6だろうと、あなたの邪魔をすることはできない.
これは非常に強いメッセージだ。ひとつには、誰もが自分の仕事により意識的になると言うことだ。彼らは「マネジメントが承認したから」という考えの陰に隠れることはできない、というのもマネジメントは仕様を実際にはよく見ないからだ。マネジメントのすることは、優秀な人材を雇い、何か彼らのする仕事を与えることにつきる。
-
しかしあなたは経営命令で組織を変える力を持ってないかもしれない。あなたが階級組織の最下層にいる下っ端のプログラマなら、人々にスケジュールやバグデータベースを作るように命令することができないのは明らかだ。そしてあなたがマネージャであったとしても、開発者を管理するのは牧猫するようなもので、違いはそんなに楽しくないことだとわかるだろう。「こうしろ」と言うだけではそうはならないのだ。
(中略)
戦略 1 実行あるのみ
一人の人間がそれをするだけでプロジェクトをずっと改善できることがたくさんある。デイリービルドするサーバがないって? 作ればいい。
(中略)
戦略 6 かけがえのないものになる
あなたが本当に優れた貢献者なのでないなら、これらの戦略のどれも機能しない。あなたが良いコードを、しかもたくさん書くのでないなら、あなたはコードを書いているべき時に、ただバグデータベースを怒っていじり回しているばかりだろう。
(中略)
あなたは管理する立場にいなくとも、ものごとを改善することはできる。しかしあなたはシーザーの妻である必要がある: 疑惑を招いてはならない。そうでなければあなたは敵を作るだけだろう。