‘効率化’ タグのついている投稿

【わかりやすいマニュアルの作り方】第205回 取扱説明書の立場は?

2013年9月4日 水曜日

取扱説明書は、商品についてるものだと思っている人がほとんどです。

実際のところ、事実上そうなんですけれども、商品についている取扱説明書は取扱説明書としてレベルに達していない物なんかも非常に多いというのが実は現実です。

メーカーさんとしては取扱説明書にコストをかけても、ただコストがかかるだけと思っている場合がほとんどのようです。
でも、それは間違いだという事を説明していかないと、「取扱説明書を作る」なんていうことを商売として売り込んでことができないのだなと最近痛感しています。

取扱説明書の立場はいくつかあります。
●1つめは、お客様が初めて商品を扱うときに必要な文書です。
●2つ目は、技術文書としての最下流に位置する文書です。
●3つ目は、広報・ユーザーサポート・広告の資料として使える文書です。

今までの取扱説明書は1つ目と2つ目の立場でしか説明されてきませんでした。
この2つだけでは、まあ確かにコストをかけても、たしかにお金がかかる以外の効果がなさそうに見えます。

しかし、今は昔と違って印刷メディアだけの時代ではなくなっています。作成した取扱説明書は、サイトを使ったりして公開することもできるようになっているのです。

そして、つい最近、取扱説明書を改善すると具体的な善い事も起こる、という話をある場所で伺ったのです。
詳しく書くことはできませんが…通販会社の商品の取り扱い説明書を改善したら、オペレーターにかかってくるその商品に関する質問が激減した、はっきり言えばほぼゼロになったというお話を伺いました。

これってすごいことじゃありませんか?
オペレーターが楽になるという事は、同時に売った後の商品の評判も良くなっているということです。そして、よい取扱説明書であれば問い合わせを受けたオペレーターさんのほうも回答するのが、楽になるのです。
取扱説明書ツールとして使えば、営業にも使うことができるということです。地味に使いやすいかどうかを説明するというためには、取扱説明書をサイトに公開しておくといった方法も使えます。

本来、サイトに取扱説明書を公開するということは、ユーザーサポートのためというのが目的でした。
しかし実際にはそれ以外に買う前に取扱説明書を見ておこう、買うための判断の材料としようといった方法でも使われるのです…というかこの方法は実際にうちの妻がやっていました。

長くなってしまったので次回に続きます。


【わかりやすいマニュアルの作り方】第144回 データナンバリングとバックアップ

2011年9月13日 火曜日

 

今回はデータのバックアップと二重化についての話をします。
弊社では、というよりも自分の仕事のスタイルとして、バックアップを必ず残すということは、ポリシーというよりも基本的な仕事スタイルとしています。

■バックアップについて

バックアップを取るのは、ハードウェアやOSのトラブルで読めなくなることを警戒してですが、実はデータを失うときはむしろそういったトラブルよりも人為的なミスでデータを消す…もっとはっきり言えばデータを空にして元データを上書きしてしまうことです。
システム的なトラブルには大体の場合は予兆があります。システムが、滑らかに動作しなくなったり、今まで見たことのないようなエラーが表示されるようになったり、あるいはハードウエア的に変な音がする、といったことも含まれます。
ですからこういったことに気がつけばその時点でバックアップをもう一度取るといった対策をすれば、ある程度までは損害を防ぐことができます。
もちろん、ある日突然起動しなくなる。といったことはありますかせ油断は禁物ですが。しかし、それよりも恐ろしいのは、ファイルを開いた状態でうっかり「すべてを選択」して、EnterとかSpzceキーを押して、Ctrl-Sを押してセーブしてそのまま終了してしまうことなのです。
なぜ、終了してしまうまでを含めているかというと、終了さえしていなければまだCtrl-Zで操作の取り消しをしていけばデータの復帰が出来る可能性があるからなのです…
もちろん、その結果は数バイトのサイズのファイルが残るだけです。
手の施しようもない悲劇です。

■データナンバリングについて

弊社では、数週間から一カ月、場合によっては何カ月にもわたって同じファイルを書き直して原稿を作成していく場合があります。
まあ、一週間に一度は、ハードディスク全体のバックアップを取っているので、前記のようなトラブルが起こったとしても、最悪先週のデータは残っているということにはなりますが、仕事をする上では致命的と言って良いレベルの大惨事でしょう。
しかし残念なことに、この悲劇を完全に防ぐことはできません。
そのため、長く同じファイルを使い続けているということは、日数が伸びるにつれ統計的に内容を失う確率が高くなっていくわけです。
そして、納期が厳しい最終日近くに一週間前のバックアップに戻されたら……泣くに泣けません。納期が近くなった場合には、多くの場合、メールでファイル送ったりして、結構バックアップがとれている場合もあります、しかしそんな偶然に頼るわけにはいきません。
そこで、筆者は毎日同じファイルを使う場合は、当日の朝、そのファイルのコピーをエクスプローラーで作成して、「ファイル名に」その日の日付をつけるようにしています。
当然ながらファイルを新規作成するときも、作成日をファイル名に含ませています。

