エンタープライズアーキテクチャの終焉（また？）

アジャイルもよく終わるけど、エンタープライズアーキテクチャ（EA）もよく終わる。最近読んだ「大規模データ管理 ―エンタープライズアーキテクチャのベストプラクティス」（第1版）でまた終焉してたので考えたことを書く記事。なお読んでいる間に第2版が発売されてしまったようで、しょんぼり。

大規模データ管理 第2版 ―データ管理と活用のためのモダンなデータアーキテクチャパターン

先に自分の意見を表明しておく

システム構築におけるバイモーダル戦略と同じように、EAにも状況によるグラデーションがあるのではないかと最近考えている。図にするとこんな感じだ。

• 法制度や規制に近い領域では、静的で強固なEA、より細かく言えばビジネスアーキテクチャBAやデータアーキテクチャDAが要求される
• 一方で変化する時代や市場に適応すべき領域（加速する世界）では従来型の静的なEAは成立しない。動的なEAに変化することが求められる
• SoE/SoRはどちらも競争圧力（高度化＋コスト圧縮）がかかるので図でいう右上へのシフトが求められ続ける

何が言いたいのかというと、従来型のEAが通用する領域は現在も存在しているのだが、それはひどく小さくなっているということだ。これが現在の私の意見てある。

従来のエンタープライズアーキテクチャの終焉

さて、「大規模データ管理 ―エンタープライズアーキテクチャのベストプラクティス」の話に戻ると終章にて次のようにある。

11.4 従来のエンタープライズアーキテクチャの終焉

エンタープライズアーキテクトの役割は、アーキテクチャそのものと同じくらいに変化するでしょう。（中略）このような役割（戦略家、高度な技術を持つエンジニア、情報管理者）は、従来の「静的なオブジェクトやダイアグラムだけで考え、IT部門の奥深くにいるアーキテクト」という固定観念とは大きく異なります。エンタープライズアーキテクチャ（EA）を実践するには、新しい時代に合わせて、さまざまな役割を行う必要があり、多様な領域に注力しなければなりません。

詳細は同書の11章を参照いただくとして、この後には概ねこんなことが書かれている。

• 形式化されたモデルやVisioダイアグラムは、動きの激しい現代では通用しない
• エンタープライズアーキテクトは専門家から問題解決者に変わらなければならない
• コントロール（取り締まり）モデルから脱却して、別の形のガバナンスを実現しなければならない

これは、以下のように言い換えてもよいだろう。

• 委員会モデル（EA評議会のような）でのデータマネジメントはもうダメだ。つまり企業として単一／標準的なモデルをコンサルタントが策定し、それを個別の各システムに守らせたり、守っていることを証明させるようなマネジメントは現実的ではない。
• 少なくともデータに関しては、データアーキテクト自らが個別のシステム開発プロジェクトに入り、ビジネスユーザーと一緒にデータモデル上の問題解決を図るようなアプローチを目指すべきだ。

簡単ではないだろうが、理想としてはよく分かる。

Complex Enterprise Architectureへ

そういえば2019年に読んだ「Complex Enterprise Architecture: A New Adaptive Systems Approach (English Edition)」でも、EAを複雑適応系として扱うべき（＝静的なものではなく、動的なものとして考える）という話だった。

agnozingdays.hatenablog.com

• 新EAはトップダウンのアプローチをやめる。企業情報システムの全容を少数のエンタープライズアーキテクトが掌握、管理することは現実的ではない。そこで組織の創発的な行動に任せて、目標の達成方法を把握しながら監視することに集中する。
• 新EAは各システムの互換性や相互運用を可能とするための規律と制約を策定、共有する。

ただ、この時も書いたのだけれども方向感は納得できる一方で、どのように運用していくべきなのかのイメージがまだついていない。

むしろ現代的にはAI利活用を中心とした巨大なデータプラットフォームを構築してしまい、力業で解決する方向性に言ってしまうという可能性もあるのだろうか。

探索は続く……

「データモデリングでドメインを駆動する」を読む Part.2

読むのがホネな技術書やビジネス書を取り上げて2週間の読書期限を課して読んでアウトプットする仮想読書会「デッドライン読書会」の第66回。同僚と読書期限を約束することによって積読が確実に減るという仕組み。過去記事はこちら。

さて、今回は前回に引続き「データモデリングでドメインを駆動する──分散／疎結合な基幹系システムに向けて」である。前回、前半の第2部まで読んだが、今回は残りを最後まで読んだ。

データモデリングでドメインを駆動する──分散／疎結合な基幹系システムに向けて

