勘と経験と読経

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

「Design It! ― プログラマーのためのアーキテクティング入門」の後半も読んだ #デッドライン読書会

後輩の年下エンジニアに突き上げられて老兵エンジニアが未消化の積読技術書を読み、感想をブログに書く企画の第11回。今回も「Design It! ― プログラマーのためのアーキテクティング入門」である。今回は残り(第3部)を2週間で読んだ。というわけで本書は読了である。やりきった。

Design It! ―プログラマーのためのアーキテクティング入門

Design It! ―プログラマーのためのアーキテクティング入門

  • 作者:Michael Keeling
  • 発売日: 2019/11/25
  • メディア: 単行本(ソフトカバー)

デッドライン読書会のルールは、以下参照

わたしのDesign It!の前半の感想はこちら

なお、訳書が発売されてはいるのだが、本ブログでは原著で読んでいる。https://learning.oreilly.com/ のサブスクはオライリーだけでなくPragmatic Bookshelfも対象なのだ。このテクニックについてはこちらの過去記事をどうぞ。アーキ部のkawasimaさんもおすすめしてた。

チーム活動としてのアーキテクティング

さて、第3部「アーキテクトの道具箱」は言葉通り、アーキテクトがアーキテクチャに関する情報収集、検討、共有するためのテクニックが列挙されている章である。

非機能要件のヒアリングとしてのテクニック

「14章 問題理解のアクティビティ」で紹介されているテクニックは、これまでの文脈で言えば要件定義における非機能要件ヒアリングに相当するのだろう。紹介されている手法はすでに知っているものも多い。たとえばGQMなどはIPAでいろいろと資料が公開されているので見てみるとよいだろう。

なお言うまでもなく、本書で扱われる手法は抽象度がとても高い。一方で日本においてはより詳細レベルのヒアリングテクニックとして、非機能要求グレードがポピュラーである。このあたりの使い分けはよく考えた方が良さそう。

チームでのアーキテクティングテクニック

「15章 潜在的な解決策を探るアクティビティ」はチーム活動としてアーキテクティングする方法という点でとても新鮮である。
自分の経験では、アーキテクチャはリードメンバーが集中して考えるものであって、チームメンバーはあくまでそのレビュアーである。しかし、本書で紹介されているテクニックの多くは、複数メンバーのグループワークとして検討を実施する形となっている。これはかなり興味深いのだけれども、どこかで素振りをしておかないと、いきなり実戦適用は難しそうな印象。

アジャイルアーキテクチャを共有するためのテクニック

「16章 設計をタンジブルにするアクティビティ」「17章 設計の選択肢を評価するアクティビティ」は、情報共有に関するテクニックとアドバイスになっている。
とくに16章はシンプルかつアジャイルに情報を共有するためのいろいろなアイデアが紹介されていて、すぐにでも活用できそう。本書の前半でも紹介されていた「悪名の高いアーキテクチャ文書」の対策でもあると思う。

ソフトウェアアーキテクチャの文書化は、悪名高いことで有名だ。コードを書く時間を奪うし、賞味期限が切れていることがほとんどだ。独自のバイナリファイル形式で書かれていて、手軽に編集できないことも多い。それに加え、それを読む人がほとんどいない! ソフトウェアアーキテクチャ記述(Software Architecture Description)のことを SAD と呼ぶ人がいるのも不思議ではない。
Design It! ―プログラマーのためのアーキテクティング入門 11章 アーキテクチャを記述する

Design It!の感想まとめ

現時点での(時代に即した)アーキテクチャ設計論としては、本書Design It! ―プログラマーのためのアーキテクティング入門Release It!: Design and Deploy Production-Ready Software (English Edition)が二代巨頭だと思っている。残念ながら後者は未翻訳ということもあるので、本書が日本語で読めるようになったというのはとても良いことだと思う。
でも、英語/機械翻訳でも、けっこう読めるけどね。

アフター『アフターデジタル』

先日読んだ「アフターデジタル オフラインのない時代に生き残る」がとても面白かったのだけれども、その続編「アフターデジタル2」が現在執筆中ということで、しかも原稿がライブで公開されているのがとても面白い。その他にもYoutubeで発信されている関連動画などいろいろあって興味深く観察している。欧米とは異なる進化を進んでいる中国ネット事情に関する話だが、ある種の先端、あるいはSF小説のような内容がとても刺激的だ。

アフターデジタル

そもそもどうしてこの本を手に取ったかというと、その前に読んでいた「イノベーション・スキルセット~世界が求めるBTC型人材とその手引き」の関連の対談をTakram Podcastで聞いたからだ。
podtail.com
podtail.com
(ちなみに後述するアフターデジタル2の第1章で本書が概観されているので、そこから読み始めても良さそう)

同書で語られている中で特に中国事例が非常に刺激的というか、SF的で非常に面白い本である。
テーマそのものである『すべてがオンラインになった世界』という切り口は、ある程度は理解していたつもりだった。自分もある程度は様々なサービスを使いこなしているつもりだったが、まだまだ知らない世界が多いというか、視点が広がるような知的興奮のある本だと思う。

Youtubeでの対談

