書けない悩みは人それぞれ
著者の開米瑞浩氏は、「文書作成能力」を向上させるための企業研修を2003年からされています。ご自身がITエンジニアだったこともあり、IT企業からの研修依頼を多く受けてきましたが、「プログラムは書けるけど、文書は書けない」といったITエンジニアからの悩みを聞くことが多いということでした。
個人で完結できる仕事は別ですが、たいていは他者とのやりとりが発生します。たとえば受託開発であれば、顧客から提示された要求仕様書を読んで理解し、こちらからは提案書や設計仕様書などで仕事内容を先方に伝える必要があります。文書は仕事を円滑に行ううえで必須のコミュニケーション手段です。
では、文書がうまくなるにはどうすれば良いのでしょう？ 「書けない悩みは人それぞれ」と開米氏はこれまでの経験から述べています。仕事内容も多種多様です。そのため何から努力したらいいのか見当をつけるのが難しいのだと思います。
文書のわかりやすさは「書く前」の作業にかかっている
本書では「わかりやすく書く力」を向上させるために、次のような点を解説しています。手っ取り早くうまく書けるようになるための銀の弾丸はありません。しかし、書く力をつけるための努力の仕方には方法があることを本書で知ってください。
- 本書の要旨
- 文書を作成する前に考える、基本となる6つのポイントを押さえる
- 「図解」と「文章」でわかりやすい「文書」になる
- 構造を図解するための典型的な型を知る
- 文書の役割をワークフローから考える
- ITエンジニアに馴染みのある豊富な例文から、自分の仕事に近いもの見つけて学べる
6つのポイントの中でも特に重要なのが「分類してラベルを付ける」ことです。これを行うことで文書の構造が見えてきます。構造がわかれば図解もしやすくなります。文書の構造化、それこそがわかりやすい文書への第一歩です。
ここで本書からワークフローの考え方の一部を紹介しましょう。図をご覧ください。Windows XPのサポート切れに関する例です。エンジニアはXPのサポートが切れることを知っていたはずなのに、経営陣がOSの切り替えにGOサインを出さなかったために結局サポートが切れても使い続けるはめになっている現状があります。エンジニアが経営陣に報告する際、この図のような考え方で、読み手が経営者であることをふまえて文書にすれば理解を得られたかもしれません。詳しく知りたくなったら、本書を手にとってみてください。ワークフローの考え方は、本書で紹介する文書作成のコツのほんの一例です。
図 ビジネスの基本のワークフロー
簡単なことからはじめてみましょう！
かくいうこの文章も、「状況把握」→「方針立案」→「行動提案」というワークフローを念頭に置いて書いてみました。「状況把握」では、ITエンジニアといえども組織内で仕事をする以上文書によるコミュニケーションは必須であり、それに苦慮されている方は少なくないことを述べました。「方針立案」は、わかりやすく書く力の向上に本書がどう役立つか、という説明です。そして「行動提案」は、明示的に書いてはいませんが、本書をご購入ください、ということです。
文章嫌いの方でなくても、本書をお読みいただくと「人に伝える」ためのエッセンスをあらためて確認してもらえると思います。もしこの文書を読んでご興味を持っていただけたなら、担当編集者として望外の幸せです。
