カテゴリー

最新の記事

最近のコメント

最近のトラックバック

月別アーカイブ

ブログ検索

RSSフィード

ブロとも申請フォーム

この人とブロともになる

スポンサーサイト

スポンサー広告
--.--.--
上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

ベンチャーブログのランキングに参加しています。
下のバナーをクリックして応援していただけると嬉しいです。
にほんブログ村 ベンチャーブログへ

雑誌の時代は終わったのか?

未分類
2008.08.28
すみません。今回は一部の方、特に出版関係の方から、反感を買いそうな内容です。タイトルは「雑誌の時代は終わったのか?」と疑問形になっていますが、真意は「雑誌の時代は終わったのだ」ということなのです。

ネットの利用が拡大することで、以前から「紙の新聞がなくなる」と言われてきました。もちろんその傾向は確かにあるのですが、実際には新聞よりも、雑誌の方がネットの攻勢に弱いのではないかと感じています。特に情報力を売り物にしている雑誌、例えばIT関係やビジネス系の雑誌は、急速な勢いでネットに飲み込まれているような気がします。

なぜそう感じるのか。ふたつの個人的な理由があります。

まず私自身が雑誌を買わなくなりました。以前は仕事柄もあり、日経BPの雑誌を十誌以上取っていたのですが、現在では「日経ビジネス」しか購読していません。キーワードさえわかれば、ググることで必要な情報にアクセスできるので、雑誌を取っておく必要がなくなったのです。以前は本棚まるまるふたつを雑誌収納に使っていましたが、このスペースも不要になりました。いま他に定期的に買っているのは「週刊アスキー」くらいでしょうか。それも情報を入手するためというよりは、電車移動の暇つぶし、といった意味合いが強いのです。

もうひとつの理由は、雑誌関係の仕事が減っていることです。コピーライターを始めた頃は、出版社からいただく記事体広告の仕事が圧倒的に多く、これが長らく収入の柱になっていました。21世紀に入ってからは広告代理店からいただく特定クライアントの仕事が増えていったのですが、それでも雑誌掲載の原稿は少なくありませんでした。しかし今では雑誌掲載の仕事はほとんどなく、ほぼすべてがクライアントの自社サイト掲載か、パンフレットやリーフレットの仕事、ブログなどの企画系の仕事になっています。私自身は雑誌中心からクライアント中心の仕事へそれなりにシフトしたのでまだ生活が可能なのですが、雑誌を中心に活動してきたライターさんは、いま大変なのではないかと思います。

現象面から見る限り、少なくともIT系の雑誌の時代は終わったと見ていいでしょう。書店の棚を見ても、雑誌数はかなり少なくなっていますし、各誌の厚みも減少傾向にあります。しかしこれは、他の分野の雑誌にもいえるのではないか。最近は女性誌が付録を付けるケースが増えていますが、これも最後のあがきかもしれません。実際ある雑誌関係者も、ラジオで「女性誌の売れ行きが芳しくない」といったことをおっしゃっていました。

もちろんすべての雑誌がなくなるわけではないと思います。私自身は、雑誌には大きく2つの役割があり、そのうち一方の役割がネットに代替されると考えています。それは「情報の提供」という役割です。しかし雑誌には「娯楽の提供」という役割もあります。電車の中で時間をつぶすには、雑誌はけっこう手軽で優れています。このあたりを意識した雑誌は、これからも生き残るのではないか。

また趣味系の雑誌も読者を維持し続ける可能性があります。つまりエンターテイメント性を重視する限り、雑誌にも勝負できる土俵が残っているのではないかと思うのです。もちろん漫画雑誌の状況を見れば、エンターテイメント系も厳しいことには変わりありませんが、部数の確保は可能でしょう。毎号100万部売るのは難しいとは思いますが。

