2008年6月アーカイブ

手軽に画面をキャプチャし、FTPサーバにアップロードできるツールがないか探したところ、FastStone Capture というシェアウェアが見つかりました。
英語版ですが、これは便利です。

会社を発展させていく過程で、さまざまな支障が出てくるものである。
今年の新社員を迎えるにあたって、今は仕事を増やすために様々な営業活動をしている。
新社員を受け入れるための設備投資に資金が必要ということもあるが、それより新社員に
十分仕事を提供できるようにしておきたいということがある。

今まで工数不足でお見送りさせていただいていたお客様に仕事をいただけないかお願いしたり、
現存のお客様に新規のお客さんをご紹介していただけないかお願いをさせていただいたり、
セミナーに出かけて名刺交換をさせていただいたりしている。お客様の暖かいご支援のお陰も
あって、少しずつ成果が現れてきたのだが、私が営業活動に回っている分、製作の工数が
減ってしまっている。その結果、土曜日も仕事をしていることが多く、家族には大変申し訳
ないと思う。

10件前後で同時進行している仕事を管理していると、仕事を手伝っていただいている提携
編集者さんへの連絡が遅くなったり、キャンセルになった仕事について連絡するのを忘れて
しまったりするような事態が発生するようになった。

前へ進むことばかり考えていると本当に大事なことを見失ってしまいかねない。決して
忘れてならないのは、今自分がここにいるのは、多くの人の協力と応援に支えられていると
いうことだ。会社を発展させるのはよいが、それは支えていただいている方々へきちんと
感謝を示すことができた上での話しであろう。
家族のみんな、ありがとう。
社員の皆さん、ありがとう。
編集者さん、ありがとう。
お客様、ありがとう。
元同期の友人達、ありがとう。
同級生の皆さん、ありがとう。
会計士さん、社労士さん、ありがとう。
事務所の地主さん、ありがとう。
翻訳者の大先輩、ありがとう。
経営者の大先輩、ありがとう。
翻訳者の同士さん、ありがとう。
デザイナーさん、ありがとう。
プログラマーさん、ありがとう。
こうやって書き始めると、如何に多くの方々に支えられているのかが分かる。
しっかりと地に足をつけて進みたいものである。

日本語のテクニカルライティングでは、操作と操作結果を別の文章にして分かり
やすくするという手法があります。
例えば、次のような書き方です。

1. [環境設定]ボタンをクリックします。
   [環境設定]ダイアログが開きます。

これに対し、Microsoft Manual of Style Third Edition では、次のような記述が
あります。

Avoid explicit descriptions of system responses. If necessary to orient the reader, include the response in the step or the one immediately following.

つまり、「操作結果の説明は避けること。説明する必要がある場合は、操作と一緒に
書くこと。」ということになります。これに従うと、上記は以下のようになります。

1. Click Preferences.

「[環境設定]ダイアログが開きます。」は、実際に操作してみれば分かることなので、
書かないことになります。物事を丁寧に説明することを好む日本人にとっては、
抵抗があるかもしれません。

「[環境設定]ダイアログが開きます。」をMicrosoft Manual of Styleに従って
入れるとしたら、どう書くのでしょうか。以下のようになります。

1. Click Preferences to open the Preferences dialog box.

日本語テクニカルライティングと英語テクニカルライティングでは、
このように対立するような考え方があったりします。

一文一文翻訳していると、対象言語のテクニカルライティング手法に
そぐわない文章ができてしまういい例です。

会社を発展させていく上で、古いバージョンのソフトウエアが
購入できなくなっていくことは、悩みの種である。

例えば、MS Wordを考えてみる。これから数年先でも一般の会社は、
バージョン2003以前のWordを使うであろう。
お客様が古いバージョンを使う以上、弊社としても古いバージョンで
対応できなければならない。

しかし、今後新入社員が入ってきた時に、古いバージョンは
購入できなっている可能性が高い。MS Word 2003も、もうそろそろ
販売終了になる。仕方がないので、見込みの先行投資として、昨日
Word 2003を3ライセンス購入した。

