$shibayu36->blog;

クラスター株式会社のソフトウェアエンジニアです。エンジニアリングや読書などについて書いています。

文化による知覚・認識・行動への影響を知る - 異文化理解力を読んだ

異文化理解力という本がおもしろいと聞いたことがあり、興味があったので読んだ。想像以上に面白く夢中になって一気に読んでしまった。

この本は、国ごとの文化が、そこに属する人々の知覚・認識・行動へどれほど影響を与えているかを教えてくれる。指標として8つを提示し、それぞれの中で各国がどのような位置にいるかを相対的に示してくれる。8つの指標とは次のようなものだ。

  • コミュニケーション:ローコンテキストvsハイコンテキスト
  • 評価:直接的なネガティブ・フィードバックvs間接的なネガティブ・フィードバック
  • 説得:原理優先vs応用優先
  • リード:平等主義vs階層主義
  • 決断:合意志向vsトップダウン式
  • 信頼:タスクベースvs関係ベース
  • 見解の相違:対立型vs対立回避型
  • スケジューリング:直線的な時間vs柔軟な時間

個人差はあるものの、国によって知覚・認識・行動のベースラインが相当異なると知れたのは良かった。とくに日本は極端な位置に配置されることが多く、グローバルなコミュニケーションを取る時は気をつける必要がある。たとえば日本は超ハイコンテキストであり、ネガティブ・フィードバックはもっとも間接的に伝え、階層主義的なのに合意志向が極端に強い。この考えのままグローバルなコミュニケーションをすると、別の国の人には何も伝わらないし、別の国の人からは日本人は行動が遅いと言われる可能性がある。自分たちがどの位置にいるかを知った上でコミュニケーションを取るとより円滑にものごとを進められそうだ。

また、特定のベストプラクティスを取り入れるときに、そのベストプラクティスがどの国の文化をベースにしているかも大事そうだ。たとえばスクラムに関連するプラクティスを導入しようと考えた時、日本とは全然違う文化のもとで作られたものをそのまま日本企業に導入しようとすると、そのベースとなる考え方が違いすぎてうまく行かないということがありそうだ。ベストプラクティスはいろんな文脈でもうまくいくことが多いように作られている傾向にあるが、いきなりそこに向かわずに文化に浸透する形で改変しつつ、徐々に良い方向に向かわせるのが大事と感じた。

示唆に富む内容だったので非常にオススメな本だった。とくにいろんな国の人がいる企業で働いている場合にはかなり参考になることが多いと思う。

多様性の力を知る - 多様性の科学を読んだ

タイトルを見てなんとなく興味が惹かれたので読んだ。想像以上に面白くてためになった。

多様性の科学

多様性の科学

Amazon

自分はこの本から多様性が実際に何に役立つかを学ぶことができた。世の中では多様性が大事と非常に多く言われている。しかし自分は多様性の高さによってどのような効果があるかについて理解ができていなかった。この本はいろんな観点から効能について教えてくれる。例えば興味深かったところは

  • 人の物事の捉え方には、ただものを見るという単純な行動にさえ、文化に基づく違いがある。ある問題において、見方が多様な集団を作ることにより、新たな捉え方や落とし穴への気づきが得られる
    • 逆に同質な集団の場合、考えていることが正しいと周りも同意するため、それが間違っていたとしても信じてしまう
    • 賢い個人がいるだけでなく、解決しようとする問題空間の中を網羅するような多様な構成にすべき
  • ある集団の平均値を用いて標準的な何かを作ると、逆に誰にも便利ではないものが出来上がってしまう
    • パイロットのいろんな部位の身体計測をして、それを元に標準的な戦闘機を作ったら、墜落率が高かったみたいな話題。サイズをカスタム可能な戦闘機にすると墜落率が下がった
  • 心理的安全性がない集団では、もともと多様性が高い集団だったとしても、支配的なリーダーの思想に寄っていってしまい、多様性が低い状況になってしまう

これ以外にも色々となるほどなーと思うことが多かったのでおすすめです。

読書ノート

- 人の物事の捉え方には、ただものを見るという単純な行動にさえ、文化に基づく違いがある 26
    - 違う見方をするもの同士が協力し合えば、ひとりの時より多くの発見が得られる 28
    - 同じような人々の集団は盲点も共通しがち。その傾向を互いに強化してしまうため、不適切な判断や完全に間違った判断にも自信を持つようになる 34
- チームで難問に挑む際にまずやるべきことは、問題そのものをさらに精査することではなく、一歩下がってこう考えること。カバーできていないのはどの分野か、無意識のうちに盲点を作ってしまっていないか、画一的な人間ばかりで問題空間の片隅に固まっていないか? 70
    - 問題空間と領域の例
    - 集合知を得るには、賢い個人と、同時に多様性も欠かせない。そうでなければ同じ盲点を共有することになる 76
    - 多様性を満たすためには、対処する問題と密接に関連し、かつ相乗効果を生み出す視点を持った人々を見つけることが鍵になる 83
