nDiki : 4月12日

■ 過去の今ごろ

過去の4月12日より。

• EXLIM EX-Z3
  • 5年だか10年だか使えるようにかなり吟味して買ったとか言ってたな。銀塩ならアリだが、デジカメでははたして?

• 12:50 インタビューお姉さん再襲 (2001-11-26)
• デジカメつきペン (2004-03-17)
• jpegtran で Exif データを削除 (2004-11-27)
• 今日のさえずり - スポーツの制裁金ってどこにいくのだ? (2008-06-11)
• 今日のさえずり - NEW MEGALOPOLIS かぶった (2008-06-13)

■ PEG-TJ25 インストールメモ

• OffStroke 0.3
  • OffStroke.zip / OffStroke.prc

スタイラスによる簡単な操作で電源を切る Palmware。 PEG-TJ25の電源スイッチがいまいち使いにくいので電源を切るよいソフトがないか探していた。

電源ボタンのスライド方向に合わせて、キーボードエリアから検索エリアへスタイラスをすべらせると電源が切れるように設定してみた。

• AutoDimmer v1.0
  • AutoDimmer10.zip / AutoDimmer.prc, AutoDimmer_jpJP.prc (AutoDimmer_jpJP.oprc)

• お気に入りの Palmware (2005-07-06)
• PEG-TJ25 インストールメモ (2004-04-06)
• PEG-TJ25購入 (2004-03-05)
• PEG-TJ25 インストールメモ (2005-12-02)
• CLIE マルチスタイラス購入 (2004-03-11)

■ DELL PowerEdge 2600 が帰ってきた。

ようやくこれで仕事になる。

• USB HDD 上に ext3 ファイルシステムを作ろうとしたらフリーズ (2006-01-16)
• ファイルシステム作成はノート PC でやっておいた (2006-01-17)
• DELL PowerEdge 2600 本社へ出張 (2004-04-01)

■ 新人歓迎会

昨年インターンとして働いたのち、この春に入社した新人スタッフの歓迎会。 当初は花見とセットの予定であったが、天候不良につき呑み会のみ。 場所は駒八 秋葉原店で。

@ 駒八 秋葉原店

料理はまずまず普通の感じ。ボリュームがあるので満足感はあるか。 いや、皆が食べなさすぎ?

@ 話題

まだ花粉シーズンなので、アルコールはパス。 呑むと鼻が詰まりまくるんだよねぇ。

「呑めば治るよ」

はい。「呑めば××は治るよ」というセリフは聞きなれているので軽く流しておくってことで。

今回は mixi ネタは少なめ。 社内での mixi ブームも一段落か。 mixi日記書きが定着した人もいるので、使う人は使うという感じで安定してきたといったところか。 社長は先日のPCのクラッシュでメールの読み書きすらままならない状況で、mixiを読むどころではないとか。

あとはオメデタ?と思ったら転職らしいという話とか。 本所吾妻橋は台東区ではなくて墨田区だよとか。

@ 傘忘れた

帰りの電車で席に座れたのだが便意に気をとられて、傘を置いてきてしまった。 バイト先の飲食店の置き傘をもらったもので、結構ボロかったし惜しくはないんだけれど、どちらにせよ新しい傘が必要だな。

• 宴会写真

• 今日のさえずり - それ多分 Gmail spam フォルダの中 (2007-12-27)
• 今日のさえずり - 「ゑぶあぷり」って誤変換にしておくのは勿体ないな (2008-09-05)
• 新年会 + 送別会 (2005-01-12)
• PHSつながった (2004-12-30)
• 世代間グループ化されてきた? 歓迎会 (2006-04-13)

■ サーバ用 IBM xSeries に Debian GNU/Linux をインストール

4月にはいってしばらく経ち、ようやく時間的な余裕がでてきた。

死にかけている社内サーバをリプレースするために調達してあった xSeries への Debian GNU/Linux のインストールを開始。 今回はもう1人の管理者と2人で管理できるように、一緒に作業を進めていく(いや、基本的には彼がやってくれた)。

sarge は随分インストールが楽になっている様子。 そういえば普段 dselect な自分には aptitude の操作がいまいちわからん。 そろそろ移行した方が良いのか?

• QEMU を使って Debian GNU/Linux 上で Windows... (2005-04-08)
• 納品前日なのに /var が壊れた! HDDからのブートで Debian ... (2005-09-27)
• Debian GNU/Linux sid 環境を新 HDD へ (2006-07-29)
• Perl モジュール Parse::Lex 2.10 をインストール (1999-08-18)
• Debian に RSS リーダ「フレッシュリーダー」をインストール (2006-03-06)

■ メールによる社内コミュニケーションの問題

