キーボードが使えなくなった！

　なんだかんだで現在は ロジクール マウス ＬＸ８ を使っている。

　ところが、ロジクールのマウスとキーボード用のユーティリティ “SetPoint” の動きがどうも怪しいことに気がついた。具体的には、日単位で使い続けると、システムの動作がどんどん重たくなってくるのだ。

　ある日、ふと思いついて、タスクマネージャーから SetPoint を強制的に終了させると、長時間使い続けてもシステムが重たくならなかった。どうも、わずかだと思うが、SetPoint がメモリリークをしているような気がする。

　そこで、マウスの使い勝手が悪くなるのを承知で SetPoint をアンインストールすることにした。そして、これが悪夢の始まりだった。

　まず、SetPoint の削除方法に戸惑った。コントロール パネルのプログラムの追加と削除内を見ても、SetPoint がなかなか見つけられなかったのだ。

　私は “Logicool” や “SetPoint” で探していたのだが、プログラムの追加と削除には 『ロジクール SetPoint』 で登録されていた。

　SetPoint の削除自体は、何の問題もなく終わった。SetPoint 削除後は、強制的にシステムの再起動が要求される。

　そして、再起動後に、その問題は起こった。キーボードが “使用不可” になってしまったのだ。SetPoint を削除したことによる問題なのは明らかだった。

　デバイス マネージャーから、キーボード ドライバーを削除してみたり、キーボード ドライバーを入れなおしてみたりしたが、問題は解決しなかった。

　そこで、エラーメッセージをマウスでコピーペーストしてググってみると、なんと、同様の問題とその解決方法を紹介してくれる人たちが、何人もいるではないか。

　とりあえず私がお世話になったのは、ここだ。

はっしぃの映画三昧！WindowsXPで日本語ｷｰﾎﾞｰﾄﾞが英語ｷｰﾎﾞｰﾄﾞに・・・

　ただし、上の 「この状態の回復方法」 で紹介されている方法を実行する前に、やっておく作業がある。

　SetPoint を削除した状態だと、キーボードが 「不明なデバイス」 になってしまっている。これを一度 「日本語 PS/2 キーボード」 にしておく必要がある。具体的には、「不明なデバイス」 を右クリックして “ドライバーの更新・・・” を実行する。

　キーボード ドライバーを変更しないと、どうも上のサイトで説明されているレジストリの値が “４” に切り替わらないようだ。

　キーボードを 「日本語 PS/2 キーボード」 にしても、引き続き問題が発生している状態になっているので、ここでようやく上記サイトの 「この状態の回復方法」 を実行して、レジストリを書き換える。

　書き換えた後は、システムを再起動すれば、元の通りにキーボードが使えるようになる。

　それにしても・・・。

　SetPoint はマウスだけでなく、キーボードをカスタマイズするためのユーティリティになっている。そのために、SetPoint をアンインストールするとキーボード環境にまで問題が及んだようだ。

　長時間使い続けるとシステムの動作が重たくなる現象といい、ユーティリティのアンインストールでユーザー環境を壊す点といい、どうもソフトウェアの作りこみが甘い気がする。

　よいハードウェアを作ってくれているだけに残念である。

さらにブラウザが使いやすくなった

　Firefox を標準のブラウザとして使い始めてから、パソコン全体の調子もなんだかいい気がする。

　Firefox で私が今現在使っているアドオンは、以下の３つだ。

1. Google Toolbar
   Google が提供しているブラウザ用ツールバー。私は、Wikipedia で検索、上位ディレクトリを表示、ページ内検索、を主に使っている。


2. PrefBar
   多種、多様な機能をもつボタンを任意に追加できるアドオン。私は、Flash と Gif アニメーションの停止 と Flash コンテンツの削除、を使っている。


3. Tab Mix Plus
   リンク、タブ、マウスジェスチャ、セッション、等などに、実に多くの追加機能を持つアドオン。

　３．の Tab Mix Plus により、私の Firefox 3 の使い勝手が大きく改善した。

