無差別に技術をついばむ鳥

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

テーマ : ソフトウェア開発
ジャンル : コンピュータ

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

テーマ : ソフトウェア開発
ジャンル : コンピュータ

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

テーマ : ビジネス
ジャンル : ビジネス

　この記事は、初心者のための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へと戻る

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

テーマ : プログラミング
ジャンル : コンピュータ

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

テーマ : ビジネス
ジャンル : ビジネス

　今回は特にこれといった意味無く、ブログの中心で愛を叫ぼうと思いました。私は数あるOSの中でWindowsOSが一番好きです。私はWindows95から愛好していますが、その心は変わりません。Linux、FreeBSDといったUNIX系OSもカーネルを調べるほど好きですが、やはりWindowsの方が好きです。
　Windowsとの付き合いは長いです。仕事でWindowsを使ったシステムを販売していますし、プライベートな時間でも大半はWindowsを使っています。一応UNIX系OSを使ったシステムに関わる事がありますし（WindowsOSとLinuxを混在させる会社も多い）、カーネルなどを調べる時に使っていますが、やはりWindowsの方が好きです。
　といっても、盲目的に全てが好きなのではありません。Linuxの方が勝る事柄もあります。例えば、OSを学習したい時Linuxの方が有利な点は否めません。他にも、些細な点でLinuxの方が優れている面もあります。さらに、Windowsで嫌いだと感じた事すらあります。ですが、嫌いな部分も含めて、総合的にWindowsに魅力を感じます。
　WindowsOSの魅力は様々な事柄から成り立っています。WindowsOSを提供しているマイクロソフト社、開発メンバー、仕事での出来事、プライベートな時間で使用した経験・・・それら全てを含めて、私の中でWindowsOSの好感度が高いです。どの様な製品でもそうですが、やはりその製品に対する愛着度は、様々な要因で決まります。恐らく大半の人がそうでしょう。特に仕事で扱っている製品に対しては、その傾向が強くなると思います。
　私がWindowsを大好きになった理由のうちの一つは、闘うプログラマーを読んでWindowsOSにかける人々の熱き魂に感銘を受けたからです。私は元々研究肌の人間なので、ビジネス用のシステムよりもOS開発に心惹かれます。それに加え、OS開発の人間ドラマを知ってしまえば、嫌う理由は一切ないと言っても過言ではありません。WindowsOSも人間が作ったものです。そこにはやはりドラマがあります。そのドラマが私を惹きつけます。あぁ、1日中OS開発が出来れば天国なのにな。
　他にも理由が色々あります。意外だと思うでしょうが、WindowsMeが理由になっています。私が初めてPCを買った時、WindowsMeだったのですが、その後直ぐWindows2000が発売され凄くショックを受けました。Windows2000発売直後は、かなり腹がたち、Windowsが嫌いになりかけていました。ですが、後にWindowsOSの歴史を知ってその評価が180度変わりました。
　歴代WindowsOSの構造を調べていくと、技術的に考えるとWindowsMeの存在理由はありませんでした。ですが、世界規模の大会社であるマイクロソフト社がその様な大きなミスを犯すとは到底思えず時代背景を調べました。その結果分かったのですが、ハードウェアベンダとユーザーに配慮した結果でした。当時のマイクロソフト社は、やろうと思えばWindows2000をすぐさま販売できたかもしれません。それぐらいの技術力がありました。しかしながらそれをしてしまうと、ハードウェアベンダがついていけず、Windows2000のデバイスドライバが提供されません。そうなると、一般ユーザーに打つ手はほぼないでしょう。そういった事情もあり、移行用OSのWindowsMeが発売されました。
　当時の私は若く、どちらかというと技術に傾向するタイプの人間でした。そんな私にとって、マイクロソフト社の配慮は衝撃を受けました。WindowsOSをただの技術的産物だと考えず、色々な人間に配慮するというその姿勢は、私が抱いていたプロフェッショナル像を変えました。技術だけしか見ず、ただ技術力をふるって製品を販売すれば自己満足でしかありません。人のことを考えなければ、プロの仕事ではなくアマチュアの趣味です。
　他にも色々ありますが一番大きいのは、苦楽を共にした存在だという点だと思います。WindowsOSで苦しみ、WindowsOSで喜びました。そうした思い出が愛着をもたらします。昨今はその様な骨がある製品がありません。デフレ故でしょうが、多くの会社が、成り行き任せで製品を発売しているという印象を受けてしまいます。WindowsOSの様な骨のある製品が生み出されたらいいのになと私は思えてなりません。
　なにはともあれ、私はWindowsOSが大好きです。おそらく、提供され続ける限り、WindowsOSを愛用するでしょう。私もWindowsOSの様に人に好かれるものを作りたいと常日頃考えております。これからもWindowsに幸あれ！

