中の人の徒然草405

それにしても、システム屋の性分で、自分が住んでいるシステムの不備が気になります。
立法府の処理性能が悪いのは、明らかに報酬と選挙システムにバグがあるからです。民間では通常、仕事の成果を考慮して給与が定められます。ですが政治家の場合、選挙に当選しただけで報酬がほぼ確定します。
この様なシステムである場合、怠けて国民の利益に貢献しなくてもよいわけですから、平気で決められない国会をする事になります。なにせ、成果を上げなくても報酬が頂けるのですから、「働いたら損をする」わけです。となれば、自然と国民の利益を考えなくなります。
民間で成果を加味する理由はまさにここにあります。お客様に利益をもたらさないと、報酬が得られないから一生懸命に働くし、お客様に尽くした人はある程度報われます。
ですが、現状では国会議員は当選と所属政党だけで報酬が決まります。だから何時まで経っても政党間の争いだけに終始し、国民の事を第一に考えない状態が続くのです。システムは人の心を変えます。というか、システムの性質がそういった人を招きます。
この件でよく言われる事は「政治家の仕事は評価できない」だとか「評価できるほど分からない」です。ですが冷静に考えて下さい。民間でお客様が理解できないサービスを提供しても売れません。つまり、サービスの対象となる人が分かるようアピールするのが当然なのです。分からない人が悪いという論法は民間では通用しません。
ただし、政治家だけを責めても仕方がありません。仕事を曖昧にしている我々国民にも問題があります。どの様なサービスを求めているのかを定義し、その様な報酬を定めないと政治家も何をしていいのか分かりません。実のところ、決断できないと称されている政治家達は、何をしていいのか分からないのかもしれません。もしくは、国民が求めている事と乖離しているのかもしれません。
私は政治家が可哀そうな職業だと思っています。何をしていいのか分からず、どれだけ働いても報酬は同じなのですから、この状態で国民に奉仕する事を求めるのも酷です。さらに言えば、この複雑な社会の全ての問題に精通した人は存在しないでしょう。従って、政治家の仕事の範囲を減らし、求められる能力を可視化する必要があります。
古くから改正されず、国民の足かせになっている法律が沢山あります。それらレガシーなシステムを改良し続けるには、政治家がするべき問題と、国民達が自分の手で改正する必要がある法律を分ければいいのではないかと思います。全ての法律に関する立法権を一部の人に与えるのは危険な上に非効率的です。
例えば、国会議員に関する法律は国民がするべきです。彼らが自分で不利になるような法律を立法する筈がありません。自分に甘くなるのは人間の性質ですから、報酬・権限・責任を定めた法を国民が制定するべきです。そうしたセキュリティがないから今の国家システムが破たんしているのです。
国家を一つのシステムとして捉えなおし、法律の生産性を真面目に考えるべきだと私は思います。国家システム自体がレガシーとなって不況や問題を生んでいます。日本が沈む前に、この古すぎるシステムを変えなくてはなりません。そうすれば多くの悲劇が避けられます。
ところで、国会の動きが遅いですが、彼らは国民の命が脅かされている事を認識しているのでしょうか？最近は特に仕事が遅いですが、その時間で死んだり苦しんだりする国民がいます。また、日本政府は随分な浪費家ですが、そのお金で救える命がどれだけいるか考えた事があるのでしょうか？
私はどうも彼らが命の重さを意識していると思えません。意識していれば、復興に1年以上もかかるなんて事ありえないでしょうし、自殺者数が3万人を超えている現状をもっと重く受け止めていると思います。彼らは人の命がかかっている事をもっと意識して欲しいです。一国民として切に願います。

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

