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

　この記事はシステム開発における情報セキュリティ4の続きです。前回は、見つけ出した情報資産についての分析を解説しました。今回は、役割と権限の識別を解説します。
　システムを導入する組織には、様々な役割の人がいます。それらの人々は日常の業務で業務をこなすために、様々な情報にアクセスし、求められる情報を生みだします。ここで考えなくてはならないのは、業務を行う上で必要な情報と適切な権限です。もし、あらゆる情報がアクセスできる権限を与えれば、情報漏洩の危険やシステムダウンの可能性が高くなります。また、何か問題があった時に、犯人を突き止めなくてはなりません。適切な役割に、適切な権限を与える事を考えなくてはならないのです。
　情報セキュリティの基礎的な考え方は、「最小限の権限だけを与える」です。権限を考える際には、業務に最低限必要な情報にアクセスできるようにするのが原則です。従って、分析をする際に「どの役割の人がどの情報を必要とするのか」を分析する必要があります。
　それに加えて、組織間もしくは部署間でやり取りする情報にも注目せねばなりません。業務では複数のグループが必要とする情報もあります。例えば、生産管理をするグループは、需要予測を立てる為に販売データが必要になるでしょうし、連結決算時には子会社や関連会社の財務データが必要となります。個人単位もしくは単一の役割単位で権限を考えると、思わぬ落とし穴が出来てしまうので注意しましょう。
　そういった事から、システム開発に於いて、役割と権限を洗い出す作業は非常に大切です。この作業は、どこか特定の工程だけですればよいというものではありません。全工程にまたがり、情報が判明するたびに権限をチェックせねばなりません。非常に地味で退屈な作業ですが、セキュリティを高める上で欠かせない作業です。面倒くさがらずにしっかりと行いましょう。

ネタつつき104 - 変化は不変の職人魂から生じる

　ドックイヤーなIT業界に生きる我々は、激しい変化の波に常にさらされています。従って情報技術者は、変化とどういう風に向き合うのかという姿勢が大事になってきます。今回は、その話題について自分の見解を述べます。
　私のスキルセットは常に変化しています。情報技術者が学ぶべき事は沢山あります。今すぐ思いつく分野だけでも、「プログラミング、設計技法、分析技法、テスト技法、運営技法、ネットワーク、データベース、セキュリティ、プロジェクトマネージメント、コンパイラ、オペレーティングシステム、ハードウェア、英語、数学、会計、生産管理、販売管理、人事、経営」と非常に多岐にわたります。
　特別な才能がない私は、自分が望む高みまでまだまだ到達できませんが、凡人には努力しかないと考え常に学習しています。たまに他人から何故そこまで頑張るのかと聞かれる事があります。その答えは、世界は常に変化するからです。
　変化は自然現象です。時間は常に流れるのですから、必死に否定しても変化は止まりません。変化は人間の力でどうする事も出来ません。ならば、人が出来る事は一つしかありません。変化を受け入れ、自分が変わるしかありません。答えは簡単なのですが、日本ではどうやら、変化という言葉にはマイナスイメージがあるようです。
　ある学説によると、日本人は農耕民族であり、畑を作ってどっしり構え、みんなで同じ事を続ける性質があるそうです。それが原因なのか知りませんが、とにかく変化に否定的で、頭ごなしに変化を否定する人々が沢山います。しかしながらその行為は、自然現象に素手で立ち向かっているのと同じです。理論的に考えると、変化を否定してもどうにもならないのですが、感情論で否定しているようです。私はその感情も一部分かります。
　変化は良い事ばかりではありません。無闇にビジネスプロセス・リエンジニアリングをすると、事態が余計に悪化する場合がある事が知られています。また、長期展望が持てないという弱点も知られています。ビジネスプロセス・リエンジニアリングだけをしている企業は、経営活動に継続性が持てず、確固たるブランドイメージが築けない可能性もあります。ただ変化するだけでは駄目なのです。
　変化にただ身を任せるだけでは、変化の荒波に押し流されてしまいます。確固たる自分を持って、変化に対して毅然と立ち向かわなくてはなりません。私も無闇に変化しているわけではありません。揺るぎない職人魂を胸に秘めています。不変なものを持っているからこそ、変化に対して果敢に立ち向かえるのです。
　長くなったのでそろそろ纏めます。変化は自然現象であり、人は受け入れるしかありません。しかしながら、ただ受け入れるだけでは何も生まれません。変化の荒波に立ち向かうべく、確固たる意志を持って立ち向かう必要があります。そうすれば、自ずと道は開かれるでしょう。
　一度しかない人生なのですから、揺るぎない魂を持って変化を楽しむべきではないでしょうか？

