ネタつつき151 - 誹謗中傷や流言飛語はどうして起こるか？

　インターネットに限らず、誹謗中傷や流言飛語は多々あります。こうした質の悪い情報を減らさねば、本当の意味で情報化社会と呼べません。そこで今回は、誹謗中傷や流言飛語がどうして発生するのか及びその対策について考察しました。
　私が調べたところ、誹謗中傷や流言飛語は、人の悪意と無理解で構成されていました。先ずは無理解について述べます。
　ここでいう無理解とは、誤読や無知といった「理解していない」事全般を指しています。読解能力が低い人、よく人の話を聞かない人、前提となる知識がない人、...などといった人は多く存在します。そういった人々が、自分が理解していない事を自覚せず、何かの情報を完全否定したり、誰かを誹謗中傷したりすることがあります。厄介なことに、そういった自分が理解していない事を理解しない人は、物事を深く考える習慣と能力がありません。またその手の人は、自分の発言の責任について深く考える事もないので、平気で人を誹謗中傷し流言飛語を流します。そういった無理解に対する対策法は、真実を語り続けるのが一番だと思います。
　次に、人の悪意による誹謗中傷や流言飛語ですが、これが一番厄介です。特に無理解で悪意のある人は最悪です。本人に理解する能力がないので、説得することは不可能ですから、本人をどうにかするのは無理です。本来は法律がどうにかしなければならない問題なのですが、日本の法律と体制は遅れているのでそれは望めません。この手の人に対する対処法は、真実を広く語りつつ、毅然とした態度を崩さないのが一番だと思います。これでは不完全ですが、残念ながら現状ではそれしか方法がありません。
　主に情報の発信者を主体に話しを進めましたが、真の解決法は情報法の受け手が誹謗中傷や流言飛語を真に受けない事です。真に受ける人が居なければ、無理解による誹謗中傷も流言飛語も意味を成しません。情報を受ける側としての情報リテラシー教育と、そういった有害な情報をどのようにして排除するのかが、これからの社会的課題と言えるでしょう。

初心者のためのC#プログラミング本格入門111 - 例外処理の動きを知ろう

　この記事は、初心者のためのC#プログラミング本格入門110の続きです。前回は、テストプログラムをチェックする方法を解説しました。今回は、例外処理についての解説を進めます。
　前回、例外をキャッチする準備を整えたので、今まで作ったテストプログラムを修正して、テスト失敗時に例外をスローするようにしましょう。一例を挙げますので、それを参考にしてください。

//例外をスローするようにする
public void OneElementAdd()
{
    //テキトーに要素を追加して確認してみよう
    base.Execute();
    this.target = new SimpleList();
    int value = 10;
    this.target.Add( value );

    //要素の数が増えているはず
    if ( this.target.Count != 1 ) {
        string message = "要素追加後の要素数が間違っています。" +
            "追加処理が正しく行われていません。" +
            "予想値：1 返却値： " +
            this.target.Count;
        throw new TestFail( message );
    }

    //追加した要素は取り出せるはず
    if ( this.target[ 0 ] != value ) {
        string message = "正しく値が追加されていません。" +
            "予想値：" + value +
            " 結果：" + this.target[ 0 ];
        throw new TestFail( message );
    }
}

テストプログラムの修正が終わったら、テストを実行してください。違和感がありませんか？テスト件数をよく見てください。テスト件数が減っています。おまけに、予想されるエラーメッセージの多くが表示されていません。それらの事実からわかると思いますが、テストが実行されていません。何が問題なのでしょうか？
　その答えは、例外処理の動作にあります。例外処理は、例外がスローされると、キャッチするプログラムまで飛びます。それ故に、実行されないプログラムが出てくるのです。

public override void ExecuteAllTest()
{
    try {
        //ここでテストが失敗すると、
        this.OneElementAdd( );
        
        //ここからは実行されない
        this.CurrentTest( );
        this.AddElementCheck( );
        this.ForeEachTest( );
        this.ForeEachTest2( );
        this.OneElementRemove( );
        this.EnumeratorWhenRemoveElement( );
    } catch ( TestFail e ) {
        //テストが失敗したらこの行を実行
        base.Error( e.Message );
    }
}

