勘と経験と読経

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

2023年上半期に読んだ本まとめ

book

2023年1月～6月に読んだ本のまとめ。カウント対象は期間中に読み終わったものに限り、読みかけの本は対象外としている。あとコミック、漫画雑誌類もけっこう読んでいるのだけれども、これは除外。
この6カ月では62冊の本を読んだらしい。わりと平常運転すこし多めという感じだが、あらためてふりかえってみると大著や以前から読みたかった本が読めており、自己満足感高め。

いつもどおり半期で読んだ本の中で良かったものをピックアップしてみる。

文芸書のおすすめ（一般編）

「クララとお日さま」と「プロトコル・オブ・ヒューマニティ」はちょっとSF小説とも言えるのだけれども、あえて一般文芸書として紹介したい。SF小説に不慣れな人にもおすすめだ。
クララとお日さま
カズオ・イシグロの最新作、といっても2021年発表作である。AIロボットと少女の物語なのだけれども、SF小説というよりは文学作品。
ちなみに映画館ではじめて「M3GAN／ミーガン」の予告編を見た時、最初は本作が映画化されたのかと思った（違う。こちらはホラー映画）。
プロトコル・オブ・ヒューマニティ
「SFが読みたい！」2022年国内編の第2位であり、著者は有名なSF小説家なのだけれども……本作もSF小説というより文学作品である。もともと自分がコンテンポラリーダンスに親しんでいたという背景もあるのだけれども（主人公はコンテンポラリーダンサー）、面白くまた未来について考えさせられる良作。

文芸書のおすすめ（趣味のSF編）

「三体０【ゼロ】　球状閃電」はもちろん最高だったのだけれども、あえて「異常【アノマリー】」を推したい。
異常【アノマリー】
何を書いてもネタバレになりそうなのだが、驚きが止まらない。読み終わった後、表紙を見つめてしまう。「SFが読みたい！」2022年海外編の第4位

教養書のおすすめ

最近、未来について考える本をよく読んでいる気がする。というわけで「次なる１００年―歴史の危機から学ぶこと」「システム・エラー社会　「最適化」至上主義の罠」「監視資本主義―人類の未来を賭けた闘い」を推す。

次なる１００年―歴史の危機から学ぶこと
どうして本書を手に取ったのかは覚えていないのだが、凄い本である。内容の説明はAmazonの紹介ページが最も詳しい。

和書であるが、ユヴァル・ノア・ハラリの「サピエンス全史」や「ホモ・デウス」に勝るとも劣らない勢いで現代を論じており強い刺激を受けた。ただし超長い。

システム・エラー社会　「最適化」至上主義の罠
こちらの紹介記事を見て手に取ったもの。

テクノロジストの特性（技術の賞賛、最適化重視）が現代の様々な歪みを引き起こしていると論じる本書にはうなずける点も多く、読むなら今だろう、という素晴らしい現代論。スタンフォードで行われているCSと社会科学と倫理学を統合した講義がベースとなっているそうだ。

監視資本主義―人類の未来を賭けた闘い
数年前の世界的ベストセラーということでやっと手に取ったもの。読めば世界観が変わるくらいのインパクトはある。こちらも読むなら今だろう。ただしかし、分厚いだけでなく値段も高価である。とりあえずは書店かKindleのサンプル書籍でよく確認してから読み始めよう。

ビジネス書のおすすめ

人の採用や評価に関わっている人には「経営×人材の超プロが教える人を選ぶ技術」と「みんなのフィードバック大全」がお勧めだが、汎用性で言えば最近読み終わった「「対話と決断」で成果を生む 話し合いの作法 (PHPビジネス新書)」が一番だった。
「対話と決断」で成果を生む 話し合いの作法 (PHPビジネス新書)
対話／ダイアローグは、1on1とあわせてビジネス界では大ブームである。しかし我々は「対話」についてどれくらい真剣に考え、実行しているだろうか。本書を読むとぜんぜん出来ていない事がわかり、どうすればいいかがわかる。新書サイズであっという間に読めるのがいい。

技術書のおすすめ

（別に否定するつもりはないのだが）世間では「アジャイル」「DX」的な本が溢れている中で、一番骨太だと思ったのは「継続的デリバリーのソフトウェア工学　もっと早く、もっと良いソフトウェアを作るための秘訣」だ。
継続的デリバリーのソフトウェア工学　もっと早く、もっと良いソフトウェアを作るための秘訣
詳しい感想は別の記事に書いているが、現代の主流なソフトウェア開発の問題を正面から論じ、改善しようとしている。ベースは（私の理解だと）XPである。

