« 2007年6月 | トップページ | 2007年9月 »

2007年7月の10件の記事

2007年7月31日

「きちんと感」のあるトラブル報告書の書き方

30代OLを読者層とする女性向けファッション誌に、「きちんと感」という言葉がよく出てくる。ヒラヒラフリフリがいっぱい付いたエビちゃん風の服ではなく、かちっとしたスーツと白いブラウスにタイトスカートといった、ビジネスシーンにふさわしい「きちんと」した服装のことらしい。

社外向け文書も、「きちんと感」をしっかり出したいものひとつだ。しかし、最近見かける社外文書は、「これで大丈夫か?」と首をかしげるものが結構あってビックリする。

私が社会人になったときは、世の中にまだまだ余裕があったので、約3ヶ月の研修期間が設けられていた。最初の2週間が導入教育で、ビジネスマンとしての基本をたたき込まれる。名刺の受け渡し方、電話の取り方、そしてビジネスライティングだ。最近はこんなに悠長なことをいってられないので、入社してすぐ現場に配属され、OJT中心で育てられていると聞く。怪しげな社外文書を見かけるようになったのは、こういった研修環境の変化が影響しているのだろうか。

特にトラブル報告書は、「きちんと感」がきわめて重要だ。ただでさえ頭に来ているお客様に出す文書だ。火に油を注がないように細心の注意を払う必要がある。

「きちんと感」のある報告書にはポイントがいくつかある。どれもごく当たり前のことなのだが、それが当たり前でなくなっている世の中だから、ここに書いておく価値が十分あるだろう。

(1)フォントは明朝体

Don McMillanのプレゼン(持ちネタ)で出てきたように、数多くのフォントの中からどれを選ぶかは、その人の性格や人となりを表す。トラブル報告書の場合は、絶対に明朝体を使うべきだ。まかり間違っても丸ゴシックなど使ってはいけない。ビジネス文書ではゴシック体が一般的だが、「きちんと感」を出すには明朝体が最適である。私はWindowsで社外文書を作るので、MS P明朝を使うようにしている。

英文フォントは日本語と同じフォントにしておく。Times New Romanなどの英文フォントを選ぶと、英数字の部分が浮き上がって見えて、見た目の統一感を欠く。

(2)「拝啓・敬具」より「謹啓・謹白」

社外文書というと、判で押したように「拝啓・敬具」を使う人が多い。トラブル報告書は、会議を開催しますとか新しい製品が出ましたとかいう連絡文書と一緒にしてはいけない。かしこまった雰囲気、すなわち「きちんと感」を出すために、トラブル報告書では「謹啓・謹白」を使った方がよい。

「冒頭の挨拶文なんか誰も読んでないよ」という人もいるだろう。それは正しい。しかし、そういったところに気を配るかどうかが、「きちんと感」を出せるかどうか、きちんとしたビジネスマンと見られるかどうかの分かれ目だ。

(3)とにかくしっかり謝る

このまえレビューした報告書は、こんな書き出しで始まっていた。

拝啓 貴社ますますご清栄のこととお慶び申し上げます。平素は格別のご高配を賜り、厚く御礼申し上げます。表記の件につき、下記の通りご報告申し上げます。ご査収の程、よろしくお願い申し上げます。

これでトラブル報告書といえるだろうか。トラブル報告書は単なる事実の報告書ではない。自社の製品やサービスの問題なのか他社に非があるのかがはっきりしていない段階で出す報告書でも、「このたびの○○の障害について、貴社に多大なるご迷惑をおかけしておりますこと、心からお詫び申し上げます」とまずはしっかりと謝るべきだ。

謝ることは自分の非を認めることと思いがちだが、迷惑をかけていることについては頭を下げる必要がある。そうでなければ、その先の話を読んでもらえないかもしれない。ここはアメリカではないので、謝ることでその後の話が不利になるとは考えなくてよいだろう(少なくとも今のところは)。

(4)誤字・脱字・変換ミスは厳禁