　以前に要改善部分として書いた部分も、（完全ではないものの）私が期待する操作系に変更が出来た。具体的には 『Ctrl+Tab でのタブ切り替え順』 と 『ブックマークから新しいタブにページを表示する機能』 だ。この二つが追加されただけで、私にとってかなりユーザビリティが向上した。

　ところで、

　「そういえば、IE7 （Internet Explorer 7.0） には、PrefBar や Tab Mix Plus のようなアドオンは出てないのだろうか？」

と思って軽く探してみたら・・・、すぐに見つかったので笑ってしまう。

　IE7Pro

「究極のアドオン」 と自称は伊達じゃない、と思えるほど、たしかに多機能・高機能なアドオンだ。

　もっとも、IE7Pro で私が一番必要としているのは、“Flash ブロック・広告フィルタ” だったりする。たった一つの機能なのだが、この機能を使うのと使わないのでは、Web ブラウジングの快適さに雲泥の差が生まれる。

　私が使う範囲においては、

• Firefox 3 + PrefBar + Tab Mix Plus
• IE7 + IE7Pro

が同等の使いやすさを提供しているように思えた。

　そこで、私の主観では、どちらを標準にすべきか、比較してみた。

　ということで、次回に続く。

IE7 ハング問題、再び

　安定したと思っていた Internet Explorer 7.0 (IE7) だったが、どうやらそうではなかったようだ。というのも、やはり条件がそろうとハングしてしまうからだ。

　その条件は、起動しているアプリケーションの種類や数によって満たしたり、満たさなかったりするようだ。IE7 がハングする頻度やタイミングが、起動しているアプリケーションの種類や数によって違うのだ。逆に言うと、一度 IE7 がハングした状態で、再び IE7 を起動して操作していると、同じ操作で IE7 が再びハングする。

　IE7 がハングするタイミングは、次の二つだ。

• 一つの IE7 ウィンドウ内でタブを切り替えた時
• タブを閉じようとした時 （IE7 を終了させる時を含む）

特に、タブを閉じようとした時に IE7 がハングする場合によく遭遇した。

　ハングを起こす Web ページにも傾向がある。多くの Flash を広告などに使っていたり、地図サイトなどの複雑なスクリプトを使っているページで、IE7 のハングが起こりやすい。実際、私が IE7 のハングの再発に遭遇したのは、地図サイトでルート検索結果を印刷している時だった。

　Windows Live メールや Windows Live Messenger、Paint Shop Pro 等が起動していると、より IE7 がハングしやすいように感じた。

　そこで私の頭に浮かんだのが、ヒープ領域が関係しているかもしれないということだった。というのも、それらのアプリケーションは、ヒープ領域をより多く消費している印象があるためだ。

　特に Paint Shop Pro （私が使用しているのは古いバージョン７なのだが） は、「ちょっとアプリケーションを立ち上げすぎているかな？」 と思っている状態だと、間違いなく起動することが出来ない。プロセスを監視するツールを使って観察していると、Paint Shop Pro のプロセスが一度作られるのだが、何の表示も、何の警告もなしにプロセスが終了してしまうのが確認できる。一つ、二つ、アプリケーションを終了させてやると、Paint Shop Pro は、何の問題も無く起動する。

　そういった経験もあり、今回の IE7 のハングも、ヒープ領域に関係しているのではないかと、推測したのだ。

　改めてヒープ領域について調べてみると、

• 「基本的には、既定値の状態で問題ない大きさになっている」
• 「ただし、使い方やアプリケーションの作られ方によっては、足りなくなることがある」
• 「足りなくともダイナミックに大きくすることは出来ない」
• 「大きさは、レジストリの設定で変えることができる」

ということがわかった。

　具体的な変え方については、下のページに解説付きでわかりやすく説明されている。

原因不明のメモリ不足エラーに対処する方法（デスクトップ・アプリケーション・ヒープ不足エラーに対処する方法）
　＠IT ： Windows TIPS

　さっそくヒープ領域を広げようとレジストリ エディタを起動してみて驚いた。なんと、私のシステムの設定が “２０４８” になっていたのだ。上記のページによれば、既定値は “３０７２” のはず・・・。パフォーマンス設定が関係してたりするのだろうか・・・。

　そこで、既定値の ３０７２ に変更をして、システムを再起動。

