バッチプログラムのパターン化について、ＣＯＢＯＬとＪＡＶＡの共通点・相違点

　パターンのお話をしているブログをみて、ふと思いました。
　プログラムのパターンについて、画面があるものは（表示方法が違うから）もちろんなんだけど、バッチ系でも、ＣＯＢＯＬのパターンと、ＪＡＶＡのパターンって違うよな。。

　と思いつつ、考えてみると、
　ＣＯＢＯＬのバッチパターンって、
　そろそろなくなるかも！と思い、

　おおおお、これは、
　ＣＯＢＯＬ文化財保護協会　会員ナンバー３番（うそ！）の
　ウィリアムのいたずらとしては、書き残しておかねば！
　と思ったので、

　独断と偏見による、
　ＪＡＶＡとＣＯＢＯＬのバッチプログラムのパターン、
　共通点と相違点
　を、今日はお送りします。

---

　バッチのパターンの共通点

■■　目的

・開発思想を統一する
　開発思想が異なったものが混在すると、その思想の矛盾によって、障害を招く可能性がある。
　特にアジャイル開発とかで、開発思想が途中で変わると、ひどいことが起こる。

　そうそう、ウィリアムのいたずら、このまえさあ、ＤＢアクセスでね、パターン作ってあるはずなのに、だれかの連絡ミス？かな？？途中から、変わっちゃてさあ、それでありえないひどい目にあったよ(@_@!)

　っていうのも。。。

　って、今日は、体験談を話す日ではなかった。省略します。わき道それてすみませんです。

・品質の担保
　パターンの前処理、主処理、後処理ごとに、決まったログが入ることによって、このパターンを守っていれば、そこを通過したことは、わかるといった感じ。

　品質の保証はテストでやることだけど、保証はしないけど、最低、このことだけは、守られるといったような担保（って、いわなかったっけかな？？）

　ＣＯＢＯＬの場合、printStackTraceという命令が無い。
　そのため、モジュールのなかのスタッカに、そのモジュールを通過した情報をいれ、エラー発生時に、そのスタッカの中身を吐き出させるといった感じで、printStackTraceと同じ効果が出せる。とかね！

・業務内容の位置付け
　どのパターンを使うか、パターンは使えないか、使えない場合、どこをどういう風に修正すれば良いかを考えることにより、その業務は、どのような位置付け（パターンに一致しているか、してないか、してないとき、どれくらい違うか）を明確にすることが出来る。

　これがなされてないと、人によりやり方が違い、本来、やさしい業務が複雑になっていたり、似たような業務が、まったく違う方法でかかれて、品質にばらつきが出る上、保守しにくい。


・プログラムの共通化・再利用
　これもあるけど、共通化するほど、バッチを作らない場合（数本しか作らないとか）、パターンも作らなくていいの？ということになるので、これが目的！とは、一概には言えない。

■■　主な流れ

パターンの主な流れは、以下のとおり

・前処理
共通部分：
　プログラムに入ったことをログに書き出させる
　共通の環境変数などあれば、取得
　入出力のオープン
　　　ＤＢ関係
　　　プリンタ出力関係
　　　ネットワークのコネクションとかもあれば

固有部分：
　引数の取得、チェック、
　そのほか、主処理を行うために必要なもの
　
・主処理
固有部分：
　やりたい処理を書く。
　レコード処理の場合は、ループすることも

・後処理
固有部分：
　主処理の後始末

共通部分：
　入出力のクローズ
　　　ＤＢ関係（ここで、コミットする場合は、コミットも）
　　　プリンタ出力関係
　　　ネットワークのクローズとかもあれば
　プログラムが終わったことをログに書き出させる
　正常ステータスでＥＸＩＴ

・エラー終了（かなないときも）
　プログラムがエラーしたことをログに書き出させる
　入出力の異常終了
　　　トランザクションのロールバックなど
　異常終了ステータスでＥＸＩＴ

---

　ＣＯＢＯＬとＪＡＶＡバッチのパターンの共通点

■■　実装方法

　ＪＡＶＡの場合は、パターンの基本的な部分をクラスにまとめ、
　個別のプログラムで、それを継承して使うこともある

　ＣＯＢＯＬの場合は、パターンをどっかにかいておいてCOPYでおこなったり、
　もともと、何も処理が書いてないパターンソースがあって、修正したり。。。

■■　実際のパターンの種類

　ＪＡＶＡの場合は、バッチパターンなら、
　　・前処理、主処理、後処理の１とおり
　または、
　　・主処理がぐるぐるまわる、
　　・主処理がぐるぐる回って、１回、回るごとにコミットする
　こんなかんじだけど
　（あと、プリンタ出力するときとか、ＤＢアクセス用とか、お好みで）、

　ＣＯＢＯＬの場合、業務処理をさらにパターン化しちゃって、
　　・リスティング用
　　・エディティング（アップデート・更新）用
　　・ソート
　　・マージ
　　・マッチング
　　・チェッキング
　など、いろんな種類のを作ってしまうこともある。
　ＣＯＢＯＬは、こう「しない」と、効率がわるい。
　ＪＡＶＡは、こう「する」と、効率がわるい。
　理由は、気が向いたとき、かきます。

