# Clean Architecture　第1部イントロダクション/第2章 2つの価値のお話　読書会#2

###### tags `book`

## 概要
|項目|内容|
|-|-|
|開催日|2021/02/07|
|開始時間|12:45|
|休憩開始|14:50|
|休憩終了|15:35|
|終了時間|17:00|
|メンバー|nyx,niro|

***

## 第1部イントロダクション/第2章 2つの価値のお話

### 感想・気づき

#### はじめに
P41
ソフトウェアシステムは、ステークホルダーに2つの異なる価値を提供する。
->ソフトウェアシステムが価値を提供しているという視点が欠けていた
P41
ソフトウェアシステムの提供する価値「振る舞い」「構造」だが、片方にしかフォーカスされていない。しかも**価値が低い方にフォーカス**されがち :+1:
最終的に価値が0になってしまう。
->経験者が言っていることで説得力を感じる。

***

#### 振る舞い
振る舞い
-> ソフトウェアシステムの機能/実装された業務ルールと言い換えられると考える。

***

#### アーキテクチャ
→「構造」https://hackmd.io/aNSu16DETYSk3R6tpl-VpA?both#
P42
> マシンの振る舞いを簡単に変更する手段になる事を目的としたものがソフトウェア
> マシンの振る舞いを簡単に変更したくないものをハードウェアと呼んだ。

ソフトウェアのソフトウェアたる由縁は柔軟に変更できる事:+1:

>アーキテクチャが特定の「形状」を選択していると,新しい機能がその構造に適さない可能性が高くなっていく。
>したがって、**形状にとらわれない**アーキテクチャにした方が実用的である。:+1:

具体的に想定していたのは、ロギングをする際の割り込み処理で第一引数を決め打ちでリクエスト型を継承したTypeと想定して実装していた箇所はまさしく、形状に依存した形式であると想起しながら読んでおりました。

-> P21　5行目のプロジェクト書記のアーキテクトが必ずしも適切になるとは限らない。ことを意味していると思う。

***

#### 大きな価値
P43
>ビジネスマネージャに質問すると、ソフトウェアシステムが動作することが重要であると答える。開発者もこの意見に賛同することが多い。**だが、これは間違った態度だ。** :smile:
P43
> - "完璧に動作するが、変更できないプログラム"->"いずれ役に立たない"
> - "動作しないが、変更が簡単なプログラム"->"引き続き役に立つ"

変更のコストがメリットを上回るという事は事実上、変更ができないという事。
そして、多くのシステムは一部の機能や設定がその段階に達している。
->プロジェクトリーダも事実上変更ができない状態は経験したことがあると思うので、そういう意味でも、有効な手段なのかなと思う。

簡単に変更が実現できることこそが、大きな価値であると言っていると解釈。
-> 上記をビジネスマネージャーにわかってもらう事が「アーキテクチャの戦い」

開発者が膨大な見積をしてビジネスマネージャが理不尽な態度を取るのは自分自身がビジネスマネージャの態度を改めなかったことが原因になる可能性がある。
-> これも「アーキテクチャの戦い」

***

#### アイゼンハワーのマトリックス

>ドワイト。Dアイゼンハワー大統領
>私には緊急と重要の2種類の問題があります。緊急は重要ではなく、重要は緊急になることはない。
>This President said, "I have two kinds of problems, the urgent and the important. The urgent are not important, and the important are never urgent.":+1::pencil:
https://en.wikipedia.org/wiki/Time_management#cite_note-12
https://web.archive.org/web/20150402111315/http://www.presidency.ucsb.edu/ws/?pid=9991

P.44
> 1. 緊急かつ重要
> 2. 緊急ではないが重要
> 3. 緊急だが、重要ではない
> 4. 緊急でも重要でもない
>ビジネスマネージャーや開発者がよくやる間違いは、3の項目（緊急だが重要ではない）を1（緊急かつ重要）に昇格させることだ
1||3 と 2||4 は性格が異なるのでに適切な人材配置が必要になると。大きなプロジェクトをする際、ブレーンは3人は必要なんじゃないかと思う。

ソフトウェア開発チームの責任として、**機能の緊急性**よりも**アーキテクチャの重要性**を強く主張する
-> これも「アーキテクチャの戦い」

***

#### アーキテクチャの戦い
>マネジメントチームも、マーケティングチームも、セールスチームも、オペレーションチームも同じだ。常に闘争である。
>それを言うことが開発者の責任だから。

> アーキテクト（または開発者）は、機能を簡単に開発・変更・拡張できるアーキテクチャを構築するものである。

雇われている理由は、簡単に変更できる構造の大切さと、それの実現と主張が大きな理由であるカナと思います。

