« 2006年9月 | トップページ | 2006年11月 »

2006年10月の31件の記事

2006/10/31

敬語システムの崩壊

 あいかわらず(笑)、日本語が乱れているそうである。

 そうおもって、Wikipedia で調べてみると、“日本語の乱れ” と題してこんな記述があった。それによると、言語学においては “乱れ” という概念はなく、“変化” があるだけである、ということである。この考えは私の感覚にとてもよくあっている。

 では、誰が “日本語が乱れている” といっているのか? やはり Wikipedia によると、個人のいわゆる 「最近の若い者は」 的な感覚と、さらに政府による国語統制による影響らしい。
つまり、時の権力者が国民統制の一つの手段として “国語統制” を行い、そこからの逸脱を “日本語の乱れ” と称して弾圧を行っている、と私は理解した。そういう話を聞くと、なぜテレビがやたらと “日本語が乱れている” と叫んでいるのかが良く理解できた。テレビ局は政府&官僚が好むことを放送する媒体だからである。

 また、古くは清少納言が “日本語が乱れている” と嘆いているらしい。こうなると、“日本語の乱れ” は1000年続いていることになり、1000年続いたことが数年で収まるとは到底思えないし、つまりは日本語は “乱れている” 姿が本来の姿であるということである。

 論理的に言えば、日本語は統制されていたほうが話が伝わりやすい。正しく物事を伝えるためには、一つの言葉に一つの意味しかなく、その意味を誰もが知っている状態が必要である。
 それでも、私は “日本語が乱れている” 状態のほうが好きだ。仮に、女子高生が私の理解を超える 「あげ」 だの 「もる」 だの 「がちゅ~りからめし」 だのと、しゃべっていても、そこから新しい何かが起こりそうで、私は好きである。

 少し前に敬語の分類が 三 → 五 に増えた。詳細については こちら を参照されたい
私なんかが見ると、「三でもよくわからんのに、五に増やしてどうする?」 と思ってしまうのだが、学者によるとこの方が論理的に文章が整理しやすかったり、誤用を指摘しやすかったりするそうである。

 言語学者や言語を商売にしている作家などには、なじみのある話題で適正な敬語の使い方が体に染み付いているのかもしれない。しかし、少なくとも私には、政府&官僚のさだめる正しい敬語の使い方は、したくてもできない。
 そもそも、敬語は日本社会における身分制度に基づいて構築されたものである。現在の(少なくとも建前上)には身分・階級がなくなった社会においては、敬語は不要なのではないか?と私は考えている。

 状況によって、丁寧になったり、尊敬したり、へりくだったりと、ムリに使いにくくすることはないだろうに、と私は思っている。
 私の意見は、もっと単純にせよ、である。  「敬語は一種類として、とにかく敬語と思われる何かを使っていれば、その人は丁寧に話をしている。」 でいいではないか。例えば、「お茶を入れた」 に対して 「お茶が入りました」 でも 「お茶をお入れしました」 でも、どちらでもよいではないか。そんなことを言うと “いしかわじゅん氏” あたりに、「日本語が間違ってる!」とののしられそうであるが。(笑)
(余談になるが、BSマンガ夜話で “いしかわじゅん氏” が、映画監督の “大林宣彦氏” に映画の技法について、“それは違う!” と自信たっぷりに反論していて、見ている私はなんだかこっけいに感じた。)

 私は敬語を正しく使う自信がない。おそらく大半の人が自信をもって、正確に敬語を使うことはできないのではないだろうか? 言語学者や作家など、一部の人たちだけが正しく使えるようなシステムは、すでに崩壊しているといえるだろう。
 パソコンに例えれば、政府&官僚が 「Windows では、パソコンの使い方が間違っている。Linux (もしくは BTRON)こそが正しいパソコンの使い方である。」 として、国民に押し付けているようなものだ。(Windows を皆がほんとうに正しく使えるかどうかは置いとくとして)  Linux は優れたOSであることは事実である。しかしながら、Linux を日常的に使うためには、多くの専門的な知識を必要とする。少なくとも、Windows ほどに、ほいほい使えるものではない。

 現在の年金制度といい、ゆとり教育といい、官僚は崩壊しているシステムに固執するのが好きだ。自分達が間違っていたことを認めたくないからである。
 しかし、官僚もしょせんは人の子。間違いも失敗もする。それを前提に官僚システムを再構築して、“官僚・公務員は 『公僕』 つまり 『国民に奉仕するもの』” 、“恣意的に権限を用いない”、“官僚も公に個人で責任を取る”、といったシステムに改めていかなければならないと、私は強く考えている。

| | コメント (0) | トラックバック (1)
|

2006/10/30

テスティング -「話を聞きに言ってますか?」 マネージャー、リーダーへの提言-

 提言シリーズの3回目である。

 私が上司として嫌いなタイプの一つに、“聞きたいことがあると、こちらの都合も考えずに呼びつける” タイプがある。そういう上司に限って、仕事に追われているわけではなく、部下のサポートのための根回しをするでもなく、いつも自分の端末であちこちのホームページや掲示板をずっと見てたり、ソリティアをして遊んでいたりする。そして、さらにその上の上司から報告を求められると、あわてて部下を呼びつけて報告させる。
普段遊んでいるという部分はおいておくとして、私が出会った上司の9割は “呼びつける” タイプの上司であった。

 そういう反面教師に多くあったせいかどうかは知らないが、私がリーダーをしたときは、特別な理由がない限り、聞きたいことがあるときは自分のほうから部下のほうに出向いていって話を聞きにいった。
以前に書いたこともあるように、1テスターの頃からいろんな人のところに話を聞きに逝くことが好きであったし、それによって得られたことも多かった。ので、部下のところに話を聞きにいくことはまったく苦にならなかった。

 なぜ、自分から聞きに行くことにしたかにはいくつか理由がある。

1. 部下の時間を無駄に使わせない
部下は当然自分の担当の仕事をしてもらっており、その仕事を効率してもらうことで、結果として開発費を低く抑えることができる。
通常上司のほうが時給が高いので、部下に雑用をさせるほうがコストが安い、という考えもあるが、私はチームの雑用(=マネージメント)をして歩くのがマネージャー&リーダーの仕事だと考えている。

2. 話を聞きにいったほうが効率が良い
呼びつけて話を聞いているときに、情報が足りなくていったん情報を取りに戻ったり、上司との所にもっていくための資料を印刷したり、と報告をもってこさせるのは意外と効率が悪い。
それよりも、部下が働いている場所に行って、みたい情報がすぐに見られるところで話を聞くほうが効率的である。特に私の仕事はテスティングであり、ひとり数台の端末をもっており、情報を印刷せずとも端末で表示できるし、テスト中のソフトウェアの実際の動きを見ながら話を聞くことも容易である。

3. 情報を知りたい側が積極的に行動すべき
“情報が欲しい” のはこちら側である。変な言い方になるが、情報が欲しい側が弱い立場だと考えた。

4. 自分が出向くことでこちらの努力が示せる
こちらが出向くことで、相手にこちらが “努力をしている” ことを知らせることができる。努力していることを見せると、たいてい見せられた側も一生懸命にこちらの質問に答えようとしてくれる。

5. 部下の仕事ぶりを見ることができる
私が働いていた部署では、ひとりひとりがパーティションで仕切られており、仕事の様子を見通すことができなかった。実際にひとりひとりのパーティション内を覗き込むことで、部下の仕事の様子を知ることができた。

 また、ひとりひとりのステータスを確認するために、いつもチーム全体を集めてミーティングをしているマネージャー&リーダーもいた。私はこういう上司のやり方も非効率で嫌いであった。
チーム内のほかの人がなにをやっているのか、どういう状態なのかを知ることはけっして無駄なことだとは思わない。しかし、個々人の上司に対するステータス レポートは他の人にとっては退屈なだけであり、私から見るととても無駄な時間の使い方に思えた。

 私ももちろんチーム全体ミーティングを定期的に行った。ただし、それはチーム全体に共有してもらいたい情報をやりとりするためだけに行い、何でもかんでもチーム全体ミーティングに詰め込むことはしなかった。
個々人のステータスは私が個々人の元へ出向いて聞き取っていった。チーム全体ミーティングでは、個々人のステータスのうち、全体に関係すると思われることを私から報告して、捕捉を本人からさせるようにしていた。上部組織からの情報もそのミーティングで伝えた。

 このような方法を取ることで、チーム全員を集めるきわめてコストの高いミーティングを必要最小限の時間で済ませることができた。その基本になるのが、上司自らが部下の元に出向いて話を聞くことである、と私は今でも信じている。

| | コメント (0) | トラックバック (0)
|

2006/10/29

言うウソ、言わないウソ

 携帯電話番号ポータビリティの開始にともない、ソフトバンクが “通話料・メール代0円” を大々的に掲げたサービスを発表した。さすが一代でここまでの地位を築き上げた孫氏である。発表のタイミングといい、キャッチフレーズのインパクトといい、凡人にそうそうできる技ではない。

 しかしながら、私はこの手の手法が “大嫌い” である。
確かに“通話料・メール代0円”はウソではないかもしれない。しかし、ケータイ Watch を読んでもわかるように、通常の使用を考えれば“通話料・メール代0円”になるはずがない。学術的に誤解を生じないようなキャッチフレーズであれば、“ソフトバンク携帯同士の昼間に限って通話料・メール代0円” となる。当然、こんなキャッチフレーズでは人目を引かない。

 私が会社に入ってまだまだ駆け出しだったころ、当時の上司にこう教わった。

「ウソを言ってはいけない。しかし、本当のことをすべて言ってもいけない。自分(自分達)にととって不利なことは、なるべく相手に知らせないようにする。」

会社に勤めていた頃は、この手法をよく使ってきた。ビジネスを自分に有利に進めるためにこの手法はきわめて有効であることも事実である。

 しかし、一個人、一消費者としてみた場合、意図的に知らせないことも “ウソ” である。タイトルに書いた “言わないウソ” である。 「言ってないのだからウソではない」 というのであれば、すくなくとも “誠実ではない”。だから私は大嫌いなのである。

 私の最寄り駅に “立ち食い寿司” なる店ができた。入り口にドデカク “にぎり一つ 75円” と書いてある。二つ頼むと150円となり、105円の回転寿司より高くつく。 「一種類一つずつ頼めば、一皿二つずつ乗っている105円寿司より、たくさん種類が食べられるな」 と思い、以前食事をしてきた。
入って驚いた。メニューにはっきりと 「注文は、一種類二つで二種類ずつお願いします」 と書かれていた。開いた口がふさがらなかった ( ゜д゜)ポカーン。 私からみれば、明らかに詐欺である。一つ75円ずつ注文できると思わせておいて、実は300円単位でしか注文を受け付けない。残念ながら、入ってから注文せずに店を出る図太さは私にはなかった。
例えば、“1リットル 120円” を出しているガソリンスタンドが、「うちは 100リットル 単位でしか給油してないんですよ」 と言い出したらどう思うだろうか? “サンマ 一匹 10円” とチラシに出したスーパーが、いってみたら100匹単位でしか売ってなかったらどう思うだろうか?

 それらは確かにウソは言っていないが、多くの人が考える常識から考えると、客寄せのためにやっていると思われても仕方がないであろう。そういうことを上記のソフトバンクや立ち食い寿司屋は実際にやっているのである。

 ソフトバンクの今回のサービスについては、いずれ何らかのゆり戻しがあると予想している。今後も同社の動向から目が離せない。

おまけ:

 そういえば、2chかどこかで一時話題になっていた話しがあった。
ニンテンドーDS Lite を転売しようとした人が、落札価格を抑えて手数料を少なくしようとしていた。その方法が、DS Lite の外側だけをオークションに出すというものであった。外側というの外箱ではなく、DS Lite のプラスチックの筐体のことである。もちろん、ほんとうに筐体だけを売るつもりはないらしく、+1万7千円ぐらいで中身をつけてお渡しする、とコメントに書いてオークションに出していた。
ところが、世の中にはいろんな人がいるものである。傷がつこうが、ばらばらになろうが、“筐体だけを希望” する猛者がいたのである。
出品者は、あわてて、脅したりなだめたりしたらしいが、落札者は頑として “筐体だけ希望” したらしい。
どういう決着がついたのか最後までは見届けなかったが、「自業自得だな」 と思った私はまだまだ人間ができていないと思った。

追記:

ソフトバンク、「0円」広告を修正へ

| | コメント (0) | トラックバック (0)
|

2006/10/28

テスティング -「毎朝五分ミーティングの薦め」 マネージャー、リーダーへの提言-

 提言シリーズの二回目である。
前回、「目的を明確に伝えよ」、と提言した。伝えるためには、伝える機会が必要である。そのための一つの手段が “毎朝五分ミーティング” である。

 これも私の成功例からの話である。
私がテスト チームのリーダーをしていたとき、会社が試験的にインターンを使っていたので、私のチームでも早速ヘルパーとして二人ほど来てもらった。インターンであるの当然まだ学生である。テスターの経験がない、ほんとうの駆け出しである。そこで私は、ひとりひとりをチーム内の中堅テスターの下に配置して、具体的な作業命令はその中堅テスターにしてもらうことにした。
その一方で、私とは毎朝五分のミーティングを持ち、そこでステータスの確認や疑問への回答などを行った。インターンには仕事を終えるときに、当日やった仕事を五分~十分で箇条書きにまとめてメールしてもらうことにしていた。翌朝の五分ミーティングでその仕事の確認と当日の作業予定、さらに疑問への回答や指示が不明確な部分へのサポートを行った。一方で、私のほうからは具体的な作業命令は出さなかった。命令系統が二つになることを避けたわけである。
これによって、インターンは何をすればよいかわからないといった不安な状態がなくなり安心して仕事ができるようになる。私も、配属させた中堅テスターが的確に指示を出しているかのチェックができた。

 わずか五分、一週間でもたかだか十五分(週三日勤務だった)。たったそれだけの時間で、テスティングの流れをまだ理解していないインターンに効率的に仕事をしてもらうことができたのである。これは、大きな成功であったと自負している。
