いくお先生のXのポストを見てなんとなく気になったので購入して読んでみました。
概要
今日のソフトウェア開発を取り巻く状況をふまえてつつ、アーキテクチャの重要性やアーキテクトの必要性について分かりやすく解説されています。また、ソフトウェアが実際のビジネスシーンで使われ続けていく中で、アーキテクトとして注意すべきポイントについても解説されています。ソフトウェア開発の全体像を把握しつつアーキテクトとしての基本的な知識を得る（または再認識する）ことが主な狙いであるため、アーキテクチャあるいはアーキテクトの特定の領域を深くを掘り下げるものではありませんのでご注意ください。
感想
書籍のタイトルに「教科書」という文言が入っているとおり、ソフトウェア開発の全体をざっくりと把握しつつ、ソフトウェアのアーキテクトとして必要な基本的な知識を体系的に把握するには良い本だと思えました。情報として既知のものも多かったですが、これまで個別に学んできた事柄（点）同士を繋げて全体像を意識してある程度体系的に理解できた気がします。書籍の紹介ページにも記載されているとおり「これからアーキテクトを目指す方」「アーキテクトとしての経験が浅い方」「駆け出しのITエンジニア」「ソフトウェアアーキテクチャの基礎知識を学びたい方」「自分の知識や経験の棚卸しをしたいアーキテクト」といった用途に適していると思えました。
これまでに読んだ書籍（例：『ソフトウェアアーキテクチャの基礎』など）からの引用も多く、内容の整合性も取れていることから混乱することなく内容を理解できました。また、最近読んだ書籍『ドメイン駆動設計をはじめよう』との関連も多く、読む時宜という点でも、ちょうど良かったかもしれません😀
本書を読んでみて印象に残った点を中心に以下に書き留めておきます。
印象に残った点
印象に残ったフレーズや共感できた点などを以下にメモしておきます。
１章 アーキテクトの仕事
1.1 現代のソフトウェア開発をとりまく環境
▶ DX（デジタルトランスフォーメーション）とその課題
【Page：29】
"DXという言葉はバズワード化してしまい、定義が曖昧なままに濫用されることも少なくありませんが、経済産業省が2020年に公表した『DXレポート2（中間取りまとめ）』によると、三つの段階に分けて考えることができます。
- デジタイゼーション（Digitization）：アナログ・物理データのデジタルデータ化
- デジタライゼーション（Digitalization）： 個別の業務・製造プロセスのデジタル化
- デジタルトランスフォーメーション（Digital Transformation）：組織横断/全体の業務・製造プロセスのデジタル化、“顧客起点の価値創出”のための事業やビジネスモデルの変革"
▶ DX時代のIT戦略
【Page：31-33】
"取るべき方針は、SoE（System of Engagement：顧客との繋がりを強化するITシステム）とSoR（System of Record：企業活動に関わる情報を記録するためのITシステム）とで異なってくるでしょう。"
・SoRの領域
"SoRの領域では、これまで以上にERP（Enterprise Resources Planning：企業の経営資源を統合管理する手法やソフトウェア）やSaaS（Software as a Service：クラウド上でサービスとして提供されるソフトウェア）の活用が進んでいくでしょう。（中略）これからのDX時代においては、ERPの標準機能をそのまま活用し、自分たちの業務プロセスを業界のベストプラクティスに合わせていく「Fit to Standard」の考え方が重要となります。（中略）一方で、SoR領域の中でも自社の事業活動に競争優位をもたらす業務も存在します。たとえば、ロジスティクスの会社において、競合他社よりも効率よく早く商品配送を可能とする業務の仕組みなどです。そのようなコアとなる業務に関しては、個別のシステムを開発してERPと連携させるという判断は理にかないます。"
・市民開発
"昨今のIT人材不足を背景とし、非IT人材である業務部門の従業員による「市民開発」の機運も高まっています。RPA（Robotic Process Automation：人間がパソコン上で行う定型的な業務処理を記録し自動実行する仕組み）ツールや、マイクロソフト社のPower Platformに代表されるローコードツール、ノーコードツールの発展も後押しとなっています。"
1.4 アーキテクトとは
▶ アーキテクトの定義
【Page：41-43】
・ITスキル標準V3でのITアーキテクト
"情報処理推進機構（IPA）がまとめた『ITスキル標準V3 2011』では、ITアーキテクトの職種を以下のように説明しています。
- ビジネス及びIT上の課題を分析し、ソリューションを構成する情報システム化要件として再構成する。
- ハードウェア、ソフトウェア関連技術（アプリケーション関連技術、メソドロジ）を活用し、顧客のビジネス戦略を実現するために情報システム全体の品質（整合性、一貫性等）を保ったITアーキテクチャを設計する。
- 設計したアーキテクチャが課題に対するソリューションを構成することを確認するとともに、後続の開発、導入が可能であることを確認する。
- また、ソリューションを構成するために情報システムが満たすべき基準を明らかにする。さらに実現性に対する技術リスクについて事前に影響を評価する。
また、当該職種は「アプリケーションアーキテクチャ」「インテグレーションアーキテクチャ」「インフラストラクチャアーキテクチャ」の専門分野に区分されるとされています。"
・情報処理技術者試験でのシステムアーキテクト
"同じIPAが管轄する情報処理技術者試験の区分の一つであるシステムアーキテクト試験（SA）では、その業務と役割を以下としています。
- 情報システム戦略を具体化するための情報システムの構造の設計や、開発に必要となる要件の定義、システム方式の設計及び情報システムを開発する業務に従事し、次の役割を主導的に果たすとともに、下位者を指導する。
"
・アーキテクトの主要な職務
"企業のIT戦略を実現するための最適なアーキテクチャの設計ならびに実現がアーキテクトの主要な職務となります。
そのため、アーキテクトは単に技術トレンドに目を向けるだけではなく、企業の事業活動のビジョンやミッション、それに基づく経営戦略やIT戦略を正しく理解した上で、業務部門の人たちと円滑にコミュニケーションを取ることが求められます。"
1.6 アーキテクトに必要な脂質
▶ アーキテクトが備えるべき能力や考え方
【Page：51-53】
・設計力、コーディング力
・抽象化能力
・ビジネスの理解
・好奇心
・完璧主義よりも合理主義
"（前略）ソフトウェアのアーキテクチャの同様で、すべての項目で満点を取れるアーキテクチャは存在しません。課題に優先順位をつけて取り組み、ほどほどに良いアーキテクチャを目指すべきです。アーキテクチャは目的ではなく手段であると認識し、合理的な判断を下すこともアーキテクトの役目です"
２章 ソフトウェア設計
2.1 ソフトウェア開発プロセス
▶ ソフトウェア開発のアクティビティ
【Page：61】
⋯■実装・テスト
"（前略）注意が必要なのは、V字モデルにおける工程の分け方や名称はまちまちであり、統一された標準モデルはないということです。たとえば、「単体テスト」がプログラム単位なのか、画面単位なのか、はたまた機能単位なのかは企業やプロジェクトによって異なります。
重要なのは、自分たちのプロジェクトで採用する開発プロセスに合わせて、適切なテスト計画を立てることです。また、ウォーターフォールかアジャイルかに関わらず、早い段階からテストを行うシフトレフトのアプローチも有効です。"
2.2 ソフトウェア設計の抽象レベル
▶ 四つの抽象レベル
【Page：63-64】
⋯■クラス設計
⋯■コンポーネント設計
"（前略）コンポーネントという言葉はよく使われますが、その定義はまちまちで、文脈によって異なる意味で使われることもあります。一例としてSWEBOK V3.0では以下のように定義されています。
ソフトウェア・コンポーネントとは、独立した単位であり、明確に定義されたインターフェースと依存関係を持ち、独立して構成・配置することができる。
Spring Framework のようなDIコンテナで管理対象となるようなものが、まさにコンポーネントです。"
⋯■モジュール設計
"（前略）モジュールとはコンポーネントの集合体です。"
⋯■アーキテクチャ設計
2.3 ソフトウェアの設計原則とプラクティス
▶ SOLID原則
【Page：71】
⋯■SRP：単一責任の原則
"とてもシンプルな原則ですが、悩ましいのは役割をどの粒度で捉えればよいかという点です。極端な話、それぞれのクラスが一つのinstance variableと一つのメソッドだけで構成されるまで分割すればよいかというと、そういうことでもありません。"
【Page：83】
⋯■DIP：依存関係逆転の原則
"DIPは、SOLIDの他の四原則よりも抽象レベルを上げて考える必要があります。DIPは、コンポーネントやモジュール分割をする際の依存関係について定めたものだからです。"
▶ その他のポイント
【Page：88】
⋯■二種類のロジック
"（前略）「値引きや発送料込みの注文金額の計算を行う」処理は、注文オブジェクトの振る舞いとして実装されるでしょう。このように業務の知識やルールを表すものが中核ロジックです。ビジネスロジックの中でもドメインロジックと呼ばれます。
「注文金額を計算し、決済手段の有効性が確認できたら、在庫を引き当てた後、注文を登録する」という一連の流れは、注文登録サービスの振る舞いとして実装されます。このように業務処理の手順を表すものが処理フローロジックです。ビジネスロジックの中でもアプリケーションロジックと呼ばれます。処理フローロジックは複数のオブジェクトを適切に協調させる調整役と捉えることができます。"
【Page：89】
⋯■二種類のロジック
"（前略）このようにソフトウェアはフラクタル構造を取っていると見ることができます。"
2.4 設計パターン
▶ デザインパターン
【Page：92】
"「生成に関するパターン」「構造に関するパターン」「振る舞いに関するパターン」の三つの分類で、合わせて23のパターンが存在します。"
▶ アーキテクチャスタイルとアーキテクチャパターン
【Page：94】
⋯■アーキテクチャスタイル
"ソフトウェアのソースコードの編成の仕方や相互作用についての「包括的な構造」と定義されます。全体的な方針を定めるコンセプトであり、アーキテクチャパターンの上位機に位置付けられる抽象度の高いものと考えてください。"
⋯■アーキテクチャパターン
"「特定の解決策を形成するのに役立つ低レベルの設計構造」と定義されます。アーキテクチャの方針を具体的なコードに落とし込んでいく際に適用するパターンであるため、2.2節で挙げた四つの抽象レベルでいうと、モジュール設計やコンポーネント設計にあたるところまでをカバーします。
３章 アーキテクチャの設計
3.1 アーキテクチャ設計の概要
▶ アーキテクチャの定義
【Page：100】
"
アーキテクチャ
環境におけるシステムの基本的な概念や特性が、その要素や関係、および設計と進化の原則に具体化されたもの
（中略）本書では、アーキテクチャを図3.1.1に示す四つの側面で捉えます。
- アーキテクチャによって達成スべきこと：ビジネス要求、機能、品質特性
- 設計判断：比較評価マトリクス、ADR
- システムの形状：アーキテクチャモデル
- 文書・規約・ガイドライン：アーキテクチャ記述、開発規約、（自動化された）チェック
"
3.2 アーキテクチャドライバの特定
▶ アーキテクチャドライバとは
【Page：106】
"アーキテクチャを検討する上で重要な考慮事項のことを、アーキテクチャ上重要な要求またはアーキテクチャドライバと呼びます。"
3.3 システムアーキテクチャの選定
▶ サービス分割
【Page：106】
⋯■Sagaパターン
"（前略）ところで、Sagaパターンを実現するには、左記の例の注文処理サービスのようにサービス間の調整役を置くオーケストレーションという方式と、調整役は置かずに各サービスが自律的に相互調整を行うコレオグラフィという方式があります。関係するサービスの数が少なく単純なケースを除いて、オーケストレーション方式を採用した方がよいでしょう。第２章で設計のポイントとして述べたとおり、処理フローロジックを担う役割は明確に分離した方が全体の見通しがよくなるからです。"
3.4 アプリケーションアーキテクチャの選定
▶ レイヤードアーキテクチャ
【Page：146】
"（前略）この問題点を解決する方法として、依存関係逆転の原則（DIP）を適用したレイヤードアーキテクチャの亜種と言えるものが考え出されました。オニオンアーキテクチャ、ヘキサゴナルアーキテクチャ、クリーンアーキテクチャなどです。これらのアーキテクチャは厳密には細かな差異はあるものの、主目的とコンセプトは同一で、アプリケーションにおいて最重要であるドメイン層を中心に据えることです。"
3.5 アーキテクチャの比較評価
▶ 比較評価マトリクスによるトレードオフ分析
【Page：160】
"
（Column）
アーキテクチャプロトタイピング
アーキテクチャ上の選択肢を比較評価するにあたっては、社内外の様々な情報源から収集した情報を活用しますが、机上の検証だけでは結論を導けないことがあります。たとえば技術的なリスクの解消に確信を持てない場合や、パフォーマンスに関するリアルなデータを収集したい場合などです。
その場合は実際にコードを書いたり、ツールを触ってみたりするなど技術検証を行います。検証項目が多岐にわたる場合、それらを確認できるようなサンプルのアプリケーションを作ることがあります。
"
3.6 アーキテクチャの文書化
▶ アーキテクチャ記述
【Page：163】
"（前略）ADRは個々の設計判断を記録し共有することを目的とした軽量な文書ですが、アーキテクチャ全体を説明する文書も作成する必要があります。この文書は、アーキテクチャドキュメント、アーキテクチャ記述（SAD：Software Architecture Description）、アーキテクチャ説明書などの名称で呼ばれるものですが、本書ではアーキテクチャ記述という表記に統一します。"
▶ アーキテクチャモデル
【Page：171】
⋯■C4モデル
"経費精算のケーススタディを題材に作成したシステムコンテキスト図の例を図3.6.5に示します。"
４章 アーキテクチャの実装
4.2 仕様書の標準化
▶ 設計書の標準化
【Page：188】
"（前略）一方で、どんなプロジェクトでも作成した方がよい設計書があります。ER図やテーブル一覧、テーブル定義書といったデータベースに関わる設計書です。"
4.3 ユースケース駆動のアーキテクチャ実装
▶ ユースケースの実装
【Page：195】
"（前略）ドメインを中心に据えるというクリーンアーキテクチャの思想からするとエンティティ層とユースケース層から取り掛かるのは筋が通っているのですが、アプリケーション基盤の観点ではこの層に用意すべき共通機能は多くないため、あまりそれにこだわる必要はありません。筆者の場合、早い段階で画面が表示されることを確認したいので、まずはコントローラー周辺（①）から着手することが多いです。"
4.4 アプリケーション基盤の実装
▶ トランザクション制御
【Page：211】
⋯■トランザクション制御の実装方法
"（前略）もう一つは宣言的トランザクションです。処理内に直接トランザクション制御を記述するのではなく、設定ファイルやアノテーションを用いてトランザクションのスコープや振る舞いを定義する方法です。"
５章 品質保証とテスト
5.1 アーキテクトと品質保証活動
▶ テストタイプ
【Page：233】
"（前略）各々の品質特性に対して適切なテストを実施することで、開発したソフトウェアが品質基準を満たすことを検証します（図5.1.11）。"
5.2 機能テストの自動化
▶ ユニットテスト
【Page：240】
"（前略）もし他のユニットへの依存がある場合、実際の依存先ユニットを模倣して振る舞うテストダブルと呼ばれるユニットテストで代替します（図5.2.3）。図のBarStubクラスがBarクラスを代替するテストダブルです。
（Column）
テストダブル
- スタブ（Test Stub）
- スパイ（Test Spy）
- モック（Mock Object）
- フェイク（Fake Object）
- ダミー（Dummy Object）
"
▶ インテグレーションテスト
【Page：245】
"（前略）ユニットテストとE2Eテストとの間の粒度のテストは、すべてインテグレーションテストと言えます。ですので、ユニットテストにおけるユニットの定義をプログラムの最小単位とする方法だと、二つ以上のプログラムを統合して行うテストがインテグレーションテストです。振る舞いの単位とする方法ならば、二つ以上のコンポーネントを統合するテストがインテグレーションテストです。"
▶ E2Eテスト
【Page：250】
⋯■E2Eテストの特徴
"
（Column）
振る舞い駆動開発（BDD）
（前略）BDDでは、フィーチャー（ユーザーストーリーなどで定義される、ユーザーにとって意味のあるまとまった振る舞い）の実装に入る前に、フィーチャーの仕様を受け入れ条件という形で明確化します。
"
⋯■ユニットテストのポイント
"（前略）なお、メソッド呼び出しの検証を行うための、テストダブルとしてスタブではなくモックを用います。
（中略）処理フローロジックの正しさはユニットテストで検証するのではなく、より上位のテスト（インテグレーションテストやE2Eテスト）に任せた方がよいというのが筆者の意見です。
（中略）筆者の経験上、テスト駆動開発やテストファーストで開発を進めると自然と90%を超えるカバレッジに到達するので、90%以上は一つの目安となる数値だと思います。"
⋯■E2Eテストのポイント
"E2Eテストは作成コストと実行コストが大きいため、品質保証のためと言ってテスト数を増やし過ぎると、開発生産性やそのほかの品質特性を下げる要因となってしまいます。從って、E2Eテストの目的と範囲は明確にしておく必要があります。
（中略）
（Column）
テストコードへの投資
（前略）散らかったテストコードは技術的負債であり、プロダクションコードの品質低下や、プロダクトの開発速度の低下などの大きな問題を生み出す要因となります。ですから、テストコードにも必要な投資を行って負債化を防ぐべきなのです。
テストコードの可読性や保守性を高めるためには、次の三つを意識するとよいでしょう。筆者は頭文字を取ってテストコードのSOSと呼んでいます。
- 構造化されている（Structured）
- 整理されている（Organized）
- 自己文書化されている（self-documenting）
"
5.3 パフォーマンステスト
▶ パフォーマンステストの全体像
【Page：262】
"パフォーマンステストは、システムが性能効率性という品質特性を満たしていることの検証を目的としたテストです。パフォーマンステストは、検証の観点によってさらにいくつかのテストタイプに別れます（図5.3.1）。
（中略）
筆者の経験上、パフォーマンステストの全体のリード役はアーキテクトが担うことが多いです。計画の立案からテストの準備、テストの実行、問題発生時の解決策の検討など、各局面において広範囲に及ぶ技術知識が求められるため、アーキテクトが主導するのが効果的だからと言えるでしょう。"
▶ 負荷テスト
【Page：266】
"負荷テストでは、業務のピーク時にシステム全体として所定のパフォーマンスが達成されることを検証します。そのため、単機能性能テストがチューニングを含めて完了していることが前提条件となります。少なくとも、負荷テストシナリオに含まれる機能については単機能性能テストが完了していなければなりません。"
６章 アーキテクトとしての学習と成長
6.1 アーキテクトとして成長するために
▶ アーキテクトの人材像
【Page：277-288】
"（前略）アーキテクトはアーキテクティングを専門領域とするスペシャリストであると同時に、ソフトウェアエンジニアリング全般の知識や経験を有するジェネラリストであることが求められます。
（中略）
アーキテクトという職種を選択し、その専門領域としてアーキテクティングを深耕していくためには、その土台として、IT技術やソフトウェアエンジニアリングに関する幅広い知識や経験を有することが必要となります。
その上で、アーキテクティングに関する手法を学び、実際の業務で経験を積んでいきながら、アーキテクティングという中心の柱を太くしていきます。"
▶ 成長の道筋
【Page：280】
⋯■基礎技術の習得
"（前略）すべての項目で一定水準に達しないとアーキテクトの仕事が始められないというわけではなく、当然得意分野や苦手分野もあるでしょうが、遅くともアーキテクトとしての修行期間中には足りていない箇所を補っていく必要があります。"
【Page：280】
⋯■業務知識とソフトスキルの習得
"（前略）ソフトスキルはとても重要です。素晴らしい技術力を持っていたとしても、それをうまく発揮して、システムやプロダクトがもたらす価値へ変換できなければ意味がありません。技術力をいかんなく発揮し、ユーザーや顧客へ価値を届ける素晴らしいソフトウェアを開発することでビジネスに貢献する力を、技術貢献力と呼ぶことにします（図6.1.4）。技術貢献力は、アーキテクトが有する技術力とソフトスキルの掛け算です。技術力を最大限に活かすためにはソフトスキルの強化が欠かせません。
ソフトスキルの源泉はリーダーシップです。リーダーシップとは、自分に求められた役割と責務を理解し、正しいゴールを設定して主体的に行動する意志のことです。チームリーダーやサブリーダーといった体制上の役割名を与えられているかどうかとは無関係に、プロジェクトに参加する全員がそれぞれのリーダーシップを発揮するべきです。"
▶ 仕事との向き合い方
【Page：282】
"アーキテクトとしてのキャリアアップと、アサインされる仕事の内容とがうまくマッチしていることが理想的ですが、実際にはそう都合よくいかないこともあります。おそらくみなさんのマネージャーは、個々人のキャリア志向と組織の目標達成とのバランスを取った最適な人員配置を試みているはずですが、時には本人の希望に沿わないアサインをお願いしなければならないこともあります。
そのような場合でも、決して後ろ向きになってしまわないことです。スペシャリストであると同時にジェネラリストであるアーキテクトにとって、幅広い知識と経験は大きな武器となるものです。おおよそどんな仕事でも無駄になることはありません。幅を広げるチャンスを得られたと前向きに捉え、その仕事を通して何を見出すか、どんな力を身につけるかを考えることが生産的だと言えます。"
6.2 効果的な学習方法
▶ インプット
【Page：284】
⋯■書籍
"多読によって様々な分野の情報を幅広く知ることもよいのですが、活用可能な知識としての質を高める上で重要なのは、良書を見つけ、良書を繰り返し読むことです。読書術に関する有名な書籍『本を読む本』では、良書の内容は一度読んだだけで到底理解できるものではなく、分析的に何度も読む必要性を説いています。
分析読書とは、取り組んだ本を完全に自分の血肉と化するまで徹底的に読み抜くことである。
"
▶ アウトプット
【Page：287】
⋯■読書マップ
"読んだ書籍の内容を自分なりに整理し、要点をまとめることによって、理解を深める効果と記憶定着の効果を得ることができます。"
