システム開発における情報セキュリティ13

　この記事は、システム開発における情報セキュリティ12の続きです。前回は、セキュリティに関するルール作りについて解説しました。今回は、セキュリティポリシーについて解説します。
　セキュリティポリシーとは、企業レベルで情報資産の扱いについての理念を定義し、セキュリティの目標と目的を定め、情報資産を守るための手順や手段を宣言したものです。ちょっと分かり難いと思いますので解説します。
　情報セキュリティは日進月歩だと言われております。つまり、恐ろしく変化が速く、明日安全だと言われたものが、今日危ないと言われても不思議ではないという事です。小手先のセキュリティでは直ぐに対応できなくなります。従って、セキュリティ手順と言った目の前のレベルではなく、思想レベルでセキュリティを考え、変化に対して柔軟に対応しつつ実施しなくてはなりません。
　クラッカーどの様な弱点でも利用するので、企業がセキュリティを実施するには、全ての人々にセキュリティ意識を持ってもらう必要があります。そのために、情報資産の大切さや行動基準を定義し、それに基づきセキュリティ対策を実施し続けなくてはならないのです。
　セキュリティポリシーは、ユーザー企業だけが考えればよいというものではなく、システムを知り尽くしたシステム開発側の人間も参加して作らねばなりません。何故ならば、ビジネスに関してはユーザー企業の方が詳しく、情報技術と情報システムについて詳しいのは開発側の人間だからです。
　今までシステム開発側には「売ればいい」という風潮がありましたが、企業責任が問われる昨今では、その様な考えは通用しません。自社が売る商品について、より積極的にサポートしなくてはなりません。
　クラッカーは人の思考と、広い意味でのシステムにある小さな隙間を狙ってくるので、ユーザーとベンダが密接に協力し合い、隙間をなくす努力を続ける必要があるのです。

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

　この記事は実践的オブジェクト指向設計入門1の続きです。前回は、システム設計について解説しました。今回は、システムの分割について解説します。
　よほど単純なシステムでない限り、１つのシステムをそのまま扱うのは大変なので、システムを少数のサブシステムに分解します。ここで注しなくてはならないのは、サブシステムが１つのクラスや関数（機能）ではなく、それらをパッケージングしたものであるという事です。
　設計時にいきなり細かい要素を考えだすと、選択できる設計の幅が狭くなってしまいます。また、視野が狭くなると柔軟な思考を失い、プロジェクトが失敗する確率が高くなります。何故ならば、細かい単位の設計は読む人の理解をさたまげ、コミュニケーションを阻害してしまうからです。
　どの様のシステムを分割すればよいのかというと、OMTではレイヤーとパーティションで分けて考えるという方法が提示されています。
　レイヤーはシステムを階層化して考えます。TCP/IPプロトコルスイートやOSが良い例です。システムを階層化すると、１つのレイヤーを取り換えれば変更できるようになるので、仕様変更に対して対処しやすくなります。システムは最低限、ハードウェア、OS、アプリケーション、サブシステムは分けておくべきです。そうすれば、システム設計の幅が広がり、変更の影響を押えられます。
　パーティションはシステムを独立しているサービスに分割します。例えば、オペれティーングシステム（OS）は、ファイルシステム、メモリ管理、デバイス制御、プロセス制御といったサブシステムを含んでいます。この様にシステムを、結合度が低いサブシステムに分割します。
　レイヤーとパーティションの違いは結合度とインタフェースです。階層化されたサブシステムは、他の階層に依存し、関係するサブシステムのためのインタフェースを提供しています。一方パーティンは、サブシステム間の結合度が低く、人間が扱いやすいインタフェースを提供しています。
　システムの分割は、レイヤーとパーティションの２つの考え方を両方使用します。一般的には、システムをパーティションで分け、個々のサブシステムを階層化します。
　サブシステムが判明したあとは、サブシステム間の関係とデータの流れを記述します。色々な記述方法が考えられますが、パッケージ図と配置図がこの目的にふさわしいでしょう。
　以上でシステムの分割についての解説は終わりです。

F#でテストファースト

　F#でテストファーストをしたい時NUnitを使用する人が多いと思います。そこで、F#でNUnitを使用したテストを行う際に気をつける事を書きます。
　F#でNUnitを使用したテストプログラムを書く際に気をつけるポイントはコンストラクター、メソッドの引数と戻り値の型、デリゲートの扱いです。テストクラスにコンストラクターを要しないと、F#はC#等の言語とは違い、自動的にコンストラクターを用意しないのでエラーになります。また、テスト用メソッドも引数と戻り値の型にも気をつけないとエラーになります。さらに、ThrowsメソッドとDoesNotThrowメソッドを使うためにデリゲートの扱いが重要となります。
　この3点に注意して作成すると次の様なコードになります。

