東工大の奥村研が「株式会社ブログウォッチャー」をリクルートと設立

ここのニュース
リクルート、東工大奥村研究室と「株式会社ブログウォッチャー」設立
http://bb.watch.impress.co.jp/cda/news/17711.html
によると（以下斜体は上記サイトより引用）

リクルートは、ブログなどを利用した日常メディアとマーケティングの開発・推進を目的とした「株式会社ブログウォッチャー」を設立すると発表した。

（中略）

設立日は4月2日、資本金は5,000万円で、株主構成はリクルートが99％、奥村学氏が1％。代表取締役にはリクルートの羽野仁彦氏が就任する。なお、ブログ検索「blogWatcher」の運営をブログウォッチャーに移管するかどうかについては現在のところ未定だという。

だそうな。。ほー。。

ちなみに、そのビジネスの内容なのですが。。

東京工業大学奥村学研究室のテキストマイニング技術とリクルートの編集ノウハウを用い、ユーザーの声で作られた雑誌感覚のサイト提供を目的としている。


ってことなんですけど、前の「ユーザーの声で作られた」って言う部分は、blogwatcherですよねえ。。
　で、そのあと、雑誌感覚って言うことは。。

　メタブログの内容を、Hotpepper風のレイアウト（１ブログを四角い箱にいれて、トップページのイメージを載せる）にするとか？？

　でも、そーいうやつより、関心のあるキーワードを登録しておくと、そこから適合率をだして、適合順に、Hotpepper風のレイアウトや雑誌のベストテン風のレイアウト（のXSLを作っておいて、適合順の結果をXMLで返すことによって）を出してくれるほうが、興味あるなあ。。

　っていうか、gooとか、Yahooとか、検索結果表示、そーいう、四角いマスで、トップページも表示してくれるようになってると、見やすいなあ。。って、処理速度が間に合わないか（＾＾；）
　でも、もちょっと表示方法を。。　

　。。。とか言ってると、そのうち、Gooあたりに
　じゃあ、RSSで返してあげるから、好きに加工すれば！
　といわれそうなので（それは、それでいいかもしれないけど。。）
　このへんで。。

開発の初めから順番に書いていってみる その２１：要求分析（７）要求仕様の問題点

　シリーズ「開発の初めから順番に書いていってみる」の続きです。
　前回まで、要求分析フェーズは終わりました。

　ここで、要求仕様の問題について書いてみたいと思います。

---

■要求仕様の問題

　要求仕様の問題は、
　　・要求仕様自体に漏れ（想定外）がないかどうかが、良く分からない
　　・要求仕様にできないことが書いてあるかもしれない
　　　　　　矛盾がある
　　　　　　到底できないことが書いてある
　　・発注者、受注者が同じ理解をしているとはいえない

　などです。では順に見ていきます。

---

■要求仕様自体に漏れ（想定外）がないかどうかが、良く分からない

　これは、仕様の検証（要求仕様の機能要件の品質評価）が、良くなされていないことから起こります。
　ここで、想定から外れてしまい、それ以降の工程で発覚すると、大きな手戻りになります。
　これを防ぐ方法として、形式仕様言語などはあることはあるのですが、それは、「おかしい」ことは指摘しても、じゃあ、何をどう直せばいいのかまでは教えてくれません。

　たとえば、「ゾウを冷蔵庫に入れる」という仕様があったとします。
　このままだったら、要求仕様として、仕様がとおってしまいます。
　でも、形式仕様言語に直したら、ゾウの型と、冷蔵庫の引数の型などから、チェックして、「おかしい」ってことは、気がつきます。でも、なにが、どうおかしいのかは分かりません。これは、１工程抜けていて、

　「ゾウを火葬する」→「そのゾウを冷蔵庫に入れる」（つまり、遺灰を冷蔵庫に入れる）かもしれません（ゾウの漢方薬を作るため、火葬して、その粉を冷蔵庫に入れる）。

　もしくは、冷蔵庫の定義が間違えていて、
　「ゾウを、石巻第三冷蔵庫（＝冷蔵倉庫のこと。魚なんかを入れる）」に入れる
　かもしれません。何が抜けているか、わかりません。

　問題は、ゾウの話ではなく、このように、工程が抜けていたり、言葉の意味が違っても、仕様として、通ってしまうことです。
　ゾウで間違えることはありませんが、集計表のブレークで、日ごとに集計するけど、毎日のデイリーデータは、来ないみたいなオチがたまにあります。

