Webが実現する顧客志向のマーケティング

by tanabe on May 31, 2005

今回は、既知の現象をまとめてみるだけ。わかっている人には今更の話。わからない人にはここ見せればいいかも、っていう話。ただ、The Long Tailを考える場合にも重要な前提となっている話だと思う。

Webが実現する顧客志向のマーケティング

Webは顧客志向のマーケティングを実現する強力なツールだ。企業はWebを活用したマーケティングを積極的に推進するべきだ。

  • 現代は顧客経済の時代であり、顧客創造こそが最重要課題となっている
  • 顧客を創造するためには、製品主導主義から顧客中心主義へとシフトしなければならない
  • 顧客志向の知覚−反応マーケティングのツールとして、Webは非常に優れている

顧客経済の時代

 現代のマーケティング上の重要課題は、顧客創造だ。市場に製品はあふれており、顧客はその中から好きな製品を選んで使う。このような中で企業が意識をしなければいけないのは、「何を作るか」ではない。また、「製品を必要としている顧客はどの層なのか」でもない。そういった売らんかな主義、いかに売るかの発想から脱却をする必要がある。

 一人一人の顧客が何に関心を持っているのか、何を望んでいるのか、を考えなければならない。彼が(彼女が)価値を感じるのはどういったサービスなのか。対価を払ってでも得たいと望むのはいったいどんなことなのか。そして、”顧客”という総体としてはそれらがどういったバランスになるのか。これが最も大切な視点になっているのだ。

 この視点を欠くと、そもそも顧客のいない所へ向かって”素晴らしい製品”を大々的に売り出すということになってしまう。不足しているのは製品ではない。顧客なのだ。

製品から顧客への意識転換

 顧客経済の時代という視点を持つと、必然的に製品主導の仕組みから顧客主導の仕組みへという根本からの変化を受け入れることになる。

 製品を作り、顧客のセグメントを分析し、最も勝機のあるところを狙い撃つという製品主導型のマーケティングは必要ないということではない。ただ、この方法論は「狙いさえ外さなければ、そこに顧客はいるはずだ」という前提に基づいている。そのセグメントがすでにライバルによって刈り取られていた場合には所期の効果は期待できないだろう。

 そこで発想の転換が必要となってくる。まず顧客を知るのだ。顧客を知り、その望むものを提供する。このプロセスを「コトラーのマーケティングコンセプト」から引用してみよう。

 ほとんどの企業が顧客中心主義というよりも、製品主導主義の立場に立っている。その思考プロセスを図示すると次のようになる。

 資産 → 投入(インプット) → 提供物 → チャネル → 顧客

 こうした企業は製品主導型で資産に莫大な投資を行っているため、想定しうるあらゆる顧客に提供物を押しつけようとする。個々の顧客の違いや価値には注意が行き渡らない。個々の顧客をよく知らないためにに、クロス・セリング(抱き合わせ販売)やアップ・セリング(高値販売)もうまくいかない。どちらも、顧客1人ひとりについての取引情報等を集めるとともに、彼らがほかに興味を持ちそうなものを推測する必要があるからだ。顧客志向の企業は、上とは異なるアプローチをとっている。それは、知覚−反応マーケティングと呼ばれるもので、以下のようなプロセスをたどる。

 顧客 → チャネル → 提供物 → 投入(インプット) → 資産

 顧客を理解することから始めれば、チャネル、提供物、投入、資産をより適切なかたちで展開できるようになる。

 顧客志向とは、目の前のお客様へ親切ごかしにサービスを押し売りすることではない。企業としての大いなるパラダイムシフトなのだ。

顧客志向マーケティングツールとしてのWeb

 そして、この顧客志向のマーケティング、知覚−反応マーケティングを実現する手段としてWebは非常に有効だ。ただし、当然テクノロジーは万能ではない。メリット・デメリットを理解し、それを生かしきることが必要だ。

 まず、Webの末端は一人一人の顧客と直接つながっている。これは非常に大きなメリットだ。直接の販売店でしか知りえなかったような生の顧客の様子というのを逐一知ることができる。

 そして、Webは顧客のすべてのアクションを記録することができる。Webサイトのどこのページでどれを何回クリックしたのか。入力した文字は何なのか。さらにそのページから移動したのはどこのページか。これらは客観性の高い事実であり、時には顧客自身よりも顧客の求めるものを描き出すだろう。企業はあらゆる入力の意味を考える必要がある。顧客が起こしたすべてのアクションの意味を考え、そこから導かれる顧客の意図を読み取るような分析が必要だ。全体の中での割合、回数、そして訪問されてからの流れといったものを徹底的に分析し、顧客の考えるところを知らなければならない。

 最後に、Webは顧客からその望むもの以外の余分な属性を排除するという特長もある。職業や年齢、性別といった属人的な情報はわからない。ただ、そのヒトは何を求め、どのように振舞ったのか、それだけが記録として残る。より本質的な「何が一番の関心なのか」に焦点を絞った分析ができるというわけだ。

 一方で、その特性ゆえの弱点もあるだろう。

 まずは経年的に解消されると思われることだが、当面の問題としては顧客層に年齢による偏りがあるという点が挙げられる。特に今後の重要顧客になり得る高年齢層に弱いというのは、よく考慮すべきだ。Webマーケティングを生かすと共に、この弱点を逆手にとったマーケティングを平行させるべき、とも言える。

 そして、先ほどはメリットとして挙げた「属性の排除」が弱点にもなりえる。例えば、顧客の生み出す利益とWebで得られる動向との相関が分かりにくいなどの点だ。こういった理由で戦略的な打ち手に困るという可能性はある。ただ、その場合はそれを補完する別のデータを収集するべきだろう。

 ここまでで述べたWebによるマーケティングは何もWebによる販売を行っている企業だけに関わる話ではない。メーカーでもたいてい製品情報くらいはWebで公開しているだろう。このアクセスを記録し、マーケティングへ生かしているだろうか?時間軸での変化や、商品別、商品のカテゴリ別などの違いを見ることで十二分に新しい可能性を探れるはずである。SEOだけがWebを使ったマーケティングではない。

オマケで、モノツクリな国の人たちへ

 今のところ、Webのこうした利点を積極的に生かしているのは、GoogleやAmazonといったいわゆる”インターネット企業”だ。これらの企業はWeb上のデータの見方、扱い方に長け、その価値をよく知っている。

 彼らが得意としているのは、テクノロジーであり、顧客のインプットをどういう意図として読み取るかという読み取り方だ。テクノロジーでGoogleに追いつくのは容易いことではないだろう。しかし、顧客志向のマーケティングの分野でも彼らに遅れをとる必要はない。まずは手持ちのインプットと目の前の顧客を相手に、その望むことを理解してみよう。

 Webは非常に強力なツールだが、一方でけっきょく消費者にお金を払わせやすい土俵というのは物理的なモノ・サービスであるのも現在の状況だ。人を接点として提供されるものと言い換えてもいいかも知れない。Googleが莫大な利益をあげている広告も、末端にはモノ・サービスを売りたい企業がいてこそ成り立っている。

 モノツクリ国家、モノツクリ企業と卑下することはない。顧客から始まる製品をつくって、GoogleやAmazonを養ってやろうくらいの気概で良いのではないか?そのためには、必要な武器、そして先駆者について大いに学ぶべきだと思う。

後記

Webの最大の利点はそのスケールメリットであり、”製造した分だけ”しか販売できない製造業には物理的な限界が弱点となって、本質的な”インターネット企業”には勝てない、というのは正論だと思うけど、実際に企業が作り出す必要がある利益は必ずしもGoogleクラスだけではないので、ここではこういう話として受け取っておいてほしい。

日本における「こちら側」「あちら側」観て、こういう手がかりになりそうなステップを踏んだ方がシフトして行きやすいと思うので。もちろん「あちら側」をばりばりと駆使して、スケールの大きな仕事を成し遂げる企業が出てくるのが一番の楽しみではあるんだけど。

  

