2015年に読んだうさみみエンジニアがよかったと思う書籍

2015年は会社の業務外でまるでアウトプットができませんでした。特に下半期はやばかったです。 自分なりにいろいろ大変な時期だったので、学んだことはたくさんありました。学んだことの量で言えば多分仕事し始めてから一番学んだ1年だった気がします。

で、振り返りを書くのは大変だし、むしろそういうのは、 Scrum Gathering Tokyo 2016 で話すので、自分の記録として恒例の「2015年に読んだうさみみエンジニアがよかったと思う書籍」をまとめておきます。

組織

HARD THINGS

ワーク・ルールズ！―君の生き方とリーダーシップを変える

How Google Works (ハウ・グーグル・ワークス) ―私たちの働き方とマネジメント

スクラム　仕事が４倍速くなる“世界標準”のチーム戦術 (早川書房)

エクストリームプログラミング

Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン

組織パターン (Object Oriented SELECTION)

エッセンシャル スクラム

アジャイルレトロスペクティブズ　強いチームを育てる「ふりかえり」の手引き

リーン開発の本質

テスト

絵で見てわかるシステムパフォーマンスの仕組み

Exploratory Software Testing: Tips, Tricks, Tours, and Techniques to Guide Test Design

Explore It!: Reduce Risk and Increase Confidence with Exploratory Testing

プログラミング

Groovy in Action

コンピュータシステムの理論と実装 ―モダンなコンピュータの作り方

C#実践開発手法 (マイクロソフト公式解説書)

．ＮＥＴのエンタープライズアプリケーションアーキテクチャ　第２版 (マイクロソフト公式解説書)

Lean Architecture: for Agile Software Development

C#プログラマのための.NETアプリケーション最適化技法 (Programmer's SELECTION)

要求

ソフトウェア要求 第3版

バリュー・プロポジション・デザイン 顧客が欲しがる製品やサービスを創る

誰のためのデザイン？　増補・改訂版　―認知科学者のデザイン原論

ユーザーストーリーマッピング

ゴール&ストラテジ入門: 残念なシステムの無くし方

IMPACT MAPPING インパクトのあるソフトウェアを作る

価値論

哲学概論 第1部 (岩波文庫 青 654-2)

哲学概論 第2部 (岩波文庫 青 654-3)

新カント学派の価値哲学―体系と生のはざま

行動経済学

予想どおりに不合理: 行動経済学が明かす「あなたがそれを選ぶわけ」 (ハヤカワ・ノンフィクション文庫)

お金と感情と意思決定の白熱教室: 楽しい行動経済学

ファスト&スロー(上) あなたの意思はどのように決まるか? (ハヤカワ・ノンフィクション文庫)

ファスト&スロー(下) あなたの意思はどのように決まるか? (ハヤカワ・ノンフィクション文庫)

文章

数学文章作法 基礎編 (ちくま学芸文庫)

数学文章作法 推敲編 (ちくま学芸文庫)

数学

初等整数論 ―数論幾何への誘い― (共立講座 数学探検 6)

超高速グラフ列挙アルゴリズム?〈フカシギの数え方〉が拓く，組合せ問題への新アプローチ?

経済学

コーポレート・ファイナンス 第10版 上

コーポレート・ファイナンス 第10版 下

看護学

看護覚え書―看護であること看護でないこと

看護の基本となるもの

今年はあんまりテストの書籍を読んでいないなーと思ったのですが、テストはもっぱら論文ばっかりだったのと、チェッキングよりもテスティングに力をいれていたという事情があってあんまり書籍には結びつかなかった感じですかね。。。

いつもよりはいろんな分野の書籍を読むことになったので、来年もこの調子でもっといろんな分野の知識を統合できるといいなぁと思っています。

来年の個人的な目標は「価値基礎勉強会」をやることですね。

要求を明確にしたり、整理したり、共有するときに参考にしている書籍リスト

背景

次のようなリプライが飛んできたので、後輩も絡んでいることだし kyon_mmが普段仕事で要求を明確にしたり、整理したり、共有するときに参考にしている書籍リスト を公開してみる。

これらの書籍の情報から得られるPOとしての振る舞いを僕は常日頃、自他共に求めている。読んだことがなくても体験で得られるものもあるとは思っている。僕はその体験を待つだけの忍耐がないのと、自分に恥を感じるのと、知的好奇心からこれらを読んだ。ちなみに全部合わせて2年くらいで読んだと思う。

@kyon_mm 教えてきょんせんせー！ RT @zakky_dev @c0hama どの書籍がいいか、さらに知りたいのであればきょんさんに聞いてもらうのが良いかと思います！

— こはま (@c0hama) November 19, 2015

ビジネスモデル系