「情報の提供」を担う雑誌が不振になるということは、メディア業界全体に大きなインパクトをもたらすでしょう。そもそも私たちに新しい情報が伝わる時には、雑誌→新聞→テレビという順番でやってくるケースが少なくありません。もちろんニュースはこの逆になりますが、トレンド情報やゴシップ記事などの情報は、まず最初に雑誌が取り上げ、その後を新聞やテレビが後追いするケースが多いと思います。しかしこの部分は簡単にネットで代替できるのです。

情報媒体の売れ行きの変化は、ナレッジの流通形態が大きく変わっていくことも意味します。20世紀までは、ナレッジの流通は雑誌や書籍に頼るところが大きかった。しかし今ではその役割をネットが担うようになっている。出版社はこれからどんどんつぶれていくでしょう。また書店も今後さらに数が減少していくでしょう。特に大型書店が危ない。Amazonに代替されちゃう可能性も高いですしね。最近は駅の構内に小型書店を積極展開しているところもありますが、このような企業はけっこう生き残るのかもしれない。暇つぶしや娯楽としての雑誌・書籍へのニーズに特化した形になっているからです。ビレッジバンガードが成長を続けているのも、エンターテイメント性を強く打ち出しているからだと思います。

こういう書き方をすると、なんだか「出版業界は危機に直面している」という論調に近くなって、ちょっと暗くなってしまいますが、実際には決して暗い話ではないと思う。ナレッジの流通をネットが代替するというのは、ナレッジの利用者から見ると悪い話ではないからです。ナレッジを「手書き」や「伝承」から解放したのがグーテンベルグだとすれば、ナレッジを「物理的な媒体」や「効率の悪い流通機構」から解放しつつあるのがネットだというわけです。

一部の業界の方には申し訳ないのですが、本当に、決して悪い話ではないと思うんですよね。いずれにせよこの流れは変えようがありません。その前提で次の一手を考えることが重要だと思います。
スポンサーサイト

ベンチャーブログのランキングに参加しています。
下のバナーをクリックして応援していただけると嬉しいです。
にほんブログ村 ベンチャーブログへ

海水浴に行って来ました

閑話休題・・・
2008.08.22
8月18日~20日にかけて、家族で海水浴に行って来ました。場所は伊豆・下田の白浜海岸。近くのホテルに泊まって、子供たちと一緒に波と戯れていました。

まあ根がコドモなので、海にいくとヘロヘロになるまでボディボードもどきをやってしまうのですが、波に乗るというのは結構難しいですね。まずいい波が来そうな場所を選んで、やってくる波の中からいい感じのものを見つけて、さらにその波がブレイクするポイントを予測して、そのタイミングで波に乗る必要があります。また波に乗り始めた後も、身体の力の入れ具合が悪いと、沈んだりひっくり返ったり、最後まで乗り切ることができません。でも面白い。やみつきになります。

そんなことをしながら思うのは、ビジネスの波に乗るというのはどういうことなんだろう、ということです。何か新しいこと、自分が有意義だと感じることを始めても、それが世の中の波にうまく乗っていないと、結局のところうまくいかないんだよなあ。それにうまく波を見つけて乗り始めても、そのための準備が不十分だと振り落とされてしまう。いい感じの波を見つけるために沖をぼんやり眺めていると、これまでの失敗やら、いま取りかかっている仕事のことやら、いろいろと考えてしまいます。

とにかく大きな流れに逆らわないこと。これはとても重要なことだと思います。時代の流れにも、結局のところ逆らうことはできないのではないでしょうか。

ビジネスだけではありません。例えば少子化問題なんかも、そういう観点から考えた方がいいのではないかという気がするんですよね。いわゆる先進国と呼ばれるエリアで出生数が減り、人口が徐々に減っていくというのは、大きな時代の流れなのではないか。だとすれば、人口増を前提としたシステムを変える必要があります。でもいまの少子化問題の議論って、いかにして人口を増やすかに焦点が当たっているような気がします。

