勘と経験と読経

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

「Retrospectives Antipatterns」を読んだ

Project Management Agile book

先日「Project Retrospectives: A Handbook for Team Reviews (Dorset House eBooks) (English Edition)」を読んだばかりだけれど、別の調べ物をしていたら「Retrospectives Antipatterns」という本が最近発売されたことを知ってしまったので勢いで読んでみた。アンチパターン好きなもので。すごい有用な本だった。

Retrospectives Antipatterns

Retrospectives Antipatterns

著者サイトはこちらのようだ。https://metadeveloper.com/

全体的な感想

えてして「ふりかえり」のファシリテーターは孤独だと思う。特にファシリテーションすること自体を主な仕事にしている場合、「より良い方法」「違ったやりかた」に触れる機会を持つことはなかなかに難しい。組織外のオープンコミュニティなどで情報交換をすることは可能だ。でも、外部から入手できる情報は「うまくいった事例」「新しいテクニック」が多い。チームのコンテキストはそれぞれ違うので、新たに入手した情報を活用することもなかなかに難しい。知りたいのは「よくある失敗と対策」である－－という意味では、まさに本書はズバリ革新を突いているいると思う。まさにアンチパターン＝「ふりかえりでよくある失敗と対策」が示されているのだ。

というわけで私は本書を読みながら「ああ、これはあるある」と感じまくり、そして「自分だったらどうするか」を考えることが出来たという意味でとても有用だった。

なお、全てのアンチパターンには通常の対応方法だけではなく、オンラインで実施する場合の注意点が併記されている点も素晴らしい。オンラインでのふりかえりは、オンサイトのものに比べて難易度も高いし考慮点も多い。良いきっかけを与えてくれたと思う。

おまけ：Retrospectives Antipatternsを読んだメモ

自分で後から参照することも考慮して、読みながら書いたメモを公開する。
なお書籍では各アンチパターンにはいろいろな解決策も提示されているが、これは興味があれば原著をあたっていただきたい。

序文

  • 蛸
    • 蛸は観察学習ができる。餌につられて学習訓練を行う蛸を観察して、報酬を受け取らない蛸も同様の能力を得るのだ。
    • 蛸の脳の60%は8本の足にある。
    • 良いレトロスペクティブにおいて、ファシリテーターとチームは蛸の足のように共通の目標に向かって一緒に働くのだ。
    • 本書で紹介する各アンチパターンには、その本質をふまえた蛸のイラストが添えられている。

Part.1 Structural Antipatterns

Wheel of Fortune（運命の輪）
  • ふりかえりの時間を短縮するためにStart-Stop-Continue（KPTに類似）のようなワークを使い、問題を分析せずに表面上の対策ばかりを実行してしまう（例：もっとペアプログラミングをする）
  • 運よく問題解決できる場合もあるが（アタリが出る）、根本問題が解決できない場合はふりかえりのたびに同じ話を繰り返すことになるだろう。ルーレットを回し続けても、状況は変わらない
Prime Directive Ignorance （最優先命令を提示しない）
  • ふりかえりを実施するにあたり、いわゆる「カースの最優先事項」を共有しないで始めてしまう

カースの最優先事項
今日見つけたものが何であれ、チームの全員が、その時点でわかっていたことやスキルおよび能力、利用可能なリソースを余すことなく使って、置かれた状況下でベストを尽くした、ということを疑ってはならない
Project Retrospectives: A Handbook for Team Reviews (Dorset House eBooks) (English Edition)

  • ふりかえりが非生産的なスケープゴートの発見と追及の場になってしまう（例：初期のメンバーXの働きが不十分だった）
In the Soup（インザスープ）
  • ふりかえりでチームは自分たちの権限が及ばないことについて話し合ってばかりいる
Overtime（延長）
  • ふりかえりをだらだらと延長してしまい、参加者の一部は離脱してしまう
Small Talk（スモールトーク）
  • 雑談を止めることができない
Unfruitful Democracy（実りの無い民主主義）
  • 議題を投票で決めた結果、選ばれなかった少数意見のメンバーが議論に参加せず、別議論を始めてしまう
