第一印象いいもの同士

最近は、採用のお仕事とかもしているのですが、面接って本当難しいですよね

面接のときは、当然、経験やスキルも見るんですが、実は一番知りたいのは「勤勉さ」「素直さ」「優しさ(相手のことを想像できるか)」という、なかなか、わかりにくいモノだったりします。つまり、客観的に測ることが難しい指標を一番重要視しているのが現状。しかも、それらを、たかだが一時間の面接で見極めないといけないわけですから、ほとんど無理ゲーに近い。

どんな質問をしたら、その人の為人がわかるのか、あれこれ考えてるのですが、今のところ、「送別会の時に何をもらったか」と「最近、寄せ書きをもらったことがあるか？そこにはなんて書いてあったか？」が、一番、答えに近い気がしています。

送別会にもらう品も寄せ書きも、他者によるその人のエピソードが詰まっているので、割りと対象者のパーソナリティを客観的に測れるんじゃないかなと。だから、もし面接の時に持ってくるものを指定できるのであれば、寄せ書きとか送別の品を持ってきて欲しいなぁと考えてたりします。それか、紹介状ね。できれば現職の職場の人からの。紹介状すら書いてもらえない人は、ま、いろいろとダメでしょうし。

採用にもう少し権限を持てたら、このあたりやってみたい。応募する側は面倒くさいでしょうけど

あとよぉ、勤怠悪いやつってどうやって見極めたらええんや…。

『テスト担当者を悩ませる、10の難題克服法』 その5

このペースだと、「その12」くらいまでいきそうなイキフン

テスト担当者を悩ませる、10の難題克服法

第5章 難題第8位 ツールを使用せずにテストすること

ツールがどれだけ充実しているかが、そのままテストチームの効率性とか高度性みたいなものに直結している気はする。言い方を変えれば、ツールが充実しているテスト組織ほど、「イケてる」組織ということです。

まぁ、あとは、結局ツールは道具なので、どれだけ使いこなせるかが大事ですよね。どれだけ良いツールを買ったとしても、使いこなせなかったら意味が無いし、場合によっては、効率が悪くなることだってありえます。なので、ツールを導入する際は、「そのツールで何が出来るか」も大事ですが、「そのツールを使いこなせる人材が組織に居るのか？」という視点も大事だなぁと思うわけです。例えば、組織の中に誰ひとりとして英語が読めないのに、英語のツールを買ってもしょうがないよねっていう。

個人的には、自動化ツールとか旬だし興味があります。でも、僕のいるゲーム業界では、あまり話は聞きませんねぇ…。まぁ、ゲームは自動化とはあんまり相性良くないのかもな。
また、会社の偉い人たちは、「自動化」と聞くと、それこそクルマの自動運転みたいに、「何から何まですべてをコンピュータがやってくれて、人間は何もしなくても、バグを洗い出してくれるモノ」って勘違いしがちなので、コミュニケーション取るときは注意しなければならないことが多いです。現状、自動化は、あくまで、一部の項目を自動化するレベルであり、クルマで言えば、ギアの切り替えを勝手にやってくれるオートマ機能くらいのものです。ゲームだと、メモリリークとか処理落ちとか、特定のバグを見つけるのに使ったりしますね。どっかの記事で読んだ話ですが、ナムコの鉄拳では、ひたすらランダムキャラ、ランダムステージででCPU同士を対戦させて、処理落ちするところを洗い出してたらしいです。で、処理落ちした瞬間の画面を自動でキャプチャしてメールで配信してたとかだった気がする。素敵な自動化の仕組みを考えたものだなぁと関心しました。

以下メモ

・テストは単純な作業の繰り返しが、どうしても発生してしまう。そして、その退屈さがテスタの油断を産み、重大なバグを見逃してしまう。その課題に対する解決策は、作業にあった適切なツールを適切なプロセスと組み合わせて使用し、使用する人を適切にトレーニングすることである

・ツールだけでは何も解決しない。ツールをプロセスに組み込む必要がある

・テストに固有な特性の一つに、テスト担当者が同じことを繰り返し実行する、という点がある。

・手作業によるテストは…
1.正確性および信頼性が低い
2.退屈である
3.手間暇がかかる

・一部のテスト・タイプの中には、自動化が適さないものがあることを、理解することが重要である