この記事を書いている段階では新型コロナウィルスの問題が世界的にも日本としても大きな課題になっている。対策としてリモートワークなどの促進が身近なところでも急速に広まっている中で、「いま、中国サービス業界では」という切り口も含めたインタビューが公開されていて非常に興味深い。



アフターデジタル2

上記のインタビューでも触れられているが、現在「アフターデジタル2」という書籍が執筆中とのことだが、なんと執筆中の原稿が公開されている。
www.bebit.co.jp

さっそく読んでみたが、後半はメモがそのまま残っていたり、まさに執筆過程も含めて共有されているのがとても面白いと思う。
書かれている情報のそれぞれは、様々なWebメディアで小出しで見たことのあるものもあるが、それぞれの情報が点である。
著者の藤井さんによってこれらの点が繋がれていく様にも、強く知的好奇心が刺激される。書籍版の発行も楽しみである。

読書について 2020

自分は活字中毒であり、わりとたくさん本を読むほうなんだけど、最近立て続けに「どうやって読んでるんですか」と聞かれたので、最近の読書周りについて振り返ってみた記事。もしくは自分の読書週間の定点観測。

読書のスピードと読書術について

本を読むのは割と早い方だと思うけれど、速読法のような特殊な読書法は使っていないし、興味もない。普通に最初のページから読み始めて、最後まで読んでいる(あとがきを先に読むということもない)。読むスピードについてはちゃんと測ったことがないけれど、なんとなくの目安としては一冊4-5時間くらいだろう。

半年ごとに読んでいる本を棚おろしているので年間の読書スピードみたいなものは計算できる。試しに2019年で計算してみると

  • 1月〜6月に読んだ本…52冊
  • 7月〜12月に読んだ本…44冊
  • というわけで、96冊/年=8冊/月 のペースである。

ただし雑誌とコミックは計算に含んでいない。まぁ雑誌はマンガ週刊誌を惰性で読んでいるくらいだし、コミックも数ヶ月に1冊買うくらいなので誤差の範囲だけど。
agnozingdays.hatenablog.com

複数併読

2020/2/20のtakram radio(愛読番組のひとつ)が「読書と誤読」というテーマで面白かったのだけど、番組内で渡邉康太郎さんと荒木博行さんがどちらも10冊程度常に併読しているという話にはちょっとびっくりした。

こんな本もあるのは知っているが、未読。

自分はだいたい4冊くらいの併読が多い気がする。

  • 文芸書(小説)
  • 軽めのビジネス書
  • ソフトウェア開発関連の技術書
  • 重めのビジネス書

をその時の気分によって読み分けている。文芸書と軽めのビジネス書はすぐに読み終わって入れ替わっていくが、内容の重い本は数か月かけて読むこともある。

電子書籍か、物理書籍か?

物理書籍は書棚のスペース的な問題があるので、最近の好みとしては電子書籍(主にKindle)で本を購入することが多い。もちろんスペース的な問題だけでなく

  • スキマ時間での読書
  • 仕事などで読み返したくなった時にいつでも取り出せる
  • セールで安価に購入できる場合がある

などのメリットも大きい。

なお、並行して文芸書などについては公立図書館で借りて読むことも多く、これは当然物理書籍になる。

選書の方法

この10年ほど「読みたい未読本」が大量に積み上がってしまったので極力物理書店には立ち寄らないようにしている。売り場の書棚を見てしまうと新刊本など買いたくなってしまうからだ。では新しい本にどう出会うのかというと、基本的には「誰かがオススメしているもの」だけをチェックしている。ソーシャルネットワークやブログ、会った人に聞くなどして紹介してもらった本の中で興味のあるものをいったん非公開のAmazonの欲しいものリストに登録して、順番に読むのが最近のスタイルだ。
Kindleで大規模セールが実施されたら、欲しいものリストをまとめてチェックして値引きの多い本は買ってしまう。結果として最近は電子積読(買ったものの未読の電子書籍)はかなり沢山ある。

あと、技術書については数年前から加入している米オライリーのサブスクリクション(定額読み放題)もある。定期的に新刊をチェックして興味のあるものをピックアップしている。同サービスでは未発売のベータ版も読めるので、話題の技術書をいち早く読むことができる。
agnozingdays.hatenablog.com

読書フロー

読書前

ビジネス書や技術書の類はまず読み始める前に、目次をEvernoteに書き出してメモを取る準備をしてから読み始める事が多い。目次はネットで公開されていればコピーするが、公開されていない場合は本から書き写すことも多い。文芸書はこういった準備は何もしない。

読書中

気になる事があれば、Evernoteなどにメモを取っていく。また本の中で類書が紹介されているなら興味がある場合は、次に読む書籍リストに追加しておく。引用元が気になる場合は引用元の本を開くこともある。特に技術書については米オライリーサブスクリプション契約をしているので英語で良ければ読み放題のため、原著を併読することもある。
電子書籍の場合はマーカーをどんどん引いている(特に色とかは適当)。

読了

以前は書評などをマメにブログに書いていたのだけれども、最近は手抜きでInstagramに書影と寸評を書くだけで済ましている。もちろんそれ以上にコメントしたくなった場合などは、ブログに書評を書くこともある。