Nothing to Talk About（何も話すことはありません）
  • プロジェクトがうまくいっているので、ふりかえりが不要とされてしまう
  • ふりかえりの目的が誤解されている

紹介されているFuturespectiveとThe Shipというワークはかなり興味深い。

Political Vote（政治的投票）
  • ふりかえりにおける投票などで、みんな他人の顔色をうかがってしまう。結果として各人の本当の意見が反映されない。

Part.2 Planning Antipatterns

Team, Really?（本当にチーム？）
  • 忙しい兼務の専門家（アーキテクトなど）をふりかえりによばない
Do It Yourself（日曜大工）
  • ふりかえりのファシリテーターが固定化（一般的にはスクラムマスターが担当）することにより、回数を重ねるごとにマンネリ化する
Death by Postponement（延期による死）
  • 次回のふりかえりまで問題を抱え込んでしまい、対処が遅れる
  • ふりかえり間隔が長すぎる、または忙しさによりふりかえりが延期される
  • 結果として、ふりかえりに大量の問題が持ち込まれて十分に議論できなくなる
Get It Over With（已むを得ず）
  • 作業を優先するために、ふりかえりの時間を短縮する
Disregard for Preparation（準備を無視する）
  • オンラインで行うふりかえりにおいて、準備不足により参加者が時間通りに参加できず、共有ドキュメントを開くのに手間取り、結果としてふりかえりは混乱し目的を達成できない
Suffocating（窒息）
  • 休息をせずにふりかえりをおこなう
  • 集中力が損なわれ、もしくは眠くなったりイラつく人も出て、結果としてふりかえりが時間の無駄になる
Curious Manager（好奇心旺盛なマネージャー）
  • 好奇心旺盛な上司やマネージャがふりかえりへの参加を希望する。
  • 邪魔をしないことが約束されても、安全性が損なわれてしまう。
Peek-A-Boo（いないいないばぁ）
  • オンラインふりかえりにおいて、参加者がビデオオフにしてしまう
  • ビデオオフにした参加者がふりかえりに集中していないことに気づけない

Part.3 People Antipatterns

Disillusioned Facilitator（ファシリテーターへの幻滅）
  • ファシリテーターが経験不足などにより、ふりかえしの有用性をきちんと説明できない
  • チームが真剣にふりかえりをしない（ふりかえりをお遊びだと評する）
Loudmouth（おしゃべり）
  • 特定のひとばかりが話をする
  • 話が長いので、チームメンバーは話を聞かなくなる
Silent One（静かな人）
  • 極端に静かな人がいる
Negative One（否定的な人）
  • ふりかえりに対して否定的かつ、阻害するような発言をする人がいる
Negative Team（否定的なチーム）
  • チームがネガティブな問題に対する議論ばかりにフォーカスする
Lack of Trust（信頼の欠如）
  • チームメンバー間の信頼が欠如しており、重要なことを共有できない

この章で紹介されているこのビデオがとても良い。https://www.youtube.com/watch?v=YPDmNaEG8v4

Different Cultures（異なる文化）
  • 異なる組織と協働するプロジェクトで、文化が阻害要因となってふりかえりが促進できない
Dead Silence（死の沈黙）
  • チーム全体が発言しない（特にオンラインふりかえりなどで）

結論

  • ファシリテータもふりかえり続けよう

というわけで良い本であった。みんなも読もう。

アジャイルレトロスペクティブズ　強いチームを育てる「ふりかえり」の手引き

アジャイルレトロスペクティブズ　強いチームを育てる「ふりかえり」の手引き

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

book Professional Engineer

読むのがホネな（積みがちな）技術書やビジネス書を取り上げて２週間の読書期限を課して読んでアウトプットする仮想読書会「デッドライン読書会」の第19回。今回は前回に引き続きの「モダン・ソフトウェアエンジニアリング」後半戦である。分厚いので前後編に割っていて、今回は「第Ⅲ部 プラクティスを使った小規模開発」と「第Ⅳ部 大規模で複雑な開発」および付録までを読んでいる。

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

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

通読しての総評