ビジネスモデル・ジェネレーション ビジネスモデル設計書

バリュー・プロポジション・デザイン 顧客が欲しがる製品やサービスを創る

ビジネスモデルYOU

キャズム

ＨＡＲＤ　ＴＨＩＮＧＳ

ゴール指向

IMPACT MAPPING インパクトのあるソフトウェアを作る

ゴール&ストラテジ入門: 残念なシステムの無くし方

ソフトウェア開発全体系

実践ソフトウェアエンジニアリング-ソフトウェアプロフェッショナルのための基本知識-

ソフトウェア品質知識体系ガイド -SQuBOK Guide-(第2版)

アジャイルソフトウェア要求 (Object Oriented SELECTION)

ディシプリンド・アジャイル・デリバリー　エンタープライズ・アジャイル実践ガイド

ソフトウェアシステムアーキテクチャ構築の原理 第2版 ITアーキテクトの決断を支えるアーキテクチャ思考法

システムアーキテクチャ構築の実践手法 (IT Architects’ Archive)

Lean系

リーン開発の本質

Running Lean ―実践リーンスタートアップ (THE LEAN SERIES)

リーン・スタートアップ

Lean Analytics ―スタートアップのためのデータ解析と活用法 (THE LEAN SERIES)

リーン顧客開発 ―「売れないリスク」を極小化する技術 (THE LEAN SERIES)

Lean UX ―リーン思考によるユーザエクスペリエンス・デザイン (THE LEAN SERIES)

ユーザーストーリーマッピング

アントレプレナーの教科書

要求仕様系

ソフトウェア要求 第3版

要求工学知識体系 第1版

ユースケース駆動開発実践ガイド (OOP Foundations)

[改訂第2版] [入門+実践]要求を仕様化する技術・表現する技術 -仕様が書けていますか?

ユーザエクスペリエンスのためのストーリーテリング -よりよいデザインを生み出すストーリーの作り方と伝え方 -

モデル系

UMLモデリングの本質 第2版

形式手法入門―ロジックによるソフトウェア設計―

抽象によるソフトウェア設計−Alloyではじめる形式手法−

VDM++によるオブジェクト指向システムの高品質設計と検証 (IT architects’ archive)

見積もり系

アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~

ソフトウェア見積り

ソフトウェア見積りのすべて 第2版 ―現実に即した規模・品質・工数・工期の予測―

IA/UX系

誰のためのデザイン？　増補・改訂版　―認知科学者のデザイン原論

インタフェースデザインの実践教室 ―優れたユーザビリティを実現するアイデアとテクニック

IAシンキング Web制作者・担当者のためのIA思考術

インタフェースデザインの心理学 ―ウェブやアプリに新たな視点をもたらす100の指針

IA100　ユーザーエクスペリエンスデザインのための情報アーキテクチャ設計

一人から始めるユーザーエクスペリエンス

ユーザビリティエンジニアリング原論―ユーザーのためのインタフェースデザイン (情報デザインシリーズ)

モバイルデザインパターン 第2版 ―ユーザーインタフェースのためのパターン集

リスク系

熊とワルツを - リスクを愉しむプロジェクト管理

ピープルウエア　第3版

ソフトウェアテスト293の鉄則

人月の神話【新装版】

チームの文化系

Clean Coder プロフェッショナルプログラマへの道

Software in 30 Days スクラムによるアジャイルな組織変革"成功"ガイド

小さなチーム、大きな仕事〔完全版〕: 37シグナルズ成功の法則

組織パターン (Object Oriented SELECTION)

Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン

RE:統計的品質管理の功罪

概要

SNSで『統計的品質管理の功罪』というスライドについての意見を多数みかけたので、僕も読んでみたので感想を書きます。 ゆえに発表場所では多くのコンテキストが語られているかもしれませんが、スライドからはこう読めるよっていう感じです。 僕の感想は一言でいえば「タイトルは違うほうがいいし、SQCの勉強してないですよね？よく言えますね。」って感じです。 お酒飲みながらのLTだったらありかもーくらい。

もしSQCに村を焼き払われたという事情があるのであれば、SQCを徹底的につぶすくらいの非難なり、手法なりもってくるほうがよいのではないでしょうか。 つまり、マサカリ投げるなら徹底的に投げろ。

発端や背景

SNSで下記のスライドに対する言及が多数ありました。

統計的品質管理の功罪 from 工 久納

"辛いよねー"と共感するか、"コンテキスト広く言いすぎじゃないか？"と批判するかの2つが多かったように見えます。

私もこのような行数あたりのバグ数に関してつらい思いをしたことはありますが、やはりこれはあまりにコンテキストが広すぎるという感じです。

kyon_mmの所感