テーマ : 情報処理技術
ジャンル : コンピュータ

　この記事は、初心者のためのC#プログラミング本格入門69の続きです。前回は、新しいテストファーストの心得を解説しました。今回は、テストオブジェクトについて解説します。
　今まで、ユーザーストーリーに沿ったテストを行い、使いやすいオブジェクトを目指してきました。その考えは、テストを行うオブジェクト（今後テストオブジェクトと呼ぶ）にも適用されます。何故ならば、テストオブジェクトが扱いにくいものであれば、テストを実行する事が嫌になり、テストの実行頻度が落ちてしまうからです。テストは頻繁に実行できるものでなくてはなりません。その為に、テストオブジェクトも改良していきます。
　現在存在するテストオブジェクトはMultiAnalyzerTestです。このオブジェクトにテストを追加する時、MultiAnalyzerTest.csファイルとMainメソッドがあるTestProgram.csファイルの両方を変更しています。これは非常に面倒かつ、追加忘れがありうるので危険です。意識を集中させるために、MultiAnalyzerTest.csファイルだけを変更すればいいように改良しましょう。
　ポイントは「如何にMainメソッド内のプログラムを変更せずにすませるか」という事です。色々考えられますが、一番簡単な方法は、「全てのテストを実行するメソッドを実行する」です。早速実行してみましょう。

class TestProgram
{
    static void Main()
    {
        MultiAnalyzerTest multiTests = new MultiAnalyzerTest();
        multiTests.ExecuteAllTest();
    }
}

class MultiAnalyzerTest
{
    //全てのテストを実行する
    public void ExecuteAllTest()
    {
        //ここへテストを追加していく
        this.AnalyzeSimpleExpression();
        this.ErrorExpressionCheck();
        this.ErrorAndSuccess();
        this.AllErrorExpressionDelete();
    }
    
    //他のコードは省略
}

これで、新しいテストを作成する度にMainメソッドにコードを追加する必要がなくなります。この様にちょっとした工夫で、テストオブジェクトが扱いやすいものになります。
　プログラミング上達のキーは意識の集中です。初心者やアマチュアを観察して気付いたのですが、プログラミングが下手な人は意識が分散しています。下手という言葉はネガティブだと感じる人もいるでしょうが、下手な理由さえわかれば上手になれる事を意味しています。プログラミングを才能の一言で片づける人も見受けられますが、一般的なプログラミングに才能は殆ど関係ありませんし、才能なんて数値化できませんから誰にも測れません。非論理的に才能の一言で済ませず、原因を一つずつ発見し解決していくと何事も上達します。
　何事も投げ出さず前向きに生きよう。「俺には才能がない」だとか「文系だから」などと逃げる人生よりも、「上手くできないなら工夫する」という前向きな人生の方が良いのではないでしょうか？人生の教訓はプログラミングにもあります。それを発見するのもプログラミングの楽しみの内の一つです。

テーマ : プログラミング
ジャンル : コンピュータ

