考えごとの最近のブログ記事

全体のパイが決まっていて、それを均等に上手に分ける。
日本人はとっても得意だ。

短期的にパイは止まっているから、うまく分けたような気になれる。
少したつとパイが変化する。
きっとその頃には新しい経営者になっていて、そのときのパイをうまく分けなおす。
これを続けていれば、世代をまたいで均等に成果を残せる。

変化が加速すると、すごい勢いで経営者を変えなければ適応できない、ということになる。
そんなことは無理だから、少なくとも、すごい勢いで自ら変化できる経営者は必要だろう。

しかしもっと必要なのは、まったく新しいコンセプトを生み出し、
細かい変化を無視できるほどの大きなパラダイムシフトを作り出せる経営者、
ということになるかもしれない。

この文書の「経営者」を「技術者」に書き換えても、成立すると思う。

現在の主流のコンピュータ(OS)は、イベント駆動である。

1. イベント駆動OS
CPUなどの処理リソース全体のうち、管理用をのぞいた残りの部分を浮動票として、
みんな(プロセス)で仲良く使う。
一般道路のようなものだ。
なかには救急車などの緊急車両もあるので、先に通さなければならない。というルールもある。

共有すれば共有するほど効率は高まりやすい。
しかし、一方で、処理が溜りすぎれば、渋滞などを引き起こす。
横転トラックが道路を封鎖したり。みんなが同じリソースを食い合ってしまう。

2. 時分割(TSS)OS
初期のOS(大型汎用機)は、時分割(TSS)であったときく。
(私自身は、TSS自体には数時間しか触ったことがないので、あんまし実感がない。)

また、ロボットなどのリアルタイムOSも、時分割にちかい処理をしているはずだ。
(これもよく知りません。)

横転トラックが道路を封鎖しても、電気や水道が止まらないように、
役割分担をはっきりすることで、全体の最低限のスループットを維持する仕組みである。
(だんだん、メタファーが苦しくなってきました。)

あらかじめ処理を割り振るので、実際は行わない/必要がない時間というのが発生しやすいが、必要な時に必要なリソースが待機しているため、全体としての危機を引き起こさない。

3. イベント駆動OSの安全策としての分散処理
従来、イベント駆動のOSで、安全性を確保するためには、マシンをわけ、負荷を分散してきた。
一台がこけても他のマシンはこけないような配慮を行う。
そのために各マシンの装置の独立性を確保し、配分装置には精度の高いものをつかう。
そのためには、多くのマシンが必要になる。ネットワーク機器や負荷分散装置も高速で精度の高いものが必要だし、ネットワークも冗長化するためケーブルがたくさん必要になる。

しかし、資源枯渇が深刻になってきたため、マシンをホイホイと増やすわけにもいかなくなってきた。マシンの処理能力もフツーには伸びなくなってきた。

4. サーバ統合
そこで、一台のマシンを、時分割(TSS)で分割し、その中をイベント駆動で処理したい。
CPUがマルチコア化するにあたり、各コアを仮想のマシンとしてとらえれば、これまでマシンを複数にわけてきたケースでも、マシン一台ですむ(サーバ統合という)。
仮想マシン間の通信は共有メモリで代替できるので、そのぶんの、物理的なネットワーク機器やケーブルも削減できる。物理障害の影響が減り、待機電源も少なくてすむ。

VM(仮想化)はそういうニーズ(資源枯渇)と技術動向(マルチコア化)にマッチしていると考えられる。

5. イベント駆動と時分割(TSS)の組み合わせ
VMM(仮想化管理機能)自体がイベント駆動のOS上で動いていると、時分割(TSS)が正確にできないので、これまでマシンをわけてきたようには、安全でない。
そのためVMM自体が、時分割(TSS)を行えるOSであるほうがより安全であると考えられる。

ベアメタル型VMM(VMwareでいえばESXサーバ)はこの方向である。
VMM自体が極めて小規模なリアルタイムOSカーネルになっている(らしい)。

イベント駆動と時分割(TSS)を組み合わせる、ひとつの方法、トレンドである。

・・・そして、信じるか信じないかは、あなた次第、である(かもしれない)。

