Ⅴ 実務への適用

１．電子メールで伝える

電子メールの特長は、第一に送信者と受信者の同期が不要であること。相手が不在であっても連絡ができることにある。第二は、電子メールを一旦受信すれば、相手とまったく同じ情報をデジタルデータとして共有できることである。ファクスでは回線の状態によっては文字化けが起きることもある。デジタルデータであれば、受信したメールを正確な文字データとして自在に編集することができる。たとえば、特定の件名で検索したり、受信メールを別の人に転送したり、またワープロの文書に張り付けたりすることもできる。

もちろん速報性とか、記録性とか、同時通報などの機能も強力である。忘れてならないのは、個人に対する機密性であろうか。一方、電子メールの欠点として、相手がメールを読んだのか読まないのか、あるいは通信障害で未着なのか、発信者には分からないことがある。だから受け取った方は、詳しい回答は後回しにしても、受信した旨を直ちに返信するのがエチケットの一つ(ネチケット)である。


【名乗ってから結論を】
メール本文は、余計な前書きをやめて、ビジネスライクに直ちに本文に入ろう。｢拝承｣とか｢お世話になっていますとか｣の前書きはいらない。社内文書であれば敬語への配慮も必要最小限でよい。またメールを受け取った方では、誰から来たメールか直ぐにはわからないのが普通である。特に転送が重なっている場合には余計わからない。だからメール本文の先頭でまず名乗るのがネチケットの第一。次に、重点先行の趣旨に従って結論をまず冒頭に置くこと。そして読み下せるように短文で書くこと。

メールの件名では、内容をズバリ要約すること。例えば、｢システム停止の件｣ではなくて、｢停電によるシステム停止の連絡｣とか、相手にアクションを促す言葉を入れること。単に「～について」や「～の件」などのように、本文を読まないと内容が分からない件名は、まどろっこしいものだ。

メール本文は、要件ごとに段落で区切ってまとめること。段落はせいぜい３行程度か。段落の区切りには、スペース行を置いて次の段落を始めるのが良い。先頭の１文字空けよりも、スペース行の方が段落の区切りがはっきりする。視認性･可読性を考えよう。また、視線を動かさず、スクロールしなくても読めるように、20字前後の短い文章で組み立てること。センタリング等の書式に配慮するのも不要である。情報量を増やしてパソコンの画面に見やすく記述することが大切だ。

【箇条書きの活用】
要件を明確にするために箇条書きは効果的である。積極的に活用したい。視覚的に訴える力を増すために、記号を箇条書きに利用するのも良い。例えば、“◆”を個人的には提案したい。


【電子メールの具体例】
＜例＞

【チェック・ポイント】
◆所属部署などを含めて、あて先/発信者名をはっきりと書くこと。
◆結論から書き出すこと。簡潔にスクロールしないで読み下せるように書くこと。
◆箇条書きを活用しよう。１文は短く(40字を超えない)。段落は３文でまとめる。
◆後々の検索を考えて本文に的確なキーワード(固有名詞・顧客名など)を入れておく。
◆機種依存型の記号(丸数字 ① ② ③ 等々)や顔文字 ヾ(＾v＾)k は使わないこと。

【件名の活用】＜件名は最も情報伝達効率が高い＞
◆本文の内容が伝わるように具体的かつ要約的(連絡・報告・依頼・指示)に書くこと。
　 お知らせ →「工程会議延期の連絡」 →「工程会議 2/26に延期」
◆結論や発信者名を入れても良いだろう。 「……のお願い：金沢から」

【注意事項】
・詳しい回答は後にしても、受信した旨をすぐ返信しよう(メール不着では宛先間違いが最多)。
・添付ファイルに全情報を委ねないこと。本文になるべく盛り込むこと。
・ＣＣとＢＣＣを目的によって使い分けること。
・返信時に件名を変えないこと。
・開封要求は不快に感じる人もいるので、特に外部ユーザには注意。
・添付ファイルとしてＭＳのWord/Excel/PowerPoint形式を無条件に採用しないこと。

２．議事録をまとめる

