企業ブログが失敗する7つの理由。。。

こんな記事が。。
企業ブログが失敗する7つの理由
http://web-tan.forum.impressrd.jp/e/2007/04/02/1117

まあ、（以下斜体は上記サイトからの引用）

個人の声ではなく企業の声になってしまう

や、

「販売」や「広告」を意識してしまう

はそうだねー。
でも、広告したいから、ブログをやってるんだと思う。
多くの会社の場合。。

で、それはそうと。。

そもそもブログに向いていない企業、というケースがたくさんある。

ま、そーなんだよね。。
でも、それを言ってしまうと（＾＾；）

WebAPIでXMLで返すようにすると、画面部分が完全分離できる:その２クッキーを使わない値渡し

　前に書いたWebAPIでXMLで返すようにすると、画面部分が完全分離できる:その１－方法１（１６時修正）で、


　とはいえ、次の画面に変数をわたすには、どーするの？
　サーバーならセッションに入れるという手があるけど、
　クライアント側で変わった場合。。
　クッキーでもつかうの？

　って言う話は、このシリーズの次回に書きます。


　について。
　つまりAJAXでクライアント側で画面を切り替えるとなると、クライアント側で、画面間で共通に使う変数を渡さないといけない。その渡し方。

---

■たしかにクッキーを使う方法はあるけど。。

　たしかに、クッキーを使う方法はある。
　document.cookieに値をセットし、受け手は、document.cookieから、とってくる
（ただし、変数=値の形で取れてしまうので、分解しないといけない）

　詳しくは
とほほのCookie入門
http://www.tohoho-web.com/wwwcook.htm
にやりかたとかが載っている。

　でも、ここで引渡しするのは、１つのXMLドキュメントとかもありえる。
　それをクッキーにいれて、さらに受け手で解析する？？

　ちとめんどう

---

■トップ画面に変数を用意、各種画面は、トップ下のフレームで動く

　で、ちょっと技巧がかった話を１つ

　一番初めにアクセスする、index.htmが、以下のように

＜html＞
＜SCRIPT type="text/javascript" src="abc.js"＞＜/script＞
＜SCRIPT Language="JavaScript"＞
＜!--
var	val1	=	"2345";
// --＞
＜/SCRIPT＞
＜head＞
＜title＞テスト＜/title＞
＜/head＞

＜frameset＞
 ＜frame name="gamen" src="main.htm"＞
 ＜noframes＞
  ＜body＞

  ＜p＞このページにはフレームが使用されていますが、
  お使いのブラウザではサポートされていません。＜/p＞

  ＜/body＞
  ＜/noframes＞
＜/frameset＞
＜/html＞

（上記＜　＞　は、本当は半角）

変数宣言（val1）をして、フレームを作成する。フレーム面はgamenで
main.htmを表示している。
　で、実質、初めに表示される画面は、main.htmなのだが、ここで、
そのmain.htmで、

＜?xml version="1.0" encoding="utf-8"?＞
＜!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
 "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"＞

＜html xmlns="http://www.w3.org/1999/xhtml"＞
＜head＞
＜title＞キーワード表示・選択＜/title＞
＜SCRIPT Language="JavaScript"＞
＜!--
//*==============================================//
//*	関数：next()			   *//
//	内容：ボタンが押された		   *//
//*==============================================//
function next_win()
{
	top.val1 ="2345";
	window.open("test.htm","gamen");
}

// --＞
＜/SCRIPT＞
＜/head＞
＜body bgcolor="#FFFFCC"＞
＜input type=button id=bt1 onClick="next_win()" value="次へ"/＞
＜/body＞
＜/html＞

（上記＜　＞　は、本当は半角）

のように、ボタンが押されたら、next_win()にいくようにして、
next_winで、そのトップで取った変数、
top.val1 ="2345";
に値をセットするようにして、ここで、次の画面に行くとき、
_topではなく、index.htmで宣言した、実質的なトップのgamenへ行くように
表示する。そうすると、topは変わらないので、変数は保存され、test.htmで

＜?xml version="1.0" encoding="utf-8"?＞
＜!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
 "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"＞