こんなことは改めて書くまでもないのだが、実際に誤字・脱字・変換ミスだらけのドラフトが回ってくるのだから、書いておく必要がある。先日レビューした報告書は、いきなり「背景 貴社ますますご清栄のこととお慶び申し上げます」で始まっていて、開いた口がふさがらなかった。

ひととおり書いたら、しばらく時間をおいて何度も読み返そう。時間をおくことで、第三者の視点で客観的にレビューできる。他の人が見つけてくれるなどと期待しないこと。ドラフトのレビューは、内容や構成をチェックするもので、誤字・脱字・変換ミスはそれまでに撲滅しておくべきだ。ちょうど、単体テストとシステムテストの関係に似ている。

Wordのスペルチェックや校正機能も活用し、波線が付いているところは目をこらしてじっくり見ること。思わぬ間違いをしているはずだ。

(5)宛名には「殿」ではなく「御中」「様」を使う

文書の左上の宛名書きで、「○○社 △△事業部 殿」のように「殿」を使っている例が多い。実は、私が受けた導入教育でも「殿」を使うように指導された。しかし、いまなら「御中」や「様」を使うべきだ。広辞苑を見ると、こんなことが書いてある。

他人の氏名・官名の下に添えて敬意を表す語。「様」よりも敬意が軽く、また現在ではより公的な用語。

トラブル報告書に敬意の軽い言葉を使ってはまずい。会社名には「御中」だ。個人名宛で発信するのであれば「様」がよい。会社名に「様」を付けた例も見かけるが、書き言葉にはふさわしくない。話し言葉だけにとどめておくのが無難だ。

(6)レターヘッドの自社ロゴは右上に配置

自社ロゴ付きの用紙やテンプレートを使うことがある。それ自体は問題ないが、ロゴの場所は用紙の右上でなければまずい。

左上にロゴを置いたテンプレートを社外文書で使うと、相手の名前の上に自社ロゴが乗っかることになる。トラブル報告書に限らず、これは実に失礼だ。どんな場合でも、相手の頭の上に乗ってはいけない。

(7)構成は「概要」「調査状況/原因」「対策」の3本立て

まず「概要」でトラブル内容を簡単にまとめ、「調査状況」でこれまでわかっていることを説明する。原因が判明しているのであれば、それを説明する。そして最後に「対策」を書く。この構成がトラブル報告書の原則で、状況に応じて必要な情報を追加する。

あまり情報を詰め込みすぎると、かえってわかりにくく訳のわからない文書になってしまう。報告書本文はできるだけ簡潔にまとめ、詳細情報をどんどん添付資料に追い出すとよい。時系列の詳細な対応履歴や、障害に至ったロジック、対策のための操作手順などは当然添付資料行きだ。目安としては、本文はA4で1枚から2枚に抑える。添付資料は、必要なら10枚以上付けても構わない。

報告書は、渡した相手だけが読むものではない。報告の場に出ていなかった人にも回覧される。一般的にいって、管理職や幹部社員は本文だけ読んで状況を判断するから、そこだけを読んでもトラブルの経緯や対策がよくわかるようにしておきたい。添付資料は、主にシステム部門の担当者など現場の人向けだ。

| | コメント (0)

2007年7月28日

AutohideでFirefoxの全画面モードをさらに使いやすくする

Firefoxを全画面モードにしても、ナビゲーションツールバーやタブバーは相変わらず表示されている。これを非表示にするアドオンがあった。Autohideだ。

Autohideをインストールし、ナビゲーションツールバーとタブバーを自動で閉じるように設定する。ここでF11を押すと、Webのページがパソコン画面いっぱいに表示される。広く使えるだけでなく、視界に夾雑物がないので、そのページに集中できる。Macjournalの全画面モードを初めて見たときに味わったのと同じ感覚だ。

(参考記事)
Firefoxを鍛え直せ! フォクすけブートキャンプ:第3日目:広い画面を手に入れろ――Autohide