実践的オブジェクト指向分析入門34

　この記事は実践的オブジェクト指向分析入門33の続きです。前回は、動的モデルの構築の最初に行うべき作業である「事象の発見」について解説しました。今回は、事象の発見で注意するべき事柄や要素を書きます。
　事象の発見において重要な要素の内の1つがインタフェースです。ここでいうインタフェースとは、既存システムの画面や帳票などを含む広義の意味で使用しています。
　interfaceという英単語は、2つの物体や空間の面の境界面・接触面を表し、システムや組織体が接して交信・交流する共通領域や、境界領域間を結ぶ手段も表しています。この意味をオブジェクト指向分析に当てはめて考えると、部門間や組織間でやり取りするデータおよび手段を分析する事になります。
　システム構築でよくある失敗の内の一つが、他部門・関連会社・顧客の接点を考慮しない事です。例えば、販売管理システムを受注した際に販売管理だけを考えてしまうと、会計データの扱いが疎かになり使えないシステムになります。
　また、今日のビジネスは顧客との関係が重要視されています。システムを導入するお客様が提供している商品やサービスを買う消費者の事まで考えないと、役に立たないシステムの烙印を押されてしまいます。すなわち、オブジェクト指向分析は広い意味のシステムのインタフェースが大事なのです。
　それとは別の問題で、企業が持つデータとオブジェクトを分析するために、帳票や既存システムのインタフェースを分析する事も大切な作業です。システム分析は基本的にビジネスプロセスを対象としますが、それだけでは見落としが生じます。何故ならば、日本は特に暗黙の了解や慣習が多いからです。それが原因で、ビジネスプロセスからは見えにくいオブジェクトがよくあります。
　オブジェクト指向分析では、事象とオブジェクトの見落としがないように多面的な分析をしましょう。

初心者のためのC#プログラミング本格入門31 - 初心者がプログラムを改良する方法

　この記事は初心者のためのC#プログラミング本格入門30の続きです。前回は、「任意の式から演算子を取り出す方法」について解説しました。今回は、「自由に計算式を指定して計算するプログラム」作成を通じて、初心者がプログラムを改良する方法について解説します。
　今まで解説した知識を組み合わせれば、「自由に計算式を指定して計算するプログラム」を作成できます。しかしながら、初心者は、まだプログラミングに慣れておらず、自分の知識を組み合わせて作るのは難しいと思います。
　そこで今回は、元からあるプログラムを改良して、自分が望むプログラムを作る方法を解説します。
　最初に、自分が作成したいプログラムに似たプログラムを探します。「自由に計算式を指定して計算するプログラム」に似たプログラムは、22回で解説したプログラムです。このプログラムを元に改良して、「自由に計算式を指定して計算するプログラム」を作成していきましょう。
　元となるプログラムは、GetValueメソッドとGetSignメソッドが目的に合致しません。ですから、この2つのメソッドを数回にわたって解説したメソッドを使うように変更すれば、ひとまず目的のプログラムが得られます。

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

        //数値1を取得
        System.Tuple<int, string> result = GetValue( inputValue );
        int value1 = result.Item1;
        inputValue = result.Item2;

        //演算子を取得
        System.Tuple<char, string> result1 = GetSign( inputValue );
        char sign = result1.Item1;
        inputValue = result1.Item2;

        //数値2を取得
        result = GetValue( inputValue );
        int value2 = result.Item1;

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