この本が特に良いと思うのは「クラフトマンシップ」を否定している点である。詳しくは上記リンク先をご参照いただきたい。

この半期の振り返り

この6カ月は以前から読みたい本をしっかり読めたという印象。パンデミックもほぼ収束し、在宅勤務ではなくオフィスに出社する頻度も増えてきているので通勤時間という読書時間が確保できているからかもしれない。ただ、文芸書はSF小説ばかり読んでいるのが課題。もうちょっと普通の小説も読むべきだろう。バランスが悪い。村上春樹さんの新刊をまずは読もう。しかしちょうどタイミング悪くハヤカワ書店のKindleセールなどが始まっているので、やはりSF小説の積みが深い。

とりあえず今年後半に絶対読み終えたい本はこんな感じ。

2023年上半期に読んだ本

  1. WIRED（ワイアード）VOL.47
  2. 哲学の先生と人生の話をしよう
  3. 九段下駅　或いはナインス・ステップ・ステーション (竹書房文庫)
  4. 人と組織の行動科学
  5. 法治の獣 (ハヤカワ文庫JA)
  6. Au オードリー・タン　天才IT相7つの顔 (文春文庫)
  7. 美術展ぴあ2023
  8. デジタルトランスフォーメーション・ジャーニー 組織のデジタル化から、分断を乗り越えて組織変革にたどりつくまで⇒（★書評）
  9. 事業をエンジニアリングする技術者たち ― フルサイクル開発者がつくるCARTAの現場
  10. 異常論文 (ハヤカワ文庫JA)
  11. 三体０【ゼロ】　球状閃電
  12. なめらかな社会とその敵　──PICSY・分人民主主義・構成的社会契約論 (ちくま学芸文庫)
  13. ゴジラ S.P＜シンギュラポイント＞ (ジャンプジェイブックスDIGITAL)
  14. マルドゥック・スクランブル　The 1st Compression─圧縮　〔完全版〕 (ハヤカワ文庫JA)
  15. マルドゥック・スクランブル　The 2nd Combustion─燃焼　〔完全版〕 (ハヤカワ文庫JA)
  16. マルドゥック・スクランブル　The 3rd Exhaust─排気　〔完全版〕 (ハヤカワ文庫JA)
  17. カムパネルラ (創元ＳＦ文庫)
  18. 単体テストの考え方/使い方⇒（★書評1、★書評2）
  19. 葉桜の季節に君を想うということ (文春文庫)
  20. 実力も運のうち　能力主義は正義か？
  21. Winny　天才プログラマー金子勇との7年半 (NextPublishing)
  22. 第二開国 (角川書店単行本)
  23. 異常【アノマリー】
  24. そのうちプラン
  25. 見抜く力――びびらない、騙されない。
  26. アマゾンの最強の働き方――Working Backwards
  27. 密室黄金時代の殺人 雪の館と六つのトリック (宝島社文庫)
  28. ＷＯＲＫＳＩＧＨＴ［ワークサイト］１８号　われらゾンビ　We Zombies ＷＯＲＫＳＩＧＨＴ［ワークサイト］１８号 われらゾンビ　We Zombies
  29. タテ社会の人間関係　単一社会の理論 (講談社現代新書)
  30. はじめての短歌 (河出文庫)
  31. SREエンタープライズロードマップ
  32. クララとお日さま
  33. かがみの孤城
  34. 現代思想入門 (講談社現代新書)
  35. プロトコル・オブ・ヒューマニティ
  36. あの人と短歌
  37. 継続的デリバリーのソフトウェア工学　もっと早く、もっと良いソフトウェアを作るための秘訣⇒（★書評）
  38. 僕たちはどう生きるか　言葉と思考のエコロジカルな転回 (集英社文芸単行本)
  39. AI 2041　人工知能が変える20年後の未来 (文春e-book)
  40. 料理と利他
  41. 次なる１００年―歴史の危機から学ぶこと
  42. マルドゥック・ヴェロシティ１　新装版
  43. マルドゥック・ヴェロシティ２　新装版
  44. 私たちはどう学んでいるのか　――創発から見る認知の変化 (ちくまプリマー新書)
  45. 経営×人材の超プロが教える人を選ぶ技術
  46. From Tokyo わたしの#stayhome日記2022-2023
  47. はじめてのスピノザ　自由へのエチカ (講談社現代新書)
  48. マルドゥック・ヴェロシティ３　新装版
  49. 掃除機探偵の推理と冒険 (ハヤカワ文庫JA)
  50. プロジェクトのトラブル解決大全　小さな問題から大炎上まで使える「プロの火消し術86」
  51. 流浪地球 (角川書店単行本)
  52. 一人称単数 (文春文庫)
  53. システム・エラー社会　「最適化」至上主義の罠
  54. 硝子の塔の殺人
  55. みんなのフィードバック大全⇒（★紹介）
  56. アナベル・アノマリー (徳間文庫)
  57. ロジカル・シンキング練習帳―論理的な考え方と書き方の基本を学ぶ５１問
  58. 要件最適アーキテクチャ戦略⇒（★書評1、★書評2）
  59. 料理の四面体 (中公文庫)
  60. 監視資本主義―人類の未来を賭けた闘い
  61. 「対話と決断」で成果を生む 話し合いの作法 (PHPビジネス新書)
  62. WIRED（ワイアード）VOL.48

