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

リラックスすること

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

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

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

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

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

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

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

緊張に気づくこと

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

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

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

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

武道におけるリラックス

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

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

Sitting in the Fire

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

共感とは何か

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

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°フィードバック、という人事制度を採用しているところもあるだろう。

フィードバックとは

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

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

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

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

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

2. 現在発せられ、

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

フィードバックの重要性

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

現代においては、

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

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

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

フィードバックの難しさ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

自尊心に配慮する

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

追記（2019/01/07）

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

個人的なおすすめ本

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

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

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

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

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

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

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

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

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)

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

HIGH OUTPUT MANAGEMENT(ハイアウトプット マネジメント) 人を育て、成果を最大にするマネジメント

定番。

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

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

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

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

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

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

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

緊張構造（Structural Tension）をつくる

緊張構造は、ロバート・フリッツのメソッド。

自分なりにようやく理解して、体得してきた感じがするので、一度ここで理解していることを書き出してみたいと思った。知っている人向けの記事。

少し考えると、やはり、言葉で説明するのは難しい、と悟った。あまりにも単純だから。その難しさはここに書いた

medium.com

だから、ここでは、「この記事を書く」ことを緊張構造を利用してやってみて、そのプロセスを記述してみる。

ビジョンを描く

まずは、ビジョンを描く。ビジョンは、自分が創り出したいもの、目の前に存在するすることを望むもの。それを現実的に思い描いた。

・緊張構造についてのブログ記事（内容はもやっとしている）

・ロバート・フリッツのメソッドを学んだことのある人が読んで、理解と実践の助けになるもの（映像を思い描いた）

この時点で、色々な邪魔なものが頭をかすめる。知らない人が読んでも面白くない記事を書くのはどうか、グダグダの記事を書くと評判を落とすのでないか、やっぱり言葉で説明するのは難しいよな。。。多くが自意識の問題。とりあえず横にどかして、目標に集中する。

達成しなきゃならない、という強迫観念も捨てる。実現したい未来をドンと置く、というイメージ。

ビジョンから現実をみる

次に現実をみてみる。自分は今ここで自分の目に映るものに意識を移してから考え始める。

・記事はできてはいない。

・mediumの記事は書いた。

・新しい知識は不要。現時点での理解を共有すればよい

そうこうしているうちに、行動したい衝動が起こる。というより、体が勝手に動き始める。感情の高ぶりはない。坦々と行動しだす。

書こうと思うと、アイデアが湧いてくる。

言葉で説明するのは本質的に難しい。

だから、主観的体験を共有すればよい。限られた読み手のささやかな助けになることがビジョンだ。

この記事を書くプロセスをそのまま書いてみたら、たぶん助けになるだろう。

アクションプラン

 書き始めればよいし、すぐ書き始められる、と分かった。

ここまで書いてみて、読み直して確認する。振り返りを書いた方が読む人の助けになる、と思って振り返りを書く。

やってみての振り返り

・エネルギーはビジョンと現状をセットアップすると流れ出す。アクションプランはその結果。

・感情の高ぶりは一切なかった。（ある時もあるだろう）

・ビジョンは、描くとき、現状をみるとき、やっているとき、にどんどん形を微妙に変え、明確になっていった。アクションが終わったとき、ビジョンは現実になっている。

・自意識は常に邪魔しに来る。それを脇にのける。

ソフトウェアアーキテクチャとサッカーにおけるプレーモデル

共通イメージ

最近、ワールドカップシーズンのみのにわかサッカーファンとして、色々な動画やら、本やらを読んでいた。

youtu.be

サッカーの新しい教科書 戦術とは問題を解決する行為である

本の中で、「プレーモデル」という言葉がでてくる。ようするに、プレーについての監督、選手が共有する、どう戦い、何をすべきかの共通イメージである。複雑系スポーツであるサッカーでは、コンビネーションの秩序を得るためにプレーモデル、という共通イメージが必要ということだ。

ここから発想したこと