(当ブログの関連記事)
Firefoxの全画面表示
MacJournal

| | コメント (0)

2007年7月21日

Firefoxの全画面表示

FirefoxでF11キーを押すと、全画面表示モードになる。ディスプレイ解像度をXGAにしているPCでは、これが重宝する。

SXGA解像度のPCが一般的になったせいか、XGAではWebページをじゅうぶんに見渡せず、たくさんスクロールしなければいけないことが多くなったように感じる。さらに、Firefoxなどのタブブラウザ画面表示領域をタブバーに奪われるので、さらにページの縦が狭くなってしまう。

こういうときはF11キーの出番だ。タイトルバー、メニューバー、ステータスバーが消え、さらにWindowsのタスクバーも消える。Firefoxのナビゲーションツールバーを非表示にすれば、もっと表示領域を稼げる。タブブラウジングにこだわらないのなら、タブバーを表示しないようにすることも可能だ。ここまで消すと、本当にWebページだけの表示になり、画面をいっぱいに使える。

| | コメント (0)

2007年7月20日

「これがないと売れません」

競合他社に比べて機能が不足しているために苦労しているという話を、営業の商談報告でよく聞く。いまの会社の製品は、新興企業ということもあってまだまだ機能が揃ってないからそれもうなずけるが、以前いた会社でも、その分野でかなりメジャーな製品について同じような話をよく聞いた。どの会社・どの製品をやっていても、「隣の芝は青い」ということだろう。

重要な見込み客の場合は、開発部門や経営層にエスカレーションして、何とか機能を実装してもらう。ところが、せっかく対応したのに、肝心の商談が取れないということが実際にある。開発部門がその機能を実装するのにつぎ込んだ投資を回収できないという最悪の事態だ。実装に時間がかかりすぎて正気を逸してしまうということもあるし、ほかにも要件が次々と出てきてしまうということもある。

私が経験した事例では、幸い本社からお咎めがなかった。しかし投資効果をじっくり見ている人間が本社にいたら、結構やばかったのではないかと思う。ギブ・アンド・テイクのテイクばかりでギブしないと、相手にされなくなるばかりか、そのうち失格の烙印を押されて、特に外資系の場合はおさらばとなってもおかしくない。

機能要件だけでなく、評価中のトラブルについても同じだ。「このトラブルが解決できないと商談を落とす!」と強烈なエスカレーションを受けたことが半年くらい前にあった。そのトラブルはうまく解決できたのに、その商談はまだ終わってない。商談に残っているから、少しは貢献できたのだろうか。

「これがないと売れません」が本当に「Must Have」なのか、ほかにいろいろとある要件のうちの1つで、実は「Nice to Have」なのかをきちんと見分ける必要があるだろう。もちろん営業は成績が上がらなければ即クビという因果な商売なので、そんなに悠長なことをいっていられないという事情は理解するが。

| | コメント (0)

2007年7月19日

立ち話は周りをよく見て

電車の中やエレベーターの中で仕事の話をしている人を見かける。自分の同僚が話しかけてくることもよくある。進行中の商談の話や、代理店や顧客に対する不平や不満(ときには悪口)を口にする人もいる。

こういう話を周りの人に聞かれるとまずいと思うのだが、無頓着な人が多いようだ。せめてイニシャルトークにして欲しいところだ。もちろん、どこで面が割れているかもしれない狭いIT業界だから、見知らぬ人のいるところでこういった話をしないのが安全だ。F社といえば富士通だし、N社といえばNECかNRIと、業界人なら想像できてしまう。

トイレも要注意。立って用を足しながら、隣の人と世間話をする男性は多い。そのとき個室に誰が入っているのか。もしかしたら、「最近、あの課長が・・・」とか「あのプロジェクトが・・・」などと他の人を批判する話をしているときに、その当人や関係者が個室に入っているかもしれない。あとで怖いことになる。話を聞いただけなのに、悪口の共謀者と思われては損だ。私はトイレで話しかけられたら、まず後ろを振り返って、個室のドアが閉まってないかどうかを確かめるようにしている。もし誰かが入っているようなら、相手に目配せして話をやめさせる。