「データモデリングでドメインを駆動する」はレコード駆動設計（？）の本

前回の記事では本書を以下のように紹介した。

さて、（まだ半分しか読んでいないけど）本書は概ねこのような本である

• 既存の基幹系システムを概観し、課題を指摘した上でよりよい基幹システム像を提言する（第1部）
• 基幹システム（SoR）を、活動のシステム（SoA）と経営管理のシステム（SoM）に大きく分離し、データアーキテクチャレベルで検討する（第2部）
• 横断的な関心事となりそうな重要要素について整理検討する（第3部）※まだ読んでない
• データモデリングの基礎を再考する（第4部）※まだ読んでない

今回通読し、あらためて本書は（このような表現をされてはいないのだけれども）レコード駆動設計の本という印象を持った。

• 本書で通底するテーマはビジネスの核心としての「帳簿」である。そういう意味では帳簿駆動設計になるのだが、帳簿という言葉の印象もまた広すぎるので、あえて言うなら「（ビジネス）レコード駆動設計」と考えるのが個人的には良さそうに思えたのだった。
• 類似のコンセプトは、業務設計に関する素晴らしいエッセイ集である「Web世代が知らないエンタープライズシステム設計」で示される「帳簿組織を意識した設計（帳簿設計）」というコンセプトの詳解版とも言えるだろう。
• ドメイン駆動設計（DDD）の良さと重要性は認めつつ、その危うさを指摘し、エンタープライズ企業システム設計における要点を、今は薄れつつあるデータ中心設計（DOA）から展開した設計論で拡張している。

かなりハイレベルな内容を扱っているので、ビギナーにはお勧めできない一方で、一度でもエンタープライズ企業システム設計に関わり悩んだ人であれば、非常に大きな学びが得られる本だと思う。
またエンジニアではなくビジネスユーザーの立場で、要件定義やデータ設計に課題感がある人にも（ちょっと難しいけれど）ぜひ目を通して欲しい本である。

Web世代が知らないエンタープライズシステム設計

上流工程でデータモデリングが軽視されがちな問題

というわけで本書は極めて良い本なのだけれども、一方で上流工程でデータモデリングはあいかわらず軽視されがちである。これを何とか出来ないものか
DXブームとアジャイル開発手法の追い風もあって、現在主流の要求分析の手法はユーザー中心的なアプローチである

• ユーザー中心的なアプローチとは、ユーザーストーリーやそれに類する要求分析手法のこと
  • もちろんこの手法は誤りではない。機能中心の分析に比べれば極めて適切な進歩ではある
  • しかしエンタープライズ向けの基幹システム設計には向いていない。この点についての理解がまだ業界的には正しく出来ていない印象だ
• 例えばIPAのユーザー向け要件定義ガイドではデータモデリングの重要性は語られているが、浸透していないのが実情ではないか
• ドメイン駆動設計によって、ある程度「ドメインについて深く考察する」重要性は再認識されつつあると思う一方で、これは本書で指摘される通り別の課題もあるのだ

ドメイン駆動設計は、ソフトウェア作りという私たちの日々の営為をドメインにおける情報処理の進化と結び付けたいという、エヴァンス氏の希望から生まれたものととらえています。知識のかみ砕き、深いモデルといった表現はそのことをよく表しています。そうした思想は広範な支持を集めました。しかしその一方で、軽量DDDにみられるとおり、ドメインに対峙せずに実装に近い設計を競う換骨奪胎的な動きも広くみられます。また、帳簿の重要性を看過し、過剰に計算判断寄りになる傾向や、過剰にドメイン寄りになって、技術がもたらす可能性を十分に活用しない傾向など、設計における焦点のズレを助長している面があるようにも見受けられます。
データモデリングでドメインを駆動する──分散／疎結合な基幹系システムに向けて、14.5 ドメイン駆動設計に共感しつつ批判する、より

思うに、データモデリングの作業は検討者への負担が重いのだ。少数の検討者で深い考察を行う（そして正解はない）ものであるので、われわれは自然とデータモデリングを避けてしまっているのだろう。しかし本書で語られている通り、データモデリングはエンタープライズ向けの基幹システムという領域においては、避けて通れない核心であろう。忌避せず真正面から向き合うために、本書はヒントを与えてくれるような気がしている。

というわけで本書は読了。さて、次は何を読もうか……
いま気になっているのはこんな感じ。読む時間が足りねぇー