[Ruby] プログラムはどう始める?

by tanabe on May 28, 2005

気になっていたことについて、まつもとさんの解釈を発見したのでメモ。

オブジェクト指向でプログラミングをしていて、どうにも気持ちの悪いのがプロ グラムをスタートするときなんだけど、その辺りに関するRubyとしての解釈が Ruby-talkの過去ログにあった。

http://www.ruby-talk.org/cgi-bin/scat.rb/ruby/ruby-list/8970

川村氏の問題提起から。

おっしゃる通りです。トップレベルの文は誰が呼びだすのか、ということが気 になったわけです。

既存のOSの上で走る言語処理系は、オブジェクト指向じゃない外の世界との界 面を持たざるを得ない、それをどんな風に設計するべきかということですよね。

たとえばEiffelは、その界面を極力減らそうとしていると思います。プログラ ムのスタートにあたって、外部がやることは、ある特定のオブジェクト(神に相当?) を生成することだけで、後はそのオブジェクトのコンストラクタが世界を創り出すと いう考え方ですから。

ここから、まつもと氏の見解。

http://www.ruby-talk.org/cgi-bin/scat.rb/ruby/ruby-list/8965

まず前提。

プログラムの実行が制御の流れの開始点であると考えるとCのmain関数とかJava のmainメソッドとかいろいろあるわけですが,Rubyの場合はトップレベルの文がそれ を担っています.

これは確かになにかのメソッドではないのでオブジェクト指向的ではありませ ん.トップレベルではselfがmainに設定されているので,全体がmainのメソッドであ るという解釈は不可能ではないですが,私自身はそうは考えていませんし,そのよう な解釈をお勧めするわけではありません.

で、そのような言語仕様となっている理由はというと、『プログラムの開始は本 質的に手続き的なものだから。』というもの。

というのも,プログラムの実行の開始というのはどう考えても「制御の流れ」 であり,本質的に手続き的だと思うからです.EiffelやJavaのようになんらかのオブ ジェクトのメソッドとしてしか処理を記述できない文法の言語ならともかく,Rubyの ような言語でこのような部分までなんらかのオブジェクトのメソッドにする(あるい はそう解釈する)必要はない,あるいは本質的にメソッドでない以上メソッドにする のは適材適所の観点からも不自然であると考えます.

Javaなんかも含めて、もやもやしていた部分だったけど、これを読んで「そうい う理解の仕方なのか。なるほどなぁ。」と。これが一番美しいかというのは置いてお いて、一つ背景の理屈がわかってまずは納得。

  

