MS-Accessでソッコー開発（Accessでアジャイル その１）

　アジャイル開発というと、Javaでの開発が多いと思いますが、別の言語でやっちゃいけないという法律はありません。つーことで、今日から、Accessでアジャイル開発、とくにＴＤＤっぽくやる方法を考えます（見てくれる人が多かったら、少なかったらソッコーやめます）。

---

　Accessでアジャイルっぽく開発する場合、ちょっと、普通とは違う考え方をします。それは、

　Accessはデータベースではない。
　Accessは、データベースもやろうと思えばできる、開発環境＋実行環境である。
　　　とくに、テーブルは、データベースも「作れる」というだけで、
　　　　　　　ワークファイルとして使っても問題はない。

　もし、AccessをＤＢとかんがえてしまうと、正規化をどうするとか、ビューがどーでこーでとか考え始めて、ソッコーでつくれなくなります。

　しかし、Accessで使うすべてのテーブルを、共有しなければならないという法律はありません。で実は、Accessのテーブルは、共有するものはＤＢ，共有しないものは、ワークファイルと思うと、ソッコーで開発できるようになります。
　ワークファイルなら、ＤＢの正規形に従うことはありません。

　帳票や画面の可変項目と、まったくおなじ項目を用意すれば、その値を帳票や画面に表示してくれます。その方法は簡単です。

---

　そうすると、共通部分のＤＢから、そのワークファイルにデータを落とすことになりますが、このとき、データベースの人たちは、ＳＱＬと考えますが、ＳＱＬを知らなくってもＯＫです。

　方法は２つ
（１）ＡＤＯを使い、ＤＢをOpenして、レコード処理する
　　　→ＶＢＡのプログラムが書ける人
（２）ビューを使って、そのテーブルをリンクする。計算式が必要な場合も、ビューで書く
　　　→ＶＢＡは、いりません。Excelみたいな感覚でかけます。

---

　ということで、具体的な内容に関しては、今後、見る人が多かったら、書いていく予定です。

　ちなみに、こんな内容を予定しています

■■　帳票を１つ作ってみる
　１．レポートの作成
　２．テーブルを作成する
　３．レポートとテーブルを結びつける

■■　２つめの帳票を作ってみる
　１．レポートの作成
　２．テーブルを作成する
　３．テーブルを分割して、共通部分を出す
　４．共通部分のデータ取り込み法
　　　　（１）ＡＤＯを利用する
　　　　（２）Viewで書く
　５．レポートとテーブルを結びつける
　　　　（１）ＡＤＯの場合
　　　　（２）Viewの場合

■■　詳細がある帳票を作ってみる
　１．レポートの作成
　２．テーブルを作成する
　３．テーブルを分割して、共通部分を出す
　　　　　（１）サブフォームを使う場合
　　　　　（２）サブフォームを使わず、繰り返してしまう場合
　４．レポートとテーブルを結びつける
　　　　　（１）サブフォームを使う場合
　　　　　（２）サブフォームを使わず、繰り返してしまう場合


■■　入力画面を作ってみる
　１．フォームの作成
　２．テーブルを作成する
　３．フォームとテーブルを結びつける

■■　詳細がある入力画面を作ってみる
　１．フォームの作成
　２．テーブルを作成する
　３．テーブルを分割して、共通部分を出す
　　　　　（１）サブフォームを使う場合
　　　　　（２）サブフォームを使わず、繰り返してしまう場合
　４．フォームとテーブルを結びつける
　　　　　（１）サブフォームを使う場合
　　　　　（２）サブフォームを使わず、繰り返してしまう場合

こんなかんじです。
もし、読んでみたかったら、お友達おさそいあわせの上、今日のこのブログにアクセスしてみてください。。。なのかあ？？

仕様変更によるＤＢ変更がおこっても、アプリ的に影響なくする方法＆ＳＱＬは一箇所にまとめるのが安全

