勘と経験と読経

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

上流工程のイバラの道：More About Software Requirements: Thorny Issues and Practical Advice 読んだ

Requirement Developments Professional Engineer book safaribooksonline

「ソフトウェア要求　第3版」といえばソフトウェア開発における要求エンジニアリングの鉄板本である。版を重ねて最新版は第3版だが、ちょっと調べ物をしていたところ、第2版には続編が存在することを知った。サブタイトルが興味深いのと、O'Reillyのサブスクで読めるようなので、読んでみたという話。

More About Software Requirements: Thorny Issues and Practical Advice (Developer Best Practices) (English Edition)

この記事の目次

全体的な感想

本書は要求開発のバイブルである「ソフトウェア要求 第2版」の補足的な内容となっている。同書の刊行後に著者が頻繁に受けた問合せの答えをまとめた、と序文には書かれている。つまりは要求開発の分野における「FAQ本」とも言えるような内容になっている。「ソフトウェア要求 第2版/第3版」は工学のテキストのような章立て・内容となっているが、本書はそれよりはもう少し砕けた表現で面白く読めた。

シリーズを時系列に並べると以下となる

  • 「ソフトウェア要求 第2版」原著 2003年 発刊
  • 「続 ソフトウェア要求」 原著 2009年 発刊　⇒ ★今回取り上げている本
  • 「ソフトウェア要求 第3版」原著 2013年 発刊

というわけで、今回取り上げる本は13年前の書籍である。が、それでも学びは多いと思った。13年前と現在の違いといえば、アジャイル開発プロセスの拡大がある。当然のことながら本書ではアジャイル開発プロセスのフォローアップは手厚くないが、エクストリームプログラミングを意識した言及はある（6章前後など）。

なお、最新の（それでも原著2013年の本だけど）「ソフトウェア要求 第3版」はアジャイル開発プロセスを意識した内容となっているので、未読であればまずこちらをオススメする。
ソフトウェア要求　第3版

なお、本ブログには以下の「ソフトウェア要求 第3版」関連の記事もあるので興味があればどうぞ

抜き書きメモ

I. On Essential Requirements Concepts

このパートは、「ソフトウェア要求 第2版」の要約である

1. Requirements Engineering Overview

「ソフトウェア要求 第2版」の抜粋のようだ。第2版または第3版を読んでいるならスキップできるだろう

2. Cosmic Truths About Software Requirements

ソフトウェア要件に関する宇宙の真実 :-p

  1. 要件を正しく理解できなければ、プロジェクトの残りの部分をどれだけうまく実行しても意味がない
  2. 要求開発は、単なる収集プロセスではなく、発見と発明のプロセスである
  3. 変化は起こる
  4. 要求では、すべてのプロジェクト関係者の利害が交錯する
  5. 顧客はソフトウェア品質の最も重要な貢献者である
  6. 顧客が常に正しいとは限らないが、顧客には常に言い分がある
  7. アナリストが提案された新規要求について尋ねるべきは「この要件はスコープに含まれるか」である
  8. 最高の要求文書であっても、人間の対話に取って代わることはできない。また、そうすべきではない
  9. 要件はあいまいかもしれないが、製品は具体的である
  10. 完璧な要件は手に入らない

II. On the Management View of Requirements

このパートは、管理者視点での要求管理に関して述べられている

3. The Business Value of Better Requirements

要求のビジネス価値に関して

  • 要求開発／要件定義に関する投資（トレーニング、プロセス改善、支援ツールの投入）の費用対効果は明確には示すことはできない
  • 一方で要求開発／要件定義の品質のプロジェクトへの影響は多大である
4. How Long Do Requirements Take?

要求開発／要件定義にどの程度の期間をかけるべきか

  • 目安としての業界ベンチマークは存在するが、プロジェクト「成功」の定義があいまいであることに留意しなければならない
  • 要求開発／要件定義の期間に影響を与える要因
    • 期間を短縮するもの
      • 高度な技術と経験を持つアナリスト
      • 適切なユーザー担当者の広範な関与
      • 過去のプロジェクトからの再利用
      • 質問に迅速に対応する顧客担当者
      • 明確で安定したビジョンとスコープ
      • アプリケーション・ドメインに精通した開発者
      • レガシーアプリケーションからのリプレース
      • 曖昧さを取り除き、抜けを発見するための効果的なインクリメンタル・ピアレビュー
    • 期間を延長するもの
      • 不慣れなプロジェクトやアプリケーションのドメイン
      • 地理的に分散したステークホルダー
      • プロジェクト参加者間の言葉の壁
      • 意思決定プロセスの弱さ
      • 大規模プロジェクト
      • ユーザー層の多さ、多様性
      • ソフトウェア開発とビジネスプロセスリエンジニアリングの同時進行
      • 外部との依存関係、不確実性
      • ハードウェアとソフトウェアのコンポーネント間の複雑な相互作用
      • 要求開発プロセスが存在しない
5. Estimating Based on Requirements

要件と見積もりについて

III. On Customer Interactions

パート3は顧客とのやりとりについて取り扱う。なお本書執筆時点で著者はアジャイル開発手法による「オンサイト顧客」というコンセプトには賛同できないとしている。1人の個人が顧客の代表として機能するとは思えないからだ

6. The Myth of the On-Site Customer

本章ではアジャイル開発手法における「オンサイト顧客」コンセプトに関する課題を改めて整理し、代替策を提示している。それはProduct Chamipnである。

7. An Inquiry, Not an Inquisition