ブログとは別に、自分用の読書メモは割と時間を取って書いている。最近はEvernoteに蓄積している。ビジネス書であれば事前に作成していた目次に追記する形でメモを作っていく。電子書籍の場合はマーカーした文書をすべて吸い上げて、読書メモに付け加える。あと後で読み返しそうな図表などは写真を撮るなどしてこれもメモに追加している。
なんでこんなことをやっているのかというと、『二度と同じ本を読み返したくない』のだ。

  • 仕事で使いそうな情報
  • ブログで引用したそうな情報

があったとして、もう一度該当書籍を紐解くのが面倒というか時間の無駄だと思っているので、そういうことが無いように読書メモを書いている。ただ今どきは電子書籍であれば全文検索可能なので本当に必要かどうかは若干怪しい。ただ、この作業で読書の質も向上するような気がしているので習慣として続けている。

agnozingdays.hatenablog.com
(この記事を書いたときはGoogle Driveを利用していたが現在はEvernoteを利用している)

読書のツール

物理書籍の場合、以前は付箋をバンバン張り付けるスタイルにしていたのだけれども、付箋は意外に紙にダメージを残すので最近はブックダーツを愛用している。

電子書籍については、

  • 自宅で日中に読む場合は、Fireタブレット
  • 自宅で就寝前に読む場合は、KindlePaperwhite
  • 通勤で読む場合は、KindlePaperwhite もしくはiPhoneKindle.app
  • 仕事中に調べものをする場合は、PC上のKindleデスクトップアプリ

を使っている。

なお最近急速に老眼が進んでいて、リーディンググラスを利用することが多くなってきた・・・

togetter.com

本を読む場所

割とたくさん本を読んでいるのだが、半分以上は通勤時間に読んでいる。
それ以外では自宅(就寝前など)、あとは子供の習い事の送り迎えの合間に喫茶店で本を読むなどである。加えてiPhoneのアプリを使って、エレベーターの待ち時間や会議前の待ち時間なども読書時間に充てている。読みたい本がたくさんあるので、スキマ時間を極力うまく使いたいのだ。

読書について

別にたくさん本を読む人が偉いとも思っていないし、自分の読書は趣味と実益を兼ねたお楽しみである。
ただ、学びという観点で言えば読書のコスパは非常に高いと考えている。このあたりは以前に書いている。
agnozingdays.hatenablog.com

「Design It! ― プログラマーのためのアーキテクティング入門」の前半を読んだ #デッドライン読書会

後輩エンジニアに追い立てられて、老兵エンジニアがリーディンググラス片手に未消化の積読技術書をデッドラインを決めて読んで感想をブログに書く企画(ざっくり)の第10回。今回は「Design It! ― プログラマーのためのアーキテクティング入門」である。2週間で本書の前半部分(最初〜226ページ、第1部と第2部)を読む約束でがんばった。

Design It! ―プログラマーのためのアーキテクティング入門

Design It! ―プログラマーのためのアーキテクティング入門

デッドライン読書会のルールは、以下参照

なお、訳書が発売されてはいるのだが、本ブログでは原著で読んでいる。https://learning.oreilly.com/ に加入しているので原著であれば購入せずに読めるからである。このテクニックについてはこちらの過去記事をどうぞ。

リーン/アジャイル時代のソフトウェアアーキテクチャ

個人的なアーキテクティングのバイブルは長らく

だったのだけれども、本書では従来のアーキテクティングアプローチをバッサリと切っているあたりが楽しい。

ソフトウェアアーキテクチャの文書化は、悪名高いことで有名だ。コードを書く時間を奪うし、賞味期限が切れていることがほとんどだ。独自のバイナリファイル形式で書かれていて、手軽に編集できないことも多い。それに加え、それを読む人がほとんどいない! ソフトウェアアーキテクチャ記述(Software Architecture Description)のことを SAD と呼ぶ人がいるのも不思議ではない。
Design It! ―プログラマーのためのアーキテクティング入門 11 章 アーキテクチャを記述する

というわけで本書の基本的なコンセプトとしては、

  • ライトウェイトかつスケッチに近い Architecturally Significant Requirement:ASR Workbook を中心に
  • BDUF(Big Design Up Front)ではなく、ENUF(ENough design Up Front)でやる

となっていて、これはさっそく試してみたくなってしまう。

実際問題、モノシリックで巨大なエンタープライズシステムは世の中から減ってきているので、以前に書いたEAともども、ファットなADは絶滅していくのかしら・・・というのがここまで読んだ感想である。

問題はどう実行できるかだ

さて前半を読んで、ASR Workbookを中心にしたアプローチはわかった。というわけで問題なのは「どうやるか」である。
本書の後半には様々なプラクティスやアイデアが散らばっているので、これを読んでいろいろとシミュレーションしてみたいところ。その上で、おそらく本書に書かれたことを学ぶためにもっとも良いのは「やってみる」なんだろうなぁ、と思う。実際問題、十分にプロセスは軽量なので、少しの時間さえ作れば素振りはできそう。
さて、どうしたものか・・・

エンジニアリングマネージャ/PMスキルの自己採点

エンジニアリングマネージャ/プロダクトマネージャのための知識体系と読書ガイド - Qiitaの記事が興味深かったので、自分が同記事で紹介されている書籍のどこまでを読んだのか、そして未読の書籍を今後読むのかどうかについてチェックしながら棚卸ししてみた。

