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

JIGも素晴らしかった。 

効果的な研修について

研修の有効性

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

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

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

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

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

効果的な研修とは何か。

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

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

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

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

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

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

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

mattun.hatenablog.com

実例

• 柔道における「崩し」と「つくり」と「掛け」。ただし、洗練度はいまいち。

• 演技におけるスタニスラフスキーシステム。これは本当のイノベーション。

  俳優の仕事―俳優教育システム〈第一部〉

  演技ー創造の実際―スタニスラフスキーと俳優

• オブジェクト指向のこころ。デザインパターンそのものは、教授可能なモデルとしては洗練度がいまいち

  オブジェクト指向のこころ (SOFTWARE PATTERNS SERIES)

• ワインバーグの有機的リーダーシップ論。ＭＯＩ

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

• スペインサッカー

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

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

リラックスすること

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

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

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

コンスタンチン・スタニスラフスキー - 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

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

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

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

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

追記

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

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

追記

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

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

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