創造性と批判的思考

下記に行ってきて、いろいろ考えた。

ABLE2016 Winter - 直観力を育てる

いろいろ考えさせられたので、自分の脳内を整理する。

あまり、整理できてないが、なんとなく、こんな感じだ。

創造的思考のプロセスモデル

創造性が評価されるまでの簡単なモデル。G.M.ワインバーグの設計の自然淘汰モデルと、デューイの問題解決学習が元ネタ。

システムづくりの人間学―計算機システムの分析と設計を再考する

学校と社会 (岩波文庫)

(1) 解決したい問題の認識

(2) アイデアを絞り出し、複数のアイデアを結合して対象の問題に対する解決策を立案する

 ・アイデアの源泉は既存のアイデア、思いつき、イマジネーション、他の別分野のアイデアからの類推など様々

(3) シミュレーション等による解決策のテストとフィルタリング

 ・脳内シミュレーション、模型や図面、ラフスケッチによるフィルタリング
 ・天才肌の人は脳内シミュレーション力がすごい。多分

　この本では、宮崎駿の脳内シミュレーション力に触れている

コンテンツの秘密―ぼくがジブリで考えたこと (ＮＨＫ出版新書　458)

(4) 選別されたアイデアの具現化
(5) 具現化したものの最終的なテストとフィルタリング

  ・製品等は市場でのテスト
  ・論文は科学者コミュニティでの評価や後の研究への貢献によるテスト

(6) テストに合格したものが創造的とされる。

(5)でテストに合格しなかった製品や論文は創造的でないものとして、世の中に認知される。創造的な思考には

　1. (1)、(2)でできるだけ(5)のテストに合格できる可能性の高いアイデアをたくさん生み出すことと

   2. (3)で製品を実際に作ってしまう前に適切に不合格にして無駄な努力をしない

の二つが大事と思う。

(3)で(5)のテストを先取りできる人が多分、創造的とされている人たち。脳内テストに合格するアイデアを求めて、アイデアを生み続け、捨て続けているんだと思う。

科学的知識などの体系的知識が創造的であることにとって必要な意味

過去に創造的と見なされたアイデアは

1. 他人が気づきにくい問題の存在を示唆する
2. (5)のテストに合格したアイデアであるため、解決策の材料として高品質 

よって、(1)と(2)のプロセスの品質を向上させる。

批判的思考

オレオレ定義では、批判的思考はテスト志向の思考態度。要素は下記の２点

　1.その思考が間違っている可能性を常に視野に入れること

　2.その思考が間違っていないかどうか、を機会あるごとにテストすること

これができていると、(3)のプロセスがきちんと機能する。

テストの仕方

　1.間違っていることを立証する

    →反例をあげるとかね。ただ、そのためには議論や思考が反証可能になっている必要がある。カール・ポパーは全ての科学的議論は反証可能であるべし、とした（確か。。。）。ただ、確率でしか言えない社会科学などの複雑系の学問では徹底は難しい。だから

    2.より良い説明を見つける

　→同じ事象を別のより良い説明で合理的に説明できる場合、悪い説明は否定される。予測の精度が高い、シンプル、適用範囲が広い、など

つまり、自分の定義では、批判的思考とは、機会あるごとに、自分の考えと矛盾する事象、もしくは、より今の自分の考えより良い考えを探す態度。

多分、批判的思考によって、アイデアを否定し続けていると、筋の悪いアイデアを産む、という無駄な行動をとらなくなっていく気がする。

そのリスクがある気もするが。。。

創造性を生み出すには

創造性を生み出すには、間違っているかもしれない大量のアイデアを生み出し、できればそれを明確に否定する、っていう矛盾する体験を継続的に行うことなんだと思う。

だから、流行りの「否定しない空気」の中で生み出される アイデア会議とかってそれだけじゃダメで、合理的、論理的、非情にアイデアを否定するフェーズってのも必要なんだと思う。

ジョブズはアイデアを辛辣に否定することで有名。

こっちも参考。

blogs.itmedia.co.jp

変容へ向かう振り返りとメンタルモデルと感じ方

振り返りはとても有効。

 

特にチームでやる振り返りは有効。チームの生産性にも決定的な影響を与える。

 

でも、どうにもKPTやっても、頑張っても上手くいかない時がある。

 

根深い構造、文化がそれを阻んでいる場合がある。

 

ここで、話すのは、とてもプライベートで、より深い変容に向かう振り返りのこと。

 

どうしようもない、と限界だ！、絶望した！

と思ったときこそ、自分自身を成長させるチャンスなのかもしれない。

 