---

　以上、あくまでもウィリアムのいたずらの独断と偏見で考えた、パターン化についてです。

　独断と偏見なので、外れてる部分とか、あるかとは、思いますが、大目にみてやってください。
　実は、なぜ、パターン化の話をしたかというと、他にも目的があるのですが、それは、機会があって、そのとき、覚えていたら、また書きます。

　ってことで、今日の「パターン化のお話」は、ここまで。

create table文やテーブル構造が書かれたものからＥＲ図を半自動的に？でっち上げる方法

　昨日のブログで設計の段階でＥＲ図を作る方法を書きましたが、最近の流行は、ドキュメントはプログラムからの自動生成です。

　ということで、ＥＲ図もテーブル構造から、でっち上げることが出来ます。

　その方法、もう新人ではない人（実務経験２年くらい）に、ウィリアムのいたずらが言ったら、わざわざメモとっていたので、それほどのことではないと思うけど、ここにかいときます。

---

１．テーブル＝エンティティと、かってに思い込みます！
２．テーブルの主キーをチェックします
３．Ａというテーブルの主キーの項目（カラム）が、Ｂというテーブルの項目に含まれていたら、
　　リレーションを引きます（Ａ、Ｂは、任意のテーブル）。
４．あとは、カーディナリティ（１対多、とか１対１とか）を、適当にいれます。
　　（細かい目安みたいなもんは、あるけど、長くなるし、目安でしかないので省略）
５．１のエンティティ（テーブルだけど）を四角に書いて、なかにテーブル名（tblとかは省略）
　　そのエンティティ間に対し、３のリレーションがあるものは、線でつなぐ。
　　きたなくなったら、きれいに配置して
６．４のカーディナリティをかきいれ

できあがり！！

---

注：
　あくまでも、これはでっち上げです。
　これだと、プログラム上、便利だから作ったテーブルまでエンティティになってしまいます。
　ただ、発注元や元請けから、ＥＲ図をかけ！といわれたとき、オブジェクト指向でドキュメントを作ってしまい、どーしてもＥＲ図を作らなければならないときの手段です。

　と思うけど、世の中、JavaDocのように、ソースからドキュメントを自動生成しているのが、普通の文化になってきたくらいだから、create table文から、ＥＲ図を作るほうが、いまや、普通の文化・・・なのかなあ？？

オブジェクト指向と、構造化分析についてフリーSEの立場

　 最近、オブジェクト指向と、構造化分析にかんしての話題のブログが多いと思います。

　そこで、この人気？に乗じて、ウィリアムのいたずらも、ひとつ。

　まず、この手の話の場合は、自分のおかれている環境を書くようだ。なので、ウィリアムのいたずらの立場。
　ウィリアムのいたずらは、バブルのころは、ビジネスのモデルを作るお仕事（システムやさん）をしていましたが、その後、落ちぶれて？？いまは、業務系のアプリケーション作成や業務系のドキュメントからプログラム、テストデータを自動生成するようなプログラムを作ったりしてます。

　が、一番大事なことは、今は、下請けだということです。

　で、下請けの立場としては、方法論はえらべません。元請けが、「これをつくれ」といわれたら、それを作るしかありません。

　その立場だと、オブジェクト指向と、構造化分析、１つのシステムで、両方やらされます。
　理由は、DBのテーブル設計のドキュメントとして、ER図
　　　　　JAVAのプログラムのドキュメントとして、クラス図
　　　　　システムの内容を示すのに、ユースケース図を入れさせられる
　のが、最近、多いからです。

---

　ER図を入れさせるのは、RDBのテーブルのドキュメントとして、まっとうな話だと思います。
　でも、ER図は、DFDと同じく、構造化分析のときに作る図です。

　一方、クラス図を入れさせるのは、Javaで作っている場合、これまた、それほどはずした話ではありません。
　でも、クラス図は、UML,オブジェクト指向で作る図です。

　下請けの場合、この両方の図を入れさせられるので（RDBをつかって、Javaで開発させられる場合）、結局、両方の分析が必要になります。しかし、両方の分析を別々にやったら、時間がない上、話が合わなくなる危険もある（おなじエンティティを違う名前で、違う視点で分析してしまう可能性もある）ので、オブジェクト指向から構造化分析にもってくる方法、その逆、両方できなければなりません。つまり、下請けの場合、オブジェクト指向と、構造化分析は、優劣をきそうものでなく、分析の過程で、相互交換できないと、まずいものになります。

---

　で、相互交換の方法。

１．ユースケースのユースケース（楕円）を、DFDのプロセスとします。
２．シナリオ中、ユースケース（動詞かサ変動詞）を修飾したり、目的格、主格となる名詞が、
　　データの保管先・保管元（エンティティ）または、データの発生源・行き先
３．で、データのエンティティがでてきたら、そこにリレーションをいれる
　　という手順でER図をつくる