人口が増えてくれれば、いまのシステムのままで対応できるのでラクだ、というのはわかります。市場も大きくなるし、企業活動もやりやすいでしょう。ダイエーの故中内氏が「売上がすべてを癒す」とおっしゃったことを思い出します。でも「出生数をいかにして増やすか」というところに焦点を当てて対応策を考えるのは、大きな流れに逆らうことなのではないかと思うのです。

もちろん子供が産みやすい・育てやすい環境を作るのは必要ですが、それは人口増を目的として考えるのではなく、社会的に「当たり前のこと」として考えるべきだと思うんですよ。その一方で、人口減を前提としたシステムを作り、徐々に移行していくという取り組みも欠かせないのではないでしょうか。そもそもこの間まで、人口がこのまま増えていくと地球環境が持たなくなる、という議論をしていたわけでしょう?人口が自然に減っていくなら、それは決して悪いことではないはずです。問題は、人口増を前提に社会システムや経済システムを組み立てていることだと思うのですが、どうなんでしょうか?

ちょっと話が飛びすぎてしまいましたが、波というのはいろいろなことを考えさせる、という話でした。

でも片道210キロ・約4時間のドライブは、結構疲れますね。20代の頃は「高速を使わずに24時間耐久1000キロドライブ」なんてオバカなことを平気でやっていましたが、最近は長時間のドライブがキツクなってきました。

もうトシなんでしょうかねえ。

ベンチャーブログのランキングに参加しています。
下のバナーをクリックして応援していただけると嬉しいです。
にほんブログ村 ベンチャーブログへ

Webアプリの難しさ

PCとかネットとか
2008.08.14
5月23日の「ご無沙汰してます。」でも書いたように、ここしばらくLAMP(Linux&Apache&MySQL&PHP)での開発作業を行っています。何を開発しているのかはまだナイショですが、この数ヶ月でいろいろと感じたことがあるので、自分のための備忘録として記録しておきたいと思います。(それにしても「ご無沙汰してます。」って、ひどいタイトルですね。我ながらびっくり。)

