Category Archives: books

『ソフトウェアの欠陥予防 テストより確実な品質改善法』を読んだ

ソフトウェアの欠陥予防 テストより確実な品質改善法 を読みました。 ある市営図書館でたまたま見つけて、ふと手に取ってた書籍です。 この書籍は日本語訳する時に一部がっつり省かれた章があるらしいです。日本語で読んでかなり資産としてよかったので、つい英語版をポチってしまった。届いたら再読しようと思います。ご興味のある方はどうぞ => The Practical Guide to Defect Prevention (Developer Best Practices) 読んでみて、この書籍はテストエンジニアや品質にかかわる人は読んだほうが良さそうです。が、それ以上にソフトウェアで製品を開発し、それによってユーザに価値をより効率的に提供したい開発者やディレクターの人ほど読むべきだと感じました。特に、第1、2章くらいを。経済的な話など含めて、欠陥予防への取り組みの価値を知ることができるので。(ちなみに、これを書かれた方はWindows Vistの開発に関わった方々です。) 例えば、欠陥予防の取り組みが、破壊的なイノベーションへの投資へ資源を回すことができる余力を作ることに如何に貢献するかなどが書いています。欠陥予防を中心に取り組んだ組織と事後対応中心に取り組んだ組織とでは、彼らの計測結果の中で新機能やサービス改善への生産性に対して約2倍の差があったそうです。つまり、欠陥予防へ取り組んだ組織は、そうでない組織に対して新機能/新しい価値を生み出すための挑戦が多く実施可能だそうです。 この背景は想像の世界ではなく、開発時にかけるコスト、その保守対応時のコスト、機会費用などを持ってきて、費用という側面からの議論のコンテキストの上で行っていることがこの書籍の素晴らしいと感じたところです。 例えば、機能を開発している時に発見された不具合を事後対応に回すほどに、リリース前に対応していた時に比べて修正するまでに費用がかかります。それは、リリース後にユーザサポートにかかるコストや、その修正を行ったあとに行われるテスト作業など含めて考えると直感にも反しないでしょう。これは事後対応中心の組織における開発では考えられないことも多く、例えば自身の変更がmasterにマージされるまでは考慮するが、それ以外のことは考慮しない、というような 限られたソフトウェアのライフサイクルしか考慮できていない ことも関係あるそうです。 ここでいう欠陥/不具合とは、それを利用した人が欠陥/不具合と判断したものです。そのため、Specの通りに実装できていないものだけを欠陥と言っているのではないです。誤って行った設計など、より上の工程に埋め込まれた欠陥、などへも言及しています。 Microsoftの人の言葉はなかなか強いですね。論文などもちゃんとしているぶん。 幾つか頭に残った項目を以下につらつら。 メトリクス P133ページごろに書かれていたメトリクスの話。 例えばカバレッジなどのメトリクスに関して書いていました。よくあるソフトウェアテスト／品質関連の書籍同様、目指す計測可能な値の1つだと書かれてはいますが、それが銀の弾丸などではないとも書いています。コード変更量とかカバレッジの話で気構えるの、私の観測する範囲ではなんかテスト界隈の人よりも開発者が過剰に反応している環境の方が多いように見えるのですが、これは過去に何かあったのかな…その計測値が顧客への成果物になってたりする場所で働いて、それが絶対的だったりしたのかな。参考値としては多彩な情報を提供してくれますが、それだけをプロセス管理などの管理のために使うといった、誤った使い方は妥当ではないですね。 Microsoftのビジネス及び従業員のゴールは、SMARTを求められるそうな。 具体的 specific 計測可能 measurable 達成可能 achievable 結果重視 result oriented 期限付き time bound そのための要素としてGQMが言われていて、 Goal Question Metric を使うそうな。優先付けの数値は、一般に粒度があまり密でないほうが良いらしい。なので、hight 9/medium 3/low 1くらいの点数付けでメトリクスやタスクを優先付けするそうです。その重み付けには、開始の容易さ・メンテナンスの容易さ・有用性、現在収集されているか、信頼レベルなどらしいです。それを元にヒートマップを作るみたい。ヒートマップを作るの良いな。(P.140くらい) リスク分析 第8章ではリスク分析の話が書かれてました。リスク分析では、特性(characteristics)、量(amount)、インパクト(impact)、理由(reason)、オーナーシップ(ownership)でリスクレベルを判断するそう。コードの変更内容、変更量、変更による影響、変更理由、誰が変更しているか、だそうです。真っ当な感じですね。過去、現在から予測する。そこにフィードバックも入れる。 欠陥分類 第10章では欠陥分類法について言及してました。そこでは、以下の内容を前提に、欠陥を分類していく幾つかの実例を載せています。 変化には決まった種類がある: 人/文化/プロセスなど…More

