Winduws8がもたらすものはオンデマンドビジネス

　私はシステム屋としてWindows8に注目しています。その理由は、いつでもどこでも仕事ができる状態になる点を評価しているからです。今までのWindowsはデスクトップと組み込み（WindowsCE）で別れていました。それでシステムを開発する際に手間をかけていました。しかし、Windows8になるとその苦労もなくなります。これにより開発コストを下げられ、より場所を選ばない形態のシステムを考えられるようになります。
　デスクトップOSはその名の通り、ディスクに座ってする仕事を想定しています。しかしながら、そういった仕事は一部であり、逆の仕事の方が多くあります。さらに、情報を処理するべき場所はどこにでもあります。従って、適用範囲としてはCEの方が広いのですが、実際のところは開発し辛い状態でした。Windows8が登場したらその心配はなくなります。
　いままでのビジネスは、場所を固定されるものであり、情報時代と言われている割には、仕事のやり方が前時代的でした。これは、情報技術の恩恵を少ししか得られていない事を意味します。世の中にレガシーシステムが沢山存在しますが、一番レガシーなのは人間です。人間が古い慣習に縛られている限り、新しい時代を真に迎えたとは言えません。いつでもどこでも仕事が出来る方が生産性も高く、よりきめ細かいサービスを提供できるようになります。さらには、ビジネスの幅も広がります。
　日本は特にそうなのですが、場所に縛り付けて根性論で仕事させる苦行を仕事だと呼んでいます。しかしそれは、本当の意味で仕事ではありません。苦行と仕事を結びつける事態がナンセンスです。人間の生産力を高めるには、苦行よりも知的で創造的な仕事させる方がいいのに決まっています。これは1990年代に既に言われていた事ですが、未だに日本は情報技術があるのにも関わらず、もっと昔の考えに縛られて従業員に苦行を強いています。これでは、商売をするのが目的なのか、人を築けるのが目的なのかわかりません。商売をするのが目的であるのならば、もっと合理的に生産性を高めるべきです。
　こういった話題になると、マスメディアは機械的で人の心を捨てるのに等しいという風な論調で情報技術を否定します。やれ、IT会社もしくはIT関連会社はマネーゲームをしているだとか、情報技術は犯罪を生んでいるだとか、昔は良かったなどと情報技術を感情論で否定しがちです。ですが、マネーゲームをしているのは相場師であり、そもそもIT会社の仕事ではありません。そもそもIT関連会社の定義は何でしょうか？ITを使用しているというだけならばほぼ全ての会社が使っています。また、犯罪者はどんな道具でも使用します。どうやら、人の心を活かすために情報技術があるという事実を知らない、もしくは見ようともしていないようです。
　一例を挙げます。その少女は勉強が好きです。ですが、体が弱くて学校に通えず、望んでいる教育を受けられません。情報技術があれば、その少女に教育サービスを提供できます。しかし、マスメディアがいうような「ITは駄目だ。昔は良かった理論」を適用すれば、学校に行けないのであれば仕方が無いと切り捨てる事になります。昔は人を切り捨て、見殺しにし、できないものは仕方が無いと頭から決めつけていました。
　情報技術があれば、病弱な人にもサービスを届けられますし、障害を持った人が仕事を得るチャンスを得られます。温かいとされる人を見殺しにする昔のやり方と、技術により社会に参加できる人を増やすのとどちらが人間的に温かいのか、それは明らかだと思います。
　Windows88が発売されたからと言って、すぐさまオンデマンドビジネス（いつでもどこでも仕事ができる）が実現され、何時でも何処でもだれでもサービスが受けられる状態になるとは思っていません。レガシーな考え方を持つ人がいる限り、オンデマンドは実現しません。しかしながら、それが可能になる重要な一歩を踏み出したと言えると思います。Windows8を使ったシステムにより、より多くの人が社会参加できるようになり、より多くの人がサービスを受けられる時代になる事を願っています。

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