要件の引き出しは取り調べではないという話

  • 要件の議論中の最悪の質問「なにが欲しいですか」次に悪い質問「あなたの要件は何ですか？」
  • ビジネス要件、ユーザー要件、ユースケースのヒアリングで使える良い質問リスト
  • 要求アナリストは懐疑的である必要がある。得られた回答をすべて額面通りに受け取ってはいけないのだ
8. Two Eyes Aren’t Enough

要求ドキュメントのレビューについて

  • 著者の見解では、現在最も強力な品質対策は要件ドキュメントのレビューである
  • 具体的には、ピアレビューとインスペクションをやれ
  • 良いレビューをするためには、レビュアーを教育する必要がある
  • 適切なレビュアーを選ぶ必要がある。顧客、開発者、利害関係者にレビューをさせろ
  • 誤植や文法上の誤りがあると、レビュー担当者が表面的なエラーにつまづいて本質的なレビューができなくなる恐れがあるので、熟練した編集者に校正してもらってからレビューをすることが望ましい

まじでいいことしか言っていない章だ

IV. On Use Cases

ユースケースについて。筆者は要件調査のためのユースケース手法の利用を強く支持している

9. Use Cases and Scenarios and Stories, Oh My!

ユースケース、シナリオ、ユーザーストーリーの取扱いの整理に関して

  • システムの特徴と機能に重点を置く従来の手法より、ユースケースに代表される使用法中心のアプローチは優れている
  • ユースケースがもっとも抽象度が高く、シナリオはユースケースより抽象度が低い。シナリオはユースケースを通る特定のパス・要約である。この相違点に留意する必要がある
  • XPに由来するユーザーストーリーは幅広い要件カテゴリと抽象化レベルをカバーする。ユーザーが実行したいことにうまく焦点を合わせなければ、ランダムな情報の集まりになってしまう可能性がある
  • どの手法を使おうと、ユーザの目標とビジョンに焦点を合わせる必要があることに変わりはない
10. Actors and Users

アクター／ユーザー（人間には限定されない）に関する話
どのような形であっても、要件の調査を開始するにはユーザークラスを特定して、ユーザ要件を見つけるために誰と話す必要があるかを確認することから始める

11. When Use Cases Aren’t Enough

ユースケースのメリット、デメリットの話。著者はユースケースを強く推している。この章は示唆多い！

ほとんどの新しいソフトウェア開発手法と同様に、ユースケースは少し神秘的で、誤解、誇大宣伝、そして熱狂的なファンの二極化した陣営を獲得しました。この章では、ユースケースがうまく機能する場合、うまく機能しない場合、およびユースケースが要件の問題に対する十分な解決策ではない場合の対処方法についての私の見解を共有します。

  • ユースケースは強力だが、開発者が構築するための情報はユースケースだけではカバー出来ない。1つの要件表現で開発者とユーザの要求を満たすことは難しいので、ユースケースとソフトウェア要件仕様を組み合わせる必要がある
  • DWH、バッチ、制御ソフトを含むハードウェア製品、計算量の多いアプリケーションではユースケースの価値は低くなる（この種のシステムでは、ユーザとシステムの相互作用の複雑さが主要な課題ではないため）
  • ユースケースは機能要件を置き換えるものではない（この点については業界内で様々な意見がある）
  • ユースケースは機能要件を明らかにするものである

V. On Writing Requirements

要件の文書化について

これを行うための定型的な方法はなく、経験に代わるものもありません。

12. Bridging Documents

ソフトウェア要求文書は、ユーザと開発者やテスターをつなぐ一種の「ブリッジドキュメント」と言える、という話

  • 本書では、ソフトウェア要求をユーザ中心で検討することについて話している。同様に「ソフトウェア要求文書」も利用者を中心に検討するべきである。この利用者には開発者やテスターも含まれる
  • アナリスト、開発者、その他の利害関係者が頭を合わせて、どのような要件仕様を作成するか検討すべきである
13. How Much Detail Do You Need?

どこまで要求を詳細化すべきかという話

  • 要件の詳細化レベルに影響を与える要因
    • より詳細化すべき
      • 開発を外部委託する
      • プロジェクトメンバーが地理的に分散している
      • 要件に基づいてテストが行われる
      • 詳細な見積が必要
      • 規制要件などにより要件のトレーサビリティを確保しておく必要がある
    • 詳細化が不要
      • 顧客担当者の関与度が高い
      • 開発者が高いドメイン知識を持っている
      • 先例がある
      • パッケージソリューションを採用する
14. To Duplicate or Not to Duplicate

要求文書の複数個所に、特定の要件を（繰り返し）記載すべきかという話。単一のトピック（ユースケースや機能）に関する情報がひとまとめになっていることは閲覧者にとっては有用だが、これを実現するためには情報の複製が必要である。いっぽうで複製は不整合等の問題を発生させるという話

15. Elements of Requirements Style

要求をどのように明確に明文化し記述するかという話（主に言語ルール的な意味で）。筆者は記述ルールはあまり好まないそうだ

16. The Fuzzy Line Between Requirements and Design

「要件」と「設計」の境界についての考察

  • 境界は存在しない
  • 要件段階でソリューションのアイデアをたくさん盛り込んでしまうと、それは設計上の制約に変化してしまう
  • 明確な指針は無いが、要件は「ソリューションの手がかり」程度に留めることが望ましい

VI. On the Requirements Process

要求プロセスについて

17. Defining Project Scope