【議事録の役割】
ソフトウエアの特質のひとつは「変化」である。受注プログラムの開発などでは、工程の進捗と共にユーザの要求はどんどん拡大し仕様が変わるのが通例である。開発当初に計画した機能は、業界状況とか他社に対する競合力の強化策などによって変わってくる。このような変化に追随しプログラムを完成させるためには、既定の仕様書だけでは不十分であり、その都度、議事録などで更新･補完することが必要となる。議事録は仕様書より優先するのである。

また、約束ごとを記録するのも議事録の役割である。議事録を書かなかったために、約束違反をユーザから指摘されて大赤字となった事例も散見する。ユーザとの打合せの場では自ら率先して議事録を書く心得を持とう。議事録を書くには、正確な知識――技術的なものだけではなくユーザー環境なども含めて――を持つことが前提条件である。

議事録は、２つの方式に分けられる。①逐次的記録。誰が何と発言して、どう回答したか、など時間の経過に従って記録する方式である。これは臨場感があり、会議の雰囲気が伝わるというメリットがあり、書く手間も少ない。もう一つは②要約的記録。会議の結論、決定事項、宿題等々を項目ごとにまとめて書く方式である。まとめるのには工夫が必要である。いずれにしても、議事録の冒頭で会議の結論がわかるようにすること。全体がＡ４の１ページにまとまればベストである。

パソコンなどを活用し議事録をデジタルデータ化するメリットは、検索性に優れるということ。たとえば、月日とか特定の顧客名で議事録を検索したいときがある。

【チェック･ポイント】
◆決まらなかったことこそ議事録に書くこと。
◆メモを取る代わりに、その場で議事録を書こう。
出し遅れの証文とならないように。
◆年月日の記入は必須。記入書式を統一しておくこと。
◆固有名詞をきちんと正しく書くこと。
　会社名、人名(役職)、プロジェクト名、略号、……
→検索するときに、もっとも有用で使用頻度が高いのは固有名詞である
　｢冨士写真フイルム｣か｢冨士写真フィルム｣か、｢日本コロムビア｣か｢日本コロンビア｣か


【議事録は差分でしかない】
議事録は本来の仕様書の差分である。従って議事録だけでは全体像を把握できない、という欠点がある。適当なタイミングで、機能仕様書を全部印刷して見るなどして全体像を再確認することが欠かせない。


【具体例】

【注意事項】
・Ａ４で１ページに収まればベスト。コンパクトに要領よくまとめよう。
・核心事項は誤りなく記入すること。納期、仕様変更、金額など。
顧客の承認を得ることも必要。
・電子メールで管理する場合は、決定事項を先頭に置くなど定型のレイアウトを工夫すること。
・配布先は、少ないよりも多い方がよい。
・単なる参考資料なのか、あるいは情報連絡なのかを受け取った側が判断できるようにする。
・同一プロジェクトでは、一貫して同一フォーマットの議事録を使うこと。



３．仕様を決める

仕様書は、設計工程で作成するドキュメントである。機能仕様書などに代表される技術文書が該当する。
・機能仕様書の目的は、当該ソフトウェア製品の外部仕様、すなわち機能の定義とその適用範囲などを明確に決めることである。
・機能仕様書の第２の目的はは、外部仕様を実現するにあたり、どのようなシステムまたはプログラム構成を採用するかあるいは、どのような処理方式を採用すべきかを明確にし、それ以降の工程で作成するドキュメントの指針とすることである。
・外部仕様や内部処理仕様を明確に定義するために、積極的に図表を用いること。

【具体例】＜仕様書の書式はプロジェクトごとに詳細が決められている＞

【チェック・ポイント】
◆仕様書の作成/完成に当たっては、レビュー(審査)が必須。図表を活用するなど、レビューしやすい書式とすること。レビューしやすい機能仕様書は、結果的に仕様が整理され、すっきりしたプログラム構造を実現できる。エンドユーザを交えてレビューすること。
◆あらかじめ明確にできない仕様が出てくるかもしれない。このときは、どの仕様を、いつ(期日)確定するかを、ユーザと協議してはっきり文書化しておくこと。放置しないことだ。
◆一旦、仕様が確定した後も、変更があるのは普通である。仕様変更を前提として、変更部分がはっきりと分かるように書式を工夫しよう。
◆仕様書によって工程初期段階でのベクトルが決まる。初期状態のわずかなズレが、工程の終わりには大きな差異となって影響する。