ryokatsu.dev

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

GW中に読んだので感想ブログです。

内容

タイトルから想像が付く通りで、ソフトウェア開発におけるアーキテクトの仕事は何をするのか、アーキテクチャをどう設計していくかが書かれていました。3部構成になっており

  • イントロダクション
  • 1部では、ソフトウェアアーキテクチャの設計についての基礎部分
  • 2部では、様々なアーキテクチャパターンを例を交えて紹介
  • 3部では、アーキテクトのソフトスキル

という順番で読み進めていきます。自分はそもそもフロントエンドしかやっていない（PMとかディレクターとかはやったことあるけど）なのでまずイントロダクションの時点で挫折しそうになりました。

しかし読み進めていくと開発者目線でも学びが多く、アーキテクトにもしなれることがあれば再読したい書籍でもありました。

自分の今までの仕事の中で、アーキテクトというポジションの人と一緒に仕事をした経験がほぼなくどういうことしているんだろうと気になったのも読んでみようと思った理由の一つです。

イントロダクション

ここは導入部分になります。上記で挫折した図があったり、定義やアーキテクトに期待することなどが書かれていました。期待することは8項目あったのですが、技術スキルは勿論のこと「社内政治に強い」「対人スキル」「事業ドメインの理解」など技術とは別のソフトスキルも必要と書かれていました。社内政治なんて絶対やりたくないのですが、ビジネスをしている以上発生するし、プロダクトに責任を持つ職種でもあるので戦っていかないといけないんだろうな。と感じました。

第1部

ここでは、アーキテクチャの基礎や用語などが紹介されていました。ここでは、「アーキテクトを考えることはトレードオフを考えること」という言葉が印象に残ります。何かを決めて何かを捨てるでも捨てたときにちゃんと理由も説明できるようにしておくというのはとても大事なことだと改めて思いました。

アーキテクチャ思考の章では、アーキテクトとは「技術の深さではなく幅を知る必要がある」と書かれておりここは普段開発している側すると異なった箇所だと感じました。もちろん一定の深さを知る必要はあるのですが、それよりも日々進化する技術トレンドに追いつくためにネタを仕込んでおき、いい設計ができるようにしておくのが大事だと感じました。3部のソフトスキルの章でもアーキテクトは、1日20分技術トレンドを確認する時間を設けると言ったことも書かれていました。

モジュール性、アーキテクチャ特性、コンポーネント思考なども書かれており「コナーセンス」というキーワードを初めて知りました。コナーセンスを紹介している記事もありました

普段開発しているときに言葉は知らないけど、意識しながら作業していたことだったので説明はわかりましたが、非常に難しいなと感じるところでした。このあたりはアーキテクトの方と一緒になって考えていければ勉強になりそうだなと感じました。

コンポーネント思考は、分割の仕方やエンティティの罠、モノリスか分散かなどが書かれており、事例も紹介されていました。普段フロントエンドでもコンポーネント分割をするのですが、そのコンポーネントの責務などを考えることが多くこのコンポーネントがアーキテクト全体からみてどうかみたいなところを俯瞰して考えるといろいろと難しいなと思いました。

アーキテクトは最悪じゃないトレードオフの集合だという言葉もあり最高の設計なんてないんだなと改めて感じる章でした。

第2部

ここでは、アーキテクチャのデザインというか様々なパターンについて紹介されていました。数が多いので全部は書かず省きますが。モノリシックアーキテクチャと分散アーキテクチャの2つの中で更にパターンがありそれぞれ紹介されています。

モノリシックアーキテクチャで、一番名前をよく耳にする「レイヤードアーキテクチャ」の紹介もありました。シンプルだけどDDDとは相性悪かったり、とメリットデメリットをしっかり抑えることができます。フロントエンドでもこういう構成で仕事したことが何回もありますが、やはり保守性とかテストとかが非常にやりにくい印象を受けます。ただこのアーキテクチャはモジュール分割さえちゃんとしておけば他のアーキテクチャへの移行はコスト低く済みそうな印象を受けますが、実際すんなり移行できた事例はあんまり見たことがありません。拡張性とか開発者体験とかを考えるとデメリットが多そうな設計だと感じました。

分散アーキテクチャでは「イベント駆動アーキテクチャ」「マイクロサービスアーキテクチャ」などが紹介されていました。イベント駆動アーキテクチャは初めて耳にする単語が多くてちゃんと理解できませんでした。。とにかくスケールしやすいらしいが、イベント駆動アーキテクチャでは非同期通信に依存していることから高速に処理ができるらしいです。ただ非同期だと処理が完了したかの保証がなくrejectされたときにちゃんとエラー処理を設計しようという設計なんだなと理解しました。フロントエンドでもよくあることなのでわかるなーと思いながら読んでました。

「マイクロサービスアーキテクチャ」はよく聴くアーキテクチャでしたが、マイクロフロントエンドも紹介されていて今までざっくりしか理解しかしていなかったので少しだけ理解度が上がった気がしました。ドメイン一つ一つがそれぞれでちゃんと動くように設計されている分、他のドメインのことを考えなくて良いためテストやデプロイなどもやりやすくなるんだろうなと思いました。自分はマイクロサービスアーキテクチャの構成でガッツリ開発したことがないので一度は経験してみたいと思いました。

第3部

ここでは、アーキテクトの仕事をする上でのソフトスキルが紹介されていました。結局の所「対人スキルがなかったらアーキテクトにはなれない」ということがわかりました。その通りだなと思いますし、おそらくアーキテクトになるにはリードエンジニアや、テックリードなどの職種を経験しているので対人スキルがない人はいないと思いますが、ここでは立場をわきまえた言葉遣いが紹介されていました。高圧的な言葉を使うと、開発者とうまくいかないことはあるあるなので改めて気をつけていきたいところです。

面白いところでは、「スケジュール管理」についても触れていました。アーキテクトはMTGが多いのでどうやってスケジューリングしていくかが書かれていて、これはアーキテクト限らずタメになる内容でした。

読み終えて

かなり重厚な内容だった分一つ一つの内容はとても参考になることが多くとても良い本でした。書籍になかったこととしてそれぞれのアーキテクチャパターンの移行方法などがもしあれば知りたいなと思いましたがそもそも移行作業で成功した事例が少ないのかなとも感じました。これからアーキテクトと仕事する機会があればもう一度この本を読み直して理解を深めようと思いました。

アーキテクトに限らずエンジニアが読んでもとても面白い本です！！！