他のソフトウエアについても同じことが言える。弊社では、Adobe社の
Creative Suiteを使って、お客様にレイアウト済みのドキュメントを
提供させていただいている。お客様の多くは、今後もしばらくはCS2以前の
バージョンを使うであろう。CS2はすでに購入できない。

OSについても同じである。Windows Vistaで動作が保障されて
いないソフトウエアは多くある。これらのソフトウエアを使う限り、
Windows XPは必須になる。しかし、Windows XPもそろそろ販売終了だ。
早速、今年の新入社員のための Windows XPマシンを購入した。
来年はどうしよう。Windows XPも数ライセンス購入しておいた方が
よいのだろうか。このように考えていくと、切りがない。

この問題はどう対処すればよいのだろうか。
1つの解決案は、分業を進めるということである。レイアウトに関する
作業をすべて現在の編集担当の人達に一任し、翻訳者がレイアウトソフトを
使わなくても済むようなワークフローを確立できれば、しばらくは
古いバージョンのソフトウエアを追加購入する必要はなくなる。

もう1つの解決案は、オープンなドキュメント形式を使った
ソリューションを提供できるような会社になることである。
例えば、XMLとXHTMLを使ったターンキードキュメントソリューションを
提供できれば、お客様も Word や CS などの専有技術に
依存する必要がなくなるので、喜んでいただけるのではないか。

XMLとXHTMLを使ったターンキーソリューション。大手のドキュメント会社が
豊富な技術者と研究費を投入して、開発を進めている分野である。
一見太刀打ちできないように思えるが、小さい会社であるからこそ
小回りが利くコストパフォーマンスの高いソリューションを
提供できる可能性は十分ある。

色々な訳し方があるかと思いますが、ネットを検索すると
以下の2つの書き方があるというところが興味深いです。

Commands are separated by semicolons.
Commands are separated by a semicolon.

一般的に考えると、前者が普通の書き方ではないかと思います。
しかし、IBM社やMicrosoft社のウエブサイトでも後者の書き方が
見受けられます。

なぜ、このようなことが起きるのでしょうか？

テクニカルライティングでは、情報を的確に伝えなければなりません。
前者の書き方の場合、2つのコマンドの間にいくつセミコロンが
入るのかは明確ではありません。常識的に考えれば、1つなのでしょうが、
1つであると明示されているわけではないのです。

そこで、後者の書き方が使われることがあると私は考えております。
後者の書き方の場合、1つのセミコロンであることが明確です。
ただし、この書き方にも問題があります。3つコマンドを連結する場合、
3つのコマンドを1つのセミコロンで区切るのか、という矛盾です。

普通の読み手ならば、気づきもしないこのような細かいところを考え、
読み手が一度読めばすんなり理解できるように文章を書く、というのが
テクニカルライターの仕事です。

• 「プラスドライバ」
  Philips screwdriver
• 「マイナスドライバ」
  Flat-blade screwdriver
  Flat-head screwdriver
  （他にも色々な名前があるようです。）
  

機械がアラームを発生する原因となる「アラーム要因」という言葉があります。
例えば、機械の温度が一定の温度を超えるとアラームが発生する場合、「機械の温度が一定の温度を超えること」が、アラーム要因です。

この言葉を簡潔に表す英語は何でしょうか。
「要因」を辞書で調べますと「factor」とか「cause」という言葉が出てきます。
ただし、これをそのまま使って、「alarm factor」とか「alarm cause」とすることは
できません。「alarm factor」と書くと、「アラーム発生率」という意味に読めます。
Googleで調べると「アラーム発生率」という意味でよく使われていることが分かります。
「alarm cause」はこの言葉の組み合わせ自体が不自然です。

「アラーム要因」とは、「アラームを発生する事象」ですから、
「events that trigger alarms」と訳すことはできますが、
日本語のように簡潔ではありません。