多分、サッカーでプレーモデルとされているのは、チームとしてどうプレーするのかの共通理解。
ソフトウェア開発においては、多分、
ソフトウェアアーキテクチャ
プロセスモデル
のふたつがそれに該当すると思う。

— 松下正嗣 (@masatsugumatsus) 2018年7月14日

つらつら書いてく

ソフトウェアアーキテクチャとは

ソフトウェアアーキテクチャの定義としては、色々IEEEとかの定義があるが、

IEEE 1471 - Wikipedia

個人的にはあまり、有用と思えない。不正確とも思わないけど、「So What?」な定義になっている。実際に仕事するとき、自分が念頭に置いているのは、マーチン・ファウラーが『エンタープライズアーキテクチャパターン』で記載した、Ralph Jonson(デザインパターンのGang Of Four の一人？)の言葉

アーキテクチャとは、主観的要素であり、プロジェクト内の熟練開発者がシステム設計に関して共通して理解していることに過ぎない。

 ファウラーはこれに加えて、「変更しにくい」「重要なもの」という要素を何となく付け加えている。

つまり

アーキテクチャとは

• 主観的要素であり
• 熟練の
• 開発者たちが共通して理解している
• システム設計についての事柄で
• 変更しにくく
• 重要なもの

 である。

個人的には、

「熟練の」というのは不要。古い大規模開発とかだと、プログラマにアーキテクチャについての理解を求めない場合もあったかもだけど、現在の規模やプロセスでそれを区別する意味はない。

「変更しにくく」も不要。今のエンジニアリングではほとんどのものが変更容易になっている。もし変更しにくいのは、多くの開発者の「共通して理解」していることだからだとおもう。

「重要なもの」も不要。共通理解が重要である、てこと以上のものはないと思う。

また、「システム設計」には当然プログラミングも含む。

だから、個人的な定義はアーキテクチャとは

アーキテクチャとは、主観的要素であり、チーム内の開発者が、システム設計/プログラミングに関して共通して理解している事柄

である。

これはサッカーにおけるプレーモデルの概念ととても近いと思う。

ソフトウェアアーキテクチャは何のために定義するのか

ソフトウェアアーキテクチャは何のためにあるのか。ここで、サッカーにおけるプレーモデルの概念が参考になる。

 ボール 保持 者 と その 味方 が お互い の こと を 理解 し、「 この 選手 は ここ で ボール を 受け て 壁 パス を したがっ て いる」 という よう に、 味方 の 次 の プレー を わかっ て いれ ば、 動き出し も 早く なる はず です。

この よう に し て 共通 の イメージ を 持つ こと で、 息 の 合っ た コンビネーション プレー が 実現 する の です。 少ない タッチ 数、 特に １ タッチ での コンビネーション プレー という のは、 どんなに 緻密 に 形成 さ れ た 守備 組織 で あっ ても 突破 する こと が 可能 です。 チーム という のは 選手 の 集まり で 形成 さ れ、 各 選手 は お互い の 性格 や 考え方 を 理解 し て いる 方 が よく 機能 する の です。

坪井 健太郎. サッカーの新しい教科書　戦術とは問題を解決する行為である (Kindle の位置No.179-187). . Kindle 版.

つまり、共通イメージをもつことでコンビネーションが促進される。また、意思決定を柔軟に、素早く行う効果もある。

note.mu

また、ソフトウェアは開発し始めたばかりのときは、設計の選択肢は無限にある。だから制約を見つけることは開発の障害であるよりは、より考えることを絞り込めるため、開発を促進する。

制約は味方である。G.M.ワインバーグ

ソフトウェアアーキテクチャ定義、アーキテクティングとは、変化していく要求に対応して開発を駆動していくために、設計とプログラミングにおけるチーム内での共通理解を作り上げ、維持、変更していく行為なのだと思う。

どんなものがソフトウェアアーキテクチャなのか

ソフトウェアアーキテクチャの例として挙げられるのは、論理的に演繹できるもの、というよりは、経験的に、共有していた方がよいとされる認識のあつまり、なのだと思う。

