Try IT系ライター

IT系ライターやってみたい人

 IT系のライターを目指す人、もしくはコンピューター書籍などを書いてみたいと思っている人向けに書いてみました。コンピューターと言っても今や幅広く使われており、情報 (IT) 関連は一分野に過ぎません。さらに、私が経験しているのは、その中でもさらに限られたWebプログラミング関係です。このため、IT系でも毛色が違う分野では全く違うかもしれません。参考がてらに読んでもらえばよいかと思います。
(2007年7月19日に文章などを一部追加してあります)

何が必要か

 ここでは、物理的な環境で必要になるものと、精神的に必要なものに分けて見てみましょう。まず、IT系となると、さすがにインターネットに接続できる環境がないと話になりません。また、2006年7月時点では携帯電話では、PDFの校正などができないのでパソコンが必須になります。また、雑誌の場合はPDFでの校正、書籍の場合には紙での校正になります。このため、書籍の場合ではA3×2くらいの机や床の領域が必要になります。
(2007年7月現在の状況では、すでに書籍もPDF校正となっており紙で校正する方が珍しいと思われます。このため、大きな領域を表示するための液晶ディスプレイを乗せるための広い机が必要になります。と言っても私の場合19inchモニタで処理しているので、必ずしもバカでかいディスプレイを用意する必要はないかもしれません。)
 パソコンはWindowsでもMacintoshでもUNIXでも構いません。Web関連であれば単一機種よりも幅広い動作環境を整えておく方がよいでしょう。
(2007年7月現在では、iPhoneが発売されWindows版のSafari 3βも登場しています。本当は、一通り揃えれば良いのでしょうけど、それが駄目な場合はMacintoshを購入し、その上で動作するエミュレータを購入するか動作させると場所を取りません。また、Windowsマシンは投げ売りかと思われるほど低価格になっているものもあるので、Windows×1台にWindowsとUNIX、残りをMac Bookという手もあります。)

 ハード的なもの以外にソフトウェアも必要になります。エディタは標準のものでも好みのものでも問題ありません。ただし、文字コードが変換できる、いろいろな文字コードが処理できるエディタがよいでしょう。エディタ以外で必須なのはAdobe Reade (旧名称:Adobe Acrobat) です。特に雑誌系での校正は全てAcrobatで行われますので、持っていないと校正自体不可能な状態になります。また、マイクロソフトワードとエクセルも必要になる編集部があります(MdN関連書籍など)。これはワードで整形しDTPへと渡すワークフローになっているためです。

 物理的な(ハード/ソフト)で最低限必要なものは書きました。最悪はマンガ喫茶でもどうにかなりますが、物理的なハードルよりも精神的なハードルの方が高いかもしれません。IT系といっても最先端技術を紹介する雑誌系のものと私がよくやっているリファレンス系では全く違っています。文章表現力があり、新しいものが好きであきっぽい人は最新技術を追う雑誌系の方がよいでしょう。ネタ切れにならない限りは大丈夫です。

 これとは対照的に地道な努力ができる人は、文章力も特段必要にならない(=買う気を起こさせる文章とか)リファレンス系/サンプル系に向いているでしょう。サンプル系の書籍や雑誌は数多くあるので最初に狙うならば、サンプル系が楽でよいと思います。

 かなり地道な努力ができ、長期間忍耐強くできる人であれば翻訳という方法もあります。これは米国で発売された書籍を日本語に翻訳するというものです。一旦機械翻訳に通してから、おかしな部分を修正します。普通に日本語で分かりやすいように書き直すとコスト割れ(赤字)になってしまうことがあるので、一定の品質であれば問題ないでしょう。(ただ、機械翻訳で実際に買ってみて使い物にならないのがほとんどです。駄目だったのはLogo Vista、Atlas、コリャ英和。翻訳に関しては翻訳ソフトの評価のページを参考にすると良いでしょう。)

専業でやるべきか、副業でやるべきか

 IT系ライター専業というのは実際怖い面もあります。これはIT系に限りませんが、常に仕事が来るとは限らない、という点です。仕事が来なければ一般の会社でもつぶれますから条件は似たり寄ったりかもしれません。

 実際の所、書籍を書いたらどのくらいの収入があるのでしょうか。ここでは多く出回っているサンプル系の書籍で一般的な価格と印税で計算してみましょう。まず、書籍の価格は2480円、印税率は7%とします。印税率は出版社によって異なりますが最高でも10%、共著などで少なければ1%か、それ未満ということもあります。

 価格が2480円で印税率が7%、あとは刷部数が大問題です。コンピューター系の場合、思ったよりも部数が少なく3000部〜5000部の範囲だと思ってよいでしょう。ここでは3500部と5000部の場合を計算してみます。すると以下のような金額になります。