(もっとも当時の私の上司はこのことを評価してはくれなかったが・・・ orz)

 半年後、そのときのインターンのひとりがその会社に入社してきた。

 さらにその二年後、プロジェクト内小プロジェクトをその元インターンが担当したという話を、私はずいぶん後になってから聞かされた。
元インターンは、私がやったことをまねて小プロジェクトを成功させることができて、チーム内でも高く評価された、と大いに喜んでいた。その小プロジェクトは、社員が元インターン一人で、後はアルバイトの学生や若者で編成されたらしい。リーダーとなった元インターンは、毎朝短時間のミーティングで常に全体のステータスの確認を行い、もし予定通りにいっていない場合は、状況に応じたスケジュールの変更を臨機応変に行ったらしい。それにより、無駄な作業の重複や巻き戻しがなくなり、スケジュールを伸ばすことなく、かつ、期待されていた以上の品質の製品を作ることに成功したといっていた。

 自分から学んでいった人間がいて、さらにその学んだことで成功を収めた、そして仕事の成功で自信を得た、という話を聞いて、私もまた一つ自分に自信を得た。

| | コメント (0) | トラックバック (0)
|

2006/10/27

一つのことは三度目に理解される

 以前からの私の持論なのだが、

『他人に自分の考えを正確に理解してもらうには最低三回同じことを繰り返し言わなければ通じない』

と思っている。

 これをイメージしてもらうと、

一回目: わかった部分とわからない部分が混在している。大半は忘れ去られる。

二回目: あれ?この話は以前にも聞いたことがあるぞ?と思う。一度聞いた話であるため、覚えている部分はスルーして、忘れている部分を保管する。

三回目: あ~、この話ね。と自分の記憶とすり合わせる。大部分を記憶しているため、聞いた内容を自分の解釈で記憶することができる。

となる。

 よく 「私に二度も三度も言わせないでよ!」 と怒る風景をドラマや映画で見かける。私も今よりもっとずっと若いころはそういって感情を高ぶらせることが良くあった。しかし、上の持論を悟ってからは、なにかこうあきらめのような気持ちとなり、何度も同じことを繰り返し言うことが苦痛ではなくなった。実は、子育てでこれがずいぶんと役に立っていたりする。

 さらに、他人から同意を得るためには、次の三段階が必要であると考えている。

1. 理解
まず、こっちのいっていることを理解してもらう必要がある。この段階で最低三回は話を聞いてもらう必要がある、というのが上の話である。

2. 納得
話を理解してもらったうえで、さらに話を聞いて生じた疑問などを解消する必要がある。もらった質問に適切に答えてようやく相手は、「なるほど、その話にはたしかに合理的な内容を含んでいる。」 と納得してもらうことができる。

3. 同意
最後に、話の合理性に賛同してもらう必要がある。ある局面では合理的であっても、状況が変われば、あるいは物の見方が違えば合理的でなくなってしまうことは良くある。例えば、今話題の“談合”は、談合をしている企業とその内部にとっては、利益を上げるという合理性があるが、外部から見れば自分達の税金を不必要に多く取得しているという非合理にうつる。自分の立場から主張しても合理的、相手の立場から聞いても合理的な状態にもっていって初めて同意が得られる。

 営業などの交渉ごとを仕事にしている人にとっては、ごく当たり前の話であると思う。論理的には契約までこぎつけるはずなのに、先方の担当者の 「気が進まない」 といった気まぐれで長い時間をかけてきた仕事がおじゃんになった、などという話も聞いたことがある。
しかしながら、製品開発の部隊にいて、社外の顧客どころか、社内的な調整や交渉にも無関係な仕事をしていると、上記のようなことを考えずに日々をすごすこととなる。
実際、私がテスターや仕様策定の仕事をしていた頃の同じチームの同僚には、説明や説得がほんとうに下手な人が多かった。しかしながら、チームで働いている以上、たとえ開発を専門にやっていたとしても、他人の同意をいかに上手に取っていくかは、大切なスキルである。自分ひとりですべてができれば、そんなスキルも必要ないが、今の製品開発でたった一人で最初から最後までをこなすことはまずないのだから。

 私の若いころの失敗経験からの、若い製品開発者への提言である。

| | コメント (0) | トラックバック (0)
|

2006/10/26

テスティング -「目的を説明してますか?」 マネージャー、リーダーへの提言-

 今回から “提言” シリーズを四回ほど行う予定である。
提言シリーズは、私が平社員としてマネージャーやリーダーから受けた “良い指導”・“悪い指導” を私なりにまとめたものや、私がリーダーであったときに “うまくいった指導”・“まずかった指導” を回想したものである。
内容としては、けっして “テスティング” に限ったものではない。しかしながら、タイトルに “テスティング” とつけたのは、私の “テスティング” に対する思い入れからである。また、話の内容もそのほとんどが私がテスターであったときの話である。

 初回は “目的説明の重要性” の話である。

 私がテスト・リーダーのときに採用した採用した社員が、私の次のテスト・リーダーのときに辞めた。辞めた理由は “寿退社” だったりする。で、辞めたあとに再び合って話をする機会があった。そのときに、

元社員
「マストさんがリーダーのときは、それぞれの作業の目的をきちんと説明してくれたので、とても作業がしやすかった。新しいリーダーになって、作業内容そのものしか説明されなかったので、仕事がすごく苦痛だった。」

という内容の話を聞いて、私はとてもうれしかった。「あ~、私の考えてやってきたことが間違っていなかった」 と。このことは、私の自信の一つであり、自慢の一つでもある。
ただし、余談ではあるが、その元社員が配属されてしばらくは、経験不足・知識不足ということもあり、本人にとってはかなり厳しい指導を私はしていたようであった。上記の話を聞いたときの前か後に、「仕事を始めたところは、作業内容が当時の自分にはとても高度だったため、毎晩夢の中で 『バグが出ない、バグが出ない (;´Д⊂)』 とうなされていたそうである。 |ヽ(。_ 。) ハンセー

 “目的の説明” は特別な話ではなく、ごく当たり前のこととして語られる。しかしながら、それを実践できているマネージャー、リーダーは私の経験からは少ないように思える。目的をきちんと説明するためには、本人がその目的をきちんと理解していなければならない。説明を “しない”・“できない” 多くの場合は、本人がよく理解できていないためであると思われる。理解できていないため自分の言葉では説明できずに、「これをしろ」、「あれをしろ」、「いわれたとおりにやれ」 となってしまうようである。
マネージャー&リーダー の マネージャー (上級マネージャー)がいったことを、そのまま部下に伝えるだけならば、上級マネージャーが直接全員に指示すればいい話である。そうしないのはそこに意味があるからである。同じ目的であっても、部署(プログラミング、テスターなど)によって作業内容は異なるし、アプローチも違ってくる。それを一番理解していなければならないのは現場の マネージャー&リーダー であり、彼ら/彼女らが自分の言葉で、作業目的、アプローチ、作業方法などを説明することが重要となる。

 目的が明確であると、具体的な作業がイメージしやすい。すべてのテストケースを通さないといけないのか、限定的で良いのか。先にやっておくべき作業がないのか。指示された作業内容が適切か。などである。
駆け出しか、ベテランかで、指示する作業内容の量が異なってくる。駆け出しテスターであれば、経験値が少ないため、目的を十分に理解させた後に、具体的な作業項目を指示していく必要があるだろう。目的:作業項目=50:50 ぐらいになろうか。一方、ベテラン テスターであれば、目的さえ明確に伝えておけば、場合によっては作業項目はあえていう必要もないと思われる。目的がわかれば、自然と作業項目が頭の中で組みあがるからである。もしかしたら、マネージャーやリーダーが想定していた作業よりも、適切で効率的な作業手順・項目を、担当テスターは組み立てるかもしれない。それも、目的が正確に理解されていることが前提となる。

 こんなへんぴなブログまでチェックしている優秀なマネージャー&リーダーであれば、上のようなことはおそらく当たり前のこととしてやっているであろう。また、上のようなことをあらためてやったほうがいいと思われる平均以下のマネージャー&リーダーであれば、こんなブログなど読んでいないと思われる。
 ということで、この提言はどちらかというと、「一生懸命働いていてもなんか働きにくい」、「自分のやっていることがほんとうに間違っていないのか不安である」、「なんのために今の作業をやっているのかよくわかっていない」 といった不満を抱える現場担当テスターに向けたものとなる。
 自分が、ちゃんと目的を理解していない、あるいは説明をきちんと受けていない、と考えるのであれば、上司に当たるマネージャーやリーダーにきちんと説明を求めてはどうだろうか? 一度ではダメかもしれないから、二度三度。優秀なマネージャー&リーダーであれば、きっと応えてくれるはずである。もし応えてくれなかったら・・・、そんなときはしょうがない。山にでもこもって、優秀な上司の下に移動できることを祈るしかないであろう。部下は上司を(ほとんどの場合)選べないのだから。
 ただし、時には、部下が上司を教育できる、あるいはする必要のあるときもある。そうするためにはかなりのコミュニケーション・スキルが必要なのだが。残念ながら、私にはそのスキルはなかった・・・。

| | コメント (0) | トラックバック (0)
|

2006/10/25

今日の鳥ハム(鶏ハム)

 今日作った鳥ハムは見事に失敗であった。塩気が明らかに足らなかった。どうやら寝かせる前にまぶす塩の量がゼンゼン足らなかったらしい。

 自分ではもう何回も作っているのですっかりわかっているつもりでいたので、肝心の塩をぱらぱらとしかつけていなかったらしい。その辺の記憶が待ったくない。

 食べられなくなったわけではないので、きちんと(私一人で)食べているが、食べる前に食卓におくタイプのハーブ塩を上からぱらぱらかけながら食べている。

 次はレシピどおりにおいしい鳥ハムをつくるぞ~。 (^o^)丿 ォー

 ちなみに、我が家の夕食のサイドメニューの定番(というかいつも置いてあるもの)は、

・ 鳥ハム
・ 黒豆
・ 寒天
・ ラッキョウ
・ 納豆(めかぶ入り)

である。
おもいっきりテレビで紹介されていたり、いろんなところで発掘されてあるあると大辞典で取り上げられそうなものばかりのように思えるのは、気のせいである。(汗)

 以前の鳥ハム
鳥ハム(鶏ハム) その後
鳥ハム

| | コメント (0) | トラックバック (0)
|

2006/10/24

洗濯機 -その後のカビワカメちゃん-

 前回、洗濯機の話をしたときは、ワカメ上のカビが取っても取っても出てくるという話をした。その後の話である。

 前回の投稿を書いた後、それからもしつこく100円ショップで売っている“洗濯槽クリーナー”やついには“カビキラー”にまで手を出すにいたった。しかし残念ながら、その後もカビワカメは遠慮する様子を見せなかった。

 ところが、あることをした以後、洗濯毎にカビワカメが減っていることに気がついた。そのあることとは “台所用漂白剤” である。なぜそんなものを使う気になったかというと、ナショナルが自らのホームページで使用を推奨していたからである。また、台所の排水口やまな板がカビで黒くなっているところに台所用漂白剤を使うときれいに黒ずみがなくなることも経験上知っていた。

 そこで、一週間ほど間をおいて、二回ほど台所用漂白剤を試してみた。確かに、漂白剤を使ってもカビワカメが大量に浮いてくることはなかった。
しかし、それ以後、洗濯物に付着するカビワカメが明らかに減っているのである。以前ならば、糸くずフィルターに大量にカビワカメがたまっていて、ほとんどの洗濯物のどこかにカビワカメが付着していた。私は洗濯物を干す前に強く洗濯物をふってからえもんかけにかけるくせがついており、全部の洗濯物を干し終わったあとは、床に20~30個ぐらいのカビワカメが落ちていた。それがここ一週間ぐらいは、糸くずフィルターには一つか二つぐらい引っかかっているぐらい。ほとんどの洗濯物にはカビワカメはついておらず、洗濯物1枚か2枚ぐらいに耳かすぐらいの小さなカビワカメが付着している程度である。床に落ちるカビワカメもほとんどない。

 あくまでも私の想像でしかないが、“台所用漂白剤”をつかったことで、付着していたカビが死滅して増殖しない環境になったのではないのか?と考えている。それまでの洗浄剤で大きなカビワカメが、その土台となっている石鹸カスと共に大量に剥がれ落ちたことは確認している。にもかかわらず、それ以後もカビワカメが出続けたのも、生き残っていたカビが私の想像を超える速さで増殖していたのではないかと想像している。我が家では、二日に一回のサイクルで洗濯しているので、その間の二日で増殖していたのではないかと。それが、漂白剤によってカビが死滅して、外から新しいカビの胞子が来るまで増殖しない状態になったのではないかと想像している。

 もちろん以前につかった “カビキラー” の効果ということも考えられるし、しつこく洗浄した効果がちょうどこの頃に出だした、ということも十分に考えられる。また、実質的にはなくなっていないが、黒ずみが消えて、白や透明なカビワカメが出ていて、私が気がつかないだけかもしれない。
いずれにしろ、カビワカメに悩まされることがなくなってほっとしている今日この頃である。

 なお、この投稿で “台所用漂白剤” の使用を推奨しているわけではない。台所用漂白剤はけっこう強力な薬品であるので、もしかしたら洗濯槽・洗濯機に気がつかないダメージを与えているかもしれない。(ナショナルはたんに“漂白剤”としか書いていない。) また、台所用漂白剤をつかったからといって、かならずカビワカメがなくなる保証はない。