　再起動後に IE7 を使ってみる。何枚か地図サイトを広げてみて、使って、閉じてみる。なんとかが無事に IE7 を終了できる。

　さっそく、よく使うアプリケーション達を立ち上げて、ブログの記事を書き始める。記事を書くために、あちこちのページを切り替えながら IE7 を使う。

　初めのうちは順調だったのだが、調子に乗って何枚かタブを閉じたところで ・・・・・・・・・・、IE7 がハングした。

　どうやら、ヒープ領域の大きさの問題ではなかったようだ。

　三度、IE7 の設定を “タブなし” に切り替える。タブなし の状態でも実用上は何にも問題はないのだが、原因がわからない問題があるという状態が、私にはとても居心地が悪い。

　はたして、私が何も気にすることなく IE7 をタブで使える日は来るのだろうか・・・。

IE7 のハング問題、解決！

　ここ一週間ほど、Internet Explorer 7 (IE7) の不具合に悩まされてきた。

　具体的には、タブを切り替えたり、タブを閉じたりすると、IE7 が無反応、いわゆるハング状態になるのだ。おかげで、タブを使うと安心してブログが書けな。そこで仕方なく、タブを使わずに IE7 を使っていた。

　タブは、IE7 の売りの一つであるだけに、タブが使えない IE7 は、“クリープを入れないコーヒー” 状態だ。

　IE7 も最初から問題があったわけではない。私は Micrsoft Update からインストールできるようになったときに、IE7 を入れた。それから、しばらくは何の問題も無く IE7 を使えていた。

　断言は出来ないが、どうも Windows Xp SP3 を入れてから、IE7 が問題を起こすようになったような気がする。

　もちろん、いろいろ解決策は探っていた。

　キャッシュをクリアしてみたり、クッキーを消してみたり、スクリプトを禁止してみたり、アドオンなしで IE7 を起動してみたりして。

　そして、ある程度予想はしていたものの、アドオンを “一切なし” にすると、IE7 をタブ付きで使えるようになった。

　だが、最近の有用な Web ページは、Flash が必須要件となっている。そして、Flash を使うためには、アドオンを使用しなければいけない。

　結局、Flash を使うために、しばらくタブを使わない状態で IE7 を使っていたのだ。

　そして、私は IE７ の調子が悪いのは、「IE7 と アドオンのどれか の相性がよくないためだ。」 とずっと信じていた。

　だが、それは間違いだった。

　最近は、IE7 でのハングの情報を集めるのが日課になっていた。

　そして今日、いくつかの Web ページで、

「IE7 に切り替えたにもかかわらず、バージョン 6.0 の iexplore.exe がアプリケーションエラーを起こす」

という情報を目にした。

　そして、その情報を目にした時、私はあることを思い出した。

　IE7 が問題を起こすようになったのと時を同じくして、デスクトップに保存したインターネット ショートカットを開くと、IE が二つ起動するようになったのだ。後から起動した IE には、設定した Web ページが表示されるが、先に起動した IE は真っ白の空っぽの状態なのだ。

　そしてしばらく後になってから気がついたのだが、先に起動した IE のツールバーが、実は IE “６” のものだったのだ。

　そこで、私は仮説を立ててみた。

• 「システム ドライブ内に、IE6 のプログラムがまだ残っている。」
• 「IE7 が実行しているときに、何らかの理由で IE6 が起動しようとする。」
• 「IE7 も IE6 もプログラム名が同じ iexplore.exe のため、システム内でコンフリクトが起こり、IE7 がハングする。」

のではないか、というものだ。

　そこで私は、以下のことを実行してみた。

1. システム ドライブ内の “iexplore.exe” をすべて検索する
2. 見つかった iexplore.exe のうち、バージョン番号が ６ のファイルの拡張子を ex_ に変更する
3. レジストリ エディタを起動して、“iexplore.exe” を検索する
4. 見つかった iexplore.exe のパスが “C:\Program Files\Internet Explorer” でないものは、すべて削除する

　１．で、実際に使われる iexplore.exe の他に、アップデートのバックアップやシステム ファイル プロテクション用のバックアップなどで、ファイル名に iexplore.exe を含むファイルが、２０個ほどの見つかった。

