2026
2025
2024
2023
2022
2021
2020
2019
2018
2017
2016
2015
2014
2013
全17件 (17件中 1-17件目)
1
テクニカルライターは、新しい技術用語の勉強をして、締め切りをめざして、原稿を書く。納期がきついときは、ただひたすら原稿を書いている。なので、身なりになんて構ってられない。そのへんにあるものを着て、会社にいく。極限に達したときは、誰ともあまり話をしたくない。テクニカルライターは、お客様のところに伺って、取材もするし、プレゼンテーションもする。受注できるかどうか決まる日は、気合もいれる。スーツも着るし、ぴかぴかの靴もはく。顔は満面の笑みをたたえ、いろいろな人とお話できるのが楽しい。テクニカルライターは、仕事の周期によって、着ているものから、態度まで異なる人種である。(というのは、私だけ?)
2004/03/31
「開発者が残業して、社内でマニュアル作ればコストダウンでしょ」「システムを一番知っているのは開発者(SE)だし」「1~2週間もあればそれなりに制作できるでしょ」このような話になるのも、昨今の経済情勢ではしかたない面もあるかもしれません。※特に北海道の不況はなかなか出口が見えませんしね。そんなわけで、わかりやすいとは到底言えないマニュアルが世の中に出回ります。それで実際、コストダウンしているでしょうか?開発者の人件費、マニュアルがわかりにくいことに起因するユーザーサポートの経費はどうでしょう?補足の説明資料を、何度も作り直したりしていませんか?一度、コスト計算して、アウトソーシングした場合と比較してみませんか?---------------------------------------------------『でも、製品の仕様をいちいち説明したりするのは面倒』『外部仕様書も、説明資料も作る暇ないよ』---------------------------------------------------その点については、次回の日記で。(^_^)/~
2004/03/30
どんなお仕事にも当てはまることだと思いますが、テクニカルライターも想像力が大事だと思っています。開発の方がどんな思いで製品を作っているのか、そのことを仕様書やプロトタイプからくみ取り、その思いをどのように伝えたら、ユーザーさんが一番操作をしやすいのか、この部分を考えることがとても大事なことだと思うのです。どんな人がどんな場面で使うのか、そういうことに神経を使い、今回のマニュアルはどう作ろうかを考える。納期に追われると、とにかくデジタルのデータを完成させることに神経を使い、想像力をめいっぱい使うことがおろそかになります。「何が求められるのか」、いつも大事に考えて仕事をしようと思います。
2004/03/29
はい、クラッシャーのMです。開発中のプログラムを何度もインストールし、各種データベースを入れては消し、ときにはレジストリをいじり、大量のマニュアルデータを書いては消し、書いては消し。さらに、テクニカルライターの宿命「新し物好きの魂」がソフトの新バージョン体験版をインストールさせ、「便利なフリーウェアはないか魂」が月に1度くらい発動いたします。もちろん、Webアプリの画面を設計しろ、と言われれば、メジャーなブラウザの、あらゆるバージョンをインストールするわけで…。でも、不調なHDDをフォーマットして、OSを再インストールするのも、実は大好きです。しょーがないんです。あれもこれもテクニカルライターの宿命なんですってば。
2004/03/26
去年は、パソコンが壊れる年でした。(T0T)。Macintoshは、コピーにやたら時間がかかり、終わったと思ったら、そのファイルは壊れてました。それで、どうにもならない。こちらは、マニュアル関連のデータしか登録してないので、バックアップはある。即刻ハードディスクのフォーマットとOSの再インストール。Windows98の挙動がおかしくなり、Excelを起動したら暴走。ほかの場合はOKだったので、仕事関連のファイル、辞書、メール、お気に入りのバックアップをとって、またまた、ハードディスクのフォーマット。Windows XPへアップグレード。やれやれと思ったら、今度は、そのWindows XPが起動しない。ひぇ~~。外出先から戻ったばっかりで、バックアップがない (--;幸い、原稿執筆真っ最中の出来事ではなかったので、それだけが救い。お気に入りも、メールも、辞書もないパソコンは他人みたいです。わたし好みのパソコンになるまでに、時間が必要でした。わたしたち二人は、会社で「ハードクラッシャー」と呼ばれてます。使用時間が長い、開発中のソフトウェアを動かす、インストールとアンインストールの繰り返しなど、わたしたちの仕事には、壊れやすい原因となるものが多いのかも... いいわけですか?
2004/03/25
テクニカルライターは辞書が命!?マニュアル制作の工程の中で、バリバリ執筆している期間は3分の1くらいしかないので、とにかく速く、正確に書くために辞書を育てます。商品名やプロトコル名のスペルミスは恥ずかしいので、いろいろ登録してます。 えくす → Internet Explorer てーし → TCP/IP ゆー → UDPブロードバンド用語も。 び → Bフレッツ えで → ADSLマニュアルでよく使う言葉 く → クリック ぼ → ボタン …タグも登録してますよ。 び → <br>、<b> ぴ → <p> …あとはかなりマニアックな用語も。 てい → TRCD(図書館システムのマニュアルで)麻雀ゲームのマニュアルやメルマガも書くのでひととおり…^_^;。 てんぱい → 聴牌 めんぜん → 門前(面前じゃないのよー) ほうじゅう → 放銃(放縦じゃないのよー)辞書のバックアップを忘れて、PCが逝ってしまうと、ショックでかいです。はい。
2004/03/24
小学生の国語教育も、変わってきてますね。昨日、小学校5年生の子が持ってきたプリントは、ディベートの課題でした。わたしが「ディベート」という言葉を知ったのは、大学生のとき。えらい違いです。課題は、「郵便局で、住基カードを持っていなかったので、きちんとした対応をしてもらえなかった」という投書を題材に、郵便局の対応が正しいのか、投書した人が正しいのか、意見とその理由を書くことです。両方の立場での意見を書いた後、「あなたならどう思うか」という欄もあります。"ライター"という仕事をしているので、子どもの書いたものへのチェックは厳しくなってしまう私。でも、今回はどちらの立場での意見も、筋道が通っていて、なるほどなと納得しました。その昔、新人の頃に読んだライティングの本には、アメリカでは小さい頃から自分の意見を書く習慣があるが、日本ではない。それが、日本語のマニュアルがわかりにくい原因のひとつでもあるというようなことが書かれていました。時の流れははやいです。
2004/03/23
小学校時代の国語の教科書、覚えてますか?物語があって、「このとき主人公はどんな気持ちだったでしょうか?」なんて問題ばかり出題されていたイメージ、ありませんか?私がこの業界に入った当時も、「日本の国語教育が悪いから、説明書もわかりにくい!」なんて批判がありました。ところが、最近の国語は違うんですよー。長女(小3)は、国語の時間に「説明書を書いてみよう」という授業を受けてるんです。ひょっとしたら、こんな授業を受けて「将来は説明書を書く仕事についてみたい!」という小学生が出てきてるかもしれません…。テクニカルライティング業界の未来は明るいかも??
2004/03/22
久しぶりに、担当の印刷屋さんに電話をして、マニュアルの原稿を取りに来ていただきました。電気屋さんで売られているような、パッケージソフトの売れゆきが落ちているので、マニュアルを印刷会社で印刷することも少なくなっています。私たちも、マニュアルのデータをPDFファイルに変換して納品することが多くなりました。印刷会社にデータを渡さなくてもよい分、ぎりぎりまで原稿を書けるのでちょっとラクなのですが、自分の原稿が「本」という形になる喜びはなくて、寂しいなと思っていました。最近、ひさびさに印刷まで担当させていただく仕事をしました。印刷会社から校正用の原稿がきたとき、この原稿を戻したら、今度は本になってくるのだなと、ちょっとわくわくしました。完成ファイルをメールで送るのも便利ですが、箱に詰めた本をお客様のところに持っていくのも、なかなかいいものですよ。
2004/03/19
この仕事を始めた頃、今から15年ほど前になりますが、校正と言えば「紙」に「赤」を入れるというのが当たり前でした。最近は、紙に赤を入れるよりも「PDFファイル」に「注釈」を付けて、メールで校正のやり取りをすることの方が多くなりました。もちろん、メールの文面だけで例えば「P.xxは画像差し替え」などのように指示していただくこともありますが、PDFだと、具体的にどの場所に対する指示なのかがわかりやすくてよいのです。特に開発者の方は、手書きで校正するよりも、パソコン上で校正する方を望まれることが多いですね。さて、DTPソフトやワープロソフトで書いたマニュアルなら、すぐにPDF化もできますが、HTML形式のマニュアルの場合、「PDFにできるの?」という方もいらっしゃるかもしれません。実は、かんたんに、できるんですよ。Acrobat の WebCapture 機能というのがありまして、それを使うと、あっと言う間に変換してくれます。title タグから、しおりも生成してくれたりする、スグレモノだったりします。ブラウザ上で見る場合とは、若干イメージが違ってしまいますが、私のように、校正のやりとりをするような場合には、非常に便利な機能です。皆さんもお試しあれ♪
2004/03/18
マニュアルを作るときは、必ずしも自分たちの詳しい製品であるということはありません。むしろ、新しいコンセプトの製品であったり、特殊な業界の方が使う製品であったりするので、詳しい知識を持っていないことも多いのです。ですが、最初に知らないことは、それほどこわいことではありません。お客様から直接、製品の開発コンセプトを聞く、参考文献を紹介していだだく、インターネットで関連用語を調べるなど、いろいろな方法で、知識を得ることができるからです。私たちの勉強の目的は、ユーザさんが読んで製品を操作できるための文章を書けるようになることです。そこに重点を絞って情報を集めます。根っからの文系の人間なので、関数とか二進数とか全然わからないと思っていたのですが、人間、その気になれば、理解できるようになるんだなと、この仕事をしていてつくづく感じます。私は密かに、この勉強の過程は、通訳者が通訳をするために事前に情報を集める作業に似ているなと思っています。通訳の方は、たとえば英語→日本語の場合、最低限機械的に英語を日本語にできるようになるまで、勉強をするそうです。テクニカルライターは、最低限機械的に操作マニュアルにできるようになるまで、製品についての勉強をします。その後、どこまで理解できるか、どこまで粘れるかが、マニュアルがわかりやすくなるかどうかの、決め手になってきます。いくら、書くためのテクニックを持っていても、製品の本質を理解していなければ、読み手には、わかるようなわからないようなマニュアルになってしまいます。仕事が終わると、きれいさっぱり忘れてしまうことも多いですが...(^^;少なくても、執筆開始から納品までは、その製品の専門家です。
2004/03/17
マニュアル制作を依頼されるとき、「今までは社内の開発者が書いていたのですが、 どうも評判が悪くて…」と仰られる場合が多々あります。そのような場合、参考資料としてお借りするのですが、なぜ、評判が悪いのか、その原因を考えてみたりもします。開発者の方は、もともと論理的な思考が得意で、文章も上手な方が多いのです。また、製品や対象ユーザーの知識もあり、何より製品に対する「愛」がありますから、よいマニュアルが書けるはず…です。それでも評判が悪いのはなぜか。思うに、その最大の原因は、ユーザーのある特性への理解が足りないからだと思います。どんなユーザーにもほぼ共通する特性、それは「できることなら、マニュアルなんか1ページたりとも 読みたくない」と思っていること、なのです。そんな人たち相手に、製品の利点だの、自分には必要のない機能の説明だの、長々と書いては逆効果です。「読みたくない」ユーザーに必要な説明を、いかに読ませるか、それもテクニカルライターの腕の見せどころなのだと思っています。
2004/03/16
テクニカルライターの最大の楽しみは、いろいろな製品を操作できること。しかも発売前に。守秘義務がありますから、具体的な製品名を書けませんが、ルータだったり、グループウェアだったり、ホームユースのソフトだったり、本当に様々なソフトやハードの仕事を担当させていただきました。インターネットがこんなにポピュラーになる前に、ルータやTAのマニュアルを書かせていただいたことがあります。TCP/IPとは何か、ドメイン名とは何か、ダイヤルアップとは何か、必死に勉強しました。インターネットに常時接続など非常に高価なものだと思っていたのですが、今では私でも(?)自宅で使えちゃう手軽なサービスになっちゃいましたね。そういえば、その当時は、WindowsもMacintoshも、インターネット環境を標準でサポートしていませんでした。時の流れははやいものです。=====今日のMの怒りとあるサイトからペ・ヨンジュンの写真がダウンロードできない。「キャプチャーしてやる!!」Windowsなら[Print Screen]キーを押すと、画面をコピーできます。アクセサリのペイントを起動して、貼り付けを実行すると、ローカルマシンに保存できます。※あくまでも個人でお楽しみください。
2004/03/15
先日、私の車(ミニカでした)を廃車にしました。今はダンナの車だけで生活しておりますが、いざ1台になると少し不便を感じます…(-_-;)そんな中、Pods UniteのCMが気になって仕方ありません。iPod つきの New Beetle。しかし、私にとってはNew Beetle つきの iPod に見えて仕方ありません。ちょっと高い iPod だけど、いいかもなあ…。
2004/03/12
マニュアルを読んで、操作できるかできないかの決め手になるのは、ライターが製品の時系列分析を行ったかどうかにかかっていると思います。時系列分析とは、どの順番でどの機能を使うのか、時間を軸にして、製品の操作を考えることです。たとえば、あるソフトを起動するならば、1.パソコンの電源をONにする。2.OSが起動するのをまつ3.デスクトップに表示されるソフトのアイコンをダブル クリックする。というように、時間の流れにそって操作手順をあてはめていきます。当たり前じゃないかと思っても、ひととおり操作の流れを作ってみると、案外見落としていることに気がつきます。この時系列の分析を間違うと、やっぱり操作できないマニュアルになってしまうので、緊張します。執筆中に、操作の順番を変えたほうがわかりやすいことに気がつくこともよくあります。途中途中で、目次の並び順が本当にわかりやすいか、チェックすることが大切ですね。
2004/03/11
わかりやすいマニュアルを書くのは、比較的簡単なんです。日記公開の記念に、特別にお教えしましょう♪●ポイント その1製品の操作を、時系列に整理してから、書き始めましょう。●ポイント その2記載する内容ごとに、読者、難易度、使用頻度、などで分類し、きちんと整理してから書き始めましょう。これだけ守れば、製品を知っている方なら、大体、わかりやすいマニュアルを書くことができるんです。テクニカルライターの技術とは、このようなことを、短期間で、正確に、正しい日本語と見やすいデザインで、きちんとしたデータで納品する。ということなんです。特に、この「短期間で」というのがポイントでしょうかね。
2004/03/10
テクニカルライターは何をしている人??答えは、コンピュータ関連製品(ハードウェア、ソフトウェア)の取扱説明書を書く人です。「わかりいにーい」「読みたくなーい」という声も聞きますが、それでもライターたちは、どうしたらわかりやすくなるのか研究しています。これから、テクニカルライターの生活を綴っていこうと思います。よろしくお願いします。
2004/03/09
全17件 (17件中 1-17件目)
1


