iPhoneは決してケータイを変えない

社団法人・電子情報技術産業協会によれば、この記事を書いている時点で、最新の2009年8月の統計で、１か月の携帯電話出荷台数は約１８７万台で、１４か月連続マイナスとなっているらしい。

うち、ソフトバンクのシェアは、総務省によると、ざっくり２０％と言われているので、2009年8月の１か月で約３７万台。

ところで、アップル社発表による、2009年4～6月期の、「全世界」でのiPhoneの販売台数は約５２１万台だ。これを１カ月平均にすると、１７４万台。

仮に、ソフトバンク加入者の半分がiPhoneを購入するという、非現実的な想定をしても約１８万台で、iPhoneの2009年8月単月の国内シェアはたった１０％。

実際にはiPhoneの累計販売台数は１００万台に届くか届かないか、程度の台数だと言われている。

総務省の「平成19年通信利用動向調査報告書（世帯編）」（2008年6月）によれば、国内の携帯電話機・PHSの世帯普及率は2007年末で95.0%とのこと。

2005年の日本の世帯数が約4,900万なので、2007年の世帯数が少し減っているとして、iPhoneがすでに累計100万台売れていたとしても、シェアはたった２％。

要するにiPhoneは、日本国内では極めてマイナーな機種なのだ。

ところが国内のＩＴ系メディアは、iPhoneに関して「バカ騒ぎ」状態。特に日経ITProなどは、iPhone専用のコーナーまで設ける始末。

そのコーナーに「ケータイを変えたiPhone」などという、勘違いもはなはだしいタイトルを付けている。

しかも「ケータイを変えた」と過去形。一体いつ日本のケータイ文化がiPhoneによって変えられてしまったのだろうか。

日経ITProのこのコーナーは「とんでも記事」のオンパレードで、ここまで来ると「お笑い」だ。

梅田望夫の『ウェブ進化論』に始まる「グーグル狂想曲」以来、ＩＴ系メディアのこの種の「根も葉もない流言飛語」には、目に余るものがある。

たった数％の機種が、いつ、どうやって、相変わらず親指でメールを打ちまくり、モバゲーでヒマをつぶしている、大多数の日本の携帯利用者の文化を変えたというのか？

いったいiPhoneが日本の携帯電話業界に、どんな顕著な「功績」をもたらしたというのか？

iPhoneのテレビＣＭのセンスが良くて、「さすがアメリカ」などと、いまさら、米国かぶれの頭がからっぽのフリーライターが、iPhoneが日本のケータイ業界に革命を起こすと、完全に誤った妄想を抱く様子は、某新興宗教がハルマゲドンを本気で信じていたのと大差ない。

こんな特集コーナーを組む日経ITProの編集部は、妄想にもとづいて特定商品の宣伝記事を書く自らの編集姿勢を恥じ、謙虚に現実を伝える方向に正すべきだ。

というか、日経の記者って、もう三流スポーツ新聞と同じレベルになってしまっているのかもしれない。

以前ここで批判したAsteriskの連載にしてもそうだが、日経ITProの特集記事は、いわゆる「都市伝説」が書いてあるんだ、くらいの気持ちで、８割引くらいで読むべきだろう。

つくりがヘボい、柴田淳のファンクラブサイト

柴田淳が、デビュー８年目にして作ったファンクラブ「蠍一座龍世柴田組」（※）に加入したことは、すでに書いた。

（※「さそりいちざ・りゅうせ・しばたぐみ」と読む。柴田淳が蠍座で、辰年生まれであることから）

ファンクラブ専用ウェブサイトがあり、当然、ユーザ、パスワードでログインし、「組員」しか閲覧できない。

ところが、このウェブサイトの出来が、とにかくヒドいのだ。

株式会社ロム・シェアリングという会社のシステムを利用しており、この会社はファンクラブの運営・管理を全般的に代行する専門会社らしい。

しかし、株式会社ロム・シェアリングの企業サイトにアクセスした後、延々とFlashや画像のロードに待たされることからも分かるように、明らかにデザイン偏重で、基礎的なシステム開発の技術レベルが低いことがわかる。

というのは、ファンクラブが開設して１か月もたたないのに、ファンクラブ専用サイトの掲示板システムがダウンしたのだ。

柴田淳には悪いけど（ごめんね、しばじゅん）、柴田淳のファンはそんなに多くない。決して、mixiのように分単位で書込みが殺到するような掲示板ではない。

事実、サイト内の掲示板のうち、最も書込みが多いものでも約1,300件だ。

これでダウンするのだから、システム基盤の設計技術のレベルの低さは明白だ。

しかも、この掲示板、PCと携帯電話の両対応しているのはいいが、携帯電話の一部の機種に非対応で、一部のファンがファンクラブ先行のコンサートチケット予約に申し込めなかったらしいのだ。

単純なHTMLを吐き出すだけのCGIで、なぜ携帯電話の一部機種に非対応になるのか、理解に苦しむ。

問題の掲示板コーナーについては、個人的に気になってHTMLのソースコードをのぞいたところ、複数ある掲示板へのハイパーリンクの<A HREF="～">タグが、どれも閉じられていない。（要は</a>がない）

運営者にメールで連絡したが、いまだに改修されていない。

それにこの掲示板、PC版の本文入力欄が、携帯版に合わせて横半角40文字と、極端に狭いし、自分の書いた記事の削除機能さえない。

また、サイト全体は、どこのコーナーに行っても、いちいち結構な高さのあるトップバナーが表示され、PCで見るときは毎回たてにスクロールする必要がある。

デザイン偏重で、使いやすさが犠牲になっている。

さらに、会員情報の編集機能があるのは当然だが、自分で初期パスワードの変更ができないのだ。

ユーザ認証のあるウェブサイトで、パスワード変更ができないサイトなんてあるだろうか？初期パスワードが漏れてしまったら、個人情報保護の観点から、株式会社ロムシェアリングは一体どうするつもりなのか。

さらに、HTMLのソースコードをのぞいて気になったのが、ローカルの開発環境のスタイルシートへの参照が残ったままになっていることだ。

...などなど、この株式会社ロムシェアリングという会社のウェブサイトは、突っ込みどころ満載の、かなり品質の悪いシステムだ。

ただ、よく考えてみると、なぜビクターほどの有名なレコード会社のアーティストが、個別にファンクラブ・サイトを構築しなきゃいけないのか？

柴田淳が所属するVictor Music Artsは、ビクターエンタテインメントの100%子会社だ。

親会社がファンクラブ運営システムを、一括してまともなシステム構築業者に発注し、それをASPの形でシェアすれば、ビクターグループ全体としても費用削減になるだろう。

レコード会社には、そういうことをマネジメントできるＣＩＯ的な人間がいないのかね。まったく。

「キンドル」は日本で絶対売れないが、iPodは売れた理由

前回は、米アマゾンが開発した「キンドル」のような電子書籍端末が、日本では絶対に売れない理由を、ぐだぐだと書き連ねた。

今回は、「キンドル」が絶対に売れない日本で、なぜiPodのような携帯音楽プレーヤーが売れたのか、その理由を考えてみる。

まずは、下らない理由から。昔のLP盤がCDの大きさになることで、すでにレコードの「モノ」としての価値が小さくなっていたこと。

「音さえ聞ければいい」というニーズが、すでに十分に大きくなっていたことだ。

そして、より重要な理由は、音楽配信で実質的な値下げになっていることがある。

CDはシングルでも普通1,000円するが、音楽配信で１曲単位で購入すれば200円ほどで済む。アルバムも、音楽配信で購入すれば、CDを買うよりも約３割は安くあがる。

「キンドル」のような電子書籍端末をヒットさせるポイントがあるとすれば、この点だけだ。

たとえば電子書籍が、紙の書籍の半額になったら、新書・文庫を「キンドル」のような機器で読もうという消費者が出てくるかもしれない。

ただ、それでも機器の物理的な大きさで、ケータイとの競争に敗れるだろう。

書籍を読むには、どうしても一定の大きさの画面が必要だが、音楽を聴くにはケータイより小さい画面で十分だ。

じっさい、携帯音楽プレーヤーは、フルカラー液晶をもつ機種もあるが、動画配信端末としては失敗している。曲名などを表示する、最小限の画面があれば十分。

なので、ケータイに加えて携帯音楽プレーヤーを持ち歩くことを、面倒がる人はほとんどいない。

じゃあ、ケータイ自体を音楽配信端末として使えばいいのに、なぜケータイの音楽配信サービスは、「着うたフル」どまりで中途半端なのか？

音楽配信で、ケータイが圧倒的に不利な理由は、大量の音楽ファイルの管理に不向きだからだ。

１年で100冊の本を読む人は少ないが、１年で100曲の音楽を聴く人は普通にいる。

音楽ファイルは、１アルバム１ファイルではなく、１曲１ファイルなので、どうしてもファイル数が膨大になる。

すると、大量の音楽ファイルを整理する道具が必要になり、iTunesのようなパソコンで動くソフトウェアと、携帯音楽プレーヤーを組み合わせて使うことになる。

そして、iPodなどの携帯音楽プレーヤーは、パソコンが誰でも使えるふつうの機械になってから登場したので、成功した。

パソコンを買うお金のない消費者層は、ケータイの着うたフルや、CDレンタルで音楽を聴き、経済力がつけば、自然と携帯プレーヤーとパソコンの組合せへ移行していく。

また、書籍は書籍そのものが売れなくなっているが、音楽はそうではないという根本的な市場規模の違いもある。

当り前のことを書き連ねてきたが、要するに「キンドル」のような電子書籍端末は、日本でマーケティングするだけ販促費のムダなので、やめた方がいいということだ。

米アマゾンの米国人社員は、日本のケータイがいかに若年層の生活に浸透しているか、また、社会人がいかに単行本を読まないか（漫画ばっかり読んでいるか）といった、文化的背景の違いを軽視し過ぎているに違いない。

日本では「キンドル」なんて、絶対に売れません。

米アマゾンの「キンドル」が日本で絶対売れない理由

『電子書籍「キンドル」上陸の衝撃』

日経ビジネスオンラインの上記の記事によれば、米アマゾンは、電子書籍を読む携帯機器「キンドル」快進撃のおかげで、大幅な増収増益を記録したらしい。

米アップル社のiPodが日本の音楽業界を激変させたのと同様、「キンドル」が上陸すれば日本の出版業界を激変させるかも...

...という主旨の記事だが、絶対ならない。保証してもいい。

「キンドル」は、ブラックベリーのようなPDA型携帯電話と同じく、日本では絶対にヒットしない。
Amazon Kindle will never sell in Japan, just as Blackberry doesn't sell well.

「キンドル」が売れない理由も、ブラックベリーがヒットしない理由も同じ。日本には独自の「ケータイ文化」があるからだ。
The reason why Kindle will never sell in Japan is the same as why Blackberry doesn't sell. There is a unique "Keitai Culture (mobile phone culture)" in Japan.

「キンドル」やブラックベリーに食いつく日本人がいるとしたら、ケータイ文化の根深さに鈍感な「米国かぶれ」だけだ。
If there are any Japanese who are going to get Kindle, such Japanese are mere a kind of Americophilia who are not sensitive their own cultural background.

日本の出版物を、雑誌、新書・文庫、漫画、その他全ての単行本に、大きく分けてみよう。
Let's categorize published books into magazine, paperback (called 'Shin-sho' or 'Bunko' in Japanese), manga (Japanesse comics) and all the other hardcover.

雑誌のなかでも、上質紙に印刷された写真の美しさが必須のファッション誌のようなものは、「キンドル」では売れない。
Among manazines, such as mode managinzes in which beautiful photos printed on a high-quality paper are important will never sell with Kindle.

「キンドル」で売れるが文字中心の雑誌（論壇誌、文芸誌、大衆小説誌など）の読者層は、「キンドル」のような最先端のＩＴ機器に手を出す層とは、おそらく一致しない。
Magazines without beautiful pictures, such as critique or novels magazines can be sold with Kindle. However, those who are interested in such old-fashioned serious magazines will never be interested in a new IT device like Kindle.

次に、新書・文庫だが、これは電子化する価値がある。しかし、これらが電子書籍として売れるとすれば、「キンドル」ではなくケータイだろう。
Paperbacks can be electronized and sold with Kindle. But in Japan, there is already a strong-sell device for this purpose, i.e. mobile phone.

新書・文庫の利点は、持ち歩きやすさだ。もし、新書や文庫の新刊が、ケータイで読めるようになったら、誰がケータイの他に、もう一台、「キンドル」のような、かさばるものを持ち歩くだろう。
The merit of paperbacks is their portability. If Japanese paperbacks can be read on mobile phone, who dear to bring an annoyingly big device like Kindle in addition to a mobile phone?

しかも「キンドル」のデザインは、味もそっけもなくて、全然カワイくない。ダサダサである。
And the design of Kindle is boring and not attractive at all. In Japanese we say Kindle is NOT 'kawaii'.

電子手帳（PDA）もそうだが、通勤電車の中で「キンドル」なんか持っていたら、間違いなくオタク扱いだ。
If Japanese bring a Kindle in the train, people will surely regard him/her as an 'Otaku' and look down on him/her.

なので、「キンドル」は、新書・文庫の配信機器としても、まったく魅力的でなく、実用的でもない。ケータイで十分だ。
So Kindle is neither attractive nor practical in Japanese context of 'Keitai Culture' for reading paperbacks. Mobile phone is enough for Japanese.

最後に漫画だが、漫画しか読まない読者層も、経済水準的に、また、趣味嗜好的に、「キンドル」のようなＩＴ機器を購入する層とは明らかに異なる。
Regarding the last category, manga, those who read only manga and never read novels have totally different background from those who are interested in a state-of-art IT device like Kindle.

また、ページ全体のコマ割りが、ストーリー展開と直結する漫画のようなビジュアル重視の書籍は、ファッション雑誌と同様、電子化に向かない。
In addition, the visual design of each page is really important for manga. But the LCD screen of Kindle isn't suitable for representing an avantgarde page design of Japanese comics.

また、コアな漫画ファンは、コアな単行本ファンと同じように、本の装丁や、紙の質感、ページレイアウトなど、本の持っている装飾的な価値を重視する。中身だけ電子化しても、売れない。
And those who really love manga love not only the contents but also the cover design, the quality of paper and the whole layout of each pages, just like those who really love hardcover books. So if you encode only the contents of manga, it will never sell.

その他の書籍、例えば、百科事典、地図、電話帳、ガイドブックなど、純粋に情報提供のための出版物は、すでに電子化されており、ケータイから閲覧できるので、「キンドル」は不要だ。
The other kind of books, e.g. encyclopedia, maps, yellow pages and various guidebooks, i.e. information providing books are already turned into numberless websites. Japanese can already search such contents with "Keitai" (mobile phone).

これで、「キンドル」が新し物好きのおもちゃとしてしか売れないことは明らかだろう。
As written above, Amazon Kindle will sell only for neophilia in Japan.

というより「キンドル」に限らず、書籍を電子化し、専用端末へ配信するサービスは、少なくとも日本では、ケータイがある限り、大きなビジネスにはなりえない。
In Japan the electronic book itself will never be a big business as far as the context of Japanece "Keitai Culture" exists.

ただ、最後に付け加えるとすれば、いわゆる「ケータイ小説」はどうなんだ、という話がある。たしかに「ケータイ小説」は成功している。

電子書籍がケータイで読めるサービスは、ケータイが出始めたころから存在する。

しかし、配信されている書籍にろくなものがなく、かつ、すでに書籍化されているものの電子化なので、読者の需要を度外視した価格設定がされている。

それに対し「ケータイ小説」は、ケータイだけのために書かれ、読者層（大多数は若い女性）のニーズに合った内容だ。

後に書籍化される場合でも、最初にケータイで配信されるときは、おそらく筆者がプロであっても、流通コストがかからないため、配信価格を低くおさえられるのだろう。

それに、現実には「ケータイ小説」全般が成功しているのではなく、一部の「ケータイ小説」が成功しているだけだ。

別に、小説がケータイで読まれることが普通になったわけではない。相変わらず、小説は紙の書籍で読まれるのが普通だ。

一部の「ケータイ小説」の成功は、小説のネット配信時代の到来を告げるものでもはない。まして「キンドル」のような電子書籍端末の成功を予告するものでもない。

以上が、紙の書籍とケータイが存在する限り、「キンドル」のような電子書籍端末が、絶対に日本で成功しない理由だ。

（ところで、ブラックベリーなどのPDAが売れない理由は、iPhoneのように、PSPやDSと同じカテゴリのゲーム機として使えないからだ。日本では、遊びに使えないPDAは絶対に売れない）

では、「キンドル」のような電子書籍端末が、日本で絶対に成功しないと断言できるのに対して、なぜiPodは成功し、日本の音楽業界を激変させたのか？

それについては、回を改めて書くことにする。

twitterで「何ができないか」を書いてくれ！

ＩＴ業界って「Web2.0はすごい！」「オープンソースの電話交換ソフトはすごい！」「twitterはすごい！」などなど、素朴な新しモノ好きの、浅はかな発言があとを絶たない。

その背後に何があるのか、考えてみると、一人の人間が使えるリソースは有限だ、という認識が欠けていることだ。

ここでいうリソースとは、時間、知能、知識、体力、人脈、性格、信念などなど、僕らが日常生活をするときに、意識して、あるいは無意識に利用している、あらゆるものを含むことにする。

例えば、一人の人間が使える時間、知識、体力は、言うまでもなく有限だ。違法なクスリでも使えば、ちょっとは増やせるかもしれないが（笑）。

個人の性格や信念といったものも、そう簡単には変わらないという意味で有限と見なせる。

性格や信念といったものは、その人の持っている人脈など、周囲の環境や人々とどのように接し、どのような結果を出すかを、大きく左右する。

そして、これらのリソースは、人によって大きな差がある。

例としてあげるのは申し訳ないが、瀕死の状態の方もいるし、そこそこ健康な人もいるし、健康でも他人と適切な意思疎通ができない人もいるし、天才と呼びたくなるような人もいるし、などなど...。

「twitterはすごい！」と能天気に書いてしまう素朴な新しモノ好きには、人々の間にある、こうした残酷なリソースの格差が見えていない。

「twitterは面白い！」と能天気に書く人は、そう書いているとき、自分と同じようにtwitterを楽しんでいる人々のことしか考えていないという、自分の認識範囲（これも一つのリソースである）の限界を忘れてしまっている。

Web2.0でもtwitterでも何でもいいのだが、何かをすごい！と言うためには、まず自分のリソースの限界を認識し、それによって、Web2.0やtwitterの限界を語る必要がある。

つまり、「twitterで何ができるか」をいくら訴えたところで、「それはあんたが×××だからでしょ」と、発言者自身の持っているリソースの限界を指さされておしまいだ。

そうではなく、「twitterで何ができないか」をできるだけ細かく記述するのが、適切なtwitterの論じ方である。

Web2.0など、他の新しモノについても同じことだ。

「それを使って何ができるか」ばかりを、自分の知識や見識といったリソースの限界を棚に上げて書き連ねても、まったく説得力がない。

（梅田望夫や勝間和代やITProの記者は、自分の肩書、バックグラウンド、過去の実績などが、自分の書くものに自動的に権威をあたえてくれるとでも思っているのだろうか？）

「それを使っても何ができないか」を記述するには、「それ」（Web2.0でもttwitterでも何でもいい）について、まず「疑う」必要がある。

「疑う」という作業は、人間が本質的にかかえているリソースの有限性を、克服とは言わないまでも、相対化する唯一の手段だ。

そもそも人間はいつかは必ず死ぬ。人間にとって時間というリソースは絶対的に有限である。

本質的に有限な存在である人間が、「疑う」ことを忘れるのは、致命的な誤りだ。

だから僕は、梅田望夫や勝間和代のような「疑う」ことを知らない人々の意見を批判する。

彼らのような人々が言っていることを聞いたら「何ができるか」を記述するのではなく、彼らの言っていることを聞いても「何ができないか」を記述する。

それが、任意の対象について、有限な存在である人間として、より適切な語り方なのだ。

だから、twitterにのめりこんでいる人には、twitterで「何ができないか」を責任をもって記述して欲しいものだ。

特に記者を職業とする人には、ナイーブな礼賛記事を読ませて、読者の有限な時間をムダにさせないでほしい。

MS Office Project 2010の画期的な機能

うむむ、Microsoft Office Project 2010 には「ユーザ管理型スケジューリング」という画期的な機能ができるらしい。詳細は下記のマイクロソフトの公式「Microsoft Project Team Blog」の記事へ。

'Project 2010:Introducing User-Controlled Scheduling'

これは、プロジェクト計画の初期段階で、各タスクの開始日、終了日を確定できないとき、Project Professional 2010で、開始日、終了日を空白にしたままで、タスクの洗い出しと前後関係の定義だけを行うことができる、という機能だ。

もともとボトムアップ型、部門間調整型で、あいまいなスケジューリングしかできない多くの日本企業にとって、この機能はかなり有用だろう。

また、親タスクの開始日と終了日は、上層部の意向で決定したが、その中身の、個々のサブタスクに、それぞれ何日かかるのか分からない、なんてこともよくある。

下手をすると、サブタスクどうしに前後関係を定義した後、所要日数を積み上げてみたら、親タスクの終了日を大幅にオーバーした、なんてことも。

Project Professional 2007までは、親タスク（サマリータスク）は、常に自動的にサブタスクのうち、もっとも早い開始日と、もっとも遅い終了日に設定されていた。

ところが、Project Professional 2010で、Projectのプロパティーを「手動スケジュール」モードにすると、親タスクの開始日・終了日を固定したまま、サブタスクの積み上げが予定オーバーするのを許しているのだ。

このとき、親タスクを示すガントチャートのバーが赤色に変って、サブタスクのお尻が、親タスクの予定終了日をオーバーしていることを知らせてくれる。

さらに、前後関係をつけたタスクの日程の「ダブり」が許される。

Project Professional 2007までは、タスクどうしをリンクして前後関係をつけると、先行タスクの終了日を遅らせると、自動的に後続タスクの開始日がズレる。

しかし、Project Professional 2010の「手動スケジュール」モードでは、自動的にズレずに、赤の波線で警告が表示されるだけになる。

そして、いよいよサブタスクまで開始日・終了日が確定したら、該当するタスクだけを選択して、「自動スケジュール」モードに切り替えることもできる。

そうすると、リンクされているタスクや、親タスクの開始日・終了日は、Project Professional 2007までと全く同じ動きで、自動調整される。

いやぁ、この「手動スケジュール」って、なかなか良さそうな機能だ。

特に、最後の段階まで、なかなか意思決定ができない日本企業にとっては。

twitterをめぐるバカ騒ぎに既視感

twitterの何がいったい革新的なのか、まったく分からない。１日にブログを数十回更新する人がいたら、それはすでにtwitterだろう。

ITProの記者が「Twitterの便利さと、オープンであること」という記事を書いている。

だが、情報収集を口実に、会社で堂々とtwitterのフォローができるのは、出版社ならでは。

発信する側だって、日常の些細な出来事を、日中に延々とtwitterでつぶやけるのは、きわめて限られた職種だ。

モバイル環境でtwitterを利用するといっても、国内の携帯電話なら、すでにmixiやモバゲーやGREEなど、先行のSNS業者が1,000万単位のユーザーを獲得済み。

twitterは、まだ国内では100万ユーザーにさえ届かない。日本のケータイ文化の世界では、マニアのおもちゃの域を超えていないし、これからも超えないだろう。

こんな状況で、「twitterをフォローしていれば、初対面でもいきなり本題に入れる」など、上述のITProの記者が書いているtwitterの利点を享受できるのは、ごく限られた人たちに過ぎない。

まして、人身事故で特定の電車路線が使えなくなったとき、他のどの路線がすいていそうとか、そんなtwitterのつぶやき情報は、首都圏に勤務する会社員にしか当てはまらない。

東京中心主義を相対化できないような人間が、日経新聞子会社の記者にならないで欲しい。

他方のmixiやモバゲーやGREEのユーザーは、地方の携帯電話ユーザーも獲得している。

mixiやモバゲーやGREEが「国産」サービスで、良くも悪くも日本的なコミュニケーションの文脈に依存することで、利用者を獲得しているのに対し、twitterは、所詮、米国のものだ。

日本では開放的ななコミュニケーション基盤を作ったって、遅かれ早かれ、閉じられた島宇宙に細分化する。

そして、それぞれの島宇宙の中でも同調圧力がはたらき、「真の鬼束ちひろファンとは？」などといった不毛な議論が始まる。

坂本龍一、オバマ大統領、ホリエモンが使っていることが、売りになるかのような言説がネットに流布している時点で、そうとうイタイ。

「米国発なら何でも良い」という名誉白人的な臭いがぷんぷんする。

新しモノ好きの無反省なヒマ人には困ったものだ。

経済格差の進んだ日本社会で、twitterを使うことが「勝ち組」であるかのように喧伝する言説には、既視感をおぼえる。

梅田望夫的言説に対する反省から、誰も何も学んでいないのだろうか。

ネットは基本的にバカと暇人のものであって、そうでない人たちだけが、米国発の、ちょっと頭が良さそうで先進的なお遊びであるtwitterに喰い付いている。

それだけのことだ。下らない。実に、下らない。

梅田望夫氏は、すでに過去の人物である

読者の方から、梅田望夫がまたおかしなことをしゃべっているというメールを頂いた。

『日本のWebは「残念」 梅田望夫さんに聞く』というIT Media Newsのインタビュー記事だ。

このインタビューの中で梅田望夫氏は、中川淳一郎著『ウェブはバカと暇人のもの』（光文社新書）を「まだ全部は読んでいない」が、「彼の書き方はフェアだ」と感じていると話している。

中川淳一郎氏は『ウェブはバカと暇人のもの』の中で、梅田望夫の『ウェブ進化論』は「頭の良い人の世界」であり、自分が書くのは「普通の人とばかな人の世界」だと明記している。

梅田望夫氏は、この点を「彼の書き方はフェアだ」と言っているのだろう。

しかし、これを読むにつけても、梅田望夫という人物は、どこまで無自覚なエリートなんだろうかと実感する。（まさに勝間和代氏のように）

中川淳一郎氏の議論が「フェア」なら、梅田望夫氏の『ウェブ進化論』はまったく「フェア」ではない。

『ウェブ進化論』は、普通に読めば、インターネットは、より多くの人に、情報資産の共同産出の機会を均等に与えると書いてある。多くの人がインターネットに参加することで、より良い社会が実現されるという希望の書として書かれている。

だから「進化」や「革命」といった、ナイーブな弁証法的歴史観（＝歴史は失敗をくりかえしながらも、だんだんと良い方向へ発展していくと信じる考え方）を連想させる言葉が使われている。

梅田望夫氏はそれを今になって、「あの『ウェブ進化論』は、たしかにごく一部の頭の良い人たちについて書いたものだった」と、あっさり認めているのだ。

仮に、『ウェブ進化論』を書いた当時、梅田望夫氏が、ネットの進化によって、「バカと暇人」が「頭の良い人」に進化する可能性があると信じていたのだとしたら、梅田望夫氏のナイーブさには言葉を失う。

そうではなく、梅田望夫氏が、無意識のうちに「頭の良い人」たちだけを想定して『ウェブ進化論』を書いたのだとしたら、やはりそのナイーブさには言葉を失う。

この場合、もう梅田望夫氏の発言は傾聴に値しない。所詮、エリートの自己満足に過ぎないからだ。自分がエリートであることを自覚していないエリートの発言は、中川淳一郎氏のいう「バカと暇人」のネットへの無反省な書き込みと大差ない。

３つめの仮定として、梅田望夫氏が、実は「頭の良い人」たちだけを想定しつつも、まるで「バカや暇人」も参加できるかのような扇動として『ウェブ進化論』を書いたのだとしたら、悪意を感じざるを得ないだろう。

つまり、若者に対して「夢をあきらめるな！」と扇動して、大量のフリーターや派遣労働者を生みだすのと大差ないということだ。

まぁでも、梅田望夫氏は、すでに過去の人である。

日本のまともなインターネット観察者は、梅田望夫氏が、実は単なるアメリカかぶれの「とんでも批評家」の部類に入る書き手であることを分かっている。

『ウェブ進化論』も、小泉・竹中改革の生んだ格差社会の、インターネットにおける追認作業だと総括してしまえば、すでに過去の遺物、歴史的文献である。

ITMediaを含むネットメディアや出版業界も、これからは梅田望夫氏をあまりまともに取り上げないだろう。

氏の発言は、何の批判的切り口もない、単なる「頭の良い人」の自己満足であることが、すでに明らかになってしまったのだし、梅田望夫氏自身、それを認めているのだから。

安くて管理も楽な、企業向けの携帯から社内メールを読むツール

仕事の関係で、携帯電話から社内メールが読めないかと、いろいろな製品を比較したが、結論として「CACHATTO（カチャット）」になった。

CACHATTOポータルサイト

東レからスピンアウトしたベンチャー企業「いいじゃんネット」社の開発したLinuxベースの製品だ。

ずばり、長所は以下のとおり。

■ファイアウォールに穴を開けなくていい

ファイアウォールに外部から社内へのインバウンドの穴を一切開けなくていい。社内から外部へSSLのポートさえ開いていればよい。

多くの企業は、社内から社外のウェブサイトへ、SSL（https）でのアクセスすることを許可しているはずなので、「CACHATTO」ファイアウォールの設定変更が不要だ。

■社外にデータを置かなくていい

社外のサーバーに社内のメールデータを蓄積する必要がない。携帯電話からの接続先にあたる、「CACHATTO（カチャット）」のアクセスポイントは「いいじゃんネット」社が24時間365日監視しているが、単に携帯電話からのリクエストに応じて、社内メールサーバからデータを受け渡すだけなので、メールデータを蓄積することはない。

■ワンタイムパスワード機能がついている

携帯電話からアクセスするとき、マトリックス式のワンタイムパスワード機能が標準で付いている。わざわざ別にワンタイムパスワードの仕組みを導入する必要がない。

セキュリティレベルが低くても許される企業なら、この機能はOFFにできる。

■携帯電話の端末ＩＤ認証ができる

携帯電話の端末ＩＤ認証を強制することができる。つまり、ふつうのパソコンのウェブブラウザからの接続を拒否できる。

もっとも、端末ＩＤ（製造番号）を偽装するようなソフトをインストールしたり、iモードのエミュレータを使えば、ふつうのパソコンからでも接続できる。

しかし、そういう場合は、ユーザーごとに許可する端末ＩＤの個数を設定できてしまうので便利だ。

つまり、各ユーザーにつき、ある特定の１台の携帯電話からしか接続させない、という設定ができる。

■社内に立てるサーバーは最新パソコン程度の性能で十分

「いいじゃんネット」社の管理するアクセスポイントに対して、社内からSSLで接続するサーバを構築する必要があるのだが、このサーバーに要求される性能は、もちろんユーザー数にもよるけれど、最新のパソコン程度の性能で十分。

保持するデータはユーザーなどの各種設定情報や、テキスト形式のログファイルくらいなので、ディスク容量も最新のパソコン程度で十分。とにかく安く始められるのが良い。

■端末を選ばない

国内で販売されている第三世代の携帯電話なら、全キャリアのほぼ全機種で使える。ブラックベリーのように、端末が限定されることがない。

■英語対応

ログイン画面やメニューがすべて英語対応している。ブラウザの言語設定が英語になっていれば、自動的に英語表示になる。ユーザーごとの設定で、表示言語を日本語・英語のどちらかに固定することもできる。