　ここで問題となるのは、全てのテストが実行されない事です。1つのテストが失敗したら、それ以降のテストを実行しないという動きは、色々な問題が生じます。例えば、1か所だけ間違っているのか、複数個所間違っているのかが分かりません。なんにせよ、テストで混乱が生じるのは好ましいことではありません。
　例外処理をマスターするには、今回紹介した「プログラムの動き」を理解する必要があります。プログラミングを文法の暗記だと勘違いしている人が多くいます。しかし、プログラミングの学習は文法を暗記する事ではなく、こうしたプログラムの動きを理解する事です。プログラミングに期末試験はありません。文法をド忘れたら、専門書やインターネットなどで文法を調べてもよいのです。暗記することにほとんど意味はありません。本質を理解する事が学習なのです。

新しいWindowsの使い方

　新しいWindowsが発売されるたびに、「インタフェースが変わったから移行したくない」という人が必ず出てきます。インタフェースは大事な要素ですが、それだけのために移行しないというのは勿体ないです。というのも、マイクロソフト社は、無暗に新製品を出しているわけではなく、ちゃんと良くなっているからです。操作法が少し変わったからと言って、新しい利益を捨てるのは実に勿体ないです。とはいえ、インタフェースが変わったら、心理的抵抗を覚えるのも無理はありません。移行方法を教えずに新しいものを使えというだけではいけないと思いますので、私が推奨している方法を書きます。
　インタフェースが変わったから、新しいものを使えないという人に対して私は、普段している操作を書き出してみる事を勧めています。無意識に色々やっているように思うでしょうが、実際に書き出してみると、意外と同じ操作しかしていないことがわかります。生活習慣には一定のパターンしかありません。
　次に、書き出した普段している操作に、新しいOSの操作方法を調べて書きます。これで準備は終わりです。そのメモ書きを印刷して、手元に置いとけば困りません。後は慣れです。2・3日もすれば文句を言っていたことが馬鹿らしくなるでしょう。
　これは物事全てに当てはまります。新しいものに抵抗感がある人は沢山います。しかしながら、何事もやらないで否定していては、得られる利益も逃します。新しい操作だからやらない。そういった文句は言いやすいのですが、世の中は常に変化します。変化に対して抵抗することは無意味です。そんなことをしている暇があったら、さっさと行動を起こした方が精神衛生上もよいでしょう。
　人は年を取るごとに、変化を拒む傾向があると言われています。しかしながら、どれほど個人が抵抗しても、世の中の変化は止まりません。ならば、変化を受け入れ、新しいものと古きものの両方を活かしましょう。前向きが一番です。
　思い出してください。貴方は無意識に子供の時から変化を繰り返しています。つまり変化を無暗に否定する行為は、子供時から変わらないのと同じです。子供の時から変化しないことに何の意味があるのでしょうか？このたとえで、変化を否定することの無意味さがわかると思います。変化を否定する時間があれば、変化を受け入れる準備をした方が有意義な人生を送れます。後ろ向きなことで時間を無駄にせず、前向きなことに時間を使いましょう。後で後悔しても遅いのです。

初心者のためのC#プログラミング本格入門110 - エラーを発生させてテストをチェックしよう

　この記事は、初心者のためのC#プログラミング本格入門109の続きです。前回は、親の定義を有効利用して、便利なオブジェクトを作る方法について解説しました。今回は、エラーを発生させてテストプログラムをチェックする方法を解説します。
　前回、オリジナルの例外を簡単にスローできるようになりました。しかし、本当にうまくいくのかチェックしていません。ありがちな盲点と言えます。テストプログラム自身をチェックしないと、本当にテストプログラムが正しいのかわかりません。もし、テストプログラムが間違っていると、バグが生まれます。絶対にテストプログラムのチェックを忘れてはなりません。
　では、どうやってテストプログラムをテストするのでしょうか？テストプログラムのテストプログラムを作ると思いがちですが、ならばそのテストプログラムのテストプログラムの妥当性をどうやってチェックするのでしょうか？この方法では永遠に終わりません。初心者の方はこの事で困るようです。プロの人でも、「だからテストはやらない」と逃げる人すらいます。
　すごく難題のように見えますが、解決方法は簡単です。自分でエラーを発生させればいいのです。この方法はコストもかからず、納期に追われているときでも実行できます。実際にやってみましょう。

//関係のないプログラムは省略
partial class SimpleList 
{
    //ここを修正するだけでOK
    public int Count
    {
        get { return 0; }
    }
}