過去の読書ふりかえり記事

あと過去にこんなのも書きました

「要件最適アーキテクチャ戦略」の後半も読んだ。まずは正しくモノリスを作るDDDの本だ

book Professional Engineer

読むのがホネな（積みがちな）技術書やビジネス書を取り上げて２週間の読書期限を課して読んでアウトプットする仮想読書会「デッドライン読書会」の第54回。常時、けっこうな量の積読があるのだけれども、知り合いと読書期日を約束することによって消化が捗るという仕組み。過去5回分のログはこんな感じ。

さて、今回取り上げるのは前回に引続き「要件最適アーキテクチャ戦略」だ。ちょっと長いので前半と後半に分けて読んでいる。今回は後半の「Part3 イベントファーストアーキテクチャ」「Part4 目的を持ったアーキテクチャの2つの道」を取り扱う。

要件最適アーキテクチャ戦略

要件最適アーキテクチャ戦略

Amazon
日本語タイトルは若干わかりにくい気がする。原題は「Strategic Monoliths And Microservices: Driving Innovation Using Purposeful Architecture」、ストレートに直訳すると「戦略的なモノリスとマイクロサービス： 目的別アーキテクチャによるイノベーションの推進」というタイトルの本となる。

まずは目的を持ったモノリスを作る（大きな泥だんごではなく）

このような形で紹介されているわけではないけど、本書を読むとシステムの進化の段階は以下の3レベルと定義されていることがわかる。

  1. 大きな泥だんご／レガシーシステム
  2. 無駄な部分や妥協点のないモノリスシステム
  3. マイクロサービス適用システム

ゼロから、もしくは大きな泥だんごから一足飛びにマイクロサービスに向かうことを筆者は推奨していない（不可能ではないが、「もっとも険しい道のり」と言っている）。また、全てのシステムがマイクロサービスの適用を目指すべきではないとも。

モノシリックアーキテクチャを構築することを、責任逃れの三流の選択のように感じる必要はない。つまり、筆者が勧めているように、十分にモジュール化された、ちゃんとしたモノリスを構築するのであれば、そうはならない。
要件最適アーキテクチャ戦略　第10章 モノリスを目的どおりに構築する

そして筆者の言う「十分にモジュール化されたモノリス」ならば、必要に応じたマイクロサービスへの移行も難しくない（第11章 モノリスからマイクロサービスへの悠然たる移行）のだ。

うーん、言うのは簡単だけれども、実践は難しそう。
一応数年以内に出版される予定の続編で、さらにこのあたりは詳しく語られるようだ。

後半を読んだ感想

  • 前半の感想にも書いたのだけれども難解。そして例題がわかりにくいのは引続き。
  • 難しいのだがそれでも「第10章 モノリスを目的どおりに構築する」は興味深かった。大きな泥だんごシステムを例にとって、どのような形で正しいモノリスへリアーキテクティングしていくか、という話だからである。どう分解していくべきかという話は非常に面白い。
  • またあくまで戦略としてはリライトではなく、リアーキテクティング推しである。

筆者には、建設業界で経験を積んでいる友人がいる。その友人が言うには、建物をきちんとした方法で解体するのにかかる時間は、その建物の建設にかかった時間の10 分の1 以下で済むそうだ。単に建物を壊すだけではなく、重要なパーツをすべて再利用することも目的に含まれている。ソフトウェアの構築は建築業界とはあまり似ていないが、友人の主張は、コードの有意義な再利用を意図した、大規模なシステムのコードベースの秩序あるリファクタリングと再構築の手がかりになるだろう。
要件最適アーキテクチャ戦略　第10章 モノリスを目的どおりに構築する

