« 2008年11月 | トップページ | 2009年1月 »

2008年12月の8件の記事

2008年12月20日

携帯電話で国際カンファレンスコール

本社のカンファレンスコールがWebEx Audio Teleconferencingに変わった。WebExのNetMeetingやSupport Centerサービスは数年前から使っていて、それと統合できるというのが主な理由らしい。

以前はAccuConferenceを使っていて、アメリカの有料番号にSkypeでかけて経費を節約していた。WebExはKDDIワールドフリーフォン00531の番号が使えるのだが、残念ながらSkypeやひかり電話ではこの番号にかけれらない。市外局番03の有料ダイヤルを使うことになる。

携帯電話ではどうかというと、話中になってしまう。調べると、事前に登録する必要があるとのこと。0077-7160に電話して本人確認の質問や携帯電話のパスワード、支払い方法の手続きをすませると、約40分後に使えるようになった。この手続きは24時間いつでもできるようだ。私は朝7時過ぎに電話して、8時からの電話会議に余裕で間に合った。

Skypeの時はヘッドセットを使っていたからハンズフリーで、しかもマイクミュートを使えた。マイクミュートは電話会議の時は常識だが、日本の人にはあまりなじみがないと思う。こちらの音声、咳払いや呼吸音、キーボードの打鍵音などを拾ってしまうと耳障りだし、携帯電話で参加しているときは音声が途切れがちになる。

携帯でもイヤホンマイクを使えばハンズフリーになる。しかしauのW51CAやW41Sにはマイクミュート機能が付いてない。auの現行機種をいくつか調べると、シャープのW64SHとURBANO、東芝W65T、ソニーエリクソンのreだけにしかマイクミュートは付いてないようだ。

もしかすると、会議といえば大勢がひとつの部屋に集まって顔をつきあわせるのが常識と化している日本と、電話会議やビデオ会議を積極的に使う(移動距離が半端でないので使わざるを得ない)アメリカの違いが背景にあるのではないかと思う。

| | コメント (0)

ITエンジニアの格好悪い姿勢は理にかなっている

PCを使っているITエンジニアはだいたい同じ姿勢である。尻を椅子の前方にずらし、机の下に下半身を潜り込ませるようにする。足は前方に投げ出す。いかにもだらだらと仕事をしているように見えるが、意外と理にかなっているようだ。

アメリカのPC販売台数で、初めてノートPCがデスクトップを上回ったそうだ。しかしこれは背中や首、肩にとってあまりよくないことだと、Wall Street Journalの記事が警鐘を鳴らしている。人間工学の専門家のアドバイスによると、コンピュータを使うときには次の点に気をつけなければならない。

  • モニタは目の高さに置き、背もたれに寄りかかれるようにする。
  • キーボードは肘の高さにおき、肘を曲げた角度が90度かそれ以上になるようにする。下腕はアームレストで支える。

しかしノートPCをテーブルにおいて使うと、たいていの場合キーボードが高すぎる。内蔵ディスプレイは位置が低すぎ、首を前に曲げてのぞき込むようにしなければならない。このため背中にストレスが溜まる。最初に書いたITエンジニアの姿勢は、体に負担をかけないようにと、自然にそうなってしまったわけだ。この姿勢なら、目線とモニタの高さを近づけ、肘の角度を90度以上にできる。

一番いいのは、外付けディスプレイとキーボード、そしてマウスを使うことだ。Wall Street Journalの記事からいくつか抜粋する。

  • マウスはなるべく体の近くに置くとよい。手が体から離れれば離れるほど、腕に負担がかかる。
  • キーボードを肘の高さに置くということは、テーブルの少し下に置くということになる。テーブルの下に取り付けるキーボードトレイを使う。
  • 液晶モニタを目の高さまで上げるためには、ノートPCスタンドを使うという方法もある(個人的には、ハードディスクを傾けた状態で使用するのが気になるが)。

2点目については、塩澤メソッドのように腿の上に置く方法も同じ効果がある。

