2009年8月17日
事業領域とシステム構築の方法
ビジネス価値が高い領域はスクラッチ開発、低い領域はSaaS/ASP。ここに「ITがコア／非コア」という縦軸を入れると、BPO領域がマッピングできる。
合わせて「内製／委託」という区分も乗せてみた。ちょっと分かりにくい。「ITがコア／非コア」という区分が、企業の中の個々の事業の位置づけか、それとも企業のIT重視度か、どちらとも取れる。「内製／委託」は、後者に影響されるのではないか。
投稿者 kmatsu : 20:19 | コメント (0) | トラックバック
2009年8月11日
Movable Type 4.261へのアップグレードで難儀
MT4.1へのアップグレードに引き続き、御難に遭遇。アップグレード途中でストップ
エラーメッセージは以下のとおり。
アップグレード中にエラーが発生しました failed to execute statement ALTER TABLE mt_ts_job ADD CONSTRAINT mt_ts_job_uniqfunc UNIQUE (ts_job_funcid,ts_job_uniqkey): Duplicate key name 'ts_job_funcid' at lib/MT/Upgrade.pm line 2003..これは前回と同様に、データベース・テーブルの既存のインデックスを生成しようとするエラー。myphpadminを使って、2つのテーブルのインデクスを削除し、アップグレードを実行する。前のアーティクルでは2つめのインデックスを記録するのを忘れていた。
- テーブルmt_ts_jobのインデックスts_job_funcid
- テーブルmt_ts_funcmapのインデックスts_funcmap_funcname
ブログタイトルやコメントの一覧、あるいはアーティクルの修正など、テキストをデータベースから読み出している箇所が文字化けする。これは、開発元のサポートページに修正方法あり。
http://www.movabletype.jp/faq/mt-425-perl561-patch.html
手作業でファイルを6個ほど交換する。なお、作業指示の手順9は手順6とまったく同じ。作業指示のミス。
Movable Typeを使って6年たつ。最初の頃はサーバをいじるのが面白かったけど、このごろはアップグレードするのも面倒になってしまった。その上、アップグレードのたびに不具合が発生。まあ、不具合を解消するのも、多少は楽しんでいる。 ちなみに、前のアーティクルは数件トラックバックがあった。同じ不具合に遭遇する人が多い様子である。
投稿者 kmatsu : 21:07 | コメント (0) | トラックバック
2009年7月 7日
XHTML 2 cancelled
XHTML 2は、W3C勧告に至ることなく廃案となることが確定したとのこと。
XHTML 2、廃案へ
2年前もHTML5が優勢だった。予想通りの結末である。すでにFirefoxはHTML5を搭載している。GoogleからはChromeも登場した。IEのシェアは着実に低下している。
といっても、ブラウザは企業が覇を争う主戦場ではない。標準通りに、高速に画面を作成できればよい。戦いは雲の彼方で繰り広げられている。ブラウザはそれを覗く窓である。
投稿者 kmatsu : 21:47 | コメント (0) | トラックバック
2009年2月 6日
「幻のB級! 大都映画がゆく」(本庄慧一郎著、集英社新書)
「大都映画」という映画会社があった。活動期間は、昭和2年から戦時統制で他社と合併させられた昭和17年まで。活動期間の大半で、年間製作本数が100本を越えるという多産ぶりを発揮した。そして、製作したのは徹底して娯楽作品のみ。見物料が他社より安いこともあって、大都の映画しか見ないという根強いファンが多かったという。
本書では、大都映画の創業から消滅までが、創業者の河合徳三郎のエピソードを中心に描かれる。著者は脚本家であり、大都映画を題材にした舞台作品の脚本も書いている。
それにしても、本書で描かれる大都映画の有り様は夢か幻のようだ。土建業で一家を成してから河合商会＝大都映画を創業した河合徳三郎も、猛烈な量産で多忙だったにもかかわらず意気盛んだったスタッフも、そして何より大都映画の娯楽作品を熱心に支持した観客も、70年以上を経て歴史的な過去の中にある。
大都映画は、千本を越える作品を製作したにもかかわらず、現存するフィルムはごくわずかだという。娯楽映画しか作らなかった映画会社にふさわしい事実である。もっとも、現在ではアートと見なされる溝口健二や小津安二郎の作品でも、戦前期で残っているものは多くはない。
文芸は残り、映画は消滅する。この違いは流通する媒体の数量に起因する。テキストは数千部、フィルムは数十本。同じ数千人に届くものでも、媒体の数量によって残存する可能性が大きく違った。
ディジタル技術はこれを変えた。映像もディジタル情報となって、テキストと同じものになった。あるいは、すべてのディジタル情報と同じものになった。大量に複製され、雲として表現されるそこかしこに保存され、残存する可能性が高くなった。そして、見ようと思う者がすぐに見られるようになった。あるいは、なろうとしている。
テキストも映像も、作ること、人に提供することが簡単になった。そして、それは残る。人の知覚も変わる。
投稿者 kmatsu : 22:46 | コメント (0) | トラックバック
2008年6月 3日
「Googleを支える技術 巨大システムの内側の世界」（西田圭介著・技術評論社）
Googleのプラットフォームは、低価格のコンポーネントを大量に用いて高速で信頼性の高いシステムを構築していることで有名だ。しかし、その実態は積極的には公表されていない。秘密主義は、Googleのもう一つの顔である。
本書の著者はGoogleが公開している技術論文を読み解き、Googleの社内システムを緻密に推測する。対象は、大規模検索、分散ストレージ、分散データ処理、データセンター運用コスト、それに開発体制。
ソフトウェア技術で興味深いのは、分散ストレージ(GFS, Bigtable, Chubby)と分散データ処理(MapReduce, Sawzall)である。いずれも、検索を大量に高速に頑丈に実行するために構築されたシステムだ。そして、その目的を遂行するために強力なスケーラビリティと耐障害性を実現している。
情報技術を使ってビジネスを実現し、遂行する。必要ならアプリケーションだけでなく、プラットフォームも自製する。これは、Googleだけでなく、ほかの情報技術インテンシウな企業も同じだ。プララットフォームまで自製するコストを投資と見なせるのは、時間を短縮することがビジネスの成否に決定的だからだ。
20年以上前、日本の銀行はオンラインシステムを再構築するために、IBMに専用のトランザクションモニタ(IMS)を開発させた。システムの構築にも長い年月がかかった。今から見ればビジネスを実現する速度が牧歌的に見える。
情報技術をビジネスの核心に据える企業は情報システムを自製する。ときにはプラットフォームまで自製する。投資も惜しまない。そうでない企業が情報システムを外注する。外注経費は投資ではなく、削減すべきコストである。したがって、受託してシステムを開発するいわゆるSIerという業態は、つねにコスト削減圧力にさらされることになる。
SIerという業態は、基本的に発注者からオーダーされたシステムを構築する。そこで新しい技術が創造されることはほとんどない。ビジネス遂行のために新しい技術が創られるGoogleとはじつに対照的だ。もちろん、新しい技術を創らなくてもビジネスは成立するのだろう。
さて、本書で紹介された分散ストレージや分散処理は、Googleのコアビジネスたる検索を支えるシステムである。Googleは、検索以外のアプリケーションを増やすことにも努めており、そうしたアプリケーションを大量に頑丈に実行するプラットフォームも構築しているはずだ。つぎの関心事はここである。
なお、本書はソフトウェア技術だけでなく、データセンターの設備・電力にまで記述が及んでいる。著者はソフトウェアだけでなく、理科全般の素養も備えており、記述は的確だ。
投稿者 kmatsu : 21:45 | コメント (0) | トラックバック
2008年4月 2日
建設業界とソフトウェア業界
建設業界の姿は、受託開発ソフトウェア業界の未来像に見える。
談合消滅後の建設業界で何が起きているか
工事単価の"ダンピング"や発注者の権限強化で職人は青息吐息
(NBonline)
この記事を読んで同じことを考えた人は多いようだ。
はてなブックマーク
価格下落に苦しむだけでなく、建設業界とソフトウェア業界にはビジネスの成り立ちに類似点が多い。受託開発ソフトウェア業界の大手がITゼネコンと呼ばれるのもむべなるかな。
・労働集約型
・多重下請け構造
・付加価値が低い（ゆえに価格が下落する）
これにくわえて、会計の原価基準も建設工事と同じ工事進行基準に変更される。
もちろん、受託型ソフトウェア業界には建設業界と異なるところもある。
・完成品の姿が途中で見えない
・材料・機材が外国製品ばかりで、しかも寡占が進んでいる
そして、ソフトウェア業界には談合という受注調整メカニズムはない。たぶん。
投稿者 kmatsu : 20:43 | コメント (0) | トラックバック
2008年1月 7日
電子投票の難しさ
米国では大統領選を前に電子投票の準備が進んでいる。その様子を伝えるNew York Timesの記事。
Voting Machines - Elections - Ballots - Politics - New York Times
印象的な一文はこれ。
Part of the problem stems from the fact that voting requires a level of precision we demand from virtually no other technology.
選挙は一回限りのイベントであり、かつ、結果は当落の二値によって決定的である。当落を判定するための得票数はえてして僅差となる。したがって、投票の結果にはきわだった正確さが要求される。また、その結果に疑義が生じたときは、投票結果が検証可能でなければならない。
It is the need for anonymity that fuels the quest for perfection in voting machines.事態をややこしくするのは、投票には正確さと同時に匿名性（ある種の秘密性）が要求されることだ。無記名投票では、特定の投票者がどの候補者を選択したかを秘匿しなければならない。情報技術では、匿名性と検証可能な正確さを同時に実現することはきわめて難しい。電子投票の難しさはここにある。
日本でも地方自治体の選挙で電子投票が何度か実施されている。不具合が多く、訴訟に至ったケースもある。表面的な問題は機械や記録媒体の故障である。だが、問題の本質は匿名性と検証可能な正確さを、情報技術だけでは実現できていないことにあるのだ。
Critics of touch-screen machines say that the best choice is “optical scan” technology.
この記事の結論は紙に頼ること。タッチスクリーンで直接電子データを作るのではなく、紙にチェックしてそれを光学スキャナーで読み取り電子データを生成する。数え直す必要が生じたときは紙に戻る。匿名性と検証可能な正確さを同時に実現する手段は紙、というわけだ。
米国の電子投票機器には、投票結果をキャッシュレジスター用のプリンタでロールペーパーに印刷・記録するものがある。プリンタは、投票者の手に触れないように透明な窓から見えるように設置されており、投票結果を確定する前に目視するようになっている。とはいえ、印字は小さくて高齢者には読みづらい。また、ロールペーパーでは結果が投票者の順番に記録されてしまうので、投票者が10人しかいないような小さな投票所では個人の投票結果が分かってしまう。そのため、紙に印字する機能を備えない機種を調達した州もあるという。
電子投票というと、自宅のPCや携帯電話で投票する場面を想像する向きも多いだろう。だが、実際には投票所に電子投票機器を設置している。有権者が、強制なく自発的な意志で投票することを保証するためである。また、電子投票機器はスタンドアロンであり、投票終了後に記録媒体を選挙管理委員会運んで集計している。すべての投票所にネットワークを用意し、それを安全に安定して用いることが難しいからである。電子投票機器の主な機能は、ユーザインタフェースと結果の記録。情報技術としては実にローテクである。
「紙頼み」はローテクな情報技術よりさらにローテクである。それでも、投票で必要なものを実現するには、当面は現実解ということだろうか。
投稿者 kmatsu : 23:09 | コメント (0) | トラックバック
2007年4月22日
HTML5とXHTML2
ウェブの基本的な文書フォーマットのHTMLには、HTMLそのものと、HTMLをXMLで拡張したXHTMLという2つの系統がある。それぞれ、HTML5とXHTML2という新たな標準が検討されている。
"HTML5, XHTML2, and the Future of the Web"という記事によると、HTML5が優勢のようだ。
XHTMLはInternet Exploereをはじめとする多くのブラウザで正しく実装されなかった。さらにXHTML2サポートを表明したブラウザはない。
ブラウザでHTMLを解釈するパーサーは、エラーがあってもできるだけ動作を継続させ、文書を表示するように努める。インターネット上のHTML文書のほとんどにエラーがあることを前提とするなら、現実的な実装である。
だが、XMLのパーサーはエラーがあればそこで動作を停止する。XHTML文書をHTML文書として扱うことには、無理があるようだ。
"Beware OF XHTML"という記事はXHTMLを支持する立場だが、XHTMLがブラウザで正しく実装されていない事実は認めている。
それにしても、だ。
ajaxが流行するまで、ブラウザの進歩は10年近く停滞していなかったか？じっさい、筆者の勤務先ではつい数ヶ月前までNetscape Navigator 4.7が現役だったくらいだ。
10年年前、マイクロソフトはいわゆるブラウザ戦争で勝利を収めた。それ以来、Internet Explorerの機能強化を停止した。
クライアント上のソフトウェアはマイクロソフトの大きな収益源である。ブラウザの機能を高めることはこれを脅かす。収益源を自ら危険に晒す必要はない。
ajaxはブラウザに足りない機能をサーバによって補う方式である。ブラウザの機能を高めなかったマイクロソフトに対する宣戦布告とも言える。
HTML5ではユーザエクスピアリアンスの強化も課題となっているという。期待したい。
投稿者 kmatsu : 22:28 | コメント (0) | トラックバック
2007年4月11日
データセンター in コンテナ
コンテナにサーバ機器を詰め込み、コンテナ全体をデータセンター・パッケージにするというアイディアが注目されている。
Sun MicrosystemsはProject Black Boxというコンセプトを提示している。最初はジョークかと思ったが、かなり真剣である。現場で大量のサーバを設置するより、工場でセットアップする方が効率がよい。ラック単位では小さい。どうせなら20フィートの標準コンテナにしてしまえ、という発想が明快だ。じつに242式のサーバが格納されている。
電源、冷却水、通信回線が確保できれば、どこにでもデータセンターが設置できる。必要に応じて機動的にデータセンターを配置することもできる。
Sunに対抗するポジションにあるマイクロソフトからは、さらに一歩先のコンセプトが提案されている。論文は"An Architecture for Modular Data Centers"。パワーポイント版はこちら。
マイクロソフトの提案は過激である。人間が作業する保守用スペースを確保せずに、コンテナいっぱいに機器を詰め込んでしまえ、というのだ。では、どうやって保守するのか？答えは「現場では保守しない」である。
4年なり5年なりのライフサイクルの間に、コンテナ内の機器は少しずつ故障し、動作しなくなっていく。それを冗長構成で補い、システム全体としての機能が継続できるようにする。つまり、コンテナ全体を1つのシステムと見なし、全体の性能が経年変化によって劣化していくと捉えるのだ。もちろん、ライフサイクル満了時の性能劣化が許容範囲に収まるように設計する。
ライフサイクル満了時には、別のコンテナ・データセンターを持ち込んで切り替え、役割を終えたコンテナは工場に戻されて、リサイクルされる。
こうした巨大なコンピュータシステム・パッケージを、メインフレーム・コンピュータの再来と言う人もいるだろう。だが、システムを構成するコンポーネントはベンダー固有ではなく、汎用品だ。RAID(Redundant Arrays of Inexpensive Disks)ならぬ、RAICS(Redundant Arrays of Inexpensive Computer Systems)なのである。
ユーティリティ・コンピューティングやSaaS(Software as a Service)が注目されるとともに、データセンターの役割が増している。サーバを提供するベンダーは当然この分野に注力する。その果実の一つがデータセンター・コンテナなのである。
クライアントサイドのビジネスで圧倒的な成功を収めたDellも、データセンタービジネスに注目し、"Dell Cloud Computing Solution"を発表している。
こうした動きはコンピュータ技術として興味深く、ユーザとしても目を離せない。
註：マイクロソフトの論文は、Nicholas Carrの"Rough Type: Nicholas Carr's Blog"で知った。