　DFDからの場合は、ユースケースに変換します（プロセスをユースケースに）

　こういう意味で、DFDのプロセスは、ユースケースとおなじく、機能であり、
　COBOLは、プログラムモジュールで機能（プロセス）を実装し
　オブジェクト指向の場合、機能は、メソッドになります。
　これが、「のものも」さんのブログ単体テストあれやこれやにでてくる以下の文

COBOL時代の「モジュールの定義」とオブジェクト指向時代の「モジュールの定義」とがうまくリンクしていないところがあるようです。聞いた話ですが、COBOL時代からの品質管理担当者の意見では、「Javaのメソッドは単体テスト、クラスは結合テスト」なんて言っているところもあります

のキ・モ・チかなあ？と、勝手に思っております。

---

　さて、じゃあ、オブジェクト指向と、構造化分析、どこでわかれるかというと、情報隠蔽をするところでわかれます。

　プロセスに関しては、DFDでも大きな機能から小さな機能へ詳細化していく形になりますし、オブジェクト指向でも、上位クラスの中に、詳細な下位クラスを書いて、細分化できます。

　問題は、データのほうです。
　RDBの特徴は、「一貫性・共有制・独立性」といわれるように、データを共有します。
　共有＝隠さないということです。
　この共有化を行うための作業が、正規化になります。

　一方、オブジェクト指向は、データを隠すことができます（カプセル化で）。
　ここで、問題が起こります。データを隠してしまうと、共有制が崩れます（もちろん、一貫性も）そうすると、RDBを構造化分析で使う前の問題である、データの矛盾がおこったり、おなじデータを違うように定義して、わけわかんなくしてしまったりします。
　これが、「いがぴょんさん」のブログにでてくるオブジェクト指向レス開発という選択肢にでてくる「逆正規化」のキ・モ・チかなあ？と、勝手に思っております。

　で、たしかに、オブジェクト指向で、データを隠されると、失敗しやすい。。。
　たいへんなのよ。データが関連しちゃってね。。
　この前、テストのとき、テストデータをつくるときね。。。（；＿；）
　って、私の体験談は、どうでもいいね。。。次！

---

　しかし、データの情報隠蔽に関して言えば、これを行わないと、困ることがあることもたしか。

　たとえば、DTP（で作る本）とWeb、同時に公開するシステムにおいて、赤といったら、Webの人はRGB系で、DTPの人はCMYKで欲しい。
　で、このRGBからCMYKの変換法則は、プロファイルを利用して。。。。っと、かなり長いプロセス＆多くの人に知られていない＆たまーに、業務と関係なく仕様変更になる可能性あり！が必要なんだけど、それはみんなに見せたくない。

　これなんかが、「さとし」さんのブログ構造化手法とオブジェクト指向に出てくる
オブジェクト指向で新たに導入されたアプローチを利用しなくてもそれなりの設計は可能である。でも、よりよい設計をするためにはオブジェクト指向で導入されたアプローチは必須である
の例なのかなと、かってに思っております。

　あ、ついでにいえば、上の例が、たぶん「ペーペープログラマの日記」さんのブログや、arclampさんのブログに出てくる、「賢いデータ」の例でもあるかなと勝手に思っています。

---

　つーことで、みかままさんのブログのおっしゃるとおり、構造化分析・設計はOOと対立する概念じゃなくて、ウィリアムのいたずらの場合、両方やらされるんだけど、問題となるのは、オブジェクト指向らしい機能である「情報隠蔽」なんです。

　どこまで情報を隠して設計するかというのは、これは、コンピューターシステムの開発だけじゃなくって、リアルのビジネスモデルを開発する上でも「何を、どこまで機密にして、だれに知らせるか」、「どこまで公開していいか」という、かなり大きな問題となります。

　国の場合、この問題は、個人情報保護法のように、きまりがあるけれど（？？？）
　業務では、ないので、どこまで情報隠蔽するか。。。

　の基準りは、実はウィリアムのいたずら的にはあるんだけど、それを書くと、さらに長くなりそうだし、きょうは、いろいろな人から引用してしまったので、みんなから、「おまえの考えはちがーう！！」とぼこぼこにやられそうなので、「今日のところは、ここまでにしておいてやろう」（吉本新喜劇風に）

実際の開発は、トップダウンとボトムアップの悪いほうを足して２で割ったかんじ（その１）

　おととい、トップダウンの記事、昨日、ボトムアップの記事を書きましたが、実際の開発は、この２つの悪いほうをあわせて２で割った感じになると思います。

　実際には、システム開発を行うとき、偉い人が、のりのりで、こんなのをやりたい！とか、目標とか、夢をかたっちゃいます。

　これをかっこよく、to-beモデルとかいってるかもしんないけど、とにかく、偉い人が考えた、コンピューターを導入した、まだ、やっていないことです。抽象論です。