module TestSample
open NUnit.Framework

//テスト対象となるクラス
type Foo( x ) =
  let m_value = x

//テストクラス
[<TestFixture>]
type FooTest() =

  //関数を使用
  [<Test>]
  member this.ConstructorTest() = 
    Assert.DoesNotThrow( fun() -> 
        ignore( Foo( 10 ) ) )
  
  //順次パイプラインを使用
  [<Test>]
  member this.ConstructorTest2() = 
    Assert.DoesNotThrow( fun() -> 
        Foo( 10 ) |> ignore )

  //()を使用
  [<Test>]
  member this.ConstructorTest3() = 
    Assert.DoesNotThrow( 
      fun() ->
        let obj = Foo( 10 )
        ()
    )

このサンプルコードは、コンストラクターが正常なのかをチェックするものです。FooTestが暗黙的コンストラクターを定義している点、テスト用メソッドの引数、Assert.DoesNotThrowにデリゲートを渡している点に注目して下さい。
　Assert.DoesNotThrowは、戻り値がvoidのデリゲートを要求しています。その方法はいくつかあり、それら３つの方法を試しています。どの方法でも結果は同じです。ただ、個人的には順次パイプラインを使用する方法が、関数型プログラミングのスタイルとマッチしていると感じるので好きです。
　デリゲートが重要なのは、.NETが関数をデリゲートで実現する場合が多いからです。具体的に言うと、DoesNotThrowはTestDelegateを使用しています。さらにILを見てみると、F#（F# 2010）はFooTestクラスにインナークラスを定義し、そこで定義したメソッドをTestDelegateの初期化時に指定しています。
　気をつけるべき点がありますが、ちょっと学習すれば乗り越えられます。見ての通り、F#は短いプログラムでテストを行えますのでF#を使う利点は非常に大きいと思います。
　.NETでは多言語をサポートしているので、「C#で開発してF#でテストする」などと言った事も可能となります。F#でテストプログラミングをするとテストコードが短くなるので、積極的にF#を使っていくとよいと思います。

初心者のためのC#プログラミング本格入門56 - テストプロジェクトを用意しよう

　この記事は、初心者のためのC#プログラミング本格入門55の続きです。前回は、個々のオブジェクトをファイルで整理する方法を解説しました。今回は、本格的なプログラミングをする為の準備であるテストプロジェクトについて解説します。
　前回の方法でプログラムが整理できました。しかしながら、これだけでは本格的なプログラミングはできません。プログラムが複雑になってくるとテストが必要になってきます。
　「自由に指定した計算式を計算するプログラム」は今のところ、いちいちコンソール画面を起動し、値を入力してプログラムが正しいか確認をしています。これでは非常に不便です。もっと簡単にプログラムが正しいのかテストする必要があります。
　はじめに、画面右にあるソリューションエクスプローラーにあるソリューションを選択して下さい。このサンプルの場合、ソリューション'FirstProgram'(1 プロジェクト)と表示されていると思います。この項目を選択した状態で、右クリックしてポップアップメニューを出し、項目追加の先にある「新しいプロジェクト」を左クリックして下さい。すると、新しいプロジェクトの追加というダイアログボックスが表示されます。
　ダイアログボックスが表示されたら、コンソールアプリケーションを選択して下さい。名前は何でもいいのですが、テストである事が一目でわかるようにFirstProgramTestとしておきましょう。名前を入力したら後はOKボタンを押すだけです。これで新しいプロジェクトが作成されました。
　次は作成されたプロジェクトFirstProgramTestを選択し、マウスを右クリックしポップアップメニューを出し、追加項目の先にある「既存の項目」を選択して下さい。すると、ファイルを選択するためのダイアログボックスが表示されます。表示されたら、FirstProgramフォルダー内にあるファイル「Analyzer.cs」と「MultiAnalyzer.cs」を、Ctrlキーを押しながら選択して下さい。これで２つのファイルが選択されたので、追加ボタンの▼をクリックして「リンクとして追加」をクリックして下さい。これで、テストプロジェクトと元のプロジェクトにあるプログラムが、同時に編集できるようになります。
　以上でテストをする為の準備が整いました。次回、このテストプロジェクトを使って、MultiAnalyzerの作成を進めます。

初心者のためのC#プログラミング本格入門55 - プログラムを整理しよう

