「ソフトウェアアーキテクチャの基礎」と「アーキテクトの教科書」の備忘と感想

はじめに

最近、ソフトウェアアーキテクチャを改めて勉強しようと2冊の本「ソフトウェアアーキテクチャの基礎 ―エンジニアリングに基づく体系的アプローチ」と「アーキテクトの教科書 価値を生むソフトウェアのアーキテクチャ構築」を読んだので要点と感想を備忘としてまとめます。

• ソフトウェアアーキテクチャの基礎 ―エンジニアリングに基づく体系的アプローチ

https://www.oreilly.co.jp//books/9784873119823/

• アーキテクトの教科書 価値を生むソフトウェアのアーキテクチャ構築

https://www.shoeisha.co.jp/book/detail/9784798184777

概要とポイント

ソフトウェアアーキテクチャの基礎 ―エンジニアリングに基づく体系的アプローチ

アーキテクチャには正解も間違いもない。ただトレードオフがあるだけだ。

この本はアーキテクチャを考えるための思考から、代表的なアーキテクチャスタイルの紹介やアーキテクトとしてのソフトスキル（対人スキルやチーム運営、キャリアパス等）まで網羅的にまとめられているものとなります。
アーキテクチャの技術的な部分だけではなく、心構えや振舞についても学ぶことができる非常にいい本だと思います。
技術的な部分はもちろんですが、アーキテクトとしての技術の幅を広げることが印象的でした。

簡単にポイントをまとめると

• アーキテクトへの期待

  • アーキテクトは技術的な決定を導くためのアーキテクチャ決定や設計指針を定義することが期待される。その際、技術的な選択を指定するのではなくガイドすることが重要。
  • アーキテクチャや技術環境を継続的に分析し、改善策を提案することが求められる。
  • 最新の技術や業界の動向を把握し続けることが重要。
  • アーキテクチャや設計指針の順守を徹底すること。
  • 様々な技術、フレームワーク、プラットフォーム、環境に触れていることが期待される。
  • 事業ドメインの知識が必要。
  • ファシリテーションやリーダーシップ等卓越した対人スキルが必要。
  • 社内政治を理解し、かじ取りすることが必要。

• アーキテクチャ思考

  • 技術者は技術的な深さが求められるが、アーキテクトは技術の幅が重要となる。技術を幅広く理解し、それを使って具体的な解決策を検討することが求められる。
  • 専門性の陳腐化を防ぐために常に最新の技術のキャッチアップが重要。
  • あらゆるソリューションのトレードオフを考えることが重要。あらゆることが**「場合による」**。
  • ビジネスドライバを意識する。
  • アーキテクティングとコーディングのバランスを取る。=理想と現実を考え実現可能なソリューションを採用する。

• アーキテクチャ特性
  以下のような特性を理解することが重要

  • 運用特性
    • 可用性、継続性、パフォーマンス、回復性、信頼性/安全性、堅牢性、スケーラビリティ
  • 構造特性
    • 構成容易性、拡張性、インストール容易性、活用性/再利用性、ローカライゼーション、メンテナンス容易性、可搬性、アップグレード容易性
  • 横断的特性
    • アクセシビリティ、長期保存性、認証、認可、合法性、プライバシー、セキュリティ、サポート容易性、ユーザビリティ/達成容易性

• アーキテクチャ特性の計測

  • 運用面、構造面、プロセス面からアーキテクチャ特性を計測し、統制が取れた状態を維持するように意識する。

• アーキテクチャスタイル
  この本で一番楽しみにしていた部分です。
  それぞれ概要ではありますがわかりやすく書かれており、特性も評価されているので実務でアーキテクチャを検討する際に参考になると思います。

  • レイヤードアーキテクチャ：一般的によく使われるn層アーキテクチャ
  • パイプラインアーキテクチャ：パイプとフィルタで構成されるアーキテクチャ
  • マイクロカーネルアーキテクチャ：製品ベースのアプリケーションでよく使われるもの
  • サービスベースアーキテクチャ：柔軟性が高くもっとも実用的なアーキテクチャの一つ
  • イベント駆動アーキテクチャ：分散非同期型のアーキテクチャ
  • スペースベースアーキテクチャ：高スケーラビリティ、高弾力性、高い同時実行性を持ったスタイル
  • オーケストレーション駆動サービス指向アーキテクチャ：初めて聞きましたが無用の長物になったらしい。
  • マイクロサービスアーキテクチャ：クラウドソリューションでもよく使われる近年人気のアーキテクチャ