| | コメント (0)

2007年7月14日

Don McMillanのPowerPointべからず集

オルタナティブブロガーの永井孝尚氏がこんなビデオを紹介していた。元IBMのエンジニアというエンジニア・コメディアンのDon McMillan氏が、職場やセミナーでよく見かけるPowerPointの例をおもしろおかしく解説するコント。

これはいい。「ある、ある、ある~」と思わず声に出して笑いながら観賞。

| | コメント (0)

2007年7月12日

月曜のミーティングがサザエさん症候群を招く

日経ビジネスのポッドキャスト「編集長のここだけの話」に、月曜にミーティングをしないという方針の会社の話が出ていた(参考記事)。

日曜の夜、楽しい週末が終わり、緊張とストレスの連続の仕事場に明日から戻らなければならないと考えると、誰しも気が重くなる。これを世間では「サザエさん症候群」と呼ぶことがある。

それを助長しているのが、月曜のミーティング。特に営業は、月曜のミーティングで商談のレビューをしたり、売上予測をしたりしてから、週の残りを客先周りに費やすのがよくあるパターン。そうすると、月曜の朝から上司にプレッシャーをかけられることになる。順調に数字を達成できていれば左うちわだろうが、そんな悠長に構えていられる営業は多くないはず。このままで予算を達成できるのか、目標達成のためにどんな対策を立てているのか、先週はどこへ行き、今週はどこを訪問するつもりで、課題はなにか、その対策はなにか。細々と突かれ、どなられ、けなされる。中には泣き出してしまう営業もいると聞く。

ポッドキャストが紹介していた会社は、こういった月曜のミーティングで社員のメンタルヘルスを害さないように、月曜は仕事環境への復帰に専念させ、難しいミーティングは週の半ばに設定するとのこと。これはいい考えだ。

開発プロジェクトで週半ばに進捗管理ミーティングなどを設定することは可能だろう。月曜の朝のミーティングまでにいろいろな報告資料を準備するのは大変だ。下手をすると土曜が資料作りの時間になってしまう。週半ばのミーティングであれば、十分余裕を持って準備できる。

営業部門では難しいかもしれない。出張の多い職場もそうだ。私がシステム開発に従事していたころは、週のほとんどを客先で過ごしていたので、部署の全員が集まれるのが月曜しかなかった。いまの会社も社内ミーティングは月曜の9時からで、それが終わると営業は客先に散っていく。

(参考記事)
本当の教育再生 光る現場に学べ(2007年5月25日)
http://business.nikkeibp.co.jp/article/podcast/20070524/125471/

| | コメント (0)

2007年7月10日

メールを投げてはいけない

「メールを投げる」「質問を投げる」「リクエストを投げる」という言葉をメールやふだんの会話でよく見聞きする。この「投げる」という乱暴な表現が耳障りで仕方ない。せめて「投げかける」くらいにして欲しい。もちろん「メールを出しておいた」「質問した」「リクエストした」と平易に書いて全く問題ない。

使っている人はあまり意識していないのかもしれないが、「メール/質問/リクエストを出しておいたので、あとは相手が返事をするだけ。私は知らないよ」という投げやりな意識が根底にあるように思う。質問にしろリクエストにしろ、こちらの期待通りのアウトプットを得るには、フォローアップが欠かせない。これを十分理解していれば、「投げる」という乱暴な言葉を使う気持ちにならないはずだ。

| | コメント (2)

2007年7月 9日

ノートPC持ち出し禁止というセキュリティポリシーの是非

情報漏洩対策として、ノートPCの持ち出しを禁止している会社がある。それを否定する気はないが、やり方によっては弊害が大きい。