　この記事は、実践的オブジェクト指向設計入門14の続きです。前回は、内部クラスの設計について解説しました。今回は、責任の割り当てについて解説します。
　物事にエラーと例外はつきものです。プログラミングにおいて、エラーと例外処理は非常に重要な要素であり、品質をも決定するので、システムからみても重要だと言えます。従って、予めどのオブジェクトが責任を持つのかについて、深く考える必要があります。設計時にオブジェクトの責任について考えておかないと、エラー処理と例外処理が混雑した非常に見通しが悪いプログラムになります。それがいかに品質を下げ、開発生産性を下げるのか、システム開発の経験者ならばよく知っているでしょう。
　現実を反映した操作（アルゴリズム）である場合、その責任の所在は簡単に決定できます。しかし、システムは現実に存在しないオブジェクトを必要とします。現実に存在しないオブジェクトについてはどうするべきなのでしょうか？それについては、明確な答えはありません。ですが原則として、エラー処理専用のオブジェクトを作ると上手くいくと経験的に分かっています。ようするに、横断的に存在するエラー処理プログラムを如何に管理するのかという問題に尽きると言えるでしょう。
　そういった事実から、オブジェクト指向方法論OMTにはありませんが、属性（アスペクト）を使用する事も検討する事をお勧めします。ただし、アスペクト指向は視点により横断するプログラムが変わるという弱点があります。従って無闇にアスペクト指向を振りかざすと、視点が定まらない醜い設計になる恐れがあります。アスペクト指向を適用する場合、視点を統一して明記しましょう。そうすれば、混乱する事もないでしょう。

書籍をつつく148 - Windows Sysinternals徹底解説。プロならば読むべし！

これは文句なしの名著。Windows Sysinternalsはプロならば誰しも使った事があると思うピヨ。でも、今まで解説書もなく活かしきれないという人も多かったと思うピヨ。でも、もう安心♪これを読めばツールの使い方が分かるピヨ♪



WindowsOSをより深く知りたい人、トラブルを解決したい人、システムを管理している人、Windowsを仕事で使用する人・・・兎に角、あらゆるWindows使いにお勧めするピヨッ♪
新設かつ丁寧に書かれているから安心して読めるピヨ。


他の本のレビューも読みたいピヨな人は書籍レビュー目次をチェックしてね♪

中の人の徒然草408

今に始まった事ではありませんが、日本政府は未だに国民を裏切り続けています。消費税導入に反対し、天下り根絶をマニフェストにしていた民主党が、命を賭けて増税を推進しています。前から思っていたのですが、多くの政治家は嘘吐きですね。命を賭けるという事は、増税が達成できなかったら切腹をするのでしょうか？それともまた嘘なのでしょうか？
とにかくいえることは、マニフェストなんて意味が無い。強いては選挙なんて意味が無いという事です。社会的契約を平気で破る上に、何の罰則もないのですから（嘘をつく事が前提なようだ）、選挙は嘘でできた虚実であり、主権者である国民はまともに代表者を選べないことを意味します。
そうした嘘や茶番で、1日当たり100人以上（日本の自殺者数だけでも3万以上）の国民の命が消えていると思うと、何とも言えない気分になります。彼らは、何人死ねば気が済むのでしょうか？というよりも、国民の命が失われる現実を直視していないと思えてなりません。
政治家たちに事の重大さを知らせるために、死亡者数をカウントし突き付けるといいと思います。「あれから１０日経ちました。ということは、少なくとも千人の国民が死んだ事を意味しますが、その責任をどうお考えですか？」というふうに国民は政治家に対して言わないと駄目でしょう。何人の国民を結果的に殺しているのか、その自覚をしてもらわねば、政治と言う名の喜劇は終わりません。今のままだと日本国家が消えても治らないでしょう。
私は国民が事実を知り意見を言う事が大事だと言いました。それと同様に、政治家が命を預かっているという認識をせねばならないと考えています。少なくとも1年以上政治が進んでいません。その間に、万単位の国民の命が消えました。それを踏まえてなお今の行為を続けるのであれば、事の重大さを強調する為に強烈に表現すると「大量殺人鬼」と言えるのかもしれません。
今政治家に求めれているのは、「国民の生命と財産を守るという基本を見直し、日本を立て直すのか。」「既得権益を守るために、国民を見殺しにして、日本を滅ぼすか」の選択に他なりません。今度の選挙はそれを軸にすればいいでしょう。今までは政治家が軸を決めていましたが、それでは嘘が前提となり問題から逃げるので駄目です。主権者である国民が軸を決めましょう。本来は雇う側が要求を決めるものなのです。

