作るとは？
|
マークアップエンジニアとして社会人のスタートを切った荘野和也さん。HTMLやCSSだけでなく、JavaScriptやXUL、PHPと活躍の場を広げていった荘野さんの仕事術とは。（11/12） 社会に大きな影響を、しかも良い影響を与えるようなサービスや製品を作りたい。だから30歳まではひたすら勉強する──。一時は「Webから取り残されていた」とまで思っていた浜本階生さんのサービス開発とは。（10/17） 今回の「ひとりで作るネットサービス」は、番外編として「チームでつくるネットサービス」を取り上げる。会社の枠を越えて集まった3人が作ったネットサービスとは？ その企画、開発、運営のウラにはどういった苦労があったのだろうか。（10/03） ブラウザ上でブログのデザインを作成し、利用したりほかの人と共有できるサービス「CSSEZ」。これを1人で作り上げたのは、プログラミング歴1年のクボケーさんだ。（09/03） カップルでネットサービスを作った2人がいる。ネット企業に勤め、開発のスキルも持つ者同士。普段からシステムの話で盛り上がる2人が、力を合わせてサービス開発を始めた事の始まりは……。（07/26） 購読しているフィードを解析するRSSリーダー「ReadOne」。文章を解析するAPIサービス「KOSHIAN」「TSUBUAN」──。数々のネットサービスを開発してきた若きエンジニアの目指す道は。（07/23） 少人数でシンプルなツールを作る「37Signals」に憧れた。Plnet.jpを作っていく中で、1人でもサービスを作ることができると知った。一方で自分に足りないことも知った。生活も仕事もシンプルを心がける駒形さんのスタイルとは──。（07/11） 今回は「ひとり」ではなく有志によるグループで開発・運営しているネットサービスを紹介する。大学サークルのチラシをネットで公開する「サークルライフ」だ。学生が中心となり、社会人がサポートして活動している。学生メンバーたちをまとめ、運営していく方法にもコツがあるようだ。（06/14） 「有名人身長推定サイト SETAKE」「EREK」などのサービスを作ったたつをさんはドメイン取得からサービスリリースまでは半日でこなすという。飲み会で生まれたアイデアをもとにサービスを開発することもあるため、ペンはどこにでも持ち歩く工夫をしている。（06/11） 「あとで行く」を開発した石原淳也さんは新入社員時に課された「弁当の買い出し」のためにExcelマクロを組んだことがきっかけで、コンピュータの面白さに目覚める。その後、転職や米国勤務を経て、開発者として独立に至る道のりは――。（05/23） Webデザインとプログラミングの両方をこなすYasuhisaさん。「国際的な仕事をしたい」と米国に留学したが、そこで出会ったインターネットが人生を変えた。ロディアのメモからWebデザインを立ち上げる一方、PHPでプログラムも作成する。（05/07） 「3分クイズ」などを作ったサイボウズ・ラボの秋元裕樹さんは、小学生のころからゲームに魅せられていた。ブログ運営やインターネットそのものも、彼にとっては大きな意味での“ゲーム”だという。（04/17） あきやんこと秋田真宏さんは、石川県で育ったゲーム作りが大好きな少年だった。彼を動かすのは自分の作ったプログラムが周りの人に注目され、喜ばれること。プログラマーとして地元で就職したが、ブログを通じて東京にはすごい技術者がたくさんいることを知り、会社を説得して東京への転勤に成功した。（04/02） ダミーの個人情報を大量に生成できる「なんちゃって個人情報」の作者、kazinaさん。少年時代はゲームが大好きで「自分も作りたい」と思ったのをきっかけにプログラミングを始めた。「やりたいこと」を探してオーストラリアに渡って英語を学んだり、アクセサリーを作ったりと、PC関連以外の活動も好きだという。（03/28） コミュニティ型の英単語学習サイト「やわなん」を手がけるりもじろうさん。小さい頃から海外が身近な存在だったこともあり、ITを使って「住みたいところに住む」ために英語学習サイトを開発した。（03/08） 新感覚の○×コミュニティ「コトノハ」などを手がける大日田貴司さん。「文系だから、プログラマーなんて無理」と思っていた学生時代を経て、プログラミング未経験可の会社に就職。業務のかたわら独自のサービスを作り、スカウトされて転職、そして独立――。一見順調に見えるキャリアだが、その裏には焦りや苦労もあった。（02/20） まだ大学生でありながら企業を経営し、かつメタ検索エンジン「CEEK.JP」や「はてブニュース」など、個人としてネットサービスの提供を行う吉田光男さん。既存のサービスの不満点を改良したサービスを自分で作ることにやりがいを感じるそうだ。（01/30） 生活改善応援サイト「早起き生活」を運営するのは、書籍編集者の百瀬央さん。職業に必須ではないプログラミングを学んだきっかけは、エンジニアに「どうせ技術のこと分からないんでしょ」という態度を取られ、悔しかったからだという。（12/19） 最近、個人が提供するネットサービスが増えている。これらを作る人は何を思い、どのように運営しているのだろうか。GTDでおなじみの田口元氏が、ネットサービス開発者にインタビューする。第1回は「SimpleAPI」を開発する伊藤まさおさんに話を聞いた。（11/27） グループウェア「サイボウズ」にAjax導入した新版、携帯連携も強化サイボウズは11月28日、中小規模向けWebグループウェア「サイボウズ Office」シリーズの最新版「サイボウズ Office 7」を発売した。Ajaxを使い、ユーザーインタフェースを改善したほか、携帯電話との連携機能も強化した。 gooランキング：仕事に行き詰まりを感じたら、まずは「ソニー」から学べ！ビジネススキルを高めるための方法の1つが、カリスマ経営者たちが書いたビジネス書に触れること。ビジネスパーソンに聞いた、一度は読んでみたいと思う本とは？ 文具王の「B-Hacks！」：黄色い紙は自分用筆者は色付きのコピー用紙を用途に分けて使っている。たとえば「黄色は自分用」と決めているのだ――。 ライフハック テンプレート：＃057 自分ポスターあなたはキチンと自己PRできていますか？ 自分を映画の主人公に例え、ストーリーを作ってみましょう。 以前は自分が伸びていた感じがあったのに、最近は伸びている感じがしない。意外なところにある自己成長を阻害するワナを解説する ビジネスでもプライベートでも多くの人がコミュニティに携わるHP。社員の自由な活動を支える企業文化と行動規範とは 情報処理技術者試験がITSS(ITスキル標準）と融合しようとしている。どこへ行く、情報処理技術者試験？ jobtxt1 += '30代で派遣・フリーの仕事はなくなるのか？43歳エンジニアと派遣会社担当者に聞いた'; jobtxt2 += '匿名｜最高25社から査定結果が届く。査定｜プロが鑑定するあなたの市場価値'; |
[ 61] 田口元の「ひとりで作るネットサービス」探訪 - ITmedia Biz.ID
[引用サイト] http://www.itmedia.co.jp/bizid/hitori_index.html
|
カップルでネットサービスを作った2人がいる。ネット企業に勤め、開発のスキルも持つ者同士。普段からシステムの話で盛り上がる2人が、力を合わせてサービス開発を始めた事の始まりは……。 「ひとりで作るネットサービス」第15回は、番外編として「カップルで作るネットサービス」をお送りします。人の噂がどういう風に変化していくかをシミュレートできるネットサービス「うわさメーカー」を作った小張亮さん（23）と斉藤のり子さん（24）に、カップルでサービスを作る際の勘所をお聞きしました。 「好きです……」。徹夜明けの小張さんの携帯にメールが届いたのが午前5時。ついさっきまで一緒に働いていた斉藤さんからだった。始まりは斉藤さんの一目惚れ。それ以来、斉藤さんは告白のタイミングを探っていた。 「徹夜明けだったし、判断力が鈍っているだろうから今しかない、と思って（笑）」。斉藤さんは笑いながら、そう告白に至った経緯を教えてくれた。数分後、斉藤さんの携帯に返信メールが届いた。「僕もです。付き合ってください」 2人ともネット企業に勤め、それぞれが開発のスキルを持っている。「最初は言語で告白しようと思ったのですけどね。『あなたの心にINSERT INTO！』とかでもよかったのですが、さすがにそれはふざけていると思われるかな、と思って素直に告白しました（笑）」「え、そうなの？ じゃ、俺は『1 row(s) affected.』って答えたのに（笑）」 小張さんは現在23歳。大学生のときからインターネット企業での仕事を通じてエンジニアとしてのキャリアを積んできた。モットーは「まずはやってみる」。アルバイトで入ったネット企業ではブログパーツ、チャットサービス、SNSなどの開発、運営を手がけてきた。 「学生だったので、やりたいことは全部言いました」と小張さん。チャットサーバを『3日で作ってみせます！』と宣言して開発を任せてもらったり、『営業がやりたいです！』と宣言して実際に案件を受注、プロジェクトマネージャを経験させてもらったりしたという。 ただし、学生の次はスタートアップ企業からキャリアを始める──と堅く決めていた。現在は社員3名のベンチャー企業に籍を置き、技術全般を担当している。 一方、斉藤さんがネットに興味を持ったのは携帯からだった。当時流行っていた「魔法のiランド」で自分のホームページ作りに熱中した。携帯からひたすらHTMLを打ちこむ中で、自分を表現する楽しみにはまった。 「ただ、ケータイの料金が月7万円を越えちゃって」。携帯のためにバイトをする日々が続いた。そして月7万円を払い続けて数カ月を過ぎたとき、「パソコンでやればいいんじゃない？」と友人からアドバイスを受けた。 今まで携帯しか使ってこなかった斉藤さんには大きなカルチャーショックだった。「画面が大きい！」「通信速い！」。ネットにハマるのに時間はかからなかった。HTMLの書籍を買い集め、ホームページ作りに没頭した。そして彼女は決心する。「よし、これで食べて行こう」 当時埼玉にいた斉藤さんはネット関係の職を探し、東京の企業に就職する。大学のサイトを作ったり、モバイルサイトを作ったり。PHPはそのときに覚えた。「プログラムができないと雇わない、と言われたので思わず『やります！』と宣言してしまって（笑）」 そしてブログが流行っていた2003年、ライブドアでブログを開設。ホームページを通じて知り合った2chのひろゆき氏と“うまい棒”で料理を作るなど、「とにかくふざけたことをやろう！」というブログだった。その企画がウケて、1カ月後にはランキング2位にまで登りつめた（当時の1位は倉木麻衣さんのブログ）。 人気が出てきたのに合わせてブログのタイトルも変更した。「ライブドアに就職したい」という直球のタイトルに変えた直後、ライブドアの人事から連絡が来た。「企画からやってみませんか？」。二つ返事でOKし、ライブドアに転職する。ライブドアでは掲示板コミュニティの企画、運営を担当した。 その後、斉藤さんは何度か転職を重ねるが、一貫して手がけてきたのはコミュニティ関連の仕事だ。「ユーザーとの交流が楽しくて。炎上もしますけどね」。コミュニティ運営では2つのことを心がけているという。1つはオープンなコメント欄などを作り、ユーザーがフィードバックをしやすい環境を作ること、そしてもう1つは自分もちゃんとそのサービスを使っていることを見せること。運営者も自分でアカウントを作り、それをユーザーに公開することが大事だという。 「ね、斉藤さんって彼氏いるの？」。会社でそう聞かれたのが始まりだった。普通に「ええ、いますよ」と答えただけだったが、数人を経るうちに「斉藤さんの彼って年上の青年実業家でお金持ちなんだって」という噂に変わっていた。その噂がぐるっと一回転して自分に戻ってきたとき「どれ1つとして合っていないことに驚きました（笑）」 後日、斉藤さんが小張さんにその話をしたとき、噂をシミュレートするサービスを作ってみたら面白いのでは──という話で盛り上がる。ちょうど連休中だった。カフェでその話をしていたのが土曜日の昼。その日の夕方には仕様を書き留め終わっていた。小張さんがプログラミングを、斉藤さんがJavascriptとHTML/CSSを担当。17時から始まった自宅開発合宿は翌日の朝6時に完了した。 最初はお互いに「2人で開発すると殺伐とした雰囲気になるのではないか……」と不安を抱いていたという。しかし、完全に作業を分けることで、相手の作業に対してイライラすることがなくなった。終わったあとは「意外とスムーズにいったね」という感想を持ったという。 小張さんはJava、Perlを得意にしていたが、今回の開発では彼女がメンテナンスしやすいようにPHPを1日で学習することにした。「echoって何だよ」「PEARってのがあるらしい」──。苦戦しながらも何とかサービスを作り上げた。「彼氏が私のためにPHPでやってくれたので、私はお返しに彼の好きな青色をデザインに入れることにしました」 斉藤さんは、開発を終えて自身のブログに「カップルでWebサービスを作るための9のポイント」をまとめた。「ネタだと思っている人も多いようですが、本人たちはいたって真剣です。是非参考にしてください」 「デートは基本的にインドア派です」と言い切る小張さんと斉藤さん。もちろんオンラインツールも2人の関係維持に大きく貢献している。 2人で共有しているのはcheck*padとGoogleカレンダー。どちらもcheck*padへ一発でメールできるショートカットを携帯のデスクトップに置いている。またcheck*padに入れるまでもないアイデアはメモ帳を携帯し、すかさずメモしている点も同じだ。小張さんはあまりモノを持ち歩きたくないので、パスケースに貼り付けたポスト・イットにメモするという。 NEC製の携帯が備える「デスクトップ」にcheck*padにメールができるショートカットを配置（左）。パスケースにポスト・イットを貼り付けてメモ代わりに（右） 街中を歩いているときもシステムの話で盛り上がる。タッチパネルを見かけたら「このUIって何とかなるんじゃない？」「Webでこういうことしないよねー」と、どちらからともなくコメントし合うという。 また2人で何かサービスを作る予定はあるのですか？ と最後に聞いた。「いえ、しばらくはこのサービスを育てたいと思います。2人の関係のように」。そう語る斉藤さんの横で笑う小張さん。「誰がうまいこと言えと（笑）」 グループウェア「サイボウズ」にAjax導入した新版、携帯連携も強化サイボウズは11月28日、中小規模向けWebグループウェア「サイボウズ Office」シリーズの最新版「サイボウズ Office 7」を発売した。Ajaxを使い、ユーザーインタフェースを改善したほか、携帯電話との連携機能も強化した。 gooランキング：仕事に行き詰まりを感じたら、まずは「ソニー」から学べ！ビジネススキルを高めるための方法の1つが、カリスマ経営者たちが書いたビジネス書に触れること。ビジネスパーソンに聞いた、一度は読んでみたいと思う本とは？ 文具王の「B-Hacks！」：黄色い紙は自分用筆者は色付きのコピー用紙を用途に分けて使っている。たとえば「黄色は自分用」と決めているのだ――。 ライフハック テンプレート：＃057 自分ポスターあなたはキチンと自己PRできていますか？ 自分を映画の主人公に例え、ストーリーを作ってみましょう。 以前は自分が伸びていた感じがあったのに、最近は伸びている感じがしない。意外なところにある自己成長を阻害するワナを解説する ビジネスでもプライベートでも多くの人がコミュニティに携わるHP。社員の自由な活動を支える企業文化と行動規範とは 情報処理技術者試験がITSS(ITスキル標準）と融合しようとしている。どこへ行く、情報処理技術者試験？ jobtxt1 += '30代で派遣・フリーの仕事はなくなるのか？43歳エンジニアと派遣会社担当者に聞いた'; jobtxt2 += '匿名｜最高25社から査定結果が届く。査定｜プロが鑑定するあなたの市場価値'; |
[ 62] 田口元の「ひとりで作るネットサービス」探訪：【番外編】カップルで作るネットサービス──うわさメーカー - ITmedia Biz.ID
[引用サイト] http://www.itmedia.co.jp/bizid/articles/0707/26/news002.html
|
XMLを用いて新しい言語を作る場合、好き勝手にタグを定義したり、構造を定義していたのでは何の役にも立たない言語になりかねない。言語を作るときには、一度きりで使い捨てになる言語ではなく、再利用のことをあらかじめ考えた設計が求められる。では、再利用性の高い言語とはどんなものだろうか。今回はそのことについて解説しよう。 よく使われるものを、パターン化し、規格化し、再利用するのは、どんな分野でも常識的に使われるテクニックである。 例えば、デジタル回路を設計する場合には、AND, OR, NOTといった基本的な演算機能を持った部品を組み合わせる。しかし、実現する機能が変われば回路は大幅に変化してしまい、設計図は引き直しとなる。例えば、外見が同じに見える電卓を開発する場合でも、機能が異なればまた回路をゼロから描き直すことになる。これでは無駄が多い。 そこで、機能を実現する作業手順をハードウェアから切り離す構造が考案された。このアイデアによって、まったく同じハードウェアであっても作業手順を入れ替えることによって、異なる機能が実現できることになる。これによって、ハードウェアは特定のモデルに限定されず、再利用可能な部品へと進化したといえる。そして、この再利用を実現するチップこそ、現在のパソコンで使用されているCPUの直接の祖先にあたる部品になる。そういう意味で、パソコンと再利用という概念は切っても切れないものがあるといえる。 ソフトウェアの分野でも、再利用は重要である。1980年代ぐらいまでは、COBOLプログラマは容易に機械的に自動生成できるようなパターン化されたコードを、毎度手で書いていた、という話もある。これは情報投資は聖域と考えられていた幸運な時代にのみ通用する話であろう。全体的な流れとしてソフトウェア開発の歴史を見れば、ソフトウェアの断片に再利用の価値があることを積極的に認めて、それをうまく活用する方法を模索する話題に事欠かない。 例えば、最も原始的な構造の1つである「サブルーチン」と呼ばれるものは、1つのプログラムで繰り返し利用される部分を抽出したものといえる。さらに、再利用可能な部品をライブラリとして整備したり、オブジェクト指向においては最初から再利用されることを前提としてクラスを設計することを原則とするほどである。 ところが、SGMLなどの構造化文書の世界では、再利用に関する認識は遅れていた。それはDTDの仕様を見れば一目瞭然である。DTDは設計時にすべての要素や属性が明らかになっていることが前提となっている。設計時にまだ決まっていない別の言語の要素や属性と併用することを、適切に表現する能力を持っていない。 しかし、電子商取引など、現実世界の幅広い分野で利用しようとすると、膨大な数の言語を作り出す必要が生じる。その際に、それぞれの言語をゼロからいちいち作るのでは非効率的すぎる。言語を別々に作る非効率は、言語仕様作成の手間だけでなく、もっと広範囲に影響する。複数の言語の中の共通部分を、再利用可能な断片として規定することができれば、それを処理するソフトウェアも再利用可能なプログラム部品として作成できることを意味する。つまり、全体として効率よくシステムを構築し、運用していくためには、再利用性を強く意識する必要がでてくる。従って、XMLの世界でも、「たまたま再利用が有益なときに再利用を意識して言語を作る」のではなく、「どんな言語であろうと、再利用を意識する」ということが求められているのだ。 XGRは、XML文書の中に、画像データを指し示す情報を埋め込む。ただし、HTMLのimg要素のように、直接画像データを指定するのではなく、もっと抽象的な名前を指定する。登録されている名前には、現在8万文字以上の文字を収録する今昔文字鏡の収録文字に対応するものがある。XGRを用いることで、ある特定の文字の形を、画像データとして直接指定することができるわけで、「ちょっと普通と違う私の名前の漢字」を明確に指定する、といった機能を実現できる。 ここでのアイデアのポイントは、文字を文字コードで示すのではなく、画像データとして参照することにある。つまり、XGRは「文字」を扱う言語ではなく、「画像データ」を扱う言語なのである。これにより、（文字コードで文字を指定するときに発生する）フォントデザインの違いによって微妙に違う別の文字を、画面やプリンタから出力してしまう危険から解放される。ただ単にHTMLのimg要素のような画像ファイルを直接指定してしまう方法だと、別ファイルを示しただけなので、表示したい文字と同じ画像を示しているのかどうか判断が付かなくなってしまう。そこで画像データに名前を付けて、それを使って参照するというのが、XGRならではの特徴だ。 さて、前置きはこのぐらいにして、XGRがどのように再利用を意識した言語であるかを見てみよう。 まず最初にこのXGRは、単体でXML文書を記述できないことを指摘したい。つまり、通常の文書を記述するために必要な要素や属性を、すべて何も規定していない。段落を示す要素すらない。ある意味で驚くべき大胆さといえるが、最初から再利用を前提とした言語なら当然の選択といえる。段落などを記述する能力を持った言語はすでに世の中に多数あるわけで、すでにあるものはそれを再利用するのが、再利用的な態度である。 XGRに存在するのは、わずかに、たった1個の要素と、それに付随するたった1個の属性である。具体的なDTDの定義は以下のようになっている。 ただし、この定義を読む場合は注意しなければならない。それは、gaiji要素がどのような親要素の下にくるか、gaiji要素の子要素に何がくるかは、XGR側ではまったく関知していないということだ。これは併用する言語のつごう次第で何がくるか分からないということだ。 この言語が具体的なXML文書の中でどのように使われるかピンとこない人もいると思うので、上記仕様書からXHTMLとXGRを併用したサンプルを以下に示そう。 この例では、XHTMLのp要素の子要素として、XGRのgaiji要素が記述されている。そして、gaiji要素の子としては、XHTMLの通常のテキストで内容に関する説明が記述されている。XGRでは画像データにアクセスできない場合には、gaiji要素の子を代用として使用すると規定している。しかし、それが文字列であるべきだとは一切規定していない。これが最初のポイントになるので、詳しく説明しよう。 HTMLのimg要素では、画像データを扱えない場合に表示する代替文字列を、alt属性で指定する仕様になっている。これと同じような感覚で考えると、gaiji要素にalt属性を設けて、ここに代替文字列を記述することが適切であるかのように思える。しかし、HTMLとXGRでは、前提が決定的に食い違っている点がある。HTMLでは、扱うデータは基本的に文字列と、GIFやJPEGのようなビットマップと決まっている。もちろん、それ以外のデータも扱えないわけではないが、標準的ではない。そのため、HTMLで画像データが扱えない場合は、文字列で処理するしかない、という結論に至る。しかし、XGRの場合は、どんな言語と併用して使われるか分からない。もしかしたら文字列という概念のないグラフィック言語かもしれない。そのことを考えると、XGRでは、代替文字列は文字列だと決めつけることはできない。そもそも、文字列でないなら代替文字列とはいえないのである。そこで、この情報をこれ以後は「代替表示情報」と呼ぼう。 さて、代替表示情報が画像データである、という状況は具体的にどういうことだろうか。例えば、ベクターグラフィック言語のSVGの中に、XGRを埋め込んで使うことも考えられる。この場合、代替表示情報はSVGで描かれた文字の形であって悪いことは何もない。SVGの曲線データはXMLフラグメントになるが、属性には文字列しか記述することができない。そのため、属性に代替表示情報を記述するという作戦は、この場合にうまく機能しない。属性ではなく、要素の子として記述するようにすれば、文字列だけでなくXMLフラグメントも持たせることができる。 別の角度から考えてみると、文字列を代替表示情報として使う場合でも、詳しい情報を記述したサイトへのリンクを埋め込みたい、といったケースが考えられる。当然のことながら、文字列しか持てない属性ではこのニーズに対応できない。 これらの話から分かるとおり、HTMLのimg要素のようなalt属性を持たせることでは、XGRが想定するニーズには対処できないのである。このように、どんな言語と組み合わされても機能するように考えることが、再利用性の第1のポイントである。 XGRについての説明をさらに進めよう。ここでは、あるRDBのデータを入出力するために以下のような言語があると仮定する。 ルート要素がrecordという名前で、子要素に、fieldという要素を任意の個数持つことができる。fieldの子として文字列を持つことができ、これがデータを示す。field要素にはname属性があり、これがフィールド名を示す。この言語で記述された1個のXML文書が、RDB上のテーブルの1つのレコードの情報を持つとする。 さて、ここで何やら人名の漢字にうるさい人の分も、データを書かねばならなくなったとする。パソコンに入っているフォントで処理すると、「漢字の形が違う！」と怒り出すので、何とか対処したいと考えたとする。 ここで1つのアイデアは、このレコード記述言語と、前述のXGRを合体させて運用することである。XGRの情報を処理するために、多少システムを拡張する必要は生じるが、XGRで示す画像データにはユニークな名前が付くので、検索も可能になる。これならいけるということで、その人のデータを表す、以下のようなXML文書を書いてみたとしよう。 ここまではうまくいくのだが、この次の手順で問題が起きてしまう。このXML文書をRDBに格納しようとしたとき、RDBのフィールドに文字列は入るが、XMLフラグメントは入らない。つまり、gaiji要素や、それに付随するname属性を、そのままRDBに格納することができない。 この問題をどう考えるかは微妙なところである。今ある道具だけを前提にすれば、このような言語の組み合わせはNGということになる。言語の再利用を行うと、要素の階層構造は必然的に深くなるからだ。この場合、RDBと言語の再利用のどちらがより重要か、が選択のポイントである。現時点では、性能面でRDBの使用は外せないというケースも多いと思われるが、言語の再利用に関する強いニーズも厳然と存在する。このジレンマを解決するには、RDBを高性能XMLデータベース置き換えていくしかないだろう。RDBに匹敵するXMLデータベースはまだ存在しないと思われるが、ニーズがある以上、RDBを置き換えられるだけのパワーを持ったXMLデータベースの出現はそう遠い未来のことではないだろう。 データベース論はさておき、実際に言語を作るという観点から見た場合、再利用の制限と可能性に関する考察が必要だといえる。つまり、上記の言語をあくまでRDBへの格納用ととらえるならば、field要素の子に文字列以外の要素を持ってくるような形での言語拡張は不可であると明確にする必要がある。逆に、言語拡張の可能性が必然的なニーズであるならば、RDBへの格納は不可能であり、XMLデータベースの利用が必要であるという提言を発するきっかけとなる。 さて、データを表すこのRDB言語には、もう1点、再利用性という意味で検討を要することがある。ここではフィールド名を示すために、name属性が使用されている。このname属性に対して、何らかの再利用可能な言語を用いた拡張をしたいと思う人が出てきたら、何が起こるだろうか。例えば、フィールド名に難しい漢字がいくつかあるからルビを振りたい、といった拡張が考えられる。 しかし、属性にはそれ以上子を持たせることができないため、拡張は不可能ということになる。 ここでさらに考える必要がある。属性の名前とは、単に機械的にフィールドを区別するために付けられた便宜上の名前にすぎないのか。それとも、それは人間にとって読む意義のある文字列なのか。もし、後者であれば、人間に対する表現力を高めるという意味で、さらなる拡張が試みられる可能性がある。しかし、ソフトウェアの内部で使う識別名にすぎないと考えるなら、そのソフトウェアは名前に関するルールを決めているはずである。そのルールから逸脱する名前を付けることは、ただ単に利用不能のデータを作り出してしまうだけのことである。ならば、再利用可能な言語を付け加えて拡張することなど考える必要はないし、もっと突っ込んでいえば、拡張を許す構造にしないことがトラブルを未然に防ぐ手段とさえいえる。 もし、再利用可能な言語が付け加えられて利用されることがあり得るとするならば、属性として記述することは適切ではない。これは要素に変更すべきものだといえる。しかし、何かを付け加えてはならない性格のものであるならば、属性として文字列以外を書けないようにしておくことも、1つの選択である。 どちらを選択するにせよ、決断するには、再利用性ということを十分に意識しなければならない。 XMLで言語を作るときによく出てくるのが、段落や文字の強調といった表現のための機能だ。再利用を前提とした言語設計を行うのであれば、この手のよく出てくる機能は、メジャーな言語から借りてくるとよい。特に、XHTMLに既にある機能は、XHTMLを再利用可能な部品と見なして丸ごと利用してしまうとよい。 そのような設計にしておくと、現実のご利益がある。例えば、XSLTスクリプトを用いて、あるオリジナルな言語から（X）HTMLへ変換する場合、XHTMLの要素はそもそも変換が必要なくなる。変換せずに素通しするには、XSLTではxsl:copy-of要素を用いることで簡単に実現できる。あとは、独自機能だけを（X）HTMLに変換するスクリプトに書けばよいわけで、楽ができる。 これは、決して「（X）HTMLと同じ仕様の要素や属性を定義しておけばよい」ということにならない。あくまで、XHTMLの要素をそのまま持ってきて使う点が重要だ。 このサンプルでは、p要素はXHTMLのp要素と同じものとして処理したいという意図は同じなのだが、p要素に作る名前空間名が異なっている。上の例ではhttp://www.w3.org/1999/xhtmlという名前空間に属するが、下ではhttp://myLanguageという独自言語の名前空間に属している。現在は、HTMLに対応しているWebブラウザにXHTMLをHTMLであるかのように認識させているので、名前空間とは関係なく、結果が表示されるかもしれない。しかし、本格的にXHTML対応してくる次世代のWebブラウザでは、名前空間をきちんと認識するようになるだろう。つまり、名前空間がhttp://www.w3.org/1999/xhtmlに属さない要素は、いくら名前が同じであってもXHTMLの要素と見なしてくれず、エラーになる可能性がある。 前節の例では、XHTMLのp要素が、myLanguage要素の子要素として出現している。当然、XHTMLの規定の中には、p要素がmyLanguage要素の子要素となって良いという規定は存在しない。しかし、再利用という考え方を前提にするなら、作成した要素や属性が、どのような使われ方をするか、あらかじめすべてを予見することはできない。そのことから、複数の言語を混用する場合には、その都合に応じて、ルールを変形させながら利用することも多いと思われる。 しかし、何でもかんでも自由にしてよい、という考え方を取ると山のようなトラブルを抱えることになる。言語と言語を組み合わせる場合には、よく使われる型があり、これに沿って言語を作ったり、使うようにするとよいだろう。 文書系で典型的な型は、要素を、ブロック要素とインライン要素に分類する考え方である。ブロック要素とは、段落など、ページの中で1つのかたまりを構成する要素のことをいう。つまり、最もシンプルなページは、上から下に向かって、ブロックが並んでいる構造を持っているといえる。これに対して、インライン要素は行の中の一部を構成する要素である。文字列の中に挿入される画像や、文字そのものを修飾する強調などの機能がこれに該当する。 再利用を意識して言語を設計する場合は、それぞれの要素がブロック要素かインライン要素かを考えながら作成し、言語を混用するときは、ブロック要素はブロック要素として、インライン要素はインライン要素として使うようにすると、きれいで分かりやすい秩序を導入できる。余談だが、XGRは文書と併用する場合、インライン要素に相当すると考えられる。 文書系以外では、例えばRDB用のデータなら、レコードとフィールド、といった基本分類を設けて整理することができるだろう。 長期的な視野で見ると、名前空間に対応するスキーマ言語は、言語間の関係性も、整理して規定する能力を持つことになる。これらの言語が一般的に使用されるようになれば、まだ別の指針を語ることもできるだろう。 今回は、かなり抽象的で高度な話題になってしまい、読むのに苦労した読者も多いことだと思う。だが、今回の内容は苦労に値するだけの価値がある。つまり、再利用可能な言語というものを使いこなせば、XMLの活用に関する手間と労力が軽減でき、より大きなパワーを発揮させることができるようになるのである。 ここで「より少ない手間で目的を達成しようとは、手抜きか横着か？」と思わないでいただきたい。これはインターネットの持つ、コミュニケーションという性質と密接に関係することである。相互理解を成立させるためには、相互に同じ言語を理解可能でなければならない。しかし、インターネット上のすべての利用者、すべてのコンピュータがあらゆる言語を理解すると期待するのは現実離れしている。少しでもコミュニケーションの可能性を高めるためには、言語の種類は少ない方がよい。しかし、世の中のXMLに対するニーズは多様であり、そう簡単に言語の種類を減らすことはできない。ならば、言語の含まれるボキャブラリを可能なかぎり統一しておき、全体は理解できなくても、一部なら理解できるというレベルは最低でも維持しなければならない。 これは、インターネットが宝の山になるか、ゴミの山になるかというギリギリの選択なのである。仕事熱心だからといって、新しい言語、新しいボキャブラリを生み出し続けることは勧められない。他人から理解されない言語、ボキャブラリはゴミと等価と見なされてしまう可能性が存在するのだ。 さて、次回は趣向を変えて、XML宣言に出てくるstandaloneということは何かを考えてみよう。 QAフレームワーク：仕様ガイドラインが勧告に昇格 （2005/10/21） データベースの急速なXML対応に後押しされてか、9月に入って「XQuery」や「XPath」に関係したドラフトが一気に11本も更新された 文字符号化方式にまつわるジレンマ （2005/9/13） 文字符号化方式（UTF-8、シフトJISなど）を自動検出するには、ニワトリと卵の関係にあるジレンマを解消する仕組みが必要となる XMLキー管理仕様（XKMS 2.0）が勧告に昇格 （2005/8/16） セキュリティ関連のXML仕様に進展あり。また、日本発の新しいXMLソフトウェアアーキテクチャ「xfy technology」の詳細も紹介する 技術者としての力量を数値で把握していますか？ITSSレベルを無料で判定、12月25日（火）まで ホワイトペーパー利用者に「Amazonギフト券」を抽選で100名様にプレゼント！――TechTargetジャパン リニューアル・キャンペーン ＠ITトップ｜XML & SOAフォーラム トップ｜会議室｜利用規約｜プライバシーポリシー｜サイトマップ |
[ 63] 再利用できる言語をXMLで作る
[引用サイト] http://www.atmarkit.co.jp/fxml/rensai/xmlwomanabou08/learning-xml08.html
|
慶應義塾大学先端生命科学研究所（山形県鶴岡市、冨田勝所長）では、最先端のバイオテクノロジーを活用した環境技術の研究が進められている。研究の1つは、藻からオイルを作り、バイオ燃料にしようというもの。オイルを作る藻とは何なのか？ そして、藻の生み出すオイルはどのようなインパクトを社会にもたらすのか？ プロジェクトを立ち上げた伊藤卓朗研究員に、実験の詳細と将来のビジョンを語っていただいた。 ──オイルを作る微生物を使って、石油代替燃料を生み出すシステムを作ろうとされているとお聞きしました。そんな微生物がいたんですね。 この微生物は、軽油産生微細藻、シュードコリシスチス・エリプソイディア（Pseudochoricystis ellipsoidea）（仮名）という新属、新種の緑色単細胞植物です。海洋バイオテクノロジー研究所の藏野憲秀博士らが温泉地から発見しました。 軽油産生微細藻は、名前の通り、軽油成分を細胞内に蓄える性質を持っています。この軽油を生み出すメカニズムを明らかにし、培養条件を整えてやれば、石油代替燃料を生み出せるのではないか。そして、メカニズムを明らかにするため、この先端生命科学研究所のメタボローム解析技術を活用できるのではないか、そう考えました。 大腸菌の細胞内で起こっている代謝を図にしたもの（図はRoche Applied Scienceによる。クリックでデジタル版の公開サイトにジャンプ）。現在のバイオ分野では、実験やシミュレーションを繰り返して、こうした細胞のメカニズムを明らかにしていく メタボローム解析技術を説明する前に、現在のバイオ分野で行われている研究手法について簡単にお話ししましょう。 現在のバイオ研究では、細胞内の代謝経路を明らかにしようという試みが盛んです。このためには、細胞内の代謝物質を網羅的に測定し、大量のデータを得ることが必要になります。そして、得られたデータを解釈するためには、コンピュータによる解析が欠かせません。取り組みの1つとして、コンピュータ上で細胞のメカニズムをシミュレーションして仮説を立て、それを実験にフィードバックして再度検証するといった手法も行われています。こうやってシミュレーションと実験を繰り返して、細胞内部がどのようなメカニズムになっているのか、遺伝子がどのような役割を果たしているのかを明らかにしていくのです。 そこで活躍するのが、先端生命科学研究所のメタボローム解析技術です。キャピラリー電気泳動-質量分析計（CE-MS）という装置に、細胞から取り出した代謝物質を入れて、高い電圧をかけます。物理化学的な性質の違いによって、各物質は動く速度が異なります。どのような質量の物質がどれくらいの速度で移動するかを調べることにより、サンプル中に含まれる物質の構成がわかるわけです。従来の手法では、一度にせいぜい数十程度の物質しか分析できませんでしたが、メタボローム解析技術によって数百、数千という物質の分析が可能になりました。細胞の代謝経路の解析を飛躍的に効率化できたのです。 私の研究では脂質の分析も必要になるため、新しい手法を開発し、100種類程度の脂質代謝物質を一度に分析できるようになりました。 複雑な代謝のメカニズムを視覚化する研究も進んでいる。図は、先端生命科学研究所で開発されたE-Cell 3D。代謝の時間的変化や物質の質量変化などを、3DCGアニメーションによって表現する 研究室内の水槽で、さまざまに培養条件を変化させるとどのように藻の生長や代謝が変化するかを実験しているところです。藻の細胞や培地から代謝物質を採取して、メタボローム解析をしています。オイルを作っている状態、作っていない状態を比較することで、オイルを生み出す仕組みが明らかになると考えています。 軽油産生微細藻は、光とCO2それに窒素栄養を取り込んで光合成を行います。窒素栄養を与えるのをやめると、藻はオイルをたくさん作り始めるんですよ。 私も不思議に思いました。人間なら、栄養が豊富な時にため込み、栄養がなくなったら脂肪を代謝させて活動しますからね。 ところで、菜種油、大豆油など、植物の種子にはたくさんの油が含まれています。なぜかといえば、油はエネルギーに変換しやすいからのようです。植物が発芽する時、すぐにエネルギーを取り出して、生長することができます。 そこからの推測ですが、この軽油産生微細藻は、栄養がなくなって生存が脅かされると防衛反応としてオイルをため込み、休眠のような状態になるのではないでしょうか。そして、環境が改善されたら、ためたエネルギーを使うという戦略なのかもしれません。休眠から目覚めるといった急激な変化が起こる際には、大量のエネルギーを消費しますから。 そうです。それでは、光合成をしている時とオイルを作っている時で何が違うかというと、増殖にエネルギーを使うかどうかなんですね。光合成をしている時は、増殖にエネルギーを使い、とにかく増えまくります。一方、オイルを作る時は、増殖を抑え、自分自身だけを守ることに専念するようです。 ただし、これもあくまで仮説であって、今のところ証拠はありません。生物の行動を理由付けするには、状況証拠から固めていくしかありません。そして、科学的にわかったことから推測して、人間として理解できる物語を作るのです。 そもそも生命活動には無駄な部分が多いですよ。代謝活動についても、AからZまで一直線に流れるシンプルなものだと、1ヶ所反応がうまく行かないだけで成り立たなくなってしまいます。常に冗長性を確保し、回り道、無駄を作り、いざという時にはそれらを使う。そうでないと生物は生き残れません。この一例については、私たちの研究所が世界で始めて科学的に証明しました。 先端生命科学研究所が開発し、特許を取得しているキャピラリー電気泳動-質量分析計（CE-MS）。こうした特許を事業化するため、同研究所からはヒューマン・メタボローム・テクノロジーズ株式会社というベンチャー企業がスピンオフしている オイルを作るためのメカニズムが解明できれば、さまざまな応用ができると思います。例えば、窒素栄養以外の変化でもオイルを作るかもしれません。遺伝子組み替えによって、オイルの量を増やせる可能性もあるでしょう。また、遺伝子組み換えを行わなくても、突然変異を利用するという手がありますね。メカニズムがわかれば、できることが一気に広がるのです。 1970年生まれ。雑誌編集者を経て、フリーの編集者・ライターとして独 立。ネットカルチャー、IT系解説記事などで活動中。著書に 『ウェブログのアイデア！』（企画・共著）、『進化するケータイの科学』などがある。ブログは、こちら。 ロボットバイオニクス軍事・対テロWiredが見た日本宇宙・航空自動車ゲーム・仮想世界ガジェットMac & Appleデジタル音楽 |
[ 64] オイルを作る藻が、日本を救う？ 1/2 | WIRED VISION
[引用サイト] http://wiredvision.jp/blog/yamaji/200711/200711160954.html
