実践的オブジェクト指向設計入門11

　この記事は、実践的オブジェクト指向設計入門10の続きです。前回は、オブジェクト指向設計の概要を解説しました。今回は、オブジェクト指向設計の作業のうちのひとつ、3つのモデルを組み合わせるを解説します。
　オブジェクト指向設計で最初にする作業は、オブジェクト指向設計で作成した3つのモデルである、オブジェクトモデル、動的モデル、機能モデルをよく確認し、それを元に設計したシステムをどの様に実装するのか考えます。オブジェクト指向方法論OMTでは、オブジェクト指向設計の前にシステム設計をしています。それで、分析結果と合わして考えるという事です。
　この際、中心となるモデルはオブジェクトモデルとされています。分析段階のオブジェクトモデルは、得てして操作が足りませんので、動的モデルを元に判明した動作、および機能モデルで判明したプロセスを変換し操作を追加します。
　オブジェクト指向方法論OMTでは、状態図を用いて解説がされています。ですが、現在はアクティビティ図の方が適切なので、アクティビティ図に置き変えて解説します。最初はアクションに注目します。アクションは操作に変換しやすいです。ただし、分析段階のアクションは抽象的な物なので、1つの操作で実現できない事の方が多いです。そこで、アクションを分解する事を考えます。
　アクションはサブアクティビティに分解できます。例えば、原材料の調達という一つのアクションでも、購買部門・会計部門・生産管理部門など複数の部門に渡ってアクションとデータが存在します。そうした細かいビジネスプロセスは複雑なので、サブアクティビティ図を任意の段階まで書きます。この時問題となるのは、どこまで具象化するかです。
　アクティビティ図を具象化しすぎるとフローチャートと同様になってしまいます。フローチャートレベル（実装）ともなれば、プログラミングした方が早いし、プログラマーの裁量範囲を狭めてしまいます。それは悪妙高きマイクロマネジメントになってしまいます。従って一般的には、余り具象化しない方が得策だと言えますが、会社の事情によってはそこまでする必要があるかもしれません。その辺のバランスは、会社の実情と開発体制をよく加味して考えましょう。
　システム設計の結果とアクティビティ図を詳細に検討していくと、状態をどの様に扱うのかが課題となってきます。その他にも、複雑な流れをどの様に管理していくのかなどの課題が露呈します。そこでオブジェクト指向段階では、状態を管理するオブジェクトなどの情報技術特有のオブジェクトを考える必要があります。それは次の作業で解決します。
　

中の人の徒然草402

久し振りに日記を書きます。ここ最近、生活保護に関する議論が活発化しているようです。その件で私は色々な疑問を感じました。
　一番最初に疑問に感じたのは、国会議員が個人を名指しで批判していいのかどうかです。週刊誌の情報を元に個人にああいう事をしてよいのでしょうか。政治家は公人なので慎重に調べてから発言するべきです。また国会議員なのですから、個人レベル問題を考えるのではなく、国家レベルで物事を考えるべきです。
問題視されている芸能人については、謝罪会見して返納する事が決まったのでもう興味はありません。それよりも問題なのは、自民党は一体何をしていたのかという点です。何十年にも渡り、生活保護制度について何もしてこなかった議員達は高い報酬を得ていてよいのでしょうか。個人的には議員報酬の返納を希望します。
あとそれと、国会議員の身内（3親等内）に生活保護受給者がいなかどうか気になります。芸能人が返納したのですから、万が一身内に生活保護受給者がいれば、国会議員ももちろん謝罪の上に返納するべきですよね。他にも色々気になる点があります。
ですが、些細な事はどうでもいいです。国民のセーフティネットシステムがまともに考えられていない事を一番問題視します。年金で生活できない人はいます。ワーキングプアもいます。餓死している人もいます。餓死する前に自殺する人もいます・・・それら全ての根本的問題は議論されないままです。
恐らく国会議員にはこの手の問題を解決する意思がないでしょうし、仮に意思があっても問題処理能力が低いので、この問題を任していても何も進展が無いと思います。何故ならば、戦後60年以上何もしてこなかった輝かしい実績があるのですから・・・
この点から私は思うのですが、選挙が受かった時点で固定の報酬が支払われる報酬システムがおかしいと思います。私達民間人は能力主義で報酬が決まります。選挙は一種の就職活動であり、当選しただけで報酬が決まるのは何時の時代の報酬システムだと思えてなりません。何も決められない人に、多額のお金を掛けて就職活動させ、何も実績を挙げていないのに1億円近い血税を費やす。現状は本当に馬鹿げています。
ただ、私は政治家も可哀そうだと考えています。というのも、政治家と言う曖昧な職業で、能力も評価されないまま仕事をしなければならないからです。政治家にも優秀な人もいれば、そうでない人もいます。報酬が同じとなれば、誰でも真面目に働く気がなくなるでしょう。それに加えて、職業の定義曖昧なので仕事の範囲が広すぎます。全ての問題に精通したスーパーマンは居るのでしょうか？
思えば我々国民にも責任があります。現状は日常的に発生する問題の解決をお上任せにしすぎです。大人なんですから、自分たちで解決できる問題は自分たちで解決する事を前提にシステムを再構築する必要があります。国家システムは、国家レベルで発生する問題を解決するためのシステムだと言えます。従って、国家システムというものを真面目に考えると、今の状態では何も解決できないのは当たり前なのです。
問題処理システムとしてみた場合、普通に考えて問題発生数＜問題処理能力にならないと駄目な訳ですから、ちんたらと選挙して会議をする人を決めて、その人達が問題を解決するのを待っているだけでは破綻して当たり前です。現在の国家システムは、システムとして呼べる代物ではありません。仕様段階で間違っています。例えるなら、Windows95未満です。MS-DOSに近いレベルと言えます。
私達システム屋は、最近では1週間単位で問題を解決する事を求められています。そして、問題が発覚したら数時間（遅くて2・3日）で修正する事を求められます。そんな私からしてみれば、今の国会システムは全ての事が遅すぎます。法律に問題がある事が発覚したら、その日に修正するぐらいでないと駄目です。それぐらいの処理能力が無ければ、複雑化する社会を維持する事は出来ません。このままだと、問題処理能力が無い（スペックが不足している）のですから、国家が破綻もしくは衰退するのが目に見えています。
政治家だけに任せていても解決する筈はなく、このままだと日本崩壊が目に見えています。国家レベルの問題を処理するシステムを、一から考えないとならない時期に来ていると思います。その為には先ず我々国民一人一人が、社会問題や国家ビジョンを考えなくてはなりません。お上任せで物事が良くなるという考えは、原発で崩壊した安全神話と同じなのですから・・・