　そのうち、バージョンが ６ だったものは、３個だった。

　３．で C:\Program Files\Internet Explorer 以外のパスの iexplore.exe の情報を持っていたのが、“Shockwave” だった。Shockwave は、設定で２箇所ほど、バージョン ６ の iexplore.exe のパスを記述していた。

　そして、上記の処理をしたところ、それまでのトラブルが嘘のように起こらなくなった。

　IE7 をインストールしたときには、IE6 へのリンクはすべて断ち切られていたのだろう。

　だが、Windows Xp SP3 がインストールされたときに、IE6 への関係が蒸し返されたのではないか。そして、それは Shockwave Flash がらみで、アドオンを禁止すると IE6 の呼び出しが起こらなかった。と推測している。

　SP3 をインストールすると、IE7 が削除できなくなることからも、IE7 の登録情報を大幅に書き換えていることは間違いないだろう。そして、その書き換えで、IE6 へのつながりが蒸し返されてしまうのではないかと推測している。

　もし、同じように、IE7 でのハングに悩まされている人がいたら、上記の処置を試してみてはいかがだろうか。お金もかからないし、IE7 を削除するつもりがないのであれば、特に問題も起こらないはずだ。

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

2008年5月19日追加

　実は、問題解決の理由が他にあることがわかった。詳細については、これの次の記事で。

効率のいい方法だとは思うけど……

　ソフトウェアを作るとき、中心となる部分は、言語 “非依存” の形で作って、言語依存の部分は、追加する形で作ることが、当たり前になっている。多くの人が使っている Windows もそうだし、Office もそうだ。インターネット上で配布されている小さなツールでも、各国言語用のモジュールを追加するだけで、任意の言語で動作するようになっている場合がほとんどだ。

　ソフトウェアの世界の話だと思っていたが、ハードウェア、しかも車の世界でも似たような状況らしい。

日本で売っても儲からない
だから世界戦略車で勝負
　浜田基彦
　　NBonline [2007年12月18日]

　この記事の最後にこうある。

世界のどこでもない“某国”を想定して、素のカローラを設計する。トヨタは本当に「素カローラ」と呼んでいる。ここには各国の要求がほど良く盛り込んである。それを元にして国別のモデルに仕立て直す。日本向けはそのバリエーションの1つに過ぎない。

　まさに各国対応の後付だ。

　この “基本部分の一般化” 手法は、効率的だ。表示やメッセージの部分は、処理を行う部分と切り離しやすいので、基本部分を作る人は、他国の言語や文化を知らなくてよい。言語の壁がなければ、人材の確保がずいぶんと楽になる。最近では、インドやイスラエルに米国企業が外注しているという話も聞く。

　とはいえ、それは開発会社の経営者やマネージャーから見た場合の話だ。

　一般消費者、一般ユーザーとして私が考えると、ちょっと見方が変わってくる。

　基本部分が一般化されて、それに言語依存部分を追加しているということは、それだけ処理が冗長になっているということだ。日本語の使用 “だけ” を考えて効率よく作られたソフトウェアと比べれば、処理能力が遅くなる。

　日本人には一生必要のない機能まで実装されている部分もあるので、ソフトウェアのサイズも肥大化することになる。

　実装の仕方が悪かったりすると、他言語の仕様のために日本語ではうまく機能しなくなる場合もある。たとえば、英語では一文字の検索は意味をもたない。そのため、一文字で検索しようとすると検索を行わない実装がされてしまった。しかし、日本語の場合は違う。ひらがな・カタカナは意味がないが、“車” “家” といった漢字を一文字で検索することは、よくある。

　共通部分をなるべく多くして、各国語対応を最小限に抑えれば、確かに効率よく世界市場に向けた製品が作れる。コストを抑えて、安価に製品を提供するという経済的な観点から、それは正しいのだろう。

　しかし、製品を使うユーザーの立場から見ると、言語依存が減らされれば減らされるほど、その製品の満足度が下がるように思う。日本語に特化して作られた昔の製品の日本語処理についての満足度が９０点以上だったとすれば、今の各国語対応された製品の日本語処理の満足度は、８０点にも届いていないような気がする。