(2009/12/11追記)
肘の角度を90度以上にしたり、モニタを目の高さにしたりするという点は守った方がよいが、「尻を椅子の前方にずらし、机の下に下半身 を潜り込ませるようにする。足は前方に投げ出す」姿勢は腰によくないようだ。しばらく腰がのだるさに悩まされていたのが、この姿勢をやめてぴたりと止まっ た。別の記事に書こうと思う。

| | コメント (0)

2008年12月18日

一次情報に当たる

小寺信良氏が、一部の新聞記者は一次情報を自ら確認せず、別の報道をもとに記事を書くと苦言を呈している。

比較するのはおかしいかもしれないけど、コラム書きの僕でも、合っても居ない人の拾ってきた発言を「記事の中心に据えて書く」なんてことはしないよ。ジャーナリストなら、自分で一次ソースに当たってコメント貰ってくるってのが、当たり前なんじゃないの?

「新聞記者の記事が、それでいいの?」より
http://blogmag.ascii.jp/kodera/2008/10/09225650.html

ビジネスの場でも、一次情報に当たることは非常に重要である。話者の主観に基づく細部の誇張・割愛はざらにある。人は自分の都合のいいようにしか話を聞かない傾向があるから、情報が一部欠落したり歪曲していたりすることもある。

話者のボキャブラリ不足が原因の場合もある。例えばこの文章の最初で「小寺氏が苦言を呈している」と書いた。このほかには「懸念を示している」という表現も使えるだろう。ところが、こういった表現を使いこなせない人は、「腹を立てている」「怒っている」という直截な表現に安易に飛びついてしまう。「苦言を呈する」と「腹を立てる」では、読み手の受ける印象は大きく異なる。私が読むかぎり、小寺氏は腹を立ててはいないと思うのだが、いかがだろうか。

ユーザ先でトラブルが起きているときは、「大騒ぎになっている」「クレームがすごい」「製品を突っ返すと言っている」などという刺激的な表現の連絡を受けることがよくある。もちろん、業務に少なからぬ影響が出ているのだろうが、代理店や営業担当者が中間に入っている場合は特に、話に尾ヒレが何枚も付いている可能性がある。トラブル対応の優先度を上げてもらおうとして、意図してか、あるいは無意識のうちにか、誇張した表現を使っているのだろう。私自身もそうしたくなる衝動に駆られることはあるから理解できる。

それでも、どこかで状況を客観的に冷静に把握しなければいけない。トラブルが大きければ大きいほど、慌てず騒がす、冷静に対処するようにしている。アメリカの本社にエスカレーションするときは、なおさら具体的に話をする必要がある。クレームがすごいというのは、具体的には何件くらいのクレームが来ているのか(問題の発生頻度はどのくらいか)。製品を突っ返すというのは、本当にユーザが言った言葉なのか。ほかの製品にリプレースすることも考えなければならないという可能性を示唆しただけではないのか。

一番いいのは、一次情報にあたること。つまりユーザに直接話を聞くことである。ベンダーを連れてこいと言っているのであれば、願ったりかなったりである。喜んでユーザを訪問して、本当の温度を測るようにしている。もしユーザと直接会話できない場合は、具体的な数字を中間に入っている人に聞き出すなど、客観的に判断できる情報を集めるように心がけている。

トラブルシューティング事態も一次情報が非常に大切だ。サポートエンジニアなら誰でも心がけていることだと思うが、ログやエラーメッセージで現象を確認する。再現手順をステップバイステップで確認するなど、客観的な情報を積み上げていくことが解決の第一歩である。ユーザや代理店が言ったことを、証拠を集めながら検証していくわけである。人の言うことを100%信用してはいけないと言っても言いすぎではないだろう。人は自分の都合のいいようにしか物事を見ないし、自分に都合の悪いことは自ら進んで言わないのだから。

| | コメント (0)

Responsiveness

