取説屋のテクニカルライター兼代表ブログ なんでもマニュアル(取扱説明書)作成します

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

マニュアル制作の専門家:取説屋・石井ライティング事務所のテクニカルライター兼代表の石井宏治のブログです。
Jul.2010
S M T W T F S
        1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30 31
ブログシステムを移行します
この取説屋ブログですが、いろいろと機能不足とか感じるため、思い切ってWordPressに移行しました。
新しいアドレスは以下の通りです。

ブログトップページ
http://torisetuya.com/t_blog/

【わかりやすいマニュアルの作り方】シリーズ目次

ログも移行してありますので、引き続き新しいブログをよろしくお願いいたします。
本ブログの更新は、今回で最後となります。
お知らせ : comments (0) : trackback (x)
【わかりやすいマニュアルの作り方】第76回 テクニカルライティングの価格 その02
さて、コストの話の続きです。

価格の妥当性は、品質や納期と見合うかどうかによります。

前回、「寝ていた方がマシ」程度の金額で受注する人たちについて、
>こんな人たちに依頼した原稿の品質や納期は
>あてにならないのは言うまでもありません。
と断言しました。
乱暴と思われるかもしれません。
また、該当する人は「そんなことは無い」と思うかもしれません。

ですが。
まず、納期です。
プロは納期を守ります。守れない人はプロではありません。
なぜなら「納期を守れない人」は仕事を発注する先として、まったく信用がおけないからです。
信用がなければ受注はありません。
そして、プロは自分の信用を看板として仕事をしているのです。「在宅ワークだから」「サイドビジネスだから」という理由で安く受注している人とは背負っている重さがハナからちがいます。
そういう人たちにもきちんと納期を守る責任感のある人も多いです。ただし、比率として、プロの方が納期を守る人が多いです。

私は20代前半、編集者をしていたときに、入稿日に発熱して出社できなかったことがあります。そのときは上司がフォローしてくださったので事なきを得ましたが、後日出社したときに言われました。
「たとえ倒れても入稿日には来なさい。倒れるのは入稿を確認してから。」
私は、その1回の失敗以来、この言葉を守っています。
納期に対する責任はそういうことです。
これが価格に対する対価だと思っています。

続きます。
この件は、取説−マニュアル(操作説明書)とは必ずしも関連しませんね。
次回は品質についてを書こうと思います。
次はきちんとからむと思います。
【わかりやすいマニュアルの作り方】第75回 テクニカルライティングの価格 その01
前回のブログでは、もういちど「マニュアルのカタチ」について書こうかと予告しましたが、考えが変わりました。
まぁ、あまり考えていないのですが。

さて。
今回からは、マニュアルのコストというある意味いちばんヤバげな話をしようと思います。
いや、別にもっと原稿料をよこせとかいった話ではなく。もちろん、たくさんいただけるにこしたことはりませんが。
取扱説明書…操作説明書の原稿の適正な料金って何だ、ということです。

今回はマクラだけです。

ぶっちゃけて言えば、労働に対する対価ですから、その成果物にどれだけの価値を見いだすかという話ですが。
ネットで探すと、とんでもなく低い価格のものがあります。400字詰め原稿1枚200円以下、下手すると100円とか。日本語なんかだれでも書けるじゃないかということで値段の叩き合いをやった結果です。
こういう価格を提示されると、プロは逃げます。「寝ていた方がマシな値段」の仕事だからです。
どういうことかというと、自分が1時間に書ける枚数はだいたい計算できるわけです。
そうすると、1時間にどれだけ稼げるかがわかるわけですね。
1枚200円として……まぁ5枚でしょうか。時給1000円。100円だとその半分の500円。
コンビニやファーストフードでアルバイトするほうがナンボかマシです。
しかも、自分は今で培ってきた専門性を提供した上でこの値段なら。

「寝ていた方がマシ」というのは、こんなところから来ているのです。
でも、こんな値段で応じる人がいるのもどうも事実らしいです。
「在宅ワークだから」「サイドビジネスだから」という理由のようですが。

でも。
こんな人たちに依頼した原稿の品質や納期はあてにならないのは言うまでもありません。
続きます。
Adobe CS4 導入しました
タイトルの通り、導入いたしました。
Windows版ですし、フォントも特に加えていませんが、一通りのことはできるようになりました。
これまではIllustrator Ver.9で開けるファイルに制限があったりしましたが、以降はそういったことでご迷惑をおかけすることが無くなるかと思います。

これからも石井ライティング事務所をよろしくお願いいたします。
経営 : comments (0) : trackback (x)
今週は更新が遅れます
業務多忙のため。
すみません。
ネタも練り直す方向です。
- : comments (0) : trackback (x)
【わかりやすいマニュアルの作り方】第74回 テクニカルライターとは その012
なんだか、今週は随分暖かくなってきました。
10度どころではなく、15度を越えるのでポカポカです。

