以前から何度も議題になる(けれども改善されない/しない)問題として、本社/東京オフィス間のコミュニケーション問題がある。 うまく情報共有ができていなかったり、共通認識になっていない背景にもとづいてのコミュニケーションによってうまく意思が伝わっていなかったりするという問題である。 特に電子メールによるコミュニケーションに多発気味のようである。
しかしなにもこれは本社/東京オフィス間だけの問題ではない。 電子メールをその特性を意識せずに使用することによって、コミュニケーションしていると思いながらも「実は一方通行」でしかなかったり、あるいは「その一方通行さえうまくできていな」かったりすることがままあるのである(もちろん自分も含めて)。
そこでまずは電子メールを含むコミュニケーションツールの利用方法について検討し、ガイドラインを決めていこうということになった。 もちろんガイドラインはシンプルかつ効果的なものにしたい。
まずは電子メールについて現状としての雑感を(特に自分の場合について)。
「ま、返事しなくてもいっか」と思わせるメールの筆頭は、メーリングリスト宛のもの。 以下のものは無視してしまう(あるいは先送りしているうちに忘れてしまう)事が多いタイプ。
「検討しなければならないなぁ(そのうち)」->「しばらくたっちゃたなぁ」->(リファイル)
「意見を考えなければならないなぁ」->「しばらくたっちゃたなぁ」->(リファイル)
○○した -> (完了報告なし) -> (リファイル)
(そうですね) -> (リファイル)
「○○について問題があればご指摘ください」-> 読めん (Mew が wvHtml で変換して表示してくれるからちょびっとだけ見るけれど)。
「○○について問題があればご指摘ください」-> 読めん (Mew が xlhtml で変換して表示してくれるからちょびっとだけ見るけれど)。
ヤバ。間違える(自分)。送信前に読み返しても、なぜか気がつかない。
まぁそういう場合もあるので、差し引いて読まないといかん。
いいね! 非常にいい。ほっとする。嬉しい。いい気分。
自分ではほとんど書かないんだけれど。
「誰に」「何を」「いつまでに」「どの品質で」して欲しいのかが不明確というのが問題の大部分を占めていると思う。 会話におけるリクエストでもこれを明確にできていないのだから、メールではなおさらな状態である。
逆に言うとこれらがはっきりしていて約束がかわされたならば、、添付ファイルフォーマットの問題などは些細な問題で(いや、面倒ではあるけれども)、相応に努力してしかるべきアクションをとっていくであろう。
それから、リクエストメールに対してはどうするにせよ「受ける」「断わる」「別の提案をする」というレスポンスをリクエストした者に返すべきだけれど、メールだとこれがないがしろになってしまう事も多い。 これも大きな課題であるな。
まずは、メッセージのタイプ(指示/命令? リクエスト? 情報? ……)を分析して、どのようにすれば効果的なコミュニケーションがなされるようになるか検討してみよう。
[ ビジネスメール ]
以前メールによる社内コミュニケーションの問題について書いて以来、いろいろと考えてみている。
そんな中、東洋経済新報社の「Think! SPRING 2006 No.17 超ロジカルシンキング」の中に参考になる記事を発見。 照屋華子氏の「ロジカル・ライティング - 論理的に考え、伝えるための3つの鍵を身につける」という記事だ。
すべてのビジネス・コミュニケーションは「伝え手」「受け手」「テーマ」「答え」「期待する反応」という5つの基本要素で成り立っている。-- Think! SPRING 2006 No.17 p.43
おお、ちょうどこういう切り口を探していたところだったんだ。 電子メールによるコミュニケーションも全く同じ枠組みである。 記事の中ではロジカルシンキングをコミュニケーションで生かすという話題を中心に展開しているが、十分メールの書き方に通じるものがある。
この記事と、さらにちょっと前に買った「SEの実力を磨く究極仕事術」のメール術の章を参考にガイドライン案のスケルトンを作ってみた。
感情論は今回は置いておいて、情報共有・課題共有・リクエストの明確化・処理促進をポイントに列挙。 それから署名その他、一般的な話もいまのところ省略。
ポイントを列挙しただけなので、他人にもわかる形にはなっていない。
まずは自分自身に適用して、整理していってみることにする。
○○様へ # 受け手 △△の××(自分)です。 # 伝え手 テーマ ****** コミュニケーション設定 ○○の結論 # 答え (結論) ========== ... (ここまででポイントを言いきる。) 具体的な内容 # 答え (詳細) ============ 項目1 ----- .... - リスト項目 - リスト項目 項目2 ----- ... - リスト項目 - リスト項目
コミュニケーション設定を行う。
結論を書く。
根拠・資料などを書く。
どれか
メールでは不適当と思ったらコミュニケーション手段を 直接 / 電話に切り換える。
昨年から会社内で「Google Apps でカレンダー共有したい」という声があって、計算機管理者として頭にはあったんだけれど「メールがどうなるの?」「今までの Google ドキュメント上のドキュメントはどうなるの?」などがクリアでないので二の足を踏んでいた。
今のメールアドレスを Google Apps の Gmail に移行させると
といった問題が出る。 ということで、Google Apps は今のドメイン (ここでは example.com としておく)に apps サブドメインを作って apps.example.com としてそこで社内向けサービスとして使うことにした。
申し込みページから、ドメイン名の指定 (apps.exemple.com)・管理者の入力・管理者アカウントの作成を実行。 これで管理画面に入れるようになる。 そこでドメイン所有権の確認の指示にしたがって
googleffffffffxxxxxxxx(確認用の名前).apps IN CNAME google.com.
を example.com の BIND のゾーンファイルに追加。
ヘッダ用のロゴもばっちり設定。
各サービスごとに CNAME を設定する。
管理画面の指示に従ってゾーンファイルに以下を追加。
mail.apps IN CNAME ghs.google.com. calendar.apps IN CNAME ghs.google.com. docs.apps IN CNAME ghs.google.com. sites.apps IN CNAME ghs.google.com.
これで http://calendar.apps.example.com/ などで各サービスに入れるようになる。結局すぐにリダイレクトされてしまうから絶対必要ではないけれど、設定しておいた方が格好いい。
メールは今まで通りレンタルサーバで運用するので、Gmail はいいかなと思ったがサブアドレスとして使えるように一応設定しておいた。
管理画面の指示に従ってゾーンファイルに以下を追加。
apps IN MX 10 ASPMX.L.GOOGLE.COM. apps IN MX 20 ALT1.ASPMX.L.GOOGLE.COM. apps IN MX 20 ALT2.ASPMX.L.GOOGLE.COM. apps IN MX 30 ASPMX2.GOOGLEMAIL.COM. apps IN MX 30 ASPMX3.GOOGLEMAIL.COM. apps IN MX 30 ASPMX4.GOOGLEMAIL.COM. apps IN MX 30 ASPMX5.GOOGLEMAIL.COM.
これで username@apps.example.com 宛のメールは Google Apps の Gmail に届くようになる。
あとはまずは自分のユーザアカウントとテスト用のアカウントを作って、Google Apps の機能、特に共有関連についてチェック。 ここら辺の作業までで最初の申し込みフォームの入力始めから4時間ぐらい。 BIND は自社サーバ上にあるのですぐに反映させられたので、そのあたりの待ち時間が必要なかったのでその点は楽であった。
基本は Google アカウントで提供されている機能とたいして変わらないな。Standard Edition だからかもしれないが、思ったほどドメイン内のユーザ間での共有や管理者からの一括管理機能ってなくて拍子抜け。 Google カレンダーも基本はユーザ間で共有をかけていくみたいだし。
新しくドメインを用意してユーザ管理していくには Google Apps 導入は効果的そう。 逆に既に別にメールアドレスがあって、しかも皆個別に Google アカウント使って活用とかし始めちゃっていたりすると、また別に Google Apps アカウント作るから使ってねっていってもメリットを感じてもらえないと使われなくなりそう。
Google ドキュメントなんかは、個人で個別に発行した Google アカウント上にあるのが気持ち悪かったので、Google Apps 上にもってきてそこでドメイン内で共有していけるようになるというのは嬉しい。 それと Google Apps の Google サイトに Google ドキュメントを貼りつけることができるので、ドメイン内での情報共有に使えそう。Google ドキュメント上の共有だけだと、ナビゲーション的にどれがどのドキュメントかわからなくなって埋もれてしまいそうだったので、プロジェクト別に Google サイトを作れば良さそうだ。
しかしこれから Google Apps を活用していくにはガイドラインを作る必要あり。 スケジュールの共有は Google Apps 上でこのようにしてねとか、Google ドキュメントは個別 Google アカウント上ではなくて Google Apps 上で作るべしとか。
まずは何人かにモニター利用してもらって「これって便利」探しをしてみよう。
千葉の東京ディズニーランドいったり、秋葉原の東京ディズニーランド(アキヨド)へ行ったりといろいろ満喫した3連休を終えて月曜日スタート。
で、ガイドラインのドラフトをブラッシュアップしたり、納税したり。
それから、ひとつの決断、おつかれさま的なお別れがあるなど。今回の経験が人生の糧になり中長期的に最善な選択だったと思える日がくると信じてる。
夜は Xperia A の設定2日目。まずは Wi-Fi 設定。spモードまわりで、またここでもパスワード設定が必要になるんだけれど、ほんとにNTTドコモは暗唱番号/パスワードの数を減らせないものなのかねぇ。
接続は問題なく。「エリア連動Wi-Fi」が設定にみあたらなくて機能が無くなっちゃったのかなーと思っていたんだけれど、mixi で「あ、それは設定>電源管理のところにあります」って教えてもらったので、明日設定する。
あとは Facebook のログインと設定。こちらは PC で使っているので、機能というか構成要素というか、そういうのは何となくわかっているのでわりにスムーズに導入できた感じ。通知のオン/オフ設定をどんな塩梅にするかは、使ってみて調整ね。
Spirit#photography
— Naney (@Naney) January 25, 2022
RICOH GR III #GR #GRIII #GR3 pic.twitter.com/xD6m4FXrtZ
Naney (なにい) です。株式会社MIXIで SNS 事業の部長をしています。
※本サイトの内容は個人的見解であり所属組織とは関係ありません。