初心者のためのC#プログラミング本格入門77 - 地味で目立たない努力が大量のバグを消す

　この記事は、初心者のためのC#プログラミング本格入門76の続きです。前回は、テストデータに境界値（最大値、最小値など）を使ったデバッグ技法について解説しました。今回は、小さなテストや細かいデバッグと言った地味な行為が、大きな効果を生む事を示します。
　早速ですが、再びサンプルプログラムのテストを実行してみましょう。まだ大量のエラーが表示されています。大量のエラーが表示されると初心者は慌てがちですが、心配する必要はありません。落ち着いて1行目のみ見てみましょう。そうすると、「-2147483648 + -2147483647」のテストそのものがおかしい事に気付くと思います。正しい値として表示されている値そのものがおかしいのです。テストそのものが間違っている場合も視野に入れてチェックしましょう。
　このテストプログラムはどこが間違っているのでしょうか？前回の記事の内容を思い返して下さい。そうすれば答えが分かります。答えは「使用している型がおかしい」です。前回述べたように、float型では扱える値の範囲が不十分です。という事は、テストプログラムの方もdouble型にしておかないと正しい計算結果が得られません。修正しましょう。

//計算処理をチェックする
private void CalculateTest( double value1, double value2, char sign )
{
    string inputValue = value1 + " " + sign + " " + value2;
    this.target = new MultiAnalyzer();
    this.target.AnalyzeExpression( inputValue );
    double result = target.Calculation();
    double rightValue = 0;
    //あとは省略...
}

再び実行して、1行目のエラー文を見て下さい。正しい値になっている事が分かります。テストを修正した後は、テスト対象を修正します。
　1行目のエラー文の処理結果をみると、正しい値との差が激しい事が分かります。次に値に注目するとたった1です。1という数値がどうして算出されたのか考えると、-2147483648と-2147483647の差である事に気付くと思います。という事は、加算演算をするべき場面で減算演算をしていると推測できます。推測したら検証します。

class AnalyzerTest
{
    //他のコードは省略...]
    
    public void ExecuteAllTest()
    {
        this.MinusValueCheck();
        this.MinusValueLimitCheck();
        this.MinusExpressionSignCheck();
    }
    
    //符号が正しく取得できているかチェック
    public void MinusExpressionSignCheck()
    {
        string value = int.MinValue +
                " + " + int.MinValue; 
        this.target = new Analyzer();
        this.target.AnalyzeExpression( value );
        if ( this.target.Sign != '+' )
        {
            System.Console.WriteLine(
                "符号を正しく解析できませんでした。" + 
                "（正しい符号「+」, " +
                "返された符号 " + this.target.Sign );
        }
    }
}

テストを実行すると、案の定符号が「-」になっています。このバグの原因を探りましょう。
　符号が正しく習得できていないという事は、式が正しく解析できていないことを意味します。これが分かれば、チェックするプログラムも自然と分かります。

public void AnalyzeExpression( string inputValue )
{
    //数値を取り出す
    string tmp = inputValue;
    AddValues( ref tmp );

    //符号を取り出す
    System.Tuple<bool, char, string> signInfo = GetSign( tmp );
    this.sign = signInfo.Item2;

    //処理が成功しているか否かを記録
    this.success = this.values.Count != 0 &
        signInfo.Item1 == true;
}

