勘と経験と読経

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

「The Unicorn Project」の前半がエンジニア向けのホラー映画だった(ネタバレなし)​ #デッドライン読書会

読むのがホネな(積みがちな)技術書やビジネス書を取り上げて2週間の読書期限を課して読んでアウトプットする仮想読書会「デッドライン読書会」の第20回。今回は「The DevOps 勝利をつかめ! 技術的負債を一掃せよ」の前半(10章まで)までをゴール設定して読んだのだけれども、エンジニア向けのホラー映画だったという話。

The Unicorn Projectについてざっくり整理

この本は(マーケティング的理由だと思うけれど)だいぶ邦題はよろしくない気がする。原題は「The Unicorn Project」であり、ジーン・キムのDevOps関連シリーズの一冊という理解である。

特に2作目の「The DevOps ハンドブック 理論・原則・実践のすべて」は非常に網羅的で、DevOps関連を学ぶという意味ではとても良い本という印象を持っている。

本書を完成させるまでの道のりは長かった。始まったのは2011年2月、共著者たちの間で毎週交わされていたSkypeによる通話で、当時まだ完成していなかったThe Phoenix Project(邦訳『TheDevOps逆転だ!究極の継続的デリバリー』)と対になる処方箋的なガイドブックを作ろうという夢を語ったときだ。それから5年もたって、2千時間を越える仕事の末に、本書は完成してここにある。本書を完成させるまでのプロセスは恐ろしく長いものだったが、とてもやりがいがあり、すばらしい学習のチャンスが無数にあり、当初の見込みよりもはるかに広い話題を取り上げることができた。プロジェクトを通じて、共著者たちは全員、DevOpsは純粋に重要だという信念を共有していたが、その信念は、それぞれのプロとしてのキャリアにおけるかなり早い段階でやってきた個人的な「アハ!」体験によって形成されたものである。そのアハ体験は多くの読者に共感してもらえるのではないかと思う。

類書だとレン・バスの「DevOps教科書」という本もあるのだけれども、こちらはだいぶアーキテクチャ寄りの本である。特にDevOpsの文化的な側面はほとんど触れられていない印象だった。あと「Effective DevOps ―4本柱による持続可能な組織文化の育て方」という本もある(デッドライン読書会の第1回で取り上げて読んでいる)が、こちらはDevOps実践者が読む技術エッセイ集といった感じ。

では本書はどうだろうか。たしか、Release It! 著者のナイガード先生が公開している読書リスト でも推奨図書に選ばれている。というわけで読み始めてみたのだけれども……

恐怖の展開、デスマーチが疑似体験できる

非常に読みやすいし共感もしやすい。一方で詳細を書くとネタバレになってしまうのだけれども、前半(10章)まではエンジニアとして震え上がる展開になっていて精神的な負荷がものすごく高い。先に進むのが怖い。
むしろ、こんな恐怖体験を安全に疑似的に体験できるという意味では非常に稀有な書籍なのかもしれない(前向きな感想)。

  • 主人公はキャリア25年の凄腕シニアエンジニア/アーキテクト。データベースベンダーのドライバを逆アセンブリしてバイナリーパッチを当てるくらい有能
  • 冒頭とある事件で、デスマーチプロジェクトに放り込まれる
  • で、ありとあらゆるひどい事が起こる・・・

っていうのが前半10章の大まかな流れ。いや、もう、お腹痛い。
例えばこれくらいお腹が痛い。
togetter.com

前半で気になったこと

つづく

というわけで後半に突入。ハッピーエンドであることを祈ってる。

「ゾンビスクラムサバイバルガイド」読んだ飼育係の日記

Zombie Scrum Survival Guide (English Edition)」という本を発見したので読んだ感想。良い本でした。

ゾンビスクラムサバイバルガイド!

さて、本書は著者たちの言う「ゾンビスクラム」への対策ガイドである。アメリカ人は本当にゾンビが好きだなぁ・・・
本書は架空の組織ゾンビスクラムレジスタンスが発行するサバイバルガイドという設定である。

ゾンビスクラムとは一言で言うと

「ゾンビスクラム」の世界へようこそ。これは、人々が実際のスクラムを模倣しながら、生きたり従事したりすることなく、単に動きを経験しているという悲痛な状態です。

という感じで、つまり

状態である。ヤバイ、見たことがあるぞ!

というわけで本書はイカす比喩を交えながら

  • Part.1 ゾンビスクラムの概論
  • Part.2 ステークホルダーのニーズにこたえる
  • Part.3 素早く出荷する
  • Part.4 継続的に改善する
  • Part.5 自己組織化

という形で、各章で「症状に対する分析」と「対策案」を説明するという形式で書かれた本である。
対策案が具体的なので「うまくいっていないスクラム対策」本としてけっこう使えそうな印象。

腕が落ちても文句を言わないゾンビのように、ゾンビスクラムチームは失敗したスプリント、または成功したスプリントに対しても応答を示しません。

方向感覚なしでつまずくゾンビのように、多くのゾンビスクラムチームは特にどこにも行かないように一生懸命働いています。

でも、そんなことを言ったら日本のアジャイル開発の現場は……

本書で語られるゾンビスクラムの特徴をだいぶ雑にまとめると「形骸化したスクラム」になるだろう。これは日本のSIer的文脈を考えると極めて発生しやすいとも言える。バズワードとしてのDXを追い風にゾンビスクラムが蔓延する終末的な世界がたやすく想起されるのは考えすぎだろうか。ゾンビランド

特に日本人的な気質としてテクニックに走りがちであること、加えて近年「トップダウンで変革を加速させよう」とする風潮が状況悪化に拍車をかけそうな予感を感じる。

本書で例えに使われている『「鼓動する心臓」にあたるものが欠けている』という状況は非常に的確で、核心なんだろう。外部からスクラムマスターを雇っている場合じゃないんだろうなぁ。

その他気になったこと

「Retrospectives Antipatterns」を読んだ

先日「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(死の沈黙)
  • チーム全体が発言しない(特にオンラインふりかえりなどで)

結論

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

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

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

通読しての総評

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

仕事のコミュニケーションが電子メールからチャットに移行しつつある今日この頃、やっぱり文章は短く書いて欲しいという話。
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標準は気になった人だけが読めばいい(一般の人はとりあえずアルファをそのまま使えばいい)という割り切りなのだと思うけれど、ちょっと残念に感じたのであった。

つづく

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