闘うプログラマー2009/08/14 01:16


闘うプログラマー[新装版] ビル・ゲイツの野望を担った男達 (単行本(ソフトカバー))

G・パスカル・ザカリー (著), 山岡 洋一 (翻訳)


Windows 7のリリースにあわせてなのか、再版されていた。おもしろいセンテンスだけ抜き出した読書メモ。




1990年1月の時点ではNTはモノにならないだろうと考えられていたらしい。

マリッツは、NTについて、「技術革新の練習であって製品ではなく、しかも「ろくにコーディネートされていない練習だ」と判断した。ウィトマーのグラフィック・チーム、ルビンのネットワーク・チーム、NTチームがすべてカトラーの指揮下で一つのチームになれば、状況は良くなるだろうと考えた。そうしないかぎり、NTは商品にならないだろう。



開発の初期の段階で、グラフィック・チームのひとりである、ムーアは精神的に病み、仕事ができなくなってしまった。

「どうせチャック(ウィトマー)が変えてしまうのに、決める必要がどこにあるんだ。何を考えようと関係無い。これはチャックの製品だ。すべてはあいつが決める。オレは奴隷のように、それを実現すればいいだけだ」

ムーアは、「破滅的な悪循環」に陥っているとも思っていた。この7年間、マイクロソフトで1日12時間も過ごしてきた。友人はしだいに遠ざかり、真綿で首を絞めるようにじわじわと孤独感が襲ってきた。こんなことになるとは思わなかった。「懸命に働いていて、知り合いはいないし、何人かの友人は、みな忙しい。それなら、もうすこし働こうと考える。働き続けて、知り合いがもっと減っていき、やりたいことも減っていく。しばらくすると、仕事以外なにも残らなくなる」。そうなると、仕事まで中身のないつまらないものに思えてくる。必死に逃げようとしても、追われているような気がしてくる。



プログラム管理者:ユーザーがよろこんだり、満足するような機能や改良を提案するのが仕事。

マイクロソフトのプログラム管理者は、コードを書かないが、製品の仕様を決める作業を支援する。その影響力は大きく、プログラミング責任者以上の力を持つこともある。しかし、意見を通すには、相手を説得するしかない。プログラマーに直接、自分のアイデアを実現するように命じる権限はない。しかし、プログラマーに拒否された場合、希望するコードを外注する権限を持っている。


カトラーのプログラム管理者へ対する評価

自分やチームに口出ししようとするプログラム管理者は、みんなくそくらえだ。
・・・
わたしはいつも闘っている。連中がもっとまともなら、いつもこれほどピリピリせずに済むだろう。わたしのような人間は、めったにいない。正しいことなら、何だって取り入れる。昼も夜も懸命に働く。しかし、難しい仕事をやると決めた後で、とやかく口を出すな」


マリッツが1990年の春から夏にかけて、ゲイツとバルマーを説得してOS/2から開発リソースをNTに移すように進言。

NTは「本当に真剣に取り組まなければ」完成しない。ところが、マイクロソフトには「NTを製品として仕上げるために必要な資源さえない」。OS/2に時間と資金をつぎ込みすぎているからだ。
マリッツは2人に、このままでは自分はOS/2の責任者として失敗するのは間違いないと言った。「戦略を変えなければ、自分の人生を無駄にしていると感じる。勝てる見込みのない戦略をとっているのに、緊張やストレスに耐えようとする者がいるだろうか


マイクロソフトのスタイル

「コードにあれこれ注文は出さない。注文はたった一つ、動くものを作ってくれということだけだ」とルコフスキーに言った。
カトラーの指示は、プログラマーに自由にやらせるというマイクロソフトの伝統にのっとっている。「社員のほとんどは、やる気をおこさせないといけないタイプではなく、やる気がありすぎて抑えるのに苦労するタイプだ」とあるベテランは語る。

