おとなのふりかけ考

 テレビなどのCMで見たことがあると思いますが、永谷園の『おとなのふりかけ』は、大人も子供もどの世代にも支持されるロングセラー商品です。永谷園のホームページ「おとなのふりかけ裏話 知られざる開発秘話」によると、次のようなことが書かれていました。これまでの消費者データによると「ふりかけ=子供商品」というイメージがあったことがわかりました。その思い込みへの挑戦が、この商品への開発につながったそうなのです。「子供だけでなく大人も満足できるふりかけ」というテーマでちょっと贅沢な品質とイメージの商品をデビューさせました。特にCMでは、「子供の目から見た大人の世界を描く」というコンセプトで制作されました。

 このCMを覚えている人がいるかどうかは知りませんが、「大人って、…ずるい。」というような文句が、子供の側から発せられたと、確か私は記憶しています。『おとなのふりかけ』は、大人向けの、大人にしかわからない世界の中で食べられ、楽しまれる食べ物に、子供の側からは見えた。ということです。大人は、それを子供に隠すしか手はないのですが、それはそれでいいと私は思います。子供に「大人はずるい。」と思われても、それは「かわいそう」に当たりません。それは、虐待でも差別でもありません。それは、『大人の世界へのあこがれ』の気持ちとして残ります。言い換えれば、これからの将来を生きてゆくための心の力が、子供に育ってゆくのです。

 しかも、『おとなのふりかけ』を子供が食べたら、法律で罰せられる。などということはありません。それは禁じられていないのです。子供が食べようが大人が食べようが、それは自由です。私の希望としては、そこから本当の『自由』を感じてくれる人が一人でも増えるといいなと思っています。そんなことは当たり前だと思っている人は多いと思います。けれども、『成人映画やビデオ』とか『おとなの飲み物』とか『おとなの玩具』とかを考えると、18歳未満で禁じられているものも、世の中には少なくないと思います。(もっと心配で問題なのは、それらを大人に禁じてしまうことは、大人を幼児化してしまう、という懸念があることです。)

 話を戻して、もう一つ述べておきたいことがあります。『おとなのふりかけ』を食べている大人を見て「大人って、ずるい。」と言っている子供についてです。大人は子供に見られている(あるいは、観察されている)ということです。大人がおかしなことをしていれば、それを子供に見破られるのは時間の問題です。

 人を殺しておいて「躾(しつけ)としてやった」という言いわけが、私には、「悪いことをした子供がする言いわけ」と同じに聞こえてしょうがないのです。あるいは、「体罰を行った人の厳罰化」は、本当に抑止力になりえるのか疑問な点があります。第三者や近くの人間が介入してひと言「それは良くないよ。」と、大人としてき然としていたほうが効果がありそうです。

 大人としての自信とか、大人としての資格がない、それが不安で仕方がない、という言葉をよく聞きます。大人は本当は誰だってそうなのです。そのことに共感することは悪いことではありませんが、だからといって、大人として相応(ふさわ)しくないことをして、良いわけがありません。私たち大人が気にかけていても、気にかけていなくても、子供の目は、私たち大人の姿を必ず見て育っています。

 

