真正性をつつく2 - 識別子と認証方法の決定

　この記事は、真正性をつつく1の続きです。前回は、真正性が保証するオブジェクトとは何かについて解説しました。今回は、識別子と認証方法について解説します。
　真正性を考慮したシステムを作るためには、対象の決定後に識別子と認証方法を考える必要があります。人や情報が本当に正しいのかを判断するには、名乗っているオブジェクトの等価性を判定します。ですが、無闇にその人の等価性を判断する事は出来ません。何らかの識別子が必要となります。毎度おなじみの例を元にその事について考えてみましょう。
　目の前にいる営業部長山田太郎と名乗る人物は、本当に営業部長の山田太郎氏なのでしょうか？言動だけでそれを判定する事は出来ません。それだと余りもいい加減であり、確認する人が口車に乗ってしまえばお終いです。営業部長の山田太郎氏だと確認を持てる動かぬ証拠が必要です。そうした認証に関する問題に対処するため、人類はいくつかの認証方法を考え出しました。
　認証技術は常に進化しているので、その全てを知っているわけではありません。私が知る限り認証方法は、記憶認証、所持認証、属性認証があります。情報システムは、それらの認証方法を用いて真正性を確保します。これから個々の認証方法を解説します。
　最も一般的なのが記憶認証です。そのオブジェクトしか知りえない情報を記憶していたら、そのオブジェクトだとみなします。これを読んでいる人は、殆どの人がOSを立ち上げる時に、パスワードを入力しています。これをパスワード認証と呼びます。パスワード認証は実施に殆どコストがかからないので、多くの場面で採用されていますが、認証方法としては弱い部類に入ります。何故ならば、その人の生年月日や有名な単語などの単純なパスワードならば他人でも容易に推測できますし、パスワードを書いた紙を読めばお終いです。この様に記憶認証は色々な弱点がありますが、何時でも変えられるという長所を持っています。重要なので、記憶認証の長所と短所をぜひ覚えておきましょう。
　所持認証とは、特定の持ち物を所持しているオブジェクトを、そのオブジェクトだとみなす認証方法です。例えば、キャッシュカード、ICカード、スマートカードなどがあげられます。所持認証は色々な工夫が出来るものの、識別子となる物が他人に奪われると破られますし、偽装などの方法で突破する事もありえます。所有物の紛失についてよく注意しましょう。
　属性認証とは、本人の生体情報を照合して認証する方法です。生体情報は虹彩（アイリス）、指紋、DNA、静脈、声紋・・・など色々あります。生体情報は極めて信頼できるデータですが、風邪をひいて声が変わり、本人でも認証されないなどといった本人拒否の問題があります。それに加えて、人工的に指を作って指紋認証を突破するなどの手口も考えだされており、必ずしも完璧だとは言えない状態です。なお、生体情報は漏れてはならないプライベートなデータです。生体情報は厳重に管理しましょう。
　以上のように、全ての認証方法には弱点が存在します。従って、どれか一つだけを採用するのではなく、複数の認証方法を組み合わせる多要素認証が一般的です。実務的なシステムは必ず複数の認証方法を採用しましょう。

ネタつつき125 - 情報の粒度と抽象度は重要