試してみる場合はそのあたりを十分に理解して使っていただきたい。
私が台所用漂白剤を使ったときには、ビニール手袋・長袖・メガネ・マスク で武装をして、使用後はしつこいぐらいにすすぎをしたことをあわせて報告しておく。

| | コメント (0) | トラックバック (1)
|

2006/10/23

答えのわかりきった質問をしていませんか?(テレビ編)

 今回も “テレビ局批判” ネタである。いい加減うんざりしている人は、申し訳ありません。また、明日お越しください。m(_ _)m ペコリ

 テレビ番組、特に報道番組やワイドショーを見ていると、よく街頭インタビューをしているのをみせられる。あれが私にはとても不愉快に感じられる。

 まず、「答えを強制した質問をしていませんか?」ということ。
事故や事件で家族や親族をなくして悲しんでいる人に、なんの躊躇もなく 「今のお気持ちをお聞かせください」 とか 「犯人に対してどう思いますか?」 など、相手が決まった答えしか出せないような質問を平気でするテレビレポーター。彼ら・彼女らを見ると、ほんとうにテレビ局に属する人間は知的水準が低いとしか思えない。
“悲しい”、“憎い”、そんな気持ちは聞かなくてもテレビを見ている人は十分にわかっているのである。それをわざわざ質問することのどこに意味があるのか?

 そして、「賛成・反対、両方の意見をきちんと取り上げていますか?」 ということ。
少し前に “皇族に男子誕生” のニュースが流れたとき、放送されたインタビューはすべてとても喜んでいる人たち“だけ”であった。ほんとうにそういう人たちだけであったのだろうか?無関心な人は一人もいなかったのだろうか? 喜ぶ人たち“だけ”を意図的に放送するのであれば、「どうおもいますか?」 なんて質問は無意味である。「撮影しますので喜んでください。」と指示すればよいのである。

 いろいろなところで、“テレビカメラとマイクをもっていれば何をしても許されるとテレビ局は思っている” といわれている。意識している・していないはわからないが、私も、おそらくそう思っているだろう、と思っている。
少し前までは、テレビを中心としたマスコミがほぼ唯一の不特定多数への情報発信者であったので、おそらくそんな特権意識を持つようになったのであろう。しかしながら、いまや誰でも、自由に、不特定多数へ、情報を発信できる時代である。私もこのブログで不特定多数の人たちに発信している。
もちろん、信頼性の問題もあるだろう。インターネットに点在する多くの情報には信頼性がないかもしれない。それでも私は、ごく一部の人間によってフィルタリングされた情報より、自分で情報を見極めないといけないがフィルタリングされていない情報を多く含むインターネット上の個人からの情報を選択する。

| | コメント (0) | トラックバック (0)
|

2006/10/22

答えのわかりきった質問をしていませんか?(面接編)

 以前にも少し書いたが、私は自分のチームの欠員を補充するために、中途採用のための面接を150人くらいしてきた。そのときに会得した面接の仕方について書きたいと思う。
人事面接を実際に行う人はおそらく少数だろうとは思うが、もしかしたら、別な何かの参考になるかもしれないと思いあえて書いてみることにした。

 最も基本となるのは、タイトルにも書いたように 「答えのわかりきった質問をしていませんか?」 ということである。これは、時間の無駄になるし、こちらの知的レベルを低く見られることにもなりかねないので、“やってはいけない” ことの一つであると思っている。
具体的には、


  「当社で働きたいと思っていますか?」

 面接に来て 『働きたいと思っていません』 とは普通答えないだろう。 「はい、ぜひ働きたいと思っています」 とかえってくるのは目に見えている。とはいえ、150人のうち一人だけ 「いや~、人材登録していたら、『ぜひ面接を受けてみませんか?』といわれて、きただけなんですよ。今すぐに今の会社を辞めようとは思ってないんですけどね~」と“正直に”答えてくれた人はいましたが・・・ (^^;)。


  「年下の上司の元で働くことに抵抗はありませんか?」

 これも、就職したくて来た人には愚問である。「年下から命令されたくありません」などと、心に思っていてもいうはずはない。いえば、明らかに不合格にされるのがわかっているのだから。ただ、私の同僚にはこの質問をする人がけっこう多かった。まぁ、「そういうこともありますから、そのつもりで入社してくださいね」的な念押しで質問しているのだろうが、私から見れば余計な質問であることに変わりはない。


  「XXX の経験はありますか?」
 求める職種の経験を聞く質問であるが、やはり大きな意味はない。同じ単語であっても企業によって定義は異なる。また、経験があるからといって、自分の求めるスキルがあるとは限らない。
では、どう質問すればいいかといえば、実際に期待するスキルを証明させればよいのである。「OOO について説明してもらえますか?」 とか 「□□□ で △△△ を実現するにはどうすればいいですか?」 といった具合である。


 とにかく、「はい」 「いいえ」 で答えられるような質問はしないほうが時間の節約になる。何しろ面接の時間は限られているのだから。
それに、みんなが想定できるような質問は、特に人材登録会社経由で紹介された人に対しては、やはり意味がない。人材登録会社の想定問答集でけっこう受け答えの練習をさせられるからである。
「自分の長所は?」、「短所は?」、「これまでの実績は?」、「なぜ当社を選択されましたか?」、「当社のどのような点が気に入りましたか」、などなど。

 最後に、私がよく使ってきた質問を恥ずかしながら記述しておく。
私の面接はテスターの補充に対してであるから、質問も必然的にテスターを前提としたになっている。また、けっこう意地悪な質問でもあるので、時に仲介をしてもらった人材登録会社の担当者からクレームをいただいたこともあったことをあらかじめお知らせする。


  「この灰皿と同じものを言葉だけで電話の向こうの人に注文してください」

 以前にも書いたようにテスターは正しく表現できるスキルが必要であると考えている。ので、その場で始めてみたであろう物をきちんと言葉で説明できるか?を見た。もちろん正解はない。が、“材質”、“縦、横、高さの大きさ”、“色”、“重さ”、“特徴的な形状” などに気がつき、きちんと説明できればテスターの資質が高いと判断した。


  「駅から当社までの道のりを英語で説明してもらえますか?」

 もしかしたら、自分でもうまくできないかもしれない。(汗) ただ、私の勤めていた企業が米国資本で、英語によるコミュニケーションが重要であったのであえて“英語で”とした。英語が完璧でなくても、英語に強い拒否反応を示さなければそれほど気にしなかった。
また、30分~一時間前のことをきちんと覚えているか?、普段何気ないことを意識してきているか?、そしてやはり、相手に伝わるように正確に説明できるか?を見た、というか聞いた。もちろん正解はない。


  「あなたが一番好きなことはなんですか? では、その***の仲間になるように私を誘ってください。」

 これも場合によっては英語での説明をお願いした。
一番好きなことは何でもよい。パソコン、映画鑑賞、バイク、クルマ、スポーツ、音楽、とにかく、そのときに自分が一番はまっているものについて熱く語ってもらった。一番好きなことであれば、いろんなことを知っていて、そのことを雄弁に語れるハズである、と考えたわけである。強い説得力を発揮できる人であれば、バグを見つけたときにプログラマーをうまく説得できるだろうと期待したわけである。


 とにかく気をつけたのは、答えが自明でないこと、事前に想定問答集などで練習できないこと、である。

| | コメント (0) | トラックバック (0)
|

2006/10/21

ユーザビリティ・テスト -テストを見るときの心得-

 ユーザビリティ・テストは、自分の目で見ることが大切である。

 ユーザビリティ・テストを依頼すると、ユーザビリティ・スペシャリストが担当となって、目的・シナリオ・テスト・レポートまで、きちんと面倒を見てくれる(はずである)。
提出されるレポートを見れば、あまり時間をかけずに行ったユーザービリティ・テストの詳細を知ることができる。自分の時間を極力使わないようにするのも一つの方法ではある。しかしながら、私が思うに、それは非常にもったいないユーザビリティ・テストの使い方である。
実際にユーザビリティ・テストを行っているところを、リアルタイムで自分の目で確認することを、私は強くお勧めする。そして、自分でレポートがかけるくらいに細部にわたって観察をするのである。スペシャリストのレポートを当てにしないということではない。それぞれに異なる観点からテストを観察することで、一回のテストを何倍にも有効なものとすることができるのである。

 以前にも別な何かで記述したことがあると思うが、「言葉や文章にすると、知っていること や 思っていることの半分から八割しか伝わらない」 という制約がどうしてもレポートには付きまとう。より100%に近い理解を得ようとすればやはりその現場に立ち会うのが一番である。
開発担当者 と ユーザビリティ担当者 の立場の違いを具体的にいくつ列挙してみる。

・ テストしているソフトのことは、開発担当者がよく知っている
 ユーザビリティ担当者も、担当者としてそれなりにテストするソフトウェアの目的や使い方、現状での問題点などをまず理解するが、短時間ですべてを理解することはできない。そのソフトウェアを一番よく知っているのは、やはり開発担当者である。(というか、『でなければならない。』)
そのことが何を意味するかというと、ユーザビリティ担当者では気がつかない開発側が想定していない使い方を被験者がしたときである。 「あれ? あの機能はそんな使い方を想定していないぞ?」 とか 「それを実現するにはそっちじゃなくてこっちの機能を想定していたのだが」 ということがよく起こる。そういう細かいしかしもしかしたら重要な問題は、やはりそのソフトウェアに精通している開発担当者でなければ気がつきにくい。

・ その場で被験者に何を考えていたか質問することができる
 上と関連する話。シナリオにない、ごく当たり前の操作で、被験者がよそしていなかった操作をしていたとき、「なぜその操作方法を取ったのか?」 とか 「普段からその方法を取っているのか?」 とかの質問ができる。こういった細かい情報は意外と貴重である。
多くのユーザビリティ・テストでは、テスト全体をビデオにとっていることが多いので、あとから見ることも可能であはある。しかしながら、疑問に思っても被験者に質問するわけには行かず、何よりライブ感のない映像を見続けるのは意外と苦痛である。

・ 落ち込むことができる
 というのはへんな言い方であるが、リアルタイムに自分の予想を被験者が裏切り続けるとほんとうにへこむ。もし、テスト結果でユーザビリティが極めて悪いといった結果を、ユーザビリティ担当者のレポートで知った場合、人というのは不思議なもので、ついつい、ユーザビリティ担当者を疑ってしまう。「ちゃんと見ていなかったんじゃないか?」 とか 「勘違いしているんじゃないか?」 とか。しかし、自分でリアルタイムにその被験者の言動を見聞きしていた場合、それはもう疑いようがない。そして、その結果をレポートで出されても素直に信じられるし、信じられないほかのチーム・メンバーを説得する側に回れる。これは重要なことである。


 ユーザビリティ・テストに立ち会うのは確かにたいへんである。かなりの時間をとられるためである。おそらく仕事を山のように抱えているときに、ユーザビリティ・テストを二時間じっと見ているのは、もしかしたら落ち着かないかもしれない。
しかし、もしユーザビリティ・テストを行うのであれば、多少無理をしてでもテストに立ち会って欲しい。それまで自分や自分の周辺だけでは気がつかなかった多くのことのうち、いくつかがかならずユーザビリティ・テストから得られるはずだから。

---------------
 ユーザビリティ・テスト については、今回でひとまず終了です。またなにか書き残したことを思い出したときに随時投稿する予定です。

| | コメント (2) | トラックバック (0)
|

2006/10/20

私の風邪予防法

 毎年冬になると決まって風邪をひいていた。まず喉の痛みから始まり、せき、鼻水・鼻づまり、発熱、下痢、嘔吐、最後にバタンキューである。一冬に一回、多いときは二回ぐらいやっていた。

 ところが昨年は一度もバタンキューすることなくすごすことができた。何をしたのか?

 ほとんど常時マスクをつけていたのである。もちろんカッコウはよくない。寝るときも、マスクをして寝た。途中で知らずに外していることも多かったが。
喉の痛みから風邪が始まることはわかっていたので、ならば喉が痛くならないようにすればどうか?と考えたのである。そのために、常にマスクをつけるようにして喉を乾燥させないように考えたのである。また、湿度が高いとウィルスが繁殖しにくいという話をよく聞いていたので、「喉にウィルスがついても繁殖しないようにしちゃる」と考えた。(この件に関しては何の根拠もない。私の思い込みである。)
ちなみにマスクの役割は、ウィルスを吸い込まないようにすることではなく、口内の保湿や保温である。

 今年はさらに首を冷やさないように心がけている。具体的には、常時首にバンダナやハンドタオルを巻きつけておくのである。
去年、薬局で薬をもらうときに 「首を温めるとよい」 と何度も聞かされた。インターネット上でしらべてみても、喉の温度が高いと、喉の内部の繊毛運動が活発となり、細菌類を外に押し出す働きが活発になるらしい。

 そのほかにも、タンや鼻水は積極的に体外に排出するように心がけている。
今年も大風邪をひかないで過ごしたいものである。

| | コメント (0) | トラックバック (1)
|

2006/10/19

ユーザビリティ・テスト -活用法-

 ユーザビリティ・テストの有効な活用法について少しだけ書いてみる。

 まず、一番大事な “テストをする側の心構え” について書いておく。
ある意味、この心構えがテストを有意義なものにするか、無意味なものとして金と時間を無駄にしてしまうかの分かれ目となる。
その大切な心構え、それは、

  “被験者の行動をすべてありのままに受け入れる”