・テストケースジェネレータ(ウチの組織にも導入してみたい)

・ツールの有効性はツールを使用する人と同水準でしか無い。

・ツールを有効活用するためには、優れた管理方法及び技術方法が不可欠である

・ツールの不足を自分の肉体的な能力で補おうとしてはならない。ツールの予算を認めないならば、テストできる量が少なく、テストの進捗が遅く、テストの効率が悪くなることを、経営管理者は覚悟をするべきである

・有効なプロセスと併用せず、トレーニングを受けていない人がツールを使用することは、悪いテストを早くすすめるだけである。

・1本の木をハンマーで切り倒すことは可能だが、約30日かかる。ハンマーを斧に取り替えれば、30分で切り倒せる。30日と30分の差がスキルである

・組織内で真剣にツールを使用しようとしているならば、プロセスに不可欠な一部としなければならない

『テスト担当者を悩ませる、10の難題克服法』 その4

引き続き、以下の本のメモ

テスト担当者を悩ませる、10の難題克服法

第4章 難題第9位 開発者と良好な関係を築くこと

「品質は、後から付けるものではなく、最初から作りこまれなければならない」っていう言葉をどっかの本で読んで、まさしくその通りだと思うのですが、それを理解していない関係者は結構多い(企画やデザイナなら、まぁまだわかるが、プログラマにも居る)。そういう人たちは、品質とはテストチームが責任を追うべきものであると認識しているように思える。

高品質なソフトウェアは、関係者全員が品質に対する高い意識を持たないかぎり、なかなか達成されない。誰か一人でもいい加減な奴が居れば、品質はそこが基準となってしまう。

どうにも「QA(品質管理) = テスト」のイメージがあるので、テストを行えば品質が保証されるという誤解があるのかもしれない。
僕はそのような誤解をしている人に対しては、「QAチームは、観察と報告しか出来ません。言ってみれば、スポーツジムのトレーナです。対象の人の健康状態と、それを改善するための方法をお伝えするのが仕事です。大事なのは、実際に不健康なのはあなただし、それを改善するのもあなただということです。我々は医者ではないので、直接的に手を動かして、何かを改善することはできません。」というような話をして、QAチームの役割をイメージしてもらいます。

そして、観察と報告しかできないというQAの業務の性質上、その報告先の相手とは、良好な関係を築いている必要があります。簡単にいえば、こちらの意見の聞く耳を持ってもらうということです。ただ、QAの報告とは、大抵の場合が「悪いニュース」であるので、伝え方には充分気をつけないと、たんなる嫌味ったらしい奴らだと思われてしまい、誰からも評価されなくなってしまいます。

たとえば、品質が悪いソフトウェアのテストをすることになっても、「バグだらけだぞ。なにしてんねん。はよ直せや」というのではなく、「見たところ多数問題があるようです。このままリリースするとリスクがあると思うのですが、問題ないでしょうか？」くらい落ち着いた口調で、かつ相手に判断を委ねる形式で伝えておけば、開発者との関係性は悪化するリスクは抑えられるはず(リリース判断をQAチームが持ってない場合もよくあるし)。

あと、開発者と仲よかったら、デバッグツールも作ってもらえるしね。

以下メモ

・組織内のだれもが、テストに参加すべきである。なぜならば、テスト結果には共同して責任を追わなければならないからである

・コミュニケーションが悪いことはプロジェクトが失敗する主要な原因の一つである。また、コミュニケーションのチャネルが詰まっていることは、テストにとって決定的に有害である。

・チームは息を合わせて仕事をするものである。他方、グループは必ずしも、力を合わせて仕事をするとは限らない

・チームワークが最も肝要であり、他の関係者ぐぁの視点に立つことも同様に重要である

・自分たち(テストチーム)が成功するためには、他の人たちからの助けが必要であることを理解する

・敵対的な関係から、win-winの関係に移行するために必要なことは、内面的に目覚めることと時間である。

・テストに関連して、人にやる気をなくさせる最も確実な方法の一つは、成果物ではなく作成者を批判することである

『テスト担当者を悩ませる、10の難題克服法』 その3

続・以下の本のメモ

テスト担当者を悩ませる、10の難題克服法

第3章 難題第10位 テストに関するトレーニングを受けること

