PC21表計算大会2003-04
2003/10/27
最近、めっきり寒くなりました。みなさん、いかがお過ごしでしょう。
実は、今年の7月頃から15年ぶりにテニスを復活して、3ヶ月で15キロ痩せました。ウェストも20センチ減。昔のスーツを楽に着られるようになったので喜んでいます。しかし、15キロ分の脂肪が減ったわけで、何だか今年の冬は異常に寒く感じます。
もともと私は暑がりで、12月頃でもTシャツにビーサンみたいな格好をしていたのですが、今年はダメです。もう、今から寒くてしかたありません。その原因が脂肪の減少なのか、それとも単純に去年よりも寒いからなのか…
まぁ、どっちでもいいですけど。

ということで、今年も表計算腕自慢大会の季節がやってきました。
応募される方にとっては、問題が発表される12月後半から、応募の〆切である1月中旬くらいまでが腕自慢大会の期間なのでしょうけど、われわれ審査員は違います。

まず、問題を考えなければなりません。毎年似たような問題を出すと「またかよ」と言われてしまいますし、かといってガラッと違う問題を出すと「難しすぎる」と文句を言われます。いやはや、問題を決めるのは毎年苦労します。それがこの時期です。実は、もうだいたい決まったんですけどね (^^;
この後、実際に解いてみて、難度や問題点などを調査します。もちろん、1-2-3や三四郎でも、同じ方法で解けなくてはいけません。そうして問題が確定し、誌面で発表するのが12月の後半。PC21の2月号になるのかな…とにかく、12月発売号です。

早い人は、この号が発売された日に応募作品を送ってきます。まぁ、今までのケースでは、このように速攻で送ってくれた作品が受賞することは希です。みなさん、じっくりと考えて作り込んだ作品を応募してくれますからね。実際には、〆切間際に応募が殺到します。毎年のことですから、こちらもそれを見越して予定を立てます。
その後、一次審査を行い、メーカーの合同審査会を開きます。厳選された作品だけが残りますので、会場内からは毎年驚嘆の声が聞こえてきます。で、最終的に受賞作品を決めて、作者に連絡して、解説号の誌面を作って、3月発売号で結果を発表します。これで今年の表計算大会もようやく終わります。その間に、Web用の問題を作成して、審査して、結果を発表するなど、やることは山ほどあります。

約半年を費やす表計算大会は、雑誌の企画としては異例中の異例です。ですが、毎年この大会を楽しみにしてくれる多くの読者を考えると、何とか盛り上げようという気持ちになってきます。
審査員という立場からは、あまり明確なアドバイスはできませんけど、どうか皆さん、表計算大会を楽しんでください。定められたルールの中で、自由な発想を、思う存分発揮してください。そうした作品を見ることが、われわれ審査員にとって何よりの喜びです。
そして、賞を狙う方々。小手先のテクニックに自己満足するのではなく、もっと大局的な考え方をしてください。なぜその関数を使うのか、なぜエラー処理をするのか、なぜこの表を作るのか……そうした"理由のある"作品は、数千件の応募作品の中でもひときわ光って見えるものです。

今年も、たくさんの応募をお待ちしています。(^_^)

パソコン誌とソフトメーカー
2003/10/03  
早いもので、もう10月ですね〜今年も残り3ヶ月。1年なんてアッという間です。
もう少しすると、いよいよマイクロソフトからオフィス 2003が発売されます。そうなると、また仕事に忙殺される毎日が続くわけで…

そういえば先日、ある掲示板で「パソコン誌はメーカーの悪口を書けない」という発言を見ました。パソコン誌はメーカーから広告を出してもらい、その広告料が貴重な収入源になるからです。もしメーカーの悪口……たとえば「このソフトにはこんなバグがある」なんて記事を書いたら、メーカーが怒って広告を出してくれなくなります。それは困るので、記事の中ではメーカーの悪口を書けないという意味の発言でした。

理屈ではその通りです。パソコン誌にとって広告料が貴重な財源であるのは本当です。過去、そうした記事に腹を立てた大手メーカーがいっせいに広告を引き上げたという事件も、業界内では周知の事実です。しかし、実際に原稿を書いている私の印象では、最近ではそういう"悪しき遠慮"をほとんど耳にしません。バグや不具合、セキュリティホールなどが発見されたときは、そのことを正確に伝えようとしています。メーカーが怒るから……なんて発想はありません。

正直なところ、パソコン誌の売れ行きは芳しくありません。以前に比べて売れ行きが落ちているということです。廃刊や統合される雑誌もあり、われわれライターとしても気を抜けないのが実情です。そんな中で、読者に支持されて毎月購読してくれる雑誌を目指すには、内容を充実させるしか方法はありません。どこかの雑誌を真似て、企画の二番煎じでお茶を濁していては、最近の読者を納得させることはできないのです。もちろん、書かれている情報にも質が問われます。間違いは論外ですし、本来伝えるべき情報が欠けているようでは読者も喜ばないでしょう。インターネットが普及した現在、パソコン誌以外にも情報を得る手段はたくさんあります。そうすると、雑誌に書かれている情報について、ネットで検証することも可能なのです。

最近のパソコン誌は、当たり前ですが、読者の利益を最優先に考えます。バグや不具合を見つけたら公表します。そうして読者に読んでもらえればこそ部数も増えます。部数の多い雑誌なら、メーカーも喜んで広告を出します。ですから、メーカーの顔色をうかがって、読者に不利益を与えるような雑誌を作ることは、それこそ現在では自殺行為なのです。噂で言われるように「パソコン誌はメーカーの悪口を書けない」ということは、私の知る限り最近ではありません。
もちろん、誹謗中傷はいけません。これこれのバグがあるから、このメーカーはけしからん……という書き方はしません。けしからんかどうかは読者が決めることで、パソコン誌が結論を出すことではないからです。

もう10年ほど前になりますが、有名表計算ソフトのムックを書いているとき、ある機能を繰り返し実行するとメモリがどんどん消費していくというバグを発見したことがありました。どう考えても致命的なバグです。その旨を出版社に伝えると「その件には触れないでください」と言われました。まあ、そのソフト専用のムックでしたし、使用していたのもベータ版でしたから、製品版では改善されることを期待して口を閉ざしました。かなり昔の話です。ちなみにその出版社ですが、今はありません。

マニュアル本ができるまで (その5)
2003/09/24  
著者校が終われば、ライターの仕事も一段落です。ただし、まだ完全に終わったわけではありません。慣れてくると、著者校と同時にやってしまうこともありますが、実は細かい作業がけっこう残っているんです。

step.6 その他の細かい作業
(1)空きスペースを埋める

原稿が、ちょうどページの終わりまで書いてあればいいのですが、そううまくはいきません。原稿を書くときは、1ページ当たりの文量を正確に意識しないからです。書籍は一般的に、節や章で話が完結します。するとどうしても、最後のページに空きスペースができることがあります。
この空きスペースは埋めなければなりませんので、普通はここにコラムを書きます。ところが、コラムに何を書くかで悩む場合もあります。直前のページで話題にした内容と関連したことを書こうと思うのですが、重要なことは本文に書くべきです。そうではなく「ちなみに…」「参考までに…」と、別になくてもいいけど、あると「へぇ〜」と思えるような…まさにトリビア的な話を書かなければなりません。ところが本文の内容によっては、そんなにウマイ話が思いつかないこともあります。さらにコラムの量は、そのページの空きスペース分しかないのです。ほんの数行かもしれませんし、2/3ページ分かもしれません。この量を変えるわけにはいきません。ある意味では、本文を書くよりも完成度の高いコラムを書く方が、はるかに頭を悩ます作業です。ちなみに私は、本文を書いている途中でコラムネタを思いついたとき、その場でコラム用の別テキストファイルに書き出しておきます。1つの章で5個程度のネタがあれば、後になって悩まずに済むものです。

空きスペースとは少し違いますが、章のトビラも書かなければなりません。だいたい章の最初は1ページを使って「第2章 セルの操作」みたいなトビラを用意します。このタイトルだけなら何も問題ありませんが、最近の傾向ではここに「この章で学ぶこと」などを箇条書き、または短い文章として書くケースが多いのです。章が多い本ではかなりの文量になりますし、何より上手くまとめられる章ばかりではありません。概論的な章の場合は、本文に書かれていること自体が"まとめ"的な内容です。その"まとめ"をさらにまとめろと言われても困ってしまいます。結局、本文と同じことを繰り返したり…と、不本意な結果に終わります。逆に、本文の内容が多すぎてまとめきれないこともあります。これもまた文量が決まっているだけに頭を悩ませます。

(2)索引を作る

みなさんは何気なく見ている"索引"ですが、あれを作るのはけっこう大変なんです。索引は、編集部側で作る場合もありますが、ほとんどはライターとの共同作業で作ります。作ります…つったって、一筋縄ではいきません。索引は、○○が××ページに書かれているという情報をまとめたものですが、この××ページというのがライターにはわからないんです。
ライターの手元にあるのはテキストファイル原稿と、校正用のゲラです。ゲラにはページ番号も入っていますが、たいていは章ごとに1ページから始まります。1冊を通したページ番号は、すべての作業が終わらなければ確定しないのです。とはいえ、そこまで待っていては間に合いませんから、とりあえずライターが「これを索引にしたい」という単語や用語をマーカーなどで印します。そのマーキングされた単語や用語を編集者がピックアップして、まとめて、ページ番号を割り振ってくれるのです。編集者が徹夜して割り振ることもありますし、クウォークなどのDTPソフトの中には索引を自動的に作成する機能もあるそうです。いずれにしても、ライターと編集者が協力して作ることになります。

マーカーで印を付けるだけなんて簡単ぢゃん!と侮ってはいけません。たとえば「〜セルを削除するには〜」という本文があったらどうします?「セル」と「削除」をマークしますか?それとも「セルを削除」にマーカーを塗りますか?「セル」と「削除」を分けて索引にすると、「削除」の中には「罫線の削除」「オブジェクトの削除」「グラフ系列の削除」など、さまざまなページ番号が示されます。セルを削除する情報を探したい読者にとって、これは良い索引とは言えません。では「セルを削除」を索引にした場合、ずっと後の章で「〜ただし、セルの削除は〜」という本文が出てきたらどうします?何十ページも前にマークしたのが「セルを削除」だったか「セルの削除」なのか覚えているはずがありません。すると索引の【せ】の欄に「セルを削除」と「セルの削除」が2つ登録されてしまいます。こんな索引もうれしくありませんね。
索引がしっかりしている本は、内容もしっかりしていると言われますが、それは本当です。索引作りは全行程の最後に行われますので、ここを投げやりな仕事で済ませていては、最後のシメがままなりません。ちなみに、索引に書かれているページ番号と実際のページが違っている本を見たら、「あ〜最後で何かトラブったんだなぁ」と思ってください(^^;

(3)「はじめに」を書く

「はじめに」は最後に書きます。一度だけ、目次案と一緒に「はじめに」を出してくれと言われたことがありますが、私の場合それでは困ります。最後に書かせてください。
私は本を買うとき、よく「はじめに」に目を通します。その目的は「この本に何が書かれているか」を知ることではありません。そんなのは目次を見れば分かります。そうではなく「この本はどんな思いで書かれたか」を知りたいのです。「はじめに」には著者の思い入れが詰まっています。「はじめに」から「良い本が書けたので、ぜひ読んでください!」という熱意を感じた本にはハズレがありません。その気持ちは、実際に本を書いてみるとわかります。1冊分の原稿を書き終えて、この本はこんな感じに仕上がったな…とか、今回の本ではここがポイントになったな…など、自分なりの総評を決めなければ「はじめに」は書けないんです。ですから、少なくとも私は「はじめに」を最後に書きます。

(4)「著者略歴」を書く

巻末に掲載する「著者略歴」も書かなければなりません。もっとも略歴はそう変化しませんので、以前のものを使い回しできます。「主な著書」を書くときは、まず同じ出版社の本をあげます。次に最新の本。関連する内容の本、という順番でしょうか…別に決まってませんけど。HPのURLやメールアドレスなどは、出版社によって明記するかどうかのルールがありますのでそれに従います。共著の場合は、内容や文量を打合せした方がいいでしょうね。

(5)契約書を交わす

本来なら執筆を開始する前に交わす出版契約書ですが、すべての作業が終わってからサインすることもあります。作業の前に送られてくればサインをして送り返しますが、なぜか最後になるケースが多いですね。
契約書には印税の割合や、増刷時の取り決め、二次使用のルール、似たような内容の本を他の出版社から出さない、などの内容が書かれています。出版契約書のひな形もありますので、ほとんどの出版社で似たような内容です。ただし、某有名出版社だけは契約書を交わしません。こちらから催促しても作ってくれません。担当者に聞いたら「ウチには契約書がありません」と言われました。この出版社からは、著者校が終わった後で最初に決めた印税率を下げられたことがあります。知り合いのライターにも、あそことは仕事しないという人を何人か知っています。みなさんもお気を付け下さいね(^^;

(6)打ち上げをする

これを忘れてはいけません(^^;
打ち上げはいわば、反省会であり、次回の企画会議でもあります。打ち上げの席で次作の企画が決まることも珍しくありません。よほど忙しい場合を除いて、喜んで参加いたします(^_^)



「マニュアル本ができるまで」ということで長々と書きましたが、とりあえずこれで終わりです。本を書くという仕事は、何か特別なことのように思われますが、やってみるとそうでもありません。特別というなら、どんな業種にも特別な要素がありますしね。最初に本を出したときは、毎日書店に足を運びました。自分の本を見つけてニヤリとしたり、見あたらなくてガッカリしたり、子供を連れて行って見せてやったり…そうした気持ちは今も変わりません。何もないところからカタチのある物を作る作業ですので、クリエイターとしての気持ちも忘れないようにしています。何よりも、田中亨という人間がこの時代に生きていた――という証を残せる仕事に、とても満足しています(^_^)

マニュアル本ができるまで (その4)
2003/09/23  
先日サイトを新しいサーバーに移しました。今度のとこはcgiも自由に使えます。そこで、各ページのビューカウンタを取り付けているんですが、予想に反してこの「ライター的独り言」のページビューが多いです(^^; そういえば以前、知り合いの編集者からいきなり「あのページおもしろいですよね」と言われて、へぇ〜読んでくれるんだあんなページと思った記憶がありますが、作者としてはいささか複雑な思いです。日記のように適当なここより、力を入れて書いたテクニック集などを見ていただきたいのですけどね…(^^;

step.5 著者校する
gooの国語辞典によりますと、校正とは…
(1)印刷で,仮刷りと原稿とを照らし合わせて,文字の誤りを正し,体裁を整えること。
(2)計測機器に表示される値と,それに対応する既知の値(国際標準など)との関係を,特定の条件下で確認する一連の操作。
〔(2)は「較正」とも書く〕
だそうです。マニュアル本の作成に必要なのは、もちろん(1)です。
読者さまに買っていただく本ですから、間違いがあっては困ります。内容的な間違いはもちろん、誤字脱字など初歩的な間違いもできるだけ排除しなければなりません。そこで、ライターが作成した原稿や画像を印刷して、紙の上でもう一度内容を確認する作業が校正です。校正は、編集者が行ったり、関係ない第三者に依頼したりと複数回行います。その中で、著者が行う校正が"著者校"です。"著者校正"の略でしょうね、きっと。

校正に使用する印刷物を"ゲラ"と呼びます。ゲラは、実際の紙面と同じレイアウトですが、A4用紙などに印刷されてきます。1ページを1枚の用紙に印刷するのですから、一般的な300ページ程度の本でもかなりの量になります。通常は宅配便などでやり取りしますけど、時間がないときは編集部からライターへ、ライターから編集部へと人間が運ぶこともあります。はっきり言って重たいです(^^;

ゲラ上で間違いを見つけたとき、それが簡単な誤字脱字程度ならゲラに直接書き込みます。いわゆる"赤入れ"というやつで、普通は赤色のペンで誤りを正します。ただし、同じゲラに何度も校正したり、ライターと第三者が別々に校正したりすると、誰がどこをどう直したかわからなくなりますので、そんなときは別の色も使ったりします。赤を入れたページは「ここを直しました」と明確にするため、ページの端に付箋を貼り付けます。1冊の本を書き終わると、相当な付箋を使い切りますね。ある程度長い文を直すとき、私は新しい文をテキストファイルに作成して「ここに○○.txtを挿入」などと書き込みます。知り合いのライターには、長い文をゲラに細かく書き込む方もいますが、私はダメです。字が汚いので、とても読めたものではありません。それに、書くより打つ方がはるかに速いですし…(^^;
著者校を複数回行う場合もあります。そんなとき、最初の校正を"初校"、2度目を"二校"、3度目を"三校"などと呼びます。校正した結果を確認する意味でも、二校はよくやりますが、三校までいくのは希です。しっかり校正すれば初校で済むはずです。

いつも困るのが"出張校正"です。これは、著者が編集部へ出向いて行う校正のことです。私はできるだけ出張校正をしないようにお断りしています。だって、ものすごく効率が悪いからです。私が書いているのは小説ではありません。技術書です。中には、他の本や過去の雑誌、机の回りのメモ、知人からのメールなども参考にすることもあります。出張校正では、それら参考資料が手元にないため、事実の確認ができなくなります。さらに、先にも書きましたが、少々長い文はテキストファイルで渡します。それにはパソコンを使います。オンラインソフトレビューのAltIMEにも書きましたが、私はこのソフトがないとキーを打てません。エディタも秀丸でなければ困ります。もちろんデフォルトの秀丸ではありません。自作のマクロでカスタマイズした私専用の秀丸です。ファイルの管理もエクスプローラなんぞ使ってられません。各種の機能をキーアサインした私のFileVisorがないとストレスが溜まりまくりです。画像をキャプチャし直すならWinShotViXが必要です。パソコンなら何でもいいという訳にはいかないのです。

話が長くなりましたけど、とにかく出張校正だけはしたくないです。時間がないのでしたら、校正したゲラを直接持っていきます。今まで30冊以上の本を書いてきましたが、出張校正したのは初めて書いたときを除いて3冊だけです。初めてのときは右も左もわかりませんでしから、言われるがままに出向きました。ちなみに、昨年出したExcel2002完全制覇パーフェクトは諸々の事情で出張校正に行きました。いえ、このときは必要性を感じたので私から言い出したのですが……。

ちなみにその日は、NBAのオールスター戦が開催される日でした。昨年(2002年)のオールスターと言えば、ジョーダンが出場する最後の年です。これを逃したら、もうオールスターで活躍するジョーダンを見ることはできないのです。私はシーズン開幕時から、この日のカレンダーに大きく赤丸を付けていました。しかし、出張校正です。スケジュール的にやむを得ないとはいえ、まさに断腸の思いでした。もちろんビデオで留守録を予約しましたが、もし予約ミスがあったらどうしよう…もし不意な停電が起きたらどうしよう…もし泥棒が入ってビデオを盗まれたどうしよう……と、心配の種は尽きません。

確かこの日は、最終電車ギリギリで事務所に戻りました。疲れた身体にむち打って、食事もせずにビデオを再生します。ヨカッタ…無事に録画されていました。ハーフタイムにはジョーダンの引退セレモニーなどもあり、感涙にむせびながら試合を観戦しました。試合も白熱していて、結局OT(延長戦)に突入です。同点のまま攻防が続くOTも残り3秒。このままオールスター史上初の再延長か?と思われた瞬間、ジョーダンのフェイダウェイが決まりました!!
いんやぁ〜〜〜!もう、涙が出てきました(←本当です^^;)
2点リードしたその直後、試合終了1秒前にコービーがファールをもらいます。3本のフリースローのうち2本を決めて、なんと!本当にオールスター史上初の再延長に突入してしまいました。ジョーダンがベンチに下がった再延長は終始Westernのペース。8点差をつけられて、このまま試合終了か?と思われた残り35秒!

ブチっと放送が終了しました…え?あれ?\('0';)/

そうです。番組の予定では放送時間が3時間30分だったのですが、生放送ですし、史上初の再延長ですし、時間内で終わらなかったんで…もちろん番組は続きます。しかし、留守録は続きません…試合時間残り35秒で録画終了です…

すいません、出張校正から話が脱線してしまいました。とにかく、出張校正と聞くとこの試合を思い出します。
さて、いよいよマニュアル本も完成が近づきました。著者校の一部でもありますが、その他の細々とした作業でライターの仕事は終わりです。次回は最終ステップ「step.6 その他の細かい作業」をお送りします。

マニュアル本ができるまで (その3)
2003/09/22  
この話を完結させないと、なかなか他の話を書きづらいので…(^^;

step.4 執筆する
いよいよ執筆活動の始まりです。原稿を書くときに気を付けるのは次のようなポイントです。

(1)"である調"や"ですます調"などの文体
文体を統一するのは基本中の基本です。ところが疲れてくると、ついうっかり混在することがあります。特に、本文は"ですます調"で、キャプションは"である調"というケースです。キャプションとは図の解説文です。よく図の下に「○○を××したところ」などと数行の文が書かれているでしょう。あれをキャプション、または業界用語でエトキと呼びます。このキャプションは数行と短めなので、本文の文体に関係なく"である調"で書くことが多いです。しかし、原稿を書くときはできあがりのレイアウトをイメージしながら、本文とキャプションを同時進行で書いていきます。おわかりですね(^^; 徹夜が続き、意識がもうろうとしてくると、気が付くと本文も"である調"で書いていたりして…ほとんどは脱稿前に気づきますが、これはライターにとって超恥ずかしいミスですね。

(2)読者層に合わせた読みやすさ
その本が、ビギナーを対象にしているのか、それともある程度のスキルを持ったユーザーを対象にしているのかで書き方が変わります。まぁ、これも当たり前のことです。どちらに対して、どういう書き方をするかというと……一応秘密にしておきます(^^;こうした書き分けができることこそ、ライターにとって貴重なスキルになるわけですから。とにかく、書き分けるという点が重要です。そして、読む人に「この本はわかりやすいなぁ」とか「この本は役立つぞ」と思わせれば成功です。

(3)正しい日本語と読みやすい日本語
当たり前の話ばかりですが、これも重要です。どれほど貴重な内容が書かれていても、それが読みにくかったら読者に嫌われます。では、読みやすい内容とは…と考えると、やはり"正しい日本語"に行き着きます。「〜に」と「〜へ」など助詞の使い方や、句読点を打つ場所、比喩表現や受け身表現の使い方や頻度などなど、気を付けた方がいいポイントはたくさんあります。さらに私はいつも"文のリズム"にも注意しています。正確な日本語は大切ですが、正確さにこだわる余り、読みやすい"リズム"を崩してはいけません。本来なら助詞が続いてはいけない場面でも、リズムが良ければあえて続けたりもします。このへんは、小説などをたくさん読むと参考になるでしょう。特に、テンポの速い推理小説などがオススメです。またはポパイやターザンなどの雑誌も役立ちます。本以外にも、スポーツの実況中継や、映画の日本語吹き替えなどでもリズム感が養われます。いずれにしても、常に日本語を意識していると、そのうち意識しなくても書けるようになるでしょう。鍛えるべきは「何か変だな」と感じる感性です。

さて、執筆中に作成するのはテキストだけではありません。紙面に載せる画面も同時にキャプチャしなくてはならないのです。そう、これもライターの仕事です。
いろいろな方法を試してみました。画面は先に撮っておき、画面の流れに合わせてテキストを書いてみたり、まずテキストだけ完成させて、後でまとめてキャプチャしたり。結論として、もっとも効率のよい方法は同時進行であるとわかりました。「[ファイル]メニューの[開く]をクリックします」と書いたら実際にその通りに操作して、ディスプレイに表示されている[ファイルを開く]ダイアログボックスをその場でキャプチャします。これが一番です。どちらかをまとめて行うと、後になって修正するリスクが伴います。この作業が実に非効率的です。なにより精神的にガックリきます。

そうして書いたテキストを推敲して、キャプチャした画像ファイルをチェックしてから編集部にメールします。昔は保存したMOを宅配便などで送ったこともありましたが、最近は数MB程度のメールは珍しくありませんしね。これらの原稿はたいてい「"章ごとに"送ってください」と言われますし、こちらも「はい、そうします」と答えるのですが、なかなか予定通りにはいきません(^^; 〆切間際になって、複数の章をまとめて送ることも珍しくありません…私の場合は。
勘違いされる方が多いのですが、ここで送るのは"テキストファイル"と"画像ファイル"です。文章と図をきれいにレイアウトしたWordの文書ではありません。レイアウトは編集部またはデザイナーさんの仕事です。ライターはテキストと画像という、重要な素材を作成するのが仕事です。

さてさて、原稿と画像をすべて送ると、ライターの仕事も一段落です。まだ終わったわけではありませんが、とりあえず好きなワインでも飲もうかな…という気になります。次回は最終段階の「step.5 著者校する」をお送りします。

WORLD PC EXPO 2003
2003/09/19  
WORLD PC EXPOでExcelのステージをやるようになって4年になります。
今年も今日、無事に終わりました。お越しくださいました多くの皆様、本当にありがとうございます。

最初のステージは2000年でした。東京駅から有明のビッグサイトに向けてタクシーに乗ったことを、昨日のように覚えています。 PC21の誌面で「達人がこっそり紹介する8つのワザ」と告知したものの、はたして何人の方がいらっしゃるかまったくわかりませんでしたが、ふたを開けてみれば、300人を超す方々でステージは盛況のうちに終わりました。特に忘れられないのが、開場を待つ列の先頭に並んでいらした年配のご夫婦です。

控え室のある2階から入場を待つ列を見ていたのですが、先頭に年配のご夫婦がいらっしゃいました。「パソコン人口も幅が出たんだなぁ〜」とのんびり構えていたのですが、ステージに立ったら、その夫婦が一番前の席に陣取り私の登場を待っていてくれました。確かそのときのステージは、開場してすぐの10時開始だったので、私の話を聞きに並んでくださったのかと思うと…正直、涙が出るほどうれしかったです。

さてさて、今日は時間調整に失敗してしまい、急遽その場でグラフネタを紹介しました。講義内容をホームページにアップしてくださったPC21編集部のみなさん、ご迷惑をおかけいたしました…
毎年のことですが、WORLD PC EXPOが終わると"腕自慢"の季節です。そろそろ問題を考えなければなりませんね〜(^_^)
今回もたくさんの応募をお待ちしております。

マニュアル本ができるまで (その2)
2003/09/12  
前回このページを書いてから、何と1年7ヶ月が過ぎてしまいました(^^;;;
理由はたくさんあります。忙しかったからとか、入院してたからとか、長期出張していたからとか…
でも、最大の理由は単純です。言うまでもありませんね(^^;

さて、またぞろ独り言を書こうと思い立ったわけですが、そういえば下の方で次回は「step.3 目次案を作成する」をお送りします。と書いていました。それなら、勝手に話を展開するわけにもいかないでしょうから、まずはその話から完結させましょう。

step.3 目次案を作成する
目次案というのは、いわば設計図のようなものです。目次案を作成することは、要するにその本で何を書くかを決める大切な作業です。
ここではExcel本を例にしてお話ししますが、たとえば初心者向け入門書の場合、どんな機能をどんな順番で解説していくかを考えます。
普通の入門書でしたら、第1章「印刷」というのは少々乱暴でしょう。やはり、第1章「セルとワークシート」、第2章「データの入力」あたりから始まって、第3章「計算してみよう」とか第4章「関数にチャレンジ」のように機能を説明していくのが王道です。しかし、ここで重要なことは他社の類書と同じでは意味がないということです。我々ライターだけでなく、編集者も毎回これで頭を悩ませます。

マニュアル本の出版は、それを趣味で行っているのでなければ、買ってもらうことが最大の目的です。どんな本を出版したって、売れなければ出版社が成り立ちません。では、どんな本が売れるか?それがわかれば苦労しないのですが……(^^;
本を作るには、装丁やページレイアウト、本のタイトルなど多くの要素を考えなければなりません。しかし、売上に直接影響を及ぼす最大の要因は、やはり何が書かれているかではないかと私は考えます。いえ、これはもちろん私がライターだからです。デザイナーの方なら「レイアウトが一番大事」と判断されるかかもしれませんが……。どんなに見やすいレイアウトで、どんなに斬新なタイトルで、どんなに安い本であっても、そこに書かれていることが買うに値しない内容であったら……それでもあなたはレジへ向かいますか?

というわけで、何はともあれ充実した内容が求められるのですが、かといって類書の猿真似では困ります。そこで、売れている類書を多数取り寄せ、どんな内容が書かれているかを検討します。「この本はグラフ機能を詳しく書いているな」とか「ここでピボットテーブルの話をするのは唐突じゃない?」みたく。そして理想は、類書には書かれていないことを、わかりやすく、丁寧に解説するような内容を目指すことになります。

そして、ここがライターの腕の見せ所にもなります。一昔前に流行ったマニュアル本のように、ヘルプやマニュアルに書かれている順番通りに機能を並べても、今の読者は納得してくれません。それなら、本など買わずにヘルプを開けば済む話です。もちろん、ヘルプが悪いと言っているのではありません。ヘルプとマニュアル本では、目的が違うからです。読者にとって、何が一番重要か。何を書けば読者に役立つか。そうした観点で目次を作らなければ良い本などできません。しかし、それでは何が本当に役立つ情報かは、実際にExcelを操作した者でなければ決してわかりません。ワークシートを印刷したら文字が途切れてしまった。なぜだろうと原因を調べ、そしてどうしたら途切れなくなるかという解決策を知っていれば「印刷時にはこういうことが起こる。そのときはこう対処しよう」と教えてあげることができるのです。そして、このトラブルに数多く遭遇した経験があればこそ「これはよく起こる」→「多くのユーザーが悩んでいるはず」→「読者に有用な情報」と判断できるのです。このように、読者が本当に望んでいる情報は、決してヘルプを見ただけではわかりません。実際にExcelを使いこなしている者でなければ理解できるはずがないでしょう。そうです。事件は現場で起きているのです。

話が脱線しましたが、要するにライターがどれほどExcelを使っているか、精通しているかが良い目次案を作るカギになるのです。これはTIPS集的な本でも同じことです。どんなに珍しいテクニックでも「そんなことする奴いねぇよ」では困ります。要するに、どれだけ読者の身になって考えられるかが、良い目次案を作るポイントになるわけです。

ちなみに、作成する目次案は「章見出し」と「節見出し」あたりまでが一般的です。次のような感じですね。

第1章 ○○を××する
  1-1 ○○とは
  1-2 ××する
第2章 △△機能を極める
  2-1 △△のメリット
  2-2 こんなケースでは

こうして目次案を作成して編集者に送ります。必要なら、サンプルのブックや、ラフな画像を添えます。
さて、目次案の内容にOKが出たら、スケジュールを決めて、いよいよ執筆の開始です。次回は「step.4 執筆する」をお送りします。(できれば近日中に…(^^;)

マニュアル本ができるまで (その1)
2002/02/09  
むむぅ…忙しいです… 〜 (/_;)/
例年ですと、表計算大会の審査が終った後、その反動でしばらく休むのですが、今年はそんな余裕がありません。あまり詳しくは書けませんが、マニュアル本の執筆などが鬼のように入っています。現在進行中が2冊ありまして、1冊はすでに〆切を大幅に過ぎています。本当は、こんなもん書いてるヒマはありません…もう1冊の300ページ超は今月いっぱいです。全13章のうち2章までしか終わっていません。今月の終わりから来月にかけて別のVBAの本を速攻で書いて、3月いっぱいであと2冊のVB本を書きます。また、来月になると、おそらくVBA本の新しい企画が動き始めますので、中頃からは執筆を始めることになるでしょう…4月は関数の本と、VBAの本と、まだ詳細が決まっていない本の計3冊が始まります。もちろんその間に、連載を含めた諸々パソコン誌の原稿と、PC-Gaz!などWebのコンテンツと、あ!今月の後半にはVBのシステム開発もやらなければなりません…むむぅ…不景気なご時世ですから、仕事があることに感謝せねばなりませんね…

さてさて、現在何冊かのマニュアル本を書いていますが、マニュアル本が世に出るまでの舞台裏をご紹介しましょう。もちろん、私のケースです。これがすべてではありませんから、そのへんはよろしく。

step.1 企画がスタートする
当たり前ですが、出版社から「書いてください」と言われ、こちらが「書きます」と意思表示することから始まります。この「書いてください」の話ですが、私の場合は大きく2パターンあります。1つはメールでいきなり「はじめまして、私は○○出版の××です。突然ですが執筆していただけませんか」みたいなオファーや、「ご無沙汰してます、また執筆をお願いしたいのですが」みたいな話です。2つ目は、執筆中に次の企画が決まるパターンです。これもよくある話ですね。

昔、廃刊直前の「ざべ」に『テクニカルライター養成講座』みたいな連載がありました。著者の方は私もよく存じ上げている有名なライターさんでした。すいません、今お名前をど忘れしています…(^^; その中で、ライターは「営業活動をしているようではダメ」という一説がありました。確かに、私もこの仕事を始めて以来、営業活動らしきものは1度しかしたことがありません。その1度も、知人のライターに付き合って、某編集部に「よろしくお願いします」みたいな挨拶にうかがっただけです。もともと営業肌の人間ですから、本来は飛び込み営業とか大好きなんですよ、私。ですが、正直「営業活動してるヒマがない」のが実状です。

いずれにしましても、「書きます」の意思表示の後で、「それでは打ち合わせをしましょう」ということになります。

step.2 企画の打ち合わせをする
ほとんどの場合、打ち合わせは編集部におじゃまします。理由は簡単です。私の事務所は、とても来客をお招きするようなスペースも快適さもないからです。ここは、事務所とは名ばかりの"作業場"あるいは"隠れ家"ですから…
最初の打ち合わせでは次のようなことを決めます。
(1) 内容やコンセプト。想定する読者層や本のレベル、大まかなレイアウトやデザインなど
(2) 発行部数や価格、CD-ROMの有無、Webとの連動など
(3) 印税率や支払いの条件など
(4) 次の企画があればその話など
すでにお付き合いのある出版社の場合は、支払いの話が割愛されることもあります。もちろん、もっとも重要な話は(1)です。特に「コンセプト」は、本の売れ行きだけでなく、私のモチベーションにも大きく影響します。ホントはそんなワガママ言ってちゃいけないんですけどね…(^^;
で、たいていの場合は「では、目次案を作ってください」という話になります。そう、書籍はまず「目次」を決めることから作業が始まるのです。完成した目次案を社内の企画会議にかけてから正式にGOサインが出るケースもあります。そして、この「目次案の作成」が、ライターの最初の仕事なります。料理で言えば"下ごしらえ"、陶芸で言えば土を練る作業に匹敵します。あ、いや、陶芸はやったことがありませんが…とにかく、目次案を失敗するとロクな本になりません。これは事実です。お持ちのマニュアル本を開いて、今一度目次をご覧下さい。きっと良い本の目次は輝いているはずです。何か訴えかけるもがあるはずです。気持ちがこもっているはずです。

次回は「step.3 目次案を作成する」をお送りします。

表計算腕自慢大会2002 (審査後記)
2002/01/26  
今年は昨年の7,000件より少なかったのですが、それでも6,000件弱の作品をすべて審査しました。いやはや、毎年のこととはいえ、超疲れました…(^^;

審査中に感じた点をいくつかお伝えしましょう。と言っても作品の内容的なことではありません。「審査員を困らせる作品」についてです。

1.でかいファイル
表計算大会では、計算式はもちろん、表のレイアウトも自由に設計してOKです。
「10人分の計算をしてください」という問題であっても「いやいや、10人では少ないだろう…100人まで対応できるようにしておこう」とか、「1ヶ月分の計算をしてください」という問題に対して「むむ?1ヶ月分だけでは使いにくいだろう。ここはひとつ10年分のシートを作っておこう」などなど…もしそれが応募者の意図であれば、どれほど巨大なファイルであっても、それは立派な応募作品です。もちろん"ファイルがでかい"など文句を言うはずもありません。

そうではなく、意味なく"でかい"ワークシートには困ってしまいます。
Excelでは「ワークシート中で使用されている領域」という概念があります。たとえば、セル範囲A1:C10だけにデータ(あるいは計算式)が入力されているワークシートでは、A列〜C列の3列×10行=30個のセルが使用されているとExcelが認識します。では、このワークシートのセルD20に何かデータを入力したとしましょう。このワークシートで使用されているセル数はいくつだと思いますか?30個+1個=31個ではありません。入力されているデータのうち最も左上のセル(ここではセルA1)と、ワークシート上で使用されている最も右下のセル(ここではセルD20)を対角線とする四角の範囲が使用されていることになるのです。したがって、Excel内部で認識される「使用されているセル数」は、A列〜D列の4列×20=80個となります。わすか1つのセルにデータを追加しただけで50個ものセルが使用中と認識されてしまうのです。
この「最も右下のセル」を終端セルと呼びます。Ctrlキーを押しながらEndキーを押すとアクティブセルが終端セルに移動しますので、お使いのワークシートでご確認ください。

困ったことに、Excelでは終端セルを誤って認識されることがあります。たとえば、セル範囲A1:C10にデータを入力します。終端セルはセルC10ですね。Ctrl+Endを押すとアクティブセルはC10にジャンプします。ではここで、C列全体を削除してみましょう。ワークシート上に残されたデータはセル範囲A1:B10です。C列は削除してしまったので何もデータが入力されていません。この状態でCtrl+Endを押すと、やはりアクティブセルはセルC10に飛んでしまうのです。そう、Excelでは、そのブックを保存しない限り終端セルの情報が更新されないのです。

…と、ここまではExcelの仕様です。ところが、厄介なことにExcelは終端セルの更新を忘れるという不具合を持っています。何度も何度も、広い範囲に入力&削除を繰り返すと、いくらファイルを保存し直しても適正な終端セルを認識せず、いまやデータが入力されていない遙か遠くのセルを終端セルと思いこむことがあるのです。こうなると、Excelが誤認識している(実際は空の)行や列を自分で削除しない限り終端セルが戻りません。応募作品の中には、このようなブックが少なからずあります。

ではなぜ、こうしたワークシートが審査に支障をきたすのでしょう?実は、私が行う第一次審査では、ブックを開くと同時に使用されているすべての計算式をテキストファイルに抽出しているからです。For EarchでUsedRangeを調べ、HasFormulaプロパティがTrueの場合にFormulaプロパティを抽出します。実際にはもっといろんな情報を調べますが、まぁこんな具合です。したがって、Excelで「ワークシート中の使用領域」を表すUsedRangeが異常に大きいと、抽出に数分から数十分の時間を要する場合があります。数百個のセル数なら一瞬で終わります。数千個になると1分〜3分程度待たされるでしょうか…これが数万個になると「はぁ〜またかよ…」と悪態をつきながらコーヒーをいれに席を離れます。

もちろん、応募作品が意味なくでかいワークシートだったとしても、応募作品としては有効です。他の作品と何ら変わることなく審査を行います。ですが、審査員だって人間です。「はぁ〜あ…」とか「おいおい!」とか感じる作品には、多少の感情変化が起こったとしても無理はありません。ちなみに今回の応募作品には、ワークシートのセルIV65536に署名している作品がありました。このワークシートのUsedRange.Countは16,777,216個です。その署名が作品にとって必要ならまだしも、見つかりにくい場所にこっそり署名を残したのだとしたら何とも迷惑な話です。そんなもんスクロールバーの大きさを見ればすぐにバレてしまいます。私だったら、もっと見つかりにくい場所に署名を隠すでしょうね。いろいろ考えられます。ユーザー定義の名前とか、ユーザー設定のビューとか、ユーザー設定リストとか、あるいは昔流行った"列幅による暗号"とかね。

でかいワークシートが審査上不利になるという話ではありません。でかいワークシートは受け付けないという話でもありません。いいんです。どうぞご自由にワークシートを作ってください。ただ、徹夜で頭がもうろうとしている審査員が、少しだけ不快な思いをするだけです。

2.パスワード付き保護
表計算大会2002の問題は日経PC21の2月号で発表されました。この号の94ページには応募要領が載っています。その中に
>ブック(ファイル)やシートに「パスワード」を設定するのは避けてください。
>適正な審査ができなくなる恐れがあります。

と明記しています。しかし、それでも「パスワード付きの保護」をしてくる作品が後を絶ちません。まったく理解に苦しみます。(^^;

まず、なぜ「パスワード付き保護」が審査に支障をきたすのかお教えしましょう。他人が作ったワークシートを調べるというのは、かなり大変な作業です。そもそも、どのセルがどこを参照しているのかすらわかりません。そんなとき役に立つのが「ワークシート分析」機能です。参照元あるいは参照先にトレース矢印が引かれるこの機能は審査に欠かせない秘密兵器なんです。ところが、保護されたワークシートではこの「ワークシート分析」が使えません。他にも、保護されたワークシートではいくつかの機能が使えなくなります。これでは審査にならないんです。そこで、現在の審査システムでは、ブックを開くと同時に強制的に保護を解除しています。もうおわかりですね?パスワード付き保護を設定したブックでは、マクロで保護を自動解除しようとしても「パスワードを入力してください」というダイアログボックスが表示されるだけで審査システム自体がストップしてしまうんです。

個人的な感想ですが、そもそも応募作品に保護を設定する気持ちがわかりません。保護する方々の意見はおおむね次の2つです。
(1)誤操作によって計算式が削除されるのを防ぐ
(2)Tabキーで入力エリアを移動できる

なるほど、それはよくわかります。ですが、思い出してください。あなたが作っているのは「審査されるための応募作品」なんです。「パソコンってよくわかんないんですぅ〜」という新人オペレータに渡すブックではないんです。ブックの完成度を高める気持ちは理解できますが、審査員はあえて計算式を削除してどこがエラーになるかを調べることもあるんです。

「保護のパスワードは応募票のコメント欄に明記しています」という応募者もいらっしゃいます。申し訳ないのですが、ブックの審査中には応募票を開きません。たとえば100件の審査を終えたあとで、100件分のコメントをまとめて読む…というやり方もします。パスワードを明記すればいいのではなく、パスワードを付けてはいけないんです。いずれにしましても、応募要領ではっきり「パスワード付き保護はダメ」と書いてあるのですから、これは表計算大会のルールです。ルールの是非はともかく、出題側が決めたルールなんです。「○○について400字以内で書きなさい」という問題に800字の小論文を書くようなものです。

3.応募票の書き方
これはどちらかというと"お願い"です。応募票の書き方について、あまり詳細に規定するのもどうかと思いますので公式に明言しませんが、できたらこうして欲しい…ということです。以下に応募票のサンプルをお見せします。

氏名:田中亨[*1]
ふりがな:たなかとおる
[*2]
電話番号:045-333-****
[*3]
郵便番号:240-****
[*4]
住所:横浜市保土ヶ谷区○○町××
[*5]
年齢:38
[*6]
性別:男
[*7]
職業:会社員
[*8]
業種:
[*9]
職種:経理
電子メールアドレス:toru.tanaka@officetanaka.com
[*10]
使用ソフト:Excel 2002
[*11]
コメント:INDEX関数とVLOOKUP関数で解きました。
人数の制限が不明だったので、最高10人まで対応できるように作りました。
[*12]

[*1]
すべての項目に言えることですが、項目名は正しく書いてください。「氏名:」を「名前:」などと変更しないでください。また、他項目の先頭と合わせるために
氏名:      田中亨
ふりがな:たなかとおる
のような書き方は避けてください。くれぐれもタブを入れないようにしてください。
[*2]
ふりがなは、ひらがなでもカタカナでもかまいません。ただし、カタカナでふりがなを記入する場合でも、項目名は「ふりがな:」とひらがなで書いてください。
[*3]
市外局番などの区切りは「-」(半角のハイフン)でお願いします。045(333)****はなるべく避けてください。また、携帯電話の番号でもかまいませんが、その際にも090-1234-5678のように3桁-4桁-4桁とハイフンで区切っていただくとうれしいです。
[*4]
電話番号と同じですね。3桁-4桁とハイフンで区切ってください。7桁の郵便番号がわからない方は3桁でもけっこうですが、できたらご自分で調べて7桁郵便番号を書いてくれるとうれしいです。
[*5]
「マンション」や「ハイツ」などのカタカナは全角でお願いします。「2-14-24」などの数字と記号は半角でお願いします。
[*6]
項目名の「年齢:」を「年令:」と書く人がいます。ご注意ください。数字は半角でお願いします。「歳」や「才」は書かなくてけっこうです。毎年数件あるのが、
年齢:38(ただし今年の5月で39になります)
みたいなコメント付き(^^; コメントはコメント欄にお願いします。
[*7]
できればシンプルにお願いします。「たぶん男」「MAN」「MALE」「♂」などは避けてください。
[*8]
ここもコメントが多いです。
職業:会社員(今年の夏には独立する予定です)
みたいな。(^^; コメントはコメント欄にお願いします。
[*9]
わからない項目や該当しない項目は未記入でけっこうです。ただし、項目名だけは書いてください。
[*10]
応募作品をメール送っているのに「ありません」という方がいます。悩んでしまいます。このメールアドレスは連絡用という目的以外にも、応募者の重複をチェックするためにも使います。ですから
電子メールアドレス:aaa@bbb.com(個人用) www@bbb.com(仕事用)
のように複数のアドレスを書いていただく必要はありません。また、メールで応募したんだからメールを見れば送信元アドレスがわかるだろ…という意地悪は言わないでください。お願いします。
[*11]
実は、ここで書いていただきたい「使用ソフト」とは、応募作品を作ったソフトなんです。「使用ソフト」という項目名がいけないのですね。来年からは別の項目名に変更しようと思います。
使用ソフト:Windows Me、Outlook Expressなど
という方をよく見かけます。
ソフトのメーカー名は必要ありません。「Microsoft Excel」ではなく「Excel 2000」などとお願いします。できれば「エクセル」ではなく「Excel」の方がうれしいですね。「Ecel」や「Xcel」などのスペルミスにもご注意ください。
[*12]
自由に書いていただいてけっこうなんですが、
コメント:INDEX関数とVLOOKUP関数で解きました。
            人数の制限が不明だったので、最高10人まで対応できるように作りました。
みたく行頭を揃えるより、
コメント:INDEX関数とVLOOKUP関数で解きました。
人数の制限が不明だったので、最高10人まで対応できるように作りました。
のようにベタで書いてくれた方が読みやすいです。

うるさいことを言いましたが、これは「必ずこうしてください」ではなく「こう書いてくれるとうれしい」というお願いです。ちなみに、応募票は1つずつ開いて読むのではなく、審査システムで自動的に読みとってデータベース化しています。
ずいぶん長く書いてしまいました…(^^;;

表計算腕自慢大会2002 (その2)
2001/01/26  
いよいよ始まりました。表計算大会2002。
日経PC21の2月号(12月23日発売)に問題が掲載されていますので、ご覧になった方も多いことでしょう。とりあえず150件ほどを審査しましたが、編集部にはすでに2000件ほどの応募作品が届いているそうです。まだ応募〆切まで日にちがありますので、ここではあまり内部事情をお話しできません…〆切が過ぎたら…こっそり…(^^;
PC21の表計算大会2002についてはこちらをご覧下さい。

今回は初めての試みとして「文章問題」を出しました。今までは、サンプルの表を見せて「この表を完成させてください」という問題ばかりでした。文章問題では、作成する表の条件だけを文章で示し、表のデザインから腕を振るっていただこうという主旨です。

どんな表を作るか…どこにタイトルを入力して、どこに罫線を引くかなどが明らかになっていれば作るのも簡単です。考えるべきは、計算式や書式、さらにエラー処理などでしょう。ところが文章問題では、そもそも「どんな表を作るか」から考えなければなりません。150件の中にもさまざまな表があり、みなさん工夫されている様子が感じられます。

う〜む…ついヒントを書いてしまいそうになるので、このへんで止めておきます。(^^;
〆切は1月の16日です。ふるって応募してください!豪華賞品に加えて"達人"の称号があなたを待っています。

雑誌の内容に間違いはない?
2001/12/22  
パソコン誌の話をもうひとつ。

あなたは、雑誌に書かれていることがすべて正しいとお思いですか?「雑誌にだって間違いはある」という方もいますし「雑誌に書かれているんだから正しい」と感じる方もいらっしゃるでしょう。正解はもちろん、間違ったことが書かれていることもある!です。ただし、できるだけ正確で間違いのない情報を掲載しようと努力していることは事実です。間違いを書いてしまうのは、その努力がほんの少し足りなかったからです。

先日、日経ネットナビさんでIE6.0とOE6.0の特集記事を書きました。私は主に新しくなったセキュリティについて書いたんですが、その中で「P3P」という規格について解説することになりました。

P3PとはIE6.0で追加された規格で、簡単に言うと、怪しいサイトにはクッキーの送受信をさせないという技術です。サイト側に「私たちは、あなたの個人情報をこのように使います」と明言させたり、広告配信サイトなどが秘密裏にあなたのアクセスを記録しようとするのを防ぐ働きがあります。この規格や技術的な内容を読者に伝えるわけですが、なにせ新しい規格ですので詳細がわかりません。わからなければ記事にできません……

そこで取材です。まずMicrosoftに電話しました。詳しく教えてくれと。答えは「よくわかりません」です(^^; いや、別にMicrosoftを責めているのではありません。そんなことは日常茶飯事です。電話の先は一般の問い合わせデスクなのですから、わからないことがあっても不思議ではありません。結局msnに行って直接話を聞くことにしました。

msnの担当者は親切に解説してくれました。ところが、私たちが知りたいことを具体的に聞くと、やはり言葉を濁します。どうやら、本国からの情報がうまく伝わっていないようなのです。数ページのメモをとって部屋を後にしました。しかし、これだけでは疑問が残ります。疑問を残したまま記事にすることはできません……

次はBiglobeに取材を申し込みました。Biglobeは国内でいち早くP3Pに完全対応したサイトです。実は、msnよりも早く対応していました。会議室で数名の担当者から詳細に解説していただきました。P3Pについて何とか理解はできてきたものの、今度はこれを読者がわかりやすい内容にまとめなければなりません。

結局、数件の取材と数日の徹夜を経て記事が完成しました。わずか1ページの記事です。みなさんはパソコン雑誌を購入して、パラパラとページをめくるのでしょうが、そのたった1ページの記事を作るのに、こうした労力と時間がかかってるんです。もちろん、それが私の仕事なのですから、労をねぎらって欲しいなどとは思いません。ただね……ページの裏側ではそんなことが行われているんだなぁ〜と感じてくれたら、またパソコン雑誌を読むのも楽しくなるのではないかなと(^^;

もうひとつだけ似たようなエピソードを。

数年前になりますが、Excelのムックを書いたときのことです。Excelではワークシート上で「Shift+スペース」を押すと「行の選択」になります。「Ctrl+スペース」では「列の選択」です。私は原稿の中で「〜この機能はIMEをオンにしていても実行できる」と書きました。事実私の環境ではできたからです。すると編集者から「どんなIMEでもできるんでしょうか?」という質問。なるほど、IMEは世の中にたくさんあるわけです。「IMEをオンにしていても実行できる」と書く以上、確認しなければなりません。

私がふだん使っているATOKはすぐに確認できます。MicrosoftのOfficeに付属しているMS-IMEも確認できました。他にも、当時は、VJE-βとか松茸とかWXPとかいろんなIMEがありました。あ、いや、今もあるのかもしれません……(^^; あまり知られていないワープロソフトですが、オリジナルのIMEが付属しているものもありました。秋葉原に行って、入手できる範囲でIMEを購入し、自宅のパソコンにインストールしていきます。

結果は、すべてのIMEで問題なく機能しました。時間的にも金銭的にもかなりの負担がかかった結果、わすか1行の「〜この機能はIMEをオンにしていても実行できる」という原稿が通りました。いやはや、間違いのないことを書くというのは大変です。

売れるパソコン誌の条件
2001/12/08  
いろんなパソコン誌に書かせていただいていますが、最近は編集部を見ただけで雑誌の売れ具合が何となくわかるようになりました。というか、売れている雑誌の編集部と、そうでない雑誌の編集部では、明らかに空気が違うんです。雰囲気というか、印象というか……

たとえば、現在売上部数でトップを争う某パソコン誌編集部では、打ち合わせにも相当の熱が入ります。コンセプトは何か?題材は?どんなことを書くのか?その見せ方は?などなど、さまざまな意見が飛び交います。しかし、どんな発言や意見であっても、その根底には「読者が何を望んでいるか」を忘れていません。編集部も、外部ライターも、イラストレータも、デザイナーも、カメラマンも、読者が望む誌面を作ろうと努力しています。

当たり前だと思いますか?しかし、そうでない編集部もあるんですよ。読者のために誌面を作るのではなく、自分たちが書きたいから作るというスタンスの編集部も。結果は明かです。読者もバカではありませんからね。そんな雑誌は立ち読みしても買おうとは思いません。もちろん「自分たち」と読者の感性が一致していれば問題ありません。しかしねえ、そんなにうまくはいきませんって。読者つったって1人じゃないんです。数万人もいる読者の感性を完全に掌握しようなんて無理に決まっています。自分が知りたいのだから、読者だって知りたいだろうなんて、思い上がりも甚だしいです。だからこそ、何をするにせよ「読者はどう思うかな」と立ち止まって考えることが必要なんです。それができる雑誌は売れて、できない雑誌は売れません。簡単で明瞭な理屈です。

書店の棚を覆い尽くすパソコン誌。その出来映えを審査するのは読者です。

表計算腕自慢大会2002
2001/12/01
ホームページを作るとき、日記だけはゼッタイにやりたくなかったです。だって、パーソナルなホームページで、何がつまらないって日記ほど退屈なページはないと思っていたから。別にあなたが今日ナニを食べて、ナニに感動したのかって、そんなものを読みたいとはこれっぽっちも思いませんって。じゃあ、なんで日記みたいなページを作ったのかと言うと、ただ何となくです。気まぐれです。思いつきです……だから、突然やめてしまうかもしれませんので、あらかじめご容赦ください。
さてさて、12月というと毎年恒例の仕事があります。表計算大会の問題作成です。表計算大会というのは、日経BP社のPC21というパソコン誌でやってる企画でして、誌面で出題したお題をExcelなどの表計算ソフトで作成し応募してくださいっていうコンテストです。ご存じない方はPC21のホームページをご覧ください。→こちら

私は第1回から審査員を勤めているのですが、これがハンパじゃなく大変な作業です。ちなみに前回の応募作品は7,000件を越えました。これら全ての作品を約100件程度に絞り込む第一次審査も私の仕事です。7,000ですよ、7,000!仮に1作品の審査を15分かけたとすると、全部見終わるのに1,750時間かかります。1日に20時間働いても87.5日かかります。ところが、私に許された審査期間はわずか1ヶ月 程度。定員が5人の乗用車に20人くらい乗せるようなものです。
まあ無理だと泣いても許してくれませんので、そこは強引に、無理矢理、常識を越えて、何とかするしかないんですが……

先日の打ち合わせで今年の問題が決まりました。今回はちょこっとだけ雰囲気を変えて、例年とは違う形式の問題も出してみました。さらに、正式にはあらためて誌面で公表されるでしょうが、今年からWebを使った企画も考えています。応募されるみなさま、どうぞお楽しみに。
なお、私が表計算大会の審査員と知り、賄賂を送って審査を甘くしてもらおうなどとは思わないでくださいね。公明正大に厳選かつ公正な審査を心がけていますから。でも、大好きなワインなどいただいたら……たぶんその方の名前は忘れないと思いますけど……ちなみにブルゴーニュの赤が好きです……あ、いや独り言です…… (^^;