例えば、

• 物理/論理構成
• 採用するフレームワーク
• 採用するコンポーネント分割指針（モノリシックか、マイクロサービスか、MVC、DDDなどのパターンをどのように取り入れるか、など）
• コーディングガイドライン
• テスト戦略

例えば、RDBのテーブル構造を「技術的詳細」としてアプリケーションから隠ぺいするのか、それとも、アプリのモデルとして扱うのか、といった見立てと判断も含むと思う。

これらは文書化されることもあれば、フレームワークやツール上に実装されることもある。文書化されず、文化として保持される場合もあるとは思う。

もちろん、これらを共有するためには一定水準の共通知識が必要。スペインのサッカーでは、プレーモデルを実現する前提として、様々な概念、知識（サッカーの教科書）が育成年代からトレーニングを通じてインストールされているという。

youtu.be

ソフトウェア開発でも同じで、アーキテクチャを理解するための基礎知識は必要なんだろうな。それがあると、個別具体的な状況に合わせた対応ができる。

チーム外のステークホルダーとアーキテクチャ

伝統的なアーキテクチャの考え方として、チームやプロジェクト外のステークホルダーとの合意が重要とされることがある。自分の定義だとその観点はでてこない。ただ、別に普通のシステムに対する要求事項として扱えばよいと思うので定義を変える必要はない。

どうせ、ステークホルダーがレビューしたり、合意したりする場合はそれ向けのドキュメントなりを提示しなければならない。

追記

どんなものがアーキテクチャでないか

• 開発者に認知されないドキュメント
• 個別機能の設計やプログラミングを助けない制約
• 共有する必要のない、一部機能やコンポーネントの詳細

追記

フレデリック・ブルックスのアーキテククチャの定義

• 利用者に知覚される製品の定義

つまり、そのシステム/ソフトウェアとはなんであるか、のイメージ。アーキテクチャは実装ではない。

Jim Coplien氏の認定スクラムマスター研修に行ってきた

アギレルゴコンサルティング社主催の7月2日〜3日に実施されたJim Coplien氏の認定スクラムマスター研修に行ってきた。

Jim Coplien - Wikipedia

認定制度には懐疑的なんだけど、個人的にJim Coplien氏の本は好みのものが多く、彼のスクラム・パターンの研修を受けて非常に感銘を受けたので、今回認定スクラムマスター研修に行ってきた。

以下は面白かった点の備忘録。自分の貧弱な英語で通訳なしで聞いた結果なので聞き間違いや、勘違いもあるかも。（通訳は提供されてたが、自分は使わなかった。）

また、色々主張は強いが、質疑応答などでも現場のコンテキストを尊重する姿勢があった。機械的にこうやれ、と言っているわけではないとおもう。高みを目指すなら正しいのは、こっちだ！という主張と理解している。

• スクラムアライアンスとスクラムを一緒にするな
• 開発マネージャーというのはない。チームがやる。マネージャの仕事は部署間調整などチームが働く環境を整えること、そして大幅な組織改革「カイカク」をやる。チームがやるのは「カイゼン」
• 基盤となるようなビジネス要求というのは、実は安定している。変化するのは要求の理解である。
• ユーザストーリーはバックログに入れるものではない。バックログに入れるのは、要求/機能、技術、課題である。ユーザストーリーは要求を理解するためのコミュニケーションに使うもの。
• JIRAのようなバグトラッカーは無駄である。バグはすぐ直す。バックログ管理は簡単なExcelシートで充分。
• 研修のようなものもバックログに入れる。そうでないとチームから時間を奪うことになる
• ユニットテストは無駄。システムテストは無駄だけど、現時点では必要
• 完了は完了（DONE is DONE）。それ以上やることがないこと。リファクタリング、文書作成、システムテスト、性能テスト、デプロイ。全部終えて完了。POと合意する。
• 信頼を築くには、まず、自分から信頼すること。
• 心理的安全性は単なる結果。パーソナルな問題も持ち込んでいい。もし、心理的安全性を保つために、パーソナルな問題に踏み込まなかったり、壁を作っているような場合、それは病んでいるってことじゃないの？信頼が大事。
• デイリースクラムでは、ペットが死んだ、みたいなものも共有して良い。開発の障害は全て。スクラムは全体性。仕事と個人を分ける必要ない。
• チームがコミットするのはスプリントゴール。スプリントゴールによって、一体感を醸成する。
• POが出してきた要求にもチャレンジすることが大事
• アジャイルコーチを雇っても、開発チームと接触しない。スクラムマスターに対してコーチングする。（どこまで強い主張かは不明）
• スプリント毎の振り返りでは、浅い振り返りになる。年に３日とか使ってしっかりと振り返りをして改革につなげたりする。
• ベロシティなども統計的に管理する。一度ブレただけで次の予測を変える必要はない。３スプリント連続で変わったりするなら再考必要