2015年に新たに読んだ書籍群を振り返って

Blogに書き起こした、2015年のうちに新たに読んだ書籍をまとめてみました。過去読んだことがあるものを必要に応じて読んだり、本棚やKindle見るとBlogに残していない書籍も散見されましたが、そちらは特別Blogには残してないです。書いていないものは、読んでなるほどね、で終わっている感じ。WIREDみたいな雑誌なんかも。 ここ1年たどると、48冊は読んでいたことになってました。本を読むこと自体、特に嫌いではないのですがこう見ると思いの外、技術的な書籍読んでいるのですね。小説類は除いても月に3冊くらい読んでいたことになります。移動時間あるってこういうところでは素晴らしい。 ざっと見てみると、今年は実際の実装よりの所であったり、デザインに対する所が中心だった、という感じでしょうか。テスト技術という所では有名どころは過去に読んでいたため、時折読み返したりしましたが新たなものを購入して読んで、という所まではいってないです。モバイル系の話とか、書籍になった時点で欲しい情報はだいぶ私自身が知見貯めてましたしね。 このリスト取得はWordpressのAPIから、特定のtagの投稿だけを取得して整形しました。コードはこちら。 https://github.com/KazuCocoa/wordpress_ex/blob/master/lib/wordpress_ex.ex 読んでて良かったと思ったものには★をつけています。 その中で、特に良かったものは以下。 『日本の大和言葉を美しく話す―こころが通じる和の表現』 『スマホに満足してますか？～ユーザインタフェースの心理学～ (光文社新書)』 『エクストリームプログラミング』 『システムの科学 第3版』 2016年はどんな書籍を読むかな。 programming language Elixir 『Elixir in Action』を読んで写経とかも合わせてやった★ 『Programming Elixir』を読んで、写経とかした★ [Elixir]macroのテストを書いてみる 『The Little Elixir & OTP Guidebook』のMEAPを読んでみた 『Programming Phoenix』を読んでみた（まだドラフト版） Swift [Swift]The Swift Programming Language(Swift2.1)を読んで写経して学んだ★ Ruby 『リファクタリング:Rubyエディション』を読んだ★ 『dRubyによる分散・Webプログラミング』を読んで分散処理を思い出す★ 技術 テスト関連 システムテスト自動化 標準ガイドを読んだ 駆け足でテストコードのプラクティスを学べる『実践JUnit』を読んだ★ 『BDD in Action』を読んだ 『ソフトウェア・テストの技法 第2版』を久しぶりに読んだ 『TPI NEXT』を読んで(テスト)プロセス改善を考える 「実践テスト駆動開発」の積読をようやっと読んだ★ モバイル ハイパフォーマンスブラウザネットワーキングを読んでモバイルアプリ開発(クライアント/サーバ含め)に関わる人が知っているべきだと思ったこと★ Testing…More

『システムの科学』を読んだ

