じゃあ、おうちで学べる

思考を呼び覚ます このコードに、君は抗えるか。

SREとして「ソフトウェアアーキテクチャの基礎」を読んでないのに堂々と語る方法

このエントリーで言いたいこと

システムの構造や各種機能を実装することもアドバイスを求められることも非常に少ないがSREもソフトウェアアーキテクチャに関わることがある。 それは、プログラマーとしてではなくアーキテクチャ特性の専門家としてアーキテクチャに触れる場面です。そのため、アーキテクチャ全体についての知識は得ておくことは良いこと。

タイトル説明

読んでいない本について堂々と語る方法という書籍がある。読んでいないにも色々あって…本当にぜんぜん読んだことのない本、ざっと読んだもしくは流し読みをしたことがある本。人から聞いたことがある本、ブログで書評だけ読んだ本、読んだことはあるが忘れてしまった本などあらゆる本を語る技術に書かれている読書論の本のタイトルだけのオマージュです。

はじめに

本日、10/27に『ソフトウェアアーキテクチャの基礎を執筆した著者陣が書いた『ソフトウェアアーキテクチャ・ハードパーツ - 分散アーキテクチャのためのトレードオフ分析』が発売されました。絶対的な銀の弾丸がないソフトウェアアーキテクチャの世界ではトレードオフを見極め、状況に合った選択をすることが常に求められます。悔いなき判断には多くの知恵と経験が要求されると思います。ハードパーツは、読者が自身のアーキテクチャ上の難題に対して効果的なトレードオフ分析を行い、より良い決定ができるようにするための書籍です。また、我々SREはプロジェクトやシステムに対して意見や判断を求められることも多くあると思います。そんな時にきっと、ソフトウェアアーキテクチャの基礎ソフトウェアアーキテクチャ・ハードパーツ を読んでおけばよかったと思うことがあるかもしれません。このエントリーではその前作のソフトウェアアーキテクチャの基礎の概要を確認することでハードパーツへの理解をより深めていけるとおもいます。優秀なアーキテクチャになりたいから読んでほしいわけではありません。スペシャリストとして意見や判断を求められた時の判断材料や語彙の強化などで今後のエンジニア人生に役に立ってくれると思います。このエントリーは『ソフトウェアアーキテクチャの基礎を読んでみた中での感想文となります。

ソフトウェアアーキテクチャの基礎」の目次


部と章立ては以下の通りです。全24章もありこれだけでもすごく勉強になります。個人的には付録Aの自己評価のためのチェックリストをやってみてから本書を読むのも良いかな‐って思っているが自分はやっていないので何も責任は持てない。

Ⅰ部では基礎や概念、Ⅱ部では詳細な各アーキテクチャについて、Ⅲ部ではソフトスキルとマネジメントテクニックみたいな話をしてます。

1章 イントロダクション
# 第I部 基礎
2章 アーキテクチャ思考
3章 モジュール性
4章 アーキテクチャ特性
5章 アーキテクチャ特性を明らかにする
6章 アーキテクチャ特性の計測と統制
7章 アーキテクチャ特性のスコープ
8章 コンポーネントベース思考
# 第II部 アーキテクチャスタイル
9章 基礎
10章 レイヤードアーキテクチャ
11章 パイプラインアーキテクチャ
12章 マイクロカーネルアーキテクチャ
13章 サービスベースアーキテクチャ
14章 イベント駆動アーキテクチャ
15章 スペースベースアーキテクチャ
16章 オーケストレーション駆動サービス指向アーキテクチャ
17章 マイクロサービスアーキテクチャ
18章 適切なアーキテクチャスタイルを選ぶ
# 第III部 テクニックとソフトスキル
19章 アーキテクチャ決定
20章 アーキテクチャ上のリスクを分析する
21章 アーキテクチャの図解やプレゼンテーション
22章 効果的なチームにする
23章 交渉とリーダーシップのスキル
24章 キャリアパスを開く

付録A 自己評価のためのチェックリスト
参考文献
訳者あとがき
索引

目次や本の詳細についてはO’Reilly Japanよりご確認ください。

特徴と感想


問われるシステムアーキテクチャとしての知見の広さと深さ

目次を見ると分かると思います。が、単純にいくつかのアーキテクチャについての紹介しているだけではありません。アーキテクチャを考える際に必要な思考方法やどのような部分に思考を巡らせればよいか、リスク分析から立ち回りまで広大なトピックを凝縮し網羅的にまた、今という視点だけではなくどのような技術的な変化や背景があっては今に至るのか? などの文脈まで考慮されて書かれています。この、書籍の好きなところは2点あります。1つ目は定義づけて不毛な議論を避けることです。Twitterで定期的に発生する背景なき不毛な議論もほとんど無くなるといいなと思ってます。2つ目は技術的な手法だけではなくところです。結局は人の問題で、全ての議論でチームや人を蔑ろにせずソフトスキルや技芸へのリスペクトがあるところです。 また、『ソフトウェアアーキテクチャの基礎を一冊読んだところで直ちに目の前にあるソフトウェアやアプリが急激によくなったりすることはない。が今後のソフトウェアの開発に関わって生きていく上でまた、様々な指標になる素晴らしい書籍だと思いました。本当は一章づつ振り返りたいのですが時間的にも余裕がないので少しだけ紹介させてほしいです。

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