弱いEMから強いEMにかけての、知識体系をまとめるとこのようになります。自分自身のキャリアや足りない部分などを見つめ直して、インプットするのに使えるとよいかもしれません。

自己採点結果のまとめ

改めて過去の自分の読んだ本、読んでない本を見ると以下のような傾向があるようだ。

  • ピープルマネジメントの観点では、「1on1/メンタリング」の領域は弱く、「チーミング」に偏っている。実際問題メンタリングは課題認識あるので、優先度を上げて読まないといけない。
  • テクノロジマネジメントの観点では、「ソフトウェア品質」についてはそれなりにわかっていたつもりだけれども、ちょっと弱い。
  • プロジェクトマネジメントの観点では、「CCPM」と「CMMI」観点が弱い。
  • プロダクトマネジメントの観点は(SIer所属なので)全般的に弱い。とはいえ、これは優先度は下げて良さそう。

うーん、厳しいのう。。。

自己採点結果(兼、自分のための未読リスト)

重要なことですが、全てを読む必要はありません
必要に応じて、段階に応じて「このような世界があるんだなー」と認識しておき、行き詰まりを感じたときに深堀りをしてみるといいかもしれません。

いやぁ、チェックしているだけで死んだ。。。既読26/未読69かな。

なお備考にORと記載しているのは、米Oreillyのサブスクで読める本のリンクである。訳書を買わずに原著で読みたい(コスト削減のためにも)。