処理の流れをよく見ると、数値を取り出す　→　符号を取り出す　→　成功の有無　となっています。処理の流れから、GetSignメソッドに渡される値は、数値が取り出された後に処理をすると想定されている事が分かります。この考えが正しいかデバッグ機能を使って確認してみましょう。
　先ずはMinusExpressionSignCheckメソッド内のコード「this.target.AnalyzeExpression( value );」にブレークポイントを設定します。設定したらデバッグ実行します。すると、設定したコードでストップしますから、AnalyzeExpressionメソッド内のコード「System.Tuple<bool, char, string> signInfo = GetSign( tmp );」にブレークポイントを設定します。その後、F5キーを押すと、そこまで処理が進んだ後にストップします。ローカル変数ウィンドウで、tmpの値を確認して下さい。そうすれば、GetSignメソッドに渡される値に数値を含んでいる事が分かります。確認できたらもう一度F5キーを押します。
　以上のチェックで分かったのは、想定外の値がメソッドに渡されている事です。この値を正しくするには、直前の処理（AddValuesメソッド）で変数tmpの内容を変更せねばなりません。いまこぞ、新しい文法が必要です。この様に、メソッド内で渡された変数の内容を変更したい時はrefキーワードを使用します。

public void AddValues( ref string inputValues )
{
    bool loopFlag = true;
    string tmp = inputValues;
    do
    {
        System.Tuple<bool, double, string> value = 
                TryValue( tmp );
        loopFlag = value.Item1;
        if ( loopFlag == true )
        {
            this.values.Add( value.Item2 );
            tmp = value.Item3;
        }
    } while ( loopFlag == true );
    inputValues = tmp; //結果を反映
}

public void AnalyzeExpression( string inputValue )
{
    //数値を取り出す
    string tmp = inputValue;
    AddValues( ref tmp ); //呼び出し側もrefを書く

    //符号を取り出す
    System.Tuple<bool, char, string> signInfo = GetSign( tmp );
    this.sign = signInfo.Item2;

    //処理が成功しているか否かを記録
    this.success = this.values.Count != 0 & signInfo.Item1 == true;
}

変更点を緑色で示しました。refキーワードは、パラメーターにつけるだけです。あとは、パラーメタ―に結果を反映すればOKです。最後の仕上げとして、デバッグ実行（F5）をして下さい。エラー文が大量に消えた事を確認できます。やったね♪
　今回の記事で示したように、ちょっとした事でエラーは消えます。それが、デバッグとテストの醍醐味です。テストとデバッグは地味で退屈な作業だと思われがちですが、面白さと大切さが分かれば見方は変わるでしょう。プログラミングでもそうなのですが、あらゆる物事は地味で目立たない行為に支えられています。その真理を見抜き、そこに喜びを見出すことこそ、プログラミング上達への道です。

ネタつつき131 - 無知こそ幸せ。技術者に必要なものは尽きない知識欲。