アメリカの本社が言っていることが信用できないと不平を漏らしている人が周りにいる。本社マーケティングが出してきた新製品情報が不正確だとか次々に変わるとか。しかし私が見る限り、担当者は好きで間違いを言っているわけではない。その時点で分かっている情報を提供したが、そのあとで変更があったり、開発側が何かの事情で仕様を小変更したらしい。出荷間際の新製品だから、情報が錯綜するのもやむを得ないだろう。

Responsivenessという言葉がある。サポートセンターでResponsivenessが評価指標になる場合は、ユーザからの問い合わせに対して、どのくらいの時間で返答したかというレスポンスの速さのことを言っている。「エリック松永の英語道場」で指摘されているように、グローバルなビジネスシーンではResponsivenessが非常に重要である。100%正解でなくても、とにかく何か返答する。もしかするとそれがヒントになって、相手は解決策を見つけることができるかもしれない。全く当たっていなくても、自分の存在をアピールすることができる。黙っていたら、存在しないのと同じだ。

最初の事例に戻ると、本社のマーケティングはレスポンスよく情報を出してきた。残念ながらそれは結果的に不正確な情報だったわけだが、全くないよりマシであると考えるべきなのである。新製品情報が全くなかったら、提案活動どころか、新製品発表準備すら始められない。出てきた情報をもとに、できるところからはじめて、情報が変わったら起動修正する。

じゃあ、情報の正確さをどうやって判断すればいいのかというと、複数の情報ルートや視点で検証するしかない。印刷物は一度作ってしまうと修正が難しいしコストもかかるので、ここはじっくり取り組む。確度が十分上がるまでは、PDF原稿を印刷するなど工夫すればいいのである。

(参考記事)
日本のビジネスマンがグローバルビジネスになじめない理由--エリック松永の英語道場(11)
http://japan.zdnet.com/sp/feature/08eric/story/0,3800086749,20382057,00.htm

| | コメント (0)

2008年12月17日

トラブルシューティング中に責任逃れと思われないために

トラブルシューティングというものに対する理解の齟齬が要因で、顧客の心証を害することがある。

製品の不具合が発現するためには「引き金」が必要である。「引き金」は特定の操作や操作、周辺システムの環境、もしくはそれらの組み合わせなどだ。たとえばある値より長いデータのpingにより起きるping of death。ping自体は正常な処理だが、受信したオペレーティングシステムの不具合を誘発してシステムがダウンする。トラブルシューティングで最初に行うのは、この「引き金」を見つけることである。「引き金」を早期に発見することには次の意義がある。

  • 「引き金」を引かないような運用(いわゆる回避策)をお客様にお願いすることで、不具合の発現を抑止できる。
  • 意図的に作り出せる「引き金」であれば、再現環境を構築し、根本的な不具合の発見と修正をより効率的・迅速に行える。

「引き金」を見つけるには、ログを解析する、設定を確認するなど様々な手法を駆使し、まず仮説を立てる。次にその仮説を検証するために、「引き金」と思われる設定を変更したり操作を意図的に行うなどする。もし仮説が外れていた場合は、別の仮説を立てて検証する。このサイクルを繰り返す。

以上のようなトラブルシューティング基本手順をよく理解していない人は、「引き金」を見つけようという行為を「他者に原因を押しつけて責任逃れしようとしている」と感じたり、仮説・検証サイクルを「行き当たりばったりのモグラたたきをしている」と誤解することがあるようだ。

こういった誤解を避けるためには、手順を体系立ててきちんと説明する、つまり原因追及のプランや流れを説明することはもちろん、言葉の選び方に留意する必要がある。ある設定や環境が引き金ではないかと疑っていてその変更や調査を依頼する場合は、「○○が問題を引き起こす要素(要因、引き金)でないかと考える」と表現するのがよい。このとき「○○に問題があるのではないか」と表現すると、責任逃れと取られかねない。

回避策を提示すると、「バグがある状態では怖くて使えない」「ほかにも何か致命的なバグがあるのでは?」と言ってくることがある。極論すれば、すべてのハードウェアやソフトウェアは怖くて使えないと言っているのに等しい。バグがあるという前提で、うまく付き合っていく必要がある。これがIT業界の現実である。