ネタつつき128 - 技術者がしがちなコミュニケーションミス

　コミュニケーションについて何度か書いているので、技術者に特化した注意点を書く事にしました。残念ながら私達技術者は、他の職業の方からしてみればおかしな行動を無意識にとっております。それを知っておけば、コミュニケーションをより上手く取れるようになるでしょう。
　技術者にありがちなコミュニケーション上のミスは、不適切な場面で知識を披露する事です。たとえば、エンドユーザーの方が情報技術に関する勘違いをしていたとします。この時に、不用意に間違いを指摘する技術者が結構います。技術に生きる私達にとっては見過ごせない事ですが、冷静にエンドユーザーの気持ちを考えてみましょう。
　エンドユーザーにしてみれば、情報技術なんてよく分からない事ですし、対して興味もない事です。でも、雑誌か何かで知った時、その用語を使いたくなるものです。最近では「クラウド」や「Web2.0」（ちょっと古いかな）がこれに該当するでしょう。文章では分かり難いので、会話を例にしてみましょう。

【問題がある会話の例】
エンドユーザー「Web2.0というだけあって、最近は凄い世の中になったな。
　クラウドとかいうやつで、何でも使い放題なんだろ？」
技術者「Web2.0？・・・
　それは、パブリッククラウドの事ですか？
　それともプライベートクラウドの事ですか？」
エンドユーザー「それは何だ？よくわからんが、
　　クラウドを使えばソフトを使いたい放題と聞いた。
　もうソフトなんて買う必要が無いな。
　それと、データの保存場所にも困らんそうだが・・・」
技術「何を持って使いたい放題と仰っているのか分かりませんが、
　きっとDaaSやSaaSの事ですよね？
エンドユーザー「？？？クラウドって色々あるのか？」
技術者「はい、色々あります。
　よろしいですか？クラウドとは曖昧なもので、
　定義をはっきりさせておかないと・・・」
エンドユーザー「もう結構だ！」

分かりやすいように強調して書きましたが、専門用語の言い間違いを訂正したりする人が結構います。技術者にとって定義はきになるでしょうが、状況を冷静に考えましょう。この例は明らかに、「近頃は技術の進歩が速い」と「便利な世の中になった」と言いたいだけです。クラウドやWeb2.0という用語に反応する必要ありません。それにも拘らず、技術者が細部にこだわったので、エンドユーザーの面目が丸つぶれです。たかが雑談で相手（素人）を言い負かして何になるのでしょうか？子供じみた行為に映るので、聞き手にまわり会話を広げるようにしましょう。

【先の例よりもよい会話の例】
エンドユーザー「Web2.0というだけあって、最近は凄い世の中になったな。
　クラウドとかいうやつで、何でも使い放題なんだろ？」
技術者「よくご存じですね。」
エンドユーザー「いやいやそんなことないよ。
　俺もコンピューター音痴ではいかんと思って、
　ちょっと勉強しているだけだ。」
技術者「○○さんは凄いですね。
　新しい事をどんどん吸収しておられる。
　なかなか出来る事ではないですよ。」
エンドユーザー「そんな事はない。君にしたらちょっとした事だろ。」
技術者「そんな事はありません。私もクラウドを最近知って吃驚しました。」
エンドユーザー「そうだろ。俺も驚いたよ。
　俺の若いころは、インターネットすら無かったからな。」
技術者「ええ。私もこんなものが発明されるなんて想像出来ませんでした。」
エンドユーザー「ああ。技術の進歩は速いな。
　俺みたいな年寄りは訳が分からんよ。」
技術者「そんな事はありません。
　○○さんは現にクラウドを知っているではありませんか。
　○○さんならば、なんだかんだいってついていくと思います。」
エンドユーザー「そうか」