　仕事をしていると、出来る人とできない人に差を感じる場面が沢山あります。そのうちの1つが、情報の粒度と抽象度の取り扱い方です。これが下手な人は仕事が出来ず、上手な人は仕事が出来る傾向があると感じます。統計を取って検証しておりませんが、経験上おおむね正しいと私は考えています。
　情報の粒度というのは「細かさ」です。仕事が出来る人は、情報の細かさについて適切な判断を下せます。具体的には、その仕事の段階で必要なだけの情報の細かさで書類を書いたり、分かりやすい報告をしたり出来ます。一方仕事が出来ない人は、不必要に細かい情報を出したり、必要な時に情報が欠けたりします。他にも、やたら細かい事を言って業務を妨害したり、細かい配慮がないため仕事の質が悪かったりします。
　情報の抽象度についてはIT業界の人ならばよく分かると思います。分析段階、設計段階、実装段階などの開発工程により、扱う情報の抽象度が違います。分析段階では、どちらかというと人間よりの抽象度が高い情報を扱い、実装段階ではコンピュータよりの抽象度が低い情報を扱います。仕事が出来る人は、抽象度も正しく判断できますので、作業がスムーズに進むのは想像に難くないでしょう。
　システム開発に於いて、抽象度が適切に扱えない人は問題になります。よく、営業マンとプログラマーは仲が悪いなどと言いますが、コミュニケーションにおける情報の抽象度が適切でない事が原因です。営業マンからしてみれば、プログラマーの言う事は抽象度が低すぎてわけが分かりません。逆にプログラマーからしてみれば、抽象度が高すぎて上手く実装に落とし込めずイライラします。この様に、抽象度を意識せずコミュニケーションを行うと悲劇が生じます。
　営業と開発のように極端な例だけではなく、抽象度を上手く使いこなせないと、分析・設計・実装の各段階をこなす技術者になれません。全ての段階をこなす必要がなくとも、システムエンジニアとプログラマーのコミュニケーションもうまくいきません。従って、抽象度を使いこなせない人は非常に不利だと言えるでしょう。
　情報の粒度と抽象度を理解できないと、他にも色々な問題が発生します。対人関係だけではなく、読解能力にも悪い影響を与えます。読解力が低い人を観察すると、その文章が扱っている粒度と抽象度を理解しておらず誤読しているケースが多々見受けられました。残念ながらその様な人は、資料や専門書から適切に情報を引き出せません。
　私は以上の事から、情報の粒度と抽象度に非常に気を配っています。経営者に対しては粒度が大きく抽象度が高い情報を、プログラマーに対しては粒度が小さく抽象度が低い情報を扱います。むろん、情報の内容も重要です。経営者にCPUの動作を言っても聞いてもらえません。これは言うまでもないでしょう。
　この記事を読んでいる貴方は情報の粒度と抽象度を意識していますか？もししていないのであれば、今日から意識しましょう。そうすれば、仕事もプライベートも今よりもよくなります。情報の粒度と抽象度はそれ程重要なのです。

初心者のためのC#プログラミング本格入門65 - 数値は色々あるよ

　この記事は、初心者のためのC#プログラミング本格入門64の続きです。前回は、漏れの無いテストをするのかについて解説しました。今回は、プログラミングにおける数値の扱いについて解説します。
　大量のテストデータを扱うには、数値そのものに関する知識が必要です。数値と言うと簡単そうだと思う人もいるでしょうが、実のところ数値は結構難しいオブジェクト（もの）です。どの様に難しいのかと言いますと、C#では数値に複数の種類（型）があり、状況によりそれらを使い分けなくてはなりません。
　C#にある代表的な数値の型は、sbyte、byte、short、ushort、int、uint、long、ulong、float、double、decimalです。これらを合わして値型と言います。値型は大変重要なオブジェクトで、これらのオブジェクトを状況に合わして使いこなします。
　初心者の方は、何故これほど多くの数値を表す型があるのかと不思議に思うでしょう。その理由は、コンピュータは2進数で動いているからです。私達人間が普段使っている数は10進数です。でも、電気で動いているコンピュータはプラスとマイナスを表す2進数で動いています。その違いを埋めるには、2進数を10進数へと変換せねばなりません。
　2進数から10進数の変換に当たって、色々な問題が生じてきます。10進数「8」を2進数で表そうとする「1000」です。この数値はWindowsのアクセサリ電卓を使えば確認できます。この時点で勘の良い人は察すると思いますが、数値を表そうとする1と0が複数個必要になります。ですから、その数をどれだけ取るのかで表せる数値の範囲に違いが出ます。その数値の範囲の違いが数個の型で表現されています。
　ここまでの説明で、個々の型がどれだけの範囲の数値を表せるのか気になったと思います。幸いC#にはそれを確認する術があります。次のプログラムを実行すれば、最小値と最大値を確認できます。

