‘編集’ タグのついている投稿

【わかりやすいマニュアルの作り方】第120回 読んでもらうには見掛けも重要 その3

2011年2月1日 火曜日

もうすぐ立春です。今日をすぎれば寒気団もすこし遠ざかり、過ごしやすくなってくるかもしれません。

さて、今回は引き続いて見掛けと読みやすさについての話をします。

■見出しを設定しよう

以前、この連載でも、見出しの重要性について書いたことがあります。
しかしその時は、主に見出しの文書における構造的な役割について書いていました。
見出しのツリー構造は、取扱説明書全体の構造をひいては見渡しやすさを決定しますから、内容的には間違いありませんし、いまでも内容には自信がありますが、今回は違う話です。

■1つの文章は見出しの下に3~4行まで

見出しの後には、本文が続きます。本文の内容は、この見出しのように3~4行ぐらいまでとします。1行の長さは、版型によって異なりますが15~35文字程度。これが3~4行で1ブロックを構成します。

これは、ぱっと見たときに、あまり視線を移動させずに文字を読み取ることができる範囲です。
たとえば横に60文字もあったり、縦に20行も続いていたら、そのブロックの内容を一回で把握することは困難になります。
こうした場合は、ブロックを分割して、新しい見出しをつけることを考えます。

小説の場合は、もっと長い場合もよくあります。そうした方がイメージを伝えられるからです。
しかし取扱説明書は、実用品です。
正しい内容を、誤解されないように伝える必要があります。

内容が正しくても、読んだ人に誤解されてしまって、正しく伝わっていない。これでは取扱説明書の意味がありません。

■見出しと本文に差をつける

以上のようにして見出しと本文を書いていきます。
そして出来上がった文書の中で、見出しをはっきりと目立つようにすることが必要です。
現在のワープロでは、テンプレートを使用して見出しを段落単位で設定すると、適切な書式を設定してくれるものもあります。こういったものをうまく活用すべきです。
しかし会社の書式がある場合など、そういったテンプレートを使えない場合は、自分で見出しの書式を設定しなければいけません。

ここは、デザインについて詳しく語る場ではありません。ですから、詳しいことは割愛しますが、見出しと本文が、紛らわしいような書式設定は論外だということを覚えておいてください。

見出しは見出しとして目立ってこそ、意味があるのです。

マニュアル(取扱説明書)制作の専門家 取説屋:石井ライティング事務所


【わかりやすいマニュアルの作り方】第74回 テクニカルライターとは その12

2010年1月26日 火曜日

なんだか、今週は随分暖かくなってきました。
10度どころではなく、15度を越えるのでポカポカです。

今回は少しまとめに入ろうと思います。

■テクニカルライターとは-再考-

テクニカルライターは、境界領域の技術者です。

そのため、マニュアルで説明を加えるよりも、「本体のここにシールで説明を張った方が良い」とか、「このパーツの部分の色を変えればいいんじゃないか」とか考えたりします。

しかし。

こういった意見は、小さい企業で社長に直接話ができる場合以外はまず取り入れられることはありません。

というか正しく言えば、その意見が開発者までまず届きません。

できれば社内で気が付くのが1番なのですが、ベストばかりを求めても得られるとは限りません。何とかして、私たちのユーザーインターフェイスに関する知識や経験を生かしたいと考えています。

もちろんそれが商売につながると良いということもありますが、エンジニアとデザイナーで製品をデザインするときに、インターフェースの専門家としての意見をを述べる機会があればなあ、思うことがよくあります。

今週で、テクニカルライターについては終了しようと思います。
途中から、熱くなってどんどん話題がそれて行ったのが理由です。
ちょっとまとまらなくなってきてしまいました。

さて。
来週からは、「取扱説明書のコスト」で行こうかと考えています。


【わかりやすいマニュアルの作り方】第73回 テクニカルライターとは その11

2010年1月21日 木曜日

今回はマクラなしです。

■外部の人間の強み-テクニカルライターのできること-

前回は、エンジニアさんから良いところを、ユーザーさんから悪いところを教えてもらって初めて良いマニュアルができるという話を書きました。
そのためにはコミュニケーションが必須であると書きました。

では、テクニカルライターはそういうことができるのか?という点ですが、この辺が外部の人間の強みになります。