うーむ、私の周りにもゴロゴロとした大きな泥だんごがあるのだが、誰か一緒に本書を読みながら戦ってくれる人はいないか、と思う今日この頃であった。

さて、本書もなんとか一応読み終わった。次は何を読もうかなぁ。話題の本を取り扱っても良いかもしれない

最近読んだフィードバックに関する本を３冊紹介する

Project Management Work book

先日読み終わった「みんなのフィードバック大全」が面白かったのだけれども、ふりかえってみるとフィードバックというテーマの本は他にも何冊も読んでいた。おそらく深層意識のどこかでフィードバックに関する課題感を感じているのだろう（大げさ）。復習も兼ねて、最近読んだフィードバックに関する本を整理してまとめておこうと思ったのだ。

目次

みんなのフィードバック大全

みんなのフィードバック大全
SAP Concerという経費精算システムを販売するコンカーの日本法人社長が執筆した書籍。SNSのタイムラインで絶賛されていたので手に取った本。本記事で紹介する他の2冊はマネージャー向けであるのに対して、本書はマネージャー以外の若手にもおすすめしたい本である。著者もそう考えているようで、タイトルに「みんなの」とあるのはその意思の表明とのこと。

  • コンカー日本法人の設立直後は組織作りが後手に回ってしまい苦戦。方針を見直した結果、日本における「働きがいのある会社」で表彰されるようになった。
  • 現在は本業とは別に、働き方に関する施策や取組みを研修として提供している。その中で最も注目されている「コンカー流フィードバック」を書籍化したのが本書。
  • ベースとしては著者のマッキンゼーでの学びがある。
  • 参考

本書が良いのは、マネージャーの立場だけでない形で、様々なフィードバックの方法がフレームワークと実例で紹介されているところだ（ちゃんと大全になっている）。
特に「部下から上司」「同僚間」でのフィードバックの事例は参考にしたいし、いろいろ考えるきっかけになる。
実際に本書のプロローグでは、著者の三村氏がマッキンゼーで新卒2年目の若手社員からフィードバックされる場面が紹介されるが、これはけっこうインパクトがある。

「ビジネスの経験は大切です。ただ経験だけに頼って考えたり話したりするのでは、マッキンゼーのコンサルタントとしては不十分だと思うんです。経験に頼るのではなく、〝ファクト〟と〝ロジック〟で話す。そこに経験を裏打ちする。そこを意識すれば、三村さんはもっと強くなれると思うんです」
みんなのフィードバック大全 プロローグ、より

新卒2年目の若手社員が、他社から転職してきた10歳以上年上の著者に、こんなことを言うのである。
これをコンカーでは組織的に常時やれるようにしたとのことで、それは強いだろう。真似したい。

フィードバック入門～耳の痛いことを伝えて部下と職場を立て直す技術

フィードバック入門 耳の痛いことを伝えて部下と職場を立て直す技術 (PHPビジネス新書)
以前に本ブログのこの記事でも取り上げたのだが、「ヤフーの1on1」という書籍（この本もオススメ）で、「この本を超える参考書はたぶんない」などお激推しされていたのが本書、フィードバック入門である。新書なので忙しいビジネスマンにとっては有難いコンパクトな本でもある。こちらはマネージャー、管理者、人事部や経営者向けの本である（実際に著者もそう言っている）。

本書の特長は、
①部下育成やフィードバックの基礎的な理論、学問的な知見（科学知）
②現場のマネジャーからヒアリングを通して抽出した実践的な知見（実践知）
この二つをバランスよく盛り込むことを意識している点にあります。
フィードバック入門 耳の痛いことを伝えて部下と職場を立て直す技術 (PHPビジネス新書) はじめに、より

キーワードは「育成」である。本書はコンパクトながらも、「なぜ部下が育たないのか」という課題に関する社会史的な分析に始まり、「部下育成のためのフィードバック理論」を説明し、さらに実践編＋タイプ＆シチュエーション別FAQまでついているという密度で、持っていると非常に心強い教科書という感じだ。またロジックが明確なので、例えばリーダーを部下に持つ管理職にとっては特に心強い本だと思う。

GREAT BOSS～シリコンバレー式ずけずけ言う力

ＧＲＥＡＴ　ＢＯＳＳ（グレートボス）　―シリコンバレー式ずけずけ言う力
邦題がおかしい本（そして机の上に出しておくと同僚にハラスメントの疑いをもたれる本）。原著はタイトルは「Radical Candor（徹底的な本音）」である。率直なフィードバック（時には厳しいことも言わなければならない）について書かれている本である。現代の技術者マネジメントの教科書だと勝手に思っている「エンジニアリングマネージャーのしごと ―チームが必要とするマネージャーになる方法」でもおススメされている。

