ネタつつき138 - コミュニケーションが取れない人の特徴

　私は仕事柄、多種多様な人々とコミュニケーションをとります。その中で、酷い状況を目にしました。今回は、反面教師にする為に、コミュニケーションが不可能な酷い人々を紹介します。
　私がもっともコミュニケーションを取れないと感じた人は、自分の思いこみだけで発言する人です。この手の人々は、そもそもコミュニケーションを取るつもりがありません。一方通行に自分が言いたい事だけをまくしたてるだけです。そんな人でもコミュニケーションを取る方法があるのではないかと模索していますが、今のところよい方法が思いつきません。
　根本的な原因は、何らかの思いこみで発言している人です。誰しも一度ぐらいは思いこみで発言する事があります。しかし通常の社会人は、自身の思いこみに気付いたら素直に認め、コミュニケーションを取ろうとします。一方、コミュニケーションを取るつもりが無い人、もしくは思考能力が著しく欠けている人は、自分が正しいと思いこんでおり、一方通行に相手を言い負かそうとします。しかも、間違いに気づいてもレッテル貼りをしたり、嘘をついたり、その他卑怯な手段をしたりして、無理やり押し通そうとします。その手の人は、誰かを攻める目的で発言しているので、双方向の会話になりえません。その人自身に問題があるので、こちら側から解決する方法がありません。
　思いこみの変形として、誰かの言葉を鵜呑みにしている人も正常なコミュニケーションがとれません。このケースが意外と多いのですが、その誰かが間違っている可能性を考慮していないので、真実を知っているがゆえに反対している人の意見を聞こうともしません。この手の人は結論を先決めているので、全く会話になりません。多かれ少なかれ、人は噂や迷信を信じ込んでいるケースが意外と多いので注意しましょう。
　最後の最も酷いケースは、誹謗中傷するのが目的の人です。この手の人と会話が成り立たないのは明白です。どうしようもありませんので放置するしかありません。もしくは軽犯罪に対する対処法を取るしかないでしょう。
　こういった人にならない為にするべき事は、発言する時は裏付けを取り、相手の意見を聞く心を持つ事です。誰かの言葉をうのみにせず、それが本当に正しいのかという疑問を常に持ち、相手の事が正しい可能性を視野に入れて会話しましょう。
　私の場合は、常に背門書などで調べ、それが成り立つ条件を考え、相手の言葉に耳を傾ける姿勢を持ってコミュニケーションをしています。システム屋は異業種の人と会話をする事が多く、情報技術を知らない人と情報技術の内容でコミュニケーションをする場面が多いので気をつけています。これは簡単な事ではありませんが、相手に対する敬意と社会常識を持てば自ずとできます。もちろん、何事も100％の成功はありえませんが、少なくともコミュニケーションが取れないと言われた事はありません。正確に言うと、1・2回だけ誰かの言葉を鵜呑みにしている人から、一方通行に言われた事がありますが、コミュニケーションを取る意思が無い人とは会話が成り立ちません。会話は双方の意思があって成り立つものですから、意思が無い人とはどうしようもありません。この状態でも何とか解決したいとは考えているのですが、そもそもレアケースですし、おそらく手段そのものが無いと思います。
　なにはともあれ、自分だけはコミュニケーションが取れない人にならないように注意しましょう。1人々がその心掛けを持てば、よりよい社会になるでしょう。全員が最善を取るのは無理でしょうが、最悪だけは避けられる筈だと私は思います。

オブジェクト指向プログラミングは逆転の発想から生まれた

　オブジェクト指向プログラミングの見どころは、やはり逆転の発想にあります。その発想を知る事により、オブジェクト指向プログラミングの神髄が分かると思います。その発想を知るには時代背景から知る必要があります。
　オブジェクト指向プログラミングが生まれる前には、構造化プログラミングの時代でした。構造化プログラミングは、関数（機能）を視点においてプログラミングをしていました。C言語でプログラミングしてみると、その世界が体験できます。

#include 

struct Foo
{
    int value;
};

void Add( struct Foo* a, struct Foo b )
{
    a->value += b.value;
}