マイクロソフトでは管理者もコードを書くのが原則だ。ゲイツは、まともなコードが書けるプログラマーだけが管理者になるべきで、管理者になってからもコードを書き続けるべきだと考えている。これはソフトウェア会社が陥りやすい問題を見事に解決する方法だ。ソフトウェア会社では、管理者はプログラマーのいいなりになりやすい。スケジュールは守られず、製品は失敗に終わり、予算は膨れあがる。すべては、現代の魔術師がしていることを、トップの人間が理解できないからだ。最初は成功したソフトウェア会社が、コードを知らない管理者の失敗で急激に転落した例はいくつもある。

マイクロソフトは、十分な研修をしないことで有名だ。「泳げないヤツは沈めばいい」というのが、新人のルールだった。




自分で作ったドッグフードを食え、とは?

カトラーは、半分は男らしさを見せるために、半分は常識的は判断から、「ドッグフード」を食べることを重視していた。つまり、「自分で作ったプログラムを使う」べきなのだ。ドッグフードを食べていれば、NTの欠陥や不十分さから目を背けることができなくなる。
・・・
当初は、ドッグフード程度の味しかしないのであれば、ますますこれを食べるべきだ。プログラマーは、早急に品質を上げなければならないと実感し、すぐにコードのエラーを修正し、もっと信頼性の高いコードを書くようになるだろう。



MSのマニュアル整備に対する姿勢

マニュアルは冗談のタネにされることが多いが、聖書を読むように熱心に読めば、いくつもの秘密があきらかになる。マニュアルが良ければ、ソフトをもっと使いこなせるようになる。マニュアルのほとんどは悲惨なもので、良いものをつくれば目立つことになる。ユーザーは普通、マニュアルの出来にはほとんど関心を持たない。ソフトを使いこなそうとするときにも、マニュアルは避けている。しかし、プログラミングの専門家は、すみからすみまで、必死になって読む。オペレーティング・システムではとくにそうだ。



チームでのソフトウェア開発

理想のソフト開発チームは、人数がひとりのチームだと、カトラーが皮肉ったことがある。


クリフ・バン・ダイク(セキュリティ機能担当のプログラマー)

プログラミングの能力には限度があり、休みをとって充電しなければ、能力がすぐにつきてしまうと考えている。

不思議なもので、「勤務時間を長くすると、正しい答えを見つけ出すまでにかかる時間も多くなる」。

「マイクロソフトでは、注意していないと、いくらでも自分の時間を食われてしまう」。だから、自分を守るために、「オフィスからはなれるべきだ。1日の仕事が終わったら、家に帰るべきだ」と言う。



理想やスタイルは想像力の源泉である

プログラマーはコードの設計にあたって、論理や数学に頼っているので、技術的な判断では個性は重要ではないと考えている。しかし、過去に偉大な発見や工夫がいくつもあるのだから、どう判断すべきかは決まっていると考えるのは幻想にすぎない。ほぼおなじ目的を達成するための方法は、技術的にみていくつもある。



NT開発がマラソンといえるほどになって、緊張をほぐす遊びと、単なる時間の区別をする必要がでてきた。

ある日、カトラーはNTチーム全員が共有している電子掲示板、NTDevで、関係代名詞の正しい使い方について、熱心な議論が戦わされていることに気がついた。
・・・
この時期に熱心に議論するような問題なのか。文法についての議論はやめろ、とカトラーは命令した。「これをNTDevから削除しろ。今度おなじものがあったら、てめえらのオフィスの壁をぶちやぶって話をつけにいく」。


レジストリーはセキュリティについでの大論争の結果、つくられたものだ。セキュリティ機能の一部として、ネットワークに接続している個々のパソコンをユーザーにあわせて、簡単にカスタマイズできるようにすることが、最大の目的だ。



1992年12月16日のビル・ゲイツによる出荷の可否を判断するためのレビュー

