ヴィゴツキーにおける科学概念と生活概念の発達の違いとその意義

先日、この本を読んだ

 

「発達の最近接領域」の理論―教授・学習過程における子どもの発達

「発達の最近接領域」の理論―教授・学習過程における子どもの発達

 

 

第6章の「生活的概念と科学的概念の発達」についてメモ。

 

ヴィゴツキーによれば、学校で教えられるような科学的概念の発達と生活概念の発達は、相互に関連しつつも別の経路をたどるという。

 

その中で、彼は、「であるから」のような言葉を歴史学習の問いかけでは正しく答えられるのに、現実の生活の例だと正答率が落ちるような例をあげている。

 

彼によれば、無自覚に習得した生活概念が強いところでは、自覚的な科学概念が弱く現れる傾向にある、という。

 

研修をやっていると、こういうのは至る所で見る。机上の空論と呼ばれるやつだ。学習の文脈の中では言葉上で理解しているのだけど、現実に当てはめることができない。新しく学んだことを利用するのではなく、古い慣習的なものの見方をつい、適用してします。

つまり、生活概念が邪魔しているのだ。ヴィゴツキーは、第二外国語を学ぶ時にもこれと同様なことが起こっているという。

さらに、科学的概念を生活の文脈の中で適用できるようになるには、その概念の内在的な成長、そして、教師などによる支援が必要になってくる。

 

ここまでの議論で自分が受けた示唆は以下の点だ。

 

一つは、学んだことが現実に適用できず、言葉だけのものであったとしても、それは科学概念の萌芽なのであって、無意味ではない。それどころか、実践的に学んだことを適用するために不可欠である、ということ。

 

2つ目は、生活概念が邪魔をする、ということを教師も理解しつつ、辛抱強く新しく学んだ科学概念がその生徒の内面で発達してくることを待ちつつ支援する、ということが重要だということ。

創造指向と問題解決指向の違いについて

ロバート・フリッツがよく言っていることだが、

創造(Creation)と問題解決(Problem Solving)は全く違う。

なぜ、それが強調されなければならないのか、というと両者は表面的には似ているから。

ロバート・フリッツが定式化したシンプルな創造プロセスは下記のようなものだ

f:id:masatsugumatsus:20190411224939p:plain

www.soljapan.org

望む結果があり、現在存在している現実がある。その差異がエネルギーを生み出す。

一方で、G.M.ワインバーグの定式化した問題の定義は下記のようなものだ。

望まれている状態と現在の認識の差異

参照

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

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

コンサルティングシステム開発のビジネス要件定義などで行うGap分析もこれだ。

果たして両者に違いはあるのだろうか。文章だけ読んでいただけでは、その違いは明確ではない、自分もよく分からなかったし、その違いは重要ではないと思っていた。。

だが、最近これを区別することはかなり実践的なインパクトがある、と考え直すようになった。

指向(orientation)の違い

今のところの自分の理解では、創造(Creation)と問題解決(Problem Solving)の違いは、その出発点と方向。英語のOrientationの違いにあると考えている。

問題解決(Problem Solving)は現状の不満、不足、マイナスから始まる。現状の評価から出発する。現状から離れることが目的。成果はそれほど重要ではない。多くの場合、抽象的な「完璧モデル」や漠然としたイメージから「望んだ状態」を定義する。

創造(Creation)は出発点において現状を評価しない。ニュートラルにみる。創り出したい状態から現状を見てその違いを識別するだけ。その差異の認識がエネルギーを生み出し、創り出すことを後押しする。

問題解決(Problem Solving)は現状から離れることに主眼があるため、対策が効果を持ち出すとどうしても望んだ成果へ向かうエネルギーが失われていく。そのため、ある程度の対策をすると問題が解消され、次に問題が再発生するまで放置されることになる。問題発生→解決→放置→発生→解決のサイクルを繰り返す。

創造(Creation)はその成果が実現されるまでエネルギーが失われることはない。また、その成果が得られてから失われることはない。新しい創造の土台になる。

創造指向(Creative Orientation)の肝は、最初に現状を抽象的な評価基準を持ち込んで、評価することをやめることだ。ビジョンを定義し、そこからの差異としてのみ現実を評価する。

ワインバーグの問題定義は、おそらく、問題解決指向(Problem Solving Orientation)から創造指向(Creative Orientation)への変換、どこへ行きたいのか、という問いを根本的に問い直すきっかけを確かに与えてくれるだろう。ただ、ビジョンもなく、現状の分析から始めるだけでは、「望まれた状態」はでっち上げられたものになる。