フィードバックを伝える最良かつ簡潔なアドバイスは、徹底的な本音です。同じ名前の本になっています。スタッフと話すときに、話すべきこと、話すべきでないことを示しています。
エンジニアリングマネージャーのしごと ―チームが必要とするマネージャーになる方法 「3章 人間と関わる」3.1.4 フィードバックをするには、より

この本を紹介するのはネタでもオチでもなく、大真面目にオススメできる本である。マネージャーおよび人事担当者向けである。

さて本書は（シリコンバレー流という前提付きで）良い上司になる方法、具体的にはメンバーとの信頼関係を構築して、徹底的な本音で語り合うことを推奨する本である。けっして部下を「詰める」本ではない。著者は起業に失敗した後にグーグル、そしてアップルに入社後はリーダーシップ教育を実践してきた方である（現在は独立）。シェリル・サンドバーグが大学院の同級生だそうだ。
翻訳書という点では注意は必要だろう。米国におけるマネージャーと、日本における管理職では人事権等も含めた裁量が異なる。ただそれを差っ引いても学ぶべき事が多い本である。

まとめ

関連記事

以前にはこんなことを考えていた
agnozingdays.hatenablog.com

「要件最適アーキテクチャ戦略」の前半を読んだ。難しいぞ

book Professional Engineer

読むのがホネな（積みがちな）技術書やビジネス書を取り上げて２週間の読書期限を課して読んでアウトプットする仮想読書会「デッドライン読書会」の第53回。常時、けっこうな量の積読があるのだけれども、知り合いと読書期日を約束することによって消化が捗るという仕組み。過去5回分のログはこんな感じ。

さて、今回取り上げるのは「要件最適アーキテクチャ戦略」である。ちょっと長いので前半と後半に分けて読む予定。というわけで今回は前半の「Part1 転機をもたらす実験による戦略的学習」「Part2 イノベーションを促進する」を取り扱う。

要件最適アーキテクチャ戦略

要件最適アーキテクチャ戦略

Amazon

要件最適アーキテクチャ戦略とは

原題は「Strategic Monoliths And Microservices: Driving Innovation Using Purposeful Architecture」である。ストレートに直訳すると「戦略的なモノリスとマイクロサービス： 目的別アーキテクチャによるイノベーションの推進」となる。
そして著者はヴァーノン。前著で翻訳されているのは「実践ドメイン駆動設計」だ。
というわけで、鍵となるのはドメイン駆動設計（DDD）である。

なお本書では、マイクロサービスを礼賛しているというわけではない。

この数年間に、ソフトウェアに対して使われるモノリスやモノリシックという言葉が非常に否定的な含みを持つようになった。たとえそうでも、モノリシックなレガシーシステムの圧倒的多数が大きな泥だんごに分類されるからといって、必ずしもそうなるとは限らない。モノリスが問題なのではなく、泥であることが問題なのである。

「泥であることが問題なのである」強い表現だ（レビューの時などに活用したい。「それは泥ですね」とか言いたい）。ちなみにこういったパンチのある表現がPart1にはよく出ているので楽しい。ソフトウェアの有名なアンチパターンである「大きな泥だんご」が本書において解決したい主要な問題である。

大きな泥だんご

ちなみに、ソフトウェアのアンチパターンである「大きな泥だんご」は、とりあえずWikipediaが詳しい。何かの本で詳しい説明を読んだ気もするのだが思い出せない。
大きな泥だんご - Wikipedia

アンチパターンといえば、まさに「アンチパターン―ソフトウェア危篤患者の救出」という名著（現在は絶版）があったのだけれども、そこには大きな泥だんごは収録されていないようだ。

この「大きな泥だんご」化を防ぐためにアーキテクチャを戦略的に構築していくべきだ、というのが本書の主張である。ただし、それはビジネスの学習と理解を通じて進化的に構築すべきでもある。技術主導ではなくビジネス主導で検討せねばならず、そこで出てくるのがドメイン駆動設計である。