　この記事は、実践的オブジェクト指向設計入門13の続きです。前回は、アルゴリズムの設計におけるデータ構造の選択について解説しました。今回は、アルゴリズム設計における内部クラスの選択について解説します。
　前回少し触れましたが、補助オブジェクト（ヘルパークラス）を使用する場合もあり得ます。オブジェクト指向設計の基本は、ある一定の抽象度を保つ事です。しかしながら、操作が余りにも複雑になる場合、内部クラスを設計し、操作の複雑さを軽減する必要があります。
　一般的にヘルパークラスと呼ばれる内部クラスは、クラスの内部で定義するクラスを指します。ここに重要な要素が含まれています。オブジェクト指向の原則は、情報の隠蔽です。従って、オブジェクトを使用する者にとって不必要な複雑さを閉じ込めるために、内部クラスとして定義して隠蔽するのです。
　内部楽巣を考える時によくある間違いは、実装面まで踏み込んでしまう事です。今まで何度も指摘してきましたが、設計と実装を混同してはなりません。設計のオブジェクトと実装のオブジェクトは、扱う抽象度が違うのです。全くの別物だと言ってもいいぐらいです。しつこいようですが、重要なので決して忘れないでください。

ネタつつき130 - 日本の問題をネタにしたブラックジョーク

現状の日本は冗談としては笑えます。

「失敗した時の態度」
政治家「選んだ貴方が悪い」
国民「そうかな？・・・」

社員「採用した貴方が悪い」
会社「それは失礼しました。明日から来ないでもいいですよ。」

「報酬」
政治家「我々は選挙に当選したのだから年間1億ぐらいもらってもいいだろ。」
国民「・・・」

社員「採用されたんだから、仕事の成果に関係なく年収1億円ぐらいくれ。」
会社「貴方の働きでは報酬を支払えません。明日から来なくて結構です。」

「約束」
政治家「選挙時の間に言ったマニフェストなんて信じていたの？」
国民「また騙されたか・・・」

社員「面接時に言った事なんて守れなくても当然じゃないですか。」
会社「嘘をつく人は当社に必要ありません。」

「年金システムの破綻」
官僚「想定外です。」
国民「・・・また誰も責任をとらないのか・・・」

社員「想定外です。」
会社「ならば能力が無いという事ですね？余りに酷いので訴訟も検討します。
　責任を取ってもらいます。」

「年金システムの破綻2」
官僚「システム障害を直すには数千億円かかります。税金を上げましょう。」
国民「拒否できないのか・・・」

会社「システム障害を直すには数千億円かかります。価格を上げましょう。」
お客「もうこの会社のものは買わないから結構。
　それよりも、個人情報流出と預けたお金の損失について告訴する。」

「税金」
政治家「とにかく必要だから税金を上げます。」
国民「抵抗できないのか・・・」

会社「とにかくお金が欲しいから価格を上げます。」
お客「分かった。もうこの会社から物を買わないだけだ。」

「税金2」
政治家「とにかく必要だから消費税を20％ぐらいにします。」
国民「足りないのだったら仕方が無いかな・・・」

社員「とにかく予算が必要だから計上して下さい。」
社長「なぜその金額が必要なのか理由を詳細に述べよ。
　あと、利益はどれぐらい見込めるのかも述べよ。」

「天下り」
官僚「受験勉強頑張ったから死ぬまで快適に暮らすよ。」
国民「・・・」

社員「受験勉強頑張ったから老後も年収1千万円ほどください。」
会社「受験勉強頑張るのは当たり前です。報酬は仕事の成果から判断します。
　あなた以外にも働きたい人は沢山います。」

あくまでもジョークなので誤解しないでください。
ただ、日本には根本的な問題が多いのも確かですね。
余りに酷いので憂鬱になります。

中の人の徒然草404

暑くなったり寒くなったりと忙しい気候で参っているインドリです。ここ最近感じた事を書きます。
ニュースを見て何時も思うのですが、日本って国家システムの事を全く考えていないですよね・・・
問題が発覚したお祭り騒ぎして終わり。そして何度も同じ問題を発生させます。システム屋ならばバグだと見做して徹底的に見直します。
例えば、未だに日本の国家システムは根本から間違っています。システムの仕様にバグがあります。
ちょっと考えれば思いつくバグを列挙すると・・・

• 権限と責任が考えられていない
• コストと利益のバランスが考えられていない
• 変化に対応できない
• 国民の事を第一に考えていない
• 悪い人ほど得をするシステムになっている
• 問題をしっかりと考えてシステムを改良できない
• 生産性が全くない