　この記事は、初心者のためのC#プログラミング本格入門54の続きです。前回は、初心者がコンポジション（合成）を行うオブジェクトを作成する方法について解説しました。今回は、プログラミングをしやすくする方法について解説します。
　徐々に学習用サンプルプログラムの「自由に指定した計算式を計算するプログラム」が難しくなってきたので、プログラムを整理し今後に備える事にします。今までAnalyzer、MultiAnalyzer、Programの合計３つのオブジェクトを作ってきました。それら３つのオブジェクトを分けます。
　メニューの「プロジェクト」を選択し、その中から「新しい項目の追加」を選択して下さい。すると、ダイアログボックス（小さな画面）が表示されます。その画面の中央に、「クラス」という項目があるのでクリックします。これでクラスが選択されましたので、一番下にある名前の右横にある空欄にAnalyzer.csと入力してから「追加(A)」ボタンをクリックします。するとAnalyzerクラスが表示されますので、そこに今まで作成したAnalyzerクラスのプログラムを切り取って貼り付けます。
　切り取り＆貼り付けの操作方法を書きます。プログラム「class Analyzer」の左横に囲まれた小さな「-」記号がありますので、左クリックしプログラムを折りたたみます。すると、プログラムが「class Analyzer...」の様に表示されます。次にマウスをドラックし、プログラム「class Analyzer...」全体を選択します。選択出来たら、Ctrlキーを押しながらXキーを押します。これで「切り取り」が完了しました。次は切り取ったプログラムを貼り付けします。
　貼り付けるには、先ほど新しく作成したファイルAnalyzer.csの中身を表示させてから（※）、Ctrlキーと同時にAキーを押し、続いてCtrlキーとVキーを押します。すると、今まで作ってきたAnalyzerクラスの内容に変更されます。これでOKです。MultiAnalyzerクラスも同様の操作をして、MultiAnalyzer.csファイルを作りましょう。これで随分とプログラムが読みやすくなったと思います。
※ファイル内のプログラムを表示したい時は、画面右にあるソリューションエクスプローラー内で表示されているファイルをダブルクリックして下さい。そうすると、ファイルの内容が表示されます。
　ところで、今回は「クラス」という用語を使用しました。今まで解説の中で使ってきた「オブジェクト」という用語とどう違うのか気になった方がいるかと思います。今のところクラスはオブジェクトの一種と考えて下さい。実はC#のオブジェクトには色々な種類があります。その違いは徐々に解説していきます。
　今回はファイルでプログラムを整理する方法と、ショートカットキーを使った操作について解説しました。既に知っている人が多いと思いましたが、こういった「ちょっとした事」は意外と重要なので改めて解説しました。プログラムの整理は重要なのです。
　ちょっとしたプログラムでも数百行は当たり前で、実務ならば万単位になります。ですから、本格的にプログラミングをする人は必ず、プログラムを整理する方法を身につけておかねばなりません。プログラムは常に美しく整理するよう心掛けましょう。それが、本格的なプログラミングをする為の第一歩です。

システム開発における情報セキュリティ12

　この記事は、システム開発における情報セキュリティ11の続きです。前回は、人とセキュリティの関係について解説しました。今回は、セキュリティに関するルール作りについて解説します。
　前回「関係者全員に細かいルールや複雑な手順を強いるのもまた間違い」だと明言しました。では、具体的にどうすればよいのでしょうか？今回はその件について書きます。
　真面目にセキュリティ対策を考えるのであれば、守られなくなるのが目に見えている細かいルールを定めてはなりません。細かいルールを作っていると、それだけでセキュリティ対策をやっていると錯覚しがちですが、実際には役立つどころかセキュリティの効果と業務効率を下げる元凶になります。
　細かいルールを作る方針では、日々進化するクラッキングテクニックに対抗するために自然とルール数が増加し、直ぐに人間が覚えられない量になります。人間が覚えられないセキュリティ対策ほど効果がないものはありません。それどころか、セキュリティ対策そのものが軽視され、非常に危険な状態になる可能性すらあります。従って、無闇に細かなルールの数を増やすのではなく、セキュリティの本質を押えたセキュリティポリシーを定めるべきです。
　セキュリティポリシーについて書くと長くなるので次回に続きます。

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

