勘と経験と読経

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

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

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

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

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

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

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

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

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

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

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

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

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

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

第1章 土台

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

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

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

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

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

はい。その通り

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

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

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

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

「Docs for Developers」を読んだ

最近知った興味深い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
本を読むのがつら過ぎて詰んでたところなので、こんどゆっくり見てみようと思う

HBRの「Strategies for Learning from Failure」を読んだ

恐れのない組織――「心理的安全性」が学習・イノベーション・成長をもたらす」で紹介されていたHBRの「Strategies for Learning from Failure」だが、オライリーのサブスクでアクセス可能だったので読んでみたという話。

失敗のリフレーミングは、失敗のタイプによる基本的な分類を理解することから始まる。詳細は私の他書に委ねるが、失敗の典型は、回避可能な失敗(絶対に、よい知らせではない)、複雑な失敗(やはり、よい知らせではない)、そして賢い失敗(楽しくはないが、高い価値をもたらすので、よい知らせと考えられるべき失敗)である。
恐れのない組織――「心理的安全性」が学習・イノベーション・成長をもたらす、第7章 実現させる

恐れのない組織――「心理的安全性」が学習・イノベーション・成長をもたらす まだ読み終わってない

論文「Strategies for Learning from Failure」 の全体像

Strategies for Learning from Failure の抜き書きメモ

The Blame Game

まず著者は、失敗と過失には境界が無いことを示す。失敗の理由のスペクトルを例示し、どこからが非難すべきものかは明確にすることはできないという。これをリーダーは理解し、その上で失敗/過失は3つのカテゴリーに分類できることを理解しなければならない。それは以下の3つである。

  • 回避可能な失敗(防止できる日常的または予測可能な操作の失敗)
  • 複雑な失敗(複雑な操作をしている人には避けがたいが、大惨事を起こさないように管理することが可能)
  • 賢い失敗(知識を生み出すための研究環境での望ましい結果)

その上で、The Blame Gameを回避し、失敗から学ぶ必要がある。

カテゴリー別の失敗への対応

回避可能な失敗
複雑な失敗
  • 発生するイベントの徹底的分析
  • 安全とリスク管理のベストプラクティスへの適用
  • 内包される小さなプロセス障害(避けられない)を悪いとみなすことは逆効果である
賢い失敗
  • 適切な規模で実験する

学習文化の構築

ここは、いわゆる心理的安全性の話なので、「恐れのない組織――「心理的安全性」が学習・イノベーション・成長をもたらす」を読んでいるなら飛ばしてもよかろう

失敗の検出

失敗を隠さず報告してもらうにはどうすればよいか。これも「恐れのない組織――「心理的安全性」が学習・イノベーション・成長をもたらす」を読んでいるなら飛ばしてもよかろう

失敗の分析

心理的な抵抗を乗り越えて向き合うためにはどうすればいいか。これも「恐れのない組織――「心理的安全性」が学習・イノベーション・成長をもたらす」のほうが詳しい。

実験の推進

体系的な実験を通じて、適切な場所で適切なタイミングで失敗を戦略的に生み出すにはどうすればいいか。「成功する失敗の設計」をどうやるか

ビッグテックのエンジニアリングカルチャーについて書かれた本

わりとビッグテック(GoogleとかAppleとか)のエンジニアリングカルチャーには興味があって色々と本を読んだり探したりしているのだけれども、いろいろ取っ散らかって来たのでいったんまとめてみる記事です。どうでもいいけどFacebookがMetaになったせいで、便利な略称が崩壊しているのはちょっと面倒ですね。GAFA(GAMA?)とかFAANG(MANGA?)とか。

Googleのエンジニアリングカルチャー

Googleのソフトウェアエンジニアリング ―持続可能なプログラミングを支える技術、文化、プロセス
最新のものとしては「Googleのソフトウェアエンジニアリング ―持続可能なプログラミングを支える技術、文化、プロセス」が一番まとまっている。原著は2020年、邦訳は2021年に出た本。
自分は原著をざっくり読んでいる。