ゲイツは会議に出るにあたって、腹を決めていた。「こいつを出荷する」つもりだった。
・・・
コンピューターの新しい時代を切り開くためには、妥協すべき点は妥協するつもりだった。たとえば、8MBのメモリーのパソコンでNTを使えるようにするという希望はもうあきらめていた。NTがまともに動作するには、最低16メガバイトのメモリーが必要になりそうな形勢だ。
・・・
しかし、パフォーマンスではそうはいかない。この点では妥協できない。ここで妥協すれば、ユーザーに見向きもされなくなるだけだ。
・・・
ゲイツにも頭が上がらない相手がいるとすれば、その名はスピードだ。ウィンドウズのアプリケーション・ソフトがNTでそこそこ速く動かないのであれば、ユーザーはNTのすばらしい機能を無視して、おなじウィンドウズのソフトをDOSで使い続けるだろう。ひょっとすれば、最大のライバル、IBMが売っているOS/2を選ぶかもしれない。人気の高いソフトはどれもOS/2には対応していないが、IBMは死んだも同然のこのプラットフォームを生き返らせるうまい方法を考えついている。今後のバージョンでは、ウィンドウズのソフトが、DOSと変わらぬスピードで(ひょっとしたら、DOSより速いスピードで)うごくようにする計画なのだ。



結局この会議ではパフォーマンス上の疑問から、会議は大荒れし、ビルgの決定は保留され、6週間後にもう一度会議を設定

1993年2月1日のゲイツとNTチームの会議で、マリッツはNTが「ようやく最終コーナーをまわった」と感じた。ウィンドウズのアプリケーションを実行したときの速度は、まだDOSより遅かったが、違いは小さくなり、ゲイツも満足した。


バグをとれ、ということ。

どういう欠陥があって、周囲の人たちを傷つけることがあるにしろ、普通の生活のなかで仕事への集中を妨げるものを片っ端から封じこめられるからこそ、すばらしい仕事ができる。普通の人たちに偉大な仕事ができないのは、めったにない仕事に取り組んでいるときですら、日常の習慣にとらわれているからである。月並みな仕事しかできないのは、才能がないからではない。意志に問題があるからだ。カトラーはそう考えている。この段階にきて、カトラーはチームの全員がたったひとつのことに注意を集中するようもとめていた。たったひとつのこと、それはバグである。

どのバグを処理するのか?

最悪のバグは「ショーストッパー」と呼ばれるようになった。ショーを止めるようなバグ、つまり、リリースを遅らせるしかなくなるバグである。次に重要なバグは、「プライオリティ1」と呼ばれた。NTのサンプル版にはファースト・クラスのバグが数百あった。もっと軽度のバグは「プライオリティ2」であり、数千にものぼることがあった。

しかし、どのバグがどこまで重要なのかが、いつもはっきりしているはけではない。もちろんNTがクラッシュするようなバグは取り除かなければならない。しかし、ショーストッパーとファースト・クラスのバグのほとんどは、ここまで悪質なものではなかった。
・・・
マーク・ルコフスキーがずばり真実をつく才能を活かして、こう語っている。「処理しているものは、問題なのだろうか。予定を遅らせているものは、問題なのだろうか。必死になっているものは、本当に問題なのだろうか



巨大なプロジェクトがどういうものであるかについての核心をカトラーは知っている

なにが悲惨な結果をもたらすのかは、だれにもわからない。だから、プログラマーは、ひとつの失敗で、すぐにではなくても、いつか、取り返しのつかない事態になりうると考えて、仕事に取り組まなければならない。ここまで厳しい態度を取っておくべきなのだ。バグとの戦いは凄惨だ。パフォーマンスの改善なら、遠くからの急所攻撃で一気にカタがつく。しかし、バグ取りはそうはいかない。言ってみれば、血まみれの接近戦に似ている。



欠陥があることは避けられない

NTのコードは560万行にもおよび、3500ページの大辞典よりもテキスト量が多いのだ。これだけのソフトが完璧になることはない。十分に良くなることがあるだけだ。



ダリル・ヘブンズは、チーム発足当時からのメンバーだが、フィアンセと別れることになったのはプロジェクトのためだと考えている。

しかし、苦痛に満ちた今回の経験で、自分の仕事量をもっと抑える必要があると痛感する必要になった。NTの完成に向けて無理を重ねた結果、チームの多くのメンバーが、疑問も持たずに長時間勤務をうけいれる純真さを失ったとヘブンズは見ている。