• 情報セキュリティの敗北史
• 組織を変える5つの対話 ―対話を通じてアジャイルな組織文化を創る
• ソフトウェアアーキテクチャメトリクス ―アーキテクチャ品質を改善する10のアドバイス　
• エレガントパズル　エンジニアのマネジメントという難問にあなたはどう立ち向かうのか（5/30発売なのでちょっと厳しいか）
• 鬼時短―電通で「残業６０％減、成果はアップ」を実現した８鉄則
• エンタープライズアーキテクチャのセオリー

「データモデリングでドメインを駆動する」を読む Part.1

読むのがホネな技術書やビジネス書を取り上げて2週間の読書期限を課して読んでアウトプットする仮想読書会「デッドライン読書会」の第65回。同僚と読書期限を約束することによって積読が確実に減るという仕組み。過去記事はこちら。

さて、今回は「データモデリングでドメインを駆動する──分散／疎結合な基幹系システムに向けて」である。今回は読書会メンバーで少しディスカッションをして選書。みんな、著者の杉本さんのシステム開発に関するXでのポストなどもよく見ていたので、読んでみようということになった。また目次を見る限りでは骨太のようなので、前後編に分けて読むことにしている。というわけでPart.1では 第1部と第2部を取り扱う。

データモデリングでドメインを駆動する──分散／疎結合な基幹系システムに向けて

「データモデリングでドメインを駆動する」とはどんな本か

さて、（まだ半分しか読んでいないけど）本書は概ねこのような本である

• 既存の基幹系システムを概観し、課題を指摘した上でよりよい基幹システム像を提言する（第1部）
• 基幹システム（SoR）を、活動のシステム（SoA）と経営管理のシステム（SoM）に大きく分離し、データアーキテクチャレベルで検討する（第2部）
• 横断的な関心事となりそうな重要要素について整理検討する（第3部）※まだ読んでない
• データモデリングの基礎を再考する（第4部）※まだ読んでない

類書だと次のようなものになるだろうか。

システム開発・刷新のための　データモデル大全

――システム構築の大前提―― ITアーキテクチャのセオリー

Web世代が知らないエンタープライズシステム設計

この3冊は既読であり、どれも非常に参考にしている。

エンタープライズアーキテクチャのセオリー

こちらの本は残念ながらまだ読めていない。読まねば……

エンタープライズシステム開発におけるビジネスアーキテクト／システムアーキテクト必携の書

（まだ半分しか読んでいないけど）本書はいわゆるエンタープライズシステム開発における、ビジネスアーキテクトとかシステムアーキテクトにとっては必読本の一つになるだろう。
システムアーキテクトには疑問点がつくかもしれないが、いわゆるIPAの情報処理技術者試験が定義する「システムアーキテクト」は、ほぼ上流工程人材なので間違いではないだろう。

情報システム戦略を具体化するための情報システムの構造の設計や、開発に必要となる要件の定義、システム方式の設計及び情報システムを開発する業務に従事し、次の役割を主導的に果たすとともに、下位者を指導する。

1. 情報システム戦略を具体化するために、全体最適の観点から、対象とする情報システムの構造を設計する。
2. 全体システム化計画及び個別システム化構想・計画を具体化するために、対象とする情報システムの開発に必要となる要件を分析、整理し、取りまとめる。
3. 対象とする情報システムの要件を実現し、情報セキュリティを確保できる、最適なシステム方式を設計する。
4. 要件及び設計されたシステム方式に基づいて、要求された品質及び情報セキュリティを確保できるソフトウェアの設計・開発、テスト、運用及び保守についての検討を行い、対象とする情報システムを開発する。
5. なお、ネットワーク、データベース、セキュリティなどの固有技術については、必要に応じて専門家の支援を受ける。
6. 対象とする情報システム及びその効果を評価する。

システムアーキテクト試験 | 試験情報 | IPA 独立行政法人 情報処理推進機構、業務と役割

（IPAのシステムアーキテクトが上流工程スキルを多くカバーしているのは意外と見落とされているポイントだと思う。上流工程力に課題感のあるエンジニアにはこの資格試験を割と積極的におすすめしている）

名前付けの素晴らしさ：SoAとSoM

本書で素晴らしいのはまず、企業の基幹システムつまりSoR（System of Record）を分解して、SoA（System of Activity）とSoM（System of Management）と名付けたことだと思う（SoAには別の意味がすでにあるけど）。おそらく類似のシステムアーキテクチャの整理は何度もされてきたはずだ。しかし名前がなければアーキテクチャの構造についての議論などはできない。基幹システムは対象業務や組織によって千差万別なのだからだ。そういう意味では本書、というかSoA/SoMの対置は流行ってほしい。

