おサイフケータイで、玄関を開け閉めするのができるなら、サイトに入る認証も！おねがいりんこのぷー

昨日のブログで、おサイフケータイ（Fellica）を使って、認証をやったら？と書いたけど、日本証券新聞（８月１日号　１６ページ）をみたら、おサイフケータイ（Fellica）を使って、玄関の鍵の開け閉めができる錠前が発売されるそうです。
　それを作っている会社の、コネクトテクノロジーのニュースはこちら。

　リアルの世界で、部屋に入る玄関の鍵の開け閉めを、おサイフケータイでやるんなら、
　バーチャルの世界の、部屋（サイト）に入る玄関（ログインページ）の鍵の開け閉めである認証も、おサイフケータイでなんないと！

　コネクトテクノロジーさん、つくってください（つくっても、買うお金はないので、かえないけど）。おねがいりんこのぷー

ＥＣサイトの一般的なシステム構造と、考慮点をまとめたメモ

　昨日のブログで、通論の話をしたんで、ちょっとＥＣサイトの通論なんつーのを、今日はまとめてみました。

　まあ、昨日も書いたけど、今はオブジェクト指向全盛だから、この業界的に言うと、こういう内容をユーザーからヒアリングするっていう形が一般的であって、こういうノウハウを教える人たち、別の人たち（その一派がプチリタの人たちなのかあ？？）になるんだろうけど。。

　まあ、そんなうだうだ話は、さておき、ＥＣサイト通論
　メモなんで、抜け落ちてるところは、いっぱいあると思うよ。

---

ＥＣサイトは、だいたい以下の構造に分かれる

・Ｗｅｂ上の話
　　・ＤＢから、商品表示部分（ＤＢなければいらない）
　　・ショッピングカート
　　・決済（前払いのクレジットなどの場合）

・Ｗｅｂじゃない事務処理
　　・入金処理
　　・発送

・例外系
　　・キャンセル／返品／配送不能処理

ここで、考慮点は、
（１）ＤＢを持つか持たないか
　→持つ場合、商品表示部分はＣＧＩ：デザイナーを関与させるの大変
　　　持たない場合、ショッピングカートに商品名、価格を渡す。デザイン可能。
　　 →ショッピングカートの形式がかわる
　→ＤＢを使わない場合、直接ＧＥＴ型で、適当なデータを入れられるのに注意する

（２）集金方法
　昨日のブログに書いた。
　で、問題は、どのような集金代行会社を選ぶか。
　→個人の場合、使えない代行業者あり
　　ＣＧＩを呼び出すだけでＯＫな代行業者、ＣＧＩを作らないといけない業者
　　ざまざまあるので、ここの選び方で、開発方法が変わる

・継続の場合、クレジットの情報は、サイト側で管理することになる。
　この場合、ゼウスなど、契約が違うので注意
（ゼウスの一般的な使いかたは、サイト側に顧客情報を通知しない方法だか、
　この契約方法もある。契約の仕方が違う）。

　銀行口座から引き落としの場合、口座振替依頼書を送り、それを受け取ってからになる。第一回目の引き落としには、たいてい間に合わないので、第一回目の引き落としをどうするか、考える必要あり。

　コンビニ決済の場合、自社で、あの紙をだすと、バーコードが読み取れない危険あり

　なんで、宅急便、郵便の代引きがべんり。

　郵便振替用紙は、郵便局で、宅急便の送り状は、業者にいうと、くれた気がした
（自信ない。まちがってるかも）郵便振替は、電信と一般の違いに注意
　銀行口座に振り込んでもらうときには、馬鹿が多いのに注意
（なぜか、自分の口座名に振込先を書いてしまう馬鹿がいる。誰が振り込んだか、わからんだろう）

（３）キャンセルのワークフロー
　　代行業者との、集金のからみがある。

（４）訪問販売法など、法律のからみ
　・確認画面をだす
　・とくていなんとかなんとかにもとづくひょうじというのがある。
　・個人情報保護のからみ

（５）Ｗｅｂから事務処理のつなぎ
　・ここをつなぐと、自動化できる→するかどうか
　・ＤＢ直接書き込みにすると、サーバーは自社になる（たいてい）
　・メールでやるのであれば、サーバーはＣＧＩ（メール送信）
　　事務処理は自社（メール自動取り込み）という手もある。

（６）セキュリティ・バックアップ
　ＳＳＬでやる→ＣＡは？
　
その他
・発送に関しては、事務代行業者などもある。

Fellicaの仕様置き場＆Fellicaを使って認証するシステム、作ってくれないかな！！

　mymy-mycompany分室さんのSQLインジェクション その２で、「DataAccess 」っていうクラスをつかって、ログインをチェックするお話がでてました。
　このお話、ログインをカプセル化しているわけですが、このログインのカプセル化は、ＳＱＬインジェクションの話だけでなく意味ある気がします。

　というのは、認証って、ユーザー名とパスワードだけで、なくなるような気がするんです。めんどーくさいじゃないですかあ！
　それに、ユーザー名、パスワードがわかれば、なりすましもできちゃうわけですし。。

　なんで、認証システムは、どんどん変わっていくかもしれないんで、そこだけ分離するのは、意味ありそう。

　で、そんな新たな認証システムとして、期待しちゃうのが、ケータイのFellica（＝おサイフケータイ）を利用する形！（本当は、たいして期待してないのだが、ある言葉を書きたいために、そうする。理由は最後に、わかる）