GetValueメソッドは28回で解説したものを使用し、GetSignメソッドは30回で解説したものを使用しています。それに加えて、CalculationメソッドとShowResultメソッドの引数を、char型を指定するように変更しています。

static int Calculation( int value1, char sign, int value2 )
    {
        int result = 0;
        switch ( sign )
        {
            case '+':
                result = value1 + value2;
                break;
            case '-':
                result = value1 - value2;
                break;
            case '*':
                result = value1 * value2;
                break;
            case '/':
                if ( value2 == 0 )
                {
                    result = 0;
                }
                else
                {
                    result = value1 / value2;
                }
                break;
            case '%':
                result = value1 % value2;
                break;
        }
        return result;
    }

    static void ShowResult(
    　　　　int value1, char sign, int value2, int result )
    {
        string message = "計算結果";
        System.Console.WriteLine( message );
        string expression = 
                value1 + " " + sign + " " + value2 + " = ";
        System.Console.Write( expression );
        System.Console.WriteLine( result );
    }

この様にすれば、初心者でも目的のプログラムを作りやすくなります。
　システム屋の私は「プログラミングの専門書をよく読み、サンプルプログラムを自分で打ったりしたけど、いざ自分が作りたいプログラムを作ろうとするとできない。自分はプログラミングに向いていないのだろうか？」という相談をよく受けます。すっかりプログラミングをする自信をなくしているようです。同様の経験をしている人は多いと思います。
　ですが、そんな事はありません。プログラミングをするのに特別な才能は要りません。経験者が自由自在にプログラムを作れるのは、似たようなプログラムを沢山作っているからです。初心者から見たら凄い経験者でも、何の苦労もなく特別な才能だけでプログラミングが出来るようになったのではありません。膨大な数のプログラムを作り続け、頭と体で覚えているだけなのです。
　プログラミングに対して苦手意識を持っている人は多いと思いますが、プログラミングは思いのほか簡単かつ便利なものなので覚えないと損です。ほんの少しの勇気と好奇心を持って、気楽にプログラミングをしましょう♪

ネタつつき103 - 知られざるシステム構築の現場

　ITという言葉そのものは有名ですが、その実態が知られてないと私は思えてなりません。TVの影響もあって、株の売買がIT技術者のお仕事だと思っている人すらいます。そこで今回は、知られざるシステム構築の現場について書きます。
　システム構築はお客様の要望を聞く事からお仕事が始ります。ITというと、非人間的などとマスメディアに言われていますが、実際は人間ありきの商売です。メールという形をとる場合もありますが、電話が発明された当時「汚らわしい」だとか「ビジネスは直接合わないとできない」だとか「電報でないと・・・」などと言われたのと同じ類の迷信です。
　そもそも、メールに終始する事はあまりありません。利便性を考え、選択肢のうちのひとつとしているだけです。コスト削減と言われて、自然とメールで出張費を削減するというだけの話しなのです。他には、大量の書類を素早くやり取り出来ないという事情もあります。短い納期でシステムを納品せねばならないので、手間を掛ける時間がないのです。
　お客様との会話についても誤解されやすい業種です。「技術者は専門用語ばかり使いやがる」という迷信があります。しかしながら実際のところは、殆ど情報技術の専門用語を使いません。極力お客様の専門分野に合わせて会話します。どちらかというと、専門用語を意識しないで使うのは他業種の専門家の方々です。もちろん他業種の専門家達も、極力専門用語を使わないように配慮してくれているとは思いますが、何故か情報技術者だけが非難される傾向があります。とはいえ、胡散臭いコンサルティングの方が、情報技術の専門用語を並べたてる場合もあるので、あながち根拠がない迷信とは言えないのが辛いところです。
　その他には、技術についての迷信もあります。IT業界はドックイヤーだと言われている事もあり、新技術ばかりを売り付けるという迷信が広がっています。しかしながら、本当のプロは技術の新旧に拘りません。拘るのは経営レベルの部分です。システム屋は、ビジネスプロセス・リエンジニアリングを基本としており、如何にしてお客様の会社の業績を伸ばすかを考えます。基本的にシステム屋は、ビジネスプロセスそのものをお客様と話し合います。自分が技術者である事を忘れてしまうぐらい、ビジネスマンもしくはコンサルタントとして会話します。情報技術について討論するのは開発時あって、お客様に対して技術的な事を殆ど言いません。
　おそらく、IT技術者＝オタクというデマをマスメディアに流されているせいで、この様な迷信が広がっているのだと思います。ですが実際のところは、IT業界も普通の商売をしており、他の商売と同じく技術オタクな言動をしません。もちろん、お客様に求められれば出来ますが、無意味に技術的な話しはせず、新技術を押し売りするなんて事はしません。
　他にも色々な迷信がありますが、システム構築は人間臭い仕事であり、IT業界はごく普通の人間が集まったごく普通の業界です。色々な迷信がありますが真に受けないでください。