　IT業界は、秒進日歩と呼ばれるほど変化が激しい業界だと言われています。実際、1年ひと昔ぐらいに感じるスピードの中、技術者は生きており、この状態を苦痛だという技術者も多いようです。しかしながら、私自身は苦痛だと感じた事がありません。何故ならば、私は知識欲を原動力にして生きているからです。得るべき知識が無いような退屈な世界を生きたくありません。変化が無い世界ほど退屈で死にたくなるものはありません。
　何故人は生きるのでしょうか？その理由は人それぞれですが、私の場合「そこに知識があるから」です。この世に知識と言う名の宝物がごろごろあるから楽しく生きてゆけます。私にとっては、知りたいものがない薄っぺらい世界を生きて何が楽しいのか分かりません。知識と言う名の刺激があるから生きています。
　そんな私にとって、進化が早いから嫌だとか、進化が早いのは問題だなどという意見は同意できません。何事にも反面があるから、変化が嫌いな人がいる事は理論的に理解できます。ですが、そんな人が技術者をやっている理由が分かりません。知識欲が無い技術者は、なぜ知識を扱う職業に就いているのでしょうか？
　例えば、運動するのが嫌いな人がスポーツ選手になったとします。彼は練習が嫌いです。試合も嫌いです。何故ならば、運動そのものが嫌いだからです。・・・おかしいと思いませんか？技術者にとって頭を使うのは必須条件です。スポーツ選手が運動するのと同じです。ならば、技術者以外の職業に就けばよいのではないでしょうか？頭を使うのが好きだから技術者になったのではないでしょうか？
　私とて人の子ですから疲労は感じます。ですが、その疲労は不快ではありません。むしろ快感と言ってもよいぐらいです。その快感を求めて、情報技術だけでは飽き足らず、他の学問にも手を出している状態です。この世の何よりも情報技術が一番好きなのは変わりませんが、情報技術にはある一定のパターンがあります。それを言葉にする事はできませんが、そのパターンさえ押さえれば、新技術でも対応できてしまいます。全く使った事が無い技術であっても、仕事を依頼されれば自由自在に使いこなせる状態にまでもっていけます。IT業界は進化が早いなどと言われていますが、実はそんな事はなく、ただ変化が早いだけです。進化ではなく変化なのですから差分を習得すればいいだけです。もっと違う思考パターンや思考リズムが欲しいです。
　むろん私は情報技術の全てが分かるわけではありません。ただ、あとは情報量だけの問題だけだと感じるレベルには達しています。本質を押えればあとは暗記と調査を繰り返すだけです。といっても、情報技術の全てを修めているわけではありません。私も分からない領域があります。情報技術やいくつかの領域に分かれており、その領域を探るには他の分野の学問の知識がいるのです。
　情報技術は実に奥が深いです。全ての学問を合わせたほど範囲が広いです。それもそのはず、「情報」技術なのですからその集合は無限です。人間は脳で情報処理しています。ならば、全ての知識が情報であり、情報技術の集合は人間の知識そのものだと言えます。といっても、全ての学問が奥深いです。自然数で数直線をみると穴だらけですが、整数、有理数、実数、複素数と視点そのものを変えれば、より深いものが見えてきます。つまり、人間の視点により、全てのものは無限なのです。無限の前には、進化が早いなんて言葉は意味をなしません。
　何を言いたいのかと言いますと、全ては自分の心掛け次第だという事です。何かを速く感じるのも人の心。何かを遅く感じるのも人の心。世界の真理はただそこにあり、人間がそれを見るかどうかなのです。ならば、新しい知識を拒む理由なんて何もありません。無限に広がる世界の真理の前には人は等しく無知です。無知を恐れて変化を否定する人がいますが、もともと人は無知なのですから恐れることなど何もありません。「無知を楽しみ知識を欲する」その心さえあれば、その人は技術者であり続け、人生が豊かになります。
　さあ、今日も無知を楽しもう♪

最近のアジャイル事情

　アジャイルと言えばイテレーションです。昔は、1イテレーションを何週間にするのかが話題になっていました。しかしながら、今アジャイルで「何週間」なんていったら「アジャイルじゃねえ」と笑われます。というのも、単位が週ではなく、日になっているからです。
　10年以上仕事している人ならば分かると思うのですが、開発に馴れてくると大概のものは1週間で出来てしまいます。下手なユーザーストーリーを設定すれば別ですが、新人よりも分析能力が高いので、そもそも1週間以上かかるようなユーザーストーリーなんてほとんど設定しません。10年以上のキャリアを持つ人が、1週間以上もかかるストーリーなんて粒度が粗すぎます。
　アジャイルの本質は変化なので、お客様に提示するまでの時間を極力短くし、ユーザーからのフィードバックを頻繁に得ようとします。それ故に速さを求め続け、お客様の要求を引き出した時点で、分析／設計／実装／運用の想定が殆ど終わっている状態になりますから、大概の事は「来週お持ちします」で終わりです。後はフィードバックを繰り返すだけです。
　殆どの事が1週間以内に終わるので、自然とお客様から「もっと細かく報告してくれ」と言われるようになります。細かくと言ってもマイクロマネージメントの話しをしているのではありません。ユーザーストーリーはある程度の長さを持ちますから、それを細かくしたサブストーリーの進行状況をお客様は聞きたいわけです。
　その理由をお客様に聞いたところ、「仕事が速すぎるのでこちらの要求が間違っていないか心配になる」だそうです。何週間もかかっている遅き時代では、仕様を変更したい時に直ぐに声を掛けられます。しかしながら、今の様に日単位のアジャイルでは、1週間後には完成しているのでストップが出来ないのです。これは仕様の確認作業が原因で起こる事象です。
　システムを発注する側のお客様はその道のプロですが、情報技術については素人です。ですから、何を要求したいのか分からない状態です。従って、実際に試してみてようやく判断しています。アジャイル化により速さが増すと、お客様の確認作業が間に合いません。そこで、今何を発注しているのか詳細に把握したくなるわけです。
　ただし、お客様に報告する情報は簡潔でなくてはなりません。ただでさえ、ついていけない速さになりつつあるので、情報の洪水に溺れてしまわないように、情報量を制御せねばなりません。お客様が知りたい抽象度、かつ知りたいであろう情報を察して報告するセンスが求められます。
　例えば、システムの仕様について憂慮するべき点が見つかる場合もあります。その場合、お客様は極力早期に検討するために、一刻も早くその情報を知りたいと願います。大概の場合、ユーザーストーリーを練る段階で分かりますが、ユーザーストーリーの整合性を図るために、複数のユーザーストーリーを予め作る作業があります。その段階で判明した仕様の不備、もしくは検討課題が発生する場合もあります。また、所詮人間がする事ですから、やってみて初めて気付く事もあります。そうした例外情報こそお客様は知りたいのです。その他にも「業務そのものが変更された」なんて場合もあります。世の中は「人間にとっては想定外」で出来ているのです。神様でなければ100％の未来予知はできません。ですから、想定外が起こる事を想定しておくのは当然なのです。
　こうした出来事から私は、今や開発は速くて当たり前であり、システムを受け入れる側のお客様に対して如何にきめ細かいサービスをするのかが求められているのだと考えました。システム開発もサービスの一種です。我々開発者は、お客様がより快適に感じるサービスの提供を、目指さなくてはならないのではないでしょうか？