ノートPCも携帯電話もなかったころ(80年代~90年代初頭)、営業や作業で外出した社員は、夕方になると伝票処理などをしに会社に戻らなければならなかった。外出先で各種の事務処理をできるようにし、生産性を落とす移動時間や会社での事務処理をなくすことができたのは、ノートPCやモバイル環境のおかげだ。ノートPC持ち出し禁止はこれに全く逆行し、20年前の仕事環境に戻れと言っているに等しい。

中には、代替策をきちんと手当てしている会社もある。たとえばダイキン(参考記事)。どのオフィスでも同じようにメールを読み書きできるように、Thunderbirdをカスタマイズしたメール環境を自社で構築している。もっとも、この環境を構築した理由は、ノートPC持ち出し禁止するためではなく、ノートPCが普及していないころに、共有PCで個人のメールを読み書きできるようにするためであったのだが。

私が仕事で付き合っている会社はこれと全く反対だ。ノートPCが持ち出し禁止で、メールを見るには会社に戻らなければならない。生産性が落ちて従業員に不満だが、会社のポリシーだからとみんなあきらめている。話を聞くと、モチベーションが相当落ちていると感じる。この会社の人にメールを出すときは、送信したあと電話で確認したり、メールをあきらめて最初から電話で連絡したりと、手間がかかって仕方がない。さらに、何とか効率的に仕事しようと、こっそり私物PCを使うという悪循環に陥っているようだ。

こういう会社には転職したくない。せっかく転職した会社がガチガチのセキュリティポリシーで、仕事がやりにくくてしょうがないと、自分の力を十分に発揮できない。面接のときに、どのくらい厳しいポリシーを持っている会社か、自分の仕事スタイルにあった環境が揃うのかを確かめておきたい。


(参考記事)
ダイキン工業はなぜ「Thunderbird」を選んだのか
http://www.itmedia.co.jp/bizid/articles/0703/09/news112.html

| | コメント (0)

2007年7月 7日

強いパスワードの生成方法

数字4桁や簡単な単語、自分の氏名などをパスワードに使ってはいけないというのはいまや常識。では、推測や辞書攻撃に耐えられる強いパスワードをどうやって作るか。あまり複雑にしてしまうと、覚えられなくなってしまう。アイディアをいくつかまとめてみた。

(1)文字をずらす

「apple」のように単純な単語は辞書攻撃であっという間に破られてしまうが、ひと手間加えれば比較的強いパスワードにできる。まず、アルファベットを前か後ろにずらす方法。a→b、p→qとひとつずつ後ろにずらして「bqqmf」という文字列を生成する。前と後ろに交互にずらす、2つずらすなどのテクニックを使えば、もっと推測しにくくなる。

(2)逆につづる

覚えやすい単純な単語から複雑なパスワードを作る方法のふたつめは、単語を逆につづるやりかた。「apple」なら「elppa」となる。簡単に推測できるのであまりお薦めではないが、あまり重要でないパスワードや、ほかのテクニックと組み合わせて使えば、十分役に立つ。

(3)パスワード生成ツールを使う。

パスワードの桁数や文字種を指定してランダムなパスワードを生成するツールがある。何回か生成して、十分複雑で、かつ覚えられそうなものを選べばよい。私は、秀丸エディタの開発元、サイトー企画の「パスワード総合管理」を使っている。サイトやアプリケーションごとにユーザIDとパスワードを記録し、ファイル自体を暗号化してくれる。

(4)身近な文字列を利用する

ポッドキャスト「Security Now!」で視聴者が紹介していたテクニックだ。コンピュータディスプレイの型番とシリアル番号を組み合わせると、十分複雑なパスワードとなる。もし忘れても、ディスプレイを見ればもう一度作り出せる。Webサイトごとに別のパスワードにするために、型番とシリアル番号のあいだにドメイン名を入れるという手もある。

ほかにいろいろな方法があると思うが、定期的にパスワードを変更するのが大切なのは、どの方法でも共通だ。

| | コメント (0)

« 2007年6月 | トップページ | 2007年9月 »