本書の前半を読んで良いとおもった点

  • 「Part1 転機をもたらす実験による戦略的学習」は現代のソフトウェアが直面する課題について論じていて非常に刺激的である。Space Xを引合いに出した説明も面白い。
  • ビジネス分析の手法の中核に「イベントストーミング」を置いている。これは注目していきたい手法である。
    • 近年流行しているビジネス分析手法としては「ユーザーストーリーマッピング」がある。この手法は強力であり有用なものだと思うが、複雑なビジネスをモデリングするという点では取扱いが難しいというのが個人的な意見だ。
    • 「ユーザーストーリーマッピング」を代替もしくは補完する手法として「イベントストーミング」は良さそう。
    • ただし本書で「イベントストーミング」を理解するのは難しそう。私はこちらのページなどを参考にいろいろと調べ始めている：イベントストーミング導入

本書の前半を読んで課題があるとおもった点

  • 難解だ！おそらく翻訳の問題ではなく、原著も難解なのだろうと思われる。
  • そして輪をかけて理解を難しくしているのは書籍がモノクロだという点である。おそらく原著では図表がカラーだったのだと思われるが翻訳はモノクロになっていた、これがわかりにくさを増幅している。
    • 実際のところ、わからないところは自分で手を動かしてカラーで図を書き直してみたりしてる。ちょっとつらい。

というわけで、前半はヒーヒー言いながら読んだ。後半では「イベントファーストアーキテクチャ」が取り扱われるようであり、これはちょっと楽しみである。

ウォーターフォールを殺しにきている書籍「継続的デリバリーのソフトウェア工学」を読んだ

book Professional Engineer

読むのがホネな（積みがちな）技術書やビジネス書を取り上げて２週間の読書期限を課して読んでアウトプットする仮想読書会「デッドライン読書会」の第52回。常時、けっこうな量の積読があるのだけれども、知り合いと読書期日を約束することによって消化が捗るという仕組み。過去5回分のログはこんな感じ。

さて、今回取り上げるのは「継続的デリバリーのソフトウェア工学　もっと早く、もっと良いソフトウェアを作るための秘訣」である。ちょっと長いので通常2週間のイテレーションを延長して3週間で読んでいる。

継続的デリバリーのソフトウェア工学　もっと早く、もっと良いソフトウェアを作るための秘訣

継続的デリバリーのソフトウェア工学　もっと早く、もっと良いソフトウェアを作るための秘訣

Amazon

ちなみに先に言っておくと、私の好きな開発プロセスはウォーターフォールではなくUnified ProcessもしくはDADである。別にウォーターフォールに思い入れはない。あしからず。

ウォーターフォールへの新たな刺客！

さて本書だが、わかりやすくウォーターフォールを刺しに来ているのが興味深い。新たな使徒登場である。
ちなみに個人的な観測範囲での前回の使徒はマコネルの「More Effective Agile “ソフトウェアリーダー”になるための28の道標」である。ただこちらは、ふんわりとした太刀筋なので攻撃されたことに気づかなかったかもしれない。

煩雑系であるという絶対的な確信がある場合以外は、プロジェクトを複雑系として扱い、アジャイルプラクティスに投資するほうが安全である（なお、プロジェクトを煩雑系として扱う場合は、シーケンシャルアプローチがうまくいくだろう）。
More Effective Agile “ソフトウェアリーダー”になるための28の道標、第3章より

同書の感想記事はこちら

さて、本書はよりストレートにウォーターフォールに切り込んでくる。直球である。

  • ウォーターフォールを中心とした「これまでのソフトウェア工学」には誤謬があり、停滞している。この停滞はハードウェアの進化に隠蔽されている。
  • 場合によっては誤ったプラクティスによって退化している場合もある。

このあたりは本書でも紹介されているグレン・ヴァンダーバーグの講演に通ずるものがあり、実際本書のプレストーリーはその内容とほぼ一緒である。

ウォーターフォールの思考様式を広めた人々はよい意図からそうしたのです。彼らは、ウォーターフォールこそ、最良の仕事の進め方だと思ったのです。ソフトウェア産業は、数十年をかけてこのアプローチを軌道に乗せようとしましたが、うまくいきませんでした。
継続的デリバリーのソフトウェア工学　もっと早く、もっと良いソフトウェアを作るための秘訣、第4章より

ただし、それではアジャイル開発を推奨しているのかというと必ずしもそうではない点が興味深いところだ。明確にアジャイル開発を批判しているわけではないのだが、クラフトマンシップでは不十分ということも述べている。

ソフトウェアクラフトマンシップという考え方はかつて重要でした。この考え方のおかげで、以前の製造重視で儀式的な開発アプローチから重要な一歩を踏み出せたのです。私は、ソフトウェアクラフトマンシップという考え方が間違っているとは思っていません。それでは不十分だと思っているのです。
継続的デリバリーのソフトウェア工学　もっと早く、もっと良いソフトウェアを作るための秘訣、第2章より