プロジェクトスコープの定義と、スコープクリークの管理に関する話。スコープが明確でなければ変更が発生しやすいという話

  • 大枠ではプロダクトのビジョンと、プロジェクトのスコープを定める（書籍「ソフトウェア要求」第5章が詳しい）
  • スコープには「何が含まれないか」も記述するべきである
  • 補完する表現手法としては、コンテキスト図、ユースケース図、階層化したフィーチャーとして表現できる

忍び寄るスコープの幽霊に犠牲になったり、変化を抑制しようとして無駄にしないでください。代わりに、プロジェクトの早い段階で明確なスコープ定義を確立し、実用的な変更管理プロセスを使用して、避けられない、そして多くの場合有益な要件の進化に対処します。

18. The Line in the Sand

要件ベースライン管理の話。「砂の上に線を引く」って何のことかと思ったら、「超えてはならない一線を設ける」という慣用句表現らしい

ソフトウェア開発者は、初期の要件開発作業の後に要件を凍結してから、それらの厄介な変更に煩わされることなく設計と構築を進めたいと思うことがよくあります。これは、古典的なウォーターフォールパラダイムです。ほとんどの状況ではうまく機能しません。要件ベースラインを定義してから、そのベースラインへの変更を管理する方がはるかに現実的です。

19. The Six Blind Men and the Requirements

盲人が象を撫でるたとえ話。単一の表現だけで要求を完全に理解することはできないという話。本章の内容は、書籍「ソフトウェア要求 第3版」で言えば「第12章 1枚の絵は1024の語に値する」に記載されているものに近い

VII. On Managing Requirements

要求管理について

20. Handling Requirements for Multiple Releases

段階リリースを行うシステムの要件定義文書をどのように取り扱うか。選択肢は以下だが、一長一短がある

  • すべての要件を単一の要求文書に保存する
  • リリース別に個別の要求文書を作成する
  • 要件管理ツールで管理する
21. Business Requirements and Business Rules

ビジネス要求とビジネスルールの違いに関して

22. Measuring Requirements

要求管理におけるメトリクスについて。以下のようなものを記録すると良い。詳細抜き書きしていないけど、細かいアイデアが列挙されている

  • 要求仕様の数量（機能数とか数えられるものを）
  • 要求の品質
  • 要求ステータスの経時的な追跡
  • 変更リクエスト
  • 労力
23. Exploiting Requirements Management Tools

要件管理ツールの活用について。うーん、最近はあまりこの手のツールの話は聞かなくなったなぁ

要件管理ツールを使用すると、要件の管理が簡単になりますが、簡単ではありません。このようなツールに投資する前に、チームがそのニーズに最適な製品を選択できるように、ツールの独自の要件を定義してください。

次に読む候補：Software Development Pearls

久しぶりに、要求開発／要件定義／上流工程に関していろいろ調べる中で本書を発見して読んだのだけれども、なかなか面白い本であった。
そういえば「ソフトウェア要求 第3版」も9年前の本であるので、続編は出るのだろうかと調べてみたところ、著者のKarl Wiegersさんの新刊はちょっと違ったタイトルで出ているようだ。
Software Development Pearls: Lessons from Fifty Years of Software Experience (English Edition)

ソフトウェアに関する50年以上の経験と、ソフトウェアチームが150近くの組織で成功するのを25年以上支援してきた経験から、アプリケーションドメイン、テクノロジ、または開発ライフサイクルに関係なく、プロジェクトに適用できる60のレッスンを紹介します。非常に実用的で、100以上の実話の経験で説明されているこれらの原則、視点、および実践は、数十年にわたって有効であることが証明されており、今後何年にもわたって関連性があります。

次はこいつを読んでみようかな

フィードバックと1on1について考える 2022

Professional Engineer Kindle book Work

立場と年齢的に、後進を指導しなければならない局面が増えている。個人的には7-8年前から1on1を中心としたアプローチを使っているのだけれど、最近あらためて1on1やフィードバックについて考え直したという話。「ヤフーの１ｏｎ１―――部下を成長させるコミュニケーションの技法」と「フィードバック入門 耳の痛いことを伝えて部下と職場を立て直す技術 (PHPビジネス新書)」を読んだ感想。

本記事の目次

これまでの1on1とわたし

ヤフーの1on1を読む

2022年に入って、とある筋から「ヤフーの１ｏｎ１―――部下を成長させるコミュニケーションの技法」を紹介されたので読んでみた。読む前はナメていた。
「あー、よくある流行りの本でしょ。1on1は知ってるし、学ぶことなんかなさそう」⇒本当にすいませんでした。超いい本でした
ヤフーの１ｏｎ１―――部下を成長させるコミュニケーションの技法

と、極めて参考になる本だった。
一方で、ちょっとひっかかったのはここ。

本間　フィードバックを受けろ、と。実は1on1のポイントは、コーチングとフィードバックです。私は、会社に公にフィードバックする場がなかったから1on1を取り入れた部分もあるんです。
（中略）
本間　フィードバックは人によって微妙に定義が違うんですよね。東大の中原淳先生が『フィードバック入門』というとてもいい本を書いていて、この本を超える参考書はたぶんないと思う。その本で、中原先生は「立て直すために厳しいことを伝える」のをすなわちフィードバックだと言っていて、なるほどそうだなと思うんですね。
でも一方で、ヤフーの場合、「立て直すために厳しいことを伝える」ためのフィードバックに加えて、厳しくないことでも、見えた通りに伝えるというフィードバックもあると思っています。つまり鏡なんですね。こう見えているぞ、今、こんなふうに手が動いたぞと伝えるのも、フィードバックです。
ヤフーの１ｏｎ１―――部下を成長させるコミュニケーションの技法、「対談④　社員に成長の場を与えることは企業の役割だ」より抜粋