基本的にはPHPでのプログラミングが主軸になるのですが、Webプログラミングというのは、想像以上に難しいです。難しいというのは、言語仕様が難しいとか、動作が複雑だとか、概念的に難解といったことではありません。あまりに融通無碍な世界であるため、自分に対して適切な「枷」をかけなければならない点が、難しいなあと感じているのです。しかもどのような「枷」をかけるべきなのか、ひととおりやってみないとわからない。PHPにはいくつもフレームワークが存在しますが、「確かにフレームワークが必要だなあ」と思います。でも私自身は、既存のフレームワークを使う気はないんですけどね。

 というわけで、この数ヶ月で、プログラミングスタイルを何度も変更しています。

 まず最初は書籍のサンプルコードを参考にしながら、フォームを使った会員登録画面を作ってみたのですが、いきなり違和感を感じることになってしまいました。まあ、サンプルコードにありがちな、HTMLとPHPが完全に混在しているコードだったのですが、これではメンテナンスができない、という感じだったのです。PHPって、動くコードを書くのは簡単なんだけど、メンテナンス性を維持したコードを書くのは、なかなか一筋縄ではいきませんね。

 まず言語仕様に問題があります。宣言無しで変数を使うことができ、型付けが非常に緩やかなので、どこでどのような名前の変数を使ったのか、別にドキュメントを残しておかないとわからなくなります。これは「手軽に使える」というスクリプト言語のメリットでもあるのですが、将来の変更を前提にしてプログラミングを考えると、大きなデメリットになります。まあ、ドキュメンテーションをきちんと行えばいいわけですが。でも「ソースそのものをドキュメントにする」という、昔のC言語の発想を引きずっている私としては、ちょっと不満だったりします。変数の頭にすべて「$」を付けるというルールは「なるほどなあ」と感心したりもしているのですが。このルールがあれば、予約語とバッティングすることもないですしね。

 それからWebプログラミングの場合、まずHTMLありき、というのも厄介です。つまりMVCで言えば、何も考えずにプログラミングを進めていくと、どうしてもView主導型になってしまうのです。これもプログラムの見通しを悪くします。まずプログラム構造全体をControl主導型にし、その下にデータモデルとViewが配置されるようなイメージにしないと、なかなか見通しのいいプログラムになりません。そのためには自分でプログラム構造のルールを厳格に決め、そのルールを自分で徹底的に守る必要があります。

 昔のX/Motifのプログラミングでは、このあたりが比較的扱いやすかったような気がします。私の時代は自分で無限ループのメインルーチンを記述し、そこに画面要素とそこで発生するイベントの定義を挿入、さらにコールバックルーチンを別途用意する、という手法が一般的だったような気がします。主役はあくまでもプログラム本体で、画面要素はオブジェクトとして扱えたのです。しかしPHPの場合、イベントは画面遷移を伴うのが一般的です。Ajaxを使えばオブジェクト的に扱えますが、そうでなければ個々の画面要素をPHPからコントロールすることはでませんよね。たぶんできないと思う。(弱気)

 それから画面遷移時の変数の扱いも厄介です。一般的な変数は画面遷移時にすべて解放されてしまうため、スーパーグローバル変数を使わないとステートを引き継げません。例えばフォームに何か入力させ、「OK」ボタンで次の画面に遷移するといった処理を考えてみましょう。もしフォーム入力の内容に誤りがあれば、その内容を保持して元のフォーム画面を再表示すると共に、エラーメッセージを表示したいところです。しかしいったん次の画面に遷移してから元の画面を呼び出すと、フォームフィールドの内容は消えてしまいます。フォームフィールドの内容を次のコントロールに伝達するPOST変数も消えています。最初はフォーム画面の次の画面の中にhidden型のinput要素を記述し、POST変数を維持するようにコーディングしていたのですが、どうもしっくりきません。今ではSESSION変数にフォームの内容を保持し、不要になった時点でunsetしています。でもこれが最善の方法なのか、まだ確信が持てていない状況です。

 というわけで、6月にはコントロールとビューを完全分離するための方法をいろいろと試行し、7月には「だいたいこんなもんだろう」という形を決めています。単純な方法なのですが、ひとつのプログラム(コントロール)の処理を、前処理(主にSESSION変数の確保とPOST/GET変数からの引継)、イベントハンドリング、画面表示用のデータセットの作成、画面表示、後処理、という5つの部分に分け、画面表示のコードをコントロール内に記述しないようにしているのです。画面表示はそれぞれひとつの関数として定義してあり、その内部にHTMLが記述されています(XHTMLと自信を持っていえないところが悲しい)。さらにひとつの画面を構成する機能ディビジョンは、「disp_○○_box.php」という関数にして、画面表示関数から呼び出すようにしました。こうすると画面表示の記述がものすごく短くなり、構造が明確になります。

 画面表示に必要な情報も、最初はグローバル変数やスーパーグローバル変数を画面表示関数の中でそのまま参照していたのですが、これもメンテナンス性を損なう要因なので、引数渡しに変更しています。まあこれは当たり前の措置ですね。前述の「画面表示用のデータセットの作成」の部分でこの引数を作成し、画面表示関数の呼び出しのところで使用するわけです。ひとつの機能ディビジョンに対しては、ひとつのデータセットを引き渡します。もちろんこのデータセットは配列です。それも単純な配列ではなく、C言語の構造体のようなものです。C言語と違うのは、配列の要素の識別を文字列で行っている点でしょう。連想配列って便利ですね。コードの可読性も高くなるし。

 関数の戻り値をどう扱うかも悩み所ですね。関数に引き渡す情報は引数、戻り値は関数そのものの値、というのが妥当だと思うのですが、引数の一部をリファレンス渡しにしてそこに戻り値をセットするというのも、自由度が高くなるので捨てがたい。どちらにするか結構揺れていて、何度も関数を書き直していたんですが、今では「関数の値を戻り値にする」という、ごく当たり前の方法に落ち着いています。引数をリファレンス渡しにすると、自由度は高まるんですが、可読性が落ちるような気がするんですよ。まあこのあたりは、趣味の世界かもしれませんけどね。でも可読性をいかに高めるかは、プログラミングで最も重要なことではないのかなあ。そんな気がします。

 現時点で、MySQLのテーブル数が29、定義済みのファンクション(関数)の数が70ちょっとになっていますが、メンテナンス性はかなり上がりました。トレースログやタイムログのテーブル&関数も作り、ログ取得関数を各関数に仕込んでいるので、デバッグもしやすいです。もちろんシンタックスエラーや未定義インデックスがあれば、PHPそのものがワーニングを画面に表示してくれますが、PHPのエラーが出ている間は「まだまだだめじゃん」ということ。本当のデバッグは、インタープリタからのエラーが出なくなってから始まるんですよね。

 CSSとJavaScriptの勉強も本格的に始めました。CSSは他のサイトの記述を参考に「まあこんなもんかな」というレベルで適当に記述していたのですが、どうも根本的な誤解があったようなので、標準テキストを頭から読むことにしました。恥ずかしながら、かなり間違った使い方をしていたようです。JavaScriptはDOMのコントロールに使う予定です。もちろんAjaxの使用も考えています。CSSハックやJavaScript使用不可の環境との互換性をどうするかも、今後基本方針を決めなければなりませんね。

 ということで、まだ道のりは長そうなのですが、ボチボチやっています。できあがったら公開するつもりなので、乞うご期待。

