@hihihiroroのLog

ダラダラと。本ブログは、個人の意見であり、所属会社とは関係がありません。

「ソフトウェアアーキテクチャの基礎」を読んだ

積んでいたがようやく読む気がおきたので手にとった。

目次は以下。流石に幅広い内容なので長いし、章も多い。

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

アーキテクトに期待されていることとしては、以下のようなことが紹介されていた。

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

技術的なことが強いだけではないことが特徴的。後半はソフトスキルよりのことが求められており、知識や技術力だけを磨いていれば良いわけではないというのが面白かったし確かになと納得した。

ソフトウェアアーキテクチャの法則として次の2つが紹介されていた。

  1. ソフトウェアアーキテクチャトレードオフがすべてだ。
  2. 「どうやって」よりも「なぜ」の方がずと重要だ。

第一の法則通りですべてこれで大丈夫というものはなく、その場での必要性と我慢できる範囲を考え評価をし、その場で使えそうなものを考えて選んでいくのが大事だということがよく書かれていたなと思う。トレードオフの評価として使えるものに、構造*1アーキテクチャ特性*2が説明されていてなるほどと思った。

アーキテクチャを選択する上でこの考え方を忘れないようにしようと思ったのは第4省にあった以下の言葉。

決して最善のアーキテクチャを狙ってはいけない。むしろ、少なくとも最悪ではないアーキテクチャを狙おう。

P.66

最適を考えてすすまなくなったり、これじゃないとなってしまうことが多くなってしまうが、最悪じゃなければとりあえず作ってみて入れ替えるなどを試せるようにしておけば良いのかもしれないなと。ただし、アーキテクチャの入れ替えは相当大変そうなので最悪以上のものを結局は狙ってしまうだろうけど。

途中の章では多様なアーキテクチャが紹介されており、それぞれのアーキテクチャの知識を得ることができた。知っているものも曖昧なものも、なるほどと知ったものもあった。この中ではメリットもデメリットも紹介されており、上記に書かれているトレードオフを考えるのに必要な知識として役立ちそうだなと思えた。これらは1度くらいは自分で組んで知識として身につけておきたいなと思った。
また、いろんな問題に対してどのようなアーキテクチャが良いのかを何人かで話し合ってみて考え方を整理していってみたいなと思った。

訳者の方の発表スライドもあったのでこちらを読み直しの意味で見直してみる。

speakerdeck.com

まとめ

  • 幅広い内容なので何度も読み直してみたいと思う
  • トレードオフで取捨選択できるだけの手札を揃えておくための勉強を続けるぞ
  • 技術的だけではなくビジネス的、チーム的での判断ができるようなスキルも身につけたい

*1:アーキテクチャスタイルの種類

*2:可用性、回復性、スケーラビリティ、構成容易性、メンテナンス容易性、アクセシビリティ、セキュリティ ...