たった1行変えるだけでエラーを発生できます。このように、テストが何をチェックするのかを意識していればエラーを発生させるのも簡単です。逆に何をチェックしているのかわからないときは、エラーを発生させられません。この行為は、自分は何をテストしたいのかをはっきりさせる意味があります。
　さっそくテストを実行してエラーを発生させましょう。そうすると、例外処理がスローされた行でプログラムがストップします。これは、例外をキャッチするプログラムが用意されていないからです。復習を兼ねてキャッチするプログラムを打ちましょう。

//関係のないプログラムは省略
class SimpleListTest : Test
{
    public override void ExecuteAllTest()
    {
        try 
        {
            this.OneElementAdd( );
            this.CurrentTest( );
            this.AddElementCheck( );
            this.ForeEachTest( );
            this.ForeEachTest2( );
            this.OneElementRemove( );
            this.EnumeratorWhenRemoveElement( );
        } 
        catch ( TestFail e ) 
        {
            base.Error( e.Message );
        }
    }
 }

これでプログラムがストップしません。なお、try文の{}（波括弧）の位置は自由に変えられます。次のように書いてもOKです。

//関係のないプログラムは省略
class SimpleListTest : Test
{
    public override void ExecuteAllTest()
    {
        try {
            this.OneElementAdd( );
            this.CurrentTest( );
            this.AddElementCheck( );
            this.ForeEachTest( );
            this.ForeEachTest2( );
            this.OneElementRemove( );
            this.EnumeratorWhenRemoveElement( );
        } catch ( TestFail e ) {
            base.Error( e.Message );
        }
    }
 }

どっちにするのかは好み次第です。ただし、一度決めたらどちらか一方のスタイルを使った方がよいです。何故ならば、あとで統一したほうが読みやすくなるからです。プログラミングをするときは、後で読みやすいように注意しましょう。
　今回は、テストプログラムそのものをチェックする方法を解説しました。テストプログラムを、チェックする行為は忘れやすいので十分に注意しましょう。

情報集合論（仮名） 理論を使って数を分析

　この記事は自分用のメモです。０～∞を表わす新しい濃度関数Γを定義し、他の数も分析することにより、理論の使い勝手を試します。
　分数は2つの数を組みとする情報ととらえることができます。分子は自然数、分母は整数なので濃度は、( Γ - 1 ) * ( 2Γ - 1 ) です。なお、情報集合論では既約分数に拘りません。何故ならば、2/4と4/8は約分するとともに1/2ですが、情報としては別物だからです。無暗に約分すると情報が喪失します。ここで気付くのは、有理数の分数と実数の分数とは違う点です。実数の範囲で分数を考えると、分子と分母ともに浮動小数点数を使用できます。その点から分数の濃度は、抽象オブジェクトの濃度によると考えられます。また、複数の分数があるとわかります。
　実数は自然数に1対1対応できないという事は有名です。その要因は、小数点以下の数値にあると思われます。自然数とは違い、0.01, 0.001というふうに幾らでも数値の頭に先頭に0をつけられます。という事は、情報集合論の濃度で表すと、小数点以下の数値は( Γ / 10 ) + ( Γ )であり、小数点でない部分を考慮すると、実数の濃度は( 2Γ- 1 ) * { ( Γ / 10 ) + ( Γ ) }となります。ただしこの濃度は、部分集合に過ぎないので、無理数の濃度を加算する必要があります。また、表現形式もまだあるのでまだ濃度を確定できません。
　こうやって考えてみると、数は多様な表現形式があることがわかります。数という情報は奥が深い。良い分析対象となります。

VBオブジェクト指向プログラミング講座 第18回 実装の継承はカプセル化を破壊する

　この記事は、「第17回 継承の種類を知ろう」の続きです。前回は、継承には、インタフェースの実装と実装の継承の2種類があることを解説しました。今回は、実装の継承のデメリットについて解説します。
　実装の継承は素晴らしいものです。同じプログラムを何度も再利用できるので、生産性は飛躍的にアップします。実装の継承を知ったら、あらゆる場面でそれを使いたくなるでしょう。しかし、便利なものには必ず裏があります。こんな簡単なサンプルにも罠があります...

Imports System

Class Foo
    Public Overridable Sub Print(ByVal message As String)
        Console.Write(message)
    End Sub
End Class
Class PiyoFoo : Inherits Foo
    Public Overrides Sub Print(ByVal message As String)
        MyBase.Print(message)
        Console.WriteLine("ピヨ♪")
    End Sub