創造指向(Creative Orientation)において、現実はただそこにあるだけなのだ。画家がキャンパスを前にしたら、それに絵を描いていくだけ。キャンパスの材質が悪い、とか、小さいとか、キャンパスを修理し出しても絵は完成しない。

そして、創造は常に、選択でもある。やってもいいし、やらなくてもいいことなのだ。

不満のない状態から目指すものを見つける、というのはある種のスキルだ。そこに理由は不要。カレーが好きとか、野球がしたい、とかそういう純粋な動機。多くの大人はこれを失っている。

増田さん/@irofさんのDDDサンプル徹底解説についての雑感

jsug.doorkeeper.jp

 

本当に面白かった。DB周りの質疑も楽しかった。

内容は他の方のブログ参照。

これとか

takeda-san.hatenablog.com

 

以下雑感

 

DDDと増田さん流のOOPを使ったアプリケーション開発

個人的にDDDというのは、アプリケーションの目的であるユーザー世界の関心毎を中心に置こう、というだけでコンセプト自体はそんなに特殊なものではなく、ソフトウェアエンジニアリングというか、プログラマー界隈では多くのグルたちが同じようなことを目指していたと思う。要するに関心毎の分離。

いくつかの重要なアイデアが発明されたけど。RepositoryとかAggregateとか、境界づけられたコンテキストとか。

 

いくつかの点で増田さんのやり方はエバンズが本で書いたものとはずれてたり、ポイントが違っていたりするから、DDDということではなく増田さんというプログラマーの先輩によるOOPを使ったアプリケーション開発の解説、ということと捉えている。

 

ドメイン層の解説と質疑聞きながら思ったこと

  • ドメイン層は条件分岐と計算ロジック、という整理はかなりしっくりくる。改善の指針にもなる。入出力の関心毎はドメイン層ではない所に追い出すこととなる。
  • フィールドのゲッターをフィールド名()というメソッドにしている。役割はゲッターだけど、getはいらない、可読性優先、ということという。確かに見やすい。C#とか、Kotlinとかプロパティが機能としてあるけど、目的は同じと思う。
  • パッケージ構造/関連の重視。一貫して、コードをドキュメントとして扱えることを目指していると思うが、このパッケージ構造の重視も面白い。変な循環参照なんかはコードの不吉な匂い、ということ。
  • Java標準の型ではなく、汎用的なDateとかの型を定義している。それはいいんだけど、PayRollというすごく抽象度の高い、というかコアなクラスのメソッドで汎用型が顔を出すのは、自分としては納得がいかない。後でコード見て考えてみたい。
  • 試行錯誤の過程を見せてもらえたってのはすごく大きい。可読性、パッケージの関連、見た目の感覚、ドットの数,一覧。こういうものを手がかりに改善していく、ということ。
  • 動くものを作ってから改善していった、ということらしい。多分、経験豊かな人なら最初からやれるんだろうけど、多くの人がこれをやる指針になると思う。

アプリケーション層とインフラ層の解説と質疑聞きながら思ったこと

  • Repositoryはアプリケーション層。これはすごく面白い。これまで、入出力はIoCを使って隠蔽し、インタフェースのみをドメイン層としてきた考えだったけど、現実として、インタフェースにも入出力の考慮が出てきてしまう。Repositoryそのものをドメイン層から追い出したことで、アプリケーションの処理方式に基づいた様々な考慮がアプリケーション層で記述する、という形にすることができる、と感じた。
  • 履歴の追加と最新状態の書き換えは別トランザクションにしている、とのこと。ここは理想としてはそうしたいものだと理解している。現実的に一つのアプリだと、1トランザクションにしてしまった方が楽とは思う。ただ、どちらにしてもそれらはアプリケーション層の関心毎。履歴の追加と最新状態の書き換えは別の仕事ということかと
  • トリガーを利用して最新の書き換えをDB側でやっていて、うまくいっている、という方がいた。個人的にトリガーでやりたいな、でも怖いなあ、と思ったことはなんどもあるので、それで行けるんだなあ、と思った。こういうの挑戦するのはすごいな。考慮すべきは、ソースからその処理の情報が消えることかな、とは思う。ソースを読んでもアプリの全体像が分からなくなる。ドキュメンテーションとしての機能が奪われる気がする。ここら辺は方針の問題。
  • DB例外(多分ユニーク制約違反とか)とかは基本的には起こらないようにする。起こるのはシステムエラーなので例外なげて終わらせる。これ、そうだよね、という気がする。
  • JSONとかは、ドメインオブジェクトをそのまま出したい。階層深くなるけど、ということ。ここ、個人的にかなり悩んでた。結局階層が不自然だから、詰め替え発生するよなあ、と。ここら辺を綺麗に、ということならプレゼンテーターを導入してもいいんだろうなとは思う。
  • 画面、API共に詰め替えをする時もある、とのこと。個人的にどこを綺麗にしていくか、ということかと。

 