[Ruby] 複数の戻り値を返す(風

by tanabe on May 28, 2005

Rubyメモ。

引用元はFAQ

5.14 メソッドから複数の戻り値を返すことはできますか

Rubyでは,メソッドの戻り値は一つしか指定できませんが,配列を使うことに よって,複数の戻り値を返すことができます.

return 1, 2, 3

とすると配列が返されます.つまり,

return [1, 2, 3]

とするのと同じです.

さらに多重代入を利用すると,複数の戻り値を戻すのとほとんど同じことができ ます.たとえば,

def foo
return 20, 4, 17
end

a, b, c = foo
print "a:", a, "\n" # -> a:20
print "b:", b, "\n" # -> b:4
print "c:", c, "\n" # -> c:17

こんなことができるわけです.

  

プログラムをどう分割するか

by tanabe on May 25, 2005

それゆけ西表島」さんの「プログラムを分割することと図形に補助線を入れることはなんとなく似ている(気がする)」で思ったこと。

プログラムをどう分割するかは経験則だ、と言ってしまうとそれ以上先には進まない。数学の図形の補助線は、ある程度までなら学習を繰り返すことで、補助線の書き方もパターン化できる。プログラムの分割についても同じことが言えるのではないだろうか。

初歩的なところで、やっぱり繰り返しの排除はしてほしい。トップダウンでプログラムを書いて、繰り返し同じ処理をしているところは機械的に関数にまとめてみる。で、どうも似たような処理なんだけど、上手に関数にすることができないようなのを、グローバル変数でなくて引数使って解決するように試行錯誤してみる。

一方で、関数にまとめる意味を考えるようにする。ただ同じ処理だからというだけでなくて、それらを一つにまとめるのがどんな意味を持つのかを考える。まとめた方がいいのか、まとめない方が後々都合がいいのか考える。

自分がそうやって一歩ずつ進んできたんで、この結論をプログラムを分割できない初心者が理解できるのか疑問に思った。

どういう固まりが他のどの固まりと繋がっているか、その固まりはもっと小さな固まりにしたほうがよいのかどうか。ポイントはいくつかあるが、要はプログラムを眺めた時に固まりを意識できるかどうかである。

こう言われても、最初にどうやって固まりを理解すればいいのかわかるのかなぁ。

いや、文句があるわけではなくて、文章自体が言いたいことは分かるんですけどね。

分割統治、分割統治とお題目のように言われて、分割することだけを意識していると、いつまでたってもプログラムを分割できない。分割ありきではなくて、固まりありきなのだ。

分割できない人が本意を理解してくれるのかどうか、ちょっと心配だっただけなんです。大きなお世話と言われれば、まったくもってその通りなんですが。

  

Webの課金モデルとLong Tail

by tanabe on May 23, 2005

このblogのエントリ「Web コンテンツのストリーム化と独立、そしてデータの綱引き 」にisiさんからコメントを頂き、回答をした。

ちょうど普段気にかかっていた話に関係するので、新エントリ扱いでも出してお く。(コメントだとRSS Reader経由の人の目に留まらないんで)

isiさんから頂いたコメントはこちら。

「コンテンツや情報、データ」を利益に還元する方法は、広告以外でありえるのかが 問題のようにも思います。
AdSense代替広告なんかに象徴される物販を伴うリアルな売買とその広告以外でwebは 利益を生む方法はないのですかね。

で、回答したのがこちら。

>広告以外でありえるのかが問題

そうですね。私もそう思います。

インターネットビジネスの難しいところとして、 情報の流通にかかるコストが限りなく安いという点があると思います。 流通コストが0に近いので、物理的な最低ラインのコストというのが ほとんど発生せず、競争の中でだんだんと無料化という方向へ行ってしまう。

そのせいで情報自体で課金するというモデルへ持っていけないんですよね。 本質的に価値を持つものに課金できないからパトロンを探す、 という流れで広告型になっていると思います。

なので、原点に帰って課金できるような競争力の強い情報を持つか、 パトロンの違う形を模索するか、この辺りが現状でパッと思いつく 工夫ですかね。

で、これを飛び越えるイノベーションの種に成り得るのが、The Long Tail なんじゃないかな、と私は捉えています。

たいして、解答になりそうなことはないのだけど、まぁ、考えるきっかけという か枠組みというか、自分のためのメモとして。

isiさん、面白いご指摘ありがとうございました。

  

難儀な性格

by tanabe on May 22, 2005

blog.nomadscafe.jp」さんの「プログラム「で」作っているんだ」から。

プログラム「を」作っているのではなくて、プログラム「で」つくっている。自分としてはそんなつもりでコミュニティの構築・運用をやってます。プログラムは、自分のアイディアの表現方法の一つであって、目的ではないし、プログラムのためのプログラムは性に合わない。

たしかにその通りだと思う。これが正論。

それはわかっている一方で、こんな話も気持ちがすごくわかってうなずいてしまう。

Matzにっき」さんにあった情報共有CMSの話

あと、個人的な情報管理としてHowmを導入した。前から気になってたけど、ちょっと敷居が高くて。しかし、いざ使って見るとこれは便利だ。

Howmで記録して、(認証用のパッチを当てた)hiki-modeでWikiに転記、いつもEmacsの中で快適。

いやあ、こういう環境整備の仕事は燃えるねえ。完全に手段と目的をはき違えるタイプ。手段のためには目的を選ばないっていうか、なんていうか。

実際、手段だったはずのものが大好きで仕方ない場合はどうにもならない。好きなもん好きなんで仕方ないんだと思う。「人生を楽しむことこそが最大の目的なんだ」っていう詭弁。

はき違えていることを自覚できていれば、大きく困ることにはならないしね。(あと、時と場合を選ぶことも大事)

  

断酒

by tanabe on May 22, 2005

えらい失敗やらかしました。カバンを紛失。デジカメやらMD WALKMANやら財布やらクレジットカードやら銀行のカードやらを全部まとめて紛失。持ち歩いていた本三冊も紛失。なんやかんやで総額10万相当の物が消えました…

ZAZENのライブチケも入ってたのに。現金はいいから物だけでも返ってきてくれー(切実)

反省と二度とやらかさないために、断酒します。はー。

  

Web コンテンツのストリーム化と独立、そしてデータの綱引き

by tanabe on May 20, 2005

My Life Between Silicon Valley and Japanの「RSSとページビュー」 や Wired News の「サイトの体裁を変えるFirefox拡張機能『グリースモンキー』」なんかを読んで、Web の姿が変わってきているよなぁと改めて感じた。

「HTMLで構造を、CSSで見た目を。」というのは常套句だが、この見た目とコンテンツの分離というか、コンテンツの見た目からの独立はますます加速しているような気がする。

Web コンテンツはストリーム化している

AMAZONやdel.icio.us、あるいは日本のはてなのようにAPI を公開し、コンテンツを外部から利用できる仕組みを提供するような流れも大分浸透してきており、それがまたコンテンツが単独で存在することを後押ししている。RSS feed なんかも加速を後押しする技術の一つといっていい。

そして、かつてはページ単位でいわゆる「ホームページ」文化だったWeb が、「コンテンツのストリーム」という捉えられ方へ移っているのを感じる。

『特定のホームページへ自分で情報を取りに行く』というスタイルから、『自分の前を流れ続けるコンテンツから、必要な情報だけをピックアップする』というスタイルへ変化しているのを感じるのだ。

これによって、自分で情報を管理するというよりも、ただ自分の所へ流れ込む情報の中から”必要なものだけを見えるようにする”という工夫が重視されてきているのだ。プッシュ型とプル型の違いと言っても良いかもしれない。

ストリーム化したコンテンツの世界では、「その情報が誰からのものか」はあまり意識されない。誰から発せられて誰に所属するのかというのにはあまり意味がなく、情報自体の価値の方が重視され、最初の情報の発信者の手を離れて情報自体が動き出す。

まだ、このことが持つ力や効果ははっきりとしていないけど、もう少しこの流れが強まるであろう2〜3年後のWeb の姿、あり方というのは今とは大きく変化していると思うのだ。

コンテンツは独立していく

最初の話に戻り、「見た目とコンテンツの分離」から「コンテンツの独立」へのシフトについての話をしよう。「サイトの体裁を変えるFirefox拡張機能『グリースモンキー』」から引用しながら話を進めることにする。

見た目とコンテンツの分離というのは、そもそもはシステムの作り方・設計の仕方としてユーザーインタフェースと実際の動作を制御する部分は分けて管理しましょうという発想から出ていると思う。これは主に作り手・発信者側の問題であった。

ただ、今はそれがもう少し違った視点として、コンテンツは誰のものなのか?見た目は誰のものなのか?という受け手側も巻き込んだ動きになってきているように感じる。

グリースモンキーは、サイトのデザインや使い方の REMIX を可能にする。見た目や使い方という部分は受け手のものだという考え方だ。

『Firefox』(ファイアーフォックス)の一部のユーザーたちが、改造したブラウザーを使って、好き放題にウェブサイトに手を加えている。

 こうしたユーザーは、『Gメール』(Gmail)に削除ボタンや常時検索フォルダを追加したり、ブラウザーがオンライン版ニュース記事の印刷ページだけを表示するようにしたり、人気のある音楽サイトのコンテンツを丸ごと再構成したり、オンライン・ニュースリーダー『ブログラインズ』からロイター通信が報道するマイケル・ジャクソンの記事を取り除いたりしている。

 こうした変更は、Firefoxの拡張機能『グリースモンキー』によって可能になった。グリースモンキーを組み込んでカスタム・スクリプトをロードすると、特定のウェブサイトを訪問するたびに、ページの体裁を変更して表示できる。

一番価値を持っているのは”情報そのもの”としてのコンテンツであり、その一番価値があるものを一番使いやすい形で利用すれば、さらに好都合なんじゃない?ってのがこの考え方だ。

同じ家具を使うとしても、配置や使い方は人それぞれだ。やっぱり自分が使いやすいように扱うのが快適なんだろう。それが家具と同様に”日用品”となった Web の情報にも求められることなんだと思う。

だから、私はこのグリースモンキーが流行るかどうかはともかくとして、このようなコンテンツを独立して扱い、より使いやすいようにするというスタイルは今後どんどん発展していくだろうなぁと感じている。

データの綱引きの勝者は?

そして、この流れの中で「データは誰のものか」というのが一番の焦点になっている。

背景には、「Web上へユーザーのデータを移すこと」が進行する中で、「ユーザーの囲い込み」と「何が誰のためのものか」という考え方がせめぎ合っているというのがある。

梅田望夫氏がかつてCNET JapanのBlogで「「こちら側」から「あちら側」への情報シフトが始まる」と指摘したように、実際にこの一年でかなりの情報シフトが進んだと思う。(特に新し物好きの人たちの間で。)

そして、そのサービスを提供している者には、いかにユーザーを囲い込み、自分たちがプロプライエタリな存在になるかという重要なテーマがあった。Web の世界ではユーザー数がそのまま競争力につながることもあり、なんとかユーザーを集めたいという思惑があったはずだ。

しかし残念ながらこの考え方は、オープンにしてこそその本来の強力さが発揮されるWeb という環境や、その先進的なユーザーたちにはあまり馴染んでこなかった。

ユーザーにしてみれば、サービスを通して入力したデータに関しては自分のデータ、という意識が強い。Webのアプリケーションが高度化し、よりユーザーにとって日用的で重要なデータがWebへ移るにつれて、その意識はますます強くなっている。

ユーザーとサービス提供者が互いに互いを必要としている中で、「何がどこまで誰のものか」についての綱引きを互いにしているのが現在の状況だろう。

あまり上手に言いたいことがまとまっていないが、こういった中でコンテンツや情報、データと呼ぶような本質的な競争力を持っているものが誰の手中に収まるのかというのは、非常に興味深い問題なのだ。

  

ボーランドMyPageメンバー登録で、SEShop.com 10% off

by tanabe on May 18, 2005

無料のメンバー登録をするだけで、SEShop.comでの買い物が10%OFFになるらしい。

https://mypage.borland.co.jp/mypage/

MyPageメンバーご登録いただきますと、翔泳社 SEShop.comの優待割引をご利用いただけます。

高価なIT専門書の購入はためらってしまうものですが・・・
MyPageメンバーの方は、翔泳社SEShop.comで全書籍を10%引きでご購入いただける大変お得な特典です。

※翔泳社SEShop.comの優待販売サイトへログオンするには、必ずMyPageへログインの上、左サイドバーのSEShop.comバナーをクリックしてください。

  

WWW2005の"Web services considered harmful?"・その2

by tanabe on May 17, 2005

先日も取り上げたWWW2005のレポートだが、さらに濃いレポートが上がってきていたのでご紹介。

Adam Bosworthの「Queries vs Methods」に関する解説があった。

まず、Methods についての言及。

彼のMethodsという言葉に代表されるのは、Strict Syntaxということなんだろうと。

Methodsというのは、パラメータの順序やその明確な意味の事前合意を求めるモノの総称ということなんだろう。

そしてもう一方のキーワード、Sloppy。

そして、重要なポイントはSloppyという言葉だとも思う。彼のいうSloppyなモノとは、要するに無邪気なまでにデータの読み手に解釈をゆだねる姿勢のことなんだと思う。パネルでもあげていたInternet Explorer(彼はv4チームのリードだった)の例:「なんとなくレンダリングできそうなデータが来たら、レンダリングするという方針。Webブラウジングしていて、『このページは読めません!文法が間違っています!』っていうエラー見たことないでしょ?」MethodsはこのSloppyを許さないモノを象徴する言葉だったのだろう。

Sloppyについては、どこかで見たなと思って探してみた。ということで、Adamの息子、Alex Bosworthのblogから。

Nevertheless, Google engineers of all people should realize that the web is sloppy and that arbitrarily prefetching things within web applications might be dangerous.

from "Google's new web accelerator breaks webapps"

先日、サービスの一時停止のアナウンスもあった、GoogleのWeb Acceleratorに関する37signalsの指摘の話に始まり、webはsloppyなんだから気をつけなきゃいけない、という内容だ。

'the web is sloppy'に貼られるリンクから跳ぶと、Adam Bosworth's Weblogの'TENSIONS ON THE WEB'が参照されている。

そして、もう一つレポートをご紹介。

こちらは図表がきれいにまとまっていて見やすい。行けなくてもこれだけの情報が手に入るとは、便利な世の中になったものだ。公開してくれている人たちに感謝。

  

WWW2005の"Web services considered harmful?"に関するレポートメモ

by tanabe on May 15, 2005

幕張メッセで開催されていたWWW2005の"Web services considered harmful?"に関するレポートメモ。

Adam Bosworthが来日していたなんて。一応、Keynoteの面子くらいはチェックしていたんだけど、どうせ仕事で行けないだろうとパラパラしか確認しなかったのは失敗だった。

Web Services Considered Harmful? from "yohei-y:weblog"さん(あれ、傭兵日記さんからタイトルが変わってる。)

Webサービスの死は日を数えて待つべし from "村田 真のチャンネル"さん

Web Services Considered Harmful? Apparently, but apparently not. from "何はなくとも XML InfoSet"さん

Web Service After Five Years (Panel Discussion Proposal) (pdf)

  

[Ruby] Ruby on Rails を手動でインストールするには。

by tanabe on May 14, 2005

企業や学校などでRailsをインストールする場合、ProxyやGroup Policyなどの環境に依存し、RubyGemsによる自動のリモートインストールが失敗することがある。

このような場合もローカルへRailsの依存ファイルをダウンロードし、RubyGemsのlocalオプションを使うことでRailsをインストールすることができる。

手順は下記のとおり。

  1. rake のインストール
  2. Rails の依存ファイル群をダウンロード

    ページ左側のTGZ/Zip releases から'.gem'ファイルをダウンロードする。

    Rails
    Active Record
    Action Pack
    Action Mailer
    Active Support
    Action Web Service
  3. RubyGemsを使い、下記の順にインストール

    gem install activesupport --local
    gem install actionpack --local
    gem install activerecord --local
    gem install actionwebservice --local
    gem install actionmailer --local
    gem install rails --local

 

  

Ruby on Rails を紹介してみる。

by tanabe on May 12, 2005

Ruby on Railsの普及も本格化してきているように感じる。perlやpythonでも同じようなMVCフレームワークが開発されていたりするし、Tim O'ReillyのRadarにも引っかかっていた。どうも一過性のブームでは終わりそうにない。

そこで、日本でのより一層の普及を願って、あまりに有名なONLamp.comのRuby on Railsチュートリアルを日本語でパパッと再現してみる。なるべく本家の流れを大切にして進行するつもりだが、けして完訳とか全訳とかいう大層なものではない。本家を読んだ方にはあまり新しい発見はないはず。

ただ、まるっきり本家をトレースするのも日本語版の意味がないので、日本用のローカライズは多少するつもり。自分がやっていたときのちょっとしたこととか。

ということで、Curt Hibbs&ONLamp.comから快い回答を頂いたので、ぼちぼちと翻訳していきます。

更新が遅れてたら、この作業をしていると思います。(と、先に逃げ道を作っておく)

  

その開発費用は誰が負担すべきなのか?

by tanabe on May 11, 2005

なんだか今日は示唆に富む話が多いな。

次は羽生章洋さんの「コスト x 投資」から。

結局、それが納品する「商品」を作り出すためにかかっているのであれば、本来は開発元における投資であるはずなのです。

そうなんだよ。この根本がずれているから事態が”人月の神話”と化すわけだ。

なのに受託ということを利用して、お客様サイドにそれをコストとして転嫁してしまってるから、リスクテイクしている(=投資している)のはお客様側だけになってしまい、Win-Winになりようがないのです。

じゃあ、どうするか。これしばらくの間、自分の中でテーマにしよう。

  

コードに転嫁できるドキュメントはただのムダ

by tanabe on May 11, 2005

よしおかさんの「無駄なドキュメントは書くな」から。

ひたすら実装に関するドキュメントをしこしこ書いている人がいるが、好きで書いているわけではなく、書かされているのかもしれないけれど、そーゆー無駄なドキュメントは書くな。時間の無駄である。実装は日々変化する。それに追従する形でドキュメントが更新されるということはない。

まつもとさんも「オブジェクト指向スクリプト言語 Ruby」で「ソースがドキュメントだ。 バグも完全に記述されている」と言っている。

このドキュメントこそが成果物という悪習はウォーターフォール型の開発手法による部分は非常に大きい。なんせ要件定義やら設計やらのPhaseを終わらせようと思ったら、そのPhaseごとの成果物を納品する必要があるのだ。そりゃ、メンテも放置され、コードとの乖離は進む一方になる。しかも、たいていプロジェクトが後々きつくなるのは分かっているから、早いPhaseをなるべくさっさと終わらせたくてドキュメント自体の質も悪くなる。

なんでこんな状況が放置されているかについては、業務アプリケーション業界のストラテジスト不在という構造的な欠陥があったりすると思っているのだけど、この話は別でエントリをするつもり。

で、書きたかったことがコメント欄に指摘されていたので引用しておく。

「なぜそのコードになったのか」を説明するべきなのに、コードが何をしているのかの説明をするから、すぐ Out of date になるのだろう、と。

よいドキュメントを書く人は、全く違った視点から同じアルゴリズムを2度見つめます。ドキュメントとコードの2度、構造の理由を説明した版と実装を説明した版の2度です。で、ドキュメントを先にします。だから「良いコード」になります。もちろん、その後でコードにあわせてドキュメントを直します。ver1.0よりver2.0の方が良いに決まってますから。

下手なドキュメントを書く人は、先にコードを書きます。ver1.0です。で、それにあわせてドキュメントを書くので、ドキュメントもver1.0です。当然バギーです。すぐ変更がかかります。ドキュメントはver1.0のままで、役立たずです。

ドキュメントとコードのどちらを先に起こすべきかについては、ちょっと異論があったりするのだけど、大事な部分は全面的に賛成。

ドキュメントは実装の詳細ではなくて、なぜそのコードをそういった形で書いているのかという設計の思想を語るものであるべきだ。業務アプリケーションであれば、どのように顧客の業務を理解し、設計へと落としたのかというものだ。何をプログラムを起こすときのルールとしているのかと言っても良い。

コードはそのルールに沿って書かれる。保守の段階で、設計時の思想を理解できない人がコードを読むことは往々にしてある。そのときに的外れな変更をしないためには、そのプログラムの根底に流れるルールを理解している必要がある。

ちなみに、「コードがドキュメント」を口先だけでなく実践している人は、たいていこの「構造の理由」についてもヘッダ辺りに必要最小限のコメントがあるので、この問題もクリアされるような気はする。

そして、口先だけで「コードがドキュメント」を言い放つ人は、「コードくらいしかドキュメントと呼べるものがない」だけだったりするのは周知の事実。

念のためだが、このよしおかさんの話は「ひたすら実装に関するドキュメントをしこしこ書いている」ことが問題であって、なんでもかんでもドキュメントは書くな、コードを見ろって言っているわけではないと思う。あくまで、タイトルのとおり「無駄なドキュメントは書くな」なのだ。

  

ユーティリティ・コンピューティングに必要なもの

by tanabe on May 10, 2005

CNET Japanの「「IT Doesn't Matter」の編集者、今度は「企業コンピューティングの終焉」を予言」を読んだ。

「情報技術は、企業が所有する資産(コンピュータやソフトウエア、関連する無数のコンポーネントなど)から、ユーティリティプロバイダから購入するサービスに変わろうとしており、この流れは変えられない。社内の資産であったITが社外から購入するユーティリティサービスに変われば、戦略上/オペレーション上の前提が覆り、業界の経済構造が変化し、市場が混乱し、あらゆるユーザーやベンダーが大きな課題を突きつけられることになる」(Carr)

多くのIT企業がユーティリティコンピューティングの考えを受け入れつつあるが、特にSun Microsystemsでは、自社のコンピュータグリッドの計算処理能力を貸し出しており、将来は主に最終需要者にサービスを販売するビジネスパートナー向けに基盤となるインフラを提供したいとしている。

ということで、これに関して面白い記事が米CNET NEWS.COMにあったのでご紹介。

上記を見るとSub Microsystemsにとっては、Nicholas Carrの"The End of Corporate Computing"は都合のよい話に思えるが、Jonathan Schwartz が注意を投げかけているようだ、という話。

"Nick missed (as I pointed out to him when I reviewed an early draft) the one fundamental point, that the concept of utility is predicated upon common platform multi-tenancy," Schwartz told CNET News.com.

ユーティリティ・コンピューティングを実現するためにはベースとなる標準化された環境が必要となる。その目指す環境とは、Jonathan Schwartzの言葉を借りるとこのような状態だ。

It was the third stage--utilization, in which electricity was viewed as a commodity with a transparent price and reliable service quality--that really brought the benefits of electricity to the world. As electricity moved from customized to standardized to utilized, two things happened: Its ubiquity rose, and its cost plummeted. All manner of things driven by electricity, in addition to lights and industrial motors, were created, bringing real value to everyday people.

電気が長年かけて普及をし、適正な価格で安定したサービスを供給できるようになったように、ユーティリティ・コンピューティングにおいてもより一層の基盤となるIT環境の発展と普及が必要だというのがSchwartzの指摘だ。

CNET NEWS.COMのコラムに戻って、

In other words, utility computing services require standardization, something that doesn't exist widely right now. Custom business applications that run in-house are configured for very specific hardware and software combinations. For utility computing to take off, business applications will need to be designed and tested to run on a standardized grid, he says.

"He's just continuing to (try to) be inflammatory--it's not the end of corporate computing, it's the rise of network services, one of which happens to be corporate computing," Schwartz concludes.

現在のビジネスアプリケーションはハード、ソフトの両面において特定の環境に絞って運用が想定されており、ユーティリティ・コンピューティングの実現にはこういった特定環境を想定したアプリケーションがもっと標準的でどんな状況でも動くものとなってこないといけないと主張している。

気になる点は、けっきょくここでいうユーティリティ・コンピューティング像だと、Sun Microsystemsでなくてはならない何かというのはないので、基盤が整い競合する企業が出てきた際にはコモディティの中での競争へと進んでいくのではないかということ。

それから、本当に「社内の資産であったITが社外から購入するユーティリティサービスに変われば、」「あらゆるユーザーやベンダーが大きな課題を突きつけられる」のであれば、そこには何か効果を生む変化があるのだろうけど、それが今ひとつまだ見えていないこと。ITには"効果を生むIT"と"効率を生むIT"があると思っているのだけど、現時点では効率を生むための仕組みとしての理解しかできていない。"The End of Corporate Computing"にその辺りのヒントが隠されているのであれば、興味深い。

  

taggingの将来性についてもう少し考えてみる。

by tanabe on May 09, 2005

能動的なフォークソノミーと受動的なフィルター

フォークソノミーだなんだと色々言われているソーシャルブックマークだけど、今のところtaggingによるフォークソノミーということよりも、フィルターとしての機能が非常に優れているな〜と感じる。

はてなブックマークの「注目のエントリー」も、「はてなユーザーの皆様」というフィルターをかけて得られる人気情報ということと、○Usersから跳んで見られるブックマークしている人の感想・要約などのコメントが面白いという点が買いなわけだ。(今のところ)

てことは、ブックマークする行為でWeb側が得られる「ブックマークをされたページです」という情報自体がやっぱり価値を帯びているということ。そう考えると、自分というパーソナリティを通した結果のWebマップを「あちら側」へ提供するかわりに、自分が価値を感じる人のフィルターを使わせてもらうという使い方も意外と本質的なのかなぁと思う。その自分が価値を感じる人のフィルターというのが私であれば、「miyagawa」氏であったり、「ma.la」氏であったり、「naoya」氏であったり、「umedamochio」氏であったりすると。もちろん「大衆」としての「注目のエントリー」@はてなブックマークであったり、「popular」@del.icio.usであったりしてもOKだ、と。

その用途だと今のソーシャルブックマークにない機能だけど、ブックマークのマージがあればより使い勝手はよくなるなー。これだと明らかに個人用途だからRailsあたりでささーっと作れそうかも。必須としてRSSでのブックマーク受信と、あとはゆっくりと他のソーシャルブックマークとの連携のためのRSSのI/O API あたりを実装してやれば良さそう。

フォークソノミーな機能が生きるときって、基本的に新しい情報を求めて能動的に動くときなんで、日常的にはBloglinesで受動的に情報を処理しまくる自分としては、こんなフィルター強化系のソーシャルブックマークはとても実用的だ。(と今日気付いた。)

tagはそれ自体にデータとしての価値がある

taggingっていうのは、URLのようなそのコンテンツ自体を指し示すものじゃない。それじゃ、tagは何を表しているかというと、その人のコンテンツの見方だ。切り口と言ってもいい。その人がそのコンテンツの中のどういった側面に関して興味を持ったのかを明確に表すキーだ。ここで言うコンテンツは、ソーシャルブックマークで言えば各ブックマークとイコールだ。つまり、ブックマークが興味のあるキーワードを含んだ文章を提供し、tagはブックマークした人と同じ視点でブックマーク先のコンテンツを理解するための読み方を与えてくれる。

ということで、そもそもtag自体がTim O'Reillyが「Data is the next "Intel Inside"」と言っていた「あちら側」のデータとして機能をするのは、ほぼ間違いないと思っている。興味の分布がこれほど明確に数値化して把握できるチャンスが他にあるだろうか。Amazonのアクセス記録に匹敵するコンテンツマッチ広告のチャンスだと思っている。

Data is the next "Intel Inside"

Applications are increasingly data-driven.

Therefore: Owing a unique, hard-to-recreate source of data may lead to an Intel-style single-source competitive advantage.

もしはてなブックマークが自動キーワード抽出のみで進むなら、意外と後発が足をすくうチャンスはこんなところにあるかもしれない。

  

Curt Hibbsからメールが届いた。

by tanabe on May 08, 2005

"Rolling with Ruby on Rails"の翻訳を許可してもらおうと、著者のCurt Hibbsにメールをしたら、即日で返事が来た。

めっさ良い人だった。感動。

ONLamp.comのジャッジ待ちなので、良い結果が出たら日本語版をここで公開します。(ダメだったら、私の英語力か交渉力不足。。)

  

はてなのキーワード抽出とdel.icio.usのTaggingと。

by tanabe on May 07, 2005

naoyaさんのDiaryから「はてなブックマークとTagging」を読んだので、del.icio.usユーザーから見た意見をちょろっと書いてみる。

手動タグと自動キーワード抽出の違い

 del.icio.usのタグに近いはてなブックマーク(以下、はてな)の機能は、自動キーワード抽出なのだと思うんだけど、これを手動でやるか自動でやるかっていうのは似ているようで性格が違ってくるものだと思っている。

 del.icio.usの手動タグは、「オレ分類」とでも言うか、自分が後で探しやすいようにというのが一番の目的になっていて、そのオレ基準から拡がるフォークソノミーな世界が出来上がっている。

 一方、はてなのキーワードの性格は(naoyaさんが書いているとおり)、横串として機能することにある。はてなのフォークソノミーの説明で言うならば、「ネットワーク的かつフラットな情報の構造」を作ることにターゲットを絞った機能だ。

del.icio.us - タグのメリット・デメリット

 この対比をしてみると、del.icio.usは前述のとおり「オレ分類」なので、フォークソノミー的にはあまり貢献しない場合もある。人のタグを見ているとよくわかるのだけど、本当に人それぞれで付けている。

 これはこれでメリットがあって、当然自分で探すときにはとても探しやすい。なんせ自分が直感的に感じたタグなんで、探そうと思って、「あれー、どんなタグ付けたっけな〜?」と適当なタグから探してみても、けっこうな確率で探し当てることができる。自分のセンスが基準なんで、あまり検索時のブレはない。

 じゃ、デメリットは何かというと、同じ話題を探そうと思ったときのブレがけっこう激しい。一つのタグが人それぞれの用途で使われていたりするので、ノイズとなる情報が多くなる。関連する話題を探したくても、自分のタグ付けが他人からずれていると、なかなか近い話題を括るタグを見つけられないこともあったりする。

デメリットを使い方で克服できるdel.icio.us

 それでも、del.icio.usのようなスタイルでやる意義はあると思う。手動で自由に変更できる一番のメリットは、使う人が好きなように使い方を進化させられるという点だ。工夫しながら使うことで、フォークソノミー的な用途にも十分対応はできる。海外の情報になってしまうが、このサイトを見てほしい(音声が出るので注意!Flashのダウンロードに時間がかかるのでステータスバーをチェックしながら気長に。)

 他人のタグと比べることでより一般的なタグに付け替え、情報の汎用性を高めるのはたしかに手間はかかる。それでも、特に重要なタグについては一度チェックする価値はある。例えば、Ruby on Rails関連情報のタグは"rubyonrails"にすべきか"rails"なのか"ror"にすべきなのか。ONLamp.comのチュートリアルについているタグを見れば、一般的な傾向がつかめる。これだけで、面白い"rails"情報により効率よくアクセスできるのだ。

 そう考えると、一人で使い勝手よく使いたい人にも、フォークソノミーなツールとして生かしたい人にも、どちらにもそれなりに対応できる便利さがある。まぁ、そうは言っても、面倒なことは面倒なので、将来的には手動&自動のハイブリッド型が主流になるんだろうなぁという気はしているが。

 

  

Blog論2005 JAPAN

by tanabe on May 06, 2005

かなり遅まきながら、Blog論について書いてみた。かなり荒いのだけど、話として早いうちに出した方が良いと思うので出力してみる。

前提としての議論は、この辺りを読んで頂ければと思う。

My Life Between Silicon Valley and Japan - Blog論2005年バージョン(1)

My Life Between Silicon Valley and Japan - Blog論2005年バージョン(2)

My Life Between Silicon Valley and Japan - Blog論2005年バージョン(3)

My Life Between Silicon Valley and Japan - Blog論2005年バージョン(4)

My Life Between Silicon Valley and Japan - Blog論2005年バージョン(5)

My Life Between Silicon Valley and Japan - Blog論2005年バージョン(6)

My Life Between Silicon Valley and Japan - Blog論2005年バージョン(7・これで完結)

・誰の情報を求めていたのか?

日本において、国際競争力のあるソフトウェア製品を作った経験のある超優れた職業プログラマというのはそれほど多くはないと思うのだけど、そーゆー人の少なからずは大企業の奥深くにいるような気がする。富士通や日立やNECや東芝やNTTやIBMやらなんやらにいるような気がする。でもって、そーゆー人は別にオープンソースのコミュニティになんか参加したりしない。参加する強いインセンティブはない。わたしは、そーゆー人がオープンソースのコミュニティに参加しないことを責めたりはしない。絶対しない。だけど、残念だと強く思う。なぜか?

日記を書くこととオープンソースソフトウェアに関わること

経験と実績を積んだ本当に地力のしっかりした底力のある人たち。例えば、柴田芳樹氏や荒井玲子氏であればイメージが近づくであろうか。

 

・どのような情報を求めていたのか?

私事になるが、僕が1980年代後半に「IT産業に特化した経営戦略の研究」ということを専門にして以来、どういう勉強法を工夫したかということを少し触れておきたい。

前にもどこかで書いたことがあるかもしれないが、「米国IT産業の最前線で活躍する超一流の個人(経営者、技術者、コンサルタント、ベンチャーキャピタリスト、ビジョナリー、起業家・・・)が、どういう言葉をリアルタイムに肉声で発するか」というところに焦点を絞り、僕は徹底的にその肉声に耳を傾け続けてきた。それをもう15年以上も飽きずにやっている。「IT産業は大きな流れとして、これからどういう方向に向かっていくのか」という研究テーマについて、他の人には他の人で色々と勉強法はあるだろうが、そういう肉声に刺激を受けて考えるしかない、とあるときに気づいたからだった。それは僕の場合、「新しい技術に関する先端研究内容や、世の中で提案されている標準等の詳細を眺めることからIT産業の行く先を直感する」という技術的才能を欠いているためである。その才能の欠如を補うために編み出した苦肉の勉強法だったのである。僕の書くものが「IT産業好きの文系的な人たちや経営者たち」に愛好される理由でもあり、「本物の技術的才能を持った人たち」からやや胡散臭いと思われる理由と、深く深く関係している。

Blog論2005年バージョン(2)

梅田氏に欠けていた「本物の技術的才能」をもって、「IT産業の流れ」のヒントとなるような内容を持ったBlogを求めていたのだろう。

そもそもBlogで書くことの良い効用について、

(5) 自分が持つ「専門性の高い情報」、自分の専門に照らして「質が高いと判断できるコンテンツへのリンク」をリアルタイムで公開していくという習慣は、ネット全体での「知の創造」にプラスに作用するだろう。

と考えていた梅田氏である。自身のBlogだけでなく、他人のBlogについても自身が価値を感じたことと同種の内容を求めたいと思っていても不思議はない。

 

・今後、梅田氏の求める方向へ動くのか?

そしてある程度の結論が出るのかと期待していた話として、「けっきょく、梅田氏の望むような方向へ動いていく可能性はあるのか?」という点がある。これは、「面白おかしい日本のブログ」とシリアスとの対比としてではなく、そもそも日本にその土壌があるのか、という意味で問いたい。

私は、今後ますますギークとスーツの境があいまいになり、ギークならではの視点で未来を見通すようなBlogは出てくるとしても極端な少数派となると思っている。一方で、可能性として新しいスタイルのギークが生まれてきて、ギークの視点から未来を見るというBlogが出てくるという可能性に期待はしている。

なぜ、現状ではそういったBlogが出にくいと考えているのか、可能性として期待する新しいスタイルのギーク像はどういったものか、といった辺りを書いていきたい。

 

職業プログラマが存続しにくい現状

よしおか氏の文章にはこのような記載があった。

職業的プログラマとして現役を続けるためには、大げさなことを言えば、死ぬまで勉強を続けなければならない。あ、勉強といっても、別に机に向かって暗記物をやるということではないですよ、もちろん。プロのアスリートが現役でいるために引退するまで常にトレーニングを続けなければならないのと同じだ。

日記を書くこととオープンソースソフトウェアに関わること

一つの違和感がある。

いや、私は普段からよしおか氏の話を読ませて頂いているので、よしおか氏の文章自体としては非常に刺激的で、上の世代にこのような方(そして、その背後に同じような同世代の方々)が居るというのは嬉しいのだ。ただ、自分の日常としてのIT業界というものとは、乖離を感じる。

現在のIT業界のトレンドは、職業的プログラマに否定的だ。「Blog論2005年バージョン(7・これで完結)」にはギークとスーツの話もあったが、特に30代前半以降の若手のエンジニアには、ギークへの絶望的な思いがある。エンジニアとしての自己肯定は、完膚なきまでに叩きのめされているのが、現代のエンジニアと言っていい。彼らのほとんどは、スーツに成ることを望んでいるか、望まないまでもスーツに成るしか自分のキャリアの存続の道はないと思っている。

これは、主にエンタープライズ系のシステム開発をしている人に強い思いなのだろう。例えば@ITを読んでいるような人たちと言えば想像付くであろうか。

技術者と作業員」のようなことを言い切るのは羨望のマナザシでは見られることになるが、けして多数派の考え方ではない。(だからこそ、登氏の不満につながるのだろうが。)

 

「若手エンジニアのキャリア戦略」とは?

もう少し話を具体的にしよう。

IT業界の若手と呼ばれる人間にとって目下の緊急の課題は、自分のキャリアだろう。

キャリアについては、梅田氏がかつてこのように書いていたことがある。

連載をはじめてしばらくして、山岸君から「キャリア戦略」への若い読者の関心が強いと聞いた。「キャリア戦略」といえば「いかに生きるべきか」みたいな大仰な話につながるわけで、そんなものを書く気はもともと全くなかった。でも、「成功とか幸福というのは、頭の回転の速さ、知識の量、記憶力といったこととの相関関係はむしろ小さく、人との出会いという偶然を大切にする姿勢、日々過ごす環境を少しずつでも良いものに変えていくことにどれだけ意識的であるか、自分を知りその自分の生き場所を社会全体の中から見つけ出そうと考えられる柔軟性、そういう類のこととの相関関係のほうが大きい」という、こう書いてしまえばまぁ当たり前の話を、ITトレンドにときどきまぶして、若い人たちに話してみるのもいいかなと思うようになった。そして、ロジャー・マクナミーが何気なく口にしたVantage Pointという言葉にとても触発された。若者は見晴らしのいい場所に行け。確かにそれが「キャリア戦略」としていちばん大切なことだなと思った。見晴らしのいい場所には旬な人が集まるからより良い出会いが生まれるし、未知の自分を発見するチャンスも大きくなる。

CNET Japan連載を終えての感想(2)

梅田氏は日本の状況をご存知の上で、このような梅田氏にしかない切り口でのキャリア戦略の話を書いていたのかもしれない。Vantage Pointの話は私の中で今後を考えるときのとても比重の大きな要素となったし、とても面白く読んだのを覚えている。

ただ、この時もある種の違和感を覚えたのもたしかなのだ。

この文章で言う、「山岸君から「キャリア戦略」への若い読者の関心が強いと聞いた」ときの、「キャリア戦略」はここで語られるものよりも、より切羽詰った余裕のない物であったのだと思うのだ。

若手エンジニアの抱えるキャリア上の課題というのは、大雑把に三つの視点で語られる。

  • テクニカルスキル
  • ビジネススキル
  • 業務スキル

テクニカルスキルはイメージしやすいだろう。従来からのエンジニアにも要求されてきたいわゆるギークとしてのタシナミである。

ビジネススキルは、IT系のエンジニアがコモディティ化してきたことにより重視されてきたものである。従来も成功するためのキーではあったが、絶対数が現在よりも少なかったため、専門職扱いとして目をつぶって見逃されることの多かったスキルである。

業務スキルは、さらに現在のトレンドと言っていいだろう。少なくとも一つの特定のドメインに特化した業務知識を持たなければならないというものだ。

これらの現在の日本の状況は、書店へ行けば一目瞭然だ。技術書のコーナーがあり、その脇には「SEのための・・・」「若手SEの学ぶ・・・」と言ったタイトルでプレゼンテーションやコミュニケーションスキル、マネジメントスキルなどに関する書籍が並ぶ。そして、さらに冊数は減るが「SEのための・・・」シリーズとして、会計や金融、製造業といった業務ドメイン別の基礎知識についての書籍が並ぶのである。

そして、エンジニアがこれらを身に付けた末に目指すのは「プロジェクトマネージャー」であり、「ITコンサルタント」なのである。(もう一つ他者が太刀打ちできないようなプログラムを書ける者として”スーパープログラマ”(名称は色々)が挙げられることが多いが、これは「君には無理だろ?」という文脈で使われることがほとんど)

つまり、日本のギーク志望者たちは、ギークの鎧を脱ぎ捨ててスーツを着るしか将来はないと考えているのだ。これは、好き嫌いとは関係ない。いや、好き嫌いだけで言えば、技術の好きなエンジニアはまだまだ多いと感じた。ただ、現実(として世間に吹聴されること)がもはやそのようなギークとしての未来を許さなくなったというのが、日本での世間一般のイメージなのである。

ここには、Grahamが説くような美しきハッカーの姿はなく、またよしおか氏の説く頑なで懸命に生きる職人としての美学も薄い。それでも、あっという間にコモディティに関しては供給過多、クリティカルな部分に関しては需要過多というアンバランスな状態になった業界で、どのように生きていくかを迫られた人たちの現実がある。

 

ギークならではの視点は重視されない

この現実は、程度などの差はあれ、「日本企業で働く超一流の個人」たちも感じているもののはずである。年齢的な部分でより強く危機感を持つ人も居るかもしれない。また、自分の残してきた実績や、根強く残る「終身雇用」への信頼から歯牙にもかけない人もいるかもしれない。

ただ、いずれにせよギークでいることへの自尊心を持ちたい、持たなければいけないという思いと、ギークであることの劣等感、スーツへと脱皮を図る必要があるという意識・強迫観念の両面に挟まれているのが多くのエンジニアたちの実像のような気がする。

これらは、Blogの世界では自虐的なスタイルでは発露するが、よりシリアスなスタイルでは表現されているのをあまり見ない。ただ、「働いてみたいIT企業」の調査結果などを見るにしても、上流と呼ばれる仕事、スーツな仕事への憧れというのは明らかに今の主流だ。

で、こんなところを覗いたりするようになると、その不安はますます助長されるわけである。

こうした背景から日本のエンジニアを考えると、ギークならではの視点というものがあまり重視されなくなっていると言ってよいと思うのだ。スーツ然としたギークこそ最先端であり、あるべき姿であると考えられている。豆蔵 萩本順三氏辺りは、キャリアモデルになり得るのかもしれない。同じCTOでも伊藤直也氏との違いは明白だ。(どちらが良い悪いという話ではない。念のため)

これには、従来のエンジニア像への極端な揺り戻しもあるのだとは思う。数年すれば、いくらからは基本となる技術見直しの動きも起こってくるだろうが、それでも日本のエンジニアの行く先としてスーツを着たギークへ向かうのは避け難いように感じる。

大分、話がそれている感があるが、こうしたことを考えると梅田氏の求めるような意味での「ギークならではの視点で未来を見通すようなBlog」というのはポンポンと生まれてくる環境ではないと思うのだ。

シリアスなBlogとして出やすい形としては、How to的な技術Blogと、ITとビジネス的な話との折衷Blogになりそうに感じる。

 

期待を込めての日本の姿

先ほど、「一方で、可能性として新しいスタイルのギークが生まれてきて、ギークの視点から未来を見るというBlogが出てくるという可能性」と書いた。

これは、伊藤直也氏のFeedBackを読んだりして感じている希望としての可能性だ。日本でもCheap Revolutionに乗っかってギークでありながら、生計を立てられる道を模索する人たちがどんどんと生まれてくるんじゃないか?という期待だ。

そうなれば、ひょっとしたら住み分けにはなるかもしれないが、「ギークならではの視点で未来を見通すようなBlog」も生まれてくる土壌が日本にも出来るかもしれないと思う。

梅田氏の提示した「新しい日本」とは別のものだが、これが私の感じる「新しい日本」への可能性だ。

  

詰まったら・・・

by tanabe on May 05, 2005

梅田さんのブックマークから見つけた「羽生――21世紀の将棋」という本の創作ノートからメモ。

もう一つ、『将棋世界』編集長の大崎善生から、こんなことを訊かれたことも、きっかけになっている。
 「保坂さん、小説書いてて詰まったらどうする?」
 「それまで書いたところを読み直す」
 「羽生も同じことを言ったんだよ。指し手に詰まったら、それまでの指し手を何度も辿り直すんだって。それまでの指し手の流れに一番素直な手が、一番いい手のはずだって言うんだよ」
 それまで棋士は、自分の思い描く理想形を実現させる手が一番いい手だと思っていた。ここでも羽生は、いわば「主体」を放棄して「法則」についている。これはもう小説や音楽や絵画とまったく同じことで、作品というのは作者の当初の意図を離れて、その作品固有の法則や運動を持ちはじめる。そのとき、作者の「主体性」なんか関係ない。

なんかもやもやと思ったのだけど、言語ではっきりできるレベルまで具体化できなかったのでメモだけ。

筆者の方には、将棋愛好家ではない「あんまりわけのわからないところ」での引用となってしまい申し訳ないかぎり。

  

伝説のトレーダーをマネジメントするには

by tanabe on May 04, 2005

藤巻健史氏の「タイヤキのしっぽはマーケットにくれてやる!」を読んでいる。自身「伝説」と呼ばれたトレーダーである藤巻氏が尊敬するトレーダーとして挙げていたマーカス・マイヤー氏の話が興味深い。

日本に赴任してきて三ヶ月の間ほとんど何もしなかったマーカス・マイヤー氏は、その三ヶ月の観察期間で藤巻氏のマーケット分析の能力を買い、藤巻氏が強く自信を持ったマーケットの見方に対し、三倍の巨大なポジション(持ち高)を持つよう指示したという話があった。

「三倍の巨大なポジション」については、

 三倍のポジションというのは、当時の私にとっては考えたこともないほどとんでもない巨大なポジションだった。JPモルガンのあらゆるトレーダーの中でも最大の、それもダントツに大きなポジションになった。東京市場で同じような仕事をしている人たちの中でも、突出したポジションになったのはもちろんである。

という記載があり、その判断がマーカス・マイヤー氏にとってもけして小さいものではなかったことをうかがわせる。

この話を受けて、藤巻氏の語る上司とトレーダーの話が良い。

「いいトレーダーが育つかどうか」はまさに上司次第であると、私は絶えず言ってきた。とかく上司は、トレーダーの損がたまってくると不安になり、文句を言いたくなる。自分の部署の成績を左右する大きなポジションを持っているトレーダーであれば、上司とは運命共同体だから、なおさらである。自分が直接トレーディングしていないからなおさら不安なのである。運転手を信頼していないと、助手席に乗っているのがえらく不安になるのと同じである。トレーダーにすぐ損切りをさせたくなる。

 トレーディング経験のない上司を持ったトレーダーは、とりわけ不幸である。上司は「損をしている時に損に耐える胆力を鍛える」訓練を積んでいないからである。上司のするべき仕事とは、トレーダーの論理を検証するため、絶えずトレーダーと論戦することである。トレーダーがどの程度マーケットの見方に対して自信を持っているかをチェックすることである。論理に無理があったり、自信がないのにポジションを持ち続けているようだったら、勝負から降ろすべきである。

トレーダーの「マーケットの見方」に対し、どのくらいその論理に自信を持っているのか、をチェックするというのがいい。

「マーケットの見方」というwhatに対して、「自信」という視点で定量的にチェックをする。もちろん「自信」なんてものは厳密には定量的に量れるものではないのだけど、それはビジネスとしての視点なので、厳密に量るわけではなくて、「こいつはOK」か「こりゃ、NG」のどっちかを判断できる程度でいいわけなんで、「マーケットの見方」のロジックと「自信」の程度でチェックするというのは、非常に具体的で本質的な報告の受け方だと思う。

何が本当に必要なことか、が分かっていないと定型的な管理手法を使って色々と情報は集めたけれど、何も肝心なことは把握できないという結果になりがち。

ITILやPMBOKを学ぶのはもちろん大切なんだろうけど、そもそもの本質的なマネジメントっていうのはこういうことなんだと思う。

以前書いた「「何を管理すべきか?」がマネジメントの本質を問う」なんかもその辺りの機微を書きたかったのだけど、さっぱり書ききれていなかったのでこの話も書いておく次第。

ちなみに、今回取り上げた「タイヤキは・・・」はあまりオススメしません。読みやすいし、面白おかしいけど、まぁ、それなりの本。

どうせ藤巻氏の本を読むなら、「藤巻健史の実践・金融マーケット集中講義」の方がずっと内容が濃い。これもお堅いはずの内容が軽妙な語り口で非常に読みやすくなっているので、タイトルに臆せずこちらを読んだ方が良いです。ということで、リンクも「集中講義」の方だけ貼っておきます。

藤巻健史の実践・金融マーケット集中講義

  

キャリアビジョン(ポジ)

by tanabe on May 01, 2005

codemaniaxさんの「codemaniaxの脱・公務員宣言」のこちらの記事を読んで。

世の中いろいろ見てて感じたんだけど、プロフェッショナルとして自分のキャリアビジョンについて真剣に考えてる人って、思ってたより少ないんだなぁ、と。

 あー、これは感じます。めちゃくちゃ感じます。よく皆それで不安じゃないよなーって思う。私なんかは社会人の入り口からけっこうハンデを負っているという意識があるので、とにかくやれるだけのことはやろうという思いが強い。どこでリカバーするか、最後はどこで勝負をするか、をいつも考えている。大学中退だし、文系エンジニアだし、武器を間違えるとあっという間にダメエンジニアになりかねない。(今もなっているという噂も)

クリステンセンの「イノベーションのジレンマ」とかは読むくせに、ドラッカーの「プロフェッショナルの条件」を読む管理職は少ない(と感じる)。大所高所の議論を好み、自分の足元を見つめることを怠る。

 本当の良書は「努力を避けては何も成らない」ということしか書いていないから、求めている物と違うのかも。みんな、自分が想像もできないような成功をするには、なんかとんでもない抜け道があるんだと思ってるんだろうなぁ。
ひょっとしたら、何か抜け道があるのかもしれないけど、自分がそんな類稀なラッキーにぶち当たるほど恵まれた運命の下に生まれたとは思えないし、そんなあるかないかわからんものに一生を左右されるくらいなら、目の前の1分1秒で先の1ヶ月、1年、10年を脳みそ溶けるまで考えている方がよっぽど安心できる。
100億円は欲しいけど、100億円だけが欲しいわけじゃないから。Grahamじゃないけど、プロセスが美しいことはビジネスにおいても最高のhackだと思う。

 まぁ、どうやったら濡れ手で粟の大儲けができるか考えている人に、正しい方向の努力を他の人よりも圧倒的に濃い密度でひたすら繰り返して上達しろって言ってみても、「はぁ。そうですか。」で終わっちゃうんだろうな。

 それでも幸か不幸か、自分がこれから勝負をしていくべき相手は、「やってない人」でなくて、すでに「成し遂げている人」をターゲットにしないといかんので、「やっている途上の人」な自分はなんにも安心できる話じゃないのだけど。うし、がんばろ。