　Fellicaには、docomoに、いろいろ申し込まないと勝手には使えない、共通領域と、iアプリから、自由につかえ、仕様書がでている、フリー領域とあるようなんで、フリー領域を、使いましょう。

　Fellicaの技術仕様書は、ここ

---

　で、たとえば、社内で、認証をとって、ログインしたい場合、

（１）その会社で作った認証用iアプリをダウンロードしてきて、
　　　そのiアプリが、その人固有のIDを作成するわけ。

　　　そのIDは、
　　　　　その人を特定できる文字列
　　　　　　（この場合、社内での認証なんで、社員番号とか）
　　　　＋ダミーの適当に発生した文字何桁か
　　　としておく。

　　　たとえば、社員番号が9001で、
　　　　　　　　適当に発生した数字が2478901
　　　だったとしたら、

　　　その人のＩＤは、 90012478901

（２）認証するとき、アプリケーションは、
　　　　　ワンタイムの公開鍵と
　　　　　そのログインしてきた人の、固有ＩＤ中、
　　　　　　　　　何桁目をとってきて、それを何桁目におくかをおくる。
　　　　　（ここで、後々のために、その人を特定できる文字列は、必ず送る）

　　　上の例だと、9001は、必ず送る。
　　　　あと、今回、頭から６桁目の4と、
　　　　　　　　　　　　　８桁目の８を使い、
　　　　さらに、それをさかさまに、送ることにする。

　　　なんで、こういう指示になる

1-6
2-5
3-4
4-3
6-2
8-1

　　この文字列と、公開鍵をクライアント側（ログインするほう）に送る。

（３）ログインするクライアントのほうは、Felicaをつかう。
　　　ログインしたい人は、ケータイをかざすと、カードリーダで読み込んで、
　　　ＩＤを取得し(90012478901)、クライアントのほうで、
　　　　そのＩＤと、（２）の指示から、番号を組み立てて、(841009)
　　　　それを公開鍵で暗号化する。このへんはjavascriptを使ってやる
　　　（それとも、こういうアプリ書いたほうが早いか？）

（４）サーバー側に、（３）の結果が送られると、
　　そこから、秘密鍵で、組み立てた数字をとりだし（841009）、
　　自分が送った規則より、ＩＤを取り出し、(9001)、
　　のこりの数字で、正しく送られてきているかチェックする
　（この場合、４と８と正しく着ているか確認）

---

　こうすると、ワンタイムで、公開鍵を使って暗号化してるんで、解読されにくいし、毎回、サーバーに送信する数字が違うから、規則がわかっても、ぜーんぶ番号を知らない限り、なりすまして送るのもたいへん（もちろん、今回は短い数字で、規則も簡単だから、偶然見破られる可能性もあるけど、ほんとうは、もっと長くする）。

　自分は、ＩＤをしらないから（ケータイに入ってるＩＤは、表示しないものとする）、ほかの人には教えられない。ほかの人は、ケータイを奪って、解析しないとわかんない。

　で、おサイフケータイなんで、持ち運びもらく。

　あとは、fellica読み込み機が安いといいんだけどね。。。

　あ、もし、この方法、使いたい人がいたら、かってにどうぞ。

　ただ、思いつきで書いただけだから、どこか、特許とられてたりするところがあるかないかとか、そういうことやってる会社があるかないかとかは、一切調べてないので、そのつもりで（そのへんは、自己責任で）。

（実は、この部分は、まえふりだから。あとで、なんでこんな話をしてるのかの理由がわかる）

---

　で、これが、普及してくれると、なにがいいって、
　ウィリアムのいたずらみたいに、ケータイを持ってない人は、システムが使えない！
　それは、会社がこまる。

　っていうことで、会社がケータイをかって、くれるかもしんない！！

　それがいい

（って、そんだけのために、こんなこと、いってんのかい。　自分で買えよって！！）


　っていうわけで、

Docomoさん、
Fellicaを使った、汎用的なワンタイムパスワードの認証システムの
開発をしてください。

おねがいりんこのぷー

（って、言ってるんだよね。小倉優子って！ちがうかな。。。ちょっち自信ない。
　じつはきょうは、この言葉が書きたくて、ここまで無理やり引っ張った ^^;)

中国でうまくいかなくても、日本だとうまくいく理由は、丸投げの対応ができるからだと思う

　中国オフシェアの話で、
マネジメントしなくても半分のプロジェクトは成功するっていうことを書いているブログがありました。

　私も、中国の人たちと開発していたとき（とはいえ、彼らは、中国では、大学教授とかなので、まあ、できる人たちなのですが、その人たちと一緒にやっても）、そんな気がしました。

　理由なのですが、日本の場合、仕様書に書いてなくても、プログラムを作る側で判断するのがあたりまえなのです。
　だけど、中国の場合、書いてないことは、やらないのが、あたりまえなのです。

　だから、極端な話、私が最近やってるような、マネージャーさんは、なにやってるんだか、よーわからんけど、ほぼ私に丸投げで、私は、勝手に、すきなよーにやっているっていうような仕事は、日本では、うまくいくんだけど、中国だと、「なにしたらいいんですかあ？」と聞かれて、ぜんぜん仕事してくれなかったり、てきとーに作られて、しまったりします。

　たとえば、オブジェクト指向で書いた、クラス図があったとします。
　で、それを作る場合、メソッドの引数の意味（値の範囲とか）がわからなかったら、周りの関係者たちに、プログラマ側が聞きますよね。