　この記事は実践的オブジェクト指向設計入門0の続きです。前回は、オブジェクト指向設計の前に、システム設計をする必要がある事を解説しました。今回は、システム設計について解説します。
　システム設計とは、どのように問題を解決するのかを決定する事です。オブジェクト指向分析では、何をするべきなのかを解明しました。何をするべきなのかと、どの様に行うのかは独立しています。従って次の段階の設計では、何を行うべきなのかを、抽象度が高いレベルから始めて、徐々に詳細なレベルまで決定しなくてはなりません。今回から、そのシステム設計で行う作業について解説していきます。
　システム設計で最初に行う作業はシステムの分割です。システムは余程小さなものを除いて、複数のサブシステムから成り立っています。例えば会社というシステムは、研究・製造・購買・販売などといった複数のシステムから成り立っています。人間は大きなシステムの全てを一度に扱えませんので、分かりやすい単位で大きなシステムを分割し、それをサブシステムとして扱います。
　きりがいいので今回は終わりです。次回システムの分割について解説します。

初心者のためのC#プログラミング本格入門54 - コンポジション（合成）を行うオブジェクトの作り方

　この記事は初心者のためのC#プログラミング本格入門53の続きです。前回は、初心者用のオブジェクトの作り方を解説しました。今回は、初心者がコンポジション（合成）を行うオブジェクトを作成する方法について解説します。
　「コンポジション（合成）という技法を使ってオブジェクトを定義する」というと、なんだか難しく聞こえるでしょう。でも心配は要りません。コンポジション（合成）はプログラムで実現するのが簡単です。普通のオブジェクトと同様に作れます。
　では、早速サンプルを作ってみましょう。前回同様、呼び出す方のプログラムを先に作ります。サンプルプログラムは、毎度おなじみの「自由に指定した計算式を計算するプログラム」です。

static void Main()
{
    string end = "";
    do
    {
        //計算式を入力
        string message = "計算式を入力して下さい";
        string inputValue = InputValue( message );

        //計算式を解析して値と符号を得る
        MultiAnalyzer analyzer = new MultiAnalyzer();
        analyzer.AnalyzeExpression( inputValue );
        if ( analyzer.Success == false )
        {
            string error = "計算式が間違っています。";
            end = "Error";
            System.Console.WriteLine( error );
            continue;
        }

        //計算して結果を表示
        float resultValue = analyzer.Calculation();
        ShowResult( inputValue, resultValue );
        System.Console.WriteLine( "" );
        end = GetEnd();
    } while ( end != "" );
}

このプログラムは見覚えがあると思います。今まで改良を重ねてきたサンプルプログラムのAnalyzerをMultiAnalyzerに変えているだけです。
　現在の状態だと、Successプロパティ、AnalyzeExpressionメソッド、CalculationメソッドがまだMultiAnalyzerクラスで定義されていないのでエラーが出ます。エラーを消すために、足りないプロパティとメソッドの定義だけをしておきましょう。

class MultiAnalyzer
{
    bool success;
    public bool Success
    {
        get { return this.success; }
    }

    public void AnalyzeExpression( string inputValue )
    {
    }

    public float Calculation()
    {
        return 0.0f;
    }
}

「return 0.0f;」の部分に注目して下さい。この末尾にある文字「f」は、C#に対して数値がfloatである事を伝えています。もしfを指定しないと「型 double のリテラルを暗黙的に型 'float' に変換することはできません。'F' サフィックスを使用して、この型のリテラルを作成してください。」とエラーが表示されます。この機会に是非覚えておきましょう。
　長くなりましたので今回はひとまず終わります。次回は各メソッド内のプログラムを作っていきます。お楽しみに。

ネタつつき121 - プロフェッショナルな叱り方

