ラベル 人間の思考特性 の投稿を表示しています。 すべての投稿を表示
ラベル 人間の思考特性 の投稿を表示しています。 すべての投稿を表示

2010-04-24

ひとりでは学食に入れないという若者が増えている

今週はもうひとつ映像コンテンツの感想を書こうと思う。NHK で4月23日(金)19:30に放送された特報首都圏「“ひとり”が恐い」というテレビ番組を電車の中でラジオで聞いた。


ゲスト : 土井隆義
キャスター : 中野純一
ひとりでは学食に入れないという若者が増えている。なかにはトイレで食事をすませる学生もいる。背景には、周囲から友だちがいないさびしい人間だと思われたくない心理が働いている。専門家は、携帯メールで24時間常に維持される友人関係が、自己肯定感の大部分を占めるようになったと分析。大学では、友だち以外の分野で自分の居場所を持てるように、さまざまな取り組みを始めている。“ひとり”が怖いという若者の姿を伝える。
簡単に解説すると、学食でひとりで食べていることを見られることで、「あいつは友達がいないんだ」と思われることがイヤなので、そう思われるくらいなら歩きながらパンを食べたりトイレでささっと空腹を満たす方がいいとということなのだ。

「それほどまでに他人の目を気にするなんて」と思った人は、現代の若者達のコミュニケーションの方法について理解が足りていない。そうなる原因は携帯電話によるコミュニケーションの変化にある。

ようするに、現代の社会人になる前の若者達はメールで連絡を取り合うことで友達との連帯感を確保している。24時間「レス」できるようにしておくことが友達としての証であり、それができないと友達との距離が生まれる。

番組ではアドレス帳が500件までしか登録できないので700件まで登録できる携帯に買い換えた女子大生が出ていた。携帯電話のアドレス帳が友達の範囲であるような印象を感じる。

嘉悦大学では大学の入学式の前に新入生を集め大学構内を二人ひと組で回り、教授やサークルの先輩を訪ねるオリエンテーションゲームを行い、新入生の心のハードルを下げることに成功しているとのことだった。

冒頭に紹介したひとりで学食で食べられない学生に対して一緒に食事をしてくれるカウンセラーがいる大学もあるとのこと。(そうしないと辞めてしまう学生が後を絶たないのだとか)

もしも、自分が学生時代に携帯電話があったら確実に今の若者と同じ事をしていると思った。その環境があればもっとコミュニケーションが多くなって活動の範囲が広がったのではないかとも感じる。

ただ、その環境がなかったことでよかったのは一人で考えを巡らす時間が十分すぎるほどあったということだと思う。大学から離れた時にはたっぷりと一人の時間があった。

番組では携帯メールによる広くうすい四六時中つながっている状態の友達関係は若者の自立を疎外する傾向があるという。「自分は自分、他人は他人」という自己の確立が遅れるというのだ。

昔は、中学→高校→大学→社会人という流れの中で自己の確立が強まっていくのだが、携帯電話によるコミュニケーションにより、中学生レベルの自立にしかなっていないらしい。

twitter も24時間見ていてつぶやかないと疎外されるような感覚を持つようになると同様の問題が起きる可能性がある。

ちなみに、こういう時代になってしまった以上、パソコンや携帯電話が悪でありそれを排除すれば問題は解決すると考えるのはムリがあると思っている。なぜなら、これらのアイテムによるメリットもあるし、現実的に排除などできないからだ。

インフラの変化やコミュケーション手段の変化をキチンととらえて、それらのメリット、デメリットを把握しながら、どう向き合えばいいのかを考えていく必要があると思った。

2010-03-20

和製ピープルウエア

今回リリースした本『リコールを起こさないソフトウェアのつくり方』が、和製ピープルウエアなどというと見識者から「何を思い上がっているのか」と怒られそうだが自分自身はそう思っている。

今回はなぜ、そう思っているのかについて書いてみたい。

ピープルウエア』(原著:Peopleware: Productive Projects and Teams)はトム・デマルコ と ティモシー・リスターが1987年(23年前)に書いた名著で、今でも多くのソフトウェア技術者に読み継がれている。『ソフトウェア開発の名著を読む 【第二版】』の中でも紹介されている。

トム・デマルコは、構造化分析手法の考案者としても有名だ。 『ピープルウエア』が他のソフトウェア系の書籍と一線を画しているのは、ソフトウェアに焦点を当てるのではなく、ソフトウェアを作る人に焦点を当てていることにある。