　でも、中国だと、マネージャーに「ここわかんない、どーにかしろ！」といってくるのです。このとき、マネージャーは、仕事を丸投げしていたら！？
　マネージャーもだれにきいたらいいか、わかんないですよね。
　日本の場合、たぶん、丸投げだろうとあきらめて、自分たちで、ドキュメントをしらべて、聞く人をわりだし、「勝手にきいていいですか」とマネージャーにおうかがいをたてる。なんで、まるなげのしごとでも、できるというからくりです。

---

　同じ件について、atsushifxの七転八倒さんののブログで、とりあげていましたが、そこで

作業者が主体的に行動してリスクの芽を摘み取っている - 徹夜続きでもなんでもやりとげるのどちらなのかわかりませんが、

とかいてありました。これで言うと、前者のほうだと思います。

日本の仕様は、きのうの極上生徒会の内容のように、
「う」とシンディ真鍋がいうと、
「それは、どーとかこーとかで」とぷっちゃんが説明するようなもんです。
（きのうの極上を見てない人には、さっぱりわかんない説明で、すみません）

　そーやって、理解することが、いいことか、全部仕様書に盛り込んだほうがいいのかって言うのは。。。微妙な問題の気がする。

以上、あくまでも、私の経験です。ほかのひとは、違った印象／経験を持ってるかも！？

オブジェクト指向だと、ユーザー自身が業務をわかってない新規事業だと、大変だねという話

　そうそう、２日間の説明は、以前書いたブログの

なぜ、業務の標準化や、新規ビジネスを創出できないように、業界が進んでいるといえるのか？」と、思われるであろう。

と

９０年代前半で、システムをビジネスパターンに分けることによって、枯れたプログラムをつなぎ合わせる手法が、ＳＥという存在が業界から省略されることによって、なくなってきた

の説明のためなんですけど、その説明、しておきますね！

---

　オブジェクト指向による分析は、昨日、その前にも書いたように、スタートラインが、ユーザーの業務説明から始まるのが普通。

　この場合、ユーザーが、自分で業務がわからない（新規業務などは、やったことがないから、自分自身もわからないことがある）と、開発側では、なにをつくっていいかわからないということで、開発できない。仕様待ちになってしまう。
　こういうケースだと、よくユーザーさんのほうから、「あとで仕様をまとめます」とか言われる場合があるけど、真に受けてはいけない。たいてい、仕様はでてこない。

　っていうことで、新規事業、新規業務で、業務がまったくわかんないのには、オブジェクト指向は使いにくい。

　それと、もうひとつ。
　オブジェクト指向の場合、業務の標準化というと、標準化したモデルないしは、クラスの再利用ということになる。この場合、業務手順である、クラスの中のメソッドもふくむ。
　ところが、実際に業務手順までをモデル化しようとすると、なかなか決まらない。
　フォームや、コード体系なら、結構簡単に決まるけど、手順も一緒に決めてしまうという場合、なかなか、きまんない。

　なので、オブジェクト指向だけしか教えないと、標準化するのは大変だし、新規事業（業務）からシステムを組むのも困難。
　でも、最近の学校って（稚北大も、佐賀大も）オブジェクト指向中心のカリキュラムなのね！ということ。で、この業界自体が、オブジェクト指向中心の方向に進んでいるように見える。

　これが、はじめの文の説明。

---

　で、あとの文の話題。

　じゃあ、昔、新規業務のときは、どーしてたのか？というと、業務における通論というのが、存在していた。
　モデルまでの形にはなっていないけど、フォームなどはきまっていたわけっす。

　たとえば、
　　　小売で伝票なら、統一伝票だし、
　　　受発注のオンラインプロトコルといえば、ＥＤＩでＥＤＩＦＡＣＴとか。
　で、それらを使うとなると、だいたい業務パターンは決まってしまい、さらに、それらはプログラム可能なレベルにまで落としてあったわけ。

　なんで、その通論をもとに、考えればよかった。新規業務との差分をとれば、いいのね。

　このへんの通論の基準が、流通システム開発センターが、毎年、その成果を出している本にのっていて、その本を持っていると、どのへんが通論になっているかが、おさえられたわけ。

　９０年代は、こんなかたちで、通論っていうのがあって、その通論はビジネスパターンとよべる、こまかな部分の組み合わせにできて（っていうか、ライブラリがあったのよ）で、新規ビジネスでも、それの適用や、差異をとればよかった。

　でも、最近のシステム開発では、まず、そういう通論をクラス化したようなのも、見ないし、学校でも、おしえていないようだ。
（「情報処理」の佐賀大の記事にも、教える内容に、標準業務：集金業務なんていうのは、なさそうに見えた）。

　昔のＳＥさんは、そういうのを習ってきたんだけど（ウィリアムのいたずらも、さんざん勉強させられましたよ！ウィリアムのいたずらの専門はＤＴＰなのに。ちなみにＤＴＰでも、そういう通論的なシステムっていうのがあるのよね）、

　オブジェクト指向が中心になって、昔のＳＥさんみたいな、通論なんていうのを学ぶ人も機会もなくなってきましたね（通論がデザインパターンに変わってしまった。でもデザインパターンは、カネを生み出すシステムを教えてくれるわけではない）。

---

　だからたとえば、下記のシステムを開発する場合、昔のＳＥなら、一発で答えられるのに、今のシステム開発の人だと（オブジェクト指向で分析すると）、ユーザーが答えてくれるまでまってしまう。ユーザーは、知っている可能性は低いので、そーすると、システム開発が宙にういちゃうのよね。

（記）

　会員制のフィットネスクラブで、クレジットカードで、自動的に落とすことを考える。会員は、何年間も継続して契約している。

　なにが、むずかしいか、わからない？