　前回、叱り方は難しいと書いたので、叱り方について書きます。色々な職業の人を観察したところ、尊敬されるプロフェッショナルは皆、非常に叱り方が上手い事に気付きました。そのプロフェショナルな叱り方から非常に多くの事を学べます。
　プロフェッショナルな人達の叱り方は様々ですが、共通した要素があります。それは、人格否定をせずに問題について考えさせる事です。叱り方が下手な人は、無闇に怒鳴ったり、ネチネチと説教したりします。しかし、そんなネガティブな叱り方をするとマイナス効果しか生まれません。人間関係を壊し、相手が委縮する事によりさらなる失敗が生まれるだけです。そんな状態でよい仕事が出来る筈がなく、ネガティブな叱り方をする人は、チームの生産性を低下させてしまいます。でも、下手な叱り方をしたい人は稀です。なぜそんな下手な叱り方になってしまうのでしょうか？
　私が分析したところ、叱り方のうまさは焦点に合わせ方にあります。叱り方が下手な人は焦点を人に合わせます。叱り方が下手な人は、失敗した人を中心に説教をするので、その人からしてみれば人格否定で話しが終わってしまいます。そんな受け取り方をされれば、根本的な解決になりません。一方、叱り方が上手な人は問題に焦点を合わせます。問題を中心で話しを組みたてているので、お叱りを受ける人は人格否定だと感じず、問題解決に向けて前向きになれます。それゆえ叱り方が上手な人は、嫌味な上司ではなく、頼れる上司だと部下に慕われるのです。
　叱り方がうまい人にはもうひとつ特徴があります。それは、考えさせる点にあります。叱り方が下手な人は、一方通行に問題の解決法を押し付けます。そんな事をされれば誰しも、反抗心が芽生えたり、一人前として認められていないなどと感じたりします。世間は良く、最近は受け身の人が多いなどと言いますが、受け身にさせているのは上司の叱り方です。一方、叱り方が上手な人は、解決方法を押し付ける事はせず、ヒントをあげて本人に考えさせます。人は自分が考えた事を受け入れる性質を持っています。頼れる上司からヒントをもらえば、部下は喜んで答えを導き出します。そうすれば、叱られた部下も成長し、仕事の生産性が向上します。
　纏めます。叱り方が上手な真のプロは、常に問題を焦点に置き人格否定をしません。その言動は叱られた人を前向きにし、自分で考え成長する人へと変えます。その結果チームの生産性は向上し、真のプロが率いるチームは、優れた生産性を示す事になります。ただし、何事にも例外があります。問題の本質がその人の性格にある場合は、真のプロでも性格を直す様に叱ります。ですが、決してその人全てを否定する事はありません。その点に於いても、真のプロは知り方が上手いと言えます。
　叱るという行為は非常に難しいですが、それを避けては真のプロになれません。真のプロを目指し、叱り方についても深く考える事が、真のプロへ向かう道への第一歩になると私は考えています。

ネタつつき120 - プロは自己をコントロールする

　需要がありそうなので、今回の記事もプロフェショナル精神がテーマです。プロは基本的にお客様主義です。ですがそれはまだ表面的な事です。より深く考えると「自己のコントロール」にいきつくと私は考えています。これからその理由を書きます。
　プロはお客様を大事にします。それと同時に、仕事の関係者も大事にします。たまにお客様に対しては非常に丁寧に対応するが、部下に対してパワハラ行為を繰り返す人がいます。それはプロフェッショナルな行為とは言えません。ただ外面がいいだけです。本当に優れた人は、部下に対しても真摯に対応をします。それは、打算的な行動ではなく、プロフェッショナル精神から自然に滲み出るものです。
　仕事は常に複数の人が関係します。仕事の品質を気にするプロフェッショナルは、仕事の質をあげる事だけを考えて生きているので、自然と部下に対しても真摯に対応するようになります。誤解がないように明記しますが、真摯に対応するのと媚を売るのは別物です。仕事に対して真剣なプロフェッショナル達は、部下の将来を真剣に考える故に厳しい言動を取る事が多々あります。人はどうしても言動が優しい人に気を許しがちです。ですがその優しさは、他者に対する無関心さからする行動の場合があります。その見極めが必要です。
　誤解している人が多いのですが、本当にプロフェッショナルな人は、場面と人を考えて叱っています。叱るという行為を、簡単な行為だと誤解している人がいますが、ただ感情に任せて怒鳴るのと、部下の事を考えて叱るのとでは天と地の差があります。感情に任せて怒るのは簡単ですが、叱るのは非常に難しいのです。他者の事を真剣に考えていないと叱れません。そんな面倒な行為をしないで、ただ優しく（無難に）振舞う方が簡単です。
　私は多くのプロを観察しその事に気付きました。プロは常に自身よりも他者と仕事を中心に物事を捉え行動しています。ですが最近は、本当の意味でプロフェッショナルな人が減ってきたと思えてなりません。媚を売るためにお客様主義を口先だけで提唱する人／会社、自己顕示しかしない人、他者を顧みない我儘な人、何に対しても無関心な人、自己保身のために全ての変化を否定する人、嘘八百で生きている人・・・。それら全ての人は、自己をコントロールする力が不足しています。
　日本は不景気ですが、不足しているものは「お金」などではなく、本当に不足しているのは、「プロフェッショナル魂を持つ質がよい人」ではないでしょうか？むろん自己のコントロールは難しい行為です。しかしながら、やらなければコントロールする力は身につきません。学ぶ事はまねる事から始まります。先ずはプロフェッショナル精神をまねて、それを本物に変えるのがベストだと私は考えています。