int main()
{
    struct Foo a, b;
    a.value = 1;
    b.value = 2;
    printf( "加算前の値；%d\n", a.value );
    Add( &a, b );
    printf( "加算後の値；%d\n", a.value );
    return 0;
}

Add関数にFoo構造体を渡して計算しています。これは関数（機能）を主眼に置いているので、関数視点のプログラミングです（※関数型プログラミングの話しではありません）この時代の構造化プログラミングは、データと関数が別々のものでした。従って大規模になると、大量のデータと関数が必要になり、管理と集団作業が難しい状態でした。
　今度は、C++によるオブジェクト指向プログラミングの例を見てみましょう。

#include <iostream>

class Foo
{
private:
    int value;
public:
    void SetValue( int value ) 
    {
        this->value = value;
    }
    int GetValue()  const
    {
        return this->value;
    }
    void Add( Foo b )
    {
        this->value += b.value;
    }
};

int main()
{
    Foo a, b;
    a.SetValue( 1 );
    b.SetValue( 2 );
    std::cout << "加算前の値；" << a.GetValue() << std::endl;
    a.Add( b );
    std::cout << "加算前の値；" << a.GetValue() << std::endl;
    return 0;
}

今度はデータの方に注目して、プログラミングをしている事が分かると思います。変数を自由に触れないので、プログラムの行数が増えます。ですが、変数に直接触る事による弊害の方が多いので問題になりません。また、関数がデータに付属しており、管理と集団作業が構造化プログラミングよりも簡単になりました。
　以上の様に、視点を変えると新しいものが見える事があります。関数とデータの立場を逆転した事により、新しいプログラミングパラダイムが生まれました。オブジェクト指向プログラミング見れば、見方を変える事は大変重要だという事が分かります。また歴史を知っておけば、よりプログラミングが面白くなると思います。

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

　この記事は、実践的オブジェクト指向設計入門17の続きです。前回は、設計の最適化について解説しました。今回は制御の実装を解説します。
オブジェクト指向方法論OMTでは、次の作業として制御の実装が提唱されています。この名称は紛らわしいのですが、実装／プログラミングの事ではありません。実装の制御とは、動的モデルに表されている状態ー事象モデルを実装するための戦略を具体化する作業の事です。すなわち、動的モデルの具体化を示しています。
　オブジェクト指向方法論OMTでは、動的モデルの具体化するアプローチを、手続き駆動システム・事象駆動システム・並列タスクの3点挙げています。
　長くなるので次回から、動的モデルを具体化するためのアプローチ法を1つずつ解説していきます。続く。

中の人の徒然草414

　それにしても暑いですね。暑さに参っているインドリです。でも、心は常に熱いけどね。気温の厚さはともかく、人は心に熱さを持っていないと駄目というのが持論です。特に技術者は熱き魂を持っていないと、秒進日歩で変化する技術に対応できません。自分でここまできたらいいかなんて限界を決めたら、技術者としてはお終りになると思います。
　常に変化するのが技術者としての誇りです。それを失くしたら楽になれるかもしれませんが、それは技術者として進歩を止めた事を意味します。人間だから時には休むのも結構。寄り道するのも大いに結構。悩む事も必要。だと思いますが、歩みを止めたらそれでお終りです。人よりも歩みが遅くても1歩ずつ前に進み続けるその熱き魂があれば、その人は技術者だと思います。
　長年といっても10年ちょっとだけ技術者と生きて思うのですが、本当に必要なのは技術に対する愛と情熱です。私はそれ程頭がよくありませんが、それでも心さえあれば出来ます。5歳でも80歳でも技術としての心を持てば何も問題はありません。技術は全ての前に平等です。
話しは変わりますが、何らかの事件でネットの使用について聞くたびに、気持ち悪くなります。包丁を使った殺人を聞いたら、料理人もきっと同じ気持ちになるかと思います。プロは道具を愛します。その道具を本来の使用目的と違う事に使用されると嫌な気分になるのは当然でしょう。
　なぜこんな話しをするのかというと、最近の虐めはネットとか携帯を使うと聞いたからです。インターネットや情報端末はその様な目的で作られたものではありません。人を助けるために作られたのであって、誰かを傷つけるために作られたものではありません。包丁が人を殺すためにつくられたものではないのと同じです。
　どうすれば、情報技術の正しい使い方が広まるのか、それが気にかかります。老後は、正しい情報技術の使い方の普及に励むかもしれません。
　それはそうと、やはりオリンピックが熱い。私はあんまり見ていませんが、そういう健全な熱さは気持がいいですね。金メダルの数とかはどうでもいいです。一生懸命だったらそれだけでいいです。スポーツでも趣味でもなんでもいいから一生懸命になれる、それが人としての正道だと私は思います。