カテゴリー サブカテゴリー 書籍名 書影 状況 備考
ピープル 1on1/メンタリング コーチングのすべて コーチングのすべて――その成り立ち・流派・理論から実践の指針まで 未読
ピープル 1on1/メンタリング 認知行動療法による対人援助スキルアップ・マニュアル 認知行動療法による対人援助スキルアップ・マニュアル 未読
ピープル 1on1/メンタリング マイクロカウンセリング技法 マイクロカウンセリング技法―事例場面から学ぶ 未読
ピープル 1on1/メンタリング 傾聴の心理学 傾聴の心理学: PCAをまなぶ:カウンセリング/フォーカシング/エンカウンター・グループ 未読
ピープル 1on1/メンタリング プロカウンセラーの聞く技術 プロカウンセラーの聞く技術 未読 興味アリ
ピープル 1on1/メンタリング フレーミング心理的枠組の変換をもたらすもの リフレーミング―心理的枠組の変換をもたらすもの 未読
ピープル 1on1/メンタリング 短期間で組織が変わる 行動科学マネジメント 短期間で組織が変わる 行動科学マネジメント 未読 興味アリ
ピープル ファシリテーション ザ・ファシリテーター ザ・ファシリテーター 既読 お勧め
ピープル ファシリテーション 問題解決ファシリテーター 問題解決ファシリテーター―「ファシリテーション能力」養成講座 未読
ピープル ファシリテーション ファシリテーターの道具箱 ファシリテーターの道具箱 未読
ピープル ファシリテーション プロジェクトを変える12の知恵― ケンブリッジファシリテーション プロジェクトを変える12の知恵― ケンブリッジ式 ファシリテーション ― 未読
ピープル チーミング なぜ弱さを見せあえる組織が強いのか なぜ弱さを見せあえる組織が強いのか ― すべての人が自己変革に取り組む「発達指向型組織」をつくる 未読
ピープル チーミング チームが機能するとはどういうことか チームが機能するとはどういうことか ― 「学習力」と「実行力」を高める実践アプローチ 既読 お勧め
ピープル チーミング はじめてのリーダーのための 実践! フィードバック 耳の痛いことを伝えて部下と職場を立て直す「全技術」 はじめてのリーダーのための 実践! フィードバック 耳の痛いことを伝えて部下と職場を立て直す「全技術」 未読 興味アリ
ピープル チーミング Measure What Matters 伝説のベンチャー投資家がGoogleに教えた成功手法 OKR Measure What Matters(メジャー・ホワット・マターズ) 伝説のベンチャー投資家がGoogleに教えた成功手法 OKR 未読
ピープル チーミング THE TEAM 5つの法則 THE TEAM 5つの法則 (NewsPicks Book) 積読
ピープル チーミング THE CULTURE CODE THE CULTURE CODE 最強チームをつくる方法 未読 興味アリ
ピープル チーミング 具体と抽象 具体と抽象 未読
テクノロジー ソフトウェア品質 ソフトウェア品質知識体系ガイド -SQuBOK Guide-(第2版) ソフトウェア品質知識体系ガイド -SQuBOK Guide-(第2版) 積読
テクノロジー ソフトウェア品質 データ指向のソフトウェア品質マネジメント―メトリクス分析による「事実にもとづく管理」の実践 データ指向のソフトウェア品質マネジメント―メトリクス分析による「事実にもとづく管理」の実践 未読
テクノロジー ソフトウェア品質 初めて学ぶソフトウエアメトリクス~プロジェクト見積もりのためのデータの導き方 初めて学ぶソフトウエアメトリクス~プロジェクト見積もりのためのデータの導き方 未読 OR
テクノロジー ソフトウェア品質 ソフトウェア品質の経済的側面 ソフトウェア品質の経済的側面 未読 OR
テクノロジー XP/DevOps テスト駆動開発 テスト駆動開発 未読 OR
テクノロジー XP/DevOps モブプログラミング・ベストプラクティス ソフトウェアの品質と生産性をチームで高める モブプログラミング・ベストプラクティス ソフトウェアの品質と生産性をチームで高める 未読 OR
テクノロジー XP/DevOps The DevOps ハンドブック 理論・原則・実践のすべて The DevOps ハンドブック 理論・原則・実践のすべて 既読 お勧め
テクノロジー XP/DevOps LeanとDevOpsの科学[Accelerate] テクノロジーの戦略的活用が組織変革を加速する LeanとDevOpsの科学[Accelerate] テクノロジーの戦略的活用が組織変革を加速する impress top gearシリーズ 既読 お勧め
テクノロジー XP/DevOps レガシーコードからの脱却 ―ソフトウェアの寿命を延ばし価値を高める9つのプラクティス レガシーコードからの脱却 ―ソフトウェアの寿命を延ばし価値を高める9つのプラクティス 既読 お勧め
テクノロジー SRE/モニタリング SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム 既読 お勧め
テクノロジー SRE/モニタリング 入門 監視 ―モダンなモニタリングのためのデザインパターン 入門 監視 ―モダンなモニタリングのためのデザインパターン 既読 お勧め
テクノロジー SRE/モニタリング Infrastructure as Code ―クラウドにおけるサーバ管理の原則とプラクティス Infrastructure as Code ―クラウドにおけるサーバ管理の原則とプラクティス 未読 OR
テクノロジー SRE/モニタリング 詳解 システム・パフォーマンス 詳解 システム・パフォーマンス 既読 お勧め
テクノロジー アーキテクチャ ソフトウェアシステムアーキテクチャ構築の原理 第2版 ソフトウェアシステムアーキテクチャ構築の原理 第2版 既読 お勧め
テクノロジー アーキテクチャ Clean Architecture 達人に学ぶソフトウェアの構造と設計 Clean Architecture 達人に学ぶソフトウェアの構造と設計 既読 お勧め
テクノロジー アーキテクチャ エンタープライズアプリケーションアーキテクチャパターン エンタープライズアプリケーションアーキテクチャパターン 既読 お勧め
テクノロジー アーキテクチャ アプリケーションアーキテクチャ設計パターン アプリケーションアーキテクチャ設計パターン 未読 興味アリ
テクノロジー アーキテクチャ .NETのエンタープライズアプリケーションアーキテクチャ第2版 .NETを例にしたアプリケーション設計原則 .NETのエンタープライズアプリケーションアーキテクチャ第2版 .NETを例にしたアプリケーション設計原則 未読
テクノロジー アーキテクチャ 進化的アーキテクチャ ―絶え間ない変化を支える 進化的アーキテクチャ ―絶え間ない変化を支える 未読 興味アリ
テクノロジー アーキテクチャ Design It! ―プログラマーのためのアーキテクティング入門 Design It! ―プログラマーのためのアーキテクティング入門 積読
テクノロジー アーキテクチャ 実践ドメイン駆動設計 (Object Oriented SELECTION) 実践ドメイン駆動設計 既読
テクノロジー アーキテクチャ モジュール化―新しい産業アーキテクチャの本質 (経済産業研究所・経済政策レビュー) モジュール化―新しい産業アーキテクチャの本質 (経済産業研究所・経済政策レビュー) 未読 興味アリ
プロジェクト PMBOK 図解入門よくわかる 最新PMBOK第6版の基本 図解入門 よくわかる 最新 PMBOK第6版の基本 未読
プロジェクト PMBOK 図解 これ以上やさしく書けない プロジェクトマネジメントのトリセツ 図解 これ以上やさしく書けない プロジェクトマネジメントのトリセツ (Panda Publishing) 未読
プロジェクト PMBOK プロジェクトマネジメントの基本 この1冊ですべてわかる プロジェクトマネジメントの基本 この1冊ですべてわかる 未読
プロジェクト 不確実性分析・クリティカルパス 不確実性分析 《新装版》不確実性分析 実践講座 未読 興味アリ
プロジェクト 不確実性分析・クリティカルパス 計画の科学 計画の科学 どこでも使えるPERT・CPM (ブルーバックス) 既読 古典
プロジェクト 不確実性分析・クリティカルパス ピープルウェア ピープルウエア 第3版 既読 古典
プロジェクト 不確実性分析・クリティカルパス 熊とワルツを リスクを愉しむプロジェクト管理 熊とワルツを リスクを愉しむプロジェクト管理 既読 お勧め
プロジェクト CCPM クリティカルチェーン―なぜ、プロジェクトは予定どおりに進まないのか? クリティカルチェーン 既読 古典
プロジェクト CCPM 進む! 助け合える! WA(和)のプロジェクトマネジメント―――プロマネとメンバーのためのCCPM理論 進む!助け合える!WA(和)のプロジェクトマネジメント――プロマネとメンバーのためのCCPM理論 未読 興味アリ
プロジェクト CCPM アジャイルCCPM: プロジェクトのマネジメントを少し変えて組織全体のパフォーマンスを大きくのばす アジャイルCCPM: プロジェクトのマネジメントを少し変えて組織全体のパフォーマンスを大きくのばす 未読 興味アリ
プロジェクト CCPM 品質と生産性を重視したソフトウェア開発プロジェクト技法―見積り・設計・テストの効果的な構造化 品質と生産性を重視したソフトウェア開発プロジェクト技法―見積り・設計・テストの効果的な構造化 未読 興味アリ
プロジェクト 見積もり アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法 アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~ 既読 お勧め
プロジェクト 見積もり ソフトウェア見積り ソフトウェア見積り 人月の暗黙知を解き明かす 既読 聖書
プロジェクト 見積もり ソフトウェア見積りのすべて 第2版 ―現実に即した規模・品質・工数・工期の予測 ソフトウェア見積りのすべて 第2版 ―現実に即した規模・品質・工数・工期の予測― 未読 OR
プロジェクト アジャイル/リーン アジャイルサムライ アジャイルサムライ――達人開発者への道 既読 お勧め
プロジェクト アジャイル/リーン 大規模スクラム Large-Scale Scrum(LeSS) 大規模スクラム Large-Scale Scrum(LeSS) 未読 OR
プロジェクト アジャイル/リーン エッセンシャル スクラム: アジャイル開発に関わるすべての人のための完全攻略ガイド (Object Oriented Selection) エッセンシャル スクラム 未読
プロジェクト アジャイル/リーン アジャイル開発とスクラム~顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント アジャイル開発とスクラム 顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント 既読 お勧め
プロジェクト アジャイル/リーン リーン開発の本質 リーン開発の本質 未読 OR
プロジェクト アジャイル/リーン アジャイルイントロダクション:Agile開発の光と影 アジャイルイントロダクション:Agile開発の光と影 未読
プロジェクト アジャイル/リーン 知的創造企業 知識創造企業 未読
プロジェクト CMMI 図解 はじめての「開発のためのCMMI」とプロセス改善 第2版 図解 はじめての「開発のためのCMMI」とプロセス改善 第2版 未読
プロジェクト CMMI PSPガイドブック ソフトウェアエンジニア自己改善 PSPガイドブック ソフトウェアエンジニア自己改善 未読 OR
プロダクト ビジョンマネジメント/ビジネス分析 リーン・スタートアップ リーン・スタートアップ ムダのない起業プロセスでイノベーションを生みだす 既読 お勧め
プロダクト ビジョンマネジメント/ビジネス分析 起業の科学 スタートアップサイエンス 起業の科学 未読
プロダクト ビジョンマネジメント/ビジネス分析 ビジネスモデルの教科書: 経営戦略を見る目と考える力を養う ビジネスモデルの教科書―経営戦略を見る目と考える力を養う 未読
プロダクト ビジョンマネジメント/ビジネス分析 ビジネスモデル for Teams 組織のためのビジネスモデル設計書 ビジネスモデル for Teams 組織のためのビジネスモデル設計書 未読
プロダクト ビジョンマネジメント/ビジネス分析 バリュー・プロポジション・デザイン 顧客が欲しがる製品やサービスを創る バリュー・プロポジション・デザイン  顧客が欲しがる製品やサービスを創る 未読
プロダクト ビジョンマネジメント/ビジネス分析 INSPIRED 熱狂させる製品を生み出すプロダクトマネジメント INSPIRED 熱狂させる製品を生み出すプロダクトマネジメント 積読 OR
プロダクト ソフトウェア要求/仮説検証 【改訂第2版】[入門+実践]要求を仕様化する技術・表現する技術 ~仕様が書けていますか? 【改訂第2版】[入門+実践]要求を仕様化する技術・表現する技術 ~仕様が書けていますか? 未読
プロダクト ソフトウェア要求/仮説検証 ソフトウェア要求と仕様(電子版): 実践,原理,偏見の辞典 ソフトウェア要求と仕様(電子版): 実践,原理,偏見の辞典 未読 興味アリ
プロダクト ソフトウェア要求/仮説検証 要求工学実践ガイド: REBOKシリーズ2 要求工学実践ガイド: REBOKシリーズ2 未読
プロダクト ソフトウェア要求/仮説検証 アジャイル開発の本質とスケールアップ 変化に強い大規模開発を成功させる14のベストプラクティス アジャイル開発の本質とスケールアップ 変化に強い大規模開発を成功させる14のベストプラクティス (IT Architects’ Archive) 既読 お勧め
プロダクト ソフトウェア要求/仮説検証 アジャイルソフトウェア要求 アジャイルソフトウェア要求 既読 お勧め
プロダクト ソフトウェア要求/仮説検証 正しいものを正しくつくる プロダクトをつくるとはどういうことなのか、あるいはアジャイルのその先について 正しいものを正しくつくる プロダクトをつくるとはどういうことなのか、あるいはアジャイルのその先について 既読 お勧め
プロダクト ソフトウェア要求/仮説検証 モデルベース要件定義テクニック モデルベース要件定義テクニック 未読
プロダクト プロダクトマーケティング/プロダクトセールス THE MODEL(MarkeZine BOOKS) THE MODEL(MarkeZine BOOKS) マーケティング・インサイドセールス・営業・カスタマーサクセスの共業プロセス 未読
プロダクト プロダクトマーケティング/プロダクトセールス カスタマーサクセス――サブスクリプション時代に求められる「顧客の成功」10の原則 カスタマーサクセス――サブスクリプション時代に求められる「顧客の成功」10の原則 未読 OR
プロダクト プロダクトマーケティング/プロダクトセールス サブスクリプション――「顧客の成功」が収益を生む新時代のビジネスモデル サブスクリプション――「顧客の成功」が収益を生む新時代のビジネスモデル 未読
プロダクト プロダクトマーケティング/プロダクトセールス [改訂4版]グロービスMBAマーケティング [改訂4版]グロービスMBAマーケティング 未読
プロダクト プロダクトマーケティング/プロダクトセールス マーケティングリサーチの論理と技法 マーケティングリサーチの論理と技法 未読
プロダクト プロダクトマーケティング/プロダクトセールス 最新マーケティングの教科書2019 最新マーケティングの教科書2019 未読
プロダクト プロダクトマーケティング/プロダクトセールス プロダクトマネジャーの教科書 プロダクトマネジャーの教科書 未読
プロダクト UXデザイン/ユーザビリティ ユーザーエクスペリエンスの測定 : UXメトリクスの理論と実践 ユーザーエクスペリエンスの測定 (情報デザインシリーズ) 未読 OR
プロダクト UXデザイン/ユーザビリティ ユーザビリティエンジニアリング : ユーザエクスペリエンスのための調査、設計、評価手法 ユーザビリティエンジニアリング(第2版) ―ユーザエクスペリエンスのための調査、設計、評価手法― 未読
プロダクト UXデザイン/ユーザビリティ デジタルプロダクトのためのデザインシステム実践ガイド Design Systems ―デジタルプロダクトのためのデザインシステム実践ガイド 未読
プロダクト UXデザイン/ユーザビリティ エンジニアのためのデザイン思考入門 エンジニアのためのデザイン思考入門 未読
プロダクト UXデザイン/ユーザビリティ ユーザーインタビューをはじめよう ユーザーインタビューをはじめよう 未読
プロダクト UXデザイン/ユーザビリティ デザイン組織のつくりかた デザイン組織のつくりかた デザイン思考を駆動させるインハウスチームの構築&運用ガイド 未読 OR
プロダクト UXデザイン/ユーザビリティ デザインリーダーシップ デザインリーダーシップ デザインリーダーはいかにして組織を構築し、成功に導くのか? 未読 OR
プロダクト UXデザイン/ユーザビリティ ユーザーストーリーマッピング ユーザーストーリーマッピング 既読
プロダクト UXデザイン/ユーザビリティ ノンデザイナーズ・デザインブック [フルカラー新装増補版] ノンデザイナーズ・デザインブック [第4版](リフロー版) 既読 OR
プロダクト UXデザイン/ユーザビリティ デザイニング・インターフェース 第2版 ―パターンによる実践的インタラクションデザイン デザイニング・インターフェース 第2版 ―パターンによる実践的インタラクションデザイン 未読 OR
プロダクト UXデザイン/ユーザビリティ マイクロインタラクション ―UI/UXデザインの神が宿る細部 マイクロインタラクション ―UI/UXデザインの神が宿る細部 未読 OR
プロダクト UXデザイン/ユーザビリティ Running Lean Running Lean ―実践リーンスタートアップ (THE LEAN SERIES) 未読 OR
プロダクト UXデザイン/ユーザビリティ 一人から始めるユーザーエクスペリエンス 一人から始めるユーザーエクスペリエンス 未読