　具体的のどこがどうとうまく説明できなくて、申し訳ないのだが、昔の製品のほうが、米国製であっても、日本語処理の細かい部分を考慮して作られていたように思う。

　米国より1年遅れ、２年遅れという代償を払っての結果なのだが、満足度や安定性を考えると、その代償には十分価値があったと、今でも思っている。

数値はひとり歩きする

他人が作った数字を疑い「数字を見る目」を養う
会社の数字に強くなる＜第５回＞
　水越豊
　　NBonline [2007年12月11日]

　私も会社の第一線で働いていたときは、いつも言われていた。「具体的な数字を出せ」 と。いつしか、あちこちからデータをかき集めて、自分の主張の根拠を数字で示すことが当たり前になっていった。

　具体的な数字を出すことで、他人を説得しやすくなり、自分の主張する機能を実装しやすくなる。

　自分が散々使っておいて言うのもなんだが、具体的な数字を出されると “説得力がある” というのが曲者なのだ。上記の記事でも言われているように、背景となっている条件をきちんと把握しないと、とんでもない誤算を招く。

　政府の発表する出生率予測など、いい例だ。政府は常に 「出生率は今後上昇する」 と言い続けている。しかし、現実の出生率は下がる一方で、上がる気配を見せない。それはひとえに、政府の前提が 「少子化対策が有効である」 という、“極めて非現実的な” 前提に基づいているからだ。

　逆に、示したはずの前提がいつの間にか忘れ去られてしまい、データを提示した者が 「うそつき」 呼ばわりされることもある。

　私が担当したアプリケーションの新機能を、ユーザビリティ テストしたときのことだ。新機能は、特定の作業をまとめて、単純化したウィザード型のものだった。該当アプリケーションの未経験者向けに実装したものだ。結果は良好だった。

　報告書には、「“未経験ユーザーに対して”、極めて有効に機能した」 と書いたにもかかわらず、時間がたつにつれて、いつの間にか 「すべてのユーザーに対して、有効な機能」 と思われるようになってしまった。

　致命的だったのは、営業・販売部隊に勘違いされたことだった。その機能を、前バージョンの機能のスーパーセットと広告されてしまった。発売後、既存のユーザーから、「機能が減っている」、「使い勝手が悪い」 といったクレームが多く寄せられてしまった。

　それはそうだ。既存のユーザーには、従来どおりに使ってもらおうと思っていたのだから。新機能は、従来のユーザインタフェースでは、うまく使えない新規未経験ユーザーに対して、機能を最低限に絞って、わかりやすくしたものなのだから。

　営業・販売部隊と、密な連絡・連携が取れなかったための失敗であった。私にとっては苦い経験だ。

　出された数値が一人歩きをして、私のように痛い失敗するケースがある。一方で、数値の一人歩きを見越し、他人を陥れて、だまそうとする輩もいる。

　自分が数値を伝えるときは、本文よりも何倍も強調をして前提条件を伝える。他人の出した数値を読むときは、上記の記事でも言われているように、荒唐無稽な前提が使われていないことをしっかりと確認する。数値を一人歩きさせないための、重要なテクニックだ。

なぜ私がサポートを気にするのか

　前回、前々回とサポートの対応によって、顧客離れ、企業イメージの損失について話をした。私自身はサポート業務の経験はない。しかし、製品サポートの大切さは、身をもって経験してきたつもりだ。

　私が前の会社で働いていたときの話だ。最初の製品が出荷された直後、１９９２年ごろのことである。当時はまだサポートを電話と手紙でのみ行っていた。そして、サポート チームは、電話対応の記録のコピーと郵送されたサポートシートのコピーを、定期的に開発チームに回してくれた。回ってきたコピーは、開発チーム内で回覧をして、気がついたことがあれば、書き込みをして、サポート チームへ返却していた。

　２～３ヶ月サポート内容のコピーを読み続けた頃だろうか、私は、サポート チームがユーザーに間違った内容を伝えているケースが多いことに、耐え切れなくなっていた。できることを 「できない」 とユーザーに伝えたり、一つの機能でできることを、複数の機能の組み合わせでユーザーに教えたり。我慢しきれなくなった私は、サポート チームに文句を言いに行くことにした。

