勘と経験と読経

略すとKKD。ソフトウェア開発やITプロジェクトマネジメントに関するあれこれ。

TryHackMe(無課金版)を始めた

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

前提

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

THMを始めたきっかけ

  • そういえば、世の中には仮想やられ環境(学習目的で攻撃する環境)が利用できるサービスがあるという話を知り合いに聞いていたので調べてみたところ、以下の2つを認識した
  • ネットの評判を確認したところ、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あたりから)やる方針に変更している。

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

課金すべきか

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

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

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

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

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

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

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

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

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

冒険の書」全体の感想

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

あそぶようにまなぶ

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

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

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

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

過去2回の記事はこちら

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

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

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

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

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

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

ファシリテーター

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

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

コラボレーター

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

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

プレゼンター

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

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

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

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

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

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

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

エンジニアリングモデルとコントラクタモデルと納期のはなし

牛尾さんの「納期がなぜ生産性をぶち壊しにしているのか?」という記事を読んで考えたこと。あるいはインターネットが屑情報ばかりになってしまう現象への個人的な抵抗。

牛尾さんの記事では、特に日本では重視されがちのようにみえる「納期」というものがソフトウェアエンジニアの生産性に悪影響を与えるということ、現所属および周囲の北米企業では「納期」の少ない良い環境であることを示している。その論には強い異論はないのだけれども、「納期」というキャッチーな(?)用語を使ってしまっているので、論点の見通しが少し悪いようだ。

そこで、いろいろな見方があると思うが「文化」の話と「現場」の話に分けて、関連書籍などを紹介しながら論じてみたい。

エンジニアリングモデルとコントラクタモデル(文化の話)

納期という単語に反応すると「それは契約の話なのでは」となってしまいがちだが、もう少し抽象度を上げると企業文化の話になるだろう。というわけで「要件最適アーキテクチャ戦略」で紹介されているエンジニアリングモデルとコントラクタモデルについて紹介したい(なおこの本自体は正しくモノリスを作るDDDの本である。詳しくは以下の過去記事を参照)。

ちょっと長いが引用してしまおう。ちなみに引用部分を書いたのはリーン開発本で有名なMary Poppendieckさん。

 この機会に、コントラクタモデルの対極にあるエンジニアリングモデル手法をソフトウェア開発に取り入れるという考えを紹介したい。まず、典型的なコントラクタモデルについて考えてみよう。このモデルでは、従業員と実際の請負業者のどちらで使われるとしても、開発者には担当する作業が正確に指示され、少しの失敗も許されない。エンジニアリングモデルでは、仮説に基づく実験を使って、学習と改善を行いながら複数の選択肢を検討する。
 SpaceX とTesla はエンジニアリングモデルを採用している。対照的に、ほとんどのソフトウェアプロジェクトはコントラクタモデルを採用している。この対立する2 つのアプローチを並べてみた場合、ソフトウェア業界全体での1 人あたりのイノベーションを最大化するのがどちらであるかは明らかである。
 SpaceXペイロードを宇宙に打ち上げるコストを劇的に削減し、ブースターロケットを回収して再利用するという主要目標を――― 予定を大幅に短縮した上で達成した。どうやってなし遂げたかというと、SpaceX は近年まで宇宙探査の唯一の資金調達法とされていた政府との請負契約を結ばなかった。(中略)というのも、あらゆることについて耐えがたいほど詳細な検討を重ねるのではなく、とにかくいろいろなことを試して未知の未知を発見しようとしたからである。エンジニアリングのアプローチとしてはかなり典型的なものだが、コントラクタモデルでは決して許されないものだ。SpaceX チームによれば、墜落させて問題を見つけ出すほうが、リスクがなくなるまで待っているよりもずっと安上がりだったそうだ。
要件最適アーキテクチャ戦略(P.43)

私の理解する限りにおいては

  • エンジニアリングモデル:仮説に基づく実験を使って、学習と改善を行いながら推進する。アジャイル的なアプローチ(納期はない)
  • コンストラクタモデル:請負契約に基づき、計画駆動で推進する(納期はある)