リーダシップがしっかりしていることは重要だが、それだけでプロジェクトが進むわけではない。チームワークが効率的なことも大切だ。

しかし、チームワークといっても、普通に考えられるようなものではない。普通、チームワークといえば、個々人のばらばらな言動を抑えることを意味する。こうしたチームはフットボール・チームや軍隊には適しているだろうが、想像力がもとめられる世界では、個々人は強烈な個性を持っている。通常のチームワークでは、グループの目標に向けて、全員が協力し、順応し、妥協することが不可欠であり、創造的な仕事とは真っ向から対立する。
・・・
実際、技術チームと文字を持たない種族とには、よく似た点が多い。今日では、技術の進歩はきわめて早く、印刷された情報はおどろくほどの短い時間に時代遅れになる。技術分野はきわめて細かくわかれているし、たえず変化しているため、技術の核心については、マニュアルもなければ、教科書もない。技術者は担当する分野に習熟し、知識を吸収するために、チームメイトに頼るしかない。
・・・
技術チームの多くは、チーム内の対立を奨励していても、官僚制度を生み出していく。決定を間違えるのを恐れて、重要な問題を検討する委員会をつくる。委員会には小委員会がつくられ、すぐに、単純明快な提案でも、実際の仕事にはたずさわっていない人たちが延々と検討を重ねるようになる。NTチームはこのワナには陥らなかった。
・・・
技術面での重要な決定のほとんどは、形式ばらない方法で下され、プログラマーが担当する部分について決定権を持つのが通常であった。チーム以外による検討は、ごくまれにあったにすぎない。

ブランド戦略【実践】講座2009/07/23 00:57

数ヶ月借りっぱなしで読んでいなかったブランド戦略の本をやっと読んだ。
最近流行の嵩高紙での本なので厚みのある割にページ数は少なくてあっさり読了。

事例でわかる! ブランド戦略【実践】講座 (単行本(ソフトカバー))
水野 与志朗 (著)
http://www.amazon.co.jp/gp/product/4534044623?ie=UTF8&linkCode=as2&tag=zakblog-22


以下、読書メモ。

【戦略1】
「競合他社が作り上げた市場に後から参入し、連続的な新製品の発売、大量の広告投資、強力なプロモーション・プッシュによって市場を席巻する戦略」

・先発ブランドに比べて2倍以上のマーケティング投資ができることが理想
・広告投資はGRP(グロス・レーティング・ポイント)で測定可能
・物量戦(カネがモノを言う戦略)
・下位の人を対象とした市場浸透戦略

例) Yahoo BB、ソフトバンクモバイル


【戦略2】
「戦略企業が作った市場はあえて無視する。そのようなカテゴリーはあたかも存在しないかのごとく振る舞う。その代わり、自分が一番手になれるカテゴリーを自ら作り出すことに専念する」

・初めて見るカテゴリーの最初のブランドになることが重要
・戦略1が独自のものと見なされるまで、お金と時間がかかることに対して、戦略2はすでに独自のもの見なされている前提でのマーケティング活動ができる
・ゲリラ戦
・安ければいい、というやっかいな顧客(傭兵タイプ)を避け、上位20%の人をターゲットとする、スキミング戦略

例)マクドナルドに対する、モスバーガー

【駆逐艦戦略】

・すでに優位にある先発企業が、戦略2による後発企業の挑戦を受けたときに取る戦略
・戦略2のブランドに対して中途半端なポジションにしてしまうような新カテゴリーを作ってプロモーションする。
・目的を達したら、役目を終えたものとして、そのカテゴリー自体を終熄させる

例)ペプシコのクリスタル・ペプシに対する、コカ・コーラ-のタブクリア(勝負がついたあと、タブクリアも終売した)


【ジレンマの領域】

・戦略2を取る後発企業が、先発企業からの戦略1、または駆逐艦戦略を防ぐための方法
・先発企業が戦略1、駆逐艦戦略でブランドコンセプトのマネをしようとしたときに、先発企業の既存のブランドイメージが傷ついてしまうようなコンセプトにしておく(マネできるが、したくない→ジレンマ)