例:
file20110912を使っている場合

コピーすると↓のファイルができる。
“file20110912のコピー”

ファイル名を変更する。
“file20110913″ ←ファイルの操作をした日付

そして、実際の作業はこのファイルを開いて行います。
こうすることにより、たとえ何らかのミスが発生してファイルの内容が失われるトラブルが発生したとしても、「昨日作成したファイルまでは残っている」ということになるからです。
ただし、ファイルがたまっていくことになりますから、適当なタイミングで整理をする必要はあります。
もちろん一日分の作業が失われるのはとても痛いことですが、それでも一週間分の作業が失われることに比べると断然ましです。

■もう一つのメリット

さて。

実は、このように履歴を取ってデータを残しておくことは、バックアップの安全性、という視点だけではなく、他にもいくつかのメリットがあります。
一つめは、やはり安全性です。
弊社のような仕事では、一つのファイルを元にして似たような内容のファイルを作ることがよくあります。
こうした時に、最新のファイルをもとに新しいデータを作ると、「ついうっかり」最新のファイルをテンプレートとしてしまうという事故が起こります。
しかし、履歴がとってあれば、2~3日前のデータを使えば「そんなに内容に違いはない」ですから、安全にほぼ最新データからテンプレートを作成できます。
ちなみに、最初の段落で書いた「内容の全消し」というのはこの作業で起こったことでした。
話がそれました。
このような形の履歴を取っておくことのメリットですが「変更依頼に対応しやすい」というメリットもあります。
取扱説明書制作の仕事では、ある程度までできた時点でクライアントにチェックを依頼します。デザイナーさんなんかも、同じような仕事ですね。
そしてクライアント参加の指示や意見に従って最新版から調整を行います。
これで、一方向に進んでいけばことは簡単なのですが、ときどき「前の方がよかった、前のみたいに直してくれ」という意見が出てくる場合があります。
こうした場合、履歴のデータがとってあると、とても助かるのです。
もちろん新しく作ることはやぶさかではありませんが、それでも納期がきついときには、データがあると助かることは変わりありません。

ということで、同じファイルを更新し続ける場合、このように日付をつけた新しいデータを前に作ることは、大変お勧めです。

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


【わかりやすいマニュアルの作り方】第139回 テンプレートを使う

2011年7月19日 火曜日

今年はまた去年並に熱くなりそうです。おまけに節電ときますから、今年はどうしたものやら正直悩みます。
いくらなんでも、身体をこわしてしまっては意味がありませんから。

ちなみに、次回の更新はお休みします。早めの夏休みを取るためです。
申し訳ありません。

■基本的な定型化

さて、今回は作業の定型化について書きます。
取扱説明書という業務においては、実は意外なほどの割合が定型化できるものだということを書こうと思います。
また、逆に定型化しないでいると、ミスの発生を呼ぶ可能性が高くなる場合もあります。
取扱説明書は、対象となる会社によって一部ターンがのパターンがことなるとはいえ、お客様に説明するための文書であり、消費者基本法に裏付けられたものです。
ということは、製造/販売の責任主体である会社については必ず掲載しなければなりませんし、安全のための注意を欠かすこともできません。
当然、製品の仕様であったり、家庭用/業務用の区別、製品寿命といった、場合によっては落としたり見過ごしたりしがちな内容は、「この内容を書き換える:未定」として定型化しておいたほうが見落としやミスの発生が防げるというものです。

■上のレベルでの定型化

