『テストから見えてくる グーグルのソフトウェア開発』 その2

グーグルのソフトウェアテスト本のメモ、その2

テストから見えてくる グーグルのソフトウェア開発

第1章 グーグルのソフトウェアテストの世界へようこそ

ざっくりとグーグル内のデベロッパは、「ソフトウェアエンジニア(SWEと著書では略される)」「ソフトウェアエンジニアインテスト(SET)」「テストエンジニア(TE)」にわけられる。そして、プロダクトの品質を担保するのはSWEの仕事であり、TEやSETが責任を追うものではない。
SETやTEが、具体的にどんな仕事をしているのかは、2章以降で語られる。

以下メモ
・マイクロソフトがテスターの地位を上げた。マイクロソフトもテストに関する本を出している、が、グーグルとのアプローチは全然違う

・ソースコードの品質はSWEが責任を追うものである。

・品質とは、開発とテストを互いに区別できなくなるまで融合することで実現される

・品質とは見つけるものではなく、守るもの

・SWEの仕事とは、ユーザが触れるプロダクトを作ること

・SETの仕事とは、SWEが品質を保つために必要なツールを作成したり、自動化をしたりして、SWEが効率よく高品質なコードを書くためのサポートをすること

・TEの仕事とは、テスト結果の解釈やテストの実行を指揮すること。ユーザ寄りの目線でテストをする。

・SETやTEは組織横断型であり、特定のチームに所属するわけではない。その理由として、テスト分野のイノベーションを会社内に浸透させるには、イノベータがいろんなチームで仕事をすることが望ましいためである。また、チーム間の異動が多いため、仕事に飽きが来ることがなく、モチベーションを高く保つことができる。

・一般的なテストの用語の、ユニットテスト、結合テスト、システムテストを、グーグル内ではそれぞれS,M,Lテストと呼んでいる

・テストは可能な限り自動化されているが、手動のテストもそれなりにやっている。ただ、常に自動化の余地が無いかどうかはチェックしている。「人間の思考の一歩手前まで、自動化」がポリシー

第2章 SET(ソフトウェアエンジニアインテスト)

SETとは、いったい何者でどんな仕事をしているのかが語られている。

SETとは、素養としてはデベロッパであり、コードを書くことが求められる。と同時にテスターとしての素養も必要であり、各種関数やコンポーネントが、どんな使われ方をするのか想像を巡らせ、どのようなテストをクリアすれば、そのコードが安全といえるのかを理解している必要がある。
SETはテストの自動化を支援し、テスト駆動開発のお作法のようなものをSWEに教育し、SWEが効率よく高品質なコードを書くためのサポートをするのがミッションである。

以下メモ
・シンプルを保てば、安全は保たれる

・グーグルではテスト駆動開発を実践している

・SETの昇進コースはSWEと同じ

・品質は、ソフトウェアが重要になるまでは重要ではない。したがって、SETは優先度の高いプロジェクトにコミットされる

・SWEは関数単位、コンポーネント単位の比較的狭い視野で判断を下す傾向にあり、SETはシステム単位の広い視野で判断を下す傾向にある

・SETは広い視野で製品を見ているというアドバンテージがある。そのため、コードの再利用パターンや、コンポーネントのやり取りの設計が得意である

・テストを自動化する際は、「何を自動化するのか」をまず考える。規模が大きければ良いというものでもない

・SETの仕事を一言でいうと「テストのし易い環境を作る」ということ

・グーグルでは、コードを書くことよりもレビューすることのほうが、ずっと大切なこととして扱われる

・「テストの自動化」とは、テストプログラムの実行、結果の分析、格納、レポーティングのことである

・Sテスト(ユニットテスト)は、コードの品質向上に役立つ。Mテスト(結合テスト)、Lテスト(システムテスト)は製品の品質向上に役立つ。製品の品質を見る際は、「使いやすさ」や「スピード」といった目に見えない機能も無視してはならない

・プロダクトの種類によって、SMLの比率を変えている。ユーザに近いプロダクトは、MとLが多め。インフラ系やデータ操作が中心のものはSが多め

・テストは、結果だけでなく、「どこで失敗したか」がわかるような仕組みにしなければならない