ということだろうと思う。「要件最適アーキテクチャ戦略」ではもちろん目指すべき形はエンジニアリングモデルとされている。一方でエンジニアリングモデルを選択するということは企業の戦略であり、文化の変革の話であり、リスクを取る選択をすることになるだろう。このリスクが取れるのであれば「納期のないエンジニアリング」は実現できるのだ。

逆に言えば、リスクを取らずにコンストラクタモデルの文化を続ける会社で「納期のないエンジニアリング」を実現するのは(不可能ではないだろうか)難しい。
(ちなみに、Space Xがめちゃくちゃリスクを取っている話は自伝「イーロン・マスク」に描かれている。波乱万丈すぎて面白い本だった)

納期と期日と目標(現場の話)

牛尾さんの記事で気になったのは、以下の箇所である。

日本にいた時には何でも納期が付いて回ってた気がする。凄ーくちいさな仕事を頼まれても「〇〇日までにお願いします」と納期が付いてくる。今からするとなんにでも納期が付いて回る感覚だ。
納期がなぜ生産性をぶち壊しにしているのか?|牛尾 剛

「〇〇日までにお願いします」は、わたしの感覚で解釈すると期日か、単なる要望である。これを納期と捉える感覚には違和感がある。
ただ、実際には特に日本の現場ではこういった言葉の誤用・乱用が多いのも事実だ。例えば納品物と成果物、善管注意義務プロマネ義務、プロトタイプとMVPなどなど。ソフトウェアエンジニア的には様々な用語の定義に敏感であってほしいものだが、仕様と技術用語以外はルーズになってしまうのは割と不思議である。

実際のところ、納期(または納品日)は契約で定めるものであり、守らなければならないコミットメントである(これを守らなければ債務不履行になる)。逆に言えば納期だけは特別な約束であり、それ以外の日付はそこまで厳格なものではないし、調整余地も多いはずである(もちろん納期だって適切な手続きを取れば変更できる)。納期(コミットメント)を達成するためには様々なタスクに分解しマネジメントする必要があるが、分解したタスクの終了予定日は納期ではない。遅れたら他で取り返せば良いし、そういったリスクも含めて管理する方法はいろいろあるだろう(個人的にはTOC理論が好き)。

ちなみに現在も有用な古典的名著である「ソフトウェア見積り 人月の暗黙知を解き明かす」では第1章で「見積り、ターゲット、コメント」は異なるものだと言っていた。同じ話だ。

 辞書にある「見積り」の定義は、厳密な意味では正しい。見積りとは、プロジェクトにかかる期間やコストを予測することだと言ってよい。だが、ソフトウェアプロジェクトの見積りとは、ビジネスのターゲットと、コミットメントと、コントロールとの間の相互作用である。(中略)
 ターゲットが実現したいビジネス目標の記述であるのに対して、コミットメントとは、定義された機能を、特定の品質レベルを確保しながら期日までに納品するという約束を意味する。コミットメントと見積りが、同一のものを指すこともあるが、コミットメントが見積りより挑戦的だったり保守的だったりすることもある。言い方を変えると、コミットメントと見積りが同一でなければならないと考えてはいけない。そもそも同じものではないのだ。
ソフトウェア見積り 人月の暗黙知を解き明かす (P.4)

雑なまとめ

というわけで

  • 所属する企業の文化を確認しよう。コントラクタモデルな文化の企業やプロジェクトで納期不要論を主張しても仕方がない。転職しよう
  • 日付の話が出たらそれは「納期」なのか「期日」なのか「目標」なのかをちゃんと確認しよう。勝手に目標を納期と誤解してあたふたするな(相談すればなんとかなることもあるよ)

そんじゃーまた

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

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

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

アーキテクチャスタイル

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

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

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

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

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

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

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

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

9章 基礎

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

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

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

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

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

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

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

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

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

さて、今回から取り扱うのは「ソフトウェアアーキテクチャの基礎 ―エンジニアリングに基づく体系的アプローチ」である。読もう読もうと思っている間に2年経ってしまった(発売は2022年03月)。けっこう分厚いので3回(×2週間)に分けて読んでいく。