フィードバックとは。
というわけで、フィードバックの謎を解くべく、我々はAmazonの奥地へさらに向かったのだった（本を買った）。

フィードバック入門を読む

フィードバック入門 耳の痛いことを伝えて部下と職場を立て直す技術 (PHPビジネス新書)

結論から先に言うと、ものすごく参考になった。今後本書を何度も人に勧めるだろうと思う。サブタイトル「耳の痛いことを伝えて部下と職場を立て直す技術」だが、この本そのものが（上司としての私にとっては）耳が痛いものだった・・・。

日本ではフィードバックという言葉は、あまり一般的ではありません。多くの人は、フィードバックと聞くと、「期末の面談で、評価結果を通知されること」を思い浮かべるのではないでしょうか。たとえば、「あのさー、中原君。君、今期は、こうで、こうで、こうだったから、君の評価は、Ｃにするよ」と、いったような具合に。　しかし、本来のフィードバックは、単に結果を通知するだけでなく、そこからの立て直しをも含む概念です。本書は、このように日本の企業の現場ではあまり知られていないフィードバックについて、一から丁寧に解説しています。
フィードバック入門 耳の痛いことを伝えて部下と職場を立て直す技術 (PHPビジネス新書) はじめに、より

まさにこれ。私はフィードバックをまったくわかっていなかったのである。

本書は全編素晴らしいので切り取る事も難しいのだが、特に印象に残った点を簡単に紹介するとこんな形になる。

  • 日本においては、環境変化からマネジャーが疲弊しやすい下地が出来てしまった
  • マネジャーの若年化、プレイング化に加えて、部下の多様化（元上司、派遣社員、外国人、働かないおじさん）で難しさが各段に上がった
  • 2000年代にコーチングが流行したが、コーチング業界の策略もあり誤った導入のされ方で、「ティーチングを否定する」方向になってしまった
  • 結果として部下が育たず、マネジャーが疲弊する構図が現代の状況
  • 部下育成の理論を整理した上で、フィードバックにより耳の痛いことを部下に伝えて、立て直していく必要がある
  • 1on1とフィードバックを使い分ける。別の言い方をすると、コーチングとティーチングを行う

目から鱗が落ちまくりである・・・

参考までに著者の中原先生の紹介文もリンクしておく。おすすめ・・・

フィードバックと1on1について考える

本書を読んで、マネジメントに感じて最近感じていた「モヤモヤ」が一つ晴れた気がする。
それはつまり「わたしはティーチングの技法がまったく不十分」ということなのである。

今回、「フィードバック入門 耳の痛いことを伝えて部下と職場を立て直す技術 (PHPビジネス新書) 」を読んで、いろいろとクリアになったような気がする。実際の業務にも反映してみたいし、ティーチングについてはもう少し深掘りしてみると面白そうだと思っている。
放送大学で以下の講義があるようなので、聞いてみようかなぁ

成人の発達と学習 (放送大学大学院教材)

Building successful communities of practice 読んだ

Project Management Kindle book

Building Successful Communities of Practice: Discover How Connecting People Makes Better Organisations (English Edition)
「チームトポロジー　価値あるソフトウェアをすばやく届ける適応型組織設計」で紹介されていた「Building Successful Communities of Practice: Discover How Connecting People Makes Better Organisations (English Edition)」が気になったので調べてみたら、良さそうだったので購入して読んでみた話。CoPという概念は実はよく知らなかった。
どんな本なのかを知りたければ、以下の動画をざっと見るのが良さそう（私はこの動画を見てから購入することにした）
youtu.be

チームトポロジーではこんな感じで紹介されている。

イネイブリングチームもコミュニティオブプラクティス（CoP）も、他のチームが持つ能力を向上させ、またチームが持っている能力を広く知らしめるのに役立つ。イネイブリングチームのメンバーはフルタイムで活動する。CoPは組織内のさまざまなチームから関心を持つ個人が集まり、毎週もしくは毎月、プラクティスの共有ややり方の改善を行うことが多い。エミリー・ウェッバーは、著書『Building Successful Communitiesof Practice』のなかで、「コミュニティオブプラクティスは、社会的学習、実験的学習、バランスの取れた学習が行いやすい環境を作り、メンバーの学習を加速する」と言っている。
チームトポロジー　価値あるソフトウェアをすばやく届ける適応型組織設計 Chapter.5 4つの基本的なチープタイプ

この記事の目次

Building successful communities of practice の全体的な感想

  • 2016年に発売された94ページの薄い本。さらっと読める。Kindle Unlimitedな人は無料で読める。英語。
  • ひとことで言うと、「組織内に自律的に活動する実践コミュニティを人工的に生み出す方法について書かれた本」である。
    • 日本的なイメージだと「〇〇勉強会」みたいなものをうまく組成し、継続的に活動するようにする方法という感じ
    • でも、これはものすごく難しい事でもある。マネジメント的立場だと、この手のコミュニティはたくさん生み出したいところなのだが、実際は運まかせのチャレンジであることが多い
    • たまたま課題とリーダーシップをもつメンバーと雰囲気が核融合すると良いコミュニティが生まれるのだけれども、打率はだいぶ低い印象
    • またコミュニティを長期間維持するのも結構難しい。音楽性の違い問題などもすぐに発動する
  • というわけで実は「人工的にコミュニティを（意図的に）作る」ことに書かれた本書は、個人的にはいろいろと示唆があって刺激的だった