僕も複数の会社で働いてきたが、ソフトウェアテストに関して、体系的なトレーニングを実施している会社は無かった。

大抵の場合は、配属されて3日めくらいに一番簡単なテストケースを渡されて、「これを上から順番に消化していってね。もし、わからないことがあったら聞いてください」という感じでした。また、デバッグツールの使い方も時間を割いてレクチャされることはなく、「○○をするにはどうしたらいいんでしょう？」と質問して初めて、それを実現するツールの存在と使い方を知ることになるのです。

そして、それなりのテスターを養成するには、それで充分という現実もあったりします。テストは、テスト対象のシステムを使えさえすれば、務まる仕事がそれなりにあるからです。世の中のテストベンダーが繁盛している理由の一つが、安い賃金で人を集めて、特別なスキルを持たない人でも、役に立てる仕事を供給できるからであり、それがソフトウェアテストの特性の一つかもしれません。

ただ、効率的で効果的なテストを設計し実施するためには、コンピュータサイエンス的な面や、ソーシャルスキル面で、ちゃんとしたトレーニングをした方が良いと思います。まぁ、経験でカバー出来る面も大いにあるけど(そして、大抵のテストリーダは経験ありきで、キャリアを積んでいる)、それは、前近代的な「背中を見て学べ」的な職人の世界みたいなもんで、学習の効率があまり良くないし、個人の特性に大いに左右されてしまいます。

自社のテストチームを永続的に結果を出せるチームにしたいのであれば、トレーニングプログラムの開発は必須だと強く思います。

以下メモ

・テストに関して一般的に信じられていることに、システムを動かせる人は、誰でもテストを行える、ということがある。

・テスト実施について、組織内ではたくさんの誤りがなされてきたが、その中で最たるものは、誰でもテストを実施して重大な欠陥を見つけられる、という誤った想定である。

・テスト担当者は欠陥が発生する可能性のある源を認識していなければならない。それらの欠陥の発生源は、摩訶不思議な深淵に潜んでいるのではない。トレーニングを受けたテスト担当者はそういった点をよく知っており、それは次第に増えていく知識の一部なのである

・テスト技法に関する適切なトレーニングを受けなければ、テストを実施して誰でもわかる欠陥を見つけることは出来ても、システム障害の原因となりうる微妙な欠陥を見逃してしまうだろう

・テスト技法について公式にトレーニングを受けたことのあるソフトウェアの専門家は1%にもみたない

・テストの対象となる3つの属性がある。機能と構造と品質である。

・実施するテストの品質と範囲は、リスクをどれだけ洗い出して緩和したいのか、およびソフトウェアの機能と構造をどれだけテストしたいのか（カバレッジ）に、左右される。

・トレーニングを受けたテスト担当者は、テスト計画を記述する方法、テストケースを作成する方法、適切なテスト環境を構築する方法、テストを実施する方法、テスト結果を評価する方法などを習得している。