ここで話すのは、そういうときに少し助けになるかもしれないこと、別に人生順風満帆でも助けになるかも。

 

学習は変化をもたらす。自分の中の定義では、深い変化、変容が起こったときに変わるのは、物事に対する感じ方。感情的反応が変わる。

 

人の心は色んなものに反応する。これは進化の過程で人間の心に備わった機能。快、不快といった単純な反応だけでなく、

 

ウキウキする

安心する

重苦しくなる

怒る

 

無限のパターンがある。生来の癖もあれば、経験が無意識に作り出している反応もある。

 

これそのものは普通で望ましくある。

 

ただ、一方で自動化した反応は目の前の現実に不適合な場合もある。

 

反応は先天的、もしくは、後天的に作られた世界に対するもののみかた(メンタルモデル)によって作られているように自分には思える。

 

反応に自覚的になることによって、自分自身がどのように世界を見ているか、に気づくことができるかもしれない。

 

そして、気づくこと、そのことが変化をもたらすこともある。もたらさないこともある。

 

個人的な経験と観察と思索の結論だけど、ここで、自分で意識的にメンタルモデルを変えようとか思わない方がいい。

 

気づいたとき、起こるべき変化は自然に起こる。

 

多分、人間には自己成長へ向かう自然な傾向が備わっている。それを信じて委ねること。

 

”Good travels at a snail's pace.”　Mahatma Gandhi

 

瞑想と気づき

あくまで自分の理解ね。

 

瞑想は気づきを深めることで変化を促す

 

古代インドの哲学者たちは世界を理解するために、世界の一部である自分自身を理解することから始めた。

 

そこでは、感官は単なる機能であり、真の自己は世界そのものである、との認識に至った。

 

まあ、実はこの事自体は自明に近い。スピノザも同じ事を言っている。人間の意識や思念は基本的には有機的装置の機能であり、進化の産物。

 

ヴェーダンダ哲学における解脱は、真の自己と世界を同一化するもの。意識のレベルではなく、根本から。多分。

 

まあ、ここまでいかなくても、瞑想は自分を客観視して、自分やそれと関係する世界の複雑なシステムを理解することを助けてくれる。

 

呼吸、自分の体の反応、物事に対する感じ方、捉え方、自分の頭に去来する思念、執着

 

この自分自身に気づき、理解しようとする意図や願望自身も、気づきの対象となる。

 

whyと考えることは、仮説であり、妄想の一種なので理解は直観に任せる。ひたすら気づく。

 

そして、気づいたことを、評価判断するのも妄想。単に気づくだけでよい。どうしても評価してしまうんなら、評価する自分に気づいてそれも受け入れる。

 

慣れてくると、リラックスして軽く瞑想するだけで元気がでたりする。

 

慣れないときは、少し自分のなりたい姿みたいのをイメージしてから始めると、迷子になりにくいらしい。

 

まあ、やり方はそれぞれ流派があるのでそこで。

 

人によっては気持ち悪くなる人とか、怖くなる人とかいるらしい。

 

そういう場合は、無理しないでやめるか、短く終わらす。

 

無理して頑張る必要はない、というか、個人的な意見ではそれは逆効果。

 

相性も時期もある。

 

経験学習と問題ない症候群

人は常に経験を整理し、記憶し、活用しようとしている。

 

そして、経験したことを整理する際に情報を取捨選択している。

 

最も簡単な経験学習は、今までの体験したことのない経験をすることによって起こる。はじめてのプロジェクト、新卒入社、転職。

 

研修なんかで目新しいゲームや演習をやるときにも起こる。

 

はじめてのことは失敗する。問題だらけ。問題は分かりやすい、人に迷惑をかける、評価が下がる、怒られる。自分の周りに問題がある、ということは自分が変化し、成長しなければならない、ということ。

 

学びは当然大きい。

 

でも、一度、それが繰り返され、「問題ない（No Problem）」状況が続くと、学びは起こらなくなる。

 

その状態が客観的にみていい状態かはわからなくても、とにかく、問題ない、とその人が思えば学びは起こらない。

 

継続的に学習が起こるには「問題ない」状況から問題ある状況を作り出す必要がある。それには、現状に対するものの見方を継続的に変化させる必要がある。

 

 

もっといいやり方がある、と信じること

 

自分が実現したいビジョンを持つ、ということ

 

性格タイプ論の有用性と罠

自分が今まで学んできた性格タイプ論について書いてみる。もっと時間があれば短く書けただろう。。。

 

タイプ論とは

 

人間を様々なタイプに分けることは、色んな人が色んな根拠でやって来たと思う。

正式な理論に基づかなくても、オレオレ分類論は結構持っている人が多いのでは？