組織設計で頭を悩ませるマネージャーとか、コミュニティづくりに苦労している人にはおすすめのような印象

抜き書きメモ

以下は気になった箇所に関する抜き書きメモ。気になる箇所があれば原著をあたっていただきたい。

Introduction

  • "組織の構造や文化が急速に変化する時代に、人々がつながりサポートされていると感じるようにすることは、これまで以上に重要です"
  • Communities of Practice（CoP）の定義

1. Why You Need Communities of Practice in Your Organisation

ほぼ前述で紹介した動画の内容が書かれている章。

  • CoPの利点
    • 組織横断的な専門性の開発促進
    • 組織内サイロの打破
    • 知識と良いプラクティスの共有
    • 良いチームを雇用し、作り出す
    • 人々のモチベーションおよび幸せの向上

2. The Stages of a Community of Practice

3. Creating the Right Environment

  • コミュニティを成功させるために必要な環境とは何か
    • 定期的に集まる（信頼を構築するために）
    • 適切なコミュニティーリーダーシップ
    • 安全に失敗学習できる環境
    • 組織サポート（時間、ヒト、カネ）

4. The Leadership of a Community of Practice

  • コミュニティリーダーシップの役割
    • コミュニティの構築、維持、発展
    • ヒト、およびダイナミクスの管理
    • コミュニティの支援、ファシリテーション
    • 知らせる、助言する、コーチングする
    • 専門的な方向性と標準を定義する
    • 内外組織に対して代表として振舞う

5. Identifying Who is in the Community

  • CoPの始め方
  • 最初のメンバーをどう見つけるか
    • 目的、チャレンジ、学習、教える事に関する質問で適任者を確認する

6. Becoming a Community

余談だが、紹介しているアイスブレークテクニックの1つ”Top Trumps"がかなり興味深い～

7. Getting Value from Community Interactions

コミュニティ活動から価値を生み出す方法について。単なる会合をどう脱するか

  • 人脈をつくる
  • グループ学習（発表、素振り、ゲームとワークショップ、見学ツアー）
  • ディスカッションによる問題解決と良いプラクティスの構築
  • コミュニティ外への共有
  • コミュニティの改善（振返り）

このあたりは自分にとっては社内外のコミュニティで実践してきたところでもあるのだけれども、こうやって構造化、明文化してみると見通しが良くなってすばらしいと思った。定跡として使いまわしたい。うまくいったり、うまくいかなかったりするのだ……その理由がわかったかも

8. Identifying Skills Gaps to Work On

  • 前章で紹介した振返りなどで構築したバックログを参考に、コミュニティおよび個人のスキルギャップを識別して改善していく話

ドレイファスモデルを久しぶりに目にした。興味がある人はオライリーで無料ダウンロードできる、リファクタリング・ウェットウェア ―達人プログラマーの思考法と学習法の第1章を見ると良いだろう。

9. Growing the Community of Practice

コミュニティの育て方

  • メンバーシップの拡大
  • メンバーのタイプを理解する（コア、アクティブ、ノンアクティブなど）
  • コミュニティリーダーを見つけ育てる
  • リーチを拡大する

10. Self-sustaining Communities of Practice

自立した実践コミュニティ（CoP）をつくるには

参考

「Team Topologies」前半読んだ #デッドライン読書会

book Professional Engineer

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

今回のお題は話題の「チームトポロジー　価値あるソフトウェアをすばやく届ける適応型組織設計」である。
チームトポロジー　価値あるソフトウェアをすばやく届ける適応型組織設計
Kindle版を読んでいるので分厚さが実感できないが、2スプリントに分割。今回は冒頭からPart.2までを読んだ。

「チームトポロジー」の現時点での感想

非常に良い本だと思うし、本書で使われた用語はしばらく業界内で通用しそうな気がする。中堅以上の、ソフトウェア開発のチームリード的立場の人は必読ではないだろうか。

  • ソフトウェアシステム開発組織をどう設計するのかというのは実に悩ましい問題で、この組織設計を真正面に捉えた本書は、なんというか芯を喰っている手ごたえを感じた
    • もちろん、これまでも「組織パターン」のような武器はあったのだけれども、抽象度が高くて使いこなしにくいという背景もあったと思う
  • コンウェイの法則も、逆コンウェイ戦略も知っているけど、どーすりゃいいんだよーと頭を抱えている人にはとっても助かる本だろう
  • 表紙の「Spotify、Netflix、Google、Amazonから学んだチームとアーキテクチャーが同時に進化する実践的モデル」はちょっと盛りすぎのような気がする。
    • Spotify、Google（SRE）、Amazon（2-Pizza Team）はいいとしても、Netflixの話はあんまり見えてこない（参考文献には出てくるけど）

ところで、トポロジーって何だっけ

ちょっと気になったのは、なぜ「トポロジー」なのかだ。パターンじゃだめなの？
ja.wikipedia.org

  • おそらく「何らかの形（かたち。あるいは「空間」）を連続変形（伸ばしたり曲げたりすることはするが切ったり貼ったりはしないこと）しても保たれる性質」を念頭に置いているのだと思うけれど、用語の解説は本書には無いような気がする（見落としているかも）
  • 本書のベースとなった DevOps Topologies でも良い説明は見つけられなかった