・バグデータベース:buganaizer

・ブラウザ自動化:selenium,WebDriver

・社内ツールとかはDDD(欠陥駆動開発、Defect Driven Development)でやってもいいかもしれない。
DDDとは、実際に使ってるユーザが困ってるバグから治していくというスタイル。ということは、誰も気にしないバグは直されない

？？？「誠意とは言葉ではなく金額」

不適切会計で揺れた東芝ですが、不正会計時のCFOが財務顧問に就任とかいうニュース。まぁ、第一印象は不誠実な感じを受けますよね。
速報：東芝、不正会計時のCFOが財務顧問に就任：日経ビジネスオンライン

だけど、僕は、「責任を取る＝身を引く」という考え方も、ちょっとどうかなと思ってたりもします。責任の取り方はそれだけではないだろう、と。

さだまさしの歌に「償い」という歌があります。交通事故の加害者が、被害者遺族に対して、長年に渡る愚直で誠実な謝罪を続けるうちに、被害者遺族に「少しだけ」許されるというおはなし。むかし、実際にあったとある裁判の時に裁判長が加害者に対して、「さだまさしの『償い』のように、あなたも云々～」と説教をしたこともあるらしい、そんな歌。

ここでの責任の取り方は、ひたすら愚直に信頼を取り戻すための正しい行いを積み重ねるというものです。そして、僕は「責任を取る」という行為は、こういった地味な行為を指すものであって欲しいと思っているのです。

切腹ハラキリの美学が残っているのか、責任者の立場のくせに、「失敗したものは去る」というのが責任を取る行為だと思ってる人も多いのですが(実際に何度か会社でもみましたが)、それって、責任をとったのではなく、責任を後任者になすりつけてるだけな気がするんですよね。まぁ、そもそも荷が重くて失敗した場合は、別の誰かに失敗の尻拭いをさせない限りは前に進まないので、しょうがないですが、その場合でも、責任をとってるのは、失敗した人の上司であり、失敗した当の本人では無いのですよ。それを、なんか悲壮な顔で「責任を取って、職を降ります」的なことを言われると、何を悲劇のヒーローぶってるのかと。まずは自分に出来ることを探さんかい。

ああ、なんか具体的な人の顔を思い出しているのか、話が脱線しかけました。まぁ、何が言いたいのかというと、今回の東芝のCFOの件も、こんな火中の栗を拾うやつなんてそうそういないわけだから、当事者にやらせてみるのもいいんじゃないですかねってことです。東芝の役員を務めるくらいですから、めちゃくちゃ頭はいいはずで、ヘンに東芝にしがみつく必要も多分なくて、「不誠実だ、理解できない、盗人が警察をしているようなものだ」みたいなバッシング受けることも百も承知で、それでも自分の責任で持って、東芝の信頼を取り戻そうとしているのではなかろうかしら。

たぶんね。

消費するだけにはもう飽きた、の件

テレビ見たり散歩したりしてボンヤリと思うことなのですが、今って、「消費」の世の中だなと思うわけです。みんな、「楽しいこと」や「美味しいもの」や「珍しいもの」を消費することに一生懸命。そして、それらを、ブログやSNSツールに乗っけて共感してもらうこと(つまりは、自慢やね)に必死だなぁ、と。

消費することも当然楽しいと思うのですが、消費だけだと、どうしても、ちょっと物足りなく感じてしまう今日このごろで。表現を変えると、インプットだけだと、楽しさに深みが無いと思うのです。

たとえば、学園祭で一番充実しているのは、遊びに来る客ではなく主催している学生側だろうし、コミケも買う側よりも出す側のほうが、より深くコミケというのものを楽しんでいるだろう。インプットする側よりも、アウトプットする側のほうが、絶対に楽しい。

アウトプットをすると、世の中の見方が少し変わる。
僕は数年前まで、絶対に見ないテレビ番組として、マラソン中継とゴルフ中継があったが、自分自身がゴルフを始めた途端、ゴルフ中継を見るようになった。相変わらず、ゴルフ中継は画面の見栄えとしては地味なわけだが、素人の自分とプロの間の技術の差が理解できるようになってから、それが面白く感じるようになったわけである。どのような練習を積めば、あの技術に近づくことができるのだろうかと考えて、そしてそれを練習して試してみることが楽しい。