『共用体』からパクってみる

 ここで言う『共用体』とは、C言語などで一つのメモリ領域に複数の変数名や変数型を付けることができるプログラミング・テクニックあるいは規則のことを言います。「ある時は片目の運転手、またある時は流しの歌い手、そしてまた、ある時は、しがない私立探偵…しかしてその実体は…」という七つの顔を持つ男、多羅尾伴内みたいな話ですが、実際には、特殊なデータ操作以外に余り有効利用されていないとも、プログラマの間では言われてきました。よくわからない人は、ネットで検索して調べてみてください。
 今回私は、以前『人工知能もどき開発事情』(2018年11月19日)で述べたHTMLアプリケーションのプログラム(Reversi V1.55.hta)を作るに際して、この『共用体』の考えを参考にしました。そうすることによって、VBスクリプトという簡易言語で簡単にプログラミングする方法の一つを見つけてしまいました。
 VBスクリプトと言うと、BASIC言語をルーツとする初心者用プログラミング言語をイメージする人も多いと思います。そして、いつまでもそのような簡易言語を使い続けていると、プログラミングが困難になるほど馬鹿になってしまう(つまり、コンピュータ・プログラミングが上達しない)と、教え込まれてきた人も多いと思われます。(少なくとも、私は、20代の頃に、そのように周りから教え込まれてきました。)
 しかし、VBスクリプトの言語仕様や動作の仕組みは、昔のBASIC言語のそれよりも、JavaやJスクリプトのそれによく似ています。それらの機能限定版とみたほうがよいのかもしれません。そもそもマイクロソフト版のBASIC言語は、C言語やPascal言語のように、字下げによる入れ子方式のプログラミング記法だったので、行番号やGOTO文が無くても、プログラムが書けました。しかも、そのことは、プログラムのモジュール構造化をできるようにして、オブジェクト指向プログラミングへと発展しました。
 また、一昔前までは、ウィンドウズAPIなどをシステムコールとして呼び出していたものが、今ではオブジェクトの実体を作ってそれを活用するというふうに変わってきました。VBスクリプトなどの新しいBASIC言語では、システムコールを直接呼ぶ代わりに、ウィンドウ・オブジェクトというものを活用できるように、Set文とかNew命令とかClass文とかが、その言語仕様内で使えるようになっています。(なお、これらの命令や文は、既存のオブジェクトを利用するだけでなく、自前で新たにオブジェクトを作るのにも使えます。)
 問題は、ある程度実力のあるプログラマが、昔のBASICの言語仕様に捕らわれて、その呪縛から抜け出せられないでいることだと思われます。今さらBASICでプログラムを組むなんて、気恥ずかしい。あれは、初心者用のプログラミング言語だ。プロが使ったら馬鹿になる。というイメージが濃いのだと思います。(その割には、大きなシステムのバグ不具合で社会的に大きな事故が時折テレビのニュースになったりします。)
 実際には、実務上いろいろと事情があるとは思います。その一方で、現在の私は、そうした実務からは遥か遠く離れて、一銭にもならない趣味でコンピュータ・プログラミングをやっています。「何らかの技術をパクる。」と言うと、人聞きが悪いと思われるかもしれませんが、私には一銭の儲けにもなっていないことをここで断言させていただきます。今回私がパクったのは、『共用体』そのものではなくて、その『共用体』の役に立ちそうな側面の一つをVBスクリプトで形にしたに過ぎません。ひょっとしたら、そのVBスクリプトによるコーディングは、疑似的なプログラムであって、本物のプログラムとか、その実体は別にあるのかもしれません。仮想コンピュータならぬ、仮想プログラムなのかもしれません。あるいは、仮想ソフトウェアなのかもしれません。このことに関して、私自身は、コンピュータのプログラムとかソフトウェアとかは、もともとそのような(実ではなくて虚の)ものだと承知しております。
 いろいろとごったくを並べてしまいましたが、説明に入りましょう。『共用体』とは、具体的にC言語上で、

union EXAMPLE {
int value;
char str[4];
} sample;

などと表せます。『共用体(union)』の定義内{ }の変数の、メモリ上の先頭アドレスは同じになります。すなわち、sample.valueとsample.strは、メモリ上の同じ番地を指しています。前者は、そのメモリ番地から始まる4バイトで一つの整数型のデータ(数値)をC言語のプログラム上で扱えるようになります。後者は、前者と同じメモリ番地から4バイトで半角文字4つ分の文字データ(文字列)を同じくC言語のプログラム上で扱えるようになります。
 これだけ見てもわかるように、『共用体(union)』は、メモリの節約や有効利用にしか役に立たない、というC言語プログラマの主張に嘘が無いことがわかると思います。それはそれで正しいとして、私がやりたいのはC言語風に書くと次のようなことです。

union DIMENSION {
int R(63);
int Q(7,7);
} Board8x8;

 変数領域Board8x8とは、縦8マス横8マスのゲームのボードを表します。その各マス目に、白石あるいは黒石あるいは空きのいずれかの状態を記憶します。ここで、各intの変数(4バイト)はcharの変数(1バイト)のほうがメモリの節約になります。が、それほど大きなメモリ領域ではないため(256バイトくらい)、ここではメモリの節約は考えないことにします。
 これに何のメリットがあるのかを説明いたしましょう。1次元配列でアクセスできるメモリ領域を2次元配列でもアクセスできると、便利なことがあります。たとえば、囲碁や将棋やチェスなどの盤面を、コンピュータのメモリ上にデジタル化(つまり、オブジェクト化)したい場合を考えてみましょう。ゲームの盤面を一括してクリアしたり、くまなく検索したりする場合は、一つのカウンタやインデックスで一次元配列をアクセスするほうが処理は速いし、プログラムも効率的です。一方、一つか二つの盤上の箇所だけをチェックしたり変更したい場合は、縦y値と横x値(xy座標値)で2次元配列をピンポイント・アクセスする方が、速くて効率的です。
 しかるに、『思考ゲームプログラミング −オセロゲームのアルゴリズムと作成法−』という本で、『森田オセロVer.6.1』のC言語によるプログラムリストをみてみると、ゲームの盤面を表すメモリ領域は全て1次元配列になっていました。縦y値と横x値(xy座標値)で1次元配列にアクセスする前に、それら2つの値を計算して1次元配列上のポイント位置に変換する処理が必ず入っていました。そのたんびに変換するための計算をしなければならないため、C言語のプログラムがやや複雑になっていました。
 その変換のための計算を、プログラムを作る私の側でやりたくないがために、私は今回の技(わざ)を考え出したわけです。それでは、それをVBスクリプトとDynamicHTMLによるウィンドウ・オブジェクトを駆使して、どのように実現したかを以下に述べることとしましょう。まずは、その中核部分を次のプログラム例で示します。

Option Explicit
Dim Q(7,7), R(63), idx, yy, xx