この言葉には長年悩まされてきたのですが、昨夜ふと思いつきました。
「alarm source」です。いかがでしょうか。
技術者にとっては常識かもしれませんね。

先月と今月は非常に仕事が立て込んでいます。
新入社員を迎え入れるために先行投資が必要になるので忙しいに越したことは
ないのですが、社員にも疲れが見えてきていて申し訳なく思います。

さて、今日は普段私がどんなことを考えているのか、書き出したいと
思います。あまりにも色々なことを考えているので、自分でも
書き出すのが楽しみです。それでは、スタート。

• 顧客を増やすためには何をすべきか。
• 展示会やセミナーなどに出席し、名刺交換する。
• 会社のウエブサイトに来訪してもらえるように、名刺は工夫しないと。
• では、名刺はどのようなデザインにしようか。
• 普通の名刺じゃだめだ。会社のURLだけを記載した名刺はどうか。
• 仕掛けのある名刺なんておもしろいんじゃないかな。
• 会社のウエブサイトの来訪していただいたとき、印象に残るウエブサイトに
  しないとな。ウエブサイトを改善しなくては。
• とりあえず、トップページのFlashアニメーションを変えよう。
• アイデアを書き出し、デザイナーに発注しよう。
• 新社員がいち早く稼げるようにするためには、OJTの充実が欠かせない。
• Day 1 ～Day 30 の集中研修用の教材を作らなくては。
• 新入社員が入ってくるに伴い、Tradosのライセンス、パソコン、ソフトウエアを
  購入しなければならないな。100万円ぐらいで足りるかな？
• 新入社員が使うワゴン（書類を入れるもの）が必要だな。
  
• ところで、InDesign CS2 とか Word 2003 とか今はもう手に入らないぞ。
  このソフトウエアがないとちょっとまずいよな。どうしよう。
  
• あるお客さんは、PDFマニュアルからHTMLベースの取扱説明書に
  移行したがっている。弊社の編集の売上が半減する日もそう遠くないかもしれない。
  InDesign -> XML -> HTML形のヘルプへ変換するターン・キー・ソリューションはないかな。
• XML、XSLTは勉強したが、XSLTではInDesignから出力したXMLをHTMLに変換するのは
  難しそうだな。この辺に詳しい人いないかな。
• 分配型賞与制度は、売上の何割までいけるかな。
  なるべく一生懸命働いてくれる社員に報いたいが、経営者として自分も報酬も得たいし。
• 以前働いていた会社で、社員の給料を賄うには社員が自分の給与の2倍以上
  売上に貢献しないと会社は赤字になると言っていたが、本当にそうだよな。
  自分が経営者にならないと、こういうことは分からない。
• ちなみにベテランの翻訳者に売上の50％を分配したとすると、会社の運営コストは
  20%ぐらいだから、残りは30％。この30％で、経営者としての報酬と、
  品質管理マネージャ（校正者）の報酬、将来の庶務の報酬、研究費を賄うとなると、
  やはり10人ぐらいの会社にしないと成り立たない。
• 最初は自分が品質管理を担当することになるが、何人の翻訳者まで自分一人で
  チェックできるんだろうか。ざっと見て3人ぐらいいたらもう手一杯じゃないかな。
  これでは、10人にたどり着く前に、もう一度工数不足が起きそうだな。
• ベテラン翻訳者が会社を退社するまでに、品質管理のポストも経験しておくと
  きっといい経験になるだろう。このポストに十分の報酬を払えるようにして
  おかないといけないな。
• 途中、自分の報酬を減給しなければならないかな。
• いや、「ミリオネア・マインド」という本には、成功する人は両方とも手に入れる
  努力をすると言う。社員が稼げるようになるまでは、自分の報酬を下げる
  と考えるのではなく、どうしたら社員が稼げるようになるまでの間も
  自分の報酬をキープするかを一生懸命考えなければいけない。
  