- 多様性豊かなチームに支配的なリーダーがいた場合、多様性が下がる 115
    - 心理的安全性が高いことは、多様性を下げない利点になる 140
- 多様性を損なわない会議テクニック 143
    - 会議前にまとめたメモを黙読した時間を作り、他人の意見が入る前に個々が考えられる時間を作る
    - 会議が始まったあと、最も地位の高いものが最後に意見を述べる
    - 誰のアイデアかを明らかにしない
- 人は大きなコミュニティに属すると、より狭いネットワークを構築する傾向がある 207
    - 交流できる人の数が多いなら、自分と似ている人の数も多く、細かい選り好みができる
    - 小規模なコミュニティに属すると、逆に多様な人間とのコミュニケーションがなされる
- 平均値が適切に利用されれば複数の人々の視点や意見を活かせる。しかし不適切な場合には、複数の人々に平均的な答えを押し付けることにしかならない 251
    - 気づき: 標準化の罠とも近い
- 「標準的な」「誰にでも当てはまる」食事療法というのは基本的にない 256
- 日常に多様性を取り込むための3つのこと 292
    - 無意識のバイアスを取り除く
        - 採用で履歴書の目隠しをする、など
    - 陰の理事会
        - 重要な戦略や決断について、若い社員が上層部に意見を言える場
        - 上層部にとっては、多様な意見に触れて視野を広げる「テコ入れ」の機会になる
    - 与える姿勢
        - 多様な社会で、自分の考えや知恵を相手と共有する「giver」は、他の人から知恵を受け取る機会を得られ、成功を収めやすい

セキュリティが満たされやすい設計を学ぶ - セキュア・バイ・デザインを読んだ

設計やアーキテクチャについて学び直したいと思い、今回はセキュア・バイ・デザインを読んだ。

この本の作者は「オブジェクト指向入門」という本の思想に共感しているようで、自分もその本が大好きなので、共感できる内容が多かった。またDDD周りで定義されている用語を教えてくれるので、その辺りがぼんやりしてきていた自分にとって、再度学び直すきっかけになった。

以下のトピックが印象に残った。

  • 集約によって、複数のエンティティの状態変化を常に正しくできる。論理的なトランザクション(DBのトランザクションではない)を作れるということ
  • 妥当性確認は以下の順で行うことで、より負荷のかかる高度な妥当性確認を不必要に実施することを防げる
    • オリジン:正当な送信元
    • サイズ:適切なデータサイズ
    • 字句的内容:正当な文字のみで正しくエンコード
    • 構文:正しいフォーマットか
    • 意味:意味的に正しいデータ
  • ドメイン・プリミティブというものを作ることで、値自体が有効であることを保証する仕組みを作れ、セキュリティを上げられる

読書ノート