悩ましいのは移行の方法

おそらく未読の3章以降でも触れられていないようなのだけれども、悩ましいのは本書で論じられているアーキテクチャへの移行方法について触れられていないことだ。マイクロサービスアーキテクチャについては、ストラングラーパターンという移行方式についての議論がある。本書で論じられているSoA/SoMアーキテクチャへの移行については、このパターンに類似の方法を取ることになると思われるが、それでもかなり悩ましいだろう。しかし、基幹システムをビッグバンで再構築するのは現代ではかなり困難である。その点について、本書を起点にいろいろなところで議論が巻き起こったりすれば良いのではないだろうか。

あと2週間で残りを読んで、つづきの記事を執筆する予定である。さて後半にはどんなことが書いてあるのだろう

TryHackMe（無課金版）を始めた

数年前に情報処理安全確保支援士の資格を取得し、その後も資格維持のための研修は受講している。けれども、手を動かしていないのでセキュリティに関する知識向上に不足があるという感覚があった。そこで、実際に手を動かすべく、TryHackMe（以下THM）というサイバーセキュリティトレーニングサービスに触り始めた。なお現在触り始めて2週間ちょっと、タイトル通り無課金での利用である。

前提

記事を執筆している自分のセキュリティに関するスキルはこんなもの

• 情報処理安全確保支援士
  • 情報処理安全確保支援士の受験をした記録 2021 - 勘と経験と読経
• 以前にCTFを勉強していたことはある
  • 書籍「セキュリティコンテストチャレンジブック　CTFで学ぼう！情報を守るための戦い方」を読んで、オンラインの過去問題を解いたりしていた
• SOCで働いているわけではない

THMを始めたきっかけ

• 冒頭に書いた通り、セキュリティに関する学習不足感があった。とりあえず何か本を読もうと思って（オライリーのサブスクで）「ポートスキャナ自作ではじめるペネトレーションテスト ―Linux環境で学ぶ攻撃者の思考」を手に取ったところ、なにやら楽しそうだ。ただ書籍の内容を試せる環境が手元になかった

ポートスキャナ自作ではじめるペネトレーションテスト ―Linux環境で学ぶ攻撃者の思考

• そういえば、世の中には仮想やられ環境（学習目的で攻撃する環境）が利用できるサービスがあるという話を知り合いに聞いていたので調べてみたところ、以下の2つを認識した
  • TryHackMe | Cyber Security Training
  • Hack The Box: Hacking Training For The Best | Individuals & Companies
• ネットの評判を確認したところ、THMのほうがビギナー向けということ。また無料で1日1時間の仮想マシン（ブラウザ経由でアクセスできるKali）が利用できることがわかったので、まずはここから無課金で始めてみようと思った次第

とりあえずのTHMことはじめ

アカウント作成

• 特につっかかることもなく、アカウントを作成。最初のコースを選択するための質問がいくつか出され、適当に回答

Learning Path：SOC Level 1 への挑戦

• アカウント作成時の質疑応答から、「SOC Level 1」という学習コースがデフォルトでセットされたのでとりあえず開始
• 初心者向けなので、基本的には説明文を読み、設問に回答するというスタイルで進める
• 学習が進んでくると、実際に仮想マシンを立ち上げて、コマンドを入力して回答を得ないと答えが得られない問題も出てくる（こういうのがやりたかったのだ）
• とはいえ進めていくと「ここからはプレミアムプランになります」という表記でスキップせざるをえない教材（ルーム）も出てくる

実際に学習したコンテンツは以下の通り

• Cyber Defense Frameworks
  • Junior Security Analyst Intro
  • Pyramid Of Pain
  • Cyber Kill Chain
  • Unified Kill Chain
• Cyber Threat Intelligence
  • Intro to Cyber Threat Intel
  • Threat Intelligence Tools
• Network Security and Traffic Analysis
  • Traffic Analysis Essentials
  • Snort ★これはかなり楽しかった

いよいよ課金まったなしか、と思っていたのだが……

Learning Pathをやめて、公開されている無料教材リストを使う

調べていたら、無料の教材（ルーム）をまとめている記事を発見した。進めていたLerning Pathの続行はやめて、こちらのページに列挙されているものを（初心者向けはスキップして、Basic Roomsあたりから）やる方針に変更している。

• GitHub - rng70/TryHackMe-Roadmap: a list of 350+ Free TryHackMe rooms to start learning cybersecurity with THM
  • 一部リンクが切れていたり、現在は有料化してしまっているコンテンツはあるようだ

