2008年7月アーカイブ
・「はじめてのRuby」を読了。次はRails。
・昔見たテリー・ギリアムの「12 Monkeys」。ブルース・ウィリス主演のSF映画でした。その時は気がつかなかったのですが、音楽が、敬愛するPaul Buckmaster。最近、サントラを手に入れました。テーマはピアソラの曲なのですが、所々、Buckmasterのきらりと光るストリングスが。
・N君の推薦で、谷崎潤一郎の「細雪」を読んでいるところ。900ページの大作です。まだ200ページですが、何故かドストエフスキーを連想。本当に久しぶりの小説です。
・Radio Meowingsの曲数がもうすぐ1000曲。記念にナレーションの入ったプログラムを作ったのですが、ナレーションの難しいこと。Toshiboさんのうまさに脱帽です。公開は再来週の予定。ちょっと怖い。
・グーちゃんはあれきり来ない。家には入れるまいと思っていたのですが、気配がするとドアを開けて確かめる始末。なんだか寂しい。
今週のRadio Meowingsは、Rick Wakeman,Coldplay,Spandau Ballet,Peter Gabrielをお送りします。宜しかったらお聴きください。
Rubyの本を読んでいて、正規表現の項になった。
そこで見慣れない記法が・・・。
(.*?)"
暫く考えたあげくに、「Perl5 デスクトップリファレンス」の正規表現の項を再読。
分かりました。
「繰り返しサブパターンは可能な最長の文字列にマッチする。ただし、その後に？が続く場合は、最短のマッチングを行う。」
Rubyの例では、「"」が現れるまでの最短のマッチングになります。
分かっていると思っていた正規表現での新しい発見でした。
Yugui著
オライリー(2008)
いまさらですが、Rubyの勉強を。
6月に出たばかりの本ですが、Amazonでは在庫切れ。楽天で買いました。
まだ1/3しか読んでいないのですが、これだけ言語がある中、更に新しい言語が必要なのか？、と思って読み始めたのですが、「ええっ！こんな設計ありなの？」と驚くことしきり。
まつもとゆきひろ氏を見直した1冊でした。
頭を硬くしないためにも、新しい言語には挑戦するべきですね！
マッコーネルの本だったか、プロならば、年に一つは新しい言語に挑戦するべき、というのがありましたね。
最近はプロジェクト管理や、ピープルウェアの本が多くて、とても年に一つにはなっていませんが、その精神は大切にしたいと思います。
Railsの本も読もうと思います。
Rubyが好きになりそうです。
とても魅力的な言語です。
リクルートの「アントレ」のネット版。
この中の「プロワーカー」と呼ばれる人たちのインタビューと、お店を持った人たちのインタビューそれぞれ数十件を読みました。公開期限が過ぎて参照できないもの以外の全てです。
好感が持てるのは、紹介されているのは大成功している人ばかりではないこと。
等身大のチャレンジャーの姿が垣間見えます。
モチベーションをたっくさんもらいました。
こういう情報を無料で提供しているリクルートに感謝です。
もっとも雑誌もそうなんですが、フランチャイズの広告記事で成り立っているサイトなんですが、それだけではないところが、立派です。
くじけそうになったら、是非ブラウズしてみてください。
「ああ、こんなに頑張っている人たちがいるんだ」そう思うだけで感動します。
みなさん、とってもいい笑顔です。
願わくば、私もこんな笑顔で毎日仕事をしていますように。
近所の書店で買った、「アントレ」8月号。
「アントレ」を買ったのは独立前に数冊買ってから、数年ぶり。
有名人、無名な人のいろいろな人たちの体験談は、元気の源になります。
こういうものを読むと、「何でもありなんだなあ」「どんな逆境でもリトライできるんだなあ」と改めて思います。
たった500円の雑誌で、これだけ元気づけられるとは、非常にお勧めです。
映画でも小説でもないリアルライフ。
それぞれの人の短い記事が、それぞれが感動的なストーリー。
みんなお金儲けのことなど考えていない。
世の中の不便を解消したい、困っている人を助けたいという信念のもとで頑張っている。
初心に返るいい機会でした。
それにつけても、一番大事なのは「健康」。
今まで、一番大事なのは、「時間」だと思っていたのですが、2番手に下げました。
健康であることに感謝！
昨日、今日と、DVDで映画鑑賞。
「ALWAYS 続・三丁目の夕日」と「ロード・オブ・ザ・リング 王の帰還」。
どちらも話題作だし、名作だし、楽しめるはずだったのですが、見終わった後の、この空疎感はなんでしょうか？
所詮、偽りの人生、と言う気持ちが常にある。
時間が長いほど、現実からかけ離れているほど、その感が強い。
親に話すと、「年をとったんだよ、そうやって卒業していくんだよ」という答えが。
ちょっと寂しいが、確かにそうかも。
でも多分、話題作のDVDは買い続けると思う。
それは友達と話を合わせるためにだけかもしれないが・・・。
今週のRadio Meowingsは、Enya,Kenny G,Ian Anderson,Matt Monro,John Barryをお送りします。宜しかったらお聴きください。
フィーリングが事実であり、しかも重要な事実である、とあなたが考えないなら、次のような質問を自分に投げかけてみるとよい。なぜ顧客は、しばしば、訴えられたり、違約金を支払うリスクを冒してまで、不満足な製品に対する契約を破棄するのか？そして、なぜ将来の製品の供給業者を変更するのか？
ブラックボックス作業は延期してはならない。目標を達成するメカニズムを考え始めてしまうと、その効力はなくなってしまうからだ。このような場合、システム試験は、そのメカニズムが物事を正しく行っているかどうか（設計及び実装の試験）を試験するという罠に陥ってしまい、メカニズムが正しい物事を行っているかどうか（要件の試験）には目が向かなくなってしまう。
そうではなくて、解を与える段階でではなく、問題を定義する段階で、ブラックボックス試験をしなければならない。特に、クライアントが何をしたいのかということを、どのようにしてそれを行うかということにかかわりなく、理解しようとしなければならない。
”チームは日曜日も休まずに働くが、要件作業は決して終わらない。”ある種の仮定の定義は、設計者、構築者、及び顧客に残されるのがつねである。しかし、あなたは、ある仮定は他の人が定義するように残しておくという、メタ仮定を文書化しておくことができる。
全ての仮定を意識に上らせること。そうすれば、開発プロセスが進むにつれてそれらを制御できるようになる。
凍結というアイディアは、幕引きの恐れを手なづけるために考案された幻想にすぎない。しかし、私たちは、必要なら再交渉プロセスがあるということを知っていなければ、恐怖を覚えることなしに要件フェーズを閉めることはできない。
不完全であるというおそれによって、無限サイクルに陥ることがあるから、要件プロセスを終了させることに特に注意を払うこと。
作業に参画した人すべてから終了したことの合意を取り付けること。そうしなければ、彼らはいつまでも変更することを止めない。再交渉プロセスを約束すれば、彼らは合意するだろう。
要件作業を終わらせることは本を終わらせること、特に要件定義のような開かれた主題の本を終わらせることに似ている。あなたはもっと言うことを持っているが、朝にコンマをとり、夕べにそれを戻すようなことをしているのに、自分で気づくときがくる。その時点で、あるアイディアを不完全のまま残し、ある啓示は見えないまま残しておきリスクをただ受け入れるのだ。文書化された資料が失われていないことを確認し、勇気を集め、そして止めるのである。
～設計に先立つ品質の作り込み」
D.C.ゴーズ
G.M.ワインバーグ
黒田純一郎 監訳
栁川志津子 訳
共立出版株式会社(1993)
あいまいさは高くつくのだから、あいまいさにアタックすること。
できるだけ早い時点であいまいさを攻撃すること。いつかはあいまいさから抜け出すにしろ、製品開発の早い段階で誤りを修正すれば、遅い段階で修正するよりも、はるかに安く修正できるのだから。
最大の仮定が行われるのは、開始以前の思考によるものである。
●
誰がクライアントか？
クライアントにとって本当に価値のある高い成功を収める解とはいかなるものか？
この問題を解決したい真の理由は何か？
設計チームは一つだけにするか、複数必要か？
誰をチームに入れるか？
このプロジェクトにどれだけの時間をかけてよいか？
時間と価値のトレードオフはどうか？
この設計問題の解はどこか他で得られるか？
既存のものを模倣できるか？
●
この製品はどんな問題を解決するか？
この製品はどんな問題を作り出すか？
この製品はどんな環境で使用されることになるか？
この製品に要求される、あるいは望まれる精度はいかなるものか？
●メタ質問
私は質問しすぎるか？
私の質問は妥当か？
あなたはこの質問に答える適任者か？
あなたの回答は公式なものか？
お互いの理解を確かめるため、質問と回答を書いておき、空いた時間に検討したい。あなたの回答を書いて、コピーを渡すから、査見してもらえるか？
●
書類は役に立ったが、面談すれば、もっとよく問題が理解できると思う。いつかお目にかかれるか？そうすれば、私たちはもっとよく知り合え、問題点をはっきりさせることができる。
他に有益な回答をくれる人がいるか？
製品が使用されることになる環境を見に行けるところがあるか？
●面談を終える前のメタ質問
何か他に、私が聞いておくことがあるか？
あなたが私に聞きたいことがあるか？
今回カバーできなかったことがあれば、またここへ来るか、電話してよいか？
●
この質問に答える前にだいぶ長い間躊躇されたようだ。他に何か私たちが知っておかなければならないことがあるか？
その問題をXにたずねたところ、彼女はYと言った。あなたは彼女がなぜYと答えたのか心当たりがあるか？
あなた方は回答に合意しているようには見えない。そのことについて、何か聞いておくことがあるか？
これまでの進め方に満足しているか？
不満なことがあるなら、その理由は何か？
このプロジェクトに携わっている他の人々について何か話せるか？
このプロジェクトで私たちと仕事をしている他の人たちについてどのように感じるか？
このプロジェクトに入っていない人で、必要な人がいるか？
このプロジェクトには必要でない人が入っているか？
その人についてもっと話してもらえるか？
みんなのための会議（注意点）
１．出席者全員にとって安全な文化を創る。
２．会議はできるだけ小さく、ほどよい規模にする。
３．どの会議も一つのタイプに限定し、そのタイプを当面の仕事に合わせて設計する。
４．念入りに準備する。
５．熟練した司会者を使う。
要件定義の基本的な問題はあいまいさである。
観察：人々が重要な事象を見たり聞いたりするときの差異
記憶：人々が重要な事象を思い出すときの差異
解釈：人々が重要な事象に結び付いた重要な出来事をどのように解釈するかという差異
問題理解：人々がどのように心の中で問題を定義するかに関する差異
道具は次の三つの範疇に大別されることに注目して欲しい。すなわち、自分がどこにいるのか（アイディアが多すぎるのか、少なすぎるのか、ちょうどよいのか）を判断して記憶する道具、南に移動する（アイディアを減らす）道具、北へ移動する（アイディアの数を増やす）道具。
紛争の調停
司会者がしなければならない最初のことは、紛争が本質的なものかどうかを判断することだ。本質的な紛争とは、このプロジェクトに、この時点でかかわり、今出席している人々を巻き込むものである。
よい司会者であるためには、完全に参加する技術--自由に注意する、自由に質問する、自由にコメントする--を身につけなければならない。
●私は今回中立と思われているかもしれないが、提案Aを支持したい、提案Bは文書になっていないのだから。
●考えをまとめるために5分間の休憩をとりたい
●ぼくは今かなり腹を立てている、頭を冷やすため2時間ほど休憩したい。
●何人も一緒に話すから、ぼくは会議についていけない。
●フィービ、君の話を全部聞きたいのだが、マリリンが話し始める前に全部終わったのかどうかわからないんだ。どうなの？。
どんなプロジェクトも紛争を経験するし、ある種の調停なしでは、一貫して成功することはできない。幸運にも必要が生じたときに、活動できる”アマチュア”調停者でうまくいくプロジェクトもある。しかし、幸運に頼りたくないと思えば、訓練を受けた調停者集団を作り上げることだ。
少し余裕が出てきたので、仕事に役立ちそうな本や雑誌の再読をしています。
今回は、ワインバーグとゴーズの「要求仕様の探検学～設計に先立つ品質の作り込み」。
原著は89年、翻訳は93年に出ました。
このころは多分、内容は理解できていなかったに違いない。
線を引っ張っている箇所もまばら。
しかし、今やっと、自分の知識・経験が、この本を理解できるレベルに追いついた。
まだ１／４位しか読んでいないが、アイディアの宝庫です。
惜しいのは独立したときに読んでいたらな、と感じること。
明日から、そのエッセンスを紹介します。
当時はCASEが話題になっていたのですが、ワインバーグとゴースは、CASEを使おうが、どのような表記法を使おうが、要求仕様から曖昧さを取り除くような人間的な問題は解決できない、と説く。
日経コンピュータ 7/15号 特集
過去3年間で取り上げたシステム障害のうち４９％が「運用・設定誤り」
内訳は、運用操作の誤り、パラメータ設定・変更漏れ、データ入力ミス、障害発生時の作業誤り、障害からの復旧作業のミス。
根本的な要因：オープン化による製品・技術の多様化、システムの肥大化、運用時間の拡大、行き過ぎた効率化、システム化範囲の拡大、変更頻度が高まる、接続先の増加、劣悪な作業環境
ミスを招いた要因：手作業に頼りがち、作業手順が未確立、経験・訓練不足、テスト手法が決まっていない、手順書の更新を怠る、作業の複雑化、担当者の士気低下
直接の原因：作業者の勘違い、手順書の誤り、作業内容・手順の理解不足
「うっかり」対策、べからず集
×作業ミスで片付ける
○ミスを招く真因を追求
×ミスをしかる、罰する
○ミスしない人をほめる
×恥ずかしいから隠す
○積極的に全社公開
×ルールで縛る
○絶対守れる最小限に抑える
×「チェック強化」で終わり
○仕組みを見直す
×運用は単純作業と考える
○臨機応変に動くのは高度な力が
×経営・品質部門が牽引
○全員参加型の活動を
日経コンピュータ 6/15 第二特集
(1)要件定義が自社で出来ないと、「品質」「コスト」「納期」全てで満足度が低下する。
(2)安さを求めて要件定義能力やプロジェクト管理能力のないベンダーに発注すると、結局は高くつく。
(3)開発着手の延期による、コア・メンバーの喪失とプロジェクトの失敗。
「作って効果を出すのは発注者の責任、その自覚がITベンダーの能力を"使い倒す"ことにもつながるのだ。」
今週のRadio Meowingsは、The Carpenters,Ofra Harnoy,Weather Reportをお送りします。宜しかったらお聴きください。
今日は久しぶりにF君と遅いランチ。
例によって、自然派バイキングの「わらべ」です。
今日は二人で地域の情報紙についていた、ジェラート無料のクーポンを持って行きました。
添加物なしのジェラートで10種類の中から選べます。私は「抹茶」にしました。
別途注文すると320円で、なかなか豪華なデザートで満足でした。
食事の方は、やっと体重が元に戻ったところなので、無理せずにそこそこに。
F君の方はいつものように、思いっきり食べていました。
大丈夫かいな。
二人であっという間に平らげて、40分くらいでお店を出ました。
私の方は直ぐに仕事に復帰。
行き帰りのクロスバイクも気持ちがいいし、いい気分転換です。
・Accessのサポートの仕事に時間を取られています。徐々にパートナーさんへシフトを計画中。
・固定資産の管理プログラムなのですが、ちょっとしたテストに12桁の電卓があると便利。今までWindowsの電卓を使っていたのですが、その不便なこと！字は小さいし、マウスでクリックするなんて面倒。Amazonで字の大きなCASIOの12桁電卓を買いました。
・Radio.Meowingsで提供している楽曲がもうすぐ1000曲を超えます。それを記念して、ナレーションの入ったプログラムを計画中。昔の10万以上したDATとマイクより、今の数千円のICレコーダーの方が音がいいのですよね。
・最近手に入った珍しいCD。カーペンターズのUS盤「Made in America」と野生のエルザのサントラ「Born Free」。カーペンターズはUS盤は中古市場で数千円の値がついているのですが、偶然2000円以下の物件を発見。野生のエルザは米国のAmazonのマーケットプレースで海外発送OKだったもの。廃盤のはずなのに新品でした。早速、Radio.Meowingsでオンエアー！
・「ねんきん特別便」が届く。はて、問題は何もなさそうに見えますが、何が問題だったのでしょうか？
・ついにブラウン管のテレビをその大きさに耐えかねて廃品回収業者に持って行ってもらいました。やはり費用を取られましたが。
・AQUOSのDVD/HDレコーダーは、「新日曜美術館」を撮るためだけに活躍中。DVDのラベルにも凝りたくなります。
・目覚ましの時刻を7:00から6:45に変更。ニュースで目覚めるよりもバロック音楽の方が心地よい。
・何十年ぶりで、夏用のジーンズを買う。UNIQLOで半額で売っていたもの。暑いときにはやはりこちらがいい。少し前まで、ライトウエイトとかは無かったような気がしますが。
今週のRadio.Meowingsは、Billy Joel,Lalo Schifrin,Elmer Bernstein,Arturo Benedetti Michelangeliをお送りします。宜しかったらお聴きください。
ショックなことがありました。
去勢手術も終わって、病気の検査も白、うちの子にしようと思っていたグーちゃんが飼い猫だったのです。
病院から帰って、首輪をつけて外に出したのですが、次に来たときには首輪がとれている。
緩くしてやったからとれたのかな、と思っていると、翌日来たときには、鈴のついた首輪をつけていて、首輪には飼い主の名前が書いてある。
いつものように、部屋を探索して、ご飯を食べて、ごろ寝をしていくグーちゃんですが、残念です。
シルバーの迷子札まで作ったのですが、ムダになりました。
去勢したことで、訴えられたりしなければいいのですが・・・。
Links