【商品で差別化が困難ならば、HOWで差別化】

仕事のやり方を独自なものにして、戦略2を開始する。
WHAT(モノ)で差別化できなければ、HOW(やり方)で差別化

例) ユニクロ、マクドナルド、デル


【いかなる差別化ポイントも陳腐化する】

ブランド・コンセプトは、仮に競合にマネされなくても陳腐化する
陳腐化してもビジネスを続ける力(ユーザに選んでもらう力)が、すなわち「ブランド力」であり、ネーミング(商標)によって固定化される。

例) セブンイレブン、ネスカフェ


【広告は継続しなければやらなかったのと同じ】

お金がかかり続ける→効率を考えないと続けられない

・キャスティング(仕込み)
・生活導線に組み込む
・ブランドが売られるシーン、場所に気を遣う
・「製品」を広告として意識する
・「店舗」も広告として活用する
・テストマーケティング


【Webサイトを使った顧客開拓】

(ただ見せるだけのHP)
・イメージ重視・キレイな仕上がり
・一方的に書きたいことを書いている
・パンフレットの代用品(紙媒体で十分)

(顧客開拓をするHP)
・3秒で何の専門家なのか理解できる
・顧客の知りたいことが書いてある
・オファー(消費者が知りたくなるような提供物)
・3回メールやメールマガジンなどの顧客フォローのしくみがある



【ブランドステートメント】
統一的な共通認識を求めるために文書化し、様々なプロモーション活動においてブランド方針との矛盾を防ぎ、ブランド価値の破壊を防ぐ。
キレイ事としてではない一貫性へのごだわり
ブランドのフォーカスを失ってきたと感じたときに作り始めるのが適切(導入時から用意する必要は無い)

1.ブランドの定義(ポジショニング、ブランド・エッセンス=エバンジェリスト・ユーザにとっての主観的なイメージ)
2.ターゲット顧客の定義(コンシューマー・インサイト=消費者心理を推理)

3.ブランド・キャラクター(世界観)の定義
  コラージュ(雑誌などからの写真の切り貼り)を通じて言葉のみならず、ビジュアル的にも表現する。
  どのような世界観なのか(IS)を正確に理解するために、どのような世界観でないのか(似て非なるもの:ISN'T)もビジュアル的に表現する。

4.製品開発、広告戦略、営業活動、価格戦略など、日常オペレーションにおけるDO'S&DONT'S(やるべきこととやってはいけないこと)
  DON'Tは具体的な禁止事例を列挙(ブランドを傷つける理由も併記)、DO'Sにはブランディングの効率性を追求するノウハウを列挙
  書かれている内容が消されることはほとんどない
5.その他(ブランドの課題や特性による)

→最終的にはブランド・アイデンティティ・マニュアル(ブランド・ガイドブック)などに落とし込まれるが、それよりも、こちらのほうが重要(実際的で実務的な内容)

ジョブズはなぜ天才集団を作れたか (単行本)2009/03/01 18:30


ジョブズはなぜ天才集団を作れたか (単行本)

ジェフリー・L・クルークシャンク (著), 徳川 家広 (翻訳)

たぶん、技術にあまり明るくない、アップル信者が書いた本。

邦訳のタイトルに惹かれて読んでみたけれど、これは誤訳だろうと思う。素直に本来の題である、アップル・ウェイ、とすべきであっただろう。 そういう意味では期待はずれだった。

それでも、これまでのアップル社の紆余曲折、失敗と成功について、かいつまんで解説し、そこから教訓らしきものを抜き出したところについてはおもしろい内容だったと思う。ただ、これは、僕がアップル信者ではないからこそ、初めて知る内容が多くてそのように評価しただけで、アップル社に詳しい方に言わせれば結局は噴飯ものなのだろう(Amazonの書評にそんな感じのことが書いてあった)。


Google
WWW を検索 zak.asablo.jp を検索