というわけで、上記ページを参考にしながら無料教材を毎日スキマ時間でこなしている。

課金すべきか

無課金版THMの制限のうち、気になるものは以下の2点だ。

• プレミアム教材にアクセスできない
• 仮想マシンの利用が1日に1時間のみ

前者は仕方がないとして、問題は後者の1時間縛りである。が、ものは考えようでもある

• 1時間という学習時間の縛りと考えて、メリハリのある学習を行える（タイマーのように使う）
• 1時間でクリアできない場合は、予習復習をして翌日に再チャレンジする

というわけで、当面無課金を継続予定だ。
THMで学習を進めて、Hack The Boxにチャレンジできるようになったら、HTB側を課金しようかな、と考えている。

ITエンジニア本大賞ノミネート本の「冒険の書」を読んだ

読むのがホネな技術書やビジネス書を取り上げて2週間の読書期限を課して読んでアウトプットする仮想読書会「デッドライン読書会」の第64回。同僚と読書期限を約束することによって積読が確実に減るという仕組み。過去記事はこちら。

さて、今回は「冒険の書 AI時代のアンラーニング」である。前回骨太の技術書を読んでいたので、ちょっと気分を変えてITエンジニア本大賞2024ノミネート作品からセレクションしてみました。

冒険の書 AI時代のアンラーニング

あとで調べたら、いろいろ話題になっている本だったようである。知りませんでした。すいません。

• ベストセラー孫泰蔵『冒険の書』 理解を深めるインタビュー・対談・書評 | 日経BOOKプラス

「冒険の書」全体の感想

不思議な本である。有名なシリアルアントレプレナーである著者の孫泰蔵氏が、主に「教育」に関する問いを古今東西の名著で解決するという筋書きなのだが、紹介のしかたが面白い。なんと、名著を読んでいるとその著者の世界に転生して対話ができてしまうという……

いつものデスクの横にあるソファに座って、さっそく「ホッブズ市民論」（1642）を開きました。その瞬間、ソファのまわりが白い光に包まれ、一瞬の閃光に目がくらんだ僕は、思わずうずくまってしまいました。湿った空気が肌に触れた気がして顔をあげると、僕はべンチに座っていました。目の前に広がるのは、古いヨ ー ロッパの朝の街並みのようです。どんよりとした空の下に古びた教会が見えます。隣では、僕より少し年上に見える男性がなにやら板の上に紙を置いて書き物をしていました。僕に気がついた彼は、薄茶色の目を細めてひとしきりこちらを見た後、再び視線を手元に落として書き物を続けながら言いました。「新しい冒険者よ！どうだね、イングランドの素晴らしい天気は？」
冒険の書 AI時代のアンラーニング　第1章 解き放とう、より

この会話している相手がトマス・ホッブズである。な、なんだってーっ！
とはいえ、この奇妙な仕掛けは実は巧妙で、結果として古今東西の教育に関連する書籍のエッセンスがわりとわかった気になるのである。

（そんなことは著作には書かれていないのだが）この本は孫泰蔵のプレイしたゲームの「セーブデータ」を追体験するような形になっていると感じた。RPGだとよく主要なエピソードのムービーは見直せるようになっているが、転生部分はそういうイメージである。もちろん同氏と同じようにたくさんの本を読んでいくほうが学びが深いと思うのだけれども、著者の旅路を覗き見することで、理解が深まるという趣向である。現在同氏は「VIVITA」というクリエイティブラーニングの活動も行っているようだが、そこに至る活動の記録のようなものと考えれば良いのだろうか。

そんな本書であるが、全世代に共通する「学ぶ」ということをテーマにしていて内容としても学びは大きい。わたしは子供の親として、また学習を続けるおとなとして非常に刺激になっている。

本書で気になったこと、考えたこと

「能力信仰」と、日本型「能力」のこと

本書の第3章から「能力信仰」に関する話が紹介される。

• 最初は統計的な研究で生み出された「能力」という概念が発展し、「能力を身につければ幸せになれる」という「能力信仰」が発展した
• 「能力信仰」から「能力によってその人間の地位が決まる」というメリトクラシーの考え方、自己責任論が生まれた
• メリトクラシーが人々を分断し不幸に追いやっている

これは知っているし、現代という時代を理解する非常に重要なキーワードだと考えているが、加えて日本型「能力」という考え方がある。これを混ぜない方が良いと思うのだ。
最近読んだ「ジョブ型雇用社会とは何か　正社員体制の矛盾と転機 (岩波新書)」ではこんなことが紹介されていた。