ここでは、心理学とか、人材開発の流れを組むタイプ論について話す。

 

ここでのタイプ論は人間はある観点に従って、複数のタイプに分類でき、それは生涯変わらない、ということを主張する類いのもの。

 

タイプ論と似たものに、あくまでも分類はそのときの社会的振る舞いの傾向についてのもので、変わる可能性がある、とするものもある。ソーシャルスタイルとか。

個人の印象だけどソーシャルスタイルはあまりにも変わりやすいため、それを分類することのメリットは殆どない。個別対応のほうがいい。

 

タイプ論の有用性  

他者理解と他者受容

タイプ論を学ぶことで得られる分かりやすい有用性は他者理解。
通常、僕らは自分と他人は同じという仮定に基づいて行動し、共感したり、感情を推し量ったりする。これは、人間が自然にやる本能的行動。

 

タイプ論を通じて見えてくるのは、タイプが異なると、根本的に違う前提で世界を見ていることがあること。今までの赤とおもっていたものが、黒や紫に見えていた人がたくさんいるってこと。
例えば、MBTIで内向的とされているタイプは１人の時間を通じてエネルギーを蓄える。逆に外向的なタイプはみんなといることで元気になる。
落ち込んだ時とか、内向的なタイプに対して外向的なタイプが飲みに誘ったりするのは、余計なお世話だったりする。

 

こうした認識がないと、例えば誘いを断られた外向的なタイプは、断った内向的なタイプに関して、自分を好ましくおもっていないのではないか、とか、バカにされているのではないか、とか変人だ、とか色々状況を歪んで判断する可能性がある。

 

よくあるタイプの違いから来る誤解はかれは不道徳だ、とか、無能だ、とかそういう低い評価。

 

少なくとも自分が当然と思っていることを当然と思わない人が周囲にたくさん昔から存在していた、と気づくことは対人関係の状況認識に劇的な影響を与えると思う。

 

自己理解と自己受容

自己理解にも役立つ。特定の文化や組織は集団的規律を維持するために、ある程度特定のタイプの認識や傾向に有利な規律を強制する。あるタイプはある文化圏では変人として扱われる。
友達100人できるかな、とかね。

 

そういう状況では、集団に不利なタイプは自分の感じ方やものの捉え方に自信が持てなくなり、自分以外のタイプの特性を内在化するようになる場合がある。もしくは、社会を拒絶する。自己認識や社会の捉え方が歪む。

 

タイプ論は自分が他人と異なっているだけであったり、さらに同様な人は他にもたくさんいたりすることを教えてくれる。自分の感じ方やもののみかたをあるがままに受け入れることができるようになる。 

上記二点は、タイプ論を学んだ極初期に得られる利点。さらに深く学ぶともっと各々のタイプ論特有の仕方で自己理解や他者理解が進むと思う。

 

タイプ論はよく誤解されているように人間や組織に対するもののみかたを単純化するものではない。

 

他人は今までの自分の自然な捉え方だけでは理解できない、と突きつけるもの。社会は無限に多様な個人から成り立っているものであることを教えるもの。人間や社会をより複雑にとらえなくてはならないことを教えるもの

 

タイプ論の罠

タイプ論の罠としては、人をタイプの枠組みで単純化して捉えることだと思う。ただ、個人的にはこれはタイプ論をよく理解していないし、別にタイプ論を学ばなくても人をステレオタイプで判断する人だろうからあまり、気にすることはないと思う。

 

タイプ論のエバンジェリストたちは、評判落とすから警戒するだろうけどね。

 

自分が学んで、良かったタイプ論

MBTI

ユングタイプ論をもとに、マイヤーズとブリックスが拡張、整理したもの。 万人におすすめ。グローバル、とくにアメリカでは主流だと思う。

 

生まれつきの利き手のようにタイプが決まる。

下記でどちらが優位かでタイプが決まる。2×2×2×2の16タイプ

• どこからエネルギーを取り込むか（I 内向: E外向）
• どのように情報を知覚するか（N  直観: S感覚）
• どのように判断するか（F  感情: T  思考）
• 外界に対してどのように振る舞うか（P 知覚: J判断）

MBTIのタイプは仕事の仕方とか、対人関係のスタイルとかと影響が強い印象。仕事で有用だし、学生とか若手社会人にもいいと思う。

 

一般社団法人 日本MBTI協会

MBTIへの招待―C.G.ユングの「タイプ論」の応用と展開

エニアグラム

神秘主義思想と心理学的タイプ論を融合したもの。9つの頂点をもつ図形に合わせた9つのタイプ。触れていない本もあるけど、9つのタイプには、両端のどちらかのタイプにより近いか、というウィングがある。全部で9×2の18タイプ。英語、日本語ともに表現は様々なものがある。