| | コメント (0)

2008年12月16日

No news is good newsだった三菱東京UFJ銀行システム統合

三菱東京UFJ銀行のシステム統合が完了した。

5月12日の第1回移行作業で軽微な障害が発生したが、その後の移行作業はきわめて順調で、全く不具合が聞こえてこなかった。まさにNo news is good newsである。システム移行ではありがちなように、もしかすると現場ではそれほどスムーズではなかったのかもしれない。しかし利用者には全く迷惑をかけることなく、史上最大規模の移行作業を完遂した。この業績は賞賛に値する。

ところが往々にして、順調で何も問題なく終わったプロジェクトは顧みられることが少ない。途中で大トラブルが起き、それを苦労して解決したものが脚光を浴びがちである。これは不公平だ。リスクの芽を早期に摘み、粛々と業務を進める優秀な人たちにもスポットライトを当てたい。

日経ビジネスオンラインに谷島宣之氏が書いた2本の記事は一読に値する。

「トレードオフの概念は日本に無いのか」三菱東京UFJ銀のシステム一本化報道に思う
http://business.nikkeibp.co.jp/article/tech/20080520/157860/

失敗を待つマスメディアの監視下システム一本化を始める三菱東京UFJ銀行
http://business.nikkeibp.co.jp/article/tech/20080422/153876

日本のIT業界の金字塔として後世に語り継ぐべき一大プロジェクトであるが、5月の軽微なトラブルの時に鬼の首を取ったように騒ぎ立てた一般マスコミは、どうやら統合完了を報道する様子がない。いずれ「日経コンピュータ」や谷島氏が関係者に取材して記事を書くと思うが、微力ながらこのブログにも書き留めておきたい。

| | コメント (0)

インド人はショートカットを好む

「日経コンピュータ」(2008年12月15日号 )が、インドソフトウェアサービス協会会長ガネッシュ・ナタラジャン氏のインタビュー記事を掲載している。インドや日本、中国の国民性について興味深いことが書いてあった。

日本人はシステマティックにプロセスの順番を踏まえて考えるが、インド人はショートカットして結論を求めがち。インドはインフラが整備されていなくて渋滞が多い。常に新しいルートを考える必要に迫られる。このため「なぜだろう」と常に考える国民性が醸成された。この点は、社会インフラが整備されている中国に比べて優位点である。

こういった文化論は、ともすればステレオタイプに陥りがちで危険ではある。日本人、インド人とひとくくりにできるほど人間は単純ではない。とはいえ、インドのエンジニアと一緒に仕事をしていて物事の進め方に違和感を感じたとき、それも一理あると受け入れられるような視点を持っておくことも必要である。幸いにして、私がふだん接しているインド人ソフトウェアエンジニアたちには、それほど違和感を感じない。

| | コメント (0)

2008年12月13日

T. D. ミントン「ここがおかしい日本人の英文法」

大西とマクベイの「ハートで感じる」シリーズを先に読んだほうがいいだろう。この本は解説がちょっと高度でわかりにくいかもしれない。しかし、「ハートで感じる」シリーズで取り上げないような高度で微妙なニュアンスの表現も出てくる。仕事の内容によっては、こういった表現が必要になってくるだろう。特に政治的交渉を行うマネージャ以上のクラスは、意識して身につけておくべきであろう。

前書きでミントンが書いているのが、「言語感覚」に基づく直感力は文法知識に勝るということ。言語感覚を身につけるには、長期間にわたって大量の英語に晒される必要がある。全くその通りで、1日30分の勉強で英語が身につくという広告をよく新聞や雑誌の広告で見かけるが、そんなことはありえない。

24ページ
現在形はいつでも成り立つ状況に使う。出来事や動作には使えない。現在進行形は一時的に成り立つ状況に使う。