★各アーキテクチャに絶対の正解はなく、特性やトレードオフを意識し選択する必要がある

• ソフトスキル
  • ADRを残すことが大事
  • リスク分析をしっかりと行うことが重要
  • アーキテクチャを図解、プレゼンするためのスキルを磨くことが必要
  • 効果的なチームを作るためのリーダーシップが重要
  • ビジネス上のステークホルダーや他のアーキテクト、技術者と交渉するためのコミュニケーションや交渉、ファシリテーションスキルが重要
  • 技術にアンテナを張って、常に最新の技術や変化をキャッチアップできるようにする

アーキテクトの教科書 価値を生むソフトウェアのアーキテクチャ構築

アーキテクティングという世界を探検するにあたって地図となるような本

この本はアーキテクトを目指す方や経験の浅い方でも読める本を目指していることから、前述の「ソフトウェアアーキテクチャの基礎」よりもわかりやすく書かれていることがポイントです。
現在のソフトウェア開発を取り巻く環境から設計の昔と今の変遷、資質や実践、アーキテクトとしての成長するにはどうすればいいかまで網羅的にまとめられています。
また、ユースケースをもとに解説があったり、サンプルコードも充実しているので初学者にはイメージしやすいと思います。

簡単にポイントをまとめると

• アーキテクトの仕事

  • IT戦略を実現するための最適なアーキテクチャ設計と実現がアーキテクトの重要な職務。
  • アーキテクトに重要な資質として設計力・コーディング力、抽象化能力、ビジネスの理解、好奇心、完璧主義より合理主義であることが重要。

• ソフトウェア設計

  • アーキテクチャレベルの設計上の問題を解決するには、アーキテクチャスタイルとアーキテクチャパターンがある
  • アーキテクチャスタイル：ソフトウェアの編成の仕方や相互作用についての包括的な構造
  • アーキテクチャパターン：特定の解決策を形成するのに役立つ低レベルの設計構造

• アーキテクチャの設計
  こちらの書籍でも前述のものと同様にアーキテクチャスタイルの紹介されています。違いとしてはこちらの方はケーススタディを交えながら解説されているので非常にわかりやすく、頭にすっと入ってきやすいのかなと思います。

  -4つの側面（達成すべきこと、設計判断、システムの形状、文書・規約・ガイドライン）でとらえることが必要。
  -アーキテクチャドライバ（制約、品質特性、影響を与える機能要求、その他影響を及ぼすもの）を整理する必要がある。
  -**アーキテクチャの選定はトレードオフである。**総合的にみて妥当なものを採用する設計判断を行う必要がある。

  • 各アーキテクチャの紹介（割愛）、クリーンアーキテクチャも含まれていました。
  • アーキテクチャの比較評価はマトリクスを活用し、トレードオフ分析を行うこと。
  • ADRに設計判断を落とし込む必要がある。

• アーキテクチャの実装
  この部分も設計と同様にユースケースをもとにポイントやサンプルコードを使って解説されており、非常にわかりやすかったです。

  • アーキテクトが役割として取り組むのはアプリ基盤の構築と開発フローの構築。
  • ドキュメントや仕様書の標準化を行うことが重要。
  • 構成管理とCI/CDの検討も重要。

• 品質保証とテスト

  • テストを行うだけではなく、適切なレビューや解析ツールの導入、プロセスやドキュメントの標準等ソフトウェアの品質を向上し、維持するために必要なあらゆるアプローチを包含する。
  • シフトレフトの考え方も重要。
  • テスト戦略の立案やテストの自動化も検討する必要がある。