最近でこそ、コーチング理論やメンタルヘルスなど、ヒューマンリソースのケアが重要視されているが、1980代当時、開発者のやる気や、生産性の高い作業環境、チームビルディングの重要性を正面から論じた本はほとんどなかった。

さて、そもそも自分の卒論のテーマは「脳神経系のシミュレーションモデルの作製と検証」だった。今から冷静に振り返ると、このテーマは高校生の時代に読んだ日本の脳科学者の草分けである東京大学医学部教授/京都大学霊長類研究所教授の時実利彦先生の本「脳の話」に感化され、これもまた脳神経科学者の井上馨先生の『脳の情報処理』で紹介されていたモデルをシミュレーシ実験で再現しただけの研究だったのかもしれない。大学生の卒業論文としてはそれくらいが精一杯だった。ただ、当時の自分としては人間の思考回路とコンピュータの情報処理の方法について探求心をもって調べていたので、このこと自体はよかったと思う。

このときの研究内容をベースにした読み物については 『Software People Best Selection』の記事 「人間の考え方,コンピュータの考え方」p226-p234に掲載している。

そんなこともあってコンピュータの合理性、論理性と人間の非論理性の違い、その狭間にいて時に苦しむソフトウェアエンジニアの立場について常に考えてきたし、自分自身も20代、働き盛りのころ人間の思考や行動もコンピュータと同じように論理的に分析すれば分かるなどと考え、現実はそうではなく、その結果人間不信となり精神的に苦しんだ時期もあった。その後、カウンセリングを受けたり心理学を学んだり、河合隼雄さんの本(お気に入りの本は『こころの処方箋』)を買い込んで読みふけり、そもそも人間は臨床的にはまったく論理的ではないことを理解した。(トム・デマルコが JaSST'04 で来日したとき、基調講演の後の質問コーナーで三十代最後の自分が「ソフトウェアエンジニアがカウンセリングを受けるのはアメリカではふつうのことか」などという突飛な質問をしたことを覚えている。トム・デマルコならきっと分かってくれると思ったのだろう。)

しかし、卒論でコンピュータと人間の脳の情報処理の方法がまったく違うことを研究していたにも関わらずソフトウェアエンジニアとしてバリバリ仕事をしていてうまくいけばいくほど、自分はコンピュータも人間も論理的であると勘違いしていた。そうじゃないっていうことを研究していたのに、自分自身のことに置き換えることができていなかった。だからこそ、人間の脳は論理的でないといえるのだ。

こころの処方箋-こころの中の勝負は51対49のことが多い- より】
中学生や高校生のなかには、私のところに無理矢理に連れられてくる生徒がいる。たとえば、登校拒否の子など、心理療法家のところなど行っても仕方ないとか、行くのは絶対嫌だと言っているのに、親や先生などが時にはひっつかまえてくるような様子で連れて来られる。嫌と思っているのをそんなに無理に連れてきても仕方がないようだが、あんがいそうでもないところが不思議なのである。

あるとき、無理に連れてこられた高校生で、椅子を後ろに向け、私に背を向けて座った子が居た。このようなときには、われわれはむしろ、やりやすい子がきたと思う。こんな子は会うやいなや、「お前なんかに話しをするものか」と対話を開始してくれている。そこで、それに応じて、こちらも「これはこれは、僕とは話す気が全然ないらしいね」などと言うと、振り向いて、「当たり前やないか。こんなことしやがって、うちの親父はけしからん・・・」という具合に、ちゃんと対話がはずんでゆくのである。

こんなときに私が落ち着いていられるのは、心のなかのことは、だいたい51対49くらいのところで勝負がついていることが多いと思っているからである。この高校生にしても、カウンセラーのところなど行くものか、という気持ちの反面、ひょっとしてカウンセラーという人が自分の苦しみをわかってくれるかも知れないと思っているのだ。人の助けなど借りるものか、という気持ちと、藁にすがってでも助かりたい、という気持ちが共存している。しかし、ものごとをどちらかに決める場合は、その相反する気持ちの間で勝負が決まり、「助けを借りない」という方が勝つと、それだけが前面に出てきて主張される。しかし、その実はその反対の傾向が潜在していて、それは、51対49と言いたいほどのきわどい差であることが多い。

51対49というと僅かな差である。しかし、多くの場合、底の方の対立は無意識のなかに沈んでしまい、意識されるところでは、2対0の勝負のように感じられている。サッカーの勝負だと、2対0なら完勝である。従って、意識的には片方が非常に強く主張されるのだが、その実はそれほど一方的ではないのである。
このあたりの感じがつかめてくると、「お前なんかに話しをするものか」などと言われたりしても、あんがい落ち着いていられるのである。じっくり構えていると、どんなことが生じてくるか、まだまだ分からないのである。
【引用終わり】

人間の脳神経の情報処理の仕組みはコンピュータとはまったく違うし、その素子の数が非常に多い(140億以上といわれている)し、人体実験するわけにはいかないから、情報処理システムとしての構造、動作についてはまだ十分に解明できていない。

ジェフ・ホーキンスは Palm ComputingとHandspring の創設者で Palm OS の開発者で、その後、神経科学の研修者となりレッドウッド神経科学研究所を設立した脳科学研究者である。そのジェフ・ホーキンスが『考える脳 考えるコンピューター』で最先端の脳の情報処理の仕組みを記している。(Palm Computing 社でビジネス的に成功を収めたのにそれをすべて捨てて研究者となったところがすごい)

この本を読むと脳神経学の積み上げによって、実際に人間の脳の中で起こっていることを科学的に解明するのがいかに難しいかがわかる。でも、ジェフ・ホーキンスは脳神経学と臨床心理学の間を埋めるべく、仮説と論証と積み重ねてそのしくみについて分析をしており納得のいく内容になっている。

そんなこんなで、自分の中ではソフトウェアの論理性とそのソフトウェアを日々作っている人間の非論理性を常に意識しているつもりだ。そして、自分自身がプロジェクトの中で、もしくはプロジェクトリーダーとして振る舞うのではなく、他人のソフトウェアプロジェクトを支援する立場になって、さらに「人間の脳が論理的ではない」という問題・現実を認識しながら行動しアドバイスしなければいけないことを痛感している。

そして、そこで培った体験を踏まえつつ抽象化され責任と権限が明確な世界で体系化されてきたソフトウェア工学を日本のソフトウェアプロジェクトでどう適用していくべきかについて書いた。だからこそ本人としては『リコールを起こさないソフトウェアのつくり方』は和製ピープルウエアの“つもり”なのだ。

リコールを起こさないソフトウェアのつくり方』では、もちろんソフトウェアの安全や信頼を実現する方法論についてもきちんと書いているが、それ以上に方法論に乗っかるだけでは安全や信頼を確保することはできないということも切々と語っている。

そう言い切れるのは自分が人間の脳神経系のしくみについて過去の研究者の研究成果を読んでいるからだと思っている。どうしてもこのようなテーマは比較文化論的な切り口になってしまうが、できるだけ客観的に議論するための資料も掲載しているので、このような背景を理解しながら読んでいただくと著者の意図が伝わると思う。

2008-01-10

組込みソフトエンジニアの心理

組込みソフトプロジェクトにおける未熟な組織では、試行錯誤でシステムを作り上げてしまう。ここで、未熟といっているのは、先人の成功や失敗の経験を体系化したソフトウェア工学を使わず、かといって自分たちの成功や失敗の経験も体系化せず、ただその組織、その製品開発に長く携わっているだけで組織的な取り組みが十分にできていない状態のことを言っている。

20年、30年前の組込みソフトウェア開発では、ハードウェア、ソフトウェアの区別もなく、ソフトウェアはハードウェアを動かすためのシーケンス処理の記述でしかなかった。このころプログラムの規模は1000行にもなっておらず、試行錯誤でソフトウェアを作ってもランダムテストでバグを潰し切れた。開発の時間的な余裕もあったし、どちらかといえばソフトウェア開発は技術者の個人的な取り組みだった。

このようなソフトウェア開発のアプローチで成長した技術者が20年たってマネージャクラスになるとどうなるか。

<失敗や成功の体験を取り込んだり、体系化したことのないマネージャの特徴と思考>
  • ソフトウェア規模が小さい頃の成功体験、失敗体験でしかマネージメントできない
  • 分析してから設計しない
  • 直せと言われてたら、開発の後工程でもすぐに直してしまう
  • 要するに工程(プロセス)の概念がない
  • ソフトウェアの検証は作り込んだ後のランダムテストでやるものだ
  • 設計ドキュメント作りは余計な作業だ(設計ドキュメントを再利用したことがない)
  • ソフトウェアの再利用は過去のソースコードの適当な部分をコピー&ペーストすることだ
  • 金を払っているのだからどんな問題でも協力会社の技術者が解決すべきだ
こんなマネージャ、リーダーが全部ではないと思うが、ソフトウェア開発に対して組織的な取り組みを行っていない未熟な組織であればあるほどその比率は高いと思う。こんなマネージャ、リーダーを生み出さないようにするにはどうすればよいのか。悪いマネージャを作らない教育は上記の項目を逆に書けばできあがる。

<組込みソフトプロジェクトでダメダメマネージャを生み出さない教育>
  • 先人の成功体験、失敗体験が体系されたもの(ソフトウェア工学、自組織の体験)を教える
  • 分析してから設計することを教える
  • 開発の後工程での修正はコストがかかることを教える
  • ソフトウェア開発の工程(プロセス)の概念とその必要性を教える
  • ソフトウェアの検証に対する考え方と種別と効果について教える
  • 設計ドキュメントはどの場面でどのように使うものか教える
  • ソフトウェアの再利用戦略について教える
  • ソフトウェア品質マネージメントにおける発注と検収について教える
学校でも企業内でもこのような教育が十分に行われないで時間だけがただ過ぎていくとどんな組込みソフトウェアプロジェクトになるか考えるというのが今回のテーマである。

こんな状態で組込みソフトウェアに対する要求が複雑化し、ソフトウェアの規模が大きくなってくると、末端のエンジニアの作業工数がかさんでくる。その工数増加の分布は開発が終盤になればなるほど大きくなる。ただ、製品をリリースしたあとも後始末の工数があるため、次期製品の開発が始まった時期でも前の製品の保守に時間を割いていたりする。その結果、余裕を持って分析設計が行う時間がとれない。だからまた次の開発の終盤で苦労する。ようするに悪循環の構図だ。(『組込みソフト開発悪循環の構図』参照のこと)

そんな悪循環の中で、技術者個人が一番痛い目に遭っていて何とかしたいと考えるのが、よかれと思って修正したところが、別の問題を起こしたり今まで動いていたところが動かなくなったりするケースだ。この問題は個人に閉じている問題であり、また、プロジェクト全体に迷惑をかける問題でもある。バグの修正でデグレードしてしまうのはエンジニア個人にとって痛いし、プロジェクトにも迷惑をかけるので精神的にも負担が増える。簡単に言えばこれをやると個人的に痛みを感じる。

一度やるとイヤな記憶に残るので次は同じ目に遭いたくないと考える。そうなると最初に考えるのが何かしでかしてしまったときは、うまくいった状態に確実に戻せるようにしておきたいという心理だ。ようするに、ソフトウェアの構成管理をきちんとやろうということだ。

だから、組織にソフトウェア構成管理の取り組みを導入しようとするとき、現場に反発されることはほとんどない。すでに自分たちが行っている構成管理の方法やツールを変えるのはいやがることがあるが、ソフトウェア構成管理を行うこと自体に反対することはない。

なぜなら、バグの修正でデグレードしてしまう痛い経験をエンジニア個人が必ず一回はやっているから、その痛みを解消できるのなら多少の不自由があっても我慢できるのだ。

そして、次に考えるのがなぜ変更したのか、どんな変更を加えたのかを管理・記録することだ。バグ票を記入したり、データベースに登録したりして変更を管理する。

開発の規模が大きくなると日々バグが発生するので、次々と発生するバグや対応状況を記憶しきれなくなる。何かに記録しておかなければ分からなくなってしまう。構成管理の次は変更管理に取り組む。

テスト技術は個人でも修得できる部分が多い。だから、組織的に取り組まなくても技術者個人で技術を習得せよという命令を出せるから、プロジェクトをマネージできていないプロジェクトマネージャ、リーダでも部下に指示できる。

マネージメントされているとは言えないプロジェクトが、構成管理や変更管理をまがりなりにもできるようになるとプロジェクトのマネージメント=毎週進捗会議を行うことだと考えていたプロジェクトマネージャはプロジェクトがマネージメントされるようになったと思うかもしれない。

でも、構成管理と変更管理ができるようになっただけでは試行錯誤のアプローチから脱却できたとは言えない。分析してから設計しているわけではない。どんどん作り始めてしまって、問題があったら直していくアプローチは変わっていない。後戻りする頻度が減っただけであって、ソフトウェアシステム自体は開発の工程が進むにつれて複雑性を増していることが多い。

実は、ここからプロジェクトや技術者が一皮むけて一つ上のステージに上がれるようになるのがとてつもなく難しい。

ソフトウェア構成管理と変更管理はソフトウェア工学を取り込んでこなかったプロジェクトにも受け入れられやすい。それはなぜか。それは個人の痛みを軽減し、個人的な利益につながるからだ。組織やプロジェクトをマネージメントするという発想からきた取り組みではないんじゃないか。

プロジェクトみずからソフトウェア構成管理や変更管理をやるべきだと考え行動したのなら、それはプロジェクトマネージメントと言えるが、誰かから言われてルールだからという理由で構成管理や変更管理をやっているのなら、まだ、プロジェクトの利益のため、顧客満足を高めるためだと考えるまでには至っていないんじゃないかということだ。

失敗や成功の体験を取り込んだり、体系化したことのないマネージャのもとで、プロジェクトマネージメントを教科書どおりにやってもらうのはとても難しい。10年以上染みついてしまったスタイルをシフトするのは大変だ。

行き当たりばったりの修正に対して技術者個人やマネージャは特に問題だとは感じていないケースもある。だから、これまで実施していなかった構成管理や変更管理をやるようになっただけでも進歩していると考える。

10万行クラスのソフトウェアに対して開発の終盤で行き当たりばったりの修正を行ってしまうので,それらの修正によりサブシステム間の結合がどんどん強くなってしまう。

その結果,担当技術者でしか分からないという状況が発生するが,技術者個人にとってはその状況(自分にしかわからないことがあるという事実)は保身の材料になるため,積極的にその状況を解消したいとは思わない。そして,状況をよく知っている技術者が協力会社にいたりして,なにも考えずに新しい開発で協力会社を切ったりすると,この複雑になってしまっているソフトウェアシステムの状況が分からず同じ問題を繰り返す。

切られた協力会社にしてみれば「それ見たことか」といった感じになるので,ますます切れのよいサブシステムを構築することが困難になる。

<試行錯誤のアプローチから脱却できない個人、マネージャ、組織の心理>

技術者個人:構成管理,変更管理さえやっていれば,個人の損害は防げる。ソフトウェア資産を再利用することに技術者個人としてメリットは感じない。
マネージャ:構成管理,変更管理もまともにできていなかった。ソフトウェア資産の再利用までマネージメントするする余裕はない。
組織:なぜ,毎回毎回日程に間に合わない,予算をオーバーする,品質確保に苦労するのか理解できない。資産の再利用をなぜしないのか。

したがって,上記の3つのグループに対しては,提案の効果についてそれぞれ別々のメリットを示す必要があると思う。

<試行錯誤のアプローチから脱却できない個人、マネージャ、組織への提案の例>

技術者個人:アーキテクチャが明確になり,サブシステムの分離が進むと,設計の前段階での完成度が高まり,後工程でのバグが減る。
マネージャ:ソフトウェア資産を再利用できるようになると,最終工程でのバグが減り,ソフトウェアシステムの品質が高まる。
組織:ソフトウェア資産を再利用できるようになると,開発期間の終了が見えるようになり,ソフトウェア開発工数,デバッグ工数が減る。

成熟していない組織の最大の問題は直近の、また、直接的な利益のことしか考えられないということのように思う。長いレンジのスコープを持てないので、今日の問題の解決のことで頭がいっぱいになってしまい、明日につながるカイゼンのことに気が回らない。

自分はエンジニア個人の取り組みで組込みソフトウェアが作られてきた歴史や、責任と権限を明確にしなくても仕事ができてしまう日本人の特徴がこの状況を助長していると考えている。
 

2007-07-24

こころの処方箋

元文化庁長官で臨床心理学者の河合隼雄氏が19日午後2時27分、脳梗塞のため死去した。

河合隼雄氏は 1928年、兵庫県生まれ。京都大理学部数学科卒業後、米国留学を経て、1962~1965年にスイスのユング研究所に留学し、日本人で初めてユング派分析家の資 格を取得した。帰国後、ユング心理学を基礎にした心理療法の「箱庭療法」を完成・普及させ、日本にユング派心理療法を紹介した。

私的諮問機関「21世紀日本の構想」懇談会の座長や、教育改革国民会議委員など政府関係委員を歴任し、2002年1月、史上3人目の民間人として文化庁長官に就任しており、テレビでもよく姿を見ることがあった。

河合隼雄さんは人を包み込むような雰囲気を持っており、その著書の多くを読んだ。今回は、なぜ、河合隼雄氏の本を読んでいたのかを書きたいと思う。

プログラムは正確でないと動かない、曖昧なままでは期待したような動きにはならない。C言語などの高級言語ではやや曖昧さを受容するようにもなったが、アセンブラの時代などでは一命令でも間違っていればまったくプログラムが動かなかった。

そのような状況下ではソフトウェアエンジニアはロジカルな思考を求められる。ロジカルであればあるほど間違いの少ないプログラムを書くことができる。逆に言えば、いい加減な性格の人はソフトウェアエンジニアには向かない。

地道にこつこつこつこつとプログラムを書き論理的な問題点や、仕様が曖昧な部分があるとすぐに質問しすべてクリアにしてから前に進むような性格のエンジニアがプログラマに向いている。ことプログラマという職種に限って言えば、完全主義者であればあるほど早くて正確な仕事をし優秀であると評価される。

ところが、人間の脳は本質的にはロジカルな思考システムではない。脳神経学的に言えばコンピュータが0か1かの判断をするのに対し、人間の脳は多数決で判定を下す。また、その多数決に使われる入力はいつも同じではないため、必ず一定の結果になるとは限らない。

ようするにソフトウェアエンジニアは仕事上ロジカルであることが求められているにもかかわらず、本質的にはロジカルではないのだ。

そのギャップはときに社会生活を送る上で障害を起こすことがある。コンピュータがロジカルであるが故に生身の人間もロジカルな思考であるかのように勘違いしてしまうのである。その勘違いが進むと、人間もロジカルにコントロールできるという錯覚に陥ってしまう。そして、現実の人間はまったく論理的ではないため、コンピュータのように正確に予測したようには動かず、予測と現実が異なるためそのギャップに苦しむことになる。

例えば、野球で1点差で負けている試合、9回2アウト、ランナー2、3塁で最後のバッターを送り出す監督は選手に何というと成功に結びつくか?

「何が何でもここでヒットを打って逆転しろ」というのが監督の本音だ。でも、ベテランの監督なら「三振してもいいから思い切って振ってこい」などと言うだろう。三振しては困るのだがプレッシャーを与えないために、まったく逆のことを言った方が結果がよかったりする。人間とはそんなものだ。

また、ソフトウェアが大規模複雑化すると、ソフトウェアプロジェクトには多くのソフトウェアエンジニアが関わり合う。ロジカルでない人間が集まってロジカルにプログラムを作らなければいけない。そんな状況で問題が起こらないはずがない。このブログで顧客満足を高めることが大事と言っているのは、ロジカルと非ロジカルの矛盾を抱えながら組織やプロジェクトや個人がともに成功するためには、共通の価値観である顧客満足を高めることを目標にすれば、非ロジカルな部分のずれを修正して方向性を一つにできると考えるからである。

さて、ソフトウェアエンジニア個人が河合隼雄氏の本を読むとどんなよいことがあるのか。

それは、若いとがった気持ちで日々の仕事の黙々と取り組んでいるソフトウェアエンジニアがいるとする。自分だけの範疇ではこのような技術者はいい仕事をしている場合が多い。ところが、このような論理的でとがった気持ちをずっと解除しないでいると、複数人で共同作業をする場面やプライベートな時間で人と接するときに空回りしたり、他人を精神的に傷つけたりする。

河合隼雄氏の本をこんなエンジニアが読むとこのようなとがった気持ちを鈍らせて、所詮人間なんてそんなもんなんだということを気づかせてくれる。

河合隼雄氏の著書の中で読みやすく、もっともコンパクトな文庫本が『こころの処方箋』(420円)だ。こころの処方箋の中の一節を紹介したいと思う。

こころの処方箋-こころの中の勝負は51対49のことが多い- より】

 中学生や高校生のなかには、私のところに無理矢理に連れられてくる生徒がいる。たとえば、登校拒否の子など、心理療法家のところなど行っても仕方ないとか、行くのは絶対嫌だと言っているのに、親や先生などが時にはひっつかまえてくるような様子で連れて来られる。嫌と思っているのをそんなに無理に連れてきても仕方がないようだが、あんがいそうでもないところが不思議なのである。

 あるとき、無理に連れてこられた高校生で、椅子を後ろに向け、私に背を向けて座った子が居た。このようなときには、われわれはむしろ、やりやすい子がきたと思う。こんな子は会うやいなや、「お前なんかに話しをするものか」と対話を開始してくれている。そこで、それに応じて、こちらも「これはこれは、僕とは話す気が全然ないらしいね」などと言うと、振り向いて、「当たり前やないか。こんなことしやがって、うちの親父はけしからん・・・」という具合に、ちゃんと対話がはずんでゆくのである。

 こんなときに私が落ち着いていられるのは、心のなかのことは、だいたい51対49くらいのところで勝負がついていることが多いと思っているからである。この高校生にしても、カウンセラーのところなど行くものか、という気持ちの反面、ひょっとしてカウンセラーという人が自分の苦しみをわかってくれるかも知れないと思っているのだ。人の助けなど借りるものか、という気持ちと、藁にすがってでも助かりたい、という気持ちが共存している。しかし、ものごとをどちらかに決める場合は、その相反する気持ちの間で勝負が決まり、「助けを借りない」という方が勝つと、それだけが前面に出てきて主張される。しかし、その実はその反対の傾向が潜在していて、それは、51対49と言いたいほどのきわどい差であることが多い。

 51対49というと僅かな差である。しかし、多くの場合、底の方の対立は無意識のなかに沈んでしまい、意識されるところでは、2対0の勝負のように感じられている。サッカーの勝負だと、2対0なら完勝である。従って、意識的には片方が非常に強く主張されるのだが、その実はそれほど一方的ではないのである。
 このあたりの感じがつかめてくると、「お前なんかに話しをするものか」などと言われたりしても、あんがい落ち着いていられるのである。じっくり構えていると、どんなことが生じてくるか、まだまだ分からないのである。

 :
 :

【引用終わり】

河合隼雄氏のような包み込むような語り口で人間の心理は1か0では判断できないと言ってくれる人は他にはいないと思う。河合氏が亡くなって生の声を聞くことができなくなったのがとても残念だが、氏が残した言葉は本の中で生き続けており、ふとたまに読み返すとコンピュータの思考になっている自分を現実の世界に引き戻してくれるのである。

2006-07-08

小学生の問題も解けないなんて!

小学一年生の娘が宿題をもらってきた。4文字で一番後ろに“え”が付くものをできるだけたくさん考えてこいという問題だ。

家族4人で頭つきあわせて考えたがなかなか浮かんでこない。どうしても出てこないのだ。結局、数十分が過ぎて、宿題を出された末娘が“くちぶえ”を 思いついた。その後、小学校4年生の上の娘は“油絵”と“胡麻和え”を思いついた。

自分と妻は回答ゼロだった。

この問題がなぜ難しいのか? それは、人間の記憶はシーケンスが重要な役割を担っているからだ。人間の記憶とシーケンスは深い関係がある。このことは『考える脳 考えるコンピューター』にくわしく書いてある。また、『考える脳 考えるコンピューター』でジェフ・ホーキンスは、人間の脳は特に意識しなくても、各センサーから入力される信号から次に起こることを予測しているのだという。その予測結果と実際のセンサーからのインプットが異なると「何かが違う」という感覚を発生させるというのだ。

だから、だれかがあたなの家の玄関のドアノブにヤスリをかけてざらざらさせるといういたずらをするとどういうことになるか。

あなたはいつものように仕事から帰宅し、いつもの道を歩いている。目からはいつもの風景が入力されスーパーの次にはラーメン屋が現れる。脳の中ではスーパーを通り過ぎたころからラーメン屋の感覚が予測されているが、予測と目から入力される情報に差異はないため特に何も感じない。何も感じなくても脳は常に働いている。

しかし、自分の家に近づき玄関のドアノブに手をかけた瞬間に「おやっ」という感覚がわき上がる。ドアノブを握る直前に脳が予測した手の感覚と実際に感じた感覚に相違があったため脳がシグナルを送ったのだ。

これと同じような例で、しょっちゅう感じているのが携帯電話のバイブレータによる着信の勘違いだ。自分は会社では常に胸ポケットにPHSを入れている。音が鳴るとうるさいのでいつもマナーモードにしている。自分のPHSの内線番号が呼ばれるとブルブルッと振動する。

先の脳の予測機能は覚醒しているときは常に働いているため、胸ポケットにさしているPHSがカサッと動くと着信したときの感覚が予測・連想され、本当に着信したかのように勘違いしてしまうのだ。

この勘違いは1日に何回か発生する。PHSが胸ポケットの中で揺れたときに着信の振動の予測が想起されたことにより勘違いが起こる。普段、マナーモードにしておかないで着信音による呼び出しにしておけば、胸ポケットの中でPHSが揺れても振動の連想は起こらないはずだ。

このように、人間の記憶は時間的なつながり、すなわちシーケンスによって記憶され、次に起こることを無意識に予測している。

したがって、過去に経験したことのないシーケンスを初めて試みるときは何事もうまくいかない。冒頭で紹介した最後に“え”が付く4文字の単語探しは、最後の文字が指定されているから難しい。最初の文字が“え”の4文字単語なら、“え”を脳にインプットすることで、連想される単語のうち4文字のものを拾っていけばよい。たとえば、“エプロン”、“襟巻き”、“煙突”など、大人でも比較的簡単に思いつく。

ところが、最後の一文字が“え”の単語となると、このシーケンスによる連想が使えない。もしもくふうするなら、最後に“え”が付く短い単語を考えて、これに修飾語を付けるという方法がある。

たとえば“え”=“絵”と考えて、“絵”に3文字の修飾語を付ける方法だ。絵から単語を連想することはできるので、この方法なら“油絵”を思いつくことができる。“口笛”や“胡麻和え”も同じように“笛”や“和え”を思いつけば、口や胡麻を付けることで4文字単語ができあがる。

『Software People Vol.4』のコラム「人間の考え方,コンピュータの考え方」でも書いたが、自分の経験が積み重なってできたシーケンス記憶と、連想のメカニズムは、自分の中だけにあるものであった、他人のシーケンス記憶とは異なる。

したがって、自分が考える「相手の頭の中」の状態と、実際に相手方のシーケンス記憶の内容が違っているときはうまく意志の疎通がとれないことがある。

このようなときは、双方が共通の認識であるシーケンス記憶の例を探し、その例を使って目的へ導くことが効果的である。

特に抽象的な概念を教えるときにメタファーによる説明が有効なのは、人間の記憶がシーケンスによって刻み込まれており、シーケンスから連想が引き起こされるからに他ならない。

2006-05-02

考える脳考えるコンピューター

いま、『考える脳 考えるコンピューター』という本を読んでいる。今からさかのぼること20年前、大学の卒業論文のテーマは「脳神経系のシミュレーションモデルの製作と検証」だった。当時はワープロは一般的でなく手書きで書いた原稿を製本して卒業研究論文としていた。

この論文の内容のサマリは『Software People Vol.4』のコラム「人間の考え方,コンピュータの考え方」に書いた。不思議と『考える脳 考えるコンピューター』とタイトルが似ている。

『考える脳 考えるコンピューター』はパームコンピューティング社を設立し事業としての成功を収めたジェフ・ホーキンスが長年興味を持っていた脳についての研究を続け研究所を設立してしまった。もうこななると趣味の世界ではない。ほとんど自分の脳への探求心を追い続けるための資金を調達するために事業をしているようなものだ。

まだ、完読できていないのだが、半分まで読み進んでジェフ・ホーキンスも自分もコンピュータと人間の脳の情報処理の仕方がまったく異なるということを十分に認識できているという点が一致していると思う。

ただ、新しい発見というか、新しい理解としてジェフ・ホーキンスは、コンピュータは脳の500万倍ものスピードで情報を処理できるのに、人間の脳の情報処理能力が高いのは脳が情報を並列処理しているからではないと『考える脳 考えるコンピューター』の中で書いている。並列処理するのではなく、すでに記憶した豊富な経験の中から答えとなる答えを連想により引き出すだけだから早いのだ。

問題に対して似たような成功体験をしていなければ、その問題に似た体験や知見の記憶を探すわけだが、そのような記憶がまったくない場合は混乱したり、不安や恐怖を覚えることもあるかもしれない。

EEBOFの研究員のよしのさんがブログの中で以下のように書いている。

【ブログより引用】

計画を立てずに見切り発車し、がむしゃらに取り組むと失敗するかな。たいていこういう時には、無駄な作業がたくさん発生するわりに、本当に必要な情報を見落としちゃったりします。

  :
  :

自分の気持ちの中では多くの時間をかけ「努力」したのにアウトプットがまったく出せないのは私に能力が無いんだろうと思うようになり、そこからは仕事が手に付かず、パニックになってしまったのです。皆さんはそういう経験ありませんか?

【引用終わり】

自分は、何かの企画・計画を立てるとき、過去の成功体験の中から似たようなものをつなぎ合わせて、うまくいくような感覚を持たないとスタートをかけない。その企画が自分だけのタスクですむことなら、成功のイメージが現実となる確率は高い。

しかし、自分だけでなく他人も巻き込んだプロジェクトの場合は、プロジェクトメンバーのスキルや性格から想定されるイメージとプロジェクトの目標を総合して、成功のイメージが描けるかどうかがポイントとなる。

自分だけのタスクではないので、最初のイメージがよくても必ずしもその通りにいかないときはままある。しかし、最初に成功のイメージがない場合、見切り発車して現実に成功する確率は低いように思う。

上記のよしのさんへのアドバイスは、若いうちは小さな成功体験を積み重ねる、成功しそうなプロジェクトに参加して成功体験を積み重ねることをやったらどうかと思う。