どんな内容が書かれているかは、オライリージャパンのサイトにある目次を見ると良い。

Google内部で利用しているソフトウェアについては「SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム」(原著2016、邦訳2017)でいろいろと紹介されている。原著は英語で読める。

古いけれども、Googleにおけるテストエンジニアリングについて書かれた「テストから見えてくるグーグルのソフトウェア開発」(原著2012、邦訳2013)も面白い。ただし本書で書かれていることはすでに実践されていないという事も本書には書かれてたと記憶している。
エンジニアリング部分にはあまり触れていないけど、人材管理については「ワーク・ルールズ!―君の生き方とリーダーシップを変える」(原著2015、邦訳2015)ですこし紹介されている(360度評価のシステムなど)。

他にもいろいろあるけれども代表的なものはこんなところだろうか。
記事執筆時点では自分は未読だけれども「Building Secure and Reliable Systems: Best Practices for Designing, Implementing, and Maintaining Systems」には最新情報が書かれているかもしれないと思っている。そのうち読みたい。

Appleのエンジニアリングカルチャー

Creative Selection Apple 創造を生む力
スティーブ・ジョブズの伝記類はいっぱい出ているけれども、エンジニアリング関連の情報はあまり公開されていない印象のAppleだが「Creative Selection Apple 創造を生む力」(原著2018、邦訳2019)はけっこう踏み込んだ内容が書かれて面白かった。最初のSafariiPhone開発に関与した人が書いた本である。

他にもあるかもしれないけど、現時点では発掘できていない。

Meta(旧Facebook)のエンジニアリングカルチャー

Move Fast: How Facebook Builds Software (English Edition)
断片的にネットで紹介されることはあっても、まとまった情報の出てこないFacebookであるが、「Move Fast: How Facebook Builds Software (English Edition)」(原著2021、未訳)で社員へのインタビューのまとめとして書籍化されている。この本はモバイルシフト直前から、モバイルアプリにシフトした時期のFacebookについて語られているもので興味深い。
ちなみに同書の目次はこんな感じ。

  • Part 1: Product
    • 1. Pivot
    • 2. Portfolio Management
    • 3. Threats
    • 4. Experiment and Iterate
  • Part 2: Culture
    • 5. Something Happens
    • 6. Individuals
    • 7. Bootcamp
    • 8. Social Cohesion
    • 9. Code Wins Arguments
  • Part 3: Technology
    • 10. Cross-Platform
    • 11. Release Engineering
    • 12. Networking
    • 13. Rethinking Best Practices
    • 14. Frontend
    • 15. Facebook Moore’s Law

書籍を購入せずとも、著者のオーディオブック版が公開されているようだ(私はKindle版で読んだ)

Amazonのエンジニアリングカルチャー

さて、それではAmazonはどうだろう。私の知る限り(ベソスの伝記などを除外すると)あまり見当たらないように見える。

Amazonのエンジニアリングカルチャーが垣間見えるネット文書としてはスティーブ・イエギの「プラットフォームぶっちゃけ話」というものが有名である。こちらについては以下で紹介した。

他にはなにかあるのかなぁ。

Netflixのエンジニアリングカルチャー

お次はNetflixなんだけれども、こちらも残念ながら私の知る限りエンジニアリングカルチャーについて書かれた本などはないように見える。
カルチャーに限って言えば「NO RULES(ノー・ルールズ) 世界一「自由」な会社、NETFLIX (日本経済新聞出版)」(原著2020、邦訳2020)という本が有名なんだけれども、あんまりエンジニアリングって感じはないんだよなぁ。
NO RULES(ノー・ルールズ) 世界一「自由」な会社、NETFLIX (日本経済新聞出版)

Microsoftのエンジニアリングカルチャー

最後はMicrosoft。古代のMicrosoftのエンジニアリングカルチャーといえば「闘うプログラマー[新装版] ビル・ゲイツの野望を担った男達」(原著1994?、邦訳1994)という泣く子も黙る名著があるのだけれども、いかんせん古い。同書はWindows NT開発に関する文書である。
闘うプログラマー[新装版] ビル・ゲイツの野望を担った男達

