Wiiのミニガイドブック（洋書）を軽く流し読み。”Everybody Votes Channel (みんなで投票チャンネル)”あたりまでをカバーしているものの、かなり浅めの内容。ポケットガイドだけあって技術的な話はほとんど無いが、末尾のリンク集は多少便利そうなので、メモしておく。
コカ・コーラ社の半分以上はブランドでできている。そのブランドの価値はおよそ700億ドル、約8兆円とか。普段、我々が空気のように接している「ブランド」というものには、なかなか侮れない価値があるようだ。
そんな、一般人には何だかよく分からないけれど、企業にとってはコンサルを雇ってでも世間に浸透させたい「ブランド」について語った本、”Brand Gap”を。
「ブランドとは何か？」から始まり、いかに企業がブランドを構築すべきかを、Differentiate、Collaborate、Innovate、Validate、Cultivateの五章に分けてざっくり説明。各項目は大体こんな感じ。
Differentiate: 差別化しろ。一番か二番を目指せ。さもなくばスコープを変えろ。顧客へのメッセージは、”what it is”から、”what it does”, “how you’ll feel”, “who you are”へと進化させろ。
Collaborate: 右脳屋と左脳屋を一緒に働かせろ。ハリウッドやシリコンバレー的な、プロジェクト単位で人を集める方法が良い（ブランドとは直接関係ないような）。あとプロトタイプは役に立つ。
Innovate: 革新こそビジネスの原動力。みんなと違う発想をしよう（うん。まあそうだろう。で、具体的にどうやって？）。いい名前をつけよう。動かないロゴはもう古い。これからは動くロゴだ。ウェブサイトはシンプルで簡単に使えるように。
Validate: 顧客からのフィードバックを手に入れろ。ロゴのデザインとかを色々入れ替えてみて、印象を確かめろ。定量的調査よりも定性的調査を。大規模に調査してもあんまり効果は上がらない。
Cultivate: 組織もブランドも生きている。みんなでブランドを育てていけ。大きくなってくるとトラブル時のダメージも大きくなるので気をつけろ。ブランドにはとても高度なマネージメントが必要なので、そのうちCBO (Chief Brand Officer) という役職が普及するだろう。
とまあ、マーケティング屋らしい与太話で締めくくられる。一般人向けらしく、ほとんど根拠も議論も無く突き進むが、とりあえずブランドについて分かったような気にさせてくれる本。読み物として読んでみる価値はあると思う。専門家にとっては何の役に立たないだろうけど。（★★★）
相変わらずバカ高いAddison Wesleyの”Refactoring Databases”を、何となく。
最近のソフトウェア開発は、短期間での仮リリース→改良の繰り返しによる、いわゆるRAD (Rapid Application Development)な手法がクールとされている。こうした「agileにあらずんばソフトウェア開発者にあらず」的な風潮の中、そしてデータベースが多くのソフトウェアにとって必要不可欠にも関わらず、データベースの（スキーマの）リファクタリングについては、あまり語られてこなかったように思う。この”Refactoring Databases”は、そんな”agile database”のための方法論にスポットを当てた、少しニッチだけど割と重要そうな本だ。
Refactoring Databases: Evolutionary Database Design
Martin Fowler John Graham Sachin Rekhi
Addison-Wesley Pub (Sd) 2006-03-06
主な想定読者は、それなりの規模のRADなプロジェクトで、複数アプリから使用されるデータベースを開発しているようなDB開発者。他のプロジェクトとの整合性を取るため移行期間を設け、その間は従来のコードもサポートできるような改良手法が紹介されている。ただ、やはりと言うか何と言うか、最も重要なのはregression testだそうで、頑張ってテストを作っておいてDB変更前・変更後でパスするように保つ（小さな改良毎に行うのを推奨）、というのがこの本の方法論のポイントみたいだ。また、後半は”Drop Column”からStored proceduresまで、DBのリファクタでありそうな改変項目を具体的に挙げ、どんなときにその変更をすべきか、ありうるリスクやスキーマの変え方、(DBの)クライアント・コードのサンプルを示してくれている。
何かと真面目に書かれた本であり、中身もいちいちもっともで、RADとDBを一通り学んだ人なら良くも悪くもサプライズは少ないだろう。前半の方法論にはざっと目を通して、後半のリファレンスは必要に応じて参照する、というのが正しい使い方だと思う。ただ、リファレンスの各項目についている”Motivation”欄は、どのようなときにそのリファクタをすべきか書いてあるので、あらかじめDB設計前に読んでおけば逆にリファクタ回数を減らせるかも知れない。”agile database administrator”を目指すなら、持っておいてまあ損は無いかなあ、という程度には良書。（★★★★）
You are currently browsing the archives for the 技術書 category.