ソフトウェアアーキテクチャと言われた時に、要件とその他すべてのアーキテクチャ特性から構成されるものをふわっとまとめてなんとなくそう考えていたり言及してました。本書では以下のように4つに分類され定義されます。あと、このあとに出てくる図がとても整理があると自分が何について考えなければならないのか明確になるので本書を読んで最初に勝ちを確信しました。私は洋書が出てからすぐに友人からすごい書籍があるから紹介されて読んだので読んだことはあるが忘れてしまった本に近いのだがこの時の感動は今でも覚えている。

私たちのソフトウェアアーキテクチャについての考え方を示す。私たちは、ソフトウェアアーキテクチャを、システムの構造、システムがサポートしなければならないアーキテクチャ特性(「イリティ(-ility))アーキテクチャ決定、そして設計指針の組み合わせで構成され るものだと考えている。

システムの構造

マイクロサービスやレイヤード、マイクロカーネルなどのシステムを実装するアーキテクチャスタイルの種類を指す。よくアーキテクチャの全てだと勘違いされがちです。

アーキテクチャ特性(-ility)

アーキテクチャ特性はシステムの成功基準を定めるものです。通りの良い単語でいうと非機能要件などが近い。通常、システムの機能とは直接関係しない。システムの機能に関する知識を必要としない。しかし、システムが適切に機能するには、これらの特性への理解が必要となる。SREとしてはこの分野に対して専門性を求められる機会が多い。

アーキテクチャ決定

アーキテクチャ決定は、システムをどのように構築すべきかのルールを定めるものだ。アーキテクチャ決定は、システムの制約を形作り、何が許されて何が許されないかに関する開発チームの指針となるように行う。

設計指針

設計指針は、堅苦しいルールではなくあくまでガイドラインです。サービス間通信のすべての条件、選択肢を完璧に網羅するアーキテクチャ決定を定めるのは不可能です。非現実的なコストをかければ別だが。その代わりに、設計指針として、望ましいアプローチに関するガイドを提供する。

ソフトウェアアーキテクトへの8つの期待

ソフトウェアアーキテクトがどのような役割が求められるかは組織やチームによって違いがあるような気がする。本書ではソフトウェアアーキテクトに対する8つの期待がある。そのうち3つがソフトスキルなのも優秀なソフトウェアアーキテクトが人間と向き合わなければならないのを示している。SREの探求5章 サードパーティとの協力を円滑に進める重要性でも事業に対する理解と政治の重要性について何度も言及されている。

  • アーキテクチャ決定を下す
  • アーキテクチャを継続的に分析する
  • 最新のトレンドを把握し続ける
  • 決定の順守を徹底する
  • 多様なものに触れ、経験している
  • 事業ドメインの知識を持っている
  • 対人スキルを持っている
  • 政治を理解し、かじ取りする

ソフトウェアアーキテクチャの法則

ソフトウェアアーキテクチャのすべてはトレードオフがあるが、どちらを優先しても10年後の結果は誰にも分からなかった。だから、まぁ「なぜ」が重要なんだろうな。悔いが残らない方をチームや組織で選ばなきゃいけないんだろうな。しかし、数ある選択肢の中でなぜその選択がなされたのか他の技術ではだめなのか? を説明するのは難しい。だから、アーキテクトには技術の深さより幅が求められるんだろうな。

基礎の概念は開発に関わる全ての人間は知っておいて良い

アーキテクチャにおける重要なトレードオフを理解するには、開発者はコンポーネント、モジュール性、結合、そしてコナーセンスに関する基本的な概念と用語を理解しなければならないが自分がここで説明してもめちゃくちゃ薄く複数の解釈ができるようになってしまうので読んでないのに堂々と語るというには言及が難しく。著者が大事にしている軸になる考え方です。ここについて堂々と語るにはやっぱりちゃんと理解する必要がある。

ソフトウェアアーキテクトへの期待されるソフトスキル

ソフトウェアアーキテクトへの8つの期待でも「対人スキルを持っている」と「政治を理解し、かじ取りする」などがあるがそれ以外にも『ソフトウェアアーキテクチャの基礎では図解やプレゼンテーションの大切さ、過不足なくチームを管理する方法、開発チーム、ビジネスチームに対してどう向き合うか? キャリアの形成についての言及もある。読みものに近い気もするがヒントがあるかもしれないです。

まとめ

ソフトウェアアーキテクチャの基礎はシステム設計に関わったことがある人ならばあの時、本書を読んでいればあの時の設計の判断はなにかが変わったかもしれないと思えるほど学びのある一冊でした。読まずに堂々と語るにはやっぱり惜しい書籍です。

アーキテクチャには絶対的で正解な選択肢がなくそれぞれにトレードオフがあり地上最強の〇〇は限定的です。脳死で要はバランスとしか言う人にもなりたくない。トレードオフを一定の水準や基準で見極めることができる能力のあるエンジニアになりたいです。カンファレンスや技術ブログ記事で紹介されているツールやシステム構造にすぐに飛びつきたくなる私のような無知で軽率な若者にはとても響きました。

SREはプログラマーとしてではなくアーキテクチャ特性の専門家としてアーキテクチャに対する意見を求めれます。アーキテクチャ全体についての知識は得ておくと良いのではないか? と思います

みなさんも『ソフトウェアアーキテクチャの基礎』及び『ソフトウェアアーキテクチャ・ハードパーツ』をぜひ手に取ってみてください。