まだまだ十分な対応とは言えませんが、先ほどの例よりもましになっています。エンドユーザーの面目を潰さず、会話を広げるように努力しています。
　技術者は、場をわきまえず些細な事を気にしたり、知識を無闇に披露したりする傾向があります。ですが、本来コミュニケーションは、論争をするためのものではありません。無闇に自分の知識を披露し、相手に恥をかかせて自己満足する為のものではないのです。コミュニケーションは、相手と円滑に交流するために行います。従って、常にその場の状況をよく把握し、相手を見て適切な言葉を選び、適切な態度を取る必要があります。
　貴方は「理屈っぽい」だとか「面白くない」だとか「嫌味な奴だ」などと言われた事がありませんか？少しでも心当たりがある方は、コミュニケーション本来の目的を思いだし、自分の言動がその場にふさわしいものかと、相手の気持ちをよく考えましょう。初めは上手くいかないかもしれませんが、今よりも確実に上手くなります。口下手な私でもある程度上手くやっております。恐れずにコミュニケーションをとりましょう。

真正性をつつく8（最終回） - 今までのおさらいと総括

　この記事は、真正性をつつく7の続きです。前回は、セキュリティテストについて解説しました。今回は、今まで解説してきた事をおさらいします。
　7回にわたり認証について解説してきました。しかしながら、セキュリティを考慮したシステムを作った経験がある人しかピンとこないかもしれません。そこで、自称・営業部長山田太郎（もちろん仮名）の例を元におさらいする事にしました。

【会社のホールにて】
謎の男「済みません。ちょっとよろしいですか？」
掃除婦「はい。」
謎の男「研究開発室に用があるのですが、ご案内頂けますか？」
掃除婦「申し訳ございません。当社では案内は受付係を必ず通す事になっております。
　　　　受付ならば案内する事が出来ますが、如何でしょうか？」
謎の男「いえ、結構です。受付の場所ならば知っています。」
掃除婦「分かりました。」

【会社の裏口】
裏口を勝手に通過しようとする謎の男
警備員「お待ちください。」
謎の男「何ですか？私は社長の許可を得ているのですが・・・」
警備員「お手数をおかけしますが、当社はセキュリティ上の都合で、
　　　　　たとえ社長であろうと裏口は通れない事になっております。」
謎の男「なんだと！では、何のために裏口があるのですか？」
警備員「裏口は火災・地震時等の緊急避難のための通路です。
　　　　　誠に申し訳ございませんが、受付で正規の手順を踏んで下さい。」
謎の男「そんな事はきいていない。今度からそうするが、
　　　　　今回は緊急の用事なのでこちらを通過させてもらうよ。」
警備員「連絡に不備があった事はお詫びいたします。
　　　　　ですが、お客様や関係者の皆様からお預かりしている貴重な情報があります。
　　　　　皆さまにご迷惑をおかけしないために、
　　　　　当方はセキュリティ対策をしなくてはなりません。」
謎の男「そう、堅い事はいうな。社長とは長い付き合いがある。」
警備員「常日頃お世話になっております。関係者の方ならば、
　　　　　当社がセキュリティ対策の実施を、
　　　　　半年前から何度も通知しておりますので、よくご存知だと思います。」
謎の男「そういえば、そんなこと言っていましたね。
　　　　　これは失礼しました。既に実施しているとは知らなかったもので・・・」
警備員「お気になさらないでください。ご不便をおかけします。」
謎の男「分かりました。受付に行きます。」

むむ、怪しい人が会社にやってきました。色々な事を言っていますね。でも、認証対象となるオブジェクトが、どんな事を言ってもルートを一本化するために、必ず規定の場所に誘導せねばなりません。その為には、あらゆる人に徹底してセキュリティ教育をせねばなりません。ただし、極力相手に不快感を与えないように努力する必要があります。その辺の教育も必ずしましょう。セキュリティ対策は教育が命です。

　引き続き、謎の男の動向を見てみましょう。

【受付にて】
謎の男「ちょっと、済みません。研究開発室に行きたいのですが・・・」
受付嬢「はい、研究開発室への入室ですね。お名前を伺ってもよろしいでしょうか？」
謎の男「別にかまいませんが、何故名前を聞くのですか？」
受付嬢「入室には許可が必要となっておりますので、
      お名前を教えて頂かない事にはお通し出来ません。」
謎の男「分かりました。山田です。」
受付嬢「どちらの山田様でしょうか？」
謎の男「○○商事の営業部長山田太郎です。」
受付嬢「有難うございます。只今、アポを確認いたしますので、5分ほどお待ち下さい。」
山田太郎「緊急の用件なのでアポはとっていません。」
受付嬢「ご安心ください。
　　　　　当社のシステムは全ての取引および関係者が記録されていますので、
　　　　　お名前でチェックできます。5分ほどお待ちください。」

セキュリティ対策にはストレスがつきものです。ですから、ただ闇雲に拒否をするのではなく、相手の便宜を図るシステムの機能も作らねばなりません。この場合訪問者に、セキュリティ対策をしない時と比べて、アポ無しでも何とかなるという利点があります。訪問者を全て追い返す会社には誰も来なくなります。セキュリティ対策が会社の利益を損なわないように十分に注意しましょう。

　今度はセキュリティ実施側の視点を書きます。

受付嬢（　こんな時は、訪問者管理ソフトでチェックするのよね？
　　　　　　えっと、山田太郎で検索・・・あれ？超～ビックリ、山田太郎氏が何人もいるわ。
　　　　　　こんな時は絞らないと・・・うーん、○○商事で絞り込んでも2人居るわ。
　　　　　　2人の顔を知っている人を呼ぶ必要があるわね。
　　　　　　連絡先は、研究開発室の真田さんね。電話しないと・・・）
受付嬢「もしもし、真田さん。今ロビーに○○商事の営業部長太郎さんが来ています。　　　
      アポなしですし、開発部にも同姓同名の人がいますので、認証お願いできますか？」
