nDiki : ガイドライン

ガイドライン - guideline

関連情報

  • ルール
  • 規約

2006年2月6日 (月)

個人目標設定における課題

去年失敗している「個人目標を用いた評価制度」を今年もやるらしい。

私が感じる限りでは、去年とほとんど何も変わっていない。

  • 観念的な事業方針から、各スタッフに個人目標に一気にブレイクダウンさせようとしている。部門目標 / プロジェクト目標も明確にされないまま、個人に対しては執拗に詳細計画を求めている。
  • 詳細な記述を求めるわりに、シートの欄が狭く書き辛い。
  • 面談等のプロセスが明確化されておらず場当たり的。
  • 「評価」「評価」と「評価」を全面に押し出しており「評価」が目的になりすぎ。しかも、その「評価方法」「評価基準」が存在しない(あるいは公開されない)。

中途半端な導入では「目標による管理」にあるような効果的な自己統制や意欲向上に結びつかず、逆効果になる可能性も高い。

もとよりスタッフは日夜より良いソフトウェアやサービスを開発しようとしているのに、それを萎えさせるようでは論外である。

えーと。

  • 目標設定は「何をするのか」「何を達成するのか」で。期日と成果とメジャーメントを明確に書くようにする(ガイドラインの明示と、それらに沿った記入シート)。当然、押しつけられるのではなく各個人が自ら約束する。
  • (組織上として)上の人が下の人に、まず部門の目標および個人の目標をきちんとさらす。下に書かせて問題点を指摘するのではなく、どのよう書くのかまず示す。
  • プロセスを明確に。
  • 人事考課に使いたいのなら、きちんとした「評価方法」「評価基準」を。評価する側は、公正な評価スキルを会得しておくこと。評価者も評価されるような仕組みであること。

まずは、こんなところ?

スポンサード リンク
[ permalink ]
[ 2月6日全て ]

2006年4月12日 (水)

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

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

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

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

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

メーリングリスト

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

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

「ご検討ください」

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

「ご意見ください」

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

「○○してください」

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

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

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

形式的な不備

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

添付資料が MS Word 形式

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

添付資料が MS Excel 形式

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

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

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

内容がムカつく

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

時候の挨拶つき

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

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

結局のところ

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

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

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

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

[ ビジネスメール ]

[ permalink ]
[ 4月12日全て ]

2006年5月5日 (金)

ビジネスメールガイドライン案

以前メールによる社内コミュニケーションの問題について書いて以来、いろいろと考えてみている。

そんな中、東洋経済新報社の「Think! SPRING 2006 No.17 超ロジカルシンキング」の中に参考になる記事を発見。 照屋華子氏の「ロジカル・ライティング - 論理的に考え、伝えるための3つの鍵を身につける」という記事だ。

すべてのビジネス・コミュニケーションは「伝え手」「受け手」「テーマ」「答え」「期待する反応」という5つの基本要素で成り立っている。-- Think! SPRING 2006 No.17 p.43

おお、ちょうどこういう切り口を探していたところだったんだ。 電子メールによるコミュニケーションも全く同じ枠組みである。 記事の中ではロジカル・シンキングをコミュニケーションで生かすという話題を中心に展開しているが、十分メールの書き方に通じるものがある。

SEの実力を磨く究極仕事術

この記事と、さらにちょっと前に買った「SEの実力を磨く究極仕事術」のメール術の章を参考にガイドライン案のスケルトンを作ってみた。

感情論は今回は置いておいて、情報共有・課題共有・リクエストの明確化・処理促進をポイントに列挙。 それから署名その他、一般的な話もいまのところ省略。

ポイントを列挙しただけなので、他人にもわかる形にはなっていない。

まずは自分自身に適用して、整理していってみることにする。

1. 考える

  • 【伝え手】伝え手は誰? (自分)
  • 【受け手】受け手は誰?
  • 【テーマ】テーマは何? 問いの形で。メールのテーマは1つに絞られているか?
  • 【答え】 テーマに対する答え(テーマに対する説明)は何?
  • 【期待する反応】受け手に期待する反応は何?
    • 誰に、いつまでに、何をどうして欲しい?
  • コミュニケーション手段としてメールは適切?

2. メールを書く

 ○○様へ                     # 受け手

 △△の××(自分)です。       # 伝え手

 テーマ
 ******
 コミュニケーション設定

 ○○の結論                   # 答え (結論)
 ==========
 ...

 (ここまででポイントを言いきる。)

 具体的な内容                 # 答え (詳細)
 ============

 項目1
 -----
 ....

 - リスト項目
 - リスト項目

 項目2
 -----
 ...

 - リスト項目
 - リスト項目