　何年間も継続して契約しているって言うことは、クレジットカードだと、有効期間が切れてしまうって言うことなんですよ。
　なんで、有効期間を、切れるごとに、お客さんにきかないといけない。でも、いっぱいお客さんがいたら、それ聞くのも大変。どうしよう！！

　業務分析して、ヒアリングからだと、たぶん、このフィットネスクラブの人がクレジットカードをやっていなかったら、そう思うよね。

　これは、集金の通論を知ってる人なら、答えはわかると思うけど、「洗い替え」を行う集金代行業者にたのめばＯＫ。そうすると、有効期間が切れても、勝手に処理してくれる！！ゼウスなどが、対応してるよ！

SkypeなどのVoIPビジネス中国で違法って、オフショア開発＆中国のソフト産業に影響大では？

　スラッシュドットの記事によると、

中国政府の中国情報産業省(MII)は、SkypeなどのVoIPビジネスが潜在的に不法であるとの見解を示した。

そうです。（ここが原文）

　つーことは、Skypeとか、できなくなるんだろうか？
　中国では？

　もしそうだとすると、日本国内では、skypeとか使って、連絡とかが、ただになっても、中国で開発する場合、通信費が（それも莫大に）かかることになるし。。
（スラッシュドットの記事をみると、インドも規制があるみたいだし）

　さらに、インターネットも、みかままさんのブログをみると、中国は、アクセス制御がかかっているところとかあるみたいだし。。。

　つーことで、将来的に、通信費とかまで含めたら、中国で開発するより、日本のフリーの人や、（専門学校や、大学生の）学生アルバイトに頼んだほうが、安くつくんじゃないかなあ？

　中国も、ＩＴを自由にしないと、国際的に取り残されそうな気がするぞ！
　まあ、ほかの国のことだから、どーでもいいんだけどね！！

ものものさんのところの、「「テスト仕様書の書き方」についての悩み（２）」が、勉強になりそう

あ、表題で、いいたいことを、いいきってしまった。

掲示板みたいに、「本文なし」です。

ちなみに、その、ものものさんの「たまゆら雑記」の「テスト仕様書の書き方」についての悩み（２）っていうのは、こちら

Webのテストで、画面入力の手間を省き、自動化するプログラムの作成法と、それを作らない理由

m_pixyさんのブログをみていたら、

WEBシステムのテストは、画面起動から実施します、って言うけどこれは真実だろうか。

のあと、

それでいて、リグレッションテストをいかにさぼれるか、というテーマはきつい。ツールとして、画面入力を繰り返してくれるやつとかあるけど、使い勝手はいまいちだし。

とあるんですが、Ｗｅｂ系で、画面入力をサボるっつーか、あらかじめ画面の入力値をどこかのファイルなんかに書いておいて、それを読み込み、Ｗｅｂに渡す方法としては（そして、リグレッションテストでは、そいつをうごかせばいいだけにするには）、Ｗｅｂを呼び出すJavaのプログラムを書けばいいだけだと思います。

つまり、
・ＧＥＴ型で、入力された引数を設定して呼び出すなら、ここの書き方
・ＰＯＳＴ型のときは、ここの書き方
みたいなかんじで呼び出せば、あとは、画面の引数を、どっかファイルなり、Excelなりに入れておけばいい。
（表示内容を受け取ったら、どうするかもプログラムしておかないと、もちろんいけないけど）


そこまでは、わかっているんだけど、
で、こんなの、つくりはじめちゃえば簡単なのもわかってるんだけど。。。
実際テストする場面になると、


　　　そういうプログラムを書くより、直接画面からテストしたほうがはやそう。。

　　　フリーソフト見つけるにしても、たいへんそうだし。。。

　　　きっと、フリーソフト書くより、プログラム作ったほうが、はやくて、

　　　プログラムつくるより、画面から入力したほうが早いよな。。。

　　　だって、ツール作ったら、そのツールもテストしないといけないぜ！



とおもって、いつも、画面からテストしてしまうので。。。
そういうツールは、つくらずじまい。。。

そんなこんなで、画面からのテストになってしまう。

ひまなとき、つくっておけばいいんだよな（＾＾；）

でも、いま、ひまがない（＞＿＜）！

標準化のやりやすいもの、やりにくいものと、オブジェクト指向

　昨日のブログで

類似業務の標準化されたものや、部分部分の標準化手法を使うことになる。

って書いたけど、これ、標準化されたものを使いたい場合、標準化されたものがないと、使えませんよね。

　ところで、標準化っていっても、さまざまなレベルのものがあります。

（１）フォームや（帳票などの）フォーマットの標準化
　→統一伝票など、（２次元）バーコードの白と黒の塗り方など

（２）コード体系の標準化
　→ＪＡＮコードなど

（３）データ、ＤＢの標準化
　→商品マスタの標準化など・・・あまりないよね

（４）業務プロセスの標準化

　下にいくほど、むずかしい。なぜなら、自由がへらされるから。
　（１）は、自由がへるといっても、これも自由にすると、無秩序になってしまう。
　なので、（１）を決めるのに、文句を言う人はすくない。一方、（４）は、やり方なので、そんなの自由にやらせろよ！ということになる。

　でも、実は、（１）をきめていくと、（２）も、きめないとまずいよねとなり、（１）と（２）がきまると自動的に（３）もきまってきてしまい、そこまでの外堀をうめると、（４）も、決めやすかったりします。

---

　さて、「業務プロセスの標準化」は難しいと書きました。