class Program
{
    static void Main()
    {
        System.Console.WriteLine( "{0} ～ {1}", 
            int.MinValue, int.MaxValue );
    }
}

この例はint型だけしか指定していませんが、byteの様な他の型にも、MinValueプロパティとMaxValueプロパティがありますので同様の方法で値の範囲を知る事が出来ます。
　この2つのプロパティ、MinValueとMaxValueを上手く使えば、全ての数値を試さなくてもテストを効率よく実施できます。具体的な方法は次回解説します。スペースの都合上今回は、2進数の説明を省略しましたが、プログラミングをする上で2進数は大変重要です。プログラミングをするなら、是非とも2進数を学んで下さい。機会があれば、このブログで2進数の解説をしたいと思っています。今回はこれで終わりです。

中の人の徒然草400

そういえば、最近日記を書いていない・・・というわけで日記を書きます。
最近思ったのは年金システムと増税についてです。
政府は必死で年金システムの維持を訴えていますが、そもそも年金システムなんていらないと思ってしまいます。
私達30代にしてみれば、既に破綻しているシステムに対して、莫大な維持コストが必要な上に、恩恵が何もないシステムなんて存在意義がありません。
今の年金システムはどう見てもネズミ講であり、それに対して税率をあげてつぎ込むなんてナンセンスです。
年金は運用などと言ってなんとなくお金がなくなった（笑）だとか、システムのミス（笑）、グリーピアでなくなった（笑）などと、責任もなくなんとなく消えております。おまけに誰も責任を取らない。業務システムではありえない状態のシステムです。
元をただせば、収入がなければ生活保護の様なセーフティネットを充実させればいい話であって、維持コストも考えずに、簡単にお金が消えていくいシステムに、国民のお金をつぎ込むなんて信じられない行為です。
そんな事をするよりも、セーフティネットをどうするべきなのかという根幹を考えるべきであって、システムは維持コストも含めて考えないとならないという基本原則を分かっていません。
それに加えて、私は敬老精神を持っておりますが、だからと言ってお年寄り＝貧乏＝救うべき存在だとは思いません。
そういった考え方こそ、お年寄りに対する蔑視であって、お年寄りだからと言って経済能力がないとは限りません。
お年寄りだから、女だから、子供だから・・・等と言って、色々なシステムを維持コストも考えずに作っては、お金を消費し続けておりますが、それは本質ではなく、国民の生命を守るという国家の原則を考えるべきだと私は思えてなりません。
そうした、コストを考えずに破たんしたシステムにお金を無駄に消費しているケースは沢山あります。
もしかしたら、日本人はその辺のバランス感覚が苦手なのかもしれませんね。
増税ばかり唱えられていますが、その前に使うべき対象とその価値をはっきりさせてほしいです。
なんとなく増税されても、まだ無駄なシステムに浪費されるだけだと思うと、納税する喜びを感じられません。
納税を通じて、日本社会の発展につながるのであればよいのですが、変なシステムにお金を喰われるだけならば、汗と血を流して稼いだお金を国に納めるなんて考えが湧いてきません。
増税だとか言う前に、税金の流れを可視化するシステムが欲しいです。むろんそのシステムに無駄なコストを掛けないという前提がありますが、コストと価値の感覚も政府と行政はないんだよね・・・
そもそも経済感覚がない政府に富の分配なんてできるのでしょうか？前提が間違っているという気がしてなりません。
システム屋の私は、要求分析をちゃんとしているか？要求定義をちゃんとしているのか？の2点が気になります。
その2つの前提が欠けている状態で、増税だとか年金だとか、笑止千万です。要求が定まっていないシステムは使い物にならないのは明白であって、その様なものにお金や労力を浪費しづけている今の日本は異常に思えてなりません。
景気が悪い、デフレ経済、少子高齢化・・・など色々言っておりますが、今ある土台のシステム（OS）をちゃんとしない限り、何をしても無駄なのであって、何が悪いではなく、何をしたいのか、どうするべきなのかを議論するべきだと私は思います。
何をしたいのかという事をあいまいにさせたまま、なんとなく良くしようとする日本は、私が度々目にしている廃棄対象となるシステムに見えてなりません。
とはいえ、日本の国家システムというOSは、どれほどウイルスに侵されようが、どれだけ問題があろうが、簡単に再起動できないから、問題なんだよな・・・
再起動せずにOSを修正するには、現在のモノリシックカーネル型日本を、マイクロカーネル型日本にするべきです。
マイクロカーネルが地方分権を意味するのかそうでないのかは、今のところ分かりません。
地方分権と言っても、OS（社会基盤）として正常に働くとは言えないし、日本特有の要求定義＆要求分析を行わない体質があれば、OSどころかウイルスもしくは廃棄対象となるべきシステムが増える結果になってしまいます。
よく専門家は、あそこが駄目ここが駄目だと細かいことばかり言っていますが、日本のモデルを提示したり、要求定義＆要求分析をする事から始めてほしいものです。
要求を明確にしないシステムなんて使い物にならないのですから、モグラたたきのように、日々発生するバグだけを対処しようとしても事態は一向に良くなりません。
基本を正しく行う。それだけで、日本は戦後の復興を超える勢いで成長するかもしれません。何はともあれ根本から間違っているから、システム開発の基本からやって頂きたいです。