サブジェクトを書く
  • 見ただけでわかるようにする
    • □ 具体的に書く
導入部を書く

コミュニケーション設定を行う。

  • □ 冒頭に宛先【受け手】を明記する。(誰に読んで欲しいのか? 他に誰に送られているのか?)
  • □ 次に発信者【伝え手】を明記する。(From: フィールドに頼らず書く → 印刷・コピー用)
  • □ 【テーマ】を書く。
  • □ (オプション)【テーマ】の経緯・背景を書く。(「なぜこのテーマのメールがくるの?」)
  • □ (オプション)なぜこの【伝え手】からなのかを書く。(←「なぜあなたからリクエストされるの?」)
  • □ 【期待する反応】を明記する。
    • □ 「誰が」「何を」「いつまでに」「どのような品質で」して欲しいのかを書く? (← 「で何をして欲しいの?」)
    • □ 反応のメリットを書く (←「なぜこの反応をとらなければならないの?」)
    • NG 「ご意見があればお願いします」 → ない場合は?
    • NG 「どちらが良いと思いますか?」 → 意見として? 決定として?
    • NG 「ご検討ください」→ 検討した後どうして欲しいのか?
  • □ (オプション)なぜこの【受け手】に読んでもらいたいのかを書く (←「何で自分なの?」)
  • □ 特記事項があれば書く
    • □ 答えの情報源など
答え (結論)

結論を書く。

  • □ 詳細まで読まなくても済むようにする。
    • NG 「以下のように……」 → 要旨を書く
    • NG 「添付ファイルの通り」 → 要旨を書く
答え (詳細)

根拠・資料などを書く。

  • □ 受け手から見て必要十分な情報を書く
    • NG 「添付ファイルの通り」 → 要旨を書く
  • □ 受け手が読みやすいように書く
    • □ リスト化する
全般
  • □ 具体的に
    • NG 「来週までに……」 → 「×月×日までに……」
    • NG 「先日の……」 → 「×月×日の……」
    • NG 「この間の……」 → 「×月×日の……」
    • 説明は肯定形で書く (否定形だと具体的に何なのかわからない)
  • □ 論理的に
    • □ 構造化する
    • □ リスト化する (箇条書き化する)
  • □ 受け手が読みやすいように

3. 送信する

  • □ 送信する前に見直す
    • □ typo チェック
    • □ スペルチェッカ通す

A. メールを受信した時

まず返信する

どれか

  • リクエストを「受ける」 / 返信で処理する (意思決定を返すなど)
  • リクエストを「断わる」
  • 「別の提案をする」
  • 明確化の質問をする

メールでは不適当と思ったらコミュニケーション手段を 直接 / 電話に切り換える。

B. 返信する時

サブジェクト
  • □ テーマが変わったら書き換える
[ permalink ]
[ 5月5日全て ]

2010年2月17日 (水)

Google Apps セットアップ所要時間4時間

昨年から会社内で「Google Apps でカレンダー共有したい」という声があって、計算機管理者として頭にはあったんだけれど「メールがどうなるの?」「今までの Google ドキュメント上のドキュメントはどうなるの?」などがクリアでないので二の足を踏んでいた。

メールアドレスは Google Apps 上に持っていかないことにしよう

今のメールアドレスを Google Apps の Gmail に移行させると

  • 各ユーザの設定を変えてもらう必要がある(昨年11月に社内サーバからレンタルサーバに移行したばかりだというのに)。
  • そのメールアドレスで Google アカウントを作っている(あるいは Google アカウントに関連付けてある)といくつかのサービスでは Google Apps 優先になってしまい、今までのデータが使えなくなってしまう(メールアドレスの関連付けを変えたりする必要がある)。

といった問題が出る。 ということで、Google Apps は今のドメイン (ここでは example.com としておく)に apps サブドメインを作って apps.example.com としてそこで社内向けサービスとして使うことにした。

Google Apps Standard Edition 申し込み

申し込みページから、ドメイン名の指定 (apps.exemple.com)・管理者の入力・管理者アカウントの作成を実行。 これで管理画面に入れるようになる。 そこでドメイン所有権の確認の指示にしたがって 

 googleffffffffxxxxxxxx(確認用の名前).apps IN CNAME google.com.

を example.com の BIND のゾーンファイルに追加。

ヘッダ用のロゴもばっちり設定。

各種 URL の設定