ネタつつき137 - プロは常に他者に合わせるものかもしれない

　最近ふと気付いた事があります。それはプロは常に誰かに合わしているという事です。仕事で創るシステムはお客様が望むものですし、共同作業でも常にメンバーに合わして行動します。20代前半の頃は研究者という事もあり、自分が持つ技術と知識を総動員して、自分ならではのものを創ろうとしました。しかし、業務システムの開発に携わってからは、その様な事はなくなりました。
　特許に関わるようなシステムとは違い、業務システムの開発は特有の難しさがあります。それは、限られた選択肢の中で開発をする難しさです。業務システムの場合、技術的には研究に比べると難しくありません。では簡単なのかというとそんな事はありません。純粋な技術の部分ではなく、違う部分が難しいです。研究は持てる全ての技術と知識を使えますが、業務システムの場合それほど自由に選べません。チーム開発の場合は他者に合わせますし、単独開発の場合もお客様の望む範囲に合わせます。
　20代前半の頃は、自分は技術者だから自分の手で新しい技術を開発したいと考えていましたが、様々な人と出会ううちに考え方が変わりました。創るものがお客様のためのものであるから、その限定された状況内で如何に技術を使うかが大事です。それに冷静に考えると、1つの仕事で全ての技術と知識を使うのは未熟な証拠です。
　持てるすべての技術と知識を、使いたいというのは技術者の本能でしょう。今でもたまにその衝動にかられます。ですが、その様なプロジェクトは存在しません。普通に考えて、その様な技術のごった煮状態では、実務で使えるシステムになりえません。システムは要求があって創るものです。技術から逆算して創るものではありません。技術者の宿命として、毎日知識を広げ深めていきます。そうなれば自然と、1つの仕事の範囲を超えてしまうのではないでしょうか？それを考えると、ある種限定された技術と知識を使うようになるのは当然だと言えます。
　初めは面白さが足りないと思っていましたが、意外と限られた選択肢内でシステムを創るのも楽しいです。限定された状況は、新しい発見をもたらします。自分が知っていると思っていた技術で思わぬ使い方を閃いたり、物事の新しい見方を学んだり、開発メンバーから新しい発想を学んだりできます。
　知識についても使うべき状況が学べます。研究者の頃は知っている事全てを話したりしましたが、コミュニケーションという視点から考えたら失格です。時には知らない振りをした方が物事が円滑に進みます。誰かを立てるというのは重要な事です。プロジェクトの達成が目的であって、自分が目立つ事が目的なのではありません。プロジェクト達成のために空気になった方がよいのであれば、私は躊躇せず空気になります。システムは誰のために創るものであり、自分の事などどうでもよいのです。
　20代の人は自分が一番になるのが重要だと思うでしょう。しかし本当に重要なのは、システムを使う人の役に立つ事です。ですから私は、プロは常に他者に合わせるものかもしれないと思っています。もしかしたら、プロの理想形は存在さえ意識させない人なのかもしれません。

初心者のためのC#プログラミング本格入門86 - 執拗に攻めよう

　この記事は、初心者のためのC#プログラミング本格入門85の続きです。前回は、内部クラスについて解説しました。今回は、実践的なテストの心構えを解説します。
　前回サンプルプログラムのバグを潰しました。しかし本当にバグはもうないのでしょうか？テストデータを追加して検証してみましょう。