とはいえ、取扱説明書で書くことが決まっているとは限りません。
家庭用品であれば取扱方法とお手入れの方法、場合によっては破棄の方法を記載すればことはすみますが、現在のIT製品などでは、それだけではまったく不十分な場合がすくなくありません。
しかし、それでも基本的なパターンが適用できるという点は変わりありません。
たとえば、PC関連製品であれば、ほとんどの場合はデバイスドイバやユーテリティのインストールが必要ですし、スマートフォンであればアプリのダウンロードと登録が必要な場合が多いわけです。こういったことは、似たジャンルの製品を取り扱ったことがあるかどうかによってきますが、経験によって「こういった内容を書かなければならない」とわかってくるものです。
しかし、それがライター個人としての自分の中だけでわかっているだけでは、チェック機能が働きません。そのために、既存のPC関連のものをもとに書き直したりして、テンプレートとして使用するのですが、それだけでは、十分とはいえないのです。
どうして十分と言えないかというと「なにかが書いてある」からです。そうすると、なんとなくできているように見えてしまいます。
特に忙しいときや、疲れているとき(だいたいこの2つは同時に発生します)には、「それでよし」としてしまう恐れがあります。もちろん、それではいけないのです。
だから、新しいジャンルの製品の取扱説明書が終わった後には、ひとつず、そのジャンルのテンプレートを作ることが望ましいのです。
わからないところについては「未定」「不明」「資料待ち」と明記して。
こうすれば、書き落としや、ミスの発生の確率を下げることができるのです。

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


【わかりやすいマニュアルの作り方】 第55回 マニュアル(取扱説明書)作成・制作の効率化 その08

2009年8月26日 水曜日

前回は以下のように書きました。

チェックの不備によって発生した手戻り、遅延、予算オーバーなどが「レビュー担当者がレビュー結果に責任を持たなかったがために発生した。」ということがあると参加者全員に理解してもらう必要があります。

もちろんマニュアル制作者が対応をすべき点も多くありますが、このあたりはかなり力関係がものをいう世界です。
開発技術者よりも営業の人など、遅れると困る人を仲間につけて、必要性を理解してもらうのがよいでしょう。

開発が役割を理解し分担する。ごく当たり前の話です。
しかしこれを実現するのはなかなか容易ではありません。

◆共通化モジュールの罠

手戻りなどがない場合でも、非常に複雑なソフトウェアであったり、類似した画面がいくつも出てきてかつ機能的にも似ている、さらに予算がないといった状況で、似たような機能だから共通化したページを作ってしまうということがあります。

これをプログラムの開発としてみるとどうでしょうか。

そうです。一見似たような機能を共通モジュールとして、あらゆる機能を盛り込んだてんこ盛りのサブモジュールを作ることと同じです。

結果はどうなるか。

デバッグ不可能。

どこがどうなってるのかわからない。

普通の場合こうならないように、いくつかの共通部分はマクロ化したり、共通ライブラリを使ったりしますが、別々に部品を作ります。

マニュアルの場合でも同じことをしなければなりません。
うかつな共通化は、後で手直しができないという大変な問題を引き起こす可能性が高いです。
さて、今回で効率化の話はいったんここまでとします。

次回からはマニュアルの形についてやろうと思っています。


【わかりやすいマニュアルの作り方】 第54回 マニュアル(取扱説明書)作成・制作の効率化 その07

2009年8月18日 火曜日

お盆休みのためか、道路の車や町の人がずいぶん少なくなっていました。
ただ、今年は例年に比べるとずいぶんと涼しいように感じます。
もっとも、去年までの暑さが異常だったのだとも思いますが。

さて。

◆マニュアルのレビューとソフトウェアのレビュー

前回の続きです。
「マニュアルのレビューはソフトウェアのテストと同じ」
こう考えるべきというところのまででした。

そして「テスト仕様書」に相当するものが必要であり、レビューをする人は全員それを知っておく必要があると書きました。

しかし、それだけではまだ十分ではありません。

仕様書があっても、それを読む人の責任範囲が正しく規定されている必要があります。

最初のレビューの仕様書には「1.主な機能がすべて盛り込まれている」と書かれているとし(本当はこんな曖昧なものでは役に立たないのは言うまでもありません)、とりあえず最初のレビューはこれで通ったとします。

しかし第2回目のレビューの時に「主な機能のひとつが入っていないじゃないか」というクレームが来たとします。普通であれば、マニュアル制作では担当者が怒られてそれで終わりです。

しかしそれではマニュアルの制作工程はいつまでたっても改善されません。

レビューに参加する人が責任感をもって参加してもらわないと、意味がないのです。
仕様自体が変わって、主な機能が追加されたのならば仕方がありません。こうした場合には開発セクションから情報が追加され、マニュアルの2稿で対応といった形になります。

しかしそうではなく、仕様が変わらず、初稿では「問題なし」として通していたチェックを後から覆すのであれば、それはマニュアル制作部門のみの責任ではなく、チェックをした部門にも同等の責任があるということを明確化する必要があります。

こういったレビューの失敗による手戻りの発生、スケジュールの遅延、予算のオーバーなどは「レビューした人がレビューの結果に責任を持たなかったがために発生した。」ということとがあると参加者全員に理解してもらう必要があります。

