Browsing ""
1月 5, 2009 - Web Radio,    コメントは受け付けていません。

SoundExchangeに支払い

FarFromTheMaddingCrowd.jpgTokyo-Tower.jpg今日は、SoundExchangeにウェブ・ラジオの著作権料を送りました。
2009年度のミニマム・フィーの$500と2008年の9月から12月の分です。
9月に送ったときには1$109円でしたが、今日は93円。
1万円以上の差です。こういうところはありがたいです。
それから先日、米Amazonのマーケットプレースで、前々から欲しかった「遥か群衆を離れて」のサントラをゲット。
日本のマーケットプレースでは10000円以上の値がついていたものが、送料を入れて1000円ちょっとで手に入りました。
リチャード・ロドニー・ベネットの音楽は素晴らしいです。フルートを吹いているのが、ジェームズ・ゴールウェイだということも初めて知りました。
来週、流しますのでぜひ聴いてください。
今年のお正月は、遅まきながら、リリー・フランキーさんの「東京タワー」を読んだのですが、後半はもう涙グシャグシャ。
いつかくるお別れは、みんな、あんな風になるんだろうか?
オカンのお葬式の日に、原稿の催促する出版社。それに対して、フランキーさんは、猛烈に反発しながらも、オカンの「人に迷惑をかけたらいかんよ」という言葉を胸に、「よし、それなら、誰にも書けない文章を書いてやる!」と頑張る。
僕は、お別れの場面よりも、こちらに感動した。私を含めて、親不孝しているみなさんに超お勧め。

9月 5, 2008 -    コメントは受け付けていません。

独立・開業でかなえた極上生活

entre200810.jpg「アントレ」10月号の特集記事。
そのタイトルから・・・。
「サーフィン、音楽、アート。僕を救ってくれた湘南に恩返し」
「一から十まで自分次第。先発完投ってこんな気持ち?」
「お客は一日3組。のんびり仲良くいきましょう」
「お隣同士が助け合う、昔ながらのコミュニティ。パソコン教室なら、実はできるんです」
「38歳、ストレスがなくなったら背が伸びちゃいました」
「2人のやりたいこと、好きなこと。ぜんぶを満たすカフェをつくりました」
「野菜が、人をつなげてくれる。僕はその手伝いをするだけ」
「目の前で涙を流してくれる人がいるんです」
「ガイドブックに載らないまちの姿、知ってます?」
「こんなに子供に好かれるIT社長は、絶対に僕だけ!」
僕の理想の「山奥でWEB開発」や「カフェ」の経営は元気づけられます。

8月 31, 2008 -    コメントは受け付けていません。

このベンダーに惚れた

NC20080815.jpg日経コンピュータ 2008/8/15
「好き」と「嫌い」の分かれ道
—顧客を惚れさす七つの技
1.顔は一つ
  必ず平行稼働で引き継ぎ
2.嘘をつかない
  顧客のために「できません」
3.非を認める
  トラブル時こそ問われる真価
4.経過を伝える
  早いだけでなく「見える化」を
5.先を見せる
  技術に加えてメリットを示す
6.感動を与える
  期待をはるかに上回る
7.客を知る
  かゆいところまで手を届かす

8月 26, 2008 -    コメントは受け付けていません。

「マネジメントを考える8つのストーリー」

7つの習慣 実践ストーリー3
ハードロックカフェでの私の目標は、手本を示して導くことであり、命令によって経営することではありません。家族を第一に、仕事を第二に考える方針を組織全体に公表しました。というのも、社員にも同じ目的を持って生きて欲しいと考えたからです。
組織にとって大きな混乱は良いことだとは思いません。しかし、大混乱のギリギリ手前、そこが抑制と確信の間に存在する緊張感のある場所だと信じています。人はそのギリギリのところにいるべきだと思います。なぜなら、そこが飛躍的進歩や洞察力を生み出しやすい場所だからです。
私たちの二つの組織がベストなリソースを持ち寄り、7つの習慣をお互いの仕事に適用したらどうなるでしょうか?武器をおろして攻撃や誹謗中傷をやめ、その代わりにお互いの利益を基にした同じ目標を共有し、共通の目的を持ち始めてはどうでしょう?供給するものをどれだけ安くできるかを探る代わりに、よりよくなるための戦略的にも戦術的にも両方のビジネスを変える手伝いをしてくれる、尊敬できるパートナーを探してみるのはいかがでしょうか?