2480円×0.07×3500部 = 607,600円
2480円×0.07×5000部 = 868,000円

増刷があれば収入は増えます。しかし、増刷はあまり期待しない方がいいでしょう。つまり一般的には60万円ほどしか収入がないことになります。1ヶ月で書けば十分な収入にはなるかもしれませんが、2ヶ月、3ヶ月かかれば、かなり少ない収入となってしまいます。あと交渉次第では印税率がアップできる場合もあります。
 印税率は初刷と第二刷(増刷があった、ということ)では異なる出版社が多くなっています。初刷は7%で増刷があれば10%というパターンが最近は多く見られます。

 では書籍ではなく雑誌の場合は、どうなのでしょうか。雑誌の場合はページ単価が決められています。安いところは安いのですが、平均的には1万円ほどです。ページ単価は書籍に比べると格段に高いのですが、雑誌の場合割り当てられているページ数が限られています。連載などを持っても4ページあればラッキーな方でしょう。となると単純計算で以下のような金額になります。

1万円×4ページ = 4万円

 これを12ヶ月繰り返しても48万円ほどです。これならば無理矢理1〜2ヶ月で書籍を書き上げる方が効率が良いことになります。また、雑誌の場合は発売日が決まっている都合上、締め切りは厳守です。これに対して書籍の場合は無限に延びます(!?)

 これらの状況からすると専業よりも副業として選択し、雑誌でなく書籍のIT系ライターの方がメリットが大きいことになります。サラリーマンであれば印税はボーナスのようなものと言えるでしょう。
 IT系ライターの場合、ちょっと違ったパターンもあります。それは編集部内で原稿を書くというものです。この場合は社員になるので印税よりもボーナスで支給されることになるようです(会社によって若干違うと思われます)。
(2007年7月現在では紙メディアだけでなくWebメディアに原稿を書いても十分稼ぐ事ができる状況になりつつあります(出版社による)。Webの場合、紙メディアと異なり制約が少ないのが大きな利点です。また、後で修正できるのもメリットとして上げることができます。現在、ちょっとWebメディアにも書き始めましたが、書籍や雑誌よりも利益率がかなり高いと言えます。ページ単価が半分になっても、紙メディアと比べると十分いける雰囲気になっています。ただし、書籍と異なり増刷による印税収入のメリットがありませんので、この点には注意しないといけません。どちらかと言えば雑誌系ライター向きと言えます)

自分一人で書けない場合は(共著/監修)

 執筆する本の内容全てを自分一人では書けない場合もあります。多くの技術を複数解説するようなパターンの本です。特定の技術に関してはよく知っているが、他の技術が分からない場合、またはページ数的に不足してしまう、時間的余裕がない場合には「共著」という方法があります。これは何人かが協同で1冊の本を執筆するというものです。2人以上であれば全て共著になります。書籍で監修〜〜とついているものもありますが、監修の場合は共著のライターのとりまとめ役と内容チェックなどが主な仕事になります。編集者とのやりとりも監修者が窓口となって行うこともあります。
 共著の場合は明確に役割分担をしておきましょう。これは章(内容)ごと分けてしまえば楽です。また、その方が効率的に本が仕上がります。
 共著の場合は印税配分が異なります。この印税配分に関しては協議の上で決定されます。単純に頭割りということもありますしページ数割り(これは多い)、あとは様々な事情を加味して配分率が決まります。場合によっては1%という事もありますが、共著なのである程度は仕方ないでしょう。
 共著はメリットもありますが、実際に何度もやってみると思わぬ問題もあります。実際にあったパターンとしては、相手が病気になって入院してしまうというものです。この場合は相手が退院するまで待つか、もしくは企画自体をあきらめる=消滅になります(どちらのパターンも経験した)。入院が長引きそうだ、企画が駄目になりそうだ、と踏んだら企画自体をなかった事にして次に取りかかるのが良いでしょう。他の出版社に少し企画を変えて持ち込むのも1つの方法です。それでも駄目な場合にはWebを利用します。原稿をWeb上で公開し、Google AdSenseなどの広告を貼付けておけばよいでしょう。この時にAdSenseであれば広告の枠を取ってリンク文字を青色にして本文中に埋め込んでおけば十分です。