行政は天下りを第一に考えて動き、立法府は当選を第一に考えて動いています。それもそのはず、天下りをしたら儲かるシステムと、選挙に受かった時点で報酬が保障される貴族階級システムとなっているからです。そうなれば、真面目に働く人ほど馬鹿を見るのは非を見るよりも明らかです。ですから、善良な官僚と政治家は生きていけない様になっています。
これらの要因を一言で言うと、「国民の利益を第一に考えてシステムを作っていない」と言えます。官僚が天下りをして市場を破壊して得する国民は一部です。選挙に受かるだけで得する国民もまた一部です。おまけに、責任という概念がないから何をしてもまかり通ります。
こうした事を指摘すると決まって「善い人もいるから」と返ってきます。しかしながら、悪い人が得をするシステムを放置しておいて「良い人もいる」というのは無責任極まりないと思えてなりません。何故ならば、そのよい人が損をする状態を放置しているのですから、「善い人が世の中を変えてくれる」という甘えた考えは、そのよい人に危害を加える結果しか生まないからです。
この馬鹿げた国家システムを考えれば、現状の様に税金だけ上がり、国民の生命と財産が脅かされる状態が続くのは当然の結果だと言えます。悪人に利益を与え、善人に不利益を与えているのですから、なんとなく信じている「善良な人」の数が減り、悪人が住みよいシステムになるのは当たり前です。
要するに日本の一番の問題は、「主権者である国民が真面目に考えていない」点にあります。悪人は一生懸命に自分の利益を考えます。しかし、我々日本人はお人よしで性善説で動いていますから、善人が苦しんでいても考えようともしません。
これが本当の良心と言えるのか甚だ疑問です。絶滅危惧種の善良な政治家や官僚が戦っているさなか、見殺しにして「いつかよくなるさ。誰かが何とかしてくれる。」と考えている現状は、怠惰であり優しさではないのではないでしょうか？いい年した大人達が何も考えずに、不備だらけのシステムを放置し、考えるのではなく願っているのはおかしいです。
ニュースは社会システムの不備を知らしめるものです。自分が使用するシステムぐらい自分で考えるという当たり前の事から始めるべきです。主権者は国民です。主権者が何も考えなければ、一部の人が自分にとって都合のよいシステムを勝手に作ります。それが今の日本の姿です。
主権者である我々が考える事から全ては始ります。そうすれば、Windows95未満の日本の国家システムをヴァージョンアップできるでしょう。私が思うに民主主義というシステムは、主権者である国民が考えないと、バグの増殖とクラック（破壊行為）でまともに動かないのではないでしょうか？

初心者のためのC#プログラミング本格入門75 - バグ退治と賢い条件判断

　この記事は、初心者のためのC#プログラミング本格入門74の続きです。前回は、人間が行うデバッグの手法を解説しました。今回は、前回のバグを修正する方法と新しい文法について解説します。
　前回で明らかになったバグは、「マイナス値を解析できない」です。このバグを修正するには、場所を特定せねばなりません。特定する方法はいくつもありますが、初心者の方がやりやすい手法は、呼び出しメソッドをたどっていく方法です。実際にやってみましょう。
　最初のメソッドは、AnalyzeExpressionですね。これはOKだと思います。このメソッドのコードを読むと、数値を取り出すのはAddValuesメソッドだという事が分かります。さらにAddValuesメソッドのコードを読むと、TryValueメソッドで一つの値を決定している事が分かります。つまり、AnalyzeExpression　→　AddValues　→　TryValueの順番でバグを探したわけです。コメントを書いているので、容易にたどれたと思います。この例からもわかると思いますがコメントがあると便利です。
　さて、ここからが本題です。バグの場所に検討をつけたので、核心に迫りましょう。TryValueメソッドは、数字の初めと終わりを記録してから、文字列から数値を取り出しています。この処理方式をよく考えると、「-10」の様なマイナス値の符号を、数値を表す文字列の先頭だと見做していない事が分かります。何故ならば、前回のテストMinusValueCheckにて、0以上の値が返されているからです。目で確認したい人は、テストコードの「if ( this.target.Values[ 0 ] >= 0 )」部分にブレークポイントを設定して、止まったら画面下にあるローカルウィンドウを見てみましょう。
　ローカルウィンドウで確かめる方法は、「this」の横に表示されている＋をクリックして、ツリーを展開していきます。この場合、this → target → Values とツリーを展開していくと値が10になっている事を確認できます。ローカルウィンドウは便利なので、使い方を練習しておきましょう。
　バグの原因とおよその場所が分かったら後は簡単です。マイナス符号がついていたら数値の一部と看做す事にしましょう。早速、自分でプログラミングしてみて下さい。これから模範解答を示します。

