モダン・ソフトウェアエンジニアリングの前半を読んだ #デッドライン読書会

読むのが骨な（積みがちな）技術書やビジネス書を取り上げて２週間の読書期限を課して読んでアウトプットする仮想読書会「デッドライン読書会」の第18回。今回ピックアップするのは「モダン・ソフトウェアエンジニアリング」である。分厚いので前後編に割って、今回は「第Ⅰ部 ソフトウェアエンジニアリングの本質」と「第Ⅱ部 Essenceを使ったソフトウェア開発」までを読んでいる。残りは第19回で読む予定。

モダン・ソフトウェアエンジニアリング

なお今回は翔泳社から訳書をPDFで購入して読んでいる（購入時点で割引クーポンがあったからだけれど）。

前半読了時点の総評（後半を読んだら変わるかもしれない）

• 私は非常に楽しんで読んでいる。ただし万人向きではない。誰にでもオススメできる本ではない。次のような事を考えたい人向きではないだろうか
  • ソフトウェア開発の本質について考えたり、考察したい
  • 高い抽象度でソフトウェア開発方法論の歴史的経緯について知りたい
  • 独自のソフトウェア開発方法論、もしくは既存の方法論を大きくテーラリングすることを考えている
• ソフトウェア開発における業界、分野的な問題点に鋭く切り込んでいることは確かだし、その点は非常に興味深い（時折差し挟まれる業界ディスが楽しい！）
• 主題の（Essenceという名前の）方法論そのものについては本書では説明されていない。活用方法を中心に触れられている

とにかく、いろんな意味で難しい本です

モダン・ソフトウェアエンジニアリングが語ろうとしている事

大事なことなので何度も言うが、本書は特定のソフトウェア開発方法を教えるものではない。優れたソフトウェアをもたらす作業方法の作成方法を教えるものである。
「モダン・ソフトウェアエンジニアリング」はじめに、より

というわけで本書の中心として語られているのはEssenceという名前の「ソフトウェアエンジニアリングの汎用的な共通基盤／記述言語」と、その活用方法である。

今日のソフトウェアエンジニアリングは、未熟なプラクティスによって重大な妨害を受けている。具体的な問題として、以下が挙げられる。

• エンジニアリングというよりファッション業界でよく見られる一時的な流行の蔓延
• 妥当性のある広く受け入れられた理論的基盤の欠如
• 違いがほとんどないにもかかわらず人為的に誇張された無数の手法とその派生形
• 信頼できる実験的な評価と検証の欠如
• 業界の慣行と学術研究の分断

「モダン・ソフトウェアエンジニアリング」第2章 ソフトウェアエンジニアリングの手法とプラクティス

という問題認識に対して、「汎用的な考え方と拡張方法」を以て共通基盤を創出する、というのがゴールである。（上記の問題認識については、平鍋さんの2010年のブログ記事も参考になる）

で、具体的にどんな感じになっているかというと

もし本書を読む前に、Essenceってどんな感じなのかを知りたければ、訳者の角征典さんの資料を見ていただくのがいいだろう
speakerdeck.com
まあ資料でも触れられているが、初期にUMLが登場したころと同じ感情がわきおこる・・・

モダン・ソフトウェアエンジニアリング(という本)の弱点

というわけで、本書で紹介される概念には期待も大きい一方で、「こんなの使いこなせるのか」という懸念も感じながら読んでいるわけだが、いくつか気になった点もある

• 中心となる「カーネルのアルファ」のカードそのものが本書ではさわりしか紹介されていない！
  • チラチラと挿絵としては紹介されるのだけれども、一覧が（たぶん）書籍内では紹介されていないようだ
  • 全てのアルファを確認するなら、以下の情報源を調べる必要アリ
  • 訳者の角征典さんが公開している翻訳版 https://github.com/kdmsnr/essence-alpha-state-cards-ja
  • 本家の英語版 https://www.ivarjacobson.com/publications/cards/alpha-state-cards-pdf-version
  • SEMAT日本支部の翻訳版（ただし本書とは訳が違う）https://www.dropbox.com/s/prps8wi55hix5lb/SEMAT_SWEngKernel_Cards_Ja.pdf
  • 訳書のサポートサイトでダウンロードできるようになることを期待しているのだけれども……