出版社に売り込まなければならないか

 1996年以前、インターネットが普及する以前と以後では大きく変わっています。IT系ライターの場合、編集者は最初に書ける人を探すためGoogleやYahooなどで検索します。つまり、出版社に売り込みにいく必要性は高いわけではありません。これは地方在住者にとっては大きなメリットです。というのも例えば北海道に住んでいて、東京の出版社に売り込みに行かなければならないとなると大変な出費になってしまいます。インターネット上にWebサイトを作っておけば編集者が探しに来てくれるわけです。この場合、SEOなどで検索の上位にランクアップさせる必要はありません。必要な人を探し出すわけですから、100位でも200位でも何とかなります。逆に競争相手がいないか少ないジャンルを狙うのが得策です。これは、他の業種でもそうですが始めは隙間(ニッチ)を狙って入り込む必要があります。

 作成したWebサイトが編集者の目に止まったとしましょう。実際にページを見て、書ける人かどうか判断されます。メールのやりとりもしていないのに、と思う人もいるかもしれませんが、やはりWebサイトを見れば実力の程度と誠実さ(確実さ)が分かってしまうものです。技術的な部分を公開してしまっては好ましくないのでは、という人もいるでしょう。その場合は重要な部分に関しては載せておかなければ良いのです。全部を載せる必要はありません。

 Webサイト上に書かれている文章が、あまりに読めないものであると駄目な場合もあります。しかし、他の人では代用がきかない場合には、それでも問題ありません。というのも、文章が駄目な場合には編集部側で再執筆/再編集などが行われるためです。これは、自分が書いた文章が、そのまま本になるわけではない、ということを意味します。自分の文章を書き換えられたくない、というプライドがある人には向いていません。

ソフト(アプリケーション)は出版社から供給されるのか?

 ライターになれば出版社からソフトが供給されるだろう、と思っている人もいるかもしれません。Photoshopの企画だからPhotoshopを出版社から供給してくれる、というのはまずありません(Photoshopの企画なのにPhotoshopを持っていないという事自体疑われる。Flashなど自分の知っているソフト名に置き換えてみると分かりやすいでしょう)。つまり、Photoshopの本を書くのであれば先にPhotoshopを買わないといけない、ということです。これでは、お金がないと何ともなりません。その点、Webはソフトはブラウザなど無料のものが多いため、通信コスト程度で済んでしまうという利点があります。Webは貧乏人には優しいものなのかもしれません。
 ソフトはもらえないと書きましたが例外があります。それは発売前の雑誌のレビュー記事です。何と言ってもソフトが発売されていないため買うわけにはいきません。この場合に限ってメーカーの方から出版社にゴールデンマスター(最終版)が渡され、それがライターに回ってくることになります。ただ、この場合なぜか締め切りが迫っているのが常ですから、そこは気をつけておく必要があります。

文章の制限/ページ制限

 雑誌は最初から割り当てられているページが決まっています。書籍の場合は金額によってページ数が逆算されます。カラーと白黒では異なりますが、単純な計算では1ページ10円程度となります。256ページであれば2560円程度ということになります。一般的なサンプル系の書籍では240〜320ページ前後ですので、その範囲を超えた文書量(サンプル量)は無理または難しい事になります。また、サンプル系でなくリファレンス系の場合にはページ数は、かなり増えます。600ページを超える場合もあります。

 サンプル系の場合には、最初にサンプルを作ってから書き始めます。書き慣れており多くを把握しているのであれば文章を書いてからサンプルを作ることもできますが、慣れないうちは危険な行為です。サンプルを作成すると、プログラムのコードの行数が長くなると説明文章量は減る事になります。説明が下手な人はサンプルを多くし(または行数を増やして)、説明文章を減らせばよいのです。例えば以下のプログラムはC言語などで見られるforループです。

for (i=0; i<100; i++) n += i;

この場合、以下のようにして行数を増やすことができます。

for (i=0; i<100; i++) {
n += i;
}

さらに一行増やしたい場合には以下のようにします。

for (i=0; i<100; i++)
{
n += i;
}

 このようにプログラムで行数を調整していけば、どうにでもなります。逆に文章を書きたい場合にはサンプルのプログラムの行数は減らしておくのがよいでしょう。

 サンプルを作って説明文を書きためていけば、そのうち十分な量になるはずです。ただし、前にも書きましたが大量に文章やサンプルを作っても全部書籍に入るわけではありません。需要がありそうなものを優先して載せることになります。