7月 18, 2008 -    コメントは受け付けていません。

「要求仕様の探検学」その2

フィーリングが事実であり、しかも重要な事実である、とあなたが考えないなら、次のような質問を自分に投げかけてみるとよい。なぜ顧客は、しばしば、訴えられたり、違約金を支払うリスクを冒してまで、不満足な製品に対する契約を破棄するのか?そして、なぜ将来の製品の供給業者を変更するのか?
ブラックボックス作業は延期してはならない。目標を達成するメカニズムを考え始めてしまうと、その効力はなくなってしまうからだ。このような場合、システム試験は、そのメカニズムが物事を正しく行っているかどうか(設計及び実装の試験)を試験するという罠に陥ってしまい、メカニズムが正しい物事を行っているかどうか(要件の試験)には目が向かなくなってしまう。
そうではなくて、解を与える段階でではなく、問題を定義する段階で、ブラックボックス試験をしなければならない。特に、クライアントが何をしたいのかということを、どのようにしてそれを行うかということにかかわりなく、理解しようとしなければならない。
”チームは日曜日も休まずに働くが、要件作業は決して終わらない。”ある種の仮定の定義は、設計者、構築者、及び顧客に残されるのがつねである。しかし、あなたは、ある仮定は他の人が定義するように残しておくという、メタ仮定を文書化しておくことができる。
全ての仮定を意識に上らせること。そうすれば、開発プロセスが進むにつれてそれらを制御できるようになる。
凍結というアイディアは、幕引きの恐れを手なづけるために考案された幻想にすぎない。しかし、私たちは、必要なら再交渉プロセスがあるということを知っていなければ、恐怖を覚えることなしに要件フェーズを閉めることはできない。
不完全であるというおそれによって、無限サイクルに陥ることがあるから、要件プロセスを終了させることに特に注意を払うこと。
作業に参画した人すべてから終了したことの合意を取り付けること。そうしなければ、彼らはいつまでも変更することを止めない。再交渉プロセスを約束すれば、彼らは合意するだろう。
要件作業を終わらせることは本を終わらせること、特に要件定義のような開かれた主題の本を終わらせることに似ている。あなたはもっと言うことを持っているが、朝にコンマをとり、夕べにそれを戻すようなことをしているのに、自分で気づくときがくる。その時点で、あるアイディアを不完全のまま残し、ある啓示は見えないまま残しておきリスクをただ受け入れるのだ。文書化された資料が失われていないことを確認し、勇気を集め、そして止めるのである。

7月 17, 2008 -    コメントは受け付けていません。

「要求仕様の探検学」その1

~設計に先立つ品質の作り込み」
D.C.ゴーズ
G.M.ワインバーグ
黒田純一郎 監訳
栁川志津子 訳
共立出版株式会社(1993)
あいまいさは高くつくのだから、あいまいさにアタックすること。
できるだけ早い時点であいまいさを攻撃すること。いつかはあいまいさから抜け出すにしろ、製品開発の早い段階で誤りを修正すれば、遅い段階で修正するよりも、はるかに安く修正できるのだから。
最大の仮定が行われるのは、開始以前の思考によるものである。

