ajaxのサンプルプログラムを動かすとき、超基本的な、忘れてならないこと！

　わけあって、ajaxをはじめようと思った。
　で、このサイトにいって、「WebDesigning掲載サンプル（サーバーからデータを読み込み表示するだけの簡単なサンプル）」を実行しようと思った。

はじめにやった手順は、以下のとおり

■■　失敗した手順
１．IEなので、ここの２つめのサンプル（灰色になってる部分の＜html＞から＜/html＞のすべて）をコピーし、test.htmという名前で保存
２．そこにsample.txtというテキストファイルをつくり、テキトーに文字を入れる
３．IEから１のtest.htmをひらく。

＊＊結果
　たしかにtest.htmはみえるが、そこをクリックしてもsample.txtは、開かん。。。

---

これが、正しい
■■　成功した手順
１．IEなので、ここの２つめのサンプル（灰色になってる部分の＜html＞から＜/html＞のすべて）をコピーし、test.htmという名前でApacheのhtdocsフォルダの下に保存
２．そこにsample.txtというテキストファイルをつくり、テキトーに文字を入れる
３．Apacheを起動する
４．IEから、http://127.0.0.1/test.htmを閲覧する

---

■■　　超基本的な、忘れてならないこと！

　どうも、サーバーのところにおいて、サーバーを起動して、それを閲覧するみたい。

ユーザーにとって、ＲＤＢのテーブルってExcelのシートなんだよね。だから問題。

　ユーザーにとって、表というと表計算ソフト、Excelの表を思い出すと思う。
　なんで、ＲＤＢのテーブルと、Excelのシートって、だいたい同じイメージになってしまう。つーか、ユーザーでなくても、そうだ（開発の人でもそういう人がいる）

　でも、この２つには、決定的なちがいがある。
　Excelは、セルの結合ができる。
　ＲＤＢは、セルの結合が出来ない。
　セルの結合のように、２レコード以上で、同じ値をとる場合は、２つのテーブルにわける。正規化の処理の一部で行う。

　この問題は、聞いていると思う。でも、もう一歩突っ込んだ話。
　つまり、ユーザーにとって、レコードの最小単位っていうのは、自分が、最小単位だと思ったのが、最小単位なのよ。それより細かく分割できても、セルを結合して、まわりに線をひいてしまえば、いいし。。。

---

　っていうことで、問題がある。

　ヒアリングをするとき、ユーザーは、レコードの説明を、「自分が、最小単位だと思っている」ものを、最小単位として説明する。
　したがって、ユーザーのヒアリングをもとに、名詞項目を抽出し、（ＥＲ図を作るのをサボって、かつ正規化の作業をはしょって、すぐに）テーブルにしてしまうと。。。
　コーディングのときに。。。
　おやおや、このレコードのあるところのステータス、２つの値をとることがないか(@_@!)

　ってなことになり、テーブル設計しなおしになる。

　でも、ユーザーは、気づかない

---

　例を挙げよう

　受注のとき、
　　りんご１００個
　　みかん９０個
　という受注をうけたとする。

　自社倉庫は、東京と大阪にある。

　このとき、東京倉庫に、りんご１５０個、みかん５０個、大阪倉庫に、みかん５０個あったとする。そうすると、大阪倉庫から東京倉庫にみかん４０個を送ってもらい（これを、倉庫間移動という）、それがついたとき、この受注の出荷をする。

　そうすると、みかん９０個のステータスは、２つに分かれて、
　　　みかん　　東京倉庫分　　　５０個　　引当済み
　　　みかん　　大阪倉庫分　　　４０個　　倉庫間移動中
　と、２レコードにわかれないと、ステータス管理できない。

　ところが、Excelの人にそんな概念はない。受注明細の２行分の商品名を連結して、１行にして、そこに「みかん」と書き、上の行に５０個、下の行に４０個と書いてしまう。

　受注明細をさらに分けるという概念はない。

　そのため、その後のヒアリングに矛盾がでてくることがある。

---

　ってことを、ユーザーからの話のなかで出てきたのならいいんだけど、

　あるプロジェクトマネージャーさんが、どうも気づいてないようだったので、気になって書いてみた。

マスタメンテプログラムの自動生成方法の例と標準化

　ちょっと、いちゃもん、揚げ足取りじみてるかもしれないけど、気になった言葉。。
「PM見習いの読書日記」さんのブログで、


たとえばマスタメンテナンスみたいな画面づくりが続いたら、開発してる人は楽しくないと感じるのかな？



　ちょっと待った！マスタメンテって、もしかして、手作業でプログラム作ってる？？

　マスタメンテって、自動的にプログラムで作る（よねえ。。ちょっと不安になった）。そのため、自動生成するんで、ＤＢのテーブル構造を、標準化したドキュメントに記述する。

　だから、標準化が必要なんじゃあなくって(@_@)!。

　この自動化プログラムがなければ、テストファーストとか言われても、マスタメンテ作って、テストデータつくるよりも仕様変更のほうが早いから（最近の仕様変更は、まさに、朝令朝改だ！）、事実上出来ない。

　こういう自動化テクニックと標準化が出来てるからこそ、ＴＤＤができると思ってたけど。。これがなくって、標準化してくれなきゃ、プログラマさん、ＮＨＫにはいっちゃうよ！（ＮＨＫは、日本放送協会ではない）

　あ、マスタメンテ「みたいな」か。。。でも、それも、マスタメンテの自動化を応用できると思うけど。。。