ネタつつき102 - プロとは何か

　常日頃、私はプロとしてどうあるのべきなのかを考え続けています。もちろん、一人で考えるだけではなく、同業者の方やお客様とも一緒に話し合っています。その中で見出した事を一つの答えを書きます。
　プロのシステム屋とは何なのかを一言で言い表すと、お客様の要望を深く理解し、お客様に最も合ったシステムを提供する人です。技術だけを見てはお客様に合ったシステムを提供できませんし、言葉の表面だけを理解してもお客様の事を深く理解できません。
　システム屋のお仕事は、お客様と対話する事から始めます。対話するには、他業種のプロであるお客様が持つ知識を理解し、お客様が置かれている状況を分析しつつ会話せねばなりません。そのために私は、広範囲な業務知識をその都度勉強しています。それに加えて、事前にお客様が属している業界ニュース（時事問題）を調べます。
　私は天才ではありませんので、この勉強は正直言って辛い時もあります。他業種の方々が持つ、他の専門分野も際限なく奥深く、情報技術を学習しながら習得するのは困難です。心の中で何度も弱音を吐きました。しかしながら、お客様に合わないシステムは無価値です。どれほど技術的に優れていても、お客様がゴミだと思えばゴミなのです。
　専門家であられるお客様の領域に到達する事はないと思いますが、少しでもその領域に近づかないとお客様を真に理解できません。全てを極める事は不可能ですが、プロならば目指し続けなくてはなりません。そして私は、「こんな難しい事を習得しているお客様はすごい」と常に敬意を持って接します。
　当然のことながらシステム屋は情報技術も習得せねばなりません。昨今は分業化が進み、情報技術を知らなくてもいいという人もいますが、私はそう思いません。情報技術全般も毎日欠かさず学習しています。システムの品質を決めるのは自分の技術力です。技術力無くしてよいシステムは作れません。少しの時間でも何かを学習し続けています。情報技術はドックイヤーと呼ばれ、次から次へと新技術が登場しますが、弱音を吐く暇があったら学習します。それがプロだと私は考えています。情報技術を知らずとしてプロを名乗れません。
　今まで書いた事は知識と技術です。プロとして知識と技術を磨く事は大事ですが、それだけではプロとは言えません。心掛けも大事です。その心掛けとは、自分が習得した知識／技術に拘らない事です。技術を重んじる技術者が、技術を無視するのは大変ですが、お客様にとってどうでもいい事です。お客様の事を第一に考えます。
　人には好みがあります。しかし私は技術に対して、絶対に嫌いだと感情を抱きません。全ての技術を愛し選択肢を増やします。お客様にとって新旧は関係ありません。お客様の望みを叶える技術が必要なだけです。選択肢が広くなければ、お客様の要望を叶えられませんので全てを学習します。自分の都合で選択肢を用意しないのは怠惰であり、お客様に対する不誠実でもあります。
　初めは嫌いだと感じた技術でも、時代背景や作った人の努力を知れば、自ずと好きになります。努力しているのは自分だけだと思ったら大間違いです。自分が嫌いな技術でも、必死で作った人がいるのです。それを忘れてはなりません。技術を作った偉大なる先人達に対する敬意を忘れてはプロとは言えませんし、敬意を持たない人は一人の人間としてもどうかと思います。
　自分の考えを纏めていて気付いたのですが、もしかしたらプロとは「人に対して敬意を持つ人」なのかもしれません。まだまだ未熟な私の意見ですが、誰か一人でも参考になった人がいれば幸いです。