アウトプットの楽しさは、「昨日より少し上手くなったな」という、自己完結というか文字とおりの自己満足に満たされるのが良い。仕事とかで他人を巻き込む自己満足は厄介だけど、個人が趣味でやる分の自己満足は、この先の長い人生を楽しむ上で、とても大事なものな気がする。

ということで、ブログを初めてみたわけです。
特に仕事にまつわることとかを、今まで文章化してこなかったので、自分の専門領域のこととか、あるいは、もっとふんわりとした物事の考え方とかを、文章として残してみたいなと思っています。

『テストから見えてくる グーグルのソフトウェア開発』 その1

テストから見えてくる グーグルのソフトウェア開発

簡単で地味な作業、低所得、(プログラマ、ディレクタの)揚げ足取り

ソフトウェアのテスト、または、QA(品質管理)に、上記のような印象を持ってる人もいるのではないでしょうか。
私自身、QAをやってるので、「そう思われてるなぁ」という実感があるし(新卒とかの経験の浅い人がそういうイメージを持ってることが多い)、また、僕はキャリアのスタートをプログラマとしてスタートしたけど、確かに当時は上記のようなイメージを多少持っていた(ま、経験浅かったし無能だったし…)

そんなテスト・QA担当者ですが、世界No1のソフトウェア企業である、グーグルのテスト担当者ってどんな感じなのかというのを、この本では、解説しております。

そこには、(日本の)テスト業界で働く人たちにとって、夢のような世界が広がっているのであった…。


■まえがきの感想
3人の筆者によるまえがき。なかなか読み応えのあるまえがきでした。

グーグルも最初の頃、それこそスタートアップの頃は、手動による探索テストが中心だったが、サービスが大きくなり、かつスピードが求められるようになってきた段階で(この「スピード」というのがグーグルのキーワードだと思いました)、ソフトウェアテストにイノベーションをもたらす必要性を感じたとのこと。


大規模で高品質なサービスを、ベンンチャーのようなスピード感でリリースし続けるために必要なこととは何か。


いまでこそ、アジャイル開発だとかで、サイクルの早い開発スタイルはポピュラーになってますが、当時(2005年くらい)のソフトウェア開発は、ウォーターフォールで、数か月・数年、ってのが普通だったわけで、そのプロセスの一環であるテストも、基本的には地味で時間のかかる作業でした。

グーグルは、この課題をどうやって解決したのか。

それはずばり、品質はテスト担当者が責任を持つものではなく、各プログラマに担わせたのでした。
テストチームとは、「プログラマが品質を担保する」という思想を広げるための活動、並びに、その思想を実現をサポートするためのツール開発を行うチームとして動いた、と。
つまり、「テスト」の定義をゴロっと変えたわけですね。(今では、部署名も「テスト」ではなく「エンジニアリングプロダクティビティ」という部署になったそうです)

そのために、まず必要だったことは、一言でいうと、「エンジニアの素養を持った人の採用」だったようです。しかし、これは、なかなか難しい。そもそも、エンジニアの素養を持った人は、エンジニアになってしまうからね。
これは、テスターよりもエンジニアの方が、一般的に給与も良いし、やりがいもあると思われているからです。
誰だって、何かの揚げ足を取るよりは(実際はそんな仕事じゃないけど)、何か製品を作って世の中にインパクトを与える方が、やりがいを感じるでしょうしね。これは、初期のグーグルでも同じだった模様。

そんな状況を、どう打破していったのか、というのが本書で語られていくようです。
今では、1200人のテスト系エンジニアを抱える部署となり、給与体系もエンジニアと全く同じになったそうです

グーグルのノウハウは、果たして日本のIT企業で参考になるのか。
それとも、単なる超一流企業に入社できる選ばれし者たちのみが甘受できるユートピアの物語なのか。


つづく

てすと

てすと

• あ
• あ
• い

PlayStation 4 ジェット・ブラック (CUH-1200AB01)