　で、オブジェクト指向の場合って、標準化を利用するとすると、「この業務プロセスの標準化」の利用ですよね。フォームの、統一伝票を利用するといわれても（＾＾；）どう、利用していいのか？となる。
（ＤＦＤなら、統一伝票に書かれている項目をもとに帳票分析して、エンティティだして、ＤＢつくれるけど）
　
　で、それは、むずかしいのですよ、モデルをつくって、そいつを標準化するというのは。。なんで、オブジェクト指向で利用できる業務の標準化っていうのは、。。。どーなのどーなのっていう感じがある。

　それなら、むしろオブジェクト指向を使わないで、部分部分の標準化の成果をつなぎ合わせたほうが、プロセスが見えてくる気がします。

要求仕様がなかなか出てこなかったり、業務分析できない場合の仕様のまとめ方

　昨日の話のつづきです。

結局、昨日の話はまとめると、システム開発する際に、要求仕様をまとめるけど、その場合、２通りのケースがあり、

・１つは、ユーザーが業務についていえるとき
　→この場合は、ＵＭＬで業務分析できる

・もうひとつは、業務が言い表せなかったり、そもそも、新規事業で、業務がわからないとき
　→この場合、業務がわからないから、それをもとにして図を作成するＵＭＬでつくるのは難しい

っていう話でした。

　で、このとき、一言加えておくと、よく、下のケースでは（ユーザーが業務がわからないとき）「業務について（あるいは、要求について）、あとで出てきます」といわれてしまうことがある。

　この場合、注意してね！これ、出てこないから。。。

　で、どうしょーもなくなって、ぎりぎりになって、えいや！と適当なものが出てきて、それを開発しすると。。。つじつま合わないとか、ぜんぜん違うなんていうケースになる。

　なのに、ユーザーさんなり、だれかから、「仕様はあとで出てくるみたいです」っていわれると、ずーーーと待ってしまって、作業がとまり、結局あとで、時間が足りない！とか言い出す人っているのよねえ。

---

　で、じゃあ、こういうふうに、新規なものとか、業務がわかんないものの、業務フローを出す方法だけど、その方法の１つとして、昨日、
（１）モノの流れをおさえる
（２）次にカネの流れをおさえる（カネが関係ない場合は、省略）
（３）で、モノとカネだけで、情報の流れ（必要データ）を確定してしまう

と、モノとカネの流れから、業務を推測して出すということを書いた。

で、これですめばいいんだけど、それだと、わかんない場合もある。
で、そういう場合は、類似業務、あるいは部分的業務の標準化を利用して、もってくることになる。

　たとえば、ホリエモンの「放送とＩＴの融合」を例にとると、たぶん、その場合、テレビの動画配信ということになるでしょう。
　で、見た動画のお金を回収するのに、広告収入からとるなら、今のテレビ業界の広告業務を利用することになるし、個人個人に集金するということになれば、ネットでの標準的な集金方法ということになる。

　ネットでの基本的な集金方法っていうのは、やり方が決まってて（集金代行を利用する場合だけど）
・銀行振り込み
・口座引き落とし
・郵便振替（電信／一般）
・クレジットカード
・コンビニ決済
・代引き
とあり、それぞれの業務フローは、だいたい決まっている（決済代行会社のいうようにやると、決まってしまう）。それを利用することになる。

　こんなふうに、わかんないところは、類似業務の標準化されたものや、部分部分の標準化手法を使うことになる。
　通販サイトにおける、ショッピングカート、ショッピングカートから代金集金、さらにキャンセルの流れ、なんていうのは、もう、固まった手法があるので、こういうものに関しては、ユーザーがわかってなかったら、すぐに、こっちから、提案しちゃったほうが、いいよね。ユーザーの夢をきいてると、妄想におわり、いつまでたっても開発できない。はい。

　小売だと、統一伝票を使う場合。あの伝票をつかうと、もう、業務の流れが決まってしまう。ベンチャーで、業務がわかってなかったら、こっちから統一伝票の枠にはめてしまうっていう手もある（統一伝票自体は使わなくても）。

---

　で、そうやって、業務フローをつくるとき、どこまで細かくやるかっていうことなんだけど、デザインパターンレベルにまで落としてしまうとやりすぎ。
　９０年代前半は、マッチングとか、リスティングとか、マージとか、ある程度、事務処理の基本的なパターン（ビジネスパターンとでも呼びましょうか）があって、そこの部分のプログラムは、もう枯れていたのが、会社にあったり、ユーティリティとして用意されていたので、そのレベルにまで落とせばよかったわけ。

　でも、いま、そんなパターンなんて、習わないでしょ！

　事実、このまえ、理工系の、情報系の、国立大学卒業の、経験２、３年の、さらに卒論がオブジェクト指向関連をやってる人が、Javaで、マージプログラムをどう書くのかというのを、ほかの人に聞いているところを目撃したもん！
（ちなみに、ハッシュマップで書きます。
HashMap mst; //マスター
HashMap trn; // トランザクション

// trnのキーが、mstに、なければデータ追加、あれば上書きする（＝マージ）

String[] keylist = (HashMap)trn.keySet().toArray(new String[0]);
for(int i = 0 ; i <keylist.length ; i ++) mst.put(keylist[i],trn.get(keylist[i]) );
}
でできます）
つーことは、大学でも、会社でも、マージなんていうのを、おしえないのだよ、きっと（ちなみに、聞かれたやつも、こたえられなかったみたいだから）。

ということで、そーなってしまうと、いったい業務は、どこまで細かくすればいいの。。。という歯止めがわかんないわけなんだな、これが(^^;)
　言い換えると、どこまで細かくしたら、プログラム可能か、見えない。