End Class

Module Sample

    Sub Main()
        Dim fp As New PiyoFoo()
        fp.Print("サンプル")
        Console.ReadLine()
    End Sub

End Module

あまりにサンプルが簡単すぎて、危険に気付かないかもしれませんが、すでに危険の兆候があります。それは、オブジェクト指向の原則を崩す大変危険なものです。
　サンプルプログラムをよく見てください。メソッドをオーバーライドし、メソッド内部でMyBaseを使っていますが、MyBaseはどこで使うのが正しいのでしょうか？それを知るためには、親のメソッドのソースコードを読むのが一番です。しかしながら、この行為はカプセル化の原則に反しています。
　オブジェクト指向プログラミングのメリットは、詳細を知らずとも再利用できる事でした。これがカプセル化の原則です。しかし、サンプルプログラムで示したように、オーバーライドする際に、親に関する詳細な知識が必要となる可能性があります。すなわち、実装の継承はカプセル化の原則を破壊する恐れがあるのです。
　かといって、実装の継承を無暗に避けるのも考え物です。何故ならば、オブジェクト指向プログラミングの恩恵を放棄することになるからです。前時代のプログラミングに帰ってしまいます。ではどうすればいいのかというと、危険を理解して頭を使えば問題は解決します。
　実装の継承の危険性は、親オブジェクトの実装詳細を知る必要があるというものです。ならば、オブジェクトの仕様書を作り、子オブジェクトを実装する人がやるべきことを示せばよいのです。そうすれば、親オブジェクトの実装を調べる必要がなくなります。

Imports System

''' <summary>
''' サンプル用の何らかのオブジェクトです。
''' </summary>
''' <remarks></remarks>
Class Foo

    ''' <summary>
    ''' 指定した文字列をコンソール画面へ出力します。
    ''' </summary>
    ''' <param name="message">出力する文字列</param>
    ''' <remarks>
    ''' このメソッドをオーバーライドするときは、
    ''' 最後に親のメソッドを呼び出してください。
    ''' ※改行文字は付加しません。
    ''' </remarks>
    Public Overridable Sub Print(ByVal message As String)
        Console.Write(message)
    End Sub
End Class

''' <summary>
''' 語尾にピヨをつけるオブジェクトです。
''' 意味はありません。
''' </summary>
''' <remarks></remarks>
NotInheritable Class PiyoFoo : Inherits Foo

    ''' <summary>
    ''' 指定した文字列の語尾にピヨをつけ、
    ''' コンソール画面に出力します。
    ''' </summary>
    ''' <param name="message">出力する文字列</param>
    ''' <remarks>注意：改行文字が自動で付きます</remarks>
    Public Overrides Sub Print(ByVal message As String)
        MyBase.Print(message)
        Console.WriteLine("ピヨ♪")
    End Sub
End Class

Module Sample

    Sub Main()
        Dim fp As New PiyoFoo()
        fp.Print("サンプル")
        Console.ReadLine()
    End Sub

End Module

サンプルなので厳密に書いていませんが、伝えたいことはわかると思います。実務ではこんな具合に、何をするオブジェクトなのかと、継承する際の注意点を必ず書きましょう。
　纏めます。実装の継承はカプセル化の原則を破壊する恐れがあるので、注意して扱いましょう。使用する際には、継承を想定するオブジェクトの仕様を書きましょう。継承を想定していないオブジェクトは、NotInheritableを指定し、無暗に実装の継承がされないようにしましょう。実装の継承の危険性を理解し、準備を怠らなければ大きな利益を得ることができます。

情報集合論（仮名） 無限の構造を考える

　この記事は自分用のメモです。情報集合論（仮名） 無限の正体と新しい濃度から引き続き考察します。前の覚書をもとに無限の構造を考えると、F#で以下のように表現できます。

//無限
type Infinity( name, seed, next ) =
  member this.Name with get() = name
  member this.Seed with get() = seed
  member this.Next with get() = next
  override this.ToString() =
    this.Name + "の" +
    "開始値は" + this.Seed.ToString() + 
    "、次の数は" + this.Next( this.Seed ).ToString()  

[<EntryPoint>]
let main argv = 
    //数
    let seed = 0
    let next x = x + 1
    let number = Infinity( "数", seed, next )
    printfn "%s" <| number.ToString()
    //自然数
    let seedN = next 0
    let n = Infinity( "自然数", seedN, next )
    printfn "%s" <| n.ToString()
    //終了
    0