各サービスごとに 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 設定

メールは今まで通りレンタルサーバで運用するので、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 上で作るべしとか。

まずは何人かにモニター利用してもらって「これって便利」探しをしてみよう。

[ permalink ]
[ 2月17日全て ]

2011年9月28日 (水)

今日のさえずり: アカウント名やアイコンが心地よいとそれだけで許せる

2011年09月28日

[ permalink ]
[ 9月28日全て ]

2013年1月30日 (水)

今日のさえずり: 今の会社に入社する時に面接した人・会った人は誰でどんな印象でしたか?

2013年01月30日

  • 08:39 今日は通院してから出社します。
  • 09:30 採血した。
  • 09:43 8040円。許容範囲かな。
  • 10:05 RT @hirata_hironobu: 4歳の息子に「若さって何だ？」と問えば「振り向かないことさ。」と答え、「どんな男になる？」と問えば「名もない花を踏みつけられない男になるのさ。」と答えてくれます。そうです。息子は宇宙刑事ギャバンの主題歌に夢中です。
  • 10:10 着いた。でもせっかくだからそこら辺で仕事してから出社するか。 (@ 渋谷駅 (Shibuya Sta.) w/ 33 others) http://t.co/k3sgCUgF
  • 10:19 60秒コーヒーとアップルパイ。 (@ マクドナルド 渋谷東映プラザ店) http://t.co/b89vu72B
  • 10:22 オサレエンペラー、リーダーの素質があるらしい。
  • 10:34 他人の Enter 打鍵音が強いと心身に良くない。
  • 11:11 @finalfusion さっきのマックで、貧乏ゆすりとコンボでした。
  • 12:11 Thunderbird のテーマを設定したらデスクトップが少し華やかになった。
  • 13:28 “動的言語向けの仮想マシン「Parrot 5.0.0」リリース - SourceForge.JP Magazine : オープンソースの話題満載” http://t.co/fFQ2J4f1
  • 15:24 「オサレエンペラー」って「闇金ウシジマくん」というのに登場するのか。
  • 16:39 やっぱり安定の28℃です。
  • 17:12 「Mobageでは、iOSとAndroidの両プラットフォームのアプリに、同じ基準でレーティングを適用しております。」 / “Mobageアプリレビューガイドライン” http://t.co/f2aotj9j
  • 17:12 「iPhone、iPad、または iPod touch では、機能制限 (『ペアレンタルコントロール』とも呼ばれます) を有効にして、特定の機能へのアクセスを禁止できます。」 / “iPhone, iPad, and iPod ...” http://t.co/n3ecRIlc
  • 17:19 初めて tmux 使ってる。
  • 17:29 tmux、まず prefix key を C-b から何に変えるかで1週間かかりそう。
  • 22:26 ぼちぼち退勤。 (@ 株式会社ミクシィ (mixi, Inc.)) http://t.co/XM1dF6h4
  • 22:48 今の会社に入社する時に面接した人・会った人は誰でどんな印象でしたか? 結構みんなはっきり覚えているよねぇ。
  • 23:06 女性セブンってどんな人が買うのだろう。美容院とか?
[ permalink ]
[ 1月30日全て ]

2013年2月4日 (月)

今日のさえずり: デスクの上に片方土足を置いていたので「これは大物だ!」と思っていた

2013年02月04日

  • 07:38 “お前このサブネットでも同じ事言えんの？ - 知らないけどきっとそう。” http://t.co/w3c4pLf1
  • 09:24 @y_aki 今後は Bootstrap あたりを使って、どのデバイスでも見やすくなるようにはしたいです。サイドバーは他人の Blog 見てる時に無意識に脳内フィルタリングしてるのでいらないかなあと。
  • 09:48 福は内。 (@ 株式会社ミクシィ (mixi, Inc.)) http://t.co/grL7yVGi
  • 10:07 いつもバッグに入っているクレジットカードと折り畳みバッグを今日は忘れた。帰りにスーパー寄る予定があるのに。
  • 10:12 今日は体調不良で2人お休み。昨日豆をまかなかったに違いない。
  • 15:37 いただきもののブランチに add 忘れられているものがあるっぽい。
  • 15:40 「個人の端末で無線 LAN を使えますか?」を「故人の端末で無線 LAN を使えますか?」と書き間違えていた。
  • 19:12 渋谷区2Fのポールンロボ。 / “花粉プロジェクト - ウェザーニュース” http://t.co/0Fx21bLs
  • 19:12 JASGAガイドライン及び運営体制基準を策定。 / “JASGA自主規制の概要” http://t.co/sSSAbllv
  • 19:27 Perl やっててよかったー。 / “Perlの食えない事情 - 演算子編 - アリ” http://t.co/i7pyFIPD
  • 19:27 “そりゃそうだ！ iOS版公式『Tumblr』アプリのレーティングが17歳以上になる | NANOKAMO BLOG” http://t.co/TGRtlycg
  • 20:16 2月1日に入社した人がデスクの上に片方土足を置いていたので「これは大物だ!」と思っていたのだけれど、今日よく見たら靴型のペンケースだった。
  • 20:17 っていうか雪降る前に靴欲しい。
  • 20:42 “『Twitterカード』を設定してサイトへの流入数を「若干」増やそう！1万6742文字に渡る開発者向けドキュメントの日本語訳まとめ。” http://t.co/m1ZjsLQV
  • 21:29 @py0n 誕生日おめでどうございます!
  • 21:37 今日帰りにレジ袋を買わなければならないのか、口惜しい……。
