zackey推し

IT系のこと書くぞい

「Design It! プログラマーのためのアーキテクティング入門」の咀嚼 第1章 ソフトウェアアーキテクトになる

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

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

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

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

www.oreilly.co.jp

scrummasudar.hatenablog.com

tech-blog.cloud-config.jp

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

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. 変化への柔軟な対応を可能にする

終わりや所感

以上になります。

本章を読んだことにより、

  • アーキテクトとしての心の持ち方
  • プロジェクトポートフォリオを作ること
  • アーキテクトはシステム的な設計だけでなく、品質特性を追求するために協働が必要であること

を理解できました。

自分もアーキテクトという肩書きではないものの、
品質特性に影響を与える機能開発や改修は多々あります。

  • ステークホルダーが求めているものは何か(ビジネス目標)
  • それらを実現するために、保守するための議論

といったことは、普段意識できている場面、
もちろんできていない場面もあります。

ただ、このような考え方を知っておくと、
考え方に基づいた思考・行動が行える場面が、 いままでより増えてくると思います。

また、考え方を咀嚼、箇条書きレベルにまとめることで、
チームのビジョンとして染み込ませることができるんじゃないかな...
と感じました。

*1:世間的でいう外部品質と解釈