アジャイル開発を元に考えるプロジェクトマネージャのあり方18

　この記事はアジャイル開発を元に考えるプロジェクトマネージャのあり方17の続きです。前回は、大切な資源である時間と進歩管理について解説しました。今回は、時間管理と見積もり技法について解説します。
　残念ながら、納期以内にシステムを導入できない失敗プロジェクトが沢山存在します。この手の話題は、根性論で語られる事が多いのですが、私は能力の問題だと考えていません。何故ならば、能力の問題ではなく手法の問題だからです。
　プロジェクト失敗と聞けば、プロジェクト管理者の能力が低かった、開発スタッフの能力が低かった・・・などと能力の問題だと思いがちです。しかしながら、確かに能力不足で失敗したケースもあるかと思いますが、優秀な人やチームでも失敗するケースを多々見てきました。従って、能力の問題だけだと思いこみ従来の方法を変えないと、この見積もり問題は解決しません。手法そのものを見直す必要があります。
　様々な見積もり手法が存在しますが、それらの手法は暗に、未来を予測できる、もしくは仕様が不変である事を前提としています。本当にそうであればよいのですが、情報システムの性質を考えると不可能な条件です。仕様は変化しますし、事前に情報システムの全てを把握できません。
　その原因は、悪質なケースを除けば、お客様の心変わりにあるのではありません。市場そのものが変化するのであって、お客様の態度を失敗の原因にするのは現実逃避に他なりません。昨今のビジネスは変化に柔軟に対応する事が求められており、システムを導入する我々のお客様も苦しんでいるのです。
　システム開発はよく建築と比較され、従来の見積もり技法もその思想が見え隠れしますが、建築と情報システムは違います。情報システムの性質を良く考えなくてはなりません。その答えが、変化を前提とするアジャイル開発の見積もり技法にあります。
　アジャイル開発ではユーザーストーリー単位で見積もります。「システム全体の納期は1年後」というふうに未来予測をするのではなく、「このお客様の要望ならば1週間」というふうに個別に見積もりをします。ただし、お客様の要望が「1年以内にシステム稼働」などといった時間に関する制限がある場合があり得ます。その場合は、現状分析と要求分析をある程度しておく必要がありますので注意して下さい。鍵となるのは変化に対して柔軟かつ迅速な対応する力です。
　纏めとして、今までの内容を踏まえて、プロジェクトマネージャのあり方を書きます。現在のプロジェクトマネージャに求められるのは、変化に対して柔軟かつ迅速に行動する力です。具体的には、交渉能力・決断力・コミュニケーション力の3つが重要な能力だと言えます。これらの能力は、熟練のプロジェクトマネージャが持っている力です。見積もり技法さえ変えれば、従来持っている力を駆使して、難しい時間管理を達成できます。


参考書

初心者のためのC#プログラミング本格入門30 - 任意の式から演算子を取り出す方法

　この記事は、初心者のためのC#プログラミング本格入門29の続きです。前回はSystem.Tuple型について解説しました。今回は前回の復習も兼ねて、「任意の式から演算子を取り出す方法」について解説します。
　「自由に計算式を指定して計算するプログラム」を作るには、演算子を取り出す処理が必要になります。前回と同様の手法を使って、任意の式から演算子を取り出す処理をプログラミングしてみましょう。
　模範解答は・・・

