シーン別に解説、依頼文書作成の要点：文章コミュニケーション・リファクタリング！（6）（2/2 ページ）
作業を依頼するときは手順を明確に
今度は、顧客に導入したシステムのソフトウェアやハードウェアの更新あるいは修正を依頼することになったとします。このような作業はシステムなどの操作が必要になります。作業を依頼するときは、単なる依頼書ではなく、指示書や手順書としても使える文書に仕上げなければなりません。実際に作業をする担当者がきちんと作業を完了できるように、明確かつ具体的に作業の手順などの情報を提供しなければなりません。
「○○受発注システム」の「商品情報表示機能」を改良いたしました。
新しいバージョンでは、商品情報の表示速度が高速になり、貴社の受発注担当者のご希望に沿う性能に向上しています。
新しいバージョンを利用するには、当該のプログラムのアップデートが必要です。アップデート用のプログラムを格納したDVDを同梱いたしました。
また、アップデートの手順を以下に示します。
************************************************
■アップデートの手順
：
：
（以下、アップデート手順の詳細を長々と記述）
：
：
************************************************
以上、よろしくお願いいたします。
上記の例は、単なるソフトウェア改良のお知らせとソフトウェアの送付状にすぎません。「ソフトウェアを改良した」という情報と「アップデート用のプログラムを送付した」という情報から、読み手にプログラムをアップデートする必要があかどうかを判断させようとする、いわば以心伝心の文書です。依頼の文書にするには、「プログラムをアップデートしてください」と、読み手がすべきことを具体的に明示しなければなりません。
また、具体的な作業の手順などの詳細な情報は、（数行で済む場合を除いて）別紙として添付すべきでしょう。長々と作業手順が記述しても読みにくいだけです。実際に作業する人のことを考えても、別紙にする方がよいのです。実際に作業を担当するのは、依頼文書を受け取った人と決まっているわけではありません。業務の担当者やシステム管理担当者などになることが多いのではないでしょうか。そう考えると、具体的な手順書は、手順書として独立している方が使いやすくなります。
さらに、実際に作業を担当する人のことを考えて、質問や確認などの問い合わせ先を明確にしておくことも重要です。以下に、良い作業依頼書の例を挙げます。
「○○受発注システム」の「商品情報表示機能」のアップデートをお願いいたします。
「○○受発注システム」をより使いやすくするために、「商品情報表示機能」を改良いたしました。新しいバージョンにアップデートしていただくと、商品情報の表示速度が高速になります。貴社の受発注担当者のご希望に沿う性能に向上していますので、早急に当該のプログラムのアップデートをお願いいたします。
アップデート用のプログラムは同梱のDVDに格納してあります。アップデートの方法と手順は、別紙の指示書に記述してあります。
同梱のDVDを使って、指示書の手順に従ってアップデートしていただくようにお願いいたします。
ご不明な点、確認したい点などの問い合わせは下記までお願いいたします。
担当者： ◎◎◎◎
電話： △△△△
メール： □□□□
言い訳に終始しないよう気を付けて
次は、顧客にシステムの仕様を検討、確認してもらうことになったとします。要件定義や設計仕様、テスト仕様として確定した仕様を検討、確認してもらうことはよくあるでしょう。開発途中で変更になった仕様を検討、確認してもらうこともあります。
仕様の検討、確認を依頼するとき、エンジニアはつい仕様の内容（仕様そのもの）に意識が集中してしまい（仕様をきちんと記述すればよいだろうという意識）、依頼の文書は乱雑なものになりがちです。
「顧客情報変更機能」のユーザーインターフェイスを変更いたしました。変更点は、……、……、……の3点です。
ただし、100％貴社にご満足いただける画面イメージではないと思われます。これは、表示できる文字量と画面の大きさの関係であり、開発側としてもこれ以上の改良は難しいと考えています。その点はご了解いただきたいと思います。
別紙に、顧客情報変更機能画面の画面図と操作手順を添付しましたので、宜しくお願いいたします。
顧客に仕様の検討、確認を依頼するときに、その仕様が顧客の要望を満たしていないことはよくあることです。エンジニアは、仕様が要望を100％満たしていない点を意識しすぎて、つい言い訳がましくなってしまいがちです。
上記の例も、顧客の要求に添えなかったことを意識しすぎたものになっています。「とにかく最初に言い訳を」という意識で記述したため、依頼の文書になっていないのです。まず、依頼の内容、つまり読み手に何をしてほしいのかを記述してありません。この点だけ見ても、依頼の文書としては不完全なものです。
仕様変更の検討、確認の依頼であれば、変更する理由を記述しなければなりませんが、この記述もありません。書き手は、「打ち合わせの結果に基づいた変更であることは顧客もよく分かっているから書かなくても大丈夫だろう」と思い込んで記述してしまったのでしょう。思い込みで書いてしまった文書は、読み手にとっては不親切なものです。意図が伝わらなくなってしまう可能性も高くなります。
さらに、いつまでに検討、確認してほしいのか、期限を明確になっていません。期限の直前になって慌てて催促してしまうと、顧客に不快感を与えることになりかねません。そして、変更点を文章中に列挙していますが、これも感心しません。非常に読みにくくなります。ここは箇条書きにすべきでしょう（これは依頼文書に限りません）。
以上の注意点を踏まえて、仕様変更の検討、確認の依頼文書を作ると以下のようになります。
ユーザーインターフェイスの変更内容の検討、確認をお願いいたします。
前回の打ち合わせでの決定を受けて、「顧客情報変更機能」のユーザーインターフェイスを変更いたしました。
変更点は以下の3点です。
1.
2.
3.
貴社から出された下記2点の要求は今回の変更に反映されています。
1.
2.
ただし、表示できる文字の量、画面の大きさという制約のために、顧客情報変更機能画面の構成は、打ち合わせで決めたイメージと多少異なります。
別紙に顧客情報変更機能画面の画面図と操作手順を添付いたしました。これらを参考にしてユーザーインターフェイスがこれでよいかどうかご検討、ご確認をお願いいたします。
なお、ご検討、ご確認の結果は○○月△△日までにお知らせください。
宜しくお願いいたします。
今回は、具体的なシーンを想定しながら依頼の文書を書くときのポイントを解説しました。次回は、お願い、おわび、催促の文書を書くときに気を付けるべき点を解説します。
著者プロフィール
谷口 功 （たにぐち いさお）
フリーランスのライター、翻訳家。企業にて、ファクシミリ通信網を使ったデータ通信システム、人工知能、日本語処理関連のソフトウェア開発、マニュアルの執筆などに関わる。退職後、コンピュータ、情報処理、通信関連の書籍の執筆、翻訳、各種マニュアルや各種教材の執筆に携わる。また、通信、コンピュータ関連のメールマガジンの記事、各種雑誌においてインターネット、パソコン関連の記事やコラムなども執筆。コンピュータや通信に関連する漫画の原作を執筆することもある。
主な著作は、『SEのための 図解の技術、文章の技術』（技術評論社）、『ソフト契約と見積りの基本がよ?くわかる本』『よくわかる最新 通信の基本と仕組み』（秀和システム）、『図解 通信プロトコルのことがわかる本』『入門ビジュアルテクノロジー 通信プロトコルのしくみ』（日本実業出版社）、『図解 ネットワークセキュリティ』『マスタリングTCP/IP IPsec編』[共著]（オーム社）など。
Copyright © ITmedia, Inc. All Rights Reserved.
ITmediaはアイティメディア株式会社の登録商標です。