・緊急なことが重要な事よりも優先されていることは、よくある(テスト担当者がトレーニングを受ける時間を捻出できない理由）

『テスト担当者を悩ませる、10の難題克服法』 その2

前回に続きまして、以下の本の各論のメモ

テスト担当者を悩ませる、10の難題克服法

第1章 テストによって、テスト担当者もテストされる

ソフトウェアテストの担当者は、テストスキルと調整力が求められる。
仮に、調整が全く出来ないテスト担当者が居たとすれば、その人は、残業まみれの生活を送るはめになり、リリース後に障害が出た時のスケープゴートとなる運命にあるでしょう。

テスト技術者が抱える問題の多くは、人間関係であり、その問題を解決できるかどうか、優れたテスト技術者かどうかを決める要因だと思うのです

以下メモ

・テストはソフトウェア開発プロセスの最後のアクティビティである。そして、プロジェクトは必ずと言っていいほど予定よりも遅れるため、テストが手抜きにされる可能性は極めて高い

・よくある誤解 1
テスト担当者はリリースを遅らせている

・よくある誤解 2
開発者の中には、本末を転倒させて、部分的に完成したプログラムをテストに回す人がいる。テスト担当者が問題を見つけてくれることを期待してのことである。ずさんなコーディングをしながら、質の高いシステムを開発したとの名誉を期待してるのであろう。
(まぁ、大抵の場合、バグ修正のそばからバグを生み出す結果となり、蟻地獄になりますが)

・よくある誤解 3
リリース後に見つかった欠陥はテスト担当者の責任である。

・よくある誤解 4
開発者にはトレーニングが必要だが、テスト担当者にトレーニングはいらない
(なので、会社によっては追い出し部屋のような扱いをうける…) 　

・開発プロセスが予測可能であるならば、テスト担当者がテストを行い易くなる。なぜならば、開発プロセスの強味と弱味がわかっており、テスト担当者は弱みに焦点を当ててテストの労力をつぎ込むことができるからである

・顧客の参加度合いが強ければ、低コストで高品質なソフトウェアに繋がる

・テスト担当者が現在直面している最も困難な問題や挑戦的な課題は、他の人々との人間関係にあるように思われる

・テスト担当者は、従来、テストに関する教育をほとんど、またはまったく受けていない。しかし、テスト担当者は育成されるのであって、うまれるのではない

・経営管理者がテストに本気で関心を払っているかどうかを、テスト担当者の多くは予算を指標にして判断している。

・テスト担当者が悪いニュースの担い手である場合、テスト担当者は敵視される

第2章 テストの現状の自己評価

この先、一流のテスト技術者となり、また現在の組織で評価をされたいのであれば、まずは自分のスキルセットや、業務プロセス、組織内での立ち位置をなるべく客観的に把握する必要があります。

この章には、評価記入シートがあり、このシートを使うと「自分がどのレベルなのか」「現在の組織は、どれだけテストのことを重要視しているのか」を定量的に測れるようになってます(僕はまだやってないけど)。

以下メモ

・ある有名な児童小説の中に、「行き先がわかっていないのなら、どの道をいっても同じこと」という下りがある。
この教訓は、人生におけるあらゆる改善計画の基礎となる。

『テスト担当者を悩ませる、10の難題克服法』 その1

テスト担当者を悩ませる、10の難題克服法

本書の帯には「肝心なのはテストのヒューマンスキルだ」という文言が、デカデカと書かれている。
その言葉が示すように、この本では、ソフトウェアの技術的な話ではなく、テスト担当者が直面しがちな、組織的・社内政治的な問題への対処法や心構えのようなものが記されている。

テスト技術者は、様々な「誤解」と戦わなければならない。テスト技術者ほど、会社や組織によって、扱いが異なる職種も無いのではないだろうか。品質を守るための最後の砦となることもあれば、リストラ対象者の追い出し部屋扱いのときもある。

もし、あなたが優れたテスト技術者だったしても、今いる組織がそのスキルを十分に理解してくれるとは限らない。そんなとき、組織と社内政治の荒波をうまく泳ぎ切るためのヒントが、本書で得られるかもしれない。

なお、10の問題は以下の通り。ある程度、経験を積んだテスト技術者であれば、下記の「問題」の一覧を見ただけで、自分が今まで直面した問題の数々が思い浮かんで来るかもしれない。もしそうでなければ、あなたは、環境に恵まれた幸せなテスト技術者だと思います。

あ、各章の詳細は、また後日…

• 難題10位：テストに関するトレーニングを受けること
• 難題9位：開発者と良好な関係を築くこと
• 難題8位：ツールを使用せずテストすること
• 難題7位：経営管理者にテストについて説明すること
• 難題6位：顧客およびユーザとコミュニケーションを取ること
• 難題5位：テストの時間を確保すること
• 難題4位：投げ渡されたソフトウェアをテストすること
• 難題3位：動いている的を射ること
• 難題2位：どちらに転んでも損する状況と戦うこと
• 難題1位：「ノー」ということ

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

グーグルのソフトウェアテスト本のメモ、その4。とっくに読み終わってるんだけど、メモを書くのが遅れております…
4

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

第4章 TEM(テストエンジニアリングマネージャ)

要は、SETやTEの上司にあたる役職である。彼らが日々どんなことを考えているのか、実際のスタッフへのインタビューも交えて綴られている。人によって、自動化を重視してたりマニュアルテストを重視してたりで、同じ役職でも考えが違っていて面白い。

とはいえ、結局大事なことは、「サービスを知ること」と「スタッフを適材適所で配置すること」に尽きる気がした

以下メモ

• TEMとして成功するための最初のアドバイスは「自分の担当製品を知れ」であり、第二のアドバイスは「部下をよく知れ」である。自分の製品を良く知っているTEMならもっとも優先順位の高い仕事が何か、適切な対処を必要としている部分がどこかもわかるはずだ。部下をよく知っているTEMなら、適切なスキルをもっとも必要としている部分をそのスキルの持ち主に担当させることが出来るはずだ。

• 資源(要は人員)が足りなければ、責任が明確になり、プロジェクトのメンバーたちは仕事を自分のものと強く考えるようになる

• TEMは人に頼ることを避けなければならない。仮にスターテスターが居たとしても、彼を良いように使うだけではいけない。そのテスターをスターに押し上げたものがなんであれ、それをツールの形にまとめたり、パッケージとして他のテスターを同じようなスーパーテスターに育て上げたりしなければならない

• 害のあるプロジェクトに関わるのは避けよ

• TEMは部下たちのインパクト(要はプロジェクトに対する貢献度)を計測できるようにしておくこと

• TEMは、全体として自分の組織で見られるベストプラクティスの発掘に熱心で、それらを同僚に知らせることに積極的でなければならない

• プロジェクトに参加するときは、最初の数週間は話を聞くために費やすべき。例えば、最初の5分で抗生物質を処方する医者のような人を誰が信頼するであろうか。まずは、話すのではなく聞き、試すのではなく尋ねましょう

• 正しいスキルと正しい態度を持つ人々を集めよ

• チームのダイナミクスで必要なのは、デベロッパーチームとテストチームの関係である

• 何を解決すれば、私達テスターが対等なエンジニアとしての立場を確率出来るくらいのリスペクトが集められるのかを考えてみよう

• 採用は妥協するな。頭数を揃えるために良くない人を採用すると、もっと良い人が現れるのをまつよりも、必ず良くないこと

になります

• グーグルがしたことを真似ようと思っている会社は、スキル、人材の希少性、自動化、イテレート/統合の4つから始めるべきでしょう

• ユースケースの20%が利用の80%を占める。その20%だけを自動化し、他のものは手をつけるな。

• バグの検出ではなく、バグの予防に力を入れたことが会社に大きな利益をもたらしました

• 製品を作るのは簡単だが、高品質な製品を素早く作るのは大変なことです

• 価値を追加せよ

• 「ピラー(柱)」という考え方を使っている。ピラーにはシステムピラー(カーネル、メディアなど)、フレームワークピラー、アプリピラー、マーケットピラーなどがあり、それらで組織わけをしていた。部下であるテスターがどのピラーが得意なのかを

把握し、チームを組織した

• 時間の試練に耐えられない自動化を書くこと以上に、ひどい資源の無駄使いはありません。自動化はすぐに書けてすぐに実行出来ねばならない

• 自動化は変化に弾力的に対応することが難しい事が多い。なので、手動テストも大事である。

• 探索的テストは、製品を掘り下げてその内容を学習する最良の方法です

• 日々のビルドをじっくり見て、中身を分析する。そうすることで、製品全体を手当たり次第に探索していくのではなく、日々の変化に商店を絞って、ずっと生産的な仕事ができます

• チーム全体が成果物の品質の責任を負うようにする

• マシンに仕事の90%をやらせて、人間の知性は最後の10%だけに使うようにします

• ツールの目的は、プロセスを自動化して簡単にすることです。ただし、悪い振る舞いを自動化しないように気をつけましょう

• テストでは、コンピュータ科学的な側面よりもソーシャルな側面の方がずっと難しいということだ。

• 開発チームに孤立無援のテスターが組み込まれているのではなく、テスターのグループが一緒に座って互いのアイデアを消化しあうように

• 優れたマネージャになる秘訣は、単純に部下をその人に合ったプロジェクトに配置すること

• 変更が難しい部分のテストに、まずは力を注ぎましょう

第5章 グーグルのソフトウェアテストの未来

• すべてのエンジニアのワークフローに品質を入れよ

• テストは、品質そのものではない。品質は最初から組み込まれていなければいけないものであり、あとから付け足されるべきものではない

• テストの価値は、成果物ではなく、テストという活動自体にある

• 若手のデベロッパーや大学新卒の新人にとって、テスト開発は最初の仕事として、間違いなくもっとも良い

• 私達の考えでは、テストエンジニアリングはテストデザインという仕事に変身する