その後、社内のエンジニアが全員集まったところで、再度来週からの体制を議論することにした。ポイントは2つ。

1. はじめに決議を出したチームはスクラムマスターというロールをなくし、全員エンジニアになる、という実験を次のスプリントで行う。他のチームはこの流れに乗るか？
2. スクラムマスター同士で新しいチームを作るか、それともこれまでのチームに入るか。あるいは、チームをシャッフルして再度メンバー構成を変更するか？

各チームに分かれて10分ほど議論された。あっさりと話がまとまったチームもあるし、議論が紛糾したところもあったらしい。
再度エンジニアは全員集まり、それぞれのチームの議論の結果が公表しあった。

1. すべてのチームで、スクラムマスターなしでスプリントを進めることにすることが決定
2. メンバー構成の変更は、行わない。
   理由は、スクラムマスターがいなくなったことによる影響と、チームメンバーが入れ替えになったことによる影響がまざってしまうこと。また、急激な変化は心理的な負担になり、かなり開発スピードに影響を及ぼすので、避ける方が望ましい。

こうして、チーム・メンバーのふとした意見から、一気に話が加速し、社内全体の開発体制が来週の月曜日から変わることになった。時間にしておよそ1時間程度の議論で結論まで至った。これにはわれながら舌を巻く。「とりあえずやってみる」ことを恐れず、すばやい決定と実践を行うことができる姿勢こそがアジャイルの真骨頂だ。

社の開発プロセスにはついてはまだまだ未熟な部分も多くとても優れているといえるものではないが、この徹底されたアジャイルな姿勢という点だけは、どんな会社にも劣らない。メンバーそれぞれがこの変更を受け入れることができているのも、アジャイルがしっかり浸透している証拠だ。

このような実験の機会を作ることができたわけであるから、よりよい開発プロセスを築くために、きちんと学びを得なければならない。ただスクラムマスターをなくしただけで終わってはいけない。

この壮大な実験を経て、ぼくらが確認するべきことは3つ。

1. チームメンバー一人一人がスクラムの主役であることをみんなが心底理解しているかどうか。
2. スクラムマスターの仕事を可能な限り明文化し、チームの誰もがスクラムマスターの仕事を行うことができるか。
3. 開発（ストーリーを終える）以外に必要な作業（プロダクションのログ監視、バグ対応、営業からのサポートの対応、Gitリポジトリのメンテナンス、デプロイツールのメンテナンス、テストetcetc）がどれくらいあるのか理解されているか。そういった雑務への貢献もカウントされているか。

この3点が満たされれば、本当にデモクラティックな開発体制が実現されるかもしれない。

あるスクラムマスターはこの決定を知った後、こうつぶやいた。

「みんなが心にためたフラストレーションの矛先が、スクラムマスターに向かったのだ。スケープゴートにされたのだ」

たしかにそういった集団心理が働いたことも事実かもしれない。ただエンジニアたちのフラストレーションとは、現状の仕組みが抱えている問題点に直結している。スクラムマスターが生贄になったとすれば、やはりそれは、今の仕組みの中でスクラムマスターというロールがうまく機能していなかったということを意味していたのだ。

————

6/19 00:09 文章を一部修正

Rubyのようなダイナミックな言語に許された大きな特徴の1つは、すでに（どこか別の場所で）定義されているクラスを”開いて”拡張できること。
たとえば、基本クラスであるStringに対して、

class String
  def to_aster
     '*' * self.size
  end
end
 
"password".to_aster #=> "********"

といったメソッド追加が簡単にできる。こんなちょっとした変更だけのために、Stringの派生クラスを作らなくてもいいので、これはおいしい。

ところで、静的な型を持ち、コンパイルされるScalaでも、実はこれと同等のことが実現できる。ただし、方法はもう少しだけ込み入っている。

scala > val hidden = "password".toAster
hidden: java.lang.String = ********

ScalaでのStringは、java.lang.Stringであり、すでに定義済みのこのクラスを拡張できることはさすがにできない。代わりに、「暗黙の型変換」という仕組みを利用する。

class AsterString(str:String) {
  def toAster = str.map(_ => '*')
}
implicit def str2asterStr(str:String) = new AsterString(str)

と拡張したクラスを作り、implicitキーワードをつけて、変換を行うメソッドを定義しておくと、

"aaaaaa".toAster
res58: String = ******

と、新しい魔法を使うことができるようになる。

でも、このためだけに拡張クラスを作るのは面倒くさいかな。はい、そうですよね。
でしたら、無名クラスで代用することも可能になっております。

implicit def toAster(str:String) = new {
  def toAster = str.map(_=>'*')
}
toAster: (str: String)java.lang.Object{def toAter: String}
 
"aaaaaa".toAster
res00: String = ******

うん、同じく、魔法がきいてる。

そして、魔法を、一気に黒魔法へと変えることができる。

implicit def toAster(d:Double) = d.toString.toAster        
toAster: (d: Double)String
val pi:String = 3.14159d
pi: String = *********

Double -> Stringの型変換に、toAsterメソッドが使われるようになった。
このため、toStringを使わずに、Stringで宣言された変数にDoubleの値を代入にしても、コンパイラからtype mismatchとは言われなくなる。
定義したあなたがこの変換をいつまでも記憶の何処かにとどめておくことができたならいいけれど、数ヶ月が経ち、自分で定義した暗黙の型変換メソッドをすっかり忘れてしまっていたなら、きっと何が起こったのかわからなくて唖然とすることになるだろう。