JIGも素晴らしかった。 

 

効果的な研修について

研修の有効性

学校でのお勉強が役に立たないのと同じように、脱文脈化された死んだ知識はどんなに頑張って暗記しようとも役には立たない。

多分、最もやりやすくて効果的な研修は、文脈を同じくする社内での実践知を形式知化して、知識付与→実践とフィードバック→振り返りによる改善  のサイクルを回していくことだと思う。

下記の本では、やって見せる → 種明かし の効果も述べられている。

リーダーが育つ変革プロジェクトの教科書

リーダーが育つ変革プロジェクトの教科書

大事なことは文脈を失わないこと。

効果的な研修とは何か。

効果的な研修にはいくつかのパターンがあると思う。

  • 複雑なスキルや知識だが、On-the-JOB での実践的なフィードバックと組み合わされているもの(一般的なソフトスキル、コミュニケーション/問題解決などがフィットする。)
  • 煩雑なスキルや知識だが、体系的に整理され、かつ、受講者に前提知識やスキルが確保されているもの(ソフトウェアのフレームワークの知識とその利用などがフィットする。)
  • 比較的単純な技術の反復トレーニング(単純なコーディングスキルやアルゴリズム構築などがフィットする)

上記が比較的やりやすいものだが、もう一つのカテゴリが上記の合わせ技。 「複雑なスキルの土台にある機能しているシステムを、理解しやすい教授用モデルとして提示し、それをトレーニングする」

というやつだ。こういうのは、複雑系のスキルのトレーニングにも有効。

このモデルは、実践の中でスキルを拡張し、現状に適応し、成長していくための種になる。

理解しやすいモデルにする、ときの注意点は、簡単にしようとして実践で活用できないモデルにしてしまうこと。これは職業講師や著述家などがよくやる。アンケートや評判がよくなるから。

この「理解しやすい教授用モデル」というのは、熟達者すら自覚しきれていないイノベーティブなアイデア。とうぜん、モデルに完全な最終的な解はなく、継続した洗練が必要である。古来優れた教育者には知られてきたものだけど、ユーリア・エンゲストロームが分かりやすく定式化している。

mattun.hatenablog.com

実例

身体技法としてのコミュニケーションと思考のスキルとリラックスすることについて

リラックスすること

去年から、演技の教室に行き出した。

流派にもよるけど、オーソドックスな演技の訓練法では、リラクゼーションというのを様々な形でやる。

これは、ロシアの演出家、演技理論家で近代のリアリズム演劇の方法を確立したスタニスラフスキーに負うところが大きいと思う。彼はおそらくヨガの知識と経験的に、筋肉の緊張というのが身体の自由を奪い、表現を困難にすることを知っていた。そして、ヨガの知識から訓練法に取り入れたのだと思う。

コンスタンチン・スタニスラフスキー - Wikipedia

研修の講師みたいな仕事をしているが、 元々はプレゼンテーションなどまるで苦手だった。人前で話すと緊張する。(元々やりたくて始めた仕事ではない。)

で、駆け出しの頃は全身ガチガチに緊張しながらやっていた。でもそれだと、受講者の反応が感じ取れないし、当意即妙がなく、場が生き生きとしない。

自分の中でのブレークスルーは「リラックスして、集中する」という感覚を掴んでからだった。

緊張に気づくこと

リラックスする感覚を捉える、というのは、緊張に気づく、ということでもある。大雑把に緊張している、というのではなく、感覚をより精緻に、微細にしていくとリラックスの深さが増す。身体の部位、顔、筋肉の筋。

リラックスする深さが増せば増すほど、感覚が鋭くなり、自分の内面にも外部の環境にも気づくことができるようになってくる。

視野が広がり、思考も柔軟になる。

肩こりや腰痛とも無縁だ。

武道におけるリラックス