いやぁ、とてもじゃないけど読みきれないでしょ。

「IT業界の病理学」読了。興味深いエッセイ集 #デッドライン読書会

後輩エンジニアに追い立てられて、老害エンジニアがリーディンググラス片手に未消化の積読技術書をデッドラインを決めて読んで感想をブログに書く企画(ざっくり)の第9回。今回は昨年末に発刊された「IT業界の病理学」である。

今回はKindle版で購入。この本はKindleの連続スクロール(無限に縦に長いWebサイトのように読める)対応しているのが最高だった。米オライリーSafari(基本的に書籍がWebページとして表示されるので縦スクロール)に慣れているからかもしれないが、技術書やビジネス書は連続スクロールのほうが読みやすい。

デッドライン読書会のルールは、以下参照

「IT業界の病理学」の総評

  • 普通に「IT業界あるある」最新版がまとまっているので良い本という印象
  • とりあえず向こう数年間、身近なプロジェクトでの問題予防や回避、分析の際には読み返すだろう

というわけで、有益度の高い本だった

一方で、個々の問題については深掘りは不充分な印象である。
よって、本書を読んで書かれていること「だけ」で予防や対策をすべきではないし、あくまで議論のきっかけとしてしか使えないだろう。

まずは「こんな病気って見たことがある」「自分たちも罹ってしまっているかも」と笑い飛ばし、楽しんでください。そのうえで、何か困ったことがあった時や行き詰まった時に読み返していただき、病気の治療と予防に本書が少しでもヒントになれば、筆者たちにとってこれほどうれしいことはありません。
IT業界の病理学 はじめに