idx = 0
For yy = 0 to 7
    For xx = 0 to 7
        Set Q(yy, xx) = R(idx)
        idx = idx + 1
    Next
Next

 この例での注意点は3つあります。配列変数の添え字は、0(ゼロ)スタートだということです。この例では、配列変数Qの各要素を表す添え字には0から7まで、配列変数Rの各要素を表す添え字には0から63までの値が使えます。また、便宜上、xy座標値を(縦y値,横x値)の順番で、かつ正の整数値をとりうるものとして表記しています。もう一つ注意することは、先頭アドレスが同一のメモリ領域をアクセスするのに、Q(7,7)とR(63)の二つの配列変数(あるいはメモリ領域)を確保するという点です。これはどいうことかと申しますと、配列変数Qには、Set文によって配列変数Rの各要素をポイントするアドレス値が入ります。すると、VBスクリプト上で、配列変数Qを使うと、配列変数Rの各要素を間接的に使えるようになります。すなわち、Q(0,0)とR(0)、Q(1,1)とR(9)、Q(3,2)とR(26)、Q(7、7)とR(63)などの要素は、VBスクリプト上では同じ要素の内容として扱えるということです。
 実体としては、配列変数Qには、配列変数Rの各要素をポイントしているアドレスがずらっと並んでいるだけです。アドレス値だけのテーブル、すなわち、ベクターテーブルみたいなものを、VBスクリプトのプログラムによって自前で作ってみたわけです。
 Qの配列要素(y、x)=Rの配列要素(y*8+x)
というふうに疑似的な数式で表現できる関係を、いちいちQからRへのyとxの変換値として計算することも、もちろんプログラム上では可能です。しかし、ゲームの盤面の操作のように、あちこちの処理でそうした計算の必要不要を検討していると、結局面倒なことになります。(少なくとも、それが面倒だと言うのが私の意見です。)
 さらに、これを具体的にDynamicHTMLでウィンドウ・オブジェクトとつなげて、縦横8x8のマス目の盤面を仮想的に作ってみましょう。

<SCRIPT language="VBScript">
Option Explicit

Sub Window_Onload
    Dim yy, xx, idx

    idx = 0
    For yy = 0 to 7
        For xx = 0 to 7
            Set R(idx) = Document.all.tags("SPAN")(idx)
            Set Q(yy, xx) = R(idx)
            idx = idx + 1
        Next
    Next
End Sub
</SCRIPT>

<BODY>
<DIV class=banmen >
<SPAN id=P00 ></SPAN> <SPAN id=P01 ></SPAN>
<SPAN id=P02 ></SPAN> <SPAN id=P03 ></SPAN>
<SPAN id=P04 ></SPAN> <SPAN id=P05 ></SPAN>
<SPAN id=P06 ></SPAN> <SPAN id=P07 ></SPAN><BR>

<SPAN id=P10 ></SPAN> <SPAN id=P11 ></SPAN>
<SPAN id=P12 ></SPAN> <SPAN id=P13 ></SPAN>
<SPAN id=P14 ></SPAN> <SPAN id=P15 ></SPAN>
<SPAN id=P16 ></SPAN> <SPAN id=P17 ></SPAN><BR>
    :
   (途中、省略)
    :
<SPAN id=P70 ></SPAN> <SPAN id=P71 ></SPAN>
<SPAN id=P72 ></SPAN> <SPAN id=P73 ></SPAN>
<SPAN id=P74 ></SPAN> <SPAN id=P75 ></SPAN>
<SPAN id=P76 ></SPAN> <SPAN id=P77 ></SPAN>

</DIV>
</BODY>

 Set R(idx) = Document.all.tags("SPAN")(idx)によって、配列変数Rがウィンドウ・オブジェクト(window.Document)の、SPANタグでくくられた各要素をポイントできるようにしています。実は、ここでは、配列変数Rもベクターテーブル化しているわけですが、VBスクリプト上ではそのことを意識しないで使うことができます。さらに、SPANタグにはID(識別子)も付いているため、すなわち、

Q(7,5).InnerText = "◯"
R(61).InnerText= "◯"
P75.InnerText ="◯" 

のそれぞれ3行、あるいは、

teban = Q(7,5).InnerText 
teban = R(61).InnerText
teban = P75.InnerText 

のそれぞれ3行は、プログラム上では同じ意味の操作となります。
 ちなみに、なぜ1つ1つのSPANタグに個別のID(識別子)を付けるのか、というのを説明します。64個のSPANタグに同じIDを付けて、例えば、

<SPAN=masu ></SPAN>
    :
   (途中、省略)
    :
<SPAN=masu ></SPAN>