　１～２週間、毎日のようにサポート チームへ出向いて、サポート担当者達と話をしていくと、ある重大な問題に気がついた。サポート担当者達が、製品について正しい情報を知らないのだ。

　サポート チームは、新製品の発売に合わせてサポートの準備を始める。新製品発売前なので、製品開発が終わっていない段階でサポート チームは準備を始める。そのために、出荷直前で見つかった問題の対応や、問題回避のための仕様変更が、サポート チームに伝わらず、変更前の情報でサポートしていたりしていたのだ。

　「これではまずい。私が作った製品がユーザーに誤解されていく。」 という危機感を持った私は、時間を見つけてはサポート チームに顔を出して、質問に答えたり、開発の都合による仕様変更などの情報を伝えていった。

　その結果、回ってくるサポートの品質が、目に見えて高くなっていった。それを見て、一人で喜んでいたものだった。

　サポート担当にしてみれば、自分が作ったわけではない。にもかかわらず、問題が発生して、怒っているユーザーに頭を下げるのは自分達だ。ユーザーに答えようにも情報を持っていない。ユーザーの不満を開発に伝えても、まともに取り合ってくれない。

　これでは、サポートの質が上がるはずがない。

　私自身は、別にサポート全体の質を上げようと思って、サポート チームのサポートをしたわけではない。ひとえに、自分担当した製品が正しくユーザーに使われないのがイヤだったのだ。

　私は、ユーザーが自分の製品を正確に理解をして、正しく評価することを望んだ。サポート チームは、自信を持って製品がサポートできることを望んだ。

　あのときの私行動は、私とサポート チーム、両者の望みを同時にかなえるもだった。だから、自分も満足できたし、サポート チームからも感謝された。今でも、あのときの私の行動は、とても有益であったと信じている。

　ひるがえって、最近のサポートは、アウトソーシングが進み、一つのサポート会社が、複数の会社の複数の製品を扱うことが普通だ。そして、サポート担当者の評価は、単位時間当たり、いかに多くの問い合わせを処理したか、でされている。そんな状況では、サポート担当者は、問い合わせ内容をよく吟味せずに、事前に準備された回答で返答するだけになってしまう。もちろんそれでは、問い合わせた人が満足できるサポートになるはずもない。

　前回で述べているように、サポートの良し悪しは、その企業のイメージ、製品イメージを左右する。良いサポートは、その製品価値を高めてくれるのだ。ところが、宣伝広告には予算をつける努力をするのに、サポートには予算を付けない努力をする。

　大々的な宣伝広告をするのに比べて、サポートが貧弱な会社を、私は信用しない。良い製品やサービスを提供しているなら、良質なサポート体制を準備したとしても、それほど予算を必要としないはずだ。

なぜ私がサポートを気にするのか

　前回、前々回とサポートの対応によって、顧客離れ、企業イメージの損失について話をした。私自身はサポート業務の経験はない。しかし、製品サポートの大切さは、身をもって経験してきたつもりだ。

　私が前の会社で働いていたときの話だ。最初の製品が出荷された直後、１９９２年ごろのことである。当時はまだサポートを電話と手紙でのみ行っていた。そして、サポート チームは、電話対応の記録のコピーと郵送されたサポートシートのコピーを、定期的に開発チームに回してくれた。回ってきたコピーは、開発チーム内で回覧をして、気がついたことがあれば、書き込みをして、サポート チームへ返却していた。

　２～３ヶ月サポート内容のコピーを読み続けた頃だろうか、私は、サポート チームがユーザーに間違った内容を伝えているケースが多いことに、耐え切れなくなっていた。できることを 「できない」 とユーザーに伝えたり、一つの機能でできることを、複数の機能の組み合わせでユーザーに教えたり。我慢しきれなくなった私は、サポート チームに文句を言いに行くことにした。

　１～２週間、毎日のようにサポート チームへ出向いて、サポート担当者達と話をしていくと、ある重大な問題に気がついた。サポート担当者達が、製品について正しい情報を知らないのだ。