ヒント集としては使って良いだろう。しかし、ガイドとして使ってはいけない。

残念な点/こうだったらよかったのに

ソフトウェア業界の病理的な観点を語るのであれば、やはりこの本は外せないだろう(ただし現時点では入手困難かつ、内容はかなり古びている点に注意すること)。

アンチパターンは、ソフトウェアの開発や導入が成功するためには何を避けるべきか、という教えの集大成です。そういう、やってはいけないことを現にやっている、あるいは、このままだとやりそうだ、ということに早期に気づくこと、…アンチパターンは、その自覚と早期発見がきわめて重要です。本書はソフトウェア開発に関連したさまざまなアンチパターンを詳しく解説し、ソフトウェアの設計(デザイン)、アーキテクチャ、およびプロジェクト管理の各面に見られる多くのアンチパターンを、ユーモアに富んだ軽い文章で指摘してくれます。しかし本書が読み物としてどれだけおもしろくても、それらのアンチパターンの発生を、私たちは必死で防がなければならないのです。
アンチパターン―ソフトウェア危篤患者の救出 謝辞

同書で紹介されているアンチパターンの多くはWikipediaにも掲載されているが、
アンチパターン - Wikipedia
パターン名称が明快である(そして面白い)。この利点は、エンジニア間のコンテキストの共有がしやすい点にある。「うちのプロジェクト、ちょっと分析地獄っぽくてさぁ。アンチパターンの」「あー、なるほど」こういう会話が可能である。