　ということで、こういう場合は、とにかく、思いついたら、頭から組んでいくしかない。手がとまったら、そこをさらに、詳細化するというかんじで。。。
　。。。こんなんで、いいんかい？？

　。。。いいんだろうな、きっと。

---

ぎえー、昨日のブログのまだ答えにたどり着いてないけど、今日も、お仕事しないといけないので、このへんで、続きは、覚えていたら、書きます。

システム開発の要求仕様の出し方には、大きく２通りあって、UMLは、一方は有力だが他方は無理がある

　昨日の話のつづき

　システムを作り上げるときは、２つの方法があるんだけど

の２つの方法とは？について

---

　この２つというのは、要求仕様を出すときの問題なんだけど、

　１つは、UMLなどで、前提となっている、ユーザーからヒアリングをして、業務を分析する方法。
　いわゆるシステム分析手法というものが使える場合。

　この場合は、ヒト・モノ・カネを分析対象にできる。
　そこで、UMLが使える。担当するヒトやシステムをアクターとして、業務内容をユースケースないしは、アクティビティ図におとす。
　さらに、要求がまとまったら、クラスにおとしていくことができる。

---

　もうひとつは、ベンチャーのような新規事業開発で多いんだけど、業務の手順すら、まったくわかんない場合。たとえば、ホリエモンが、「放送とITの融合」っていったけど、なにをやるか、どうやるか、さっぱりわかんない。
　この状態で仕事が来た場合。

　この状態の場合、ユーザーは、いろいろケチ、注文をつけるんだけど、まったくやり方は、出てこない。で、このやり方を待っていると、たいてい、いつまでたっても出てこない。なので、SE側で、業務からシステムから、一切合財をまとめないといけないケース。

　たぶん、みかままさんの書いている、テスト設計の方針は千差万別の”JaSST'05版「クイズ100人に聞きました」”システムが、はっきりしないけど、これっぽい例かも。。。つまり、なにを、どうしたらいいの？というのは、さっぱり決まっていない。ここで、仕様を待つと、地獄がくる。

　だって、だれも、見たこともないもん、どーやって、仕様をきったらいいか、本当のところ、だれもわかんないもん。

　ということで、こういう開発の場合は、SEが業務フローをつくり（上記の場合は、業務ではないので、業務フローはないけど）、仕様をつくり、プロトタイプを見せて（業務の場合は、業務フローをまずみせて）ユーザに、いいたいことを言わせないといけない。

　あ、ちなみに、この場合、＠ITのコメント、

要求や仕様のあいまいさをなくすための、レビューやウォークスルーのような静的なテストも大切です。

を、真に受けてやると、たいへんな事態におちいり、開発は失敗します。

　だって、みんなみたことないもの、要求なんて、わかるわけないし、仕様もわかるわけないじゃん！だれかが作って見なけりゃ・・
　なんで、創造が創造をよび、空想的仕様で、ありえないような仕様に発散する危険性大です。

　作る「前」にレビューやウォークスルーをするのは、前者のようなシステム開発（業務分析可能な場合）で、後者の場合は、プロトタイプを作った「後」にします（＝つまり、みかままさんの態度はただしい。だれか、はやく、いってあげればいいのに。。こーいう場合は、仕様は、出る出るっていってるけど、口だけだよ！って）

---

　で、こういう後者のような場合、どうやってプロトをつくるか？
　　というか、それ以前に
　業務のフローをつくっていくか？っていうことなんだけど、

これが、昔のブログで書いたはなしで、こんなかんじっすね。

（１）モノの流れをおさえる
　　　（モノをあげて、それのCRUDをおっていくいと、流れがでてくる。
（２）次にカネの流れをおさえる（カネが関係ない場合は、省略）
（３）で、モノとカネだけで、情報の流れ（必要データ）を確定してしまう
　　→ここで、その情報を流すためのプロセスを考えて、DFDにもっていって、さらにERを作ってしまう

っていう、データ中心指向に持っていってしまう方法なわけ。

　DFDまでもってくれば、あとは、そのまま開発してもいいし、DFDからユースケースにもっていって、オブジェクト指向にしてもいいし。。。

　つまりね、ヒトを登場させないわけよ。

　ホリエモンみればわかるでしょ！従業員のことなんて、出てこないでしょ。買収するときに。。。
　基本的に、ビジネスを組み立ててる、えらーーい、かたがたは、従業員なんて、どーでもいい話なのよ。っていうことで、まず、サービスの流れと、それで、どうカネを回収するかという部分から押していくことになる。

　なんで、アクターがでてきたり、スイムレーンに分けてかくような、UMLくんは、使いにくいのよ。お偉いさんたちのビジネス構築にはね。ヒト、従業員の分担は、でてこないから（そういうのは、下々管理職のしごとと思っているんだろーな）

　で、プロトにもっていくか、業務フローと、システム概要をだして、ユーザーとのウォークスルーやレビューにもっていくわけ。

---

　う、まだ昨日の答えに行き着いてないけど、ここで、お仕事しないとまずそうなんで、いったんここで、きって、続きは覚えていたら、またいつか書くぞ！

稚北大は、ＳＥを否定し、佐賀大はＳＥを育成するのね！？

　昔、このブログで

ＳＥという存在が業界から省略される（この状況に関しては、稚北大学の宣伝の例をあげて、別のブログで、「じっくりと！！！」話をさせていただきます！！）