その後のMicrosoft内部の開発の情報はネットに散らばっていて、書籍という形ではまとめられていないような気がする(見落としているかもしれないけれど)

Hit Refresh(ヒット リフレッシュ) マイクロソフト再興とテクノロジーの未来」(原著2017、邦訳2017)はたいへんに面白い本なのだけれども、これもカルチャーについては語られていてもエンジニアリングに関する言及は薄かったような気がする。
Hit Refresh(ヒット リフレッシュ) マイクロソフト再興とテクノロジーの未来


マイクロソフト 再始動する最強企業」(和書2018)は未読なんだけれども、ちょっと違いそうだなぁ。

というわけで雑に整理してみたけれども、AmazonNetflixMicrosoftについてのエンジニアリングカルチャーについて書かれた本というのは見つからなかったということになる。それぞれ特色もあって、読んだら面白いと思うんだけれどもなぁ。もし何か良い本などをご存知だったら、教えてもらいたいものである。
Googleは立派というか、やはり余裕があるのだろうか。それともアウトプットする文化なのかもしれないが、いろいろまとまっていて素晴らしい。

「リーン・エンタープライズ」後半も読んだ #デッドライン読書会

読むのがホネな(積みがちな)技術書やビジネス書を取り上げて2週間の読書期限を課して読んでアウトプットする仮想読書会「デッドライン読書会」の第35回。今回取り上げるのは前回に引き続き「リーンエンタープライズ ―イノベーションを実現する創発的な組織づくり (THE LEAN SERIES)」である。前回7章までを読んだので、今回は8章から最後までを読んだ感想やふりかえりなどを書いている。

なお本書は米O'reillyのサブスクに訳書が含まれているので、会員であればすぐに読むことができる。

「リーン・エンタープライズ」全体に関する感想

ひとことで言うと、非常に勉強になったし、刺激を受けた。

  • 現在主流のアジャイル手法「スクラム」とは別の視点として「リーン/TPS」で物事を見ることが出来るという意味で非常に有意義
  • 中大規模企業の変革手法に関する言及が興味深い。例えば以下の章はいろいろとヒントを得ることが出来た
    • ガバナンス、リスク、コンプライアンスの観点に関する考察(12章)
    • 財務管理、予算策定に関する考察(13章)
    • 競争優位性に関する考察(14章)などなど

というわけで個人的にはとってもお得だった一冊。ただし、あまり若い方にはオススメできないかもしれない。マネージャー的役割が大きい方のほうが学びは深そう。

特に興味深いと感じた箇所の紹介

以下、自分が興味を持った箇所と調べたことについてのメモである。各章何かしら発見があるのが楽しい。

第Ⅲ部 活用

8章 リーンエンジニアリングプラクティスを導入する

トランクベース開発=TPSにおける「自働化」という指摘はちょっと新鮮だった。

9章 製品開発に実験的手法を使う

インパクマッピングをベースに仮説検証を繰り返すという説明である。インパクマッピングの本は以前に読んでいたので、腹落ち感はある。
以前に読んだ自分のメモはこちら

10章 ミッションコマンドを実行する

わかっているけど実際には実現できないミッションコマンドの話である。とはいえ、うまくいっている企業の戦略は参考になる。

本当に分散化した組織は、補完性原則に従います。つまり、基本的に決定というものは、その決定によって直接影響を受ける人たちが下すべきなのです。官僚組織の上位レベルは、下位レベルでは効果的に行えないタスクのみを実行すべきです。つまり、上位レベルは下位レベルを「補完」すべきということです
リーンエンタープライズ ―イノベーションを実現する創発的な組織づくり (THE LEAN SERIES)

第Ⅳ部 変革

11章 イノベーション文化を育てる

というのは冗談としても、以下の示唆はとても重要だと思う