public void CalculateMultiExpression()
{
    TestData[] tests = new TestData[]
    {
        //基本チェック
        new TestData( "( + 1 2 ) + 3", ( 1 + 2 ) + 3 ),
        new TestData( "( + 1 2 ) * 3", ( 1 + 2) * 3 ),
        new TestData( "( + 1 2 ) - 3", ( 1 + 2 ) - 3 ),
        new TestData( "( + 1 2 ) / 3", ( 1 + 2 ) / 3 ),
        //演算の順番チェック
        new TestData( "( + 3 4 ) + 3", ( 3 + 4 ) + 3 ),
        new TestData( "( + 3 4 ) * 3", ( 3 + 4 ) * 3 ),
        new TestData( "( + 3 4 ) - 3", ( 3 + 4 ) - 3 ),
        new TestData( "( * 3 4 ) / 3", ( 3 * 4 ) / 3 ),
        //3個の式をチェック
        new TestData( "( + 10 1 ) ( + 2 1 ) + 3", 
            ( 10 + 1 ) + ( 2 + 1 ) + 3 ),
        new TestData( "( + 1 2 ) ( * 2 ) * 2", 
            ( 1 + 2 ) * 2 * 2 ),
        new TestData( "( + 10 5 ) ( - 3 ) - 5", 
            ( 10 + 5 ) - 3 - 5 ),
        new TestData( "( * 10 2 ) ( / 2 ) / 2", 
            ( 10 * 2 ) / 2 / 2 ),
        //4個の式をチェック
        new TestData( "( + 10 1 ) ( + 2 1 ) ( + 3 ) + 4", 
            ( 10 + 1 ) + ( 2 + 1 ) + 3 + 4 ),
    };
    foreach ( TestData test in tests )
    {
        CalculateMultiExpression(
            test.Expression, test.RightValue );
    }
}

デバッグ実行（F5）して下さい。3個以上の複合式ではエラーが発生しています。複数のエラーが表示されていますが、3個の式での加算処理（最初）と4個の式（最後）に注目してみましょう。よく見ればエラーの原因が分かると思います。
　この2つの結果をよく見ると、加算処理が2回しか行われていない事が分かります。ということは、MultiAnalyzerオブジェクトのCalculationメソッドが怪しいと言えます。Calculationメソッドのプログラムをよく見るか、ブレークポイントを設定して、ステップイン（F11）とステップオーバー（F10）の機能を使い、プログラムの実行中の値をよく観察すれば分かります。ステップイン（F11）とステップオーバー（F10）は、デバッグ機能の一種です。ブレークポイントを使って止まった時に使用します。この2つの機能を使うと、プログラムを一行ずつ実行する事が可能となります。この機会に使ってみて下さい。エラーの原因が分かったら読み進めて下さい。
　分かりましたか？答えは「double backValue = analyzers[ i - 1 ].Calculation();」の部分です。このプログラムだと、前式の計算結果が反映されていません。それで2回分しか計算されていないのです。つまり、作業用につくった変数tempsで処理をするのが正解です。念のために、修正したプログラムを掲載します。

//計算式の計算結果を返す
public double Calculation()
{
    //初期値を設定
    double result = 0.0f;
    
    //複数の式を計算
    System.Collections.Generic.List<Analyzer> temps =
           new System.Collections.Generic.List<Analyzer>();
    temps.Add ( new Analyzer( analyzers[ 0 ] ) );
    if ( analyzers.Count > 1 )
    {
        for ( int i = 1; i < this.analyzers.Count; ++i )
        {
            Analyzer temp = new Analyzer( analyzers[ i ] );
            double backValue = temps[ i - 1 ].Calculation();
            temp.AddValues( backValue );
            temps.Add( temp );
        }
    }

    //最終的な計算結果を返す
    result = temps[ temps.Count - 1 ].Calculation();
    return result;
}

デバッグ実行（F5）して下さい。今度はエラーが表示されません。
　今回の解説で分かったと思いますが、テストはしつこいぐらい念入りに行いましょう。バグは油断を栄養にして増殖します。これでもまだテスト量が全然足りません。実務ではもっと詳細に行います。初心者用の記事と言う事もあり現在はテストが不十分です。テストを十分に行うには、覚えるべき文法があります。適切な時に紹介するので楽しみにして下さい。