この「能力」評価の「能力」にかぎ括弧を付けているのは、日本における能力という言葉を外国にそのまま持っていくと全く意味が通じないからです。能力という言葉は、日本以外では、特定職務の顕在能力以外意味しません。具体的なある職務を遂行する能力のことを意味します。ところが、日本では、職務遂行能力という非常に紛らわしい、そのまま訳すと、あたかも特定のジョブを遂行する能力であるかのように見える言葉が、全くそういう意味ではなくて、潜在能力を意味する言葉になっています。それは仕方がありません。末端のヒラ社員まで評価する以上、潜在能力で評価するしかないのです。
ジョブ型雇用社会とは何か　正社員体制の矛盾と転機 (岩波新書)　第1章　ジョブ型とメンバーシップ型の基礎の基礎、より

仕事をしていると様々な場所で「能力評価」というモヤモヤすることばに頻繁に触れるようになる。なお同書ではここでいう「能力評価」は年功型賃金制度を言葉だけで言い換えたものであり、情意（雰囲気）で好き勝手に定義でき、時間の経過（年功）により向上したことにできる怪しげな概念というように紹介されている。

つまり（日本の）仕事で触れる「能力」という言葉は、いちだんと歪んだ概念なのである。それを理解した上でメリトクラシー論に触れたほうがより理解が深まるのではないかと思う。

ライフロング・キンダガーデン

本書の後半では著者の結論として「ライフロング・プレイグラウンド」という考え方が紹介される。ここで思い出したのは「ライフロング・キンダーガーテン　創造的思考力を育む４つの原則」だ。

ライフロング・キンダーガーテン　創造的思考力を育む４つの原則

こどもでも使えるプログラミング環境Scratchを生み出したMITの ミッチェル・レズニックという方の著書である。
序文が以下から読めるので興味があればどうぞ。

• はじめに：『ライフロング・キンダーガーテン 創造的思考力を育む4つの原則』 | 日経BOOKプラス

過去１世紀にわたって、農業、医学、および製造の分野は、新しい技術と科学的進歩により根本的に変化しました。教育はそうではありません。新しい技術が学校に入ったとしても、ほとんどの学校の中核的な規則とアプローチは変わらないままで、依然として工業社会のニーズとプロセスに沿った、組立ラインの考え方に固執しています。
ライフロング・キンダーガーテン　創造的思考力を育む４つの原則

と、本書とまったく同じ問題意識が書かれているのだ。本書を通読したのはだいぶ以前だが、生涯「幼稚園児のように」「こねくりまわす（ティンカリング）創造を」ということが書かれている同書は本書に通じるものがあると思う。

あそぶようにまなぶ

本書のとらえ方はいろいろあると思うけれども、自分にとっては「あそぶようにまなぶ」重要性を再確認した読書であった。現在の自分の「まなび」と「あそび」の境界はほとんどなくなっている。この考え方を自分だけではなく、他者に広げるにはどうしたらよいか。そんなことを考えるようになったのであった。

さて、つぎはどんな本であそぼうか。
最近気になっている本はこんな感じ

• 情報セキュリティの敗北史
• データモデリングでドメインを駆動する──分散／疎結合な基幹系システムに向けて
• 組織を変える5つの対話 ―対話を通じてアジャイルな組織文化を創る
• ソフトウェアアーキテクチャメトリクス ―アーキテクチャ品質を改善する10のアドバイス　（訳者の紹介が興味深い）

「ソフトウェアアーキテクチャの基礎」を読む Part.3（完結）

読むのがホネな技術書やビジネス書を取り上げて2週間の読書期限を課して読んでアウトプットする仮想読書会「デッドライン読書会」の第63回。同僚と読書期限を約束することによって積読が確実に減るという仕組み。過去記事はこちら。

さて、今回は「ソフトウェアアーキテクチャの基礎 ―エンジニアリングに基づく体系的アプローチ」の完結編（第3部）だ。けっこう分厚いので3回（×2週間）に分けて読んだ。今回は「第III部　テクニックとソフトスキル」を読んでいく。

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

過去2回の記事はこちら

• 「ソフトウェアアーキテクチャの基礎」を読む Part.1 - 勘と経験と読経
• 「ソフトウェアアーキテクチャの基礎」を読む Part.2 - 勘と経験と読経

「ソフトウェアアーキテクチャの基礎」全体の感想

今回で最後まで読めたので、本書全体の感想を先に述べておこう。