文化には実体がありませんが、計測することは可能です。文化の計測に関する研究は数多く存在します。あらゆる方法論はなんらかのモデルにもとづいており、モデルにはすべて制限があります。それでもなお、こうした計測は重要です。なぜなら、文化を目に見える形にして、そこに注意を向けることができるからです。
リーンエンタープライズ ―イノベーションを実現する創発的な組織づくり (THE LEAN SERIES)

12章 GRCにリーン思考を取り入れる

GRCはガバナンス、リスク、コンプライアンスの略である。特に中大規模企業にてリーンやアジャイルの概念を取り込んだ時に悩ましい要素だが、わりとバッサリと論じていて軽快。

  • 「コマンド&コントロール」のパラダイムで作成・実行される企業内のGRCマネジメントプロセスと、リーン/アジャイルの活動は相容れない
  • GRCプロセスを価値ベースに変えるほうが適切

ごもっとも……ITIL v4もその方向性なんだよなぁ……

13章 財務管理を進化させて製品イノベーションを促進する

とりあえず以下を読むべきということがわかった(こんなのばっかり)

14章 ITを競争優位にする

なぜ多くの企業はITを競争優位性に出来ないのか、という問題意識に関する章であり、それぞれのトピックがだいぶ興味深い。

15章 今いる場所から始めよう

終章。ちなみに一つの事例としてGDSが紹介されているが、現時点では状況が変わっているという話を別の本で読んだので、紹介しておこう。
www.iais.or.jp

一方で近年は、それまでの成功とは裏腹に、行政サービスのデジタル化推進の動きには陰りが見え始めており、国連が発表する電子政府ランキングでも、イギリスは長らくトップを占めてきたが、"#"#年%月のランキングでは順位を7位にまで落とし、GDS創設を支えたキーパーソンも次々と運営から離脱している。
ハンドブック「GDX:行政府における理念と実践」 より

なかなかに難しい。

最後にちょっとひっかかるような点もあったけれども、良い学びの書であった。紹介された本のうち、特にビジネス系は押さえておきたい。

2021年下半期に読んだ本まとめ

2021年7月~12月に読んだ本のまとめ。カウント対象は期間中に読み終わったものに限り、読みかけの本は対象外としている。あとコミック、漫画雑誌類もけっこう読んでいるのだけれども、これは除外。
この6カ月は51冊の本を読んだらしい。比較的、平常なペース(?)である。読んだ本の中で良かったものをピックアップしてみる。

f:id:kent4989:20211231094124p:plain
読んだ本は雑に写真を撮って記録している

文芸書のおすすめ(一般編)

invert 城塚翡翠倒叙集
前作「medium 霊媒探偵城塚翡翠 (講談社文庫)」を読んでいるという前提が必要だが、素晴らしいの一言。国内ミステリ各賞をさらった前作が未読ならまず前作を読んでのけぞり、そして、まさかの続編(?)である本作も楽しむことができる。ちなみにこの本、セールになったら買おうと寝かせておいたのだけれども、うっかり娘が前作を読んでしまい、急かされて買って読んだのだ。娘にも感謝。

文芸書のおすすめ(趣味のSF編)

宇宙【そら】へ 上 (ハヤカワ文庫SF) 宇宙【そら】へ 下 (ハヤカワ文庫SF)
昨年2020年に発売された小説である。ちなみに続編も発売されているがこちらは未読。歴史改変モノの宇宙開発小説である。もちろん小説としても大変面白いのだが、ソフトウェアエンジニアとしても非常に興味深いものになっている。なぜならコンピュータの祖先的な話も関係してくるからだ。
このあたりは、以下の記事でちょっと触れたのだけれども、極めて興味深い。

次点は「人工知能で10億ゲットする完全犯罪マニュアル (ハヤカワ文庫JA)」で、こちらはビッグデータやAIといった話題がうまく活用されたエンターテイメント作品である。こちらもオススメ。

教養書のおすすめ

暇と退屈の倫理学(新潮文庫)
この本はいろいろなところでよく紹介されていて以前から読みたいと思っていたのだが、自分にとっては最大のネックがあって、それは「電子書籍化されていない」ことだったのだ。だがしかし、なんとこの12月についに電子化されたようだ。残念ながら私は物理書籍版で読んでしまった。一言で言うと「暇と退屈」について、とことん考える哲学書である。その量実に400ページ以上。しかし得るものは多い。