前から思っていたけど、ＰＯの役割が死活的に重要と改めて感じた。製品ビジョンを持ち、製品機能を定義し、ＲＯＩを想定しながら、順位付けをしていく。開発者の助けを借りて、やるのだけど、かなり技術にカンが働かなければ難しいとは思う。そもそも、トヨタのチーフ「エンジニア」の役回りの一部らしいので。

講師によっては、開発者が考える、と割り切って伝えている場合もあるようだ。

dev.classmethod.jp

coplienさんは、はっきりとは確認してないけど、基本的には開発者の助けを借りて、ＰＯが書く立場と思う（開発者も含めたステークホルダーは追記できはする）。プロトタイプを開発チームに渡して説明したりする、ということも言っていた。

ロールを全うするには、個人的には、ＲＯＩに責任もてない開発者がとやかくいうのではなく、ＰＯチーム側にエンジニアリングがある程度分かる人が入ったりする必要があるんではないか、と思った。

最後まで、内製チームを想定しているみたいだったな。受託でやるときは、顧客側がＰＯチームにバックログアイテムの検討を支援するエンジニア/コンサルタントを、開発チームと別契約で結んで支援してもらえばいい、と思った。コンサルティング契約とかと似たようなもの。スクラムマスターは開発チームが必要に応じて連れてくればよい。

追記①----

• 多分、スプリントプランニングの時と思うけど、３本指テストでPBIをやり切れるか、の自信を試すといい。

追記②----

上に引用したブログによると、POは顧客ではなく、開発者の組織がやり、チームのROIに責任をもつ、とある。正直、自分には「チームのROI」の意味が理解できないし、プロダクトを実際に利用する顧客ビジネスのROIがスクラムのプロセスの中のどこで考慮されるのかが、分からないから、それはbad ideaじゃないかな、と思っている。

とはいえ、それで上手くいく場合も絶対あると思う。というか、そのほうが上手くいくことがほとんどかも。実際、スクラムじゃなくても、SIとかでは、顧客が考えられない場合、製品ビジョンは開発者側が考えちゃったほうが上手くいくこと多いと思う。全体的にくだんの講師のかたは現実解みたいなものを伝えている気がする。

でも、個人的にはそれには限界があると思うので、やはり高みを目指すなら、ということ。

 追記③----

coplienさんから回答が来た！

Great post! You are right — the developers help the PO with the tests, as they might help her with everything. But the PO does most of the work specifying the tests and has the final word on what end-user functionality to test and what the results should be.

— James Coplien (@jcoplien) 2018年7月7日

以下翻訳。

開発者は他のあらゆる面でPOを支援するのと同様に、テストによってPOを支援する。でも、どんなテストを実施するのか、を特定するためのほとんどの作業をPO自身が行う。そして、POがテストすべきエンドユーザー向けの機能とその機能が何をもたらすか、についての最終決定権を持っている。

google翻訳で読んだのかな？もしくはまだ、日本にいるから、誰かに訳してもらったのかも。 

追記④----

ユニットテストが無駄である旨の記事