なぜいま「ソフトウェアアーキテクチャの基礎」なのか

ソフトウェアアーキテクチャに関する様々な事項が「変化」したからである。第1章ではこう書かれている。

なぜ今、ソフトウェアアーキテクチャの基礎を扱う書籍なのか。ソフトウェアアーキテクチャの範囲は、刻々と変化するソフトウェア開発エコシステムの一部だけに留まらない。新しい技術や手法、能力……実際のところ、この10年で、こうしたすべてのものは変化していっている。ソフトウェアアーキテクトは、そうした刻々と変化するエコシステムの中で意思決定をしなければならない。意思決定の判断基準を含めて、すべての物事が変化していっているのなら、アーキテクトである私たちは、以前にソフトウェアアーキテクチャについて書かれた記述が前提としていた中核的な公理さえも見直さなくてはならない。

本書以前のソフトウェアアーキテクチャの教科書と言えば、「ソフトウェアシステムアーキテクチャ構築の原理 第2版」がある(原著:2012年 訳書:2014年)。良い本である。しかし……

本書の冒頭でも同じようなことが端的に触れられている。

長年にわたり、ソフトウェアアーキテクチャの定義は「後から変更するのが難しいもの」という皮肉なものだった。しかし、マイクロサービスアーキテクチャの登場によって、現在は変化こそが第一級の設計上の考慮事項となった。

今回読んだ範囲(1章 イントロダクション+第I部 基礎)の感想

今回は3回に分けて読んでいく。第1回の範囲は「第I部 基礎」の終わりまで。次回は第Ⅱ部、そして最終回は第Ⅲ部の予定である。
第I部までは、アーキテクトの役割、考えるべきことについての説明が行われている。図も多くわかりやすい本という印象である。現代のソフトウェアアーキテクチャに関係する人は読むべき内容だし、知識のアップデートが必要な人にも役立つ内容となっているのではないか。

  • 1章 イントロダクション:とても良い。ソフトウェアアーキテクチャとは何かと、アーキテクトの期待役割が説明される
    • とくにアーキテクトの期待役割に「アーキテクチャを継続的に分析する」と「最新のトレンドを把握し続ける」「さまざまなものに触れ、経験している」が含まれているのが良い。
  • 第I部 基礎

第Ⅱ部からは代表的なアーキテクチャパターンが語られるようだ(まだ読んでいない)。第I部で紹介された考え方を用いて展開されると期待しているので楽しみである。

名言、金言について

本書で面白いと思ったのは、著者たち自身、もしくは著者が見聞きした達人の名言や金言がいろいろな場所で紹介されていることだ。今回読んだ範囲で面白いとおもったものを記録しておく。

  • 「未知の未知があるため、すべてのアーキテクチャはイテレーティブにならざるを得ない。アジャイルはそのことを理解して、より早く未知の未知に対処するようになっている」Mark Richards(著者)
  • アーキテクチャとは、Googleで答えを見つけられないものだ」Mark Richards(著者)
  • アーキテクチャには正解も不正解もない。あるのはトレードオフだけだ」Neal Ford(著者)
  • プログラマーは利点はわかっているが、トレードオフはわかっていない。アーキテクトはその両方を理解する必要がある」Rich Hickey(プログラミング言語Clojureの生みの親)
  • アーキテクチャに間違った答えはない。高くつくものがあるだけだ」Mark Richards(著者)

さて、それでは次は、第Ⅱ部 アーキテクチャスタイル にとりかかろう。つづく

2023年に行った美術館・博物館展示のまとめとふりかえり

2023年に行った美術館・博物館展示をまとめてみる記事。instagramライフログ的な記録はつけているのだけれども検索しにくいのでまとめてみたのと、ふりかえりをしようと思ったのだった。美術館や博物館に行くのは半分趣味だけど、年をとっても感性と知的好奇心が死なないように自分にとって理解困難なものに触れる機会を大切にしている。脳の筋トレ。

昨年の振返りはこちら

ふりかえり

2023年に行った美術館・博物館展示のまとめ

2023年4月

来年もいろいろ行きたい。