真田「分かりました。でも、ちょっとおかしいな。
　　　今のところ、山田部長が来る要件なんてないな。
　　　ロビーに警備員も呼んでもらえるかな。」
受付嬢「分かりました。警備員を呼びますので、今から2分後にロビーに来て下さい。」
真田「了解しました。ところで要件は？」
受付嬢「済みません。要件は緊急としか仰っていません。」
真田「緊急？？？分かりました。その件も含めてチェックします。」

セキュリティでは色々な事を考えなくてはなりません。この場合、山田太郎氏は本当に本人なのでしょうか？なり済ましの恐れがあります。また、たとえ本人でも怨恨による犯行も考えられますので、用心に越した事はありません。そうした連絡体制を取るのもセキュリティ対策の一環です。

　では、その結果を見てみましょう。

【警備員が見廻りをするロビーにて】
真田「山田部長。お待たせしました。」
山田太郎「おお、お久し振り真田君。」
真田「お世話になっています。あれ？営業部長の方だと伺っておりましたが・・・」
開発部長山田「済まん。嘘だ。」
真田「なぜ、その様な事を・・・」
開発部長山田「うちが作ったシステムが上手く動作しているか気になってな。」
真田「お気づかい有難うございます。
　　　　セキュリティ対策についてどう思われましたか？」
開発部長山田「まだ、たどたどしいな。それと、全般的に甘いな。」
真田「と、いいますと？」
開発部長山田「今この場で君を刺しても、この距離では警備員は間に合わないだろう。
　　　　　　　　　自分で言うのもなんだが、こんな怪しい男、もっと警戒してもいいと思うぞ。」
真田「そこまでは考えていませんでした。面目ないです。」
開発部長山田「うむ。それと、君は本当に真田なのか？」
真田「御冗談を。本物ですよ。」
開発部長山田「今さっき、ロビーに入る時、何のセキュリティチェックもしていなかったな。」
真田「ええ。出勤時に認証チェックをしていますから。」
開発部長山田「内部セキュリティが甘いな。それだと、一回突破されたらおしまいだ。
　　　　　　　　　認証は多重チェックが基本だと前にも言っただろ。」
真田「ええ、仰るとおりです。」
開発部長山田「それに、そもそも○○商事というのも嘘だった場合どうするつもりだ。」
真田「そこまでは考えておりませんでした。どうしたよいものやら・・・」
開発部長山田「まだまだだな。当社が最近開発した認証セットがあれば解決するぞ。」
真田「相変わらず商売上手ですね。」

この基本的な例（面白くなるように味付けてしています）を見れば分かって頂けると思いますが、セキュリティ対策は考えるべき事が沢山あります。また、絶対に完璧な状態になる事はありません。それに加えて、真正性は情報セキュリティの一部でしかありません。真正性単独ではセキュリティホールがあり過ぎます。他の性質と共に考えねばなりません。
　他にも色々解説するべき事がありますが、あまり長すぎると退屈だと思いますので一旦終わりにします。また近いうちに解説しますのでちょっとだけご期待下さい。

初心者のためのC#プログラミング本格入門72 - 悩む暇があったら反復的に学習をしよう

　この記事は、初心者のためのC#プログラミング本格入門71の続きです。前回は、テストを通じた学習のやり方をまとめました。今回は、プログラミング習得の心得を解説します。
　私は何度も「プログラミング本を読んだけども実際に出来ない」という悩みを持つ初心者の方と出会いました。そうした悩みを持つ初心者の方は、「自分には才能がない」、「理解力が足りないのだろうか」、「やはり文系は駄目なのか」・・・といった心境になるそうです。ですが、心配要りません。実際にプログラミングが出来ないのは、貴方の能力や適性の問題ではありません。
　プログラミングをやる人は理系の人だという誤解があるようですが、そもそも文系／理系なんて分類自体がナンセンスです。学問はそれほど単純ではありません。人類が積み重ねてきた英知を2分割にできません。プログラミングはプログラミングなのであって、○○系なんてものはありません。また、繰り返しになりますが才能云々は直ぐに答えを出すほど簡単ではありません。理解できないのはそういった問題ではなく、単純に何事も繰り返さないと習得できないだけです。歴史に名を残すほどとなると才能が必要でしょうが、普通にちょっとしたプログラミングするだけならばだれでも出来ます。現にハッカーでもプロでも繰り返し学習をしています。一度で全てを完璧に習得し、永遠にその状態を維持する事なんて人外の天才でなければできないでしょう。悩むなんて時間の無駄。余計な心配はせずに反復的に学習しましょう。
　復習を兼ねて、前回のテスト「CalculateSimpleExpression」と、計算処理の「Calculation」メソッドについて考えてみましょう。今のテストは実行できるか否かを確かめるためのものであり、大した意味はありません。この様なテストですと、前回述べたように「return 110;」でもパス出来てしまいます。AnalyzeSimpleExpressionの時と同様に改良しましょう。
　改良のポイントは、テストに網羅性があるのかという点と、特徴ある値(最大値、最小値、中央値など)をチェックできているのかという点です。この2点を盛り込んだテストにするには、先ずは今のテストコードを整理して準備します。一度に全てをやろうとしては駄目です。段階を踏む事が肝心です。具体的には、テスト値が変わっても大丈夫な様に、新しいメソッドに汎用的なコードを抜き出します。