　この記事は、真正性をつつく5の続きです。前回は、アクセスポイントの決定について解説しました。今回は、認証オブジェクトについて解説します。
　アクセスポイントには、必ず認証オブジェクトが必要となります。例えば、受付には受付嬢が必要ですし、研究室の扉には認証端末が必要です。セキュリティ対策を行う際には、それら認証オブジェクトを熟考しなくてはなりません。具体的には、認証内容、認証行動、認証に必要なデータの3点を考えます。つまり、誰が何をどの様に何をもって認証するのかよく考えます。
　認証内容、認証行動、認証に必要なデータは関連しています。認証する内容に基づき、どの様に認証するべきなのかが決まりますし、認証を行う際に必要なデータもそれで決まります。真正性の場合、何がどれだけ保障されているのかが認証内容に該当します。これから原則を述べます。
　原則其の一、認証に必要なデータは認証側から絶対に漏らさない。認証に必要なデータが漏れると、それだけなりすましが容易になります。これはオレオレ詐欺を思い浮かべると良く分かると思います。犯人「オレオレ」、被害者「健二かい？」、犯人「そうそうオレ健二だよ」。この様に認証に必要なデータを漏らすと、不適切なオブジェクトが認証をパスしてしまいます。これは意外と忘れがちなので十分に注意しましょう。
　原則其の二、認証に必要なデータは最小限にする。認証するオブジェクトに対して、不必要にデータを開示してしまうと、そこからクラックされる可能性が高くなります。権限に応じたデータを持たせましょう。
　原則其の三、アクセス経路を集約化します。この原則は他の原則と密接に関係しています。認証オブジェクトに最低限のデータしか渡さないと、自ずと十分な認証が出来なくなります。そこで、より権限の高い認証オブジェクトを知らせておき、認証対象となるオブジェクトがそこに集まるようにします。そうすれば、権限と責任が明確化し、人間の意識も集中できます。その結果、効果的なセキュリティ対策が行えるようになります。アクセスパターンが複雑化すると、それだけセキュリティ上の弱点が多くなりますのでこれは非常に重要です。
　原則其の四、情報資産の価値に比例させる。保護対象となる情報資産の価値が高ければ、それだけ厳重に保護しなくてはなりません。価値が低い情報を厳重に補語してもコストが高くつくだけです。情報セキュリティに割り当てられる予算と労力は有限です。重要な情報に予算と労力を割り当てられる様に注意しましょう。
　原則其の五、定期的に確認しましょう。どれだけ厳重にセキュリティ対策を行っても必ず穴がありますし、時間とともにクラッキング技術も向上します。セキュリティ対策は一度考えたらお終いではありません。あくまでもスタート地点に過ぎません。また、安全だと人は安心し、セキュリティ意識が低くなっていきますので、定期的にセキュリティ対策を見直し、セキュリティ教育も行う必要があります。
　細かい事を言えばきりがありませんが、ひとまずこの5つの原則をおさえましょう。そうすれば、ある程度有効なセキュリティシステムになります。情報資産の重要性は高まっています。今後、情報資産の重要性は減らないでしょうから、これからの時代これぐらいは押えておく必要があります。続く...

テーマ : ソフトウェア開発
ジャンル : コンピュータ

　この記事は、実践的オブジェクト指向設計入門8の続きです。前回は、トレードオフ順位の設定を解説しました。今回は、アーキテクチャについて書きます。
　情報システムは既存のシステムと似ている場合もあります。その場合、既存システムのアーキテクチャを参考にすると設計時間を大幅に減らす事が出来ます。厳密に言うとこれは作業ではなく、オブジェクト指向方法論OMTで触れられている事です。参考資料には、一括変換（バッチ処理）、連続変換、対話型インタフェース、動的シミュレーション、実時間システム、トランザクションマネージャが挙げられています。他にも色々なアーキテクチャがあります。参考にしない手はないでしょう。
　ただし、ここで一つ注意するべき事があります。それは、既存のアーキテクチャに縛られては駄目だという事です。これはデザインパターンでも良く知られた弊害なのですが、有効な方法を知ったら、手当たり次第にその方法を適用し、それ以外の方法について検討しない人が結構います。これは、アンチデザインパターンの黄金のハンマーと呼ばれる症状です。この症状が出たら要注意です。何故ならば、システムはお客様ごとに最適化するものであり、必要とされるシステムはお客様ごとに異なるからです。
　アーキテクチャを参考にする事により、他の設計者の英知を借りる事が出来ますが、あくまでも参考程度にとどめておくのが賢明です。システム設計の一番の敵は先入観と思考の硬化です。システムは先入観を持たず、常に柔軟な思考で設計しなくてはなりません。
　オブジェクト指向方法論OMTにおける、システム設計の段階はこれで終わりです。次回からオブジェクト指向設計段階の解説を行います。