ことである。
「なんだ、当たり前のことじゃん」 と思われるだろうが、実はこれがけっこう難しい。私も被験者の行動をそのまま素直に受け入れられるようになるまで、毎週ユーザビリティ・テストを見続けて三ヶ月かかった。
どういうことかというと、“自分が考えに考え抜いて” て、“ユーザーにとって一番使いやすい” 形に仕上げたと自負した製品である。ところがテストをしてみると、被験者はこちらの想定した使い方をしてくれない。使い方がわからなくてまごまごしている。最初の頃はいつも 「ちゃんと使える被験者を連れてこんかい!(ノ`д´)ノ彡┻━┻」 と一人で騒いでいたものである。
ところが三ヶ月ぐらいたったあるとき、ふと 「あれ? もしかして被験者が悪いんじゃなくて、被験者が使い方に困るような仕様にした私が悪いの?」 ということに気がついたのである。私の中でユーザビリティ・テストが有効に働きだしたのはそれ以降であった。自分の仕事を妄信して、目の前の現実を受け入れられない間は、ユーザービリティ・テストをしても何も得られないということを覚えていて欲しい。


 短時間で確認できる問題の確認に向いている。
一般人 (パソコンに慣れていない人に被験者になってもらうことも想定してあえてこう呼ぶ) に参加してもらうことを考えれば、それほど長時間テストすることはできない。1被験者、2時間 というのが平均的な拘束時間と思われる。一般におとなが集中できる時間は15分、断続的に行って45分 と何かで聞いたことがある。と仮定すれば、一つのシナリオが15分で終わらせることができことが、効率のいいテストを行える条件となる。たとえ2時間拘束しても、2時間目いっぱいテストできるとは思わないほうがいい。休憩をのぞいた実時間で考えれば1時間前後であろう。

 被験者の行動を見て、こちらが判断できる問題の確認に向いている。
たいていの機能はそうなっているとは思うが。例えば、つかってみて被験者が心地よく使えたか? をしらべるのはけっこう難しいと思われる。なぜなら、人はほんとうのことは言わない(というか言えない)からである。別にうそをついているわけではない。以前にもにたような話を投稿しているが、ユーザーは無意識のうちに自分をかばうような話をしてしまう。テストをしているこちらは、「できない」 「わからない」 とはっきり言ってほしいのだけれど、被験者側には、“うまくできなかった。恥ずかしい” という思いが出てしまうことが多く、また、こちらに気を使って、あまり否定的な意見が出てこない。あるいは、自分の考えを上手に表現できない場合も多い。
被験者は本音を話してくれないことを前提に、テストを見ている側が 「あ~、今わからずに悩んでいるな」 とか、「あ~、この機能は使いづらそうだ」 とかを、被験者の行動から読み解く必要がある。それゆえに、被験者の行動からその機能への被験者の評価が読み取れないようなテストは、行ってもあまり得るものがない。

 製品がターゲットにしている被験者を集める。
実は被験者を集めるのがたいへんである。被験者には、当然、製品がターゲットとしているユーザー層から来てもらわなければ意味が薄い。
私が携わっていた製品はパッケージ・ソフトウェアであり、ターゲットとするユーザー層は、不特定多数のパソコン初心者~初級者であった。そのユーザー層は、パソコンそのものにはそれほど興味がないため、ユーザビリティ・テスト被験者の募集をパソコン関連書籍やパソコン関連サイトかけても引っかかってこない。
パソコンの利用に長けている、中級車~上級者であれば、人材派遣会社などから単発の仕事としてきてもらうことは容易であるが、こちらの売り込みたいユーザー層とは異なるため、テストをしてもこちらの欲しいデーターが取れない。
社内や特定の業務の人たちにつかってもらうことがわかっているソフトウェアであれば、実際にその人たちに声をかけてテストすることができるので、被験者集めは比較的容易となる。

 最後に一つ面白い実例を。
新しいバージョンで、製品内で使っているアイコンを刷新すべく、外部のデザイン会社にアイコンの作成を依頼した。そのときに、納品の条件として “私のやっているユーザビリティ・テストで、十分にわかりやすいアイコンであると確認できること” というつけさせてもらった。
そのときのテストは、選択方式でやってもらった。左にアイコン、右に機能の説明をそれぞれランダムな順番に置き、機能にはアイコンが存在しないダミー選択肢も入れた。被験者には、なるべく直感でアイコンと機能を関連付けしてもらった。
作ったアイコンは何回かに分けて提出することになっていた。一回目に提出したアイコンのユーザビリティ・テストしている日に、たまたま二回目のアイコンの提出にデザイナー本人が来社していた。そこで、せっかくのチャンスだからと少し時間を割いてもらって今まさに行われているユーザビリティ・テストを見てもらった。
私は既に何回か見ていたので、一回目のアイコンが実はあまりわかりやすくなくて、ほとんどの被験者は正しく機能とアイコンを結び付けられないことを知っていた。一方のデザイナーは自分のデザインに自信満々で、最初のアイコンデザインで納品が完了するものと信じていた。
実際のテストが始まった。やはり被験者は機能の説明から正しいアイコンを選ぶことができない。デザイナーの顔色がみるみる変わっていったのを今でもはっきりと覚えている。結局、くるときには自信満々の顔をしていたデザイナーは、テストを見て、会社を出るときには、かなり落ち込んだ状態で帰っていった。そのぐらいユーザビリティ・テストの結果は非情なのである。
その後、そのデザイナーには相当がんばってもらい、最後にはほとんどの被験者がアイコンから正しく機能を選択できるようになった。また、そのあと数年してから、同じデザイン会社の別なデザイナーの方とお会いすることがあり、そのときの話をする機械があった。その別なデザイナーの話では、当時、私の製品のアイコンを担当したデザイナーは、日夜七転八倒しながらデザインをしていたということであった。
当時のデザイナーさん、お疲れ様でした。m(_ _)m ペコリ

| | コメント (0) | トラックバック (0)
|

2006/10/18

自己防衛 その2 -社会的自己防衛-

 前回書いた自己防衛は、主に物理的な話だった。社会的な自分については、言及しなかった。
そんなときに、例の “三洋電機社員のP2Pによる情報流出事件” がおこった。概要については、こちら を参照されたい。(一部の人たちには “○○○バーガー事件” として知られている。あまりにも下品な表現なのでここでは伏せさせていただく。)

 これを聞いて、改めてネット社会における自己防衛の大切さを痛感した。
だいぶ前に、元国税局職員がやはりファイル共有ソフトで私的な写真を流出させている。その写真にもやはり当時付き合っていたであろうと思われる彼女との私的な写真が含まれていた。そのときは、写真以外の情報から流出した本人の名前と所属が明らかになったわけだが、写真に写っていた女性の身元の特定まではいたらなかったと記憶している。
一方今回は、ミクシィに公開されていた情報との関連ができてしまった。情報を流出させた本人ではなく、付き合っていた彼女の身元までが特定されてしまったわけである。
一度、インターネットに放出された情報を完全に抹消することは不可能であることは、インターネットを使っている人ならおそらくは理解しているだろう。これは、とてつもなく恐ろしいことである。インターネット普及以前であれば、広く報道される情報は、新聞・雑誌・ラジオ・テレビなど、ほとんどすぐに消え去る媒体であった。図書館などで新聞・雑誌が保存されているとはいえ、それをすべて個人が保管しているケースはまず通常は考えられない。膨大な物理的スペースを必要とするためである。仮にもっていたとしても、そこから目的の情報を探すことはきわめて困難である。このことは、一年やもしかしたら一ヶ月前の事件で掲載された犯人の顔写真を見つけることさえこんなであることを示している。
一方、インターネットで流される情報はデジタル化された情報であり、個人の所有するパソコンに簡単に保存できる。しかも、キーワードさえ覚えていれば簡単に見つけ出すことができる。

 今回の事件に関していえば、女性のほうの被害が圧倒的に大きい。変な言い方になるが、社会的に重傷あるいは重態となる負傷をおったと思える。
このような事件に巻き込まれないようにするためにはやはり普段からの自己防衛が大切だと思うのである。不用意に名前・メールアドレスなどを公開しない。書かれた住所・氏名・電話番号を棄てるときはシュレッダーにかける。街中で安易にアンケートやインタビューにのらない。などなど。
私の子供は小学校の低学年ながら既にパソコンを使い始めている。検索サイトを使い、わからないことをしらべたりもしている。そのときにへんなサイトに引っかからないように、改めて指導をしたり、そもそもあやしいサイトが表示されないような設定になっているかの確認を行った。

 被害にあってから、加害者の責任を追及したり、加害者に賠償してもらったところで、傷を負った心や体が元に戻るわけではない。重要なのは被害にあわないようにすることである。
当たり前のことなのだが、当たり前であるがためについつい忘れてしまうことでもある。であるから、こういう機会に常に自己確認、自己確認するしだいである。


| | コメント (0) | トラックバック (0)
|

2006/10/17

ユーザビリティ・テスト -その有効性と限界-

 ソフトウェア・テスティングについては、一通り言いたいことは書いたつもりなので、いったん終わり。
今回から数回に分けて “ユーザビリティ・テスト” について書いていく予定である。

 “ユーザビリティ” という言葉を聞いたことのない人も多いと思う。日本語に訳すと “使い勝手”、“使いやすさ” といったところか。より詳しい解説については、フリー百科事典『ウィキペディア(Wikipedia)』 を参照されたい。
その “ユーザビリティー” を評価するのが “ユーザビリティ・テスト” である。

 私は、数年間いくつかのパッケージ・ソフトウェアの仕様の策定を担当した。そして、仕様を策定するにあたり一番活用したのが “ユーザビリティ・テスト” である。
ユーザビリティ・テストでは、まず “検証したい目的” を定める。“入力のしやすさ” とか、“起動から文書作成完了までの時間”とか、“使おうとしているアイコンのわかりやすさ”など、目的は多岐にわたった。
次に、その目的を検証するための “課題” を設定する。ここで大事なのは、こちらの意図を、課題を実行する被験者に気づかれないようにすることである。こちらの意図を読まれてしまった場合、被験者は普段のやっている使い方でわなく、こちらの意図に沿った使い方をしようとしてしまうことがあるためである。課題は例えば“入力のしやすさ”では、入力する文字や文そして入力場所などを指定する。入力する文字には、わざと読めない漢字や入力が難しい記号などを織り交ぜておく。
課題が決まれば実際にテストを行う。テストは、課題をこなす被験者に来てもらう。テストを行う場所には被験者のみにいてもらう。テストを行う者は、被験者の行動をマジックミラー越しやテレビモニターを使い、別室で監視する。被験者への指示はマイクを通した音声のみで行い、行動を制限するような指示をしたり、テストの意図を気づかれるような受け答えは行わない。
被験者は3人いれば有意義な結果が出せるらしいが、私のいた会社のユーザビリティーチームでは、一つの課題に対して5~6人のテストを行った。
テストが終了したあとは、テスト担当者が得られたデータに基づいた“分析”、“問題点の指摘”、“問題点改善のための提案”をレポートにまとめて、開発チームへ報告する。開発チームはそのレポートを検討して、実際にできる範囲での改良を加える。
必要があれば、改良が加わった後の製品についても同様のテストを行って、改善の確認を行う。

 私は、ユーザビリティチームのテスト担当者ではなく、開発チーム内においてユーザビリティーチームと協力をして製品の改善を行っていく立場であった。よって、ここでの話も、ユーザビリティ・テストを製品改善のための手段の一つとして用いるための話となる。
ユーザビリティ・テストの技術的な話や、実際にユーザビリティ・テストを行いたいときは、別なサイトを参照されたい。何人もの優秀なユーザビリティ専門家がそれぞれに有用なサイトを立ち上げているので検索して探してみることをお勧めする。

 ユーザビリティ・テストを何回か経験すると、『すべての問題をユーザビリティ・テストで見つけて、それから仕様を決めて、ユーザビリティ・テストで確認すればいいじゃん』 と勘違いするときがある。げんに私がその一人であった。しかし、何事にも向き不向き、適正というものがある。例えば、F1レーシングカーはサーキットでは確かに市販の乗用車など及びもつかないほど速く走れる。しかし、市街地でF1レーシングカーが乗用車より速く目的地につけるとは思えない。
ユーザビリティ・テストではっきりとわかることは 『問題がある』 ことがわかることである。その製品を使う上で使いにくいところがあれば、ほとんどの被験者がその部分でつまづくため、すぐにそれとわかる。
逆に、ユーザビリティ・テストでは、『問題がない』 ことは証明できない。いくら被験者全員が問題なく課題をクリアしても、製品を購入したすべてのユーザーに問題なく使ってもらえるかといえば、それは定かではない。

 それではユーザビリティ・テストをやるのはムダなのか?といえば、もちろんそんなことはない。
「問題がありそうだ」 と 「問題があることがはっきりしている」 では、製品を改善する上でのモチベーションが違ってくる。また、問題を修正させるときのプログラマーへの説得力の強さが違ってくる。
また、ユーザビリティ・テストを行っていると、ときおり課題を作って検証しようとした以外の問題が見つかることがある。ただし、これはタナボタ的な効果であって、『なにか問題がないか?』 と未確認の問題を見つけるためにはユーザビリティ・テストは適さないので注意されたい。
以前のユーザビリティ・テストの結果と比較することで、問題が改善されたことの確認は取ることができる。例えば、同じシナリオの課題がより短い時間でクリアできるようになったとすれば、改善されたと見ていいだろう。

 私は現役のときに、ユーザビリティ・テストを活用することで、多くの問題を確認して、また改善してきた。時には自分達より大きなマーケットシェアを持つ競合他社が次バージョンでまねをするような仕様を、先駆けて世に送り出したりも出来た。
製品開発に携わっている人が問題解決に行き詰ったときなどには、ぜひユーザビリティ・テストを活用して、より使いやすい製品を世に送り出してもらいたいものであると願うものである。

| | コメント (0) | トラックバック (0)
|

2006/10/16

プリンターを買いました (Canon PIXUS iP7500)

 前回、プリンターがなかなか決められない、と投稿した。その後も、あれこれ考えて、先週末ようやく購入した。
各情報サイトが今年のプリンターのレビューをやってからとも思ったのだが、まったく印刷が出来ない状態というのなかなか不便なので、カミさんからのプレッシャーもあり購入に踏み切った。

 購入までの私の頭の中の展開は以下のようなものであった。

1. 壊れた PM-900C を修理しようか?
PM-900Cは私にとってはよいプリンターであった。よく言われる印刷速度の遅さも、そんなに大量に印刷しなかったので気にならなかった。写真画質は十分に満足できるものであった。プリンタドライバーも細かいところまで設定が出来て私好みであった。インクカートリッジは一体型であったが、カラー6色で実売1500円は、最近主流の独立タンク一式に比べればずいぶんと安い。
しかしながら、去年やはり年末が近づいてから紙送り部分が壊れて修理に出していた。約一年で今度は印字ヘッド部分の故障である。エプソンによると PM-900C の修理対応期限が 2007年9月 になっている。1年後である。修理費用は、1万500円+輸送料+部品代である。おそらく2万近くかかると予想した。
であれば、その2万円を新プリンター購入に当てたほうがいいと考えたわけである。

2. エプソンにしようか? キヤノンにしようか?
いろんな掲示板を読むと、写真画質がいいのはエプソン、という意見が大半であった。一方のキヤノンは印字速度、印字ヘッドの目詰まりの少なさ、印字ヘッドが交換可能、という利点をあげる人が多かった。
PC Watch の 2005年モデルの印刷サンプルを見ても確かにエプソンのほうが写真画質はよいと感じた。写真画質優先な私としてはやはりエプソン優先で考えていた。

3. 複合機か? 単機能機か?
エプソンもキヤノンも販売の主流を複合機においているようであった。単機能機の価格下落が著しい状況においては、付加価値を高めて価格を維持しようという戦略であることがわかった。おかげで、単機能プリンターのラインナップが変に偏っているように思われた。
我が家では印刷物のスキャンは取り立てて必要ないと思われた。ただ、印刷物のコピーはときおりコンビニに行ってやっていたので、家でコピーが出来ればそれなりに便利になるのかな?と考えた。何より複合機であっても、昔と比べれば十分に価格が安くなっているのが魅力である。6年前にPM-900Cを買ったときは5~6万円した記憶がある。今は、複合機の最上位機種でもそこまでの値段はしない。
ということで、複合機で考えてみることにした。

4. 最新機種か? 型落ちか?
エプソンは今年は更なる写真画質の向上をうたい文句にしてきた。私にとっては魅力的である。キヤノンは写真が質についてはそれほど大きな進歩は内容であった。
一番の売りにするぐらい画質が向上したのであればやはり最新機種かな?とエプソンの2006年の最新機種にターゲットをあてることにした。

5. でもちょっと待てよ?
価格.コムによると、2006年モデルと2007年モデルを比較すると、なんと倍半分の価格差があった。(@_@;)
ここで、「ちょっと待てよ? ということは、2007年モデルも来年にはこの値段に下がっているのか?」 と思い至った。上位機種の場合、5万円と2万6千円の違いであった。実に2万円以上の差である。
「ということは、今年旧機種を買えば、来年に今年の新機種を買ってもほぼ同額の支出になるな?」 と考えたわけである。

6. で結局 Canon PIXUS iP7500 に落ち着いた
2005年モデルを買って、もし気に入らなければ来年2006年モデルを買うことに決めた。来年買い換えることも考慮すると、今回買うプリンターは比較するためにもキヤノンにすることとした。で、もしキヤノンで満足できないようであれば、2006年エプソンモデルが安くなった来年に買い足すつもりである。

 実際に購入をしたのは、ヨドバシカメラのAkihabara店であった。たまっていたポイントも使い1万5千円弱で購入することが出来た。

使用感:
エプソンに比べればドライバーのつくりがキヤノンのほうが甘いというか、手を抜いているというか、使い方がわかりにくい感じであった。
肝心の写真画質は、PM-900Cと比べてもやや劣る印象を受けた。ただし、紙との相性もあり、PM-900Cでも納得がいく組み合わせを見つけるのに半年ぐらいかかったと記憶している。
しかしながら、何よりも驚き、気に入ったのは細かい機能が充実しているところである。

・ 電源の自動オン・自動オフができる。
・ 前面給紙ができる。
・ 前と後ろで二種類の紙が同時にセットできる。
・ CD/DVD に直接印刷できる。
・ 自動両面印刷ができる

特にこの五点が気に入っている。
これだけのプリンターが1万5千円で買えるようになったというのは、ほんとうによい時代になったものである。

 当面はこのプリンターと付き合って、年末の年賀状を印刷する予定である。また、なにか気がついたことがあれば随時ここにレポートする予定である。

追記:

プリンター iP7500 使用レポート

プリンター iP7500 光沢紙比較レポート (前編)

プリンター iP7500 ICMを使った印刷 (前編)

| | コメント (0) | トラックバック (1)
|

2006/10/15

テスティング -雑談:腎臓誤廃棄-

 こんなニュースを読んだ。ソフトウェアでいえばこれはバグである。責任者のコメントが、

「恥ずかしい限りで、予想もしていなかったこと。」

である。つまり、予想していなかったところが、検証されず、重大なバグで致命的な問題が発生した。そういうことである。
テレビ報道では、「移植用とかかれていなかったが、関係者であれば、移植用のクーラーボックスであることが一目瞭然のはず。」 といっていた。しかし、実際に問題は起こった。私にはその発言は責任逃れの言い訳にしか聞こえない。

 ここ数年医療事故がある程度報道されるようになった。急に医療事故が増えたのではなく、たんに以前は隠されて報道されなかっただけだと思っている。
“医者や看護師は、国家免許を持った専門家であるから間違いなど起こさない” などと思って仕事をしているのだろう。医者であろうが看護師であろうが、プログラマーであろうがテスターであろうが、人間である以上かならず間違いを起こす危険性がある。だから、その間違いを確実に拾い上げるシステムを構築する必要がある。個人個人の努力に依存して、問題があったときにその個人の責任にするだけでは、問題は解決しない。

 ソフトウェア作成に置き換えれば、“プログラマーの間違いを拾い上げるためにテスターおよびテスティングが存在する”。では、テスターの間違い(“見落とし” や “勘違い”) は誰がひろってくれるのだろう? 結局、テスターをカバーするのもテスターしかいない。つまり、テスターの作業を多重化することである。はなはだ無駄な作業のように見えるかもしれないが、安全性の向上のために、時には重複した作業が必要になる。
私がチームを受け持ったときによく使った手法は、“機能別テスティング” と “操作別テスティング” を分けて行うことである。例えば、“印刷”をテストするとき、印刷に限定してさまざまな既存のファイルをひたすら印刷するテストと、ファイルの新規作成→入力→編集→保存→終了→開く→編集→印刷 といった実使用シナリオにそったテストを時期を離して行う。時期を離すのは、一度テストしたところが他のプログラムの修正によって影響を受けたときの対策である。

 テスティング作業を多重化したとき、二度目の作業では見つかるバグの数はかなり少なくなる。(逆にたくさん見つかるようでは問題である。) そのわりに、二度目の作業量は一度目とそれほど変わらない。一見すると無駄に見られてしまうような作業をきちんとプロジェクトの作業予定に組み込めるのか?ということが問題である。平均以下のプロジェクト・マネージャーだと、明示的には組み込まないが、必要な作業としてテスター個人の努力に押し付けるようとする。テスト・マネージャーの腕の見せ所である。

| | コメント (0) | トラックバック (0)
|

2006/10/14

男脳・女脳

 定期的に届けられる “リビング むさしの” に、男女のすれ違いを、脳の働きの違いによりわかりやすく説明している特集があった。読んでいて 「あ~、あるなあ」 と思ったことがいくつもあった。

・ 夫婦ゲンカ
“女脳流の自由な議論は、男脳では理解できない”
「(前略)、説得力を増すために、過去から未来、直接は関係ないコトにまで、自由に話を操ります。ある意味で理論を越えた飛躍的な展開は、・・・(中略)・・・。理解を超えて、寝るしかなくなってしまいます。・・・(後略)。」

 私はカミさんとそれほど激しいケンカをすることはないが、それでも時々カミさんが切れてケンカになる。最近の例だと、使ったものを元の位置に戻すように “お願い” をしたら、「忙しいんだからそんなのいちいちやってられるわけないでしょ! やってほしいならあなたがやればいいじゃない! だいたいあなたは ※§@☆◎▽♂♀・・・」 と始まったわけである。私とすれば、何でその程度のことで切れなきゃいけないのかいまだに理解できないでいる。それも男脳には理解できない女脳の逆鱗に触れたからなんでしょうかね?
  ---------------

・ 妻のグチ
“男脳はグチを解決したくなるから、聞いて欲しいだけのグチはツラくなる・・・”
「『痛い・ツライ・苦しい』というグチは、相乗以上に男性にショックを与えます。女脳はそのグチに対して『ヨシヨシ、がんばった』と共感して欲しいだけなのに、男脳は『目の前の事例を解決しなければ』と責任を負ってしまうのです。年配の夫婦で妻が『脚が痛い、腰が痛い』と言い続けていたら、夫がうつになってしまったというケースも。(後略)」

 これはすごく実感のわく説明である。カミさんがほんとうに共感して欲しいだけなのかはよくわからないが、「目の前の事例を解決しなければ」 という気持ちは実によくわかる。自分では、その “解決義務感” を、企業で訓練されてきたある種の “職業病” のように感じてきたのだが、脳の違いによるものであるという説明は 「なるほど、そういうこともあるかもしれない」 と思わせる。
ただ、うつにさせられてしまうとしたらヤダなーと思った。
  ---------------

・ お色気好き!?
“男脳は、クルマも女性もメリハリボディーが好き”
「(前略)。女性を目で追ったり、女性の部下にごちそうするのは、女性がホテルのロビーで「この花のアレンジはステキね」と振り返る感覚と同じ。(後略)」

 私もついついきれいな女性を眼で追ってしまう。(ご馳走をおごったこともないし、クルマには全然興味がないけど。) それに、たしかにホテルの花には目が行かない。幸い私は、他の女性を眺めてカミさんに突っ込まれたことはないけど、突っ込まれたときはこの説明で逃げることにしよう。
威張れる話ではないが、私は服装に無頓着である。自分の服装だけでなく他人の服装を気にすることもほとんどない。ところが、カミさんはいつも他人の服装を観察しているようである。自分の服装や私の服装にまで常にチェックしている。私が変な服装で出かけようとすると、とたんに激しいツッコミが炸裂する。それなんかもロビーの花と同じなのかもしれない。(いやいやそれは違うと思うぞ ヾ (゚Д゚ )…ツッコミ)

| | コメント (2) | トラックバック (0)
|

2006/10/13

トイレタイム

 『“テレビCM崩壊”時代、ネット広告の役割とは』という記事を読んだ。
「テレビCMの効果が薄くなってきたと今になって言われるが、テレビCMは前から“トイレタイム”と呼ばれていたではないか」
という書き出しを読んで、「そうだった、そうだった」 笑いながら、いきなり納得してしまった。実際、私はほとんどテレビCMを見なくなった。テレビそのものを見なくなったということもあるし、テレビ番組を見るときもリアルタイムで見ることはほとんどない。見るときは一度ハードディスクレコーダーに録画してから、CMを飛ばしつつ最短の時間でテレビ放送を見ている。

 私は以前より、今の電波による無料テレビ放送のビジネスモデル、にはかなり批判的である。また、そういう立場でこれまでも何度か投稿してきた。公共の資源である電波を独占的に使い、社会的な地位や経済的な恩恵を独占してきている既存のテレビ局やそれに癒着している広告代理店、制作会社、タレント事務所などは、今この瞬間にも解体して欲しいくらいである。無料放送ということになっているが、高い番組制作費=高い広告料は、結局、広告を出している会社が提供しているテレビ番組を見ていない、その会社の製品の購入者にも回されているだけなのである。

 映像コンテンツを電波を使ったテレビ放送でしか配信できなかった時代ならまだしも、今はいろいろな映像配信技術が既に確立している。ケーブルテレビもある、インターネット配信もある。そんな時代において、地上デジタル放送への切り替えがほんとうに必要なのだろうか? 私には、既得権益者である既存のテレビ局やその周辺の既得権維持のためにやっているようにしか見えない。
「ケーブルテレビやインターネットが普及していない地方を切り捨てるのか!」 と言い出す人たちが必ずいる。そんなものは、地方にそれらを普及させればいいだけである。そちらの投資のほうが他にも流用できる投資だし、日本全体を地デジ化するよりも安く上がるように思うのだが。既存のものを残すことのみを主張するのは、その既存のもので何らかの恩恵を受けている人に違いない、というのが私の思い込みである。
「地方を切り捨てるのか!」 というのは、反対するときの常套文句になっている。国鉄民営化、そして郵政民営化のときもそうであった。そして、少なくとも国鉄民営化は、地方路線の廃止であるとか問題を生み出しつつも、全体としてみれば、赤字垂れ流しから利益確保へ、民営化が正しかったことと私は確信している。

 「既得権を守って何が悪い!」 といわれそうだが、私は既得権を守ることが悪いとは思っていない。私の持論である 「人は自分が満足するようにしか行動しない」 に照らし合わせれば、自分のもっている既得権を守るのは当たり前の行動であり、私もそれ自体は悪いとは思っていない。
私もただ、自分を満足させたいだけである。自分を満足させるためには、私の周りにも満足した人が多いことが重要となる。ごく一部の人の既得権は、その限られた人たちを満足させて、その他の多くの人を不満にする。だから私は既得権の必死に守ろうとすることに否定的なのである。

| | コメント (0) | トラックバック (0)
|

2006/10/12

ポケモン スタンプラリー 2006

 今年の JR東日本 ポケモン スタンプラリー の全駅完全制覇の景品が届いた。ポケモン スタンプラリー 2006 とは、JR東日本がこの夏に行ったイベントである。首都圏にある98駅にそれぞれ違ったポケモンのスタンプが押してあり、専用のスタンプ帳にすべて押して回るというイベントである。

 私の子供も私も今年が始めての参加であった。
始める前、私は 「ま~二日もあれば十分だろう。あわよくば1日で」 と考えていたが、これがまったく甘い考えであったことは、始めて数時間で思い知らされたのであった。
山手線から離れるに従い、電車の発車時間が急にあくのである。山手線であれば、電車から降りて、改札を出て、スタンプを押して、改札から入り、ホームにたどり着くと、次の電車がホームに入ってくる、そんな感じであった。ところが常磐線などは10~13分に1本しか電車が来ないため、10分ぐらいホームでボーっとさせられたのであった。つまり、1時間に5本しか走っていない路線では、1時間で5駅しかスタンプを押すことが出来ない。これに気がついたのは、もうほとんどのスタンプを押したあとであった。常磐線だけで16個のスタンプがあるということは、そこをクリアするだけで3時間以上かかる計算になる。スタンプがおかれていたのが、9時半から16時の6時間半しかないことを考えれば、常磐線だけでほぼ一日かかってしまう計算である。

 結局、すべてのスタンプを押すのに五日間かかった。しかも、8月の暑さ中。しかも、半分の駅では階段でのぼりをりをした。毎日、500mlペットボトルを3本は消費した。
全部のスタンプを押したスタンプ帳を事務局に送ると、最後のご褒美 “全駅完全制覇認定証” と “JR東日本オリジナルポケモン腕時計” がもらえる。それが 10月7日に届いた。

Pokemon

100円ショップでも売っていそうな腕時計に、雑貨屋で10円で売ってそうなカード・・・。はっきりいって、見た瞬間かなり _| ̄|○ ガックシ きた。これの返送料として400円分の小為替までつけたというのに・・・。
交通費に1万円以上使ってやったのにこれはないだろう、JR東日本 ヽ(`Д´)ノ。

 結局、

  全98駅のスタンプを押すのにかかった日数 ・・・ 五日間
  五日間にかかった交通費            ・・・ ¥13,000-
  完全制覇の景品の送料             ・・・ ¥400-

  子供と汗水たらした五日間            ・・・ ぷらいすれす