private static System.Tuple<char, string> GetSign(
    string inputValue )
{
    //演算子の位置を探す
    int index = -1;
    for ( int i = 0; i < inputValue.Length; i++ )
    {
        char sign = inputValue[ i ];
        if ( sign == '+' | sign == '-' |
            sign == '*' | sign == '/' | sign == '%' )
        {
            index = i;
        }
    }

    //演算子を取り出す
    if ( index == -1 )
    {
        string errorMessage = "演算子を含んだ式を指定して下さい";
        System.Console.WriteLine( errorMessage );
        System.Environment.Exit( 1 );
    }
    char outputValue = inputValue.Substring( index, 1 )[ 0 ];

    //取り出した演算子以外の文字列を取得
    string remain = inputValue.Remove( index, 1 );

    //結果を返す
    System.Tuple<char, string> result =
        new System.Tuple<char, string>( outputValue, remain );
    return result;
}

おそらく大部分は簡単だと思いますが、

char outputValue = inputValue.Substring( index, 1 )[ 0 ];

が難しかったかもしれません。このプログラムは、文字列から文字を取り出しています。Substringメソッドは文字列を返しますので、1文字であるcharを取り出すには、0番目の位置にある文字を取り出す必要があります。ちょっとややこしいですが、C#では文字列内の文字を0から数えます。
　ここで、「1文字だけを取り出しているのに、何故文字列なのか？」という疑問が湧くでしょう。1文字しかない文字列はおかしいと思う人もいるでしょうが、C#が勝手に文字列を文字へ変換しないためにそうなっています。今はまだわからないと思いますが、プログラミングをしている人が知らない間に、型が変換されると困る状況が多々あります。ですから、今のところそうするものだと考えて下さい。
　これで「 12345 + 6789 」の様な式から数値と演算子を取り出せます。

static void Main()
{
    //数値1を取り出す
    string inputValue = " 12345 + 6789 ";
    System.Console.Write( "指定した式:" );
    System.Console.WriteLine( inputValue );
    System.Tuple result = GetValue( inputValue );
    System.Console.Write( "取り出した数値:" );
    System.Console.WriteLine( result.Item1 );
    System.Console.Write( "残りの文字列:" );
    System.Console.WriteLine( result.Item2 );
    System.Console.WriteLine();

    //演算子を取り出す
    inputValue = result.Item2;
    System.Console.Write( "指定した式:" );
    System.Console.WriteLine( inputValue );
    System.Tuple result1 = GetSign( inputValue );
    System.Console.Write( "取り出した演算子:" );
    System.Console.WriteLine( result1.Item1 );
    System.Console.Write( "残りの文字列:" );
    System.Console.WriteLine( result1.Item2 );
    System.Console.WriteLine();

    //数値2を取り出す
    inputValue = result1.Item2;
    System.Console.Write( "指定した式:" );
    System.Console.WriteLine( inputValue );
    result = GetValue( inputValue );
    System.Console.Write( "取り出した数値:" );
    System.Console.WriteLine( result.Item1 );
    System.Console.Write( "残りの文字列:" );
    System.Console.WriteLine( result.Item2 );
    System.Console.WriteLine();
}

GetValueメソッドの内容は前回と同じです。
　ここまで分かれば、「自由に計算式を指定して計算するプログラム」を作れます。このプログラムを作れる実力が身に付けば、レベルアップしたと思ってよいと思います。

実践的オブジェクト指向分析入門33