33ページ
一般論を展開するときは名詞の複数形を使う。不定冠詞を使うか複数形を使うか悩むことがあるが、定冠詞aには「1つの」という意味が含まれる。一般論は複数の集合に対して言及するのだから「an elephant is big」ではなく「elephants are big」とする。

40ページ
定冠詞theはとにかく唯一のものを表す。関係代名詞で修飾されているからという理由でtheを付けたくなることがあるが、関係代名詞での修飾の有無とtheを使うかaを使うかは無関係。それぞれ別の意味になる。the man you can rely onは、信頼できる人が世の中にその人ただひとりと言うこと。a man you can rely onは、何人かいる信頼できる人のうちのあるひとりという意味。

44ページ
過去形 + already。ネイティブも使う表現だが、いい加減な物言いに聞こえる。通常は現在完了形とともにalreadyを使い、もっと長くかかると思っていたのに、もう完了してしまったと言うことを表す。

46ページ
現在完了形は現在とのつながりを感じさせる。過去形は既に終わってしまったこと。大西とマクベイは現在完了形を「「迫ってくる」,過去形を「離れている」と表現した。

54ページ
「最近」を表すのはlatelyよりrecentlyの方が安全。実際、recentlyのほうが多く使われる。latelyは、近い過去から現在まで延びているような期間を表す用法しかなく、現在完了形でのみ使われる。さらにたいていの場合否定文と疑問文で使われる。muchやa lotと一緒であれば肯定文でも使われる。

57ページ
justはexactlyよりonlyの意味で使われることが多い。

61ページ
現在完了形は行為が終わっていることに焦点があり、現在完了進行形は行為そのものや、その行為がどのくらい長く続いているかに焦点がある。

68ページ
過去の出来事を順番に並べて述べるときは、すべて過去形を使う。大過去を表す過去完了形は使わない。

86ページ
命令形は所詮命令形。pleaseをつけようがwouldなどを付けようが、本質的に丁寧な表現ではない。

87ページ
日本語の否定疑問文は丁寧さを増す表現であるが、英語ではそうならない。日本語の「~ではないでしょうか」「~してくれませんか」を英語の否定疑問文で書くのはやめたほうがいい。失礼なニュアンスになり得るので要注意。使わない方が無難である。

たとえば「Will you~」はもともと丁寧な依頼ではないし、その否定疑問文「Won't you~」も同じ(16ページ)。「Can you~」は友人に何かを頼む場合に使われる表現である。目上の人やビジネスシーンで使ってはいけない。たとえ友人であっても「Can't you~」は、やってもらえるはずと思っていることをまだやってくれていないのでイライラを表現するときや、一度断られた依頼を別の形に変えて依頼するときに使うものなので、普通の依頼のときに使ってはいけない(87ページ)。

92ページ
許可を求めるときは「May I~」がもっとも安全。友人なら「Can I~」でもよい。possiblyを付け加えると丁寧度が上がる。

98ページ
「Don't you mind~」に対して許可を与える場合はNoで答える。しかしネイティブもNoと言うことに居心地の悪さを感じている。そこで何かを付け加える。Not at allやAll rightなど。

110ページ
mustは、それが必要だと個人に感じていること。have toは客観的事実。迷ったらhave toを使う。

138ページ
「know 人/場所」は、その人を実際に知っていたり、その場所を実際に訪れたことがある場合のみに使える。そうでない場合は、know the nameやhave heard ofを使う。know ofは古めかしく響く。

141ページ
使役表現
let。相手はやりたいと思っているが、自分はやって欲しくないと思っていること。
make。相手はやりたくないと思っているが、自分はやって欲しいと思っていること。
have。相手がやってくれると期待できる権利がある場合。
got <ものごと> done。やり遂げるのに時間がかかること。gotには動作のニュアンスがある。

146ページ
keep ~ing。必ずしもcontinue ~ing/to doとイコールではない。短い動作、そしてどちらかというとイライラさせることをを繰り返し行うこと。keep laughingは、ずっと笑っているわけではない。断続的に笑っていること。


| | コメント (0)

« 2008年11月 | トップページ | 2009年1月 »