エンジニアさんから良いことを聞くのは、そう難しいことではありません。
普通にインタビューの時間をとれば話してくれます。

ではユーザサポートの方への取材はどうでしょうか?

こちらは企業の秘密の情報が含まれていますので、必ずしもオープンに話してくれるとはかぎりません。
問題は人選です。あまり、上の人、例えばサポート部門の部長などですと、現場から遠く、実態を意外と把握していない場合があります。
かといって、担当者レベルのミクロの話ばかり聞いても効果はありません。チームリーダーとか、そういったあたりの人と話をするのが1番です。

…といった知識を持っていて「機密には触れないで、業務として話をしてください」と依頼するわけです。
このあたりが、社内ではどうしてもやりにくい点です。

チームを作って対応する

では、社内ではできないかというと、むろんそんなことはありません。

「チーム」を作れば良いのです。マニュアルの評価チームというか、作成に協力するためのチームを。

まぁ、最初は飲み会などの非公式な会でもよいでしょう。まず小さなチームを作ることから始めればきっと改善されるはずです。
製品もそうですが、マニュアルもひとりではできないのです。

続きます。


【わかりやすいマニュアルの作り方】第72回 テクニカルライターとは その10

2010年1月12日 火曜日

あけましておめでとうございます。
本日から、ブログの更新を再開いたします。
急な寒波が来て、冷え込んでおりますが、今年は、景気ぐらいは暖かくなって欲しいものだと心から願います。

■コミニュケーションとフィードバック

さて。

コミニュケーションとフィードバックの続きです。

「一番ひんぱんにあるクレームは何ですか?」
もっともきかなければならない質問です。
でも、なかなか聞きにくいとは思いませんか?

前回はここで終わりました。

言うまでもありませんが、この質問の相手は、営業の人です。エンジニアさんはこの答えを知りません。もしも知っていたら、当然そこを改良しているでしょうし。

この回答を最もよく知っているのは、営業、特にユーザーサポートのセクションの人です。場合によってはユーザーサポートの人はFAQ回答用のアンチョコ-虎の巻を持っている場合すらあります。

もしも「虎の巻」があるなら頼み込んででも拝借させてもらい、できるだけというよりも全部取扱説明書に反映させます。それも目立つところに

どんなに優れた機能があっても、使い方がユーザーに伝えられていなければ使えません。安全な使い方が伝えられていなければ、事故が起こるかもしれません。

製品を作った後に、その使い方、良いところ、安全な使い方などを「使う人に伝える」ということが大切なのです。

そのために、使う人と作る人の間のコミュニケーションが大切です。

ただメーカーの場合は、なかなか、ユーザーさんとのコミニュケーションを直接には取りにくいので、次善策として、営業やサポートの人とコミュニケーションを密にとっておく必要があります。

  • エンジニアさんからは「ここがよい点だ」を伝えてほしいと思います。
  • ユーザーサポートさんからは「ここが困る点だ」を教えてほしいと思います。

この2つがそろったうえで、操作説明をしっかり行って、初めてマニュアルとして役に立つものができると考えています。

続きます。


【わかりやすいマニュアルの作り方】第71回 テクニカルライターとは その09

2009年12月22日 火曜日

テクニカルライティングと安全に関する記事の続きです。

テクニカルライターの仕事の根幹部分ですね。

前回、広報と安全の注意喚起と技術文書について書きました。

■ユーザーは予想外のことをする

もうひとつの問題は、エンジニアさんは完璧なものを作ったつもりでも、かならずしも完璧とは言えないということです。
なぜなら、ユーザーは予想外のことをします。必ず予想外のことをします。

それは、正しい使い方を考えて製作するエンジニアさんの予想を超えています。

では、どうすればよいか。
実は予想外と言っても「正しくない」使い方はともかくとして、まったく他の人が試したこともない使い方を考え出せる人はまれです。

つまり、まったくの新ジャンルの製品ならともかくとして、製品を売ってきた営業部にはいままでの「ユーザーの行動」がデータベースとして保管されているのです。
これをフィードバックすればよいのです。

もちろん、フィードバックを次の開発に生かせるほど風通しが良い会社であれば問題ありません。
しかし、往々にして…というか、かなりの割合で実際にはそうなっていません。

内部の人には聞きにくいこともある

だからこそ。
ここで、外部のスタッフによるインタビューか効果的なのです。