　サポート チームは、新製品の発売に合わせてサポートの準備を始める。新製品発売前なので、製品開発が終わっていない段階でサポート チームは準備を始める。そのために、出荷直前で見つかった問題の対応や、問題回避のための仕様変更が、サポート チームに伝わらず、変更前の情報でサポートしていたりしていたのだ。

　「これではまずい。私が作った製品がユーザーに誤解されていく。」 という危機感を持った私は、時間を見つけてはサポート チームに顔を出して、質問に答えたり、開発の都合による仕様変更などの情報を伝えていった。

　その結果、回ってくるサポートの品質が、目に見えて高くなっていった。それを見て、一人で喜んでいたものだった。

　サポート担当にしてみれば、自分が作ったわけではない。にもかかわらず、問題が発生して、怒っているユーザーに頭を下げるのは自分達だ。ユーザーに答えようにも情報を持っていない。ユーザーの不満を開発に伝えても、まともに取り合ってくれない。

　これでは、サポートの質が上がるはずがない。

　私自身は、別にサポート全体の質を上げようと思って、サポート チームのサポートをしたわけではない。ひとえに、自分担当した製品が正しくユーザーに使われないのがイヤだったのだ。

　私は、ユーザーが自分の製品を正確に理解をして、正しく評価することを望んだ。サポート チームは、自信を持って製品がサポートできることを望んだ。

　あのときの私行動は、私とサポート チーム、両者の望みを同時にかなえるもだった。だから、自分も満足できたし、サポート チームからも感謝された。今でも、あのときの私の行動は、とても有益であったと信じている。

　ひるがえって、最近のサポートは、アウトソーシングが進み、一つのサポート会社が、複数の会社の複数の製品を扱うことが普通だ。そして、サポート担当者の評価は、単位時間当たり、いかに多くの問い合わせを処理したか、でされている。そんな状況では、サポート担当者は、問い合わせ内容をよく吟味せずに、事前に準備された回答で返答するだけになってしまう。もちろんそれでは、問い合わせた人が満足できるサポートになるはずもない。

　前回で述べているように、サポートの良し悪しは、その企業のイメージ、製品イメージを左右する。良いサポートは、その製品価値を高めてくれるのだ。ところが、宣伝広告には予算をつける努力をするのに、サポートには予算を付けない努力をする。

　大々的な宣伝広告をするのに比べて、サポートが貧弱な会社を、私は信用しない。良い製品やサービスを提供しているなら、良質なサポート体制を準備したとしても、それほど予算を必要としないはずだ。

身近すぎると、気がつかないもの

人の心を見る技術が社会を変える
（CSR解体新書19）製品評価などに使うと有益だが・・・
　伊東乾
　　NBonline [2007年11月27日]

　今回は、この記事全体についての話ではなく、導入部分の話についてだけ取り上げる。

日本のホームレスが新聞を読んでいるのを見て、インド人社長が嘆く。曰く、「ああ、これでは当分、インドは日本に敵うわけがない！」 と。

「だって日本では、文字を読める人が、仕事がなくて路上生活しているのでしょう？　自分の郷里ではこんなことは考えられない。文字が読めれば必ず仕事がある。いやはや日本の人材層の厚さは底知れない、と改めて圧倒されました」

　これを読んで、「なるほど」 とうならされた。

　新聞を読んでいるホームレスなど、私もしょっちゅう目にしている。いわば、当たり前の光景だ。そもそも、現在の日本人で基本的な読み書きができない人がいるということは、私には想像できない。

　しかし、世界的に見れば、日本のような状況は極めて特殊だと言うことを、あらためて思い出した。米国でさえ、読み書きができない人は意外と多いそうだ。以前に何かの特番で取材しているのを見たことがある。それなりに自立している４０代ぐらいの男性が、実は文字が読み書きできない。本の感想を聞かれると 「あなたはどう思いましたか？」 などと言ってごまかしてきた、と言っていた。

　実は、ソフトウェアのテスティングやユーザビリティも、この “身近すぎると気がつかない” ことの繰り返しなのだ。