　で、その偉い人は、「あとはよろしく」なのです。
　具体的に、きっちり出来るところまで、見切ってはくれません。
　具体論は、部下にまかせて、できないと、怒るだけなのです。

　そうです、わがままいって、出来ないと怒る、ちいさいだだっこの子どもと一緒です。

　彼らにとっての要求仕様とは、小さい子のだだっこと一緒です。

　これだけの金をあげるから、コンピューターシステムをつくって、こんだけ儲けさせてくれという「だだ」です。
　当社の要素技術は、これであり、この技術をこう結ぶと、こういうことができるはず！という絵があって、それを結びつけたシステムを要求しているのではありません。

---

　で、現場では、なんとか、その実現方法＝具体案をかんがえないといけません。
　つまり、この技術や、この人をこう結ぶと、こういうことができるという絵をつくって、それを結びつけたシステムをつくんなければいけませんが。。。

　上の人は、だだをいっただけで、それができる裏付けをとったわけではありません（要素技術をくみあさせて、できる！と読みきったわけではありません）。
　だから、実際、具体化していくと。。。あ、むすびつかない！できないということもあります。

　そうやって、気が付けばまだましです。

　具体化する方法すらわからない人もいます。

　方法がわからない人は、それでも、まだましです。
　
　自分は具体化しなけりゃいけないという仕事の内容すらわかってない人がいます。

　要求仕様とは、

　　・エラーい人が言ったことを目標として紙にまとめ、
　　・自分の思ったことを要求として、非機能要件とかいうかっこいい名前を付けて、
　　・現状をコンサルやＳＥに分析してもらって、
　　・それをきれいなユースケース図などというものとかに書いてもらえばいい。
　　・あとは、レビューというやつに出て、おかしいところを指摘すればいい。

　そんな、甘い考えで、システムなんて、できるわけねーだろ！
　だれが、その要求仕様のシステムができるっていう、裏をとるんだよ！

　めからびーむ！！

---

　といいたいところなんだけど、下請けである、フリーのウィリアムのいたずらは、言えるわけはないので、システム開発になると、
　自分で、たぶん、要素技術はこれで、
　（コンピューターだけでなく、業務の技術もある。
　　　在庫のピッキング方法、
　　　ＢｔｏＣでの集金方法（＝クレジット、口座引落、振替、代引きなど））
　こういう絵を書けば出来るんだろうというもんをつくって、
　もっていくと、非難ごうごう。

という形で、やっとスタートラインにたてるわけです（システムとして、出来るめどがたつ）

このはなし、つづく

ボトムアップで開発すると、結局問題先送りで、なにもせずに月日が流れることも

昨日、トップダウンで開発する話の問題を書いたので、きょうは、ボトムアップの開発での問題。

　ボトムアップで開発していくと。。。

　まず、「話がわかっている、ここから開発しましょう！」
　っていうことになり、分かったところから開発していくことになる。

　分かったところから開発すると、わかんないところは、先送りになる。

　そんなことしてると、いつまでたっても、
　わかんないところは、わかんないままで。。。

　開発１年だと、半年ぐらい経ったときに、
　「そろそろやばいんじゃないか？」
　といいだし、みんながやばいと気づいたときには、
　どうしようもなくなっている。

なんていうことで、問題が発生することもある。

---

　ちなみに、ボトムアップとトップダウンって、結局、構造化分析でも、オブジェクト指向でもありえるとおもう。

　構造化分析の場合は、たしかにトップダウンアプローチなのですが、オブジェクト指向でも、抽象的なクラス、大きな作業のクラスから、具体的、詳細化の部分をつくっていき、具体的、詳細化のクラスは、まず、ダミーのクラス（＝スタブ）をつくって、適当な値を返すようにしておけば、トップダウンでも分析・開発可能。。。

　一方、ボトムアップについては、オブジェクト指向の場合、分かっている部分を局所化して、クラスとし（ボトムアップで）積み上げていくことも出来る。でも、構造化手法でも、上記のように、問題を先送りにして、部分だけ作ることも可能だし。。。

　つーことで、まあ、技法にかかわらず、トップダウン、ボトムアップでは、問題を先送りにできるわけで、そーすると、やばいわけだ。。やっぱ、野中先生の唱える、ミドルアップダウンの出番かあ？？と思う、ウィリアムのいたずらなのでした。

トップダウンでメソッドを詳細化していく方法って、ビジネスだと、危険なこと、あるよね！

　いろいろブログをみていたら、「ひがやすお」さんの、こんなことがかいてあるブログに目が留まりました。
（以下引用）

はっきりいって構造化プログラミングは、好きではないし、有害とさえ思っています。なぜなら、トップダウンでメソッドを詳細化していく方法は、より抽象度の高いメソッドがより具体的なメソッドに依存することになり、変更が入ったときにその影響を受けやすくなってしまうためです。