　と書いておきながら、この説明をしていなかったので、今日、その話をするとともに、佐賀大が、稚北と一見逆に見えるとりくみをしてるので、その紹介。

---

稚内北星学園大学・東京サテライト校の「システム開発演習」の宣伝？なのかなあ？
という記事があります。詳しくは、ここ

　で、この記事では、
「ITエンジニアの2層構造」が、実はさまざまな問題をはらんでいる。
といっている。
２層とは、プロジェクトマネージャーと、プログラマの２層をさしている。
つまり、ＳＥという存在がなくなっているんだね。

　で、この講座では、今までＳＥがやってたような、要件からプログラムへの落とし込みの演習をやってるみたい。

　つーことで、稚北さんは、プロジェクトマネージャーやプログラマーがＳＥの仕事を引き受けていく＝ＳＥはなくなるってこと？と考えているみたい。

---

　で、次。。。

　情報処理（おおきいほう、論文誌じゃ「ない」ほう）の２００５年７月号、８４４ページ（情報処理を読んでない人へ。ぺーじ番号は１年間とおして振られるので、こんなに大きな数字になっている。７月号が、電話帳並みに分厚いわけではない）からの「佐賀のＩＴ戦略は教育から」の記事をみると、佐賀大は、「スーパーＳＥセミナー」をやっています。

　で、このカリキュラム（８４５ページ）をみると、ＳＥの知識に加え、（２番目のしかくのソフトウエア設計技術）、プログラマの知識と、マネージメントの知識を教えてますよね。

　つまり、佐賀大の方向は、ＳＥが、プログラマとマネージャーの内容をやるというかんじ＝ＳＥはなくならない？と考えてるみたい。

---

　おお、北と南で意見が分かれたぞ！ＳＥは、なくなるのか、なくならないのか！

　うーんと、きっと、静岡とか愛知あたりで、きりかわるんですよ！

　って、電気の周波数じゃないんだから（＾＾；）

　でも、実は、２つとも、旧来のＳＥ業務のカリキュラムが、まったくなさそうに見えるので、どちらの学校も、昔のＳＥ業務は、完全に抹殺していると考えていいのかもしれない。そういう意味では、差がないといえると思う。

　で、本当に抹殺していいんかい
　っていうより、その旧来のＳＥ業務の内容はなに？っていうことだよね。

　前のブログでも、「稚北の話をする！」と２箇所に書いていて、
　１箇所目は、

「なぜ、業務の標準化や、新規ビジネスを創出できないように、業界が進んでいるといえるのか？」と、思われるであろう。
　これを説明するのに、稚北大学の宣伝文を引用しようとおもった。

　と書いていて、２箇所目（さっきのところ）は、

９０年代前半で、システムをビジネスパターンに分けることによって、枯れたプログラムをつなぎ合わせる手法が、ＳＥという存在が業界から省略される（この状況に関しては、稚北大学の宣伝の例をあげて、別のブログで、「じっくりと！！！」話をさせていただきます！！）ことによって、なくなってきた

と書いている。今日のブログは、その答えになっていない。

　実は、コンピューターに限らず、システムを作り上げるときは、２つの方法があるんだけど、そのうち、稚北大、佐賀大のどちらの手法も、１通りの方法しか教えていない（というか、いまの業界トレンドはそっちの方向）。で、昔教わったＳＥ教育というのは、２とおりのどちらでもできるように教わる。

　つまり、もう一方のほうのやり方は、どちらの大学でも、教えないというか、業界的に抹殺されようとしているんだろう。で、その一方のやり方を教えないということが、前のブログの答えになる仕組みになっている。

　そんな話、覚えていたら、書きますね。
　（また、わすれちゃうかも。。。期待しないでね！）

結局ＳＱＬインジェクション対策は、設計・修正をどうすべきなのか（チェックではじくには無理な気が）

　昨日のＳＱＬインジェクションの話、結局、どういうふうに設計すべき、修正すべきとウィリアムのいたずらの方針を書いていなかったんで、わたしは、こう考える！というのを、書いておきます。

　入力データで、入力チェックをしたとしても、ＳＱＬインジェクションをはじくには、アポストロフィーをはじいてしまうか、これをエスケープするしかない。
　でも、アポストロフィーをはじいていいのか？という問題がある。

　たとえば、ログイン名に、メリーチョコレートだいすき！な人がいて、mary'sにしちゃったら？とか。。。
　また、ＳＱＬインジェクションとして、不正アクセスであれば、ログイン名だけの話だけど、それ以外で行うことも考えると（検索でＳＱＬインジェクションをやって、大量の検索をさせて、システムをとまらせる）、本の名前の検索などでは、アポストロフィーが入ることはある。

　=でチェックを書けた場合？でも、たしか、モーニング娘。の本になかったっけ？自信ない。

　（あ、ぜんぜん関係ないけど、さっき、地震あったねえ、いま、自信ないと打って気付いた）

　なんで、入力ではじくというのは無理がある。
　ということで、入力チェックで、このＳＱＬインジェクションをやるのは、きつい。

　じゃあ、入力の時点で、エスケープしちゃったら？っていうことになるけど、そうすると、こんど、mary'sは、mary\'sになって、文字数が変わってしまう。文字数によって、なにか処理を分けているとかいう場合、後段の処理で問題。

　っていうことで、結果として、
・入力チェックは、ＳＱＬインジェクションとかを意識せず、適切に行う
・処理中の内部データはエスケープしないで、文字をそのまま処理する
・ＤＢアクセスのところで、エスケープの変換をかけ、ＳＱＬインジェクションをはじく
　→結果として、ここではずく＝サニタイズしてるのとおなじ。