内部の人にはやはり聞きにくいこともあります。

「一番ひんぱんにあるクレームは何ですか?」

もっともきかなければならない質問です。

でも、なかなか聞きにくいとは思いませんか?

続きます。


【わかりやすいマニュアルの作り方】第70回 テクニカルライターとは その08

2009年12月15日 火曜日

前回の続きです。
技術文書と安全について、ですね。
さて。

■技術文書と安全について

すごく簡単な話、エンジニアー技術者が安全についての正しい注意書きを作らないとどうなるかを考えてみます。これはまた、現状に対する考察でもあります。

まず、エンジニアが安全に関する資料を作らないと、前回書いたように広報担当者もパンフやチラシを作れません。
そうすると、製品として出荷するときに作成されるマニュアルのチェックの時に(気が利いた担当者がいれば)「安全に関する注意はこれで良い?」と確認し、はじめて安全に使うための注意が記載されます。

しかし、これでは製品に添付されるだけで、見る人は多くありません。本来、購入前に確認すべき事項があっても、それは購入するまで箱の中なのです。

電化製品や通信、コンピューター関連機器ならば、これでも許されるかもしれません。
僕のように、動作保証のないジャンクを買ってきて喜ぶような変人もいることですし。

しかし、介護機器、幼児向け製品などではそんな事は全く許されません。
危険や注意については購入前にあらかじめ確認できることが必要なのです。
なぜなら、使用者には判断ができない場合があり、また見過ごすと危険に直結するからです。

だからこそ、わかりやすい技術文書を作成し、早めに広報などに回し、パンフやチラシ、パッケージなどあちこちで使い回してもらうことが大切なのです。

面倒なようですが、これによって製品事故の発生を一件でも未然に防ぐことができれば、充分おつりがきます。
また、「安全に注意しているメーカー」との評価につながり、ブランドの向上にもつながります。
良い技術文書作成はユーザーの安全に、ひいては寺社への評価につながるのです。

まぁ、ウチとしては「だから取説屋:石井ライティング事務所にお任せください」と続けたいところですが…

続きます。


【わかりやすいマニュアルの作り方】第69回 テクニカルライターとは その07

2009年12月8日 火曜日

大きめの書棚を購入、これで仕事場の環境がすっきりして良くなりました。
今までは家庭用の書棚を使っていたのですが、今度は事務機器です。安定度と書棚の深さが大違いです。
実にすばらしい。

■テクニカルライティングと文書作成の教育

さて、前回は教育関連のことなどを含めて書きました。
日本におけるテクニカルライターは、どこでも育成されておらず、企業の努力によって「なんとかしてきた」という状態なのです。

これが、どういう結果を招いているか。
まず、ドキュメンテーション能力の水準が技術力に比べて著しく低いということになります。
それは「良いものを作ってもちっとも伝わらない」ということになります。これは広報のうまさにもよりますが、広報のネタもとであるドキュメントが製品の良さを伝え切れていないと、広報はエンジニアに取材するといった相当の努力をしないと良い広報ができないということになってしまっています。

まぁここでちょっと宣伝をさせてもらうと、僕の得意なのはこのあたりなのです。製品を触ってみて良いところや勘所をつかむ、これができるのがプロのテクニカルライターです。

だからこそ、書くことが苦手なエンジニアさんを苦しいドキュメント作成から解放して、プロに任せましょう、というのがうちの売り文句なのです。

閑話休題。
正直な話、エンジニアさんに文書が得意になるまで文章の練習しろとか、文章を書くのが得意な人に、技術の根本的なことを理解しろというのは無理な話です。

残念ながら僕にも解決策はありません。

それこそ自分のところを使ってください、あるいは他のテクニカルライターを外注として使ってくださいという提案しかできません。

また先ほどは、広報に関して書きましたが、さらに重要なこととして「安全」に関する告知や商品の売り方に関わる問題もあります。

続きます。


【わかりやすいマニュアルの作り方】 第68回 テクニカルライターとは その06

2009年12月1日 火曜日

携帯が壊れて、すごく簡単な代替機になってしまいました。

スケジュール管理や連絡先その他のデータがたくさん入っていたので、なくなってしまうと、かなり困るのことがよくわかりました。

■説明する能力について

さて、今回は説明する能力についてです。

