第2回 The Software Architect Elevator 読書会@リモートのログ
引き続き Discord によるオンライン開催。
今回は 04. Enterprise Architect or Architect in the Enterprise? から。
次回は3/13(土)、9. Architecture Is Selling Options から。
トピック
- トレンドに逆張りして東京へ引っ越した
- 食洗機の稼働が遅れてる（自損）
- popIn Aladdinをお試し中
- ミキサーが届いたので調整中
- Clubhouse の利用体験を改善できそうなデバイスを模索中
- 腰痛で日常生活が崩壊した（気温の変動が激しすぎ）
- 仕事の余暇にGoとかTypeScriptとかを試したりしてる
- ワンダビジョンはいいぞ
ディスカッション
4. Enterprise Architect or Architect in the Enterprise?
5. An Architect Stands on Three Legs
Focusing on impact is a good exercise for architects to not drift off into PowerPoint-land.- パワーポイント界へ流されないようにするため、インパクトに注力するのはよい取り組みです
- Why Junior Employees Should Mentor Senior Employees
- ソートリーダーシップ／Thought Leadershipとは ｜MAmag.
- You Spin Me Round : 洋楽歌詞和訳・ときどき邦楽英訳（意訳）
6. Making Decisions
- Thinking, Fast and Slow - Wikipedia
少数の法則とは、サンプル数の少ない偏った情報を、過大評価して一般化してしまう認知バイアス。従来のIT組織では、特定の結果からスコアチャートをリバースエンジニアリングすることが多く、好みを操作するためのデータを持っています。- Loss aversion - Wikipedia
- Amazon.com: Priceless: The Myth of Fair Value (and How to Take Advantage of It) eBook: Poundstone, William: Kindle Store
- Micromort - Wikipedia
- Model Thinking | Coursera
- The Model Thinker: What You Need to Know to Make Data Work for You, Page, Scott E. - Amazon.com
- 数値ベースでロジカルな判断ができるくらいの抽象度ならそれほど深刻な決定にならなそう
- もっと影響力の大きな決定が求められるのは数値化すら難しい抽象度のドメインだから
- ビジネスとテックの対立にアーキテクトはどう関わるべきか
- 中立を保とうとすると両方を敵に回す羽目になる
- 本書の後半ではコミュニケーションを扱っているからその話題が出てくるかも？
7. Question Everything
- Toyota Production System | Vision & Philosophy | Company | Toyota Motor Corporation Official Global Website
- 「なぜなぜ五回」の評判が悪い
- 押しつけ感が強い
- 上手く進行してくれる人がいないと犯人捜しになりやすい
- 「なんで？」という問いかけは攻撃的な印象を与えやすいので難しい
- 原因分析がいい結末に着地する印象がない
- 人間の行動が原因になる場合は特に。
- 再発防止策が「がんばる」になりがち
Part II. Architecture
8. Is This Architecture?
- Jacobellis v. Ohio - Wikipedia
- What Is Your Definition of Software Architecture
- TOGAF - Wikipedia
- Objects, Components, and Frameworks With UML: The Catalysis Approach
- Stahl House - Wikipedia
なぜあなたはあなたのアプリケーションを複数のクラウドプロバイダーに広げているのですか？アーキテクチャについて説明するときは、明らかでないことについて話しましょう
目的に合うか、より、目的を決めるところから始めることが多いと思う
- 一番大変なところ
- 顧客が本当に必要だったもの
- MVP を決める話と似てるような気がする
- 要件定義は終わらない
- そのような状況にもアーキテクトは入っていくべきなんだろうか
- 決まらないと話が進められない要素があるなら入るべき
- アーキテクトとは（それぞれの参加者の視点）
- チームが決めた要件をちゃんと設計、実装できることを支援する存在
- 何を作りたいのか目的を決めるところから関わる存在
- 目的を決めるための人間系、目的を実現するための機械系両方を整備する存在
- ビジネスとしての競争力を生み出す要素を明示するのがアーキテクチャ
- Figure 8-2 がなぜいいアーキテクチャなのか、ということの解釈
- 目的と手段を明示してるのがいいところだと思ってる