　日常的にパソコンにさわっていると、たいていのことが日常になってしまうため、一般ユーザーにとって、何がわかりやすくて、何がわかりにくいのかが、わからなくなってくる。

　ユーザビリティ → テスター → プログラマー にいくにしたがって、いっそうその傾向が強くなってくる。一般ユーザーにはパソコンが難しい、ということを理解できないプログラマーもいたし、「難しいのならパソコンを使うな」 と言い切るプログラマーもいた。

　プログラマーならそれでもいいのかもしれないが、テスターやユーザビリティ担当は、それではいけない。

　上記の記事のインド人の目と同じように、自分達とは違った文化（＝職種）の人の目で見て、自分達が問題を見落としてないか、きちんと確認をしていくのは、重要なことである。

始まりは革新的に、最後は保守的に

改革の裏にある「石橋を叩く」姿勢
～校長・荒瀬克己～
　茂木健一郎
　　NBonline [2007年10月16日]

　この記事の中の、

堀川高校はいろいろな改革をし、新しい試みをしているのだけれど、実際はどこかで事前に実施されて効果があると分かっていることばかりを取り入れている。

という部分を読んで、なんとなく自分が経験してきたソフトウェア開発を思い出した。

　新しいバージョンのソフトウェアが宣伝する新機能は、実は他のソフトウェアですでに成功している機能だったり、他の分野で成功している機能の応用だったりすることはよくある。

　これまでどんなソフトウェアでも実現していないとか、どの分野においても類似の機能を見たことがない、などというモノは、めったにない。

　実は、ソフトウェアの開発者の多くは、その “誰も見たことがない新機能” をなんとか製品にしようと頑張っている。そのために、製品の開発初期には、あらゆるアイデアが実装の候補として挙がり、その革新性や有用性が試されていく。

　ところが、誰も世に出していないアイデアや手法は、開発している最中に様々な問題を引き起こす。ソフトウェアの安定性だったり、動作速度であったり、使い勝手であったり。革新性、新規性が高いほど、問題がなかなか収束しない。

　そして、開発終盤になると、問題が収束しない機能は、次々と切り捨てられていく。そう、製品として纏め上げるためには、開発チームは保守的になる。“石橋を叩く” モードにならざるを得なくなる。そうなると、収拾がつかなくなった革新的な機能に代わり、すでに実績のある機能が組み込まれることになる。

　まだ私が駆け出しの頃は、開発終盤の “石橋” モードが理解できなかった。せっかく長い時間をかけて開発した革新的機能をばっさりと切り捨てていくことが納得できなかった。

　しかし、いくつもの製品を担当して、最終的な製品出荷の責任の一端を担うようになり、ようやく終盤の “石橋” モードが理解できるようになった。

　そんな経験のおかげだろうか、上記の記事の 「成功した実績のあることだけを取り入れた」 という発言に、素直に納得できた。

　改革というと、とかくそれまで他人がやったこのないことをするというイメージがある。しかし、改革が必要とされているということは、現状がうまくいっていないということである。であれば、改革の目的は、「現状よりもより良く物事が進むようにする」 ことのはずである。

　問題点とあるべき形がはっきりしているのであれば、それを実現できる手段をどこからか探してきて、そのまま実行するというのは、理にかなっている。

　ユーザーの多くが欲しいのは、開発者の自己満足で未成熟な革新的機能ではなく、使い慣れて確実に使えるオーソドックスな機能である。

　同じように、うまくいかない学校運営で一番困っているのは、生徒達だ。その生徒達が望んでいるのは、確実に学校を良くしてくれる運営のはずだ。目新しいが、うまくいくかわからないことをするのは、改革担当者の欲求を満たすかもしれないが、困っている生徒達を救える保障はどこにもない。

　とはいうものの、どこかで新規性の高いチャレンジをしなければ、どこかで行き詰ってしまう。失敗する可能性が高いチャレンジも、どこかで誰かがやらなければいけない。ソフトウェア開発を見習うとすれば、チャレンジは学校運営が安定して、改革が必要とされないとだと思う。改革が必要でなければ、チャレンジが失敗しても、元に戻せばいよいだけなのだから。