ネタつつき124 - システム開発で求められている能力

　世間から誤解されがちな職業をしているので、長年システム屋として仕事を遂行していて、必要だと感じた能力を書きます。最初に感じたのは創造力です。これについては以前書きました。ですが、それ以外の能力で重要な能力もあります。より厳密に言うと、創造力の前提となる能力です。
　私達システム開発に従事している者達は、毎回新しい事に直面し、それを理解することを求められます。ビジネスで役に立つシステムを作る以上、その対象となるビジネスを理解せねば話しになりません。しかしながら、私達にとって異なる業種のお仕事は未知なる分野です。お客様にとって当たり前のことでも、異業種の我々にはわからない事ばかりです。
　世間一般ではシステム開発というと、プログラミングばかりしているとか、コンピューターの事ばかり考えていると思っているでしょうが、実のところ異業種の学習に多くの時間を費やしています。システム屋の私が最初にする事は、システム設計とかではなく、お客様を早期に理解する事です。
　お客様はどの様に毎日の業務をこなし、何を考えているのかを早急に察しないとシステム開発は始まりません。ですから、私達システム屋は、世間が思っている以上に非コンピューターの学習に時間を費やしています。異業種のプロであるお客様と対等に会話をしないとならないのですから、コンピューターの事ばかりを考えていては務まりません。お客様の事を理解しないと、お客様が満足するシステムを提供できません。
　そういった事から、創造力の前提として、正確かつ速く物事を習得する能力が必要となります。より具体的に書くと、システム開発の依頼が決まる前から、そのお客様の業種について研究します。システムを納品するまで研究は続くのですが、少なくとも1週間ぐらいで、お客様と業務内容について話し合うレベルに至らないと、仕事は消えてしまいます。
　これは非常に大変です。理由は知りませんが、他業種の人は我々技術者が知っていて当たり前だと考えているので、お客様に合わせてこちらが常に学習するしかありません。おそらく、自分たちの仕事が常識化しているので、他業種の人には分からないという事を失念しておられるのでしょう。
　なにはともあれ、お客様から要望を引き出すには、お客様の目線で物事を考えなくてはなりません。その為には、新しい物事を素早く習得せねばなりません。一言で言うと、情報吸収能力と言えると思います。この情報吸収能力がなければ、システムの開発作業すら始められないでしょう。非常に重要な能力だと言えます。
　むろん、情報吸収能力だけではシステムは開発できません。吸収した情報を如何にしてシステムで解決するのかという、創造能力がなければ何も生み出せません。知っているだけではだめで、知っているから何をするというアクションが求められております。
　かといって、他業種の仕事ばかり学習していては、システム屋は務まりません。日進月歩で進化する情報技術について深く知る必要があります。しかしながら、私は普通の人間ですから、全てを完璧にこなすと頭がパンクしてしまいます。これに対応する為に、第3の能力である選択的忘却能力が必要となります。
　選択的忘却能力とは、今現在必要でない情報を忘れて、脳のパフォーマンスを保つ行為です。システムの依頼があるとその業界について深く知り、仕事が終わると要点を除いて忘れます。全てを暗記する必要はありません。細部の情報は外部記憶装置に任せて、必要な時に直ぐに取り出せる様にしておけばよいのです。自身の脳をより効果的に使うべきです。
　纏めます。システム屋といえば、コンピューターおたくのように思われがちですが、実際のところはコンピューター以外の事柄も考えているジネスマンです。システム開発をビジネス的に成功させるために必要な能力は創造力であり、創造力を発揮するためには情報吸収能力と選択的忘却能力が必要です。仕事が始まれば新しい物事を素早く大量に習得し、仕事が終われば素早く大量に忘却します。システム屋というお仕事は、大量に情報を消費し新しい情報と価値を生み出すお仕事だと言えるでしょう。