それでもよく考え抜き、「適切に」使用されるならば、これまでコンパイラを黙らせるためだけに書いてきたtoString()やInteger.parseInt()などの紋切り型のメソッドやキャストを書く必要がなくなるばかりか、データベースから取り出した値をScalaオブジェクトの自動的に変換させるORMの機能の実装にすこぶる役に立つものになるだろう。

Scalaさんは、はじめてRubyを触ったときを思い出すほど、わくわくさせてくれる言語である。
こんなDSLを量産したくなりますね。

  val phrase = onC(4 / 4).with7th { 
    val melody = Melody('F * 2', G * 2 , 'C * 4)
    melody.withHarmony(1 octaveUp) 
  } 
  tempo(120).play(phrase)

むふふ、これはおいしい。

王様の速読術 斉藤 英治

ターゲットは、渡部昇一「知的生活の方法」です。

知的生活の方法 (講談社現代新書 436) 渡部 昇一

まずは、王様の速読術にあった速読の秘訣を紹介しておきましょう。

速読の秘訣１：プレビュー（５分）

ページをめくる前に、プレビューという作業を行います。プレビューでは、

1. 私はこの本を読んでどんな情報を得たいのか。なにができるようになりたいのか、といった、この本を読む目的をはっきりさせる
2. 目次やカバー、キャッチなどに目を通して、本の構造や概要を理解する
3. 著者がどんな目的で書いたのか、気持ちを察する

ことをします。

僕の場合、「知的生活を満喫するためのコツを３つ以上見つける」という目標にしました。２の本の構造は、目次をざっと見ればたいてい頭に入ると思います。心細い場合、メモに章立てだけを書いておくといつでも見返すことができて便利です。３の著者の気持ちですが、本書の場合、まえがきで渡部さん自身が

本を読んだりものを書いたりする時間が生活の中に大きな比重を占める人たちに、いくらか参考になることを述べること

と書いていたので、ここに線を引いておきました。この著者の目的と、読者である私の目的が合致しているといい読書になる予感がします。

これらの作業を、５分でやることが重要です。なにもかもきっちりやる必要はありません。作業内容はおおざっぱでいいのですが、時間制限だけは守りましょう。

速読の秘訣２：フォトリーディング（５分）

次に写真読み（フォトリーディング）を行います。見開きを２秒ずつ、パッパッとめくっていくのです。文字を読むというよりは、絵画をすらすら眺めるのに近い感覚で、とにかくテンポよくページをくっていきます。

この作業の目的は、

1. 自分にとって大事なことが書いてある場所を見つける
2. 自分にとって不要である場所を見つける

です。つまり、拾う部分と捨てる部分を明確に仕分けしていくのです。３０分で本を読む場合、はじめから終わりまで一字一句逃さず読み切るようなことはできません。

興味本位で読書をする場合、いらないと思う場所を見つけることに集中する場合が多いです。本を読む目的が具体的に決まっていて、その目的に答えてくれる場所が本の一部である場合には、読むべき場所を定める法に集中したほうがいいでしょう。

この作業も制限時間は５分です。５分で全ページを繰ることになるので、地の文を読むことはほとんどできないでしょう。

速読の秘訣３：スキミング（２０分）

最後に、２０分のスキミングです。フォトリーディングで目星をつけた箇所を重点的に読み込み、自分の得たい情報を得る作業に入ります。

まるで大海原の上を舞う鳥のように、滑空しながら海面を見渡すのである、そして魚の気配を見つけたら、急降下していく
（王様の速読術 p.82）

ように本を読むのです。１ページ目からだらだらとページをめくっていてはいけません。常に、「このページから自分にとって有用な情報を取得できているか」と意識しておいてください。難しすぎる、簡単すぎる、面白くない、意義が見出せないなんて場合には、読まずにさっさと次のページへ進みましょう。

気に入ったフレーズなどがあったら、ノートをとるのもいいですし、赤線を引いておくのもいいです。ノートをとる場合、あまり丁寧にやっているといくら時間があっても足りないので、気になったフレーズを走り書き程度に残すのがいいかと思います。

本から１００％の情報を得ようとしないでください。抜けたり漏れることは当然あると思います。速読の目的は、通常の２０％程度の時間で本の内容の８０％を得ることにあります。一番得たいものだけを確実に得ること、それが大切です。

成果

僕が、渡部昇一「知的生活の方法」を速読するに当たって立てた目標は、

「知的生活を満喫するためのコツを３つ以上見つける」

でした。

スキミング中に残した走り書きマインドマップはこちら。

自分にしか読めない字でなにかを書いています。これをまとめると、

1. 繰り返して読むにたえる自分だけの古典を多くつくると、自分の読書趣味を磨いていける
2. 一年中毎日数時間コミットできるような「静かなる持続」をすることが大切である
3. 知的生活に疲れ休息を求める、コースティング（健康的な退行）現象が起こることが誰しもある。そんなときは、安らかな睡眠をとったり、映画や推理小説などのエンターテインメントを楽しんで心をリラックスさせるといい

となりました。

はっきりいって、このまとめは、本書の趣旨の１０分の１も言い表してないと思います。ただ、僕は、自分の得たかったことを得ることができて、とても満足です。

感想

速読を実践してみて思ったのは、今まで受動的であった読書スタイルが、能動的になったということです。普通に順にページをめくって読む作業というのは、目の前に現れてくる文字を単に次から次へと追っていくだけで、ＴＶを見ているのとほとんど変わらないくらいに、受身の作業であることに気づきました。

速読では、受身であることは許されません。自分の手と頭で本のページを自由に行き来して、肝心な部分だけを選び取るという、自発的な作業が要求されます。

しかし、はまると面白い。高速道路を疾走するのに似た快感があります。また、要らない部分はよまなくていい、と決めることで、読書により気軽に行うことができます。

特に、積ん読本が山のようにある奇特な方たち、ぜひ速読を身につけて、ばっさばっさと積読本たちを制覇していきましょう。

2010年、あけましておめでとうございます。今年もよろしくお願いします。

今年は、teNeuesの「FORM 2010 Super Poster Calendar」をGETしました。たまたま立ち寄った紀伊国屋新宿南口店で、年明けに買ったので、半額でおとく。

teNeuesというのはドイツ系出版社で、写真つきカレンダーで有名な会社のようです。

サイトを見ていると、なかなかおしゃれな写真集を多く出しているようで、興味あり。

このSuper Poster Calendarは、カレンダーというより部屋を飾る絵画に近いです。30日しか壁に掛けられないのが残念なくらいのクオリティ。

部屋での作業に気合いが入ります。

メリークリスマスイブ！
こんな聖なる夜に、他人のブログを読んでいる人なんていないと知りながら、投稿します。

この記事では、「Ruby Facets」ライブラリを紹介したいと思います。

Rubyは簡単に基本クラスを拡張できることから、より便利に、あるいは暗黒的に使うためのライブラリがたくさんありますね。”2.days.ago”で一躍評判となったRailsのActiveSupportや、”require :merb / :core_ext / :lib”でおなじみのMerbのextlibが有名です。

Ruby Facetsも、そんなライブラリのひとつ。Rubyをほんのりおしゃれに、ちょっぴりスパイシーにしちゃいます。

どんなことができるのか、つまみ食い形式でご紹介しましょう。

Array

Arrayの積を求める（デカルト積というらしい）

%w(Chapman Cleese Gilliam) ** %w(ham egg spam)
#=>
[["Chapman", "ham"], ["Chapman", "egg"], ["Chapman", "spam"],
["Cleese", "ham"], ["Cleese", "egg"], ["Cleese", "spam"],
["Gilliam", "ham"], ["Gilliam", "egg"], ["Gilliam", "spam"]]

組み合わせを求める

%w(Chapman Cleese Gilliam).combination(2).to_a
#=> [["Chapman", "Cleese"], ["Chapman", "Gilliam"], ["Cleese", "Gilliam"]]

Arrayのおしりに詰め物をする

%w(k t k r).pad(10, "!")
#=> ["k", "t", "k", "r", "!", "!", "!", "!", "!", "!"]

セパレータを複数指定できるjoin

["Crosby", "Stils", "Nash", "Young"].conjoin(', ', ' & ')
#=> "Crosby, Stils, Nash & Young"

Enumerable

EnumerableをごにょごにょするときのECOモード「Denumerable」
（select, mapなどはフィルタのように働き、中間のオブジェクトを生成しない）

arr = (1..100).to_a
class << arr
  include Denumerable
end
puts arr.select{|n| n%10==0}.map{|n| n**2}.to_a

グループ化

(1970..1990).group_by{|y| y < 1989 ? 'showa' : 'heisei' }
#=>
{"heisei"=>[1989, 1990],
"showa"=>[1970, 1971, 1972, 1973, 1974, 1975, 1976, 1977, 1978, 1979, 1980, 1981, 1982, 1983, 1984, 1985, 1986, 1987, 1988]}

MapしてHashしたいから、Mash!

[:year, :month, :day].mash{|sym| [sym, Date.today.send(sym)]}
#=> {:day=>24, :month=>12, :year=>2009}

最頻出要素(modeは統計用語だそうです)

%w(ham egg spam egg spam egg).mode #=> ["egg"]

出現する確率

%w(ham egg spam egg spam egg).probability
#=> {"egg"=>0.5, "spam"=>0.333333333333333, "ham"=>0.166666666666667}

出現する個数

%w(ham egg spam egg spam egg).frequency
 #=> {"egg"=>3, "spam"=>2, "ham"=>1}

エントロピー増大の法則

%w(ham egg ham egg ham egg).entropy #=> 1.0
%w(ham egg ham egg ham spam).entropy #=> 1.45914791702724
%w(ham egg spam! egg ham spam).entropy #=> 1.91829583405449
%w(ham egg spam! spam!! ham spam).entropy #=> 2.25162916738782
%w(ham egg spam! spam!! spam!!! spam).entropy #=> 2.58496250072116
%w(spam!!!! egg spam! spam!! spam!!! spam).entropy #=> 2.58496250072116
%w(spam!!!! spam!!!!! spam! spam!! spam!!! spam).entropy #=> 2.58496250072116

Hash

Hashだって、時にはArrayのように振る舞わせたいものです。

{ :john=>'lennon'} + { :ono=>'yoko'} #=> {:john=>"lennon", :ono=>"yoko"}
{ :john=>'lennon', :ono=>'yoko'} - { :john=>'lennon'} #=> {:ono=>yoko}
{ :john=>'lennon', :ono=>'yoko'}.join(' ', ', ') #=> "john lennon, ono yoko"

Object

Object#newのProc化

class Monty
  def initialize(name); @name = name end
end
%w(Chapman Cleese Gilliam).map &Monty
 
 #=> [#<Monty:0x1254a6c @name="Chapman">,
 #<Monty:0x1254a30 @name="Cleese">,
 #<Monty:0x12549f4 @name="Gilliam">]

Kernel

ファイル名、行番号つきデバッグ ‘d’（’g'とか’n'とかありますが、’d'もありますよ、ということで）

d variable
#=> [["Chapman", "Cleese", "Gilliam", "Idle", "Jones", "Palin"]] d.rb:5

仲間に入ってる？

me = "tomoya55"
monties = ["Chapman", "Cleese", "Gilliam", "Idle", "Jones", "Palin"]
me.in? monties #=> false

困ったらユーザに聞くといい

ask "Oops, I encoutered unexpected problems. Do you want to debug me?"

とまらないかも。。しれない。

loop do
  break if maybe
end

maybeはtrueになる確率を指定することができる。

# Christmas Eve by Tasturo Yamashita
maybe(0.01) ? 'she will come' : 'she will not'

だまれ！

silently do
  warn "It is a Chiristmas, stupid!"
  puts "We wish a Merry Chiristmas, We wish a Merry Chiristmas"
  STDERR.puts "****, explode!"
end

alias devnull silently

などしてみるのもいいかもしれません

Stackable

文字列をスタックのように扱う

str = "0123456"
class << str
  include Stackable
end
str.pop #=> 6
str.push("9") #=> "0123459"

Time

時の経過をはかる

Time.elapse{require 'active_support'} #=> 0.695170879364014
Time.elapse{require 'extlib'} #=> 0.185311079025269

１年前

Time.now.ago(1, :years)

１年後（引数のパターンが違うのがいやですね。こちらのCREDITはActiveSupportチームらしいです）

Time.now.advance(:years=>1)

Module

ラッパー（いわゆるデコレーター）

class ChristmasObject
  wrap(:inspect) do |orig, *args|
    "<We Wish>" + orig.call + "< a Merry Christmas!!>"
  end
end
p ChristmasObject.new #=> <We Wish>#<ChristmasObject:0x12535cc>< a Merry Christmas!!>

Symbol

~ではじまるSymbolは否定語

:friend.not? #=> false
:'~friend'.not? #=> true

String

Stringにはわさわさとメソッドが追加されています。使いやすそうなものだけ。

"ero".bracket('(') #=> "(ero)"
"ero".bracket('x') #=> "xerox"
"santa".chars #=> ["s", "a", "n", "t", "a"]
"santa clause".cleave #=> ["santa", "clause"] cleaveは「割く」という意味ぽい
 
%q(/usr/bin/ruby).quote(:b) #=> "`/usr/bin/ruby`"
%q(/usr/bin/ruby).quote(:s) #=> "'/usr/bin/ruby'"
%q(/usr/bin/ruby).quote(:d) #=> ""/usr/bin/ruby""
%q("/usr/bin/ruby").dequote #=> "/usr/bin/ruby"
 
"ham spam".rewrite([[/am/, "i"],[/\s/,'-']]) #=> "hi-spi"

まだまだありますがこのへんで、ふう〜

あまりここでは紹介していないけれど、メタプログラミングのための拡張もずいぶんなされているので、Rubyで黒魔術やるのが好きな向きには一見の価値ありだと思います。

ところで、Facets(Core)自体は、目新しい機能は何も用意しません。当たり前に使いたいメソッドを簡潔に実装したものの集まりにすぎません。たいていのメソッドの実装は数行程度で、多くても２０行程度。
おそらくRubyプログラマなら、似た振る舞いをするメソッドを実装した経験も数多くあるでしょう。

このライブラリを使用する目的は、

• 車輪の再発明なしに
• 簡潔に
• 正しいメソッド名で

書けることができることにつきます。つまり、コードが読みやすくなり、メンテナンスしやすくなるのですね。

正しいメソッド名とというのは、かなり重要です。
われわれ、へっぽこ日本語プログラマは、痛いクラス名、痛いメソッド名を量産してしまいがちなので、こういったライブラリから適切な英単語をパクる術を身につけておきましょう！

どれだけRuby文法的にきれいにコードを書いても、命名規則がアレげじゃあ、台無しです。
かっこいいメソッド名を使って、おしゃれRubyにしちゃいましょう。

また、実装自体が短いので、Ruby Wayなコードの書き方の参考にもなるなるです。
（ただし、テストがRSpecじゃないのが残念！）

RDocを見て、気になるメソッドがあればソースもぜひ覗いてください。
今夜さっそく気になるあの子を落とすのに役立つトリビアが待ってるかもしれません。

最後に、、、個人的な趣味で、コード例にPython的な用語を盗用してしまってごめんなさい。

１２月５日６日に大阪に戻り、「一万人の第九」コンサートに参加してきました。広い大阪城ホールの中に、一万人の歌声が響いたのを聞いたときは、本当に感動的でした。

「一万人の第九」イベントは、その名の通り一万人の大合唱団でベートーヴェンの交響曲第九番を歌おうというイベントで、毎年、年末に開かれています。今年でもう２７回目だそうで、知る人ぞ知る年末の恒例イベントです。

合唱隊として参加することを決めたのは今年の夏。妻に誘われて応募してみたら、見事抽選を合格し、東京クラスのレッスンを受けることができることになりました。当選して喜んでは見たものの、ぼくは合唱なんてこれまで一度も参加したことがありません。歌が上手とはお世辞にも言えないし、歌詞であるドイツ語もいっさいわかりません。まったくずぶの素人が参加したわけです。

まず困ったのが自分のパート選び。合唱は男声・女声パートに分かれ、それぞれ音域の高低によって、

• 女声（高）ソプラノ
• 女声（低）アルト
• 男声（高）テノール（年配の方は「テナー」とも呼ぶ）
• 男声（低）バス

に分かれています。合唱の経験がないので、テノールとバスのどちらが自分にとって歌いやすいのかまるでわからないわけです。悩んでも仕方ないので潔く、きらびやかさのあるテノールを選びました。

パート選びは抽選前に決めなくてはなりません。結果的には、毎年男声の（特にテノールの）人材不足が深刻なようで、女声に比べると、男声で応募する人はずっと当選確率が高いようです。

抽選に通ったからと言って、「一万人」に参加できるわけではありません。その前にきちんと全１２回の練習に参加する義務があります。たしか今年は２回お休みすると本番に参加する権利を失うというルールだったと思います。平日夜のレッスンだったので、残業がちなビジネスマンはなかなか参加しづらいかもしれません。

初回から七−八回目くらいまでは合唱の一部を取り上げて繰り返し読み上げ＋練習することの繰り返しでした。ぼくのように初めての人の場合、曲の全体構造を知ること、自分のパートの楽譜を「正確」に知ること、歌詞を覚えることを同時に進めていく必要があります。第九の有名な合唱部（いわゆるMのパートです）以外は、なかなか聞き覚えのないメロディーですので、練習だけではどうしても覚えきれません。しかし、練習の回数は決まっているわけなので、どうしても練習以外の時間、つまり家に帰って自分で自習する必要があります。ぼくの場合、レッスン会場で販売されているパート別CDを買って、何度も聞くことにしました。楽譜をていねいに読み解くことができる人であれば、パート別CDをわざわざ買わなくても、楽譜を片手に、いろんな第九の録音を繰り返し聴くのでもいいかもしれません。

練習の後半は通し練習が中心でした。楽譜を見ずに円になって歌います。楽譜を手にしていると、ついうつむきがちになりますが、楽譜を投げ捨てると、両手が自由になり、リズムに合わせて左右に体を揺らしながら歌えるようになります。こうなるまでには、何度も何度も練習する必要はありますが、曲の全体の流れさえ覚えておけば細部はとりあえずうろ覚えでも気持ちよく歌うことができました。ぼく自身なまけものなので、一部歌詞をきちんと覚えていないところはありました（苦笑）全部の歌詞をきちんと覚えるのは来年以降の課題ですね。

11月の後半には佐渡裕さん直々の指揮による練習がサントリーホールの小ホールで行われました。世界で活躍するプロの指揮者が目の前にいて、直接指導してもらえるチャンスなんてめったとあることではありません。会場全体が一種の興奮に包まれていて、佐渡さん自身が表現したような「祝祭」的な雰囲気の中で、2時間の練習を行うことができました。見ず知らずの人同士が集い、「ベートーヴェンの第九を歌いたい」という気持ちを体中を使って、佐渡さんにぶつけていました。佐渡さんもその会場の思いに答えるように、いっさい手を抜くことなく、懸命に指揮をし、悪い点を注意し、そして何度も何度もほめていただきました。いま思い返しても、すばらしい時間だったと思います。会場の一体感・親密さという点では本番以上に充実した時間だったとすら言えます。

東京での最後のレッスンで通し練習を行うそのときまで、怠け者で歌の不得手な自分が本当に第九を歌いきれるだろうかという不安は拭い去れないままでした。テノールのパートは、音の高低の変化が比較的大きく、平気でオクターブ以上の動きがある部分もあります。また、後半には見せ場でもある「フーガ」があります。曲の展開が非常に早くなり、いろんな表情の声をめくるめく間に切り替えていく必要があります。もたもたしていて置いてけぼりにされてはいけないとがんばって歌おうとすればするほど、体が硬直し顔から笑顔が消え、お坊さんが早口でお経を唱えているような歌い方になってしまいます。無表情で声だけ張り上げているのです。こんな歌い方ではどんな名曲ですら台無しです。歌い手がもっとも喜びを感じていない「歓びの歌」なんて誰も聴きたくはないでしょう。

「笑顔、笑顔！」「リラックス、リラックス！」と何度も何度も指摘されました。

たしかに周囲の人達を見渡しても、慣れている人ほど自然な表情で気持ちよく歌い上げているかわり、ビギナーの人達はしかめ面・仏頂面で顔をゆがめながら歌っているように見えました。

ぼく自身、うまく歌うことはかなわなくとも、楽しんで笑顔いっぱい元気いっぱいに歌うことだけは忘れまいとしました。

12月5日がリハーサルで、12月6日が本番でした。

両日、大阪城ホールには1万人の合唱隊が集まりました。ホールの3分の2が合唱隊で占められています。男性はスーツに蝶ネクタイ、女性は白ブラウスに黒のスカート。ずらーと並ぶとやはり圧巻です。練習ではじめて全員で声を出したとき、やはり普段の教室の響きとは全然違うことに少しとまどいました。ソプラノやアルトの声が1秒以上遅く聞こえるのです。また声の響かせ方にも工夫がいります。遠く遠くに声を飛ばすように意識しないと、声がすとんと下に落ちてしまって、くぐもったような音色になるのだそうです。何度も何度も音を出し合って大阪城ホールの響きを確認しました。

何度リハーサルを繰り返してもやはり本番は空気が違います。

正装したオーケストラが入場し、佐渡さんの情熱的な指揮の下、第一楽章、第二楽章、第三楽章と演奏が続きます。第四楽章に入ると、合唱隊の人達の口元がきりりとなります。

低弦が「歓喜のテーマ」を奏でます。それに呼応するようにバイオリンも奏で始め、曲は一気に華やかさを帯びます。

ティンパニーが叩かれた瞬間が合図でした。会場の一万人でだんっと同時に立ち上がりました。会場の照明もぐんと明るくなります。はっとするようなこの演出も、佐渡さんの指揮のものと何度か繰り返し練習したものでした。どれほど効果的だったか、早く映像で確認したいものです。

一万人が立ち上がり、照明が会場全体を照らした直後、バリトンの厳かな独唱が会場を包みます。ここらです。ここから、オーケストラ、ソリスト、合唱隊の掛け合いによる第九の見せ場が始まります。

Freude
とバスとテノールの男声がはじめて響きます。このタイミングも遅れないように入念に練習しました。広い会場なので、佐渡さんの指揮を見てから声を出していては遅いのです。その２小節ほど前からFrの発音のために巻き舌を作っておき、あるいはこすれるようなFの音を先行して出しておく必要があるのでした。

この音がどれほど肝心であるかはいくら強調しても足りません。このFreudeがわれわれ合唱隊の第一声であり、このFreudeこそが全歌詞の中でもっとも重要な「歓喜」という意味を持っているのです。ぼく自身はリハーサルでの遅れてしまった反省があったので、普段より一歩早く発声したつもりですが、気持ちが先んじてしまって、少し声が空回りしてしまったように思います。やはりこの箇所はとても難しい部分です。

そこから後は、もう佐渡さんの指揮を見つめて必死に歌っていました。誰もが知ってる有名なパート、であるMの部分では、特に笑顔を意識して、朗々と歌い上げることを心がけました。しびれるようなフーガのパートはもう下手くそでもいいので、がむしゃらに元気いっぱいといった歌い方。「ひざまづきなさい」の厳かな部分も練習よりも本番が一番うまく歌えたように思います。一万人で静寂な雰囲気を作り出すことは容易なことではありませんが、何度も練習してきたところで最後の最後にひとつにまとまったのではないかと思います。

あっという間に歌い終え、オーケストラが最後の音を出し終えたときは、とてもさわやかな達成感を感じることができました。

「歌うことは生きることだ」

と佐渡さんは言っていたのですが、この歌い終えた瞬間は、老若男女問わず合唱隊全員が生気ある喜びの表情をしていたように思います。

まだまだ自分のすべてを出し切ったとまでは言えませんが、３ヶ月の練習した分だけ、その時間の努力の分だけはしっかり出せたように思います。

とても貴重な体験をすることができました。関係者の皆様の努力により何十年も続いてきたイベントです。これからもいつまでも続いてほしいものです。

その間にアクセスしていただいた方、ごめんなさい！

原因は調査してみましたが、直接の原因はまだつかめていません。
アパッチ先生が残したダイイング・メッセージは、

[Sun Sep 13 19:46:04 2009] [notice] caught SIGTERM, shutting down

でした。

調査については、技術用の英語ブログnicecabbage.comに残しています。

こんなに長期間に渡って、不具合に気づくことができなかったことを反省しております。
これまでめんどくさがってやっていなかった監視ツールを導入しました。

ライブドア社のデータホテル・パトロールです。
このサービスは5分か10分に1回程度サーバへアクセスしてくれて応答を確かめてくれるモニタリングサービスです。
なにかいやなエラー応答になった場合には、すぐにメールで教えてくれる優れものです。

これで、二度と同じ過ちをおかすことはありません。
今後は一瞬で復旧できるようにつとめます。
これからも当ブログをよろしくお願いします。

Amazonで詳しく見る by G-Tools

はじめての京極夏彦さん体験でした。数ヶ月前に数十ページ読んだだけで放置していたが、一昨日から再度腰を据えて読んでみた。

予想を超えておもしろかった。余計な知識に触れるのが好きなぼくにとって、主人公の京極堂の口から次々にこぼれてくる禅にまつわる話がたまらなくおもしろかったです。釈迦・達磨からはじまり、中国で花開いた禅。鎌倉時代に本朝・日本へ輸入され、栄西・道元らの高僧たちによって広められる。禅の方法は、日本の風土のなにかとマッチしたようで、室町時代以降、日本人の生活・芸術・文化にとけ込み、水墨画・工芸・建築などあらゆる方面で、「革新」をもたらした。

日本人にとっては、一見、なじみがあるように思える禅ですが、実は何も知らないことも、知らされます。たとえば、臨済宗・曹洞宗という言葉を知っている人はたくさんいると思いますが、どう違うのか？禅問答（公案）ってどんなもの？なぜ座禅をするの？悟りってなに？

解説でも触れられているとおり、まさに仏教版「薔薇の名前」といった感のある小説です。
殺人事件を解くミステリー小説としても一級で、宗教的なものに興味のない人でも、読んで楽しめて、おまけに、禅の考え方をわかった気になれるとてもいい本です。
惜しむらくは、1200ページを超す大作で、貴重な休日を2−3日まるごとつぶしてしまうこと。でも、その分、お腹いっぱいの満足感を得ることができますよ〜。

ちなみに、さらに禅に興味を持たれた場合は、鈴木大拙の著作をおすすめします。

10年前のぼくは、大学２回生で、なんか不器用な生き方としていたように思う。

夜の都市で女の子に声をかけてまわったり、取り立ての免許で車をバカみたいに飛ばして遠く遠くへ無目的な旅に出たり、バーで明け方まで酒を飲んでたださわいだり。
ずいぶんチャラいことをやっていたような気がする。記憶から消し去りたいものである。

とはいえ、ぼくは、そもそも、それほどあっけらかんとした性質ではない。
遊びにくれている自分をバカにした目で見ているもう一人の自分がいた。
もう一人の自分は、懐疑的なペシミストで、哲学書や思想書、あるいは文学書を好み、折にふれて、
「絶望することがかっこいいのだよ、きみ」
と、タバコをぷかぷかふかしながら、教えてくれた。

この二人の自分はたしかにあまり仲良くはなく、片方が表に出ているはもう片方は裏に引っ込んでいた。
たぶん同居されると、目の前の人が混乱しただろうし、ぼく自身もおかしな方向に行ってしまっていただろう。

しかし、同じ人間から派生した人格である。共通するところもたくさんある。
その一つが、将来のことを考えないことであった。

もちろん、当時の自分は、「将来のことを考えたりは絶対にしないぞ！」と固く決意していたわけではない。
ただ、普段の思考プロセスのなかに、未来への展望のようなものが入り込む余地がほとんどなかっただけである。
なんたって、１９歳の夏である。
他に憂慮するべきことが２００個くらいあったのだろう。

大学を中退するときも、今楽しくないから出て行こうと思ったばかりであった。
けして、将来の二つの選択肢を天秤にかけて、「ステイ」と「ドロップアウト」のどちらが有利か見比べながら、判断したわけではない。
そういう戦略的な思考のできる人間ではなかった。

そして、もちろん今も。
この姿勢はほとんど変わっておらず、今でもむやみに将来に不安を覚えることがない。

その代償と言ってはなんだが、ぼくは、現在について猛烈に「悩む力」がある。
自分に与えられた環境・ポジション・待遇すべてが、
「実がじぶんにはふさわしくないのではないだろうか」
と思うのである。
こんなものを頂いてしまっては、自分はもったいなすぎると、悩むのである。

そして、最後には、
「やっぱりこんな素敵なものは受け取ることができません」
という心境になって、辞表を出して、お返ししてしまうか、
「こればかりは失うわけにはいかない。与えられたものにそぐうよう精進します」
と発奮するか、の２つの形のどちらかとなって、行動に表れるのである。

これはなぜかという、自分が与えた以上のことをもらうのが、基本的には苦手だからである。
なぜかぼくには、「先に人に与えてから、後でお返しを受け取るべきである」という強迫観念がある。
先にどっぷり投資しておき、後々がっつり回収する、というほうが自分の精神衛生上、都合がいいのである。

最初に受け取ってしまうと、ぼくはその相手に対して、どんなお礼をしたらいいのかわからなくて途方に暮れる。
なので、つねに、その相手に負い目を感じざるをえなくなる。
それは、少しも気分のいいものではない。
もはやその人と対等ではなくて、膝下にひざまずいている感覚が拭い去れない。
英語でいうところの、I-O-U I owe youというやつです。

ちなみに、こんなことを書いていながら、自分で不思議に思うのだが、ぼくは金に関しては、人から借りてもなんとも思わない。
金に対して鷹揚であるというと、聞こえがいいが、稼ぎが少ないので、結果として、人（というか家族のみなさま）から借りることが多い。
金に悩まないのは幸せであるが、幸せなのは本人ばかりで、周囲にご迷惑をかけているのであれば、いつ包丁で刺されても文句は言えない。

３０になる前に、なるべく現実感覚をもう少しアジャストしないとまずいかなあと思う。

Amazonで予約してみたのだが、ぜんぜん届かないで、どうしたものかを待っていたのですが、今朝になって、こんなメールが届いた。

紙媒体はなにかと不便だなと思い、オンラインでPDF販売していないか探してみたところ、出版元のApressでしっかりと販売されていることを発見した。

というわけで、早速、購入してみました。

まだ、全部は読んでいませんが、第一印象としては、起業をする決意をした人が、実際にどのような一歩を踏み出せばいいのかについての詳しいマニュアル本のようだと感じました。
起業家としての心得とか精神論ではなくて、何をすべきかという実践の書です。

数々のスタートアップ経験者との対談も多く載せられていて、彼らのリアルな言葉を聞くことができるようになっています。

これを読めば、シリコンバレーのスタートアップを経験したも同じ！ような気分にはなれそうです。

本書にも触れられていますが、Getting It Done、つまり「成し遂げる」ことが最も大切です。
そこから、スタートアップの戦いがはじまるのです。
そのための第一歩を踏み出すところまでをこの本では丁寧にカバーされているようです。

「アイデアはある」
けど、
「まだ実行していない、実行の方法がわからない」
人にぜひとも一読をおすすめします。

目次が公開されていないようなので、興味のある方のために、へっぽこ翻訳版の目次一覧を載せておきますね。

気になる方は、ぜひＰＤＦ版でも書籍でも買ってみてください！

目次

序文
著者について
レビュアーについて
謝辞
はじめに

第1章　はじめに：かつての正解は、もはや不正解
脳にチップを入れて下さい
[Micro-ISV: ビジョンから現実へ]の時代から変化したこと
新しいオンライン経済事情とスタートアップ
冗談みたいに短くまとめた、ソフトウェア・スタートアップの歴史
で、スタートアップってなに？なぜはじめたほうがいいの？
スタートアップの種類ーお好みのものをどうぞ
いつ飛び込めばいいだろうか？
ソフトウェアビジネス会議　Neil Davidson
Microsoftビジネス開発ディレクターDon Dodge
まとめ

第2章　スタートアップは、価値創造こそすべて
問題意識・価値創造
はじめを始めるのは、ほんの始まり
Wallyのスタートアップの法則
Wallyのスタートアップの法則が示すもの
いいアイデアがあるって？ちょっと待って
どこから問題を探し出すのか？
やってはいけない10の起業（理由つき）
まとめ

第3章　山ほどのプラットフォーム・山ほどの選択肢
以前と現在
プラットフォーム・ビジネスはみんなのあこがれ
チェックリスト：プラットフォームを評価する
SaaS
Rick Chapman, Softletter社: SaaSビジネスの現実性
PaaS
Google App Engineが大好き
MicrosoftのAzureサービスと Meshプラットフォーム
プラットフォームとしてのＳＮＳ
モバイル
Antair Corporation社 Andrey Butov,
Googleモバイル・プラットフォーム・プログラム・マネージャ Eric Chu
ハイブリッド
Appcelerator社CEO Jeff Haynie,
Balsamiq Studios Peldi Guilizzoni
オープンソース・ＣＭＳ
デスクトップ：MacとWindows
Indev創業者 Scott Morrison
Brisworks共同創業者 Gwen Hilyard
まとめ

第4章　スタートアップのためのツールとグループ
かつてまでは...
スタートアップのための使えるツール
スタートアップ・コミュニティ
The Micropreneur Academy社 Rob Walling
IT/Digital Legal Companion Author and Attorney Gene Landy
スタートアップのための団体・オンライングループ・オフライングループ
Women 2.0 Shaherose Charania
あなたの住む街の起業家たちの集まり-オフラインとオンライン
スタートアップのための大企業ベンダープログラム
まとめ

第5章 お金: 調達し、管理し、利益を出す
お金の流れに従うこと
資金を調達する
資金調達のはしご
君は一人じゃない
資金ゲームの基本
Guy Kawasaki: エンジェル投資を受ける方法
Guy Kawasaki: 起業家にまつわる１０の嘘
Morgenthaler Ventures代表: Rebecca Lynn
Milk Street Venturesパートナー: Jo Anne Miller
Illuminate Ventures経営企画部門代表: Cindy Padnos
Golden Seeds創業者兼経営部門代表: Stephanie Hanbury-Brown
スタートアップ・インキュベーター
資金を管理する
Attorney and Author of IT/Digital Legal Companion Gene Landy
Accretive Solutions副社長: Mairtini Ni Dhomhnaill
お金を稼ぐ
Shareware Promotions創業者 Dave Collins
まとめ

第6章　メディアとスタートアップ
注目を引くこと
ビッグアイデア
メディアへのレーダーを設置する
スタートアップ起業の会社ブログ
Six Apart: Andy Wibbels
Twitterの地へようこそ
あたらしいニュース・メディア
ReadWriteWebリード・ライター: Marshall Kirkpatrick
編集者はなかにいる
DP Directory, Inc.社長: Al Harberg, President
リポーターもなかにいる
blogtalkradio.com 広報コーディネータ: Luke Armour
正しい広報の仕方
別の肩書き: コミュニティ運営責任者
Six Apart TypePadコミュニティマネージャ Ginevra Whalen
uTest, Inc. マーケティング・コミュニティ副社長: Matt Johnston
Blellow コミュニケーションマネージャ Veronica Jorden
Linqia CEO Maria Sipka
まとめ

第7章 わかりやすさがものを言う
明確にできなければ、売ることはできない
｢独創的販売計画（ＵＰＳ）｣パターン
ケーススタディ: Mint.com
ケーススタディ: RescueTime
まとめ

CHAPTER 8 GETTING IT DONE
第8章　成し遂げる（ＧＩＤ）
水を差すようなことを言うけれど...
GTDまとめ
GTD著者 David Allen
生産術エキスパート Matt Cornell
オンラインでの生産性向上
開発者の生産性向上
創業者の生産性向上
まとめ

第9章 6人の賢人たち
耳を傾けるべき人たちの声
HubSpot 創業者・チーフソフトウェアアーキテクトDharmesh Shah
SourceGear 創業者/CEO Eric Sink
Fog Creek Software CEO/共同創業者 Joel Spolsky
作家・コーチング Pamela Slim
Experience Engineering創業者・チーフエキスパリエンスオフィサー Lou Carbone
作家、Alltop創業者 Guy Kawasaki
まとめ

第10章　次にすべきこと
終わりへの導入
スタートアップが成功するための機会がこれほど恵まれたことはなかった
スタートアップ起業の製品・サービスを支えるアイデアの質こそが最上の課題
少なくともある特定のセグメントに対して、真に訴求性のあるアイデアでなければならない
｢本物の価値＋素晴らしい顧客体験｣を提供すれば受け入れられる
他人のルールで勝負すれば、敗北する
ソーシャルネットワークが成功の鍵
軌道に乗せる前の「死の谷」を越えるプランを用意しておく
資金こそがスタートアップの血液ーー正しく管理する
最後のアドバイス

アマゾンのサーバでエラーが起こっているかもしれません。一度ページを再読み込みしてみてください。