nDiki : 書き方

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. 返信する時

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

2006年9月11日 (月)

社内 Perl 勉強会 最終回 (第16回)

リャマ本を使用した社内 Perl 勉強会の16回目を開催。 今日は8人全員。

今日は「初めてのPerl 第3版」第17章「上級テクニック」が範囲。 17章では、「Perl らしい」機能 (Perl 流 eval、grep、 map、スライス)が盛沢山。

今回の反省点

robust なプログラムを書くには Perl では eval 必須の機能なので押さえておきたいところ。 grep、map は何だかんだいって自分が練習問題の解答で使ってしまっているので、他の人もある程度見なれているはず。

練習問題の解答としてはスライスは今回は使用せず。

逆にスカラーコンテキストとリストコンテキストについては、まだ理解が不完全な部分があるようなので解説をしておいた。

最終回を終えて

Perl については

Perl の理解が進んだ (「正規表現」が何か少しわかった、使い方がわかった、知識が増えた)

という一方

Perl の気持ち悪さが理解できた。

という意見があった。

プログラミング言語勉強会としては

他の人の書き方を見ることが参考になった。実際に書くことで覚えた。

等、定期的に練習問題をやってくるというスタイルに対する評価が得られた。

4月21日から始めて5カ月弱。勉強会でスキルアップをはかっていこうという雰囲気ができてきているのはいい傾向だと思う。

今後もテーマを選んで継続していきたい。

次のテーマをより実用重視のものにするか、基礎固めのものにするのかは悩みどころである。

[ 9月11日全て ]

2006年11月3日 (金)

DiKickern 年日記機能を追加

久しぶりに DiKicker に機能追加。

n 年日記機能

ハイパー日記システムで書いていた旧 Web 日記である Naney's Diary の記事を nDiki に移すにあたり、n 年日記にあたる表示がなくて困るので実装した。

最近はぱったり「過去の今ごろ」を書かなくなったけれど、たまには n 年日記を見て振り返るのも悪くない。

n 年日記へのリンクをどこに置くか迷ったが、とりあえず1日の一番最後に置いてみた。 tDiary テーマとの兼ね合いもあって思案中。

diary-article:

記事書き用には

 [[diary-article:記事ID]]

という記法を追加。 今までは他の記事へのリンクは URL で指定するしかなかったのだけれど、これだと可搬性がないしスマートでなかったので、あわせて実装してみた。

過去記事も全部この書き方に直したいけれど、それなりに数があるので面倒くさい。 もちろん今のままでも問題はないんだけれど。

過去の(膨大|それなり)のデータをいつまでも利用できるようにシステムを維持することの重要性(と手間)を再確認。

[ 11月3日全て ]

2007年4月23日 (月)

ソフトウェア技術者御用達のプロジェクトマネジメントツール TaskJuggler

ときたまやってくるソフトウェア開発計画作成、今までは GanttProject を使っていたのだけれども、挙動が安定しないのと印刷機能が貧弱なのとで満足できていなかった。

ということで今回は新しいツールを使ってみることにした。チョイスしたのは TaskJuggler

Linux 上で動くツールである。 GanttProjectWindows でも Linux でも使えるのが利点だったのだが、ここ数年の中でプロジェクトファイルを共有することも無かったので、まあ Linux だけでしか動かなくてもいいかなと。

テキスト形式でのプロジェクト記述

TaskJuggler が特徴的なのは、プロジェクトをテキストファイルで記述するところである。 一般的なプロジェクトマネジメントツールは GUI 上でガントチャートを直接編集したりできるのだが、TaskJuggler はそんな軟弱者向けの機能は用意されていない。

あくまでテキストで書く。プロジェクト・リソース・タスク・レポートをテキストファイルに書く。 でコンパイルするとガントチャート等のレポートが生成される。実績もテキストで入力する。

書き方に問題があればコンパイルエラーになるし、定義したタスクの依存関係等でプロジェクト期間からはみ出てしまうような時もコンパイル時に怒られる。 渋い。

TaskJugglerUI

とっつきにくく見えるが、慣れると以外とそんなに難しくない。 effort と length と duration の違いが分かればあとは楽勝。

TaskJugglerUI という GUI ソフトウェアでは、補完機能の優れたエディタが内蔵されているしサイドバーのリストからタスク等を選んで、対応する行に移動することもできる。

さながら Eclipse でコードを書いているような感じ。

下手にガントチャート上でタスクをドラッグアンドドロップして、日にちを動かすよりも思った通りに定義していけるので良い。

印刷

ガントチャートについては、それなりに見やすいフォーマットの印刷物を生成してくれる。 印刷からプリンタとして「Print to File (PDF)」を選択すれば日本語も含めて問題なく PDF 化できるので、でき上がったものも配付しやすい(ここら辺は KDE 側の範疇か)。