class MultiAnalyzerTest
{
    //※他のプログラムは省略

    //簡単な式1つの計算処理をチェックする
    public void CalculateSimpleExpression()
    {
        int value1 = 10;
        int value2 = 100;
        CalculateTest( value1, value2 );
    }

    //計算処理をチェックする
    private void CalculateTest( int value1, int value2 )
    {
        string inputValue = value1 + " + " + value2;
        this.target = new MultiAnalyzer();
        this.target.AnalyzeExpression( inputValue );
        float result = target.Calculation();
        float rightValue = rightValue = value1 + value2;
        if ( rightValue != result )
        {
            System.Console.Write( inputValue + 
            　　　　"の計算処理が正しくありません。" );
            System.Console.Write( " 正しい値：" + rightValue );
            System.Console.WriteLine( " 処理結果；" + result );
        }
    }
}

コードを変えたらすぐに実行してみましょう。ブレークポイントをCalculateTestメソッド内のコードに設定し、デバッグ実行をすると、テストが実行されている事を確認できます。
　これでひとまず安心ですが、現在のテストは演算子の部分に問題があります。今のままでは足し算しかチェックできていません。どの演算子でも大丈夫なように自分で改良してみましょう。

class MultiAnalyzerTest
{
    //※他のプログラムは省略

    //簡単な式1つの計算処理をチェックする
    public void CalculateSimpleExpression()
    {
        int value1 = 10;
        int value2 = 100;
        CalculateTest( value1, value2, '+' );
    }

    //計算処理をチェックする
    private void CalculateTest( int value1, int value2, char sign )
    {
        string inputValue = value1 + " " + sign + " " + value2;
        this.target = new MultiAnalyzer();
        this.target.AnalyzeExpression( inputValue );
        float result = target.Calculation();
        float rightValue = 0;
        switch ( sign )
        {
            case '+':
                rightValue = value1 + value2;
                break;
            case '-':
                rightValue = value1 - value2;
                break;
            case '*':
                rightValue = value1 * value2;
                break;
            case '/':
                rightValue = value1 / value2;
                break;
            case '%':
                rightValue = value1 % value2;
                break;
        } 
        if ( rightValue != result )
        {
            System.Console.Write( inputValue + 
            　　　　"の計算処理が正しくありません。" );
            System.Console.Write( " 正しい値：" + rightValue );
            System.Console.WriteLine( " 処理結果；" + result );
        }
    }
}

これで、任意の値と演算子を指定できる計算処理のテストが出来上がりました。
　準備が出来たので、AnalyzeSimpleExpressionテストを参考にして、よりよいテストに改良します。

class MultiAnalyzerTest
{
    //※他のプログラムは省略

    //簡単な式1つの計算処理をチェックする
    public void CalculateSimpleExpression()
    {
        //テストデータを準備
        char[] signs = new char[] { '+', '-', '*', '/', '%' };
        int[] values = new int[] 
        { 
            int.MinValue, int.MinValue + 1, int.MinValue / 2, 
            0, int.MaxValue / 2, int.MaxValue - 1, int.MaxValue
        };

        //全演算子と主要な数値の組み合わせをチェック
        foreach ( char sign in signs )
        {
            foreach ( int v1 in values )
            {
                foreach ( int v2 in values )
                {
                    this.CalculateTest( v1, v2, sign );
                }
            }
        }
    }
}

このテストを実行すると・・・動作が停止して怪しいダイアログボックスが表示されます。これでプログラムが間違っている事が分かったので、このダイアログボックスはひとまず閉じて、何が間違っているのかを考えます。次回へ続く・・・

真正性をつつく7 - クラッキング方法を考えよう