真正性をつつく1 - 真正性の対象を見極めよう

　この記事は、真正性をつつく0の続きです。前回は、真正性を保証することのむずかしさを書きました。今回は、真正性が保証するオブジェクトとは何かについて解説します。
　前回、真正性とは「情報を要求するオブジェクトが本当に主張通りのオブジェクトなのかを保証する特性」だと書きました。オブジェクトだと書いてある点に注目して下さい。オブジェクトと考える事が重要です。何故ならば、真正性と言うと多くの人は人間を思い浮かべますが、保証するべき対象は人だけに限らないからです。人が発する言葉の内容も対象となります。その他にも、プロセスなどといったプログラム的なものも対象となります。
　前回提示した、営業部長の山田太郎（仮名）が緊急の用件で来ているケースを元に考えてみましょう。真正性の対象となるオブジェクトを大別すると、営業部長の山田太郎と、要求している内容である緊急の用件です。この人は本当に営業部長の山田太郎なのでしょうか？緊急の用件とは何なのでしょうか？順を追って考えていきましょう。
　先ず問題となるのは、山田太郎という人物が存在するか否かです。犯行をもくろむ人物が、適当な偽名を使っている可能性があります。山田太郎氏が存在するのか否かをどうやって知るのでしょうか？オブジェクトの存在を確認する方法を考えなくてはなりません。
　次に考えるべき事は、営業部長としての山田太郎氏が存在するか否かです。情報部長の山田太郎氏が存在するものの、営業部では存在しないかもしれません。また、営業部に山田太郎氏が存在しても、部長でないかもしれません。他にも、同姓同名の人物が存在する場合もあります。こうした色々な可能性を視野に入れなければなりません。
　最後の「緊急の要件」と言うオブジェクトについては、より慎重に考える必要があります。何故ならば、これは複合オブジェクトだからです。要件そのものと、緊急の用件に対する行動を伴っています。緊急の要件というオブジェクトと、それに伴い求めている行動というオブジェクトを見極める必要があるのです。さらに要件の内容によっては、さらなるオブジェクトがそこに含まれています。
　以上のように、真正性は対象を見極める事が大切です。対象をはっきりさせないと、保障されていないオブジェクトを許可してしまうかもしれません。クラッキングもしくは詐欺の手口は、その多くが対象そのものを誤魔化す事から始まっています。おれおれ詐欺が格好の例でしょう。息子が存在するにしても、電話越しに存在する彼が本当に息子なのかという事をはっきりさせずに、彼の言う言葉を信じてしまうと大変な目に遭います。
　今回は、真正性の第1段階である「対象の識別」について解説しました。次回は次の段階を解説します。

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

