勘と経験と読経

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

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

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

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

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

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

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

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

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

おっさんエンジニアの放送大学教養学部に入学記録8(4年目後期終了)

2020年4月から放送大学教養学部「人間と文化コース」に入学して、これまで勉強してこなかった人文系の勉強を始めている。4年目後期が終わったので感想をまとめておく。

目次

もうすぐ50のオッサンが放送大学の全科履修生として気ままに授業を取っている。理系の大卒資格は取っているので卒業をゴールにはしていない。学割の利用や大学図書館サービスなども活用できるので、割とお得な趣味である。授業はすべて(受講していないものも含めて)ネット配信されているので好きなペースで進めることができる。

4年目後期に受講した科目

この半年で受講した科目はこちら

社会と産業の倫理(’21)

社会と産業をめぐる諸科学において、倫理の問題がどのように取り上げられているかを検討する。「いかに生きるべきか」「善く生きるとは何か」といった問いをめぐるものである倫理は、あらゆる人間活動において、極めて重要な要素である。しかしながら、科学的方法にとって、倫理の問題の扱いは、けっして容易なものではない。本講義では、倫理の問題がなぜ重要なのか、それを学問的に扱うにはどうしたよいのか、そして、学問的な営みそのものにとって、どのような倫理的検討が必要なのか、といった問いを、さまざまな領域の専門家が検討するさまを紹介する。

  • (本来は哲学とか美術を学びたかったはずなのに)突然どうした?という感じであるが、少し倫理学について深めたくなって選択した科目である。
    • 某勉強会で、大学の倫理学講義に関する動画を同時視聴したり、倫理学関連の本を読んできた影響でもある。
  • 倫理学という分野の概観に始まり、企業倫理と内部統制までをカバーしていて、教養の枠を超えて仕事にも役立つ良い科目だった。
  • 一応、技術士であったりセキスペの資格を持っているという点でも倫理については敏感なつもりだったが、授業として聞くのは意味深い。社会人にはおススメ

考古学(’18)

モノである考古資料は、そのままでは何も語ってくれない。考古学は、モノからさまざまな方法で情報を読み取り、過去の社会や文化を復元し歴史を構築していく学問である。そこで、発掘調査や型式学・年代論・機能論・分布論などの方法論、隣接科学の考古学への応用、それをもとにした具体的な歴史の復元など、考古学の基礎を体系的に講義する。初めて学ぶ者から専門的な学習を目指す者まで幅広い学生を対象としている。

  • 以前からちょっと気になっていた科目。ソフトウェア開発者として要求や仕様策定の方法として「考古学的アプローチ」なるものが考えられないのか……などと妄想していたこともあって受けてみたかったのだ。
  • 考古学という学問や方法論に関する講義はかなり興味深い一方で、考古学を通じた人類史に関する講義は少し苦手なので大変だった。試験も難しく感じた。

初歩からの数学(’18)

これから大学で数学の勉強をするにあたって必要な事柄を解説する。講義の内容は、高等学校までに学ぶ数学であるが、それをできるだけ体系立てて解説していく。数学の各分野におけるさまざまな基本概念を理解することに重点をおき、数学的な見方、考え方、そして正確な議論の進め方を学ぶ科目として講義する。特に初学者にとって分かりづらいとされる分野を丁寧に解説したい。

  • この科目は聴講のみ(テキストを購入して授業は視聴するが、単位は認定されない)
  • 一応、理学部を卒業しているので一通りの数学は出来たはずなのだが、だいぶ忘却してしまった。というわけで数学の学び直しをしたいという気持ちがあったのだ
  • この科目は様々な教養書でよくおススメされていたので手を出してみたもの
  • さすがに前半は簡単すぎるので聞き流し。後半からはだいぶ興味深かった。また講義よりもテキストが素晴らしく、興味深い証明などについては実際に手を動かしながら学び直すのが良かった

www.youtube.com

来期(5年目前期)の予定

以下を受講予定。

ちょっとソフトウェア工学とかも気になり始めているのだけれども、欲張りすぎると破綻するのでマイペースで継続したい

これまでの記録

これまで受講した科目

  1. 哲学・思想を今考える(’18):1年目前期
  2. 西洋芸術の歴史と理論(’16):1年目前期
  3. 総合人類学としてのヒト学(’18):1年目前期
  4. 博物館概論(’19):1年目後期
  5. 文学・芸術・武道にみる日本文化(’19):1年目後期
  6. 西洋哲学の起源(’16):1年目後期
  7. 教育心理学特論(’18):1年目後期 ※大学院科目の聴講
  8. 「人新世」時代の文化人類学(’20):2年目前期
  9. 日本美術史の近代とその外部(’18):2年目前期
  10. 現代フランス哲学に学ぶ(’17):2年目前期
  11. 記号論理学('14):2年目後期
  12. 舞台芸術の魅力('17):2年目後期
  13. 西洋音楽史(’21):3年目前期
  14. レジリエンスの諸相(’18):3年目前期
  15. 心理学概論(’18):3年目前期
  16. 現代の危機と哲学(’18):4年目前期
  17. アメリカの芸術と文化(’19):4年目前期
  18. 中高年の心理臨床(’20):4年目前期
  19. 社会と産業の倫理(’21):4年目後期(本記事)
  20. 考古学(’18):4年目後期(本記事)
  21. 初歩からの数学(’18) :4年目後期(本記事)

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部 テクニックとソフトスキル」である。アーキテクチャではなく、アーキテクトという職業について語られていると思われるので楽しみだ。