合気道なんかは典型だけど、リラックスすることで効果的に動ける、動きが効果的に相手に伝わる。

柔道でも、実は技をかけることそのものには力は要らない。自分はまだ力が入ってしまう。(それ以外にも課題は山ほどあるが。。。)

Sitting in the Fire

尊敬する偉大なセラピストで、ファシリテータである。アーノルド・ミンデルの本に下記のようなものがある。

Sitting in the Fire: Large Group Transformation Using Conflict and Diversity (English Edition)

Sitting in the Fire: Large Group Transformation Using Conflict and Diversity (English Edition)

対立や葛藤の炎の中で静かに座る、ということ。

ヨガクラスや静かな禅寺でだけ、リラックスができる、というのは、練習にはいいけど、実用的ではない。

武道でも、演劇でも要するに、緊張してしまう状況でいかにリラックスができるか、ということが大事。

気付きながら、行動する、ということ。

ビジネス環境やチームの中で行われるコミュニケーションや思考は、身体的なものだ。

体を上手く使う、というのが上達のポイントでもある。

どうやってリラックスするか

まずは、緊張していることに気づく。普段から、我々は相当身体中に力が入っている。それに気づくことが大事。

ヨガとか、フェルデンクライス、アレクサンダーとか色々ある。

あと、セラピーやカウンセリング的なもので心のシコリみたいなのが取れると力が抜ける、というのもある。

マニアックだが、個人的に好きなのはこんなの。

自分さがしの瞑想―ひとりで始めるプロセスワーク

自分さがしの瞑想―ひとりで始めるプロセスワーク

感情と共感とリーダーシップについてのあれこれ

共感とは何か

EQ(Emotional Intelligence)などで語られたりもするし、コミュニケーション、そして、リーダーシップの不可欠の要素として共感力(Empathy)が挙げられることが多い。近年注目されたマイクロソフトのCEOであるサティア・ナデラの本も、「共感」が一つのテーマだ。

Hit Refresh(ヒット リフレッシュ) マイクロソフト再興とテクノロジーの未来

Hit Refresh(ヒット リフレッシュ) マイクロソフト再興とテクノロジーの未来

ここでは、共感とそして感情について、自分の考えていることをつらつら書く。まとめたかったが、全くまとまらなかったのでポエム。

共感(empathy)の定義

共感力の重要性については、英語で語られるので、ひとまず、「empathy」の意味を確認する。

en.oxforddictionaries.com

上の辞書によれば、「empathy」とは「他人の感情を理解し、共有する能力」とのこと em(en)という接頭語は、「中に」というニュアンスもあるので、他人に感情移入したりする能動的な能力を含んでいるのだと思う。

共感(empathy)の種類

一般的に、共感力には「認知的共感(Cognitive Empathy)」と「情動的共感(Emotional Empathy)」の二つがあると語られたりすることが多いようだ。心理学のテストなんかでは、これらを別の能力として扱って測定したりする。

共感 の種類 意味
情動的共感 相手の感情を自分のことのように感情移入する能力
認知的共感 相手の状況、ものの見方を理解する知的能力

時々、認知的共感のことを純粋に、理知的で感情の共有も伴わない場合もある、とされる。後で書くが、おそらく、現実の共感力を語る上で両者を厳密に区別することは難しい。

共感力の基礎

共感は、多分、スポーツのプレイのようなもの。ある程度の心的体力とスキルがいる。

自分の感情への気づきと感じることの受容

自分の感情への気づき、というのは結構重要。人は傷ついていたり、怒っていたりするのに気づかなかったりする。抑圧された感情は、制御できない行動や、意図しない他人へのインパクトとなって、対人関係に影響する。

もう一つは、家族療法家バージニア・サティアの洞察だが、自分の感情に対する反応/感情というのがある。典型的には、悲しみや怒りのようなネガティブな感情が自分に生じたとき、ほとんど同時に、それに対する怒りなり、恐怖なりの自己防衛の感情が沸き起こることがある。これは注意深いリフレクションをしなければ原因は全く分からない。これも制御できない感情が対人関係をややこしくする。

大抵の場合、感情はそのまま受容する、否定しない、感じることを許す、というのがよりよい関係や、ストレスのない生活につながるように思われる。

ただ、人によっては、トラウマの蓋をあけてしまう、みたいなことになりかねないので注意が必要なものではある。