• 個人的には、アーキテクチャに関する鉄板本は「ソフトウェアシステムアーキテクチャ構築の原理 第2版」だったが、今後は本書をスタンダードにしたいと思う。アーキテクトを名乗るなら読んでおいてほしい本だ
  • もちろん構築の原理も良い本だ（特にビューポイント／観点集として）。しかし同書はどちらかというとアーキテクチャを静的なものとして扱っているきらいがある。現在のアーキテクチャの多くは動的なものだ
• レガシーなものからモダンなアーキテクチャまでの概論を包含しており、包括的で見通しが良い。ここから始めると良さそう（もちろん深掘りするためには別の検討は必要になる）
• 目指すべきアーキテクト像もモダンである。ファシリテーターであり、コラボレーターであり、プレゼンターであるというのは重要な指摘ポイントだと思った（この点は本記事の後半でも触れる）

第III部　テクニックとソフトスキル

今回読んだ第III部であるが、読む前には一抹の不安があった。なんというか、類書を沢山読んでいるので「また似たような話かー」となる懸念があったのだ。しかし、それは杞憂だった。

ひとことで言えば、アーキテクト像もちゃんとアップデートされている。全体の感想で書いた通りだが、ファシリテーターであり、コラボレーターであり、プレゼンターであることについて書かれているのが興味深い。

ファシリテーター

本書ではアーキテクチャそのものが動的なものであり、アーキテクトだけが構築していくわけではないというコンセプトに従っていると理解している。その上で、例えばアーキテクチャのリスクを分析する際には「リスクストーミング」という手法でメンバーと共にリスクを特定し改善する方法が示されている。

アーキテクトが単独でシステムの全体的なリスクを決定することはできない。一人ではリスク領域を見落とす可能性があるし、システムのすべての部分について完全な知識を持っているアーキテクトはほとんどいないからだ。そこで役に立つのが、リスクストーミングだ。
ソフトウェアアーキテクチャの基礎 ―エンジニアリングに基づく体系的アプローチ、20章　アーキテクチャ上のリスクを分析する より

コラボレーター

同様に、チームでのコラボレーションに関するテクニックについてもいくつかの章が割かれている。「22章 効果的なチームにする」では、アンチパターンとしてのアーキテクトタイプとして「コントロールフリーク（すべての決定をアーキテクトが行う）」「アームチェアアーキテクト（コーディングをせず抽象的な決定ばかりする）」を示したうえで、チームに適切な制約と境界をつくり出してコラボレーションすることの重要性が語られていて興味深かった。

またチームとの境界を定めるためには、トレードオフスライダーに似た「コントロール量の尺度（メーター）」を用いて、どこまでコントロールするのかを調整するという話はかなり面白い。

プレゼンター

著者はアーキテクトに政治的な状況への対応力が必要であると述べる。

本書の冒頭で、アーキテクトに期待されることを挙げたが、その最後に、ソフトウェアアーキテクトは企業の政治的な状況を理解し、その政治的な状況を切り抜けられなければならないという期待を挙げた。このような期待が挙げられる理由は、ソフトウェアアーキテクトが下すほぼすべての決定には異議が唱えられるからだ。
ソフトウェアアーキテクチャの基礎 ―エンジニアリングに基づく体系的アプローチ、23章　交渉とリーダーシップのスキル より（下線は本記事の筆者）

下線の箇所は、なるほどと膝を打ったところである。

その上で、利害関係者との調整のために

現代のアーキテクトに求められるもう1つのソフトスキルは、PowerPointやKeynoteのようなツールを使って効果的なプレゼンテーションを行う能力だ
ソフトウェアアーキテクチャの基礎 ―エンジニアリングに基づく体系的アプローチ、21章　アーキテクチャの図解やプレゼンテーション より

という主張があるのも納得である。

なお著者の一人であるNeal Fordさんは「Presentation Patterns: Techniques for Crafting Better Presentations (English Edition)」という本も執筆しているからか、プレゼンテーションの方法については楽しいアンチパターンがいくつも紹介されていて興味深かった。いつかこの本も読んでみたい。

というわけで、読みたかった本書をやっと読み終えて感慨深い。折を見て読み返すことになりそうな良い本であった。
関連書籍として以下がすでに翻訳されている。これもいつか読みたいな。

ソフトウェアアーキテクチャ・ハードパーツ ―分散アーキテクチャのためのトレードオフ分析

ソフトウェアアーキテクチャメトリクス ―アーキテクチャ品質を改善する10のアドバイス