ということなんですね・・・。そうですか・・・ (´・ω・`) ショボーン

| | コメント (0) | トラックバック (1)
|

2006/10/11

テスティング -テスターの心得-

 今回は、テスターの心得、心構えについて書いてみようと思う。
なお、記述している順番は、優先順位ではない。たんに私が思い出した順番というだけである。

 まず、悪役になるつもりでいること。
バグという相手の欠点を声高に訴えなければいけないという点で、テスターというのは損な役回りである。伝え方を間違えると、簡単に恨まれ役、憎まれ役になってしまう。
そうならないためには、常日頃からプログラマーとの交流を図り、プログラマーの揚げ足をとっているのではなく、プログラマーがあとで恥ずかしい思いをしないようにお手伝いをしている、というようなことをちゃんと伝えておくことが重要である。
そうは言っても、不興を覚悟で大量のバグを報告しなくてはいけない場合もある。そんなときは、自分が悪役になって憎まれ役になる覚悟が必要である。プログラマーに気を使い、見つけたバグも報告できないようでは、プログラマーを一時的に満足させられても、プロジェクト全体から見ればきわめて危険である。

 次は、プログラマーの言うことを鵜呑みにするな。
私の経験だけから言うと、お世辞にも優秀とはいえないプログラマーほど、変に根拠のない自信をもっている。曰く、「私の書いたプログラム完璧である。バグなどない。」と。しかし残念ながら、そういったプログラマーが書いたプログラムにこそ、それこそ山のようにバグが見つかるものである。優秀なプログラマーは常に慎重であり、常に自分がバグを作っているのではないかと不安をもっている。
大昔の話であるが、ある製品の最初、二番目、さらに三番目のバージョンで私は同じ機能のテストを任されていた。担当したプログラマーはバージョンごとに違っていた。三番目のバージョンを開発しているある日、三番目のプログラマーが私のところに来て、「機能を実装したのでテストして欲しい。私は過去のバグをきちんと把握して、二番目のバージョンの反省を生かして、まったく別なプログラムを書いたのでおそらくほとんどバグはないでしょう。特に同じよなバグはありません」 と自信満々であった。そこで私は早速テスト段階のプログラムをテストしてみるとはたして・・・。出るわ出るわ、一番目、二番目で行ったテストを、三番目のバージョンでテストしてみると、違う人が違うプログラムを書いているにもかかわらず、なぜか一番目や二番目とおんなじバグが見つかるのである。私はおかしくておかしくてしょうがなかった。
また別な日には、私が見つけたバグの話をしにきた。「これはシステムのバグだよ。俺のじゃないよ。80~90%の確率でシステムの問題だから、俺は治せないよ。」 といってきたのである。そこで私は、「それじゃ~、どんな風にシステムに問題があるのか報告しなくちゃいけないので、調べてもらえないかな?」 とお願いした。数日後、再び同じプログラマーが私のところに 「ゴメン。この間のバグ、やっぱり俺のバグだった。(^^ゞ」 と言いに来たのである。
それらの経験から私は、「プログラマの言うことを鵜呑みにしちゃいけないな~。ちゃんと自分で確認するようにしないといけないな。」 と学習したのである。上述のプログラマーもそこでずいぶんと反省したようで、以後は自信過剰になることなく、きわめて優秀なプログラマーとして、今も第一線で活躍している。

 上記の事例は別なことも示唆している。それは、プログラマーとテスターがうまく協調していければ、お互いにすばらしく成長することができる、ということである。
プログラマーとテスターというと、どうもよくない関係になる話をよく聞く。強い敵対関係となり、互いにののしりあうような関係。プログラマーがテスターを従属させて、テスターがプログラマーに気を使いながらのテストを強いられる。などなど。
テスターはプログラマーとうまい協調関係を築くべきである。プログラマーとテスターがうまく協調すれば、プログラムの品質は飛躍的によくなると、経験上から私はそう信じている。

 仕様を鵜呑みにするな。
プログラマーと同じく、仕様を絶対正しいものと信じてはいけない。仕様を作っているのは人間である。人間であればどこかに間違いはつき物である。
間違いといっても、1.仕様そのものに矛盾があったり、抜けがあったりする誤り、と 2.仕様が想定されるユーザーの要求を満たしていない場合の二種類ある。
1.については、論理的な思考があれば比較的簡単に気づくことができる。一方の 2.については、自分自身がユーザーの要求をきちんと理解していないと気がつきにくい。このことから、テスターも仕様策定者と同等かそれ以上にユーザーの要求を理解している必要がある。

 ユーザーやサポートの話をよく聞く。
私の場合、パッケージソフトに参加していたため、一般ユーザーからの問い合わせをサポートチームから聞くことが出来た。多くは、マニュアルに書いてあったり、ユーザーの勘違いであったりする。しかし、極稀にとても有用な、問題の本質を鋭く突くような質問をしてくるユーザーがいる。そういうわずかな鋭い質問を自分テストに生かすことでプログラム全体の質を上げていくことができる。
また、サポートと親しくすることには別の意味もある。サポートの人たちは当然製品を作っているわけではないので、製品の細かい部分や成り立ちを知らない場合が多い。そこで、製品開発に携わっているテスターが製品の細かい部分をサポートの人たちに教えてあげるのである。すると、サポートの人たちの知識レベルが上がり、一般ユーザーへの対応の質も上がってくる。サポートは一般ユーザーとの接点であることを忘れてはいけない。サポートの質が上がれば、バグや使い方がわからないことで製品に失望しかけているユーザーに、逆に満足感を与えることも可能となるのである。ユーザー間のコミュニケーションを軽く見てはいけない。小数の満足したユーザーがより多くの製品選択に影響を及ぼすことは十分にありえるのである。

 見つけたバグはすぐに報告する。
ゆめゆめ、あとでまとめて報告しよう、などとは思わないほうがいい。バグは速く直せば直すほど規模も小さく時間もかからずに直せる。もちろんバグを作らせなければ、バグの修正にかかるコストも時間も0である。
出荷間際になるとついついバグの報告を躊躇してしまうテスターがいる。「なぜ、今まで見つけられなかったのか?」 などと叱責されることを恐れたり、今まさに出荷しようとしているのにそれに水を差しかねないバグを報告することに、二の足を踏んでしまうのである。
冷たい言い方になるが、その程度のことを恐れるようならテスターをやめたほうがいい。最初に言ったように、テスターは時には悪者にならなければいけない。また、出荷直前に致命的なバグを見つけたからといって白い目で見られるようなチームからは早いところ抜けたほうがよい。
出荷してからバグを修正するのと、出荷を延期してでも出荷前にバグを修正するのでは、コストやブランドイメージの損失に桁違いな違いが出る。もちろん出荷後のほうが損失がはるかに大きい。
見つけたバグは、その大小にかかわらず、きちんと確認を取って、速やかに報告できること、がテスターにとってのだいじな資質の一つである。では、確証がすぐに取れない場合はどうすればいいのか? 簡単である。プロジェクトのリーダー、場合によっては全員に相談すればいいのである。例えば、「どうやら XXX なバグがありそうなのだが条件が見つからない。心当たりのある人は教えてください。」 といったぐあいである。

 聞きに行きやすい人ではなく、答えを知っている人に聞きにいけ。
こればテスターに限った話ではない。疑問が生じたときに、いつも決まった人に聞きにいくテスターがいる。それも、自分と同じぐらいの知識レベルの人にである。自分が知らないのだから、たいていは聞かれたほうも知らない。知らないもの同士が 「あ~なのか、こ~なのか」 と無駄な時間をすごしているのをよく見る。
確かに聞きに行きやすい人というのはある。しかし、それを優先していては時間を浪費するばかりである。疑問を持ったのなら、知っている人、あるいは知っている人を知っている人に真っ先に聞きにいくべきである。
「いや~、あの人なら知っているだろうけど、聞きにいくと怒鳴られたりいやみをいわれたりするんだよね~。」 との言い訳をよく聞く。バカ者である。疑問を解消することが最優先なのだから、怒鳴られたりいやなことをいわれたりすることを理由に時間を無駄に使うべきではない。この場合、「急がば回れ」 ということわざは当てはまらない。

 これ以外にも普段から心がけていたことがあったような気がするが、今は思い出せない。また思い出したときに続きを書くことにする。

 ソフトウェア・テスティング の個人的な文書にしにくいこと、あまり専門書などには書かれていなさそうなことは数回に分けて一通り書いたつもりである。私は現場を離れてしばらくたつことから、最新の技術的なことについては、最新の書籍や他の現役のテスターのブログを見てもらったほうが参考になるはずである。
次回からは、数回に分けて “ユーザビリティ・テスト” について書く予定である。

| | コメント (0) | トラックバック (0)
|

2006/10/10

アメリカのレストランでの注文の心得

 なんどもアメリカに行っている人には当たり前だろうけど、アメリカのレストランで注文するときには少々コツがいる。まあ、コツというほど大げさなものではないのだが。
そこで、今回は私が自分で会得した私なりの心得を紹介したい。


 その1: アメリカのレストランではパスタは注文するな
アメリカ人に “アルデンテ” は理解できないと思え。アルデンテを出されたアメリカ人は、「このパスタは、まだ茹で上がっていないじゃないか ヽ(`Д´)ノ」 と怒り出す。つまり、アメリカで出されるパスタは、ゆですぎのべろべろでのびきった麺となって出てくる。


 その2: 普通のレストランでは味に期待するな