https://rbcs-us.com/documents/Why-Most-Unit-Testing-is-Waste.pdf

上記記事のからの引用

• Keep regression tests around for up to a year — but most of
those will be system-level tests rather than unit tests.

回帰テストは続けろ。でも、そのほとんどはユニットテストではなく、システムレベルのテストだ。

• Keep unit tests that test key algorithms for which there is a
broad, formal, independent oracle of correctness, and for
which there is ascribable business value.

広範性、形式性、独立性、正確さがあり、ビジネス価値に帰結する中心的なアルゴリズムに関してはユニットテストを維持しろ

（ビジネスルールのアルゴリズムとか？）

• Except for the preceding case, if X has business value and you can text X with either a system test or a unit test, use a system
test — context is everything.

上記以外の場合、そのコードがビジネス価値を持ち、システムテストでもユニットテストでもテストできるのなら、システムテストを採用しろ。コンテキストが全てだ。

• Design a test with more care than you design the code.

プロダクトコードをデザインするより注意深くテストをデザインしろ

• Turn most unit tests into assertions.

ほとんどのユニットテストをアサーションに変換しろ

• Throw away tests that haven’t failed in a year.

1年間テストして、失敗しなかったテストは捨てろ

• Testing can’t replace good development: a high test failure
rate suggests you should shorten development intervals,
perhaps radically, and make sure your architecture and design
regimens have teeth

テストはよい開発を置き換えたりはできない。高い失敗テストの比率は、開発のサイクルを短くするべきであることを示している。さらに、根本的には、アーキテクチャと設計に改善の余地が大いにあることを確証している。

• If you find that individual functions being tested are trivial,
double-check the way you incentivize developers’
performance. Rewarding coverage or other meaningless
metrics can lead to rapid architecture decay.

もし、テストされた関数が些細なものであったなら、開発者をどのように動機付けしているのかを厳重にチェックしろ。カバレッジやその他の無意味なメトリクスはアーキテクチャを劣化させる。

• Be humble about what tests can achieve. Tests don’t improve
quality: developers do. 

テストが達成できることに謙虚になれ。テストは品質を向上させない。それは開発者しかできない。

IntelliJ IDEAハンズオン に行ってきた

こちらにいってきた。

samuraism.doorkeeper.jp

仕事で使っているわけではなく、個人用に有償版を何年か前から購入させてもらっていたのだけど、使いこなせている感が全くなかったので参加。ツールを追求するのは苦手。。。

仕事ではEclipseだけど、使いこなせている感覚はない。。。

当日のカリキュラム

・JetBrains社の紹介
・製品紹介
　・TeamCity/Upsource/YouTrackなどのチーム開発製品の紹介
　・各種開発ツール
・ハンズオン

　・キーマップなどの初期設定

　・ショートカットと補完機能をフル活用したFizzBizz

　・デバッグ機能

　・Git

・クーポンなど
・質疑応答

注意点

感想その他

・チーム開発のツールは少人数なら無料みたいなので必要なら積極的につかってみたらよさそう。Upsourceがよさそう。

・コード補完機能は、変数の宣言と初期化が「値.var」「変数.if」や条件式.notでコード生成したり、条件式変更してもらえたり、これは、全く知らなかった。。。流れるようにコーディングできて、使いこなすと生産性がかなり変わりそうな印象。

・デバッグ機能は、Eclipseでも使いこなしていなかったけど、実際に目の前でデモしてもらうと分かりやすかた。

　※特定の条件でのみブレークポイントで止まるって機能、Eclipseにあったっけ。。。

・有償のChrononデバッガーがインストール可能なのでそれも使える、とのこと。業務ではまったときとかは使えそう。

Chronon Time Travelling Debugger | Chronon

・Gitの機能もほとんど使ってなかったのでやくだった。一部だけコミットしておくとかって結構使えそう。

結論

・時間は金で買える。

・そして、使いこなすのに時間を使うくらいなら、ハンズオン依頼しちゃうのがいいと思った。