---

　念のための意識あわせ。

　マスタメンテの自動生成（これ以外にもあると思うし、現場は、もっともっと、進化系を使ってると思うけど、ちょー単純にした話）の例：

（１）１テーブル１シートにして、そのシートに、テーブル名を書きましょう
　　　で、テーブルの項目、型、桁数などを書くようにする
　　　これは、標準化しておく。そうしないと、自動生成プログラムがたいへんだよ！

　　　名前は、英字のものも用意しておいてね！英字のほうを使うから。

---

（２）自動生成プログラムはwebでつくるのがかんたんっす。
　　　っていうことで、Webでつくることを前提にする。

　　　で、マスタプログラム画面は、各テーブルごとに用意する。
　　　関連したテーブルを直したいときは、Viewっていうことにするのね。
　　　で、Viewの更新の場合、ちょっと工夫（実は標準フォーマット側にも）が必要。
　　　
　　　各テーブルに対して、以下の画面が必要になる
　　　　・検索（はじめの初期表示）画面
　　　　・一覧画面＝ここで、削除、更新、追加を指示
　　　　・明細画面＝更新、追加のときに、項目を修正、入力する画面

　　　で、サーバー側のＣＧＩ（じゃなくてもActionでも、おんなじだけど）は
　　　　・検索画面から、テーブルと検索条件を受け取って、一覧を出すＣＧＩ
　　　　・一覧から明細画面を出すＣＧＩ
　　　　・明細画面かた更新するＣＧＩ

　　　ＣＧＩ側は、コントローラと、ＤＢアクセス部分にわかれ、

　　　ＤＢアクセス部分は、検索・更新・削除・追加用のクラスを自動生成する。

　　　なお、このクラスの値の引渡し方法（ＶＯ）を、どのように汎用的につくるかは
　　　いろいろなテクニックがあるが、省略
　　　ただ、getter,setterを使うんなら、setterで、セットされたら、フラグをあげる
　　　ようにして、各テーブルごとに項目、そのフラグ、getter,setterを自動生成して
　　　それをＶＯクラスにすれば、なんのテクニックも使わないでできる。
　　　（フラグを使わないのにテクニックがいる）

---

（３）それぞれの自動生成を行うためのプログラムをつくる　
・検索（はじめの初期表示）画面
　検索項目を選択し、値を設定すると、検索条件ＳＱＬとテーブル名を引数としてＣＧＩを呼び出すＨＴＭＬのＦＯＲＭ画面を自動生成する。

・一覧画面＝ここで、削除、更新、追加を指示
　受け取った項目をリスト形式で表示し、削除、更新、追加ボタンを作成し、そのボタンが押されたら、選択箇所のメインキーと、押されたボタン名を引数としてＣＧＩを呼び出すＨＴＭＬのＦＯＲＭ画面を自動生成する。

・明細画面＝更新、追加のときに、項目を修正、入力する画面
　受け取った値を画面に表示し（追加の時には、この値がない状態で受け取る）、実行ボタンをつけて、実行ボタンを押されたら、各項目と入力値を返すようにする（更新か追加かは、セッションでわかるようにしておく）

・ＤＢアクセス部分
　マスタメンテを作る前に、すでに、ＤＢアクセス自動生成プログラムで出来ているとする。そのつくりかたは。。。いいよねえ、わざわざ、説明しなくて(^^;)

・検索画面から、テーブルと検索条件を受け取って、一覧を出すＣＧＩ
　受け取った条件とテーブル名をもとに検索用のＤＢアクセスプログラムを呼び出し、その結果を、一覧用に返す。

・一覧から明細画面を出すＣＧＩ
　削除の場合は、そのデータを削除する
　追加の場合は、セッションに追加だよ！と設定し（実際は、フラグに値を設定するが）
　　　明細用に値をクリアして返す
　編集の場合は、セッションに編集だよ！と設定し
　　　ＤＢアクセス用プログラムに、
　　　　　引数として渡された選択された箇所のメインキー値をいれて、
　　　　　ＤＢを検索し
　　　明細用の値に、検索結果をいれるようにして返す
　

・明細画面から更新するＣＧＩ
　チェックしたければ、引数チェック
　で、セッションにはいっている、追加か、編集かをみて、インサートかアップデートのＤＢアクセス関数を呼び出す。

---

（４）このやり方だと、複数関連テーブルの一括修正・登録ができない。

　で、その場合は、ＶＩＥＷを使うんだが、そうすると、更新部分で、ちょっとした工夫がいる。その工夫は。。。。あんまりにも長くなるので省略。

---

　マスタメンテ「みたいな」画面のときは、上記の「初期画面」ー「一覧」ー「明細」の枠組みに落とし込み、ＤＢアクセス部分をモデルにかえて、実行できるようにすると、自動化の枠組みに、はまるよ！

---

　でも、これ手作業でつくったら、ウィリアムのいたずらなんかが関係するシステムだと、テーブルだけで、５０も、いや、もっともっとあるから、それだけで、まあ１万ステップ、いやもっともっとだなあ。。。をコーディングしなくちゃならないわけで。。。

　つーか、これもってないで、テストファーストとか、ＰＭにいわれたら、「そんなご無体な」っていう感じだよねえ。。。

　ぜったい、そのＰＭさんって、いじめっ子だったとおもうよ。