　ウィリアムのいたずらは、（その「ひがやすお」さんのブログのテーマである）構造化プログラム、構造化分析と、オブジェクト指向について、今日は、語りたいとは思ってないのです（また、別の日にでも）。
　ただ、トップダウンでメソッドを詳細化していく方法は、より抽象度の高いメソッドがより具体的なメソッドに依存することになり、変更が入ったときにその影響を受けやすくなってしまうについて、「ひがやすお」さんが、こういう意味で、おっしゃっているのかどうか、わかんないけど、同意することがあるので、ちょっとかきます。

---

　構造化分析の場合、まあ、こんなかんじでしょうか？

１．	はじめに自分のシステムを丸く書き、そのわきに、周辺の入出力を書いて矢印でむすぶ、コンテキストダイヤグラムを作成する
２．	そのコンテキストダイヤグラムを詳細化し、ＤＦＤを作成していく
３．	２のＤＦＤをさらに詳細化したＤＦＤをつくり、そいつをまた詳細化したＤＦＤをつくり。。。
４．	ついには、ミニスペックとよばれる、簡単に言葉で書いた仕様にまで、落とし込む（詳細化する）

　これの、どこが問題？？となるのですが、これだけなら問題は生じないのです。

　ただ、この手法を、ビジネスの仕組みづくりのときに応用すると、

・えらーい人が、総論で話しているときは、いいんだけど、
・それを、部長、課長、したっぱ、と落としていくごとに、「ありえねー！」となって、
・一番最後になって、だめじゃん！やっぱ、かえなきゃ！

　となっちゃうと、大幅変更っていうよりか、モデルとして成り立たなくなっちゃうことがあるのよね（というのが、ベンチャーのシステムなんかに多い気がする）

---

例：放送とネットの融合

■■えらーいお方、
　放送とネットの融合させ、テレビ放送でやった番組を、ネットで配信しよう！

■■部長クラス：
　月９ドラマを、ネットで配信したらどうだ！

■■課長クラス：
　月９ドラマの著作権関係を全部調べて、けりをつけておくように

■■しもじも：
　ひえー、むちゃ！だってそこに流れる音楽の著作権でしょ。
　俳優さんの出演料は？
　どーやって、カウントして支払うのよ！
　そもそも、それって、コピーの問題とか、大丈夫なの？
　　→だめっす！むりっす！

っていうと、会社みんなうごいて、結局無理！みたいな。。。

---

　つまり、はじめから、著作権問題とか、いろんなネタを解決しておいて、そのネタを組み合わせてビジネスにする。。。それならいいのね。

　でもね、トップダウンで、「これいいんじゃない？？」っていう抽象的なアイデアを出されて、「あとの詳細・具体策は、しもじものみんな！がんばって！！」っていうやりかたは、結局、どうにもない！！っていう時があって、「結果、できることといったら、女子アナの写真をもらって、ネットで流す」なんていうオチになっちゃったりするのよね。。。

　ベンチャー企業さんは、トップダウンで自分のアイデアをだして、あとはよろしくというビジネスモデルをやめて、ちゃんと、できるところから、こつこつと、それを組み合わせて、ビジネスモデルをつくったほうがいいとおもいます。

　大学のえらーい先生がた、国のお役人のえらーい先生方には、ぜひとも、そういう、トップダウン式での起業をあおるんじゃなくって、地道な努力で、できるとこからこつことと？やっていって、起業するような指導をしていただきたいものっす。

---

　あ、でも、じゃあ、ボトムアップがいいのか？っていうと、ボトムアップにはボトムアップの問題があるのよ（今度書きますね）
　なんで、構造化分析とオブジェクト指向どっちがいいのか？ということに、今回の話は答えたわけでは、ないっす。

これでExcelの仕様書から、JavaのソースやDDLの自動生成を、Javaを使ってかけそう

　いままで、Excelの仕様書からJavaのソースコード自動生成をするのを、Excelのマクロを使って書いていたけど、なんか、

　　JavaからExcelファイルの読み書きが出来て、

　　結局、Excelファイルの仕様書から、
　　　　　Javaのソースプログラムや、
　　　　　ＳＱＬのＤＤＬなんかを、Javaを使って自動生成できそう。

（Javaのソース自動生成といっても、ＭＤＡみたいな話じゃなくって、Excelの仕様書にデータベース定義があったとき、そのデータベース定義から、ＤＢアクセスするクラス作るなどどいうとき、そのソースを自動生成できるという意味）

---

　というのも、JExcelApi (Java Excel API) っていう、Excelファイルを読み書きする、Javaのライブラリがあるみたい
　ここ！ここ！

---

　つーことは、

　　　Strutsとかでも、Actionクラス（から呼ばれるサーバーサイドのクラス）から、
　　　これを使ってExcelファイルを書き出し、
　　　そのExcelファイルを適当なときに、プリンタ出力

　させれば、ADO使わなくっても、Excelファイルを帳票にして、印刷できるのかな？？

　きょうみしんしん。

　まずは、おとしてきて、遊ばなくっちゃ！！

１１日の「コピーされるほど儲かるシステム！開発日記」は、プロトタイプ