***

### 疑問
P41
ソフトウェアシステムの提供する価値「振る舞い」「構造」だが、片方にしかフォーカスされていない。しかも**価値が低い方にフォーカス**されがち :+1:
->「振る舞い」「構造」とは？

#### はじめに

***

#### 振る舞い
>多くのプログラマは、それが自分たちの仕事だと思っている。マシンが用件を満たせるようにして、バグがあれば修正する。それが仕事だと思っている。ひどい間違いだ。:+1:

-> 何がひどい間違いだと思ったの？
価値を提供する事が仕事だと言おうとしているのかな？
それとも、メンテナンスしやすい様にしてバグがでない様にするのが仕事と言っているのかな？
>- マシンに振る舞いを与えるために雇用されている。
> 1. ステークホルダーが機能仕様書や要件文書を作成するのを支援する。
> 1. その後、ステークホルダーが要件を満たせるように、プログラマはコードを書くことになる。
> 1. もしマシンが要件を満たしていなければ、プログラマはデバッガを取り出して問題を解決する。

***
#### アーキテクチャ
P42
> 変更の難易度は、変更の形状ではなく、変更のスコープに比例しなければならない。
niro: 変更の難易度は、変更の形状(~~実装の良し悪し/され方~~)ではなく、変更のスコープ(要件)に比例しなければならない。
nyx : 変更の難易度は、変更の形状(ふるまい/要件/IF/シグネチャ)ではなく、変更のスコープ(影響範囲)に比例しなければならない。

- この場合のスコープとは何か？
- 影響範囲のことを想定していた。
- > **ステークホルダー視点**でほとんど同じようなスコープを伝えているだけである。
- 上記を受けて 、ステークホルダー視点でほとんど同じような要件を伝えているだけである。と考えた。なので、スコープ＝要件ではないか？
- 橋本さん異論
>scopeとは
>主な意味
>(知力・研究・活動などの及ぶ)範囲、視野、(活動や思考などを働かせる)余地、機会
>https://ejje.weblio.jp/content/scope
- ステークホルダーとプログラマでは見ているのもが違うから、変更に対しての難易度の認識が異なる。
- > **ステークホルダー視点**でほとんど同じようなスコープを伝えているだけである。
- 上記が、「**ステークホルダー視点**でほとんど同じようなスコープを伝えている**つもり**である。」って書いてあったら勘違いせずに済んだ（niro）
形状とは？
- 暗号化方式の変更とかのふるまいの変更を言いたいのかなと思いました。
- 変な実装をしていると変更範囲が広がることを感じている。適切に実装できていると変更のスコープが最小限になる。実装のされ方/良し悪し
- ふるまい/要件/IF/シグネチャ

***
#### 大きな価値
***
#### アイゼンハワーのマトリックス
***
#### アーキテクチャの戦い
***

## ふりかえり

### YWT
#### Y: やったこと
- 2章までの読書会ができた。
#### W: わかったこと
- 意外と時間がかかる
- ソフトウェアのソフトウェアたる由縁は柔軟に変更できる事
- ソフトウェアシステムの提供する価値「振る舞い」「構造」
- ソフトウェアシステムが動作することが重要であると答える。開発者もこの意見に賛同することが多い。だが、これは間違った態度
- ステークホルダーとプログラマでは見ているのもが違うから、変更に対しての難易度の認識が異なる。
- 変更の難易度は、変更の形状(ふるまい/要件/IF/シグネチャ)ではなく、変更のスコープ(影響範囲)に比例しなければならない。
- 形状にとらわれないアーキテクチャにした方が実用的
- ビジネスマネージャーや開発者がよくやる間違いは、3の項目（緊急だが重要ではない）を1（緊急かつ重要）に昇格させることだ
- 適切な人材配置で解決可能性があると考える。
- ソフトウェア開発チームの責任として、**機能の緊急性**よりも**アーキテクチャの重要性**を強く主張する

#### T: 次にやること
- 第2部構成要素から始めよ：プログラミングパラダイス 3章パラダイムの概要

***

### KPT
#### Keep
-
#### Probrem
- 時間がかかる
-> 時間を区切る（何分たったら強制終了）
-> 予め文章を用意しておく
- 「感想・気づき」「疑問」が位置的に飛んでいるので探しづらい。
-> まとめて書く 「感想・気づき・疑問」

#### Try
- 時間を区切る（何分たったら強制終了）
- 予め文章を用意しておく
- まとめて書く 「感想・気づき・疑問」

***

### Fun-Done-Leanrn
#### Fun:
- -
#### Done:
- -
#### Learn:
- -

速度
満足度
進め方