システムの科学 第3版 を読みました。 FB上で誰かがコメントしていたことをきっかけに読んでみることにしましたが、これは大学院の頃にも読んでおきたかったと思ったものでした。(ただ、その頃に読んでも今ほど楽しめなかっただろうですが) 原書は “The Sciences of Artificial, Third Edition”です。人工物に対して、科学的な見解をまとめている本です。そこには数多の論文が引用されています。第3版では、複雑性に関する内容を取り入れて、システムへの考察もその時点での経験的な側面含めて述べています。 ここでいうシステム、とは複雑系を指しています。なので、人の生活や文化、組織の話だったり、コンピュータを使った分散システムの話であったりが対象です。認知心理学やデザインの科学のほか、複雑性に対するカオスや遺伝的アルゴリズムなどの話を交えつつ、それら”システム”に対していろいろ述べています。 人は、どんなにしたいと思っても、できないことをやろうとはしないであろう。… それ以外に選択の余地がないがゆえに、「十分良好な」代替案を受け容れる、そういう人間すなわち満足化を追求する人なのである。 面白かったところは、人が満足するとはどういう状態か、というような所まで踏み込んでいたことです。科学的な視点から、例えば創造したシステムが人を満足させる、満足したとはどうなっていることなのかまで書いています。ここら辺も踏まえて、ソフトウェアテストや品質という点で、私が進んでいるような先にあるテストエンジニアを目指す人には必要な論理的な基礎として学んでおきたい所ですね。 人工物の科学を考えるのでれば、デザインの評価(評価理論、計算方法、形式理論)、代替案の探索(発見的探索、資源配分、組織化の理論、問題の表現)を学ぶ必要があると途中で書いてました。ここら辺まで踏み込んでまとめられているものが、すでに1990年代にあったとは… 政治学には「代替案なしに批判だけすることはできない」という諺がある。 複雑性の話は、私自身が複雑系を対象に研究をしていた時期があったこともあり、とても面白かったです。複雑なシステムは、少なくとも 単純な仕組みが幾重にも階層的に連なり構成されるシステム であることを、いろいろな例を基に書いています。そこにはまだ経験的な話ベースの例が多いですが、この書籍を書いた以降の幾つかの経済系論文を追ったことがある身としては、ちゃんとした数式で証明された理論もあるので経験を理論で固めていく、という科学の話を追えたこともまた面白かったです。 最後に、経済学は、心理科学であると述べていることが面白かったです。富を追う、という所よりも、人の心理に注目しているところが品質ぽかった。 いろいろ頭を使いながら読む必要がありそうな本なのですが、これはまた読み返したい。 余談ですが、複雑系では私は The Wisdom of Crowds が面白かった憶えがあります。Kindle版もでていたのですね。More

『ヤバい統計学』を読んだ

『ヤバい統計学』を読みました。きっかけはなんだったのかな。覚えていないですが、確かKindleの安売りセールのときに目に止まって、読み物的に読み始めた記憶があります。 読んだ感想としては、特に”ヤバい”ところがパッとせず、大学でおそらく統計学などを学んだ人からするとそうだよね、というものが多いように見えます。見方によって色々解釈が変化するジレンマだったり、直感の裏にある統計的な視点であったり。 大学の頃、よく教授に『世の中は確率に満ちている。学ばなくても問題はないが、学んでいかせていれば賢く生きることができる。』といった感じのことを聞いていました。そこの実例が載っている感じ。 どうやら、原書は”numbers rule your world”のようで。確かに、そのタイトルからすると納得な内容でした。ふむ。More

『7つの言語　7つの世界』を読んだ

『7つの言語 7つの世界』を読みました。電子書籍は、このeBook StoreのWebサイトから購入しました。ちょうどeBook Storeのリニューアルキャンペーンで安く購入できるようになったので、これを機に読んでみることにしました。 取り上げられた言語が開発された背景、概念、目指すものなどがうまいことまとめられています。また、それらが解決したいとしていた問題など含めて。 私は言語仕様自体ではなく、それらが解決したいとしていた現実問題やその成長の歴史を学び、現実の問題にフィードバックを与えることに興味があります。そういう意味で、私がこの本に興味を持ったのはちょうどよかったです。 取り上げられている言語は以下。これらに絞った理由などはこの本書に書かれているのでここでは除きます。 Ruby Io Prolog Scala Erlang Clojure Haskell 私はRuby/Scala/Erlangはある程度触ったことがありました。Ioは唯一、初めて見聞きしたものでした。他は聞いたことはあるけれどまだ踏み込んでいないものです。それらの概要や基本的な書き方、特徴的な箇所をざっと知り、それらの成長の課程を学ぶことは読み物としても興味深いものでした。 読んでいて、例えばElixirの言語設計にClojureに影響されたと書かれている箇所が多分にあるのですが、そこの影響された箇所がわかったりしてなかなかに面白かったです。Haskellのモナドなんかは、写像とか、そういう言葉は理解できるけれどそれがプログラミング言語としてどう現実解に落とされているかぱっときてませんでした。そこへの取っ掛かりも得ることができました。 こういうプログラミング言語などの発展は、やはり解決したい問題とこれまでの蓄積があるのですね。 あと、この本で楽しかったのが各言語がなんらかの物語に照らし合わされていたことです。例えばErlangは映画・マトリックスの世界で語られていました。Haskellはスタートレックのスポックなど。More

『エンジニアとして世界の最前線で働く選択肢』を読んだ