　この記事は、実践的オブジェクト指向設計入門5の続きです。前回は、データストアの管理について解説しました。今回は、大域資源の扱いについて解説します。
　システムには、プロセッサ、テープドライブ、通信衛星などといった物理的な資源があります。また、ディスクスペース、ワークステーション画面やマウスボタンと言った空間（位置情報）、オブジェクトID、権限、などといった論理的な資源があります。これら多くの人から使用される資源の取り扱い方を慎重に考えなくてはなりません。
　取り扱い方を考えないと、思わぬトラブルを生みます。オブジェクトIDの例について考えてみましょう。グローバルなオブジェクトIDは、一意でなければ大変な事になります。オブジェクトIDが利用者を表す場合、同じIDがあるという事は、なりすましが容易に可能となるシステムだという事です。他にも、オブジェクトがリソースであった場合、同じIDが存在してしまうと、リソースが判別できない事になり、予期せぬトラブルが発生してしまいます。IPアドレスが重複していればどうなるのかを考えると分かりやすいと思います。
　大域資源は、割り当て方、意味と制御方法、回収もしくは破棄の三つの事柄を考えます。つまり、どの様にして大域資源を発行するのか、その大域資源は何を意味しどの様に制御するのか、用事がなくなったら回収もしくは廃棄をどの様にするのか・・・などを考える事になります。「など」と書いてあるのは、大域資源の性質により異なるからです。私の経験から言うと、大域資源を見つけ出し、その性質を考える事から始めるとよいと思います。
　大域領域への同時アクセスは極力避けるとよいとされています。その理由は、資源のロックが難しいからです。トラブルを避けるために、あらかじめ大域領域へのアクセスを減らすシステムを設計しておけば、それだけトラブルの種が消えます。保守的すぎて使用し難いシステムになっては元もこうもありませんが、何でも大域資源として取り使いシステムを複雑化させるよりも、シンプルなシステムの構成を考え、大域領域の必要性を極力減らす様に設計するのが賢いやり方です。

初心者のためのC#プログラミング本格入門64 - 入力値を網羅したテストの作り方（序論）

　この記事は、初心者のためのC#プログラミング本格入門63の続きです。前回は、テストのあり方について解説しました。今回は、どうやって大量の入力データを使って、漏れの無いテストをするのかについて解説します。
　あらゆる入力値を考え、その入力値を手作業で入力して、プログラムの正しさを確認するのは大変です。だからと言って、少数のテストデータでプログラムが正しく動作するものと考えると、思わぬ間違いを見逃す羽目になります。一体どうすればよいのでしょうか？
　その答えは意外と簡単です。今まで覚えたC#の文法と機能を使ってテストプログラムを作れば解決できます。実際にやってみましょう。

//簡単な式が指定された場合の解析処理をテストする
public void AnalyzeSimpleExpression()
{
    //全演算子をテスト
    char[] signs = new char[] { '+', '-', '*', '/', '%' };

    //演算子が前の式をテスト
    foreach ( char sign in signs )
    {
        this.AnalyzeTest( sign + " 1 2 " );
    }

    //演算子が中間の式をテスト
    foreach ( char sign in signs )
    {
        this.AnalyzeTest( " 1 " + sign + " 2 " );
    }

    //演算子が後の式をテスト
    foreach ( char sign in signs )
    {
        this.AnalyzeTest( " 1 2 " + sign );
    }
}