もちろんメールの中身が英語でない言語の場合、携帯電話端末が英語以外の表示に対応しているかどうかの方が、問題になってくる。

海外拠点での仕様に耐えうるかどうかは、導入時に販売会社とよく相談した方がよい。

以上のように、構築がお手軽で、アクセスポイントのメンテナンスは「いいじゃんネット」にお任せでき、管理も楽。

しかも、設定次第では、セキュリティ・レベルを非常に厳しく設定でき、ＩＳＭＳ等の情報セキュリティ認証取得企業でも安心して導入できる。

ブラックベリーのように、専用端末を購入する必要もなく、社員がすでに持っている携帯電話で使える。

こんな便利でセキュアなしくみ、もっと爆発的に売れてもいいと思うのだが．．．。

宮台真司氏、Twitterに対する楽観的すぎる反応

宮台真司さえ、最近ビデオニュース・ドット・コムで「Twitter」にハマっていると言うようになった。

僕は話題が何であれ、宮台真司の鋭い問題点の指摘や、その論旨には大いに賛成だ。

ただ、この手の新しいツールに対する宮台真司の反応は、実に「おやじ臭い」。

梅田望夫的ナイーブさがある、と言い換えてもいい。

日本の若者は、すでにモバゲーなどの携帯サイトや、携帯電話のSMSなどで、短いメッセージで、ほぼリアルタイムの連絡をとりあうことに慣れている。

なので、日本の若者（といっても３０代まで含まれるだろうが）に、はっきり言ってTwitterは不要だ。

日本でTwitterを使うのは、ちょうど宮台真司氏のように、情報感度が高く、情報リテラシーが高く、会社員と違って時間を自由に使える、一部の人々に限定される。

ふつうの若者は、いちいちパソコンを起動しなければいけないTwitterよりも、当然、携帯サイトを使い続けるだろう。

僕個人としても、Twitterにはまったく魅力を感じない。

一度、Twitterからこのブログ「愛と苦悩の日記」にトラックバックを受けたことがある。

けれど、僕は一つの話題についてきっちり語るためにブログをやっているので、たった100文字程度のTwitterからのトラックバックには、返答のしようがない。

また、ソフトバンクのホワイトプランのように、携帯電話の通話料金に定額制があることも、日本でのTwitterの普及を妨げるだろう。

新しいネット上のサービスに、梅田望夫的に、ナイーブに反応するのは見苦しいのでやめた方がいい。

僕は過去、日本ではBlackBerryは、米国のようには絶対に流行しないと断言したが、実際ユーザー層が、iPhoneのように広がる気配はまったくない。

Twitterも同じで、ごく一部の人々のおもちゃになって、それ以上ユーザー層が広がることは絶対にないと断言できる。

モバゲーの柴田淳の日記を一括ダウンロードするプログラム

最近、すっかりシンガーソングライターの柴田淳の曲にハマってしまっている。

ところで、柴田淳は公式サイトの他に「モバゲータウン」にも日記を書いている。

「モバゲー」の日記の方が、柴田淳の日々の気分の浮き沈みがよく分かるので、まとめて読みたいと思った。

「モバゲー」はパソコンのウェブブラウザからも読めるが、ページ繰りが面倒なので、一括ダウンロードしたい。

そこで以下のようなVBScriptのプログラムを書いてみた。
Windows XP、Windows Vistaなら動くはずだ。

柴田淳だけでなく、モバゲータウンの他の有名人の日記にも使える。

ただしあくまで2009/06/24時点の話。モバゲータウンの画面レイアウトが変わったら使えなくなるので要注意。

まず、ここを右クリックして「対象をファイルに保存(A)...」をクリックし、デスクトップなどに、そのままの「GetAllMBGADiary.vbs」というファイル名で保存する。

保存したファイルをWindowsのメモ帳で開く。

いちばん上にある「Const MBGA_USER_ID = "16782171"」という行の数字の部分を、日記を一括ダウンロードしたい有名人のユーザ番号に書き換えて保存する。

ユーザ番号を調べるには、パソコンのウェブブラウザで、その有名人のプロフィールを開き、アドレスを見るとよい。

柴田淳なら「http://www.mbga.jp/.pc/_u?u=16782171」となっているので、「16782171」がユーザ番号だと分かる。

次に、Windowsのメモ帳を起動し、下記の１行を貼り付けて、「start.bat」などの名前で、上記のプログラムファイルと同じ場所に保存する。

cscript.exe .\GetAllMBGADiary.vbs //I

この１行だけでよい。

あとは、この「start.bat」というアイコンをダブルクリックすれば、プログラムが走り出す。

日記の量や、パソコンの性能にもよるけれど、20分くらい待てば、ファイルと同じ場所に「MBGADiary.txt」というファイルができあがる。その中に、今までの日記がすべてダウンロードされている。当然、顔文字はすべてなくなる。

．．．僕はなんてヒマなんだろうか。

でも柴田淳のバラードが良い曲ばかりであることに変わりはない。すでに『Single Collection』の全１１曲はYouTubeでカバーし終えた。どれも素晴らしいメロディー。素晴らしい歌詞。

Two Serious 'Specs' of MS Office Project Server 2007

I can't understand why no company seems to complain about serious 'bugs' of Microsoft Office Project Server 2007.

My company is now trying to update Microsoft Project 2002 suite (i.e. Project Server, Project Professional and Project Web Access) to 2007 Service Pack 2. However, we found two serious 'bugs' as follows.

Let's call Project Professional simply 'Pro' and Project Web Access 'PWA'.

Bug-1: When team members input the actual working hours of any assigned task through 'My Tasks' page on PWA2007, the planned working hours, planned start date and planned end date are also automatically modified based on the value of inputted actual working hours, in case the tasks are with 'weak constraint', i.e. default constraint setting of a task.

Bug-2: When project managers update the planned working hours, planned start date and planned end date of a task and publish it by Pro2007, it is applied only to 'Project Center' page on PWA2007, not applied completely to 'My Tasks' page on PWA2007. As a result, no team members can clearly recognize the task updates by project managers.

I'd like to explain these 2 'bugs' more in detail.

Concerning Bug-1, you might think it's not a bug but a reasonable spec because weak-constraint tasks work like that by definition.

However, let's imagine how the weak-constraint tasks work in a real project management.

Team members are expected to input their acutual working hours, e.g. on daily or weekly basis. And everytime they input their actual working hours, the planned working hours, planned start date and planned end date of each task are continuously changing.

Let's call such various planned aspects of a task 'task plan'.

The everyday input of actual working hours by each members continuously change the task plan without being recognized by project managers who published those tasks.

When can project managers recognize such 'unintentional' changes of task plan?

Team members 'submit' their input of actual workin hours to project managers through 'My Tasks' page of PWA2007 and project managers receive e-mail notices.

Then project managers open PWA2007 'Task updates' page and 'approve' and 'publish' the actual working hours inputted by team members.

At this moment project managers still don't recognize how the original task plan they planned and published is changed by team members' input of actual working hours, based on the 'weak constraint' rule.

Project managers launch Pro2007 and check the property of each task. At last they recognize how the origianl task plan is changed.

Let's suppose that a project manager assigns a task which starts July 1 and ends July 15 to a team member. But the team member could start the task only on July 16.

So the team member inputted some working hours for the task on July 16.

As a result, based on 'weak contraint' definition, the start date of the task is automatically changed into July 16.

The end date is also automatically changed into some day depending upon how many actual working hours the team member inputted on July 16.

The same thing happens to all team members. This means that almost all task plans are changed in an unexpected way.

If project managers want to bring back such unintentional changes of task plan into the original task plan they planned, they have to re-input the task plan of all the affected tasks with Pro2007 and publish them again.

But I'm sorry this doesn't help project managers.

Even if project managers re-input the original task plan and publish them by Pro2007, it is applied only to PWA2007 'Project Center' page, not completely applied to 'My Tasks' page of each team member.

This is how Bug-2 works as I described above.

Let's summarize what on earth happens when Bug-1 and Bug-2 work together.

By the definition of 'weak constraint', the original task plan by project managers is continuously modified every time team members input their auctual working hours to assigned tasks.

In order to recognize such unintentional modifications of task plan, project managers have to 'approve' and 'publish' all the inputted actual working hours.

As a result, the original task plan is overwritten at random and thrown into a chaotic situation.

So project managers have to re-input their original task plan and publish it again through Pro2007.

However, because of Bug-2, the publishment is only applied to PWA2007 'Project Center' page to which team members usually don't pay attention, and NOT completely applied to 'My Tasks' page to which team members input their actual working hours every day.

This means that team members continue inputting their actual working hours based on a continuously modified task plan which cannot be corrected by any means just as project managers would like to correct.

In a word, in the environment of MS Project Server 2007 suite, the task plan recognized by team members through PWA2007 'My Tasks' page and the task plan planned by project managers through Pro2007 will never meet forever. Conversely the difference between them is continuously widening.

Of course, Bug-1 can be easily 'fixed' by changing all the tasks into constraints other than 'weak constraint'.

However, regarding Bug-2, what can we do?

I suppose that the synchronization between the back-end database tables of 'My Tasks' page and those of 'Project Center' doesn't work well.

