勘と経験と読経

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

ソフトウェアプロダクトの80%はほとんど使われないという2019年の調査は条件付きで正しそう

Professional Engineer

吉羽さんの「大規模アジャイルフレームワークの紹介 | Ryuzee.com」という記事に興味深いリサーチに関する記述があったので調べてみた。Pendoの2019年の調査はいくつかの条件を考慮すれば正しそうだ、という話。

なお、こっちの話はダメという話は以前書いた

2019年にプロダクトマネジメント関連のSaaS企業であるPendoが行った調査によると、ソフトウェアプロダクトにおいて平均的な機能の利用状況は次のようになったそうです。

  • まったく使わない: 24%
  • ほとんど使わない: 56%
  • よく使う: 8%
  • いつも使う: 12%

つまり80%の機能はほとんど、もしくは、まったく使われないということになります。 たくさんの人を集めて、たくさんの機能を作るのは、ムダである可能性が高いと言えます。
大規模アジャイルフレームワークの紹介 | Ryuzee.com

Pendoの「The 2019 Feature Adoption Report」

上記情報の元ネタはおそらくこれ。
www.pendo.io

プロダクト・レッド・オーガニゼーション　顧客と組織と成長をつなぐプロダクト主導型の構築

プロダクト・レッド・オーガニゼーション　顧客と組織と成長をつなぐプロダクト主導型の構築

Amazon

ざっくり読んだところ、以下の通りのようだ

  • Pendoが保有している3か月分の匿名化データをもとに分析している。このデータには金融/銀行、HR、教育、輸送/物流、ヘルスコア、ECなどの業種が含まれている（比率などは明らかではない）
  • 24%の機能は、まったく使わない（Never Used）
  • 56%の機能は、ほとんど使わない（Rare）
    • 「ほとんど」の定義は、全体の5%の使用率（Last 5% of Usage）
  • 12%の機能は、いつも使う（Frequent）
    • 「いつも」の定義は、全体の80%の使用率（Top 80% of Usage）
  • 08%の機能は、よく使う（Moderate）
    • 「よく」の定義は、81%～95%の使用率に収まる範囲（Next 15% of Usage）

なお、はっきりと明言されていなかったり触れられていない事としては、以下があると思う

  • データは言うまでもなくPendoのユーザとなる。基本的にはコンシューマ向けのアプリケーションに限定されるであろう。エンタープライズ向けの基幹システム等が入っているわけはない
  • おそらくだが、利用データは「Pendoを利用し始めたユーザー」に限定していると思われる
    • はっきりと読み取れなかったのだが、「Pendoを1年間利用することによって、上記比率が大きく改善される」という報告になっているので裏を返せばPendoで利用率が最適化されたプロダクトは取り除かれていると考えるのが自然だろう
  • 一定の信頼性はありそうだが、セールス向けマテリアルという点には留意する必要がある
    • なお本レポートは同社のチーフデータサイエンティストが作成とされているので、あまりおかしな操作はされていないだろう

というわけで、参考にする場合はいろいろ注意が必要だとは思うが、非常に興味深いレポートである

関連記事

agnozingdays.hatenablog.com

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

book Professional Engineer

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

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

「チームトポロジー」通読した感想

前回の感想でもこう書いたけれど

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

改めて、中堅以上のソフトウェア開発のチームリード的立場の人、PM、アーキテクト、あとソフトウェア開発組織をマネジメントする人にとっては必読な本だと思う。少なくとも私は、本書を読んだ人とチーム設計の議論がしたい。

一方で、日本の一般的なソフトウェア開発チームの文脈を考えると次のような注意事項があるだろう。

  • 本書が想定しているのは現代的なプロダクト企業、チームである。受託開発プロジェクトで本書をストレートに適用することはできない（もちろん参考にすべきアイデアはあるが）
  • ビジネスとデベロッパーが分断されているような組織構造も想定されていない（統合されている前提のように見える）。「ユーザー部」という単語を使っているチームに本書の内容はそのまま適用できない
  • つまり、一般的なお前には10年早い（死）

というわけで、本書には高い壁があるのだけれども、それを乗り越えて本書が提示する概念／パターンは重要だと思う。本書で紹介されている概念やパターン（本書で言うところのトポロジー）をベースに、自分の組織の現状を描いてみることから始めるのが良いだろう。自分はいろいろ描いてみて、いくつか発見もあった。

「チームトポロジー」後半（Part.3～）の感想

さて本書の後半は「Part.3 イノベーションと高速なデリバリーのためにチームインタラクションを進化させる」である。
このパートは3章で構成されているが、最後の章は本書全体のまとめなので、実質2章である。ここでは、

  • チーム間のインタラクションのパターン（7章 チームインタラクションモード）
  • チーム構造を進化させる戦略（8章 組織的センシングでチーム構造を進化させる）

が語られている。

定義される3つのインタラクションパターンは非常に有用な整理だと思っている（コラボレーション、XaaS、ファシリテーション）。チーム構造を分析設計する際に活用しやすく、独立している。
そしてチームの進化は、まさに逆コンウェイ戦略の要点であると思う。最初から最適なチーム構造を設計実装できることは無いという制約を踏まえて、どう発展させていくかの話は非常に参考になった。

おすすめ復習コンテンツ

というわけで本書を手に取る事をオススメする一方で、読むかどうか悩んでいる方、もしくは読んだ後に復習したい人向けのコンテンツをいろいろ発掘できたので紹介しておく。でも以下を見て読んだ気にはならないほうが良さそう。

Quick Reference Card（QRD）

本書で書かれている内容が「Quick Reference Card（QRD）」としてまとめられているのだけれども、以下のページで日本語訳されているので、ざっくりどんな本か知りたい場合は参照すると良さそう。
scrapbox.io

fukabori.fm

個人的には、読んだ後に聞くのがお勧め。

ちなみにmiholovesqさんが以下のようなこと（不正確かもしれません）を言っていたが、強く共感。

  • Team Topologiesの前提には、アジャイル的文脈の小規模チームと、DevOps（書籍「LeanとDevOpsの科学（Accelerate）」が紹介しているもの）がある
  • エンジニア的資質や上記背景を知らない人が本書を読んで、イキナリ組織設計に走るべきではない

Forkwellさんの勉強会「チームトポロジーを成功させる実践方法の探求 - Team Topologies Study」のアーカイブ

もしかしたら公開期間に制限があるかも……
www.youtube.com

上記勉強会で説明された、訳者のひとりである吉羽さんの資料はこちら
www.ryuzee.com

上記勉強会で説明された、kameikeさんの資料はこちら
timee.notion.site

というわけで、たいへんに勉強になった。さて、次はなにを読みますかね

上流工程のイバラの道：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年目前期終了） - 勘と経験と読経