自分はネガティブな感情に対する耐性が相当強い方で、強いネガティブな感情とワークすることが苦にならないので、そうしたリスクは全く感じないのだが。。。

他者の感情への感応

感情は伝播する。一種のテレパシーといっていい。役者はその能力を表現に活用するし、学術的な研究もある。そのおかげで、ある程度の精度で我々は他人の感情を理解することができる。ただ、感情の伝播に対する感度は、ひとつには視力のようなもので強い人と弱い人がいるということ。また、人から影響を受けないように、それらを拒絶する反応を示す場合があるなどの理由で、他人の感情をあまり感じ取れない場合がある。

他人の感情を感じ取れたとしても、それを受け取ってどう扱うか、というのは、ちょっとスキルがいる。自分勝手な解釈をしてしまうのもよくないし、また、本人が気づいてないものを受け取ってしまったときなどそのままフィードバックするのも相手を無駄に傷つけ、自己防衛に追い込むことになる。

対人コミュニケーションにおいては、大抵の場合は、ただ、伝播してくる感情をそのまま拒絶せず受け取る、というだけでコミュニケーションがスムーズになったりするし、様々な気づきをえることができるようになると思う。

受け取ったものをフィードバックしたらいい場合もあるが、

  • 解釈を極力排除すること
  • フィードバックを受け取る用意が相手にあること。(同意を得るなどの方法で)

などがないと、うまくいかないことが多いと思う。

自己の感情と他者の感情の区別、そして、投影への気づき

感情の伝播と関係するが、相手の感情を受け取ると、それを自分の感情のように感じ取り、否定したりしたくなる場合がある。ある程度は仕方ないが、人の自然な感情まで否定してしまう時がある。 (感情的に)「ネガティブなことを言うな」 みたいなやつ。 これは多くの場合、自分の中にあるネガティブな感情が他人の感情を感じ取ることで自覚せざるを得なくなり、それを否定したくなって、関係のない他人を批判する、ということだと思われる。投影の一種。

本来的には、他人がどういう感情をもっていようが、自分とは関係ないはず。周囲の人間の感情を一定の状態に保とうとするのは、何らかの不合理な心的メカニズムが自分の内面にあるとみなした方がよいと思われる。

他者の状況の内在的理解

他人の状況を理解する、というのは、単に知的に分析するだけではなく、知的に再構築した他人の経験や状況を追体験し、感情も含めて味わうことで様々な視点を得ることができるように思われる。これは小説や映画、ドキュメンタリーをみたりすることでもできるだろう。最近の個人的な経験では、演技の練習はこれの良い訓練になる。

想像力を駆使した他者の状況の内在的理解、というのは、社会や組織の一見不合理なメカニズムを理解するための非常によい手がかりになると思われる。 もちろん、それらあくまで仮説で、事実にもとづいた検証にさらされなくてはならないのだが。。。

個人的に、リーダーに共感が重要なのは、対人コミュニケーションにそれが役立つ、という点ではなく、 情緒的共感と認知的共感の合わせ技によって、人間の相互作用システムを深く理解し、組織や社会における人間系システムに新しい関係性を構築する洞察を与えてくれる点にあると思っている。

2019-01-21 この本、著者の実体験と研究も合わさってよい本。

感情の問題地図 ~「で、どう整える?」ストレスだらけ、モヤモヤばかりの仕事の心理

感情の問題地図 ~「で、どう整える?」ストレスだらけ、モヤモヤばかりの仕事の心理

効果的なフィードバックについて

Engineering Manager vol.2 Advent Calendar 2018 の 23日目の記事。

現場のエンジニアとしてのリーダー、および研修講師としてのフィードバックを与えたり、受けたりする経験から、より、成長につながるようなフィードバックについて、つらつら書いていく。

ビジネスにおけるフィードバック

フィードバックという言葉は欧米のビジネスにおいては一般的な言葉として昔から使われていて、ずいぶん前から日本でも広まってきているように思う。限定的な意味としては、「業績評価」などを伝える評価面談などをフィードバックと呼ぶことがあり、よりカジュアルな意味としては仕事上の様々な局面での他者(上司含む)からの評価を伝えることをいう。
「ちょっとフィードバックするね。昨日のプレゼン、あれは少しユーザ相手には細かなこと言いすぎたんじゃないかな」とか

360°フィードバック、という人事制度を採用しているところもあるだろう。

フィードバックとは

