Google、大規模日本語データの公開を検討

ここのスラッシュドットニュース
Google、大規模日本語データの公開を検討
http://slashdot.jp/it/07/03/16/0315207.shtml

およびGoogleのページ
大規模日本語データ公開に関する特別セッション
http://www.google.co.jp/events/anlp2007.html

によると(以下斜体は上記Googleのページより引用）

グーグル株式会社では、日本語の言語処理研究推進のため大規模日本語データの公開を検討しています。つきましては仕様を決定するにあたり、実際にデータを御利用頂く研究者 / 技術者の皆様の「生の声」を是非お伺いしたく存じます。今回、言語処理学会様の御好意により、下記のとおりデータ仕様に関する特別セッションを設けて頂ける事になりました。

講演終了後お疲れのところとは存じますが、是非ディスカッションに参加頂き、忌憚の無い御意見をお聞かせ願いたいと存じ上げます。



日時: 2007年3月20日（火） 18:30 ～ 19:00
会場: 龍谷大学 瀬田学舎 言語処理学会全国大会 A会場 3-106


おおー、何を公開するんだろう。。。
ブログとかのコーパス？
共起？

やっぱ、公開はテキストデータとかではなく、ＷｅｂＡＰＩにしていただいて、Ｇｏｏｇｌｅアカウントがあれば、だれでも呼び出して使えるようにしていただきたいよねえ。。

でも、それにしても何を公開するんだろう。。。

まさか。。。

セマンテックＷｅｂでの検索をやりたいんでえ、機械的にＲＤＦはつくっておいたからあ、これを公開するのでえ、日本の皆さんは、これを呼び出してテキトーに直してくださーい！！

　そーしていい感じにできたらあ、グーグルでセマンテックＷｅｂ検索やりますんでえ。。

　・・・とか、まさか、そんなオチじゃないでしょうねえ（－＿－）
　疑ってしまうウィリアムのいたずらなのでした。。

　うーん、２０日に、いったい何を公開するといっているのか、
　ＩＴメディアやＩｍｐｒｅｓｓＷａｔｃｈやＭｙｃｏｍで、取り上げてくれるのかなあ？？ぜひ、取り上げていただきたいものだ。。

開発の初めから順番に書いていってみる その１０：立ち上げ（４）アクティビティ

　シリーズ「開発の初めから順番に書いていってみる」の続きです。
　今、プロジェクトの立ち上げから話を起こしているのですが、プロジェクト憲章、をつくって、スコープ定義をしてWBSを作るところまできました。

　以前、順番を書いたところで言うと、「計画のコアプロセス」の（２）まできたので、今回は（３）である


（３）アクティビティ定義（タイム）
　　　「何を」しなきゃいけないかに対して、それを「どのように」行うかに
　　　ついてきめる


っていうのをやります。

---

■アクティビティ定義、WBSをどのように分解したかでちと違う

　　アクティビティでは、具体的に、どうやってするのかって言う話を書くことになるのですが、これ、WBSを、どのような要素で分解したか（要素分解）によって、ちょっと話が違ってきます。

　まず、WBSを、構成要素で分解した場合、つまり、一番下の部分が
　　　「受注票作成」
　　　「受注入力」
　　　「キャンセル」
　のように、本当に、そのシステムが、「何」からできているかで分けた場合には、アクティビティで、具体的な作業内容が定義できます。
　画面の要望を聞く、画面設計、画面のイベント設計、サーバー側プログラム設計などなど。。

　なんで、この場合は、やる内容を定義していけばいいです。

　問題は、そうではなく、WBSのときに、作業で分解しちゃった場合です。

　　「要求仕様をきめる」には、
　　　・ヒアリング前の準備をする
　　　・ヒアリングする
　　　・ヒアリング内容をまとめる
　　　・アクティビティ図を作成する
　　　・ユースケース図を作成する
　　　・ユースケースシナリオを作成する
　　　・ER図を作成する
　　　・制約条件をまとめ、非機能要件とする
　　　・要求仕様書を作成する
　って、ここまで分けてしまうと、アクティビティでさらに細かく。。は分けられない（＾＾；）
　分けてしまうと、後のスケジュールで、「何時間」とかいうのが出てきてしまう。。
　っていうことで、WBSをどこまで、アクティビティをどこまで細かく分けるか？っていう問題になります。

---

■で、WBSもアクティビティも、開発標準に左右される

　じゃあ、具体的に、アクティビティの内容として何を書くか？っていうことになりますが、それは、開発標準に左右されます。
　開発標準を決めてしまうと、「このときには、これをやりなさい」ときまっているので、アクティビティに何をやるかがきまります。

　ってことはですねえ、実は、WBSで、構成要素（「受注票作成」、「受注入力」、「キャンセル」等）で定義しておいてくれると、あとは、どのフレームワークを使うかを決めれば、フレームワークでやることは、きまっているので、

	ヒアリング	アクティビティ作成	ユースケース作成	画面
受注表作成
受注入力
キャンセル

のように、表形式（横にやること、たてに構成要素）にして、それぞれのセルでやることがあるかないか、判断すればできます。

　しかし、WBSを構成要素で定義できない場合は、フレームワークどおりに、とりあえず、アクティビティを定義するということになります。

---

■フレームワークの問題
　しかし、この方法の場合、使うフレームワークが間違えている場合、また、フレームワークというのは完璧でない場合が多いから、実際には何か他の作業でフォローしないといけないのに、それを抜いてしまった場合などなどで、問題をおこしてしまいがちです。

　とくに、要素に分けるとき、構成要素か作業要素にわけるのですが、このほかに、開発で使う、技術的な要素技術にわけ、その実現性と手順を確認しておかないと、後工程で、「う、これってできないじゃん（＞＿＜！）っていうことになります。

　この要素技術にわけ、その要素技術の確認っていう作業（たいてい、プロト作成の中でやる）を抜かっしゃうと、後で大変なことになったりします。

---

　っていうわけで、ここで、作業項目内容が具体化しますので、
　ここで、要件定義でなにをやるのかも、具体化されたということにします。
　（具体的に何をやるのかは、要件定義の話のときに書きます）
　
　で、次回は、そのあとのお話に行きたいと思います。

YouTubeから削除されたムービーを視聴できるサイトだって。。。。

　ここのGIGAZINEの記事
YouTubeから削除されたムービーを視聴できる「Delutube」
http://gigazine.net/index.php?/news/comments/20070316_delutube/
によると（以下斜体は上記記事より引用）


諸事情で削除されたYouTubeのムービーを視聴できるという、とんでもないサービスだそうです。どうやら100％完全に視聴できるというわけではないようですが、消えてしまったムービーを見られるというのはすごいかもしれません。

先日YouTubeとGoogleが10億ドルの損害賠償で訴えられたということをGIGAZINEでも取り上げましたが、大丈夫なのでしょうか…。


たしかに、YouTube用魚拓みたいなサービスが
”理論的には！！”
あってもおかしくないわけではあるが。。

。。。だいじょうぶなのか、このサイト（＾＾；）

ちなみに、そのサイト、「Delutube」は、以下のところ
Delutube - The Deleted YouTube Video Viewer
http://youtube.infamousx.com/index.php
にあります。

「BREWフレームワークを開発」－東芝ソリューション

　BREWのテンプレートや開発部品などを提供したフレームワークが、東芝ソリューションから出たみたいです（って、ごめん、２日前にもうニュースに出てたのね　＾＾；取り上げるのが遅くなったけど）

ここのニュース
東芝ソリューション、携帯アプリ開発でBREWフレームワークを開発
http://japan.cnet.com/news/ent/story/0,2000056022,20345211,00.htm?ref=rss

及びここのプレスリリース
東芝ソリューション、携帯アプリケーション開発の生産性を向上させる
BREWフレームワークを開発
http://www.toshiba-sol.co.jp/news/detail/070314.htm
によると（以下斜体は上記プレスリリースより引用）

　東芝ソリューションが、BREWにおけるプラットフォームを開発したそうで


これまで同種の製品には、用途を絞ったり、ライブラリや関数を提供するものはありましたが、開発方法論とテンプレート、開発ツール、モバイル対応共通部品を構成要素(*2)とするフレームワークは業界初(*3)となります。

　だそうです。

　このブログは。。！！って、

　「あんたBREW業界の人じゃなくって、ぷう太郎でしょう」って。
　　そーでした（＾＾；）（いちおう、仕事は、してるのよ。。。＾＾；）

　で、冗談はさておき、提供する内容だけど。。


各構成要素にて提供するものは以下のとおりです。

◆ 開発方法論
・BREWアプリケーション開発ガイド
・開発環境構築ガイド


◆ 開発ツール
・PC上でデバッグ可能な携帯電話シミュレータ　など


◆ テンプレート
・イベント処理や画面遷移管理機能などアプリガイドラインに準拠すべき内容は定型フォーム（テンプレート）としてあらかじめ記述し提供
　→開発者はカスタマイズ画面や個々の業務ロジックの開発に注力可能



◆ モバイル対応共通部品
・携帯電話のネイティブ機能をわかりやすくまとめ、ライブラリとして提供
　→　膨大なBREWR APIを理解していなくても開発することが可能
・モバイル対応共通部品をまとめて業務に必要な機能をミドルウェアとして提供
　→　サーバ連携、セキュリティ連携、GPS連携、Bluetooth連携 など　

（文字化けの危険があるので、BREWとBluetoothの後の、”まるR”をとってます）

　たしかに、これによって、テンプレートができて、開発が標準化され、しやすくなるかもお。。

---

　ここで、これの効果を考えるには、BREW市場を２つに分けて考えないといけないだろう。
　２つとは、コンシューマー市場とビジネス（法人向け）市場だ。

　コンシューマー市場は、ゲームなど、利用者が特定されない市場のことで、この場合、ケータイを限定することは不可能なので、すべての端末に対応することが求められる。

　一方ビジネス市場は、業務アプリにBREWを利用するケースで、この場合、お客さんが決まっているので（それをA株式会社さんとしましょうか）、そのお客さんが、この端末と選んでしまえば、その端末に対応すれば良いだけの市場だ（A社さんが、わが社の次期システム、ケータイはW51Tで実現する！と宣言したらW51Tだけで動けばいい。のちのち、新機種に変えたとしても、T（東芝）なら、次もT（東芝、つまりW●●T）として、一向に問題ないという市場だ。

---

　前者のコンシューマー市場においては、テンプレートが出ても、全機種にそれが対応できるかどうか分からない。その点で、テンプレートのメリットが、はっきりあるとは言い切れない（もちろん、共通ライブラリは出ているが、それが全機種で「まともに」動くかは？？）

　もちろん、標準をきめることで、それから何がずれているという表現ができるので、テンプレートができることに意味は大きくあるが。。（しかし、機種によって大きくテンプレートをいじらないといけないなら、”その”テンプレートで生産性があがるとはいえない）

　しかし、後者のビジネス市場になってくると、話は大きく違ってくる。

　これは、１端末で動けばOKなわけだ。逆に、このテンプレートで動く端末の機種をみんな選ぶようになる。そーなってくると、テンプレートの効果は絶大だ。

　テンプレートに基づいて開発すればいいので、開発で必要な知識が下がり。。というか、業務系のSE,プログラマが参入できるようになる。そうなれば、SE単価は激減するだろう。

　また、SEの供給も増えるので、ケータイを業務に使う開発案件も、ふえてきそうだ。。

　さらにさらに、テンプレートで動く機種は売れるけど、動かない機種は売れないということになってくる。。

---

　っていうことは、東芝は、絶対的な優位に立てることになるのだが、この話は長くなりそうなので、また今度。。