この本は2021年の少し遅めの夏休み、ゆるくではあるがデジタルデトックスしながら読んだのだ。とても良い時間の使い方をした、と思っている。

ビジネス書のおすすめ

未来を実装する――テクノロジーで社会を変革する4つの原則
いろいろ読んだけど、心に残った一冊といえばこちら。しばらく本書に立ち戻ることは多そうな気がする。
なお偶然であったが、本書の前に読んでいたビジネス書が「ブリッツスケーリング」だったのだけど、本書を開いたらいきなり冒頭で否定されてて笑ってしまった。わかるー。

そのころはある程度の事業の方向性さえ合っていれば、あとは「リーン・スタートアップ(1)」のようなシリコンバレー流の迅速な仮説検証や繰り返しの方法論を適用して、スピード勝負で開発を繰り返せば、いつか「当たりくじ」を引くことができる、という希少な時代だったといえます。そしてシリコンバレー流の急速な拡大をする「ブリッツスケーリング(2)」のような方法論を適用することで、一気に世界へと拡大することもできました。
しかしこれからの10年は、スタートアップにとってまた少し異なる様相を示すと思っています。
未来を実装する――テクノロジーで社会を変革する4つの原則

技術書のおすすめ

うかる! 情報処理安全確保支援士 午後問題集
この半年は割とセキュリティ方面の勉強に力を入れていたのだけれども、参考書のような本書が実は濃度が濃くて非常に面白かった(そして役にも立った)。
本書は一見すると学習参考書のような形になっているが、知識が高圧縮されているので読んでいて非常に楽しい玄人向けの本である。そして情報処理安全確保支援士という資格試験そのものが、実際のセキュリティインシデント事例をディープに扱うということから、本書で扱う内容はかなり実践的な内容になっているように思える(時々差しはさまれるセキュリティコラムもまた楽しい)

ちなみに次点は洋書だが「Move Fast: How Facebook Builds Software (English Edition)」も良かった。Facebook(現Meta)のモバイルシフトを中心としたエンジニアリングに関する本である。昨年原著を読んだ論文集「Googleのソフトウェアエンジニアリング ―持続可能なプログラミングを支える技術、文化、プロセス」ほどディープではないが、Facebookのエンジニアリングおよび周辺プロセスがどのようになっているかが垣間見えるのが興味深い。ちなみに最近Kindleバイスやアプリの翻訳機能が高度化してきたので、今までにもまして洋書がラクに読めるようになっているのも発見だった。おすすめ。

この半期の振り返り

年末に公立図書館でけっこうな本を借りてしまって、もともと読んでいた本をあわせて、この記事を書いている時点で6冊併読中である。それぞれ面白い本なので、結果としてどれも持ち越しになってしまった。年始の休みでもう少し読み進めることができれば良いのだが。
読書の半分以上は電子書籍として読んでいるのだけれども、そういえば8年前に購入し、ずっと使っていたKindle PaperWhiteをこの秋に新調した。旧機種は8年経っても現役で、とくに不具合もなかったのだが、新しいKindle PaperWhiteの評判がすこぶる良いのと、老眼の影響で画面サイズが大きくなるという魅力に抗えなかったのだ。

これは大正解で、読書の快適性が非常に増えた。6インチから6.8インチの画面サイズ拡大も老眼には大きい。
また、アップデートが停止された旧機種には提供されていない様々な機能(特に文章の翻訳機能)が利用できるのが素晴らしい。洋書読みが捗る。
どうせまた5年以上は利用するのだ。と自分に言い訳をしながら、今日もページを捲るのである。