　Ｏ／Ｒマッピングが広まってしまったため、ＤＢのテーブル定義が変更すると、そのクラスも変更され、インターフェース(呼び出し引数等）も変更されるように、考えられてしまった気がします。

　しかし、ＤＢのテーブル構造が変わったら、アプリ側のプログラムが変わっちゃうと、ＤＢの特徴から、まずいわけです（ＤＢの特徴＝一貫性、独立性、共用性）。つまり、独立性(プログラムとＤＢは独立している、ＤＢが変化してもプログラムは変わらないし、プログラムが変わってもＤＢは変わらない）。

　で、どうするか。。。

１．ＤＢのアクセス部分を、まずはじめに、独立したクラスとして作ります。
→ふつうは。。。ウィリアムのいたずらが前にやった仕事のようにＡｃｔｉｏｎメソッドからＳＱＬを直接書くような仕事を引き継がない限り

　なんで、ＤＢのアクセス検索メソッドでは、そのメソッドのなかから、１つのテーブルを検索するようにＳＱＬを発行していると思います。

２．あるテーブルの一部を、別テーブルに分けたとします。
　２．１　そしたら、別テーブルに分けた部分のアクセスメソッドをつくります。
　２．２　前のテーブル（１）の検索部分のＳＱＬだけをＪＯＩＮする形に、変形する
→そうすると、（１）の検索部分を利用している今までのプログラムにとって、帰ってくる値、引数は同じなので、変化したことに気づかない＝独立性がある。

---

　で、上記のことをやる、前提として、ＳＱＬは１箇所にあつめる（あるパッケージ内にあるクラスからしか発行しない）。そうするとやりやすいということもあるが、一番の問題は、パフォーマンスが出ないとき、ＳＱＬをチェックするとき、いろんな人が触って、いろんなところにあると、チェックできない。

　なので、ＳＱＬは１箇所にあるめる、できれば、触る人を限定するか、自動生成がいいかも

---

　で、こういう書き換えをしたいので、Ｏ／Ｒマッピングツールより、自分たちで自動生成を作ったりする。どんなかんじで、自動生成ツールをつくるかは、今度気が向いたときに書く。

　ちなみに、もし、インターフェースを変えちゃったりすると、大きなプロジェクトだと、「何で変えたあ！」と怒られるので、注意したほうがいい。

ＲＦＩＤの定期を使って、位置を知る応用、小田急グーパスでやってるみたい。鉄道で広告収入も？

v　前のブログ（ＩＣタグ（ＲＦＩＤ）と個人情報の漏洩）で、こんなことを書きました。ちょっと長いけど、引用します。


　ＪＲのスイカ、あれ、もし、番号が１個１個振ってあったとする（まあ、名前と電話番号でもよい）。改札で、リーダーは、その番号を読み取っているかもしれないよね（定期は読み取っているはず。２回同じ定期を入れてしまうと、「前に入れた定期と同じです」というようなメッセージが出るから。スイカは知らん）。

　で、もし仮に、その通過した人の番号をとっておいたとする（今は、たぶん、そんな情報とってないと思うけど。。適当な予想）。

　警察官が、犯人をしらべようと、ＪＲに協力を依頼、その犯人がスイカの定期券を使っていたとしたら。。

　スイカ定期券の登録内容をもとに、番号を割り出し、ぜーんぶの駅の通過者の番号と犯人の番号をマッチングさせたら。。降りた駅までは、わかるよね。

　これで、捜査は簡単だけど、個人情報漏洩では（＾＾；）

　まあ、スイカは、だれが通過したかという情報をとってるなんていうことしてないだろうから、
　今はできないと思うので、いいけど。。


　ＪＲはどうかしんないけど、小田急電鉄はとっていて、それで新サービスをやってるみたいですね。日経情報ストラテジーの３分間キーワードのＬＢＭ（０１９ページ）の最後のほう、小田急電鉄のグーパスについて書いてます。

　このしくみ、
　ＲＦＩＤの定期を通す

　　→それを「読み取って誰が通過したか検索する」！！

　　→その人の携帯電話に、改札を通過した駅周辺の情報を電子メールでお知らせ！

　つーさーびす。くわしくはここ

　おお、ウィリアムのいたずらみたいに、犯罪捜査に利用する？？わけでなく、
　こういうサービスに使うわけですね！！

　とはいえ、ウィリアムのいたずらのように、個人情報を気にする人はいないのかなあ。。
　ホームページのＦＡＱに、そういう内容はなかったけど。。
　個人情報の取り扱いについて、見えるところにわかりやすく書いたほうが安心な気も？？

---

　でもですよ、このサービス、本格化するとすごいですよね。
　その送られる電子メールに、広告がのると。。。

　鉄道会社に、一気に広告収入があ！！

　そしたらですよ、ＪＲなんて、ものすごいいっぱい駅あるから、
　ものすごーく広告収入が入ってきそうですよね！！

　おお、鉄道会社の新しい収入源かも？？

　広告代理店、新しいメディアかも？？

TDDやアジャイルでのＤＢ開発は、昔ながらの正規化理論で作ることになる？

　先ほどの話を受けて。ＴＤＤやアジャイル、とくにＴＤＤで開発をしたとしよう。

　ＴＤＤの最大の制約は、

　「その要件を満たす、必要最小限の方法」でしか、実装しては、いけないことだろう。

　これは、ＤＢの作成上、ちょっとやっかい。

　最近の佐藤氏などの流派でいくと、全体が見えていて、業務内容がみえているのであれば、全エンティティを導き出せる。

　でも、片っ端から、手当たり次第、プログラムして言った場合、ある項目は、属性値なのか、それとも、別にＩＤをふって、テーブルにすべきなのかは、はっきりしないし、そもそも、ＴＤＤに従う限り（というか、一般の開発においても）言われてないのに、勝手にテーブルを作ったら、怒られる。

---

　たとえば、（前の例にからむけど、一番最後の話）従業員の部署と、配置年月日を分ける必要があるのは、配置の履歴をとる必要がある場合に限られる。

　でも、言葉でイベントを導き出す方法では、「配置する」というをテーブルを（「知った」と同じように）作成し、このテーブルアクセスを記述することになる。

　しかし、もし、そんな配置の履歴をとる必要がないプログラムしか作らなかったら、そのテーブルを作るということは、ＴＤＤの理念に反する。必要最小限ではないからだ。このテーブルはなくても、問題はない。従業員の属性として、部署と配置年月日があれば十分だ。

---

　実は、今のは一例で、言葉でイベントを取り出すと、膨大な量のエンティティを生じ、プログラムを必要とすることが多い。

　ＴＤＤという開発方法をとらない場合、こちらのほうがいい。一度作ってしまえば、あとは簡単だから。

　しかし、ＴＤＤやアジャイルの理念には合わない。言われてないテーブルを、今必要ないと思うのに（配置の履歴なんて必要ないのに、その人の今の部署名を知りたいためだけに）作って、アクセス部分までつくんなきゃいけない。

---

　一方、昔の正規化理論の場合、今、必要ないものは、エンティティとしてあがってこないというか、あげなければいい。で、そこに関しては第二正規形でとめても、いちおう、プログラムは動く。

　つまり、例では、いまのところ、部署と配置年月日を従業員テーブルの属性として入れておき、もし、履歴が必要になったら、配置のテーブルをつくり、部署と配置年月日をとりたい場合、今までのテーブルアクセス部分を、配置テーブルとJOINさせる形に修正すればいい。

　修正も、最小限だ。

　つーことで、ＴＤＤでやるんなら、昔の正規化理論で、正規化し、いっとうはじめは、システム化に関心のあるエンティティだけをだしてきたほうが、アジャイルっぽくできる。

---

　じつは、この話は、月曜日以降に、書くかどうか考えている話題の伏線であったりする。

ＤＢのテーブル作成、エンティティから、正規化理論で作る、普通の方法について

　前のブログで、ＤＢの作り方で、「ふつうの正規化理論の作り方で」と書いたけど、その作り方について、説明してなかったので、一応書いておきます。

　このやり方は、昔の一種の情報処理試験テキストに沿ってる方法だと思います（ごめん、手元にないので確認できない）

---

作り方は
（１）エンティティを導出する
（２）エンティティ間の関係を調べＥＲ図作成
（３）正規化
ということで、佐藤氏やはぶさんのやり方と、大枠同じです。

　大きく違うのは、（１）の導出の際、一般の理論では、言葉の構造にまでさかのぼってやらなくても、つまり、エンティティの本来の意味である、実体のあるものやその抽象概念、あるいはイベントという形だけを抽出してきてもＯＫということです。

（第三正規形の部分で、佐藤氏らの理論と同じになります。逆に言うと、トランザクション系等を、第二正規形まででとめた場合、佐藤氏らのテーブル構造より、テーブル数が少なくなります）。

　なお、第三正規形を完璧に行った場合、最終的には、佐藤氏の理論と、普通の正規形は、たぶん同じ形になります（なお、佐藤氏は、正規形を崩す（＝第二正規形でとめる）ことを否定している＝すくなくとも、私がセミナーを受講した時点では）。

---

＜つくりかた＞

　この方法と、ほかの方法の違いをわかりやすくするため、この例を使って説明しますね。


（１）その１：エンティティをとってきましょう。
　ここで、エンティティを厳密に出さなくても、第三正規形を行うと、すべてのエンティティがでてくることになるので、気軽にエンティティを出してください。

（１－１）まず、着目する業務のエンティティをイベントとして出しましょう。
　→とはいえ、この業務は、永続性のあるデータを保存する必要のある業務にしてくださいね。
　　コピーとって、お茶入れてはだめです。
　　コピーしたら、何をコピーしたか、お茶入れたら、誰にお茶入れたかというのは、
　　必要ないですよね。
　受注した、発注したのような、業務を行っても、コンピューターの電気を切っても、「やったことを忘れた」と、言わしてもらえないような業務です。

　（例の場合は、「予約」になります）

---

（１－２）その業務のエンティティに関係のあるエンティティを出します。
　（１－１）の内容を説明するエンティティを出します。
　内容説明というと、５Ｗ２Ｈです。で、このうちエンティティになる可能性のあるものは＊を付けたもの

　いつ：業務エンティティの属性（年月日）になります
　どこで：場所が固有名詞なところの場合、エンティティになる　＊
　誰が：エンティティになる
　なにを：なにをが対象物の場合（牛乳をのむの牛乳を）、エンティティ＊
　　　　　なにをが動作物の場合、（カラオケをする）こちらが業務エンティティのことも　＊
　なぜ：必要ない。コンピューターは、理由を説明しなくてもやってくれる
　どのように：これからプログラムする内容。メソッドに相当
　いくら：なにかの属性（金額）

　つーことで、誰がという、関係者と、どこでという場所が、固有名詞で示されるような場合、場所を、なにをという対象物をだしてきます（英語だと、ＳＶＯＣ、ＳＶＯＯの、Ｓ，Ｏ，Ｃを出す）

　例の場合、予約者が、図書館またはみどり号で、本を予約する。

エンティティは、とりあえず

予約者、
本、
予約、
図書館など

　で、ここで、「図書館またはみどり号」について、佐藤氏の理論だと、わけます。
図書館と、みどり号は、あきらかに別物だから。
でも、ここでは、別に抽象概念を使って、図書館等としてしまいます。
この場合、図書館にあって、緑号にないもの、緑号にあって、図書館にないものがあるので、その項目はＮＵＬＬになることがあります（このＮＵＬＬを認めるかどうかによって、わかれる）。

---

（２）関係を入れる

　てきとうにいれてください。(ほんとうはいけないけど、後で入れられる）

---

（３）正規化する

（３－１）第一正規形：繰り返しをなくす
　例は繰り返し部分がないので、いいのですが、
　受注伝票のなかに、表になっていて、商品ごとに列になっているような場合、繰り返しとして、わけます。

---

（３－２）第二正規形：エンティティに、各項目を振り分け、主キーを決めます。
　帳票や画面、まあ、考えた項目などなどを、上記エンティティに入れて、そのエンティティを一意にきめるためのキーを導き出します。
　この操作方法

（３－２－１）まず、はじめに、項目をすべて、業務のエンティティに入れちゃいましょう。
　（って、操作すると、間違いが少ない）

　　申込年月日
　　名前
　　振り仮名
　　貸出券番号
　　連絡方法
　　連絡先番号
　　書名伝達ＯＫ
　　受取希望図書館
　　書名
　　著者
　　出版社
　　出版年
　　知りましたか区分
　　図書案内号
　　その他内容
　　新聞名
　　新聞号

---

（３－２－２）そして、これを一意に決めるキーをみつけます。
　同じ日に、ある人が、同一の本は、１回しかリクエストできなければ
　　キーは、
　　　　予約者のキー
　　　　本のキー
　　　　申し込み年月日
　　を合わせたものだけど、その制約がわからなければ（つーか、キー３つなんて、面倒なら）ＩＤを振ってしまい、予約ＩＤとする。今回は制約わかんないので、予約ＩＤ追加にしとく。

---

（３－２－３）次に、ほかのエンティティに目を向け、ほかのエンティティに入れたほうがいいものがあれば、そのエンティティにいれる（業務追加の場合には、もうエンティティに項目が入っているわけなのでその場合は、足りなければ追加）。

　入れた場合、業務エンティティの抜けたところに、
　　その抜いたエンティティのＩＤ項目がわかれば、ＩＤ項目名、
　　　　　　　　わかんなかったら、仮にＩＤ項目を書いておき、わかったら、直す。

　たとえば、
　　名前
　　振り仮名
　　貸出券番号
　は、予約者のほうに入れるべき。
　なぜなら、予約者が同じなら、名前は同じはず（こういうのを、関係従属という）。
　なので、これらは、予約者のほうに入れる
　（ほかの業務ができている場合、貸出者になっているかもしんないけど）

この操作を行うと、こうなるはず

予約
　　予約ＩＤ
　　申込年月日
　　（予約者のＩＤ項目）
　　連絡方法
　　連絡先番号
　　書名伝達ＯＫ
　　受取（図書館などのＩＤ項目）
　　（本のＩＤ項目）
　　知りましたか区分
　　図書案内号
　　その他内容
　　新聞名
　　新聞号


予約者
　　名前
　　振り仮名
　　貸出券番号

図書館
　　受取希望図書館またはみどり号ステーション名

本
　　書名
　　著者
　　出版社
　　出版年

---

（３－２－４）そのあと、全部のテーブルのＩＤについて、決まってなかったら、きめる（一意にする項目があれば、それを採用、なければ、ＩＤを振る）
　予約者は貸出券番号がたぶんＩＤ，
　図書館はＩＤをふらないとすると、名前がＩＤとなってしまい
　　（それでもいいんだけどね）扱いが大変なので、一応ふる。
　本は、書名が同じ場合がありえるのでＩＤをふる

　ＩＤが決まったら、予約で仮に入れていたＩＤをもどす。

　第二正規形なら、ここまで。

---

（３－３）第三正規形：上記のエンティティ内で、分けたほうがいいものをわける。
　また、（これは、第三正規形の話ではないけど）自動的にもとまるものも、削除する。

例の場合：
・予約の連絡方法と連絡先番号について
　もし、予約者に、（予約者登録をやったときに）すでに、自宅ＴＥＬ，携帯、ＦＡＸ，勤務先ＴＥＬが入っていて、予約では、その番号をみるのであれば、連絡先番号は不要。もし、予約時に、登録してある内容とは違う自宅ＴＥＬにすることを認めるなら、連絡先番号は必要。

　この場合、プログラム上は、予約者テーブルで、これら番号をみておいて、デフォルトでは、この予約者テーブルの値を先にセットしておき（連絡先を変えると、これらが切り替わるように設計しておく）、修正したければ、修正可能なように、画面を設計しておく。画面入力の値を、保存する形になる（なにも画面で修正しないと、テーブルの値が入る）

・本の出版社
　まじめに分けると、出版社は、別テーブルになる。
　出版社ＩＤ，出版社名が、とりあえず入るかな。。

・図書館など
　ここでは、直接的には導き出せないが、たぶん、、図書館みどり号区分というのがあるはず。

・知りましたか区分
　やる気になると。。だけど。。。
　知りましたか区分、知りましたか自由項目という構造に、じつはまとめられる
　（区分によって、号がはいるのか、その他の言葉が入るのかなどきまる）

---

結論、こうなる。

予約
　　予約ＩＤ
　　申込年月日
　　貸出券番号
　　連絡方法
　　連絡先番号
　　書名伝達ＯＫ
　　受取図書館ＩＤ
　　本ＩＤ
　　知りましたか区分
　　知りましたか自由項目

予約者
　　貸出券番号
　　名前
　　振り仮名

図書館など
　　図書館ＩＤ
　　図書館みどり号区分
　　図書館みどりステーション号名
　　

本
　　本ＩＤ
　　書名
　　著者
　　出版社ＩＤ
　　出版年

出版社
　　出版社ＩＤ
　　出版社名

　なお、あるエンティティにほかのエンティティのＩＤが入っているとＦＫになる。

---

　その日のうちに、出版社が追加されるということや、図書館が急にできるということはかんがえにくい。

　そこで、実務上では、プログラム立ち上げ時に、出版社テーブルと、図書館などテーブルは（テーブルが小さいので）全件読んでしまったり、クライアント側で、共通のメモリ領域にいれたりする。（で、この場合、ある日を境に、データを利用できるように、これらのテーブルに、利用年月日を付けたりする）

　そうすると、
　　予約票でテーブルアクセス必要なテーブルは、
　　　予約、
　　　予約者（貸出者）
　　　本
　の３テーブルに抑えられる。

　例の場合は、連絡方法を先読みするとしても、連絡先テーブルと知ったテーブルがさらに必要で、ＳＱＬ文を作るうえで、ＪＯＩＮ数が増えてしまうよね。

---

　どうして、この差がでるのかといえば、連絡先は、上記の操作では、予約ないしは、予約者（貸出者）の属性とみなしているから。
　属性なので、エンティティは現れず、テーブルもない。

　そして、知ったテーブルがない理由は、以下のとおり

　イベント系エンティティの場合、過去の事象は、過去形と現在分詞形の場合がある。
　過去形は、過去の事象を、過去に入力する。

　たとえば、受注と入金の場合、受注がおきたときに、受注データが入力され、入金は、その後、入金が起きたときに入力される。

　現在分詞は、過去の事象を、今（現在）入力する。

　上記の例、知ったを入力する場合、知ったという情報を知ったとき入力するのではなく、予約するときに入力する。
　同様な例は、従業員の生年月日など、従業員が生まれた何十年前には、入力不可能。そのとき入社してるか、システムがあるかわからないから。従業員が入社したときに、入力する。

　で、このように、現在分詞形の場合、現在関心のあるイベントに対して、付随しておきることが多いので、この場合、第一正規形に反しなければ、第三正規形で分けられないことがある。
（ふつう、従業員テーブルで、「生まれた」テーブルを別に分けたりしない）

　ただ、この場合、問題が起こることもある。履歴関係などで
（従業員テーブルで、従業員の現在の部署と配属年月日。この履歴をのこすには、配属されたというテーブルを作らないと、残らない）

　そのため、分けることもあるが、このテーブル作成時に、履歴が必要かどうか、自明ではない。
　（履歴が必要な場合、はじめのエンティティに上ってくるので、第二正規形で、別れる）

　そうすると、テーブルは一緒になるということになる。

　佐藤氏の理論（はぶさんの場合も）では、ことばでやっていくので、このエンティティは、例のように、わかれる。

---

　てなかんじかな。。ね、テーブル数が減るでしょ。

　ただ、当然だけど、とっちが正しいというものではないし、あともう一個の操作を行うと、佐藤氏のものと一致する（もう一個＝ＮＵＬＬ項目の排除）

昔の同種の開発経験が豊富でも、最近はあんまり役立たないかもね

　「昔の同種の開発経験が豊富でも、最近はあんまり役立たないかも！！」
　ＴＡＣの答えをもとに、情報処理試験ＰＭの午後１、問３設問１の（１）の問題を解釈すると、こうなるんですけど。。

　うーんたしかにそうかも。最近、バージョンアップがいろいろやられてしまって、同じソフトでも、昔のバージョンの開発経験では、パフォーマンスとかについては、あんまり役立たないかも。。それにハードも変わってしまっているし。。

---

　

情報処理試験ＰＭの午後１、問３はまとめると、こんなかんじ。
・システムを再構築する
・１年で２０％で、４年で２倍のデータ量になる
・システム開発予算削減のため、開発規模を１０％削減した
・外部設計段階で、見直し後（１０％削減後）の機能で性能評価を行った　＊
　→このとき、問題ないと判断した
・その後、内部設計完了段階でバッチ処理が１日で終わらないこと発覚
・その後、総合テストで、性能目標を６０％超えると、ハードがネックになり、目標に達しない

設問１の（１）の問題は、外部設計段階での性能評価（＊をつけたところ）「現時点で可能な性能の評価方法として提案したと考えられる評価方法は何か」

ＩＴＥＣの解答
４年後のデータ想定量を一割少なくして性能評価を行う

ＴＡＣの解答
Ｂ社の豊富な同種のシステムの開発経験に基づいて評価する。

　ＩＴＥＣの答えは「ない」と思う。 １割減らすのは、開発規模＝ふつう機能を１割減らすのであって、データ量を減らしていいとは書いてない。
　ＴＡＣの答えは、問題文中にそのような記述があるので、可能性大かも！

---

　で、ＴＡＣの答えだとすると、昔の開発経験を使っても、バッチ処理が終わらないことや、性能が６０％のところで遅くなることを見抜けなかったということになるけど、これ、確かにそうだと思います。

　とくにＯＳＳを利用してしまう場合、バージョンアップが頻繁に行われ、内部的に大幅変更！っていうこともあるので、とくに最新のバージョンつかっていながら、昔のバージョンのつもりで開発しちゃうと、思わぬところで、足元すくわれるかも。。。

　つーことで、前の記事にかいたように、やっぱ、実機での性能評価が、必要になってくると思う。

---

　ちなみに、これが、前の記事で、唐突な話をした理由です。
　ただ、それより、資本金の話だったりする。それは、今度、覚えていたら書きます。

システムソフトで、パフォーマンスの問題を出さない対策としての性能評価方法

　今日は、システムテストで、パフォーマンス上の問題が出るケースを考えます。
　（ごめんなさい、唐突な話で。。。何回か先で、この話をした理由がわかると思う）。

　システムテストの負荷テストで、問題が出たとしても、その後で、対応策を練っているのでは、もう、時間がない場合がおおいわけです。そこで、負荷テストで、問題が起こらないように、あらかじめ、運用時の目標データが流れたとしても、性能上、問題がないことを、設計に入る段階で、確認する必要があります。

　ここまでのことを、具体的に書きましょう。
　４年後に、２倍のデータが流れるので、今からシステムを再構築するとします。
　このとき、負荷テストを行った段階で、実は、１．６倍になったところで、急速にパフォーマンスが落ち、予測していたデータ処理ができないということになったとします。
　おそいです。この段階では。。。あと、残された期間は、負荷テストから運用までの、ちょっとの期間しかありません。その期間で、ＤＢの変更などは、できないです。

---

　そこで、設計開始段階において、マシン選定などと並んで、性能の評価を行うのが普通です。
　ここでの、性能評価の方法なのですが、理論的に、データ量が目標値になっても処理できるか？
　と計算で、求めると、問題を起こします。

　具体的に言うと、現在の処理データ量と、処理能力がわかっていたとします。
　いいかえると１秒間に到達するデータ件数と、そのデータを処理する時間です。
　これにより、稼働率が求められます。

　さて、ここで、データ量が２倍ということは、到達件数が２倍になるということです。
　ということで、上記の式を２倍して、つまり、稼働率が２倍になったとして、性能を評価していいかというと、よくないです。パフォーマンスは落ちる可能性大です。

　理由は、データ量が２倍になると、通信でコリジョンがおきるなど、問題を起こす可能性があること、データベースは、処理量が多いとメモリを確保する量も大きくなり、メモリ確保がある量を超えると、（ガベージコレクションがおきるなどの理由により）急速に遅くなるからです。

　ということで、データ量が２倍になった場合、処理時間も、もっとかかる可能性があり、稼働率が高くなる可能性があります。

　結局、２倍のデータ量で、通信とＤＢの性能を、実際に評価してみないと、わかりません。

---

　ということで、負荷テストで、問題を起こさないためには、実際に設計に入る前に、性能の確認をしないといけないことになりますが、このとき、困ります。まだ設計に入っていないので、データをつくれません。

　そこで、この場合、たとえばＤＢなら
（１）ある一定のレコード項目数（たぶん、こんなに使わないだろうという項目数）で、
　レコード件数を、規定のデータ量（例だと２倍）、さらに、その２倍、４倍、１０倍などのとき
　いくつのテーブルをJOINして、検索、追加削除すると、

　どのくらいのデータ量のときに、どのくらいの遅さになるか
　どのくらいのテーブルをJOINすると、どのくらい遅くなるか

ということを確認しておきます。

（２）そして、テーブルをもっと細かく分け、項目を減らし、インデックスを張った場合の（たとえば、テーブル数を２倍にして、項目数を半分にする）検索、追加、更新、削除と、上記の場合を比較します。

---

　すると、ＤＢは、たいてい、こんなふうにわかれるとおもいます。

・テーブルを区切って、インデックスをばんばんはり、テーブルを数多くして細かくし、JOINして更新したほうがいいもの→（２）で細かくするほどパフォーマンスがあがるもの

・単表でアクセスし、テーブル数を減らしてJOINしたものがいいもの
　→（１）で、テーブル数をある一定数以上増やすと、極端に、パフォーマンスが悪くなるもの

　このデータをもとに、どれくらいのデータ量で、どれくらいのテーブル数だったら、パフォーマンス上、問題がないかを確認し、それが、目標値とあうかどうか確認します。

　その結果、テーブル数は、これくらいに抑えるべきというのがきまったら、それにあったＤＢ理論を採用し、その後、テーブルをアクセスする指標をさだめます。一度のJOINを５テーブルまでとか。。。

　なお、オンラインの処理スピードに対応するため、テーブルを細かく切ってインデックスを張ると、大量データ処理のバッチが時間以内に終わらなくなることがあります。そのため、検索だけでなく、削除、更新などもかんがえ、このテーブルJOIN数や、ＤＢ理論をきめなくてはいけません。

（１）の、細かくテーブルを区切り、インデックスをはるとパフォーマンスがあがる場合のテーブル作成技法は、佐藤氏の流派の方法となります。

（２）の、テーブル数を減らしたいなら、普通の正規化理論で、エンティティをはじめ少なく選び、第三正規形をあまりしないようにして、対応します。
　はぶさんの流派は、（１）に近い結果がでるような感じがします。

　しかし、それでも、テーブル数的に問題がある場合、マスタ系で更新が少ないものを先読みしたり、ファイル化、変数化する、設計方針を打ち出します。

　通信の場合は、１電文量を細かく切って何本も送るのがいいか、１電文量は長く、電文数をすくなくしたほうがいいのかで、設計方針が違ってくるので、それを確認します。

---

　ということで、負荷チェックを行う場合、処理させるテーブルJOIN数などを決めながら、実際のデータ量で、登録、検索、変更、削除を行って、確認することになると思います。
　そして、その決まったテーブルJOIN数から、テーブルを多くてインデックスも多いほうにするか、テーブルを絞りこむかを考え、それにあった理論で、テーブル設計を行うのが無難と考えられます。

AE,PM,SAなどの情報処理試験の解答のありかなど

　アイテックのホームページで、今年秋（この前の日曜日の）情報処理試験の解答速報、
でてますね。

ここ
http://www.itec.ne.jp/2005autumn/sokuho/

　ＴＡＣのは、ここ
http://www.tac-school.co.jp/sokuhou/joho/joho0510.html

　テクノブレーンのはここ
http://tbc.boxerblog.com/lab/2005/10/post_8d50.html

　３社とも、びみょーに答えが違い、ウィリアムのいたずらの場合、正解は、４７個前後あたり？？というかんじ（違いがある）

　あ、前にブログであげたところに関しては、全社とも、解答はすべて同じで、そこはウィリアムのいたずらも、全部あってました
　一応、簿記１級、全経上級で、診断士はもってるんで、あたってなかったら、本気でやばいですので。。

　でもそれよりも、つーことは、コンピューターに関するところで、こんなに間違えているということで、やばやばやばやばです、ちゃんと、間違えたところをコピーとって、復習しなきゃ。。

　でも、会社によって、まちがいになったり、なんなかったり、
ちがうんだよな（＞＿＜！）

---

　で、やっぱり、ＰＭ午後１の問２の設問３の（２）の答えは「資本金」のようです。
　ＴＡＣも、アイテックも同じ答えです。

　ウィリアムのいたずらは、まあ、解答は資本金にして、理由は、ＴＡＣのように、下請法のことを書いたけど、

アイテックは

「企業規模の判断に資金の情報が必要だから」

そーですかそーですか、じゃあ、会社規模的に、無に等しい、フリーの人、つまりウィリアムのいたずらには、お仕事はこないと。。

。。。このことは、別の機会に、ゆっくりと話そうじゃないか（＾＾）

---

ただ、もっとすごいのは、プロジェクトマネージャーの午後１

問１の設問３の（１）

アイテックの答え

チームX E社 リスク 変更要求の採用決定時から短期で対応しなければならないリスク
チームY D社 リスク CCBの決定結果により過度のコスト負担が発生するリス


TACの答え(PDF)

チームX D社 リスク CCBで採択されるまでにかかる期間が納期の延長につながる
チームY E社 リスク 仕様変更が却下されたときの手戻り作業などがＥ社の負担になる

　
答え、Ｄ社とＥ社で、正反対なんですけどお？？
実は、これ、どっちにするか、ウィリアムのいたずらも、むちゃくちゃなやんだのよね。
で、どっちにしたか。。。忘れてしまった（＾＾；）午後１はメモしてなかったので。。
　たしか、ここは、アイテックの答えみたいに書いた気がする。。

　これ以外でも、ＴＡＣとアイテックのどっちかの答えみたいなことを書いたんだけど、２社で大きく違うんで。。。
　どっちかの答えに近いからといっても、それで丸になるのかどうか？？（だって、たとえばＥ社とＤ社のところ、２択で、正反対なら、どっちかがＸなんじゃあ（＾＾；）

うーん、やっぱ、午後１やばやばやばやばかもお？

　つーか、どーして、ＴＡＣとＩＴＥＣ、
Ｄ社とＥ社、まったく逆になるほどの差がでちゃうんだ！？
いくらなんでも（＾＾；）

笑える、「風が強くてうまくコピーできません」だって

ここ
http://plaza.rakuten.co.jp/simple001/diary/200510050000/

うーん、よく作るよ（＾＾）
でも、ほんとーに、こんなの出てきたら（＾＾；）

ユニットテスト、契約による設計によるテスト項目抽出基準と、その基準の理由説明について

　ユニットテストを行う、現在の開発の場合、メソッドに、ある値を入れたら、どのような値を返すかという、事前条件、事後条件を調べるテストが中心になるだろう。
　契約による設計などでも、この考えだし、Junitを使った場合、このようなテストになる。

　このとき、あるメソッドに対する、テスト項目の選び方には、３通りある。

　１つは、とにかく、値を入れて通れば良いというもの。
　つまり、このとき、メソッドは、少なくとも実行され、妥当な値が帰ってきたことは確かだ。
　これを勝手にＣ０となずける（なぜそういったかは、あとでわかる）

　２つめ、３つめについて考える場合、例を出して考える。

３つの引数があったとしよう。

１番目の引数が正、２番目の引数が正、３番目の引数が正のとき、１を返す
１番目の引数が正、２番目の引数が正、３番目の引数が負のとき、１を返す
１番目の引数が正、２番目の引数が負、３番目の引数が正のとき、２を返す
１番目の引数が正、２番目の引数が負、３番目の引数が負のとき、３を返す
１番目の引数が負、２番目の引数が正、３番目の引数が正のとき、１を返す
１番目の引数が負、２番目の引数が正、３番目の引数が負のとき、２を返す
１番目の引数が負、２番目の引数が負、３番目の引数が正のとき、２を返す
１番目の引数が負、２番目の引数が負、３番目の引数が負のとき、４を返す

としよう。このとき

・返り値の違うものについて調べる（１，２，３，４を返すものについて調べる）
・引数のすべての条件を調べる方法（８通り全部）、
と２つの方法が考えられる。

　はじめの、返り値のほうをＣ１，後のほうをＣ２と命名する。

さて、ここで、メソッドをステートメントと考えよう。
そうすると、はじめのＣ０と命名したものは、
　　メソッドを 少なくとも1回は実行したことになる。
　　つまり、命令網羅みたいなもんだ。

返り値をもとに割り振ったＣ１は、
　　メソッドの返り値の分岐条件を 少なくとも1回は実行したことになる。
　　つまり、分岐網羅みたいなもんだ。

引数の全条件を割り振ったＣ２は、
　　メソッドの全条件を 少なくとも1回は実行したことになる。
　　つまり、条件網羅みたいなもんだ。

ということで、ユニットテストを
（１）とにかく１回は通る、あるいは無手勝流にやる
（２）返り値を元に分類して、それぞれ１通りは通るようにやる
（３）引数を基に分類して（同値なもので分けて）それぞれ１通りは通るようにやる
というのは、意味があり、それぞれ昔の、命令網羅、分岐網羅、条件網羅に対応しているといえなくもない。。。と思う


　では、どうして、昔みたいにソースの中に入って条件でテストしないのかといわれたら、

　それはできないと答えられる。

　なぜなら、昔は、コーディング前にドキュメントが存在し、分岐部分がわかったが、最近は、その（プログラム内部を詳細に書いている）ドキュメントがない。ドキュメントがない状態で、かりにプログラムの分岐をテストしたとしても、その正当性がない（つまり、そこで分岐させること自体が正しいかどうか、わからない）。

---

　こうすると、お客さんが、ユニットテストを採用したとき、どの基準で、このテストを実行したのかについて、明確に答えられる。そして、上記のように、ユニットテストになった理由も説明できる。

　しかし、こういうことは、ブログにかかれない。

　なぜか。

　昨日わかった。

　昔の話や、システム全体の話を持ち出すと、アクセス数が減るのだ。

　昨日、ＥＡやＩＴＩＬの話しかかかなかったら、アクセス数が激減した。
　StrutsやＯＳＳネタだと、アクセス数が増える。
　したがって、昔の、Ｃ０，Ｃ１，Ｃ２の話をしても、アクセス数はふえないことが予想される。

　だからきっと、みんな、テストというと、JUNITとか、Assertの話とかしか、しないわけね。

　なっとく。

---

　ということで、今日は、新たな手を使ってみた。
　表題に、昔の話を持ち出すとは書いていない。

　いかにも、今のブログでありそうなネタだ。

　これでアクセス数が。。。ふえるかなあ（＾＾；）

　つーか、こんな手を使ってたら、みんな、見てくれなくなったりして
（＞＿＜！）

プロジェクトの原価計算方法を、会計・簿記的に考えてみる

　唐突ですが、プロジェクトの原価計算方法を、会計・簿記的にかんがえてみます。
　そうすると、この原価計算方法は、普通は、個別原価計算となります。
　（ABC(Active Based Cost)でもできるだろうけど、一般的には、個別原価計算）

　プロジェクトを個別原価計算に適用する場合、収益（収入）は、このプロジェクトの収入＝売上となります。

　費用は、一般に（個別、総合とも）原価計算では、そのもの（プロジェクトの場合プロジェクト青果物のプログラム）に直接かかる直接費と、そうではない間接費にわかれます。

　なお、固定費と変動費というのがありますが、この区分とは違います。
　変動費はかならずしも、直接費とはいえませんが、間接費は、ふつう固定費です。

　間接費は、製造間接費としてまとめられますが、直接費には、３つあります。
　直接材料費と、直接人件費と、直接経費です。

直接材料費＝そのプロジェクトで使った材料。
　　　　　　紙のお金？？ふつう、ここにたつお金は小さい。
　　　　　（使い捨てのものが材料になる場合はそうではない）

直接人件費＝社員にかかる人件費
　　　　　　会社が支払う金額、つまり、給与＋会社負担の福利厚生費などなど

直接経費＝外注費、特許料など。

---

　製造間接費は、このプロジェクトに直接関係のないお金、言い換えると複数のプロジェクト、場合によっては全プロジェクトにかかわるお金です。

　つまり、総務部のおねーさんの給料などです。

---

　直接費は、プロジェクトごとに割り当てることができますが（というか、割り当てることが可能なのが直接費）、間接費は、割り当てられないので、割り当てる基準を作って、各プロジェクトに割り当てます。この基準を配賦基準といいます。

　配賦基準として、売り上げや利益は普通、「使いません」
　なぜなら、このようなものを使ってしまうと、儲かっている優良プロジェクトから大きくお金をひいてしまい、困ったちゃんプロジェクトは、お金がひかれなくなり、困ったちゃんの困り具合が加減されてみえてしまうからです。

　配賦基準は、プロジェクトの人数やプロジェクト担当者の時間をもとにする方法が普通かと思います。どちらのほうが、適切な配賦基準かは、ケースバイケースであり、まあ、どっちでもいいのですが、なにかきめたら、変えないことです。

　変えてしまうと、その部分が不連続になり、正しく比較できなくなります。

---

　なお、これらの資料は、管理会計の分野に属します。

　つまり、税務署に見せるためのものでもなく、また、上場してたとしても、有価証券報告書作成に必要なものでもありません。そのため、ある程度会社で自由にできます。

　そこで、あるものが、直接材料費、直接人件費、直接経費、製造間接費のどれになるのか悩んだ場合は、別に深く考えることなく、決めてしまっていいことになります。

　たとえば、マシンをリースにしたとき、直接材料費？直接経費？製造間接費？となりますが、
　マシンはすべて製造間接費としているなら、ほかのものとの比較をしやすくするために、製造間接費にしてもいいし、いや、リースで、ほかに使い道がまったくないので直接材料費というのなら、直接材料費にいれてもいいです（ただ、自社で買ったものは、製造間接費にいれて、減価償却している場合、このプロジェクトだけ、直接材料費が多く出てしまい、比較しずらいです）。

---

　プロジェクトに追加発注が出たりしたような場合、その追加部分だけを分けるのが普通です。
　たとえば、受注ＮＯ１９１番に、追加仕様が出た場合、１９１－１として、追加分を管理するのが普通です。ただし、どこからが追加分で、どこからが今までの仕様のものかわかりにくい場合は、そんなに厳密にやらなくても。。。管理会計なのでゆるされる範囲かと。。。

---

　うーん、情報処理試験で、プロジェクトの原価計算がでないのは。。
　上記のように、結構話がかんたんだからかなあ。。
　難しい問題が作れない。。

コンピューターからアニメの時代になったんだね。専門学校の名前変更をみておもった。

　（東京の山手線）新宿から池袋に行く間に、
「東京アニメーション専門学校　申請中
（現 東京コンピュータ専門学校）」
ってかいてある、看板つーか、学校をみつけました。
この学校です。

もはや、時代は、コンピューター、ＩＴでなく、アニメの時代なんだね。

やっぱ、日本の基幹産業は、アニメになったんだよねえ。。

そのうち、「ＩＴ寵児」の時代なんていう言葉は古くなって、「アニメ寵児」の時代になり、

韓流で、コリアンの言葉が人気だったのが、ゆうこりんの「コリン星」の言葉（こりん語）が人気となり、

六本木ヒルズより、秋葉原が時代の重要スポットに、


・・・もう、なってるか？

公衆無線ＬＡＮの会社が複数あって、おなじ地域をサポートしたら、干渉して使えなくならないの？

　無線ＬＡＮ無知なウィリアムのいたずらなので、大ボケのことをいってるかもしれませんが、素朴な疑問です。
　ここを見て、思ったのですが、

今、ライブドアが無線ＬＡＮを進めてますが、同じように無線ＬＡＮに新規参入してくる新興会社が、（仮に）あったとします。

１．ライブドアの無線ＬＡＮが六本木ヒルズでできるように基地局をおいたとします。
２．ほかの新興会社も、無線ＬＡＮが六本木ヒルズでできるように基地局をおいたとします。

　さてこのとき、ライブドアと契約している人が、六本木ヒルズで無線ＬＡＮを使おうとしたとき、どーなるんでしょう？ちゃんと、ライブドアのほうが使えるんでしょうか？新興会社のほうがはいっちゃうこともあるんじゃないかなあ。

　そーすると、ですよ、そのライブドアと新興会社は、自分の無線ＬＡＮを使えるように基地局をいっぱいつくっちゃったら。。こまったちゃんになるのは、六本木ヒルズに入っている、無線ＬＡＮを引こうとしている会社ですよね。その会社も、自分の無線ＬＡＮを引こうとしても、ライブドアの無線ＬＡＮが干渉してしまい（＞＿＜！）ってなことに、ならないのかなあ。。。

　これって、こまりますよね。

　つーか、個人や会社で使うのに無線ＬＡＮを使うのなら、無免許で、出力を絞ってやればいいと思うけど、公衆の無線ＬＡＮの場合、ある程度出力を出して、そのかわり一般の無線ＬＡＮとは違う周波数を使って、会社ごとに周波数割り当てをして、免許制にしたほうがいいと思うんですけどお。。（無線従事者は必要かどうかは別問題として）

　そのへん、どーなのどーなの関東総合通信局さん！

Ｐ．Ｓ　この記事を書いてるときにＮｅｗｓ１０みてたんだけど、

羽田空港で電波障害、米軍と「同じ周波数を」使ってたあ。。

。。。大丈夫か、関東総合通信局さん。。

この電波で、たぶん、送信もしてるんだろうから、飛行機に影響あったって言うことは、米軍のほうにも、場合によっては影響あるかもっていうことでしょ！

　米軍は、しんしに対応するといってるそうだが、そりゃそうだろ、一歩間違えれば、自分たちにも、影響あるわけだから。。。

　無線ＬＡＮよりも、そっちのほうが、よっぽど大事かも。。

RFPのテンプレートをマイクロソフトが無償で配っているというけど。。

　マイクロソフトが、ＲＦＰのテンプレートを無償で配っているようです。
ここ

この前のブログにＥＡについて書いたけど、その関連で言うと

（斜体は、その記事の引用、以下同じ）

また、政府の「業務・システム最適化計画策定指針（ガイドライン）第4版」を補完する意味で、ガイドラインの各章と「簡単！RFPテンプレート」の対応表がまとめられているほか、総務省や経済産業省が発表しているEA（エンタープライズアーキテクチャ）関連の資料を参照し、「補助金業務」「物品調達」「旅費業務」といった実際の業務最適化計画をテーマに作成されたサンプル集も収録されているという。


でもね、


簡単！RFPテンプレートは、マイクロソフトとMPUF（マイクロソフト プロジェクト ユーザーズ フォーラム）が共同で作成しており、同日よりMPUFの会員向けに無料で配布される。

＊注：同日＝１０月１４日

なんだって。

会員っていう、特定の人にしかみれないところに、公表したって意味なし！
（はい、どっかの文に、インスパイアされて、書いてみました）

CMMIモデルの、公式日本語翻訳版のありか

ＣＭＭＩを、ＩＰＡが翻訳していて、それがおいてあるところのありか

ここ
http://www.sei.cmu.edu/cmmi/translations/japanese/models/index.html