締切を味方に技術書の読書を進めるデッドライン読書会第63回の課題図書は前々回と前回に続き「ソフトウェアアーキテクチャの基礎」です。
本書は3部構成であるため、最後の塊になります。第3部は「テクニックとソフトスキル」。章としては以下の通り。
- 19章 アーキテクチャ決定
- 20章 アーキテクチャ上のリスクを分析する
- 21章 アーキテクチャの図解やプレゼンテーション
- 22章 効果的なチームにする
- 23章 交渉とリーダーシップのスキル
- 24章 キャリアパスを開く
感想メモ
短いですけど、感想メモ。
アーキテクチャの記録や表現
アーキテクチャの記録にはADR、アーキテクチャデシジョンレコードを使う。アーキテクチャの選定理由(WHY)や、変更の履歴などを確認するため。Google Cloudのサイトにも「アーキテクチャ決定レコード」という解説ページがあった。
アーキテクチャ決定レコードの概要 | Cloud アーキテクチャ センター | Google Cloud
アーキテクチャ決定レコードを使用して、設計上の決定事項をドキュメントに記録して説明するタイミングと方法について学習します。
このADRは単純なフラットファイルに記録することが進められていた。構造化にはAsciiDocだと。図解をするときのツールもう少し後ろの章であった。紹介されていたのは、UML、C4、ArchiMate。C4とArchiMateは馴染みがなかったような気もするので調べてちらっと見てみたが…習得するのにコストがかかりそうだっていうのが純粋な感想です。(いずれも最近のものではなく、昔からあるもの)
アーキテクチャモデリング言語「Archimate」 | オブジェクトの広場
アーキテクチャ設計について他人と意見を交わしたり、説明をするときに、皆さんはどんな図を描いて伝えていますか。私は以前はUMLかポンチ絵を多用していましたが、最近はArchimateを使うようになりました。本稿では私のお気に入りのアーキテクチャモデリング言語、Archimateをご紹介します。
C4モデル
リスクストーミング
これはとても良い言葉。アーキテクチャ上のリスクを特定するために関係者でワイガヤして洗い出す活動。リスク+ブレインストーミングですね。プロジェクト管理におけるリスク特定においても使える技ですね。「リスクストーミングしましょうか」なんて感じで使える。
朝一番の1日20分の情報収集
自分がこれをできなくなってしまったのはなんでだろう…(若い頃はやっていた)。デッドライン読書会のように本を読むのも大事ですが、20分でも最新情報をキャッチアップするのはきっと意味があるものですね。(どうにか再開したい)
次の本は・・・
冒険の書!名前がいいではないか。2024年ITエンジニア本大賞の「ビジネス書部門ベスト10」からの選書です。
コメント