初心者のためのC#プログラミング本格入門85 - 内部クラスを使って可読性を上げよう

　この記事は、初心者のためのC#プログラミング本格入門84の続きです。前回は今までの復習をしました。今回は内部クラスを解説します。
　前回の新しいテストプログラムができましたが、式と正しい値が離れていて不便でした。これはちょっとした不便ですが、それを見逃さないのがプログラミング上達の道です。式と値をセットで記述するとくれば、読者が思いつくのはタプルでしょう。しかしタプル（System.Tuple）はプロパティがItem1とかなので読み難いです。テストを書いて間もないころだと覚えているでしょうが、１年経ってからプログラムを見ると意味が分からないかもしれません。
　System.Tupleよりも読みやすいのはクラスですが、下手にクラスを量産すると余計に読み難くなります。何故ならば、他のプログラムから「見えてしまう」からです。ならば他のプログラムから見えないクラスが定義できれば便利です。それを可能とするのが内部クラスです。
　内部クラスというのは、クラスの内部に定義できるクラスです。実際に見てみれば分かると思います。

class MultiAnalyzerTest : Test
{
    //関係のないプログラムは省略・・・
    
    //複数の式の計算処理をチェック
    private class TestData
    {
        //式
        private string m_exp;
        public string Expression { get { return this.m_exp; } }

        //値
        private int m_value;
        public int RightValue { get { return this.m_value; } }

        //式と値を設定
        public TestData( string expression, int rightValue )
        {
            this.m_exp = expression;
            this.m_value = rightValue;
        }
    }
    public void CalculateMultiExpression()
    {
        TestData[] tests = new TestData[]
        {
            //基本チェック
            new TestData( "( + 1 2 ) + 3", ( 1 + 2 ) + 3 ),
            new TestData( "( + 1 2 ) * 3", ( 1 + 2) * 3 ),
            new TestData( "( + 1 2 ) - 3", ( 1 + 2 ) - 3 ),
            new TestData( "( + 1 2 ) / 3", ( 1 + 2 ) / 3 ),
            //演算の順番チェック
            new TestData( "( + 3 4 ) + 3", ( 3 + 4 ) + 3 ),
            new TestData( "( + 3 4 ) * 3", ( 3 + 4 ) * 3 ),
            new TestData( "( + 3 4 ) - 3", ( 3 + 4 ) - 3 ),
            new TestData( "( * 3 4 ) / 3", ( 3 * 4 ) / 3 )

        };
        foreach ( TestData test in tests )
        {
            CalculateMultiExpression(
                test.Expression, test.RightValue );
        }
    }
}

前回のプログラムと比べると、だいぶ読みやすくなりました。内部クラスは「private class TestData」の部分です。クラス定義内でクラスを定義しています。これが内部クラスの書き方です。ただし内部クラスは必ずしもprivateにする必要はありません。ですが、publicにすると違うプログラムからアクセス出来てしまいます。それを有効利用するのは内部クラスの違う使用目的であり、今回の話題とは別のプログラミングテクニックなので、今のところは気にしないでください。
　何度か書いていますが、C#はプログラムが読みやすくなる工夫がされているので、ちょっと気になったら新しい文法を調べましょう。そうすれば、ぐんぐんとプログラミングが上達します。

初心者のためのC#プログラミング本格入門84 - 油断せずに行こう

　この記事は、初心者のためのC#プログラミング本格入門83の続きです。前回は、多重定義について解説しました。今回は復習をします。
　以前述べたように、テストプログラムは徐々に難しくしていきます。その考えに従って、CalculateMultiExpressionテストをちょっと難しくします。