ベンチャーブログのランキングに参加しています。
下のバナーをクリックして応援していただけると嬉しいです。
にほんブログ村 ベンチャーブログへ

かみなりこわい

閑話休題・・・
2008.08.08
夏に入ってから、天候が不安定ですね。激しい夕立や落雷も日常茶飯事です。個人的には雷や台風は嫌いではなく、むしろ楽しんでしまう方なのですが、今年はちょっと「困ったなあ」という感じです。実は今年の夏に入ってからもう2回も、雷の影響でオフィスのPCがダウンしているんですよ。

いずれも留守中の出来事で、具体的にどのようにPCがダウンしたのかはわかりません。しかしいずれも激しい落雷(ピカッ、ドンガラガッシャン!)があった夕方のことで、オフィスに戻るとPCサーバー(Windows Server 2003を動かしている)が「ピー」とビープ音を立てて止まっていました。仕事に使っているクライアントPCや、Webプログラミング用のLinuxサーバーもリブートされています。おそらく落雷で停電が発生したためだと思われます。自作のデジタル時計(AC電源を使用)は止まっていないので、それほど長い停電ではなさそうです。いわゆる瞬電というヤツでしょうね。

瞬電を回避するにはUPSを使うというのが「定石」ですが、実はUPSには痛い目に遭っています。数年前からサーバー電源はUPS経由で供給していたのですが、昨年くらいからサーバーが知らないうちにダウンしていることが多くなり、よく調べてみたらUPSが原因だったのです。そのUPSはもう使っていません。電源トラブルを回避するためにUPSを使っていたのに、そのUPSが原因で電源トラブルに見舞われるなんて、笑い話にもなりません。

ということで、瞬電対策をどうするか、ちょっと悩んでいます。サーバーをデータセンターにハウジングするという選択肢もありますが、そんなにコストをかけるようなサーバーでもないしなあ。とりあえずこの夏をだましだまし乗り切って、また後でゆっくり考えるかなあ。

ベンチャーブログのランキングに参加しています。
下のバナーをクリックして応援していただけると嬉しいです。
にほんブログ村 ベンチャーブログへ

FC2Ad

相続 会社設立

上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。