フィードバックのもともとの意味は、あるシステムの出力の一部を入力に変換し、自動制御に役立てるメカニズムのこと。 よく言及される古典的な例として、機関車の調速機がある。スピードが上がるとその分スピードを下げるように働き、スピードを一定に保つ仕組みだ。調速機は、スピードが上がれば上がるほど、それとは逆向き(負)の入力に繋がるから「負のフィードバック」と呼ばれる。

f:id:masatsugumatsus:20181223004126j:plain

IT業界では、Scrumなどが広まっていることもあり、工学的な意味のフィードバックの方が馴染みのある人も多いかもしれない。(大学で制御工学などをやってきた人もいるだろう。)

ビジネスにおけるフィードバックの定義

G.M ワインバーグは著書『ワインバーグのシステム行動法』の中で、マネジメントに関わるフィードバック(効果的なものもそうでないものも)は次のように言えるという

  1. 過去の行動についての情報が

  2. 現在発せられ、

  3. 将来の行動に影響を与えたり、与えられなかったりする

フィードバックの重要性

人によるフィードバックは重要だと昔から言われている。古いマネジメントの文脈では、上位者が適切なフィードバック/評価によって、組織を統制し、部下をコントロールするために不可欠だ、と捉えられてきた面もあると思われる。

現代においては、

  1. 個々人の仕事能力の成長に不可欠であること

  2. 組織やチームの一員として存在を承認され、動機付けられること

などが挙げられるだろう。今回の記事は主にマネージャーやリーダー向け。

フィードバックの難しさ

フィードバックは難しい。
人は自分を客観的にみることは本質的にできないので、大抵の場合、他人からどう見えるか、ということを知らされると、自己認識と異なる事実に直面する。フィードバックに慣れていない、かなりの人は心理的なショックを受ける。

また、与える方もつらい。どんな強面で通っている人間も、実は目の前で人にショックを与えるということは非常に大きな心理的なストレスなのだ。だから、実社会では、あまり率直なフィードバックは好まれない。

さらに、与えられたフィードバックはあくまで、その発信者の主観的な情報であり、完全に客観的なものではない。フィードバックの発信者と受信者では、見解の相違の可能性は常にあり、これが効果的なフィードバックを難しくする。

次から自分が考える効果的なフィードバックを可能にするアイデアをつらつら書いていく。必ず常にこれをやったほうがいい、というわけではなく、ツールセットとして持っておくといいと思うもの。

明確なゴール/期待値の共有

フィードバックを与える前提として、明確なゴール/期待値の共有が相手と共有されているかを確認する。

フィードバックは、もともと、自律制御のためのもの。そもそもその人がゴールや期待値を知りえない場合は、どのように自律的に行動していいか分かるわけがない。必然、自己評価とフィードバックとの乖離は大きくなる。

もし誰かに時間をかけてタフなフィードバックをしなければならない、と感じたとしたら、フィードバックの前にそもそも「ゴール/期待値」が共有されているのか、ということを確認したほうがよい。

客観的なフィードバックシステム

フィードバックを与える前提として、客観的なフィードバックシステムを構築する。

自分がうまくやれているのか、ということを組織内の上司や同僚が教えるのではなく、客観的な情報から判断できるのであれば、本人にとっては、それがより行動を制御する正確な情報源となる。完了したタスク/バックログ、成果物の品質、各種のメトリクスなど。こうした客観的な情報が妥当で、分かりやすくなっているならば、人の解釈に基づくフィードバックをした場合も乖離は小さくなるし、フィードバックした意見の食い違いに対しても、客観的な情報を土台に議論できる。

注意するべきは、対面フィードバックでの心理的ストレスを避けようとして、「数字」に責任を押し付けること。個々人のスキルや行動特性の評価は複雑で、最終的には人の判断によってしか妥当な評価は不可能である。評価する責任からは逃げてはいけない。

フィードバックシステムが機能しているかどうかは、One On Oneなどの場で、どんな情報をもとに、仕事の出来を評価し、行動を調整をしているかを確認してみればよい。

いわゆるKPIは、本来は、こうした仕事の仕方を調整するのに役立つ情報を明確化するものでもあったはずだが、単に成績をつけるためのものになっている場合もある。

正確で客観的な事実に基づいたフィードバック

フィードバックの時に限らないが、言葉は正確に使う。

「スキルが低い」といった抽象的なおおざっぱな評価ではなく、合意可能な事実を土台に、自分の評価を伝える。また、追従的お世辞なども不要。フィードバックを与える前に、自分の評価や印象が、どのような観測事実からどのような推測を経て生み出されたのかを振り返るといいと思う。