- ドメインプリミティブ 23
    - クラス生成時にドメインの制約を満たしていることを保証する
    - [ドメインプリミティブについて - Qiita](https://qiita.com/daikon510/items/ab70d61300bd2c641652)
- ユビキタス言語は、境界づけられたコンテキストの中のみ有効 95
- エンティティとは 97
    - 自分自身を特定できる識別性(identity)を持っており、他のエンティティと区別できるようになっている
    - 識別性はそのエンティティが生存している間変わることはない
    - 他のオブジェクト、例えば、他のエンティティや値オブジェクトを持つことができる
    - 自身が所有するオブジェクトの操作を調整する責務を有する
- 値オブジェクトとは 103
    - 識別性を持たない代わりに、値で識別できる
    - 不変
    - 完結した概念を形成しなくてはならない
        - 対象の概念を表すのに必要なすべての要素を含んで1つの個を成す
    - エンティティは持てないが、参照はできる
        - [エンティティ参照の事例、住所と国](https://chat.openai.com/share/b67f0d38-c66b-40e8-8901-b409077bfcda)
    - 重要な制約が明確に定義されており、その制約を守らせるようになっている
    - エンティティや他の値オブジェクトの属性として使われることがある
    - 生存期間は短いことが多い
- 集約 108
    - すべての集約には境界とルートがある。
    - ルートは集約に含まれる1つだけしかない特別なエンティティ
    - ルートは集約の境界の外から参照できる唯一のもので、次の性質を持つ
        - グローバルな識別性を持つ
        - 境界内のオブジェクトへの全てのアクセスを制御する
            - 気づき:つまり集約の中のオブジェクトに直アクセスしてメソッドを呼んだらダメそう
        - 集約内のルートを除いたエンティティはその集約内で一位となる識別性を持つが、その識別性は集約の外から認識される必要はない
        - ルートは集約内部にあるエンティティの参照を他のオブジェクトに渡せるようにすることが可能だが、その参照は一時的にしか使えないようにし、保持できないようにしなければならない
        - ルートは値オブジェクトの参照を他のオブジェクトに渡せるようにすることができる
    - 集約を構成するオブジェクト間の普遍条件は、トランザクションが行われるたびに、その中で常に維持されるようにする
    - 不変条件が複数の集約に広がってしまうと、正しい状態が常に保たれていることを期待できなくなる。ただし、最終的に正しい状態が保たれるようにすることはできる
    - 集約内のオブジェクトは他の集約への参照を保持できる
    - 気づき:複数のエンティティの状態変化をatomicに起こしたい場合、集約として管理するとやりやすい。それが(論理的な)トランザクションの観点
- コンテキストマップとは、異なるコンテキスト同士がどのように境界を超えてコミュニケーションを取るのかを示す概念的な見解 121
    - 境界づけられたコンテキストを把握するために、既存組織のコミュニケーション構造を把握すると良い
    - 結果として次のようなコンテキストマップを作れる

- セキュリティにおける基本原則は多層セキュリティ。複数のセキュリティ対策によって仮に一つ突破されても守られる 139
- 妥当性確認の分類。上から順に確認しておくことで、より負荷のかかる高度な妥当性確認を不必要に実施することを防げる 152
    - オリジン:正当な送信元
    - サイズ:適切なデータサイズ
    - 字句的内容:正当な文字のみで正しくエンコード
    - 構文:正しいフォーマットか
    - 意味:意味的に正しいデータ
    - 気づき:4.3妥当性確認の部分は全体的に面白い ☆
- 先にサイズを確認することで、字句的な妥当性確認などで膨大なリソースを消費することを防げる 159
- ドメイン・プリミティブ系の方式と対応されるセキュリティの課題 169
    - ドメイン・プリミティブと不変条件: コードの不正確さ、エラーの起こりやすさ、曖昧さ
    - Read-Onceオブジェクト: 機密性の高いデータの漏洩
    - ドメイン・プリミティブの応用: ロジックがあまりにも複雑になってしまったことによるコードの負担
- ドメイン・プリミティブとは、その存在だけで、その値が有効であることを保証する厳格な定義がなされた値オブジェクトのこと。オブジェクト生成時に不変条件がチェックされる 171
    - オンライン書店の、冊数など
    - 気づき: エンティティや集約はここに入らないんやな。値オブジェクトよりさらに小さいイメージがある
- ドメイン・オブジェクトが外部に漏れると、クライアントの要求にドメイン・オブジェクトの構造が引きづられる。そのためDTOの一種を使って変換した上で公開する 179
    - 気づき: GraphQLとかは、そのスキーマ定義がDTOっぽくなるよなあ
- Read-Onceオブジェクトとは、オブジェクトが生成されると、一度だけしかその中に閉じ込められたデータを取り出せないようにする 181
    - クレジット・カード番号などのsensitiveな情報向け
    - toStringのマスク
    - 気づき: なんでこれがセキュリティに繋がるかあまりわかってないな
        - 多分だけど、sensitiveな情報は大抵のケースでそのスコープ内でしか使われず、そこが最初の1回になる。それ以外で呼ばれていたらかなり怪しい、ってことか?
    - 事例は188ページ。Tomcatが勝手にダンプしていたというのは面白い
- 状態を別オブジェクトに持たせるパターン 257
- 扱う状態が10を超えてくると管理が難しい。このような時にエンティティ・リレーが使える 273
    - エンティティをフェーズごとにいくつかに分割する
- エンティティリレーが使える3条件 278
    - 1つのエンティティにあまりにも多くの状態がある
    - フェーズに分割する際、それらのフェーズが前のフェーズに決して戻ることがない場合
    - フェーズからフェーズへの遷移がシンプルで、遷移先のフェーズが非常に少ない場合(理想なのは1つだけ)
- 設計を安全なものにするためのテストの種類 284
    - 正常値テスト、境界値テスト、異常値テスト、極端値テスト
- リアクティブ宣言 358 ☆
    - 気づき: スケーラブルなシステムを考える時の指針となる
    - リアクティブシステムは、即応性、回復性、弾力性、メッセージ駆動を備える
    - [リアクティブ宣言](https://www.reactivemanifesto.org/ja)
        - リアクティブシステムとして構築されたシステムはより柔軟で、疎結合で、スケーラビリティがある。これによって開発が容易になるだけでなく、変更を受け入れやすくなる。これらは障害に対してより著しい耐性を持ち、たとえ障害が起きても災害を起こすことなく優雅に対処する。リアクティブシステムは高い即応性を持ち、ユーザに対して効果的な対話型フィードバックを与える。
- ログのサービス化による機密性・完全性・可用性(CIA)の向上 389