テーマ : ソフトウェア開発
ジャンル : コンピュータ

　日本は過去高い技術力を誇り、今もなお一部の技術は優れています。しかしながら、現実は技術および技術者を軽視しているとしか思えない状態です。今回、技術立国日本は本当なのかを技術者＆経営者目線から書きます。
　日本には何も資源がありません。本当はメタンハイドレートがあるのですが、かといって資源大国とはとてもじゃないけど言えず、島国日本は人しか資源しかないと言った方がよい状態です。技術以外に生き残る術は無いと思います。ですがその一方で、日本は技術および技術者を軽視しています。先ずはその点について、一技術者として疑問を呈します。
　日本で技術者をやっていくのは大変です。何故ならば、企業が技術を軽視しているので働く場所が無いからです。例えば、プログラマーは情報技術を操る技術者なのですが、企業はプログラマーという職業を純労働者だと蔑視し、低賃金長時間労働の過酷な仕事環境を改善しようとはしません。そういった経緯から、日本ではプログラマーは一生する仕事ではなく、情報技術について拘らない方が出世します。日本のこの現状を、「技術力＆知識量に比例して報酬が低下する不思議な業界」だと言っている人もいるぐらいです。
　技術立【国】というぐらいですから、政府の対応についても検討します。結論からいいますと何もしていません。どうやら政治家たちは、そもそも技術者に対して興味を持っていないようです。また、情報技術はコピーが容易であり、国の保護が必要なのですが、その点に於いても何もせず、現状は「盗みたい放題」です。その状態でイノベーションを起こしたい人はいないでしょう。かく言う私も毎年特許を出願しようと思えばできますが、一度特許を出願した時に盗みたい放題だと知り、自分の発明は墓の下に持っていくのが賢明だと悟りました。
　知的財産の現状は盗まれ放題であり、かつ技術者の労働環境も悪いので、そもそも日本で技術者をしたいという人はいなくなるでしょう。現に海外に移籍する人が多いようです。日本の現状は技術流出国と言えると思います。ただし、技術流出国だといっても、ここままだと何時か枯渇するので流出する技術もなくなります。技術なき日本には何も残りません。
　次は経営者の視点から技術立国日本を検証します。経営者の視点から見れば、日本で技術を売っていくのは困難だと言わざるをえません。容易に盗まれるものですから、コストをかけるわけにはいかなくなりますし、盗まれるという事は価格で勝負するしかありません。そういった事を踏まえると、盗まれ難い物資を売る方が商売としては楽になります。また、技術を作り出すと盗まれるので、既存の技術をマネージメントして売るのが常道になります。この要因から日本は多重下請け国家になっていると思われます。
　纏めます。技術立国日本というのは嘘です。現状を正確に表現すると技術流出国です。日本全体が、日本唯一の資源である技術および技術者を軽視しているので、全ての技術が流動し枯渇するのが目に見えております。それに加えて、技術を売りにして商売をするのは困難な国家なので、誰も技術を売り物にしなくなるでしょう。その時日本に何が残るのか・・・それは言うまでもないでしょう。技術立国というのならば、技術および技術者を国全体で適切な保護するべきなのではないでしょうか？

テーマ : ビジネス
ジャンル : ビジネス