じゃあ、どうするの？というのは本書の主題である。

本書で紹介されている新たな「ソフトウェア工学」の骨子

ざっくりとまとめると、以下のように要約できるだろう。

  • Accelerate本を前提に、安定性とスループットがKPIとなる
  • このKPIを役に立つ判断指標として「学びのエキスパート」「複雑さ管理のエキスパート」を最重要スキルと定義する
  • この2つの最重要スキルごとに様々なプラクティスを整理したものが新たなソフトウェア工学、本書の原題である「Modern Software Engineering」である

本書はこの点について、例示や知的好奇心を満たすコラムも交えながら（興味深い！）語っていて非常に有用な整理をしている。
特にAccelerate本を前提としてソフトウェア開発アクティビティの改善に取り組んでいる組織には、非常に有用な書籍だろう。自分も読んでいて、いろいろと見直すべき点などを考え始めている。

ただ、一方でちょっと気になる点も感じたのだ。

ウォーターフォールはオワコンなのか？

本書の著者であるデイビッド・ファーリーさんの原点はLMAXという市場系取引プラットフォームのようである。ファウラーさんのブログにも紹介されていた。QConで講演も視聴できるようなので近日中には観てみたい。

こういった領域のソフトウェア開発については少し経験があるのだけれども、探索的であり、ソフトウェアの改善が収益に直結するので非常にエキサイティングな領域なのだ。エンジニアリング・ハッピーだ。雰囲気としてはこの映画（大好き）のイメージである。

ハミングバード・プロジェクト 0.001秒の男たち(字幕版)

ハミングバード・プロジェクト 0.001秒の男たち(字幕版)

Amazon

ただ一方で、探索的であってはいけないプロジェクトも存在するわけで、そういったプロジェクトをどうするかという問題は本書のアプローチだけでは解決できないと思っている。

  • 許容される試行錯誤の範囲が狭い（高い精度で正解に近づく必要がある）
  • 複雑な利害関係があり変更許容性が低い（例えばオペレーションに多数の人間が関わっており、頻繁にオペレーションを変更できない）

などなど。ただこういった反論をしたくなるのも、古いソフトウェア工学の呪縛から逃れられていない証拠なのかもしれないけれど。
引続き、いろいろ思考をアップデートしていく必要があるわけである。

参考文献

さて、次は何を読もうか。気になっているのはこのあたりかなぁ

Glenn Vanderburgの「Real Software Engineering」講演（2017）を見る

Professional Engineer

デッドライン読書会という企画で「継続的デリバリーのソフトウェア工学　もっと早く、もっと良いソフトウェアを作るための秘訣」を読んでいる（4月に入ったら感想を書く予定）。同書で紹介されていたGlenn Vanderburgの「Real Software Engineering」講演（2017）が面白そうだったので視聴してみた。講演はYoutubeで公開されている。同書の主張と同じく、この20年間の「ソフトウェアエンジニアリング」は誤っているという話である。

グレン・ヴァンダーバーグ（GlennVanderburg）は、“RealSoftwareEngineering”と題したすばらしい講演のなかで、ほかの分野では「工学とは役立つもの」なのに、ソフトウェアではほとんど逆だったと言っています。ヴァンダーバーグは、そうなる理由をさらに掘り下げていきます。アカデミックなソフトウェア工学のアプローチは煩雑すぎて、実践してみた人はみな、将来のプロジェクトで使うことを勧める気になれなかったというのです。ソフトウェア工学は、重々しいくせにソフトウェア開発のプロセスに大した付加価値を与えてくれるわけではありませんでした。
継続的デリバリーのソフトウェア工学　もっと早く、もっと良いソフトウェアを作るための秘訣 (P.43)

vanderburg.orgwww.youtube.com

視聴した感想

主には以下のような話である。

  • これまで主流だったソフトウェアエンジニアリングは実際には「アカデミック・ソフトウェアエンジニアリング」であった
  • 「アカデミック・ソフトウェアエンジニアリング」には誤謬があった。前提としている「合理的なモデル」は実際にはカリカチュアでしかなく、実際のソフトウェア開発ではうまく活用できなかった
  • そもそも、「アカデミック・ソフトウェアエンジニアリング」では「エンジニアリング」に関する誤解がある

上記について、様々な事例の紹介をふまえて説明されており、興味深い内容である。
ただ、基本的には「継続的デリバリーのソフトウェア工学　もっと早く、もっと良いソフトウェアを作るための秘訣」の第1章～第2章で語られている事と同じでもあるので日本語での読みやすさを考えれば、本を読んだ方が早いかもしれない。