小さく、早めのフィードバック

特に組織への新規参入者やスキルが未熟なメンバーに対するフィードバックはよく観察して、認識齟齬やスキル不足があれば、早めにフィードバックしたほうが良い。

ポジティブフィードバック

ポジティブなフィードバックを与える。

仕事している普通の状態は組織に貢献している状態。そのため、貢献できなくなった異常事態の方が目立つし、我々は本能的にそれに注目する。しかし、当然日々の仕事の過程のなかで個々人なりの強みの発揮も、工夫も、努力も、成長もある。これらを達成することは、トラブルを復旧するのと同等のエネルギーを注いでいる。また、こうした細かな改善やエネルギーの投入が現実のビジネスを支えている。こうした目立たない行動に対してもポジティブフィードバックを与えると、その行動を強化することになる。

まずは、こうした目立たない努力や成果とその重要性に気づくことが大切と思う。それに気づければ、自然とポジティブフィードバックは多くなると思う。とはいえ、どうしても見落としがちではあるので、意識的にフィードバックを多めにした方がよいと思う。自戒も込めて

観察をじっくりできない場合などは、面談のときなどに自己評価してもらって、ポイントを教えてもらうといいと思う。どんな小さなことでもよいから、と。教えてもらえるとそれを見つけるのは、比較的楽になる。見つけたら、それを伝えるとポジティブフィードバックになる。

注意点として、ポジティブフィードバックも当然、事実に基づいたものであるべき。抽象的な称賛は自尊心を満足させはするけど、行動への影響は小さい。また、単に頑張っていることを評価するのではなく、目立たないけど実際に貢献している、ということを評価するべき。

大きな貢献に対しても、しっかりとポジティブにフィードバックすべき。照れてフィードバックしない場合もあるが、有能な人材のモチベーションをそぐことになる。

フィードバックとは関係ないが、予想外に大きな成果を誰かが挙げた場合、しっかりとその要因を探ってチームに還元しよう。自然にチーム内に還元できる文化があるのが理想だが、できてない場合はマネージャーがそれをやる、もしくはやる文化を作る。

Iメッセージとしてのフィードバック

フィードバックは「Iメッセージ」として与える。

「自分にはこう見える、こう受け取った。こう思った」ということ。フィードバックはあくまで「情報提供」であり、それをどう受け取るか、は本人が決めるしかない。その選択の自由を明示的に与えること。ただし「Iメッセージ」は事実である、ということはしっかりと合意したほうがいい。

また、可能なら、フィードバックをどう受け取ったか、については確認してもいい。感情的に受け取れないときは、その状況を受け入れて時間を与えることも有効。

繰り返すが、フィードバックをどう受け取るか、は強制できない。人は本質的に自律的に行動する。指示待ち人間と周囲から見えても、彼にとってそうすることが合理的に思えたから、それを意識/無意識に選択している。だから、フィードバックを受け取ることを強制しようとすれば、必ずその場では受け取ったふりをするし、受け取ったように見られるための見せかけの行動をせっせと行うようになる。フィードバックする目的は現実の行動変容やスキルの向上を実現し、ビジネスの成果に結びつけること。うわべの追従を生み出すことはそれに結びつかず、その場でのマネージャーの自尊心を満足させるだけ。

個人的な経験では、目的も共有され、事実に基づいたフィードバックがされているのに、それに抵抗する場合は、スキルに不安があり、失敗を恐れていることが多い。支援することを提案したり、失敗も許容するなり、時間を与えるなりをすると、客観的な議論が可能になる。

できないものはできないし、誰もできない状態のままでいたいわけはないので、さぼっているわけでもない。客観的に、事実に即してスキルを向上させるなり、やり方を変えるなりするしかない。

自尊心に配慮する

ネガティブフィードバックのときには自尊心に配慮する。

だれも面子ををつぶされたくはない。状況にもよるが、もし、人にネガティブなフィードバックを聞かれるのを嫌がるようなら、人の見えないところに移動するなどしてもよい。

人格否定をしないことは当然だが、人はやはり、人格と仕事の評価を結び付けてうけとってしまうことも多い。そのため、明示的に本人の人格評価はしていない、と伝えることが有効なこともあると思う。おそらく、最も有効なのは、フィードバックを与える人自身が、仕事の成功失敗を人格評価と結びつけるという考え方を一切やめることだと思う。