GanttProject では PDF 出力がイマイチで結局、画像ファイルにエクスポートしてプリントアウト/配付していたのでこれは便利。

面倒な点といえば

面倒な点があるとしたら、タスクに ID をつけてその ID で依存関係などを指定してあげなければいけない点か。 識別子を考えるのが面倒なのと、タスクの数が増えてきた時にその指定したい ID を探す(思い出す)のが面倒である。

あと、識別子の名前変更リファクタリング機能があればいいな (一括置換だと関係ないところまで置換してしまう可能性がある)。

ということで

ソフトウェアエンジニアには使いやすいツールだと思う。

マクロ機能やインクルード機能などもあるのでもう少し使いこんでみたい。

[ 4月23日全て ]

2008年3月30日 (日)

Google ドキュメントソフトウェアかんばん

ソフトウェア開発見える化としてソフトウェアかんばんの良さは実感しているのだが、分散開発ではさすがに「情報カードで」というわけにいかず実行しにくい。

今回の分散開発プロジェクトに向けていろいろ考えた結果、Google ドキュメントのスプレッドシートを使ってソフトウェアかんばんを遠隔共有してみようと思う。

他の検討候補

TRICHORD を使ってみたいのだけれど予算の問題が。 検討したのは以下。

  • TRICHORD - 本命。使ってみたいが予算が。
  • Firefox + Internote (light-board.com ライク) - カード感は十分。しかし共有に難。
  • 影舞用に新しくソフトウェアかんばんテンプレートを作る - 影舞を使い慣れているという点では○。ただストリーカードとタスクカードをどう扱うかが課題。
  • Wiki - 以前やって失敗した。
  • XPlanner - インストールと学習が手間。それと開発止まっている?
  • その他 Agile Project Management Tool - カードメタファで良さそうなのはあるが、予算が。
  • Google ドキュメント プレゼンテーション - 矩形をカードにしようとしたが文字は別オブジェクトで書かなければならず×。文字の背景を設定するというのも試したが見栄え・操作性が良くなかった。

スプレッドシートだとカードっぽさが薄れるが、共有・同時編集という点では安心して使えるし最大行数的にも OK。 一番運用しやすそうだということでこれでいくことにした。

スプレッドシートの作成

以下のようにスプレッドシートを作る。

  • 1シート目はインフォメーションシートにする。ソフトウェア概説・かんばんルール・通信事項などを書くのに使う。
  • 2シート名以降をかんばんにする。複数ソフトウェアならシートを分けてもよいかもしれない。
  • かんばんシートE列の背景を「条件をに応じて変更」で本日より前だと赤くなるように設定する。
  • かんばんシートF・G・H列の背景を「条件に応じて変更」で @ と書くと背景がそれぞれ赤・黄・青くなるようにする。

カードの書き方

内容
Aカード番号をつける。
ストーリーカードは S番号。タスクカードは S番号T番号とする。
Bカード作成日を書く。
Cストーリーカードの時にストーリー名と作成者名をかく。
Dタスクカードの時にタスク名と作者名をかく。
E期日をかく。
FTODO の時に @ とかく。DOING に移行した時は @ を消す。
GDOING の時に @ と開始日、担当者の名前を書く。DONE に移行した時は @ を消す。
HDONE の時に @ と終了日、担当者の名前を書く。
I備考欄

TODO、DOING、DONE 列は1列にまとめることもできるが、ちょっとは「かんばん」っぽくなるかと思って分けることにした。

運用

  • カード番号は重複しないように。
  • カードの状態にあわせて @ を書き換えていく。
  • DOING から TODO に移る時には、開始日と担当者名を消さないで残しておく。
  • 列単位でソートしないこと。
  • タスクの粒度はできるだけ揃える(例えば半日~1日にする)。

課題

  • カードが増えた時に使いにくくならないか? 終わったカードを別シートに分けるルールなどを考える。
  • タイムボックス等にあわせて並べ替える時の手間。
  • カード番号が手動。
  • 集計について考慮していない。
[ 3月30日全て ]

2012年3月17日 (土)

今日のさえずり: スーパーエンジニア検索したらスーパーエンプラに辿りついた