としてみましょう。すると、Set Q(yy, xx) = masu(idx)という操作が必要となり、1次元配列変数Rは不要となります。にもかかわらず、そうしないのには理由があります。実は、盤面を人間の側がマウスのカーソルを移動したりクリックしたりするので、イベントドリブン型のプログラム(Document_OnclickとかDocument_OnmouseoverとかDocument_Onmouseoutなど)を記述する必要がありました。そのプログラム処理の中で、マウスのカーソルが動いた盤面マス目の位置とか、マウスがクリックされた盤面マス目の位置を知る必要があります。その際に、各SPANタグに個別のID(識別子)が付いていて、イベントが発生した盤面マス目の位置が個別にわかるようにしてあるわけです。現在の私のプログラミング・スキルでは、その程度の仕掛けを作るので精一杯というところです。もっといい方法もあるかもしれませんが、それは他の実力あるプログラマに任せることといたしましょう。
 もちろん、こうした技術全体は外国由来のものであり、私のしていることはオリジナリティに欠けることかもしれません。しかし、そうであったとしても、私がこうしたことに意欲を掻き立ててしまうことにはそれなりの理由があります。やはり、コンピュータという機械をプログラムというもので自前で動かしてみたいという、強い意欲があるからだと思います。

原点を学ぶことの重要性

 ただの思い出話になってしまうのは残念なことですが、私が大卒後に新入社員として、とあるソフトウェア開発会社に就職した頃の話をしたいと思います。
 今は亡き私の父親は自営業で溶接をやっていました。私は、長男でしたが、家業を継がずにサラリーマンとして会社勤めをする道を選びました。が、コンピュータのソフトウェア開発というものがどういうものか、職人気質の父に説明できるほどよくわかっていませんでした。すると、私の父は、「ソフトな衣服(ウェアの意味?)を買ってくれるお客を開発する仕事のことか?」と聞いてきました。私の父は、中卒だったので、その程度の知識や常識しかありませんでした。だから、子供に学歴や学力を付けさせたいと思っていたのかもしれません。
 その頃の私は、アルバイトで稼いだお金で買ったプログラマブル電卓でBASIC言語を覚えたり、学校の電子計算機実習でFORTRANを学んだりしていました。そうはしていたものの、コンピュータのソフトウェア開発についての、根本的な知識というものは全く知らなかったと思います。
 当時人材不足だった中小のソフトウェア開発会社では、理系大卒に限らず、あらゆる分野から人材を求めていました。また、当時の私は、文学部英文学科卒の予定でしたが、就職活動中の会社説明会でコンピュータへの興味をうまく吊り上げられてしまって、入社することとなりました。当社の取締役(50代)の人の説明では、全く技能や知識が無い人でも一から教えるよ、とのことでした。小中学生だってできるような仕事だよ、とまで言われました。それらの言葉を私も信じて、4月からの新人研修に参加しました。
 研修室の隣のガラス張りの部屋には、カードパンチャ―や、衣装箪笥の大きさのミニコンピュータ(ミニコン)が置いてありました。そのミニコンには、プリント出力兼用入出力コンソールやカードリーダ(紙のカードから入力データを高速で読み取る機械)がケーブルでつながっていました。それを見て、私は、この会社がこれまでは大型コンピュータやミニコンのソフトウェア開発の業務を請け負ってきたということを知りました。後に私は、小型応用システム部という部署に配属されましたが、そこで初めてマイクロコンピュータマイコン)のソフトウェア開発が当時始まりつつあることを知りました。現在は、ワークステーションからパソコンや組み込み家電まで、マイクロコンピュータの全盛期になっています。しかし、当時は、まだそれほどでもなかったので、ミニコンピュータアセンブリ言語で動かすのが、新入社員の教育には適材だったのだと思います。
 私を含む20人余りの新入社員たちのほとんどは、コンピュータのソフトウェア開発はおろか、プログラムを組むのに使うアセンブリ言語にさえ無知でした。電子専門学校卒の人もいましたが、彼らが学校で習得したマイコンを操作する技能とも少し違っていたようです。新入社員たちにプログラム作成の講師となった人は、当社で営業を担当していた40代の人でした。
 その人は、カードリーダに読み込むデータとプログラムをある程度用意されていました。それを教えつつ、残りの足りない部分を新入社員たちに考えさせて作らせるという教材でした。研修室の隣の部屋に衣装箪笥のように置いてあるミニコンアセンブリ言語を一通り教えた後、白板上で四角く囲った領域を、メモリ上にあるAさんの個人情報と見立てて、それをプログラムでどういうふうに持ってきたらいいかという問題を出されました。
 この問題を、新入社員たちは誰も解答することは出来ませんでした。そこで、ヒントが出たのですが、誰も正解を出せませんでした。さっき教えたアセンブリ言語の中のたった一つの命令だけでそれが可能だとおっしゃられました。いくら考えても答えが出てきません。新入社員の誰もが、そのような時間を長く感じていたはずです。
 実は、当社のその営業部長の人は、元は某大企業メーカーの大型コンピュータの技術者だったのだそうです。新入社員の誰もが、そのことを知りませんでした。それで、彼が当社の営業担当で、口調がおだやかな教育係というイメージだったので、内心では彼の実力をなめていたようです。「こんなのわかんないのかなあ。簡単だよ。」などと言われても、どうしても正解にたどりつけませんでした。
 問題が出てから10分も経たないうちに、その営業部長さんは白板に「LDA $Inf」などと書いて説明を始められました。「Aさんの個人情報は、メモリ上にひとまとめにしてあるので、そのメモリの先頭アドレスをコンピュータのレジスタに読み込んでしまえば、Aさんの個人情報全部を引っぱり出すことができるんだよ。」つまり、$Infが、Aさんの個人情報のメモリ上の先頭アドレスを表すオペランド(番地アドレス)であり、その値をCPUのレジスタ・メモリに入れる命令コード(オペコード)が、LDAというニーモニックの(このミニコン特有の)アセンブリ言語だというわけです。
 この講義を聞いて、新入社員たちのほとんどは、「なんだ。こんなに簡単な答えだったのか。大したことないや。」と思ったはずです。その一人だった私も、「これまでの人生で出会ったこともない知識だったので、正答できなくて当たり前だな。でも、知らなくて悔しいな。」と思いました。
 以上が私の思い出話なのですが、その営業部長さんが新入社員教育で教えて下さったコンピュータのIT技術(インフォメーション・テクノロジー)のアドレスに関するささいなことが、なぜか私には忘れることができません。日本国民のほとんどがそう考えると思いますが、こんなこと知っていたって全くお金にならないじゃないか、というのが一般的な考えであり、正論だと思います。一銭にもならないということに私も異論はありません。しかしながら、私の個人的な教養としては、何にも代えられない宝と考えています。
 なぜならば、私の頭の中では、「『必要とする情報の先頭アドレス』を引っぱり出して来る」というコンピュータの操作一つで、インターネットも、QRコードも、オブジェクト指向も、コンピュータのあらゆるソフトウェア技術が理解あるいは説明できてしまうからです。もし仮に私が十分に若かったら、今ごろハッカーになって悪いことをしているか、あるいは、ホワイトナイトになって善行を重ねているかもしれません。私の考えでは、あの頃に学んだ上記のエピソードこそが、コンピュータのソフトウェア開発における最重要点であり、かつ、原点(あるいは基準点)であったと思われます。
 私たちの生きている日本が、技術立国の地位を世界的に失墜しつつあることは、残念なことです。しかし、その現状を分析してみると、いかなる技術においても、その原点(あるいは基準点)となるものが、その技術自体に感じられないことが多いと思います。つまり、科学的な技術やその応用が、一体何を軸として、何を原点(あるいは基準点)として成り立っているかが見えづらくなっていると思うのです。それを見つけてくれるのは、今やほとんどの場合が外国人であり、日本人はそうした外国人の評価ばかり気にしているように見えます。せめて、日本人自らが、自らの科学的技術を独自に評価して、自らそのことに自信を持てるようになれないかとも思います。そのようになったほうが、ずっと良いと思います。