• 10人ぐらいの規模の翻訳会社の社長はどれくらいの報酬が妥当なのかな？
  
• 今色々な情報をブログで管理し始めたが、プロバイダーのブログサーバに依存していると
  危険かな？ 社内でブログサーバーを立ち上げた方がいいかな。
• 校正作業に使えるツールを開発してくれる人いないかな。
• 会社経営についてコーチングしてくれるような先輩経営者はいないかな。
• 同業者の大先輩社長とお話しする機械機会があったら、いい刺激になるだろうな。
• 駄目もとで頼んでみよう。
  
• 品質管理者とになるにあたって、Microsoft Manual of Style と Chicago Manual of
  Styleは、丸暗記するぐらいに熟知していないといけないな。こつこつ勉強しなければ。
  毎日1ページ読もうと思っていたが、もう三日坊主だ。いかん。
• Microsoft Manual of Style と Chicago Manual of Style のチェックをソフトウエアを
  使ってチェックできるようにしたいな。いつもツールの開発をお願いしている人に
  頼みたいところだが、彼も忙しいからな。
• どこかで、Visual Basic programming for Microsoft Office applications を
  使ったツールを、社内で開発できるようにしなければならない。
  やはり新社員は、プログラムが書ける人がほしいな。翻訳の仕事が
  忙しくないときには、その人にツールの開発をしてもらえたらうれしい。
  
  
  
  
  

和文

プログラムデータの一覧表示、データ編集、データソート処理を行なう事が出来ます。

Ambiguous

You can view the list of program data, edit data, and sort data.

和文をそのまま上記のように訳すと、「edit data」と「sort data」が果たして
述語なのか目的語なのか分かりづらくなってしまいます。
つまり、上記の英文は、ちょっと英語としてはおかしいが、
「プログラムデータ、編集データ、ソートデータの一覧を表示することができます。」
と誤解される恐れがあります。

Clear

You can edit data, sort data, and view the program data list.

このように言葉の順番を変えるだけでかなり明瞭になります。
他の書き方も以下に示しておきます。

You can view the list of program data. You can also edit and sort data.

You can (1) view the list of program data, (2) edit data, and (3) sort data.

• 4:30 起床。個人事業レベルの会社から組織力を生かした本当の会社へ
  成長するために必要な事項を検討。
• オープンな給与体系（売上に対する配分型賞与制度）
• 研修制度（翻訳スペシャリストになるために必要なスキルの洗い出し、
  そのスキルを効率よく習得するためのOJTシステムの構築）
• 5年先までの売上拡大目標を立て、1年ごとの売上目標を検討。
• いくつか売上のレベルに応じて、その収入をどう分配していくかをシミュレーション。
  （製作、品質管理、経営、運営コスト、研究、予備）
  
• 6:30 家族と朝食。
• 7:45 会社へ出社。社内翻訳者が担当している翻訳の校正。
• 11:45 昼食 & Hacky Sack
  
• 12:45 校正のつづき。
• 14:00 InDesign&Illustrator編集担当者の質問事項に対応。
• 14:30 自分が担当する翻訳を開始。お客様からのお問い合わせに対して、
  お見積書を提出。途中、15分昼寝（これで、睡眠時間5時間でもOK）。
• 19:00 帰宅、夕食。
• 21:00 翻訳を継続。
  社内翻訳者が仕上げてくれた翻訳チェック済みデータを編集できる状態にし、
  編集担当者へデータを転送。
  
• 22:30 新入社員の募集に応募してくれた方々へ会社の業務内容、給与体系、
  研修制度などの説明メールを作成して、送信。面会スケジュールの検討。
  
• 23:00 明日の朝に検討する課題をまとめる。
  寝る前に次の日の課題をまとめておくと、朝起きたときにすばらしいアイデア
  が次々に思い浮かぶ。なかなか解けない問題などもふっと解決方法が
  思い浮かぶからとても不思議。まるで寝ている間に頭の中の回路が
  つながるような感覚。
  
• 23:30 就寝