編集部にデータを送るには

 できあがった原稿を編集部に送るには、基本的にはメールで添付して送ることになります。編集部に自分の原稿を持ち込みたい場合でも同様です。書籍の場合にはデータが大きくなるため自前でのサーバーまたは編集部側でサーバーを用意する事もあります。実際に編集部でサーバー経由した出版社は二社(○コミ、○評)のみです。データサイズが大きい場合には転送速度も重要なポイントです。ADSLのようにダウンロードは速いがアップロード速度が遅いものに関しては無駄な時間を消費してしまうことがあります。今ならば光回線にすべきでしょう。ただ、私の住んでいる地域のように光回線を引くまでに半年以上待ったり(業者がいないため)、光回線もADSLも引く事ができない場合には、宅急便を使うなど工夫をする必要があります。また、佐川急便など5日後に原稿が届いたりしたこともあり、緊急の場合には郵便局と宅急便を併用するのも手です。実際に試したところ郵便局の方がクロネコヤマトの宅急便よりも早く届きました。これは地域によって異なりますが一応参考までに。ちなみにダントツに速かったのはフェデックス (FEDEX) でした。

 話を少し戻しましょう。編集部に送るテキストは文字コードは問いませんが、画像データは制限がある場合があります。というのもDTPソフトの多くが10年前のQuark Xpress 3, 4のままなので、その制限を受けてしまうわけです。画面キャプチャーなどはPhotoshopで処理されるため問題ありませんが、図版に関しては注意が必要です。図版が必要になる場合には、あらかじめ編集部に確認しておきます。図版の多くはAdobe Illustratorを使って描かれます。2006年7月現在のIllustratorの最新バージョンはCS2です。しかしIllustrator CS2で図を描いて送ると、様々な問題が発生します。印刷関係の会社ではIllustrator 8、よくてもIllustrator 10といった状態で、非常に古いバージョンを利用しています。最新版のIllustrator CS2でver 8, 10で読み込めるようにしてもテキストが分割されてしまい、かえって二度手間になってしまう可能性があります。このような場合は逆にラフな図や絵を送る方がよい場合もあります。

 図版などが入っているとZIP圧縮しても、かなり大きなサイズになってしまうことがあります。多くの編集部では、かなり大きいサイズの添付ファイルを受け取る事ができるようになっていますが、2MBを超えるようなものであればサーバー上にアップロードして持っていってもらうか、章ごとに分割して必要に応じて送るようにします。サイズが大きすぎて編集部に届かない、というのは避けなければなりません。