• 学習と成長

  • アーキテクトはアーキテクティングを専門領域とするスペシャリストであると同時に、ソフトウェアエンジニアリング全般の知識や経験を有するジェネラリストであることが求められる。
  • コミュニケーションやリーダーシップ等のソフトスキルも重要。
  • 希望に沿わないアサインでも前向きにとらえる。
  • インプットと同時にアウトプットも重要。

感想

いずれの書籍もアーキテクトとしてのあるべき姿や心構え、実際のアーキテクチャの解説や選定の際のポイント等網羅的に書かれており、非常に学びのあるものだと思います。

• 「ソフトウェアアーキテクチャの基礎 ―エンジニアリングに基づく体系的アプローチ」
  アーキテクチャとは何か、アーキテクトはどういったことを考え、取り組む必要があるかについて体系的にまとめられた書籍です。
  こちらはある程度経験を積んだエンジニアでないと難しい部分があるのかなと思います。
  個人的には学びが多く、改めて自分のポジションややるべきことを再認識することができました。
  この書籍に書かれていたように色々な技術にアンテナを張って技術の幅を広げていければと思います。

• 「アーキテクトの教科書 価値を生むソフトウェアのアーキテクチャ構築」
  初学者だけではなく、経験を積んだアーキテクトにもこれまでの知識を整理することができるのでおすすめできる書籍です。
  ユースケースに沿ってわかりやすく解説されていたり、品質保証やテストの観点にも触れられているのでソフトウェアアーキテクチャの基礎を読んでいる方が読んでも新たな気づきや学びがあると思います。
  この書籍を読んだうえで「ソフトウェアアーキテクチャの基礎」や「Design It!」等を読むか、個別のアーキテクチャの学習を進めるのが良いのかなと思います。

  著者が目指しているようなアーキテクティングという世界を探検するにあたって地図となるような本だと思います。

おわりに

ここからポエムみたいになってしまったので興味がない方は上記の感想まで読んでもらえたら大丈夫です。

どちらの書籍も非常に多くの学びがあり、楽しく読み進めることができました。
私の所属しているようなSIerのエンジニアは特定の技術を極めることはなかなか難しく、プロジェクト毎に様々な技術やサービスを組み合わせながらソリューションを検討することが多いです。
また、実際に手を動かすよりも要件定義やマネジメントの比率が高く、いつまでも手を動かすだけのポジションでいることはできません。

こういった環境でエンジニアとしての強みになるのは、この書籍に記載されているような技術の幅です。
様々な選択肢の中からメリデメを検討したうえで最適なソリューションを選択する場面が多く、顧客への提案やプロジェクトメンバーへのアーキテクチャのガイド等アーキテクト的な動きが求められます。

私個人としてもこれまで24/365のグローバルなシステムや、自社パッケージソフト、グループ会社向けの小さなシステムまで多種多様なプロジェクトに参画し、プロジェクトによってテックリードだったり、プロジェクトマネージャーだったり、コンサルだったり様々なポジションを担ってきました。
こういった経験を積む中でいつしか様々な技術セットやドメイン知識を身に着けることができました。
新卒の時に考えていたような技術特化のスペシャリストにはなることはできませんでしたが、幅広い技術知識を持ったジェネラリストとしてのアーキテクトにはなることができたのかなと思います。

また、周りより早めにラインマネジメントを担当することにもなり、技術だけというわけにもいかなくなりました。
そういった中でも私は技術を諦めたわけではなく、引き続き活動を続けています。
常にアンテナを張ること、尖った技術ではなく幅広く技術をキャッチアップするアーキテクト思考でいることを意識しています。
昨年より全社的な技術イベントの取りまとめや部門の技術力向上のリードを任されたり、他部門から技術アドバイザーを依頼されたりと少しずつ自分のポジションを確立できたのかなと思います。

世間一般で言われるようなSIerは技術力が低く、マネジメントばかりでエンジニアとして成長できないという話もあながち間違いではありませんが、会社、部門、プロジェクトによって状況は変わります。
紹介した書籍でいうところの「場合による」ですね。
なにより、技術をあきらめずに社内政治含めた立ち回りや社内外へのアピールを続けていけばきっとエンジニアとしてのチャンスや成長につながると思います。