MicroserviceやDDDを前提にしていない点が好感度たかい

途中まで読んで、いちばん良いと思ったのは、MicroserviceやDDDを前提としていない点である。
チームはコンテキスト境界で分けましょう、とだけ言われても、現実世界のソフトウェア開発チームは下を向いてしまう事も多いだろう。
Chapter 6 チームファーストな境界を決める、ではチームの境界を検討するための概念として節理面という概念（たぶん原著ではJoint Faceなのかなぁ）を使って説明していて、これは非常に刺激となった。チーム構成を検討する際に、チームトポロジーで紹介される基本の4つのチームタイプとあわせて考える良い観点になると考えている。

なお今回は抜き書きは省略。ちょっと調べたところ、以下の記事が（本書で書かれたことを思い出すためには）有用っぽいので、興味がある方は見ていただくのが良さそう。

おっさんエンジニアの放送大学教養学部に入学記録4（2年目後期終了）

Study

2020年4月から放送大学の教養学部「人間と文化コース」に入学して、これまで勉強してこなかった人文系の勉強を始めている。2年目後期が終わったので感想などをまとめてみた。

目次

2年目後期に履修した科目

1年目と2年目前期は「公式に2科目受講し、それとは別に1科目聴講する（これは単位は得られない）」という方針でやってきたのだけど、後期は聴講ナシで2科目の受講のみとした。これは情報処理安全確保支援士の資格試験があったり、この期間に仕事の関係で別分野の勉強をガッツリする必要があったからだ。いったん区切りがついたので、次は聴講も復帰したい。

記号論理学（'14）

記号論理学 (放送大学教材)

  • 今期の大当たり。物凄く刺激を受けた。これは全エンジニア学ぶべきと思ったくらいである。主に一階述語論理を中心に、論理学を学んでいく「情報」学科の科目である。
  • 自分が放送大学に入学した動機は「哲学について学びたい」だったのだけど、哲学について学んでいると「論理学」と「数学」の必要性に気づくというブーメランが発生していて、一方で自分の所属する「人間と文化コース」には論理学の良いコースが無かったので選んだもの。
  • 本講座を受講すると、自然言語の議論の論点整理がうまくなりそう（まだスラスラとはできない）という意味でも、引き続き深めていきたい分野である。
  • ちなみにエンジニア的な立場であると、この分野の応用として「Prolog」が存在する。よって今後はちょっとProlog学んでみようという気になっている。
  • まずは手始めにここから。

７つの言語 ７つの世界

舞台芸術の魅力（'17）

舞台芸術の魅力 (放送大学教材)

  • 1年目前期に受講した「西洋芸術の歴史と理論」の講師である青山先生の講座。テーマそのものにも強い興味があったが、この先生の説明は熱意にあふれているので、講師で選んだとも言える。
  • ギリシア悲劇に始まりオペラ、バレエ、ダンス、ミュージカル、現代演劇、能、歌舞伎、浄瑠璃などの歴史の概観と主要作品の紹介ということで盛沢山である。西洋芸術の授業でもそうだったが、時代背景を理解すると作品の理解も深まるという意味で、非常に勉強になった。そして、改めて見てみたい舞台作品が山積みとなったのだった……。
  • ただ1点残念なのは、特に海外の舞台芸術作品の紹介の一部が静止画像になっている点である。著作権、費用の問題とのことだがこれはかなり残念である。まあ、実際のところは受講後に動画を検索すればある程度見れるものも多いのだけれども。

来期（3年目前期）の予定

以下を履修する予定

あともう1科目聴講しようと思っている。数学系、もしくは心理学系を何か……

これまでの記録

  1. 若手が育たないとか言っている暇はもう無い - 勘と経験と読経
  2. コンフォートゾーン外の学びの為にエンジニアが放送大学に入学してみた - 勘と経験と読経
  3. アラフィフ理系が放送大学の教養学部に入った記録（1年目前期完了） - 勘と経験と読経
  4. おっさんエンジニアの放送大学教養学部に入学記録2（1年目後期終了） - 勘と経験と読経
  5. 教育心理学はソフトウェア開発に活用できるか（教育心理学特論を読み終えて） - 勘と経験と読経
  6. おっさんエンジニアの放送大学教養学部に入学記録3（2年目前期終了） - 勘と経験と読経

「恐れのない組織」読んだ #デッドライン読書会

book Professional Engineer

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

今年最初のお題は「恐れのない組織――「心理的安全性」が学習・イノベーション・成長をもたらす」である。
恐れのない組織――「心理的安全性」が学習・イノベーション・成長をもたらす
久しぶりに技術から少し離れた距離感の本だ。

「恐れのない組織」全体に関する感想

あまりに有名すぎる「チームが機能するとはどういうことか──「学習力」と「実行力」を高める実践アプローチ」(この本も素晴らしい)の続編的な位置づけの本である。というかチームワークについて引き続き研究している中で著者自身が心理的安全性の重要性に気づき、方向性が変わったということだそうである。

とりあえず、私はもともとは心理的安全性を研究しようと思ったわけではなく、むしろチームワークとそれが失敗とどう関係するかを研究するつもりだったとだけ言っておこう。変わりゆく世界で組織が学習できるようになるためには、人々がどのように協働するかが重要な要素になると私は考えていた。そこへ心理的安全性が──後述するとおり、直観的なひらめきとして──不意に現れ、データにあったいくつかの不可解な結果を解き明かしてくれた。
恐れのない組織――「心理的安全性」が学習・イノベーション・成長をもたらす はじめに、より