私が刑事ドラマを好む理由

 私が子供の頃からテレビで観ている番組で、今もよく観ているのは刑事ドラマです。『相棒』シリーズや『科捜研の女』シリーズを始めとして、1クールの連続ドラマは数知れず観ていると思います。かつての2時間ドラマも、その大多数は刑事ドラマのタッチで描かれていたと言えるかもしれません。

 小中学生の頃の私は、桜木健一さん主演の『刑事くん』とか、大川橋蔵さん主演の『銭形平次』とかをよくテレビで観ていました。前者は、熱血根性青春ものでした。一方、後者は、時代劇ものでしたが、推理ものでアクションものでもあったと思います。中学時代に友人の勧めで『刑事コロンボ』なども観ていました。目立った格闘アクション無しで、相手との話し合いだけで犯人を追いつめて自供させるところが、かえって新鮮でした。他にも『Gメン’75』や『太陽にほえろ』なども、よく観ていました。

 最近では、再放送を含めて『相棒』シリーズが、面白くかつ観てためになるようです。これまで私が観てきた刑事ドラマには、共通のパターンというものがありました。ドラマのラストシーンあるいはその前のシーンで、犯人あるいは容疑者が必ず正直になって素直に自白をして、全ての真相が明らかになる。という筋書きのパターンです。もしも、刑事ドラマにそれが無いと、視聴者はモヤモヤしてしまいます。そうさせないために、ラストシーンあるいはその前のシーンで、犯人が素直に自白をして、事件の真相を明らかにするのです。

 実は、このことには一長一短があると私は思います。殺人事件の場合、「死人に口なし。」と一般に言われるように、その真相をまじかに知っているのは、犯人あるいは容疑者と呼ばれる人です。その人が、素直になって自白をするのですから、これほど説得力のあるシーンは他には無いわけです。多少その場が不自然であっても、犯人または容疑者の自白シーンが必ずドラマのラストシーンに付いてきます。だから、視聴者はそれを目撃して、気持ちがスッキリとするのです。

 しかし、このことは、意外な副作用を生み出しているとも考えられます。つまり、犯人や容疑者(すなわち加害者)の自白や謝罪や反省などが、事件の真相とイコールだと、テレビドラマの視聴者に見なされてしまうことです。このことは、私たちの現実の世界に少なからぬ影響を与えています。加害者が事件の真相を語るとは、加害者自らが反省や謝罪、あるいは自白をすることだと、それを意味することだと、私たちの多くは勝手に思ってしまっています。

 それは実際には、私たちが被害者の側に立って、あるいは、被害者の気持ちに寄り添い、被害者に味方しているだけなのかもしれません。もちろん、そのことは道義的に正しいことです。けれども、本当に物事を公平に見ているのか、という点では、いささか疑問があります。私たちは、ある種の日常的な不安から、大衆心理に流されて、「それほどでもないこと」を「ことのほか危険で、重篤なこと」と見なしているのかもしれません。

 今までの視点を変えてみればわかることです。あらゆる物事の『真相』とは、実際に起こった「一つ一つの事実の積み重ね」に過ぎません。そこに、意見や感情が入り込めば、真実は歪んでしまいます。どんなに私たちが学習して、成長して、生き物として進化したとしても、正解の見つからない問題に答えることはできないのかもしれません。

 かつて、私は『天使と悪魔』という刑事ドラマを夜中のテレビ番組で観ていました。それは、これまでの日本で禁じられてきた司法取引をひそかに行っていると疑いをかけられている刑事の話でした。確かに、司法取引すれすれのことをやって、加害者の自白をもとに、本当の容疑者を見つけ出すというストーリーは、スリルがあって、視聴者の側(私)からすると面白い内容でした。

 しかし、冷静になって考えてみると、どこからどこまでが犯罪なのか、どこからどこまでを容疑者とすべきなのか、あるいは、どこからどこまでが被害者と仲直りをするべきなのか、どこからどこまでの容疑者が社会的制裁を受けるべきなのか、などといった疑問がわいてきました。刑事ドラマというフィクションの世界では、こうした問題があっても何の問題もなく成立します。けれども、私たちが日常生活を営んでいる現実の世界では、私たち一人一人の私的な市民感情と、行政・司法などの公的機関や組織の判断が必ずしも一致するとは限らないのです。

 そのようなことから考えてみると、昨今の刑事ドラマの一つである『相棒』シリーズの杉下右京さんは、興味深いキャラクターと言えましょう。彼の凄いところは、警察官としての職務を忠実に果たしつつ、大衆心理に流されることなく、必ず真相を明らかにしようとするところです。もちろん、容疑者を明らかにするところは、探偵並みの手腕があると言えます。しかし、彼が優れているのは、容疑者をあげるという捕物的な趣味ではありません。それよりも、事実の真相を明らかにすることに長(た)けていることにあります。感情的に事実関係を曲げることが無く、真相を一つ一つの事実の積み重ねとして矛盾なく捉えるということです。(その結論として、容疑者がしらを切ると、彼は激高します。彼を一人の人間としてみれば、それは当然かもしれません。)

  もちろん、私は刑事ではありませんし、刑事になった経験もありません。でも、こうした刑事ドラマの背景にあるものを、テレビを観ながら考えることはあります。法と個人の関係とか、市民感情と個人の関係とかを考え、ニュースなどの報道番組や情報番組で知ることのできた現実の問題を考える際に利用したりしているのです。たとえば、隣国のK国の市民感情を私たち日本人は理解できないことがあります。しかし、彼らと同じように大衆心理で感情的に流されてしまうことは、私たち日本人にも(市民レベルで)あるようです。ただし、それは世の中がグローバル化しているからではなくて、グローバル化する以前からあったことのように思えます。

 また、別の例を示しましょう。最近、児童虐待で女児が死亡する事件があって、傷害罪で逮捕された父親が「しつけのためだった。」と自供したとのニュースを知りました。私は、このニュースを聞いて、まず「その父親がウソをついていて、その『しつけ』という言葉は、自身を正当化するための言いわけに過ぎない。」と考えていました。けれども、この私の考え方には、事実を歪めてしまうおそれがあることに、今になって気がつきました。

 この『しつけ』という言葉は、子を持つ親ならば誰でも考えて、誰でも言う普通の言葉だったのです。つまり、その父親は、親としては当たり前の答弁をしただけのことなのです。結果として、娘を死なせてしまったとはいえ、私たちが敵意を抱くほどの人物ではないと思います。しかし、私たちは、私たち自身の心の奧で、なぜかその父親に恐怖の念を抱いてしまいます。なぜか、その父親を忌み嫌い排除したく思って、その言動を認めたくないと思うのです。

 要するに、私は、私自身の心の中に、どうしようもない敵を見い出しました。冷静に考えましょう。親が子にしつけを怠り、その子供が大人になって何らかの加害者になったらば、一体だれが責任を取るのでしょうか。児童相談所はそこまで責任が取れるのでしょうか。それとも、私たちの社会全体が全ての責任を負うべきなのでしょうか。そうした疑問に答えるためには、子供に対する親のしつけは義務であり、その責任は一番に親にあると考えなければなりません。それを第三者がいちいち口出しすることはできないと思うのです。

 命を落としてしまったあの女の子は、本当にかわいそうだと思います。できれば救ってあげたいと、誰もが思ったことでしょう。しかし、この一点にとらわれて、私たちの社会のシステムが改悪の方向に進むとしたならば、一体誰が報われ救われると言えるでしょうか。私たちは、そこのところを慎重に検討する必要があります。

 今回のように、我が子を死に至らしめた場合は、個別の案件として、その父親と母親はその罪を償うべきだと考えられます。彼ら二人の大人としての責任は、社会的な不安を大きくしただけに重いと考えられます。

 以上、今回も私自身の戯言(たわごと)になってしまいましたが、私なりに考えたことを書いてみました。こうした問題には、人それぞれ考えがあるものです。それでいいと思うのです。だから、答えの見つからない問題を前にしてひるまないことが、誰でも本当は一番大事なことなのかもしれません。それこそが、大人が、これから生きていく若者や子供たちに示していける唯一のお手本なのかもしれません。

 そしてまた、私は、そういったネタ探しに、今でも刑事ドラマを好んで観ているのかもしれません。

 