否定的な評価や失敗について指摘されることを過度に恐れているようなら、「失敗は誰にでもある」、「経験がないことには誰でもスキルが未熟」、「人はだれしも得手不得手がある」、「パフォーマンスは状況に左右される」、「現実と向き合うことが重要」などの一般的な認識(経験も含めて)を共有するのが、個人的には有効と感じている。こうしたとき、自尊心に結びついた過度な完璧主義が成長を阻害している。失敗を自分自身に許容する態度が可能だということを理解できると、上手く成長軌道に乗る場合も多い。

暗黙のフィードバックに注意

フィードバックは、必ずしも意図したものだけが受け取られるとは限らない。仕事のアサイン、ポジティブフィードバックの不在、など意図しない行為が暗黙のフィードバックになって影響を与える。

心配しても仕方ない面もあるが、細かなコミュニケーションからどのようなフィードバックがチームや組織に「実際に」機能しているのかを把握することが大切。

自分からフィードバックをうけとる

自分からフィードバックを受け取りにいく。

自分のマネジメントの改善になるため非常に有効。効果的なマネジメントの下ではフィードバックも効果的になる。フィードバックを受け取るときも、自分が与えるときのポイントをそのまま適用する。

  • 組織の目標や期待値(マネジメントの責務)を共有する(マネジメントの責務の定義は自己防衛に走らないように気を付ける。完璧には決して出来ない。組織/チームの長期的な成果に貢献できる責務を定義する。)

  • 自分のマネジメントについての客観的なフィードバックシステムを用意する

  • 正確で客観的な事実に基づいたフィードバックを求める。(抽象的だったりしたら、具体例を聞くなど)

  • 特にマネジメント初心者の場合は、小さく、早めのフィードバックを求める

  • ポジティブフィードバックも求める

  • フィードバックは、Iメッセージに過ぎないので、どう受け取るか、は自分で決めることができる

  • 自分の自尊心に配慮していい。非難されても、完璧主義に毒されないこと。

  • 無言のフィードバックに、時には注意してみる。また、勘違いして受け取っている場合もある。

追記(2019/01/07)

大事なこと忘れてた。フィードバックの情報量は、相手が受け取れる量に絞り込む。余裕で受け取れる、ぐらいにしないとだめ。消化できる情報量は個人差、および、前提知識によって差があるので、適宜調整すること。

個人的なおすすめ本

リーダーが育つ変革プロジェクトの教科書

リーダーが育つ変革プロジェクトの教科書

第9章がフィードバックに割かれている。 カジュアルにポイントが書かれている。

ワインバーグのシステム行動法 ソフトウェア文化を創る (3)

ワインバーグのシステム行動法 ソフトウェア文化を創る (3)

ソフトウェアエンジニアリングマネージャーとしての効果的な対人コミュニケーション全般について書かれた名著。 フィードバックについては17章。

ワインバーグのシステム思考法 ソフトウェア文化を創る〈1〉

ワインバーグのシステム思考法 ソフトウェア文化を創る〈1〉

フィードバックシステムのマネジメントへの応用について。ちと例が古いので、今時の若者は読み解くのが難しいかも。

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

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

自尊心の扱い方について参考になる。

What Did You Say? The Art of Giving and Receiving Feedback (English Edition)

What Did You Say? The Art of Giving and Receiving Feedback (English Edition)

かなりがっつりフィードバックについて。面白い。

The Managerial Moment of Truth: The Essential Step in Helping People Improve Performance (English Edition)

The Managerial Moment of Truth: The Essential Step in Helping People Improve Performance (English Edition)

フィードバックそのものではないけど、部下育成の効果的な面談法について。 日本語に昔訳されているけど、到底おすすめできる翻訳になっていないので割愛。

定番。

補足:管理しないについて

ソニックガーデンのように、「管理しない」を採用している事例もあるが、実際にどのようなフィードバックシステムが存在するか、をみてみると、実は不思議でもなんでもない。

  • 成果に直結するソースコードはチームでレビューされている。

  • 顧客ビジネスに役立っているかはプログラマが直接顧客と相対しているのでそこからフィードバックを得られる。

  • アジャイルで小さく開発しているので、フィードバックが小まめで小さい。

  • スキル評価は、実は一人前になるかならないか、というポイントでキチンと行っている。

要するに、細かな「評価」はしないけど、組織のビジネス成果につながる効果的なフィードバックがデザインされている。