勘と経験と読経

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

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

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

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

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

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

短く書け

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

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

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

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

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

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

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

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

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

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

メンションは最小限に

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

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

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

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

文章力を強化するには?

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

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

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

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

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

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

そういえば平鍋さんのブログでも紹介されていた(自分、重要さに気づくのが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章:ふりかえりの後に

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

まぁ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さんが紹介していたので、いろいろ補いながら読んだという記事。

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

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

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

C4 Model

Accelerate​

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

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

Wardley Maps

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

Failure Modes and Continuous Resilience

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

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

The Principles of Product Development Flow​

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

Software Architecture in Practice

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

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

Domain-Driven Design

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

Data and Reality, 2ed

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

The Phoenix Project

以前に読んでた

​The Unicorn Project​

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

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

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

Release It!

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

読むことを推奨(Suggested Reading)

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

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

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

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

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

闘うプログラマー[新装版] ビル・ゲイツの野望を担った男達
(必読!)

Joel on Software Joel on Software
(大好きな本。このブログを書き始めたきっかけでもある)

アート・オブ・プロジェクトマネジメント ―マイクロソフトで培われた実践手法 (THEORY/IN/PRACTICE)
(これも大好きな本。PMとしての自分のバイブル)

なぜ、あなたの仕事は終わらないのか スピードは最強の武器である

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

筆者が在席していた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を聴くことについての、振り返り。

BRUTUS (ブルータス) 2009年 3/1号 [雑誌]

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

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

ラジオ/Podcastの聞き方

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

アプリ

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

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

最近の悩み

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