近々、プロダクトの近い位置で仕事する機会が増えます。

今までの、
SES・Slerといった顧客の要件を元に開発するスタイルから、
自分たちで最適解の機能・アーキテクチャを開発するスタイルへと変わります。

言語やフレームワークといった開発も大事ですが、
これまでとは異なるスキル（視点や行動など）が必要となってくると感じています。

プロダクトやビジネスサイドとどう付き合って、エンジニアとして動いていけば良いか、
体系的な知識を身につけるため、「Design It! プログラマーのためのアーキテクティング入門」を
購入しました。

www.oreilly.co.jp

scrummasudar.hatenablog.com

tech-blog.cloud-config.jp

これから続けられる限り、
本書から咀嚼した内容を記事化していきたいと思います。

1章「ソフトウェアアーキテクトになる」に書いてあること
終わりや所感

1章「ソフトウェアアーキテクトになる」に書いてあること

目次から抜粋します。

1.1 ソフトウェアアーキテクトが行うこと
1.2 ソフトウェアアーキテクトとは何か
1.3 チームのアーキテクトとなる
1.4 素晴らしいソフトウェアをつくりあげる
1.5 ケーススタディ：Lionheartプロジェクト
1.6 次にやること

本章では、アーキテクトとしての知識を身につける前に、

アーキテクトとは何をするのか？
どのような立ち位置なのか？
意識すること（気構え）

のようなものが書かれていました。

では、咀嚼した内容をつらつらと。

アーキテクトの役割

アーキテクトがやるべきこととしては、以下と解釈した。

アーキテクトはPMではないが、プロダクトがビジネス目標を満たしているかを確認する
- ビジネスと技術とユーザーとの交点に見える
アーキテクトに成長するためには責任を負う必要がある
- プロダクト or プロジェクトマネージャーのようなステークホルダー（利害関係者）と協力
- ソフトウェアのビジネス目標と要求を定義
- 品質特性*1の追求と理解
システム全体を意識しないといけない
- ソフトウェアを使ったユーザーはどうなるか？
  - 利益はあるか？
  - サポートはどうするか？
- 開発メンバーはどうなるか？
  - 開発頻度は？
  - サポート体制は？
  - 支持は必要ないか？
- すべてのサイクルを整理、ソフトウェアの方針を意思決定していく必要がある
技術的負債の管理
- 技術的負債とは、ソフトウェアの設計と継続価値を届けるために必要な差分（コスト）
- 技術的負債は可視化し、ステークホルダーがどのような行動を取れば良いか判断する必要がある
チームのアーキテクチャレベルの引き上げ
- 知識や設計スキルを教えていく
  - ペア設計、ドキュメントが有効

ソフトウェアアーキテクトとは

品質特性を促進させる
- ステークホルダーに対して、ソフトウェアに結果が現れるように働きかけること
基本構造の定義
- モジュール
  - 設計時
  - ファイルシステム
  - システムが動いてなくても存在するもの
- コンポーネント＆コネクター（C&C）
  - 実行時の振る舞い
  - 連携し、新しいオブジェクトをインスタンス化する
  - システムが動いているときのみ存在する
- 割り当て
  - モジュールとC&Cが物理要素として何になるか
    - 例）クライアント or サーバー
TRY: 要素、関係、構造の定義
- モジュール構造について
  - メソッドやクラス
  - 名前空間
  - パッケージマネージャーやその依存関係
- C&Cについて
  - ソフトウェアとほかプロセスとの相互作用
  - 誰が何のシステムを呼び出しているか
  - 応答によってどう変化するか
- 割り当て構造
  - ソフトウェアのそれぞれの部品は誰の責任？
  - どうやってデプロイしているか？（実際のデプロイ環境など）

アーキテクチャは肩書きがなくても取り組めるし、誰もがアーキテクトである

アーキテクトがいないチームでも、誰かが役目を果たしているし、
誰でもアーキテクトになれる。

誰かが役目を果たしている

チーム内に基本構造を決めているエンジニアはいないか？
チーム内のアーキテクトはその人、もしくは自分となる。

自分がアーキテクトでなくても、設計の議論はできるし、
妥協しているようだったら、品質特性を元に議論すべき。

ソフトウェアアーキテクトとは心の持ち方。
プログラマーは、毎日何十何百という設計判断を知らず知らずに行なっている。
そして、その設計判断は、アーキテクチャに影響を及ぼすこともある。

プロダクトやソフトウェアの構造に影響を与えられる人は、
全員アーキテクト（代行）である。

良いアーキテクチャを作るのは、自分自身。

プログラマーからアーキテクトになるには

自分がアーキテクトへと成長していることを確認・振り返るため、
プロジェクトポートフォリオを作っておくとよい。

プロジェクトポートフォリオとは、
ポジション関係なく自分が過去に携わったプロジェクトの

ステークホルダーは誰か、ビジネス目標は？
目標を達成するために取られたソリューション（手段や手法）は？
どんな技術を使用、取り組んだか？
リスクはなんだったか？どうやって克服したか？
もう一度やり直せるとしたら、どのようにするか？

を書くこと。

書くことで成長の実感。また、
次にアーキテクトする機会のための準備、予行練習となる。

素晴らしいプロダクト・ソフトウェアを作るためには

ソフトウェアアーキテクチャは、ステークホルダーが愛してくれるソフトウェアを構築する
- 6つの方法
  1. 大きな問題をより小さく、より管理しやすい問題へと変える
    - 現代のソフトウェアは大きく複雑、多くの可変部分を持つ
    - アーキテクチャは、システムをより小さな塊に分割する方法を教えてくれる
      - 1つのシステムやコンポーネントをより小さくすることで、1つの問題をより明確・専任的な問題に誘ってくれる
  2. 人々の協働の仕方を示す
    - 開発は技術であると同時に人間的なコミュニケーションでもある
    - システム全体がどのように結びつくかを示す（システムを構築する人々も含まれる）
    - アーキテクチャを知る＝ソフトウェアを開発するために、どのように協働するかを理解すべき
      - ソフトウェアが大きくなるほど、上記理解はずっと重要となる
  3. 複雑な問題について会話するための語彙を提供する
    - 相手が話していることを理解、整合するためにアーキテクチャの基本思想や中核語彙を使う
  4. フィーチャーや機能以外のものにも目を向ける
    - アーキテクチャを設計する際に意識すること
      - コスト・制約・スケジュール・リスク・チームの能力・品質特性
      - 要はバランス
  5. コストの間違いを避けるのに役立つ
    - 重要な設計判断＝重要かどうかは変更s￥コストによって図られる
    - アーキテクチャは全能ではないが、設計することによって問題の難しい部分を発見することができる
  6. 変化への柔軟な対応を可能にする
    - ソフトウェアの構造を制御するのはアーキテクチャの役目