class MultiAnalyzerTest : Test
{
    //複数の式の計算処理をチェック
    public void CalculateMultiExpression()
    {
        string[] expressions = new string[]
        {
            "( + 1 2 ) + 3", "( + 1 2 ) * 3",
            "( + 1 2 ) - 3", "( + 1 2 ) / 3"
        };
        double[] rightValues = new double[]
        {
            6, 9, 0, 1
        };
        for ( int i = 0; i < expressions.Length; ++i )
        {
            CalculateMultiExpression( 
                expressions[ i ], rightValues[ i ] );
        }
    }

    private void CalculateMultiExpression(
        string expression, double rightValue )
    {
        ++this.testCount;
        this.target = new MultiAnalyzer();
        this.target.AnalyzeExpression( expression );
        double result = this.target.Calculation();
        if ( result != rightValue )
        {
            ++errorCount;
            System.Console.WriteLine(
                expression +
                " の計算処理が正しくありません。 " + 
                "正しい値：{0}, 処理結果；{1}",
                rightValue, result );
        }
    }
}

前回の復習のために多重定義を使っています。今まで解説してきた文法を使っているのでプログラムの内容は分かると思います。デバッグ実行（F5）して下さい。今回は珍しくエラーがありません。インドリにしては珍しいと思った人は鋭いです。テストはちょっと意地悪になるぐらいが丁度いいです。
　テストデータを増やしましょう。

//複数の式の計算処理をチェック
public void CalculateMultiExpression()
{
    string[] expressions = new string[]
    {
        "( + 1 2 ) + 3", "( + 1 2 ) * 3",
        "( + 1 2 ) - 3", "( + 1 2 ) / 3",
        "( + 3 4 ) + 3", "( + 3 4 ) * 3",
        "( + 3 4 ) - 3", "( * 3 4 ) / 3"
    };
    double[] rightValues = new double[]
    {
        6, 9, 0, 1,
        10, 21, 4, 4
    };
    for ( int i = 0; i < expressions.Length; ++i )
    {
        CalculateMultiExpression( 
            expressions[ i ], rightValues[ i ] );
    }
}

デバッグ実行（F5）して下さい。案の定？エラーが表示されます。
　「やっぱりバグを仕込んでいたか！」と怒らないで、エラー文に注目して下さい。「 （ 3 + 4 ） - 4 」の答えが４ではなく-4になっています。どうやったら-4になるのでしょうか？Calculationメソッドのプログラムをよく見て下さい。そうすると、１つの式を計算して、次の式へ値を追加している事が分かります。やってみましょう。

4 + 3 = 7
3 - 7 = -4

一致しています。正しくは「 7 - 4 」にしたいのですから、値の並びが逆になっています。念のために割り算の方も計算してみましょう。

4 * 3 = 12
3 / 12 = 0.25

やはり逆順になっています。ということは、値を逆に記録して計算すれば解決します。早速修正してみましょう。どこを修正するべきなのかは問題です。答えを見る前に考えて下さい。
　答えを発表します。答えは・・・AnalyzerオブジェクトのAddValuesメソッドです。このメソッド内のプログラムを修正すればこのエラーの原因となっているバグをなくせます。

class Analyzer
{
    //値を直接追加
    public void AddValues( double value )
    {
        this.values.Insert( 0, value );
    }
}

Insertメソッドを使えば、任意の位置に追加できます。デバッグ実行（F5）して下さい。今度はエラーが表示されません。
　今回は復習をしました。プログラミングは何度も繰り返さないと上手くなりません。初心者用のプログラミング本を買っても、プログラミングが分からない人がいるのはそれが原因だと思います。特に計算された過ちをしないという点が大きいと思います。本という媒体上、計算された過ちをできないのでしょう。また、インターネット上でも正しい答えを羅列しているものしか見た事がありません。これは著者のプライドかなと思います。※趣味目的のものは除いています
　しかし、正しい答えを見るだけなんて学習になりません。人に物を教える為ならば教える側は間違う勇気が必要です。下手なプライドは要りません。もしかしたら、教える為ならば自分が恥を書いてもいいというのが、私のプライドなのかもしれません。私は自己顕示欲のためにブログを書いているのではなく、誰かにプログラミングを伝えるためにブログを書いています。ですから、自分の技術力を見せびらかす記事を書いた事がありません。常に想定する読者に合わせて書いています。長年システム屋をしているので、お客様に合わせて自分を出さないのが普通になっています。プロというものは常に誰かのために考えるものです。自分を誇示する必要なんてありません。これからも読者目線の記事を書くので楽しみにして下さい。