続きます。


【わかりやすいマニュアルの作り方】 第53回 マニュアル(取扱説明書)作成・制作の効率化 その06

2009年8月11日 火曜日

キーボードを更新しました。
ライターにとって、キーボードは商売道具その1です。
いままでの安いメンブレンキーボードから、メカニカルキーボードに。
入力したかどうかが、感覚でわかる。すばらしい。
個人の生産性は道具でも変わりますね。

と、マクラはこのへんまでとして。

レビュー(テスト)の続きです。

◆マニュアルのレビュー(テスト)について

では、このあたりを改善するのにはどうしたらよいでしょうか。
ここもソフトウェアの例にならって考えてみます。

ソフトウェアの場合、テストは何の目的もなく行われるということはありません。

「テスト仕様書」というものが作られます。
これは、文字通りテストの仕様書です。どのようなテストを行う、何の目的で行うといったことが記載されています。
ちなみにこのテスト仕様書の出来が悪いと、テストがうまくいかず、最後まで問題が残ります。

ではマニュアルはどうでしょうか。
マニュアルでは「テスト仕様書」そのものが存在しません。少なくとも私は見たことがありません。
たぶん問題の根源はここだと思います。

確実なテストは、確実に問題を減らします。
テスト仕様書、とまではいかないまでも、マニュアルのレビューの目的と指針くらいはレビュー前に配布すべきでしょう。
マニュアルのレビューをやったことがない人に、何の教育もせずに、出せるのは無理なのです。もちろん、営業などでパンフやチラシの経験を豊富に積んだ人や、仕様書をたくさん書いたプログラマなら、教育なしにできるかもしれません。でもそれは例外です。
「マニュアルのレビューはソフトウェアのテストと同じ」
こう考えると、改善点が見えてくるのではないでしょうか。

続きます


【わかりやすいマニュアルの作り方】 第52回 マニュアル(取扱説明書)作成・制作の効率化 その05

2009年8月5日 水曜日

第51回です。

私はたいがいの場合は機嫌がよくて気のいい人間だと見えるように努力しているのですが、必ずしもそれができるわけではありません。まあ、人は怒ることもたまにはあるということです。

なんのことだかちっともわかりませんね。

◆効率化の気もはレビューにあり!

さて。

>次に行うことは「レビュー」(技術的にな見方では「テスト」)です。

実は効率化はここが肝です。
「レビュー」に参加する人に、「レビュー」の意義をはっきり理解してもらわなければいけません。

  1. 初稿・再稿では全然内容のチェックをせず、最終的にDTP作業が終わったあとに、全体の構成変更を言う人がいます。
  2. 誤字脱字を発見すると、いちいち鬼の首を取ったかのごとく喜んでいい募ってくる人もいます。

正直に言うと、こういった人たちがマニュアルの生産性を下げているのです。
プログラムのレビューに置き換えてみるとすぐにわかると思います。

初稿・再稿あたりは、概要設計から詳細設計に入るあたりに相当します。
DTP作業は、実際のコーディングに当たると考えてください。

コーディングがかなり進んだところで、概念レベルの仕様変更を言い出されると、何が起こるか。

「今までの作業結果は全部捨てる」ですね。当然スケジュールを大幅に遅れます。ですが、納品の日は決まっているため、大幅な無理が生じます。
当然ながら、無理な作業を行っているため、品質はそれに伴って低下します。

つまり、初稿・再稿のチェックは「概要設計から詳細設計に入るあたり」のレビューと同じだということを理解してチェックを行ない、後の段階ではフレームの変更を必要とするような修正がないようにチェックするのがチェックする人の役目なのです。
この部分を理解して作業をする必要があります。

2)については、言うまでもありません。
要するにバグ取りです。バグはあるものです。

そんなことでいちいちかさにかかって威張り散らされてもまったく価値はありません。

むしろ作業者のモチベーションをさげるぐらいのことです。
こういったことは事務的にさっと朱を入れて戻すのがスマートなことは言うまでもありません。

続きます。


【わかりやすいマニュアルの作り方】 第51回 マニュアル(取扱説明書)作成・制作の効率化 その04

2009年7月28日 火曜日

第51回…前回の続きです。

今回はマクラなしですぐに始めます。
取扱説明書を作成するのに希望する人材は、以下のような人であると書きました。

>「コミニュケーション能力が高い人」、エンジニアや業務担当の話をよく聞くことができる人です。
実は、ほとんどの業務でこういった能力が必要なのですが…まぁ、それは横に置くとして。