中の人の徒然草407

ああ、それにしても気持ちが悪い。システム屋にとってバグの中で生活しているというのはストレスがたまりますね。 日本の国家システム＆社会システムがバグだらけなので、バグを憎むシステム屋としては最悪な気分です。
そもそも、民主主義の原則は多数決と言っておきながら、それを否定するシステムになっているのがおかしいです。何故かと言いますと、政党制の議院内閣制という事は、国民の人数から比べたら非常に少ない人数の人をハッキングしたら、どれほど少数派の意見でも通るからです。おまけに、報酬と行為が連動しないわけですから、嘘をついて当選して何をしてもOKです。すなわち、国民にとって不利益となる事をしやすい状態になっているのです。
現実に一部の業者にとって都合がよい法律ばかりが立法されています。天下り法人も作り放題です。資本主義国家を名乗りながらやっている事は社会主義です。外国にもクラックされ放題です。セキュリティが実質ありません。
これほど酷いシステムを目にした事はありません。何の仕様も実現していません。国会システムの基本は、国民の生命と財産を守る事なのですが、逆の行為をしているという気がしてなりません。基本的な仕様すら守っていないのです。これほど馬鹿げたシステムはありえません。
もう根本的な部分から間違っています。私が何度もWindows95未満だと言っているのは、再起動できない上にあらゆる情報が隠蔽されているからです。それこそ、MS-DOSなみの情報しか出していません。一部の国民の為の国家システムになっているのは明白です。さらに、国土を壊しているわけですから、今のシステムはリソースすら破壊していると言えます。サービスの対象である国民の要求を守らず、リソースすら破壊するこんなシステムが世の中に存在しているのでしょうか？物事の全てを情報として認識するシステム屋の私は眩暈がします。
それを考えると、真面目な国会議員や官僚たちは凄いストレス中働いているのだと思います。システムと呼ぶのがおこがましいバグの中で真面目に仕事をするといのは大変でしょう。それを考えると、馬鹿げたシステムをぶっ壊すと明言し実行した小泉元首相はものすごい実力者だと思います。英雄だと言っても過言ではないでしょう。それでも潰されましたが・・・
やはり問題の根源は、多くの国民がバグの名で暮らしている事を認識していない点にあると思います。世界ではWindows Updateの様に次から次へと修正するのが当たり前だし、処理スピードのUPとコスト削減が当たり前です。それにも関わらず、今の国家システムは処理スピードを落とし、システムのコストを増大させ続けています。つまり、最悪な方向に進んでいるのです。少しはマイクロソフト社を見習ってほしいです。悪い方向へ処理が進んでいるのですから、日本が滅ぶのは誰の目から見ても明白です。とはいえ、この状態を放置しているのですから、多くの国民がその事実を認識していないようです。
この状態を打開するには、中で戦っている人と外部の専門家が協力し、国民に対して詳細に情報を公開するしかないと思います。サービスの対象者である国民が、何をされても認識していないのですから、何をされているのか知らしめることから始めないと話しは前に進みません。逆に言えば、国民が何をされているのか理解さえすれば、一からシステムを作るのも簡単です。一刻も早く自分たちがバグの中で暮らしている事を認識してほしいです。
どうやら、日本人はシステムを考える事が苦手な様です。真面目でお人よしだから、誰かにとって都合がよいルールやシステムを押し付けられても疑問を感じず、不合理なルールやシステムを変えるという発想が湧かない。きっと、だからブラック会社が蔓延るのでしょう。悪い人にとってこれほど美味しい獲物はないでしょう。
私も日本人ですから、そういった性格を誇りに思っているのですが、悪い事をしようとたくらむ人からしてみれば格好の獲物です。よい国民性だから、システムとは呼べない酷いレベルの国家システムでも素直に従い、不利益をこうむり続けても無言で死んでいく（なんと年間3万人以上！）悪党は努力して攻撃するけど、人を疑わない善人は防御をすることさえ知らない。うーん、なんだかな・・・