　この記事は、真正性をつつく6の続きです。前回は、認証オブジェクトについて解説しました。今回は、次の段階であるセキュリティテストについて解説します。
　今回までいくつかの段階を踏んできましたが、それでもまだ不十分です。仕上げとして、セキュリティテストを行う必要があります。その一環として有効なのは、クラッカーとして考える事です。人は自身が行った対策について甘く評価する性質があります。そこで、クラッカーになったつもりで考えなくてはならないのです。
　クラッキング技法としては、システムに対する攻撃はもちろんの事、人間の盲点を突くソーシャルエンジニアリングの手法も視野に入れます。実際のところ、セキュリティホールとなる確率は、コンピューターよりも人間の方が高いです。人間は錯覚する生き物であり、騙されやすい精神構造をしています。セキュリティテストと呼ぶと、プログラミングの方を思い浮かべがちですが、人間は騙されやすいという重大なセキュリティホールを見逃しては真の意味でセキュリティ対策にはなりません。
　何故人間は騙されやすいのかと言いますと、人間は五感から送られてくる情報を脳の処理で補完しているからです。従って、マジックの様な視覚的トリックや、詐欺師たちが使う言葉による誤認識が可能となってしまいます。一説によると特に日本人は騙されやすい精神構造をしているそうです。それは、馬鹿という訳ではなく、人が良いのが原因です。人が良い事は生存に於いて有効に働きます。親切さが求められるビジネスの世界では特にそうです。しかしながら、クラッカーたちはその親切心を利用します。親切に振舞う事によりクラッカーは、クラッキングする為の情報を取得し、クラック行為を成功させてしまいます。
　では、全てを疑えば良いのかというと、そうではありません。ビジネスをしている以上、全ての人間を疑い人でなしになるという手段はあり得ません。セキュリティと言うと、「全てを拒否すればいい」、「そもそもネットワークに接続するな」、「全ての人を追い返せ」などと極論を言う人がいますが、それではビジネスが成り立ちません。また、疑えば疑うほど、詐欺師は騙しやすいそうです。全てを拒否するのはただの暴論であり、セキュリティとは呼べません。セキュリティ対策とは、如何にしてシステムを安全に利用するかを考える技術体系であり、使わないというのは前提から間違っています。
　セキュリティテストは、プログラミング方面とソーシャルエンジニアリングの手法を使って、予告せず不規則に実施するのがベストです。良くある間違いは、セキュリティテストの日程を教えてしまって、普段とは違う行動を社員にさせてしまう事です。普段は面倒だと思ってしていないセキュリティ対策も、その日だけ正しく行うという可能性があります。これでは意味がありません。
　クラック方法を考え、実際にテストしてみる事により、セキュリティホールを発見と修正が出来ます。セキュリティ対策は考えておしまいとなるケースが多いのですが、実際の役に立たなければ意味がありません。考えて安心するのではなく、常に危険意識を持ってバージョンアップしていきましょう。ただし、セキュリティと利便性のバランス感覚を忘れないようにして下さい。セキュリティは強固にすればするほど、不親切で利便性が下がります。ビジネスをしているのですから、お客様や従業員といった人の事を忘れてはなりません。セキュリティ以前に、使えないシステムは意味がありません。その点を決して忘れてはなりません。

実践的オブジェクト指向設計入門10

　この記事は、実践的オブジェクト指向設計入門9の続きです。前回は、アーキテクチャとシステム設計の関係について解説しました。今回はいよいよ、オブジェクト指向設計段階の解説を始めます。
　オブジェクト指向方法論OMTが提唱するオブジェクト指向設計とは、システム設計で描いたモデルを具体化するための作業の事です。システム設計はあくまでもモデルであり、実装をするには抽象度が高すぎます。そこで、実装に取りかかる前に、実装の手掛かりとなるモデルを作ります。
　システム設計で描くモデルと、オブジェクト指向設計で描くモデルの最大の違いは、プログラミングに関するオブジェクトが出現する点です。分析段階では現実をモデル化し、システム設計段階で解決方法をモデル化しました。そのモデルに肉付けし、実装作業が出来るようにする訳です。
　ここに誤解が生じやすいのですが、プログラミングそのものではないので、細部まで設計するという愚を犯してはなりません。この点を誤解し、些細なことまで指示をする場面を何度も見かけましたが、細部まで設計するぐらいならば初めからプログラミングをした方が早いです。しかしだからと言って、何でも直ぐにプログラミングをすればよいという考えも間違っています。
　では、何故オブジェクト指向設計をするのかというと、いきなりプログラミングをすると大局が見えなくなるからです。プログラミングしている時の人間は、いわば虫眼鏡を掛けた状態になります。しかしながら、システム設計ではざっくりとしたものですので、虫眼鏡を掛けた個々のプログラマーが間違った方向へ行きやすいです。また、コードが重複するなどと言った非効率な事が起こります。そもそも、作業を連携するために集団で作業しているのですから、個人が勝手な行動をしては意味がありません。だからオブジェクト指向設計を行うのです。
　よくある誤解なので繰り返しますが、人間を管理する為のオブジェクト指向設計をしてはなりません。プログラミングレベルで物事を考えると大局を見失うので、実装と問題解決策（システム）とのギャップを埋め、プログラマーに方向性を示すためにオブジェクト指向設計を行います。
　概要はこれで終わりです。次回からは、オブジェクト指向設計の具体的な作業について解説していきます。お楽しみに♪

中の人の徒然草401

2・3日前に帝国データバンクさんが、「2012年は4月までに88件、過去最悪の水準で推移」していると発表しているのを知りました。一番最初に思ったのは「そりゃ当然だよな」です。日本のIT業界の構造は酷いもので、これまでもっているのが不思議なぐらいです。IT業界は本来技術を売り物にするのが当然なのに、丸投げと人月単価による人身売買の様な事をしているから、ビジネスとして駄目過ぎます。破綻するのは当たり前です。
胡散臭い会社に発注するぐらいならば、技術者に直接発注して自社開発する方がいいのに決まっています。そもそもシステム開発は少数精鋭でする方が早くて品質が高くなるので、多重下請け構造をしている時点で自殺行為だと言えるでしょう。まぁ、まともな会社も存在するとは思いますが、真面目に商売をしている会社は生き残っていると思います。
市場がまともに働いていればもっと倒産すると思います。ただ、下手な商売をした社長は自業自得ですが、真面目に働いている技術者の事を思うと胸が痛みます。それと、下請けいじめが常習化しているから、真面目で技術力がある会社が倒産しているかもしれません。それを考えると、人ごとではないから憂鬱です。
日本の会社はラベルに弱く看板だけできめる傾向があり、小規模ながら技術力がある会社や技術者個人を雇ったりする動きがあまり無いから、その先入観に基づく商習慣が事態を悪化させていると思います。不思議な事に、宝石や美術品は鑑定士に依頼するのに、情報システムの価値を鑑定してもらうという発想がないんですよね・・・
日本は理屈よりも空気でなんとなく行動する傾向があり、色々な弊害を生んでいます。おまけに日本政府は、下請けいじめなどの社会システムの不備を解消するつもりがなさそう・・・おまけに技術流出国家だしね・・・この調子だと、この情報化社会に日本はデジタルデバインド国家になりそうです。
ああ、何か日本には希望が無いな。この希望の無さが景気をさらに悪化させそうです。どうにかならないものだろうか・・・・