大変残念ながら、現在日本の学校では物事を説明する技術の訓練は行っていません。

  • 文科系では文学というか芸術的な内容を主として扱い、詩や小説の鑑賞を学びます。
  • 理系では、そもそも文章の書き方を学ぶ機会はほとんどありません。

実際、自分の知り合いにもテクニカルライターが何人かいますが、その仕事を始めてからOJTで描き方を身につけたという人がほとんどです。多分…全員だと思うのですが、もしかしたらそうでない人がいるかもしれませんので。

またそういったことを教える学校もありません。わずかにTC協会の講習会がそれだといえます。
しかし、これはテクニカルライター業界の中でのテクニカルライティングの講習会であり、一般教養として物事を説明するための文章の書き方を学ぶ。ということではありません。

テクニカルライターは、前回記載したようにまず、技術的素養を身につれなければなりません。

そしてそのうえで、物事を説明する技術を身につける必要があり、これらを教えているところはほとんどありません。

その結果が、日本の数多く見られるイマイチな取扱説明書なのです。

続きます。


【わかりやすいマニュアルの作り方】 第67回 テクニカルライターとは その05

2009年11月25日 水曜日

20度を越えたりまた急に寒くなったりと、何だかよく分からない気候が続いています。
なんだかマクラが毎回、天気のことばかりですが、無難なということもありますから。

さて。

テクニカルライターの技術についての続きです。
前回は印刷に関する技術と知識、伝える技術として作図の技術をあげました。
しかし少し急ぎすぎたようです。

■技術を理解する能力

最初に必要なのは、技術を理解する能力です。

マニュアルを作る人間は、特にその技術についてエキスパートである必要はありません。むしろエキスパートでない場合の方が望ましいともいえます。

テクニカルライターは素人と玄人の間の橋渡しをします。そのため素人の感覚がまったく分からなくなってしまうほど精通してしまうのも考えものなのです。

■使う人を想像する能力

技術の理解と同時ににもう一つ必要なのは、使い手を理解することです。

使い手として想定するのは、あなたのおじいちゃんとおばあちゃんあたりが良いでしょう。その製品に触ったことはなくても、現代のテクノロジーには慣れている程度の人です。明治以前のテクノロジーを持っていない人を想定するのはいくらなんでもやり過ぎです。

伝えるもの、伝える対象の両方に対する理解が必要になります。

そしてそれらを、理解した上で技術をもって伝えないと伝わらないのです。
ではその伝える技術は、どうやって磨いたらよいのでしょうか。

続きます。


【わかりやすいマニュアルの作り方】 第66回 テクニカルライターとは その04

2009年11月17日 火曜日

急に寒くなってきました。

今年はUSBあったか手袋でも導入しようかと迷うほど手先が寒くなることがあります。

さて。

今回はテクニカルライターに必要な「技術」について書こうと思います。

繰り返しになりますが最も必要な「能力」はコミュニケーション力です。

取材する技術も当然必要です。また、仕様書を読む技術も必要です。

それとライティングの技術。このあたりまでは誰でも想像がつくと思います。

ですから、ここまではマクラです。ここから先が本命ですが、多分誰も教えてくれません。

■テクニカルライターとしてやっていくために必要な技術

まず、基礎知識として必要なのは印刷業務に関する知識、および電子文書(PDFやHTML)に関する知識が必要です。

これらの知識がないと、どのような原稿を書けばよいかがわかりません。

また次の作業行うことがどういう手順で作業を行うかを知っていないと、次の人にとって作業のしやすい原稿が書けません。

僕は自分でDTP作業をしながら原稿を書く方法は推奨しません。できれば分業したいと考えています。

しかし、DTP工程で何をするとかぐらいは知っていないと、作業を早くすることはできません。

さてもう1つ。

テクニカルライターには図解をする能力または技術が必要です。

「あると良い」ではありません。「必要」だと考えています。

別にきれいな絵がかける必要はありません。

しかし、「ここを見せたい」「こう説明したい」といったことを後の工程であるDTPの人に伝えるだけの説明図を作るのは必要だと思っています。

自分の場合は、「漫研」で昔とった杵柄の技術を使って、ささっと説明図を描いてしまいますが、こういった練習をしておいてよかったなぁと思うことは1度や2度ではありません。

続きます。