初心者のためのC#プログラミング本格入門76 - 境界値のチェック

　この記事は、初心者のためのC#プログラミング本格入門75の続きです。前回は、新しいデバッグ機能と新しい文法である短絡評価を解説しました。今回は、テストデータに境界値（最大値、最小値など）を使ったデバッグ技法について解説します。
　以前、最大値・最小値・平均値・などの特徴ある値を、テストデータに含めるべきだと解説しました。今回はその値を使います。先ずはデバッグ実行してみて下さい。そうすると、-2147483648 + -2147483647 が正しく計算されていない事が分かります。
　ここで考えられる原因は、最小値が解析できていない事です。プログラミングによくあるバグは、最大値や最小値と言った境界値を適切に処理できていないというものです。従って、-2147483648を正しく解析できていないと推理できます。
　バグの原因を推理したら直ぐに検証するためにテストを作り実行します。

class AnalyzerTest
{
    //関係のないコードは省略・・・
    
    //テストを忘れずに追加
    public void ExecuteAllTest()
    {
        this.MinusValueCheck();
        this.MinusValueLimitCheck();
    }

    //マイナス値が正しく解析できているかチェック
    public void MinusValueLimitCheck()
    {
        string value = int.MinValue.ToString();
        this.target = new Analyzer();
        this.target.AnalyzeExpression( value );
        if ( this.target.Values[ 0 ].ToString() 
            != int.MinValue.ToString() )
        {
            System.Console.WriteLine(
                int.MinValue + "を解析できませんでした。" );
        }
    }
}

テストを実行すると、案の定エラーメッセージが表示されます。という事はやはり、マイナス値を解析できていないという事になります。
　さて、マイナス値を解析できない理由は何でしょうか？文字列が解析できていない？それはないでしょう。この様な場合、真っ先に疑うのは使用している型です。以前解説したように、数値を表すオブジェクトにも色々あります。また、それらのオブジェクトは、保持できる値の範囲に限界があります。数学で扱う数は無限であり、範囲があるというのはちょっと腑に落ちないと思いますが、コンピューターは2進数で動いているので、どうしても扱える数値に範囲が出来てしまうのです。従って、int型の最小値を表現するには、より範囲が広い数値オブジェクトを使うしかありません。※一応他にも手段はあるものの、初心者にもできる簡単な方法を書いています。
　今使用している数値オブジェクトはfloat型です。これよりも範囲が広い数値オブジェクトはdouble型です。という事は、計算と値の格納に関わる全てのfloat型をdouble型に変更しなくてはなりません。これを一々目視で行えば大変なので、開発ソフトの機能「検索と置換」を使用します。メニューの「編集」→「検索と置換」をクリックしてみましょう。
　検索と置換ダイアログボックスは、検索する文字列と、置換後の文字列（変えた後の文字列）を入力できます。このダイアログボックスで、検索文字列として「float」、置換後の文字列として「double」を入力して下さい。さらに、検索対象を「現在のプロジェクト」に変更して下さい。これで準備はOKです。あとは、置換をクリックしていくだけです。置換はAltキーとRキーを同時押しするとやりやすいです。コードをよく確認しながら、「検索の開始位置に達しました」と表示されるまで続けて下さい。表示されたらダイアログボックスを閉じて下さい。
　デバッグ実行をして下さい。これで最小値に関するエラーが表示されなくなりました。なお、テストにて、文字列で値を比較している理由は、値が丸められて「-2147483648」を比較できないからです。両方の-2147483648が切り上げられて、共に-214748365になってしまい意図された結果ではなくなってしまいます。より正確に言うと、-2147483647も-214748365へと四捨五入されるので厳密な比較が出来ません。正確な知識があれば文字列で比較しなくてもよいのですが、それを簡潔に解説するために文字列にしています。
　プログラミングでは、数値の切り上げや切り捨てを含めて数値を丸めるだとか端数処理と表現します。端数処理によるエラーは意外と多いので、この様なテストが必要です。