雨ニモマケナイ方法?

 今回は、日常生活の重要課題を、恥も外聞もなく考えてみたいと思います。私は、10数年前から、稲を栽培してお米を作っているのですが、どうもその食べ方に疑問を持っていました。

 私は、特にお米が好きだというわけではありませんでした。白米あるいは玄米だけでは食べられないタイプの人間でした。かと言って、おかず中心の現代の食卓にも、満足がいっていません。東京で生まれ育った人間のくせに、味が濃い食べ物が苦手なのです。そういう食べ物は、炊いた白米と一緒に食べると、胃腸の消化に負担がかからないと思うのです。

 かつて、日本人の食卓は、炊いた白米が中心の食卓でした。おかずよりも何よりも、炊いた白米=ご飯が量的にも多かったわけです。その食事を摂ることそのものを、「ご飯を食べる」と表現するくらいでした。しかし、現代では、その『ご飯』よりも『おかず』を沢山食べるよう、一般的な指導がされています。『ご飯』を食べ過ぎると太る原因になる、と一般的に指摘されています。ご飯の食べ過ぎによるカロリーの摂り過ぎは、現代の私たちの健康的なライフスタイルを脅かす一因とさえなっています。

 ここ数年のことですが、私は、自身の日常の食生活を振り返ってみることにしました。ここのところの私は、自炊が続いています。ただし、毎日3食それを続けていると、仕事などの時間が十分に取れません。そんな時は、地元のスーパーで惣菜パンを買って済ましてしまうこともあります。けれども、そればかりだと、お金が続きません。それで、スーパーで惣菜を買うのですが、それさえお金がもったいないと思って、スーパーでおかずの材料を買うことになります。しかしながら、おかず中心の食事を毎日準備していると、仕事などの時間に影響が出てきます。結局、そんな堂々巡りとなってしまうわけです。

 そんな私の日常生活において、持続可能な妙案がないかと思っていました。和食の基本である一汁三菜を真似てみようかと思いました。あるいは、ずぼら飯にしようかと模索してみました。結局、お金や時間の手間がかからない方法を模索することとなりました。

 そこで、ふと、私は中学一年生の国語の時間に暗唱させられたことのある詩の一節を思い出しました。

 一日ニ玄米四合ト、味噌ト少シノ野菜ヲタベ