初心者のためのC#プログラミング本格入門71 - 不完全さと共に歩もう

　この記事は、初心者のためのC#プログラミング本格入門70の続きです。前回は、テストオブジェクトとテストの心得について解説しました。今回は、さらなるテストファーストの心得を解説します。
　現在、MultiAnalyzerオブジェクトの解析処理をプログラミングしました。次は、計算処理を行うプログラムを作ります。解析処理が完全ではない事を気にする人がいるかもしれません。ですが、その様な細かい事は考えずに前に進みます。先ずはその理由を解説します。
　プログラミングには色々な要素があります。ですがそれら全てを考慮していては前に進みません。これは、何でも反対する人を想像すると分かりやすいと思います。世の中には、何か新しいアイデアを出した人や、前に進もうとする人にケチをつけて何でも反対する人がいます。この手の人は、「○○だから駄目」と何でももっともらしい理由をつけて反対しますが、そういった人に従っていれば物事は前に進みません。何事でもそうなのですが、細かい事に拘り完璧にしないと駄目だという姿勢は物事を停滞させます。何故ならば、物事に完璧な状態はなく、プログラミングで完璧さを求めることなど不可能だからです。
　例えば、プログラミングに完璧さを求めると、OSを作れる程の知識と技術力、プログラミング言語そのものを作れる程の知識と技術力、ハードウェアを作れる程の知識と技術力・・・など永遠に学ぶべきものがあります。しかしながら、基礎的なプログラミングもできない状態で、OSやプログラミング言語を作れませんし理解も出来ません。従って、初めから完璧さを求めると矛盾が生じるので、不完全なまま学習をするしかないのです。
　アマチュアの人に限って色々言いがちですが、プロの人はあまりそういう事を言いません。何故ならば、実務では不完全なのは普通の状態だからです。仕事が始まった時点で、全ての仕様（作るべきものや機能など）が完璧に決定し、仕事をする時点でその事に関して、完璧な知識を持っていることなどありません。ですから、不完全さを前提に、徐々に完成させるように仕事を進めます。
　プログラミングの学習も当然初めから完璧な事はありえません。そもそも完璧な状態ならば学習が終わっており、学習する必要などありません。ですから、分からない事だらけだとしり込みせず、「学習している時点で知らない事があって当然」だと考え、積極的にプログラミングをしていきましょう。
　計算処理を作るには、ひとまずテストを考える所から始めます。早速テストを作ってみましょう。

class MultiAnalyzerTest
{
    //他のプログラムは省略
    
    //全てのテストを実行する
    public void ExecuteAllTest()
    {
        this.AnalyzeSimpleExpression();
        this.ErrorExpressionCheck();
        this.ErrorAndSuccess();
        this.AllErrorExpressionDelete();
        this.CalculateSimpleExpression();
    }
    
    // 簡単な式1つの計算処理をチェックする
    public void CalculateSimpleExpression()
    {
        int value1 = 10;
        int value2 = 100;
        string inputValue = value1 + " + " + value2;
        this.target = new MultiAnalyzer();
        this.target.AnalyzeExpression( inputValue );
        float result = target.Calculation();
        float rightValue = value1 + value2;
        if ( rightValue != result )
        {
            System.Console.Write(
                inputValue + "の計算が正しくありません。" );
            System.Console.Write(
                " 正しい値：" + rightValue );
            System.Console.WriteLine( " 処理結果；" + result );
        }
    }
}

テストを作り終えたら、ひとまずテストを実行（デバッグなしで実行 Ctrlキー+F5キー）してみましょう。まだCalculationメソッドをちゃんと作っていないのでエラーメッセージが表示される筈です。テストがちゃんと実行される事を確認するための作業ですからこれでOKです。
　さて、計算をするにはどうすればよいのでしょうか？その答えは簡単です。MultiAnalyzerオブジェクトはコンポジションオブジェクトなので、Analyzerオブジェクトに計算処理も任せましょう。複数の式を計算するのであれば、そう簡単ではありませんが、この簡単なテストをパスする事だけを考えるので、今は最低限しか考えません。
　できましたか？模範解答を見る前にプログラミングして下さい。

class MultiAnalyzer
{
    //他のプログラムは省略
    
    //計算式の計算結果を返す
    public float Calculation()
    {
        float result = 0.0f;
        foreach ( Analyzer analyze in analyzers )
        {
            result = analyze.Calculation();
        }
        return result;
    }
}

拍子抜けしたかもしれませんが、余計な事は考えないのがテストファーストの原則なのでこれでOKです。テストを増やせば自然と良くなるので、初めは「return 110;」の様なプログラムでもよいぐらいです。
　数回にわたってテストファーストとテストを解説してきたので、今まで解説してきた事を簡潔に纏めます。