　５月１１日に出した、「コピーされるほど儲かるシステム！開発日記」第１８号は、今回作るものの、プロトタイプです。

----------

　「コピーされるほど儲かるシステム」で作成するものの画面についての内容がかかれています。それと、今後についてです。

　今後は、上記プロトタイプで示したものの作成（開発編）と、
「コピーされるほど儲かるシステム」の理論的根拠である、口コミマーケティングや、
その口コミマーケティングで紹介されている、ブログの活用法？
などというはなしをやります（理論・実践編）。
　
　ということで、あとは決り文句。

----------

　１８号のメルマガについての、感想などはここの「コメント」にどうぞ！

　メールと、ウィリアムのいたずら自身のブログについては、このブログの
「コピーされるほど儲かるシステム！開発日記」へのメールについて
http://blog.goo.ne.jp/xmldtp/e/a58b79b40b1148c2f744556e27b76a79
を参照してください

富士通ようかん ＶＳ ニコンようかん

　ことのはじまりは、富士通クッキー？？があるらしいことからはじまった。このブログで発見。

　そのことを以前のブログに書いたら、

　そこのコメントに、

　富士通は、ようかんも、カレーも売っている

と、教えていただいた（さくらさんより。。情報、ありがとうございます）

---

　これは、調べてみないと！と思ったら、富士通が公式発表？？してました（こちら）

　さらに、調べたら、ニコンようかんなんてーのも、あるらしい。

---

　でも、ニコンようかんは、Webで買えるかもしんないけど、富士通ようかんを買うには。。。

　川崎工場や、中原の購買ですか。。。
　川崎工場って、たしか、受付があった気がする。

　受付で、

訪問先　　：　こーばい
訪問の目的：　ようかんを買う

って、書いたら。。。

追い返されそうだ(^^;)

ブログを書くと、認知度が高まって、商品が売れる？本当かねえ？？

　さて、前のブログで、「ブランド・ブロッギング」というのを書きました。
　ブログで、認知度を高めて、商品を売るという方法だそうです。

　ということはですよ、ウィリアムのいたずらは、「コピーされるほど儲かるシステム開発日記」というメルマガをだしています。
　なななんと、このブログの表題でもあります。
　たまに、そのメルマガの話題もかいています。

　なので、もし、「ブログで、認知度を高めて、商品を売る」という手法が有効なら、このメルマガの読者も増えているに違いない！

　みなさん、そう思いますよね。

---

　このブログ、そのメルマガのためにできたものなのですが、

　　当初は、一週間に１０アクセス（PV）程度だったのに、
　　昨日なんか、１日で２３１PVまで行っています。

　もう、すごい盛況です。

　ありがとうございます。これも皆様のおかげです。

---

　さあ、じゃあ、メルマガのほうは。。。
　ブログで商売をしようと考えてる人にとっては、興味ありますよね。

　ところが。。。

　メルマガのはじめのころ、読者数１８０人くらい、
　最高１９０人くらい、
　今も１８０人くらい。。。

ぜんぜん、かわってないんです。

　メルマガは、無料メルマガです。無料でも、そんなに読者数はふえません
　（もちろん、減らないのは、このブログのおかげかもしれませんが）

---

　つーことで、ブログのわりに、メルマガは伸びない。。。

　これは、

　　　　ブログに関係ない話題だから。。。

などという、ウィリアムのいたずらのせいとかんがえることもできます。


　でも、ひょっとして。。。ひっとすると、


「ブログで、認知度を高めて、商品を売る」という
　　　考え自体が間違ってるのかも？


　つまり、「ブログで、認知度を高め」ることは可能なんだけど、商品を買ってくれるかどうかは別問題だと。。。うーん、「ブランド・ブロッギング」の考え方、

ブログを書くと、認知度が高まって、商品が売れる

本当に、そうなるのかねえ？？

「コピーされるほど儲かるシステム」で作成するものの画面について

前回「コピーされるほど儲かるシステム開発日記」のメルマガで、今回は、以下の内容を行うことになってました。

　「（お）プロトタイプを作ってみて、確かめる（要件のプロトタイプ）」
　ということで、実際に画面まわりについての様子を示します。
　
　そこで、今回、画面まわりについて、作ってみました。

　ここに、その様子があります。
http://www.geocities.jp/xmldtp/mag_proto.htm
Excelを使って行います。プログラムはExcelマクロで書きます。

　機能的には、以下の３つの機能がありますが、

（１）What's New自動生成について
（２）ＦＴＰ自動送信について
（３）秘密のシート大量作成

（１）と（２）をまとめて１シートにしてしまいました。

　詳しい内容は、上記の「画面まわり」のページを見てください。

「コピーされるほど儲かるシステム」理論編（その１）口コミと、「コピーされるほど儲かるシステム」

　「コピーされるほど儲かるシステム」で、冷静に考えると、なぜ、「コピーされるほど儲かる」のか？その理論的根拠を説明していない気がします。
　なので、今日は、その理論的根拠？を、ウィリアムのいたずらの独断と偏見だけで！お送りします。