前半を読んだ時点での感想は以下のようなものだったのだけれども

  • 私は非常に楽しんで読んでいる。ただし万人向きではない。誰にでもオススメできる本ではない。
  • ソフトウェア開発における業界、分野的な問題点に鋭く切り込んでいることは確かだし、その点は非常に興味深い（時折差し挟まれる業界ディスが楽しい！）
  • 主題の（Essenceという名前の）方法論そのものについては本書では説明されていない。活用方法を中心に触れられている

とにかく、いろんな意味で難しい本です
モダン・ソフトウェアエンジニアリングの前半を読んだ #デッドライン読書会 - 勘と経験と読経

後半を読んで特に評価は変わらず。著者の鋭い分析、ソフトウェア開発の諸問題に対する問題提起などは非常に興味深い。
しかし本書で提唱されている手法についてはなかなか普及は難しそうな印象。使いどころが難しすぎる。

しかし、良い事がいっぱい書いてある本でもあるのだ

さて、この2週間で本書の後半を読んだわけなのだけれども、こんな内容になっている。

  • 「第Ⅲ部 プラクティスを使った小規模開発」
    • Essence手法によって再構築された「スクラム」「ユーザーストーリー」「ユースケース」「マイクロサービス」のプラクティスの適用について書かれている。
    • けっこうキツイというか、Essence化（エッセンシャル化）されたからといって各プラクティスの内容は基本的に変わらないし、わかりやすくもなっていない！
    • とはいえ、Essenceの立場で各プラクティスの課題や問題点なども論評されているので、むしろそこが興味深かった。
  • 「第Ⅳ部 大規模で複雑な開発」
    • さらに拡張して大規模開発や組織にEssence手法を適用させる方法について語られている。
    • 第Ⅳ部は楽しめた。結局のところEssenceでなくとも、何らかの手法や方法論をスケールさせるという意味では（Essence部分を差し引いても）示唆の多い内容だからだ

大きな組織にはさまざまな種類の開発がある。たとえば、新規開発、レガシーマイグレーション、ビジネスプロセスリエンジニアリング、探索的開発、コア機能の強化、モバイル開発。
他にもまだあるだろう。こうした開発すべてに有効な手法が存在するだろうか。絶対にない！ 組織が合意したプラクティスは永久に機能し続けるだろうか。絶対にない！ この業界は進化を続けており、新しい知識や技術が常に登場している。我々は静的な世界に生きているわけではない。世界は極めて動的である。

モダン・ソフトウェアエンジニアリング 第22章 さまざまな種類の開発

そして、ウォーターフォール的手法の終わり

以前に読んだ「More Effective Agile “ソフトウェアリーダー”になるための28の道標」と本書の2冊の読書によって、改めてウォーターフォールはもうアカンということへの確信が深められたのは良かったかもしれない（まあ、わかってるんだけどね）。

Essence 本の著者は、チームの作業方法を進化させるツールを提供することで、アジャイルムーブメントの価値と原則のレベルをさらに引き上げようとしている。
従来の多くの手法の取り組みとは違い、SEMAT はソフトウェアシステムを構築する上で、何が機能して、何が機能していないかを最もよく知る人、つまり、アーキテクト、アナリスト、設計者、プログラマー、テスター、ソフトウェアマネージャーにフォーカスしている。このことは、マインドセット（手法に対する考え方）に変化をもたらす。それは、従来の開発（ウォーターフォールのライフサイクル）からアジャイル開発に移行するために、ソフトウェア開発の考え方を変化させる必要があるのと同じだ。
意識すべきマインドセットの変化とは何だろうか。上記のアジャイルソフトウェア開発宣言とは違うが、そこから影響を受けたものが以下である。

  1. チームの一部が手法を選択するのではなく、チーム全体で手法を所有する。
  2. 手法の記述ではなく、手法の使用にフォーカスする。
  3. チームの手法は固定させず、継続的に進化させていく。

こうしたマインドセットは、ソフトウェアのプロには不可欠である。

モダン・ソフトウェアエンジニアリング 第23章 そして未来へ

（こういう鋭い文章が随所にあるのが、本書の一番良い事だと思う）

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

いまのところ未定なのだけれども手元の未読リストをながめるとこのあたりになるだろうか・・・

いずれも未購入。AmazonのプライムデーでKindle本セールにならないかなぁ

ビジネスチャットの文章は短く、という話

Professional Engineer