タイプ 1  改革する人（The Reformer)

タイプ 2  助ける人(The Helper)

タイプ 3  達成する人(The Achiever)

タイプ 4  個人主義者(The Indivisualist)

タイプ 5  調査者(The Investigator)

タイプ 6  忠実な人(The Loyalist)

タイプ 7  熱中する人(The Enthusiast)

タイプ 8  挑戦者(The Challenger)

タイプ 9  調停者(The Peacemaker)

生まれつきと幼少時の体験からタイプが決まるとされる。

 

ちとオカルト的ではあるのだけど、自己成長のための非常に良質なツールになると思う。
誰も言っていないけど、個人的には学生とか20代とかよりも、30代以降の人におすすめ。自分はエニアグラムは学生のころ知って面白かったけど有用性を実感したのは最近。

多分、若いときには色々と受け入れられないんだよね。。。

Home - The Enneagram Institute

学ぶには、まず、リソの本を読むこと。

エニアグラム―あなたを知る9つのタイプ 基礎編 (海外シリーズ)

タイプの特定と学び方

自分がどのタイプであるか、を知ることは簡単ではないと思う。いろんな診断テストとかあるけど、最終的には自分で納得するしかない。

ワークショップとかで、人と話しながら、ああでもない、こうでもないと理解を深めながら、継続的に探究していけばいい。

もし、そういうタイプ探しが退屈だったり、意味のないことに思えたなら、それが今のあなたに不要なことであるか、タイプ論の深みに触れた議論ができていないか、のどちらかだろう。

ちなみにMBTIは認定にうるさくて、ちゃんと認定ユーザによるワークショップを経た形じゃないとダメ、って言っている。

自分は２人の認定ユーザのワークショップを合わせて３回受けたことあるけど、確かによく考えられて設計された良いワークショップだったと思う。

自分はMBTIではINFP、エニアグラムではタイプ4のウイング5でかなり確信している。ただ、時々別のタイプを疑ってみることもある。

 

独断と偏見に基づくコミュニケーション力向上のための推薦図書

かなり、変わったリストだと思うけどね。

ライト、ついてますか―問題発見の人間学

 まずはこれ。実はメンタルなところより、そもそも何について話しているのかを明確にすることを学ぶべき。

スーパーエンジニアへの道―技術リーダーシップの人間学

 サティアの交流理論についての解説がいい

ゴードン博士の人間関係をよくする本―自分を活かす相手を活かす

 古い本だけどいい本なのさ。困っている時、相手を責めないで助けを求めよう。

ダイアローグ 対立から共生へ、議論から対話へ

 考えを保留するって大事。

プロセス・コンサルテーション―援助関係を築くこと

 コミュニケーションについてのコミュニケーション

Conjoint Family Therapy

 結構本質が書かれていると思う。

オデッセウスの鎖―適応プログラムとしての感情

 感情について知る。

業務システム開発の次の言語としてのKotlinの可能性

いつもながらの、雑感。Javaの次の言語としてのKotlinについて考えてみる。

mattun.hatenablog.com

上記みたいなこと、いろいろ考えていた。

もう、オープン系業務システム(エンタープライズ)の開発言語としては、長い間、UNIX系プラットフォームだとJava,Windows系だと、C#って感じでずーっと続いていたと思う。（Windows系はある種独自の世界なのとよく知らないので、ここでは割愛。）

その間、何度か、新しい言語の波が来ていて、Javaの次が来るって期待があったと思う。

RubyとRuby on Railsの衝撃

自分の記憶にあるのは、Ruby on Rails（以下RoR）の衝撃。

簡単なDBのCRUDアプリを作るのにも、ものすごい金と時間が掛かっていたStruts1全盛の時代。あっという間にWebサイトが作れてしまうのは衝撃的だった。『JavaからRubyへ』みたいな本が書かれた。

楽天市場のサイトがRubyで開発されたのって、象徴的と思う。

SIの世界でも、一部でRuby/RoRが使われるようになったし、Javaの過去資産を活用できるJRuby、そして、Javaとの連携を強く意識したgroovy/grailsが出てきて、動的言語が注目を浴びていた。

ただ、主流はやはりJavaで、言語よりフレームワークでRoRを強く意識して、同程度の生産性を出そうと頑張っていたと思う。

Javaも5になって、ジェネリクスやアノテーションが出来て、いいフレームワークを作れるようになってきていた。

Springは、RailsLikeな開発ができるSpring Rooをリリースしていたし、日本では、SAStrutsが色んな企業の業務アプリ開発に使われるようになった。