高級レストランではもちろんおいしいものが出てくる。しかし、普通のレストランでは期待すると必ずガッカリすることになる。私が説明でよく使う言葉、

 『アメリカのレストランで出る料理は、“素材の味がしない” か “素材の味しかしない” のどちらかである。』

素材の味を生かして深い味わいがある料理、といものについぞ出会った記憶がない。


 その3: 自分の適量は値段で決めろ
アメリカのレストランで出る料理の量は、料理が違ってもだいたい値段に比例する。$10の料理は、おおよそ$5のほぼ2倍ある。
一番笑ってしまったのがある日本レストランで出された “うな重” である。

 『並:乗ってるウナギが1本、 上:乗ってるウナギが2本、 特上:乗ってるウナギが3本』

をいをい、特上・上・並 の違いは質じゃなくて量かよ ヾ (゚Д゚ ) といっしょに食べに行った友人と小声で突っ込んでました。


 その4: テリヤキは注文するな
アメリカではなぜかテリヤキがはやっている。中身は当然 牛、豚、もしくは鶏 である。しかし、日本の照焼きを想像して注文をしてはいけない。あれはまったく別な物体である。
タレがしょうゆベースの和物ではない。プリンの上からかけるとカラメルとか、リブロースステーキに絡めてあるソースのような、みょうに甘ったるいタレがかけてある。要注意である。