「ソフトウェアの品質を評価するのにコードを一切見ていない」というのは、たしかによくないかもしれないですが、 では、この現場では例えば「こういった意味で品質の良いコードです」ということは伝える努力はしたのでしょうか？ それがコードを見なくてもわかるようにです。

僕は、プログラマーじゃない人にでも品質を評価してもらうというのは重要だと考えています。 最終的にはスポンサーがコードの品質にもお金を払っているわけで、 スポンサーにも同じように説得する場面が存在するであろうからです。

説得しなくても十分な場合もあるでしょう。 そのときには、この品質管理担当さんがいなくてもいいか、 もしくはもっと違う方法を取ってもらうことでサポートしてもらう必要がありそうです。

仮に「コードは、実物を見ないと評価できない」とあきらめるのであれば、 僕はそういった態度についてエンジニアとしてある種の諦めを感じますし、 あまりソフトウェア開発の未来に前向きではないなという印象を持ちました。

GitHubのIssueやコメントを求めているってどんだけ狭い話なの？

35ページに「僕たちが望んでいるもの」として、おそらくGitHubのIssueやコメントのような画面表示がありました。 そして次のページには「現実」として行数とエラーの原因や発生フェーズが書かれていました。

どちらも必要な情報だと僕は思っています。また、どちらかだけをほしいってどんだけ狭い領域で仕事しているんだよって感じです。 むしろ、この2つで足りるとでも思っているの？大丈夫？って感じが。

例えば後者の情報が長年蓄積され、共有されたことで「何をつくるかをハッキリさせることが重要だ」（要件定義のミスはやばい） という共通認識を多くの人が持っています。それらにどう対応するかはプロセス次第です。 まぁ、この情報の取り方が正しいかを考えていない人もいるでしょうが。（個々のプロジェクトでほしい情報は異なるよねー。的な）

Web上で気軽にコードのちょっとした設計について議論できるのもとても大切です。 ただ、IssueというかコメントもWeb画面上でひたすらやりとりされて、必要な情報が一切ないというのはいろんな場面で遭遇します。 あとは、楽しいと思っているだけで実際の効率について考えたことがどれくらいあるのかというのも気になります。 個人的にはチャットツールにも同じことを感じています。 （自分はSlackを使っていますが、チームメンバーで使い方ルールをつくりました。）

アジャイルの人はこれだからとか言っている人達もおかしいよね

このスライドに対してSNSの反応でアジャイルの人だからーというのが見受けられましたが、 どこにアジャイル要素があったのかわかりませんでした。

永和だから？Rubyって書いてあったから？GitHubっぽいページがあったから？コードの話をしたから？ これらであれば、アジャイルかどうかなんて全く関係ないです。

仮にこの発表のコンテキストがアジャイルだったとして、 少なくとも資料上からはアジャイルに顧客への価値提供、チームビルディング、改善を考えているようには見えませんでした。 つまり、アジャイルな発表ではカケラもない。

なにがしかのイメージでアジャイルだからーとか言うのはよくないかと思います。

SQCの例としてはあまりに貧弱ではないだろうか

イベントの都合かもしれないのでなんとも言えないのですが、 この内容でSQCというのはあまりにも貧弱な内容で、お前が言いたいのはなんなんだって感じです。

SQCについてなにか思うところがあるなら、本来のSQCの使い方とどうずれてしまっているのかなど言うべきだし、 SQCがクソだと思うなら、こんな指標値よりもっと使えるものあるんだけど！とか言えばいいだけです。 とりあえずエンピリカルなソフトウェア工学の書籍や論文を片っ端から読んだらどうなんですかね。ええ。

こんな貧弱な批判でやつらを倒せるとでも思ってんのか！てきな。

コードを書籍で例えて考えてみる

最後になりますが、僕の考え方としてコードを書籍でたとえます。 初めてのアウトプットになるのでほころびがあるかもしれませんが、僕はよく頭の中でこう考えているという具合に思ってください。

まず、コード行数というのは、書籍でも行数にあたります。 それで、行数あたりの間違いが少ない方がいいっていうのは、例えばですが、書籍でも行数あたりの誤字脱字がどれくらい少ないかという話にも通じます。 書いてあることに整合性がないとか、間違った情報が書かれているとかも、行数ごとに見ることもできます。

例えば、素晴らしい発見を伝える書籍でも誤字脱字があまりにも多かったり、表現が統一されていなさすぎると読みにくいですよね。 なので、その書籍に「ユニークですごい」「文章力が低い」みたいな評判がたつかもしれません。