static System.Tuple TryValue( string inputValue )
{
    //各種変数を準備
    int startIndex = 0;
    int endIndex = inputValue.Length;
    bool startFlag = false;

    //数字の初めと終わりを記録
    for ( int i = 0; i < inputValue.Length; i++ )
    {
        if ( System.Char.IsDigit( inputValue[ i ] ) == true )
        {
            //初めて数字が出たら位置を記録
            if ( startFlag == false )
            {
                //マイナス値かどうか確認
                if ( i != 0 & inputValue[ i - 1 ] == '-' )
                {
                    startIndex = i - 1;
                }
                else
                {
                    startIndex = i;
                }
                startFlag = true;
            }
        }
        else if ( startFlag == true )
        {
            //数字が途切れたら位置を記録してループ終了
            endIndex = i;
            break;
        }
    }
    
    //他は同じなので省略

では、ブレークポイントの設定を解除してから、デバッグ実行してみて下さい。エラーが表示されます。
　表示されたエラー文をよく読んで下さい。「if ( i != 0 & inputValue[ i - 1 ] == '-' )」の場所でインデックスが云々と表示されます。これは、インデックスである変数iが0の時に1減算してから、配列にアクセスしたのが原因で発生するエラーです。普通の人は「あれおかしいな。変数iが0でない事を確認しているぞ。」と考えるでしょう。でも、if文内のAND論理演算に落とし穴があります。それは、両方の条件を判定してしまう点です。両方を判定しまうとなると、配列の-1の場所にアクセスしてしまいます。これは非常に問題ですね。
　この問題を解決するには、察しがいい人はif分を入れ子（if文の中で再びif分を記述）気付くでしょう。こんな具合です。

//マイナス値かどうか確認
if ( i != 0 )
{
    if ( inputValue[ i - 1 ] == '-' )
    {
        startIndex = i - 1;
    }
    else
    {
        startIndex = i;
    }
}
else
{
    startIndex = i;
}

でもこれ、読み難いですよね。もっと簡潔なコードを書きたいのが人情というものでしょう。こんな場合にC#には、短絡評価という文法があります。それを使うと・・・

//マイナス値かどうか確認
if ( i != 0 && inputValue[ i - 1 ] == '-' )
{
    startIndex = i - 1;
}
else
{
    startIndex = i;
}

「&&」と二回アンパサンド記号を記述しています。たったそれだけでOKです。なんてエコなんでしょうか。簡潔なコードは善です。短絡評価を積極的に使いましょう。
　C#の文法は多くて覚えられないとか、あんなに文法があったら難しいと思っている初心者の方が多いと思います。でも、短絡評価の例をみると分かりますが、C#の文法は冗長な記述を簡潔にするためにあります。ひとまず少数の文法を学んで、コードが冗長で面倒に感じたら新しい文法を覚えたらいいのです。

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

　この記事は、実践的オブジェクト指向設計入門12の続きです。前回は、アルゴリズムの設計について解説しました。今回も引き続き、アルゴリズムの設計について解説します。
　オブジェクト指向方法論OMTで、次に挙げられている要素がデータ構造の選択です。アルゴリズムの選択にて、処理のプロセスについて検討しましたが、処理を実装するにはデータ構造も考えなくてはなりません。そこで、システムを実現する上で最適なデータ構造について考えます。
　オブジェクト指向で言う所のデータ構造とは、いわゆる入れ物オブジェクトです。配列、リスト、木、列、辞書・・・など色々な入れ物オブジェクトが存在します。ただし、それらの有名な入れ物オブジェクトだけではなく、実装したい操作に適した補助的なオブジェクトもあります。従って、狭い視野で物事を考えては駄目です。
　非オブジェクト指向言語の発想で物事を考えるのではなく、オブジェクト指向で物事を考えましょう。ただし、実装にまで踏み込まないように注意して下さい。データ構造を考えようとすると、実装を考えがちですが、設計の本来の目的は実装手段を一意に決定する事ではなく、実装方法の選択肢を示す事です。その基本をよく肝に銘じ、選択肢を狭める愚を犯さないように注意して下さい。

初心者のためのC#プログラミング本格入門74 - バグをよく観察しよう

　この記事は、初心者のためのC#プログラミング本格入門73の続きです。前回は、開発ソフトにあるデバッグ機能について解説しました。今回は、人間が行うデバッグの手法を解説します。
　前回デバッグ機能を使用し、でサンプルプログラムの間違いを発見しました。次に行う事は、バグの観察です。いくら開発ソフトのデバッグ機能が優れていても、最終的には人間がバグ（間違い）を適切に訂正しなくてはなりません。早速、バグを観察してみましょう。
　デバッグ実行（F5）をして下さい。自分で考えたエラー文が表示される筈です。そのエラー文をよく見て下さい。マイナス値の演算が間違っている事が分かります。特に2つめのエラー文を見て下さい。正しい値がマイナス値なのにもかかわらず、処理結果は正の数です。この点を考慮すると、マイナス値を正しく認識していないという推理ができます。
　新しいテストを追加して検証してみましょう。

class AnalyzerTest
{
    private Analyzer target;
    public AnalyzerTest()
    {
        this.target = new Analyzer();
    }
    public void ExecuteAllTest()
    {
        this.MinusValueCheck();
    }

    //マイナス値が正しく解析できているのかチェック
    public void MinusValueCheck()
    {
        string value = "-10";
        this.target.AnalyzeExpression( value );
        if ( this.target.Values[ 0 ] >= 0 )
        {
            System.Console.WriteLine(
                "マイナス値を解析できませんでした。" );
        }
    }
}

class TestProgram
{
    static void Main()
    {
        //MultiAnalyzerオブジェクトをテストする
        MultiAnalyzerTest multiTests = new MultiAnalyzerTest();
        multiTests.ExecuteAllTest();
        System.Console.WriteLine( 
            System.Environment.NewLine );

        //Analyzerオブジェクトをテストする
        AnalyzerTest test = new AnalyzerTest();
        test.ExecuteAllTest();

        //デバッグ実行しやすいようにする
        System.Console.WriteLine();
        System.Console.WriteLine(
            "Enterキーを押すと終了します。");
        System.Console.ReadLine();
    }
}

オブジェクトコンポジションをしているので、実際に解析処理をしているAnalyzerオブジェクトを対象にしてテストをしています。このテストをデバッグ実行して下さい。エラーが表示されるので、マイナス値を正しく認識していない（マイナス値の解析が出来ない）事が判明しました。
　なお、System.Environment.NewLineという値は「改行を表す文字」です。今は難しく考えずに、この値を指定すれば改行できると考えて下さい。
　以上の様にデバッグをします。次回、このバグを退治する方法を解説します。お楽しみに。

ネタつつき129 - 技術者がしがちなコミュニケーションミス2

　以前技術者がしがちなコミュニケーションミスを書きましたが、まだ書き足らないので今回も書く事にしました。その仕事内容ゆえに、技術者はどうしてもコミュニケーションで失敗しがちです。ですが、どの様な職業であれ、コミュニケーションは必要です。従って、ありがちなコミュニケーションミスをよく知り、対策を練る必要があります。
　技術者は、自分の専門領域でのコミュニケーションミスを犯しがちです。その件に関しては前回書きました。ですが、それ以外にも落とし穴があります。それは、技術者の習性によるものです。技術者は知識欲が旺盛で、あらゆることに凝ります。特に仕事に関する事柄となると、非常に高い吸収力を誇ります。それが要因で失敗する事もあります。実例を挙げてそのことについて書きます。
　私はシステム屋ですので、業務に関する知識も必要だと考え、日頃から調べております。ですから、業務知識についてある程度詳しいです。それが原因で少し失敗した事があります。私はお客様をその道のプロだと考え、敬意をもって接します。ですから、業務知識については当然知っているものだと思い、うかつにも相手が知らない事に気付かずに失敗してしまいました。
　随分前の話しなので細かい事は覚えていませんが、確か原価計算の事だったと思います。業務システムを作る上で、原価計算および管理会計に関する事柄は重要です。それで、担当者の人に詳しい事を聞こうとして、原価計算および管理会計の実施について込み入った事を質問してしまいました。それが失敗でした。担当者の方はそういった方面に詳しくなく、私の質問に戸惑い傷つきました。さらに悪い事に、その会社は原価計算および管理会計はしていませんでした。結果として、私の質問はお客様をただ傷つけただけでした。後でそれが分かったので、私は深く反省をし、業務知識に関して知らないふりをするぐらいが丁度いいと考えるに至りました。
　人は誰しも先入観を持っています。ですが、コミュニケーションミスはそれが原因で起きます。相手がプロだからと言って、必ずしも全てを知っているわけではありません。私達技術者は専門領域を深く知る事を求められていますが、世の中の全ての人がそうであるとは限りません。専門領域について無頓着な人もいます。そういった人に、専門知識を前提とする話しをしてはなりません。相手をただ傷つけるだけです。
　コミュニケーションは、相手の事を知るために行います。特に私達の職業は、自分の意見など殆どどうでもよく、お客様に忠実でなければなりません。お客様が望むシステムを作るのが仕事であり、自分が好むシステムではないのです。従って、自分の拘りや好みはどうでもいい話しなのです。
　ただし、自分を抑えなければならない半面、正しい事を正しいという事もまた重要です。お客様が間違っており、いずれシステムトラブルが起こるのを知っていて、それを見逃すのもまた問題です。それを如何に上手く伝えるのか、それがコミュニケーションの奥深いところです。
　この件に関しての解決方法は一つだけです。それは、聞く事に徹して相手をよく観察する事です。相手をよく観察すれば、相手が求めているものが自ずと分かります。コミュニケーションが苦手な人は、自分の意見を話しがちですが、それは失敗の元なので聞く側に回った方が賢明です。この事をよく肝に銘じておけば、仕事だけではなく、私生活も上手くいくでしょう。情報を扱う職業だけに、専門知識だけではなくコミュニケーションにも注意を払いましょう。

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

　この記事は、実践的オブジェクト指向設計入門11の続きです。前回は、オブジェクト指向設計の作業のうちのひとつ、3つのモデルを組み合わせるを解説しました。今回は、アルゴリズムの設計を解説します。
　前回述べた作業で、オブジェクトが持つべき操作（メソッド）が分かりました。次にするべき事は、操作を実現するアルゴリズムを考える事です。分析結果は何をするかを表していましたが、設計段階ではどの様に行うのかを考えなくてはなりません。その為に、何をするのかに該当するアルゴリズムを考えます。
　しかしながら、アルゴリズムを考える事は意外と難しく、色々な事を考えねばなりません。それ故、オブジェクト指向方法論OMTでは、注意するべき項目を複数挙げています。そのうちの一つがアルゴリズムの選択です。機能モデルの仕様はアルゴリズムに近い状態になっています。しかしながら、同じ事をするにしても複数のアルゴリズムが考えられます。具体的には、計算の複雑さ、理解の容易さ、柔軟性、の3点に注意します。
　計算の複雑さとは、データのサイズに応じて、処理時間はどの様な関数で増加するのかです。これは、ソートアルゴリズムを思い浮かべると分かりやすいと思います。バブルソートの計算量はO（n^2）であり、余りに処理効率が悪すぎます。通常は他のソートアルゴリズムを採用するでしょう。ただし、最適化だけを考えてはなりません。他の要素も視野に入れましょう。
　理解の容易さについては、そのアルゴリズムの分かりやすさです。保守する事を考えた場合、アルゴリズムが複雑すぎるとコストがかかり過ぎます。ただし、分かりやすさというのは、あくまでもプロ基準です。新入社員の理解力に合わせると破綻します。この辺が誤解されやすいので注意が必要です。
　柔軟性とは、変更が生じた場合に直ぐに対応できるアルゴリズムにする事を指しています。変更は遅かれ早かれ行われます。その際に、柔軟性のないアルゴリズムを採用していると大変な事になります。この件に関しては、デザインパターンで学ぶと良いと思います。
　最後に付け加えると、テストの容易性が挙げられます。テストの容易性がないアルゴリズムをテストするのは困難です。品質を高めるためにテストをするのは当たり前の行為なので、あらかじめテストが行いやすい構造のアルゴリズムを採用しましょう。
　他にも並列性やセキュリティなど考慮するべき事は色々あります。広い視野を持ちアルゴリズムを選択しましょう。続く...

中の人の徒然草403

ここ最近は生活保護について騒がれています。正直言うといまさら何を言っているんだと思います。戦後数十年以上も何をしていたのでしょうか？システム不備を何時まで放置するのでしょうか？この状態で国会議員が仕事をしていると言えるのでしょうか？色々な疑問を感じます。ですが、ワイドショー的な事は言いたくないので、システム屋としての意見を述べます。
先ずこの件に関しては、要求定義をはっきりしなくてはなりません。その要求定義とは、日本で餓死者が出来る事を容認するのかという事です。そこをはっきりさせないから話しが前に進まないのです。建前ばかり言って議論が前に進まないのは日本の悪い癖です。私個人の要望を言いますと、餓死者が出る事を容認できない。
国家とは国民の生命と財産を守るものですから、餓死者を出す時点で存在意義がありません。従って、餓死者が出ないような国家システムを作る事が第一条件だと考えています。しかしながら、この国は民主国家ですので、餓死者を出してもいいというのであれば、それを国家システムの要求定義としてはっきりと表明するべきです。
餓死者を出してもいいというのであれば、それなりの国家システムを考えるべきですが、私自身は納得できないので餓死者を出さない事を前提に、国家システムについて考えてみました。
一番最初の疑問が所得申告システムが税金を取る事しか考えていない点がおかしいと思います。生活保護は自己申告制ですが、そもそも「国民に対して健康で文化的な最低限度の生活を保障」するものですからおかしいです。何故ならば、所得申告で収入額を把握しているのも関わらず、生活保護課は何も知らないというのですから、何のために情報を収集しているのかと、問われても仕方が無いと思います。現状では、その情報を税金を取る事にしか使用していないのですから、政府の態度が「国民からお金を取る事しか考えていない」と受け取られても仕方が無いでしょう。
所得申告で得た情報を活用しない事で色々な弊害が起きています。高額所得者の親族が生活保護を受給しても分かりませんし、その逆に収入が0の人を無視しているという根深い問題があります。所得申告で得た情報を活用するという当たり前の行為をしていれば、おにぎりが食べたいといいながら餓死する人も、高額所得者の身内が生活保護を従十する事も十分に防げたはずです。これはただの業務怠慢でしかないと私は思います。
さて、この件に便乗して一部の人達が国民総背番号制の導入が検討しているそうですが、所得申告で得た情報を活用すればいいだけであって、そんなシステムを導入するというのは如何なものかと思います。国民総背番号制でシステムを運用するという事は、無限に必要となるセキュリティコストを税金で支払い、雨後の筍のように作られるであろう天下り法人が税金を浪費するでしょう。おまけに、消えた年金問題でシステム運用能力が無い事を証明していいるのですから、消えた国民問題などが発生する事が予測できます。おまけに、なりすましと改ざんが問題となります。
なりすましも怖いですが、改ざんはもっと怖いです。行政は基本的に身内に甘い体制ですから、勝手に犯罪履歴を追加されたり、口利きで犯罪履歴を消すなどの行為も横行するでしょう。他にも、税金を既に納入済みにしたり、税金を支払ってもデータが紛失して二重に請求されたりもするでしょう。年金システムで運用能力が無い事が証明されたので、余計なシステムに多額の税金を掛けて作る事は反対です。
システムというと利点だけを考えて導入するべしだと叫ぶ人がいますが、システムには運用コストとセキュリティコストが発生します。おまけにサイバー犯罪によるリスクを考慮せねばなりません。それだけのコストとリスクをかけて、所得申告で得た情報を活用するだけに新しいシステムを作るなんて、私には信じられない事です。今までの傾向から言って、システムを作るにはコストは数千億円から数兆円まで掛かるでしょうし、全国民を24時間体制で管理するには、多額の人件費が必要となります。おまけに、天下り法人が作られるでしょうから、そのコストは天井知らずです。よけないシステムを考えずに、所得申告と生活保護間で情報を流通させるべきなのです。
次に気になるのが年金システムとの整合性です。このシステムは明らかにねずみ講化していますし、すでに破綻しています。おまけに、ある資料によると元々官僚たちの老後のためにつくられたシステムらしいですから、前提そのものが間違っています。この様なシステムは即刻廃止し、責任を追及した上で、生活保護との統合を考えるのが良いと思います。破綻したシステムに一体いくらつぎ込めが器が住むのでしょうか？破綻したシステムは廃棄するのがシステムの常識です。やり始めた事を否定できない所が、日本政府の悪い癖だと私は思います。原発やダムや道路などに同じ傾向が見られます。おそらくコスト感覚が無いのでしょう。下手すれば利益だと考えているのかもしれません。
この点に注目すれば解決策が見えてきます。先ず無駄なコストを削減しましょう。その方法は、絶対に必要なシステムだけ残し、それ以外のシステムは全て廃棄する事です。そうすれば、この国に最低限必要なコストが算出できます。そうすれば、必要な税金の額も明らかになります。消費税うんぬんでもめる以前に、何にいくらかかるのかをはっきりさせるのが当たり前の姿です。その際に考えなくてはならないのは人件費です。
日本の国家システムは人件費が高すぎます。天皇陛下よりも高い報酬を要求する国会議員に疑問を感じています。民間で一億の働きというと、少なくとも十億円ぐらいの利益を生んでもらわないとありえない給与の額ですし、天皇陛下よりも報酬が高いというのは納得がいきません。彼らは常日頃、主権者である国民のために働いていると公言しているのですから、労働最低賃金を基準に、天皇陛下の給与以下の生活できる程度にするべきです。むろんこれは公務員も当てはまります。公僕という割には報酬が高すぎます。言っている事とやっている事が違い過ぎます。
とはいえ私も無闇に人件費を削減すればいいと言っているのではありません。仕事が評価できない状態だから税金で支払うのに疑問を感じているだけです。民間では、自分が生んだ利益から報酬が算出されますから、仕事の成果が可視化されていない時点でおかしいのです。おまけに、「国民のために働いている」という宣言と一致しないものですから、疑問に感じない方がおかしいと思えてなりません。
次に生活保護および年金に替わるシステムですが、今のところはベーシクインカムが最適だと考えております。日本の場合は行政コストが無駄に税金を上げていますし、餓死者をなくするにはこれしか方法がないでしょう。こういうと、遊んでいる人にもお金が渡されると異議を唱える人がいますが、私は働きたい人だけが働けばいいと考えています。他の人がどうするのかではなく、自分が働きたいという意思を持っていれば問題ありません。ベーシクインカムで配られたお金は、働かない人でも消費者として参加するので別に気になりません。低収入でもいいから働きたくないだとか、生きがいが無くても働きたくないという人はそれはそれでいいのです。また、監視コストを費やすのは無駄以外のなにものでもありません。働く人にもお金が配られるのですから、働いたら負けだと言われる現状よりもよくなります。
国家システムについて本格的に調査したわけではないので、ざっくりとした感想はこんなところです。国民一人一人が自分の国家システムをどうするのか、真面目に考える日が来る事を願っています。