186 ー訳者あとがき 翻訳にあたっては、 ReVIEW ・ DocDiff ・ git ・ Dropbox ・ Emacs ・ xyzzy ・ PDIC ・英辞郎第五版のお世話になった。開発者のみなさんに感謝したい。 編集は『ウエブオペレーション』『リーダブルコード』『 Running レ an 』に引き続 Subversion ではなくてごめんなさい。 https://github.com/kmuto/review 2013 年 6 月 kdmsnr@gmail.com 角征典 き、オライリー・ジャパンの高恵子さんが担当された。 す
176 ー 6 章ユーザーも人間 図 6-13 ユーザーにギフトを届けよう てくれるし、チームがより人間的になる。 最初から難しく考える必要はない。 GoogIe は昔から工イプリルフールに変な プロダクトを発表してきた。たとえば、 YouTube のフロントページにあるすべ ての動画を「リックロール」にしたことがあるす。あるいは、 http://www.woot. com を見てほしい。これは日用品の販売サイトだが、広告のコピーが自虐的な ネタになっている。 ューザーを驚かせて幸せな気分にさせよう ( それが「喜び」だよね ? ) 。 Google す訳注説明が難しいので、 Wikipedia(http://ja.wikipedia.org/wiki/ リックロール ) を 昭してほしい。
XXI Amit patel にも感謝したい。 案をくれた Linda Stone 、 DeWitt Clinton 、 Bruce Johnson 、 Roland McGrath 、 Jim BIandy 、 Matt Braithwaite 、 Danny Berlin 、 Chris DiBonao アイデアや提 てくれて、アドバイスまでくれた素晴しい友人たちに感謝したい :KarlFogel 、 謝したい : Dave Baum 、 Matt Cutts 、 Will Robinson 、 Bill Duaneo 相談に乗っ ものになった。執筆途中にとんでもないミスを見つけてくれた友人と同僚に感 Jonathan LeBlanc 、 Piaw Na 、 Jack Welch0 彼らのおかげで本書がまとまった なさんに感謝したい : Dustin Boswell 、 Trevor Foucher 、 MichaeI Hunger 、 多数の指摘・アイデア・修正を提供してくれたテクニカルレビューアのみ の仕事は本当に楽しかったよ。 らの楽しいイラストのおかげで、本書がいきいきとしたものになった。君たちと http://sunnibrown.com の Sunni Brown と Amber Lewis に感謝したい。彼 がなければ、本書は存在しなかった。 Freedman と恐れ知らすの編集者 Mary Treselero Mary の励まし・忍耐・催促 O'ReiIIy Media のみなさんに感謝したい。表紙のテーマを担当した Edie れた人たちには感謝したい ( ミスはもちろんばくたちの責任だ ) 。 で出会った多くの人たちとの会話から生まれたものだ。特に大きな協力してく 表紙には著者 2 人の名前が載っているが、本書はこれまでの生活やキャリア 謝辞
144 ー 5 章組織的操作の技法 法やスペルのミスは避けること。うまくまとめられなかったり、背景や情報を記 入したりする必要があれば、メールの最後 ( 署名のあと ) に「詳細」や「状況説明」 として明記しておく。 Fitz のメールは冗長すぎた。今書くとしたら、以下のようになるだろう。 Date: Thu, 1 Feb 2001 To: sjobs@apple.com 件名 : 【ご相談】顧客体験がひどい ・学校の管理者である母に iMa ( をプレゼントしました。彼女は iMa ( に興奮し て、学校で購入する予算までとりました。 ・ 7 月に App 厄がロジックボードを交換しました。 1 か月後にはアナログボード を交換しました。 ・ 9 月にスリープ機能が故障しました。 12 月にモニタが故障しました。今は修 理中です。 母親は周囲に iMa ( がジャンクだと言っています。私も同僚に相談しましたが、 唯も解決策を知りませんでした。 母親の iMa ( を正常に動かすために私に何ができるでしようか ? 以上 - Fitz 不要な部分を削除して書き直してみた。これなら忙しい経営者でも 10 秒で読 める。 ばくたちはこうしたテクニックを使って、何度も物事を成し遂げてきた。た だし、世の中にあるヒントや裏技では不十分なこともある。
5.4 組織を操作する一 Date: Thu, 1 Feb 2001 To: sjobs@apple.com 141 件名 : 私たちのハードウェアの顧客体験がひどいです。どうすればいいですか ? 私の問題解決に何かアドバイスをいただけると幸いです。言いにくいのですが、 これは App 厄と私自身のためです。 先日、母の日に iMac を購入しました。母親はニューオリンズにあるモンテッ ソーリ学校の副校長をしています。学校では古い Macintosh を使っているので、 彼女は iMac を手に入れて興奮しています。学校の研究室で iMa ( を購入するため の予算をとったほどです。 しかし、私が購入した iMa ( のストロべリーは使い物になりませんでした。 ・ 7 月にスリープしたまま起動しなくなリました。母親が App 厄の代理店に持ち 込んだところ、ロジックボードの故障と診断されて、交換することになりまし ・母親は iMac を家に持ち帰リました。電源を入れました。起動しました。サッ ドマックが登場してデスチャイムが流れました。再び代理店に持ち込みまし た。今度はアナログボードの故障と診断されて、交換することになりました。 ・ 9 月に再度スリープ機能を使ってもらいました ( 再起動ではなく ) 。すると、 iMa ( はスリープから解除されなくなりました。電源を抜いてから電源を入れ ると、起動するようになリました。そのときからスリープ機能を使わなくなり ました。 ・ 12 月にモニタが黄色、緑、青になるちらっきが出てきました。母親は昨日、 代理店に持ち込みました。いまここです。 というわけで今日に至ります。母親は私が悪いイタズラをしていると思っていま す。そして、周囲に iMa ( はジャンクだと言っています。私も同僚に相談しまし
56 ー 2 章素晴しいチーム文化を作る スタイルガイドではそうした機能を挙げるどどもに、なぜ使用を制 限したのか、その理山についても説明しています。 Goog にか開発しているオープンソースプロジェクトは、このスタ イルガイドにしたがっています。 これは C + + のチュートリアルではないこどに注意してください。 読者は c + + についてよく知っているこどを想定しています。 28.2 ソ - スコードに名前を書く ( 別名 : 「 Autho 「タグ」問題 ) 一隹もが作品にクレジットを入れたがる。画家は絵画にサインを入れるし、作 家は背表紙に名前を入れる。プロガーもプログのトップに名前を入れている。 何とかして他人から認めてもらいたいというのが人間の本質だ。でも、ソース ファイルに名前を入れると、あくまでもばくたちの意見だが、百害あって一利 なしだ。たとえば、以下のような記述がソースファイルのトップに書かれてい るのを何度も目にしたことがある。 二一口 # Created: 0ctober 1998 by Brian W. Fitzpatrick く fitz@red-bean.com/ ソースコードのトップに名前を入れるのはもう古い ( 昔はばくたち 2 人もやっ ていた ) 。チームではなく個人でプログラムを書いていた時代はそれでよかった のかもしれないけれど、今では多くの人たちがコードに触れる。ファイルに名 前が書かれていると物議を醸すことになる。それは時間のムダだ。嫌な感情も 生み出してしまう。したがって、ソースコードに所有者としての名前を書くべ きではない ( レビューアとしての名前を書くのはいいが、その場合も所有権を示 すものではない ) 。 たとえば、チームのプロジェクトに新しいファイルを作ったとする。数百行
2.5 ハイレベルの同期ー 45 か ) を報告していくのだが、時間のムダだし、目が回るし、死にたくなってく る。簡単な告知と伝達だけにするべきだ。議論が必要なときはミーティングが 終わってから関係者だけでやればいい。主要な部分が終わったら退席しよう。 必要性を感じないときやメールで用事が済むようなときは、積極的に ーティ ングをキャンセルしよう。スタンディングミーティングに出席することがステー タス確認になっていて、誰も退席したがらないという文化を見たことがあるが、 正直どうかしていると思う。 —NOTE アジャイル開発方法論では「ディリースタンドアップミーティング」が推 奨されているが、 15 分程度であれば別に問題ないと思う。参加者は何を やっているかを手短に伝えるだけで済むし、実際に立ってやるところもい 。ただし、気を付けないとすぐに 30 分を超えるロングミーティングに なってしまう。セラピーセッションのようにみんながとりとめもない話を 始めるのだ。このようなミーティングが始まったら、誰かがうまく仕切っ てやめさせなければいけない。 新しいものを設計するのであれば、 ーティングに 5 人以上参加させてはい けない。意思決定者がいない限り、部屋に 5 人以上いたら決まるものも決まら ない。たとえば、友達 5 人と 6 つの観光地に行くとする。誰かが行き先を決め ない限り、すっと道路の片隅で議論を続けることになるだろう。 ーティングは作業時間の邪魔になる。これをポール・グレアムの「クリエ イターのスケジュールとマネージャーのスケジュールす」にちなんで、「クリエイ ターの時間」と呼びたい。 ーティングで頻繁に作業を中断させられていたら、 工ンジニアはゾーンに入ることができない。 3 ~ 4 時間のプロックを「多忙」や 「クリエイターの時間」にして、まとめて仕事を片付けよう。自分でミーティン http://www.paulgraham.com/makersschedule.html す
184 ー付録 2 あわせて読みたい lntroducing New ldeas 』 (Addison-WesIey) ・ Ormond Aebi 『盟 le Art & Adventure of Beekeeping 』 (Rodale press) ・ PauI Graham 「 Maker's ScheduIe, Manager's Schedule 」 (http://www. paulgraham.com/makersschedule.html) ・ Dustin BosweII 、 Trevor Foucher 『リーダブルコードーーより良いコードを 書くためのシンプルで実践的なテクニック』 ( オライリー ・ジャノヾン ) ・ジョージ・レナード『達人のサイエンスーー真の自己成長のために』 ( 日本教 文社 ) ・ "The Significance of Task Significance: Job Performance Effects, ReIationaI Mechanisms, and Boundary Conditions" ( 2008 ) by Adam M. Grant (JournaI of AppIied PsychoIogy 93 : 1 , pp. 10 124 ) ・ Norman L. Kerth 『 Project Retrospectives: A Handbook for Team Reviews 』 (Dorset House) ・リチャード・ワイズマン『運のいい人の法則』 ( 角川書店 ) ・チャディー・メン・タン『サーチ ! ( 宝島社 ) 富と幸福を高める自己探索メソッド』 ・ MichaeI し pp 『 BeingGeek ーーギークであり続けるためのキャリア戦略』 ( オライリー ・ジャノヾン ) ・シュワルツ『なぜ選ぶたびに後悔するのか - ーオプション過剰時 ・ノヾリュー 代の賢い選択術』 ( 武田ランダムハウスジャパン ) ・エリヤフ・ゴールドラット『クリティカルチェーン一一なぜ、 は予定どおりに進まないのか ? 』 ( ダイヤモンド社 ) ・シェイ『顧客が熱狂するネット靴店ザッポス伝説 撼させたサービスはいかに生まれたか』 ( ダイヤモンド社 ) プロジェクト アマゾンを震
ー 6 章ユーザーも人間 160 巨大なフォームや膨大な設定画面を表示するようなことだ。最初にアカウント を作らせるのもひどい仕様である。まだ何もしていないのに、これからも使い 続けることを約東させられるからだ。こうしたことをすると、ユーザーは違う意 味で驚いてしまう。 プロダクトがウエプアプリケーションであれば、高速に読み込むべきだ ! ば くたちはウエプページに時間を搾取されている。 3 ~ 4 秒で読み込まなかったら、 Fi レはそのページに興味を失うだろう。弁解の余地はない。入口で待たせてし まったら、ユーザーが入ってくれるはすがない。すぐにどこかへ移動してしま う。ページの読み込みを待つよりも、他のことをしたほうがいいからだ。 入り口のハードルをなくした例としては、 TripIt が挙げられる。これは旅行プ ランを管理するためのサービスだ。これを使うには、旅行の ( 飛行機・ホテル・ レンタカーなどの ) 確認メールを plans@tripit.com に送るだけでいい。それで TripIt が使えるようになる。一時的なアカウントを用意して、メールをパースし て、豪華な旅行プランのページを作って、準備ができたらメールで通知してく れるわけだ。まるで個人秘書のようである。しかもメールを転送するだけだ ! ほとんど何もしていないのに、普通のユーザーのようにページが見れる。必要 であれば、この時点で本物のアカウントを作ればいい。 プロダクトのハードルに懐疑的であれば、簡単なテストをしてみるといいだ ろう。ソフトウェアを技術系と非技術系の両方の人に使ってもらい、最初の 1 ~ 2 分を観察してみるのだ。驚くような発見があるかもしれない。 6.2.3 ユーザーではなく利用を計測する 利用の計測方法も考えておくべきだ。インストール数やユーザー登録数では なく利用だ。プロダクトはダウンロードではなく、利用されなければいけない。 「 300 万回ダウンロードされたぜ。 300 万人のユーザーだ ! 」という言葉を耳にし たことはないだろうか。ちょっと待ってほしい。 300 万回ダウンロードされて、
XXVIIII はじめに 「エンジニアが他人とうまくやる」という話のなかで、プログラマの仕事とは ( 一見 ) 関係がなさそうな話題についても触れている。それは、チームをリード する方法・組織を動かす方法・ユーザーと健全な関係を構築する方法を別の視 点から議論しているだけだ。これらは「管理職」や「プロダクトマネージャー」向 けの話に見えるかもしれないが、ソフトウェア工ンジニアをやっていると、自分 の意思とは関係なくこうした立場になってしまうことがある。騙されたと思って とにかく読んでほしい ! 本書に書かれてあることはすべて、ソフトウェア工ン 本書はそういう本ではない。 問題を規定の手続きで解決する本が好きだ。 ますは期待値を設定したい。意識の高いプログラマは、数学的に記述された 警告 : 技術マニュアルではない ジニアに関係したものだ。 り立っている。 い。本書に書かれてあることは、厳しい試練と大量のミスから学んだ教訓で成 修正・意見・反論があれば、 http://www.benandfitz.com/に送っていただきた にある話題からさまざまな議論を発展させてほしいと思う。フィードバック・ きないようなら、是非あなたの話を聞かせてください」。本書でも同じだ クを言っている。「この内容はほくたちの経験にもとづいています。もし同意で 免責事項をいくつか用意しておきたい。講演のときにはいつもこんなジョー よう。あるいは一晩寝てから考えよう ! 複数のページに意識を向ける必要がある。右脳を働かせてうまく結び付けてみ 取り上げてから、全体的な解決策について議論する。すべてを理解するには、 は工ッセー集のように読んでほしい。各章では、関連する問題を ( 逸話として ) げる問題や解決策はまとまっていないし、論理的に説明するのも難しい。本書 くたちはよく「人間は断続的なバグの大きな塊だ」と言っている。こで取り上 ソフトウェア開発の「人間的」な側面を扱ったものである。人間は複雑だ。ば