ネタつつき136 - システム屋が考える虐めに対する対処法

　誤解されないように先に書きますがこれは真面目な話しです。私なりに虐め問題について対処法を考えました。現時点で分かっている事は、「虐めで人が死ぬ事があり得る」、「問題が隠蔽される可能性がある」、「誰も対処してくれない可能性がある」、「虐めそのものはなくならない」の4点です。これを前提に対策法を考えます。
　第一に取るべき行動は情報の記録です。どの様に虐められたのかの情報を詳細に記録します。この情報がなければ、後でとれる行動が制限されるので絶対に行いましょう。暴力をふるわれたら病院へ行って診断書を書いてもらいましょう。さらに情報隠ぺいに備えて、念のために情報のコピーも取りましょう。情報は重要です。虐めに関する情報を詳細に記録します。
　第二に、情報の発信です。現在は様々な機関に、多種多様な情報ツールで情報を発信できます。虐められた事を隠してはなりません。すぐさま情報の公開を多方向に展開しましょう。行政機関だけではなく、ボランティア団体や宗教団体も視野に入れましょう。この時もどこに相談したのかとその機関の返事を詳細に記録して下さい。ただし、個人情報の扱いに注意して下さい。自分が加害者になっては駄目です。汚い人が情報を隠蔽しようとするかもしれませんが、多くの経路で情報を発信すれば、誰かが何らかの行動を起こしてくれます。出来るだけ身内にも相談しましょう。
　一定期間うごいてくれない場合は、隠蔽されていると見做して下さい。その場合は助けを待っても無駄なので、一刻も早く最終手段の逃亡をして下さい。自殺に追い込まれるほど、虐めというレッテルで隠された犯罪は酷いものです。犯罪者によって、貴方の尊い命が失われるのはあまりにも惜しいです。自分の命を最優先で考えましょう。耐えても虐めは止まりませんし、日本の社会システムは不備が多く、法治機能が機能しない場合があります。日本社会は貴方を守ってくれない場合があるのです。社会システムの不備に対して個人が勝てるはずがありません。だから逃げるのは恥ではありません。
　自分の子供がいじめに遭っている可能性がある親御さんは、虐めを軽く考えて放置しないでください。虐めは犯罪行為そのものです。殺される可能性すらあります。情報を賢く使い、虐めに対処しましょう。対処しきれなかったら一刻も早く子供を避難させて下さい。社会システムに不備ある以上、常に頼れるのは親だけです。親だけが子供の命を守れます。

中の人の徒然草413

今日はいじめに対応した校長先生が自殺したというニュースを聞き、改めて教育システムに不備があるとの確信を持ちました。正しいシステムの基本は、「正しい事をやりやすく間違った事は出来ない」です。虐め問題に真っ向から対処した真面目な校長先生が自殺に追い込まれ、虐められた子供も自殺しています。これをシステムの不備と言わずとしてなんというのでしょうか。
改めて考えると虐め問題は今に始まった事ではありません。古くからあった事です。それにも拘らず、悲劇は止まりません。それは、自殺問題を個別の事件と捉えていた事に問題があると思います。
虐め問題が発生したら、その時だけ騒ぎ当事者を叩いてお終いです。ですが、問題があるシステムは人を狂わせます。現に自殺問題は何一つ解決されていません。ただ騒ぐのではなく、冷静に抜本的な解決法を考えるべきです。何時までも同じ問題が起こる状態は愚かとしかいいようがありません。高い知性を持つ人々がいるのですから、知恵を合わせて二度と虐めで人が死なないシステムを、作り上げるのが普通の流れだと言えると思います。
日本は問題を解決しようとしません。これでは国家が滅ぶのは時間の問題です。一つ一つ問題を解決するという、当たり前の体制を取る習慣が出来てほしいと切に願っています。