この動きっていうのは、Webアプリケーション開発/アーキテクチャのベストプラクティスが確立され、Webアプリ開発がボイラープレート的なコードの記述になっていったことを示しているんだと思う。

RoRはボイラープレート的なコードをほとんど0にしたし、それに刺激を受けたJavaフレームワークもその方向で進化した。

言語の動的性質っていうのは、インパクトの小さな部分だったのではないかな、と振り返ってみると思える。

ただ、多くの人がRubyやGroovyに触れることでそこに表現されていた関数型プログラミングの概念が業務アプリのエンジニアたちに広まったのは結構大きいと思う。

Scalaの台頭

動的言語とそのフレームワークが注目されている中、やっぱりコンパイル時のチェック、そして、何より静的言語のパフォーマンスいいよね、でもJavaいけてないよねってことで、Scalaが台頭してきた。

頻繁にクジラの画面を表示させていたTwitterがバックエンドをRoRからScalaに切り替えた、というのがその象徴的事件。

Webアプリとしてのフロント側だけでなく、Hadoopなどのパフォーマンスが必要とされるバックエンドでの大量データ処理の必要性が出てきたのも背景にあると思う。

ただ、技術的なチャレンジとしてScalaが注目、方々で採用されている中、Javaもしぶとく生き残っている状況がある。

Scalaの膨大な言語仕様や、コンパイル時間の長さ、バージョンアップ時の互換性の軽視あたりは、採用に二の足を踏むチームも多かったんじゃないかなー。

個人として、最初かなりScala面白そう、と思ったのだけど、実際書いてみると色々辛い。。。年寄り文系の自分には難しすぎるんだよね。Scalaは。。。

下記みたいな話もある。まあ、パフォーマンス問題は過去の話と思うけどねー。

YammerがScalaからJavaへ移行中

今の言語の進化の方向は、静的型付けがある中で、どれだけ手軽にプログラミングできるか、を模索していると思う。Go言語とかもね。

（ざっくり言い過ぎと思うが。。。）

Kotlinの位置付け

KotlinはIDEベンダであるJetBrainsが開発したJVM上で動作する静的言語。（JavaScriptにコンパルすることもできる。）

Kotlin

まだ、リリース前のベータ版だけど、もうすぐリリースとのこと。Android開発ではもう結構使われているっぽい。

基本的に、KotlinはAltJavaであるC#,Groovy,Scalaあたりの良いところ取り。そして、Javaプログラマが多く従事している業務アプリの現場での課題解決を強く意識していると思う。

 下記は自分がいいな、と思ったところ。

1. 静的言語であり、コンパイル時チェックが効く
2. 文法がJavaプログラマにとってとても学びやすい
3. Null Safety/Optionalが言語レベルでサポートされて、Java8のOptionalより分かりやすい
4. 関数型プログラミングが言語レベルでサポートされ、Java8より分かりやすい
5. 演算子オーバーロードや拡張メソッド（Scalaのtrait）などDDDに都合の良い機能が豊富
6. 困った時はJavaで書ける
7. 返り値を複数とるような感じで、書ける

Java8への移行との比較

個人的には、Java8のラムダやメソッド参照、Optionalなどは、かなり無理矢理詰め込んだ感があり、相当使いにくい。

複雑なロジックになった時、StreamAPIを下手に使うと、可読性が低下する気がするし、Optionalの使い方も徹底できる気がしない。そこら辺、どうしてもプログラマの規律に依存しなくてはならないと思う。

ある程度の規模のプロジェクトになると、これらを全面的に導入して、学習コストに見合うメリットが出るとは思えない。

（技術自慢のプログラマー集団なら、新しいチャレンジにもなるし、ありかと思うけど。）

個人的にそこにコストをかけるんなら、ValueObjectとか、仕様クラスみたいなDDDのやりやすい所をやっていった方がプロジェクトに対してはメリットが大きいと思う。

対して、KotlinはJava8の新機能がやろうとしていたことを遥かに効果的に実現していると思う。とにかく分かりやすくて、Javaプログラマには学習コストが低い。

ちゃんとした研修コンテンツを作って動画配信してあげれば、プロジェクト全体に導入することも大したコストなくできると思う。

@masatsugumatsus 結局、技術的に苦労するのってフレームワーク側だから、機能開発に限っちゃえばkotlin導入のリスクって殆どない気がするなあ。SIのプロジェクトなんて、どうせJavaもよく分からず使っている人ばかり、って場合も多いし。。。

— 松下正嗣 (@masatsugumatsus) 2015, 11月 23