| | コメント (0) | トラックバック (0)
|

2006/10/09

テスティング -テスティングの勘所-

 “勘所” というとなにか漠然とした感じがする。そして、今回の内容も漠然としたものになっている。申し訳ない。

 ここで言う “勘所” とは、「なんとなくこのへんがあやしい」 「このへんにバグが潜んでいそうだ」 という、どちらかというと非論理的な推察をいう。であるからして、あまり論理的に説明できない。
ただ、たしかに経験を積み重ねていくと、バグがありそうな場所が “見える” のである。某超有名ロボットアニメの主人公のように。(^^ゞ

 まず、一般的な話としては、よくバグが発生する条件というものがある。

“境界条件”: 例えば、あるエディットボックスで 1~10 のみを許容する仕様としたときの、0や11。65536 (2の16乗)など。
“文字コード問題”: 今はあまり使われないが、ShiftJIS のときの 0x5c など。昔はこれでよく文字化けしたものである。
“ストレス下”: 物理メモリやシステムリソースを使い切ったときの挙動。動作が極端に遅くなるのであまりやりたくないテスト。自動化テストがお勧め。ただし、自動テスト ツールが先に根負けする場合あり。(汗)
“巨大ファイルの読み込み”: データベースは別として、ワープロとかスプレッドシートの場合、1GB とかの巨大なファイルを読み込んでみる。これも自動的にやらせるのがお勧め。

これ以外にもいくつかの条件がある。
慣れたテスターであれば、まず真っ先にこういった条件でテストをするようになる。

 ある意味ここからが本編である。
ソフトウェアも人間がくみ上げるものであるから、バグの出方にも当然個性が出てくる。あるプログラマーは偉ー処理を軽視する。別なプログラマーはルーチン処理でよく無限ループにはまってしまう。などなど。
(余談になるが、少し前にやはり某超有名ロボットアニメの世界を使った MMORPG のベータに参加していた。そこで新しい機能が実装されるとまったく違う関係のない機能であっても、なぜか毎回似たようなバグが組み込まれていた。そのことから私は、その MMORPG の実装を担当しているのが実は一人なのではないかと予想していた。)
話を戻そう。バグのくせを見つけるためには、まずプログラマーの性格を知ることが重要となる。そのために私はよくプログラマーに話を聞きにいった。仕様をどう理解しているのか、その理解をどういうアルゴリズムで実装しようとしているのか、自分でも自信がないところ、などなど。雑談を織り交ぜながら、しょっちゅう話を聞きにいった。
これの問題は、やりすぎるとプログラマの邪魔をしてしまうところである。また、周りからプロジェクトの邪魔をしているやつと見られてしまうことである。それを回避するためには、やはりきちんとバグを見つけて、報告して実績を示すことである。そうすれば、「あ~、あいつはあーやって多くのバグを見つける努力をしているんだな」と見てくれるようになる。
そうやって、担当プログラマの性格=実装パターンが見えてくればしめたものである。某超有名アニメの腐海に遊びにいく主人公が風が見えるように、目の前のソフトウェアにバグが見えるようになってくる。

| | コメント (0) | トラックバック (1)
|

2006/10/08

地デジ、血出ジ?

 あいかわらず、地上デジタル放送、通称 “地デジ” の宣伝が盛んである。「2011年に今の地上アナログ放送が終了しますのでご協力を」、とおっしゃっている。

 勝手である。
アナログ⇒デジタルへの各家庭での切り替え費用をすべて、テレビ業界で負担するならまだしも、すべて個人負担である。納得がいかない。
デジタル化で一番得をするのはテレビ業界と一部の映像マニアである。大多数の国民にとってはたいした意味はない。にもかかわらず、負担だけは押し付ける。納得がいかない。

 「主導している経済産業省の幹部に間でも『2011年のアナログ停波は間に合わない』と既に言っている」、といようなあやしい噂も聞く。
PSE法も、最後は結局国民の反発で骨抜きになっちゃったし、ほんと国家公務員I種試験合格者の優秀な方々は何をやっておられるのかと・・・。

 前にも書いたけど、テレビ放送で電波を使うのをやめればいい。今は光ケーブルによるインターネット接続もずいぶんと普及が進んだのだから、テレビ放送をしたいのならインターネットで配信をすればいい。新しい受像機を必要とするという点では地デジとなんら変わらないと思うのだが・・・。
まあ、自分に限っていえば、テレビ放送はどんどん見なくなっているので、このままアナログ放送が停波になって、そのままテレビ放送が見られなくなってもたいして困らない気がする・・・。

| | コメント (2) | トラックバック (0)
|

2006/10/07

テスティング -テスターの条件-

 前回は、私が考える、“テスティングとは何か?” について書いた。
今回は、テスティングをする人 “テスター” について書きたいと思う。どういうスキルや気質をもっている人がテスターとして成功するのかを、あくまでも “私の主観” で書いていく。
ここで対象としているのは、テスト手法やテスト方法を自分達で考えてテストするテスターである。与えられたテストデータに基づいて、ひたすら手順どおりに作業をしていくテスターは、申し訳ないが私はテスターとはみなしていない。

 まず、必要な能力は何か? コンピューターの知識? プログラミングの知識? テスティングの基礎知識? それらもあったほうがいいが、私から見てそれらの優先順位は低い。
一般論から言えば、一番必要なのは “体力 と 気力” である。(爆) 某人気アニメ風に言えば “努力 と 根性” である。製品開発が最終局面に達すると、どうしても力技、人海戦術に頼らざる終えない場面が出てきてしまう。(そういう状況をよしとする姿勢は私は好きではないのだけれど) それらを乗り切り、そのときに頼りになるのが “体力 と 気力” である。これらなくして製品の完成はかなり難しいと思われる。

 ちょっと脱線した。話を元に戻そう。
私が考えるもっともテスターに必要な能力、それは 『物事を正確に相手に伝えることができる』 能力である。
バグは見つけただけで終わりではない。バグは直さなくては終わりにはならない。私が説明しているモデルでは、バグを直すのは、テスターではなくプログラマーである。テスターはプログラマーがバグを再現できるようにきちんと説明する必要がある。再現しないバグは、そのバグが存在していない、ことと同じ意味となる。
手順は? 再現環境は? OSは? インストールしているプログラムやドライバーは? などなど、確認すべき項目は多い。それらをきちんと特定して、他の人にきちんと再現させ確認させる必要がある。これはけっこうたいへんな作業である。プログラマーとして優秀でも、こういった作業がきちんとできるとは限らない。この意味では、テスターはプログラマーより優秀でなければならない。

 次に大切なこと、それは 『ものの見方が柔軟である』 こと。「マウスはマックのように1ボタンでなければならない」 といったように 「OOO は XXX でなければならない」 的な発想では質の高いテスティングは望めない。
ユーザーは時に、開発者がまったく想定していない使い方をするものである。想定をしていない = 作りこみをしていない = テストもしていない = バグが発生する、という構図になる。
テスターは、画面を見て、実際に使ってみて、それをどういう風に使うことができるかを想像できなくてはいけない。そして想像した使い方を実際にテストしてみてバグがないことを確認しなければいけない。もっといいのは、想像した使い方を仕様を見た時点で気がついて、仕様に盛り込ませることである。

 コンピューターに興味があることも重要な能力である。「好きこそものの上手なれ」ということわざがあるように、好きなことであれば積極的に仕事をすることができるし、周辺も含めて多種多様な知識を持つこともできる。
ただし、行き過ぎて特定のエリアにのめりこみすぎると、本末転倒になりテスターには不向きになる。たとえば、3Dベンチマーク至上主義とか。

 プログラミング知識は、私はテスターには必ずしも必要ではないと考えている。
プログラミング知識があったほうが有益な場合も多い。オートメーション テスト ツールを作れたり、プログラマーの視点からバグが出やすい条件にめぼしをつけられたり、プログラマーに成り代わってバグの箇所を見つけたり、プログラム コードを見ながらテスト条件を決めていったり。
一方で、プログラミング知識があるために、気づかぬうちにテストが偏ってしまう(このプログラムはこう動かすと思い込む)傾向を何度か目にしてきた。

 次回は “テスティングの勘所” について書いてみる予定である。

| | コメント (0) | トラックバック (1)
|

2006/10/06

Everything all right?

 10年ちょっと前、1年半ほどアメリカで生活をしていた。そのときの面白い話である。

 アメリカにも少数ではあるが日本語を学んでいる人たちがいる。
その日はたまたま夕食を食べに行ったレストランで、日本語を勉強中というウェイターが担当しているテーブルに当たった。

 アメリカではウェイター・ウェイトレスは店から支払われる賃金だけではなく、客が置いていくチップも重要な収入である。そのため、各ウェイター/トレスには担当テーブルが決まっていて、そのテーブルをサービスする代わりにそのテーブルのチップをすべて得ることができる。だから、担当でないウェイター/トレスにいくらお願いしても何もやってくれないのが当たり前。逆に、担当のウェイター/トレスはより多くのチップが欲しいから全力を挙げてサービスをする。

 サービスの一環なのだろう。注文した品がそろい、食事を楽しんでいると、ころあいを見計らってウェイター/トレスが
 “Is everything all right?” とか “Is everything OK?”
とか聞きに来る。
日本のファミレスであれば、「ご注文の品は全部おそろいでしょうか?」 みたいなものである。

 ところが、その日のウェイターは日本語を学んでいた。私たちが日本人だと知ると、盛んに日本語を使って話しかけてくる。
そして、品物もそろい、食事を楽しんでいると、そのウェイターが来て

 「ダイジョウブデスカ?」

私たちは ∑( ̄□ ̄;)ビックリ。
もしかしたら、なにか異物を混入させてしまったのか? はたまた、痛んだ食材を使った料理を出されてしまったのか?などなど、私たちはお互いに顔を見合わせながらどきどきしてしまいました。
しかし、よくよく確かめてみると、注文した品が全部そろっているかの確認をしにきただけらしい。どうやら

 “Is everything all right?” ⇒ 「すべては大丈夫ですか?」 ⇒ 「ダイジョウブデスカ?」

と直訳(?)してしまったらしい。なんとも人騒がせな・・・。
もちろん食中毒などのトラブルは一切なかった。(笑)

 しかし、よくよく考えてみると、自分が英語を使うときに同じ間違いをしている危険性は・・・、すごく大きい。
気をつけねば・・・。_| ̄|○
そういえばその昔、英会話教室の先生に 「ピーナッツ」 と言ったら、日本語式に “ピー” にアクセントを置くと、アメリカ人には 「ペニス」 に聞こえるから注意しろって言われたっけ。
大学のときの化学の教授は、イギリスに行って “ウェスト ケンシントン” まで切符を買おうとした、駅員にぜんぜん通じなくて、隣のイギリス人が “ウェスギケンシン” といって切符を買っていたので、まねして 「上杉謙信」 といったら切符が買えたといってたな~・・・。
言葉って難しい・・・。

| | コメント (0) | トラックバック (0)
|

2006/10/05

テスティング -ソフトウェア・テスティングとは?-

 今回から不定期に何回か、『ソフトウェア・テスティング』 についてかきたいと思う。
系統立ったテスティングの手法については、最近は多くの優秀な書籍が出版されているのでそちらを呼んでいただきたい。私が書こうと思っているのは、書籍には書かれにくい、ノウハウとか勘所といったものである。もともと文章にしにくい類のものであるから、どこまで伝わるかははなはだ疑問ではあるが、今テスティングに従事している人たち、これからやってみようという人たちに少しでも参考になればと思う。

 最近は多少 “ソフトウェア・テスティング” が取り上げられるようになったものの、私から見るとまだまだテストが軽んじられているように思われる。
極論ではあるが、テストを十分に行わないソフトであれば、そのソフトは発売しないほうが徳である、とさえ思っている。最近でも、NTTのIP電話がつながりにくくなる事故が起こっていて、原因の一つがソフトウェアの不具合といわれている。地名的な不具合を持つソフトを発売(もしくは使用)することによって、企業にかえって多額の損失を与えることがいかに多いことか。
ソフトウェア開発会社の経営者や幹部にはプログラマー上がりが多いことが問題の一つであるように思われる。多くのプログラマーと話をしてみると、その大半の人たちが 「プログラミングをしてソフトウェアをくみ上げれば製品ができる」 と思っていた。テストは、駆け出しプログラマーが丁稚奉公でやるものであり、できればやりたくないもの、といった印象を強く受けた。
ソフトウェアに限らず、外部からの検査を受けない物や組織がとんでもない事態や事件を引き起こすことは珍しいことではない。ソフトウェア・テストは、製品を売ろうと思えば、プログラミングと同じに重要なことなのである。

 プロフィールにも書いたとおり、私は6年ほどパッケージソフトウェアのテスティング業務に従事してきた。6年やるとそれなりに“ノウハウ”や“勘”といったものもたまってくる。ただ、残念なことにそういったものは文書化しにくい。高度な文才をもっていれば可能なのかもしれないが、いかんせん私にはその技術はないようである。

 さて、今回は 「私がテスティングをどう思っているか」 について書きたいと思う。

 私がソフトウェア製作を説明する上でよく使う例えが “三権分立” である。
“仕様の策定(スペック)”=立法、“仕様の実装(プログラミング)”=行政、“仕様の検証(テスト)”=司法
となる。つまりテスティングとは、裁判所の仕事に当たる。
テストというと、実装(プログラム)のミス=“バグ”を見つけることが仕事であると思われる場合が多い。しかし、私にはそれよりも、“仕様(スペック)のミス” を見つけることのほうがより重要と思われる。なぜか? ソフト制作においては下流工程に行くほど修正が大規模になり時間もコストもかかってしまう。マスターディスクを作ってからの修正は、コード修正・再ビルド・総テスト・マスターディスクの再作成、ととんでもない労力を要する。それが、仕様段階の修正なら、文章をちょいちょいと書き直すだけで済む。とても簡単である。

 では、どのように仕様をテストするのか?
仕様の策定者が仕様を考えているときから、その頭に入り込んでいっしょに仕様の穴を埋めてあげることである。そのためには多くの経験を積んで、頭の中でその仕様が実際にコンピューター上で動く様子をシミュレートできなければ、よい助言は与えられない。
また、仕様段階でバグをつぶしていけばいくほど、実際にプログラムを動かしてテストする段階で出てくるバグが少なくなり、テスターとしての評価が難しくなる問題もある。しかしそれについては、「何件のバグを出したか」ではなく、「何時間で(見つけたバグの修正も含めて)テストが完了したか」 を評価すべきである。もちろん、すべての仕様および書かれたコードをテストしたという前提で。テスト量が同じであれば、バグが見つからなかったほうが絶対にコストが安くすんでいるはずなのだから。

『バグは、見つけるよりも、作らせないことが重要』

という形にテスティングは進んでいくべきであるというのが、私のテスティングというものの考えである。

 次回は、「テスターの適正」 について書いてみようと思う。

| | コメント (9) | トラックバック (1)
|

2006/10/04

テレビといじめと

 前回に引き続きテレビ放送に対する批判である。

 テレビ放送のバラエティ番組ではよくいじめられ役がいる。無視されたり、物をぶつけられたり、罰ゲームをさせたれたり、熱いおでんを無理やり口に入れられたり・・・。
その番組では、それらはあらかじめ決まっていたことであり、いじめられたほうも自分が長くテレビに映ることになることがわかっているので、「おいしい」 とかいって喜んでいる。
また、発言力のある大物タレントやその番組のメインとなるタレントに対しては、露骨によいしょをしておもねる。

 前回も言ったことであるが、テレビ放送というのはいまだに影響力が大きい。それゆえに昔から放送する内容には気をつけなければいけなかったはずである。しかし現実には、殴る蹴るなどさんざんいじめるシーンが子供も多く見るであろうバラエティ番組によく出てくる。
現実と虚構の区別がいまだついていない子供達にとって、こういう映像はきわめて危険である。少しでも気後れしていたり、周りと少し違う雰囲気をもっている友人に対して、バラエティ番組と同じ行動を取る危険がある。つまり、いじめたり、おもねったり。
もちろん、親の教育、家庭内での教育が重要なのはいうまでもない。しかし、自分の子供の頃を考えればわかるように、いくら言い聞かされたとしても、親や教師の目の届かないところではとんでもないことをするものである。

 であるからして、テレビ放送ではこういった “いじめ” や “おもねる” といった表現を禁止すべきなのである。
公共の資源である電波を使い、公共性を公言するテレビ局であるならば、そのぐらいの規制をしても当然であるように思われる。もちろん、違反した場合は高額な反則金、最悪の場合は免許取り消し。
自分でも 「ずいぶんと乱暴なことを言っている」 なーという自覚はある。しかしながら、今のテレビ番組の多くを見るとそうでもしなければ収まらないくらいに子供への、場合によっては社会全体への悪影響が心配される表現が数多く見られる。

 「“有限である”電波資源を有効に活用するために地上デジタル放送への切り替えが必要である。」 とほんきで思っているのであれば、むしろ電波によるテレビ放送をすべて終了すべきである。一部の人たちにだけ利益が転がり込むような “電波によるテレビ放送” およびそのビジネスモデルは、結局今の既得権を保護するだけのような気がする。
もう少しましな状況にもっていくのであれば、テレビ放送をすべてインターネットなどのネットワーク配信として、有限の数しかテレビ局を認可できないシステムを破棄すべきである。テレビ放送業務にさまざまな企業が自由に平等な立場で参加できるようにすべきである。

| | コメント (6) | トラックバック (0)
|

2006/10/03

テレビは営利企業である

 前回もマスコミとしてのテレビ局を批判した。今回はテレビ局に特化した批判である。

 「テレビ放送は事実確認をして、正確な情報のみを放送している。法律で規制されているため、公正な立場で放送している。」 という発言をたまに聞く。
こういう発言を聞くと、私はとても不愉快になる。

 一連のやらせ事件により、テレビ放送に多くの間違った情報が入っているのは、もはや多くの人にとって常識である。
NHKの資金流用事件、およびライブドアや楽天のテレビ局買収事件により、自局にとって不利な情報はほとんど放送しないという人たちのどこに公正さがあるというのか。弱者に対しては徹底的に攻撃をするが、権威や国家権力に対しては都合のよい報道しかしない。その行動のどこに公正さがあるというのか?
マイクとテレビカメラを突きつけて、さも自分達が唯一無二の正義のような顔をして発言を迫る。そして、自分達の描いたシナリオにはない発言は黙殺する。

 そもそも、私はテレビ局のもつビジネスモデルが極めて不快である。
国民の共有財産である有限な電波を独占的に使い、多額の利益を上げている。噂でしかないが、テレビ局の社員の丘陵はかなり高額だと聞く。また、トップクラスのタレントの出演料は、1時間当たり500万円という噂も聞いたことがある。
どこにその財源があるのか? それは今のテレビ放送のビジネスモデルにある。
今の日本では、テレビ受像機(+アンテナ)というハードウェアを購入すれば、ほぼ無料で簡単にテレビ放送を見ることができる。テレビ放送は映像情報であり、情報量が多くわかりやすいため、多くの人たちが好んで視聴する。何しろほぼ無料なのだから。当然影響力も多くなる。多くの大衆を相手にした企業においては、その大きな影響力を営業に使いたいと思うであろう。ところが、テレビ放送は一部の企業に独占され、完全な売り手市場である。テレビ放送への広告費は当然のごとくうなぎのぼりとなる。影響力の大きさを考えれば、高い広告費も広告を出したい企業にとっては安いものである。製品価格に転嫁すればいいのであるから。そうやって、公共資源を独占的に使うテレビ局だけが楽に儲けられるビジネスモデルが出来上がった。

 インターネットの普及にともないテレビ放送の影響力が相対的に弱くなったといわれている。それまで独占してきた不特定多数への情報の発信権が、インターネットにより個人でもできるようになったためである。それまでは、不特定多数に自分の情報を発信しようとすれば、テレビ、ラジオや新聞の力を借りなければならなかった。しかしそれでは、彼らの偏ったフィルターに引っかかってしまい自由に発信することが出来なかった。
今はブログも広く普及してきて、個人による情報発信がいっそう簡単になりつつある。裏づけのない情報が流されることの怖さももちろんあるが、それよりも私は、一部の偏った人たちによってフィルタされた情報のみが流通するよりも、フィルタされない生の情報が流通することのほうが重要であると考える。

 繰り返しになるが、テレビ局は単なる営利企業である。ボランティアでなければ、完全無欠な公正中立な団体ではない。
彼らのテレビ放送には、自分達に利益を誘導しようという作為がある。そのことを常に意識しながらテレビ放送は見る必要があることに注意しなければならない。

| | コメント (0) | トラックバック (1)
|

2006/10/02

ニート

 ニートが一般的に使われるようになって、数年がたった。
ニートの定義や実情については他のサイトに任せるとして、ここではマスコミや政治屋が ”ニート” と呼ばれる人たちをどのように扱ってきたかについて私なりの意見を述べたい。

 マスコミ、特にテレビのワイドショーなどで “ニート” が特集されると、たいてい “社会のお荷物” “社会に適応できない負け組” といった、悪意に満ちた報道がされる。そして “ニート” という悪い状態に陥ったことを、本人の気質の問題と決め付けている場合がほとんどである。
首相や野党幹部といった政治屋の多くも、やはり同様に “ニート”=社会悪 そして本人にすべて責任がある、といった旨の発言を繰り返ししている。
はたして本当にそうなのだろうか?

 私の持論の一つが 「人は自分を満足させる行動しか取らない」 である。仮にいっけん自己犠牲のように見えても、よーく考えると “人の役に立ったという満足感” や “人にいいカッコができたという自己満足” がある。
であるからして、ニートしている人たちも、それがその時点で自分を満足させている、ということになる。そもそも、たいていのニートな人は生活に困っていないのである。ムリに働かなくても生活していけるからこそニートしているともいえる。
(そもそも、ある一つの組織の中で、その一部だけが働いているというのは、決して特異なことではない。一番身近なのは蟻である。よく言われるように、働き蟻の実は三割しかきちんと働いては折らず、残りの七割は何するわけでもなくプラプラしている。ところが、三割の働き蟻だけを集めてもやはり七割は怠け蟻になってしまう。七割の怠け蟻だけを集めると、その中の三割が働きありになる。)
一方それを外から見ている赤の他人や権力者から見ると、ニートな人たちは税金を納めず、日本のシステムに貢献していないとうつる。だから、国を安定して運営していこうとする権力者達はニートを悪人に仕立て上げる。曰く、「きちんと働いていない人々はどうしようもないろくでなし」であると。
しかし、ニートな人にしていれば、生活に困っているわけでないし、働いて税金や年金を払っても将来自分達の暮らしが楽になるという確信が持てないでいる。言い換えれば、今の日本のシステムに不満があるのである。

 そう、“ニート”という現象は個人のやる気や根性の問題ではなく、現在の日本の社会システムの問題なのである。働いても報われるとは限らない。そして、権力者や一部の政治屋とその周辺の人間だけが、濡れ手に粟のごとくかき集めた税金を自分の懐に入れて自分達だけが潤っていく。“ニート”はそんな今の日本システムの問題なのである。
政治屋たちは楽して儲かる税金や年金を納めてくれる人たちが減ると困るのである。だから、ニートを悪者に仕立て上げてスケープゴートにしようとしている。マスコミ、特にテレビはそんな政治屋・権力者に擦り寄って、彼らの考えで人々を洗脳しようとしている。

 本当に “ニート” が大きな問題なのであれば、今のこの日本のシステムを変えればいいのである。
官僚・公務員もちゃんと責任をもって行政を行い、問題が発生すればきちんと処罰される。税金や年金などは、官僚や政治家が好きに使えないように、はっきりとしたガラス張りにすべきなのである。

| | コメント (0) | トラックバック (0)
|

2006/10/01

人材、人在、人財 そして 人罪

 トラックバック先のコラムを読んで、久しぶりに 「人財」 および 「人罪」 という言葉を聴いた。
最初にこの言葉を聞いたのは、何かのビジネス雑誌だったと思う。そこでは、“実績” を横軸に、 “将来性” を縦軸にとって 「人財」 「人材」 「人在」 「人罪」 を下のように表していた。

↑|      |
||      |
|| 人材  | 人財
将|      |
来|―――――――――
性|      |
||      |
|| 人罪  | 人在
||      |
□+―――――――――
□□――――実績――→ 

『人財』 は、これまでも実績があり、今後も所属している組織に貢献が期待される人のことである。企業や組織はこういう人を多く取ることで発展をしていくに違いない。

『人材』 は、これまでの実績はないものの、今後組織に貢献していくことが期待される人のことである。人財 もいつかはいなくなってしまうから、人材 を速いうちから見つけて 人財 へと磨き上げることが、組織にとって重要になってくるのは明らかである。

『人在』 は、実績を上げてきたものの、今後組織への貢献は期待できずに、組織のお荷物になっている人のことである。こういう人には、別な道を探してもらい、速めに退場してもらうのが本人にとっても組織にとってもよいらしい。

『人罪』 は、実績もなく今後の貢献も期待できない人のことである。行為人がいると組織のモラルが低下して、人財 や 人材 が逃げて言ってしまう場合多いらしい。

 人財 と 人材 のみがいる組織が理想であるが、実際の組織では、人財:1割 人材:2割 人在:5割 人罪:2割 ぐらいが一般的であるらしい。

---------------

 当時はこんな記事を読んでは 「なるほどね~」 と感心していたが、はたして自分が 『人財』 になることが出来たのかはイマイチ自信がない。やはり 『人在』 になっていたのではないかとも思う。

 ここまで書いてからいうのもなんであるが、このような人に対する評価はあくまで企業から見た人材評価であり、今の企業的価値観に深い疑問を持つ私にとっては、上のような人の分類はたいしたことではないと感じている。
企業にとって重要な人が、必ずしも社会生活やもっと基本的な家族内において最良の人物であるとは限らない、と思うからである。
そして、家族にとっての 『人財』 になることが、今の私にはもっとも重要なことである。

---------------

10月27日 追記

他に人のブログを読んでいたら、どうも 『人済』 というのがあった。
『人済』 を導入すると、『人在』 と 『人罪』 の定義が変わってくる。

『人済』 は、実績を上げてきたものの、今後組織への貢献は期待できずに、組織のお荷物になっている人のことである。こういう人には、別な道を探してもらい、速めに退場してもらうのが本人にとっても組織にとってもよいらしい。

『人在』 は、わずかな実績とわずかな将来性がある人のことである。無害ともいえるが、企業から見た場合は 『無益』 となる。

『人罪』 は、実績もなく今後の貢献も期待できな人のことである。行為人がいると組織のモラルが低下して、人財 や 人材 が逃げて言ってしまう場合多いらしい。

“人ざい” マトリックスは以下のように修正される。

↑|      |
||      |
|| 人材  | 人財
将|      |
来|―――――――――
性|      |
||\ 人在 |
||  \   | 人済
||人罪 \ |
□+―――――――――
□□――――実績――→ 

| | コメント (2) | トラックバック (0)
|

« 2006年9月 | トップページ | 2006年11月 »