　この記事は実践的オブジェクト指向分析入門32の続きです。前回は、要求定義と動的モデルの関係について解説しました。今回は、動的モデルの構築の最初に行うべき作業である「事象の発見」について解説します。
　OMTでは動的モデルを、「システムおよびその中のオブジェクトの時間に依存した振る舞いを表す。」と定義しています。そして、動的モデルは事象の発見から始めるとされています。これから、現代に即した事象を発見する方法を解説します。
　事象の発見は様々な方法が考えられますが、ユースケース図とアクティビティ図を書くとよいでしょう。ユースケース図とアクティビティ図のどちらを先に書くかについては状況次第です。分析対象が複雑な場合はユースケース図を先に書き、全体像が明らかならばアクティビティ図を先に書きます。とはいえ、実務では両方同時に書く場合が多いので、順番については意識しない方がよいでしょう。
　ユースケース図については今まで解説してきたので省略し、アクティビティ図を書く際の注意事項について述べます。
　オブジェクト指向分析の段階で書くアクティビティ図は、ビジネスプロセスの流れです。誤解されやすいのですが、アクティビティ図はプログラムのロジックだけを対象とした図ではありません。実装段階で書くのであれば、実際にプログラミングした方が早いです。
　アクティビティ図はそういった目的ではなく、抽象度が高いビジネスプロセスを書くのに適しています。何故ならば、並列処理をサポートしており、抽象度が高い事象も表現できるのでビジネスプロセスを可視化しやすいからです。実際の業務は並列して行われる事が多く、並列処理を表現できる事は重要な要素です。
　ただし、並列処理に関する記述には表現力が不足しているので注意が必要です。並列処理を考える時、詳細な情報が欲しくなりますが、アクティビティ図は並列処理に関する詳細な情報を書くのには向いていません。アクティビティ図は抽象的に考えるのに使用します。
　アクティビティ図が書き終わったら次の作業をします。続く...

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

　この記事はシステム開発における情報セキュリティ3の続きです。前回は、システム開発で最初にするべき情報セキュリティの取り組みについて解説しました。今回は、見つけ出した情報資産についての分析を解説します。
　情報資産を見つけた後、するべき事があります。それは、情報資産の価値を算定する事です。情報セキュリティは、全ての情報資産を無目的に保護する概念ではありません。情報の価値に見合った適切な対応をするのが情報セキュリティです。
　とはいえ、情報資産の価値を算定すると言われてもピンとこない人が大半でしょう。全てを語るときりがありませんので、開発者が知るべき事柄を噛み砕いて解説します。
　先ず、情報が持つ価値とは何かについて考えます。開発者は全てが等しく思えるかもしれませんが、企業から見れば情報にも価値の高低があります。
　例えば、お客様についての情報は、有効に使えば多大な利益をもたらします。また、漏れれば法的および倫理的な問題が生じ、企業に多大な損害を与えます。一方、自社が販売している商品の名前は広く知られないと困ります。ですが、自社が全力で資財を投入している重要な商品についての技術情報が漏れれば大変困ります。
　これらの例から分かるように、情報資産には経済的な価値があります。しかしながら、全ての情報を完璧に保護するのは人間には不可能ですし、セキュリティには費用がかかります。従って、価値の高低を判断し、価値が高い情報は厳重に保護し、価値が低い情報は緩く保護します。
　システム開発の初期段階では、ひとまず段階的評価するところから始めます。情報システムの性質にもよりますが、利便性を考えると5段階評価ぐらいの粒度が好ましいと思います。なお、情報資産の評価は、開発側とユーザー側の双方が行うべきです。何故ならば、情報の価値は立場により異なり、クラッカーはその盲点を利用して犯罪を実行するからです。
　例えば、ユーザーが価値を見いだせないシステム設計に関する情報でも、クラッカーがその情報を利用してシステムをクラッキングできます。その逆に開発側が重視していない情報でも、ソーシャルエンジニアリングによるクラッキングが行われる可能性が十分にあります。それらの犯罪を防ぐために、多面的に情報資産を評価し、盲点をなくす努力をしなくてはなりません。一つの盲点がシステムの全てを駄目にします。情報セキュリティの実施は、慎重で抜け目ない姿勢で臨みます。