• そもそも「Essence標準」（つまり方法論のコア部分）については本書は紹介するに留まっており、詳細はOMGで公開されている論文を見る必要がある
  • About the Essence Specification Version 1.2

まぁEssence標準は気になった人だけが読めばいい（一般の人はとりあえずアルファをそのまま使えばいい）という割り切りなのだと思うけれど、ちょっと残念に感じたのであった。

つづく

というわけで、楽しみながらも「頭をかかえながら」読むタイプの本で知的好奇心的には刺激されまくりである。
が、皆さんが本書を読むかどうかは慎重に判断いただいたほうがよさそう。

アラフィフ理系が放送大学の教養学部に入った記録（1年目前期完了）

2020年4月から放送大学の教養学部「人間と文化コース」に入学して、これまで勉強してこなかった人文系の勉強を始めている。最初の半期が終わったので感想などをまとめてみた。
学期はじめに書いた記事はこちら。
agnozingdays.hatenablog.com

1年目前期の感想

• 授業は4月からスタートであったが、実際には印刷教材とオンラインサービスのIDが発行された3月から受講を開始した（放送内容はスタート時点ですべて視聴可能）
• 毎週末に受講科目を視聴した。科目に応じて予習または復習を実施してた（詳細は後述）。
• 5月に通信指導(ミニテストを実施して提出する)、7月に試験を実施。なお試験は当初、各地にある学習センターでのオンサイト試験を予定していたが在宅試験への切替となった。
• 在宅試験はCBTというわけではなくて、単に自宅で試験問題を解いて解答用紙を郵送するだけ。なお元々オンサイト試験でもテキストとノートが持込可なので、通常の試験より大きく有利になったということはないような気がする。
• 7月に試験が終わって夏休み期間（8～10月）になったが、自分はこの期間に興味のある文化人類学系の授業を追加で聴講した（履修登録をしていないので当然単位にはならない）
• 8月下旬に成績発表（どちらもA評価で合格）

哲学・思想を今考える

哲学・思想を今考える―歴史の中で (放送大学教材)

• 哲学・思想系の導入科目。これはレベルとしては初級に該当する
• ラジオ講座のため画像コンテンツはなし。ほぼ教科書の朗読を聞くオーディオブックのような授業だったのだけれども実はこれが良かった。特に後半戦から内容が難しくなるのでテキストを目で追うだけでは、ぜんぜん理解できないのですよ。目と耳を駆使して集中して学習したのは、ものすごく久しぶり。
• 受講にあたっては、予習は行わず、復習に時間をかけた。受講内容をノートにまとめたり、不明点についてネットで調べたりしてた。
• 近代哲学あたりから急激に難解になってきて、理解度もダウンした。ニーチェまではまだわかる。ハイデガーからは非常に厳しい。というわけで受講後に復習のために本を買ってしまった（まだ読んでいない）
  • ハイデガー入門 (ちくま新書)
• コロナ禍ということもあり、4月頃に講師の魚住先生からメールをいただけたのが大変に感動した。

西洋芸術の歴史と理論

西洋芸術の歴史と理論―芸術の深く豊かな意味と力 (放送大学教材)

• 美術系の専門科目、これは科目レベルとしては中級に該当
• テレビ講座かつ、各国美術館の取材映像やアーティストへのインタビュー等が大量に含まれており非常に素晴らしい。興味のある人は10月以降の後期放送を録画して見ることをお勧めするくらい良かった。教科書（印刷教材）は補足であり持っていなくても十分楽しめる。
• 「芸術とは何か」というテーマを下敷きに古代から現代まで各時代の芸術作品を俯瞰するという意味で、とてつもなく教養力が上がった。そして世界各地の美術館や建築を見に行きたい気持ちになった。

総合人類学としてのヒト学