仕事のコミュニケーションが電子メールからチャットに移行しつつある今日この頃、やっぱり文章は短く書いて欲しいという話。
Notes

ビジネスチャットの文章術

  • 短く書け（目安としては150字以外）
  • メッセージ、伝えたいことを中心に
  • メンションは最小限に（伝える必要の無い人のアテンションを取らない）
  • メッセージを補足する情報やデータは外出ししてリンクしろ

これくらいに気をつけると良いと思っている。ソーシャル慣れしている人はいいんだけど、不慣れな人ほど守れていない印象。

短く書け

重要事項だからと言って長文にするな

時々「重要なことは長く書かないといけない」と勘違いしている人がいるけれども、重要度と文章の長さは関係無い。むしろ長文だと理解するのに時間がかかるので、重要なことであるほど短く書いて欲しい

長い内容はパラグラフ単位に分割して投稿しろ

パラグラフの長さは諸説あるが、150文字くらいが良いと思っている（私は「超」文章法 (中公新書)における短文の定義を目安にしている）

パラグラフ内では一つの事を伝えろ

よく、「一文一意主義がよい」と言われる。賛成だ。私は、もう少し少し進めて、「一パラグラフ一意主義」を採るのがよいと思っている。つまり、一つのパラグラムに異質な内容を盛り込まない方がよい。
とりわけ、パラグラフ内での論理の逆転は、できるだけ避けるべきだ。つまり、同一パラグラフの中で、「しかし」という接続詞が現れるのは避けるべきだ。
論理を進めるには、複数のパラグラフが必要である。それらのパラグラフは、「したがって」、「なぜなら」、「しかし」などの接続詞で結ばれる。
日本人には、「パラグラフ」という概念を意識しない人が多い。文章が読みにくくなる一つの原因は、パラグラフの構成が不適切なことだ。とりわけ、右で述べた「一意主義」が守られていないことである。
「超」文章法 (中公新書)

仕事の文章の文は、短く、短くと心がけて書くべきである。
ある人は平均50字が目標だという。本書の1行は26字だから、ほぼ2行。私も短く、短くと心がけてはいるが、とてもその域には達していない。
私の考えでは、本質的な問題は文を頭から順々に読み下してそのまま理解できるかどうかであって、すらすらと文意が通じるように書けてさえいれば、長さにはこだわらなくていい。ただ、長い文はとかく読みかえさないと判らないものになりがちだから、「短く、短く」という心理が強調されるのだと思う。
理科系の作文技術（リフロー版） (中公新書)

メッセージ、伝えたいことを中心に

報告なのか、連絡なのか、相談なのか。情報共有なのか。何を伝えたいのか。これを明確にして書くべきである。
以下のようなステップを踏んで文章を書くと良い

  1. タイトル（件名）を考える。タイトルには目的（報告、連絡など）をキーワードとして含めるのがおすすめ
  2. 本文を書く
  3. 本文が書き終わったらタイトルが適切か再確認する（不適切だったら見直す）

メンションは最小限に

電子メール中心時代の名残りで、CCに組織グループアドレスなどを入れる感覚でやたらと広範囲にメンションする人がいる。
共有されたチャンネルやチャットにポストしている時点で全員に届いているので、無駄なメンションを入れる必要は無い。
ちなみに個人的には無駄メンションを連発する人には個別に指導するようにしている（想像力の無い人に多い）。

必ず返信をして欲しい人など最小限にメンションはすべきだ。

メッセージを補足する情報やデータは外出ししてリンクしろ

本体のメッセージを補完する補足情報やデータをメッセージに頑張って埋め込む人がいるが、リンクでいいんだよ。
補足情報（たとえばレポートや詳細なデータ）は必要に応じて読者が見れれば良いし、必要でなければ見なくて良いように発信したほうが効率的。

文章力を強化するには？

今回の記事でも引用したけど、私の第一のオススメは

「超」文章法 (中公新書)

「超」文章法 (中公新書)

と
理科系の作文技術（リフロー版） (中公新書)

理科系の作文技術（リフロー版） (中公新書)

である。もしかするともっと良い本が近著で存在しているかもしれないがチェックは出来ていない点に注意。

