nDiki : 箇条書き

ソフトウェア インタフェース 用字用語 Naney の用字用語 Naney ドキュメンテーションガイドライン 表記 コミュニケーション 書き方 reStructuredText UTF-8 メモ レビュー ASHFORD ビジネス文書の書き方 提案書の書き方 JIS ユースケース図 Word 企画書 目標 仮説思考 ユースケース マニュアル UML ビジネスメール 書評 ビジネス文書 用語集 ガイドライン 現代の経営

■ 現代の経営(上)読了

P.F.ドラッカーの「現代の経営」を読み終えた。

1954年出版ということで冷戦時代背景における論調の内容があったりと多少違和感があったりする部分もあるが、本質の部分はもちろん健在。

内容的には比較的大きな企業の上層クラス向けに向けられた感じがする。 経営書としては当然なのだが企業中心の視点ということで、自分の立場としてはやはりすっきりしない部分がある。

文章もかたい感じ。図もないし、箇条書き化もほとんど無い。

明快で人をより重視しているトム・デマルコの著書の方が自分にあっていると思うのは、やはりソフトウェア屋だからか?

1度読み通したけれど、ドラッカーの言いたい骨子をまだ掴み切れていないようだ。 いつかもう一度ゆっくり読み直す必要があるな。

• 現代の経営

[ 書評 ]

• ソフト契約と見積りの基本がよ～くわかる本 (2005-10-14)
• 開発の現場 Vol.004 「上流脳」をつくろう! (2006-04-14)
• Joel on Software - 必読書 (2008-08-14)
• ビジネスメールガイドライン案 (2006-05-05)
• 仕事のヒント (2005-11-26)

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

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

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

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

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

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

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

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

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

@ 1. 考える

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

@ 2. メールを書く

 ○○様へ                     # 受け手

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

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

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

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

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

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

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

 項目2
 -----
 ...

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

@ サブジェクトを書く

• 見ただけでわかるようにする
  • □ 具体的に書く

@ 導入部を書く

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

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

@ 答え (結論)

結論を書く。

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

@ 答え (詳細)

根拠・資料などを書く。

• □ 受け手から見て必要十分な情報を書く
  • NG 「添付ファイルの通り」 → 要旨を書く
• □ 受け手が読みやすいように書く
  • □ リスト化する

@ 全般

• □ 具体的に
  • NG 「来週までに……」 → 「×月×日までに……」
  • NG 「先日の……」 → 「×月×日の……」
  • NG 「この間の……」 → 「×月×日の……」
  • 説明は肯定形で書く (否定形だと具体的に何なのかわからない)
• □ 論理的に
  • □ 構造化する
  • □ リスト化する (箇条書き化する)
• □ 受け手が読みやすいように
  • □ フォーマットを工夫する (ソフトウェア技術者間なら reStructuredText がお薦め)

@ 3. 送信する

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

@ A. メールを受信した時

@ まず返信する

どれか

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

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

@ B. 返信する時

@ サブジェクト

• □ テーマが変わったら書き換える

• メールによる社内コミュニケーションの問題 (2006-04-12)
• 定型書式で内容を記述していくのに便利な形式は? (2005-11-21)
• ソフトウェア技術者御用達のプロジェクトマネジメントツール TaskJuggler (2007-04-23)
• 「プロジェクトマネジメント」はどうやって勉強すれば良いですか? (2006-11-22)
• ソフトウェアかんばん「見えない化」 (2006-04-10)

■ ほぼ日手帳をやめてミニ6穴見開き1週間ダイアリーに

ほぼ日手帳はいろいろ書いておけて、あとで見返してキュンとなれるので離れがたい。 しかしシステム手帳とあわせて手帳を2つ持ち歩くのも不便なので、ほぼ日手帳には一旦第一線を退いてもらうことにした。

@ ASHFORD 週間ダイアリー

ということで、旬を過ぎた手帳コーナーでダイアリーリフィル探し。

• 時間指定スケジュールは携帯電話に通知できる Google カレンダー中心にするので、時間軸はいらない。
• 重要スケジュールと、その日指定のアクションと、tickler file 項目が書ければ良い。

去年のほぼ日手帳での上記の書きっぷりを見ると、見開き1週間でなんとかおさまりそう。

箇条書きするので各日タテ・横そこそこあったほうがいい。

で結果、ASHFORD のNo.1505-008 週間ダイアリー(セパレイト)見開き1週間をチョイス。罫線がうるさくなくて良い。月曜始まりというのも良い。方眼が理想だがそれは諦めた。

今のところ2カ月先ぐらいまで入れておけば十分そう。

さてこれでうまくまわるかな。

• 2008年夏の GTD 運用ツール (2008-07-23)
• ほぼ日手帳復帰 (2008-07-22)
• GTD Next Actions リスト用ノートをやめる (2007-07-25)
• ダ・ヴィンチ ジャストリフィルサイズ システム手帳で GTD (2006-05-17)
• ほぼ日手帳その他保護・整理用にバッグインバッグを買ってみた (2008-08-24)