「取説屋:石井ライティング事務所」の代表兼テクニカルライターのブログ 本家サイト http://torisetuya.com

【わかりやすいマニュアルの作り方】第167回編集長の話

前回に続いて、編集の話を書きます。
前回は趣味で作成した取扱説明書の話ですが、今回はもうちょっとまじめです。

■編集の話

編集の話です。
編集とは何をするかというと、おおざっぱに言うと「素の文章をきちっと章・節・項に分け、長すぎる文章は短くしたり、句読点をきちんとしたりする。目立たせたい言葉には括弧を付ける。」といった、「文章の後処理」と「DTP(昔で言う製版)のための指定&前処理」といった作業を指します。

実は、この作業をきちんとやっていないでデザインやDTPに回すと…どうやっても、わかりにくい「文書」ができてしまいます。それは、たとえて言えば塗装の前の面取りや仕上げを行わなかった場合に相当します。どうなるのかは言うまでもないでしょう。
ですが、どうしてこういったことを行わないのかというと、理由は簡単、誰も教えてくれないからです。
国語の教科書も(あえて言うと数学も)、実は言うと上のような手順の作業を必ず行っています。
しかし、教えるのは小説や古典文学(もしくは方程式の解法)の内容であり、その「見やすい本の作り方」については、ほとんどというか、自分の学校で学んだ範囲では教えてくれることはありませんでした。
習ったことがないことですから、できるわけがありません。
まぁ一部の才能のある人は、最初からきれいに書くことができますがこれは例外としましょう。
また、趣味で編集の技能を口伝で伝えられている人がいますが、これもまた例外と言うことで。

■編集とは何をする?

さて、では今回の本題です。「編集とは何をする?」という内容の一番上についてはすでに書きました。
「読者に読みやすくすること」が目標です。
この場合、読者というのは製品を買ってくれた人を指します。

しかし、往々にして最初の原稿を書く人も、その原稿をチェックする人も、誰も読者のことをよく知らないということがあります。
たとえば、書いた人も見る人も現場の人間でしたら、「こんなバカのことをするヤツは世の中にいないからとばしたってだいじょうぶだぜい」と思ってしまって、大きく書かなければいけない注意書きを小さく書いただけでよしとしてしまうところがないとはいいきれません。
なお、製品を一般に発売する際には、このことは特に気を付ける必要があります。
むしろ素人に近いスタッフを呼び集めて「こういうときどうする?」と実地に使わせて観察し、かつ聞いてみて、「危なそうだ」と思ったことはその操作や作業の方法のそばに書いておくべきでしょう。

話がそれました。
いろいろな機械で、手順が最初は一つで、順に機能によって分岐していく場合、それぞれのセクションの先頭に「この機能は●●を目的としています」と記載していないと、よくある「機能が羅列してあるが、その機能自体が何が何だか分からない」というよくある悪い取扱説明書になってしまいます。

■責任を取る編集長は大切

こういったことを防止するのは、たしかに何割かはライター(書き手)の役割です。しかし、取扱説明書というのはあくまでも書籍の一種です。そして、書籍である以上、全体の構成などについては「編集長」が責任を負わなければいけないのです。

会社によってこの編集長という名称は異なることがあります。しかし、だれか一人、最終責任を負う人は絶対に必要です。どんな名称であれ、内容二内容に責任を負う人がいなければ決して良い物はできないのです。

編集長は、当然ながら編集や執筆といった制作業務に精通している必要があります。
実務としての業務を知らなくては、スケジュールの調整などができないからです。
たとえば、三日間スケジュールを短くして欲しいと営業から言われた場合、それを受け入れて良い物かどうかを品質の面から判断するのは編集長の仕事だからです。

最初から、品質を保ったまま納期を短くすることが無理であれば、無理だと正直に言って、「品質を妥協するか、納期をなんとかしてもらうか」の二択をありのままに告げて経営者に判断してもらわねばなりません。(これを判断するのは営業の仕事ではありません)

品質は価値です。ですから、高い品質には高いコストがかかります。
同様に、納期もまた価値です。ですから、短い納期にはやはり高いコストがかかるのです。

コストを下げて、高い品質と短い納期。

そんな夢のようなことは残念ながらありえません。
そして、物事には責任者が必要です。

今回は、ちょっときついことを書いてしまいました。

来週は申し訳ありませんが、お休みさせていただきます。

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


【わかりやすいマニュアルの作り方】第159回取扱説明書の対象について

ようやく少しずつ温かみを感じるようになってきました。
まだ春は遠いですが、春の足音が聞こえてくるような気がします。

弊社では、先週はいろいろな所に出かけていました。
今回は、その中でつかんだ新しい考えについて述べさせてもらおうと思います。

■制作する取扱説明書の対象を広げる

弊社では、これまでは主に「一般消費者」(コンシューマー)向けの取扱説明書を扱ってきました。

したがって、制作された結果は「印刷所に納品するとそのまま印刷できる」データであり、「凝ったレイアウトされたキレイなデザイン」の仕上がりでした。

はっきり言うと、格好の良い出来あがりです。

しかし、問題もあります。