『エンジニアとして世界の最前線で働く選択肢』を読みました。 海外で働くというよりは、日本人という特性がマイノリティになる場で働くことに対して、はたまたコンピュータサイエンスを求める求人に対して考えることができる面白い書籍でした。 採用におけるプログラミングやアルゴリズムの話など、いくつか大学時代に学んだことが書かれていました。今でもパッと思いつくだけ、大学の頃に学んだことは役立っている、ということですかね。 これを読んで、何を思ってか簡単なbinary searchをElixirで実装してみました。 [Elixir]implement binary search with Elixir この書籍はプログラマを主な対象としていましたが、テストエンジニアも多分これで求められることはあまり大差はなさそうと感じています。なんというか、コンピュータサイエンスを学んでいたら基礎としてある程度学ぶであろうことなので。そこからさらに、プログラマとしてのセンスなんかが効いてくるのでしょうね。 そうそう。この書籍に、まだ慣れない環境で周りの人と仲良くなるにはランチなどの食事の時間が大事、というのがありました。食やそれを取り巻く環境、作って誰かに/誰かと食べて適当に話す環境、それはやっぱり重要なんだなと感じた日でした。More

[Swift]The Swift Programming Language(Swift2.1)を読んで写経して学んだ

主に、Language Guideの箇所を全て読んで、写経して学びました。Swift2.0になって段階になったと周りから聞いたし、色々と本格的に関わる必要がでてきたので、ですね。 iBookで読んだのですが、HTMLでもあるのですね。こちらから参照することができました。 基礎的な言語仕様を写経しながら学んだので、OS提供のAPIに沿って何か開発できるところまではまだやってません。ただ、Test Engineerとしては言語仕様側をある程度知っておくことは入り口として必要なのでこちらから踏み入ってたりします。 Swiftは Class は参照型(reference type)、 enum や struct は値渡し(always copied)なのですね。なるほど。 Because classes are reference types, it is possible for multiple constants and variables to refer to the same single instance of a class behind the scenes. (The same is not true for structures and enumerations, because they are always copied when…More

『dRubyによる分散・Webプログラミング』を読んで分散処理を思い出す

dRubyによる分散・Webプログラミングを読みました。 この書籍ではdRubyのモジュール解説だけでなく、処理の中心となる考え方や参照渡しと値渡し、マルチスレッド、排他制御、Webアプリケーション実装など含めて、分散処理を考える上で基本的な考え方を網羅しています。dRubyは、 require “drb/drb” すると得られるRubyにおける分散処理環境を提供する機構です。 分散処理を考えるとき、遠隔で処理を行うための規格としてRPC(Remote Procedure Call)なんかがあります。それらはクライアント/サーバのスタブを提供し、ネットワーク越しの分散処理環境の構築を支援します。一方、dRubyでは、オブジェクト同士の通信の概念をネットワーク越しにまで拡張して、分散処理機構を構築します。Pure Rubyで実装されている、というところもとても素晴らしいですね。 私はここ半年いかないくらいの間、Erlang/Elixirをざっと学んでいました。なので、分散オブジェクト同士のコミュニケーションの取り方やLindaのRuby版であるRindaのTupleSpaceなんかの役割など、プロセス間のメッセージパッシングやETSを対比として理解を深めることができました。 この書籍、2005年の段階で関さんによって書かれていることがすごいですね。(その頃はまだ私は大学に入りたてでコンピュターにさえ慣れていなかったな…)More

『21世紀のビジネスにデザイン思考が必要な理由』を読んだ

『21世紀のビジネスにデザイン思考が必要な理由』を読みました。誰かから勧められたからか少し記憶に無いのですが、Kindleにあったので、くらいがきっかけです。 デザイン思考系は幾つか過去に読んだことあるのですが、過去読んだものは比較的具体的な技法といった話を扱っていました。それに対して、この本はそのデザイン思考に対する入口的なものだと思います。 別の書籍からの影響も含め、新しいことを生み出す感性を6つに区分し、 機能だけでなくデザイン 議論よりも物語 個別よりも全体の調和 論理ではなく共感 まじめだけでなく遊び心 モノよりも意義 を提示していたりします。比較ベースで、xxxよりもyyyという形で説明している姿はAgile Manifestoをそのまま思い浮かべさせられます。 この他に関しては、いわゆる問題解決型の考え方を主にデザインする人の視点で述べています。サービス開発を経験している方だと、多くは普段の開発そのままを示していると思います。More