　この考え方は、２つの考え方に基づいています。

・	本当に購入したい人は、お金を払ってでも購入する。意外と、ただでコピーして聞こう（見よう）と考える人は、お金を払うんなら、購入しないような人なのかもしれない。
・	本当に購入したい人に出会うには、そういう人に知ってもらわないといけない。そういう人に知ってもらうには、みんなにコピーしてもらって、ただで配ったほうが、宣伝効果大きい。

つまり、しくみとしては、こんなかんじです。

・みんなにコピーしてもらって、しれわたる
　　↓
・購入してもいいと思う人に出会う
　　↓
・購入してもらう
　　↓
・もうかる

---

　この考え方は、いままで、ＣＤ業界がコピープロテクトをしていた考え方とまったく異なります。

　ＣＤ業界は、コピーされたから、売れなくなったと主張しますが、ウィリアムのいたずらは、そうではなく、歌を出しても、その歌が知られないから、売れないんだという主張です。
　ＣＤ業界は、コピーして、売れなくなった＝＞コピーできなくされれば、売れるという考えですが、ウィリアムのいたずらは、コピーできなくなった＝＞買わないし、聞かないという考え方です。

---

　なお、この考えのはじめに、「みんなにコピーしてもらって、しれわたる」とありますが、知れ渡るには、コピーされることだけではないと思っています。

　ただ、無名の人が、いきなり宣伝しても、効果薄いでしょうから、口コミで広げるということになるかと思います。コピーされて知れ渡るというのも、口コミの一種です。
　つまり、「みんなにコピーしてもらって、しれわたる」というよりは、もっと大きく、「口コミで、しれわたる」のほうが、内容的にはあってます。

---

　では、口コミで知れ渡る方法には、どんなのがあるかなのですが、これは、日経ビジネスにのってました。７つの方法があるようです。その内容は、昨日のブログ

　このなかで、すぐに出来そうなのは「ブランド・ブロッギング」ですね。

　「コーズマーケティング」に関しては、タイトーが、なんかやってます。でも、これって、寄付をえさに、商品を買ってもらってる気が。。。これでも、社会的なんだろうか？？って、言っちゃあ、いけないんですね。

　「バズ・マーケティング」に関しては、本があるみたい。
クチコミはこうしてつくられる―おもしろさが伝染するバズ・マーケティング

　これ以外の物に関しては、個人が、ちょっと手軽には、できないかな？？

口コミマーケティングの手法

日経ビジネス５月９日号４１ページに、「口コミマーケティングの７つの手法」というのが載ってました。
これ、あとで「コピーされるほど儲かるシステム」の説明で使うので、引用しておきます。
なお、日経ビジネスに出ているWOMMAは、ここ。また、口コミマーケティングの団体には、VBMA(The Viral & Buzz Marketing Association)というのもあるらしい。

---

口コミマーケティングの７つの手法

■■　インフルエンサー・マーケティング
　コミュニティの中で、周囲に影響力のある人物を見つけ出し、商品やブランドを紹介する。

■■　バズ・マーケティング
　人々が商品やブランドのことをお互い話すように、注目に値する話題や娯楽をつくりだす

■■　バイラル・マーケティング
　ネットなどを使い、商品やブランドに関するうわさが加速度的に広まるような仕掛けを作る

■■　コミュニティ・マーケティング
　ユーザーグループやファンクラブなど、商品やブランドに興味を持つ組織を運営し、支援する

■■　プロダクト・シーディング
　試供品や商品情報などを、有識者など影響力のある人に適切なタイミングで供給する

■■　コーズ・マーケティング
　世間の関心事に働きかけ、支援することで、その事柄に興味を持っている人の支持を集める

■■　ブランド・ブロッギング
　ブログを書いたり、ブログの場を提供することで、ブランドや商品に関する認知度を高める。
　

---

どういうところで関係するかは、後日、ブログで書く予定

そうそう、Exifの開発のとき。。うーん、ソフト業界、これでいいんかい！

　たまたま、「デジカメの撮影日時を取得」という記事を拝見いたしましたので、僭越ながら、ウィリアムのいたずらが、Exif関連のソフトを開発したときに参考にしたサイト＆開発秘話？？。（ちなみに、その記事はこちら）

　ExifについてはExifのVer2.1のファイルフォーマット規約
http://it.jeita.or.jp/document/publica/standard/exif/japanese/jeida49ja.htm
のサイトにある規約のPDFをダウンロードしてきました。

で、それだけでは、まずわからないので、このサイト（「exifファイルフォーマット」）
http://www.a-effect.com/count/sentaku.cgi?pos=column&fil=exif
にあるExifファイル（キーボードの写真がそれ）をバイナリエディタで開いてみて、
それと、その下の説明をみくらべてみました。