＜html xmlns="http://www.w3.org/1999/xhtml"＞
＜head＞
＜title＞キーワード表示・選択＜/title＞
＜SCRIPT Language="JavaScript"＞
＜!--
//*==============================================//
//*	関数：next()			  *//
//	内容：ボタンが押された		  *//
//*==============================================//
function load()
{
	t = document.getElementById('tx1');
	t.value = top.val1;
}

// --＞
＜/SCRIPT＞
＜/head＞
＜body bgcolor="#FFFFCC" onLoad="load()"＞
＜input type=text id=tx1 value=""/＞
＜/body＞
＜/html＞

（上記＜　＞　は、本当は半角）

のように、読み込んだとき、loadにはいって、そこで、
top.val1を呼び出すと、前の画面で設定した値が来る

---

■このように

１．トップ画面の変数(top.変数名）に値を保存して
２．画面は、トップでなく、gamenとか名前を付けて、そこに出すようにすれば、
３．画面間で、１の変数が共用できる。

これは、初め宣言してなくても、top.変数名を直接呼んでもOKそうだ。。
ま、ちょっと変わったやり方かも（＾＾；）

開発の初めから順番に書いていってみる その１９：要求分析（５）内容をまとめる

　シリーズ「開発の初めから順番に書いていってみる」の続きです。
　現在、要求分析フェーズに入っています。
　その手順としては、

・ヒアリング前の準備をする
・ヒアリングする
・ヒアリング内容をまとめる
・要求仕様書にまとめる

　とあるわけですが、前回は、「ヒアリングする」だったので、
今回は「ヒアリング内容をまとめる」という話です。

---

■今まで書いた、ヒアリング内容のまとめ方について

といっても、前に、ヒアリング内容については、

・入力データと
・出力データと
・やることの内容

を、Excelシートにまとめると、DFDとER図あるいは
UMLの図、どちらにも展開できるよという話は、書きました。

なんで、以下に、その話を書いたところを示しておいて、

　ヒアリングをまとめる
　　　・業務をまとめたシート
　　　・入出力をまとめたシート

　これらをシートをまとめる手順については、こちら

　ＤＯＡの
　　　・ＤＦＤ
　　　・ＥＲ図

　オブジェクト指向の
　　　・アクティビティ図
　　　・ユースケース図
　　　・ユースケースシナリオ
　　　・クラス図（その前にフレームワークを決める話）
　　　　　　・その１
　　　　　　・その２
　　　　　　・その３

今日はもっと深く、結局なにをまとめればいいのか？ということに
ついて書きたいと思います。

---

■結局、なんについてまとめるのか？

UMLの図で書くにしても、DFDなどDOAの図で書くにしても、
結局、業務分析で必要なことは、

１．成果物として得たい出力はなにか？
２．そのために、どういう入力をして
３．それをどう処理するか？

っていうことです。つまり、入力をもとに、その処理をすれば、必要な（求める）出力がでるよ！という流れが書いてあればいいわけで（そのための、いつ行うっていうような制約条件も必要ですが）、そーなってくると、結局は

１．入力データから出力データは作れるか
２．そのデータ処理方法は？

って言うことが書いてあればいいことになります。
DOAの場合、これがDFDにまとまっていて、とくに、ER図で、データ部分を細かく規定しています。
一方UMLでは、２を中心に書くため（ユースケース図、アクティビティ図では）、１の部分を補足するため、クラス図をここに持ってくるか、ER図をここにもってこないといけません。しかし、ER図をもってきても、どのプロセスで、どれを入力とし、どれを出力とするか、はっきりするとは限りません。
　クラス図で、そこまではっきりさせると、それは、どう処理するかという外部設計レベルの話になってきてしまいます（＞＿＜！）

　とはいえ、問題があるかどうかは別として、書いていることは、
１．入力データから出力データは作れるか
２．そのデータ処理方法は？
この２点です。結局、これをまとめているだけです。

---

■富士通の開発標準の場合

　で、前に取り上げた富士通の開発標準だと、この関係を業務機能概要定義で書いています。システム化業務フローがアクティビティ図、概観業務フローがDFDに相当します（それを変形しています）。

　で、ユースケース一覧で、ユースケース図を表で表現しています。

　で、ER図は、概念ER図です。

　ということで、DOAとオブジェクト指向、全部の図を作ろうとしています。
　これは、手間隙かかる上、間違いが入りやすい（書く量が多くなれば、それだけ間違いも増えるし、発見しにくくなる）ので、現実的には、自動生成するか、ドキュメントを減らすほうが。。。（＾＾；）
（って、自動生成するくらいなら、作らないほうがいいんだけどね）

　ウィリアムのいたずらのヒアリング用Excelシートとの関係で言うと、ユースケース一覧の内容を、１行１シートにし、その代わりユースケース間の階層関係を表現し、読みやすくした上で、システム化業務フローを文章化したものが、業務のシートになります。

---

■ということは。。

　ってことは、富士通の開発標準も、実は、DOAやUMLと同じく、
１．入力データから出力データは作れるか
２．そのデータ処理方法は？
っていうことを書いているに過ぎないです。

　実は、その前の時代に作られた、情報関連図（というのもある）も、同じ内容ですし、さらにその前の時代に作られた産能大記号を利用した作業の図なども、同じ内容ですし、清水建設のLFD(レーンフローダイアグラム）も同じ内容です。

　要するに、日本がインドにＩＴで負ける日－ＩＴ敗戦国、日本－で「ＤＯＡ、オブジェクト指向－結局、昔と見方変えただけじゃない？」っていう項目を作ったように、基本的にはDOAの図もUMLも同じ内容（ただしUMLのほうは、データとプロセスの関係が切れる）をあらわしていて、さらに、それは以前から書いているものの見方を変えた手直しにすぎないといえると思います。

　そのあとに、「ソフトウエア工学は発展したけど、ソフトウエア品質は、結局あがってるの？」と書いてあります。
　それについても書くと、品質を上げるには、要件の正しさ、完全性（出力を入力データと条件が完全に挙がっている）を上げないといけないのですが、ソフトウエア工学は、そうではなく、その要件を、どのようにきれいに、分かりやすくまとめるかという方向に尽力しています。

　分かりやすさも重要ですが、それだけでは、品質を上げる用件にはならないわけです。

　これが、 ソフトウエア工学が発展しても、品質は上がらない１つの理由です（他にいくつも理由があります）

---

　っていうことで、業務はまとめたということで、次回は、要求仕様を書く話です。

「べつやくメソッド」でブログ作成、ケータイからでも入力可とかいいかも！

　イソプレスうぉっちの、全記事に「べつやくメソッド」を導入 について取り上げた、前のブログで、


Ｐ．Ｓ　べつやくメソッドのブログツールとか、アリかも。。
　　　　で、べつやくメソッドでブログを書いてもらえば。。
　　　　・・・ソコから先は別項目にしたほうがいいか。。話ずれるから。。


って書いた話の続き、つまり、べつやくメソッドのブログの話。

---

この「べつやくメソッド」で、ブログを書いてみた。
こんなかんじ
「萌えは日本の誇るべき文化だと痛感」 黒川氏、メイド喫茶見学で
http://plaza.rakuten.co.jp/struts/diary/200704020000/

著作権がありそうなので、左側に写真はいれてないんだけど、
うん、わかりやすくていいかもお。。

---

この「べつやくメソッド」でブログを書く画面なんかあるといいかも。。

円グラフの項目をいれるところと％がいくつかならんでて、

そこに円グラフの項目と、パーセントをいれて、
（上記の例だと、「単なるエロじじい？」　２０％とか）

あとは表題、リンクしたい記事、入れたい写真のURLを
セットしたら（表題以外は入力しないでも可）、

この円グラフをつくってくれて、ブログ完成。。っていうの。。

---

それだとかんたんなんで、いっぱいアップできそう（＾＾）

ケータイからでもアップできるの、作れそうですよね。
で、見るほうも簡単だし。。

これ、ブログにいいかも。。。
（これ「しか」ないと、さすがに、困るかもしれないけど。。

Web2.0で「べつやくメソッド」の記事化は可能、ネット時代の新聞社の生き残り術かも？

　うーん、新聞とか、この方法に、ほんとにして欲しいと思う。

　去年は、いもうとデスクトップで、リアル世界にも影響を与えた？イソプレスウォッチのエイプリールフール特集だが、今度は、本当に、こうしてほしい！！＆もし実現すれば、リアル世界に相当なインパクト！！っていうのが、でてきた。

イソプレスうぉっち、全記事に「べつやくメソッド」を導入
http://bb.watch.impress.co.jp/static/uocchi/2007/04/01/betuyaku.htm

つまり、
１．記者が、この記事で大事という部分を、数個選び、
２．それを円グラフにする。。
３．そして、それを記事として発信！！
っていう感じなんだけど、ほんとうに、記事って、こうして欲しいと思う。

で、Ｗｅｂ２．０の要素を加味して、円グラフの数値は、ユーザーがクリックするようにして欲しい。

---

そーすると、こんな感じになる

１．速報として、記者は、大事だと思うポイントを数個をあげ、
　　→１項目せいぜい２０字くらいで、数個、見出し風にあげる

２．そうすると、記事のタイトルと、その円グラフが、アップされる
　　→はじめは、各ポイント均等に（４つのポイントなら各２５％、５つなら各２０％）

３．読んだ人は、その中で、大切だと思うポイントをクリックする。
　　→そうすると、そのポイントのパーセントが増えるっていうか、クリック数に応じて、
　　　パーセントが変わっていく。つまり、４記事だったら、初め２５０クリックづつ
　　　下駄を履かせておく（こうすると、はじめ２５％になっている）。
　　　その後、ユーザーのクリックに応じて、（クリックされたものを足して）
　　　パーセントを出す。

４．３のクリック総数が多い記事だけ、詳細内容を書く。
　　クリック数が少ないのはみんな関心が無いので、放置しておく。。
　　→こうすると、見たい記事だけ書かれ、広告が載るので、広告側も有利。
　　　ニュースを書いてる人も、詳しい記事を書くのは、クリック総数が多いの
　　　だけでいいので、書かなければいけない記事の数が減る。
　　　→たしかに、記事の生産性もあがる。。


　これって、新聞社にとって、ネットと共存して、新聞の生きる道になっていくんじゃない？

１．まず、ネットでべつやくメソッドでニュースをだし、
２．クリック数が多い記事のみ、新聞で取り上げる。
３．そして、
　　「新聞には、こんなことをかくよお！」
　　と、ネットのべつやくメソッドで表示しているところに書いて、宣伝する！！

　そうすると、新聞には、興味津々の記事だけ、より深くのり、ネットと切り分けられる。。っていうか、ネットが宣伝になる。。。


おおおお、べつやくメソッドっていいかもおお。。

Ｐ．Ｓ　べつやくメソッドのブログツールとか、アリかも。。
　　　　で、べつやくメソッドでブログを書いてもらえば。。
　　　　・・・ソコから先は別項目にしたほうがいいか。。話ずれるから。。

”「システム管理基準 追補版(財務報告に係るIT統制ガイダンス）」の公表について”とか。。

３月３０日に、急に経済産業省から、興味津々の報告書がいろいろ出ていたので、
３０日でなくても、最近でていて、おもしろそうなものを
メモメモ。。。

自分へのメモで、まだ中身をみていないので（というか、中身をあとで見るための
メモなので）本当に興味深い内容かどうかは？？？

もし、見て、なんか、興味深い内容がかいてあったら、
このブログでとりあげますね！

●「産業構造審議会情報セキュリティ基本問題委員会報告書（案）」に対する意見募集について
http://search.e-gov.go.jp/servlet/Public?CLASSNAME=Pcm1010&BID=595207011&OBJCD=&GROUP=


●「個人情報の保護に関する法律についての経済産業分野を対象とするガイドライン」の改正について
http://www.meti.go.jp/press/20070330012/20070330012.html

●「電子商取引及び情報財取引等に関する準則」の公示について
http://www.meti.go.jp/press/20070330011/20070330011.html

●「中小企業のための知的資産経営マニュアル」の公表について
http://www.meti.go.jp/press/20070330003/20070330003.html

●「システム管理基準 追補版(財務報告に係るIT統制ガイダンス）」の公表について
http://www.meti.go.jp/press/20070330002/20070330002.html


●「ベンチャー企業からの公的調達の促進に向けた研究会」報告書について
http://www.meti.go.jp/press/20070330001/20070330001.html