誰がクライアントか?
クライアントにとって本当に価値のある高い成功を収める解とはいかなるものか?
この問題を解決したい真の理由は何か?
設計チームは一つだけにするか、複数必要か?
誰をチームに入れるか?
このプロジェクトにどれだけの時間をかけてよいか?
時間と価値のトレードオフはどうか?
この設計問題の解はどこか他で得られるか?
既存のものを模倣できるか?

この製品はどんな問題を解決するか?
この製品はどんな問題を作り出すか?
この製品はどんな環境で使用されることになるか?
この製品に要求される、あるいは望まれる精度はいかなるものか?
●メタ質問
私は質問しすぎるか?
私の質問は妥当か?
あなたはこの質問に答える適任者か?
あなたの回答は公式なものか?
お互いの理解を確かめるため、質問と回答を書いておき、空いた時間に検討したい。あなたの回答を書いて、コピーを渡すから、査見してもらえるか?

書類は役に立ったが、面談すれば、もっとよく問題が理解できると思う。いつかお目にかかれるか?そうすれば、私たちはもっとよく知り合え、問題点をはっきりさせることができる。
他に有益な回答をくれる人がいるか?
製品が使用されることになる環境を見に行けるところがあるか?
●面談を終える前のメタ質問
何か他に、私が聞いておくことがあるか?
あなたが私に聞きたいことがあるか?
今回カバーできなかったことがあれば、またここへ来るか、電話してよいか?

この質問に答える前にだいぶ長い間躊躇されたようだ。他に何か私たちが知っておかなければならないことがあるか?
その問題をXにたずねたところ、彼女はYと言った。あなたは彼女がなぜYと答えたのか心当たりがあるか?
あなた方は回答に合意しているようには見えない。そのことについて、何か聞いておくことがあるか?
これまでの進め方に満足しているか?
不満なことがあるなら、その理由は何か?
このプロジェクトに携わっている他の人々について何か話せるか?
このプロジェクトで私たちと仕事をしている他の人たちについてどのように感じるか?
このプロジェクトに入っていない人で、必要な人がいるか?
このプロジェクトには必要でない人が入っているか?
その人についてもっと話してもらえるか?
みんなのための会議(注意点)
1.出席者全員にとって安全な文化を創る。
2.会議はできるだけ小さく、ほどよい規模にする。
3.どの会議も一つのタイプに限定し、そのタイプを当面の仕事に合わせて設計する。
4.念入りに準備する。
5.熟練した司会者を使う。
要件定義の基本的な問題はあいまいさである。
観察:人々が重要な事象を見たり聞いたりするときの差異
記憶:人々が重要な事象を思い出すときの差異
解釈:人々が重要な事象に結び付いた重要な出来事をどのように解釈するかという差異
問題理解:人々がどのように心の中で問題を定義するかに関する差異
道具は次の三つの範疇に大別されることに注目して欲しい。すなわち、自分がどこにいるのか(アイディアが多すぎるのか、少なすぎるのか、ちょうどよいのか)を判断して記憶する道具、南に移動する(アイディアを減らす)道具、北へ移動する(アイディアの数を増やす)道具。
紛争の調停
司会者がしなければならない最初のことは、紛争が本質的なものかどうかを判断することだ。本質的な紛争とは、このプロジェクトに、この時点でかかわり、今出席している人々を巻き込むものである。
よい司会者であるためには、完全に参加する技術–自由に注意する、自由に質問する、自由にコメントする–を身につけなければならない。
●私は今回中立と思われているかもしれないが、提案Aを支持したい、提案Bは文書になっていないのだから。
●考えをまとめるために5分間の休憩をとりたい
●ぼくは今かなり腹を立てている、頭を冷やすため2時間ほど休憩したい。
●何人も一緒に話すから、ぼくは会議についていけない。
●フィービ、君の話を全部聞きたいのだが、マリリンが話し始める前に全部終わったのかどうかわからないんだ。どうなの?。
どんなプロジェクトも紛争を経験するし、ある種の調停なしでは、一貫して成功することはできない。幸運にも必要が生じたときに、活動できる”アマチュア”調停者でうまくいくプロジェクトもある。しかし、幸運に頼りたくないと思えば、訓練を受けた調停者集団を作り上げることだ。