前につくったテストプログラムを、全ての演算子についてテストするように改良してみました。これでひとまず、演算子がどこの位置にあろうとも、簡単な式ならばエラーがでない事がチェックできました。
　しかしながら、全ての数値については検証していません。今回のテストは値を1と2で固定しているので、もしかしたら違う値を入力した時にエラーになるかもしれません。とはいえ、全ての数値を同様の方法でテストするプログラムを作るとなると、初心者にとって大変な上に、チェックするのに時間がかかり過ぎます。
　一度テストを実行したらずっと待たされる状態は好ましくありません。何故ならば、誰でも長時間のテストを頻繁に実行したくなくなり、実施されないテストになってしまうからです。テストは常に読みやすく実行しやすいものでなくてはなりません。テストは何度でも実行できる事に価値があります。
　テストプログラムは単純に全てチェックするのではなく、入力する方法とデータに工夫が必要です。実のところプログラムのテストは、知識の差が出やすい分野です。ちょっとした事を知らないと大損します。次回その工夫について解説します。お楽しみに。

初心者のためのC#プログラミング本格入門63 - テストは極力網羅しよう

　この記事は、初心者のためのC#プログラミング本格入門62の続きです。前回は、エラーテストについて解説しました。今回もテストについて解説します。
　いままで、正常処理時のチェックと、エラー処理時のチェックを解説しましたが、これだけでは不十分です。プログラミングは些細なことが思わぬ問題を発生させるので、テストは色々な状況を考えて行います。サンプルプログラムを元にテストについて考えましょう。

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

    //簡単な式が指定された場合の解析処理をテストする
    public void AnalyzeSimpleExpression()
    {
        this.AnalyzeTest( "1 + 2" );
        this.AnalyzeTest( "+ 1 2 " );
        this.AnalyzeTest( "1 2 +" );
    }

    //解析処理のテストの共通部分
    private void AnalyzeTest( string value )
    {
        this.target.AnalyzeExpression( value );
        if ( target.Success == false )
        {
            System.Console.WriteLine(
                "式" + value + "が解析できていません。" );
        }
    }
}

今までは一つの式しかテストしていませんでしたが、テストは入力値を極力網羅しなくてはなりません。入力値を網羅していないと、問題が露呈しない事があります。色々な入力値をテストしましょう。
　もうひとつ重要なのは、テストプログラムでも共通部分を取り出し、プログラムを簡潔に保つ事です。テストプログラムが簡潔に記述されていないと、テストプログラムに過ちがあっても気付かない可能性があるからです。テストプログラムのテストは普通作りませんから、簡潔さは非常に重要です。
　テストプログラムが複雑になる場合は、テスト対象が正しく設計されていないか、プログラムが複雑な場合です。簡潔なテストプログラムを心掛けていると、プログラムだけでは分からない論理的な問題にも気づけます。テストプログラムが複雑だという事は、そのオブジェクトを扱いにくい事や、プログラムで解決したい問題を十分に理解していない事を意味します。そういった問題に対する対処法は、プログラミングの範囲を超えるのでこの連載では取り扱いませんが、問題に気付く事から全ては始まります。テストプログラムは如何にして多くの問題を検出するかを考えて作っていきます。
　初心者の方は、テストプログラムを作っていると、その時間が必要になるから生産性が落ちるのではないかと不安になるかと思います。ですが心配ご無用です。テストプログラムを作らずに、頭の中であれこれ考えたり、だいぶ後で問題が発覚したりすると余計に時間がかかるので、簡単なテストプログラムを作った方が結果として生産性が上がります。特に初心者の頃は、数多の中で色々考えると混乱しやすいので、思った事は全てテストプログラムで検証するぐらいの姿勢を持つと、短時間でプログラミングを習得できます。
　ただし、テストの網羅性を突き詰めるとテストプログラムが膨大な量になります。膨大なパターンの入力値を全て考え、そのテストプログラムを作ろうとすると色々問題が発生します。どうやって対処するのか次回で解説します。お楽しみに♪