2021年下半期に読んだ本

  1. 平成美術ーうたかたと瓦礫(デブリ) 1989–2019
  2. アジャイルなチームをつくる ふりかえりガイドブック 始め方・ふりかえりの型・手法・マインドセット →(★紹介記事)
  3. 人工知能で10億ゲットする完全犯罪マニュアル (ハヤカワ文庫JA)
  4. 図解 人材マネジメント入門 人事の基礎をゼロからおさえておきたい人のための「理論と実践」100のツボ
  5. 天冥の標Ⅵ 宿怨 PART3
  6. Move Fast: How Facebook Builds Software (English Edition)
  7. ことばの危機 大学入試改革・教育政策を問う (集英社新書)
  8. さよなら、俺たち
  9. 民主主義のつくり方 (筑摩選書)
  10. 戦略の世界史(下) 戦争・政治・ビジネス (日経ビジネス人文庫)
  11. ミッション・スクール (中公新書)
  12. 昆虫学者の目のツケドコロ: 身近な虫を深く楽しむ
  13. ポストコロナのSF (ハヤカワ文庫 JA ニ 3-6)
  14. 空海に学ぶ仏教入門 (ちくま新書)
  15. ビジネスの未来――エコノミーにヒューマニティを取り戻す
  16. 暇と退屈の倫理学 増補新版 (homo Viator)
  17. 2030年:すべてが「加速」する世界に備えよ (NewsPicksパブリッシング)
  18. きらめく共和国
  19. Joy at Work 片づけでときめく働き方を手に入れる
  20. ゼロトラストネットワーク ―境界防御の限界を超えるためのセキュアなシステム設計 → (★紹介記事)
  21. 組織戦略の考え方 ――企業経営の健全性のために (ちくま新書)
  22. 暇なんかないわ 大切なことを考えるのに忙しくて: ル=グウィンのエッセイ
  23. ニックス
  24. invert 城塚翡翠倒叙集
  25. 宇宙【そら】へ 上 (ハヤカワ文庫SF)
  26. 情報処理教科書 情報処理安全確保支援士 2021年版
  27. うかる! 情報処理安全確保支援士 午後問題集 →(★紹介記事)
  28. 宇宙【そら】へ 下 (ハヤカワ文庫SF)
  29. ゲンロン戦記 「知の観客」をつくる (中公新書ラクレ)
  30. 実践 CSIRTプレイブック ―セキュリティ監視とインシデント対応の基本計画 →(★紹介記事)
  31. 計算する生命
  32. ブリッツスケーリング
  33. SFの書き方 「ゲンロン 大森望 SF創作講座」全記録 (早川書房)
  34. プロセスエコノミー あなたの物語が価値になる (幻冬舎単行本)
  35. こうしてあなたたちは時間戦争に負ける (新☆ハヤカワ・SF・シリーズ)
  36. 天冥の標Ⅶ 新世界ハーブC
  37. 射手座の香る夏 -Sogen SF Short Story Prize Edition- 創元SF短編賞受賞作
  38. 未来を実装する――テクノロジーで社会を変革する4つの原則
  39. 天冥の標Ⅷ ジャイアント・アーク PART1
  40. 天冥の標Ⅷ ジャイアント・アーク PART2
  41. 組織デザイン (日経文庫)
  42. プロダクトマネジメントのすべて 事業戦略・IT開発・UXデザイン・マーケティングからチーム・組織運営まで→(★紹介記事)
  43. ソロモンの指環―動物行動学入門 (ハヤカワ文庫NF)
  44. インターネットは言葉をどう変えたか デジタル時代の〈言語〉地図
  45. 永遠の森 博物館惑星
  46. デトロイト美術館の奇跡(新潮文庫)
  47. ノックス・マシン 3/4 電子オリジナル版 (角川文庫)
  48. 現代経済学の直観的方法
  49. 天冥の標Ⅸ ヒトであるヒトとないヒトと PART1 (ハヤカワ文庫JA)
  50. Weの市民革命
  51. リーンエンタープライズ ―イノベーションを実現する創発的な組織づくり (THE LEAN SERIES)

いまさらスティーブ・イエギの「プラットフォームぶっちゃけ話」を読んだ