無限構造には無限に要素を生成するための根源（種）と、要素を生成する関数が必要となります。無限構造はこの2つを分析すればその性質がわかります。
　さて、既存の濃度の定義「1対1で対応」は何がいけなかったのでしょうか？この点について考察しておかないと同じ罠にはまるおそれがあります。その結果に違和感がありますが、定義そのものは至極まっとうです。私が思うに、自然数目線だけで対応を考えていた点が不便さの元だと思います。自然数から整数を見ると1対1対応にできます。しかしながら、整数から自然数を見た場合、全射ですが単車ではありません。すなわち、負数と正数の2つが自然数の1つの要素に対応付けられてしまいます。これにより、情報の喪失が発生します。数学では問題がないのかもしれませんが、情報技術的には大問題です。
　次に偶数と自然数の関係について考察します。数学の濃度の定義によると、これもまた同じ濃度となりますが、同種の問題が生じます。自然数から見た場合、半分の要素に対応がありません。無理やり対応付けすることができますが、そうすると全単射でなくなります。この件もまた情報の喪失が生じるのです。この件に関する教訓は、親集合からの対応も考えようだと思います。
　これらの問題で厄介なのは、有限区間内では変換関数で誤魔化せることです。誤魔化せるならば同じ濃度で問題がないと考える人も居るでしょうが、変換関数を定義できるのと、その情報の性質そのものを同一視すると問題です。何故ならば、変換関数を通すという1プロセスが余分に付加されているからです。1プロセス余分に必要な情報と、余分なプロセスがない情報を同一視するのは危険です。また、変換された時点でその情報の変質が変わってしまいます。性質が変わってしまった情報を分析すると間違いが生じます。
　変換関数はそれ単独で分析するのに値するものです。決して無限構造内に埋もれさせてはなりません。何故ならば、変換関数はいくらでも考えられるからです。その中から1つを、無限構造の一部として特別視するのは無理があります。変換関数を独立して考える方が有意義な理論体系となります。

情報集合論（仮名） 無限の正体と新しい濃度