昨今、山のように「心理的安全性」の情報が溢れているが、本書がもっとも網羅的で本質的な議論を取り上げていると思う。おそらく今後も様々なビジネス書に引用されまくる気がするので、早めに読んでおくのが良さそう。必読本という感じ。

それは、仲良しグループを作るための考え方ではない、ということについて

心理的安全性の取り扱いはもともと少し難しいと思っていた。特に組織のHR部門などが推進していたりすると、「組織がぬるま湯になるのでは」「仲良しグループで高い成果は達成できるのか」といった反論も耳にする。このあたりが本書で解決すると良いと思っていたのだが、ある程度はスッキリすることができた。

  • 心理的安全性は、いつも相手の意見に賛成したり肯定されることではない。むしろ率直に、建設的に反対したりできることである
  • 心理的安全性は、気楽に過ごせる環境という意味ではない

ただ、明記はされていないが、本書は欧米のジョブ型雇用を前提に書かれているようにも思える。日本の企業はメンバーシップ型の雇用形態である。仕事に対して適した人を雇用するのではなく、雇用した人に合わせて仕事を割り当てるという特性の違いがある。その上で、仕事に対する責任の考え方が異なるという点は差っ引いて考えねばならないだろう。（日本の雇用周りの論点は、「日本社会のしくみ　雇用・教育・福祉の歴史社会学 (講談社現代新書)」がとても面白いのでお勧め）このあたりに、心理的安全性との不協和音があると考えているのだが考察はまた別の機会に。

特に興味深いとおもった箇所の覚え書き

以下は、あとで自分で思い出すためのメモでもある。

第１章 土台

心理的安全性についての誤解

それぞれの理由については後続の章で考えていくという体裁となっているが、よくある誤解が前の方の章で取り上げられているのは良いガイドだと思った。ここで紹介されている誤解は4つである。

  • 心理的安全性は、感じよく振舞うこととは関係がない
  • 心理的安全性は、性格の問題ではない
  • 心理的安全性は、信頼の別名ではない
  • 心理的安全性は、目標達成基準を下げることではない

心理的安全性とは、高い基準も納期も守る必要のない「勝手気ままな」環境のことではない。職場で「気楽に過ごす」という意味では、決してないのだ。このことは肝に銘じておいたほうがいい。

心理的安全性だけでは十分ではない

はい。その通り

第８章 次に何が起こるのか

心理的安全性に関する、よくある質問

終章後半であるが、ふたたび第１章とは別の文脈でFAQが書かれていて、学びが深い。ここでも紹介されている質問を列挙しておこう。本書を読めばそれぞれに関する著者の見解が書かれている。

  • 心理的安全性が過度になることはないか
  • 職場が心理的に安全になると、時間がかかりすぎてしまうのではないか
  • あなたは心理的に安全な職場を推奨している。それは、あらゆることについて透明であるべきだという意味か
  • 職場で心理的安全性をつくることには大賛成だが、私は上司ではない。私にできることが何かあるだろうか
  • 心理的安全性とダイバーシティ、インクルージョン、ビロンギングはどのような関係にあるのか
    • (ビロンギングとは、自分らしさを発揮しながら組織に関われる心地よさ、ということだ。知らなかったー)
  • 心理的安全性は内部告発につながるものか
  • 業績はよいが、経営者がトップダウン型の横柄な独裁者で、誰の言葉にも耳を傾けず、従業員を泣かせることもある企業はどうなのか
  • なんとかしてくれ！同僚が職場で本音を言うのでイライラする！
  • アドバイスを請う！本当の考えを職場で言うようにしたら、みんなに嫌われてしまった（もう誰にも好かれなくなってしまった）！
  • 上司が変われず変わる気もない場合、その部下である人々にアドバイスしてほしい
  • 心理的安全性を作るリーダーには、誰でもなれるのか
  • 異文化間の差についてはどうなのか。中国では心理的安全性をつくることは可能なのか。日本ではどうか。【任意の国名】ではどうか。

さて次の本は「チームトポロジー　価値あるソフトウェアをすばやく届ける適応型組織設計」？

「Docs for Developers」を読んだ

Professional Engineer book safaribooksonline

最近知った興味深いPodcast e34.fm で紹介されていたので興味を持って読んでみた本「Docs for Developers: An Engineer’s Field Guide to Technical Writing」に関するメモ。
2023/3追記：翻訳されたようだ。ユーザーの問題解決とプロダクトの成功を導く　エンジニアのためのドキュメントライティング

Docs for Developers: An Engineer’s Field Guide to Technical Writing
e34.fmwww.oreilly.com

この記事の目次

「Docs for Developers」はどんな本なのか

「プロダクトに付随する」ドキュメントの作成に関して書かれた本。架空のプロダクト、犬の鳴き声を人間の言語に翻訳するAPIサービス「Corg.ly」の話を織り交ぜて語られているので、従来イメージの設計書とかマニュアルといったイメージではなく、まさに開発者が普段目にするようなプロダクトに付随するテクニカルドキュメントの作成について書かれているといっても良いだろう。
著者達は著名なテック企業でテクニカルライティングを実際に行ってきた人々。Googleで活躍した人もいるし、驚くことにGDSのテクニカルライティング責任者だった人までいる。ものすごく豪華なメンバーなんじゃないかと思う。

全般的な感想