さて、次は何を読もうか……

「ソフトウェアアーキテクチャの基礎」を読む Part.2

読むのがホネな技術書やビジネス書を取り上げて2週間の読書期限を課して読んでアウトプットする仮想読書会「デッドライン読書会」の第62回。同僚と読書期限を約束することによって積読が確実に減るという仕組み。過去記事はこちら。

さて、今回は前回につづき「ソフトウェアアーキテクチャの基礎 ―エンジニアリングに基づく体系的アプローチ」である。けっこう分厚いので3回（×2週間）に分けて読んでいる。今回は「第II部　アーキテクチャスタイル」を読んでいく。

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

アーキテクチャスタイル

本書における「アーキテクチャスタイル」の定義は以下のようだ。

• アーキテクチャスタイル：機能の編成、配置、データベースとの相互作用などに関する包括的な構造
• アーキテクチャパターン：アーキテクチャスタイルの中で利用する低レベルの設計構造

これは一般的な定義と同一のよう。

• アーキテクチャスタイルとパターンについて見てみる

ただ、パタンランゲージの話と（自分は）混同しがち。気をつけよう。

ほとんどのアーキテクチャスタイルは、繰り返し現れる特定のパターンに気がついたアーキテクトたちによって、後から命名される。次に来る大きなムーブメントを決めるような、秘密のアーキテクトグループが存在しているわけではない。むしろ、アーキテクチャスタイルの流行は、ソフトウェア開発のエコシステムが変化していく中で、多くのアーキテクトが共通の意思決定をしていることを表している。人々に模倣されるようなアーキテクチャスタイルは、ソフトウェア開発のエコシステムの変化に対処し、そこから利益を得るための共通で最善の方法から生まれてくるのだ。

• ソフトウェアアーキテクチャの基礎 ―エンジニアリングに基づく体系的アプローチ 17章 マイクロサービスアーキテクチャ、より

本書で紹介されるアーキテクチャスタイル

「第II部　アーキテクチャスタイル」では以下のようなアーキテクチャスタイルが紹介される。巨大な泥団子から話が始まるのがすき。

• 基礎的なパターン
  • 巨大な泥団子：伝説のアンチパターン
  • ユニタリーアーキテクチャ：メインフレームのような一元的（ユニタリー）なアーキテクチャ
  • クライアント／サーバー：懐かしの二層アーキテクチャ
• モノリシック
  • レイヤードアーキテクチャ：N層アーキテクチャ
  • パイプラインアーキテクチャ：パイプとフィルターアーキテクチャ、UNIX哲学的な
  • マイクロカーネルアーキテクチャ：プラグインアーキテクチャ
• 分散
  • サービスベースアーキテクチャ：マイクロサービスアーキテクチャのハイブリッド（DBがモノシリック）
  • イベント駆動アーキテクチャ：分散非同期型
  • スペースベースアーキテクチャ：スパイキーな負荷に対応する
  • オーケストレーション駆動サービス指向アーキテクチャ：SOA。現代ではアンチパターンであると紹介されている
  • マイクロサービスアーキテクチャ：説明省略

「スペースベースアーキテクチャ」はほとんど遭遇したことのないやつ。あと「サービスベースアーキテクチャ」はこういった名前付けを知らなかった。
それぞれのスタイルに対しての評価が付されているのは興味深い。

第II部で興味深かった記述

9章 基礎

• 「分散コンピューティングの誤信」。知ってたけど、何の本で読んだのかは忘れてしまった。

10章 レイヤードアーキテクチャ

• 「レイヤードアーキテクチャは、暗黙のアーキテクチャアンチパターンや偶発的アーキテクチャアンチパターンといったアンチパターンにも該当する」何にも考えずにってやつですね。

16章 オーケストレーション駆動サービス指向アーキテクチャ

• いわゆるSOAのことだが、メタクソにいわれていておもしろい

もしかすると、このアプローチが魅力的なものに聞こえたかもしれない。しかし、実際には、こうしたアプローチのほとんどが失敗に終わった。トランザクションの動作をオーケストレーションツールにオフロードすることは良いことのように聞こえるが、トランザクションの粒度を適切なレベルで見つけ出すのは、ずっと難しいものだった

このアーキテクチャで最も致命的だったのは、技術による分割を重視したアーキテクチャ構築が非現実的であると実感したことだった。

• まあ、言いたいことはわかる。実際に難しかった。

次回は「第III部 テクニックとソフトスキル」である。アーキテクチャではなく、アーキテクトという職業について語られていると思われるので楽しみだ。