では、書籍同士の比較をするときに、文章力の低い人と、文章力の高い人で同じテーマの書籍について同様に「行数あたりの間違い」で見れるでしょうか？ 例えば、文章をうまく書ける人であればそもそもだらだらと書く必要がありません。 そう、ここがソフトウェアのコード行数と同じようになるのです。シンプルに伝えることが1つの美徳とされます。 （もちろんそうではない分野もあるでしょうが、1例としてです）

ですが、行数あたりの誤字脱字やどれくらい整合性のとれない主張を書いてしまうかを数値で見えるようにすること自体はとても意味があります。 例えば、その著者のなかでは成長のメトリクスに使えるかもしれません。 実際には編集さんがものすごい頑張っていてそのようなメトリクスは世の中にないかもしれませんが、 編集さんがどのように思っているかを話すと、ある程度いえる数値があったり、どうやってレベルなどを感覚的に分類しているかはありそうですよね。

このように「じっくりと読んでわかる品質」もあれば「伝聞ベースの統計的に見てもわかる品質」などもあります。 なので、個人的には行数で計測すること自体にはあまり問題ないと思っています。 当たり前ですが、どうやってその行数を使うかが重要であり、くだらない方法をかざす人を見ただけで方法論を非難するのはちょっと芸がないです。

週刊ソフトウェアテスト 2015-14 #swtest_jp

前書き

ソフトウェアテストにまつわるニュースを週毎にお届けする記事です。内容はid:kyon_mmの独断と偏見です。オススメの記事があるときや、質問などなどはコメントや@kyon_mmにご連絡くださるとうれしいです。

ハッシュタグ #swtest_jp でソフトウェアテストに関する事をツイートしてくださるととてもうれしいです！（なにかの紹介でも、議論でも、質問でも！

週刊ソフトウェアテスト 2015-13 #swtest_jp

前書き

ソフトウェアテストにまつわるニュースを週毎にお届けする記事です。内容はid:kyon_mmの独断と偏見です。オススメの記事があるときや、質問などなどはコメントや@kyon_mmにご連絡くださるとうれしいです。

ハッシュタグ #swtest_jp でソフトウェアテストに関する事をツイートしてくださるととてもうれしいです！（なにかの紹介でも、議論でも、質問でも！

kyon_mmの意見

テストエンジニアとデベロッパーとの幸せな関係とは何か。開発効率の向上も、ゲームを面白くすることもテストエンジニアの領域に（後編） JaSST'15 Tokyo － Publickeyを読んでいて、概ねいいと思ったのですが、この例示というか現場はクソだなー辛そうだなって思ったのが次の文章の後半です。

私は実はQuality Assuarance（品質保証）という名前を
（私たちの仕事の名前として）使うことは反対です。
質の高い製品を作る、確約するというのはプロジェクトの誰もが持つ共通の目的です。

テスターはコードを変更する権利はなありません。
スケジュールを変更することも、予算をコントロールすることもできない。
スコープも変えられないし、プログラマの採用もできずクビにもできません。
リリースするかどうかを決定する権限もありません。

チームにおいてテスター、プログラマー、マネージャーは得意分野の宣言でしかないのに、なにを言っているんだって感じ。人の採用については難しいかもしれませんが、最低でもコードを変更する権利がないっていうのはどうかと思いますし、コードを変更するスキルがあまりにもないテスターってよっぽど特定分野でハイスキルじゃないと辛そうっていう感じが。

週刊ソフトウェアテスト 2015-12 #swtest_jp

前書き

ソフトウェアテストにまつわるニュースを週毎にお届けする記事です。内容はid:kyon_mmの独断と偏見です。オススメの記事があるときや、質問などなどはコメントや@kyon_mmにご連絡くださるとうれしいです。

ハッシュタグ #swtest_jp でソフトウェアテストに関する事をツイートしてくださるととてもうれしいです！（なにかの紹介でも、議論でも、質問でも！

週刊ソフトウェアテスト 2015-11 #swtest_jp

前書き

ソフトウェアテストにまつわるニュースを週毎にお届けする記事です。内容はid:kyon_mmの独断と偏見です。オススメの記事があるときや、質問などなどはコメントや@kyon_mmにご連絡くださるとうれしいです。

ハッシュタグ #swtest_jp でソフトウェアテストに関する事をツイートしてくださるととてもうれしいです！（なにかの紹介でも、議論でも、質問でも！

kyon_mmの意見

What if testing was a part of the design processにおけるデザインの領域が基本的にUIに関する部分だったのですが、もっと他の面でもテスティングは関わっているのでそういった話がそういえばないなーと思いました。（該当のブログはUI系を専門としているようなので書いていないのは当然な気がしています。）

例えば、「どのテストスイートをやり直しやすくするかによって、プロダクトのどの部分のモッカビリティを高めるか」は、テスティングがプロダクト設計に強く影響をあたえるところです。