中の人の徒然草406

それにしても、日本の立法システムはコストパフォーマンスが低すぎます。国会議員の報酬が高すぎるし、国会の運営費も1日1億5千万円と高すぎます。それだけの価値があるとはとてもじゃないけど思えません。おまけに、国会議員の人数に論理的根拠がありません。これほど酷いシステムを見た事がありません。この様な酷いシステムを提案するシステム屋はいないでしょう。
私が思うに、コストを減らすために国会議員の報酬を出来高制にした方がいいと思います。すなわち、価値ある立法をしないかぎり報酬が支払われないようにすれば、今よりもコストパフォーマンスを高くできます。ただし、それだけでは駄目です。
日本は政党政治による多数決で立法しています。ということは、能力が低い人に合わせなければ生産できない事を意味しますし、政党の利害で決まるという事は今現実に起こっているように、国民の利益が第一に考慮されないことを意味しています。おまけに、無意味に人数が多いから、多数決で決定する為に多大な金銭コストと時間的コストが発生する事になります。実に生産性が低いシステムです。
政党で分けるのはこれ以上ないぐらい最悪の分け方です。それならば、出来高制にして、立法した法律の数と質で報酬を定めるとし、各分野の専門家を雇った方が立法システムの生産性が上がります。すなわち、職能人が一つの目的の下に集団を組んだ方が生産力が高まるという訳です。現状は政党政治なので、党利の為に反対するだけの人や、人数合わせの国会議員が存在しており、無駄な事にコストがかかり過ぎていると言えます。システム屋の目から見れば、全てが無駄で出来ていると言っても過言ではありません。
私が思うに日本の不景気の根本的理由は、国会システムのコストパフォーマンスが悪い点にあると思います。今の世の中は秒進日歩の時代です。私は1イテレーション（仕事の単位）が1日～1週間でシステムを作っています。それぐらいしないと今の世の中生きられません。
それにも関わらず、日本の国家システムは一つの事をするのに何十年もかかります。おまけに解決する能力もありません。この状態でビジネスをするのは難しく、明らかに日本の国家システムがボトルネックとなっています。具体例をあげると、災害復興や年金です。未だに原発に関する事も災害の事も何一つ解決できていません。年金システムに至っては既に破綻しているのにも関わらず、高いコストをかけて無理やり存続している始末です。こんなひどい状態で存続する企業は存在しません。
国会議員にも優れて人がいるでしょうが、このコストパフォーマンスが低システムでは実力を発揮できないでしょう。何も決断できない政治だと言われていますが、元々何もできないコストパフォーマンスが低いシステムなのですからいまさら何を言っているのだとあきれるばかりです。今まで日本が存続していたのは、優秀な民間人がボトルネック以上の働きをしたからでしょう。ボトルネックが無ければ、世界一の経済国家に馴れたでしょうから非常に残念でなりません。
ボトルネックを解消しないと日本に未来はありません。適切な利益コントロールにより、コストパフォーマンスがよい国家システムになる事を願っています。