以前から何度も議題になる(けれども改善されない/しない)問題として、本社/東京オフィス間のコミュニケーション問題がある。 うまく情報共有ができていなかったり、共通認識になっていない背景にもとづいてのコミュニケーションによってうまく意思が伝わっていなかったりするという問題である。 特に電子メールによるコミュニケーションに多発気味のようである。

しかしなにもこれは本社/東京オフィス間だけの問題ではない。 電子メールをその特性を意識せずに使用することによって、コミュニケーションしていると思いながらも「実は一方通行」でしかなかったり、あるいは「その一方通行さえうまくできていな」かったりすることがままあるのである(もちろん自分も含めて)。

そこでまずは電子メールを含むコミュニケーションツールの利用方法について検討し、ガイドラインを決めていこうということになった。 もちろんガイドラインはシンプルかつ効果的なものにしたい。

まずは電子メールについて現状としての雑感を(特に自分の場合について)。

@ メーリングリスト

「ま、返事しなくてもいっか」と思わせるメールの筆頭は、メーリングリスト宛のもの。 以下のものは無視してしまう(あるいは先送りしているうちに忘れてしまう)事が多いタイプ。

• 宛先不明のもの/「○○各位」宛のもの
  • 10人が参加しているメーリングリストでは、送信者から届くパワーは通常のメールの1/10以下である。
• 「ご意見があればお願いします」
  • (誰かが意見するだろう)
• 「ご意見があればお願いします」
  • (メーリングリストに? 個人宛に? まいっか)
• 「どちらが良いと思いますか?」
  • (メールを出した貴方はどう思っているの?)
• 誰か一人(か二人)がメーリングリストに返事した
  • (話が進んでしまっているようだし、出遅れたな。もういっか)

@ 「ご検討ください」

「検討しなければならないなぁ(そのうち)」->「しばらくたっちゃたなぁ」->(リファイル)

@ 「ご意見ください」

「意見を考えなければならないなぁ」->「しばらくたっちゃたなぁ」->(リファイル)

@ 「○○してください」

○○した -> (完了報告なし) -> (リファイル)

@ 「した方が良いと思います」

(そうですね) -> (リファイル)

@ 形式的な不備

• 無関係なメールへの返信によって作成された新規メール
  • (一応読むけど)
• 何を言いたいのかよくわからないメール
  • (ぱっと見るけど)
• typo
  • (人間誤ちがあるからあまり咎めはしないけれど、それに気をとられて本文に対する集中度ダウン)
• (いわゆる)全角文字と半角文字が混在
  • 内容の評価までダウン
• 文章に句読点が無い
  • (日本語?)
  • 適当にメールを送ってきている? ではこっちも。
• 長～～～～い全文引用(の全文引用の全文引用の……)
  • で、本文は2行ですか?

@ 添付資料が MS Word 形式

「○○について問題があればご指摘ください」-> 読めん (Mew が wvHtml で変換して表示してくれるからちょびっとだけ見るけれど)。

@ 添付資料が MS Excel 形式

「○○について問題があればご指摘ください」-> 読めん (Mew が xlhtml で変換して表示してくれるからちょびっとだけ見るけれど)。

@ 予定の日時を間違えている

ヤバ。間違える(自分)。送信前に読み返しても、なぜか気がつかない。

@ 内容がムカつく

まぁそういう場合もあるので、差し引いて読まないといかん。

@ 時候の挨拶つき

いいね! 非常にいい。ほっとする。嬉しい。いい気分。

自分ではほとんど書かないんだけれど。

@ 結局のところ

「誰に」「何を」「いつまでに」「どの品質で」して欲しいのかが不明確というのが問題の大部分を占めていると思う。 会話におけるリクエストでもこれを明確にできていないのだから、メールではなおさらな状態である。

逆に言うとこれらがはっきりしていて約束がかわされたならば、、添付ファイルフォーマットの問題などは些細な問題で(いや、面倒ではあるけれども)、相応に努力してしかるべきアクションをとっていくであろう。

それから、リクエストメールに対してはどうするにせよ「受ける」「断わる」「別の提案をする」というレスポンスをリクエストした者に返すべきだけれど、メールだとこれがないがしろになってしまう事も多い。 これも大きな課題であるな。

まずは、メッセージのタイプ(指示/命令? リクエスト? 情報? ……)を分析して、どのようにすれば効果的なコミュニケーションがなされるようになるか検討してみよう。

• 研究結果「メールの意図が正しく伝わる確率は5割」
• 各種コミュニケーション・ツールの強みと弱み － 1/2 － ＠IT情報マネジメント

[ ビジネスメール ]

• ビジネスメールガイドライン案 (2006-05-05)
• 日本語ファイル名どんとこい (2005-03-07)
• Linux 母艦ノート PC を使わずに仕事ができるかチャレンジ (2007-08-20)
• [ Java ] Unicode (UCS) -> 別の charset (2003-12-12)
• Rubric でプライベート SBS を立てるも 0.140 では日本語に不具合 (2006-07-22)