◆話を聞けるとはどういうこと?

「話を聞ける」というのはどういうことでしょうか。
この場合は、ある程度限定されています。「ターゲットとなる商品・サービス・業務について基本的な理解を持っている」ということが必要です。
できれば、お客様に近い部署、ユーザーサポートや営業などを経験していて、その商品・サービスを「お客様がどのようにして使うか」を理解していることが、より望ましいです。
取扱説明書・マニュアルは技術者の使った「製品」をユーザーの手に渡る「商品」への橋渡しのひとつです(その他の橋渡しとしてはパッケージ・広告などがありますね)。

だからどちらか片方だけの見方で、ものを見るだけでは「技術者からの言いっ放し」や「マーケティング的見地からだけ書かれていて技術的な内容が全然足りない」といった問題が発生するのです。

ではそういった問題を避けるにはどうしたらよいでしょう。
そこでコミニュケーションの能力が必要になってくるのです。
次に行うことは「レビュー」(技術的にな見方では「テスト」)です。

続きます。


【わかりやすいマニュアルの作り方】 第50回 マニュアル(取扱説明書)作成・制作の効率化 その03

2009年7月22日 水曜日

めでたい。

何がめでたいといって、このブログの連載が、ついに50回に達したことです。
とりあえず、最初の目標としては1年間だいたい54回を目指していた。だが50回というのはなんとなく区切りのような気がするし気持ちが良いものです。だいたい目標まで、あとたったの4回である。やる気も出ようというものではないですか。
さて。

「マニュアル担当者の選任と業務の担当者のコミニュケーション」の続きです。

◆どういう人にやらせればよい?

前回はマニュアル制作を本業のひとつとして位置づけ、きちんとスケジュールに組み入れて、制作するということを書きました。
そして何より、「手が空いてそうな人に適当にやらせる」というのがいけないとも書きました。

ではどういう人にやらせるのがよいのでしょうか。

ベストの組み合わせは、製品のプロデューサー役と、書くのが得意な人の2人1組です。
片方が製品の仕様をしっかりと理解し、もう片方がそれをしっかりと文章にする、こんなに良い組み合わせば、考えられません。

ですが、そんなにたくさんの人手を割くわけにも行かないのも事実ですし、だいたい製品のプロデューサー役は納期直前には最も忙しい人です。だからこそ「手の空いてそうな人」が担当になってしまうのですが。

次善策としてはどうでしょう。
ここで出てくるのが「コミニュケーション能力が高い人」、エンジニアや業務担当の話をよく聞くことができる人です。

続きます。


【わかりやすいマニュアルの作り方】 第49回 マニュアル(取扱説明書)作成・制作の効率化 その02

2009年7月14日 火曜日

関東で梅雨明け宣言が出ました。
私は、移動のかなりの部分にバイクを利用していますので、お天気が良くなると嬉しいのです。もちろん、洗濯物もよく乾きますし。
さて、マクラはこのくらいにして。

■マニュアル担当者の選任と業務の担当者のコミニュケーション

予告通り、「マニュアル担当者の選任と業務の担当者のコミニュケーション」です。

やってはいけないこと

さて、まずは。
いちばんやってしいけない例を書きます。

  • 手が空いてそうな新人エンジニアに書かせる。
  • 手が空いてそうな営業・総務セクションの人(多くの場合女性です)に書かせる。

絶対ダメです。

うまく行くわけがありません。

多大なコスト(この場合は人件費)がかかるわりに、ろくなものができません。
もちろん、世の中には例外があり、突然担当者が知らなかったような才能を発揮してうまくいく場合も考えられますが、レアケースです。

どうしてうまくいかないのでしょうか。

わざとそう書いたのですが、「手が空いてそうな」人にやらせるという発想が間違っています。
新人エンジニアでしたら、マニュアルよりもきちんとした概要仕様書から、機能仕様、テスト仕様がきっちり作れるようになるのが先です。
これができるようになっていれば、マニュアルもその応用できちんとできます。もっとも、その頃には優秀なエンジニアとなっていて、手が空いていると言うことは滅多にないでしょうが。

営業・総務セクションの人でも、きちんと文書管理と制作が出来れば…以下同文。

◆片手間ではできません!

あたりまえですが、マニュアル制作は片手間仕事ではできないということです。
完全にその人をマニュアル制作担当のみにするのは無理な場合もあるでしょうが、業務がある場合は、本業の1つとしてしっかりと開発またはその業務のスケジュールに組み入れないと、社内マニュアルは行き詰まるのです。

続きます。