2012年03月17日

  • 09:34 ネオマグ届いた。週明けオフィスでペタペタする。25mm の注文したんだけど、あら、家で使ってるやつより一回り大きかった。
  • 13:37 iPad 出せ出せ攻撃受けてる。
  • 14:29 そろそろ iPad 2 の iOS バージョンあげるか。Windows 起動する。
  • 14:44 iPad 2 アップデートしたいんだけれど iTunesアップデートが始まってる。
  • 14:53 Apple Software Update が Windows再起動せよと……。
  • 15:10 iOS 5.1 ダウンロード待てない(待たせられない)ので今、更新やめ。
  • 15:51 Facebook 上で旧友と再会。幼稚園の頃からのつながりなので最古級。
  • 15:54 ビニールプールに一緒に入った間柄です。
  • 16:53 ネロウーノのインク補充った。
  • 18:42 風呂入っている間にダウンロードしといて iOS 5.1 へのアップデート完了。
  • 21:14CS」圧倒的向上マニュアル注文。 http://t.co/Img23w88
  • 21:33 K-9 Mail 4.112 にアップデート。そろそろ違う MUA に浮気したい気もある。
  • 21:48 RT @kazu_yamamoto: Maybe モナドとか IO モナドとかいうの止めませんか? 例外を返す Maybe の基礎は、直和型です。入出力があるのに純粋なのは、命令書というアイディアです。モナドとはなんの関係もありません。
  • 21:48 RT @kazu_yamamoto: Maybe モナドと言いたい人は、Maybe ファンクタとか、Maybe アプリカティブとか、平等に言ってあげて下さいね。そう言いたくないなら、なぜモナドと言ってしまうのか、自問自答すべきです。
  • 21:48 RT @kazu_yamamoto: モナドということで、相手を思考停止にしたいんだろうな。ただ、自分も思考停止していることに気づいていない。
  • 21:54 スーパーエンジニアっていう響きちょっといいなと思って検索したらスーパーエンプラに辿りついた。
  • 22:41 RT @kazu_yamamoto: 分かっている人が、モナドの便利さを念頭におきながらモナドというのは全然問題ないですよ。書き方が悪かった気がしますが、僕はそうでない場合を問題にしています。
  • 22:41 RT @kazu_yamamoto: ああ、分かってきた。僕がモナドと言う場合は Monad という型クラスのことであって、圏論のモナドではありません。圏論は知らないし。
  • 22:43 開発グループのバリューについてしっかり考えようと思ったら、MVV とか出てきた。
  • 24:40 持っていたゲーム&ウオッチはバーミン(VERMIN)。
[ 3月17日全て ]

2012年5月23日 (水)

[ 5月23日全て ]

2013年3月2日 (土)

【日記】春なので新しい手帳買ったし書類も書いた

naney:8520644496 新しい手帳が届いたり。この手帳があれば育て方調べるために毎回 iPad 使わなくても済むのですごい有用。

で、ケーキパーティーして、ルービックキューブの LBL 方式黙々と練習してミニマムなのだいたいマスターして、夜はちらし寿司パーティー。

明日に出しにいくつもりで、夜は懸案だった確定申告書類作成。メインの申告書は過去と同様 Web で作成するとして、追加で必要な書類は PDF ファイルをダウンロードして記入。PC で書き込もうとしたら保護されている PDF ファイルで書き込めなくて、しょうがないので iPad 上で GoodNotes でチマチマ書き込む(保護何それ? な感じで書き込める)。各項目の書き方Web で慎重に調べつつ埋めていって「できた! 次は申告書。」って Web で入力しはじめたら、さっきの書類の作成ウィザードが途中にはさまっていた……(そして最終的にそちらを含む PDF ファイルができあがる)。悪魔やー。先に作った書類で計算された数値を申告書に書くのだから、順番的に申告書作成は後で着手するでしょう普通(実はどこかに説明が書かれていたとかそういうトラップがあるかどうかは調べていない)。

[ 3月2日全て ]

2013年3月5日 (火)

Perl で "+{" は見かけるし使うけど、"{;" は見かけないし使ったことない

Perl で "{" はブロックの始まりと、無名ハッシュへのリファレンスであることの始まりが曖昧な文脈があって、後者であることを示すために "+{" という書き方がある。

このことが話題になったので、あらためて perlref を読んでみたら "{;" という書き方を発見。こちらはブロックであることを明示する時に使う。

以下 Perl 5.14.2 の prelref より抜粋。結果も 5.14.2 で確認。

 sub hashem {        { @_ } }   # silently wrong
 sub hashem {       +{ @_ } }   # ok
 sub hashem { return { @_ } }   # ok

上からリスト、 ハッシュリファレンス、ハッシュリファレンスを返す。

 sub showem {        { @_ } }   # ambiguous (currently ok, but may change)
 sub showem {       {; @_ } }   # ok
 sub showem { { return @_ } }   # ok

全てリストを返す。

[ 3月5日全て ]

2013年7月26日 (金)

今日のさえずり: 「PDF 形式」って書き方ムムムってなる

2013年07月26日

[ 7月26日全て ]

About Me

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

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

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

月別インデックス
Process Time: 0.130144s / load averages: 0.25, 0.42, 0.55
nDiki by WATANABE Yoshimasa (Naney)
Powered by DiKicker