　この記事は自分用のメモです。情報集合論を考えるのにあたって、避けては通れないのは無限の概念です。情報は本質的に無限であり、無限を避けるという選択肢はありません。私が思うに無限とは、生成関数を持ち、生成関数の定義域内であれば、いかなる区間を指定しても値を取り出せる情報集合です。有限と無限の違いは限りがない点です。では、限りがないというのはどういう状態なのでしょうか？
　限りないとは一般に上限を表わす概念だと思います。つまり、無限集合の場合、有限集合とは違い、どれだけ大きな値でも指定できるという事です。ならば、無限の根源は何でしょうか？根源がなければ情報を生成できるはずがありません。
　そもそも情報とは人間が考えるものであるから、無限情報集合の根源は生成関数（情報の定義の仕方）だといえます。という事は、無限集合とは、いかなる区間を指定しても、何らかの値を返せるという事を意味します。ただし、情報の定義から考えて、生成関数の定義域内という制限があります。そうしないと、何でも同一視するという事になってしまい、情報を判別できなくなります。情報は区別できるものであり、その定義に反していますから、その情報が任意の情報であるために何らかの条件が必要です。
　具体例として自然数について考えてみます。自然数の生成関数はf( x ) -> x + 1です。定義域は0もしくは、生成関数から生成された情報です。そして、自然数の条件は、x != 0（0以外の数値）です。自然数集合は無限なので、定義域内のいかなる区間を指定しても情報を生成できます。なお、0は空集合とみなします。
　そうなると次に濃度が問題になってきます。濃度とは個数の拡張概念なので、有限集合と無限集合の双方に使えないと不便です。しかしながら、既存の濃度の概念は、「1対1対応」しかないので不完全です。現状では整数と自然数は同一濃度であり、大雑把すぎて無限の性質を細かく分類しているとは思えません。現在の濃度の定義は、個数というよりも、個数の次元数を意味していると思います。
　現在の濃度で困る事を具体的に考えます。整数集合と自然集合の濃度が同一であれば、情報技術では困ります。何故ならば、必要なビット数が違うので、表現できる最大値が変化するからです。この現状は情報技術としては大変困ります。こんな曖昧な状態ではシステムを実装できません。同一限界値を求めた場合（値の区間をそろえたい場合）明らかに、自然数集合よりも整数集合のほうが1ビット多く必要となります。
　そこで情報集合論では濃度の定義を生成関数に区間を指定してできる個数に変更します。例えば、整数集合は区間-10～+10を生成関数に指定すると21個の情報が生成できます。一方自然数集合は、1以上なので10個の情報しか生成できません。従って濃度は、自然数集合の個数を変数Xで表すと、整数集合の濃度は 2x + 1 となります。ここで問題となるのは、統一基準をどうするのかという点です。これについては、自然数の生成関数を基準にし、Γ（ガンマ：ジェネレートのG）とするのが良いと思います。Γ表記の濃度は、自然数集合の濃度 = Γ - 1、整数集合の濃度 = 2Γ - 1(-0を許さない場合）。 こうすることにより、異質な無限情報同士を比較できると思います。また、無限情報集合の性質の分析を生成関数の分析にすることができます。これは非常に有意義です。普通では太刀打ちできない無限の性質を分析できるようになります。

書籍をつつく151 - 数独。技術者の息抜きに最適♪

私は以前数独にはまりました。今でもたまにしています。簡単なルールで奥が深いので息抜きに最適です。
ルールは実に簡単。9×9のマス目に、1から9の数字を重ならないように並べるだけです。ルールを聞いたら、「そんなの面白いか？」と疑問に思うでしょうが、やってみるとすぐに夢中になります。
おまけに、脳を鍛えてくれるらしいです。




どれぐらい嵌っていたのかというと、激辛レベルの数独を10分以内に解くぐらいです。トレーニングしたらもっと速く解けそうですが、そこまでする必要はないと思って止めました。初めは難しいと思うでしょうが、2、3問解けば初級レベルでは困らなくなると思います。そこから数独はぐんと楽しくなります。是非、お試しあれ。

中の人の徒然草444

私は常日頃暗記だけならば意味がなく、本質を覚える事こそ意味があると考えています。日々暮らしていると、暗記と本質の違いをよく感じます。例えば、ニュースを見ていると、暗記しかしていないとよく感じます。何故ならば、異例と想定外といった単語を連呼し、表面的な意見しか述べないケースが多いからです。
物事の本質を分かっていれば、異例という単語を連呼しないはずです。というのも、ニュースの99.99999％は本質を考えれば十分に想定できる事だからです。また、想定外という逃げ言葉は、ただたんに「ものを考えていない」の言い換えであり、「何も考えていませんでしたよ」と責任放棄しているだけだからです。それにもかかわらず、考えていなかったといえば責任が問われない日本社会が異常です。実に犯罪に甘い社会です。人が死んでも「そんなこと考えていなかった」で済ますなんて事、普通に考えればありえないと思います。
でも、日本社会は「いじめだから」、「学校だから」、「メールはストーキング行為にならないから」（法律の条文にない単語だから）、「民事だから」などと言って、単語が変われば罪を免れる不思議な社会です。その事実から私は「暗記社会」だと感じています。機械的に単語を暗記し、その単語に合わなければ免罪される。そんな暗記主義は日本のいたるところで見受けられます。
会社でも理由ではなく「そうなっているから」で済まされているケースが多いようです。私はそういった非理論的なことが嫌いなので自営業をしていますが、会社とかかわるときそういった「機械的暗記」が不利益をもたらしているのを見聞きしています。今騒がれている体罰問題でも「そうなっているから」で深い考えもなしに常習化しています。日本社会は、何故暗記主義なのでしょうか？とても不思議です。
ただ、もっと不思議なことがあります。それは、知性を売り物にしている技術者たちにもその傾向が見受けられることです。考える事を商売にしている人たちが、「みんなそう言っているから」という暗記で思考放棄している様は気味が悪いです。そこまで暗記に毒されているのかと思うと、恐怖さえ覚えます。
思考停止した社会は必ず滅びます。日本が色々な問題を解決できないのは、付和雷同で物事を考えないからだと思います。今も不景気だから経済対策をすると暗記を提唱していますが、立法府本来の仕事は立法です。ずいぶん前からお金をコントロールすることが政治家の仕事になっていますが、まともな法律さえあれば我々商売人がなんとかします。暗記的な行動（思い込みによる行動）で余計な行動せずに、本質を考えてちゃんと動いてほしいです。
日本は潜在能力が高いのですから、物事の本質を考える事を各々がすれば、世界一幸せな国になるのにと残念でなりません。