いまさら「Project Retrospectives: A Handbook for Team Reviews」を読む

book safaribooksonline Professional Engineer

同僚と「アジャイルレトロスペクティブズ　強いチームを育てる「ふりかえり」の手引き」の話をしていたところ、同書で紹介されていた類書「Project Retrospectives: A Handbook for Team Reviews (Dorset House eBooks) (English Edition)」に気が付いた（自分が読んだ時には気づかなかったなぁ）。未翻訳だけど、そういえばO'reillyで原著が読めるので、興味の向くままに読んでみた。2001年の本である。

Project Retrospectives: A Handbook for Team Reviews (Dorset House eBooks) (English Edition)

Project Retrospectives: A Handbook for Team Reviews (Dorset House eBooks) (English Edition)

そういえば平鍋さんのブログでも紹介されていた（自分、重要さに気づくのが15年ほど遅い）。

全体的な感想

  • 本書の重要な点は、アジャイル開発の文脈と切り離されている点である。よって本書で扱う「ふりかえり」は反復的なものではない。でもみんな今必要なのは、これでしょ？
  • 著者Norman Kerth氏のふりかえりに関するゴールデンルールは忘れないようにしたい。

カースの最優先事項
今日見つけたものが何であれ、チームの全員が、その時点でわかっていたことやスキルおよび能力、利用可能なリソースを余すことなく使って、置かれた状況下でベストを尽くした、ということを疑ってはならない

  • 加えて上記ほどはピックアップされていないけど、ケーススタディ他で取り上げられているこのルールも重要だと思う「参加者の誰かを犠牲にするジョークは言ってはならない」
  • 本書で扱われる「ポストモーテム」はSREの文脈における（インシデントに対する）ポストモーテムとは異なる点には留意をしたほうが良さそう
  • 残念ながら本書のサポートサイトである www.retrospectives.com はクローズされている。というか著者のKerth氏は99年の自動車事故により引退されているようだ。残念で仕方ない
  • PMBOKベースのプロジェクトマネジメント方法論にも「終結」プロセスっていうのはあるけれど、私は本書のアプローチのほうが良いと思う。

Project Retrospectives: A Handbook for Team Reviews 各章の感想

序文

だいぶ良い出だし。惚れた。

そうら、クマくんが、二階からおりてきますよ。バタン・バタン、バタン・バタン、頭を階段にぶつけながら、クリストファー・ロビンのあとについてね。二階からおりてくるのに、クマくんは、こんなおりかたっきり知らないのです。もっとも、ときには、かんがえることもあるのです。このバタン・バタンをちょっとやめて、かんがえてみさえしたら、ほんとは、またべつなおりかたがあるんじゃないかな……とね。
A.A.ミルン「クマのプーさん」

(中略) ミルンの言葉を読んでいるとき、ミルンが説明している世界と私たち自身のクレイジーなソフトウェア開発の世界の類似点に驚嘆しています。ソフトウェア開発者として、私たちはプロジェクトごとに毎日頭をぶつけています。少し時間をとって別の方法を考えれば、もっと良い方法が見つかると思います。
Project Retrospectives: A Handbook for Team Reviews (Dorset House eBooks) (English Edition)

  • 本書を通じて読者はプロジェクトの最後に「特別な儀式：ふりかえり」を行い、立ち止まって考えることができるようになる。
  • ソフトウェア開発の分野は急速に変化しているため、作業慣行を継続的に見直す必要がある。振り返りは、ソフトウェアプロセスの改善に役立つ。
  • プロジェクトが失敗した場合、ふりかえりによってプロジェクトメンバーは失敗から学び、それを超えて進むことができる。
  • ふりかえりは、参加者の学習、成長、成熟を促進する。

第1章：ふりかえりの紹介

  • プロジェクトで反省をするということは「自然な行為」ではない。よって行為を形式化し、儀式化し、意識的に実施する必要がある。
  • ふりかえりでは心理的安全性が重要である。
  • ふりかえりを成功させるためにはファシリテーションが重要である。

第2章：ふりかえりの解剖学／ケーススタディ

本章では本書が提起するふりかえりの流れがストーリーとして共有される。かなり興味深い。