「Docs for Developers」とあるように、開発者向けのドキュメントを書く方法について書かれているという点が重要だろう。とはいえ非常に示唆に富んでおりいろいろと応用はできそう。読んで良かったと思うし、ドキュメンテーションに苦労しそうなプロジェクトにぶちあたった時には再び手に取りそうな予感がある。

各章に関する覚え書き

Front Matter

  • 文書作成の優先順位を下げたり、省略されたりするのは、我々の多くがそれを行う方法を知らないからだ
  • 「優れたコードはそれ自身がドキュメントである」という話はあるが、一方で十分な複雑さと規模をもつプロジェクトにとっては、人間が読める形式のドキュメントは必要だ

Chap 1. Understanding your audience

  • 「知識の呪い（The curse of knowledge）」人間は他の人が自分と同じ知識を持っていると想定しやすい。
  • 呪いを解き、効果的なドキュメントを書くには、ユーザーへの共感が必要。本章では呪いを解き、ユーザを理解する方法を示す。

基本的にはドキュメントそのものをプロダクトと見なして、ペルソナ、ストーリーマップ、ジャーニーを整理していくという戦略が示されている。

Chap 2. Planning your documentation

ソフトウェアプロダクトによくあるドキュメント類を列挙していて（網羅性がすごいと思う）それを見ながら文書化計画を立てる話。
紹介されているドキュメントの一覧が良かった。説明も素晴らしい。

  • Code comments
  • READMEs
  • Getting started documentation
  • Conceptual documentation
  • Procedural documentation
    • Tutorials
    • How-to guides
  • Reference documentation
    • API reference
    • Glossary
    • Troubleshooting documentation
    • Change documentation

Chap 3. Drafting documentation

「書くことに関して最も難しいことの1つは、空の文書に立ち向かうことです」

というわけで、とても詳しいドラフト文書の書き方である。白紙のファイルに文章の目的を描くところから、目次、本文といった手順が述べられていて、もう完璧。
あと興味深いのは、以下の真実についての立ち向かい方に関する言及である。

  • 読者は情報を探してあなたのドキュメントに来ます
  • 読者はあなたが書いたものをほとんど読みません

この対策に関する観点はちょっと新鮮だった。

Chap 4. Editing documentation

「編集とは、ドキュメントを調べて、ユーザーのニーズを満たしていることを確認するプロセスです」
「ドキュメントの編集は、コードのテストとリファクタリングのようなものであり、同様に重要です」

文書の編集に関する説明。なお本書では「執筆」と「編集」を明確に別のプロセスとして定義しており、また効率性とレビュー品質向上のために分割することを推奨している。
その上で本章では具体的なチェックリストなども示されている。

Chap 5. Integrating code samples

「コードサンプルは、効果的な開発者向けドキュメントの重要な部分です」

本書の想定がAPIを利用して活用するプロダクトであるということもあり、ドキュメントとしてのコードサンプルについて説明している章。良いコードサンプルを作成するTipsなど。

Chap 6. Adding visual content

「絵は千の言葉に値する」
単一の画像は、認知処理が少なくて済み、脳がつながりを描くのに役立ち、書かれたテキストよりもはるかに迅速に理解を得ることができます。また、画像と一緒に提示すると、情報をよりよく覚えることができます。情報を聞くと、その約10％しか思い出せません。ただし、その情報に画像が付いている場合は、65％を覚えています。

というわけで、ドキュメントにおけるビジュアル活用についての説明。通常の図だけではなく、スクリーンショット（有用とするためにはいろいろな注意点がある）やビデオコンテンツに関する留意点など、学びの深い章である。

Chap 7. Publishing documentation

作成したドキュメントの公開に関して書かれている章。基本的にはプロダクトリリースと同じような、「コンテンツ（ドキュメント）リリースプロセス」の構築が推奨されている。もちろん、これにはリリース前のテストも含まれている。

Chap 8. Gathering and integrating feedback

ドキュメントはユーザーとのコミュニケーションの主要な方法であるという観点に立ち、フィードバックの収集と統合および対応を行う方法について論じており興味深い。特に近年さまざまなベンダーのドキュメントページに組み込まれている情報収集の仕組みなどの意図がわかって、面白かった。

Chap 9. Measuring documentation quality

ズバリ、ドキュメントの品質を測ることについて書かれた章。本書ではドキュメントの品質を「機能品質」と「構造品質」に分けて評価することを推奨している。その上でさまざまなドキュメントメトリックを列挙している。

なお「SREの探求 ―様々な企業におけるサイトリライアビリティエンジニアリングの導入と実践」に良いことが書いてあるらしい。たぶん「19章 ドキュメント作成業務の改善：エンジニアリングワークフローへのドキュメンテーションの統合」が該当するみたいだけど、まだ読んでないんだよねー

Chap 10. Organizing documentation

増加するドキュメントの整理について、情報アーキテクチャなども考慮して実施することが書かれている。その結果としてサイトナビゲーションの改善やランディングページの整理などを実施するという話。

Chap 11. Maintaining and deprecating documentation

ドキュメントの保守と廃止について。例によってドキュメントもプロダクトの一部と考えるので、メンテナンスの計画を行い実施するという流れになっている。またプロダクトと同様に自動化も考慮する必要があるという話。

Back Matter

補足というか付録。

  • 専門家をいつ雇うか
  • プロジェクトの文書化に役立つリソース集

膨大なリスト・・・

おっと思ったのは、タフテのこんなビデオが紹介されていたこと（知らなかった）
www.youtube.com
本を読むのがつら過ぎて詰んでたところなので、こんどゆっくり見てみようと思う