どこの出版社がよいか

 ここらへんは結構興味があるところかもしれません。全部の出版社で原稿を書いたわけではないので、とりあえずの参考として読んでください。また、比較しているのは金額だけではなく執筆期間など総合的な面で、ということです。多少義理立てする必要もあるので(?)、伏せ字になっている出版社もありますf(^^;

 まず、ダントツに良いのは日経です。日経なんちゃら、とある雑誌です。日経だけは他と比べても執筆期間などが全く異なります。日経は別格ということです。

 あとは基本的には似たり寄ったりですが、雑誌の場合には発売日の30日前後が暫定締め切りです。すでに次の企画は決まっていて発売号に掲載されていることになります。例としては毎日コミュニケーションズのWebDesigningなどです。ソフトバンクの雑誌も(以前と変わっていなければ)、ほぼ同様です。
 普通は執筆期間が10日ほどありますが、●●●社の場合は執筆期間が短いと2日ということもあります。2日でプログラムをいくつか作成し、原稿を書かなければなりません。さすがに、これは無理があります。が、あらかじめサンプルを大量に用意しておけば、この依頼に応えることができます。でも原稿料は、ほぼ同一です。

 書籍の場合でも注意が必要です。1つは印税が支払われる時期です。早い会社では発売月の翌月払い、という所もありますが、多くは発売月(本の奥付に書かれた日付)の3ヶ月後です。専門でやってしまうと、このタイムラグが非常にきつい場合があります。これを防ぐには定期的に書籍または雑誌に原稿を書く必要が出てきます。もちろん副業であれば本業の収入があるわけですから気にする必要はないでしょう。

 印税で最も難儀するのが印税が支払われない場合です。会社の業績が悪化したり、運悪く倒産してしまうと支払われない可能性が大きくなります。日経などでは、そういうことはありませんが、小さい会社だとそのような可能性も十分にあるのだ、と考えてから書くべきです。

出版社への義理立て

 運良く(?)企画を通してくれた出版社に対して義理立てすべきでしょうか? これは人によってまちまちです。人情厚く義理立てする人もいますし、そうでない人もいます。ただ、どちらかと言えば身軽にしておいた方がいいと思われます。これは、どんな出版社でも好景気ばかりではないからです。実際、本が売れなくなり会社全体の業績が悪化してくると予想外の事態が次々と発生します。
 まず、企画の練り直しにより途中まで書いた原稿や作成したレイアウトがことごとく変更になり、2冊本を書いたのと同じ状態になることもあります。企画自体が消滅することもあります(これは、いくつか経験した)。この時点で多くの出版社とやりとりしていれば、他の出版社に企画を持っていくこともできます。出版といっても情報勝負の面もありますから、どこの出版社でどのような企画が立てられているのか、企画が通る隙間がないかどうか、ある程度把握しておけばリスクを回避しやすくなります。回避しやすくなるだけで回避できないことの方が多い感じもします。この場合には別の回避方法があり、駄目になってしまった原稿から新たなお金を生み出す事ができます。

文体と編集

 雑誌によっては文体が決められているものがあります。例えば毎日コミュニケーションズのWebDesigningやWeb Creatorsでは基本的に断定調(〜だ。〜である。)になっています。日経の場合は断定調ではなく、〜です。〜となります。となります。ここは執筆依頼される前に多少雑誌の傾向を調べておくと良いでしょう。もしくは、打ち合わせの時に確認しておきましょう。

 また、句読点も出版社と雑誌によって異なっています。作者の自由になっているところもあれば、そうでない所もあります。また、ですます調で書いた場合、強制的に文章が修正されることもあります(というか修正される)。

 レイアウトした際に文章が入らない場合には削除されることもあります。また、運悪くDTPのミスで最後の行が消えてしまったりすることもあります。雑誌の場合は、出てからのお楽しみ(?)という怖い面もあります。逆に、ライターの名前が出ているからといって、その人の文章そのままという事はないと言えます。雑誌での文章を参考にする場合には、かなり編集されているというのも念頭においておくべきでしょう。

 雑誌でもリファレンス系では1ページまたは2ページ以内に説明とサンプルが収まるようにしなければならない場合が多々あります。この点に関してはサンプル系よりもリファレンス系の方が難しいと言えます。ページ数だけでなく字数やプログラムの行数まで決まっていることもあります (JavaScriptポケットリファレンスなど。例えば3版はコラムは必ず右ページにしか出てこない。実践Ajaxプログラミング入門ではプログラムが右端で改行しないようになっている。つまり改行マークなどがない)。

出版後のフォロー

 質問や予想外のミスなどでメールが来る場合があります。書いた本の範疇を超えている質問も多く来る事があります。ここの対応はライターによって異なっています。1つは全ての質問は受け付けない、というものです。実際問題、質問に毎度回答しているとかなり時間を消費され本業が進まない事があります。これを避けるため一切回答しない、というものです。
 これとは対照的に来た質問のほとんどに回答する、というライターもいます。どちらが、良いかは分かりませんが、数多くの質問の中から多くのヒントをもらえることもあります。
 サンプル系では、ちょっと工夫すると質問を減らしたり、自分が回答しやすいようにすることもできます。例えば以下のプログラムの(1)と(2)があるとします。どちらも同じ処理で同じ内容です。

(1)
for(i=0; i<100; i++) {
n+=i;
}

(2)
for(i=0; i<100; i++)
{
n += i;
}

(1)は多くのプログラマが使っている書き方で開発環境でも、このように整形されます。ところが初心者などから質問を受けて{から}の間に×××を入れてください、と回答すると(1)では、なかなか探してもらえないか見当違いのところにプログラムが挿入されてしまったりします。どうも{が右側にあるので視点の移動量が大きいのか探しにくいか間違えやすいようです。で、面倒なのでなるべく(2)で書くようにしています。

 WebでHTML+CSS+JavaScript関連の書籍だと違った指定を受けることがあります。現在では構造と見栄えを分離するというのが普通になってきています。実際の業務ではCSSやJavaScriptの記述内容は別ファイルに分けておくのが一般的です。この方がメンテナンスしやすく、使い回ししやすいためです。しかし、雑誌や書籍の場合、そのように別ファイルに分離して書かないように、と指定されることがあります。これはHTML+CSS+JavaScriptが1セットで見る事ができるように、というものとレイアウト上のスペースの問題があります。つまりポイントを把握して実際の業務で使う場合の参考にしてくださいよ、ということです。そのままのスタイルで何も問題がありませんよ、という事ではないのです(この場合はHTML+CSS+JavaScriptが1ファイルに収まっている)。
 また、Web系の雑誌によってはプログラマ的な書き方はNGで、従来の分かりやすい書き方でないと駄目な場合があります。

 ここらへんは雑誌上では、ほとんど説明されず暗黙の了解となっている事もあるため、たまにブログなどでソースコードが駄目、プログラマ的に美しくないなど批判を受けることもありえます。注意しないといけないのは雑誌も書籍もターゲット層/ターゲットユーザーが、おおよそ決まっていて、そのターゲットに対して分かるように書く事になります。同じ処理を行うプログラムでもWebデザイナー向けのものとWebプログラマ向けのもの、初心者向けのものと中級者向け、上級者向けで異なることになります。雑誌や書籍の場合、ハッカー的なプログラムやマニアックな書き方をするのは好ましくないようです。自分が分かっても多くの読者が分からなければ駄目だ、ということです。

継続性

 最初のハードルを超えれば後は継続して書けばよい事になります。最新技術を追う雑誌系の場合は、次々と新しいものがでるので、それを追っていけばよいでしょう。しかし、特定の分野に特化したものだと、一度書籍を出して終わってしまうことがあります。結局は新しいネタや情報を仕入れて、次の書籍の構想を練るということになります。

 ラッキーなパターンだとさらに依頼が来ることもあります。問題は、ある程度勉強しておかないと依頼が来たときに断るべきか、受けるべきか判断しかねることです。駄目っぽい(締め切りが間に合わないなど)場合には、断ってしまうのが結果的には得策です。無理して書いても良い事はありません。
 あとは、とにかくたくさん書けば何とかなるでしょう。継続は力なり、といったところでしょうか。

(ITProに「コンピュータ書をロングセラーにするのは難しい」という記事が掲載されていました。コンピュータ業界は流れが早いので確かに難しいと言えます。その中でWeb関連だと1日で状況が変わってしまうことが多々あり、1年間売れるという書籍を作ること自体が難しい状態になります。ソフトウェアのバージョンアップも早く、メジャーなAdobe Systemsの一連のソフトウェア群(Photoshop, InDesign, AfterEffectsなど)でさえおおよそ1年半でバージョンアップが行われます。
GoogleのようにWebアプリケーションで提供するパターンになると、書籍では追いつくことができません。本が出た瞬間に画面構成や機能が変わってしまうわけですから。このような場合は、悪くても雑誌でないと対処できません。最もベストなのはWebメディアで、これならすぐに対処可能になります。
10年前 (1998年頃) なら書籍で3ヶ月ほど余裕があった期間も、Webメディアになってしまうと数日か当日対処という凄い状況に陥ってしまいます。)


老後はどうすればよいか

地元の新聞を見ていたら老後の心配(葬式など)をしている人が結構いるようです。でも、年齢を見ると30代。まだ、50年以上生きられると思うのに年金問題などで若いうちから老後の心配をするという状況になっている感じがあります。サラリーマンなどでは年金問題は大きな関心事です。何と言ってもサラリーマンには定年があるからです。その点、専業でライターの場合、自営業/自由業扱いなので定年はありません。その代わり不安定さがつきまとうのと、老後の事も自分で計算しておく必要があります。
50年後の事ははっきり言って分かりません。ただ、戦争や小惑星などの衝突といった大きな天変地異がなければ人口動態は、おおよそ読む事ができる程度です。先の事を心配しても仕方ない楽天的に行こう、というタイプであれば割とうまく行ってしまうかもしれません。問題は悲観論者の場合です。この場合は考えられるリスクを書き出してみて、1つずつ潰していく=リスクヘッジ(危険分散)するように少しずつ処理していきましょう。もし、老後のお金が心配なら金融に関する事を勉強すればいいでしょう(個人的には株よりもFX (外国為替証拠金取引) の方がマシだと思ってます)。また、地域のネットワークもたくさん作っておけば、いろいろな時に助けてもらえるかもしれません。逆に誰かが困っていたら、できうる範囲で助けてあげるのが良いでしょう。

2006.7.10, 2006.7.11追加, 2006.7.19追加, 2007.7.19追加