第3章：ふりかえりのエンジニアリング／選択について

  • 前回のふりかえりのテンプレートをコピーするほうが、新たにふりかえりを設計するより楽だが、過去のテンプレートは現在の状況に適合するとは限らない。
  • ふりかえりは、環境条件とチームのダイナミクスにあわせて設計すべきである。
  • 考慮すべき事項
    • 目的
    • 組織文化（健康状態）
    • ふりかえりをリードするスキルを有しているか
    • 参加者
    • 実施場所
    • 実施時期
    • 期間（効果的なふりかえりを行うのであれば3日を要する）

第4章：ふりかえりのアイデアを組織に売り込む方法（かなり意訳。原題はSelling a Retrospective）

  • 組織やプロジェクトをとりまく環境によってアプローチは異なる
  • 第1セグメント：改善が習慣化された組織
    • ふりかえりは改善施策を補完する、と説明すればよかろう
  • 第2セグメント：トラブルや失敗に対する対策を考えている組織
    • トラブルを防止する方法を発見することをコミットする
    • 対応しなければトラブルは再発する、と伝える
  • 第3セグメント：プロセスを変える気はない
    • 長期的なマーケティングを実施するしかない
    • 個別チームが第1もしくは第2セグメントするように後押しする

第5章：ふりかえりの準備

  • まず、マネージャと初回セッションを実施する
  • コミュニケーションマップを作る（マネージャにも手伝ってもらう）
    • プロジェクトの略語やチーム名称などについても確認する
  • メトリクスを収集しておく（スケジュール、コスト、品質）
  • 構成管理データを収集しておく（LOC、etc）
  • バグ管理システムのデータを収集しておく
  • 参加者を招集する
  • チェックリストを用いて設備を確認する

第6章：ふりかえりで使うエクササイズ集

  • 準備に関するエクササイズ
    • Introduction
    • I'm Too Busy
    • Define Success
    • Create Safety
  • 過去をふりかえるエクササイズ
    • Artifact Contest
    • Develop a Time Line
    • Emotions Seismograph
    • Offer Appreciations
    • Passive Analogy
    • Session Without Managers
    • Repair Damage Through Play
  • 未来について考えるエクササイズ
    • Cross-Affiniy Teams
    • Making the Magic Happen
    • Change the Paper
    • Closing the Retrospective

第7章：ポストモーテムをリードする

本書では「失敗プロジェクトに関する振り返り」を「ポストモーテム」と呼んでいる。
失敗したプロジェクトのふりかえりを実施する場合の留意点。いわゆる「失敗学」の話。

  • 通常のふりかえりと、ポストモーテム（本書においては失敗プロジェクトのふりかえり）の重要な違い
    • 同じ手順や目標を共有するが同一のものではない
    • ポストモーテムのほうが難易度も高く、慎重を要する。また期間も長い

第8章：ポストモーテムで使うエクササイズ

  • CEO/VP Interview
  • Art Gallery
  • Define Insanity
  • Make It a Mission

第9章：ふりかえりファシリテータとして熟練する

ファシリテータ能力に関する学習について、およびふりかえりファシリテータとして活用できる基本的手順のカタログ。

  • Dealing with Conflict
  • Handling Resistance to Change
  • Four Freedoms
  • Understanding Differences in Preferences
  • Ingredients of an Interaction
  • Congruent Messages

第10章：ふりかえりの後に

組織にふりかえりの文化をどう組み込むか。また「ふりかえりのレポート」をどう書くべきか。そして「ふりかえりのふりかえり」について。

アジャイルレトロスペクティブズ　強いチームを育てる「ふりかえり」の手引き

アジャイルレトロスペクティブズ　強いチームを育てる「ふりかえり」の手引き

この本も面白いんですよ。こっちは日本語で読めます

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

book Professional Engineer

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

つづく

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

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

Study

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! 著者のリーディングリストを読む

Professional Engineer

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

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

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

C4 Model

Accelerate​

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

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

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

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

Wardley Maps

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

Failure Modes and Continuous Resilience

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

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

The Principles of Product Development Flow​

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

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

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)

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 DevOps 逆転だ!

​The Unicorn Project​

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

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

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)

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

Release It!

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

読むことを推奨（Suggested Reading）

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