[ permalink ]
[ 2月4日全て ]

2013年6月10日 (月)

【日記】3連休明けのお別れとか、Xperia A の Wi-Fi 設定とか

千葉の東京ディズニーランドいったり、秋葉原の東京ディズニーランド(アキヨド)へ行ったりといろいろ満喫した3連休を終えて月曜日スタート。

で、ガイドラインのドラフトをブラッシュアップしたり、納税したり。

それから、ひとつの決断、おつかれさま的なお別れがあるなど。今回の経験が人生の糧になり中長期的に最善な選択だったと思える日がくると信じてる。

夜は Xperia A の設定2日目。まずは Wi-Fi 設定。spモードまわりで、またここでもパスワード設定が必要になるんだけれど、ほんとにNTTドコモは暗唱番号/パスワードの数を減らせないものなのかねぇ。

接続は問題なく。「エリア連動Wi-Fi」が設定にみあたらなくて機能が無くなっちゃったのかなーと思っていたんだけれど、mixi で「あ、それは設定>電源管理のところにあります」って教えてもらったので、明日設定する。

あとは Facebook のログインと設定。こちらは PC で使っているので、機能というか構成要素というか、そういうのは何となくわかっているのでわりにスムーズに導入できた感じ。通知のオン/オフ設定をどんな塩梅にするかは、使ってみて調整ね。

[ permalink ]
[ 6月10日全て ]

2014年1月24日 (金)

今日のさえずり: 隣の人にナガ10薦めた

2014年01月24日

  • 09:26 RT @orga_chem: “@Naney: “必要なく output parameter 使うのやめましょう” http://bit.ly/KLsREm” こーいう形式の戻り値受け取りに名前ついてたのか。ときどきClosureLibraryでもみる形式。
  • 09:39 前に立っている人のスマートフォンにシガールがぶら下がっている。いいな、結構欲しいぞ。
  • 09:42 ウソ(鷽)もぶら下がってた。
  • 10:00 朝一 Windows Update。 (@ 株式会社ミクシィ (mixi, Inc.)) http://4sq.com/1l2RVYf
  • 11:39 @as_tone あっ、今日からなんですね。そういえば今頃だったかなあと電車の中でぼーっと考えてました。
  • 18:05 隣の人にナガ10薦めた。 SKK も薦めといた。
  • 19:19 “組織における内部不正防止ガイドライン：IPA 独立行政法人 情報処理推進機構” http://bit.ly/1fbeMf6
  • 21:59 <TMPL_INCLUDE EXPR="..." DEFAULT="..."> は「EXPR で指定したファイルが無かったら DEFAULT の方を include する」ではなくて「EXPR が空だったら……」だったので消したファイルを作り直し。
[ permalink ]
[ 1月24日全て ]

2015年3月4日 (水)

今日のさえずり: 「IP アドレス」を「IP」と呼んでいるいるのを耳にする度にムラムラする

naney:16524339080

2015年03月04日

[ permalink ]
[ 3月4日全て ]

About Me

Naney Naney (なにい)です。株式会社ミクシィで SNS 事業の部長をしています。

nDiki は1999年1月に始めたコンピュータ日誌を前身とする Naney の Web 日記(兼パーソナルナレッジベース)です。ちょっとしたノートは nNote にあります。

※内容は個人的見解であり所属組織とは関係ありません。

月別インデックス
Process Time: 0.067766s / load averages: 0.29, 0.38, 0.44
nDiki by WATANABE Yoshimasa (Naney)
Powered by DiKicker