　これを、完全に防ぐ方法はないのですが、見つけやすくする方法としては、
　１．ある程度の雛形があってそれをカスタマイズする場合は、見つけやすい
　　　　→業務知識に基づいた雛形があるべき
　２．ユースケースシナリオがあり、それを実際に確認すると、気がつきやすい
　３．プロトタイプで気がつきやすい（画面が作成できなくなったりするから）
　なんかが、考えられます。

---

■要求仕様にできないことが書いてあるかもしれない

　これは、論理的に矛盾しているケース、さっきのゾウを冷蔵庫に入れるとかがそうです。
　ウィリアムのいたずらが、であったケースでは、今日、稼動可能な人を割り当てる。。ただし、今日、病欠でお休みした人は分からない（＞＿＜！）なんていうのがありました。ただ、それは、上記の想定外のケースと対処法は同じです。

　そうでなく、到底できないことが書いてあるケース、これは、何パターンかあり、
　　　・新規業務で、理論的には可能だが、生身の人間ではできない
　　　・技術的にできない指定がされている
　　　・その日数、工数、費用ではできない。
　とくに、「技術的にできない指定がされている」について、ここで触れます。

　これは、よくあるのは、利用するフレームワークでは、そういうGUI操作はできないとか、イベントがあがらないって言うような場合、あと、データベース操作で、おいおい、オンラインでバッチやるなよ！っていうオチなどなど。。

　これを防ぐには、システムを要素技術に分解し、それぞれを試してみて、制約を洗い出した上で、やばそうな部分を、プロトタイプを作成してチェックするっていうことでできます。

　しかし、システムを要素技術に分解し。。という操作は、要求仕様ではない（外部設計だ）というのが、論理的な立場です。ただ、実務的には、フレームワークは、要求仕様以前に、営業段階で大枠は決まっていて、外部設計の時にはもう確定しているということのほうが多いです。なので、これが、問題になります。外部設計のフレームワークのところや、プロトタイプのところで、詳しく述べます。

---

■発注者、受注者が同じ理解をしているとはいえない

　そもそも、発注者側は、DFDやER図は？？？ってこともあります。
　アクティビティ図がわかるか。。クラス図は？？？っていうケースがあります。
　この場合、図で書いたら、ぜーんぜんわかりません。さっぱり理解できません。

　これはひどい例（でも、実はなくて、結構ありがちなんだけど）ですけど、言葉の定義があいまいで、プログラムを作る段階になって、「ちょっとまって、この言葉、こういう意味だよね」って聞くと、違ってることがあります。
　というか、みんながみんな、同じ理解をすると言うほうが無理です。

　図がわからないという話もあるので、やはり、この対策は、
・ユースケースシナリオを作って確認する
・プロトタイプを作る
ということになると思います。

---

■対策のまとめ

　ということで、これらの絶対的な対策はないけど、
　問題を小さくする方法としては、結局まとめると

　１．ある程度の雛形があってそれをカスタマイズする場合は、見つけやすい
　　　　→業務知識に基づいた雛形があるべき
　２．ユースケースシナリオがあり、それを実際に確認すると、気がつきやすい
　３．プロトタイプで気がつきやすい


　ここで、２については、文字通りの話なので、まあ、言うことはないと思います。
　のこりの「雛形があってそれをカスタマイズ」っていう話と、「プロトタイプ」について、今後取り上げたいと思います。

---

　ということで、次回のこのシリーズは、プロトタイプを取り上げます。
　要求仕様と、外部設計のちょうどハザマになっちゃうような話なんですけど、プロトタイプの意義が変わってきた話などです。

ITガバナンスのフレームワークCOBIT4.0日本語訳のあるところ。

日経コンピューターの２００７年４月２日号２４ページに書いてあったので、
メモメモ

ITガバナンスのフレームワークであるCOBIT4.0の日本語訳を
日本ITガバナンス協会がだしているようです。

で、そのCOBIT4.0日本語訳のあるところ
ここ　http://www.itgi.jp/download.html
の和文資料　COBIT 4 日本語版（2007年3月）に行く（緑の鍵なので登録しないでも見れるみたい）

はじめ、英語が出てくるけど、「COBIT 4.0 日本語版 (Japanese)」って書いてある下に、見出しが書いてあるので、それをクリックするとPDFが出てくる。
ので、そのPDFを保存（フロッピーの形をしたアイコンをクリック）すればいい。

まだ、ダウンロードを始めたところで、中をみていないのであった。。