総合人類学としてのヒト学 (放送大学教材)

• もともと前期で履修登録していたのは前述の2科目だけだったのだけど、後期が始まる10月までに時間があったので聴講している。テキストの購入は省略。将来受講したいと思っている文化人類学系の科目の前提講座であるというのが受講動機。
• ラジオ講義で映像はなし。講義中にときどき「テキストの図Xを参照」ということがありテキストが無いのは若干やりづらいのだけれども、なんとか耐えられる状況。
• 内容はかなり興味深い。ヒト全般に関する広範囲なテーマを扱っている。受講しながら過去に読んだ「銃・病原菌・鉄」や「サピエンス全史」の関連記述を再読したりしている。こういった類の本に興味のある人は楽しめるだろう。

1年目後期の予定

以下の2科目を履修登録した。前期に受講してみて、やはりラジオ講座よりはテレビ講座のほうが面白いということでラジオ講座の履修は取り止めている。

文学・芸術・武道にみる日本文化 (放送大学教材)

博物館概論 (放送大学教材)

ただ、ラジオ講座は履修登録していないものの聴講しようとは思っていて、テキストだけをAmazonで購入している（履修登録すればテキストが送られてくるが、登録しないテキストもAmazonや放送大学の教育センターで購入可能である）。

西洋哲学の起源 (放送大学教材)

週末に数時間「放送大学の授業を受ける」という習慣ができて、普段仕事では使わない脳を使うのがエクササイズ的に楽しい。もちろん若干お金はかかるのだけれども（1科目 11K円。テキストのみだと3K円くらい）まぁ趣味としてはコスパいいのではないかと・・・（4.5年間はAmazon Studentに登録することによってPrime年会費が半額になる他のメリットもある）

www.ouj.ac.jp

Release It! 著者のリーディングリストを読む

Kawasimaさんが紹介していたので、いろいろ補いながら読んだという記事。

ナイガード先生によるアーキテクトが読むべき本 (および記事)のリスト。これこそが必読なやつらだ。https://t.co/OJunz9WUqc

— :craftsman/kawasima (@kawasima) 2020年8月5日

Michael T. Nygard氏はアーキテクトであり、近著ではRelease It!: Design and Deploy Production-Ready Software (English Edition)が有名である。

Release It!: Design and Deploy Production-Ready Software (English Edition)

で、同氏が今年の春に公開したブログ記事が本記事の題材。ここで紹介されている「必読」「おすすめ」について調べてみた。
www.michaelnygard.com

ナイガード先生の紹介する、必読（Require​d Reading）記事など

​​Architecture Decision Records

• 必読として紹介されているのはこの記事 Blog | Documenting Architecture Decisions | Relevance
• 日本語で読める情報
  • 実践ADR - kawasima　サンプルあり
  • アーキテクチャの「なぜ？」を記録する！ADRってなんぞや？ - Qiita
  • Architecture Decision Records導入事例 | Fintan　サンプルあり
  • https://www.infoq.com/jp/news/2020/08/architecture-decision-records/
• この本で少し紹介されている
  • Design It! ―プログラマーのためのアーキテクティング入門
• この本でも触れているっぽい（詳細未読）
  • Fundamentals of Software Architecture: An Engineering Approach

C4 Model

• 必読として紹介されているのはこの記事 The C4 model for visualising software architecture
  • 上記ページで日本語情報へのリンクもある https://www.infoq.com/jp/articles/C4-architecture-model/