今回は少しまとめに入ろうと思います。
テクニカルライターは、境界領域の技術者です。
そのため、マニュアルだ説明を加えるよりも、「本体のここにシールで説明を張った方が良い」とか、「このパーツの部分の色を変えればいいんじゃないか」とか考えたりします。

しかし。
こういった意見は、小さい企業で社長に直接話ができる場合以外はまず取り入れられることはありません。
というか正しく言えば、その意見が開発者までまず届きません。
できれば社内で気が付くのが1番なのですが、ベストばかりを求めても得られるとは限りません。何とかして、私たちのユーザーインターフェイスに関する知識や経験を生かしたいと考えています。
はもちろんそれが商売につながると良いということもありますが、エンジニアとデザイナーで製品をデザインするときに、インターフェースの専門家としての意見をを述べる機会があればなあ、思うことがよくあります。

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

さて。
来週からは、説明書の形再びで行こうかと考えています。
【わかりやすいマニュアルの作り方】第73回 テクニカルライターとは その011
前回は、エンジニアさんから良いところを、ユーザーさんから悪いところを教えてもらって初めて良いマニュアルができるという話を書きました。
そのためにはコミュニケーションが必須であると書きました。

では、テクニカルライターはそういうことができるのか?という点ですが、この辺が外部の人間の強みになります。
エンジニアさんから良いことを聞くのは、そう難しいことではありません。
普通にインタビューの時間をとれば話してくれます。
ではユーザサポートの方への取材はどうでしょうか。
こちらは企業の秘密の情報が含まれていますので、必ずしもオープンに話してくれるとはかぎりません。
問題は人選です。あまり、上の人、例えばサポート部長などですと、実態をかえって把握していない場合があります。。かといって、担当者レベルのミクロの話ばかり聞いても効果はありません。チームリーダーとか、そういったあたりの人と話をするのが1番です。
…といった知識を持っていて「機密には触れないで、業務として話をしてください」と依頼するわけです。
このあたりが、社内ではどうしてもやりにくい点です。
では、社内ではできないかというと。
「チーム」を作れば良いのです。マニュアルの評価チームというか、作成に協力するためのチームを。
まぁ、最初は飲み会などの非公式な会でもよいでしょう。まず小さなチームを作ることから始めればきっと改善されるはずです。
製品もそうですが、マニュアルもひとりではできないのです。
【わかりやすいマニュアルの作り方】第72回 テクニカルライターとは その010
あけましておめでとうございます。
本日から、ブログの更新を再開いたします。
急な寒波が来て、冷え込んでおりますが、今年は、景気ぐらいは暖かくなって欲しいものだと心から願います。

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

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

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

この回答を最もよく知っているのは、営業、特にユーザーサポートのセクションの人です。場合によってはユーザーサポートの人はFAQ回答用のアンチョコというか虎の巻を持っている場合すらあります。
もしも「虎の巻」があるなら頼み込んででも拝借させてもらい、できるだけというより全部取扱説明書に反映させます。それも目立つところに。
どんなに優れた機能があっても、使い方がユーザーに伝えられていなければ使えません。安全な使い方が伝えられていなければ、事故が起こるかもしれません。
製品を作った後に、その使い方、良いところ、安全な使い方などを「使う人に伝える」ということが大切なのです。

そのために、使う人と作る人の間のコミュニケーションが大切です。
ただメーカーの場合は、なかなか、ユーザーさんとのコミニュケーションを直接には取りにくいので、次善策として、営業やサポートの人とコミュニケーションを密にとっておく必要があります。
エンジニアさんからは「ここがよい点だ」を伝えてほしいと思います。そしてユーザーさんからは「個々が困る点だ」を教えてほしいと思います。
この2つがそろったうえで、操作説明をしっかり行って、初めてマニュアルとして役に立つものができると考えています。
明けましておめでとうございます
本年も石井ライティング事務所をよろしくお願いいたします。

とりあえず、新年のご挨拶まで。
お知らせ : comments (0) : trackback (x)
本年はありがとうございました
本年はたくさんの方においでいただき、ありがとうございました。
本年の更新はこれで終了いたします。
また、1/5の定期更新はお休みさせていただきます。

ありがとうございました。

それでは皆様、良いお年を。
お知らせ : comments (0) : trackback (x)
【わかりやすいマニュアルの作り方】第11回 なぜ「書き方」ではなく「作り方」なのか?
Toni Johnston>7/22
【わかりやすいマニュアルの作り方】 第48回 マニュアル(取扱説明書)作成・制作の効率化 その01
Sumerki>5/25
ブログの移行準備中
戯作>12/16
【わかりやすいマニュアルの作り方】第69回 テクニカルライターとは その07
戯作>12/08
【わかりやすいマニュアルの作り方】 第65回 テクニカルライターとは その03
戯作または無責任なテクニカルライター>11/11
横 300 pixel 縦 192 pixelです。(ブログの初期設定で設定してください)
横 306 pixelを超えると、表示がくずれる場合があります。