格好良くしようとすると当然ながらコストがかかります。分かりやすくするためにはある程度の作業コストは必要ですが、格好良くするためのコストとは別のことです。

簡単に言うと、コストの半分はDTPとデザインとレイアウトに掛かっています。これを切ってしまおうということです。

実を言うと、弊社の利益もこのあたりから捻出させていただいたりすることもあるので、これは経営的にはかなりの冒険でもあるのですが…。それでも、この仕事には絶対に意味があると私自身が確信しています。だから、やるのです。

■技術者・作業者・販売者向けの取扱説明書

最終消費者向けの製品を作っていないメーカーやサービスを提供している会社は非常に数多くあります。実際のところ、最終消費者向けでないメーカーやサービスを提供している会社の方が数が多いのではないかと考えています。

営業に行くとよく言われるセリフがあります。

「うちでは消費者向けの製品は作っていないから、取扱説明書は必要ないんですよ」

そうでしょうか。

自分は「技術者・作業者・販売者向けの取扱説明書」のできが、いまひとつのために、作業が滞ったり問い合わせが多くなったりしている例を数多く見ています。

作業マニュアルはきちっと作られている方が良いに決まっています。あえて言えばきちっとできていない作業マニュアルはタダのゴミです。

自分はきちんとした取扱説明書を作成する技術を持っています。それは構成であったり、編集であったり、、最低限のレイアウトの知識であったりしますが、それは極小のハンダ付けをしたり、バフがけで平面に磨いたりすることと同じように、身につけようとするとどうしても時間がかかるものです。

極小のハンダ付けをしたり、バフがけで平面に磨いたりする作業が必要になったらどうしますか?社内の事務員にやらせたり、エンジニアさんにちょっと練習させてやらせますか?
まさか。当然、外注しますね。

取扱説明書制作も一緒です。「きちんとしたわかりやすい取扱説明書」を制作するには、技術が必要です。

「技術者・作業者・販売者向けの取扱説明書」をわかりやすく作り直して、公開してみませんか?

弊社では、現在「技術者・作業者・販売者向けの取扱説明書」の価格体系や作り方を検討しています。少なくとも現状の最終消費者向けの取扱説明書に比べれば大幅に低コストでできると思われます。

もちろん、コストを削っただけではなく、お使いになるお客様にもメリットがある方式、具体的には最終的に納品するデータがDTP用のIllustratorやIndesignといった、操作に専門的な知識が必要なデータではなく、一般的なWordのデータと公開用のPDFのセットなどにする(その分は弊社でもDTP作業がなくなってコストが低下します)といったことを考えております。

詳しく仕様が決まったらまた、こちらでお知らせさせていただきます。

よろしくお願いします。

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


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

 

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

■バックアップについて

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

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

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

例:
file20110912を使っている場合

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

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

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

■もう一つのメリット

さて。

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

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

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


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

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

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

■基本的な定型化

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

■上のレベルでの定型化

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

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


【わかりやすいマニュアルの作り方】第131回 納品の話

今回は納品の話です。
というか、日本企業であればどこでも、納品…納期が最大優先であることは疑いのないところではありますが。

■納品とチェック

取扱説明書は、製品そのものに比較した場合、修正が容易という特徴があります。

しかし逆に言うと取説屋としては「いつまでたっても納品したはずの仕事がおわらない」といった事態になることになります。
このあたりはメーカーさんと事前打ち合わせがどこまでできているか、という点につきるのですが、修正作業自体が大きくなくても「忙しいところに予想外に」入ってくることがあるので、問題になることがあります。

取扱説明書は、制作方法は販促物などと同じ、印刷や版下製作です。
しかし、広告よりも製品に対する責任の度合いが強いため「かならず修正しなければならない」という強い動機が働くのです。

メーカーとしても、取扱説明書は製品の一部としてきちっとチェックする必要があります。
厳密には取扱説明書まですべて整っていてはじめて「製品」といえるからです。

納品する取説屋としては、もちろん大切な商品ですが、同様に内容をチェックするメーカーしても、製品の品質にかかわるのと同じ重さが要求されます。

■お客様にとっての取扱説明書

さて、メーカーと取説屋にとっては、こういうポジションの取扱説明書ですが、それを最終的に使うお客様の目からみたらどうなるでしょうか。

お客様にとっては、製品を扱うためのただひとつの手引き書です。

もちろん、その商品を対面販売して、サポートもできているならばまだ他の手段があるということになりますが、現在は対面販売よりも通信販売の比率が増え、お客様としては、頼れるものは文書だけといった状況になっています。

ですから、「お客様がきちんと操作できるか」は、制作者とメーカーのチェックにかかっていると言っても過言ではないのです。

そして、取扱説明書は納品の時に決定してしまいます。
だからこそ、チェックと納品がもっとも大切になってくるのです。

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


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

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

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

■見出しを設定しよう

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

しかし。

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

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

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

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

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

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


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

今回はマクラなしです。

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

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

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

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

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

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

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

チームを作って対応する

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

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

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

続きます。


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

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

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

さて。

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

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

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

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

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

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

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

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

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

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

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

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

続きます。


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

続きます。


良い製品に良い取説を提供します is powered by Wordpress | WordPress Themes