という、宮沢賢治さんの『雨ニモマケズ』の一節です。「そうだ。小さな茶碗に、一口ばかりのご飯を盛って、味噌の小さな塊をのせて、さらに、その時期にある野菜を刻んでのせればいいのだ。」と、私は思いつきました。

 野菜は、最低限、夏や秋ならばキュウリが手に入るし、春や冬ならばネギや大根が買えるので、問題ありません。味噌も、スーパーで買える安いもので問題なさそうです。そこで、実際にやってみると、ご飯さえ炊けていれば、食べたいと思ってからほんの2、3分で、食べる準備ができてしまうことがわかりました。

 これは、なかなか便利な方法です。その時間に家にさえいれば、朝に軽い食事ができたり、間食のおやつ替わりにちょっと食べてみたりするので、おにぎりを作るよりも楽です。手軽にお米を食べられる方法の一つとして、良いかもしれません。(以上、あくまでも私の個人的な意見です。ちゃんとご飯を食べたい人には、物足りないかもしれません。従って、このようなご飯の食べ方を私がお勧めしているわけではありません。)

 

『ありがとう』の不可解と大切さについて

 東京生まれで東京育ちの私は、子供の頃に長野県の母の実家へ行くたびに、ハテナ?と思うことがありました。ただし、当時は、東京に戻るとそのことを忘れてしまいました。すなわち、そのことをそれほど重大視してはいなかったのです。それをそれほど疑問に思わずにいてしまったというわけです。

 それは、どんなことだったのかと申しますと、私の母の親族の人たちから話しかけられる、ある言葉があまりに多かったので、その言葉をどう理解していいのか、また、どう言葉を返していいのか判断ができませんでした。結局、その言葉を言われるたびに、都会育ちの私はおし黙ってしまい、困惑していました。

 彼らは、事ある毎に「ありがとう」という言葉を言ってくるのです。ところが、それが私の何に対する「ありがとう」なのか、つまり、私の何に感謝してそう言ってくるのか、どうしてもわかりませんでした。しかも、その理由を私の側から聞こうとすることは、恥ずかしい気がしました。だから、彼らの誰にもそのことを聞くことができませんでした。

 私の母は、と申しますと、そのことを疑問に思っている様子もなく、本人の実家に帰っても、それほど「ありがとう」という言葉を口のしていなかったようです。私の母にしてみれば、そうした感謝の言葉を改まって言うこともない位、都会慣れした調子が普通だったのでしょう。

  私は(おそらく、私の母も)思っていたのですが、余りそうした「ありがとう」という言葉を日常的に口にしていると、他人から「人が好(よ)い」とか「お人好しだ」とか言われて馬鹿にされると考えていました。だから、生まれも育ちも都会だった私は、「ありがとう」という言葉が言いにくくて、代わりに「どうも…」としばしば口ごもっていました。そのため、相手に感謝の気持ちを十分に伝えることができませんでした。長野県の地元の人たちからしたら、都会の人間は素直に気持ちを表せない、何を考えているのかわからない、その心が冷たく感じられたことでしょう。

 このことは、田舎の考え方と都会の考え方が違っていたという、まさに一つの好い例でした。だから、あえて私も、彼らに何について感謝しているのかを問いたださなかったのです。もちろん、そのような考え方は都会的だったと言えましょう。

 しかし、今になって考えてみると、長野県で生まれ育った人たちが、特別に人が好(よ)かったか、あるいは、『お人好し』だったかと言えば、そうではなかったと思います。本当は、長野県人は『お人好し』ではなかったのです。特に現在でははっきりしていますが、そう思われたのは都会的な風評の一種だったようです。

 当時の彼らが、どうして「ありがとう」を日常的に多用していたのかを、考えてみることにしました。すると、私は、現代的な一つの考え方、あるいは、一つの見方にたどり着くことができました。要するに、この「ありがとう」という言葉は、人と人とのコミュニケーション・ツールの一つだったのです。お互い相手と構えずに、気軽に会話できるようにするためのツール(道具)としての言葉でした。

 今でもそうですが、長野県人は、ひと言多かったり、余計なことを話しすぎます。それで、他県の人たちを傷つけて嫌われることも少なくないようです。だから、この言葉を多用することによって、お互いに相手と構えずに、なるべく気軽に話し合いを進める必要があったと言えます。言い換えれば、ギスギスした人間関係を少しでも緩和するために、この言葉は彼らに多用されていた、と私には思われました。

 確かに、「ありがとう(ございます)」という言葉は、そう簡単に手軽に口に出すことはできないかもしれません。何度も口に出すには、やっぱり言葉が長すぎます。言いにくいかもしれません。しかし、昨今の都会の風潮を考えると、他人に感謝をすることよりも、他人を批判することのほうが、ずっと楽に思われている節があります。人間関係がギスギスして、その中から派生するのが、働きづらさであったり、生活しづらさであったり、生きづらさであったりするわけです。

 そんな時に、話す相手とのトゲトゲした関係を緩和させることは大切です。それは、何としても必要な作業と言えます。そのために、まず、何らかの感謝の気持ちをハッキリとした言葉で相手に伝えられたら、良いと言えましょう。そのための、お互いの間の好(よ)い印象づくりに「ありがとう」という言葉が使えるということは、(都会的な視点で見てみても)意外と大切なことなのかもしれません。

 

 

 

ダイアリーからブログへ移行する

 書いてみたいことはいろいろあるものの、ここ一年ほど身近な現実世界で活動しなければならないことが多くて困っています。私も体が一つなので、どうしても優先順位が、身近で現実的なことに向いてしまいました。
 そうこうしているうちに、この『はてな』のサイトで、ダイアリーが終了して、これまでの記事はブログの方へ移行するか、あるいは、削除する必要があることを、最近のEメールで知りました。
 まずは、ネット上のダイアリーとして公開していない、いわゆる『記事の下書き』は、私自身の勝手な判断で全て削除しました。ダイアリーからブログへ自動移行されたとしても、その下書きは移行しないようです。最近の私自身はそれを見返す余裕がなさそうなので、また新たな下書きを作ればいいやと軽く考えて、削除することにしました。
 そうした自動移行を当てにしても良いのですが、私自身が手動でやってみるのも面白そうです。だから、そう考えて、その移行だけでもやり方をいろいろ調べて、私自身でやってみることにしました。
 そして今回、ダイアリーからブログへ移行しても、少し時間に余裕ができてきたら、また私自身の楽しみの一つとして、何らかの文章やら記事やらを書いてみようと思います。