• 何かのセミナーで日本語スライドで説明を見た記憶があるのだけれども、思い出せなかった :-(

Accelerate​

• 訳書が出てる。既読だけど、とてもお勧め

LeanとDevOpsの科学［Accelerate］ テクノロジーの戦略的活用が組織変革を加速する impress top gearシリーズ

• 英語でよければ、State of Devops Reportを読むと良い（これを深掘りした本だから）

Wardley Maps

• 必読として紹介されているのはこのブログ wardleymaps – Medium
• Wardley map - Wikipedia
• 日本語で読める情報はあまりなさそう？
  • https://www.infoq.com/jp/news/2016/01/innovation-enterprise/ ちょっと触れる程度

これは興味深いので、どこかでちゃんと調べようと思う。

Failure Modes and Continuous Resilience

• 必読として紹介されているのはこの記事 Failure Modes and Continuous Resilience | by adrian cockcroft | Medium
• 日本語で読める情報はあまりなさそう

これもあとでちゃんと読もう

ナイガード先生の紹介する、おすすめ（Recomm​ended Reading）

The Principles of Product Development Flow​

この本。くっ、OreillyのSafariには入っていないので気軽に読めない。2009年の本のようです。

The Principles of Product Development Flow: Second Generation Lean Product Development

Software Architecture in Practice

この本はOreillyのSafariに入っているので、そのうち読む。2012年の本。

Software Architecture in Practice (SEI Series in Software Engineering) (English Edition)

著者の一人のレン・バス氏のDevOps教科書は以前に読んだ。

Domain-Driven Design

これは以前に読んだ。
エリック・エヴァンスのドメイン駆動設計

Data and Reality, 2ed

Data and Reality by William Kent - Alibris
ざっと調べた感じだと入手難しそう

The Phoenix Project

以前に読んでた

The DevOps 逆転だ!

​The Unicorn Project​

なんと、上記に続編があるらしい。この本はOreillyのSafariに入っているので、そのうち読む。

The Unicorn Project: A Novel about Developers, Digital Disruption, and Thriving in the Age of Data (English Edition)

Pattern Oriented Software Architecture - Volumes 1, 3, and 4.

この本もOreillyのSafariに入っているけれど、ちょっと気軽に読めなさそう。

Pattern-Oriented Software Architecture, A System of Patterns (Wiley Software Patterns Series) (English Edition)

Release It!

この記事の冒頭で紹介しているが、良い本です。訳書は出ないのかなぁ。

読むことを推奨（Suggested Reading）

ちょっと疲れたので、ここは省略。。。

More Effective Agileの後半部分も読んだ #デッドライン読書会

読むのが骨な（積みがちな）技術書やビジネス書を取り上げて２週間の読書期限を課して読んでアウトプットする仮想読書会「デッドライン読書会」の第17回。今回はSteve McConnell氏の「More Effective Agile」後半部分（13章以降）がノルマである。最高にオススメの本だった。

More Effective Agile “ソフトウェアリーダー”になるための28の道標

• 前半の感想はこちら
  • More Effective Agileの前半部分を読んだ #デッドライン読書会 - 勘と経験と読経

90年代マイクロソフトの巨星たち（勝手な思い込み）

ところで自分の思い込みも多分にあると思うのだけれども、90年代前後にマイクロソフトに在席していた人はとても優秀だと思っている。

• デヴィッド・カトラー - Wikipedia

（必読！）

• ジョエル・スポルスキ - Wikipedia

　
（大好きな本。このブログを書き始めたきっかけでもある）

• Scott Berkun - Wikipedia

（これも大好きな本。PMとしての自分のバイブル）

• 中島聡 - Wikipedia

が、McConnell氏もMicrosoftに在席したというのはお恥ずかしながら知らなかった。

• Steve McConnell - Wikipedia

筆者が在席していた1990年代のMicrosoftでは、エスカレーションが非常にうまく行われていた。ある日の午後、上司が筆者のオフィスにやってきてこう言ったのを覚えている。「まいったよ。さっきまでBillGレビューミーティングに出席していて、こってり絞られた。2週間かかりっきりになっていた問題を、ビルは5分電話で話せば解決していたはずだったって指摘されてね。彼のところに回さなかったっていうんでこっぴどく叱られたよ。叱られて当然だと後悔している。彼に任せるべきだったのに、そうしなかったのだから。」
More Effective Agile “ソフトウェアリーダー”になるための28の道標 （17.1 基本原則：間違いを許す、より）

BillGレビューについては More Joel on Softwareに掲載された「はじめてのBillGレビューのこと」が翻訳も含めて最高なんだけど、元ネタになっている英語ブログ記事は公開されているので、DeepL翻訳あたりで訳して読んでも十分読めると思う。
www.joelonsoftware.com

というわけで何を言いたかったのかというと、McConnell氏の書籍は元から好きだったのだけれども、さらに好きになったということだ。なんてったって、憧れの90年代マイクロソフトに在席していたんだぜ！

（改めて）More Effective Agile の感想

本書だが、最後まで読み終わった今、はっきりと「有用な本」と断言できる良書だった。
特に以下のような観点を持っている人にとっては大きな学びがあるだろう。

• 特にアジャイルにこだわりは無く、より良いソフトウェアを開発したい
• 必要に応じてアジャイルからいいとこどりをしたい
• アジャイル開発プロセスについては一通り学んだが、一部のプラクティスについては懐疑的である

McConnnell氏がいいのは、すべてにおいてまず疑った上で、有用かどうか判断し、有用であれば活用するという姿勢である。
前半部の感想でも引用したのだけれども、この姿勢は最後まで貫かれていて良かった。

アジャイル開発に関するほとんどの書籍はエバンジェリストによって書かれている。エバンジェリストは特定のアジャイルプラクティスを提唱しているか、アジャイル全体を奨励している。筆者はアジャイルのエバンジェリストではない。筆者は「うまくいくもの」の提唱者であり、「なんの根拠もなく大袈裟な約束をするもの」への反対者である。本書では、意識高い活動としてアジャイルを扱うのではなく、管理的なプラクティスと技術的なプラクティスの集まりとして扱う。ここで扱うプラクティスは、その効果や相互作用をビジネス用語や技術用語で理解できるものである。
More Effective Agile “ソフトウェアリーダー”になるための28の道標 「第1章 はじめに」

また、以下の2章については一般的にアジャイル開発が適用しにくいと言われているテーマにフォーカスしていて、これはとても参考になりそう。

• 第20章 予測可能性
  • 一般的なアジャイル開発はデリバリーを優先するが、顧客が予測可能性（いつ機能セットがデリバリーできるか）を求めてきた場合にどうするか、という話
• 第21章 規制産業
  • 開発方式に規制の強い産業（生命科学、金融、政府機関）に対するアジャイルアプローチについて。2014年にFDAが採択した医療機器ソフトウェア向けアジャイルプラクティス利用ガイダンスを元に議論している。

ともかく、この本は新しい必読書の一つになることは間違いないだろう。ある程度ソフトウェア開発に関して学んできた中級者以上であれば楽しめるはずだ。新人／ジュニアクラスにはちょっとお勧めできない印象。

さて、次の課題図書は・・・

次回は今のところ、モダン・ソフトウェアエンジニアリングの予定である。かなりの分量なので、今回と同様に前後編に分けて取り扱うことにすると思う。

モダン・ソフトウェアエンジニアリング

以下のセミナー（開催済）に参加したので、興味を持っているのだ。
smartse.connpass.com

なにしろラジオとPodcastが好きなもので。2020

もともとラジオが好きで、テレビは嫌いだった。通勤時間でラジオやPodcastをよく聴いていた。コロナ禍になり在宅勤務が増えて通勤時間に聞くことは減ったけれど、最近は仕事の合間などに、また聞くことが増えてきている。というわけで、ラジオとPodcastを聴くことについての、振り返り。

テレビ番組はもともとそんなに見るほうではなかったのだけれども、東日本大震災あたりからすっかり嫌いになってしまった（もちろんドラマやドキュメンタリー番組などを録画して見る事はある）。特に災害と犯罪報道の刺激が強すぎる。というわけで、自分にとって日常的に触れるメディアはウェブとラジオとPodcastである。TVのニュース番組もほとんど見ていなくて、NHKラジオニュースを代わりに聞いているくらい。

音楽を聴くことも好きなのだけれども、同じ曲を繰り返し聞くのが嫌いというか、能動的に聞くのがあまり得意ではない。ラジオ番組を適当に聞き流すのが好きだ。もちろん偶然の出会いへの期待もある。Spotifyのプレイリストでもいいのだけれども（ときどき使ってはいる）、なんかラジオのほうがいい。作業に集中したいときには深夜に放送されているノンストップMIX系の番組をタイムフリーで聞くのも楽しい。

ラジオ／Podcastの聞き方

• リビングでAmazon Echo Dotで「アレクサ、ラジコでJWaveを聞かせて」「アレクサ、ニュースを聞かせて（NHKラジオのフラッシュニュースが再生される）」
• 仕事や読書をしながら、iPhoneのスピーカー、もしくはヘッドフォンで
• 散歩をしながらiPhoneのヘッドフォンで
• 庭でSonyのポータブルラジオ機で

アプリ

• Podcastは、iOSの標準のPodcast.appを使ってる
• ラジオはRadiko

よく聞いているPodcast

• ソフトウェア開発関連
  • Rebuild - Podcast by Tatsuhiko Miyagawa
  • EM . FM #EMFM • A podcast on Anchor
  • アジャイルラジオ
  • fukabori.fm
  • omoiyari.fm (lean-agile podcast) #omoiyarifm
  • 銀の弾丸ラジオ • A podcast on Anchor
  • ajitofm
• テック系
  • こんにちわ未来
  • Lobsterr FM • A podcast on Anchor
  • Takram Cast
  • blkswn radio • A podcast on Anchor
  • Off Topic
• その他のお楽しみ系
  • バイリンガルニュース (Bilingual News)
  • コテンラジオ
  • 大竹まこと ゴールデンラジオ！「大竹紳士交遊録」
  • SIGHT RADIO 渋谷陽一といとうせいこうの話せばわかる！政治も社会も • A podcast on Anchor
  • Researchat.fm
  • 渋谷らくごのポッドキャスト「まくら」
  • 未来授業 | これからの時代を生き抜くヒントを学ぶ特別授業

改めて整理してみると、anchorで配信している番組が予想以上に多くてびっくり。
Podcastの良い点は「スピード再生」できる点（ラジオではできない）。だいたい1.25倍～1.5倍再生している。

よく聞いているラジオ番組

• TAKRAM RADIO | J-WAVE 81.3 FM RADIO
  • 割と欠かさず毎週聴いてる。教養番組として好み。
• TUDOR TRAVELLING WITHOUT MOVING : J-WAVE 81.3 FM RADIO
  • これも欠かさず聞いてる。リラックス用
• Tokyo Moon | インターFM897 [ 89.7MHz TOKYO ]
  • 欠かさず聞いてる。松浦さんのファン。MCが少ないので作業の時に聞いてることが多いかも。
• RADIO SWITCH : J-WAVE 81.3 FM RADIO
  • 興味ある特集の時だけ聞いてる。
• 81.3 FM J-WAVE : RADIO SAKAMOTO
  • 隔月なので聞き逃すことが多い
• 村上RADIO - TOKYO FM 80.0MHz - 村上春樹
  • 不定期なので聞き逃すことが多い
• Growing Reed 岡田准一 : J-WAVE 81.3 FM RADIO
  • インタビュー番組。ゲストに興味があれば聞く。意外と鋭い良い番組。
• TOKIO HOT 100 : J-WAVE 81.3 FM RADIO
  • 流行チェックと意外な出会いを求めて
• 81.3 FM J-WAVE : J-WAVE SELECTION
  • 時々素晴らしい特番がかかるので、チェックしてる
• NHK ラジオニュース
  • TVのニュース番組をほとんど見ないので代わりに

NHKラジオニュース以外の番組はだいたいradikoのタイムフリーで視聴。1週間以内に聞かないといけないのがプレッシャーだけれども、Podcastのように未読が溜まってしまうことがないのはむしろ良いことかもしれない。

最近の悩み

• 視聴時間確保がいちばんの課題。聴きたいものが多すぎて聴く時間が足りていない。コロナ禍以前は通勤とジムで一気に消化することができていたのだけれども、最近はどちらの時間も無くなってしまった。
• いっぽうで、年をとったからかもしれないけれど、最近酒を飲んだら（老眼的な問題で）読書がめっきり捗らなくなってしまったので飲んだ後にまとめてPodcastを聞くということを始めている。寝落ちしちゃうことも多いのだけれども……

More Effective Agileの前半部分を読んだ #デッドライン読書会

読むのが骨な（積みがちな）技術書やビジネス書を取り上げて２週間の読書期限を課して読んでアウトプットする仮想読書会「デッドライン読書会」の第16回。今回はSteve McConnell氏の「More Effective Agile」前半部分（12章まで）がノルマである。予測にたがわず、有用な本であることに疑いはない。

More Effective Agile “ソフトウェアリーダー”になるための28の道標

ソフトウェア開発を「うまくやる」ための本

のっけから、有用な匂いがビシバシ伝わってくる。俺たちのMcConnell氏が帰ってきた！

アジャイル開発に関するほとんどの書籍はエバンジェリストによって書かれている。エバンジェリストは特定のアジャイルプラクティスを提唱しているか、アジャイル全体を奨励している。筆者はアジャイルのエバンジェリストではない。筆者は「うまくいくもの」の提唱者であり、「なんの根拠もなく大袈裟な約束をするもの」への反対者である。本書では、意識高い活動としてアジャイルを扱うのではなく、管理的なプラクティスと技術的なプラクティスの集まりとして扱う。ここで扱うプラクティスは、その効果や相互作用をビジネス用語や技術用語で理解できるものである。
More Effective Agile “ソフトウェアリーダー”になるための28の道標 「第1章 はじめに」

ちなみにこの後、「第3章 複雑さと不確実さという課題に対処する」にて、なぜアジャイルなのかについても明快に説明される。流行っているからでも、VUCAの時代だからでもなく、明確にアジャイルプラクティスに組織が投資したほうが良いという説明がされているのだ。というわけで、それ以降本書は批判的な立場を崩すことなく、アジャイルプラクティスの良い使い方についてアドバイスするという体裁となっている。

35年かそれ以上にわたってソフトウェア業界に携わってきた中で、一番の難題は、「コード＆フィックス開発」を避けることだった。コード＆フィックス開発とは、事前の見直しや計画を立てずにコードを書き、そのコードが動くまでデバッグする手法のことである（中略）。アジャイル開発には、見るからに短期集中型でコード中心であるために、チームがアジャイル開発のプラクティスを実践しているのか、それともコード＆フィックスを行っているのかますます見分けがつかなくなる、という課題がある（中略）。より効果的なアジャイルのミッションの1つは、アジャイル劇場を防ぐことである。アジャイル劇場とは、チームがアジャイルという化粧でコード＆フィックスを覆い隠すことを指す。
More Effective Agile “ソフトウェアリーダー”になるための28の道標「第4章 より効果的なアジャイルの始まり：スクラム」

あと、10章で既存の大規模アジャイル開発のフレームワークをバッサリ批判しているあたり、非常に痛快。

まだ完読していないけれども、おすすめの読み方は次の通り

• まず監訳者あとがきを読んで、本書の業界的な位置付けや、ねらいについて俯瞰する
• 1章と2章を読む
• 巻末の「28の基本原則のまとめ」を読む
• 残りを読む

マコネルと言えば……

有名なのは次の2冊だと思う。ソフトウェア開発における見積もりという行為には様々な批判があると思うけれども「ソフトウェア見積り」はいまだに有用度は高いと思うので、未読であれば強くおすすめする。「Code Complete」は好きな本だけれども、かなり古さを感じるので今から読むのであればよく注意したほうが良い（古書を買うか、Kindleでセールになっている時に買い、古いと感じたところは飛ばし読みするのが良いだろう）。

ソフトウェア見積り　人月の暗黙知を解き明かす

【電子合本版】Code Complete 第2版　完全なプログラミングを目指して

なお、本書を読んで知ったのだけれども、Construxのホワイトペーパーその他で本書以外の様々なマコネルの文書が読めるようだ。これらについても少しずつ読んでいきたいなぁ。
www.construx.com

リモートファシリテーターのポケットガイド読んだ

The Remote Facilitator's Pocket Guideという本が発売されてて読んだら面白かったので紹介する記事。本自体は短いのでさらっと読めます（個人的なな感想）。私はオライリーのサブスクをGoogle翻訳して読んだ。

The Remote Facilitator's Pocket Guide (English Edition)

本書について

• Regional Scrum Gathering South Africa 2018 で発表された"Hacking Remote Facilitation"というプレゼンテーションが元になっているっぽい。ただ探した限りだとプレゼン資料や動画は公開されていないようだ。
• 著者のサイトはこちら：The Remote Coaches
• 序文は「アジャイルレトロスペクティブズ　強いチームを育てる「ふりかえり」の手引き」の著者のEsther Derbyさん

ざっくり感想

ある程度は、この数か月の在宅勤務シフトなどで学習済の事柄であったが改めて俯瞰して見ると学びが多かった。あと、本記事では紹介していないが、セッションで利用するプレゼンテーション（筆者たちはGoogleスライドをよく活用しているようだ）のイメージが提示されていて、いくつかはさっそく取り込んで活用している。というわけで、なかなか現代にとっては良い本だと思う。きっと似たような本はこれからいっぱい出版されるんだろうな～

リモートファシリテーターとは

• 本質的には通常のファシリテーターと変わりない。参加者が貢献して協力できるようにする条件を作成することに責任を負う役割である。

リモートファシリテーターのための6つの原則

原則1：平等な機会の創出（Create Equal Opportunity）

• できれば全員がリモートで参加する
• フルリモートセッションが出来ない場合は、会議室で誰かがリモートメンバーの仲介人になる
• 会議の初めに技術的なチェックを行う
• 仮想ホワイトボード／仮想付箋として機能する補助ツールを準備しておく
• グループで意思決定を行うための準備（投票など）を準備しておく
• 資料を読む時間を作る（セッション開始時の冒頭5分など）
• 観察し、セッションに参加できていない人をフォローする

原則2：フローを有効にする（Enable Flow）

• 会議の流れに介入して、円滑に目的地に到達できるように促す
• アジェンダとセッションルールを最初に示す
• 共有編集できるビジュアルドキュメントを活用する
• 参加者が自分の感情等を表現できるツールを用意する（休憩したい、離席する、次のテーマに移りたい）
• 現在地を共有する（スライド5を見てください／質問がある場合はスライド10に追加してください）

原則3: ビジュアルによるガイド（Guide With Visuals）

• ビジュアルドキュメントを活用する（ホワイトボードの代替として）
• 明確な指示をして認知負荷を下げる（会議の手順などを図示する）
• 会議の約束事を明示する
• 結論を視覚的に記録する（全ての会話を覚え続けなくてよくする）

原則4：つながりを育む（Nurture Connection）

• チェックインの質問で会議を始める
• 小グループに分割する
• お手本になる（ファシリテーターの所作は皆に影響を与えやすい）
• 状況についてよく観察する（食事はした？休憩はできている？タイムゾーンの差は考慮できてる？）
• セッションを観察して、質問する（Aさん、喋っているようですが、ミュートになってますよー）
• 退去を許可する（このテーマに意見の無い方はここで離脱してかまいません）

原則5：遊び心のある学習を可能にする（Enable Playful Learning）

• 遊び心のあるマインドセットで参加できるアジェンダを作る
• 賢い問いを発する
• 楽しくて意味のあるビジュアルを使う
• 音楽を活用する
• 笑いを誘う

原則6：道具を使いこなす（Master Your Tools）

• セッションも目的から始める（ツールに対して最適化してはいけない）
• 事前準備重要
• 必要であればピポットする
• バックアップを準備する
• セッションと成果物を分離する（セッション中に資料を美化したくなる衝動から離れるため）