一方で「IT業界の病理学」は基本的にエッセイ集の体裁を取っているため、洗練されたパターン名称が無いのはとても残念である。

また、いくつかの病例についてはすでに業界内でいくつかパターン名的なものが提案されているものもあり、もう少しリサーチや深掘りがあったほうが良かったと思う。
例えば「なんちゃってアジャイル症候群」については、Fake Scrum / Fake Agile / Agile Hangover などの既存の論点には触れられていない。
これは、各記事の執筆者のコンテキストに依存してしまっているのだろうとは思うが・・・。

と、いろいろ書いてしまったが、読むことで様々な課題認識が刺激される良書である。
興味を持った方は、ぜひ手にとってみることをオススメする。

若手が育たないとか言っている暇はもう無い

放送大学の大学長である來生先生が2020年度の入学案内で語っていた内容がとても良かった。

 情報化の進展は、全ての分野で情報生産の量とスピードを、想像もつかないほど増大させ、その増大は今後ますます激しくなります。医学関係の知識が倍増する時間が、1950年代には50年、80年代には7年、2010年には3.5年だったものが、2020年にはわずか73日になるともいわれています。それにより社会構成員が個人的に持つ知識の陳腐化は非常に速い速度で進み、しかもその速度は等比級数的に増します。
 社会全体の情報量が限られ、その増加の速度も遅い時代にあっては、ある時点で獲得した知識の陳腐化は長い時間を経て徐々に進行します。これまでは、過去のある時点で獲得した知識の有用性の、相対的な有効性が長期に持続することが期待できました。多くの人が若い時代に獲得した学位の実質的な有効性が、人生の終末まで続くとの期待が可能だったということです。
 しかし、過去の知識の相対的有用性が、信じられないほどの速度で低下しつつあります。それが情報化の冷徹な一面です。人が社会的に価値ある存在であり続けるためには、学歴や職歴にかかわらず、「人は常に学び 続けなければならず」、しかも「それを生涯継続すること」が義務として求められる時代がすでに来つつあるのです。
放送大学 2020年度 教養学部案内(PDF)

なお、言及されている医学関係の知識が倍増される話(the doubling time of medical knowledge)についてちょっと調べてみたが、以下の論文が原典のようだ。2010年に発表されたもの。

(なおこの話が正しいのか、についてはいろいろと議論もあるようなので注意が必要だろう)

AKIRA A.D.2019 TOKYO

遅刻してくれて、ありがとう(上) 常識が通じない時代の生き方 遅刻してくれて、ありがとう 常識が通じない時代の生き方」でトーマス・フリードマンが語っているように(もしくはその他諸々の書籍で繰り返し言われているように)、あらゆるものが加速している(フリードマンの定義では”NOVA化している")状態である。よって、常に学び続けている必要性も指数関数的に増加している。

私が大学を卒業したときには、仕事を見つけなければならなかった。私の娘たちは、仕事を創り出さなければならない。私は大学で生活のためのスキルを身につけ、その後の生涯学習は趣味だった。娘たちは最初の仕事を得るスキルを身につけるために大学へ行き、生涯学習はその後のあらゆる仕事で必要になる。
遅刻してくれて、ありがとう(上) 常識が通じない時代の生き方 遅刻してくれて、ありがとう 常識が通じない時代の生き方

自分自身も45歳になって完全なオッサンなのであるが、一応ほどほどに努力はしているつもりである(成果が出ているかは別にして)。
ただ、所属組織で同年代や少し職位が上の(比喩としての)オッサンが「若手が育たない」「若手を育ているにはどうすればいいのか」と会議室で踏ん反り返って議論をしているのを見ると、大きな違和感を感じてしまう。「お前はどうなんだよ」

若手を育てるための正解は、自分がそれ以上に成長することではないか。そんなことを新年に酔っ払いながら少し考えたのであった。