継続的デリバリーのソフトウェア工学　もっと早く、もっと良いソフトウェアを作るための秘訣

継続的デリバリーのソフトウェア工学　もっと早く、もっと良いソフトウェアを作るための秘訣

Amazon

ブルックスの「デザインのためのデザイン」が紹介されていて懐かしかった。この本は好きなんだけど、絶版であり残念だ。
デザインのためのデザイン

デザインのためのデザイン

Amazon

終盤でGlenn Vanderburg氏は次のように結んでいる。「アカデミックソフトウェアエンジニアリングは、間違った目標を掲げて間違った方向に出発してしまった。アジャイルは、私たちの分野に適した適切な規律と実践で、正しい目標を念頭に置いて出発したのだ」。

www.theatlantic.com

V字モデルの深淵を覗き込んで反省する：「単体テストの考え方（UTPPP）」を読む（後編）

book Professional Engineer

読むのがホネな（積みがちな）技術書やビジネス書を取り上げて２週間の読書期限を課して読んでアウトプットする仮想読書会「デッドライン読書会」の第51回。常時、けっこうな量の積読があるのだけれども、知り合いと読書期日を約束することによって消化が捗るという仕組み。過去5回分のログはこんな感じ。

今回取り上げるのは前回に引続きの「単体テストの考え方/使い方」（原題はUnit Testing Principles, Practices, and Petternsで、略すとUTPPPらしい）である。けっこうなボリュームがあるので2回に分けて読んでおり、前回最初の２部を読んでいるので、今回は後半の「第３部　統合（integration）テスト」「第４部　単体テストのアンチパターン」を読んでいる。

単体テストの考え方/使い方

単体テストの考え方/使い方

Amazon
前半の感想はこちら
agnozingdays.hatenablog.com

昨年末に発売されて話題となり、冬休みの読書に最適などと言われていた本である。

なお本書は紙版に加えてKindle版もあるが、直販や達人出版会でコピーが可能なPDF版も販売されている。紹介されているコードを実際に動かしてみたい人などは、直販のPDFを買うことも検討されたし。

「単体テストの考え方/使い方」後半を読んだ感想

後半とくに「第３部　統合（integration）テスト」を読んでわかったのは、本書はデベロッパー（プログラマ）側のテストについて書かれている本のようだ、ということである（いまさらー！）。

ソフトウェアのテストについてはQA側のテストとデベロッパー側のテストがあると雑に整理してみると、本書が扱う「単体テスト」および「統合テスト」はQA側のテストではなくデベロッパー側が実施するものだ。だから本書の「第３部　統合（integration）テスト」で説明されるテストも、QA側のテストの匂いはほとんど感じられない（こうした理解しか出来ないのは自分がSIer脳だからかもしれないが）。

本書の冒頭付近で以下のような記述があるのだけれども、この理解を持って改めて読んでみるとなるほどと考えさせられる。

多くの書籍は単体テストの基本だけに目を向けており、それより先のことにはあまり踏み込んでいません。
（中略）
一方、本書は単体テストを作成できるようになったあとの段階にまで読者を導くようになっています。本書では、理想的な単体テストとはどのようなテストなのかについて正確で科学的な定義をし、この定義がいかに実用的で現実の世界を反映しているのかを提示しています。本書が望んでいることは、十分な数のテスト・ケースを用意したのにもかかわらず、なぜ、プロジェクトが期待した結果を得られないのか、そして、そのことを修正するためには何をすればよいのか、ということを理解する手助けになることです。
単体テストの考え方/使い方　1.1 単体テストの現状、より

というわけで「第３部　統合（integration）テスト」で説明されるのはQA側が実施する統合テストではなく、デベロッパーが実施するより高度な単体テスト（と書くと語弊があるが詳しくは書籍をご覧いただきたい）なのだ、という事である。うーん、なるほどねー。

改めて、単体テストについて考える

この本を読むことによって、だいぶ単体テストの解像度が上がった気がする。有名なt_wadaさんの以下のスライドのわかりみが増したような気もする
speakerdeck.com

そして解像度が上がったことにより、反省もいっぱいあるのである

  • そもそも論でQA的なテストとデベロッパー的なテストを混同していた
  • 単体テストの質への着目は薄く、網羅率（coverage）を重視していた
  • 単体テストの目的を明確にしていないことも多かった

いろいろと気づきの多い良い読書であった

さて、次は何を読もうか。候補はこのあたりかな