　きっと、プログラマさんたちは、ＮＨＫに、はいってしまうにちがいない！(って、日本放送協会じゃないよ！くどいって！）

　だって、こんなの手作業で作ってたら、テストプログラム作ってる間に、テーブル構造変わって、やり直しになっちゃうよ（いやまじで。１日で構造が変わることもあるしさあ）！

　「まいにちまいにち、ぼくらはＰＭの、仕様変更でいやになっちゃうよ！」

っていわれて、「およげたいやきくん」のように、とびだされちゃうよ（ふる！）

状態遷移の説明で注意したい点

さっき、ある会議に出ていて気づいた。
　状態遷移を説明するとき、その状態についての説明は、そんなにしてくれなくてもいい。
　問題は、遷移するときの条件が大事。

　たとえば、ＵＭＬなんかだと、状態遷移は、ステートチャート図で表現するけど、その場合、ガード条件が、どうなるのかが、知りたい。
　あと、アクションやイベントを書くんだけど、このアクションやイベントを、抽象的に書くと、わけわかんない。
　ＵＭＬを使わない、状態遷移図や、状態遷移表のときは要注意！この条件を明示しないと、どのタイミングで遷移するか、わかんなくなっちゃうよ！！

　たとえば、イベントが、商品引当のとき、商品の在庫ステータスを、フリー在庫から、引当済みにするというとき、フリー在庫から、引当済みになる「条件」が一番知りたい（多分在庫数＞予約数。でも、こんな簡単じゃないはず。倉庫間移動を行い、複数倉庫の在庫をひとつにまとめて引き当てるときがあるから）。
　このとき、フリー在庫とは何かとか、引当済みとは何かの説明をいくら厳密に言われても、条件がわからないと、コーディングに入れない。また、商品引当というくらい、具体的ならいいんだけど、「予約」とか、けっこう幅広い範囲だと、「具体的に、どこでやるの？」ということになる。

　当たり前の気がしてたけど、ちょっと、そうでもないみたいなんで、書いてみました。
　

データの整合性をとるための手法と、その手法が効力を発揮しない、からくり

前のブログで、

「ＥＲも入れさせて、全体データの整合性の確認をとらせたりする（その成果を、標準化された枠組みの中で、どうクラスに反映させるかが、ＰＭの腕の見せ所になる。そのためには、クラスとＥＲの関連を読みきれないと、まずだめだけど）。」


　と書きましたが、現実的には、この全体データとの整合性を取らせる方法として、実務的には、
・データベースの担当者をつくる
・データベースにテーブル、項目変更（追加、修正、削除）をする場合には、申請をする
・データベース担当者は、申請内容を確認し、良かったら追加し、そして、関連部署にしらせる
という手法をとって全体データとの整合性を取らせていると思います。

　なので、この場合、データベース担当者に期待されていることは、
・データベースの全体を把握し、一貫性、共有性、独立性のもったデータ構造にすること。データ構造に矛盾が出た場合、すでに、データが存在している（演算すれば出てくるような場合）は、追加、修正していいかどうか、判断する
・データの変更を、確実に関係者に伝えること

　なんですけど、はじめの、データ構造のチェックまでっていうのを、やってくれていると期待すると、「軽くヤバイ」（いや、けっこうヤバイ）かも！
　この仕組みは、実は、効力を発揮しないで、単なるお役所仕事になっていることが多い。

---

　こういう手順をきめると（まあ、開発プロセスの標準化の話なんかもそうだけど）、その手順を守れば、いいんでしょ！やってくれるんでしょ！っていうことになってしまうケースって、結構あるんだよね。

　で、そういう人に限って、この作業は無駄だ！とかいいだす。

　たとえば、データベースの項目修正なんかも、全体をみて、全体最適をチェックするためという目的を見失ってしまったら、おっしゃるとおり、申請して直すのは、むだっす。
　各自めいめいに直したほうが早い。でも、それじゃ、全体最適ができないでしょ。

　あと、構成管理なんかの申請も、ＣＶＳ使えばいいじゃん！っていいだされてしまう。
　あれは、構成管理申請と、関係者への通達と、ソース変更のタイミングと、開発スケジュールと、テスト用バージョンのすべてをあわせるために必要なんだけどね。。。（逆にこれらのすべてをあわせる必要がないか、すべてがネットワークでつながり、同時にできるのであれば、構成管理を申請形式にするのではなく、ＣＶＳの採用もありえる）

---

　ということで、結果としてなんだけど、

　標準化を過度に信じている人たち、過度に非難する人たちがいる場合は、標準化の意図と、それをしない場合の開発上の混乱がわかっていないケースが多い（お役所仕事的に、これをやればいいんでしょとか、あるいは、これをやれば、システムができると単純に考え、なぜやらないといけないのか、なにを管理するためにやっているのかを理解していない）。

　なんで、そういう場合、データの整合性まで考えて作業しているという、本来の仕事をやっているとは、考えないで、ＰＭが、やばい状態になってないか、チェックしたほうが安全。

　もちろん、そういう人が、開発メンバからはずせれば、はずせるに、越したことはない。やっぱ、リスク大きいからねえ。。。

２９日の「コピーされるほど儲かるシステム！開発日記」と、「かおる姫」効果

　６月２９日に、「コピーされるほど儲かるシステム！開発日記」第２０号を出しました。内容は、理論・実践編の２弾目で、前に書いたブログ番組＋宣伝だとＣＭ飛ばしされる。宣伝だけを見せたほうがいいかも（ＳＰＡのアフェリエイトの話） のまとめと、

最近のニュース、「ファイル交換ソフトの裁判の裁判において、ファイル交換ネットワーク側が敗訴」についてと、ひとこと、「かおる姫」は、アクセスアップキーワードっていうこと。

---

でもでもでも、本家では、アクセスアップしたのですが、ここでは、
　昨日のアクセスＩＰ数　　178 ip（かおる姫満載）
　月曜日のアクセスＩＰ数　195 ip（そうでもない）
うーん、アクセス下がってるじゃん（＞＿＜！）

　なんて書いたら、多分みなさまから、
「空気読めー、ここは、バレーボールの話するところじゃないだろー」
といわれそうだ。。。

　やっぱ、そうか。。


ということで、あとは決り文句。

---

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

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

あるシステム開発の場合、どの開発プロセス技法を使い、どういう方針で標準化するかのメモ

　システム開発の標準化の話題が多いんですけど、それを見ていると、このおはなしに行き着いているみたい。

開発プロセス標準化への道（1）
開発プロセスに対する幻想を破壊する

　やばやば。このお話の先の話をしないと、せっかく、かおる姫のすばらしさを書いても、ぜーんぜんつたわんないじゃないっすかあ！

　ということで、メモ程度に書きます。

---

　まず、今、学会に出ているような開発プロセス論は、そのまま使うと、現実の壁にブロックされてしまいます（後で、どんな感じか説明します）。
　なんで、実務上、開発する場合、それらをひねって使います。

　学会のいうように、ある開発プロセスをそのまま使って、ソフトウェアファクトリ（ソフトの自動生成工場をつくる）というのは、出来ないとは言わないけど、難しいと思います（たとえて言うなら、パワフルカナだけを使って、ブラジルに勝つようなもんだ。不可能ではないが、それには、爆発的なジャンプ力とアタック力が要る）。

---

　で、実際、ウィリアムのいたずらの場合、どうやって、なにを基準にひねるかというと、まず、ユーザーの要求と、利用しようとする技術等に対する情報の正確さから大きく分けている。

■■　ユーザーの要求が矛盾があったり、業務を表現できない、正しくいえない場合
　ユーザーの要求矛盾チェックをしないと、間違った方向に開発し、あとで結合テストのとき、結合しない！なんていうことになる。
　なんで、要求矛盾チェックなんだけど、これは、データを追っていくことによって、見つけるのが早い。なんで、構造化分析、とくにＤＯＡによって、ＥＲ図を描くとわかりやすい。
　ただし、ＤＯＡなどは、利用する技術が、ちゃんと仕様どおり動くことが前提になる。

■■　利用しようとする技術に不明箇所があったり、抜けがあったりする
　利用するクラスのJavadocが修正されていないで間違いだらけとか、ＢＲＥＷのように、マニュアルを信じてやるとえらい目にあう。マシンごとに動きが違うなどというとき。

　このときは、自分の目的とする動作を要求仕様として、その機能がちゃんと動くか、たしかめながら作るしかない。っていうことで、ＴＤＤ的な開発論になる。

　ただし、ＴＤＤを採用する場合は、要求に矛盾がない必要がある。
　矛盾があると、ＴＤＤだと、まず、仕様を満たす実装しかしないので、要求がおかしく、あとで、全体的見直しで、仕様大幅変更になると、作り直しの手間が大きくなってしまう。

---

　と、大きく分ければ、こんなかんじなんだけど、実際には、利用しようとする技術もはっきりわからないし、要求も矛盾だらけとなる。

　なんで、単純にＴＤＤをやったり、単純にＤＯＡをやってもできない。ある程度ＴＤＤをいれながら、仕様の全体像を加味するようなひねりとか、ＤＯＡっぽいんだけど、局所的に分割して、そのある部分は、プロトタイプでテストを先行させてつくるといったようなひねりがいる。

　で、具体的に、どうするかというと、実際に開発するときにサブシステムに分割するけど、その中で、ＴＤＤ的に開発したほうがいいものをわけ、その開発時期を確保し、さらに、ＤＯＡっぽく、全体のデータのデザインを明確化したほうがいいタイミングを見極める。

　結果として、インクリメンタルモデルが採用しやすい（サブシステムごとの独立性が高いので）。さらにサブシステムごとの独立性を高めるため、オブジェクト指向を採用するが、とはいえ、そうすると、全体のデータのデザインを明確化する部分と矛盾してくるので、そのへんのさじかげんが、問題になる。
（スクラムの体制にするかどうかというのはこの後の話。ＸＰは、テストファースト部分以外、採用しにくい。で、テストファーストは、ＴＤＤのところになる）

---

　とはいえ、あまりにもさじかげんを、みんなで自由に出来るようにしてしまうと、管理もできないし（特に意識あわせなどのコミュニケーション上の管理）、とにかく、先が読めない。そこで、（開発プロセスの標準化もふくめた）開発標準をつくり、ある程度先が読めるようにするけど（この、先が読めることがリスクヘッジにつながっていく）、これを固定的にしてしまうと、結局ＴＤＤか、ＤＯＡっぽい方法かということになり、上記の問題を、もろにかぶってしまう。

　そこで、標準化に遊びをつくり、オブジェクト指向として、中は、ある程度自由に出来るようにさせ、その一方で、ＥＲも入れさせて、全体データの整合性の確認をとらせたりする（その成果を、標準化された枠組みの中で、どうクラスに反映させるかが、ＰＭの腕の見せ所になる。そのためには、クラスとＥＲの関連を読みきれないと、まずだめだけど）。
　Ｅｘｃｅｌファイルで、仕様を書く場合も、固定的な枠で縛りを入れながら、フリーフォーマットで、自由度を持たせている。

　そして、開発のタイミング的には、ＴＤＤの部分を前に持っていき、プロトタイプ、もしくは、全体共通の部隊が、その部分を明確にするようにさせ、利用技術を固めてから、全体データをみれるようにさせる。
　この固めた成果を、パターンにしてしまうということもありますね。

　っていうかんじかなあ。。。さいきんのおしごとの仕方は。。。

---

　もちろん、あんまりにも、自由にしてしまうと、ＣＭＭなんかを推進してる人から怒られそうだし、先も読めないのでリスク管理になんないし、コミュニケーション管理にも支障が出るので、どこを標準化としてきつくしめ、どこを本質的には甘くする（ただし、外見上は、ここも、びしっと締めている）かというのが、マネージャーの才覚になってくるところになる。

---

　で、大山さんの場合は、たとえば、「ＴＤＤだけしかできません。ＤＯＡだけしかできません。テストはＪＵＮＩＴでやって、時間頂戴ね」みたいな、状況がよければいいんだけど、そうでない場合（こっちが多いんだけどね）は困ってしまうというかんじ。ただし、生産性は、恐ろしく高い。

　宝来さんの場合、それではいけないということで、最後にひねりをいれる。だから、得点に結びつく。これだけで、すごい進化。

　そして、かおる姫は、ＤＯＡでもＴＤＤでもできるし、テストエンジニアも、プログラマもＳＥも、なんでもこなしているので、状況に応じて、開発方法論をえらべ、それを、開発標準の枠組みにとりいれて、押し込めることが出来る。なんで、次元が違ってすごい、ビジュアル系「だけ」ではない！（でも、ビジュアル系）というお話なのでした。

スパム防止策としての表題への固定文字

　よくメールの表題などで

　　【申請】交通費申請

　　　　　とか

　　【連絡】次回会議の日時

　のように、メールで、「各種申請のときは、表題の先頭に【申請】を付ける」のような、きまりがある場合がありますよね。
　決まった文字を付けることによって、メールの分類を早く行うという目的で。

　この方法の（多分）応用として、掲示板で、「自動的に投稿してくるスパム」を区別するという試みをやっている？サイトがあります。

　ＹＡＨＯＯ掲示板　２３２１　ソフトフロント
http://messages.yahoo.co.jp/?action=q&board=2321

　このサイトを見ると、頭が【ＳＦ】とついているのと、ついていないのがあります。
　頭に【ＳＦ】とつけているのは、このソフトフロントの記事を書きたい人のもののようです。で、それ以外のものは、基本的にスパムになります（しらないで投稿した人もいるかもしれないけど）。

　スパムの掲示板書き込みは、プログラムでやっているだろうから、こういう特別な言葉をこの掲示板のためだけに付けないだろうと。。。

---

　この手、ブログなどでもつかえるのかもしれません。

　”コメントやトラックバックするときには、タイトルの頭に【なんか言葉】をつけてください。そうでないものは、そっこー削除します”とかいえば。。。

　もっとすすんで、ブログを書く人が、あらかじめ、タイトルに含む言葉を登録しておいて、ブログに、「この言葉を書いてください」と書いておき、その言葉がなかったら、トラックバックも、コメントも受け付けないというようになると、すごいかも。。。

　まあ、それ以外でも、タイトルの頭に、文字を付けて、それを使い分けると（【賛成】【反対】【疑問】など）わかりやすかったりするかも。。。

---

　ということで、ある意味注目な？掲示板なのであった。
　

ブログ、最近のアクセスアップキーワードは、「かおる姫」のようだ！

　昨日、本家のブログで、かおる姫（バレーボール全日本の菅山　かおる選手）のことを書いたら、アクセス数が急上昇(いつもの２倍、いや３倍くらい）！！
　ということで、いま、ブログでは、かおる姫ネタが旬のようです。

　このブログにも、かおる姫関係のトラックバックもらっているし。。。

　ランキングでも１位が「菅山　かおる」になってるし

　でも、このブログをご覧になっている方には、「かおる姫？さっぱりわからん」という感じかもしれません。
　ということで、このブログでは、圧倒的に開発の人が多いと思うので、開発にたとえて、「かおる姫」のすごさと魅力、そして、いま、ホットでなにが面白いのか！について、書いてみたいと思います。

---

　まず、かおる姫は、全日本にリベロ（守備専門）で招集されたのに、いきなり、アタッカーで起用されることになったのです。つまり、開発で言えば、テストエンジニアが、いきなり、「あ、人いないんで、システム切って、プログラムも作っちゃってくれる？」と、開発全部を任されたようなもんです。

　で、それで望んだ「ワールドグランプリ」なのですが、大山選手（まあ、若手で、ＭＤＡにより爆発的な生産性を誇ると思ってもらえばいい）は、怪我でいない状態で、はじめ、違う人（吉澤　智恵選手）が出ていたのですが、急に「かおる姫」の出番が回ってきたのです。

　そうしたら、すごいんです！！
　どんな、ボールがきても取ってしまうし、アタックなんかも、「ありえねー」というくらいの状態で打ってしまうのです。いままでの、大山選手のときと違い、悪いトスでも、打ち切ってしまうのです。さらに、大山選手は、レシーブいまいちですが、かおる姫は、リベロっす！

---

　つまり、開発に例えていえば、ＴＤＤだとして、

　レシーブを要求を聞いて、テストに落とすまで（テストデータを作るまで）
　トスを仕様を切る部分
　アタックをプログラミング・テスト実施とすると

　（したがって、レシーブからトスとアタックをあわせて２段で返す（仕様作成とプログラミング一緒）とか、ダイレクトに返す（すぐにプログラミング）もありえる）


■■　大山選手の場合
　仕様をきっちりきってあげて、環境を整えてあげれば、ＭＤＡにより、爆発的な生産性を上げる（パワフルカナ）だが、仕様を聞いて纏め上げるのはいまいちだし、最近の若手同様、ＪＵＮＩＴじゃないとだめ、流しでテスト実施（トスが流れてる状態でアタック）とか、ありえない！といい、得点に結びつかない

■■　かおる姫の場合
　仕様がなんだろうが、環境がなんだろうが、決めてしまうのです！
　要求がめちゃくちゃでもレシーブしてしまうのです。
　トスがみだれていようが（流しでテストしか出来ない環境でも）それを切り返してアタックするテクニック（一発でテストを決めてエビデンスを取れるように、仕様やプログラムを調整するテクニック）を持っているのです。
　さらに、ビジュアル最高っす！アタックＮＯ１をリアルでやっちゃうような感じです。

■■　ほかの選手でも
　大山選手がいたときには、下でやっていた（つまり、大山選手がプロジェクトマネージャー級だったとき、プログラマだったような）宝来選手も、大活躍しているのですが、いままでのやり方とちがうのです。単調にうつだけでなく、ひねりをいれて、ブロックアウトにして、得点してしまうのです（開発で言うと、いままで、オブジェクト指向だけだったので、仕様間違いが指摘できなかったのに、ＥＲからクラスへの変換などを簡単におこない、オブジェクト指向において、要求にむじゅんがあろうが、どんな状態でも、なんでも開発できるかんじ）

---

　つまりですね、「かおる姫」がはいることによって、バレーが急速にかわり、さらに変幻自在、猛スピードになってしまったのです。もはや、要求を出す前に開発体勢ができる（ブラジルがブロック体勢を整える前に攻撃してしまう）。

　開発でいうと、大山選手のときには、ＭＤＡを採用してました。なんで、ユーザーの要求がでるのをまって、それが正しいときは生産性が上がって開発してました。

　でも、「かおる姫」がはいったことにより、それじゃー、遅いだろう、要求待ってるんじゃあ。。っていう感じになり、もはや、要求が出ないんなら、こちらからＤＯＡに変えてデータ分析をしてしまい、ここらへんでオチがくるだろうと、予測して開発するなど、もう変幻自在で、スピードなんです！！

---

（午後２時ごろ一部訂正：理由は下記）
　で、そこに、大山選手が、戻ってきたとしても。。。
　ＭＤＡの権威で、どんなにすごい人で、どんなに生産性が上げられても。。。

　もう、そういう時代ではないんです。
　かおる姫の出現によって、バレーは変わってしまったんです。
　つまり、要求によって、ＤＯＡなり、オブジェクト指向なり、アジャイルなり、アスペクト指向なり、状態遷移に基づく開発なり、開発方法論をすべて変えるような時代にかわってしまったんです。

　なんでも、できなきゃだめなんです！！

　ＪＵＮＩＴでないとテストできないなんていっても、そんなテスト時間は与えられないし、与えられなくても、バチンと結果を出してくる仕様を切る能力、流しで障害箇所をキレイに切り分ける能力をみんな持っているっていう状態なんです。

　さらに、大山選手のライバル、プリンセスメグこと、栗原恵さんは、技巧派です。ある程度なんでもできます（ＤＯＡでも、オブジェクト指向でも、こなしちゃいます。テストもＪＵＮＩＴを使わなくても、自分でドライバつくって、自動生成くらいのことは、平気でできます）。

---

　ね、おもしろいでしょ。
　かおる姫が出てきたおかげで、バレーが、いま変わってるんですよ。
　そのうえ、かおる姫は、身長が169、大山選手は、187、つまり、大山選手が、慶応のＳＦＣだとすれば、かおる姫は、ばりばり文系英文科みたいな感じなんです。

　みんな、かおる姫で盛り上がるの、わかっていただけますう？？
　これからの、大山選手も見ものだよね！！

　ちなみに、大山選手、gooブログだしてるよ！！　ここ

＊午後に訂正した理由　この掲示板の内容を勘違いした：チームに戻るんですね。全日本に戻るとは書いていない。でも、北京までには。。。どーするんだろう。

総務省が「有害情報判定委員会」検討と、「実名でのネット活用促す」だって。

総務省のネット関係の記事２つ

実名でのネット活用促す　総務省「悪の温床」化防止

ネット情報に第三者の「有害判定委」…総務省が検討

　実名っすか。。。
　その上、有害判定。。。
　なんか、よのなか、きびしくなってきますねえ。

　実名なんか出したら、このサイトは、すぐに閉鎖しないといけません。
　でないと、まわりのひとに、にらまれてしまいます。

　そいと、その記事に「匿名性が低いとされるブログ」を「小中学校の教育で活用するよう求め、文部科学省などと具体策を詰める。」ってあるけど、そんなことしたら、トラックバックやコメントをスパム状態でかいて、いじめるとか、はやりそうな気がするけど。。。

昨日のエイベックス株主限定ライブで、勉強になりそうなことのメモ

　昨日のエイベックス株主限定ライブや、その前にやっていたビデオの中で、「コピーされるほど儲かるシステム！」に関係しそうな、勉強になる話のメモ。

■■　クリエイティブ＋コミュニケーションがブランドを作る
　新生エイベックスの基本方針を説明したビデオの中から（限定ライブが始まる前に流れたビデオ）。
　たしかに、モノを作っても、消費者に認知してもらわないとブランドにはならない。
　市場とのコミュニケーションが大切。

■■　大塚愛は、学園祭を行うごとにファンを取り込んでいった。
　司会の渋谷さん（だっけかな、女性のほう）が言っていた言葉。

　テレビやネットなど、ある意味バーチャルな世界というのは、場合によっては、広めにくいものがあるのかもしれない。

■■　鈴木亜美の場合、ＣＤより前に、着うたなどで配信する。
　前のビデオでだったか、司会の人が言ったのかは覚えていないが、こんなこといってた気がする。
　ＣＤ以外のものと組み合わせて、ブランド戦略を考えている例。

　ただ、鈴木亜美の場合、ＣＤよりなにより、限定ライブでは、間奏の間のパフォーマンス？？がよかったです。あれは、見てないと、通じないもんねえ。。。

　で、限定ライブって、テレビでは、大塚愛と浜崎あゆみしか取り上げないから。。
　あのライブのニュースで、「トリにあゆが登場すると株主が立ち上がって声援を送る一幕も。」とあったが、去年はその場面で、あんなに立ち上がったり、声援を送る人はいなかった。
　今年は、２番目にglobeが出てきたとき立ち上がり始め、そのノリで、そのあと（ティンクティンクで立ち上がる人はいなかったけど）、鈴木亜美、大塚愛ときたので、あゆのとき、声援とかしやすい雰囲気になっていた。
　で、それもこれも、ことしは、株主総会入場時にルミカ（パキッと折ると光るやつ）が配られたからなんだけどね。。。って、総会にルミカを配る会社って(^^;)

---

　って、あんまり書くと、本家の限定ライブネタ、総会ネタと変わらなくなるので、この辺で。。。

コミュニケーションが、生産性を決めるので、開発の人選は、大事

　前日のブログでバレーボールの柳本ジャパンの話で、最近、強くなった気がするけど、それには、セッターでありキャプテンである竹下選手からみて、周りの選手が、自分の所属するチームだったり、以前からやっている人たちだったりと、コミュニケーションがとりやすいこともあるのかもしれないみたいなことを書きました。

　なんてことを思ったのも、じつは、テレビの解説で、宝来選手と、かおる姫が、どちらも所属はJTで、竹下選手と同じだから、やりやすいのかもっていってたことからなんですけどね。
　もちろん、強い理由はそれだけでないのは、見てよーくわかるけど。。

---

　で、このコミュニケーションなんですけど、最近の開発方法論で、あまり深くとりあげられてないけど、実は、多分、生産性を決定付けてしまう、主要因だと思います。
　たとえば、ＸＰなんかで、ペアプログラミングを採用した場合（って、普通採用しないと思うけど）、ペアで組む２人がどちらも議論好きだったりすると、プログラムが進まなくなったりするかもしれません。開発のコミュニケーションが大事です。

　ＴＤＤを採用した場合、ユーザーの要件に応じて、テスト内容、データを作り、そしてプログラミングするので、このユーザーの要求の精度と理解が、開発に直接影響してしまいます。ユーザーとのコミュニケーションがとれないと、ちょっとした要件の誤解から、とんでもないテストデータを作ってしまい、それをもとにプログラミングしても、無駄になってしまいます。
　なんで、ユーザーとのコミュニケーションが大事です。

---

　ということで、コミュニケーションは大事で、開発でも「周知」とか「意識あわせ」ということが、よく行われます。というか、マネージャーの大半の仕事は、「周知」と「意識あわせ」でしょう。
　なんで、生産性に影響してしまいます。
　たとえば、意識あわせをしてもなかなか意識が合わないと、そのための時間はかかるし、意識が合わないから、障害も起こりやすいでしょう。

　なんですけど、このコミュニケーション、実はツールとかなんかの問題より、人選の問題だったりします。

　昔は受託といっても、派遣に近いような形の場合、人月単位なんで、だれでも送り込めばよかった部分がありますが、最近は、そのような形でも、「この人とこの人の組み合わせって大丈夫？」なんて、確認してることもあるみたい。

　最近の開発の場合、方法論より、人選というか、人間関係で、開発の成否がきまってしまうようなところもあり、重要なのですが、この分野は、あまり研究されてない気がします。

XPと、開発の人選と、最近のバレーボール・新生柳本ジャパン（途中まで）

　いやー、ここ最近、バレーボール変わりましたなー。
　強くなった感じがします。
　やっぱり、宝来選手、菅山　かおる姫と、きれいどころをいれたからでしょうか！

　きれいどころをいれると、生産性あがると思うんですよね。システム開発でも。
　「アジャイルは人だ」とかいわれるらしいですけど、そーいう、きれいどころをいれたら、生産性が上がるかどうかっていう研究は、なされてないような気がします。これは、重要な研究テーマ。。。

　。。。って、そんなことを話したいわけではありません。
　竹下選手の話と、XPのペアプログラミングの人選、最近の開発の人選の話。

---

　竹下選手は、JTに所属しているんですけど、セッターなので、だれかにボールをあげる役目です。
　で、今回活躍のこの宝来選手、菅山　かおる姫、どちらも所属はJT。
　さらに、ほかのメンバーは、大友選手、杉山選手、高橋選手がNECです。
　つまり、普段から、いっしょにやっているメンバーがおおい構成に今回なっています。

　いままでは、高校生つかったり、チームも結構ばらばらだったりと。。。

　と、プロジェクトと、構成員によって、生産性はかわる。理由はコミュニケーションのとりやすさで、最近の開発で、常駐先に人をだすときも、そこまで気にしはじめたという話題を欠こうと思ったんだけど。。。

やばい、もうじき、終電だ！
じゃ、このつづきは、またこんど

「携帯電話のバグをネット経由で更新」らしい。（auのＷＩＮ）

ものものさん経由で知ったニュース

携帯電話のバグをネット経由で更新，KDDIが6月下旬開始

これって、ユーザーが更新ファイルを手動でダウンロードする方法の場合はいいけど、KDDIから端末に更新ファイルを自動で配信する方法の場合、
別に、更新しなくても差しさわりのないようなもんまで、更新されちゃう（ダウンロードされちゃう＝パケット代を払わせられる）んじゃないだろうか。。？
　それが、むこうの戦略？？

　で、もし、自動更新されたものに、さらにバグがあって、ケータイが動かなくなっちゃったりしたら。。。なんてことはない？？

　手動ダウンロードのほうが、安全かもかも？？

業務が大幅に変わる場合などのとき、ワークフロー制御を行う感じで作る場合の作り方

　以前のブログの最後「この場合は、ワークフロー制御を行うかんじでつくります。」について、実現方法のまとめです。

　これ以外の方法でも、もちろん実現可能です。
　っていうか、あんまりかっこよくない、どたばたっぽい感じの例。

■■　方法

【あらかじめやること】

１．一連の処理に番号をつける
　例：商品購入サイト
　　１．受注受付
　　２．在庫引当
　　３－１．入金確認－クレジットカード
　　３－２．入金確認－銀行振込
　　３－３．入金確認－有分極振込み
　　４．出荷指示書（ピッキングリスト）作成
　　５．宛名ラベル作成
　　６．出荷
　　７．返金
　　８．キャンセル処理

２．ＤＢでも、プロパティファイルでもどこでもいいんだけど、
　　どういう状況のとき、どういう順番で、しごとを行うか
　　つまり、「仕事の雛形（標準的ワークフロー）」を登録する
　　→一般的に作る場合、こういうものがきたら、こうという仕事の手順の雛形を登録する
　　　別に、一般的にやらないのであれば、ここを省略し、ハードコーディングでもかまわない

３．ＤＢに、一連の作業指示を入れられるテーブルを作成する
　　＜項目＞
　　　　ジョブ番号：一連の仕事を表すＩＤ
　　　　明細番号：一連の仕事中、現在の仕事は、何番目の仕事を表すか
　　　　直前の明細番号：一番初めの仕事は０
　　　　　　　　　それ以外のとき、現在の仕事の前に行った仕事を記述する
　　　　　　　　　（複数ある場合、任意の１個でよい）
　　　　ステータス：起動済み、次に起動、起動まち
　　　　起動条件：いくつかの仕事があるとき、すべて終了してから起動する場合
　　　　　　　　　同期-1,2 のように、終了待ちする明細番号を書くなど
　　　　　　　　　起動するための条件を書く
　　→ＤＢでなくても、ＸＭＬなんかのファイルで作業指示でもいい。
　　　その場合、この作業は、省略
　　　項目は、一例であり、これ以外の方法ももちろんある
　　　（直後の仕事を入れるもの、直前と直後を入れるもの、
　　　　複数の仕事をジョブグループとして表現するものなど）

---

【プログラムの動作】
（こんなふうな動きのするプログラムを作成します）

４．一連の作業の開始時において、
　　・仕事の雛形をアクセスし、該当する仕事の雛形（ワークフロー）を、見つけてきて
　　・この一連の仕事をあらわすＩＤ（ジョブ番号）を取得し
　　・そのＩＤとワークフローを一連の作業指示を入れられるテーブルに登録し
　　・一番初めの仕事を終了とします

５．ワークフローにおいて、次の仕事が、
　　・前の仕事が終わったらすぐに起動する場合は、次の仕事をすぐに起動する。４へ
　　・バッチや、手作業での起動の場合、ステータスを「次の起動」にする

---

【プログラムの動作-バッチなど編】

（前のところで
　　・バッチや、手作業での起動の場合、ステータスを「次の起動」にする
　とかきましたが、そのバッチや、手作業での起動が動かされた場合）

＊バッチのとき
６．バッチプログラムの場合は、まず、そのバッチプログラムが、処理対象とするものを、一連の作業指示を入れられるテーブルを参照してとりだす
　→「次の起動」になっていてかつ、起動条件を満たすもの

７．処理を行う

８．５へ行く


＊手作業のとき
６だっしゅ．手作業の場合は、処理対象とするものを、一連の作業指示を入れられるテーブルを参照してとりだす
　→「次の起動」になっていてかつ、起動条件を満たすもの

７．６だっしゅで取り出したデータを表示し、作業するものを選択してもらう

８．選択されたものの処理を行う

９．５へ行く

---

うーん、言葉で書くと、やたらわかりにくくなってしまった。