I already reported these problems to Microsoft technical support in Japan (because I'm Japanese and working in a Japanese company) but they insist that they are the 'specs' of Microsoft Office Project 2007 suite.

So our company's decision is like this.

We will not use Microsoft Office Project 2007 for the purpose of project management any more. We will use it only for the purpose of totalizing and analyzing the actual working hours of team members.

When we used Project 2002 suite, we had no problem like this.

I wonder why Microsoft developed version 2007 of Project suite.

日経サイトで元通産官僚が「アニメの殿堂」を堂々と擁護

日経BPの「IT+PLUS」というサイトに「とんでも記事」を発見！

梅田望夫につづく「とんでもＩＴ論客」あらわる、か？

「アニメの殿堂」ほど正しい予算の使い方はない

筆者は、慶応大学デジタルメディア・コンテンツ統合研究機構准教授、かつ、エイベックス取締役の、岸 博幸という人物らしい。

まず、この岸博幸氏のコラムの最後の部分は正しい。

「日本を悪くしているのは官僚だけではない。政治の貧困がそれを加速しているのである。」

ただし、その直前の「今回の「アニメの殿堂」騒ぎを見て、改めて財務省が可哀想になってしまった」という部分は完全に誤り。

岸博幸氏が官僚に同情的なのは、岸博幸氏が1986年に当時の通商産業省に入省した元官僚だからだ。

元官僚が、官僚に同情的なことを書く。こんな見え見えのコラムを、よく臆面もなくインターネットに書けるなぁと感心する。よほど周囲の自分に対する評価に鈍感な人なのだろう。

このコラムの論旨は、例の「アニメの殿堂」といわれている「国立メディア芸術総合センター」に117億円の予算を付けることを擁護するものだ。

岸博幸氏の言うように、たしかに「世界が評価するアニメやマンガを体系的にアーカイブし、その歴史や資産をちゃんとまとめた場所がない」だろう。

しかし、それに対する最適な政策が、「アニメの殿堂」を117億円かけて建設し、かつ、建設後の維持管理費に税金を投入し続けることかどうか、この記事の中では全く検証されていない。

岸博幸氏はこう書いている。

「民主党はむしろ、政府の対応が遅かったことを問題視すべきではなかったか。「国営マンガ喫茶」というネーミングの妙には敬意を表するが、やはり問題の本質を外していると言わざるを得ない」

問題の本質を外しているのは岸博幸氏の方である。

仮に岸博幸氏自身が書いているように、

「アニメやマンガは単なる娯楽ではない。今や文化なのである。文化である以上、政府が維持・保護・発展に関与するのは当然である」

というのなら、アニメや漫画のアーカイブをいわるゆ箱モノで実現するという政策は、「問題の本質を外していると言わざるを得ない」。

まず、アーカイブなら箱モノを作らなくても、電子的に構築できる。

ところで岸博幸氏は、「慶応大学デジタルメディア・コンテンツ総合研究機構准教授」らしい。

ならば真っ先に日本のアニメ・マンガのデジタルアーカイブをネットの仮想空間上に構築し、たとえばNPO法人にその運営を委託するなどの発想が出て来てしかるべきだろう。

その方が、少ない予算（つまり税金）で、より効率的・効果的に、世界中に日本の「文化」を発信できる。また、箱モノを建設するよりも、維持費ははるかに少なくて済む。

そんなまっとうな提案さえできないで、なぜ「慶応大学デジタルメディア・コンテンツ総合研究機構准教授」がつとまるのか教えてほしい。

「アニメの殿堂」を批判しているということで、民主党を批判するのは、お門違いもいいところだ。

こんな低級なコラムを慶応大学准教授という肩書つきで、ネット上のメディアに堂々と発表して、岸博幸氏は恥ずかしくないのだろうか？

Excelの色付きセルで表現したガントチャートを図形に自動変換するマクロ

とってもマイナーな話題で申し訳ない。

Excelを使って、作業日程の管理のためにガントチャートを作るというのは、よくある話だ。

そのとき、図形（長方形）でガントチャートのバーを描く人と、シートの列幅を狭くして、セルに色を塗ってガントチャートのバーを描く人の、２種類に分かれるだろう。

もしそのガントチャートで、１週間、１か月などの期間の区切りを、セルの罫線を使って表現している場合、セルに色を塗ってバーを描く「セル派」の人は、やや面倒なことになる。

大幅な日程の組み換えがおこったとき、いちいちセルの色を一つひとつ、無色にしたり、色をつけたりする地道な作業が発生するからだ。

というのは、セルの書式を一括して変更しようとすると、罫線まで変更されてしまう。期間の区切りを表現する罫線を残したまま、セルの色だけを一つひとつ変更していくのは、やや面倒な作業だ。

そういう場合は、最初から図形（長方形）でバーを描いておいた方が、はるかに楽である。マウスでドラッグ＆ドロップして、バーの長さを伸ばしたり縮めたりするだけで、大幅な日程の組み換えにも対応できるからだ。

※もちろんMicrosoft Office Project Professionalがあれば、最初からそれを使って日程計画を立てるのが最適な方法だが。

そこで、「セル派」の人が作成したガントチャートを、自動的に図形に描き換えるマクロを考えてみる。

要は、同じ行にある、連続する色付きのセルを、１個の図形（長方形）に変換するマクロだ。

最初に、ガントチャートのあるExcelのWorksheetオブジェクトを、あらかじめxSheetという変数に代入しておくとする。（以下、Excel 2007を前提とするがExcel 2003でも動くはず）

Set xSheet = Thisworkbook.Sheets("[ガントチャートのあるシート名]")

あるセルに色がついているかどうかの判別はかんたんだ。

Rangeオブジェクト（Cellオブジェクト）のInterior.Pattern属性が xlNone なら色なし、xlNone以外なら、何らかの色がついていることになる。

If xSheet.Cells(行数, 列数).Interior.Pattern <> xlNone Then
     ' ここに色付きセルの場合の処理の内容
End If

ただ、「連続する色付きのセル」という部分の自動判別は、やや面倒だ。

各行のセルを、いちばん左のＡ列から右へ１つずつ調べていくが、そのとき、直前のセルを変数に保持しておく。

（Ａ）現在のセルに色があれば、「連続する○○色のセル地帯に突入しました！」という意味のBoolean型の変数にTrueを代入する。

このBoolean型の変数名を bInProcess と名づけておく。

（Ｂ）現在のセルに色がないか、現在のセルと直前のセルの色が違う場合は、「連続する○○色のセル地帯から抜け出しました！」という意味でbInProcessにFalseを代入する。

ミソは、上述の二つのIf文を、（Ｂ）（Ａ）の順に記述する点だ。

そうすると、色付きという意味では連続しているが、途中で色が切り替わる場合も、正確に図形（長方形）に変換できる。

次に連続するセルの左端と右端、上下の高さに、図形（長方形）の大きさをきっちり合わせる方法だが、これは比較的かんたん。

仮に開始位置のセルオブジェクトを、xStartCellという変数に代入し、
終了位置のセルオブジェクトを、xEndCellという変数に代入したとする。

連続するセルの左端は、xStartCell.Left
連続するセルの幅は、xEndCell.Left + xEndCell.Width - xStartCell.Left
連続するセルの上端は、xStartCell.Top（xEndCell.Topでも同じこと）
連続するセルの高さは、xStartCell.Height（xEndCell.Heightでも同じこと）

この４つの数値が分かれば、あとは次のようにすれば、連続する色付きセルときっちり位置を合わせた長方形を描画できる。（描画した長方形オブジェクトは xShape という変数に代入するとする）

Set xShape = xSheet.Shapes.AddShape(msoShapeRectangle, 左端, 上端, 幅, 高さ)

セルの位置と図形の位置との間では、単位変換の必要はない。そのままの値が使えるので便利だ。

次に、いま描画した長方形に、開始位置のセルと同じ色を塗る。そのとき、図形のFill.ForeColor属性にある、RGB属性を利用するのがミソだ。

xShape.Fill.ForeColor.RGB = xStartCell.Interior.Color

このように図形のRGB属性に対して、セルの内部色を代入しないと、エラーになるので要注意だ。

さらに、期間をあらわす罫線が透けて見えるようにするために、いま描画した長方形を半透明にしよう。

xShape.Fill.Transparency = 0.3

Transparencyは「1」にすると透明、「0」にすると完全に不透明になる。0～1の間で好みによって設定するとよい。

さて、さらに開始位置のセルに入力されていた文字列（たぶんタスク名など）を、この図形上に表示させたいというニーズがあるかもしれない。

残念ながら、図形内に文字列を書き込んだとき、その文字列を図形からはみ出させる設定は、僕が調べた限りでは、マクロ（Visual Basic for Application）では不可能だ。

文字列を図形内部で折り返すか、図形の方を文字列の長さに合わせて自動で大きくなるようにするか、このどちらかしかできない。

ガントチャートのような場合、このどちらも不都合だ。

そのため、ガントチャートのバーを表す長方形の上に、さらに透明な長方形を重ねて、そちらの方に文字列を書き込み、文字列の長さに合わせてサイズを自動変更する設定にするしかない。

文字列を書き込む方の長方形オブジェクトを、仮にxTextBoxという変数に代入するとすると。

Set xTextBox = xSheet.Shapes.AddShape(msoShapeRectangle, 左端 + 6, 上端, 幅, 高さ)

となる。左端にわざわざ「6」を足しているのは、後からマウスでクリックするときに、先ほど描画したバーに対して、少しだけ左にずらしておいた方がクリックしやすいためだ。

文字列を書き込む長方形オブジェクトは、完全に透明にしたいので、下記のように設定する。

xTextBox.Line.Transparency = 1 ' 外枠線は完全に透明
xTextBox.Fill.Transparency = 1 ' 塗りつぶしは完全に透明

後は、開始位置のセルに入力されていた文字列を、そのままこの完全に透明な長方形内部に記入する。

ここでのポイントは、xTextBoxオブジェクトのTextEffect属性を利用することだ。

With xTextBox.TextEffect
    .Alignment = msoTextEffectAlignmentLeft
    .FontName = "MS UI Gothic"
    .FontSize = 10
    .FontBold = msoTrue
    .Text = xStartCell.Text
End With

xTextBox.TextFrame.AutoSize = True

Alignment属性では、文字列を左詰にしてある。FontNameやFontSize、FontBoldあたりは、好みに合わせて変更して頂きたい。

xTextBox.TextEffect.Text = xStartCell.Text とすれば、セルに入力された文字列を、そのまま図形（長方形）内部に自動転記できる。

最後に xTextBox.TextFrame.AutoSize = True としているのは、文字列に合わせて、この完全に透明な長方形のサイズを自動的に拡張するためだ。

こうして色付きセルを図形化したら、最後の最後に、もともとの色付きセルの色を消してしまおう。

xSheet.Range(xStartCell, xEndCell).Interior.Pattern = xlNone
xSheet.Range(xStartCell, xEndCell).Value = ""

連続するセルの Interior.Pattern属性 に xlNone を代入してしまえば、セルの色が消える。
また、連続するセルの Value 属性に空文字列を代入してしまえば、セルの中身の文字列もすべて消える。

以上のような考え方でマクロを記述すれば、たとえば下記のようになる。

なお、変換するセルの開始位置、終了位置は、冒頭にグローバル定数としてハードコーディングしている。

また、対象となるワークシートも、面倒なのでグローバル変数にしてしまっている。本来ならMainルーチンからサブルーチンへ参照渡しすべきだけれど。

Option Explicit

Const START_ROW = 1
Const END_ROW = 200
Const START_COL = 1
Const END_COL = 100

Dim xSheet As Worksheet

Sub Main()

    Dim iRow As Integer
    Dim iCol As Integer
    
    Dim xCurCell As Range
    Dim xPreCell As Range
    Dim bInProcess As Boolean
    
    Dim xStartCell As Range
    Dim xEndCell As Range
    
    Dim xShape As Shape

    Set xSheet = ThisWorkbook.Sheets(1)
    xSheet.Activate

    For iRow = START_ROW To END_ROW
    
        bInProcess = False
    
        For iCol = START_COL To END_COL

            Set xCurCell = xSheet.Cells(iRow, iCol)
            
            ' 以下の２つのIf文の順序は変えないこと
            ' （異なる色のセルが連続している場合に正しく長方形に変換できなくなるため）
            
            If bInProcess Then
                If xCurCell.Interior.Pattern = xlNone Or _
                xCurCell.Interior.Color <> xPreCell.Interior.Color Or _
                xCurCell.Interior.Pattern <> xPreCell.Interior.Pattern Then
                    xCurCell.Select
                    Set xEndCell = xPreCell
                    Call AddRectangle(xStartCell, xEndCell)
                    bInProcess = False
                End If
            End If
            
            If Not bInProcess Then
                If xCurCell.Interior.Pattern <> xlNone Then
                    Set xStartCell = xCurCell
                    bInProcess = True
                End If
            End If
            
            Set xPreCell = xCurCell
            
        Next
        
    Next

End Sub

Sub AddRectangle(xStartCell As Range, xEndCell As Range)

    Dim xShape As Shape
    Dim xTextBox As Shape
    Dim iTop As Integer
    Dim iLeft As Integer
    Dim iWidth As Integer
    Dim iHeight As Integer
    
    iLeft = xStartCell.Left
    iTop = xStartCell.Top
    iWidth = xEndCell.Left + xEndCell.Width - xStartCell.Left
    iHeight = xStartCell.Height
    
    Set xShape = xSheet.Shapes.AddShape(msoShapeRectangle, iLeft, iTop, iWidth, iHeight)
    
    With xShape.Fill
        .ForeColor.RGB = xStartCell.Interior.Color
        .Transparency = 0.3
    End With
    
    If xStartCell.Text = "" Then Exit Sub
    
    ' 長方形の少し右にずらして描画する
    Set xTextBox = xSheet.Shapes.AddShape(msoShapeRectangle, iLeft + 6, iTop, iWidth, iHeight)
        
    xTextBox.Line.Transparency = 1 ' 外枠線は完全に透明
    xTextBox.Fill.Transparency = 1 ' 塗りつぶしは完全に透明
    
    With xTextBox.TextEffect
        .Alignment = msoTextEffectAlignmentLeft
        .FontName = "MS UI Gothic"
        .FontSize = 10
        .FontBold = msoTrue
        .Text = xStartCell.Text
    End With
    
    xTextBox.TextFrame.AutoSize = True
    
    Call xTextBox.ZOrder(msoSendToBack)
    Call xShape.ZOrder(msoSendToBack)

    ' もともとのセルの色と文字列をクリアしてしまう
    xSheet.Range(xStartCell, xEndCell).Interior.Pattern = xlNone
    xSheet.Range(xStartCell, xEndCell).Value = ""
    
End Sub

Microsoft Office Project 2007の笑える「新機能」（９）

大規模プロジェクトで、プロジェクトメンバーが100人いたとしよう。

今度はプロジェクト管理者の立場になって想像してみてほしい。

それら100人のメンバーが毎日、PWA2007の「自分のタスク」画面から実績作業時間を入力し、プロジェクト管理者に「提出」する。

100人のメンバーが実績作業時間を入力することで、タスクが初期値の「弱い制約」になっていた場合、入力された実績作業時間に引きづられて、無数のタスクの予定期間や予定作業時間などが、自動的に変更される。

それら、各タスクの予定期間や予定作業時間の変更が、100人のメンバーから一斉にプロジェクト管理者に「提出」されてくるのだ。

プロジェクト管理者としては、実績作業時間をプロジェクト計画に反映させるために、それらを「承諾」「発行」せざるを得ない。

しかし「承諾」「発行」すると、無数のタスクの予定期間や予定作業時間、進捗率などが、一斉に変更されてしまう。

さあ、ここからがプロジェクト管理者の修羅場である。

プロジェクト管理者は、どのタスクの予定期間や予定作業時間が変更されてしまったのかをチェックし、それらをすべて自分の意図どおりの内容にいちいち戻さなければならない。

先ほどの例で、「Plan-1」というタスクの予定作業時間が、自動的に7時間に変更されたものを、14時間に戻したのと同様、他の全てのタスクについても、プロジェクト管理者として最初に立てた計画の内容に、一つひとつ戻していく必要があるのだ。

そして全て修正し終わったら、改めてProject Professionalからmppファイルを「保存」「発行」しなおす。

プロジェクト管理者がこの修羅場的な作業を毎日実施しない限り、PWA2007上で各メンバーが認識している、各タスクの状態と、プロジェクト管理者が認識している状態は、食い違ったままになる。

これはプロジェクト管理者にとって悲劇的な状況だと思うのだが、なぜかMicrosoft Office Project Server 2007 について、少なくとも日本国内で悪い評判はネット上に全く見当たらない。

僕は本当に不思議に思っている。

他にもMicrosoft Office Project Server 2007を、Project Web Accessとの組み合わせで使っている企業があるはずだ。

それらの企業は、これまで長々と説明してきたような、致命的ともいえるPWA2007の使いづらさや問題点を、いったいどうやって克服しているのだろうか？

誰かトラックバックで教えて欲しい。

※この連載はとりあえずこれで一旦終わるが、Microsoft Office Project Server 2007を、より良い製品にしてほしい一心からだ。そうでなければ、これだけ長い時間を割いてこんなエッセーを書くだろうか。

Microsoft Office Project 2007の笑える「新機能」（８）

あなたはメンバーとして実績作業時間を入力し、プロジェクト管理者に「提出」した。プロジェクト管理者はそれを「承諾」「発行」した。

結果、Project Server上のプロジェクト計画（mppファイル）に、その実績作業時間は中途半端なかたちで反映された。

であれば、当然「自分のタスク」画面にも、同じように中途半端に反映されているはずと期待して、あなたは「自分のタスク」画面から、該当のタスク「Plan-1」の「割り当ての詳細」を開いてみる。

それが画面026である。

な、なんと！プロジェクト管理者が「承諾」「発行」する前と、何も変わっていないではないか！進捗率も100%のままだ。

いやいや、先ほど「プロジェクトセンタ」画面で見たサーバー上のプロジェクト計画では、期間は2日間、進捗率は50%になっていた。

プロジェクト管理者がProject Professional 2007で確認しても、やはり期間は2日間、進捗率は50%になっていた。

なのに、プロジェクトメンバーのあなたが「自分のタスク」画面から確認すると、プロジェクト管理者が「承諾」「発行」する前の状態と何ら変わっていない。

これは大笑いというよりも、かなり深刻な事態である。

つまり、メンバーがPWA2007の「自分のタスク」画面で見る各タスクの状態と、プロジェクト管理者がProject Professional 2007で見ているサーバ上のmppファイルの各タスクの状態が、食い違ったままになるということだ。

マイクロソフトによれば、PWA2007の背後にあるSQL Serverでは、「自分のタスク」画面のデータを保持するテーブルと、サーバ上のmppファイルのタスクデータを保持するテーブルは、PWA2007から別テーブルになったとのことだ。

別テーブルになった結果、この２つのテーブルの間で完全に同期をとらない仕様になっていることになる。マイクロソフトのサポート曰く、これもPWA2007の「正しい仕様」とのことだ。

なぜ「正しい仕様」なのかといえば、この不一致を解消する方法があるからだ。

その方法を説明しよう。

プロジェクト管理者が、Project Professional 2007でサーバ上の該当のmppファイルを開き、たとえば上記の「Plan-1」というタスクの予定作業時間を14時間という、初期の値にもどし、「保存」「発行」すればよい。

すると、タスク「Plan-1」は、プロジェクトメンバーが「自分のタスク」画面から確認しても、開始日2009/06/03、終了日2009/06/04、予定作業時間14時間、実績作業時間7時間、進捗率50%という正しい状態になる。

不一致を解消できるならいいじゃないか、と思われるかもしれない。

しかし、現実のプロジェクト管理現場で何が起こるか、よく考えてほしい。

※この連載はしばらく続くが、Microsoft Office Project Server 2007を、より良い製品にしてほしい一心からだ。そうでなければ、これだけ長い時間を割いてこんなエッセーを書くだろうか。

Microsoft Office Project 2007の笑える「新機能」（７）

おさらいしておこう。

あなたは実績作業時間を入力するとき、マイクロソフトの仕掛けた「落とし穴」に見事にはまり、単位をつけずに「7」と入力した。

そのおかげで実績作業時間が7日間、つまり、49時間となり、1日の実働時間7時間をオーバーしたため、タスクの期間が2日間から1日間に自動的に変更されてしまった。

くりかえしになるが、これは「弱い制約」をもつタスクの「仕様」である。マイクロソフトが「仕様」と言い切るのだから仕方ない。

その後、あなたは単位をつけて実績作業時間を7時間と入力しなおしだが、予定作業時間もそれに引きずられて7時間に変わり、タスクの期間は依然として1日間のままだ。

このようにめちゃくちゃな実績作業時間入力が、プロジェクト管理者によって「承諾」「発行」されたら、プロジェクト計画（つまりProject Server上のmppファイル）にどのように反映されるだろうか？

では、答えを見てみよう。画面025をご覧いただきたい。

タスク「Plan-1」は、期間2日間で、予定開始日2009/06/03、予定終了日も2009/06/04のまま。

ただし、予定作業時間は7時間に変更され、実績作業時間も7時間なのに、達成率は50%になっている。

この状態をプロジェクト管理者がProject Professional 2007で確認しても、やはり予定作業時間7時間、期間2日間、実績作業時間7時間だが、進捗率50%となっている。

達成率（進捗率）の計算がおかしくなっている。まさにガーベッジ・イン、ガーベッジ・アウト（＝でたらめなデータを入力すれば、でたらめな結果が出てくる）である。

これもマイクロソフトに問い合わせれば、きっと「正しい仕様」という答えが返ってくるだろう。それでもタスク期間が2日間のまま保持されているだけ、まだましかもしれない。

しかし！

安心するのはまだ早いのである。

あなたはおもむろに「自分のタスク」画面を開いて、タスク「Plan-1」がどうなっているのか、「割り当ての詳細」画面で確認する。

そこであなたは驚愕の光景を目にすることになる。

※この連載はしばらく続くが、Microsoft Office Project Server 2007を、より良い製品にしてほしい一心からだ。そうでなければ、これだけ長い時間を割いてこんなエッセーを書くだろうか。

Microsoft Office Project 2007の笑える「新機能」（６）

PWA2007の画面左端にあるメニューから「プロジェクトセンタ」というメニューをクリックし、「テストのプロジェクト2009」をクリックしてみる。

それが画面020である。上の方にタスク「Plan-1」がある。

あなたは実績作業時間を入力したが、まだ「保存」しただけで、プロジェクト管理者に「提出」していない。

そのため、プロジェクト計画自体は、プロジェクト管理者が最初に「発行」した状態のままになっている。

したがって画面020でも、タスク「Plan-1」は予定期間 2日間、予定開始日 2009/06/03、予定終了日 2009/06/04、予定作業時間 14時間のままだ。

つまり、あなたが「自分のタスク」画面で見るタスク「Plan-1」の状態と、「プロジェクトセンタ」画面で見るタスク「Plan-1」の状態は、まったく違ったものになっている。

この食い違いを一致させるには、入力した実績作業時間をプロジェクト管理者に「提出」し、プロジェクト管理者に「承諾」「発行」してもらえば良いはず。

誰もがそう思うだろう。

ところが、その期待も見事に裏切られる。

画面021は、あなたが入力した作業時間実績を「自分のタスク」画面から「提出」する手順を示している。

「提出」したいタスクにチェックマークを付けて、画面下方にある「選択した内容を提出」というボタンをクリックする。

あなたの作業はここまでだ。

するとプロジェクト管理者に自動でメールが飛んでくる。このあたりは旧バージョンのPWAと同じである。

プロジェクト管理者はPWA2007の「タスクの更新」という画面で、各メンバーから「提出」された実績作業時間を確認できる。

それが画面022だ。

プロジェクト管理者は、タスク「Plan-1」にチェックマークを付けて、「承諾」ボタンをクリックする。

実は、旧バージョンのPWAでは、このあたりの作業はProject Professionalを起動しないとできなかった。PWA2007になって、実績作業時間の「承諾」「発行」作業がPWA2007だけで完結できるようになった。

これは旧バージョンに対する、僕が知る限りPWA2007のたった２つの長所のうちの１つである。

（ちなみにもう１つの長所は、「データ分析」機能で「プロジェクト名」配下の「タスク」までを、分析の切り口として利用できるようになった点。この点については、あまりにマニアックなので説明を省かせていただく）

「承諾」が終わったら、プロジェクト管理者は続いて「タスクの更新」画面の「ジャンプ」メニューをクリックし、「適用された依頼とエラー」をクリックする。それが画面023だ。

すると画面024のように、いま「承諾」したデータが表示されるので、チェックマークを付けてから、「発行」ボタンをクリックする。

すると、あなたが入力した実績作業時間は、プロジェクト管理者によって「発行」され、無事にプロジェクト計画そのものに反映される。

さて、ここで問題です。

あなたの実績作業時間は、もとのプロジェクト計画に、いったいどのように反映されるだろうか？

ここでも大笑いできる状況が発生することになる。

※この連載はしばらく続くが、Microsoft Office Project Server 2007を、より良い製品にしてほしい一心からだ。そうでなければ、これだけ長い時間を割いてこんなエッセーを書くだろうか。

Microsoft Office Project 2007の笑える「新機能」（５）

画面015をご覧いただきたい。

Plan-1というタスクに、あなたは先ほどうっかり「7日間」作業したと入力してしまった。

そのマス目にマウスポインタを当ててみると、「予定作業時間 49時間」と出てくる。

あれ？さっきは「予定作業時間 7時間」だったはずでは？

あなたはおそるおそる、Plan-1というタスク名をクリックし、「割り当ての詳細」という画面でこのタスクの詳細情報を見てみる。

それが画面016だ。

画面中央にある格子状（グリッド）部分をご覧いただきたい。

6月3日水曜日部分が、作業時間 49時間、実績作業時間 49時間となっている。

実績作業時間は確かにあなたが入力したものだ。たとえ単位を間違って入力したとしても、まあ後で修正すればいい。

しかし、なぜ予定作業時間までが勝手に49時間に変わっているのだ！？

プロジェクト管理者でもないのに、タスクの予定作業時間までが勝手に変わってしまっている。

実はこの「Plan-1」というタスク、プロジェクト管理者が最初に「発行」したときは、6月3日～4日の2日間にわたる予定作業時間14時間のタスクだった。

その予定作業時間が49時間というとんでもない数字に勝手に変わったばかりか、タスクの期間までが勝手に2日間から1日間に変更されてしまっているではないか。

マイクロソフトによれば、Project Professional 2007でタスクを作成したとき、初期状態では「弱い制約」のタスクとなるので、メンバーが入力した実績作業時間にひきずられて、タスクの予定期間や予定作業時間が勝手に変わるのは「仕様として正しい」のだそうだ。

マイクロソフトに「それが仕様だ」と言われては、言い返すことばもない。

仕方ないので正しい実績作業時間を入力し直すことにしよう。

画面017のように、今度は時間を表す単位「h」をつけて「7h」と入力し、画面下方にある「すべて保存」ボタンをクリックする。

その結果が画面018である。

予想どおり、こんどは予定作業時間が「7時間」に変わっている。マイクロソフトの言う「仕様」どおり、あなたが入力した実績作業時間に引きずられて、タスクの予定作業時間はころころ変わっていく。

念のため「割り当ての詳細」画面でタスク「Plan-1」の詳細を確認してみよう。

それが画面019だ。

やはりタスクの予定期間は1日間のまま、予定作業時間は7時間に変わっている。

そしてプロジェクト管理者は、自分の設定したタスクの予定期間や予定作業時間が、こうしてどんどん変わっている事実に気付いていない。

ここで、PWA2007の画面左端にあるメニューから「プロジェクトセンタ」というメニューをクリックし、タスク「Plan-1」の状態を確認してみよう。

すると、面白いことが確認できる。

※この連載はしばらく続くが、Microsoft Office Project Server 2007を、より良い製品にしてほしい一心からだ。そうでなければ、これだけ長い時間を割いてこんなエッセーを書くだろうか。

自分自身のための備忘録

忘れないように自分のブログに書いておくことにしよう。
（何を忘れないようにするためかは秘密）

■秀丸エディタをインストールし、インストール時に、Internet Explorerのソース表示・ソース編集用アプリケーションとして設定する。

■GOM Playerをインストールした後、GOM Playerを起動して[F5]キーを押す。

「環境設定」画面が出てきたら、「その他」をクリックし、「関連付け」タブですべての拡張子を選択し、GOM Playerに関連付ける。

■某社の某SNS（ソーシャル・ネットワーク・サービス）の「マイページ」に自分が録音した曲が掲載されたら、Internet Explorerでソースを表示させる。

そして録音したそれぞれの曲に付与された番号をメモしておく。

■その「マイページ」から自分が録音した曲を、どれでもよいのでクリックする。

■するとその曲をストリーミング再生するページに移動するので、そのページのソースを表示させる。

さきほどメモした番号で、そのソースを全文検索すると、その番号の録音を再生するメタファイルを取得するためのURLが見つかる。

■そのURLへのリンクを自作したHTML文書を作成し、Internet Explorerで開く。

■個々のリンクをクリックすると、「保存」「キャンセル」の２つのボタンのあるダイアログが開き、拡張子WVXファイルのダウンロードが開始されるので、「保存」ボタンをクリックして、いったんデスクトップなどに保存する。

■保存したファイルを右クリックして、「プログラムから開く」をクリックし、「既定のプログラムの選択」をクリックする。そして、既定のプログラムとして、秀丸エディタを設定する。

これで拡張子WVXファイルが、秀丸エディタとGOM Playerの両方に関連付けられる。

■さきほどInternet Explorerで開いた自作のHTMLで、もう一度、同じリンクをクリックすると、今度は「保存」「開く」「キャンセル」の３つのボタンのあるダイアログが開くので、「開く」をクリックする。するとWVXファイルが秀丸エディタで開く。

■秀丸エディタで開いたWVX内には、録音したWMA形式ファイルに直接接続できるURLが埋め込まれているので、これをコピーして、別途作成したテキストファイルに貼り付ける。

■すべての録音ファイルについて同様のことを繰り返し、完成したテキストファイルを、某ストリーミングファイル・ダウンロード用フリーウェアに「LIST読込」させ、ダウンロードを開始すると、すべての録音ファイルが一括してダウンロードされる。

以上、わかる人にはわかるし、わからない人には、何のことかさっぱりわからないだろう。ごめんなさい。

Microsoft Office Project 2007の笑える「新機能」（４）

あなたは「自分のタスク」画面で、実績作業時間を「7」と入力し、「すべて保存」ボタンをクリックした。

その後の画面が、画面013である。

あなたは6月3日に、7時間ではなく、7日間働いたことになっているではないか！！

念のためにプロジェクトを展開して確認してみよう。それが画面014だ。

やはり、「Plan-1」というタスクについて、あなたは6月3日に「7日」間作業したことになっている。

さっきあなたは、すぐ上の行の表示単位が「0日」という風に「日」になっていることを、少し不審に思った。その悪い予感が当たってしまったようだ。

実はPWA2007の「自分のタスク」画面で「時間配分ビュー」を表示させると、その表示単位も入力単位も「日」になるのだ。

これはどう考えてもおかしいだろう。

あなたは１日のうち、各タスクについて何時間作業したか、その実績作業「時間」を入力したいのだから、入力単位は当然「時間」であるべきだ。

いったい誰が「0.5日」や「0.25日」や「0.2667日」などと、実績作業「時間」を「日」単位で入力するだろうか。

実は「自分のタスク」の入力単位のデフォルトが「日」になっていることについては、大笑いできるエピソードがある。

「自分のタスク」に「時間配分ビュー」を表示させる機能は、2008年6月の「サーバーおよびクライアント向け Project 2007 インフラストラクチャ更新リリース」というリリースで、初めて追加されたものだ。

そのとき、この「時間配分ビュー」は、表示単位が「時間」、入力単位は「日」になっていた。

さすがにマイクロソフトの開発関係者も、表示単位と入力単位が違うのはおかしいと感じだのだろう。その単位をそろえる修正を、2009年4月末のMicrosoft Office 2007 Service Pack 2でおこなった。

常識のある人間がふつうに考えれば、「時間配分ビュー」の表示単位は「時間」にしたまま、入力単位を「日」から「時間」へ修正するはずである。

ところが、どうしたことかマイクロソフトの開発関係者は、このサービスパック２で、表示単位を「時間」から「日」に変更し、入力単位を「日」のままにしたのである。

逆でしょ！完全に逆でしょ！

もう、笑うしかない。

実は、あなたを驚かせる事実はこれだけではない。

間違って6月3日に、「7日間」作業したと入力してしまったあなたは、さらに恐ろしい事実に直面するのだ。

※この連載はしばらく続くが、Microsoft Office Project Server 2007を、より良い製品にしてほしい一心からだ。そうでなければ、これだけ長い時間を割いてこんなエッセーを書くだろうか。

Microsoft Office Project 2007の笑える「新機能」（３）

「タスクID」は、プロジェクト管理者がProject Professionalを使ってタスクを定義するとき、いちばん上にあるタスクから自動的に採番される。

途中に新たしいタスクを割り込ませても、上から採番し直されるので、「タスクID」の昇順でソートすれば、プロジェクト管理者がProject Professionalで見ているのと同じ順番で、上からタスクが並ぶことになる。

それが画面008だ。

ただ、これでも旧バージョンのPWAの階層表示には程遠い。

たとえば「Design-1」というタスクは、どういう親タスクに対するサブタスクなのか、この画面では全くわからない。

この例では、プロジェクト管理者がとっても親切にタスクの名前を付けているので、Design-1という名前なのだから、親タスクはたぶん「Design」だろう、と推測がつきやすい。

しかし、PWA2007ではタスクの階層表示機能がなくなったため、「自分のタスク」画面上に、例えば「仕様書レビュー」という同名のタスクが３つ並ぶことが発生する。

それぞれ「ネットワーク設計」のサブタスクの「仕様書レビュー」、「外部設計」のサブタスクの「仕様書レビュー」、「ＤＢ設計」のサブタスクの「仕様書レビュー」かもしれないし、そうじゃないかもしれない。

PWA2007では、「自分のタスク」画面を見ただけでは、全く同名のタスクが現れた場合、いったいタスクの親タスクが何なのか分からなくなってしまったのだ。

くりかえしになるが、旧バージョンのPWAではタスクが階層表示されるので、一目見ただけで親タスクが何か分かるようになっていた。

いったいなぜマイクロソフトは、PWA2007でこんな重大な「改悪」をしたのだろうか。

ただし、PWA2007でタスクの階層構造を確認する方法は、ないわけではない。

画面009をご覧いただきたい。

各タスクのタスク名の右端に現れる、小さな下向き黒三角形をクリックすると、プルダウンメニューが出てくる。その中の「タスクのパス：」をクリックしてみる。

すると画面010のように、別画面でそのタスクの階層構造が表示されるのだ。

しかしこの別画面のつくりの安っぽくて、そっけないこと。

確かに「Plan-1」というタスクが、「テストのプロジェクト2009＞Plan＞Plan-1」という階層構造だと分かるが、あまりに安っぽい画面で驚いてしまう。

PWA2007では、こうやってタスクを一つ一つクリックするしか、タスクの階層構造を確認する方法がなくなった。旧バージョンのPWAと比較すると、明らかな「改悪」だ。

さて、先ほど「時間配分ビュー」をオンにしたことで、日別の実績作業時間を入力するマス目（グリッド）が現れた。

画面011をご覧いただきたい。

「Plan-1」というタスクの「06/03」にマウスポインタを合わせると、「予定作業時間 7時間」という表示があらわれる。

これはなかなか親切な機能だ。Plan-1というタスクについて、自分に割り当てられた予定作業時間が7時間だと、すぐに分かる。

しかし．．．ちょっと待てよ。

そのすぐ上の行を見てみると「0日」と表示されている。

これは本来「0時間」という具合に、時間単位で表示されるべきではないのか？と不審に思われるかもしれない。

まあでも、あまり細かいことは気にせず、あなたは6月3日に「Plan-1」というタスクについて、予定通り7時間の作業を実施したので、このマス目に「7」と入力することにしよう。

それが画面012だ。

そして「自分のタスク」画面の下方にある「すべて保存」というボタンをクリックする。このあたりは旧バージョンのPWAとあまり変わりない。

ところが、「すべて保存」ボタンをクリックした結果、あなたは恐ろしい光景を目にすることになる。

※この連載はしばらく続くが、Microsoft Office Project Server 2007を、より良い製品にしてほしい一心からだ。そうでなければ、これだけ長い時間を割いてこんなエッセーを書くだろうか。

Microsoft Office Project 2007の笑える「新機能」（２）

PWA2007の「自分のタスク」画面を多少でも見やすくするために、オプションを表示させてみる。

それが画面003だ。

これが初期状態なので、次の画面004のように変更してみる。

つまり、「時間配分ビュー」にチェックマークを入れ、「すべて展開」のチェックマークをはずす。

すると「自分のタスク」画面は、画面005のように変わる。

まず「時間配分ビュー」をオンにしたので、現在の一週間分の入力マス目（グリッド）が表示されるようになった。少しは旧バージョンのPWAの使いやすさに近づく。

また「すべて展開」をオフにしたので、プロジェクト名ごとに全タスクが折り畳まれた状態になる。

かえって使いづらくなったのでは？と思われるかもしれないが、実は大きな利点がある。プロジェクト名をクリックし、展開してみるとわかる。

それが画面006だ。

実は「すべて展開」をオフにしたことで、１画面に自分に割り当てられた全タスクが表示され、いちいちページ遷移をしなくてもよくなるのだ。

ためしに画面のいちばん下までスクロールしてみよう。

それが画面007だ。右下隅にあった、ページ遷移のためのプルダウンが消えている。

初期状態の「自分のタスク」画面が、ページ遷移が必要な設計に「改悪」された理由をマイクロソフトのサポートに質問したところ、「サーバから一度に大量のデータを引っ張ってこないようにすることで、画面の反応速度を改善するため」という答えが返ってきた。

本当にそうなら、なぜPWA2007で「すべて展開」をオフにできるようにしたのだろうか。

また、旧バージョンのPWAの時代に比べ、企業のネットワーク環境やパソコン性能は確実に良くなっているのに、わざわざ性能面の配慮から、データを細切れにおくるような「改悪」をしたのか。

そもそも「自分のタスク」画面のソースコードを表示させれば分かるが、このタスク一覧のデータは、単なる文字データである。

いまやどんなサイトでも普通に使われているFlash動画に比べれば、データ量としてははるかに少ない。

どう考えても、「自分のタスク」画面の初期状態を、全タスクを表示でページ遷移を不要とするのが合理的な判断だと思うのだが。

これで何とか旧バージョンのPWAの使いやすさに近づいたが、まだ重大な欠点がある。

もう一度、画面006をご覧いただいたい。

タスクがタスク名の昇順にソートされている。そのため、どのタスクがより早く始まるのかが分からなくなっている。

実は「自分のタスク」画面は、初期状態では「開始日」の昇順にタスクがソートされている。画面006では、すこし意地悪に、わざど「タスク名」の昇順でソートしてみた。

じゃあ「開始日」の昇順にソートすれば、旧バージョンのPWAでは表示されていたタスクの階層構造になるかといえば、そうならない。

階層構造では下の方にあるタスクが、上の方のタスクよりも、開始日や終了日が早いことは、十分ありうるからだ。

旧バージョンのPWAでは表示されていたタスクの階層構造に近づけるには、いったいどうすればいいのか。

そこで「タスクID」が登場する。

※この連載はしばらく続くが、Microsoft Office Project Server 2007を、より良い製品にしてほしい一心からだ。そうでなければ、これだけ長い時間を割いてこんなエッセーを書くだろうか。

Microsoft Office Project 2007の笑える「新機能」（１）

マイクロソフト社の企業向けプロジェクト管理ツール Microsoft Office Project Server 2007 付属の Project Web Access 2007（以下PWA2007）が、いかに使いづらい代物か、今まで何度か取り上げているが、実際の画面を見ながら、じっくり検証してみたい。

Project Web Accessというのは、プロジェクトメンバーがウェブブラウザから作業時間の実績や進捗状況を入力できるしくみだ。

各パソコンにProject Professionalという専用ソフトをインストールしなくて済むのが最大の売りである。

さて、プロジェクト管理者がProject Professionalを使って「TestMem1」というプロジェクトメンバーに、タスクを割り当てたとする。以下の説明の便宜上、わざと40個以上もの、たくさんのタスクを割り当てている。

TestMem1さんがPWAを開くと、「自分のタスク」画面で、自分に割り当てられたタスク一覧を確認できる。

PWAは会社のWindowsドメインにログオンしたときの認証情報を自動的に引き継ぐ（いわゆるシングルサインオン）ので、PWAにあらためてログオンする必要はない。

その「自分のタスク」画面が図001である。

（※なお、初期状態の画面に対して「タスクID」列を追加表示し、「標準作業時間」「残存作業時間」列を非表示にするカスタマイズをほどこしてある。なぜそうする必要があったかは、後ほどご説明する）

TestMem1さんがメンバーになったのは「テストのプロジェクト2009」という名称のプロジェクトで、その配下のタスクが、たくさん割り当てられているのがわかる。

この「自分のタスク」画面が、異様に使いづらいのだ。

まず、「自分のタスク」画面には、タスクの階層構造を表示させる機能がない。実は旧バージョンのPWAでは、実績作業時間の入力画面で、タスクが階層構造で表示されたのだが、PWA2007になってその機能がなくなった。

なぜマイクロソフトが、わざわざタスクの階層構造を見えないように「改悪」したのか、理由は不明である。

しかも、旧バージョンのPWAの「自分のタスク」画面は、ヨコ軸に日付が並んだ格子状（グリッド）になっていて、この画面から複数日の実績作業時間を連続して入力できた。

しかしPWA2007ではその便利な機能がなくなっている。実際には、その代わりになる機能が提供されているのだが、これが大笑いできる機能になっている。それは後のお楽しみ。

さて、この画面を下までスクロールすると画面002のようになる。

右下隅にプルダウンリストがあり、「ページ１」「ページ２」と表示されているのが分かるだろう。

この「自分のタスク」画面は、タスクの数が概ね40個以上になると、わざわざページ遷移をしないと、すべてのタスクを確認できない。

これも旧バージョンのPWAでは１画面に自分に割り当てられた現在の全タスクが表示され、いちいちページ遷移をしなくてもよかった。

なぜマイクロソフトが、わざわざページ遷移が必要な設計に「改悪」したのか、理由は不明である。

ただ、これらの「改悪」は設定変更である程度、改善することができる。その方法をつづいてご説明したい。

※この連載はしばらく続くが、Microsoft Office Project Server 2007を、より良い製品にしてほしい一心からだ。そうでなければ、これだけ長い時間を割いてこんなエッセーを書くだろうか。

YouTubeに自慢げにPVを違法アップするおバカさんたち

最近、中島美嘉のファンなので、ヒマなときにYouTubeで「mika nakashima」と検索してみる。

ここ数週間、新曲「Over Load」のプロモーションビデオ（PV）が次々とアップロードされては、Sony Musicに削除されるということが続いている。

ありがたいことに、「歌うペンギン」である僕がSony Musicに通報して削除させているのではないかと疑っているYouTubeユーザーもいるようだが、勘ぐり過ぎというものだ。

仮に僕が通報していたとしても、実際に削除するかどうかはSony Musicの判断次第。

前にも書いたが、現にYouTubeにアップされている柴田淳さんのプロモーションビデオは、著作権違反であるにも関わらず、ずっと削除されずに残ったままである。

本当に下らないと思うのは、中島美嘉のPVを違法にアップロードすることが、ファンとしての責務だと、とんでもない勘違いをしているユーザーがいることだ。

「別のユーザーは埋め込み禁止でアップしていますが、私は埋め込み許可しますので、どんどんご覧下さい」みたいなことを書いて、堂々と違法アップロードしているユーザーも見たことがある。

PVを10本以上もアップロードして、YouTubeアカウントを停止されたユーザーも知っている。

中島美嘉がSony Music所属のアーティストとして自分の作品に持っている権利を侵害しておいて、まるでそうすることが彼女を応援している証明であるかのように、誇らしげに違法アップロードをしているユーザーを見つけると、単なる馬鹿だとしか言いようがない。

もちろん、柴田淳や、台湾、中国のレコード会社に比べて、Sony Musicの著作権管理が厳格すぎるという批判は成り立つだろう。

しかし、それなら違法アップしたPVの説明文に、堂々と書いておけばいい。「Sony Musicは海外のファンが中島美嘉の曲を楽しむ機会を不当に奪っているので、ここにPVをアップすることで抗議する」などなど。

PVの違法アップロード合戦は、端的に見苦しい。

VBAでActive Directoryのサブドメインを含む全ドメインを列挙する方法

ややマニアックな話題だが、ExcelのVBA(Visual Basic For Applications)を使って、社内のActive Directoryに接続し、サブドメインも含む全ドメイン名を列挙し、各ドメイン内のOUやグループを列挙する方法が分かったので、備忘のために記事にしておく。

Const ADS_SCOPE_SUBTREE = 2

Dim oConn As Variant
Dim oCommand As Variant

' ActiveDirectory接続用ADODBオブジェクト生成
Set oConn = CreateObject("ADODB.Connection")
Set oCommand = CreateObject("ADODB.Command")
oConn.Provider = "ADsDSOObject"
oConn.Open
Set oCommand.ActiveConnection = oConn

' Active Directoryのグローバルカタログに全ドメイン名を問い合わせ
oCommand.CommandText = _
    "SELECT distinguishedName from " & _
    "'GC://DC=inabata,DC=com' WHERE objectClass='domain'"

oCommand.Properties("Page Size") = 1000
oCommand.Properties("Timeout") = 300
oCommand.Properties("Searchscope") = ADS_SCOPE_SUBTREE
oCommand.Properties("Cache Results") = False

Set oRes = oCommand.Execute
If oRes.BOF Then Exit Sub

Do Until oRes.EOF
    sDomain = oRes.Fields("distinguishedName").Value
    oRes.MoveNext
Loop

ここまでで自社のActive Directory管轄下にあるサブドメインも含む全てのドメイン名を取得できる。

distinguishedName形式で取得しているので「DC=japan,DC=hogehoge,DC=com」といった形式になる。

次に、各ドメイン内のOUやグループ、コンピュータを列挙するのだが、僕はてっきり、各ドメインのドメインコントローラを先ず調べて、そのドメインコントローラに対してLDAPクエリーを投げる必要があると思っていた。

例えば、ドメインコントローラーのサーバ名が「DCServer01」だとすると、その配下の全OUを列挙するには、次のように問い合わせる必要があると思っていた。

oCommand.CommandText = _
    "SELECT distinguishedName from " & _
    "'LDAP://DCServer01/DC=japan,DC=hogehoge,DC=com' " & _
    "WHERE objectClass='organizationalUnit'"

CommandTextに渡す問い合わせ文字列の中身を抜き出せば次のようになる。

SELECT distinguishedName
FROM 'LDAP://DCServer01/DC=japan,DC=hogehoge,DC=com'
WHERE objectClass='organizationalUnit'

ところが、このサーバ名の代わりに、ドット表記のドメイン名が使えることが分かったのだ。つまり次のような感じである。

SELECT distinguishedName
FROM 'LDAP://japan.hogehoge.com/DC=japan,DC=hogehoge,DC=com'
WHERE objectClass='organizationalUnit'

ドット表記のドメイン名なら、最初に取得した「DC=japan,DC=hogehoge,DC=com」形式のドメイン名から簡単に変換できるので、例えば下記のような関数として定義しておけばよい。

Function ToDottedName(ByVal sBuf As String) As String

    sBuf = Replace(sBuf, "DC=", "")
    sBuf = Replace(sBuf, ",", ".")
    ToDottedName = sBuf

End Function

後は、sDomainという引数で"DC=japan,DC=hogehoge,DC=com"形式のドメイン名を渡すようなサブルーチンを書けば、当該ドメイン内の全OUを列挙するなら、

oCommand.CommandText = _
    "SELECT distinguishedName from " & _
    "'LDAP://" & ToDottedName(sDomain) & "/" & sDomain & "' " & _
    "WHERE objectClass='organizationalUnit'"

当該ドメイン内の全Groupを列挙するなら

oCommand.CommandText = _
    "SELECT distinguishedName from " & _
    "'LDAP://" & ToDottedName(sDomain) & "/" & sDomain & "' " & _
    "WHERE objectClass='Group'"

当該ドメインの特定OU内の全コンピュータを列挙するなら、

oCommand.CommandText = _
    "SELECT distinguishedName from " & _
    "'LDAP://" & ToDottedName(sDomain) & "/OU=特定のOU名称' " & _
    "WHERE objectClass='computer'"

などとなる。

IE7でYouTubeの受信ボックスがエラー。Google社の嫌がらせか？

最近、ほぼ毎日、YouTubeにアップしている中島美嘉や梁静茹の動画に世界各国からコメントを頂くのだが、同じコメントを何度開いても、既読にならず、未読件数がそのまま残ってしまう。今まではこんなことはなかった。

よく見ると、ステータスバーにスクリプトエラーが表示されている。

Internet ExplorerのJavaScriptエラー表示の設定を、エラーのたびに毎回表示するに切り替えると、やはりInternet Explorerでは認識できないオブジェクトを、JavaScriptが使おうとしている。

直感的に、グーグルの陰謀だ！とわかった。

試しに、グーグル社製のWebブラウザ、グーグル・クローム（Google Chrome）をインストールし、YouTubeの受信ボックスでコメントを開くと、予想どおり、ちゃんと既読になる。

しかも受信ボックスが１行おきに色違いの表示になっている。Google Chromeはスタイルシートの仕様までYouTube用にカスタマイズしてあるのだ。

おそらくInternet Explorerで受信ボックスのコメントやメッセージが、どうやっても既読にならないのは、Google社がわざと仕掛けたワナだろう。

谷川俊太郎氏など174人が、Google社が「Googleブック検索」のために勝手に作品を電子化したことに抗議し、Google社の和解案を拒否しているようだ。

ストリートビュー問題にしても、Google社のやろうとしていることが適切かどうかは別として、実現にいたるプロセスは明らかに一方的で不適切だ。

米国の合意形成プロセスをそのまま日本に持ち込むようなことを、今後も繰り返すようであれば、Googleはそのうち日本のユーザーから軽蔑される会社になるだろう。

あっ、こんなことを書くと「グーグル八分」（＝原因がよく分からないままGoogleの検索結果に掲載されなくなってしまうこと）にあうかも！

グーグル八分にあうかも、というのは、実はただの冗談ではない。

この「愛と苦悩の日記」の親サイトである「think or die」は、すでに「AdSense八分」にあっている。

アドセンスに申し込んで、キーワード広告をしばらく掲載していたのだが、ある日、いきなり一方的に広告掲載を打ち切られたのだ。

おそらく、やや政治的な内容のエッセーをGoogleが「検閲」したと思われる。

グーグルはこのように、けっこう恐ろしい会社なのである。

Microsoft Office Project Server 2007の重大なバグ(3)

引続きマイクロソフト Office Project Server 2007のバグ（不具合）について、Microsoft Office Project Professional 2007とProject Web Access 2007を組み合わせて使った場合の不具合について詳しく説明したい。
I'll continue explaining the "bug" of Microsoft Office Project Server 2007 when using it with the combination of Office Project Professional 2007 and Project Web Access 2007.

ひとことで言えば、プロジェクト管理者がOffice Project Professional 2007から「発行」したタスク割当の変更が、Project Web Access 2007の「プロジェクトセンタ」画面には反映されるが、「自分のタスク」画面には反映されない場合がある、という不具合だ。
We can summarize the "bug" as follows: when project manager "publishes" task assignment updates from Project Professional 2007, in some cases, the updates are applied only to "Project Center" but not to "My Tasks" of Project Web Access 2007.

ご承知のようにMicrosoft Office Project Server 2007は、プロジェクト管理者はOffice Project Professional 2007で詳細なプロジェクト計画を作成し、チームメンバーはProject Web Access 2007のウェブ画面から、各自の進捗を入力するという使い方を、通常の使い方として想定している。
As you know, Microsoft Office Project Server 2007 expects project managers use Professional 2007 for planning in detail while team members only use Project Web Access 2007 for checking and inputting the progress of each task.

その理由は、チームメンバー全員分のOffice Project Professional 2007を購入すると導入コストが高くなるし、インストール展開する作業工数も大きくなるためだ。
The reason is that if you have to install Project Professional 2007 for all team members, it will cost too much.

チームメンバーの進捗報告や新規タスク提案の作業が、Project Web Access 2007のウェブ画面だけで完結できるというのは、Office Project Serverの大きな「売り」である。
Team members only need Project Web Access 2007 for reporting task progress. That's one of the advantages of implementing Office Project Server 2007 system.

ところが、チームメンバーが進捗状況を入力する唯一のインターフェースである、Project Web Access 2007の「自分のタスク」画面に、プロジェクト管理者からのタスク割当の更新が反映されないことがあるのだ。
However, the updates of task assignment published by project managers aren't sometimes applied to "My Tasks" of Project Web Access 2007.

そしてマイクロソフトは、それがOffice Project Server 2007の「仕様」だと言っている。
Microsoft says it is "specifications" of Office Project Server 2007.

以下、詳細を説明する。
I'll explain it in detail.

（Ａ）プロジェクト管理者の田中さんが、チームメンバーの鈴木さんに、あるプロジェクトのうちの「タスクＡ」を割り当てたとする。タスクの期間や標準時間の設定は何でも良い。
(A) Ms. Tanaka, project manager, assigns "Task-A" to Mr. Suzuki, team member. Its duration and baseline hours can be whatever.

（Ｂ）チームメンバーの鈴木さんはProject Web Accessの「自分のタスク」画面から、「タスクＡ」の進捗を入力し、一時的に「保存」だけしておいた。ただ、他のタスクの進捗も入力してから、まとめてプロジェクト管理者に「提出」しようと思っただけである。
(B) Mr. Suzuki inputs his own task progress on "My Tasks" of Project Web Access 2007 and temporarily saves it. He just wants to "submit" his progress after finishing inputting all other task progresses.

（Ｃ）その頃、プロジェクト管理者の田中さんは、鈴木さんに対する「タスクＡ」の割り当てを変更したいと思い、Office Project Professional 2007で割り当てを変更し（例えばタスクの期間を変更するなど）、Project Server 2007に対して「保存」かつ「発行」したとする。
(C) At this moment, Ms. Tanaka wants to change "Task-A" assignment to Mr. Suzuki. So she updates the assignment by using Office Project Professional 2007, saves and "publishes" it to Project Server 2007.

（Ｄ）ところが、Office Project Server 2007の仕様上、その「発行」は、Project Web Access 2007側では「プロジェクトセンタ」のプロジェクト計画にしか反映されない。つまり、鈴木さんが「自分のタスク」で「タスクＡ」を開くと、依然として自分が一時的に「保存」した時のままの状態である。
(D) However, because of the specifications of Office Project Server 2007, the updates published by Ms. Tanaka are applied only to "Project Center" of Project Web Access 2007. Even when Mr. Suzuki opens "My Tasks", "Task-A" still remains the same status as Mr. Suzuki temporarily saved it.

さて、以上のような動作は、プロジェクト管理の業務フロー上、適切な仕様と言えるだろうか。
Can this be appropriate specifications for project management workflow?

プロジェクト管理の業務フロー上、プロジェクト計画の変更権限はあくまでプロジェクト管理者にある。だからこそ、チームメンバーが「提出」したタスク進捗の更新は、プロジェクト管理者が「承諾」「発行」しない限り、「プロジェクトセンタ」のプロジェクト計画に反映されない。
Concerning project management workflow, the authority of changing project baseline plans belongs to project managers. That's why the task updates submitted by team members will not be applied to "Project Center" until project managers "approve" and "publish" them.

であれば、（Ｃ）の段階でプロジェクト管理者が変更して「発行」したタスク割当は、Project Web Access 2007の「プロジェクトセンタ」だけでなく、「自分のタスク」画面にも強制的に反映されるべきではないだろうか。
If this is true, the task assignment updates published by project managers at step (C) should be applied not only to "Project Center" but also to "My Tasks" of Project Web Access 2007.

にもかかわらず、Office Project Server 2007の仕様上、プロジェクト管理者がProject Professional 2007を使ってProject Server 2007へ「発行」したタスク割当の変更は、Project Web Access 2007上では「プロジェクトセンタ」画面には反映されるが、「自分のタスク」画面には反映されないという、不可解な仕様になっている。
Nontheless the task updates published by project managers are applied only to "Project Center" and NOT to "My Tasks" of Project Web Access 2007. This is a strange specification of Office Project Server 2007.

また、チームメンバーにとって、自分に割り当てられたタスクに対する進捗を入力できる画面は「自分のタスク」画面だけである。
In addition, team members can input their own task progresses only through "My Tasks" screen.

その画面に、プロジェクト管理者が「発行」した最新の割り当てが反映されないのは、当然のことながら、チームメンバーにとって非常に不都合である。古いままの開始日・終了日・標準作業時間の割り当て状況を見つつ、進捗を入力するしかないのだ。
If "My Tasks" screen doesn't show the latest updates of assignment which are published by project managers, that's really annoying for team members because what team members can rely on when inputting their own progress are old task assignments, old start date, old finish date and old baseline hours.
They cannot refer to the updated task assignments, updated start date, updated finish date or updated baseline hours.

ただし、マイクロソフトによれば、この不可解な仕様には「回避策」がある。
それは以下のような手順である。
However, according to Microsoft, there is a workaround for this strange specifications of Project Server 2007 as follows.

（Ｅ）鈴木さんをふくむ全てのチームメンバーは、一時的に「保存」中で、まだ「提出」していない進捗入力を、とにかくいったん全て「提出」する。
(E) At any rate, all team members including Mr. Suzuki submit every progress which are not submitted yet.

（Ｆ）プロジェクト管理者の田中さんは、それらの「提出」内容が適切かどうかにかかわらず、全てを「承諾」かつ「発行」する。
(F) At any rate, Ms. Tanaka, project manager, approves and publishes the submitted progresses.

（Ｇ）そうすると、プロジェクト管理者の田中さんが先ほど「発行」したタスク割当の更新は、当然、チームメンバーが「提出」してきた進捗状況で全て上書き変更されてしまう。
(G) Then all the assignment updates which Ms. Tanaka input before by using Project Professional 2007 are overwritten by the approved and published progresses of all team members.

（Ｈ）それに構わず、プロジェクト管理者の田中さんは再度、タスクの割当を変更し、Project Professional 2007から「発行」し直す。
(H) Ms. Tanaka, project manager, inputs task updates again and publishes them with Project Professional 2007.

（Ｉ）こうすることで初めて、田中さんの発行したタスク割当の更新は、各チームメンバーのProject Web Access 2007の「自分のタスク」画面と「プロジェクトセンタ」画面の両方に反映されるのだ。
(I) By doing this, the task updates published by Ms. Tanaka are applied both to "My Tasks" and "Project Center" of Project Web Access 2007.

これがOffice Project Server 2007の仕様である。
These are "specifications" of Office Project Server 2007.

仮に、プロジェクト管理者の田中さんが、（Ｆ）の段階で、一部の「提出」を「承諾」ではなく「拒否」したとしよう。
Let's suppose that Ms. Tanaka rejects some updates submitted by team members at step (F).

するとそれらのタスクについてだけは、（Ｉ）の段階でProject Web Access 2007の「自分のタスク」画面に「発行」が反映されなくなってしまうのだ。つまり先ほどの（Ｄ）と同じ状況になってしまう。
Then, only regarding the tasks whose update are rejected by project manager, even how many times project manager publishes task assignment updates, such publishements will never be applied to "My Tasks" of Project Web Access forever.

以上をまとめると、プロジェクト管理者が自分が「発行」したタスク割り当ての更新を、各チームメンバーのProject Web Access 2007の「自分のタスク」画面に反映させたい場合、以下の条件がすべて必要になる。
Let's summarize what is described above. If project manager wants to apply every publishement of task assignment updates to "My Tasks" page of each team member, all the following conditions must be met.

（１）チームメンバーはタスクの進捗を入力したら、単に「保存」するだけでなく、必ず「提出」する必要がある。
(1) Every team member must "submit" all progress updates to project manager, not only "save" them as frequently as possible.

（２）かつ、プロジェクト管理者は、チームメンバーの「提出」した進捗入力を、その内容がいかに不適切であろうと、いったんは全て「承諾」し「発行」しなければならない。
(2) Project manager must "approve" and "publish" all the updates submitted by team members even if project manager finds some of the updates inappropriate.

（３）その上で、プロジェクト管理者は、（２）においてチームメンバーの「提出」を「承諾」「発行」したことで、ぐちゃぐちゃになったプロジェクトファイルを、自分の想定の内容に変更し直して、改めて「発行」しなければならない。
(3) By doing so, the project file will inevitably become a 'mess' because project manager must "approve" and "publish" all the updates submitted by team members even if some updates are clearly inappropriate. Then project manager must correct every inappropriate point one by one and, in addition, must update task assignments just as the project manager originally wants to make them so.

さて、もしみなさんがプロジェクト管理者の立場だとしたら、Project Professional 2007上で、いったい何が自分の想定するプロジェクト計画だったのか、そのうち分からなくなってしまうに違いない。
By the way, if you are a project manager using Microsoft Office Project Server 2007, you will be inevitably thrown into a mess where you cannot see what was your original task assignment plan.

以上のようなMicrosoft Office Project Server 2007の「仕様」を、バグ（不具合）と言わずして何と言おうか。
Regarding such a strange "specification" of Microsoft Office Project Server 2007, why don't you call it "bug"?

Microsoft Office Project Server 2007の重大なバグ(2)

マイクロソフトのMicrosoft Office Project 2007というのは、なかなか優れたアプリケーションである（もちろん皮肉だ）。
Microsoft Office Project 2007 is an excellent project management application.

例えばあなたがあるプロジェクトのチームメンバーになっていて、以下のような「タスクＡ」を割り当てられていたとしよう。
For example, you are a member of a project and "Task-A" as follows is assigned to you.

2009/04/27 Baseline(標準) 4 hrs / Actual(実績) 0 hrs
2009/04/28 Baseline(標準) 4 hrs / Actual(実績) 0 hrs

あなたは本来「タスクＢ」の実績作業時間として入力すべき時間を、誤って「タスクＡ」の実績作業時間として入力し、「保存」てしまったとする。入力はProject Professional 2007からでも、Project Web Access 2007からでもよい。
But you happen to make a mistake. You input actual hours of "Task-B" into "Task-A" and save it. Input can be done through Project Professional 2007 or Project Web Access 2007. The results are the same.

ただし、まだ「提出」もしていないし、プロジェクト管理者による「承諾」「発行」もされていない。
You indeed saved the wrong actual hours but don't submit them to project manager yet. So project manager, of course, doesn't approve or publish them yet.

2009/04/27 Baseline(標準) 4 hrs / Actual(実績) 4 hrs
2009/04/28 Baseline(標準) 4 hrs / Actual(実績) 4 hrs

結果として当然のことながら「タスクＡ」の残存作業時間は0時間になる。
As a result, remaining hours of "Task-A" becomes 0 hours.

入力ミスに気付いたあなたは、「タスクＡ」の実績作業時間を２日間とも0時間にもどして「保存」する。まだ「提出」はしない。
After saving them, you notice you made a mistake. So you input 0 hours as actual hours for the two days of "Task-A" and save them.

すると、驚くべきことに「タスクＡ」は自動的に下記の状態になってしまう。
Now let's watch carefully the results. "Task-A" automatically turns into a strange status as follows.

2009/04/27 Baseline(標準) 0 hrs / Actual(実績) 0 hrs

つまり、「タスクＡ」は2009/04/27(月)に設定された「マイルストーン」（＝標準作業時間が0時間で、作業期間が1日のタスク）に自動的に変わってしまうのだ。
This means that "Task-A" automatically turns into a "milestone", i.e. a task with no baseline hours and 1 day duration. And the assignment of 2009/04/28 disappers.

プロジェクト管理者は「提出」を受けていないので、「タスクＡ」が自分の知らないところで「マイルストーン」に自動的に変わってしまっていることに、当然気付かない。
Project manager hasn't got the "submission" of this automatic change yet. So the project manager doesn't even notice this strange phenomenon yet. This means any "task" can turn into a "milestone" without Project manager's approval.

マイクロソフトによれば、これがMicrosoft Project 2007の「仕様」だというのだ。
According Microsoft, this is the "specification" of Project 2007.

さて、プロジェクト管理者のあずかり知らないところで、チームメンバーが単に自分の実績作業時間の入力ミスを修正しただけで、任意のタスクが「マイルストーン」に自動的に変換されてしまう。
By the way, any "task" can change into a "milestone" simply because a team member tries to correct input mistake.

これはプロジェクト管理業務上、適切な動きと言えるだろうか。適切な動きは以下の通りのはずだ。
Can it be an appropriate workflow in a normal project management?
I think the appropriate project management workflow must be as follows.

つまり、チームメンバーが入力ミスに気付いて、「タスクＡ」の実績作業時間を0時間にもどして「保存」したら、「タスクＡ」は最初の状態、つまり、
If the team member notices his/her mistake in inputting actual hours of "Task-A", corrects actual hours into 0 hours and saves them, then the "Task-A" must go back to the original status as follows.

2009/04/27 Baseline(標準) 4 hrs / Actual(実績) 0 hrs
2009/04/28 Baseline(標準) 4 hrs / Actual(実績) 0 hrs

こういう状態にもどるのが、適切な動きではないだろうか。
ところがMicrosoft Project 2007の「仕様」では上述のように、
Don't you think this is the appropriate "specification" for a project management application? However, when you use Microsoft Project 2007, if you make a mistake as described above and correct it, then the task will automatically change into a "milestone" like this.

2009/04/27 Baseline(標準) 0 hrs / Actual(実績) 0 hrs

こういう具合に勝手に「マイルストーン」に変換されてしまうのだ。
これを「バグ」と言わずしてなんと言おう。
Why don't you call this a "bug" instead of "specification"?

マイクロソフトProject 2007は素晴らしいプロジェクト管理アプリケーションである。
Microsoft Project 2007 is an excellent project management application.

Microsoft Office Project Server 2007の重大なバグ(1)

先日も書いたが、仕事の関係でMicrosoft Office Project Server 2007と、Microsoft Office Project Web Access 2007、Microsoft Office Project Professional 2007の組み合わせを評価しているのだが、致命的な不具合が見つかり、本番適用できないおそれが出てきた。

果たしてMicrosoft Office Project 2007製品群を、正しく使いこなせている企業は存在するのだろうか。ネットをいろいろ検索しても「重大な不具合がある」という評価が全く見つからず、とても不思議だ。

僕が発見した致命的な不具合とは、以下のようなものである。

例えば、プロジェクト管理者の田中さんが、Project Professional 2007を使って、Project Server 2007に接続し、次のようなタスクＡを鈴木さんに割り当て、発行したとする。

「タスクＡ」
2009/04/20(月) 標準作業時間 8時間
2009/04/21(火) 標準作業時間 8時間
2009/04/22(水) 標準作業時間 8時間
2009/04/23(木) 標準作業時間 8時間

ここから、いくつかのケースを考えてみる。

【ケース１】
割り当てをうけた鈴木さんは、他のタスクが予想以上に早く終わったので、タスクＡに予定より一日早く着手できた、とする。

そこで、Project Web Access 2007の「自分のタスク」からタスクＡの「割り当ての詳細」画面を開き、タスクの開始日よりも実働１日早い、2009/04/17(金)に実績作業時間として8時間を入力して「保存」したとする。

まだタスク割当者である田中さんへの「提出」は行っていない。

ところが「保存」しただけで、タスクＡの開始日が勝手に2009/04/17(金)に、終了日が2009/04/22(水)に書き換わってしまうのだ。

しかも田中さんが設定した標準作業時間までが、
2009/04/17(金) 標準作業時間 8時間
2009/04/20(月) 標準作業時間 8時間
2009/04/21(火) 標準作業時間 8時間
2009/04/22(水) 標準作業時間 8時間
このように勝手に前へスライドされてしまったではないか。

これはおかしいということで、鈴木さんはタスク割当者の田中さんに依頼して、同じタスクをもう一度「発行」し直してもらったとする。

「発行」し直してもらった後（設定によっては自動でメールが届く）、鈴木さんは、まず、Project Web Access 2007の「プロジェクトセンタ」画面から、当該プロジェクトのタスクＡの実績作業時間が０時間になっており、開始日が2009/04/20、終了日が2009/04/23に戻っていることを確認する。

ところが「自分のタスク」画面からタスクＡの「割り当ての詳細」画面を開くと、依然として自分がさっき入力した結果のままになっているのだ。

つまり、2009/04/17(金)に実績作業時間として8時間が入力されており、タスクの開始日は2009/04/17、終了日は2009/04/22に書き換わったままになっている。

これが僕の見つけた不具合の発生ケース１である。

※注釈

その後、マイクロソフトによれば、これは不具合ではなく、タスクが初期状態の「弱い制約」になっている場合の、既定の動作であるとのことだ。

ただ、タスクが「弱い制約」になっており、かつ、チームメンバーがタスクの開始日を直接変更した場合に、自動的に終了日がスライドするというなら分かる。

しかし、チームメンバーが単に開始日以前の日付に実績作業時間を入力しただけであり、かつ、「保存」しただけの状態（＝まだプロジェクト管理者に「提出」していない状態）であるのに、タスクの開始日と標準作業時間が連動してスライドするのは、明らかにプロジェクト管理の業務フローとしておかしい。

これでは、プロジェクト管理者のあずかり知らないところで、チームメンバーが勝手にタスクの開始日・終了日を変更できてしまうことになるからだ。

しかも、チームメンバーが、タスクの開始日を変更する意図は全くなく、単に実績作業時間を入力する日付を間違えただけだとしたらどうか。単なる入力ミスで、タスクの開始日が自動的にスライドするという仕様は不合理である。

プロジェクト管理者の知らない間にタスクの開始日・終了日が勝手に変更されないよう、少なくともプロジェクト管理者が「承諾」「発行」して始めて、タスクの開始日が自動的にスライドするという仕様にすべきだ。

以下のケースについても全く同じことが言える。

【ケース２】
割り当てをうけた鈴木さんは、他のタスクが予想以上に遅くなったので、タスクＡに2009/04/24(金)になってようやく着手できたとする。

そこで、Project Web Access 2007の「自分のタスク」からタスクＡの「割り当ての詳細」画面を開き、タスクの終了日よりも１日遅い、2009/04/24(金)に実績作業時間として8時間を入力して「保存」したとする。

まだタスク割当者である田中さんへの「提出」は行っていない。

ところが「保存」しただけで、タスクＡの開始日が勝手に2009/04/24(金)に、終了日が2009/04/30(木)に書き換わってしまうのだ。（2009/04/29は祝日のため実働日数にカウントされなかった）

しかも田中さんが設定した標準作業時間までが、
2009/04/24(金) 標準作業時間 8時間
2009/04/27(月) 標準作業時間 8時間
2009/04/28(火) 標準作業時間 8時間
2009/04/30(木) 標準作業時間 8時間
このように勝手に後ろへスライドされてしまったではないか。

これはおかしいということで、鈴木さんはタスク割当者の田中さんに依頼して、同じタスクをもう一度「発行」し直してもらったとする。

．．．以下は「ケース１」をまったく同じことが起こる。

これが僕の見つけた不具合の発生ケース２である。

【ケース３】
割り当てをうけた鈴木さんは、割り当てされたとおり、タスクＡに2009/04/20(月)に着手できたとする。ただ、2009/04/20(月)には4時間しか作業できなかった。

そこで、Project Web Access 2007の「自分のタスク」からタスクＡの「割り当ての詳細」画面を開き、2009/04/20(金)に実績作業時間として2時間を入力して「保存」したとする。

まだタスク割当者である田中さんへの「提出」は行っていない。

ところが「保存」しただけで、田中さんが設定した標準作業時間が、以下のように勝手に書き換わってしまったではないか。
2009/04/20(月) 標準作業時間 2時間
2009/04/21(火) 標準作業時間 10時間
2009/04/22(水) 標準作業時間 10時間
2009/04/23(木) 標準作業時間 10時間

要するに、足りなかった6時間分が、後続の3日間に対し自動的に平準化され、勝手に標準作業時間が書き換わってしまったのだ。

鈴木さんは自分の実績作業時間を入力しただけなのに、本来、割当者である田中さんが管理すべき標準作業時間まで、勝手に書き換わってしまうのである。

これはおかしいということで、鈴木さんはタスク割当者の田中さんに依頼して、同じタスクをもう一度「発行」し直してもらったとする。

．．．以下は「ケース１」をまったく同じことが起こる。

これが僕の見つけた不具合の発生ケース３である。

以上のMicrosoft Office Project Server 2007の不具合には、２つの重大な問題がある。

【問題１】プロジェクト管理者の管理外でのプロジェクト計画の変更

まず、プロジェクト管理者（＝通常はタスク割当者と同一人物）のあずかり知らないところで、タスクの標準作業時間の配分が、どんどん勝手に書き換わっていってしまうこと。

つまり、チームメンバーは、Project Web Access 2007から実績作業時間を入力しただけなのに、そのタスクの開始日・終了日・標準作業時間の配分までが、勝手に書き換わってしまうことである。

チームメンバーが特定の日の実績作業時間を0時間にもどすと、標準作業時間も0時間にもどる。極端な話、あるタスクの実績作業時間を、Project Web Access 2007から、全日について「0時間」と入力すると、そのタスクの標準作業時間がすべて「0時間」になり、そのタスクは「やらなくていい」ことになってしまうのだ。（※このバグについては後日詳述する）

【問題２】Project Professional 2007からの発行がProject Web Access 2007に完全に反映されない

次に、プロジェクト管理者（タスク割当者）がProject Professional 2007を使ってProject Server 2007に接続し、発行したはずのタスク情報が、Project Web Access 2007上では、「プロジェクトセンタ」画面では正しく反映されているにもかかわらず、「自分のタスク」画面では全く反映されない、ということが起こるのだ。

正確に言えば、あるタスクについて、チームメンバーが進捗を入力してプロジェクト管理者に「提出」し、かつ、プロジェクト管理者が「承諾」かつ「発行」を実行しない限り、そのタスクについて、プロジェクト管理者が「発行」した割り当て更新が「自分のタスク」画面に反映されない仕様になっている。（この件についても後日詳述する）

こうなると、Project Web Access 2007だけを使って、自分のタスクの進捗管理や報告をしているチームメンバーとしては、「自分のタスク」画面と「プロジェクトセンタ」画面の、どちらを信用したらいいのか分からなくなる。

より正確に言えば、「自分のタスク」画面の情報には、プロジェクト管理者が発行したタスクの更新情報は反映されないので、「自分のタスク」画面はまったく信用できないと考えるしかない。

しかし、チームメンバーが進捗報告できるのは、唯一「自分のタスク」画面からだけなので、「いったいどうすればいいの？」ということになる。

以上のように、Microsoft Office Project Server 2007関連製品群には、2009/04/21時点で最新の修正プログラムを適用しても、深刻な不具合がある。

他のMicrosoft Office Project Server 2007の企業ユーザーは、なぜこの深刻な不具合に気付いていないのだろうか？

考えられる唯一の理由は、他の企業ユーザーが、タスクの進捗管理を、各タスクの合計の標準作業時間で、ざっくりとしか管理しておらず、日別にきっちり標準作業時間を配分するという管理をしていないことだ。

日別に標準作業時間をきっちり配分する管理をしていない場合は、実際には上記の不具合がデータベース内部で発生しているのに、表面に出てこないため、それに気付かないままOffice Project Server 2007を使い続けていることになる。

おそらく日経など大手メディアは、マイクロソフトの広告料を重要な収入としているので、この手のネガティブ情報を公開できないと思うので、あえてここで公開してみた。

他の企業ユーザーの皆さんも、あらためてProject Web Access 2007の「自分のタスク」画面からの進捗報告が、正しい数字になっているかどうか、確認されるよう強くおすすめする。

巨額赤字見込みのYouTubeはどうなる？

僕はYouTubeのヘビーユーザーだが、クレディ・スイスによればYouTubeは2009年に約4億7000万ドルの損失が見込まれるらしい。

ＮＨＫの受信料は高すぎると思うが、YouTubeなら月額2,000円くらいまでなら払ってもいい。

それは冗談として、仮に有料化するようなことになると、最大の問題はコンテンツの提供者が減ることではないか。

僕のように、金を払ってでも自分で歌った曲をアップしまくる、愚かな自意識過剰の自己満足人間はそう多くないだろうし、僕自身のカバー集も含め、そういう動画は大抵面白くない。

面白い発想の動画を、時間をかけて制作し、発信しようという優秀な創作者が、有料化した後にどこまで残るか。

もしそういう一握りの優秀な創作者が激減してしまったら、そもそもYouTubeなんて誰も見向きもしなくなり、存続そのものが危うくなる。

仮にYouTubeもニコニコ動画も事業として継続できなくなれば、やはりCGM(consumer generated media)も、所詮は梅田望夫的ウェブ2.0幻想だった、ということになりかねない。

それはそれで寂しいなぁ。

MS Project Server 2007の使い勝手の悪さ

仕事でマイクロソフト「Office Project Server 2007」の評価をしているのだが、よほどの大組織でない限り、非常に中途半端な製品になっている。

プロジェクト要員の作業時間を集計するというのは、小規模な組織でも要員の時間管理のために必要なことだろう。

ところが「Office Project Server 2007」から、プロジェクトの進捗管理と、要員の作業時間管理（タイムシート）が分離されてしまった。マイクロソフトはこれを「新機能」と称しているが、中小規模組織の利用者からすると不便きわまりない。

旧バージョンのProject ServerのProject Web Accessでは、ウェブ画面から自分に割り当てられたタスクの作業時間を入力し、プロジェクト管理者に提出するだけでよかった。

プロジェクト管理者は提出された作業時間を、Project Professionalを起動して発行すれば、要員の作業時間はプロジェクトの各タスクの進捗に反映された。とてもシンプルな流れだ。まとめると以下のようになる。

（１）プロジェクト要員はタスク管理画面で実績作業時間を入力し、「提出」する。

（２）プロジェクト管理者は、プロジェクト要員から作業時間の更新通知を受取ったら、Project Professionalを起動し、提出された実績作業時間を「発行」する。

ところがOffice Project Server 2007から、タスク進捗からタイムシートというものが分離された。

このタイムシートという「新機能」を使おうとすると、プロジェクト要員は以下のような操作をしなければならない。

（１）プロジェクト要員は、プロジェクト管理者が自分のタスクに何らかの変更を加え、それがメールで通知されたら、Project Web Accessのウェブ画面のタイムシート画面から、関連する期間のタイムシートをすべていったん「削除」する。

（２）続いてプロジェクト要員は、同じウェブ画面から、関連する期間のタイムシートを、すべて再「作成」する。

（３）プロジェクト要員は、ウェブ画面から再作成したタイムシートを開き、実績作業時間を入力し「保存」する。ただし、タイムシートを削除する以前に入力済みのデータは、タイムシートを再作成しても維持されており、再入力の必要はない。（タイムシートを削除したのに、入力データが復活するというこの挙動は、一般利用者には分かりづらいだろう。しかも「管理用時間」という新機能で入力した時間は、タスクの実績作業時間と異なり、タイムシートとともに削除されてしまい、再入力の必要がある）

（４）プロジェクト要員はウェブ画面で、今度はタスク管理の画面を開き、タイムシートをタスク管理へ「インポート」処理する。そうしないと、タイムシートで入力した実績作業時間は、各タスクの進捗に反映されない。

（５）プロジェクト要員はウェブのタスク管理画面で、先ほどのインポート処理の結果、進捗に変更のあったタスクを選択し、プロジェクト管理者に「提出」する。

（６）プロジェクト管理者はウェブ画面で、提出された実績作業時間を選択し、「承諾」する。

（７）プロジェクト管理者はウェブ画面で、承諾済みだが、まだ発行していない実績作業時間を検索してから選択し、「発行」する。

何が面倒かといって、プロジェクト管理者が、タスクの割り当てや、個々のタスクの標準作業時間、残存作業時間などを変更するたびに、プロジェクト要員は、そのタスクの期間に該当するタイムシートを、すべて、毎回、毎回、いったん削除し、再作成しなければいけないのだ。

そして、プロジェクト要員は、タイムシートに入力した作業時間を、毎回、毎回、タスク進捗へ「インポート」処理をしなければいけない。

Office Project Server 2007でタスク進捗とタイムシートが分離されたことで、こんなにも現場の操作が面倒になり、進捗管理の工数が増えるのである。

ただし、この問題にはかんたんな解決策がある。

「新機能」のタイムシートを使わないことだ。

「新機能」のタイムシートを無視した場合、流れは以下のようになる。

（１）プロジェクト要員は、Project Web Accessのウェブ画面のタスク管理画面から、各タスクの進捗を、実績作業時間か、進捗率で入力し、「保存」する。

（２）プロジェクト要員は、プロジェクト管理者に提出したいタスク進捗を選択し、「提出」する。

（３）プロジェクト管理者はウェブ画面で、提出された実績作業時間を選択し、「承諾」する。

（４）プロジェクト管理者はウェブ画面で、承諾済みだが、まだ発行していない実績作業時間を検索してから選択し、「発行」する。

プロジェクト管理者はProject Professionalを起動しなくてすむ分、少し楽になる。ただし、各タスクの詳細情報を変更したい場合は、やはりProject Professionalを起動する必要はある。

また、プロジェクト要員が使うウェブ画面のタスク管理画面は、旧バージョンのProject Web Accessより、かなり見づらくなっている。

旧バージョンでは各プロジェクトのタスクの階層構造（WBSの階層構造）が、そのままタスク管理画面に表示されたので、プロジェクト要員は、タスクの階層構造を確認しつつ、実績作業時間を入力できた。

ところがOffice Project Server 2007のウェブ画面のタスク管理画面では、プロジェクト名と、タスク名の２階層だけとなり、タスクの階層関係がまったく分からない。

タスクの階層関係を確認するには、別画面の「プロジェクトセンタ」を開いて、プロジェクトのWBSを表示させる必要があるが、こちらの画面からは、実績作業時間は入力できない。

Project Web Accessは、プロジェクト要員がProject Professionalをインストールしなくても、ウェブ画面だけでかんたんに作業進捗を入力できるのが売りだったはずだ。

ところがOffice Project Serve 2007は、旧バージョンと比べて、プロジェクト要員にとって使い勝手がかなり悪くなってしまった。

おそらくタスク管理とタイムシート管理の２つの機能を分離し、旧バージョンのタスク管理に存在した、タイムシート管理的な機能を、すべてタイムシート機能へ追い出してしまった。このことが、タスク管理の使い勝手を「改悪」してしまったのだろう。

まったく、毎度のことながら、マイクロソフトの「バージョンアップ」には困ったものだ。

Internet Explorer 8を入れてビミョ～な不具合発生

マイクロソフトへの文句ついでに、2009/03/20に公開されたInternet Explorer 8正式版について。不具合を覚悟でインストールしてみた。

そしたら、地味なところで不具合が出た。

ふつうにウェブサイトを閲覧する分には、たしかにInternet Explorer 7よりも画面表示が高速になっている。

僕が経験した「地味な不具合」というのは、中国語の勉強のために購入した講談社「日中辞典」に付属するCD-ROMからインストールした、電子版の日中辞典が使えなくなったのだ。

この電子版の日中辞典は、ローカルPC上で動作し、インターネットの通信が一切発生しないスタンドアロンのソフトウェアである。

しかし、どうやら辞書の内容の閲覧部分にInternet Explorer関連のモジュールを流用しているらしく、妙な不具合が出た。

どういう不具合かというと、例えば検索キーワードに日本語の単語を入力すると、その中国語訳の見出しが画面右半分に表示される。

．．．はずなのだが、微妙に違う見出し語が表示されてしまう。しかたなく右半分の画面の上下スクロールバーを、一回クリックして一つ下へスクロールさせると、正しい訳語の見出しが現れる。

見出し語の表示が１画面分ずれるだけか、と思って安心し、さて、その見出し語の詳細説明を読もうと、スクロールバーをマウスでつかんでドラッグしようとすると．．．なんと、右半分の画面が２画面分ずつしかスクロールしなくなっているではないか。

キーボードの上下矢印をつかっても、やはり肝心の辞書の内容が表示される右半分の画面が、２画面単位でジャンプしてしまうのだ。

つまり、辞書の内容表示がつねに２画面単位でスクロールするので、辞書の内容の半分は閲覧不能になったことになる。これではまったく使い物にならない。

たしかにマイクロソフトが、極東の小さな島国の日本にある出版社が、たまたま辞書の付録につけたCD-ROMの電子辞書の動作まで検証できないのは仕方ない。

しかし、マイクロソフトのウェブサイトの”Internet Explorer 8はこんなに便利になりました！”的な動画に登場する、おそらく日本人向けと思われる下らないカニのキャラクターが、妙に腹立たしく感じる。

気味の悪いGoogleのパノプティコン的権力

気がついたらYouTubeでPerfumeの『気になる子ちゃん』を第1回から第14回まで見ていた。大阪では放送されていなようだ。『王様のブランチ』も放送していないし。

僕は大阪出身だけれど、大阪ローカルのバラエティー番組は、関西芸人ばっかりでうんざりする。誰もやしきたかじんや上沼恵美子なんか見たくない。テレビよりYouTubeの方が面白い。

今日、とあるきっかけから、Googleで自分のフルネームを検索したら、親サイトの「think or die」がトップに表示されたので驚いた。というのは、この「愛と苦悩の日記」を含め、親サイトにも自分のフルネームを入れないようにしているからだ。

たしかにAmazonで僕が実名で出版した本が何冊かひっかかるが、これは無関係だ。おそらく@niftyの「人気ホームページへの道」が主因だろうが、それにしてもここの親サイトをトップランクに押し上げるほどの流入があるとは思えない。

最近、親サイトは全く更新していないので、Googleのページランクが上がるはずがなく、アクセス数はこの「愛と苦悩の日記」の方が圧倒的に多いはず。

しかもこの「愛と苦悩の日記」への流入は、前にも書いたが、「mysql php 文字化け」「雅子さま　適応障害」「大久保松恵」あたりのキーワードからの流入が多く、僕の実名での流入はほぼゼロ。

以上のことから、Googleが「人為的に」僕の実名の検索結果のトップを親サイトにしているとしか考えられない。

はっきり言って、いい迷惑だ。

「人為的に」といっても具体的にどういう操作が行われているか、僕には記述できない。

でも、親サイトである「think or die」の内部には、僕のフルネームが存在しないのだから（厳密には１か所だけ存在するが）、僕のフルネームの検索結果のトップが「think or die」になるのは、どう考えてもおかしい。

「ストリートビュー」しかり、Googleは薄気味悪いパノプティコン的権力を勝手にimplementするのはやめてほしいものだ。

日経ITProの根拠薄弱なAsterisk導入のすすめ

秋田県大館市が500端末規模の電話システムにオープンソースのAsteriskという交換機ソフトウェアを利用した事例について、日経ITProというウェブサイトで、フリー・エンジニアの高橋隆雄氏が紹介している。

第36回　反響が大きかった大舘市の事例

高橋隆雄氏は、たった820万円という金額で実現できた点を検証しているが、とても楽観的で甘い分析で、そんなことでAsteriskによるIP電話システム構築が日本に普及するか？と言いたくなる。

たとえば高橋隆雄氏は、820万円という金額を実現できた最大のポイントは「自力での構築」だとしている。

たしかに高橋隆雄氏は「コストという点だけを見て自力運用に踏み切ると失敗する例も少なくない。スキルがついてこなければ自前での運用は困難を極める」と書いている。

しかし、組織にとって「スキルのある人員を確保する」こと自体がコストであることを看過している。

例えば高橋隆雄氏は、通常の電話交換機が、内線電話の増設や設定を業者まかせにせざるを得ず、設定変更作業などの出費を強いられてしまうのに対し、Asteriskの利点を次のように書いている。

「これに対してAsteriskは，自分で設定を変更できるため，即対応が可能であり，余計なコストもかからない。このように書くと設定を変更する人員のコストがかかると噛み付く人も少なくない（中略）
　これについて筆者は，『ほとんどかかっていない』と予測していた。なぜなら簡単なスクリプトを作って設定ファイルを一気に生成してしまうだけだからだ。大館市の中村氏によると，筆者の予想は正解だった」

高橋隆雄氏は、自分自身がオープンソースソフトウェアのテキストベースの設定ファイルを書き換え、一気に生成するといった作業を、朝飯前のかんたんな作業として日常的にやっているからこそ、こんなことが書けてしまう。

しかし、例えば、Excelのマクロができる要員さえおらず、そもそもAsteriskという名前も初耳といった規模の組織が、上述のような設定ファイル書き換え作業ができる要員を確保するために、どれだけのコストを負担しなければならないか。

高橋隆雄氏はその点を完全に看過している。ご自身のスキルを過小評価されている。

要するに大館市は、独学でLinuxベースのオープンソースの設定ファイルを変更できるだけのスキルをもった職員を、たまたま抱えていたので、ラッキーだったというだけの話だ。

仮に大館市の例にならって、大館市レベルの規模の地方自治体がこぞってAsteriskによる内線電話構築を始めたとき、大館市同等のスキルをもった人間を確保するのに、全体としてどれだけのコストがかかるだろうか。

そういうIT人材市場のマクロ的な観点も、高橋隆雄氏はあまり考えていないようだ。

また別の箇所には、自力で構築するとトラブルが発生するのではないかという懸念に対し、こう反論している。

「大館市が構築したIP電話用のネットワークは，それほど複雑なネットワーク構成を取っていない。内線電話専用のLANを敷設したことからも分かるように，既存のLANにオーバレイする形でVLANを切ったわけでもなければ，設定が煩雑な高機能スイッチを導入したわけでもない。つまり障害が発生しても容易に切り分けられ，回復が可能だと考えられる」

この部分の「反論」は、逆に自力で構築するには、かなりのネットワーク構築ノウハウが必要であることを裏付けている。

そもそも大館市のネットワークが「それほど複雑なネットワーク構成を取っていない」のは、複雑な構成にしなくてもよい、という判断ができる要員が、ラッキーにも存在したからではないのか。

技術的な知識のない要員が、独学でネットワーク設計をすれば、セキュリティ上のリスクを気にしすぎて、おそらく不必要に複雑なものになるはずだ。

それをシンプルな構成にできていること自体が、大館市の担当職員が、高いネットワーク構築スキルを持っている何よりの証拠である。

さらに高橋隆雄氏は次のように書いている。

「Asterisk自体のトラブルの発生はどうだろうか。知識を持った職員が少なければ，トラブル対応は困難に思えるかもしれない。だが，これも実はそれほど心配することはない。Asteriskの動作にかかわる設定ファイル類は，本連載をお読みになっていればお分かりのように，/etc/asteriskディレクトリの下に置かれる設定ファイルだけである。これらのバックアップをきちんと取っておけば，原状復帰は容易である」

高橋隆雄氏のAsteriskの連載を読んで、内容を理解できるようなスキルレベルをもったシステム要員なんて、どこにでもいると言わんばかりの内容だ。

これも一般的な組織の常識と大きくかけはなれている。

普通に考えればわかる。

IP電話交換機を自前で構築するには、かなり高度なネットワーク知識と（たとえば電話端末の給電をどう解決するかが分かっているなど）、そこそこのUnix系の運用知識をもった要員が必要で、そういう要員を内部に「新たに」確保するために、組織がどれだけの採用コストと、人件費を負担しなければいけないか。

そのことを高橋隆雄氏は完全に看過している。経営観点で社内システムの運用を見ることができていない。

高橋隆雄氏による”Astersik導入のすすめ”は、Asteriskで内線電話を構築できる、あるいは、構築したくなる規模の組織の経営者にとって、絵空事にしか聞こえないだろう。

ひとことで言えば、大館市は自力でAsteriskを構築できるスキルと、時間的余裕と、やる気のある要員をたまたま抱えていて、ラッキーだった。

それが大館市のAsterisk導入の成功要因であり、それ以外のなにものでもない。

社内でFlash動画を教材として作成・公開する手順

今日は半分仕事の話。

イントラネットでFlash動画を、ユーザ部門向けの画面操作の研修教材にしたい場合の手順をまとめておく。

（１）CamStudioで画面操作をAVI形式で動画キャプチャーする。
（２）Windowsムービーメーカーで説明の字幕をつける。
（３）WindowsムービーメーカーでWMV形式で書き出す。
（４）Any Video ConvertorでFLV形式に変換する。
（５）JW FLV MEDIA PLAYERを埋め込みプレーヤーとして再生する

まず画面動画キャプチャーソフト「CamStudio」を入手し、インストールする。必要にして十分な機能のフリーウェアだ。
http://nonn-et-twk.net/twk/CamStudio/

このソフトはSWF形式で画面操作を保存できるが、後ほどWindowsムービーメーカーで説明字幕をつけるので、AVI形式で保存する。

また、WindowsムービーメーカーでWMV形式で書き出した後、FLV形式に変換するときの最大サイズは640×480なので、CamStudioでキャプチャーするときも、必ず640×480に収まる大きさにすること。

次にWindowsムービーメーカーに、操作を記録したAVIファイルを読み込ませ、新規プロジェクトを作成し、説明の字幕をつけていく。画面の配色にも夜が、赤い太字ゴシックが適切と思われる。ここの字幕は短く簡潔に。

そしてWindowsムービーメーカーから「最高画質」で640×480のサイズ、毎秒30フレームのWMV形式ファイルで字幕つきの動画を書き出す。

次にAny Video Converter フリー版を入手し、インストールする。
http://www.anvsoft.jp/any-video-converter-free.php

このAny Video ConvertorでWMV形式ファイルを読み込み、640×480サイズのFLV形式ファイルに変換する。音声がない場合は、変換時に音声出力を無効にしておくと良い。

これでFLV形式の動画教材ができた。

次に、社内に公開するための埋め込み式FLVプレーヤー「JW FLV MEDIA PLAYER」を入手する。

http://www.longtailvideo.com/players/jw-flv-player/

ダウンロードしたZIPファイルの中にある player-viral.swf が埋め込みプレーヤーの本体で、swfobject.js がプレーヤー制御用のJavaScriptだ。

この二つのファイルを社内の適当なWebサーバにアップロードする。全社員がアクセス権を持つディレクトリにアップロードすること。

そしてFLV形式のファイルは別のWebサーバでも構わないので、適当なWebサーバにアップロードする。

次に、埋め込みFLVプレーヤーをユーザに見せるためのHTMLファイルを作成する。１ページのHTMLファイルに、いくつでも埋め込みプレーヤーを並べることができる。

当然のことながらユーザのパソコンにAdobe Flash Playerがインストールされている必要がある。（たぶんAdobe Flash Player 6以上でないとダメ）

基本的なコードは以下の通りだ。

まずHTMLのヘッダーセクション<head></head>の内部に次の１行を追加する。

<script type="text/javascript" src="http://XXXXXXX/XXXXXX/swfobject.js"></script>

ここでは先ほど swfobject.jp をアップロードした場所のURLを正確に入力するようにしよう。

次にbodyセクションの任意の場所に以下のコードを追加する。

<div id="container1"><a href="http://www.macromedia.com/go/getflashplayer">このページを見るにはFlashプレーヤーをインストールして下さい。</a></div>
<script type="text/javascript">
var s1 = new SWFObject("http://XXXXXXX/XXXXXX/player-viral.swf","ply","660","500","9","#FFFFFF");
s1.addParam("flashvars","file=http://XXXXXXXX/XXXXXXXX.flv");
s1.write("container1");
</script>

最初のdivタグのid属性に指定した名前（ここではcontainer1）と、JavaScript内の最後の行のwriteメソッドの引数は一致していなければならない。

なぜなら、id属性に指定された名前をターゲットにして、JavaScriptが埋め込みFLVプレーヤーを表示させるからだ。

JavaScriptの冒頭に player-viral.swf のURLを入力する部分があるので、こちらも先ほど player-viral.swf をアップロードした場所のURLを正確に入力しよう。

次の660、500という数字は埋め込みプレーヤーのタテ・ヨコの表示サイズだ。動画自体が640×480なので、少し余裕をもった大きさにしておく。

次の行では再生したいFLV形式ファイルへのURLを正確に入力する。

JavaScriptの最後の行の引数は、先ほど解説したとおり、冒頭のdivタグのid属性と同一の文字列にしなければならない。

このdivタグのid属性を変えることで、同じページの中に複数の埋め込みプレーヤーを並べることができる。つまり２つめの埋め込みプレーヤーは「container2」などの違う名前にしておけばよい。

作成したHTMLファイルを社内の適当なWebサーバにアップロードする。こちらは閲覧制限されたWebサーバでも構わない。

以上で、フリーウェアだけで社内での研修用FLV動画公開が可能になる。

住宅地図とストリートビューの違いについて反論あり

昨日の記事に論拠薄弱な反論のトラックバックがついた。「住宅地図」とストリートビューには決定的な違いがあるという。

その決定的な違いとは、ゼンリンは「表札だけしかみない」のに対し、ストリートビューのカメラはすくなくとも2mくらいの高さから「のぞき込んで」いることだという。

これが何の反論にもなっていないことは、書くまでもないと思うので、読者の皆さんにお任せする。

もう少しよく考えてから反論しよう。というより、トラックバックするくらいなら、もう少しよく考えてからにして欲しい。削除はしないけれど。

．．．と書き捨てようと思ったが、不親切なので一応反論しておく。

まずは不真面目な反論から。

では、身長2m50cmのゼンリンの調査員が表札だけしか見るのでなく、上からのぞき込んだら、住宅地図とストリートビューの差異は消滅するのか。もちろん答えはノーだ。

この不真面目な反論だけでも、昨日の記事へのトラックバックがほぼ無意味なことが分かる。

次に真面目な反論。

ストリートビュー反対論者が問題にしているのは、カメラで撮影した結果が公開されていることにある。

仮に撮影した映像をグーグル社が社内資料としてのみ利用するなら、というより、撮影した事実さえ公表しなかったら、誰もストリートビューに反対しない。

つまり、ゼンリンであれグーグルであれ、一方は表札しか見ておらず、他方がのぞき込んでいるという、調査時点の方法の差異は、ストリートビュー反対論者の論拠と全く無関係である。

ストリートビュー反対論者が問題にしているのは、調査時点の方法論の「程度の」差異ではなく、撮影結果が公開されている点だ。

公開されているから初めて、「プライバシーの侵害だ」というストリートビュー反対論が成立するのだ。こんなことは改めて論じるまでもない。

では、それが表札上の名前であれ、表札をマスキングした家の門構えの写真であれ、それが公開されている事実について、ゼンリンの住宅地図とストリートビューに「質的な」差異はあるだろうか。

全ての人が表札を出していることで、住宅地図上に公開されることを予期していたわけでも、許可したわけでもない。

にもかかわらずゼンリンは、いわば勝手な解釈で、「表札を出している全ての人が、地図上に公開されることに予め同意している」と見なして、住宅地図を作成している。（個人情報保護法の用語で言えば、いわゆるオプトアウト方式）

グーグルのストリートビューも同じ論理だ。「その辺に家を建てていたり、住んだりしている全ての人が、ネット上にその映像を公開されることに予め同意している」と勝手に見なして、ストリートビューを作成している。これも一種のオプトアウト方式だ。

ただ、両者は完全意味でオプト・アウト方式とは言えない。本当のオプトアウトであれば、本人が要求すれば、その本人の情報は削除されなければならない。

しかし、ゼンリンやグーグルに対して、自分の家の表札名や映像の削除要求を出しても、削除されるとは限らない。

僕が昨日の記事で論じたのは、プライバシー侵害を理由にストリートビューに反対する人々の立場に仮に立ったとき、以上のような理由から、住宅地図とストリートビューに「質的な」差異はない、ということである。

もう一度書く。僕個人がどういう意見かに関わらず、プライバシー侵害を理由にストリートビューに反対する人々の視点に立った場合、ゼンリンとグーグルのやっていることに「質的な」差異はないはずだ、ということだ。

したがって、プライバシー侵害を理由にストリートビューに反対するなら、その人たちは同時にゼンリンの住宅地図にも反対しなければ、論理矛盾をきたしていることになる。それが昨日の記事の主旨である。

この記事に対して、ストリートビューは「のぞき込んでいる」から、住宅地図と決定的に違うという反論が、全く意味をなさないことはもうお分かりだろう。

大前提として、僕は「プライバシー侵害を理由にストリートビューに反対する人たち」の視点を借りて、論を展開しているのである。

彼らの視点を借りた場合、調査時点の方法論の差異が、程度の差異であれ、質的な差異であれ、彼らがストリートビューに反対する理由に全く無関係である。

彼らにとっては、調査結果の表札名や画像が、本人の許可なく公開され、また申請による削除が困難である事実こそが問題なのであり、この点において、住宅地図とストリートビューに程度の差異も、質的な差異もない。

繰り返すが、僕個人にとってではなく、「プライバシー侵害を理由にストリートビューに反対する人たち」にとって差異がない、と言っているだけである。

以上、かなりていねいにトラックバックに書かれていた内容の無効性を説明したつもりだが、それでもご理解頂けなければ、少なくともトラックバックはご遠慮頂きたい。

もちろん、ご自身のブログでいろいろな意見をお書きになるのは自由だが、トラックバックは今後ご遠慮頂きたい。

日本で「ストリートビュー」を絶対に規制できない理由

グーグル社の思い上がった技術屋たちが、誰の断りもなく作ったグーグル・マップの「ストリートビュー」を何とか粉砕できないか、いろいろ考えていた。

しかし、日本ではプライバシー侵害を理由に「ストリートビュー」を規制できないという確信にいたった。

その理由は住宅地図の存在だ。ゼンリンの住宅地図にはご承知のように一軒一軒の表札の名前が記載されている。ゼンリンの言うことには「表札は外部に公開している情報なのだから地図に載せてもいい」らしい。

日本ではこのゼンリンの住宅地図が全く規制されておらず、かつ、ゼンリンが住宅地図の販売で金儲けすることも規制されていない。

そうである以上、日本でプライバシー侵害を理由に「ストリートビュー」に規制することはできない。逆に言えば、「ストリートビュー」を規制するなら、ゼンリンの住宅地図はなおさら規制すべきだ。

「ストリートビュー」がプライバシー侵害だとわめいている連中は、同時にゼンリンの住宅地図にも反対しなければならない。そうしなければ、グーグル社に対する単なる私的怨嗟か羨望ととられても仕方ない。

以上、これが「ストリートビュー」問題に対する、ほぼ完全な結論だ。

「DAM★とも」カラオケ録音の検閲制度はいつまで持つか？

第一興商が2008/12/01から始めた「DAM★とも」というサービスのカラオケ録音機能だが、clubDAMのウェブサイトで公開したい場合は検閲を受ける必要がある。でもこのサービス、早くも限界に達しているのではないか？

カラオケ録音の自動採番を見ていると、一日あたり3,000件はあるようだ。一人当たり10曲しか公開できないという制限はあるが、この3,000件がすべて公開するために録音されているという、最悪の仮定をしてみる。

一曲平均5分として15,000分＝250時間になる。

ウェブサイトでは検閲には48時間かかると書かれてあるが、これは単にバッファーとしての在庫を2日分持てるというだけで、作業自体は1日分の新規録音を全て処理しなければ、在庫がふくらむ一方になる。

カラオケ録音の検閲担当者が、休憩時間を除き、精神衛生を考えて、1人あたり毎日5時間、上手い歌から聞くに耐えない歌まで、検閲作業だけをしているとすると、土日祝日も含めて50人の要員が張り付いていることになる。

しかし現在、検閲作業は48時間で終わらなくなっているようだ。明らかに一日あたり録音件数の予測違いだろう。

（それにしても検閲作業に当たっている担当者の皆さん、おそらく非正規雇用の方々だろうが、心からご苦労様と申し上げたい）

ご承知のように通常のプロシューマ型ウェブサイトには、公開前の検閲はなく、事後通報による削除で対応している。そのスピード感があるから仮想コミュニティーとして機能する。

「DAM★とも」は「あしあと」機能などを持つSNS型、かつ、プロシューマ型のサービスだが、現時点では検閲制度を持ち込んでいるせいでスピード感が殺がれている。

さて、第一興商はカラオケ録音の検閲制度をいつまで維持できるだろうか。

エイサーAspire Oneを購入。大満足！

ついに格安ノートPCのacer（エイサー）「Apsire one」を購入した。大阪のソフマップで49,800円。実は東京のヨドバシカメラでは54,800円だったので出張のついでに買ったが、先週末には東京でも49,800円に値下げされていた。

バッテリーはフル充電で2.5時間程度か。今のところキーボードタッチや画面の大きさ、Windows XPでメモリ1MB、Intel Atomの処理速度も高速で、動画再生もスムーズ。全く不満はない。

バッテリーに不満の方は6セルのものを追加で購入すればよい。8,000円弱で買えるはずだ。

長時間使用時の発熱はやはり気にはなるが、2年前に9万円弱で購入した工人舎の7インチディスプレーの小型ノートが、手で触れられないほど発熱し、動画もまともに再生できない遅さだったのに比べると、雲泥の差。この2年でも確実に技術は進歩しているらしい。

唯一タッチパッドの左クリックボタン、右クリックボタンが離れすぎで操作しづらいのが難点と言えば難点。ただこれも他の無数の長所に比べれば取るに足りない難点だ。

本当は青色が欲しかったところ、白しか在庫がなかったのでやむなく白を選んだが、表面の仕上げが美しく、かえってこちらの方が良かった。非常に満足できる買い物だった。

以前勤めていた会社のWebサイトが

今となってはどうでもいいことだが、以前勤めていた会社のWebサイトの動的コンテンツの開発言語が、いつの間にかASP.NETからPHPに変わっている。

文字コードがEUCになったのはおそらくWindowsからLinuxサーバに置換したのだろうが、今さらEUC？という気がする。基幹システムがWindowsベースなら、そのうちunicodeになるのは間違いない。ユーザ登録データを基幹システムに連携するとき、文字化けをゼロにできているのだろうか。

ページデザインはほとんど変わっていないのに、多大な労力をかけてわざわざLinuxにする理由がどこにあったのか理解に苦しむ。

また、あるキーワード（これを書くとどういう会社に勤めていたかバレてしまうので書けない）で検索したページランクもすっかり落ちているが、検索エンジン最適化をやめたのだろうか。

しかも登録フォームに、入力された情報はSSL暗号化通信により守られますと書いてあるのに、URLがhttpsになっていないではないか。プライバシーマーク取得企業のWebサイトでこんなことがあっていいのか。

システム管理の基本的なレベルが、僕が在籍したときに比べて確実に落ちている。

しかも基幹システムの開発元システム会社のWebサイトに、導入事例として、辞めたはずの社員とそのシステム会社社長の対談まで掲載されている。対談内容はそのシステム会社の礼賛ばかり。完全にやらせではないか。まさか、一度辞めた社員が復帰して、あの基幹システムを継続利用することになったということか。

本当にそうなら、むしろ辞めて良かった。やはりその程度の会社だったということだ。

iTunesのm4pファイルをmp3に変換する

ご存知の方もいらっしゃると思うが、iTunesで購入したm4p形式のファイルをwmaやmp3形式に変換する方法。CD-Rへの書込みができるドライブが必要。

著作権保護されているm4pファイルはiTunes自体でmp3へ変換できないので、iTunesのディスク作成機能でいったんCD-Rに音楽CDとして焼く。

出来た音楽CDをいったんドライブから取り出して、すぐに再び挿入し、Windows Media Playerで取り込みを実行する。そうすればWindows Media Playerの設定によって、mp3形式かwma形式のどちらかで取り込まれる。あとは携帯プレーヤーにコピーするだけ。

やや面倒だが、空のCD-Rはかなり安く買える。Apple社のiPod囲い込み戦略などクソ食らえだ。

Windows XP SP2より不安定なVista SP1

自宅のWindowsは、様々なソフトを追加したり削除したりするので、長く使っていると必然的に動作が不安定になってくる。

それでもWindows XPは、どんなに不安定になっても[Alt]+[Ctrl]+[Delete]でタスクマネージャを起動して、アプリを殺すことで、少なくとも電源ボタンを押し続けて、電源を強制断する「最終手段」は避けられた。

ところが今使っているマシンの、SP1を当てたプレインストール版Windows Vista Home Basicは、実に頻繁に「最終手段」を使わなければ救えないフリーズ状態に陥ってしまうのだ。

Windows XP SP2よりもWindows Vista Home Basic SP1の方が、格段に動作が不安定である。

Acerのハードウェア（グラフィックボード？）との相性があるのかもしれないが、こう頻繁に電源強制断が必要なフリーズをするとなると、会社のWindows XP Professionalも、本当にVistaにアップグレードすべきかどうか疑問が出てくる。読者の皆さんのVista SP1はどうなのだろうか？

80年代懐かしのパソコンＣＭ

ふと思い立って、中学生のころ使っていた8ビットパソコンMZ-2200のテレビＣＭがないかとYouTubeを検索した。残念ながらなかったが、MZシリーズの紹介動画が複数見つかった他、1980年代のパソコンのテレビＣＭもたくさん見つかった。

その中でいちばん悲しかったのが下に引用したＣＭ。IBMのDOS/Vパソコンとの比較広告になっていることに驚いたのだが、NEC98シリーズの断末魔といった感じ。

個人向け売れる訳ないブラックベリー

NTTドコモがカナダのRIM社製スマートフォン「BlackBerry（ブラックベリー）」を個人向けに売り出したが、売れるわけがないだろう。

iPhoneでさえワンセグなど、日本国内の一般的な携帯電話に当然搭載されている機能がないという理由で、結局、Appleファンにしか売れていないのだ。

ましてブラックベリーはパケット定額料金制の対象でもないし、RIM社の特殊なネットワーク経由でしかインターネットやメールの閲覧ができないので、HTMLメールがまったく読めないという制限もある。

おまけに毎日のようにメンテナンスでメールの送受信ができなくなり、その時間帯は北米の業務時間外になっているので、日本では真昼間である。

しかも今日、NTTドコモのウェブサイトを見ると、日本で販売されている唯一のBlackBerry端末8707hのACアダプタ、USBケーブル、カーチャージャーが10月下旬まで品切れだというから、笑止千万。

こんな最低なスマートフォンを、いったい誰が税込31,500円も出して買う気になるだろうか。

個人顧客にとって最悪なのは、何と言ってもパケット定額制対象外という点だ。この一点だけとっても、ごく限られた富裕層しか買う気にならない代物であることは違いない。

企業向けには多少売れるかもしれないが、個人向けに売り出すとは、NTTドコモは一体何を考えているのだろうか。

またまたココログが重くて使えない

ここ２週間ほど、ココログの記事更新が重く、反映に時間がかかる。ココログのウェブサイトには夜間だけと書いてあるが、実際には昼間も記事の投稿がタイムアウトになることがある。（先週、遅めの夏休みをとっていたので気づいた）

ココログは「ココログフリー」という無料利用者向けの機能をどんどん充実させているわりに、僕のように２０年近くニフティーを有償で使っているユーザの利便性は、どうでもいいらしい。

しかも今回のサーバの高負荷は、９月２日からすでに明らかになっているにもかかわらず、いまだに対応がなされていない。

ココログほどのユーザ数のブログサービスなら、ユーザ数やトラフィックの増減のトレンドは予想できるはずだ。ハードウェアの能力がボトルネックなら、当然、計画的にサーバの能力を増強すべきだ。

富士通ほどの会社が、サーバの計画的な能力増強をやり損なうとは考えづらい。だとすれば、ミドルウェアをまともに運用するスキルがないとしか考えられない。

いずれにせよ、富士通には大規模システムを安定的に運用する能力がないということだ。

ASUSの５万円台ミニノートがとっても魅力的

最近Intel Atom搭載のASUS（アスース）「EeePC」の登場で、５万円台以下のミニノートが売れているらしい。僕も近所のヨドバシカメラに立ち寄るたびに展示品を触ってしまう。

EeePCは大量のデータを扱うには不向きだが、出張先でウェブサイト閲覧とテキストエディタで文章を書く用途に限定すれば、非常に魅力的。

先に発売された「EeePC 701」はイーモバイルの定額データ通信サービスとセットで「100円パソコン」として販売されているが、データ通信サービスの2年間総額が最低でも7万円弱なので、ネット環境のあるビジネスホテル宿泊前提なら、本体だけで十分。

内臓メモリが12GBに拡張された「EeePC 901」は1.5万円ほど高価だが、「EeePC 701」に対する最大のメリットはメモリ容量ではない。メモリ容量なら「EeePC 701」にSDHCカードを買い足せばよい。

「Eee 901」を選ぶ理由は、液晶サイズが7インチから9.8インチに拡大された点と、メーカ公表値のバッテリー持続時間が格段に良くなったことだ。この２点だけでも「EeePC 901」は買いだ。

HDD内蔵型で同価格帯のミニノートと比べても、やはり駆動部分がないので「EeePC 901」のバッテリーの持ちは随一。「EeePC 901」はとっても欲しいけれど、実は購入を正当化できるほどの出張頻度もない。しばらくヨドバシの店頭でいじるだけか。

I uninstalled Internet Explorer 8 beta2

Internet Explorer 8 beta2をアンインストールした。理由はYahoo!JAPANの天気予報や旅行のページが表示されなくなったためだ。米国本家Yahoo!のWeatherページは正常に表示されたので、買収に失敗した腹いせというわけではなさそうだ。

I uninstalled Internet Explorer 8 beta2 because the weather and travel pages of Yahoo! JAPAN have gone wrong. In the United States version of Yahoo!, IE8 beta2 normally displays weather information. So this doesn't seem to be Microsoft's "harassment" against Yahoo!.

具体的には、Yahoo!JAPANのトップページから http://weather.yahoo.co.jp/weather/ と http://travel.yahoo.co.jp/ をクリックすると、白紙の画面が表示されるだけで内容が何もない。スクリプトのセキュリティ設定をもっとも緩くしてもだめだった。

Explaining more in detail, when you use IE8 beta2 and click Yahoo! JAPAN top page link of "Weather" or "Travel", you can only see a blank page without any contents. I changed the script security configuration to the lowest level in vain.

もちろん日本語版MSNの天気情報のページは正常に表示されたし、日本語版Infoseekの天気ページも正常だった。他のサイトのFlashは正常に表示されていたので、理由はよく分からない。

Of course, Japanese version MSN's weather information page can be displayed normally. In addition, Japanese version Infoseek's weather page is also shown without any problem. Other sites' flash files have no problem. I have no idea about why only some pages of Yahoo! JAPAN failed when using IE8 beta2.

Internet Explorer 8 beta2にアップ

昨晩、ブラウザをInternet Explorer 8 beta 2にバージョンアップしてみた。Internet Explorer 7と比較してHTMLの表示が高速になった。HTMLの解析とレンダリングの速度がかなり改善されているようだ。

Skypeのアドインと、Googleツールバーが非対応になり、使えなくなったが、これはかえって良かった。Googleツールバーはそもそも使わないのでどうでも良く、何よりSkypeアドインが無効になったことで、ページ中の電話番号がSkypeリンクに変換されなくなった。

あのSkype形式リンクはWebページを非常に醜くし、耐え難かった。Skypeの設定変更をしても無効にならなかったのが、IE8にバージョンアップして消滅したので、今はホッとしている。

Googleの「ストリートビュー」機能は許されるのか？

今日、Yahoo!JAPANのニュースで、Googleの地図機能に「ストリートビュー」という新機能が追加されていることを知った。

早速、大学時代に住んでいた町や実家の付近などを地図上で歩き回ってみたが、本当に街並みがすべて連続する写真で表示され、本当に散歩しているようだ。

しかしGoogleは一体どういう風にこんな機能を実装し、公開することを正当化するのだろうか。写真には通行人が写りこんでいるが、彼らのプライバシーや肖像権は完全に無視している。

見る人が見れば分かる程度の精度で写りこんでいるので、少なくともその人物が一度はその場所を訪れたことが分かってしまう。

リアルタイムの監視システムでないとは言え、誰の断りもなくこんなことをやっていいと、Googleという会社はどうして判断できるのだろうか。

この「ストリートビュー」という機能は、偶然移りこんだ人物のプライバシー意外にも、おそらくさまざまな問題をはらんでいるはずだ。

いくらなんでも、Googleのこの「ストリートビュー」という機能は、ちょっとやりすぎではないのか。

根拠のない楽観主義者の梅田望夫なら、いろいろな理由をつけて「ストリートビュー」機能も擁護するだろう。

しかしGoogleは、一方では中国の検索規制に積極的に協力していることからもわかるように、ビジネスのためなら企業理念に反することもやってしまう、ご都合主義的な側面があることを忘れてはいけない。

企業のVista移行は単なる費用のムダ

今日、自宅の Windows Vista Home Basic が勝手に更新プログラムのダウンロードを始めたので、何かと思ったら Windows VistaのService Pack 1だった。ところがHDDの空き容量が4.5GB以上必要とのことで、断念。インストールのために空き容量が4.5GBも必要なプログラムって一体...。

ご承知のように米国大手企業の中には、Windows XPからVistaへのアップグレードを見送り、その次のバージョンを待つことに決定した会社があるそうだ。下記の日経ビジネスオンライン掲載の米『BUSINESS WEEK』誌の記事を参照のこと。

『「Windows Vista」への門戸を閉ざした企業　次の「Windows 7」を待つ企業が続出、マイクロソフトの読みは？』

この記事によると、米自動車大手ゼネラル・モーターズ、米アラスカ航空、鉄道車両部品メーカーの米トランスコ・レールウェイ・プロダクツは、少なくともVistaへの移行を見送り、次期OSを待つことにしたようだ。

企業にとってクライアントOSのアップグレードには、多大な移行コストがかかる。既存のシステムが新OSで正常に動くかの検証や、実際の移行作業など。

はたしてマイクロソフトがOSをアップグレードするたびに、それに追随するのが、各企業にとって適切な判断なのか、極めて疑わしい。

Microsoft Officeなどのアプリケーションなら、まだ取引先とのファイルのやり取りの都合上、バージョンを合わせないと不都合だという理由があるが、OSにはそういった理由は存在しない。取引先とOSのバージョンが違っても、大きな問題にならない。

唯一問題が出てくるとすれば、マイクロソフトがWindows XPのサポートを打ち切った場合だけだが、まだ世界中に大量のWindows XPユーザが存在する中で、そう簡単にサポート打ち切りもできまい。

バカを見るのは、多大な費用と手間をかけて Vista に移行する企業だけ、といったところだろう。あなたの勤めている会社も、そのバカを見た企業の一つかもしれないが。

VistoとBlackBerryの比較結果

以前、ソフトバンクのパケット定額制対象になるPUSH型メールサービス「Visto Mobile（ビスト・モバイル）」をここでご紹介した。仕事の関係で同様のサービス「BlackBerry（ブラックベリー）」と比較試用したが、いくつかの違いが分かった。

まず情報セキュリティーの面ではBlackBerryの方がかなり高度な機能を持つ。携帯端末に対して遠隔でデータ消去やロックの命令を送信すると、仮に端末が圏外や電源オフになっていても、BlackBerryは次に圏内や電源オンになったとき、その命令を優先して実行するので、必ずデータ消去やロックが実行される。対して、VistoMobileは実行されない。

また、社内のExchangeサーバとデータを同期する場合、BlackBerryは受信トレイのサブフォルダ内のメールも同期されるが、VistoMobileは同期されない。

次に、NTTドコモから発売されているBlackBerry8707hという端末と、Visto Mobileが使えるソフトバンクのNOKIA X01NK、Windows Mobile機で、バッテリーの持ちを比較すると、顕著な差が出る。BlackBerry端末のバッテリーの持ちが格段に良いのだ。NOKIA X01NKや、hTcのWindows Mobile機でVisto Mobileを動かすと、必ず毎日充電が必要になるのに対し、BlackBerry端末は２日間持つ。

その他の面では両者互角。対応機種はVisto Mobileの方が多い。

以上のことから、セキュリティ要件より費用優先で、国内出張中心、サブフォルダ内のメール同期が必要なければ、Visto Mobileの方がいい。

ただ、そこまでしてVisto Mobileを使うなら、DMZ上に中継サーバを構築する必要はあるが、Microsoft製品で端末からメールサーバまで統一する方が良いかもしれない。Windows 2008 Serverでは、Windows Mobile端末もActive Directoryで統一管理できるようなので、2008 Serverのバグが落ち着いた頃には、選択肢になっているだろう。

ここまでの話はPUSH型、つまり、携帯端末に自動でメールや予定表データが入ってくる必要がある前提だが、PULL型、つまり、毎回自分でメールや予定表データを読みに行く方式でよいなら、「CACHATTO」など、パケット定額制対象のソリューションは山ほどあるので、現場の業務要件をふまえて慎重に検討すべきだろう。

携帯電話各社の社員間24時間無料プラン比較

最近、携帯各社が社員間通話が、固定の月額基本料を支払えば24時間無料になる法人向けサービスを発表しているが、一長一短あるようだ。ここでは携帯電話が11台以上に話を絞る。

NTTドコモは、同一法人の同一グループ内300台までのドコモ携帯間なら、24時間通話無料になる。対象となる料金プランは多く、営業など社外通話が多い場合は、基本料金の高い「タイプLL」等を選んでドコモ以外への通話料を抑えられる。

KDDIは、同一法人の同一グループ内299台までのau携帯間なら、24時間通話無料になる。KDDIの特長は、同一法人のKDDIの固定電話～au携帯、固定電話～固定電話間の通話まで無料になる点だ。ただし1回の通話は90分までという制限がある。

対象となる料金プランはNTTドコモほど多くないが、営業など社外通話が多い場合は、基本料金の高い「プランLL」等を選んでau以外への通話料を抑えられる。

2008/02/28に発表されたソフトバンクの「ホワイト法人24＋」は、同一法人のソフトバンク携帯間なら、何台でも24時間通話無料になる。ソフトバンクの特長は台数制限がない点だ。しかし対象となる料金プランが「ホワイト」と「Wホワイト」のみなので、ソフトバンク以外への通話がNTTドコモやKDDIに比べて割高になる。

例えばNTTドコモの「タイプLL」の他社への通話料は30秒7.5円、auの「プランLL」の他社への通話料は1分15円、対してソフトバンクの「Wホワイト」は30秒10円（税抜き）。

1分換算するとNTTドコモは15円、auは15円、ソフトバンクは20円。1分5円差は大きい。社員間より社外通話が多ければソフトバンクが明らかに不利だ。

以上、あくまで通話料のみを見た場合、社員間を無料にしたい携帯電話の台数が300台以下で、かつ、携帯から社外への通話がはるかに多ければ、NTTドコモ、KDDIが有利となり、携帯電話の台数を加味して、社員間の通話がはるかに多いなら、ソフトバンクが有利になりそうだ。（あくまで2008/02/29現在のお話）

Asteriskビジネスに野村総研が参入

オープンソースのIP電話交換機「Asterisk」ベースの製品「xCube」を開発したモバイル・テクニカと野村総合研究所がシステムを共同開発したようだ。

モバイル・テクニカ社のニュースリリースはこちら。

「モバイル・テクニカと野村総合研究所が データセンター向け無線LAN位置検知システムおよび Click to Callソリューションを共同開発」

共同開発の中身は本質的な問題ではなく、いよいよAsteriskのようなオープンソース系のIP電話交換機ビジネスに、野村総研のような大手ＳＩコンサル会社が進出してきたということになる。

国内のAsteriskはもはやベンチャーが手を出す段階ではなく、ビッグビジネスになりつつあるということだろうか。

スマートフォンに関するガートナー・ジャパンの事実誤認記事

世界中でBlackBerryが大流行しているというデマはいい加減やめてもらいたい。ガートナーのアナリスト堀 勝雄氏が「IT media エンタープライズ」の記事『日本のユニファイドコミュニケーションが遅れているわけ』でBlackBerryの普及度について完全な事実誤認をしている。

事実誤認の部分を引用する。

「海外ではスマートフォン『BlackBerry』が業種・職種にかかわらず広く使われており、UC製品との連携に対する期待感が高い」。

これが事実誤認であることは同じ「IT media」内のモバイル関連コーナー「IT media +D mobile」のこちらの記事『携帯に押し寄せるPCのトレンド、「業界大手との競争には慣れている」――英SymbianのクリフォードCEO』の２枚目のスライドにある棒グラフを見れば一目瞭然だ。

左から「EMEA（＝欧州・中東・アフリカ）」「日本」「中国」「北米」「ROW（＝世界の残りの地域）」それぞれのスマートフォンのＯＳ（基本ソフト）のシェアが棒グラフで表示されている。BlackBerryは「RIM」という明るい水色の部分で、確かに「北米」では３割以上のシェアだが、世界の他の地域では５％以下である。

これを見れば、「海外ではスマートフォン『BlackBerry』が業種・職種にかかわらず広く使われており、UC製品との連携に対する期待感が高い」という文章が完全に間違いで、「北米に限って言えば．．．（以下同文）」と訂正しなければならないことが分かる。

上記のグラフを見れば、世界的に見て北米がいかに特殊な市場か分かるだろう。北米の市場をもって世界標準とするのは単なる偏見である。このような事実誤認を堂々とWebサイトの記事にするのでは、ガートナー・ジャパンの市場分析そのものの信憑性が疑われるのではないだろうか。

中小企業向けのIP電話運用丸投げサービス登場

2008/01/23、企業向けIP電話でおもしろいサービスが発表になった。USENグループのUCOMとシスコシステムズが協業して、中小企業向けにIP電話システムの導入から運用まで丸ごと面倒をみるいわゆるマネージド・サービスで、「uni-mo!」（ユニーモ）という名前だ。

詳細はこちらのWebサイト。「uni-mo!とは」

Flash動画を多用した分かりやすいWebサイトになっている。

IP電話交換機とIP電話機は、世界中の企業で導入実績のあるシスコシステムズ製の機器を使い、ネットワークと運用サービスはUCOMが請け負うという体制のようだ。

ネットワーク業者とIP電話機器業者が組んだこのような「丸投げ」型のIP電話運用サービスがどんどん出てくれば、中小企業はいちいち自社内にIP電話システムを構築することなく手軽にIP電話を導入して、IP電話のコスト削減効果の恩恵を受けられるので、IP電話普及の起爆剤になるかもしれない。

ITProのトンデモ連載「企業インスタント・メッセージのすすめ」

日経ITProに「企業インスタント・メッセージのすすめ」という珍妙な連載記事があるのでいちいち反論してみたい。下記の２つの記事だ。

IMの便利な使い方（その1）、会議中でも、在宅ワークにも
IMの便利な使い方（その2）、英語力のカバー、ちょっといいですか？

なおIMとはチャットソフトのことで、マイクロソフトやIBMが企業向けの製品を出している。

まずこの記事によれば、IMはURLやメールアドレスを正確に伝えるために「近くの同僚や電話の相手とのやりとりにも有効」とあるが、こんな理由だけで100万円以上かけてIMシステム一式を導入する企業などない。

次に「会議にも活用できる」として、会議中にオフィスの在席者に「急ぎで資料を5部コピーして会議室に持ってきてくれる？」といった依頼ができるとあるが、会議資料くらい事前に用意しよう。また、会議中に別の担当者に確認するくらいなら、その担当者を初めから召集しよう。会議の準備不足を補うためという理由で、IMシステム一式の投資は正当化できない。

「総務・管理系のプッシュ型活用例」として、提出書類を現場に督促するのにIMが効果的とあるが、直接会えないときにいちばん効果的なのは電話だ。IMのメッセージは他の電子メールに埋もれることもないとあるが、電話なら逃げようがない。やはりこんな下らない理由でIMシステム一式の投資を正当化できるとは思えない。

「プレゼンスで上司をつかまえろ！」として、IMがあれば「在席中」になった瞬間に上司に声をかけに行けるので便利とあるが、そこまで多忙な上司がIMのプレゼンスをいちいち真面目に設定するだろうか。非現実的な想定だ。IM上では「在席中」なのに、行ってみたら席にいない、となるのがオチだろう。やはりこんな理由でIMシステム一式の投資は正当化できない。

「安心して在宅ワーク」として、在宅勤務者との連絡が気兼ねなくとれるようになるとあるが、実例として「電話と電子メールさえあればテレワークはできないことはない。しかし、IMがあることでお互いの仕事がやりやすくなるのであれば導入すべきと判断した。事実そのとおりの効果があった」という企業担当者の発言が引用されている。

まず在宅勤務を幅広く許しているような大企業なら、IMシステム一式の導入投資くらい何でもない可能性が高い。この記事を読んで、本当にIMが必要かどうか見きわめたい企業が、在宅勤務など行っているだろうか。

次に「こっそり助け舟」という部分は、通信販売のコンタクトセンターで、スーパーバイザーがオペレータに指示を出すのにIMを利用するという、きわめて特殊な導入事例なので、これをもってIM投資を正当化できる企業はほとんどない。

「英語力をIMでカバー」として、英語のヒアリングに自信がなくても、IMなら海外拠点の外国人と打合せできるとある。しかし本当にIMだけで会社の会議が成り立つだろうか。一度も顔を見たことがなく、英語で話したこともないような相手と。

仮に顔を知っていて、下手な英語であいさつくらいしたことがある相手だとして、果たしてリスニング能力のない日本人が、複雑な話し合いをするにあたって、どの程度「通じる」英語を、IMで許されるスピードで書けるだろうか。

いくらIMが「書き言葉」だからといって返答するまで５分もかかったのでは、相手の外国人は時間のムダだ！となろう。「英語力をIMでカバー」というのは、一見説得力があるが、よくよく考えるとおよそ非現実的な想定と言える。

次の「電話機の周りのメモを減らす」は論外だろう。このためだけにIMを導入する企業はない。

「今ちょっといいですか？」についても、投資の正当化にならないのはもちろんだが、社員どうしなら断りもなくいきなり電話をかけるのは、日本企業では普通に行われていることだ。この記事の筆者は、電話をいきなりかけて相手を邪魔するのを好まないのが「日本のDNA」だと言い張っているが、以前の記事にも書いたとおり、この記事の筆者はアンケート調査結果の分析を間違えている。いきなりの電話を嫌がるのはむしろ、個人主義的な仕事のスタイルが定着している欧米である。

「ナイショ話が得意？」として、会議中の内緒話ができるとあるが、これも極めて限定された場面で、こんな目的のためだけにIMの導入投資を正当化はできない。

「すみませんが、少し遅れます。先に始めてください」では、携帯電話やPDAのIMクライアントの利便性を説いているが、社内LANで閉じたIMシステムに比べると、さらに投資が必要になる。外出先からIMのプレゼンスを気にして在席中の社員に連絡をとる日本人会社員などいるだろうか？いきなり電話をかけるのが当然だろう。

以上、これらの記事はすでにIMを導入している企業にとって、「そういう使い方もあるのか」という発見にはなるが、IM未導入の企業がIM導入投資を正当化するのにはまったく役に立たない。

そして、さすが筆者がマイクロソフト社員だけあって、日本企業の日本的な仕事のスタイルをまったく理解していない。こういう人たちが最前線に立ってマーケティング活動をしているから、企業にIMが普及しないのだ。

仮に普及するとしても、プライベートでSkypeやYahoo!メッセンジャーなどのIMが、もっと幅広い年齢層に普及してからだろう。ちょうど携帯電話のiモードが企業システムに取り込まれるのに、それだけの時間がかかったように。

年末年始のBlackBerry関連記事拾い読み

世界中で北米だけで大ブレイク中のブラックベリー（BlackBerry）というスマートフォン（高機能携帯電話）が、日本では絶対に普及しないということは以前から何度も書いている通りだが、年末年始に興味深い記事と、相変わらず見当違いな記事があった。

まずは見当違いな記事の方から。

「スマートフォンBlackBerryの企業導入が拡大」

この記事によればシステムインテグレーターの構造計画研究所によれば、「最近では1社で500台以上の端末を導入するケースも相次いで登場した」のだそうだが、これが事実なら実名を公表すべきだろう。それに、数十～数百万単位の国内スマートフォン市場でたった500台が数社に販売されたことが、何か市場にインパクトでも与えるというのだろうか。この記事は根拠薄弱な希望的観測に過ぎず殆ど無意味だ。

「ライバルはスマートフォンではない!?　BlackBerryの魅力を直撃」

昨2007年末に開催されたSalesforceのカンファレンスの報告記事だが、三段落目の「欧米と日本の温度差」という小見出しがリサーチ・イン・モーション・ジャパン社員とこの記事を書いた記者の認識不足を如実に示している。先日もここでご紹介したように、BlackBerryは欧州を含む北米以外の地域では殆ど売れていない。カナダと米国のスマートフォン市場だけが、世界中で非常に特殊な状況を示している。つまりこの小見出しの「欧米と」という部分は端的に間違いで、「北米と」と修正すべきだ。RBB TODAYは事実と異なる記事を早急に訂正すべきである。

以上のようにブラックベリー（BlackBerry）については相変わらず根拠が無かったり事実を異なったりする記事が、著名なＩＴ系ニュースサイトで平気で垂れ流しにされている。もう少し公正な評価がされれば、まだBlackBerryにも国内普及のチャンスはあるのに、この種の純然たる大衆扇動がまかり通っている限り、見識ある日本企業の経営者はBlackBerryを選択しないだろう。

次に興味深い記事の方を紹介する。

「ユニバーサルミュージック　メールや予定を携帯に自動配信，情報“時差”短くし業務効率アップ」

こちらはBlackBerry同等のサービスがより安く米ビスト（Visto）社から提供されており、日本のユニバーサルミュージックの導入事例紹介だ。最初にご紹介した記事とは違ってちゃんと実名入りである。

この記事によればソフトバンクのWindows Mobile端末を使って、パケット定額制でBlackBerryと同等のサービスを利用できるようになったとのこと。ちなみにＮＴＴドコモのBlackBerryサービスはパケット定額制対象外で、月額通信料金は青天井である。

Visto Mobileの詳細はこちらのページを参照のこと。BlackBerryと異なり、こちらはシンビアン、Windows Mobileなど複数のスマートフォンＯＳで使えるので対応機種が多い。しかも原理はBlackBerryと同じなのでセキュリティレベルも変わらない。

こういうサービスが既にあるのだから、日本国内でBlackBerryを選択するのは殆どナンセンスと言えるだろう。

「2008年のIT業界注目トピック ベスト10　グリーンIT、仮想化、国際的ハッカーの暗躍…IDG News Serviceが大予想」

こちらは米国IDG News Service発の記事だが、次の一文がなんと言っても興味深い。「ちなみにIDG News Serviceは、Microsoftが『BlackBerry』を提供するカナダのリサーチ・イン・モーション（RIM）を買収するだろうと踏んでいる」。

ただ米Vistoのような類似サービスが既に登場していることからして、BlackBerryの技術的優位性はない。マイクロソフトが本当にリサーチ・イン・モーション社を買収するとすれば、BlackBerryのサービスをWindows Mobileでも稼動するように変更して端末側も囲い込む意図がある場合だけだろう。

いずれにせよマイクロソフトの資金力をもってすれば、リサーチ・イン・モーションの買収など容易だろう。

３年後には「BlackBerryなんていうスマートフォンが北米限定でよく売れていたねぇ」という昔話になっていることはほぼ間違いない。

日本にアイフォンは必要ない

日経ビジネスオンラインが米『BusinessWeek』誌の「日本にアイフォンは必要か？」という記事を翻訳転載していた。アイフォンというのは例のApple社のiPhoneのことだ。

「日本にアイフォンは必要か？～ケータイ先進国の消費者はそっぽを向くかも」（BusinessWeek）

要約すると、アップル経営陣は日本でiPodが爆発的に売れたのだからiPhoneも売れるはずだと楽観的だが、日本の消費者はすでに高機能な携帯電話機に慣れており、たとえ3G対応のiPhoneが発売されたとしても価格性能比の悪さのため、日本市場では売れないだろう、という内容だ。

アップル社はiPhoneの日本投入に向けNTTドコモと交渉を進めているが、両者の利害が一致しないため、これも難航するだろうとしている。

BusinessWeek誌がiPhoneの日本市場進出についてここまで懐疑的な見方をしているのだとすれば、BlackBerryについてもまったく同じことが言えるだろう。

BlackBerryの方は既にNTTドコモと提携を済ませ、昨年末、BlackBerry端末だけにかかる月額利用料を引き下げするなどテコ入れをはかっているが、それでもブラックベリー端末が国内の法人向け携帯電話市場で目だって話題になることはない。

先日もお伝えしたように、世界中のスマートフォン市場を見たとき、北米市場というのはきわめて特殊な市場なのだ。iPhoneやBlackBerryが北米で成功したからといって、日本でも成功するというのは、まったく根拠のない流言飛語のたぐいである。

ＩＣタグによる書籍管理という発想の「後進性」

2008/01/01の日本経済新聞朝刊に、講談社など出版や書店、ＩＣタグで書籍管理・09年度からという記事があった。

「年間400億円以上と、国内書籍売り上げの約2％に達するとされる書籍の万引き被害を防ぐとともに店頭でのマーケティングにも活用、低迷する出版市場のテコ入れにつなげる」とのことだ。

問題はこれが出版市場のテコ入れになるのかということだ。

万引き防止ということは、レジで支払いをする時、書籍のICタグに「支払い済み」のデータを書き込み、書店の出入口のゲートで「支払い済み」データのない書籍を持ち出そうとすると警報が鳴る、という仕組みだと思われる。

ただ、ICタグの内部構造や「支払い済み」データを書き込む機器の機密が、内部関係者やICタグ技術に通じたアマチュアが「支払い済み」データを消去する手段をインターネットで公開するのは時間の問題だ。

したがって「ICタグで管理すれば万引きを防止できる」という発想が、きわめて甘い危機管理意識の上に成り立っている。インターネットのような情報伝達手段によって、情報の流通環境そのものが変質しているのに、「ICタグで万引き防止」を考えた人たちにはその認識がまったくないようだ。
この情報流通環境の変質に対する認識がないからこそ、出版業界は低迷している。にもかかわらず「日本出版インフラセンター」という、今回のICタグのしくみを共同研究した出版業界団体は、相変わらず書籍というモノをICタグのような物理的手段で保護することで、市場のテコ入れをしようとしている。

この「ICタグで書籍管理」というのは、一見、先進的なしくみのようだけれど、実際には旧態依然とした物理的なモノとしての書籍という発想から、業界団体が抜け出せていない証拠になっている。全く皮肉なことだ。

ソフトバンク携帯のPCサイトブラウザの致命的な欠陥？

ソフトバンク携帯のPCサイトブラウザにはauと比較して決定的な欠点がある。それは自分が携帯電話であることを送信してしまうことだ。

ソフトバンクの最新機種にはACCESSという会社が開発したNetFrontというWebブラウザがあり、携帯専用ではない一般のWebサイトが閲覧できる「はず」である。

ところが、ソフトバンクのNetFrontは、おせっかいにも自分がソフトバンクの携帯電話だという情報を送信してしまうので、閲覧できないWebサイトがあるのだ。

技術的な詳細はソフトバンクのこちらのページをご覧いただきたい（HTTP_USER_AGENTに関する資料）。

一方、auの携帯電話に搭載されているOperaブラウザは自分がInternet Explorerだという情報を送信するので、パソコンで閲覧できるWebサイトは電話機の記憶容量を超えない限り閲覧できる。

携帯電話にはもともと携帯電話独自のWebブラウザと、「フルブラウザ」と呼ばれるパソコンと同等のWebブラウザの２種類がある。

その「フルブラウザ」が「自分は携帯電話ですよ」という情報を送信してどうするのか。Yahoo!ケータイやEZウェブ、iモードなど、携帯電話独自のブラウザとは別に「フルブラウザ」を搭載する意味がまったくないではないか。

はっきり言ってこの点に関する限り、ソフトバンクはまったくトンチンカンなことをやっている。

ちなみにソフトバンク携帯でInternet Explorerのフリをしようとすると、有償のjigブラウザというソフトウェアをダウンロードして、UserAgentの設定をInternet Explorerに変更するしかない。

BlackBerryが世界で普及しない理由

以前、日本では絶対にBlackBerryが普及しないという記事を書いたが、そもそもBlackBerryが普及するかどうかという問い自体が無意味だったようだ。非常に特殊な北米市場を除くと、世界でスマートフォンと言えばSymbianなのだ。

確かにBlackBerry加入者数の増加は著しい。ブラックベリー社の2004/12/21発表によれば、当時BlackBerry加入者は204万4000人で、初めて200万人の大台に乗り、直前の四半期比で38万7,000人増とのこと。

RIM、新製品とBlackBerry加入者の伸びで増収増益

さらに2006/10同社発表によれば、直前の四半期に加入者が70万5,000人増加し、約700万人に達するとある。

RIMのBlackBerry加入者が620万人に──加入者数増もIDCは今後の苦戦を予測

そして2007/04同社発表によれば、直前四半期の加入者が102万人増加し、そう加入者数が800万人に達したとある。

携帯端末「ブラックベリー」の加入者，800万人に

そして2007/12同社発表によれば、直前の四半期に新規加入者が165万人に達し、累計加入者数が約1,200万人になったとある。

RIM増収増益、ホリデーシーズンの出足も好調

一方、BlackBerryのライバルであるSymbian OS搭載のスマートフォンは世界で73%のシェアを誇る。2006年第3四半期の出荷台数は1,300万台で、BlackBerryに対して１ケタの大差をつけている。

そして下記の記事にある、少し見づらいが世界各地域別スマートフォンOSシェアのグラフをご覧頂きたい。

「競合はWindows Mobileではなく独自OS」、シンビアン社長

このグラフを見ると、世界を欧州・中東・アフリカ、日本、中国、北米、その他の４地域に分けたとき、Symbian OSのシェアはそれぞれ９割以上、６割、６割、１割以下、９割以上と、北米だけが非常に特殊な市場であることが明白だ。

北米のスマートフォンOSのトップシェアはBlackBerryの約40%、マイクロソフトの約30%、Palm OSの約20%、残りがSymbian OSとなっており、他の地域と比べて異彩を放っている。

このように日本でBlackBerryが普及するかどうかという問い自体が、完全に無意味である。

Window Media Playerよりはるかにいい無償の動画再生ソフト

『地下鉄の恋』の中国語字幕を翻訳して、中国語の勉強をするのに、Windowsメディアプレーヤーよりもっと使い勝手のいい動画再生ソフトがないものかと探していたら、韓国産のGOMプレーヤーなるものを見つけた。

このGOM playerは、無償であるにもかかわらず、スペースキーで再生・停止の切り替えができたり、[X]キーで減速、[C]キーで加速ができたり、左右の矢印キーで10秒前または10秒後、Ctrlキーと左右の矢印キーで60秒前と60秒後、Shiftキーと左右の矢印キーで5分前と5分後など、キーボード操作だけでありとあらゆる再生設定ができ、非常に便利だ。

しかもMPEGの他に、AVIやDVDのVOBファイル、Real Player用の動画ファイルもそのまま再生できる。もっと早くインターネットで調べて入手していればよかった。

奇怪な記事「IMの普及を妨げる日本人のDNA？」

2007/12/20付け日経ITPro「IMの普及を妨げる日本人のDNA？」という記事が、いかにもマイクロソフトらしい的外れな記事だったので、詳細に反論してみたい。

この記事はインスタント・メッセージ（以下IM）が、欧米企業に比べて日本企業でなぜ普及しないのか、マイクロソフトの越川氏が分析しているが、その分析がかなり的外れなのだ。

記事いわく「マイクロソフトでは科学的なアプローチで日本人の特性を調べてみた」。その結果「特筆すべき日本人の特性（＝他人種との差異）は以下のものである」。

「（1）相手の気持ちを気にする繊細さがある
（2）本質を率直に表現しない
（3）ノンバーバル・コミュニケーション（非言語対話）が少ない
（4）時間・場所・状況をわきまえてコミュニケーションを行う
（5）人間関係（社会的立場、上下関係、親密度）によって切り分ける
（6）邪魔されたくないという意識が高い」

この特性分析はおそらく正しい。しかしここから引き出された分析が的外れなのだ。

越川氏はこの日本人の特性から「日本で携帯電話が普及している理由が分かるような気がする」としながら、「IMは『相手を邪魔したくない』『邪魔されたくない』というDNAを持つ日本人には、好ましくないツールであるように思われる」と分析している。

しかし、別に日本人は「邪魔したくない」「されたくない」からIMを使わないわけではまったくない。この点は後ほど述べる。

越川氏はここから突然議論を飛躍させ、別のIMに関するアンケート調査結果を持ち出し、「今後の導入検討は25%と予想以上に高かった」とし、日本人会社員の思う「IMの課題点」を列挙した後、「セキュリティの高さを備え、直感的操作で利用でき、企業のガバナンスが及ぶIMであれば受け入れられる、ということが分かる」と分析している。

さらに、若い世代に着目し、日本国内のMSNメッセンジャーのアクティブユーザーが477万人を超えていることを持ち出し、「携帯電話、PC、インターネットなどのデジタル通信が急成長した時代に育ったこのジェネレーションは、電話の音声通話や、FAXよりもIMの方が快適であると感じるのではないだろうか」と結論づけている。

正直言って、無茶な分析である。

まず、日本人の特性の(4)と(5)に注目すれば、越川氏のような結論は引き出せない。(4)と(5)によれば、日本人は上下関係のある公的な場での意思疎通と、上下関係のない友達との私的な意思疎通を、きっちりわけて考える人種だと分析できる。

日本企業でIMが普及しないのは、まさにこの点に原因がある。つまりIMは、企業内のコミュニケーションツールとしては、あまりにカジュアルすぎるのだ。

しかし日本企業にカジュアルなコミュニケーションがないわけではない。そこで日本人の特性(3)が意味をもってくる。

日本人は企業内でカジュアルなコミュニケーションをするとき、ほとんどの場合、バーバルな（＝口頭の）コミュニケーションを選択する。つまり、廊下や喫煙室、昼食時、飲み会などでのリラックスした会話だ。

したがって、正しい分析は以下のとおりになる。

日本人は(4)や(5)の特性から、社内でも公式／非公式のコミュニケーションをはっきり分ける傾向があり、さらに(3)の特性から、とくに非公式なコミュニケーションについては、直接会って話すというバーバルな方法を選ぶ。だから日本人は、そもそも会社生活でIMを必要とする場面がほとんどない。

もっと言えば、日本人の「ヤング・ジェネレーション」（越川氏が使っているこの言葉も殆ど死語だと思うが）は、越川氏が思う以上に保守的である。つまり、会社生活と私生活を、非常にはっきり区別する傾向がある。

日本人の若年層が、私生活でIMや携帯電話のメールを駆使していることには間違いない。しかしそれは飽くまで私生活に限った話であって、企業に入社してしまえば、日本人の若者は、驚くほど会社員的な生活様式に順応してしまうものだ。

仮に日本人の若者が会社でIMを使うとしても、それは就業時間中にこっそり私的な友人と連絡をとるためであって、決して業務のためではない。この点でも越川氏は日本人の傾向を見誤っている。

まして、越川氏の言う「若年者の方がタイピングに慣れているので、その点もハードルが低い」というのも、2007年の今日ではかなり的外れな分析だ。

１０年前ならまだしも、これだけ企業にパソコンが一人一台の割合で普及して、「若年者」でない日本人会社員でいまだにキーボードアレルギーのある人がいったいどれだけいるというのか。

最後に、マイクロソフトがIM導入についてアンケート調査をしたとき、なぜ「今後の導入検討は25%と予想以上に高かった」のかを考えてみる。これは単に調査結果の見方の問題だ。

この調査では「導入の予定はない」が49.1%になっており、「わからない」もあわせると、実に回答者の７割弱がIMに無関心ということになる。

このような数字は、IMに限らず、社内SNS、社内ブログ、無線LAN携帯など、新しいＩＴ系の技術について日本人会社員にアンケートをとると、だいたい共通して出てくる割合だと言える。

つまり、日本人会社員の３割弱は、何であれこの手の新しい技術に興味をもっており、その他の７割はＩＴそのものにあまり関心がない。

さらに言えば、マイクロソフトの調査に対して「今後導入を検討したい」と回答した17.9%の会社員のうち、いったい何人が社内でIMを導入する権限や職務を持っているだろうか。

以上、非常に奇怪な記事だったので、詳細に反論させて頂いた。

Windowsベースの独自開発IP-PBX「スカイ IP-PBX」

ベンチャー企業独自開発のIP-PBXで導入実績の豊富な製品を見つけた。1997年設立のスカイウェイブ株式会社の「SkyIP-PBX」だ。

ソフトバンクテレコム（旧日本テレコム）の画期的なフリーアドレスオフィス用のIP-PBXは、このスカイウェイブ社の「スカイIP-PBX」だったらしい。他にも三菱電機インフォメーションテクノロジー社の支店や、青汁で有名なキューサイ、KDDIネットワーク＆ソリューションズ、秋田県横手市、山梨県甲斐市など地方自治体の導入事例もある。

接続内線端末数はハードウェアの性能によって無制限で、日本ストラタス社の冗長化サーバを利用したソリューションもある。ドコモの無線LAN携帯電話にも対応、日本の企業文化に対応したサクサのIP電話端末にも対応している。

事業パートナーとして、NECネッツエスアイ、日立コミュニケーションテクノロジー、NTTME、KDDIネットワーク＆ソリューションズ、富士通ネットワークソリューションズなど、大手ベンダー系、大手キャリア系が名を連ねており、導入時のプロジェクト管理や、導入後の保守も一定の品質を期待できそうな印象がある。

国内企業が独自開発したIP-PBXの中では、かなり筋がよさそうな製品だ。

ただ、Googleで同製品を検索すると、2007年に入ってからは新しい動きはそれほどなく、この手の独自開発のIP電話交換機ソフトウェアの導入が、一段落して踊り場を迎えていることがよく分かる。

各企業の中小の拠点では、拠点間をIP化しさえすれば一定の通話コスト削減効果が出るので、わざわざ拠点内までIP化する必要はない、という判断の中堅・中小企業が多いということではないかと想像する。

しかしこの手のIP電話交換機ソフト、導入後正しく稼動しているのか、ベンダー自身の導入事例を除いて、客観的な評価を書いたサイトが見つからないのがやや気になる。

日本にSIPベンチャーが出てこない理由

小池良次という人が「米国情報通信ブログ」と称して、IT総合情報ポータルの「ITmedia」に「SIPベンチャー、Ribbit～最初のシリコンバレー電話会社？～」という個人ブログの記事を転載している。

記事の最後に、「日本ではこの手のSIPベンチャーが出てきませんね？米国に比べて遙かに電話料金が高いわけだから、ビジネスになるような気がするのですが。どなたか理由をご存じなら、教えてください。」と書いてあるので、頼まれもしないが勝手に答えておく。

日本企業の電話文化には「グループとして電話をとる」文化があり、１対１で話す機能しかない電話サービスでは使い物にならないからだ。

日本企業で働いたことがある人にとっては当たり前だと思うのだが、やはり米国西海岸的文化に毒されてしまった日本人には、すぐには思い当たらないらしい。

上述の記事には「米国ではすでにSIPベンチャーが出てきているのに、日本にはなぜまだ出てこないのだ」という具合に、「米国より日本は遅れている」という含みが読み取れる。

具体的に指摘すると、「音声サービスは、高度な設備と巨大なネットワークを使う電話時代がおわろうとしている」という一文だ。つまり、日本の電話はまだ旧時代の電話設備にしがみついていて、米国はそこから早くも脱出しようとしている、という意味だ。

これはどう読んでも、日本より米国の電話の方が進んでいるという意味に読める。

しかし実際には、米国の電話文化と日本の電話文化は単に「違う」だけであって、どちらが進んでいるということはない。「SIPベンチャー」がまだ出てこないからといって、それをすぐに不思議がる必要もまったくない。

梅田望夫氏も含め、こういう風に米国発で日本の後進性を指摘する人たちには、困ったものである。

日本と米国の間にあるのは「違い」だけであって、別にどちらが「進んでいるか」ということではないのだが、こういう人たちは米国から情報を発信することで、日本よりも進んだ情報をいち早く日本に伝えることができると、誤って思い込んでいるのである。

日本人はいつになったら、こういった「名誉白人」的な感覚から逃れられるのだろうか。この種の米国偏重から逃れない限り、日本はアジア外交において、いつまでたっても主導的な立場をとれないのだが。

Windows対応の格安IP電話交換機ソフトウェア「brekeke」

どうやらBrekekeの新バージョン2.1が発売されるようだ。先日触れたIP電話交換機（IPPBX）のAsterisk（アスタリスク）は、無償でオープンソースだがLinux上でしか動かないが、Brekeke（ブレケケ）は有償であるものの、100%Javaで開発されているのでWindows上でも動く。しかもWindows利用者にとってありがたいことに、.NET Frameworkでカスタマイズができるらしい。

日本国内でBrekekeを扱っているのは、株式会社ソフトエイジェンシーや株式会社瑞風があるようだ。

Brekekeは有償といっても最大同時通話数20通話で約12万円と（SIPサーバー込みの価格）、大手メーカーのIPPBXに比べればはるかに安価であることに違いない。また、日本企業の電話文化に対応したサクサのIP電話端末にも対応している。

趣味的にIP電話交換機の独自開発に手を出そうと思えば、魅力的な選択肢はいくつかあるということのようだ。

Brekekeの日本語ドキュメントは開発元の米Brekeke Softwareの日本語サイトで読める。

Brekeke PBXの日本語ドキュメントはこちら。
Brekeke SIP Serverの日本語ドキュメントはこちら。
.NETを利用した機能拡張ツールであるBrekeke PALの英語ドキュメントはこちら。残念ながらBrekeke PALの日本語ドキュメントはないようだ。

ブレケケの日本語サポート・フォーラムはこちら。

オープンソースのAsteriskを元にしたIP電話交換機5製品

企業用IP電話の話題。インターネット技術を利用した企業用の社内電話交換機（IPPBX）だが、その後ネットで調べてみると、中身が公開されているオープンソースの「アスタリスク（Asterisk）」というソフトウェアをもとにして、日本国内で開発・販売されているものが意外に多いことがわかった。

Asteriskについては日経ITProのこちらの連載記事をご参考いただきたい。

まずは、NTTデータの「Astima」。

前回もご紹介したが2007/04に発売されたNTTのひかり電話専用の小型製品。元はNTTデータの子会社であるNTTデータ先端技術が開発したもの。大手メーカーの従来型の構内電話交換機（PBX）と比べ、内線電話の構築費用は４分の１程度になるという。内線端末250台、同時通話数30チャンネルという制限はあるが、NTTグループの製品なので安心して使えそうだ。

次に同じNTTグループのNTTソフトウェア「ProgOffice」。

こちらは無線LAN対応携帯電話でも安定した内線通話ができることが売り。元はNTT研究所が開発したもの。携帯電話だけでなく、固定のIP電話も接続でき、最大500端末まで接続可能。やはりNTTグループ製品なので無線LAN対応携帯電話による内線を実現したい企業にとっては、魅力的な選択肢になりそうだ。

次にターボリナックス社の「InfiniTalk」。

ターボリナックス社は「ターボリナックス」という独自のLinux配布版を発売しているので、Linux系の技術力は信頼できそう。そのターボリナックス上でAsteriskを機能拡張したのが「Infini Talk」だ。ソニー損保に導入実績がある点に説得力がある。

次にモバイルテクニカ社の「xCube」シリーズ。

上位機種のvCube/mCubeでは他拠点構成なども実現できるようだ。こちらはユカマテリアルという水道設備メーカーに導入実績があり、やはり説得力がある。モバイルテクニカ自体は2004年設立の新しいベンチャー企業だ。

最後に前回もご紹介した「BIZTEL PRO」という製品。

ベンチャー企業のハーモナイズシステム株式会社（旧エムトゥエックス）とホスティングサービスの株式会社リンクの共同開発による製品。首都圏中古車販売のアビックスコーポレーションに小規模な導入事例があるようだ。

以上、NTTグループの2社を除くとベンチャー系なので、業務の生命線である電話設備を本当に任せて大丈夫か不安に思う総務担当者も多いだろうが、部分導入から始めて、徐々に通話費用の削減効果を出す考え方もあるだろう。

電話設備で冒険したい企業は少ないだろうから、オープンソースの「Asterisk」を機能拡張したこれらの製品の潜在的な市場規模は非常に限られることは間違いない。そんな市場に既に５社も進出しており、そのうち2社がNTTグループなので、すでに過当競争になっているとも言える。

仮にNTTグループが1,000端末規模でも安定稼動する「Asterisk」ベースの交換機（IPPBX）を開発すれば、独占状態になりそうな気もする。どうでもいいと言えばどうでもいい、非常にニッチな市場だが、まあこういう世界もあるということだ。

NTTグループもAsteriskベースのお手軽IP電話交換機を発売していた！

他にもAsteriskをベースにしたIP電話交換機があった。ＮＴＴデータがハードウェアといっしょに発売している「astima」だ。

ＮＴＴデータの製品紹介ページはこちら。
astimaの開発責任者インタビューはこちら。
日経BP社「ITPro」掲載のastimaの評価記事はこちら。

さすがＮＴＴグループの発売だけあって、無線LAN機能つき携帯電話への対応や、コールセンターシステムへの発展性など、機能が非常に充実している。また、ＮＴＴ製のIP電話機にしか対応していないのかと思いきや、逆にサクサ株式会社のIP NetPhone SXのみに対応と、なかなか渋いメーカーの電話機を狙っている。

Webブラウザによる設定画面が分かりやすそうな点も評価できる。専用のソフトフォン（Skypeのようなもので、パソコンを電話機として使うためのソフトウェア）もデザインがすっきりしていて使いやすそうだ。

IP電話交換機はなかなかFAXには対応しづらいそうだが、このastimaは何とFAXサーバ機能も持っており、G3カラーFAXの送受信までできるのがすごい。

ただし、接続可能なIP電話機の数が250台に限られており、故障時に予備機に自動的に切り替わるなどの機能はないようだ。本体はハードディスクがなく、フラッシュメモリカードに設定情報を保存する仕組みになっているので、そもそも故障が少ないということもあるだろう。

もちろんIP電話機は別途購入する必要があるが、本体価格はハードウェア込みで６０万円程度と信じられないくらいお手軽。端末数が250台を超えない中堅・中小企業にとっては、非常に魅力的な製品である。

もはや普通になったIP電話交換機

電話の話ばかりで申し訳ないが、内線番号のある会社にはビルの中に電話交換機がある。ところがこの構内電話交換機、それほど安いものではない。低機能なものでも100万円は下らない。

電話交換機には大きく分けて、昔ながらの電話交換機と、インターネットの原理を応用した電話交換機（IP電話交換機と呼ぶ）の二種類がある。一般的にIP電話交換機の方が割安なので、企業が古くなった構内交換機を買い換える場合、IP電話交換機にすることが多いようだ。

しかしIP電話交換機であっても大手メーカーが独自開発した製品は、安心感や信頼性とひきかえに値段もそこそこする。

そんな構内電話交換機の世界に「価格革命」をもたらそうとしているのが、Asteriskという無償のIP電話交換機「ソフトウェア」だ。Asteriskは普通のパソコンで動き、独自に機能を追加することもできる。極端な話、パソコン代だけで社内の電話を構築できてしまう。

しかし、Asteriskをパソコンにインストールして、自分の会社に合うように設定するのは専門的な知識が必要になる。そこで、Asteriskを素人にも使いやすくした製品やサービスが日本国内でも出てきている。

たとえばBIZTEL PROという製品だ。（＠ＩＴに掲載の紹介記事はこちら）

内線番号数を3,000件設定できる最上位製品「BIZTEL PROマスター」でも価格は100万円、年間保守料金が25万円。おそらく同規模の内線電話を旧式の構内電話交換機で実現すれば、ケタが一つ違う金額になるのではないか。

BIZTELが特徴的なのは、IP電話交換機を月額いくらのサービス（ASPサービスという）としても提供している点だろう。つまり、設備投資をしなくても、IP電話交換機を間借りして、すぐにIP電話交換機の機能を使い始められるのだ。間借りするサービスの詳細はこちらのページにある。

自社向けにいろいろ機能を追加したい場合は、買取版のBIZTEL PROを選べばいいし、標準機能でいいから手軽に使いたい場合は、間借りサービス版のBIZTELを選べば良い。これからIP電話を使おうという企業にとっては、何とも使い勝手の良い製品である。

欧米ではAmazon.comが同様の安価なソフトウェアによる構内電話交換を実現しているようだ。

Amazon.comが採用したのはピングテル社の「SIPxchange」という製品だが、故障時に自動的に予備機に切り替わる機能（高可用性機能という）をもった最上位の製品でも、たった2,720ドル。BIZTEL PROは高可用性機能が別売なっているので、BIZTEL PROよりも数段安くなっている。

ただし、BIZTELやSIPxchangeなど、安価なIP電話交換ソフトウェアの唯一の問題点は、使える電話機が限られるということだ。

日本的なビジネス電話の機能を忠実に再現したいなら、高額でも大手メーカーのIP電話交換機を導入すべきだろう。大手メーカーは、自社製のIP電話交換機専用に、日本的な企業文化に合った高機能なビジネス電話機を発売しているからだ。

いずれにせよIP電話交換機は、すでに常識になっていると言っていい。

ふつうの人にとって便利な電話とは？

今日は少しヘンなことを書く。皆さんは自宅の電話番号を、電話機の番号だと感じたことがあるだろうか。携帯電話の電話番号を、電話機そのものの番号だという感覚を持ったことがあるだろうか。

妙な質問なので、きっと戸惑われるだろう。皆さんの自宅にはおそらく固定電話があって、自宅の電話番号をかければその電話が鳴る。それは当然だが、その自宅の番号のことを、「電話機自体が持っている番号だ」とお考えになったことは、おそらくないと思う。

というのは、その電話機を持ったまま引っ越したとする。一部のIP電話など特殊な契約でない限り、引越し先では電話番号が変わる。同じ電話機が、今度は新しい電話番号にかけると鳴るようになる。

何を当たり前のことを書いているんだと言わず、もう少し読んで頂きたい。

では携帯電話はどうか。ご承知のように、携帯電話を新しい機種に買い換えるとき、新規契約しなおして番号が変わるパターンと、電話機だけを買い換えて番号は変えないパターン（いわゆる機種変更）のどちらかを選べる。

番号ポータビリティ制度が始まってからは、別の携帯電話会社に乗り換え、電話機を買い換えても、番号をそのままにすることができるようになった。

なので、携帯電話の番号のことを、「携帯電話機そのものが持っている番号だ」とお考えになったことは、あまりないと思う。番号を変えずに、電話機だけを新品に買い換えることができるからだ。

つまり、普通の人たちは「電話機そのものが電話番号を持っている」という発想をしないものである。電話番号は電話機と無関係であって、むしろ「自分の家」の電話番号であり、「自分の」携帯番号だ、という感覚の方が正常だろう。

会社で使う電話も同じことだ。自分の机にある固定電話そのものが、特定の番号を持っているなどという発想をする人は普通いない。

たしかに会社の電話は家庭の電話にない高度な機能がある。たとえば部署の電話番号というのがあって、その番号に社内や社外からかけると、同じ部署にある電話機がいっせいに鳴る。

また、会社によっては個人別にダイヤルイン番号が与えられていて、社外から直接あなたの机にある電話だけを鳴らすことができる。

いずれにせよ、あなたの机の上にある一台の電話が、部署番号にかけても鳴るし、個人のダイヤルインにかけても鳴る。ここでも「電話機そのものが特定の電話番号を持っている」という発想はしづらい。

僕らは漠然と「自宅の電話番号」「自分の携帯番号」「自部署の代表番号」などと思いながら電話を使っているだけであり、いちいち「電話機そのものが持っている番号」のことなど気にせずに使えるからこそ、電話は便利な道具なのだ。

僕は個人的に、究極の電話の世界は、全員が携帯電話しか持たないような世界だと思っている。そうなれば「自分の携帯番号」だけ覚えていればよくて、電話をかける側から見ても、一人につき一つの番号さえ覚えればいい。

会社でも同じことだ。全社員が携帯電話だけ持つようになれば、電話はとってもシンプルになる。社内からも社外からも、ある人に電話をかけたければ、その人の携帯番号さえ知っていればいい。

社内からかけるから内線番号で、社外の人はダイヤルインの外線番号で、などといった区別もなくなり、かける側が社内の人であろうが、社外の人であろうが、とにかくその人の携帯番号さえ覚えていればいい。

こういう電話世界がいちばんシンプルで、万人にとって便利だと思うのだが．．．。

究極の社用電話は「ロケーション・フリー」

最近、企業における電話について考えることが多い。

会社で使う電話で、いちばん大事なのは相手がつかまることだ。この意味で、究極の電話とはいったい何だろうか。相手がどこにいても連絡がつく究極の電話とは？

当たり前のことだが、携帯電話がそうだ。

携帯電話は、電話機がどこにあっても基地局がその位置を自動で特定し、位置情報を携帯電話会社の交換機か何かに伝え、どこからかかってきても確実に電話機を鳴らす。

その意味で、携帯電話はどこにあっても自動的に位置を特定する究極の電話だ。

重要なのは「自動的に」という点だ。携帯電話を使っている人が、いちいち自分は東京都渋谷区にいますとか、ニューヨークにいますとか、現在位置を設定する作業をしなくても、携帯電話が自動的に位置情報を送り出してくれる。

そんなこと当り前じゃないかと思われるかもしれないが、この重要性に気づいている人は意外に少ない。

したがって会社の電話としては、究極的には全社員が携帯電話を持つのが理想的だ。

もちろん社外からの電話を受けたり、高度な保留・転送機能を使うには固定電話も必要だが、ふつうの会社では、今後は固定電話は脇役、携帯電話が主役になるだろう。（コールセンターなど大量の固定電話が必要な場合を除く）

最近では、携帯電話が社内にいるときは自動的に無線ＬＡＮ対応のＩＰ電話に切り替わる仕組みもある。社内にいるときはＩＰ電話としてかかるので通信費が無料になり、一歩社外に出ると自動で携帯電話になる、といった具合だ。

また、一つひとつの携帯電話に内線番号をつけ、社内からその内線番号にかけた場合、その携帯電話が社内にあればＩＰ電話として、社外にあれば自動で携帯番号に転送されるという、とても便利な機能をもった電話交換機も発売されている。

この機能があると、社内から特定の社員に電話をかける人は、その社員専用の内線番号さえ覚えておけばいいことになる。内線番号と携帯番号の２つを覚える必要がなく、内線番号だけ覚えておけばいい。

電話の究極の姿は、このような居場所に依存しない「ロケーション・フリー」である。一人の社員が、複数の電話機（固定電話と携帯電話）、複数の番号（内線電話と携帯番号）を使わなければいけない時代は、もう終わりつつある。

別の考え方として、「デバイス独立」といって、一人の社員が複数の電話機を使うが、電話番号は一つに統一する仕組みもある。しかしこの場合、社員は今自分がどの電話機を使っているか、自分でいちいち交換機に登録する必要があり、「ロケーション・フリー」に比べると、二歩も三歩も遅れている。

会社の電話は、実はなかなか奥が深い。

ビデオニュース・ドットコムを携帯プレーヤーで聴く方法

ビデオニュース・ドットコムの音声をダウンロードして、携帯オーディオプレーヤーで通勤途中に聴けるようにする方法について、読者の方からご質問があったので説明したい。

まずベクターなどのダウンロードサイトから「GetASFStream」というフリーソフトを入手し、インストールする。

ビデオニュース・ドットコムに会員ログインし、任意の番組をいったん再生する。再生が始まったらWindows Media Playerのメニューの「ファイル(F)」→「プロパティ(P)」をクリックし、出てきた画面の「場所」に表示されている長ったらしいURLをコピーし、GetASFStreamのメニュー「ファイル(F)」→「URL貼り付け(C)」をクリックすると、自動的に新しいURLとして追加されるので、「追加」ボタンをクリックする。

そしてGetASFStreamのダウンロードボタン（赤い丸）をクリックすると、「このURL解析を行いますか?」というメッセージが表示されるので、「いいえ(N)」ボタンをクリックする。次の複数URL選択画面ではそのまあ「記録」ボタンをクリックする。

すると初期値では５倍速でストリーミング放送のダウンロードが始まる。もしこのとき、ユーザー認証ができない旨のエラーメッセージがGetASFStreamの画面上に表示されたら、何度か同じ操作を繰り返すと、そのうちエラーが出なくなる。

初期値では「C:\Program Files\GetASFStream\root\」内にダウンロードされる動画ファイルはWMV形式なので、ここからWAVE形式で音声ファイルを抽出する。それには「ぷっちでここ」というフリーソフトを、同じくベクターなどから入手してインストールする。

「ぷっちでここ」は起動して、抽出元のWMVファイルを選択し、「wavに変換」のラジオボタンを選択した状態で「開く」ボタンをクリックするだけ。とても簡単な操作だ。

なぜWAVE形式にするのかというと、１０分や１５分などの長さに分割して、携帯プレーヤーで聴くときに頭出しをしやすくするためだ。たとえば６０分番組の音声をそのまま携帯プレーヤーに転送してしまうと、４５分あたりから聴き直したいとき、早送りボタンを押し続けるのが面倒なのだ。

そこで「WAVEFLT2」というフリーソフトを利用する。Googleで検索すればすぐ見つかるので、これも入手し、解凍するだけで使える。

コマンドラインツールなので、ウィンドウズのバッチファイルを書く必要がある。バッチファイルを書けない方は別のツールで分割して頂きたい。

たとえば「waveflt2.exe -split 900 afgan02.wav "%%H%%N%%Safgan02.wav"」という１行だけのバッチファイルを作成して「～.bat」という名称で保存し、実行すると、afgan02.wavというWAVE形式のファイルが900秒ごと、つまり１５分ごとに分割され、自動的に分割時の時刻（時分秒）で始まるファイル名がつく。

次に分割したファイルをMPEG3形式に変換する。これにはlame.exeというフリーソフトが必要だ。lame.exeはSourceForgeのこちらのサイトからダウンロードできる。

圧縮ファイルを解凍すると、lame.exeという実行形式のファイルがある。これもコマンドラインツールなのでWindowsのバッチファイルを書く必要がある。バッチファイルを書けない方は、別のツールでWAVE形式のファイルをMPEG3なり、WMA形式なりに変換して頂きたい。

なぜコマンドラインツールを使うのかといえば、分割後のファイルは複数あるので、一括処理したいからだ。例えば「for %%X in (*afgan02-00*.wav) do "C:\Program Files\lame-3.97\lame.exe" -f %%X %%~nX.mp3」という１行を先ほどのバッチファイルに追加すると、分割後の「～afgan02-00～.wav」という名前のファイルを全て順番にMPEG3形式に変換してくれる。

MPEG3形式への変換が終わったら、後は携帯プレーヤーに転送するだけ。ファイル名は分割時の時分秒で始まるので、携帯プレーヤーの自動並べ替え機能で、最初から順番に聴けばよくなっているはずだ。

以上が僕なりのビデオニュース・ドットコムを携帯プレーヤーで聴けるようにする方法である。

日本でBlackBerryの命運は尽きた

先日、BlackBerryは日本では絶対に売れないと書いたが、どうやらマイクロソフトのWindows Mobileの方がかなり形勢有利なようだ。先日、東京ビッグサイトの展示会「IPコミュニケーション＆モバイル」を見て来て、そう考えた。

個人的にBlackBerryの唯一の利点と考えていたのが、メールサーバ側からBlackBerry端末に向かって、PUSH型でメールや予定表データの同期ができることなのだが、Exchange Server 2003 Service Pack 2以上なら、どうやらWindows Mobile 5に対してPUSH型の同期ができるようだ。

たしかにBlackBerryなら、メールサーバからインターネットに向かって、外向きに指定のTCP/IPポート番号の通信を許可すればよく、Exchange ServerとWindows Mobileの組み合わせのように、双方向のHTTPS通信を許可する必要がない。

ネットワーク的にはBlackBerryの方がインターネットからの脅威に対するセキュリティの確保が容易だ。

しかし、その分BlackBerryの通信は、世界のどこでBlackBerryを使おうと、必ずカナダにあるBlackBerryの発売元であるResearch In Motion社のサーバを経由するという、ネットワークトポロジー上の制限がある。

もちろんBlackBerryの通信量など知れているので、必ずカナダのサーバを経由することが性能の悪化につながるわけではない。ただ、インターネットに対して双方向のHTTPS通信を許可するのは、Webサーバの公開では普通に行われることで、セキュリティ上の短所とは言えない。

そうなると、Exchange ServerとWindows Mobileの親和性の方が、独自OSのBlackBerryと比較すると圧倒的に有利になってくる。認証にActive Directoryのユーザー名とパスワードが使えるし、Excel、Word、PowerPointも当然のことながらマイクロソフト「純正」のモバイル版Officeで閲覧できる。

日本では海外でも通話できる国際ローミング対応のWindows Mobile携帯電話が、NTTドコモ、ソフトバンクの両社から発売されており、BlackBerryのパケット通信料金が上限なしの「青天井」なのに対し、Windows Mobile携帯電話ならパケット定額制が適用される。

日本国内に限って言えば、今からBlackBerryが普及する可能性は皆無といっていい。

わずかな業務要件の違いが大きなＩＴの差を産む

業務システムをどう構築するかというのは、思われているよりも繊細な問題である。

SEが頭をひねって、利用者部門に必要そうな機能をあらかじめ組み込んでおけば、利用者部門は何とかそのシステムを使ってくれる、という考え方は楽観的すぎる。

僕自身が経験した、とてもシンプルな事例を一つあげたい。Microsoft Exchangeの予定表機能を使うか使わないか、ということだ。

僕が在籍した正社員転職支援会社では、Microsoft Exchange Serverと連動したOutlookの予定表機能は使わず、わざわざ予定表管理に別のグループウェアソフトを使っていた。

一方、同じバージョンのExchange Serverを導入していた別の企業では、ふつうにExchange Serverと連動したOutlookの予定表機能を使っていた。

表面上の使い勝手だけみると、後者がどんな場合でも効率的のように思える。会議召集と予約登録がメールと完全に連動するからだ。

正社員転職支援会社で、わざわざ予定表に別のグループウェアを使った理由は、ただ一点、自分の予定と同時に、かならず会議室（面談ブース）を予約する必要があったからだ。

転職カウンセラーは、転職希望者との面談を自分の予定として入力すると同時に、かならず面談ブースをおさえなければならない。その会社にとって社内の会議室は、利益を生み出すための「生産設備」なのだ。

また受付嬢は一日の面談予定と面談ブースの予約状況を、つねに一覧しながら、来社された転職希望者に応対しなければならない。

そうした現場業務の効率性を考えると、別のグループウェアの設備予約機能を使うほうが、現場業務を最適化できる。もちろんその予約状況が基幹業務システムと連動すればベストだ。

会議室がもつちょとした意味的な違いだけで、グループウェアを２つ運用するか、１つで済むかという具合に、ＩＴのかたちが大きく異なる。

当たり前のことだが、ＩＴ投資はあくまで業務要件で決まるものであって、その逆ではない。こと社内システムに関する限り、技術指向、シーズ指向のシステム企画は資金のムダであり、あくまで業務上のニーズが引き金にならなければならない。

当たり前のことなのだが、技術偏重のSEにとってはつねに「つまずきの石」になる論点でもある。

BlackBerryが日本で絶対に売れない理由

NTTドコモが米国で人気のスマートフォン「BlackBerry8707h」日本語対応版を2007/07/23から日本国内で販売しているのをご承知の方も多いだろう。販売形態がドコモの法人営業部によるシステム販売のみなので、一般の人がBlackBerry端末を買うことはできない。

しかし日本国内でBlackBerryは、まず売れないと断言できる。今回は「日本でBlackBerryが売れない理由」を徹底的に説明したい。

BlackBerry端末は、携帯電話にWebブラウザ、メールソフト、予定表管理機能などがついたもので、ふつうの携帯電話との最大の違いは、Lotus DominoやExchangeなどのデータが、知らない間に自動的に同期されるという点だ。

ふつうの携帯電話なら、ウィルコムのW-ZERO3なども含めて、携帯電話を操作してメールや予定表を読みに行く必要がある。一方BlackBerryは「圏内」にいる限り、サーバ側からPUSH型でデータを勝手に送り込んでくれる。この点がふつうの携帯電話との大きな違いだ。

ただ、BlackBerryが国内メーカーの多機能な携帯電話に勝っているのは、じつはこの点くらいなのだ。

では、仮にもの好きな日本企業がBlackBerryを導入したとして、それがどのように使われるか、利用シーンを想像してみよう。

まずオフィスの中でBlackBerry端末を使ってメールの送受信をするか？もちろんノーだ。

NTTドコモが提供するBlackBerryサービスは、FOMAの基本料金のほかに、月額5,700円のBlackBerry利用料が加算される。それどころか、パケット定額制が適用されない。メールや予定表を読み書きすればするほど、通信料金は限りなくふくらむ。

また、携帯電話の通話料金がかかるBlackBerryが、内線電話がわりに使われることもまずないだろう。

最近はデュアルモード携帯電話といって、オフィスにいるときは無線LAN経由でIP電話になり、通話料金がかからず、オフィスから出ると携帯電話に自動的に切り替わるなる機種が法人向けに販売されている。携帯電話を内線電話としても使いたければ、どの企業もこちらを選ぶはずだ。

ということで、当然といえば当然だが、BlackBerryの活躍の場はオフィスの外だけになる。

さて、ほとんどの企業で、業務上、社外に頻繁に出かけるのは、客先に行く必要のある社員だ。

ただ、客先に常駐で仕事をする人たちは、間違いなくモバイル通信のできるノートPCがなければ仕事にならないので、BlackBerryは必要ない。

また、海外出張や国内の宿泊出張で、定期的に会社のメールを送受信したり、予定表を読み書きする必要がある場合も、作業効率を考えてほとんどの社員がモバイル通信のできるノートPCを持ち歩くだろう。

したがってBlackBeryは、日帰り出張が多い社員に限られる。各主要都市に営業所がある企業の営業担当などがこのケースに当たる。

しかし、こういった営業担当の行動パターンを思い浮かべてみよう。

出先で気になって携帯電話でメールを確認すると、重要なメールが届いている。オフィスにもどるには電車で小一時間かかってしまう。早く返答をしなければ！

そう思った営業担当がとる行動は、間違いなく電話をかけることであって、BlackBerryの小さなキーをプチプチ押して、ちんたらとメールを作成することではない。

要するに、日帰り出張をする営業担当者に、社外からメールを「送信」するニーズがあるだろうか？ということだ。これも間違いなくノーである。

営業担当者に限らず、業務上、日帰り出張の多い社員は、スピード勝負の仕事をしているケースがほとんどのはず。そういう社員が社外で、BlackBerryに限らず、携帯端末でメールを作成するなど、まず考えられない。

メールを打っているヒマがあったら、さっさと電話で顧客に回答しろ。そして時間のできたときに日報に記録しろ、となるはずだ。

メールを打つ必要がないなら、中途半端なQWERTY形式のフルキーボードも必要ない。社内のExchange Outlook Mobile Accessなどに、ワンタイムパスワードで接続して、とりあえずメールの確認ができればいいわけだ。

幸い日本の大都市では地下でも携帯電話の圏内になっていることが多い。高い通信料金を払ってわざわざBlackBerryを導入しなくても、会社のメールを確認し、通話するだけなら、今までの携帯電話で十分なのだ。

また、BlackBerryシステムを導入するには、社内ネットワークにBlackBerry専用サーバ（BlackBerry Enterprise Server for Lotus Domino/Exchange Server）を構築し、運用する必要が出てくる。

しかも、いままでの携帯電話の代わりに、新たにBlackBerry端末を購入して配布し、基本的な使い方を再教育しなければならない。BlackBerry端末は、携帯電話というよりは携帯端末（PDA）に近く、操作をおぼえるのにそれなりの時間がかかる

BlackBerry導入にそれだけの投資が必要なのに比べれば、ノートPCから会社のメールを確認できるシステムをすでに構築している企業が、携帯電話でも同じことをするのに必要な投資や運用負荷は、かなり小さい。

たとえばExchange Serverなら、携帯電話から接続するためのOutlook Mobile Accessは無償でついてくる。携帯電話用のゲートウェイとして、WisePointなどワンタイムパスワード機能のあるリバースプロキシ製品を導入すればよい。リバースプロキシのユーザライセンス料などBlackBerryの月額利用料＋通信料金の数分の一に過ぎない。

以上のように、多機能な携帯電話が豊富にある日本国内で、BlackBerryの投資対効果を正当化するのはほぼ不可能である。

日本国内でBlackBerryの導入事例が出てくるとすれば、外資系企業で、本社がBlackBerryを標準の携帯端末に指定しており、日本法人でも導入せざるをえない、というケースに限られるだろう。

日本国内に本社のある企業がBlackBerryを導入するとすれば、資金に余裕があって、趣味や道楽で導入する場合に限られる。

NTTドコモは日本でBlackBerryビジネスを始めるにあたって、いったいどこまで市場調査を行ったのだろうか。一般消費者向けの携帯電話販売で、KDDIやソフトバンクに負け続けている焦りがあったのではないか。

日本でのBlackBerryビジネスは間違いなく尻すぼみになるので、NTTドコモの今後の展開を楽しみに注視することにしよう。

Windows Vista起動時のNumLockを無効に

最近この「愛と苦悩の日記」の記事がかなりつまらなくなってきていることはよくわかっているが、今回も下らない記事。Windows Vista起動時にNumLockキーをオフにする方法がようやくわかったので、他のページからの引用だが、検索エンジンにひっかかるように書いておく。

スタートメニュー（とは言わないのかな、Windows Vistaでは）の「ファイル名を指定して実行」をクリックして「regedit」と入力して[Enter]キーを押し、レジストリエディタを起動する。レジストリエディタの起動方法はWindows XPと同じということになる。

そして、HKEY_USERS → .DEFAULT → Control Panel → Keyboardの順にツリーを展開すると、InitialKeyboardIndicatorsという名前のキーがある。

つづけて書けば、
HKEY_USERS\.DEFAULT\Control Panel\Keyboard\InitialKeyboardIndicators
となる。

このキーの値は、初期状態ではおそらく「2147483648」になっている。レジストリエディタの画面上で、キー名の「InitialKeyboardIndicators」の部分をダブルクリックすると、値変更の画面が開くので、「値」欄に半角数字の「0」（ゼロ）を入力、「OK」ボタンをクリックして値を「0」に変更する。

そしてパソコンを再起動すれば、以降はNumLockキーがOFFの状態でWindows Vistaが起動する。
なんと下らない記事だろうか。

WordPress2.2で日付を昇順にする

WordPress2.2で、カテゴリー別や月別表示で、記事を日付の昇順に表示するためのカスタマイズ方法を、検索エンジンにひっかかるようにここに記しておく。

WordPressでは、カテゴリー別や月別表示にすると、デフォルトでは日付は降順で表示される。つまり、最新の記事から古い記事へと表示される。

ただ、カテゴリー別や月別表示にしたとき、古い記事から順に読みたいという読者も少なくないはずだ。

これを実現するには、「wp-include」フォルダ内の「query.php」というプログラムに、数行のコードを追加すればよい。

1060行目あたりに、下記のようにMySQLに向かって記事を検索するSELECT文を組み立てている箇所がある。

$request = " SELECT $found_rows $distinct $fields FROM $wpdb->posts $join WHERE 1=1 $where $groupby ORDER BY $orderby $limits";

この直後に、このSELECT文の中に、カテゴリーの抽出条件や、年月による抽出条件が含まれる場合に、SELECT文内の日付によるならびかえを、降順から昇順に変更するコードを追加すればよい。

僕が追加したのは、下記のようなコードだ。

if (strpos($request, 'category_id IN') > 0 ||
strpos($request, 'MONTH(post_date)=') > 0) {
$request = str_replace('post_date DESC', 'post_date ASC', $request);
}

ややいい加減だけれども、「category_id IN」という文字列や「'MONTH(post_date)=」という文字列が現れるのは、WHERE句に決まっているので、前者が含まれる場合はカテゴリー別表示をしようとしているとき、後者が含まれる場合は年月別、または、年月日別表示をしようとしているとき、と考えて差し支えないはずだ。

応急処置的なきらいはあるが、とりあえず所期の目的はこれで達成されている。

CentOSトラブルにハマった週末

先週、Linux系のCentOSで運用していたApache＋PHP＋MySQL環境で、centosplusという設定を利用して無理やりPHPを4.xから5.xに更新したところ、パッケージ間の整合性が失われた。

しかも、CentOSのDELLパソコンそのものが機器障害で起動しなくなるという、泣きっ面に蜂状態。やむなく常用のWindows XP機にApache2＋PHP5＋MySQL5環境を構築し、Windows Vistaの小型デスクトップを新たに購入して常用機にすることにした。

と、軽い気持ちで始めたところが、深夜2時まで作業という地獄の週末になった。

まず新しい常用機はエイサーの「ダイエットPC」でたった\59,800、超小型の筐体はとても気に入ったが、Windows Vista初体験で実に使いにくいこと。

Vista Home Basic版なら面倒なセキュリティ機能もないだろうと油断したのが間違いで、Internet Explorer 7でWindows Media Player 11の著作権管理機能を更新しようと、マイクロソフトのWebサイトからActiveXを導入しようとしても、警告の情報バーから先に進まず。

ネットをいろいろ検索して初めて「ユーザー・アカウント制御（UAC）」を無効にすればよいと分かった。この機能は初期状態は有効になっているのだが、何かソフトの導入やOSの設定変更をしようとするたびに、画面が暗転して確認メッセージが表示され、非常にうざったい。

個人利用が前提のHome Basic版でここまで高度なセキュリティ機能は無駄だと思うが、これに気づくまで小一時間かかった。

さらに苦労したのは、旧常用機でXAMPPパッケージを使わず、Windows XP上にApache2＋PHP5＋MySQL5環境を構築する作業だ。

Apache2.2のインストールは問題なく完了。PHP5もインストーラーにしたがえばApache2.2対応の自動設定がされるはずが、MySQL5を導入後、WordPressのインストールが完了しない。

小一時間試行錯誤した末、Apacheのログから、PHPのマルチバイト文字関数が存在しないことが判明。

さらに小一時間の調査の結果、PHP5インストール時に拡張モジュールを全選択したところ、Apache2.2を起動すると、OCI（オラクル呼出し用のインターフェース）が見つからないなど、大量のエラーが表示されたため、PHP初期設定ファイルから拡張モジュール読込み設定を全削除したのが原因と分かった。

そこでPHP5の変更インストールで、WordPressに必要な拡張モジュールを導入しなおし、PHP初期設定ファイル（php.ini）で注釈になっている拡張モジュール設定行（extension=～）を有効化した。

すると今度はApache2.2を起動するたびに、PHPのmb_stringモジュールは既に読込まれているとの警告ダイアログが表示される。PHP初期設定ファイルを見直すと、なんのことはない、インストーラが初期設定ファイルの末尾に、拡張モジュールを有効化する記述を自動追加してくれていたので、注釈行を手で有効化する必要はなかったのだ。

これでApache2.2＋PHP5＋MySQLは無事立ち上がり、WordPressの初期設定も完了。そこでCentOSでとっておいたMySQL4.xのWordPress用テーブルのダンプを、秀丸エディタでEUCからSJISに文字コード変換し、Windows XPのMySQL5.xに一括読込みさせるが、何度やっても失敗。

原因はいまだに不明だが、ダンプファイル内のINSERT文が、全データを１行のINSERT文で書き込もうとしているため、MySQLの何らかの処理制限に引っかかったのではないかと思われる。

そこでINSERT文を細切れにし、MySQLに１行ずつODBC接続でINSERTするVBScriptを書いたが、今度は文字コードの問題で失敗。ダンプファイルはSJISだが、MySQLの内部コードはUTF-8になっているためだ。

この「愛と苦悩の日記」に以前書いたことを思い出し、個々のINSERT前に「SET CHARACTER SET SJIS」文を実行したところ、SJISファイルを内部コードUTF-8のMySQLデータベースに無事読込むことができた。

ところが災難は続く。

MySQLのrootユーザのセキュリティを高めようと、GUI操作のMySQL管理ツールでrootアカウントの接続元サーバを削除していたところ、rootでlocalhostのMySQLサーバに接続不能になってしまったのだ。

やむなくINNODBファイル群のコールドバックアップをとってから、MySQL5を再導入し、ファイル群を書き戻すが、rootのパスワードが無効になっているらしく、やはり接続できない。

ネットを検索したところ「--skip-grant-tables」オプションをつけてMySQLデーモンを起動すると、rootパスワードなしでMySQLが起動することがわかった。

ただここでも問題があり、MySQLのマニュアルも含め、ネット上のMySQL情報はほとんどLinux前提で、Windows用のMySQLサービスの実体が「mysqld」ではなく「mysqld-nt.exe」だと気づくまでにしばらくかかった。

また「--skip-grant-tables」オプションでMySQLデーモンを起動しても、Windowsの場合はrootがパスワード無しにならないこともわかった。Windowsの場合の正解はMySQLマニュアルの下記のページにあった。

http://dev.mysql.com/doc/refman/5.1/ja/resetting-permissions.html

また、Windowsのコマンドプロンプトから下手に「mysql-nt.exe」を実行すると、プロセスが残ってコントロールパネルからMySQLサービスの起動が不可能になる。mysqld-nt.exeを強制停止するには、タスクマネージャを開いて「プロセス」タブで「mysqld-nt.exe」を選択し、「プロセスの終了」ボタンをクリックすればよい。これに気づくのにもしばらくかかった。

最終的にはrootパスワードを変更してMySQLに接続可能になり、すべての問題は解決した。XAMPPに頼らず、Windows上にApache2.2＋PHP5＋MySQL5＋WordPress環境を構築することにも成功した。

今回の地獄の週末、もとはと言えば、CentOSのPHP4.xでsimple_xml関数が使いたいばかりに、PHP5.xに更新しようとしてパッケージ間の整合性が破壊されたことが原因だった。

Windowsは利用者から見たとき、ブラックボックス部分と変更可能な部分の境界、つまり責任分解点が明確なので、自力解決できる障害と、そうでない障害の境界線も明確だ。

ところがLinuxは言ってみればすべてが公開されているので、最終的にカーネルまで手を入れる能力がなければ、トラブルの自力解決はできない。自力解決できる障害とそうでない障害の境界線が、利用者の能力に依存するが、そもそもLinuxに関する能力を客観的に把握する手段などないので、すべてが自己責任になる。

Linuxが世に出始めたころから言っていることだが、結局、大手業者のLinux支援サービスが商売として成立していることからも分かるように、責任分解点の不明確なLinuxに「素人」が手を出すのは、家庭においても企業においても、極めて危険ということだ。

Active Directory管理テンプレート.ADMファイルの文法

このページは米マイクロソフト社Webサイトの、Active Directoryのグループポリシー用の管理テンプレートファイルの文法を説明したページを、独自に日本語訳したものである。インターネットで検索する限り日本語訳が存在しなかったので訳出してみた。

Language Reference for Administrative Template Files

当然のことながら、この翻訳に基づいて作成した.ADMファイルで、あなたの会社のWindowsドメインがいかなる被害をこうむっても、筆者は何ら責任を負わない。では日本語訳のスタート。

管理テンプレートファイル言語リファレンス

このページはActive Directoryのグループポリシーを設定するための.admファイル言語の完全なリファレンスです。

各.admファイルは０個以上のポリシー設定を含み、各ポリシー設定は０以上のパートを含みます。.adm言語は下記の部分からなります。

注釈

文字列変数

クラス

カテゴリ

ポリシー

パート

項目リスト

アクションリスト

.Admファイル言語のバージョン

.admファイルの各パートを、特定のバージョンのグループポリシー編集ツールでしか評価されないように設定できます。下記はグループポリシー編集ツールのバージョン一覧です。

Windows XP SP2 ＝ 5.0
Windows Server 2003、Windows XP ＝ 4.0
Windows Server 2000 ＝ 3.0
Windows NTR 3.x and 4.x ＝ 2.0
Windows 95 ＝ 1.0

注釈

.admファイルに注釈をつけるには２つの方法があります。セミコロン（;）かスラッシュ２個（//）です。注釈はどの行の末尾にもつけられます。

文字列変数

.admファイルに文字列変数を追加するには２個の感嘆符（!!）を使います。.admファイルの最後の[strings]セクションで、すべての文字列変数を定義します。文字列は二重引用符（"）でくくります。二重引用符の内部に変数名やハードコーディングした文字列を含めることもできます。

【例】

POLICY !!LimitSize 

   EXPLAIN!!LimitSize_Explain   ; この文字列はstringsセクションで定義されています

   TIP1 "Limit Profile Size to"   ; この文字列はハードコーディングされています

[strings] 

LimitSize="Limit profile size" 

LimitSize_Explain="Limits the size of user profiles"

【推奨】
すべての文字列を[strings]セクションに記述してください。.admファイルを他の言語に翻訳しやすくなるためです。他国語に変更するとき、.admファイルの[strings]セクションを変更するだけですみます。

クラス

グループポリシー・オブジェクトエディタで表示されるポリシー名を定義します。

.admファイルの最初の部分はCLASSというキーワードです。グループポリシー・オブジェクトエディタのコンピュータの構成や、ユーザの構成で、該当のポリシーをどのように表示するかを記述します。

【文法】
CLASS 名称

名称の部分はCLASSの名称を定義します。MACHINE か USER のどちらかです。

.admファイルでCLASSの名称として MACHINE か USER 以外の名称を含む場合はエラーとなり、グループポリシー・オブジェクトエディタに読み込むとき無視されます。

【例】
下記はCLASSの記述例です。

CLASS MACHINE
CLASS USER

【注】
１個の.admファイルに複数のCLASS USER または CLASS MACHINEを定義できます。.admファイルが処理されるとき、CLASS USERはすべて一つにまとめられ、CLASS MACHINEもすべて一つにまとめられます。しかし.admファイルを管理しやすくするために、１個の.admファイルにはCLASS USERまたはCLASS MACHINEを１個だけ定義することをおすすめします。

カテゴリ

CLASSを定義したら、次はCATEGORYをつかって、グループポリシー・オブジェクトエディタで表示されるノード名を定義します。

【注】
CATEGORYを入れ子にすることで、親ノードに対する子ノードを作成できます。

【文法】

CATEGORY !!名称

    KEYNAME キー名

    [ポリシー定義] 

END CATEGORY

名称
CATEGORYの名称はグループポリシー・オブジェクトエディタのリストボックスに表示される名称のことです。変数名を二重引用符でくくることもできます。空白をふくむ名称には二重引用符が必要です。

キー名
キー名をつかって、CATEGORYのためのレジストリキーのパスを示すこともできます。

レジストリーパスにHKEY_LOCAL_MACHINE や HKEY_CURRENT_USERを使わないで下さい。CLASSですでに特定されているからです。キー名を指定すると、以下のすべての子カテゴリ、ポリシーなどの部分がこのキー名を使います。違うキー名にしたい場合は、個々に指定してください。空白を含むキー名には二重引用符が必要です。

上位カテゴリのどこにもキー名が指定されていない場合、各ポリシーで個々にキー名を指定する必要があります。さもないと、次にキー名を指定しているCATEGORYのキー名が採用されてしまいます。

ポリシー定義
CATEGORY内には０個以上のPOLICYを定義できます。ただし、下記の例のように、ポリシー定義は１個のカテゴリ内に１個しか記述できません。

【例】

CLASS USER 

; 下記のカテゴリはユーザの構成の下に表示されます

CATEGORY !!Desktop 

   KEYNAME "Software\Policies\System" 

   ; <ここにポリシーを定義します> 

   CATEGORY !!InternalApps 

   KEYNAME "Software\Policies\InternalApps" 

    ; <ここにポリシーを定義します> 

   END CATEGORY 

END CATEGORY 

[strings] 

Desktop="Desktop Settings" 

InternalApps="Line of Business Apps settings"

サポートタグ
グループポリシー・オブジェクトエディタは、要件フィールドを埋めるためにサポートタグと呼ばれるものを使います。このタグはグループポリシー管理ツールに、そのポリシーがサポートしているプラットフォームやアプリケーションを伝えます。例えば、system.admファイルに含まれる多数のポリシー設定は、サービスパックを特定するサポートタグを使っています。サポートタグに使われる文字列としてよく使われるのは、さまざまなOSやサービスパックを示す文字列です。

OSのコンポーネントがこの要件フィールドでOSやサービスパックの名称を使うのに対し、アプリケーションは、サービスパックと無関係に更新される可能性があるため、アプリケーションの特定のバージョンを指定できます。サポートタグはグループポリシー管理ツールに提示されるデータの中でも非常に重要な要素なので、正確な情報が含まれている必要があります。

.admファイルは各国語別に作成される可能性があるため、各国語対応にしやすいように、サポートタグには!!文字列変数を使うことを強くおすすめします。さらに、サポートタグはWindows XP以降のOSでしかサポートされないため、次のようにバージョン構文の中に記述してください。（こうするとWindows 2000のグループポリシー・オブジェクトエディタがサポートタグを解釈しないようにできます）

#if version >= 4
SUPPORTED!!SUPPORTED_MyApplication
#endif

CATEGORYで有効なキーワード

KEYNAME

CATEGORY

POLICY

END

SUPPORTED

【注】
CATEGORYを初期値のKEYNAMEで定義していて、同じカテゴリが.admファイル内に再度出てくる場合は、初期値のKEYNAMEが有効です。つまり、同じカテゴリですでに定義されているKEYNAMEを二度記述するとエラーになるということです。エラーを解消するには重複するKEYNAMEを削除してください。

ポリシー

ユーザが変更できるポリシー設定を記述するには、POLICYキーワードを使います。ポリシーとそれに付随する入力コントロールは、ポリシー設定をするとき管理画面上に表示されます。１個のKEYNAMEの中に複数のPOLICYを記述できます。

【文法】

POLICY 名称

   [KEYNAME キー名] 

   [EXPLAIN ヘルプ文字列] 

   [VALUENAME 値名] 

   [CLIENTEXT グローバル識別子] 

   [パート定義の記述] 

END POLICY

名称
ポリシーの名称はグループポリシー・オブジェクトエディタの名前空間に表示されます。

キー名
任意項目。カテゴリに使うレジストリキーのパスです。レジストリパスにはHKEY_LOCAL_MACHINE や HKEY_CURRENT_USERを含めないで下さい。先行するCLASS部分ですでに定義されているからです。

キー名を指定すると、配下の各PART定義内でキーが指定されない限り、すべてのPART定義でこのキーが使われます。

キーが指定されず、上位のどのカテゴリでもキーが指定されない場合は、該当のカテゴリ内の各ポリシーでキーを個別に指定する必要があります。さもないとキーを指定している次のカテゴリがキー名として使われます。

ヘルプ文字列
ポリシー設定ダイアログの「説明」タブに表示される文字列です。

値名
値名は値を変更したいレジストリ値の名称です。このオプションを設定すると、キー値をREG_DWORD の 1 に設定します。このオプションをクリアすると、レジストリ値を削除します。初期値以外の値を指定するには、対応するVALUENAMEの直下にVALUEON、VALUEOFFを記述します。これらは下記のように記述して下さい。

VALUEON ONの値
VALUEOFF OFFの値

この記述を使うと、管理者がオプションを選択した場合、値がONの値に設定されるようになります。管理者がこのオプションをクリアすると、値がOFFの値に設定されます。

グローバル識別子
スナップイン拡張のグローバル識別子を指定するオプションです。

パート定義文
ポリシーはさまざまなオプションを指定するために０個以上のPART定義文を含めることができます。PART定義文にはグループポリシー・オブジェクトエディタの下半分に表示されるドロップダウンリスト、テキストボックス、固定テキストなどがあります。

【ポリシー例】

CLASS MACHINE 

CATEGORY!!DiskQuota 

   KEYNAME "Software\Policies\MS\DiskQuota" 

   POLICY!!DQ_Enable 

      EXPLAIN !!DQ_Enable_Help 

      VALUENAME "Enable" 

         VALUEON  NUMERIC 1 

         VALUEOFF NUMERIC 0 

      CLIENTEXT {3610eda5-77ef-11d2-8dc} 

      PART!!DQ_EnableTip1    TEXT     

      END PART 

   END POLICY 

END CATEGORY 

[strings] 

DiskQuota="Disk Quotas" 

DQ_Enable="Enable disk quotas" 

DQ_Enable_Help="Enables and disables disk quota management" 

DQ_EnableTip1="Enable disk quotas for all NTFS volumes"

POLICYで有効なキーワード

KEYNAME

PART

VALUENAME

VALUEON

VALUEOFF

ACTIONLISTON

ACTIONLISTOFF

END

HELP

CLIENTEXT

POLICY

パート

ドロップダウンリスト、テキストボックス、固定テキストなど、グループポリシー・オブジェクトエディタの下半分に表示されるさまざまなオプションを指定します。

レジストリキーを1か0を設定するだけの単純なポリシーなら、PARTの記述は不要です。PARTはより親切なシステム管理ができるようにするためのもので、単純な入力コントロールでは収集できない情報を集めます。

【文法】

PART 名称 パートの型 パートの型に依存するデータ

  [KEYNAME キー名] 

  [VALUENAME 値名] 

END PART

名称
グループポリシー・オブジェクトエディタに表示するPART名称を指定します。二重引用符でくくることもできます。空白を含む名称は二重引用符が必要です。

パートのタイプ
ポリシーのPARTの型を指定します。下記に有効なPOLICY型の一覧を示します。
CHECKBOX
チェックボックスを表示します。キー値をREG_DWORD型のレジストリに設定します。チェックボックスがチェックされると、キー値は０以外の値になり、チェックされないと０になります。

COMBOBOX
コンボボックスを表示します。

DROPDOWNLIST
ドロップダウンリストのコンボボックスを表示します。ユーザは選択肢を１つだけ選べます。

LISTBOX
「追加」「削除」ボタンつきのリストボックスを表示します。１つのキーに複数値をあつかえるのはこのPART型だけです。

EDITTEXT
英数字のテキストを入力するテキストボックスを表示します。テキストはREG_SZまたはREG_EXPAND_SZ型のレジストリ値に設定されます。

TEXT
１行の固定テキストを表示します。このPART型に対応するキー値はありません。

NUMERIC
上下矢印ボタンつきの数値入力用テキストボックスを表示します。REG_DWORD型のレジストリに設定されます。

パートの型に依存するデータ
これはPARTに関する情報です。

キー名称
レジストリキーのパスのことで、任意項目です。HKEY_LOCAL_MACHINE や HKEY_CURRENT_USERは先行するCLASSのところですでに定義されているので、ここには含めないで下さい。

キー名称が指定されないと、同じ階層内の前のキー名称が採用されます。

値名
この値名は変更するレジストリ値を示します。このオプションを選択すると値はREG_DWORDの 1 となり、クリアするとレジストリ値が削除されます。初期値以外の値を指定する場合は、対応するVALUENAMEの直下にVALUEON、VALUEOFFで記述します。下記のように指定します。

VALUEON ONの値
VALUEOFF OFFの値

PARTで有効なキーワード

CHECKBOX

TEXT

EDITTEXT

NUMERIC

COMBOBOX

DROPDOWNLIST

LISTBOX

END

CLIENTEXT

PART

画面に入力コントロールを追加するためにPART型を使用する

PARTコンポーネントとともに有効なキーワードを使うと、ポリシーのプロパティ画面にさまざまな入力インターフェースを追加できます。

その文法はお互いに関連があるので、上述の管理画面の要素を作るためのこれらPART型の文法については、作業ベースで以下に説明します。

さまざまなPART型を使うとき、ポリシー設定を拡張するのにテキストや入力コントロールを追加できます。これらの型は上述のPARTコンポーネントとともに使う必要があります。

CHECKBOX PART型

このPART型はポリシー設定のプロパティ画面にチェックボックスを表示します。値はレジストリのREG_DWORD型になります。初期状態では下記のように動作します。

初期状態では、チェックボックスはチェックされていません。

チェックされたとき、チェックボックスはレジストリ値に 1 を書き込み、チェックがはずれると 0 を書き込みます。

【文法】

PART テキスト CHECKBOX

   VALUENAME 値名

END PART

テキスト

作成したチェックボックスの右側に表示されるテキストです。ハードコーディングするには二重引用符でくくります。値名の前に!!を書くことで文字列変数にもできます。

値名

選択された値が書き込まれるレジストリ値の名称を示します。オプションを選択するとREG_DWORD型の 1 が設定されます。オプションをクリアするとレジストリ値が削除されます。初期値以外の値を指定するには、対応するVALUENAMEの直下にVALUEON、VALUEOFFを記述します。下記のように記述します。

VALUEON ONの値
VALUEOFF OFFの値

これらを記述すると、管理者がオプションを選択すると、キー値がON用の値に設定されるようになります。管理者がオプションをクリアすると、キー値がOFF用の値に設定されます。

初期の動作を上書きするには次のようにしてください。

チェックボックスが初期状態でチェックされるようにするには、DEFCHECKEDを使います。上述の例なら、次のようになります。

PART !!SampleChkBox_NotChked CHECKBOX 
         DEFCHECKED 
           VALUENAME "test1" 
END PART

また、VALUEON、VALUEOFFも使えます。下記の例では次のような動作をします。

チェックボックスが選択されたらレジストリに"Enabled"という文字列を書き込む。

チェックボックスが選択されなければ数値 12 が書き込まれます。

PART !!SampleChkBox_NotChked CHECKBOX 
     VALUENAME "test1" 
     VALUEON "Enabled"  
     VALUEOFF NUMERIC 12    
   END PART

１個以上のレジストリを変更するにはACTIONLISTを使います。

CHECKBOXに有効なキーワードは下記のとおりです。

KEYNAME

VALUENAME

VALUEON

VALUEOFF

ACTIONLISTON

ACTIONLISTOFF

DEFCHECKED

CLIENTEXT

END

TEXT PART型

TEXTというPART型はポリシー設定のプロパティ画面に固定テキストを表示します。

【文法
PART テキスト TEXT
END PART

テキスト

個々に入力したテキストがそのまま表示されます。ハードコーディングする場合は二重引用符でくくります。また、値の名称の前に!!を置くことで文字列変数にもできます。

TEXTの使用例は下記のとおりです。「アクティブデスクトップを無効にする」ポリシーはアクティブデスクトップを無効にし、ユーザ自身がアクティブデスクトップを有効にしたり、設定変更したりすることを防ぎます。

【テキストの例】

POLICY !!NoActiveDesktop 

   KEYNAME "Software\Microsoft\Windows\CurrentVersion\Policies\Explorer" 

   EXPLAIN!!NoActiveDesktop_Help 

     VALUENAME "NoActiveDesktop" 

     PART !!NoActiveDesktop_Tip    TEXT     

     END PART 

END POLICY

TEXTに有効なキーワードはENDだけです。

EDITTEXT PART型

EDITTEXTは編集可能入力欄にユーザが英数字を入力できるようにするオプションです。テキストはREG_SZ型のレジストリ値として設定されます。

【文法】

PART !!テキスト EDITTEXT 

   VALUENAME 値名

END PART

テキスト
表示したいテキストをここに入れておきます。ハードコーディングする場合は二重引用符でくくります。キー値の名所の直前に!!をつけることで文字列変数にもできます。このテキストは編集可能入力欄の左に表示されます。

値名
編集可能入力欄にユーザが入力した値が下記こまれる値名です。

EDITTEXTのオプション

DEFAULT値
入力欄に入れる初期値です。このオプションを使わないと、初期値は空欄です。

MAXLEN値
入力できる文字列の最大長を指定します。入力できる文字がこの長さに制限されます。

REQUIRED
このPARTに値が入力されない限り、グループポリシー・オブジェクトエディタがこのPARTを含むポリシーを有効化できないようにします。

OEMCONVERT
ES_OEMCONVERTスタイルを入力欄に設定すると、入力したテキストがASCIIからOEMにマップされたり、逆にOEMからASCIIにマップされたりします。ES_OEMCONVERTは入力されたテキストを変換します。テキストはWindowsの文字セット（ASCII）からOEMの文字セットに変換されたり、その逆の変換をされたりします。これは、入力欄に入力された文字列をOEM文字セットに変換するCharToOem 関数をアプリケーションから呼び出したとき、適切な文字変換ができるようにするためのものです。入力欄にファイル名を入力するときにとても便利です。

EXPANDABLETEXT
REG_EXPAND_SZ型のレジストリ値として設定するテキストを指定します。初期状態ではテキストはREG_SZ型のレジストリ値になります。

EDITTEXTに有効なキーワードは以下の通りです。

KEYNAME

VALUENAME

DEFAULT

REQUIRED

MAXLENGTH

OEMCONVERT

END

EXPANDABLETEXT

CLIENTEXT

【EDITTEXTの例】
EDITTEXTやTEXTをつかったPARTの記述例は下記のとおりです。

CLASS USER 
CATEGORY !!DesktopLockDown 
  KEYNAME "Software\Policies\System" 
   POLICY !!Wallpaper    
    EXPLAIN !!Wallpaper_Explain 
     PART !!Wallpaper_Tip1       TEXT 
     END PART 
     PART !!Wallpaper_Filename   EDITTEXT 
        VALUENAME Wallpaper 
        MAXLEN 60 
     END PART 
   END POLICY 
END CATEGORY 
[strings] 
DesktopLockDown="Desktop Settings" 
Wallpaper="Desktop Wallpaper" 
Wallpaper_Explain="Used to set the desktop wallpaper" 
Wallpaper_FileName="Filename" 
Wallpaper_Tip1="Specify UNC Path for selected wallpaper"

この例では入力欄に入力されたテキストはHKEY_CURRENT_USER\Software\Policies\System\Wallpaperに書き込まれます。このテキストは最大60文字まで可能です。

ポリシー設定が「未構成」「無効」のとき、このキーは書き込まれません。

【EXPANDABLETEXTの例】
REG_EXPAND_SZ型データでレジストリ値に書き込む例は下記のとおりです。

PART!!MyVariable EDITTEXT EXPANDABLETEXT
VALUENAME ValueToBeChanged
END PART

【REQUIREDの例】
次の例は必須入力値の入力がない場合、エラーを表示します。

PART!!MyVariable E