そして、いろんなExifファイルを落としてきては、
フリーソフトのＥＸＩＦリーダー
http://www.rysys.co.jp/exifreader/jp/
を使って、Exifファイルの内容を、確認してみました。
　後で、自分でExifファイルのデータを修正したときも、このExifリーダーを使って
確認しました。このリーダー、わかりやすくて便利です。

ちなみに、Exifファイルの上記の話もふくめ、ウィリアムのいたずらのブログの
「ケータイでわかる位置情報についてのまとめ」で、位置情報の取得方法について、まとめています。

---

　で、Exifを使った開発の話。

　その当時、ウィリアムのいたずらは、まったくExifというものを、言葉すら知らない（どうやって発音するのかすらわからない）のに、なぜか、発注者側と、営業サイドで、「ウィリアムのいたずらさんなら、楽勝ですよ。１ヶ月で、Exif解析から。。。。（このほかいろいろな仕様が続く）。。まで、ばっちりやってくれますよ」

おいおい、そんなこと、いってねーだろー

うーん、ソフト業界、これで（こんなノリで）いいんかい！

と思いつつ、話はきまってしまい、ウィリアムのいたずらの休日は消えたのであった。。。

---

　そうそう、ウィリアムのいたずら、（サーバーサイドで）ASPからExcelを起動して、帳票を作るシステムの見積もりを、昔、作成したこと、あったんですよ。

　当時は.netでなかったら、.NETは使っていないのですが。。。

　ちなみに、そのASP側から、Excelを呼び出す方法は、
ウィリアムのいたずらのプログラムメモのASPのところ
http://www.geocities.jp/xmldtp/index_asp.htm
に書いておいてあります。このとき、ASPをたしか、どっか変な風に書いて、excelがきえなくって。。。

　でも、結局、やり方を示して、見積もりを書いて。。。失注した。

　まさに、日経ソリューションビジネスの４月３０日号の特集、「引き合いバブルに踊らされるな」！

ライブドア、特に乙部綾子さんを例に、ブログの影響力と、放送の影響力を考える

　昨日、プリウスの問題について、ブログに書きましたが、そもそも、ブログをはじめとする、インターネットの影響力というのは、どれくらいあるのか？について、ちょっと、考えてみたいと思います。

　というのも、日経ビジネスの２００５年５月９日号の４７ページ、４８ページの「風評が”凶器”に変わる時」をみて、あれ？と感じたからです。

　そこに２つの例が書いてあります。
例１：アメリカのホンダシビックハイブリッドについて、文句をブログに書いたら、有名雑誌が取り上げて話題になった

例２：ななめドラムの不満を価格.comに書いても、松下は、「売れ行きも好調で（悪い風評の）影響は無い」といっている

この差はなに？

ウィリアムのいたずらは、大胆に仮説を出します。

仮説
ブログや掲示板に取り上げられるだけでは、話題にならない。 それを放送や雑誌が取り上げると話題になる

---

では、この例をライブドアの乙部綾子さんを例に考えてみましょう。
乙部さんが騒がれだしたのは、（新株予約権発行差止めの）審尋のときからですので、その前と後について

■■審尋のまえ
　乙部さんを知っている人は、ごくわずか、YAHOO掲示板で、「乙部綾子ファンクラブ」というのが、冗談か、本気か分からないかんじで取り上げられる。

■■審尋のとき
　ライブドアの審尋で、裁判所から出てくる熊谷氏を多くの局が映したが、そのとき、ＮＨＫ（だけ？）が、その後ろから出てきて、熊谷氏を車に乗せる乙部綾子さんを、長時間うつす！

■■審尋直後
　あの、きれいなおねーさんは、だれ！ということになり、Gogle等で探しだす。
　ウィリアムのいたずらも、あのＮＨＫのテレビをみてから探し出し、当時、「乙部綾子」でぐぐってみたら、二百件あるあないかぐらい。ブログでも数件しか乗ってなかった。
　そこで、ウィリアムのいたずらもふくめ、みんなが、乙部さんを取り上げ始める。

■■審尋からちょっとたって
　にわかに、ネットで乙部さんネタがでてきたところで、ＮＨＫが、乙部さんを紹介し始める、日テレがそれに続き。。。となり、乙部さん人気がブレイクする。

■■いまや
　「乙部綾子」でぐぐってみると、 54,700件

---

　このように、ネットだけでは（ＹＡＨＯＯ掲示板でファンクラブができても、流行らなかったように）人気にならない。テレビが取り上げてはじめて人気になるが、ブログなどは、その人気をさらにブレイクさせる可能性があるのかもしれない。

　だから、価格.comに書かれても、（テレビで悪い風評が流れていないので）ななめドラム洗濯機は、売れ行き好調なのであろう。

　ということは、ライブドア社長の堀江氏が言っている、「放送はいずれインターネットに吸収される」というのは、ライブドアの美人広報、乙部綾子さんの人気のブレークの仕方からみると、そうではなさそうだ。

　むしろ、どっちかというと、ライブドアも、テレビで取り上げてくれたから、ここまで有名になった、「放送さまさま」の感じのほうが強いんではないだろうか？？