---

　で、ＤＢアクセスのところで、エスケープするのっていうのは、至極あたりまえの話だと思う。
　
　ふつう、入出力のところは、その入出力デバイスにあった形で文字などの情報が変換されるはず。で、その入出力データを他のモジュールが利用するときは、内部表現に変換しておくる。

　エスケープというのは、いわば、ＤＢ用のために文字を変えるものなので、入出力モジュールであるＤＢアクセスのところで、エスケープをいれる。それ以前は、内部表現として、エスケープしない、ふつうの文字の形で扱う。

　これって、あたりまえの話っすよねえ。

---

　と考えると、設計・修正は、こんなところに落ち着くんじゃないだろうか。

　設計は、ＤＢアクセスを共通化し、そのＤＢアクセスの中で、エスケープする。

　修正するときも、ＤＢアクセス部分に対して、エスケープ処理をいれる。
　ＤＢアクセス部分が、モジュール化（別クラス化）されていなければ、時間があれば、モジュール化する。

　つまり、Ｏ／Ｒマッピングとか世間で入ってるけど、ＲＤＢアクセスだけでなく、入出力部分には、そもそも、インピーダンスミスマッチがあるんだから、その入出力部分をモジュール（クラス）として独立させ、それぞれ、利用可能な形に変換して（＝エスケープなどを送って）対応するべきであると思う。

　そうすると、ＳＱＬインジェクションは、はじけるので、べつに、入力のところで、エラーチェックをするかどうかというのは、（したほうがいいけど）今回の話にあまり関係するところでは、ないかと思う。逆に入力のところでエスケープすると、エスケープした形が内部コード表現となるので、あとの処理がそれに影響されてしまい、得策ではないと思う。

てなことを考えてます。

「サニタイズ言うなキャンペーン」と、同値分析と、開発におけるコストと「業界してるう」

みかままさんの日記をみていて、知ったニュース

セキュアなWebアプリ実現のために本来やるべきことは? - 高木浩光氏

　の下のほうにある、「事後的な「サニタイズ」ではなく、最初からきちんと動作するプログラム作りが必要」

　で出てくる

「現在『サニタイズって言うな』キャンペーンを行っているところ」


っていう話。まあ、だれが、どんなキャンペーンを行うのもOKなんで、これ自体、別にいいんですけど、


「セキュリティ以前にきちんと(本来処理されるべき)記号のエスケープ化などを行っていないということだし、すなわち本来入力されうる文字列を処理できなくなるということでもある」


　に関して、ちょっち、気になるので、つっこみ。

　これ、SQLインジェクションが起きた後になってからは、いえることなんだけど、今問題になっているのは、SQLインジェクションの問題が言われる「前」に開発したシステムに関してですよね。

　その時点では、SQLインジェクションの問題は起きていなかった。

　そうすると、ですよ、ログイン名のところに、itazura' OR 'a'='a という文字列
（こういう文字列を入れてSQLインジェクションを起こす）を入れるケースって、
まず考えられないですよね！

　その状況で、SEやテスター（テストエンジニア）が、この文字列だけを、同値分析のときに、同値でないとはじけるかどうかっていうのが、この議論の中心ですよね（もし、同値だと思ってしまえば、これがテストケースになる可能性は、天文学的に低くなり、SQLインジェクションの問題が言われる「前」に開発したシステムにおいては、事前にテストや設計ではじくことは、酷ということになる）。

　これ、知ってないと、はじけないと思います。

　同値分析でここまで気が回るのは、たぶん、エスケープしないといけない文字をしっていて、そのエスケープの関係で、同値でないとしている人だけだと思います。

　で、今度、逆に、入り口でエスケープしてしまうと、DBアクセスの共通部分では、エスケープできないっていうことになりますよね（両方エスケープしたら、２重にエスケープしてしまう）。

　そうするとですねえ、
共通部分でできない
　＝みーんなちゃんとやってね！ということになり、
　＝開発にかかわるすべての人が、SQLインジェクションに対しての知識と、文字列のエスケープの知識を持っていて、全員が、そのコーディング方法を守んないといけない。で、このような周知徹底をPMがやんなきゃいけない。

　これは、PMに対して、酷というものです。
　
　それより、そのようなSQLインジェクションの知識を隠蔽化し、共通部分で、サニタイズをかけ、入力チェック側では、通常のチェックをして、エスケープを「しない」でもらったほうが、開発（修正）コストは安く済むと思うし、そっちのほうが、現実的だという気もしなくもない。

　なんで、そんなことは、共通部分の開発がやってあげればいいような気がするんだけど。。。


　でも、えらーい人が講演して、「サニタイズって言うな」っていってるんだから、それにしたがわなきゃいけない雰囲気になるんでしょうな、きっと。

　そして会社は、莫大な修正コストをかけて、多分死ぬほど大変な思いをPMがして、周知徹底させ、できっこないから、PMが、死ぬほど怒られ、悩み傷つき病気になると。。

　　　　　　うーん、業界してるう！！

UML1.XとUML2.0で書く図の種類と、ちがい

UML1.Xで書く図について、まとまっているものとして、前に、このサイトをメモしたけど、今日は、UML2.0で書く図について
（ただ、上記のサイトって、パッケージ図が抜けてる気がするっていうか、もう、そんだけあると、なにがなんだか ^^;)

　で、UML2.0になると、こんなかんじというふうに、図の名前と書き方が書いてあるのが、ここ

　で、そんなこんなを、浅海さんが、説明してくれているのが、ここ