Design It読んだまとめ（第一部1章）

この本は３部構成になっていて、３部は辞書的な形で必要な時に参照する使い方を作者からも勧められている。
そのためぼくがnoteで書き連ねるのは２部までになると思われるが、ここでは一章だけまとめていく。

アーキテクトのやること

PO（Product owner）が気にする部分以外の品質特性を気にする役割を求められる。
コスト、可用性など必ずトレードオフが発生するものを見極めスイートスポットを探し続ける必要がある。

やると良いこと:
システム分割
トレードオフの把握

技術負債を管理し、戦略的に利用する。そのための可視化が重要。
必要ならばチームのスキルレベルアップも考慮する。

やると良いこと:
チームメンバーとペア設計

システムにおけるソフトウェアアーキテクチャとは

品質特性や性質を促進するための構成のための設計判断が集まったもの。
基本構造として、要素と要素を関係でつながれたもの。

関係の種類としては次の３種類を考えると良さそう。
・モジュール: ソース上に現れる構造。クラスなど。
・コンポーネント&コネクター（C&C）: 実行時に現れる構造。オブジェクト、インスタンスなど。
・割り当て: モジュールとC&Cがどう対応するかを示すことで作られる構造。どのマシンか、どのサーバーか、どこで実行されるかなど。

ソフトウェアアーキテクチャはこんなことを手助けしてくれる
・大きな問題を小さく
・協働の仕方を示す
・複雑な問題についての語彙を提供
・フィーチャーや機能以外に目が向く
・コストのかかる失敗を避けられる
・変化に柔軟になる

わー良いことずくめー。ほんとか・・・？

Lionheartプロジェクト

今後読み解くために本書に例として出てくるケーススタディについて記しておく。

・スプリングフィールド市という組織
・予算問題を抱えている
・行政管理予算局（OMB）が合理化のために作ったチーム
・問題の箇所は日用品含めた物品の購入。
　OMBが提案依頼書（RFP）を発行→企業が入札を行う

改善したいこと
・ほとんどのRFPが入札が一回しかなく、競争が生まれていない
・契約の締結に時間がかかる（数ヶ月）
・時間がかかることがボトルネックで諦める企業が多数
・RFPの発行にすら6時間かかる

まとめ

第一部ではアーキテクチャについての定義づけを行ってきた。
どこに目を向けるか、どんな考え方でチームに所属するか。アーキテクトがチームにいなければ自分でなれば良いと本書でも書いてある。
アーキテクトは特定の人物がなるより、誰でもこれらの考えを持っておくことはチームにとってもプラスとなる。

第二章ではデザイン思考をアーキテクチャに取り組む方法を中心に学んでいく。（予定）

ではまた。