7月 16, 2008 -    コメントは受け付けていません。

ワインバーグ再び

exploringrequirements.jpg少し余裕が出てきたので、仕事に役立ちそうな本や雑誌の再読をしています。
今回は、ワインバーグとゴーズの「要求仕様の探検学~設計に先立つ品質の作り込み」。
原著は89年、翻訳は93年に出ました。
このころは多分、内容は理解できていなかったに違いない。
線を引っ張っている箇所もまばら。
しかし、今やっと、自分の知識・経験が、この本を理解できるレベルに追いついた。
まだ1/4位しか読んでいないが、アイディアの宝庫です。
惜しいのは独立したときに読んでいたらな、と感じること。
明日から、そのエッセンスを紹介します。
当時はCASEが話題になっていたのですが、ワインバーグとゴースは、CASEを使おうが、どのような表記法を使おうが、要求仕様から曖昧さを取り除くような人間的な問題は解決できない、と説く。

7月 14, 2008 -    コメントは受け付けていません。

「うっかり」ミスは無くせる

nikkei_computer20080715.jpg日経コンピュータ 7/15号 特集
過去3年間で取り上げたシステム障害のうち49%が「運用・設定誤り」
内訳は、運用操作の誤り、パラメータ設定・変更漏れ、データ入力ミス、障害発生時の作業誤り、障害からの復旧作業のミス。
根本的な要因:オープン化による製品・技術の多様化、システムの肥大化、運用時間の拡大、行き過ぎた効率化、システム化範囲の拡大、変更頻度が高まる、接続先の増加、劣悪な作業環境
ミスを招いた要因:手作業に頼りがち、作業手順が未確立、経験・訓練不足、テスト手法が決まっていない、手順書の更新を怠る、作業の複雑化、担当者の士気低下
直接の原因:作業者の勘違い、手順書の誤り、作業内容・手順の理解不足
「うっかり」対策、べからず集
×作業ミスで片付ける
○ミスを招く真因を追求
×ミスをしかる、罰する
○ミスしない人をほめる
×恥ずかしいから隠す
○積極的に全社公開
×ルールで縛る
○絶対守れる最小限に抑える
×「チェック強化」で終わり
○仕組みを見直す
×運用は単純作業と考える
○臨機応変に動くのは高度な力が
×経営・品質部門が牽引
○全員参加型の活動を

7月 14, 2008 -    コメントは受け付けていません。

御社の発注、3つの大問題

nikkei_computer20080615.jpg日経コンピュータ 6/15 第二特集
(1)要件定義が自社で出来ないと、「品質」「コスト」「納期」全てで満足度が低下する。
(2)安さを求めて要件定義能力やプロジェクト管理能力のないベンダーに発注すると、結局は高くつく。
(3)開発着手の延期による、コア・メンバーの喪失とプロジェクトの失敗。
「作って効果を出すのは発注者の責任、その自覚がITベンダーの能力を”使い倒す”ことにもつながるのだ。」

6月 18, 2008 -    コメントは受け付けていません。

組込みソフトの開発現場につける薬

杉浦英樹
技術評論社(2007)
本書を読んで、会社員時代に交換機の開発をしていた頃を思い出しました。
よく似ています。
どちらも混沌としていて、問題山積みの開発現場。
それはそうだ、うまくいっている現場でCMMIやPMBOKなど話題になるはずがない。
杉浦さんの開発経験に基づいたアドバイスは貴重なのですが、やはり特効薬はない。
例えば「議論すべき」は理想論・建前論としてはわかるのですが、そのノウハウがない。
問題提起された後で、突き放された感じ。
でも組込みソフトを作ろうとしている人には必読です。

ページ:«1234567...16»