リーンエンタープライズ ―イノベーションを実現する創発的な組織づくり (THE LEAN SERIES)」を読んでいたら、2011年に話題となったらしいスティーブ・イエギの「プラットフォームぶっちゃけ話」が紹介されていたので探して読んだという話。原文はGoogle+とともに消えているみたいだが、増田に翻訳があって助かった。

リーンエンタープライズ」での紹介

リーンエンタープライズ ―イノベーションを実現する創発的な組織づくり (THE LEAN SERIES)
この話を知ったのは「リーンエンタープライズ」なのだけど、こんな感じで紹介されている。

10.1 成長に対するAmazonのアプローチ
2001年、Amazonはある課題を抱えていました。彼らがウェブサイトで動かしているObidosと呼ばれるシステムは、大きな一枚岩の「巨大な泥だんご」であり、スケール不可能な状態にありました。阻害要因はデータベースでした。CEOジェフ・ベゾスは、この課題を機会に変えました。Amazonを他の業者も活用できるプラットフォームにしたいと考えたのです。究極の目標は、顧客ニーズに合わせることでした。それを念頭に置いて、彼はサービス指向アーキテクチャを作るように指示したメモを技術スタッフに向けて送りました。スティーブ・イエギは、以下のように要約しています†3。
[†3] スティーブ・イエギの有名な「プラットフォームぶっちゃけ話」は、テクニカルリーダー必読です。
リーンエンタープライズ ―イノベーションを実現する創発的な組織づくり (THE LEAN SERIES)

テクニカルリーダー必読といわれると、読まざるをえない(テクニカルリーダーじゃないけど)
ちなみに「大きな泥だんご」はソフトウェアの有名なアンチパターンである。久しぶりにこの単語を見たような気がする。

そういえば「ジェフ・ベゾス 果てなき野望」でも言及されていた

ジェフ・ベゾス 果てなき野望

エンジニアリング部門は、古くてつぎはぎだらけとなったインフラストラクチャーの補修をやっきになって進めていた。もともとのフレームワークは1990年代にシェル・カファンが作ったオビドスというコードできれいにまとまったものだった。アマゾン幹部、ヴァーナー・ボーガスの言葉を借りれば、成長に合わせてそれを「ガムテープとCRC5-56で補修」してきたが、そういうやり方では対応しきれないほどアマゾンが大きくなってしまったのだ。(中略)
技術インフラストラクチャーについてはサービス指向アーキテクチャーと呼ばれるシンプルで柔軟性の高いものへの移行を決定。(中略)
こうしてアマゾンは、独立した部品が互いにつながる形に技術インフラストラクチャーを作り替える作業に入った。(中略)新しいコード(アマゾンの支流が分かれる部分の地名にちなんでグルパという名前が付けられた部分もあった)への移行は3年以上の長期にわたる大変な作業で、問題が起きたらすぐ対処できるようにポケットベルを持ち歩くなど、ネットワークエンジニアたちは大変な苦労をした。
その結果、優秀な技術者が何十人も辞め、その多くはグーグルへ移籍する事態になった。そのころグーグルへ移ったひとりがスティーブ・イエギである。彼はのちに、昔の勤め先についてソーシャルネットワークのグーグルプラスに長文を投稿。友人にのみ公開の予定だったらしいが、うっかりインターネットに公開して誰でも読めるようにしてしまった。
ジェフ・ベゾス 果てなき野望

うっかりすぎるw(が、身につまされる)

読んだ感想

  • 20年前に起こったことを10年前に書かれてた記事である、ということには改めて驚いてしまう
  • リーンエンタープライズ」ではこの事例を「ミッションコマンド」つまりミッションに基づく分散意思決定に移行する例として挙げているのだけれども、本文書を読むとその難しさがよくわかる。というかこの事例を参考にするのは正しいのかちょっと悩ましい
  • 全般的にはプラットフォームの話なのだけれども、ベソスが発したと言われている6つの命令には「プラットフォームを作る」という言葉は一切出てこない

今も現在進行中のDXとかトランスフォーメーション、2025年の崖、モノリシックなシステムの再構築などの文脈においては、もっと読まれても良い文章だとは思った。

参考