※ちなみにベアメタル型VMM(だけがイベント駆動と時分割(TSS)を組み合わせたわけではない。もともとOSはイベント駆動だが、各ハードウェアは時分割(TSS)だったりするわけだし。CPUクロックは完全に時分割(TSS)であると考えられる。時分割(TSS)は過去のモノ、なんていうのはナンセンス、ということである。

静的プログラミングの限界を認識し、動的プログラミングに挑んでいる点で、これらには共通点がある。

  • 考えて走るサッカー
  • トヨタ生産システム
  • アジャイル開発
  • 行動経済学

インプットが圧倒的に多く、多様なため、処理方法を事前に計画できない。
そのため、処理者がコレクティブに動くことで、状況に対処する。
各処理者が「事前に決まった行動」をとることを前提としない。
各処理者がどのように情報を分析し、対処するか?
どのように「他の処理者と協調できるか」?
全体のトレンドを決めるのは各処理者の行動様式に依存する。
そのため、各処理者にどのような情報をあたえ、訓練をするべきか。
また、指導や訓練をするものも、やはり、一処理者である。

処理者一人一人の質を高め、全体としての状況認識、
個人としての問題解決への創造性の発揮、スルー力を
高めなければならない。

協調作業を重視しなければならない。
単純な役割分担への固執は、各処理者の成長を妨げるかもしれない。
コミュニケーションと観察と考察/仮説検証が必要だ。

- - -

「インプットが圧倒的に多く」なったのは、流行ではない。
機械やCPU能力の増加、知識の蓄積、共通の言語を理解する人口の増加、
センサーやカメラの飛躍的な増加。
それらが組み合わせ爆発をともなって発生しつづけている。

- - -

するべきことの重点は常に変化し、学ぶべきことは常に発生している。

「オリジナルか?」と問い続けると、よりニッチの方向にいってしまう。
奇抜さを求めすぎれば、万人からは理解されないものになってしまう。
・・・と、思ってきた。

しかし。
本当に素晴らしいアイデアは、トレードオフの上をいくものだ。
自分の中のトレードオフ、世の中の有効フロンティアのさらに上をいくものだ。
「複数の問題を同時に片付ける」アイデア(by 任天堂岩田社長)。

それは、結果的に、必然的に、世の中にまだないもの。
自分が知らなかっただけ(車輪の再発明)ってことも多かろうが、
そうでなければ、まさに、オリジナルじゃないか。

「世の中的に意味はあるが、未解決な問題」を追いかけることに集中すれば、
解決するアイデアは、必然的にオリジナルなものになる。
「そこにたどり着くには苦しいけれど、同じ苦しむなら、成果が何十倍、
 何千倍になって返ってくる方に努力した方がいい」(by MIT石井さん)

そういうことか!

年内にやってしまいたいこと(仕事編)
 開発用サーバラックのケーブル整理。
 ESXサーバの整備。
 Trac月への移行。
 某Proxyサーバ。
 Lの改修。
 PuppetとかMRTGとかhinemosとか。
 jQueryとかAIRとか。
 Rails2.0。
えー無理じゃん。

ここ数年、周りの人間があまり変わらない状態が続いたので、錯覚しているけど、
僕は、確実に年を取っているのである。

彼らと知り合って、何年がたったか。
入学したての大学生なら、もうとっくに卒業している。

愕然とした。
慄然とした。
唖然とした。

- - -

もしかして、これって、歴史的にも日本によくある風景なんじゃないだろうか。
自分の回りだけ時間が緩やかになっていることに、気づかない。
(ちょっと風呂敷広げすぎ)

ちょっと読み直したかったので、なか見検索で読み直しました。(本が見当たらない・・・・。)

It is a common mistake to say 'the data were fitted to the model' as if the data were something flexible and we had a clear picture of the structure of the model. On the contrary, what we are looking for is the minimal adequate model to describe the data. The model is fitted to the data, not the other way around. The best model is the model that produces the least unexplained variation (the minimal residual deviance), subject to the constraint that all the parameters in the model should be statistically significant. (p.4)
よくある間違いは、「このデータはモデルにフィットしている」と考えてしまうことだ。単にデータがフレキシブルで、我々が極めてはっきりとしたモデルをもっている、だけかもしれないのに(訳注: モデルに都合の良いデータをあてはめてしまっている、と言う意味だと思う。)。そうではなく、我々が探しているのは、データを説明する最小のモデルである。モデルをデータにフィットさせる。それ以外の方法はない。最良のモデルとは、説明できないような多様性がもっとも少ないモデルである(minimal residual deviance 最小残留自差)。その際、すべてのパラメータは統計的に有意でなければならない。

これって、統計の説明だけど、「科学」の宣言だと思います。勝手に感動してます。

Statistics: An Introduction Using R
Michael J. Crawley
John Wiley & Sons Inc (2005/04/28)
売り上げランキング: 240017

みんなが飽きると、無視されていた別の方向が脚光を浴びて、振り子の触れる方向が変わる。
知識の生産が、知識の消費に追い付かない、というのが基本にある。

研究され尽くして、新たなアイデアが枯渇。
まったく別の哲学が「発見」され、そちらに徐々に人々の意識が移動していく。
まっさきに飛びつくのが、ギークという人達なのかもしれない。

Erlangは古いものであるが、今のWeb2.0を牽引する人達には馴染じみのない文法だろう。
あるいは80年代からソフトウェアに携わる人には、もう忘れてしまった名前だろうか。

RubyがJava上で走ったり、.NET上で走ったりしていく、つまり、一言語多実装が現在のトレンドだ。しかしそういうものが、いまのところErlangにはない。ErlangはErlang言語であり、BEAMインタプリタがうまく動作することで、Erlangの特性が出る。これらは不可分だ。

Erlangはそういう意味で、次の振り子の方向になりうるかな、と思った。
かなりこじつけである。

RubyやJavaの用途をErlangで置き換える、という日はたぶんこないと思われる。
だからといって、Erlangが普及しない、っていうことはないとおもう。
まあ、そのへんがいいところじゃないか、ってことで。

意味深なタイトルのわりに、平凡なオチである。

日常生活で整理整頓のコツは、「上手に捨てるこのと」だ。
「捨てる技術」なんていわれたりする。
端的なのが「超・整理法」っていうやつで、一定時間触っていない袋はバンバン捨てていく、という方法。
企業や政府でも、機密情報の管理は、「超・整理法」方式でやっていると思われる。賞味期限切れの個人情報なんかが残っていては困るので、一定期間を過ぎた機密情報はきちんと廃棄する、という感じだ。

コンピュータの世界でも、「捨てる技術」は性能を左右する大事な要素だ。

キャッシュの管理では、LRU(Least Recently Used)という、「超・整理法」と同じ方法がある。容量がいっぱいのときは、「もっとも使っていないもの(LRU)」を捨てる。そのために、そのデータを使うごとに、リストの先頭に持ってくる。LRUは常にリストの最後尾になる。

動的メモリ管理の方法であるガベージコレクション(GC)も「捨てる技術」だ。使わなくなったメモリ領域を、ある時点で片付けてまた利用可能にする。Java、Ruby、.NET Framework、Lisp などの、動的にメモリを確保/解放する言語で使われており、しばしばそのやりかたが性能を左右する。

探索アルゴリズムでも、「枝苅り」という考え方がある。全数を調べられないくらい大きいときに、「そっちには答えがなさそうだから、もう調べない」というのを一定の基準で決めて、時間を節約する。

統計だと「オッカムの剃刀」か。

- - -

難しいのは、捨てないものと、捨てるものを、どう峻別するかである。
必要な物はなるべく捨てないで、いらん物をとことん捨てる。
なるべく簡単で高速で、捨てすぎず残しすぎず、精度の高い「捨てる技術」を使えると、シアワセになれる。

言葉の遊びエントリ。

- - -

文書の書き方に2つあるとする。
 1. 流れを追えるようにしっかり道筋を立てて文章を書く
 2. 要点を箇条書きにする

コンピュータ言語でいうと、
 1. C系の言語
 2. 関数系の言語
に近いのかなぁ、と思った。

もちろん、さっぱりと文章を書くことだって出来るし、
箇条書きを文章っぽく書くこともできるわけだから、
Cで究極まで文字数を減らすコードもかけるし、
関数系で冗長なコードを書くことだって自由だ。

箇条書きはときに説明力不足なので、
より多くの説明(コメント)が必要になるかもしれない。

実績をすべて捨て去って、新しいことを始めなければ、生き残れない。
自分の見えるところで、見えないところで、そうやって前のめりに生きている連中が、
これだけグローバルでフラットになった世界において競争を始めているというのに、
自分は関係ないと、これまでの積み重ねの上に生きていけるはずだと、
そう簡単に自分をだませる程、われわれは恵まれた社会に生きてはいない。

何がしたいのか、どういうふうにしたいのか、
何を信じるのか、何になりたいのか、
なぜ意味があると思うのか、誰が欲しがっているのか。
何が足りないのか。

・・・問い直していこう。


今は難しい。時間がない。
技術が無い。知識がない。
環境が悪い。人がいない。

・・・安易な答えに安住するのは簡単だけれど、
それで何年も自分をだますのは、難しいと思うから。

ソースコードはリファクタリングを重ねていくと、どんどん短くなっていく。
重複した処理をまとめて関数にし、効率的な記法に入れ換え、
使いそうに見えたけど使わなかった処理をなくし・・・。
そうして、洗練されてメンテナンスしやすいコードになっていく。
一方で、リファクタリングは、なにが重要かを再確認する作業でもある。

「そうじ力」の本を買ってしまった。
ライフハックにおけるリファクタリングなわけだが、その効果はソースコードのリファクタリングの比では無いらしい。
掃除すると未来が薔薇色になったりするらしい。
マメに動くから痩せてさらにお得らしい。
掃除しないと悲惨な運命が待っているようだ。
掃除して部屋をピカピカにしたらさらにフライパンで煎った塩を撒くといいらしい。
・・・ほんとかよ。

でも、「そうじ力」本のおかげでメキメキと掃除したくなった。
これはすごい。ダイソン大活躍である。
決して本代を取り返そうっていう貧乏根性だけではない。ちょっとはあるけど。

家族の荷物を片付けて文句いわれた。
人の大事なものは捨ててはいけない。
人の大事なものって、案外わかんない。

今週は風邪引いた。
そうじではウィルスは防げない。
そうじ力は万能ではないのだ。
きっと、ダイエット効果もそんなには期待できない。

とりあえず、幸運が舞い込んだとはいえないけど、
少しいい習慣がつくといいな。

「掃除しなければ」じゃなくて「掃除でもすっかな」ぐらいの
ユルイ感じでいきたい。バーチャファイターでいえば舜帝が
寝ながらローキックを出す感じであろうか。

投資計画を立てるということは、いつまでにどのくらい回収できるかという推測をたてるということ。

投資計画が立たないような、
まだ海のものとも山のものともわからないところで、必死で調べ、もがき、思いついたり、教えてもらったり。
そういうのが楽しいかも。

そういうことが、人生で、あと何回できるだろうか。

怪我をしたとき、「ああー、痛い」とか「なんで怪我しちゃったんだろう」とか考えている裏で、血小板は勝手に傷をふさぎ、皮膚組織は修復を始める。

これってすごいことなんだと思うけど、普段はなかなか気づかない。
若いうちは「つばつけときゃ直る」という世界なので、
必死で血を止めている血小板のことなんて、思いもしなかったなぁ。

傷の直りが悪くなってはじめて、若いころの元気な血小板のありがたみがわかる。

- - -

どうやって、早く傷を治すか?

プロスポーツ選手がこの課題に挑む姿を報道で見るけれど、壮絶なものがある。
イングランドのサッカー代表ルーニーが、ドイツW杯直前に怪我をして「ルーニー大作戦」といわれる回復作戦で本大会中に間に合っただとか、同じくイングランドのベッカムが日韓W杯で復活したとか、日本代表久保が必死のリハビリでドイツW杯に間に合わせたのに代表落選したりとか(残念!)。

ケガからの早期回復は、時として、技術以上に死活問題なのである。

- - -

怪我をしてしまったときは、とにかく怪我を治すことを考え、自分を励まさなきゃいけない。
そのとき、「ケガをしない方法があったのに!」「なんてくだらないことでケガしたんだ!」なんてことを妄想したって、気が滅入るだけ。

ケガと向き合い、励まし、治るまで、我慢して頑張る。
それは、地道で大変だけど、とても重要で意味のあること。

- - -

まず、怪我を治そう。
夜を徹して傷をふさいでいる、血小板をリスペクトしよう。
体をよく休ませるとか、できる限りのサポートをしよう。

そして、怪我が治ったら、落ち着いて、怪我しない方法を考えたらいい。
そうすれば、きっといい考えが浮かぶんじゃないだろうか?

過熱しすぎることを恐れるあまり、つまらないものを作って、無視されるより、
まだ、面白いものを作って、過熱、炎上するリスクを負う方が、まだましな選択だと思う。
けれど、コストが絡むとそうもいかないか。

1. no attention 無視
2. less attention 人気がない
3. well attention 人気がある
4. over attention 過熱
5. burn out 炎上、燃え尽き

一般的に、 5の発生確率より、1の発生確率のほうが高い。
嗜好が分散化しているとすればその傾向は高まる。

しかし、精神的には、5が発生すると、もう一度やる気はおきないくらい打ちのめされるのかもしれない。
きっとコストがかかることも多いだろう。

ブログなら、サーバ能力拡張した上で炎上、燃え尽きたら、つらいかも。
しかし、ほとんどの場合、そこまで恐れる必要のない 2. less attention どまり。 ロングテールのテール部分。

※いろんな人の話の焼き直しですけれど、
 とりあえず適当な文書が見つからなかったので、書いておきます。
 間違いやおかしな点がありましたらぜひご指摘ください。
 出展やリンクがわかり次第、リンクしていきたいです。

- - -

今、私が使っているソフトウェアのほとんどは英語圏で書かれている。
OS, ブラウザ, データベース, プログラミング開発環境…。
例を挙げるまでもない。

それは昔から変わっていない。
しかし、ソフトウェア業界という観点でいえば、実は、大きく変わってきた。


英語で書かれたソフトウェアを日本語で動くようにするためには、

1:処理の修正
 日本語データが扱えない部位を特定し、扱えるように修正する。
 特に、英語を処理するためのソフトウェアは英語の文字コード(ASCII)を扱えればよいが、日本語は文字の数が多いため、英語をあらわす7bitのコード体系ではひらがなすら扱えない。8bit(1バイト)に増やせば、カタカナまでは入るが、漢字は無理なのでさらに拡張して2バイト分のコードで一文字をあらわす。つまり8bit対応に加えて2バイト対応が必要。

2:表現の修正
 英語が読めなくても操作がわかるように、メニューやヘルプの日本語化、つまり英語で書かれた文章の翻訳と埋め込みが必要。

この2点が必要である。

このなかで、1:処理の修正 は、英語と日本語のコンピュータ上での処理方法がわかり、ソフトウェアの内容自体も理解できるソフトウェア技術者が必要になる。全部できる人が必要。
しかし、2:表現の修正 は翻訳者さえいれば、埋め込みは英語だけわかればこなせる。なので、英語と日本語がわかる人と、英語でソフトウェアがわかる人が一人ずついればいい。ハードルは1よりずっと低い。

初期のソフトウェア製品は、日本市場を攻略するため、1:処理の修正 をこなせる人材を確保する必要があった。それは日本の中に多く存在した。なので、ローカライズ産業としてのソフトウェア産業は日本の中にあった。
英語圏で作られたソフトウェアのソースコードを日本に持ってきて、日本語処理のわかる日本人のソフトウェア技術者が日本語向けの修正に必要な点を抽出し、直す、ということをした。
日本語が処理できるソフトは日本国外にないから、その費用は価格に転嫁できた。
日本語版ソフトが50%高い値段で売られていたとしても、安いからといって英語版ソフトを買う人はいない。日本語が処理できないから。

しかし、2バイトを使う国は、日本だけではなかった。中国、韓国も2バイト必要であった。
日本、中国、韓国の市場を狙うならば、各国固有の2バイト処理を後から入れるより、2バイト処理そのものを、もともとのソフトウェアに埋め込んでおき、必要な点のみ各言語に翻訳すれば、手間が少ない。
なので、1:処理の修正 の作業が共通化できればコスト面でのメリットが大きい。

共通なのであれば、ソフトウェアを最初に作成する時点で2バイトを考慮するのもいいだろう。
そうすれば、英語圏でも日本語圏でも中国語圏でも、そのまま動くソフトウェアになる。

その方法を記した本が英語で出版され、英語圏の中で方法が確立していく…。
さらに、Unicode/UTF8という文字コード国際化の標準仕様ができ、その文字コードを扱えるようにソフトウェアを書けば目的を達することができるようになった。各国向けのローカライズではなくグローバライズだけを考えればいい、ということになった。
その結果、最近のソフトウェアは、ほとんどが国際化対応であり、そういったソフトウェアを作るためのソフトウェアも国際化対応である。

1:処理の修正 は、ほとんどが英語圏で完結するようになった。
英語圏でソフトウェアを開発して、英語圏以外でも動かしたいとしても、ソフトウェア自体の中身を詳しく理解している人は、英語圏にさえいればよい。

あとは2:表現の修正だけすれば、日本語圏でも中国語圏でも、多くの人が利用可能になる。最近は、翻訳はネット上でボランティアを募集してやってもらう、そういうWebアプリケーションもある。
オープンソースソフトウェアにいたってはすべてがボランティア(ないし寄付)だ。

一応、補足すると・・・、
世界中で動くソフトが作れるという恩恵は、日本語圏に対しても等しく降り注いでいる。
その点からすれば英語圏でも日本語圏でも条件は同じといえるかもしれない。
しかし、そこにはネットワーク外部性が働く。
ソフトウェアの多くが英語で生産され、作っている技術者の多くが英語でコミュニケーションをとっている以上、ソフトウェアの理論を学ぶ場としても、そういう人間が集まっている場所であることが、効率的になっていく。
現在、国際化したソフトウェアには、最低限、英語での説明がついている。それがノルウェーで作られようと、ハンガリーで作られようと、インドでつくられようと、日本で作られようと。

「このソフトウェアは世界の多くの人を便利にする力がある。」といっても、その言葉は日本人以外にはほとんど通じない。
"This software can help many people in the world." と、英語で書いてはじめて、国際化対応になる。文法がまちがっていたって、まだましである。「どんなひどい英語でも、日本語よりは通じる。」

英語で書かれた技術情報を、誰かが日本語に訳してくれるのを待つより、自分が英語を学ぶ方が早い、というケースもどんどん増えていくのではないか。
それは、完全な機械翻訳の実用化のスピードよりも、いまのところ早そうに感じる。

統計的に有意な結果を得るために、サンプル数はどれくらい必要か?
というのは、統計学の入門教科書でも、一概に答えは出ない話だ、という。
経験則的には、30くらいあれば、十分ではないか、という話も紹介されている。10では少なすぎるし、30以上は経費の浪費になることが多いんじゃないか。きっちり定義できる話じゃないが、目安として30というのを考えよう、と。

ひるがえって、我々はもっと安易に判断をしているような気がしてならない。
数日間の滞在でたかだか十数人のアメリカ人(しかも彼らも国籍は外国人だったりもする)に会って話をしただけで、「アメリカ人は・・・云々」とかいいたくなってしまう。・・・しかし、それはちょっとサンプル数が少なすぎるんじゃないの?
「日本人は器用だ。緻密だ。頭がいい」とかいう話を聞くと、そりゃちょっと、どうなんだろうかと思う。
「自分は○○が得意だ」なんてのも、意外と少ない回数のラッキーに支えられた成功体験かもしれない。

そんなこといったら、なにもわからないじゃないか、ということになるかもしれないけれど、そうそう、何もわかっていないんだよ。わかってないながらも、情報をかき集めて仮定をおいて、なんとか世界を理解しようとしているんだよ、と。
この点だけは、きっと誰にも共通するんじゃないかと信じたい。

われ思うゆえにわれあり。
あれ、これだって証明できてるようで、できてないのかな。

海外に住んでいる友人の話・・・。
韓国人や中国人はすぐ集まって町をつくるのとは対照的に、
日本人は日本人だけでコミュニティを作るのを避けがち。
・・・という傾向があるかもしれない、とのこと。

せっかく海外に行ったのに日本人がいると萎える気もする。

今、思いつくいろいろな問題を一気に解決できそうな大きな風呂敷を考えてしまうことがある。

大体は、実現までの工数が大きすぎて、一人ではやりきれないとか、一人では時間がかかるとか、一人では能力不足でうまく作れないとか、ほかの人に頼みきれないとか、ほかの人が理解を示さないとか、・・・・なんだかいろいろな理由でだめな感じである。

じゃあ、なにもしないのか。

簡単に(すぐの実行は)あきらめて、アイデアとして脳かメモのどこかの放り込んでおくか。
それとも、着眼対局、着手小局ってことで、小さなことからコツコツとつめていくか。コツコツとアイデアや小道具をためていけば、いずれ大きな実を結ぶことはあるのかもしれない。

なにも考えずに、ブレークスルーにぶつかっても、それがブレークスルーだってことに気がつくためには自分の中で、どこまでができて、どこまでができがたいのか、つまり、どこが壁なのかがわかっていないと。
壁がわかんなきゃ、なにをブレークスルーできるのかわかんないのですよ。

だからきっと、つまらないようにみえることや、とりあえず今日の最短パスとは思えないようなことでも、やっておくかどうか、一人一人の投資判断だと思うけれど、時間がある分はやっておこう。

そういうのは「無駄だ、突っ込みすぎだ。まず必要なことをこなせ。」と思う人もたくさんいるとおもうし、そうでなければ暮らしていけない面もあるかもしれないし、必要なことをこなし続ける先に大きな果実(自分がしたいことですぐにはできなかったこと)に達するということもあるかもしれない(仕事の報酬は仕事)。
そのあたりは投資判断なのだけれど。

けれど、ほかの人に見えていない壁を見つけ、そのブレークスルーを提供できるのなら、自分には商品価値があるということじゃないか。今は結果が出ていなくても、その可能性があるのであれば、潜在的な価値はある。

目の前にはいろんな問題があって、今すぐに自分の力量でこなせるものと、そうでないものがあるのだ。
すぐにこなせないからといって、挑む価値がない問題であるとはいえない。
すぐにこなせるからといって、やる価値が相応にあるとは限らない。

世界はまだ十分に複雑で、人知が及ぶところは小さい。
やってみないとわかんないことのほうが多い。きっと。

- - -

戦術的にはいくつかの選択肢やスキルがある。

大きな問題は小さな問題に分割可能か?
人の役に立つものもあるし、役に立たないものもある。役に立ちそうか?どうして役に立つのか?
役に立ちそうだとして、それを近くの人にプレゼンできるか?プレゼンするための材料は作れそうか?
人を動かせるか?どこまでを自分で準備して、どこから人を巻き込むか?
周りにどういう人がいるか?彼/彼女はどんなスキルがあって、どういう興味を持っていて、どういう時間の使い方なら協力してくれそうか?逆に彼/彼女に対して自分が提供/貢献できるものはどんなものがありそうか?

Amazon.co.jp: 素人のように考え、玄人として実行する—問題解決のメタ技術: 本: 金出 武雄


それは楽しいことか?苦痛だからお金やほかのもので解決することか?
自分にとっては楽しいけど、ほかの人にとっては苦痛なことか?

- - -

ふにゃ~。眠い。
くだらないことを書いてないで掃除しろよ、という気もする。

ぶち先生が久しぶりにガンダムと車以外のことを書いている気がする。

うぇるかむぶちわ?るど!! | 自己批判中

彼らを軍縮させるためには軍事力を持ち、こちらの軍事力も減らすからそっちも減らせという交渉が必要になってくる

この一文から、歴史で習ったロンドン軍縮会議を思い出したんだけど、そういう「俺も減らすからお前も減らせよ」的な軍縮交渉を、しかも中国-日本、北朝鮮-日本、というように2国間の枠組みで少しずつ相互軍縮をしていく、という外交が展開できるだろうか。そういう成功例ってあるの?
冷戦崩壊期の米ソは2国間で核軍縮を進めていた(でもSTARTとかいう条約もあんまし実効性が、あったのかどうか知らない)けれど、むしろこれは核兵器のコスト構造の変化が要因であったんじゃないかと想像する。

そもそも、軍備を減らす余力を確保するためにあらかじめ軍備を増やしておくというスキームがつらそう。これだけ情報が公開されている時代に、軍備を増やせば、それに対応して、軍備を増やさざるをえない別の国が出てくるんじゃないだろうか。「ほら、あっちの国はこれだけ軍備をもっているんだから、うちもこの辺までは増やさないと。」なんて提案を、「そんなん無駄じゃん」と蹴るわけにもいかなくなっちゃう。だから、増やすほうに関しては、「こっちが増えると、あっちも増える」という状態になりがちなんじゃないか。

だから、日本をはじめ各国がとるべき戦略は、「攻め込むとコスト高いよ」というレベルのゾーンディフェンスがどのへんなのかを見極めて、できるだけ最低限を維持する。・・・これしかないんじゃないかと。
相手が合理的経済人じゃないことを仮定に含めるにしても、なおかつそれに対応できるような合理性でもって対処すべきじゃないか。
「GNP1%枠」なんて話が子供のころにはあったような気がするけど、今思えば、割と合理的なんじゃないですかね(景気変動に左右されすぎないようGDPの10年移動平均のx%枠とかがもうちょっと適切かもしれないけれど)。財布(現物)がなければ戦争ができないわけですよ。それでいいじゃん。信用買いの応酬は避けたい。

軍事に関しては、三国志とか大戦略のゲームレベルの知識しかないけど(ミリタリーマニアじゃないですので)、攻めるために必要な費用は、守るために必要な費用の何倍にも上る、というのはきっと現実にも通用する理屈だと想像する。そうなると、多国間の軍事バランスには、割といくつもの均衡点があっても、おかしくないんじゃないか、という気もする。戦争が起こるのって、よっぽど均衡が崩れた時だよね、きっと。読みを誤れば簡単におきるのかもしれないけど、それは軍縮でも軍拡でもおなじことで、増やすにせよ減らすにせよ、適当な範囲というやつがきっとあるんだろうと。

この範囲において、9条改正が必要かというと、必要ないと思う。
紛争地域への派遣とか、広域的なお役目は、どうも避けがたいものがあるようなので、それに対応する改正は、必要?まてよ、それも必要ないんじゃないか。本当は軍を持っちゃいけないんだけど、平和維持活動部隊は持ってますし、銃も撃ちますよ。戦車だって派遣しますよ。でも軍じゃないです。っていうんじゃだめなのでしょうか。
すでに実質的に軍を持っているから違憲状態、じゃあ、軍に合うように憲法変えよう、って、方向的にはちょっと微妙な気がしてきた。
「憲法変わったから今日から軍です。日本を代表する軍なんだから、恥ずかしくないようにそれなりの装備を・・・」なんていう展開が透けて見えなくもないし。

スポーツとかの日本代表と取り違えないほうがいいです。きっと。

昨夜、「朝まで生テレビ」を見ていて特に強く思ったのは、
皮膚感覚レベルで、ホリエモンを受け付けない人がいるらしい、ってことかな。

いつもホリエモン報道を見ていて感じるんですけど、
熱くなりすぎじゃないの?

とりあえずいまのところの罪状は、受け付けない人たちに作られた、
いわば「ホリエモン罪」なんじゃないだろうか。村八分。

- - -

ホリエモンを擁護する気も反対する気もないけれど、
客観的証拠を元に捜査や裁判、そして報道をしてほしいですね。
(あと、もし、「風説の流布」がクロと認定されたしても、それがどれほど大犯罪なのだろう・・・。)

商売には自分達で想定するセグメンテーションというのがあって、
例えば小売業と卸売業には線を引いて違う商売ね、というのがあるわけです。

たまに、ブロックバスターという企業がでてきて、これまでは
別のセグメントの商売だと思っていたところから、
一気に(その分野にとっては)新技術を持ってきて、
市場を再構成してしまいます。

規制があった産業は、規制自体がセグメントを規定していたりするわけですが、
その規制が外される局面でも、どこかの企業がそれをうまく利用してブロックバスターになる、
ってこともあるわけですね。

まんまとブロック破壊されちゃった企業はなにをしてきたのか、バーカ。
ということなわけですが、いやいや、そう簡単にはブロック破壊を止められない
モンだよ、というのが「イノベーションのジレンマ」の議論。
じゃあ、自分でブロック破壊の準備もしとこうよ、というのが「イノベーションへの解」の処方。

じゃあ、なんとなくブロック破壊されそうだな、と思ったときの戦術って、
なにがとれるんでしょうかね。準備してないけど攻められつつあることは認識した場合。

自分は紳士的であり攻めてないのに、相手は理不尽に攻めてくる。
それを認識する感覚って、恐怖と怒りが入り混じる、健康的とはいえない
精神状態だろうなぁ、と想像します。
ここはもう、力勝負でしょうか。スピードにスピードですか。

ちょっと待って、体勢崩れているのに、的はずれな対抗策をドドーンと打って、
自らの終幕を早めるってこともあるじゃない。先に攻められているとわかった
時点で負けがほぼ決まっていたりするかも。後攻めだってことを認知する
時期、彼我の体勢の差によってケースバイケースでしょうけれど。

ヤン・ウェンリーみたいに、負けないように、ごまかしてしまう、なんて
手はないもんでしょうか。体力あるうちに効率的な小規模作戦をどんどん
やって、いつの間にかせこせこ陣地を取っている、みたいな。

「イノベーション・・・に大負けしないようにたまに反撃しつつ上手に退却する戦術」
次はこれじゃないすか。うわ、ニッチ。

昔、勝った経験が、同程度以上の勝利でないと勝った気がしない、という方向に
人間の心理を追いやるとしても。

- - -

というわけで昔読んだ「墨攻」を思い出しました。マンガの方です。
攻められている城に負けない方法を説く「墨家」という学派(?)の人の話。
古代中国(春秋戦国)で諸子百家とかいわれる思想の中のひとつ、って
名前だけ覚えた記憶はあるけど・・・(老子荘子よりマイナーだよな)。
[Amazon] 墨攻 (1) 小学館文庫

そういや酒見賢一の原作小説を読んでいないことに気づきました。読んでみようかなぁ。
「後宮小説」の人ですよね。これのアニメ化版はすごく爽快感ありました。

[Amazon] 雲のように風のように :DVD

今週は、昨年作ったシンプルなアプリを改修。
よりユーザにとってシンプルにするための改修。
結果としてソースコードも短くなった。自分で書いたフレームワークとの共用度が高まったもんで。

ソースを見直して短くする、というのは、なんか頭がよりスマートに進歩したようで、
うまくいくと、うれしいたのしい大好き、状態ですね。

月曜日にオファー貰ってから、4回サンプルを改善しながら作ったので、あれ、気づけば1週間、こればっかりやってしまったかも。
(そういえば、さっき、ひとつ改善点に気がついたので、週明けにこそっと入れてみよう。うふふ。)

便利に使ってもらえることを祈るばかりです。

- - -

mixiの知人の日記で知った適職診断やってみました。

ニュートラ適職診断
 http://www.neutra.go.jp/diagnosis/

私のニュートラ適職診断結果
 http://www.neutra.go.jp/diagnosis/result02.html

勝手に要約すると「自分がリーダーじゃないと我慢できんなお前は。さっさと独立しろ。でも組織にいるなら我慢してしばらく学べ。その際はストレス発散心がけよ。いいか、すぐ嫌になって、ころころ仕事を変えるのはやめとけ。」
・・・ううむ、攻め5:守り1って、ビッテンフェルトですか私は。基本的には社会適応能力なしですか・・・・。

先人の教えを自分なりに書き出したメモです。
こっぱずかしいですが、自分用に置いておきます。

- - -

物事がうまくいかない理由について。

 ・こうなって欲しい、という未来を、妄想だと考える。
 ・思いつきと、ひらめきは違うものだと考え、思いつきに賭けない。
 ・思いつきを、現実に結びつけるための技術が足りない
 ・技術の足りなさを補うための試行錯誤ができない
 ・失敗のリスクを負って試行錯誤する胆力がない
 ・中間ゴールを設定できない。
 ・ほかに頼める人がいないのに、これは自分の仕事じゃない、と考える。
 ・これまでの試行錯誤結果を蓄積していない
 ・あるべき手順、スケジュール(予定)を考えすぎる(それこそ妄想)
 ・やれることを、すぐやらない。
 ・途中であきらめる
 ・ほかにもっとやらなければならない仕事があり、
  こんなことをやっている暇はない、と言い訳して逃げる。

すごく端的にすると「思考停止とチキンはだめよ」ってことになるかな。うわ厳しい。


[参考文献]
 ・kawaguti's chronical record: 書評: 素人のように考え、玄人として実行する—問題解決のメタ技術
 ・Life is beautiful: リーダーシップについて思い出したこと
 ・kawaguti's chronical record: 石井裕さんの講演

区切り文字を英語でなんて表現するほうが適切かということに悩んでみたりします。
デリミタ(delimiter)なのかセパレータ(separator)なのか。

 <array separator=",">aaaa,aaaa,aaaa</array>
とするか
 <array delimiter=",">aaaa,aaaa,aaaa</array>
とするか、どっちが気持ちいいかなってなもんで。
まあ、たぶん、どっちでもよさそうな感じがします。

私は一般的な用語っぽい感じのセパレータ(separator)を使いたいですが、
データの区切り文字はデリミタでしょ、っていうのがなんとなく業界的に通りがよさそうで間違いがなさそう※な気もする。

で、Wikipediaでは、
 http://en.wikipedia.org/wiki/Delimiter
CSVのカンマはDelimiterだとしている。

CSV:Comma-separated values と書きながら、commaは、Delimiterだとしている。(separateしているのはseparatorじゃないのか。)

うーん、そんなもんかなぁ。
まあ、そんなもんなんでしょう。

- - -

※separateという表現はdelimitより、よく使われるみたいなので、delimiterとした方が、検索しやすいかも?(学術用語を一般用語と分ける立場みたいな感じ。)
・・・なんてことを、思いましたが、こういう立場あんまり好きじゃないんですよね。

日経ビジネスで特集になったので、ことさらそう思うのかもしれませんが、
学力低下、NEETの次は、「縮む」(労働力不足)ですね。

就職倍率がバブル期を越えたのが決定的みたいです。
えーなー、団塊ジュニア世代の終わりの方の人間としては、うらやましい限り。

一方、アメリカの景気はほとんど金融が支えつつあるみたいで、そろそろやばさが増してきている感じ?日本も退職金景気が始まりそうですが、金融が経済を支えるっていうのも、ちょっと蜃気楼っぽい気がするのは、産業立国に育ったからでしょうか。

- - -

堺屋太一氏が「団塊世代は、従順で勤勉な、戦後教育の理想像」と(皮肉的に)書いていました。
この世代は人数こそ多くても、有力な政治家や起業家が少ないのだとか。

ふーん、そんなもんかねー、と。

団塊ジュニアはどうでしょうね。ITのおかげでホリエモンさんとか藤田(サイバーエージェント社長)さんとか、ちょっとは思い浮かぶ人もいますが、同業種でいっても、やっぱり世代の違う孫正義さんとか三木谷さんとかの方が、すごそうに見えます。
マスコミの伝え方に起因しているだけのような気もしますし、団塊世代/団塊ジュニア世代をスタッフとして使える団塊谷間世代の方が経営者として成功しやすい、なんて世代の有利不利がちょっとくらいはあるのかもしれないなぁ、とも考えてみたり。

いや、まあ、こんなことを考えても詮無きことですが、ちょっとふらりと考えてみたりするわけです。

#GoogleのPageとBrinも日本でいえば、団塊ジュニア世代。なんすけどね。

- - -

ところで、出生率が一向に上がらないってことは、団塊ジュニアジュニア世代は出現しそうにないですな。

Blogやソーシャルメディア、Wikiなどの最近のサービスの面白いところは、
幅広い"発信"を引き出しているところだと思います。

あやふやな事を書きます。しばし、お許しください・・・。

"デジタルな情報"というのは、自然発生的に生えてくるわけではない、
のです。だれか、なにかが、アナログの情報を切り取って、
デジタルに変換しなければ発生しないんです。

それは、電子メディアに物を書くとか、資料をEXCELで作るとか、
Webページを作るとか、携帯メールを打つとか、音楽CDを
レコーディングするとか、映画DVDを作るとか、
そういった作業が必要なわけです。

そういう作業が発生するには、そこに至るモチベーション、
作業を乗り越える、何かが必要なわけで。

で、どんどん乗り越えるためには2つのことがあるわけです。
-乗り越える力を集める。
 たとえば、商業的に成り立つモデルを考えて、人,モノ,カネを
 集める。
-壁を低くする。
 作業自体を省力化し、楽しみをちりばめて、潜在的な「やりた
 い人」の意欲を引きだす。

で、Blogやソーシャルメディアが後者なのかな、と。
さらに、タンジブルビットも後者の取り組みなんだろうな、と。

・・・変なまとめ方・・・。

- - -

ITmediaニュース:目指すは「ライタブルWeb」——DEMOで披露されたソーシャルメディアの数々

カリフォルニア州パロアルトの新興企業、JotSpotは、Wikiに懸けている。Wikiは、誰でも編集に参加できる形のWebページ。

 Wikiは今後、情報分類のための中間準備地点となっていく可能性がある。JotSpotの新しいWebサービスは、認定ユーザーに共同作業用の共有領域を与えたいと考える企業をターゲットとしている。


GoogleのGFSの話を書き(引用し/リンクし)ましたけど、
ある会社が、サーチエンジンを作ってサービスしようと考えたときに、
はてしてGFSのようなアプローチをとるだろうか、ということを
考えることがたまにあります。

現在の市場で新たな検索エンジンが売れるかどうかという点は、
ちょっと抜きにして、仮に、独自の新分野で一定のニーズがある検索エンジン
分野があったとして、そこに向けた検索エンジンを作ろう、となった場合に、
どうするか、です。

今のところの答えは、
「たとえGoogleが成功したことを知っていたとしても、
 そんな不確実な方法は、なかなか、とれない。」
です。

以下、題材として、サーバの堅牢製と拡張性に絞って考えます。
(Googleはもっといろいろな要因に優位性を持っていると思いますが。とりあえず。)

堅牢性と拡張性を手っ取り早く、(運用者にも)わかりやすく実現しようと思ったら、
やっぱり堅牢製をウリにしている高価なサーバを導入し、
きっちりメーカーやSIerのサポートをつけ、運用手順をはっきりさせて、
状況を固めたくなる、と思います。

非常にアバウトですが、特に技術セントリックな会社でない場合には、
やっぱりビジネス優先であり、技術は確実性を得たいので、
こういう方策になりがちなんじゃないでしょうか。
(それがいいとか悪いとかは、申しておりません。
 合理的な判断がなされた場合に、こういう方向になるケースが
 多いんじゃないかと推測するのみです。)

- - -

このパターンは、Google型に比べて、2つの短所がありそうな感じがします。
1.コスト
初期費用がおそらく高い(技術料、中間マージン分)。
継続的にコストを下げることが、難しい(かもしれない)。
コストが下げづらいということは、世の中一般的にコストが下がっているトレンドでは大きな障壁。

具体的には知りませんが、堅牢性をアピールして売ってる会社は、堅牢性のランクに従って価格付けをするんじゃないでしょうか。技術の陳腐化や新技術に伴うコストダウンはあるにしても、それを超えるコストダウンは、何らかの需給要因(先に別の利得があるとか、トップ企業に食い込んで競争優位にたつためとか)が作用する場合を除くと、やっぱりサービスレベルの低下につながるように値付けされてたりしないでしょうか。(ちょっと根拠ない想像なんですけど。)

2.変化への対応
ガチガチに固めることで堅牢性を作るとすれば、それは、変化したいときには
堅牢性に危機が迫るということ。
変化を重ねると、(一般的には)より複雑性が増し、状況の捕捉が難しくなるため、
次第に、変化に関して、コストと時間がかかるようになります。

- - -

そんな欠点があるっていっても、やっぱりサービス開始時期/納期は
ある程度、決まっているわけで、これらの欠点要因を最小限に押さえつつ、
堅牢でビジネス要望を満たすシステムを、時間内にきっちり作るというのが、
やっぱり求められていることでして。

そういうことを効率的に達成するのが「よいアーキテクト」ということになるのでしょう。
システムの技術的なマネジメント、ということよりも、メーカ/SIerの
マネジメントが長けてないと、そういう人にはなれない感じがします。
(よいアーキテクトは、気心の知れ、計算できるメーカー/SIerを
持っている人、ということになるのかな。)

先生、結局、よくわかりません。

Sotto Voce で、Stanfordで講演したAmazonのジェフ・ベゾスCEOの講演内容が紹介されています。

村山さんのまとめ自体がとても勉強になります。。。

Sotto Voce: Conversations Without Boundaries: Jeff Bezos' Speech

講演の過程で出て来たキーフレーズ、そしてそれに対する自分の理解を列挙すれば:

少人数のチームがその限られた権限・資源でできるような細かな実験を数多く繰り返し、その効果を具体的に測定しながら良いものは残し、ダメなものはすぐやめるという漸進的な製品・サービス開発こそがアマゾンにおけるイノベーションの鍵である

イノベーターは人と違う事を行っているからこそイノベーションを起こせるのであり、人と違っている事をやれば外野の雑音は大きくなるのは当たり前のことだが、顧客に良いものを提供できるという自信があるのならば外野の声には惑わされることなく自分の立てた戦略を追求せよ、ということ。

(バスに乗りながらボーっと考えたことのメモ。
 たぶん疲れているので無視してください。)

みんなが合理的に、リスクをとらなきゃ、と思うタイミングでは、誰が見てもヤバい状態。サッカーで言えば、後半になって相手に先取点を取られたような感じ。

じゃあ、その前段階では、リスクをとって攻めるという判断は、皆が合理的であるほど難しい。それよりも確実に勝つ(負けない)方法をすすめていく。

というのが、イノベーションのジレンマの根底にある人間の動き。

- - -

でも、じゃあ全員で攻めないまでも、フォワードくらいは危険な動きをしておこうよ。
全体のバランスには影響を及ぼさない程度の、小さな萌芽をきちんと育てておこう。

というのが、イノベーションの解。

- - -

難しいのは実行。

クールでクレバーな人が明確な分業・方向性・権限・予算の元に、リスクをとる危険な動きをするのであればよいが、単にリスク認識力のない冒険家や、技を出し続けているというアピールが目的のスタンドプレーヤーが、実のない投資を積み重ねても、効率は悪くなってしまう・・・。(それじゃ、やっていないのと同じ。)

絶対に獲るんだという強い意志、集中。
不利な局面での冷静な判断力。チャンスでの果敢なアタック。
昔からフォワードには、「日本人離れ」した感じが求められる。

- - -

世の中、サッカーみたいなものだなあ。


#日本代表の初戦勝利ヤッター。
次は、アウェーのイラン戦。イランは10万人規模のスタジアム(アジアチャンピオンズリーグ決勝でジュビロがやったところなら)。2度とできないようなアウェーの感覚。
それでも何とか勝ち点を獲って帰ってこれればものすごく自信になりますね。

GoogleがMozillaの人を次々雇っている話。
Firefox開発者、またグーグルへ--真実味を増す独自ブラウザの噂 - CNET Japan

まあ、Googleのリソースとthe best & the brightestな人々と一緒に仕事できたらいいナァ、と思ってGoogleに応募するというのは、まあ、ありがちなことな気がします。で、履歴書に当然Mozillaと書くでしょうから、まあ採用も通りやすそうな感じもします(もちろん優秀な人々でしょうし)。
だから、「Googleがブラウザを」というレベルの作為ではなく、自然な成り行き、というのもあるんでしょう。

- - -

まあ、それはそれとして、Googleがブラウザっぽいものを作るとしたらどういうものを作るのか、というのを妄想してみるのも面白いわけで。

- - -

-それはもうブラウザとは表現できない一種のOSみたいなものになるんじゃなかろうか。
-まあ、IEもIE上でActiveXが動くとブラウザなんだかEXEなのかあんまし関係ですし・・・。
-でも、計算機言語の実行系を作る、という話とはまた違う切り口なのかな。
-かといって、Flashのように非言語でのオーサリング環境(言語もありますが)というのも、どうだろう。ちょっと違う気がする。

Blog/Newsとビデオ/Flashをピュアに表現でき、ネットにシームレスにつながって、自分で情報を拡張できるクライアントアプリ。

なんだそれ・・・。
貧困な想像力。
ちっぽけな自分に乾杯。

どうも素性をきちんと書かないブログで、世の中のメインストリートにコメントをつけるのは気が引けてしまうのでトラバしませんが。。。

Log the Endless World: ユーザー・エクスペリエンス

私の現状認識(かなり推測)を、ちょっと書いておきます。

企業によって温度差があるとは思いますが、もしかすると大勢としては、
「使いやすいものを作るのはあたりまえ」だという認識があるのかもしれません。
じゃあ、どういうのが誰にとって使いやすいのか、を掘り下げて確認していく作業が
ユーザ・エクスペリエンスの改善と言うことなのだと思いますけれど・・・。

1.費用効果の算定
 ニールセンのAlertBoxでもよく、「テストの効用は○○ドル」といった、
 かなり突っ込んだ効果のアピールが目に付きますが、それだけ説明に苦慮している
 ともとれます。
 Appleのような、マーケティングが、それをブランディングの一部に取り込んで、
 費用以上の効果、実際のエクスペリエンス向上結果以上の効果を引き出すことに
 成功している、そういう一部の企業は別として、一般の企業が、
 (思想としてだけではなく実際の試みとして)ユーザ・エクスペリエンス向上を
 追求する場合に、投資に見合った成果が得られるか、という点は、
 常に、明確に答えを出していかないといけないんだろうなあ、と思います。

2.テスト/修正方法の確立
 一般に実現可能な方法論としてまとめ、広めていく必要があるだろう、と。
 専門家サイドではいろいろ活動されていると思いますが。
 ・・・むしろ社会的なプロパガンダが必要かもしれません。
   そういう意味では黒須先生
   ISO等の活動はキーとなるんじゃないかなぁ、と勝手に想像しています。

- - -

ソフトウェア開発の世界でも、「バグが無いのがあたりまえ」と言ってしまえば、
その一言に尽きるのですが(^^;)、費用効果の算定と、テスト/デバッグ方法の
確立があってあってはじめて、バグ排除の取り組みにつながる、と。

ドラクエのエンドロールを見ていて、
QAというカテゴリに非常に多くの人が出てくるのに
見入ってしまいました。

QAというのは、品質保証(Quality Assurance)です。
バグや不都合点を見つける人/作業 という感じ・・・ですよね。
昔で言えば、テスターとか、デバッグ(バグを見つける作業も含め)とか
言われていた人たち/作業になると思います。

ドラクエ8のエンドロール中には40人くらい?でしょうかね。
(かぞえてませんでした。もう一回見るのもの大変なのでやりません。)
最後に「... and all QA Staff」というような表記も見えましたので、
テンポラリの人はもっとたくさんいるのかもしれません。

このように多くのQA Staffに見守られて、
質の高いドラクエ8は生産されているのですね。

- - -

マーケティングスタッフもエンドロールに入っていました。
映画だと、広告のスタッフが入っていたりします。
そういう流れでしょうか。

消費者に届ける作業も含めて、製品なんだぞ、と。
そういうメッセージかナァ、とも思いました。

スタッフロールも、時につれ変化しているんでしょうね。
(と漠然としたつまらない結びを書いて逃げます。)

#昔、Macで特定の動作をすると、スタッフロールが出てくる
 公知の裏技がありましたが(いまもあるのかな?)。
 あれは開発スタッフだけだったような気がする。

人づてに小耳にはさんだ話しで、こんなのがありました。
「ユニバーサルデザインとは、すべての人が同じ道具を使うこと」
・・・ええーっ?!


ユニバーサルデザインとは、
「なるべく多くの人に使いやすい道具を作ること」
ないし、
「ある一定の人にとって、とても使いづらかった道具の欠点を
解消していこう、という運動」
だと認識します。

そういう意味では、「すべての人が同じ道具を使うこと」が
意味するところの、すべての人が同じ規格の道具を使う
ユニフォーム的なアプローチは、まったく対極だと思います。

うーむ。こんな誤用がどうして生まれるのでしょうか。
理解できないなぁ、と思っていたのですが、ひとつの仮説を思いつきました。


- - -

命題A:「ユニバーサルデザインとは、なるべく多くの人に使いやすい道具を作ること」
命題X:「ユニバーサルデザインとは、すべての人が同じ道具を使うこと」
とします。

これから3つの展開を入れて、命題Aを命題Xにつなげていきます。
もし漠然とした「道具」だとイメージしづらいならば、
「ハサミ」「マウス」「車」「机/椅子」あたりをあてはめて考えてみていただければ、と。


[マーケティング的 論理展開1]
命題Aの目指すところを突き詰めると、実はひとつの道具で誰にでも使いやすい
ものができてしまうかもしれない。
もしできるのであればすべての人にとって素晴らしいことです。

しかも、工業製品としても、1種類でよいならば最も量産効果が得られます。
よし、商売としては、これを目指そう。という展開が出てくるのかも。

命題B:「ユニバーサルデザインの結果、すべての人に使いやすい道具ができる」


[マーケティング的 論理展開2]
売りたい製品があって、これがユニバーサルデザインを考慮した製品だと
いうことに(社内的には)なっている場合、
それはすなわち命題Bをクリアできる製品、ととらえると、
一種類ですべての要求胃を満たせるんだから、どんな場合にも自信を持って
この製品をあてはめて問題ない、ということになります。

命題C:「ユニバーサルデザインの道具を利用すれば、一種類の道具に統一できる」


[マーケティング的 論理展開3]
命題Cでもってセールスされた人、それなりの企業であれば購買担当者などが
あたるのでしょう。彼らはさらに社内に対してマーケティングをする必要があります。
費用は安い方がいいが、不満/問題が出る製品は導入しない。

しかし、命題Cが満たせる製品であれば、多少高くてもメリットがあります。
価格が高い部分のプレミアム分は、
-一種類に統一することで、その後のメンテナンス費用の低減につながる
-「使いやすいから高い。」これは説明しやすい。
ということで納得します。

さらに、できるだけメリットを得られるように、この製品に統一したいですよ。
命題Cをクリアする製品なんだから、それも可能だということになっちゃいますね。

命題X:「ユニバーサルデザインとは、すべての人が同じ道具を使うこと」


…というわけで、命題Aから命題Xにつながりました。

- - -

いかがでしょう?

それぞれの人がちょっとだけ自分の思惑を入れて解釈をすることで、
伝言ゲームの結果、まったく正反対の理解が得られてしまうことも、
もしかしたらあるのかナァ、という想像に基づいた仮説です。

こういうことは、世の中的には、広く発生してしまっているんでしょうかねぇ?

「北陸新幹線」という計画があります。
東京~長野はすでに長野新幹線として営業中。
長野~富山間は着工済みで、今、建設中。
富山~金沢間は来年度着工の認可が下りそうな雰囲気。

ウチは富山に親戚を持ちますので、東京からの足が便利になることはかなり歓迎なんですね。東京から富山まで2時間ちょっと。ウチからだと飛行機に乗るのと変わらない所要時間になります。

現行の越後湯沢~富山間の特急「はくたか」は、混んでいて指定席が取りづらいくらいだし、飛行機も満席が多いので、新幹線ができればそれなりに乗る人はいるんだろうなと想像しつつ。

この北陸新幹線にオフィシャルサイトというのがあります。

私たちの心を癒す新幹線


北陸新幹線沿線には東海道新幹線沿線に匹敵するほどの人々が生活しており、

そりゃずいぶん人口が多いナァ。4000万人も住んでるんですね。
と思ったら、ほかの新幹線とかぶる地域(埼玉、群馬、京都、大阪)の人口が計算に入ってます(^^;)。ここを除くと、1000万人を割ってしまう・・・。

人口から採算性をだすとつらいなぁ。

#「はくたか」が走る北越急行ほくほく線(越後湯沢~直江津の一部・第3セクター・スーパー特急規格)が、北陸新幹線開業までに償還できるのでしょうかね??

独りごとです。

-「さっさと自分でやったほうが早いわぁ」と叫びたくなるが・・・、そういうのは子供の台詞かなあ、と思い、引き下がってみる。

-事前にもうちょっと調べといてくれれば、実のあるミーティングになったかもしれない。・・・というようなことは言わないでおく。

はぁ・・・。
人生そんなに長くもなかろうに、何やってんだろうな、私は。

CNET Japan Blog - 梅田望夫・英語で読むITトレンド:ゲーマー世代の若者といかに付き合うか

以前も本欄でネット世代論については書いたけれど、「証明せよ」と言われれば困るが、僕もsameoと同じく、1970年生まれ前後のあたりに、何か明らかな分水嶺があるように感じている。ちなみに、Google創業者の二人は1973年生まれ。sameoの議論をあてはめれば、「Mosaicがネットで公開された1993年」、彼らは20歳の学生であった。

という分類が成立するとなると私は72年なので若い方の世代(インターネット世代)ってことになります。

自分の未成年時代の時代背景としては・・・
-小学生時代にファミコンが普及した
-中学生くらいになると結構周りがパソコンを持ち始めていた(X1/MZシリーズ/PC-88/MSX) ・・・ ただし私はナイコンでしたけど。
-大学生時代にはNIFTY全盛、その後インターネット(Mosaic/Netscape)
というあたりが思いつきます。

すでにその頃社会に出て、商材として情報・通信・コンピュータを扱っていた人に
比べると、ホビーっぽい感覚があるのかもしれません。
(もちろん、上の世代の人でもホビーっぽい人はたくさんいるのですが。)

ホビーっぽいっていうのは、
-ソフトは基本的には誰でも組めるものだと思っている(少なくともHTMLくらいは)
-自分が使うツールを作るためにプログラミング作業をする
-すばらしいソフトは、大変に価値があると思う。特にプログラマブルなやつがいい。
という感じでしょうか(我ながら、なんか狭いな)。

私がインターネット世代かっていうと怪しいものですが・・・。

- - -

追伸: 梅田さんは、2つの世代に分けた上で、若い方(インターネット世代)に
属する読者に対して、何か、こう、けしかけるような、駆り立てるような文章を
意図的に書いているような感じですね。ホラホラがんばれよってことかな。

追伸2: 同世代の人、こういうの経験してません?
-パソコンは価値があるものだと思っている。でも具体的に何に使えるのかと人に聞かれて回答に窮した経験がある・・・。

風邪って、似たような症状のやつが職場で蔓延したりしません?

道具眼日誌:古田-私的記録: 風邪

によると、どうも空気感染じゃないようですが、
長いこと職場で一緒にいるわけですから、意外と、空気以外のものが接触しているものなのかもしれませんね。ちょっとキモチワルイですけど。

共有PCのキーボード、マウス、紙ベースの配布資料とか、究極はドアノブ。
まあ、仕事していれば経路はいろいろありそうですし。

こまめに手を洗うことが意外と効くんでしょうね。

ところで、保育園ではあっという間に広がりますね。これは接触感染という線で納得できます。器具は毎日、きちんと消毒されているのですが、それでも幼児同士の接触は避けられません・・・。

製品を作ることは一種のディーリングみたいなものかな、と。

tech_portofolio.png

技術屋は出来ることを増やし、
営業屋はニーズのなかで実現出来そうなことを探す。

効率を考えれば・・・、
-技術屋は一般的に収束思考(縦が伸びる)になります。
物を作るんだから、とにかく何かを完成させなければならない。
-営業屋は発散思考(横が伸びる)になります。
いろいろなニーズのいろいろな実現方法を
どんどん考え、マッチしそうな技術を探索していかないといけないい。

しかし、技術屋が収束ばっかりしていると、
ある技術ばかり高まって、裾野が広がらなくなってしまい、非効率に陥ります。
営業屋も発散ばかりでなく、技術の理解を深めていかないと、
必要な技術をいち早く捉えることが出来なくなります。

ディーリングなので、相手の意識を読む鍛錬も必要。
という感じで、オチはつきましたでしょうか?

いいアイデア…、
自分の手の届く範囲で多少の努力だとか説得をすると、
なんかいろいろ、うまくいくような案
…を思いつくこと、ってありますよね。

いろいろな利害関係者が喜び、
何かのプロセスが効率化し、
利益/付加価値が発生し、
かつ将来への布石になったりする、とか。

思いつくと、すごい楽しいんだけど、
そういうときに限って先走ってしまって、
結局、思ったような効果を発生できずに失敗。
…ってこと、よくあるような気がします。

でも、そのリスクを乗り越えないと、リターンは
得られないってことかなぁ。

まあ、ダメでも、きっと何か実になっているさ。

たまに猛烈に思うんですけど、
私、キータッチが遅いんですわ。困ったことに。
タッチタイプできないし。

TOEFLで不利だっていうから、よっしゃこの機にと思って
練習した結果、英語は正しいホームポジションに
のっとったタッチタイプが少しできるようになったん
だけど…。

やっぱり日本語は、キーボード見ながら変な打ち方を
してます。
正しいポジションだと、"A"のキーを左手の小指で
打たなきゃいけなくて、疲れるんだよね。

仕事の生産性を落としてるんだろうなー、と思いつつ。
やっぱりあんまり本気に取り組んでない自分がいる…。

今年、ノースウエスト航空のマイル会員になりました。
(ここのマイレージプログラム、結構、有名らしいですね。
 海外にほとんど行かなかった私は今年初めて知った次第。)

なんだか今年は機会があって、2回も米国本土に行った
結果、あと少し貯めるとで、一番下のクラスですけど
「エリート会員」という特典つきの会員になれるみたいです。

ここで悩み(誘惑)が発生…。
最も近い韓国往復で、必要なマイル数がクリアできる。
今年中に行っとくか…韓国。
でも、そんなに会員資格がほしいかなぁ?
来年、エリート会員期間中に旅行、行けるかなぁ?
悩んでいるうちに今年が終わってしまいそう…。

ノースウエスト航空(日本語)
http://www.nwa.com/jp/jp/

JTB格安航空券
http://www.jtb.co.jp/fit/

HIS格安航空券
http://www.his-j.com/tyo/air/index.htm

#友達紹介キャンペーン中は、結構なマイル数もらえるみたいなので、気になったら声をかけてください。ぜひ。

日本企業って、あまりに属人性を排除しすぎてるのかも。

企業ホームページに登場する経営陣の名前や、
経歴、写真、コメントなどが、米国企業に比べて
圧倒的に少ない気がする。

もちろん、社員も社外で闊達に発言するような
気風が少ないんじゃないかな。

社外で闊達に発言すれば、その企業の知名度や
社会的地位も向上しそうなものなのに。
このご時世、
売上や利益率向上よりも手っ取り早いかも?!
下手にCMうつより、全然安いかも?!

と思いつつ、自分は何もしてませんけど…。

- - -

訴訟が未発達で、なにか問題が発生した場合に、
個人(経営や社員)と企業間の問題の調整(第3者を交えて)が
あまりうまく働く気がしない、というのも障壁なのかなぁ。

経営の人も「ただでさえ日本の役員報酬は安いのに、
有名税まで払ってられるか!」という感覚もありますよね。
そりゃごもっとも。

- - -

ところで英語で「訴えてやる!」は、I'll sue you.
sueですよ。sue。短い!

アリーmyラブ 第1話 冒頭で出てきます。
主人公のアリーは弁護士なんですけど、プロローグで
いきなり同僚に訴えられます。

そこではじめてこの表現に出会った私。
最初は英語音声+日本語字幕でみてて、
どこに「訴える」という単語が入っているのか
ちっとも聞き取れなかったんです。
英語字幕に切り替えて、sueを辞書で調べて、判明。
DVDは偉大です。

英語の再勉強を始めたのは一昨年の暮れなので、
sueを知ったのもそう昔の話じゃないです。
20年前にDVDやインターネットが普及してれば、
もっとラクできたのに。と思うことしばしば。

- - -

[かわぐちの日記]成果帰属の壁
http://www.do-gugan.com/~kawaguti/archives/2004/07/post_6.html

[道具眼Blog]勝手ユーザビリティ改善提案を阻む“壁”
http://www.do-gugan.com/blog/archives/000125.html

[道具眼Blog]勝手ユーザビリティ改善提案を阻む“壁”
http://www.do-gugan.com/blog/archives/000125.html

>>世の中、「バカの壁」ならぬ「成果帰属の壁」みた
>>いなものが立ちはだかってますね。

なるほど。「成果帰属の壁」ね。

著作権というのは、
「ものを作った人がそれで適切なリターンを得ようという行動」を阻止しようというトライを抑止することで、
ものを作るという人類に必要な行為をサポートしよう、ということだと思います。
これが一つの成果帰属の壁になりそう。

また、保証だとかオーソライゼイション。
うまく動くかわからない、誰が作ったかわからない、
よりも、そうでないものの方が嬉しい。
保証されないものなんて仕事で使えるか!
という考え方が、また一つの成果帰属の壁になりそう。
この壁は、保証済みのものだけを使って、保証済みの
ものを作る。という健全性維持の欲求によって、連鎖
を作りますね。生態系っていうか。

GNU GPLはこの連鎖を逆手にとって、
壁のないオープンソースを連鎖させることで、
成果帰属の壁に対して十分に生き残れる、
別の生態系を作ったってことが言えるのかも。

な~んてね。

[slashdot.jp]まつもとゆきひろ 答える
http://slashdot.jp/article.pl?sid=03/03/14/0258247

昨日の日記エントリで話題になったRuby作者matz氏へのインタビュー。
かっこいいなぁ。

>>先程も述べた通り、ほとんどの人にとって言語って
>>いうのは単なる道具なんで、あらゆるパラダイムや
>>スタイルに対応しようという試みは単純にナンセン
>>スです。できるならやればいいけど、無理してまで
>>やることじゃない。私は新しいプログラミングパラ
>>ダイムの将来について悲観的なので、Rubyは広く使
>>われているような近い将来にそのような「Rubyで対
>>応しきれないパラダイム/スタイルが主流になる」
>>とは思っていないのですが、仮にそのような事態に
>>なったとしても、それはRubyでない別の言語がカバ
>>ーすべきではないかと考えます。そのような時代に
>>はRubyは流行遅れになるとは思いますが、たぶん
>>そうなっても私は(まだ生きているならば)Linux
>>20.4.2 あたりでRubyを使っているでしょう。
>>私は今Rubyを使ってハッピーなので、そのような
>>時代にあっても今Rubyを使っているようなタスクを
>>解決するためにはRubyでハッピーなのではないかと
>>思うのです。

すばらしい時代感です。
そうなんだよなぁ。
そろそろそういう時代なんじゃないかと思います。

私は、いまだにActivePerl5.005を使ってますけど、
それでできる世界についてはそれで十分なんだよなぁ。

一般的な商用ソフトだと「サポート有効期限」に
ひきづられたり「バージョンアップ売上」のために
強制的にバージョンアップさせられたり、まあ面倒
くさいことがあるわけですけど。

どうも気がつくと、「進化が止まると死ぬ」的な
思考停止をやっているような気もするので、
ふと立ち止まって考えることは必要かな。

一年以上前のエントリなんですが、
今日、別件のサーチをしていて、偶然みつけました。
前にも読んだ気がする。

梅田望夫・英語で読むITトレンド
日本人エンジニア、一万人移住計画
2003年05月30日 10:00
http://blog.japan.cnet.com/umeda/archives/000377.html

>>すごくシンプルな言い方をすれば、技術系大学院に進んで
>>専門を極めてPh.Dを取って、というような指向性を持つ人
>>が「第一の道」タイプで、MBAをとって幅広く勉強して、
>>という指向性を持つ人が「第二の道」タイプの人である。

自分に当てはめてみると、
「第一の道」ではない、
だろうなと思う。

修士課程には進んだものの、ちょっと博士まで自分が
保つ感じがしなかったので、ギリギリで修士を出て
就職。以後はアカデミックな活動はしてない。

特に、論文を書くってのが苦手で…。
変に自分の成果を高望みしてしまうために、
結果を出す直前で怖くなる。ダメダメっす。
(家を出られないヒッキー、に近い感覚かも。)

…いきなり、カミングアウトしてどうする(^^;)。

どっちかっていうと幅広く勉強するタイプだとは思う。
「第二の道」ほど突き詰めてないけど、
知ることが好きだし、知ることによって、いままで
話せなかったような人と話が通じるようになるのも
嬉しいと感じる。

まあ、強いて言えば「第二の道」に近いってことにしよう。

- - -

>>しかし「第二の道」タイプの人にとっての…
(中略)
>>「第一の道」タイプと違って、こちらのタイプの人は、
>>常に面白い仕事、面白い場所を探している。でも何だか
>>目移りしているうちに、年だけ取っていくというリスクが
>>ある。「第二の道」タイプの人は、コツコツと1つのことを
>>やり続けないから、下手をすると何のスキルも磨かれずに
>>歳月を送るリスクがある。

あ痛タタタタ。
器用貧乏だ。
私も、年だけとってしまったなぁ~。

…と中途半端な自分を反省させてくれるエントリでした。

「イノベーションへの解」によれば…、
 優れた製品とは、
 使用者の用事をよりよく片付けることができる製品
であるらしい(文章はテキトー)。

実際に用事を"片付けさせてもらえる"製品ってのが、
世の中の製品の数よりも希少であれば、
もっともうまく片付けるものだけが残る。
ユーザもまた経済学でいうところの希少財。

そのなかで、
用事と製品をユーザに認識させる方法を研究するのが
マーケティング研究。
もっともうまく片付ける方法を探求するのが、
ユーザビリティ研究とか、ソフトウェア開発とか、
ものづくり一般(と括っていいのか?)。

…オチありません。

- - -

何の役に立つか実際はわかっていないんだけど、
漠然と役に立ちそうな感じの技術発表、増えてきてませんか。
バブル期、再来でしょうか。
気のせいかなぁ。

一歩引いてみる。
書き出してみる。
要求を洗い出す。思い出す。
逆を考える。
元の発想をたどる。

そんな感じで、整理して考えてみる。

お茶を飲む。
首を視点に頭を回す。
頭を指でもみまくる。
深呼吸。
お茶を飲む。
トイレに行く(大)。
歩く。歩く。

そんな感じで、リラックスして考えてみる。

帰る。
風呂に入る。
寝る。

そんな感じで、一度、忘れてから考え直す。

きちんとやりだすとキリがない。

そもそも、「きちんと」というのが曖昧な基準。
きちんとやった結果、何が改善するのか。
…順序をひっくり返して…
何を改善するために、何をきちんとするのか。

・利益率の改善、コスト削減(return)
・堅牢性、継続性(risk)

これができるならば、
「きちんと」やらない効果とリスクも把握できる。
効率的に手順を飛ばすことができるかもしれない。

常に「きちんと」するのが企業価値につながるとは
限らないでしょ。

そういう風に疑問を持つことは、
大事じゃないかと思ったりする。

学生の頃、親のすねをかじって、約3年間、
スズキのジムニーというジープのような形の
軽自動車に乗っていた。

最初の頃は、運転するのがたのしくてたのしくて。
住んでいた町の市内の新たな顔を見るのが
楽しみで、街中を乗り回した。
(山や峠は攻めてません。スピード違反経歴もなし。)

でも、飽きました。
途中からただの生活の足。

今は東京という、車がなくても生活にまったく
支障のない地域に住んでしまったので、
車も持ってないし、欲しいとも思わない。

たまにレンタカーを借りて遠出することも
なくはないけど、面倒だからなるべく
自分は運転しない。

たぶん、生活の足であれば、使うんじゃないかな。
困らない程度にはメンテナンスもするでしょう。
きちんとオイルも換えるんじゃないかな。
オートバックスで。

最初は、単に知りたかっただけなのかな、
車を運転するってことを。

#血液型のせいだけじゃないと思いますけど、
 どうもAB型というのはそういうことが
 多いみたいです。

- - -

ジムニーという車は、とても面白い車でした。
あの車じゃなければ、もっと早く飽きていたかも。
深雪の駐車場をスタックせずに走れたり、
スタックしても軽いからちょっと押せば抜けられたり。
おもちゃのような、ちょっとした冒険のできる車でした。

ソフトウェア管理の世界では、
「いきなり物を作る」というのは
よくない進め方、とされています。たぶん。

まあ、大きなものを作る場合には、
いきなり細かい物をこちょこちょっと
作ってみたところで、大勢には
なんも影響ないわけで。

それよりも、いろいろよく考えて、
設計と責任分担をきっちり決めて
すすめましょう。と。

まあ、危なくないように大きなもの
を作らなきゃいけないようなケース、
たとえばビルとか発電所を作るときの
進め方を考えてみれば、
ソフトだってそれはそうなんだけど。

もう出来上がるモノが確定していて、
そこに向かって組み上げていく
だけのプロセス。

でもそれって、実は商売としては
あんまりうれしくないのかも。

だって、使う人がどういう反応をする
かわからないものを、そんな後戻り
できないような体制でわわっと作ったら、
危なくってしょうがない。

反応をみながら調整していければ、
その辺のリスクは軽減できるわけで。

ハードウェアでは容易ではないかもしれないけど、
ソフトだと結構できちゃうんだからさ。

修正するには、
どの部品がどこで何のために動いているのか、
きちんと把握できてできない。

あまり大きな規模だと難しくなるけど、
最近は処理系がどんどん便利なライブラリを
持ってくれていて、必要なコーディング量が
減ってきているので、そういうことが、
どんどん現実的になってくる。

そういうことだろうとおもいます。

最近はアジャイルといわれる、ガンガン、
ものをつくるやりかたが、
特に小規模ソフトの世界で伸びてきている
と思いますけど、根底にはそういうことが
あるのかな、と。

夜にアイデアを思いついて、
実現に向けたより詳細なアイデアをA4の紙に
ザーッと書いてしまう、そういうことをたまに
します。

うまくいくかどうかはその後の検討しだいで、
まぁ、ほとんどはものにならないんだけど、
意外とそのときの思考実験が、将来の、
まったく関係ないはずの話の解決の糸口に
なったり、ということもよくあることで。

しかし…、
「手の早い人」というのは、
紙に書くだけじゃなくて、
さらにモノを作ってしまうんだろうなぁ。

そうやって、
たくさんの試行錯誤と、
膨大な準備の上に、
ひとつのよい物はできる。

そういうことだと思います。

今のところ、「手の早い人」がおそらく
持っているであろうスキルとか経験は、
私の手の届かないところにあるのかなぁ。

「あー、この人は眼がいいんだろうな」と思う人が
たまにいます。

視力がある、という意味じゃなくて、
センスがいいとか、冴えてるとか、そういう表現に
なるのかな。

同じようなものを作っても、パパっと、
よくまとまった、見た目に使い方が想像できる、
そんなソフトを書いたりする。

そういうのは見るところを見ていないと理解でき
ないわけで、そうなると自分でも表現できないわけで。
(視覚的論理的に「バカの壁」がある。…「バカの
 壁」読んでないけど意味あってるよね。)

上手にものをつくる人は、いいとこ見てるんだな、と思う。

06月27日にこの日記で書評を書いたIDEOの本では、
経験のある人/会社が作った、よくできた製品のことを、
「履きならした靴」と表現している。
製作者の洞察力で十分に履き慣らしてあるので、
新品をいきなりはいても靴ズレしない。…ということ
だそうだ。

経験も大きな要因でしょうね。

でも、経験はセンスと勉強の積み重ねでもある
わけなので、やっぱり眼がよくないと
うまい経験も積めないんだろうな。

眼がいいという感覚は、それなりに普遍的だろうか?
「この人は眼がいいな」とおもっても、単に自分と
感性が合う、趣向が似たような、そういう人なだけ、
ってこともあるのかもしれない。
その辺にもやっぱり「バカの壁」の罠があるわけで。


堤幸彦演出ドラマ「世界の中心で愛を叫ぶ」を
観ながら、ふとそんなことを考えました。
多くの人に受ける映像を作る人っていうのは、
眼がいいんでしょうね。

#あ、こういうのを道具眼というのだろうか。

昨夜、古田@道具眼氏とメッセンジャーで会話した
時に出た話題なんですけど、早速Blogにつづって
くれています。

こういうのを、チャット終了後に
まとめて、ぱぱっとBlogに書いてしまうあたり、
知のダイナミズムですな(意味不明)。

道具眼ブログ:弟子は師匠を踏み越えて
http://www.do-gugan.com/blog/archives/000118.html

このエントリは、教育をはじめとする「世代を超えた
知識の継承プロセス」が社会的に機能しているのであれば、
「先達は必ず後進に追い抜けれなければならない」、
ということを感慨深げに綴っている。

>教育って本気で取り組んだら本質的に生徒が先生を超えて行かなきゃならないものなんじゃないでしょうか。

学校教育の現場にいる人から見たらあたりまえの
ことなのかもしれないけれど、現役バリバリの
第一線にいる人からすると、追い抜かれるという
感覚は、許容しがたい部分もあるんじゃないか
と想像する。

- - -

なにかやり遂げたら、それをきちんとほかの人にも
継承して、同じことで同じように悩まないようにする。

このすごく基本的なロジックが、人間の集合体に
おける知の発展の基礎になっている。

これがうまくワークするならば、
社会や組織の知識は無駄なく
着実に発展していくことになる。

しかし、継承は100%うまくいくわけじゃなくて。
伝達スキルや時間、基礎知識の量なんかが
パラメータになって、いろいろ邪魔をする。

だから、自分で動かせるパラメータを、きちんと
鍛えて、効率的に着実にほかの人に伝えていく
努力をすることが、社会やら組織やらの
発展の礎なんろうなぁ、と思う。

「教えるのが下手だからさぁ」という一言で逃げて
たら、アカンですな。

伝わるまでじっくり取り組んでいくしかないんですよね。

2010年11月

  1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30        

アーカイブ