【実践的なプログラミングの手順】
1. 簡単なテストを作る
2. エラーを出してテストが実行されている事を確認
3. テストを修正してより有効なテストにする
4. テストをパスする事を考えてプログラミング
5. テストがパスできなければ原因を考える
6. 原因からプログラムの修正場所を発見する
7. プログラムを修正してテスト
8. テストが成功したら直ぐに次の事を考える
9. 新しいプログラムを作るために1へと戻る

およその手順は以上です。この時のポイントは、一度に沢山の事を考えずに意識を集中させる事です。手を止めて色々考えるのではなく、気になる事があったら全てテストを作って試します。テストファーストとは、テストを通じて思考の集中と連続させるプログラミング技法とも言えます。
　初心者にありがちな失敗は、意識が集中しない事と、意識が連続しない事です。テストファーストを行って、効果的なプログラミング学習をしましょう。また、状況を考えない非現実的な完璧主義も学習の障害になります。完璧さを求めず、少しずつ覚えて生きましょう。気楽にした方が逆に高い学習効果を生むのです。

ネタつつき127 - 営業と技術職の不毛な争いは現代の縮図

　私はシステム屋として全ての工程に関わっています。その中で、各工程に従事している人達の争いを度々みました。これはよくあるコミュニケーションの問題であり、題材としてうってつけなので今回はこの話題を取り上げる事にしました。
　技術者と営業マンは意見が合わず、それが口論などの争いまで発展するケースがあります。争いまで発展せずとも、どうやら互いに不快感を持っている事が多いようです。先ずは両者の意見を分析してみましょう。
　技術者が営業マンに対してよく抱く不満は「技術が分かっていないから安請け合いしすぎる」です。納期に追われている技術者にとっては、開発中の製品に大きな仕様変更を伴うお客様の依頼は受け入れがたいものです。納期に間に合わない時に自社から責められるのは技術者ですし、成功しても自社からの評価がアップするわけでもなく、なにもいい事がありません。従って、技術者側の基本的な意見は、「技術的に重大な影響をもたらす追加依頼or仕様変更は断るべきだ」です。営業マンはそんな単純な事が分かっていないと、技術者は不満を感じているのです。
　一方、営業マンが技術者に対して抱く不満は「技術者連中は屁理屈ばかり並びたてて、商品を売る事を考えていない。売れなければ、どんな素晴らしい技術であっても意味はない。技術者は商売を分かっていない。」です。営業マンの評価基準は「物を売る事」です。従って、営業ノルマを達成するために、お客様の依頼は断れません。営業マンは技術者とは違って、製品がどうやって作られているのかではなく、「自社の商品やサービスをどうやっているのか」と「どうやって契約を成立させるのか」の2点に重点を置いています。営業マンが技術者に抱く考えは、「あの人達はオタク過ぎる。基本的なビジネスの知識と、ビジネススキルが不足している。」です。
　ここで問題なのは、部門間のコミュニケーション不足が原因で、互いに蔑視している事です。両者ともに自分の立場だけで物事を考えています。自分の立場だけで物事を考えていては、意見が合わないのは当然であり、いざこざが起こっても当然だと言えるでしょう。おまけに、互いに聞く耳を持たないので、永遠に真の和解をする事はないでしょう。
　両方の分野をまたがって仕事をしている私からしてみれば、両者ともに視野が狭すぎます。両者の意見は、その立場で考えれば正しい事であり、自分の立場で考えると考えは覆りません。両者ともに「自分は正しい。相手が無理解なのが原因だ。」と互いに罵倒している状態です。ですが、大きな視点で物事を見れば、そもそも争点がズレているので不毛なだけです。議論がかみ合っていないので、争うのは時間の無駄以外のなにものでもありません。本当の争点はどうやって利益を出すかです。
　この両者がするべき事は、意見の正しさに固執せず立場と結果を述べる事です。互いに「自分の正しさ」を基準に議論をすると争点が合わないので、平行線で終わります。そんな事をしても利益がありませんので、自分の立場と相手の立場を理解し、争点ではなく「協力できる部分」を探す事から始めなくてはなりません。実に単純な事です。この極めて単純な事に気付かず問題が発生しているのは、実力があるプロジェクトマネージャの不在が原因だと思います。その問題を突き詰めれば、最終的に経営者の実力不足が根本的原因だと言えるでしょう。
　この手の話題は枚挙にいとまがありません。それが故に私は、全体的に人々の視野が狭くなっているという気がしてなりません。巷にモンスタークレーマーがはびこり、会社側も短期的利益しか見ていません。政治家達は自分たちの利益しか考えず、あらゆる社会問題は解決されないまま放置されています。また、官僚たちも身の保身と天下り以外の事を考えていないように見えます。その一方で我々国民側も、自分の問題以外の事に関心すら持ちません。全ての人々が自分の立場でしか物事を見ていません。
　コミュニケーション不足は言われて久しいですが、ただ唱えているだけで解決されていません。この手の話題になると、マスメディア（もしかしたら一般大衆も？）は情報機器といった文明の利器を犯人だと決めつける傾向がありますが、道具が犯人な理由はありません。当然のことながら、人間が抱える問題の犯人は人間です。安易に犯人を作り上げ問題から目をそむけず、相手の立場を考えるという単純かつ難しい事をせねばなりません。それがコミュニケーションの基本であり、それが出来てこそ初めて「大人」もしくは「人」と言えると私は考えております。