検証会社10年のたたかいのれきし
所属の第三者検証会社で10年ちょい経ち、常駐した客先は計6社になりました。これまでに日報で書き散らしてきたポエムをのちのちの自分のためにも残しておこうと思いました。
私なりの退職エントリです。
コレを浴びてきた今までの私の直属上司たちありがとうございました。
※見出しに意味はありません。どこからでも読めます。
テストは楽しいぞ
テストを長くやっていると、上流工程の方面から、
「テストなんてつまらないことをなぜ生業にしているのですか？」
という素朴な疑問をぶつけられることがたびたびあります。
「つまんなくないですよ、すっごく楽しいですよ～」と答えていますが
どこがどうおもしろいのかをあまりうまく説明できたことがなく。
開発者が行うテスト＝checking
テストエンジニアが行うテスト＝testing
という言い方で腑に落ちました。
checkingは機械で代替できる（自動化）、決められたことを決められた通りに確認。
testingは対象を破壊する方法をさぐるリバースエンジニアリング。
技術的な説明がうまくなりたい。
---
「テスト」と「テスティング」の違いがどこかに書いてたなーと思いつつ
TPI-NEXTの本をパラパラめくってて
プログラムとプログラミングの違いと同じ
と書いてあってそうだったと思いだしました。
---
「ソツのない」という行動が私は嫌いですが、失敗しないようにしているうちはダメで、そもそも、自分がどれだけ打席に立てているか（立てるようにしているか）
を改めて考えました。
同時に、監督目線で、打席に立たせた人に対して勇気をあげられているのかと。
そもそも打席に立たせてあげられているのかと。
打席にたてなければ、何もできないですからね。
---
アレだなー、ジャンヌ・ダルクのように、「Follow me!」と勇んでいたのに
振り向いたら誰もいなかった、みたいにならないように
常に気を配ってないといけないですね。
---
どんなにやることがたくさんあっても自分のアウトプットのクオリティは
落としたくないなぁと思っているのですが、無理かなぁ。
---
ちゃんとビジネスしたいよね～
---
できそうもないことをどうにかできるようにするにはどうしたら良いかを考えるのがリーダーではないでしょうか。
---
品質管理や改善活動ではどうにもできないことがあり暗澹たる気持ちになっていましたが、いろいろ考えて、あきらめないことにしました。
『あきらめの壁をぶちやぶった人々』という本が好きです。
---
長年怒りが私のモチベーションなんだけどそれ以外の根拠をたくさん身に付ける必要があるのかなぁと思う昨今。
テスト 大好き
ディレクターの１人から聞かれたのですが、
「なんでテストなんかしてるんですか？（そんなイヤなものを）」
と。
「私はテストが大好きなんですよ！」と言うと奇異の目になるのですが、
そのディレクターさんたちは「地味なテストっておもしろくない」
と感じているらしく。
「それはバグが見つからない（見つけられない）からじゃないですか？」
とお話してました。
「自分の手柄」的な喜びも、少々ありますが、何よりバグが見つかると（それが直ると）「今より少し（システムが）良くなる」ってことなので、
だから幸せになるんですよ、と。マインドの話でした。
---
29119研究会でにしさんが発言されていたように、これから業界全体の潮流として、手足ではなく頭をつかって知恵をつかって品質管理を牽引するようにならなければいけないと思う。
教育制度もその助けになれれば良い。
けど、結局は、自分の意志です。
テストスコープから外すスキル
「心配だからやってほしい」「関係ないけど一応見てほしい」という意見が出るのは「見ないよりは見た方が安全」だからなのですが、確実にテストしなくて良い機能は何なのかというスキルも伝授していく必要があるなと。
---
問題は問題と認識してどうにかしたいとはおもいます。
断続的にでも思い続けていると脳は勝手に検索し続けてある日突然解答がひらめくそうですよ。
---
ちゃんとやろうとすればいくらでもやることはありますが、
スピード重視なので何をやらないかを常に検討すること。
流れる水はきれい
テスト専門担当者が存在することに慣れていないからなのか、
チケットのウォッチャーやPJのMLに私が入ってなくて、
いろんな情報から遅れていることがしばしば。
重要人物のカレンダーを１件１件見にいったりして状況把握しています。
クローズしちゃったチケットについては把握しきれていなく、
ぬかったわ～
流れない水は澱むのですよと言いたい。
改善したいこと：
ソフトウェア工学上のリスク計算かな…
---
実際役にはたたなくても心の拠り所くらいにはなりたいなぁ、なりたいなぁ。
---
バグ分析やふりかえりの実施など着実に草の根的にふりまいて行きたいと思います。
ボトムアップでね。
やればいいのに
できないって思うよりできる方法をみんな必死に
考えれば良いのに
と思います。
---
昨日今日気がついた感じなのですが、私はずっと
「グレーゾーン許容しまくり柔軟タイプ」
だと思っていたのですが、
手を抜くことができなく、全部全力で考えたくて、
（効率化はするけど手は抜けない）
めちゃくちゃゼロイチベースじゃん！
と。
具体的にいうと渦中の開発Lから
「ほどほどにやれば良いのでは？」と助言されたのですが
「ほどほど」がどの程度なのかわからない。
---
筋が通っていないことは嫌い。
---
知れない情報は知れなきゃ知れないでやってみようかと。
---
１年前に私が進言していたときは、
「（障害情報は）機密情報を含むのでプロパーにしか詳細を共有できない」
という硬化な態度であったのですが、最近かなり柔軟に相談されるようになった気がしています。
なんでこんな小さな変化（Redmineのプロジェクト変更）で
小躍りしているのかというと、自分のできることがささやか過ぎて、
常に無力感・徒労感がある中でどうにか自分を奮い立たせて奮い立たせて、
小さな積み重ねを行っていこうとしているからです。
---
新しい決まり事をつくるのって、難しい。
日々勉強です。
---
そもそも私のテストの仕方これで良いのか？
という根源的なところで迷い始めた。
「このくらいはこっちでやる」という「このくらい」のレベル感が共有できてないのじゃないかと。
でうちが実施すべき項目（得意とする領域）を明確にしていないのかと。
特定領域に決めちゃうと、会社（と自分）の価値が落ちると思っているので
曖昧な部分は残していますが、それじゃダメなのかな。
今まで一歩ひいて、野性的勘？ で「ここが危なそう」というアタリをつけてバグ探ししていましたが、そのままだと属人的でダメなのかな、と。
今今は相談する相手もいないので、やってきたことを反映するだけですけどね～…
---
Agile Japanのパネルディスカッションで横塚裕志さんが「底上げはしなくて良い」とおっしゃっていたのが印象的で。
世の中的に「属人性を排除」ってよく言われてたけど、
スピードについていって価値の高いことをするためには、
むしろ属人性を追求すべきなのかなと最近思っていることもありまして。
---
誠実であらねばならぬと思うんですよね。
しびれた
『ソフトウェアテスト２９３の鉄則』Cem Kaner, James Bach, Bret Pettichord
２週間でとれた黒帯など実戦では使えない
↑
ココにしびれた。
---
休みに読んでた書籍をまたチラ見した。
テスト（バグ探索）には認知心理学の知識も必要
やっぱりそうですよねー。
王道をいこう
昨日のISO/IEC/IEEE29119研究会は、たいへんワクテカする内容でしたが、私はもう決めました！
王道をいきます！！ｗ
---
そうだ！ テストカバレッジをきちんと出すことにしよう
---
増員したら進捗率が薔薇色にあがるわけでもないので、
さらなる工夫がひつよう。
アフリカのやつ
ブラックジャックが30人の患者を一気に手術しているイメージです。
イメージね。
---
一応やりきった感。不安がないわけではないけど、
今まで商用で起こった問題は発生しないよね？ の確認を開発Lと
「今回キャッシュサーバたててる？」
「STGは単独構成なのに商用でいきなり冗長化して問題ない？」
などと話している。
---
個人や会社のミッションって、基本は
「こうなりたいから、これをやる」
というポジティブ思考なものかと思っています。
検証会社が言うのもナンなのですが、私たちがやっていることって
障害対応も、そもそもの検証自体も、
「こうなりたくないから、これをやる」と否定形からはいるんですよね。
それも未来志向・ポジティブ思考になるように浸透のさせ方を工夫するすべきなのでしょうけど…
他社（他者）への訴求の仕方も、
「こうなりたいから、これをやる」
という未来志向のものでありたい、と本質的には思います。
---
今まで：情報が来ないなら取りに行く
これから：情報が来る仕組みを考えて定着させる
※フローをつくって発表するだけじゃダメ。運用にのせないと。
...が足りない
最近気づいたけど、「時間が足りない」というのは「頭が足りない」の言い換えではなかろうか。
確かにからだはいけるかもしれないけど、理解するまでに追いつく頭（能力、基礎体力？）が足りてない、というのが真の原因のような...
（予習、復習の時間が思うように確保できない＝頭痛くて集中できないｗ）
でも「頭が足りないです」と宣言するとなんだかものがなしいので言いません。
---
100名に語って60～70名に伝わればいいや、ではなくて
10名に語って10名に理解してもらう方が楽しいのです。
---
終わったステージは振り向かないことにしていたけど、
幾重にも積み重ねていくことが大事なのかもしれない。
覚悟というか矜持というか胆力
結局、自分の発言と行動に、最後まで自分自身で責任をもてるのか、という覚悟の問題な気がします。
何にしても。
最後にケツもつのは上司ですけどね。（私含む）
---
リリース前レビュー。
今日は「総合テストまで実施完了しているから問題ない」発言にちょっとかみつきました。
「総合テストで実施している以外の要件はどこで誰が担保しているのか」と。
やってますよと言われても根拠がない（見えない）ので。
「やってるように見えるから、大丈夫なんだろうな」と思っていて
実は大丈夫じゃなかった経験が今までにあったので、
開発Tレベルの話ではなくプロジェクト全体の主目的になりますけど、
お互いが「自分のやることではない」と思っていたら抜けが出ると思うので。
カッコいい
本日チームメンバーに話したこと：
「業務は与えられるものではなく、つくるもの」
↑
カッコよくないですか！？ｗ
---
資格取得が目的化するのは違うと思う。
実業務に結びついた上での資格勉強なので。
---
データクリーニングミスによる対策案について助言しましたが、
- 工数増やす方向で対策案をださないように
- 過剰品質にならないように
という点は、どのサービス（チーム）にも言えることなのではないかと。
超絶美女
最近はいった常駐開発ベンダの女性のリーダーが超きれいな方なのですが、
初めて声をかけたときの若干不審者を見るような目つきが最高でした。
（話したら良い人でした）
---
毎回思うことですが、お客様にご提案する内容って自分にとっては
ほぼ当たり前のことで、当たり前のことだと思っているから
すらすらと問題点を列挙できるのですが、
当たり前過ぎるゆえに当たり前だと思っていないひとたちとの
ギャップを埋める（表現する）ところが難しいと思っています。
それは仕様書がない理由と同じで、なんで仕様書がなくて済んでいるか
というとメンバー間で脳内補完し合っているからで、
じゃあそもそも仕様書ってなぜ必要なのかというと、
メンバー間で勝手な思い込みや認識齟齬を防ぐための共通認識をもつためのものなので、
その認識がそもそもないのが原因なのかなと。
心していきます。
ワニとかリス
大項目・中項目・小項目の分類について。
今「哺乳類とワニ」とかが同じレベルのところにいるので、
大：哺乳類、爬虫類
中：ヒト、ワニ
小：アメリカンクロコダイル
という風に分類し直してもらいたい、と説明したのですが
自分でも「今私良いこと言った！？」と言いふらしたくなるほどわかりやすいんじゃないかと思いました。
※例は、その場の思いつきです。
もっと可愛いのにすれば良かった。リスとか。
---
（レビュー時は）「勇気を出して発言しましょう」という言い分が意外とHITした件。
片思い
先週はJaSST'15Tokyoに２日間参加させていただきありがとうございました。
でもテスト側の方は四方を開発エンジニアの方をみて話しているのに、
同時期開催しているデブサミのセッション内容みたら「品質」みたいなテーマは１つもなくて笑えましたw
片思いじゃん！
---
要件をしっかり決めて、ブレずに開発を進めることって、難しいと思いますが、大切ですよね。
一方で変化する世情（ビジネス要件）に合わせて柔軟に仕様変更することも大切。
どちらにすべきかは、その時々のいろんな都合によるのかなと。
ただ政治要件とか、誰も幸せにならないような要件にしないという
強い意志だけはもっていたい。
レビューのコツ的なもの
- 「逆だったらどうか？」を考える
- 「他に条件はないか？」を考える
- 「本来の目的は何か？」を考える
- 「これをやって誰が嬉しいか？」を考える
- 「これをやったことで損ねる機能（要件）はないのか？」を考える
---
個人的には「少しでも んっ！？ と思った違和感をそのままにせず再確認を重ねること」だと思っています。
あとから判明した問題って実は、前にちょっとだけ不安要素が頭をよぎっていたんだよねー
と思うことしばしば。
自動化あるある
自動化対応の件、今月より本格稼働できる動きとなりました。
どの現場でもあると思いますが、
1. 最初は興味津々、ノリノリで食いつく
2. 具体的に始めてみると「予算が…」とか「タイミング的に…」とか言い出す
3. メリット、実施方針、目的を軌道修正しながら実装予算を獲得
の段階を踏むんだなぁと実感。
今回はどこからどのように自動化を着手したら良いのかお客様が迷われている感じだったので（初めてなのでわからないんだと思う）
「バージョンアップしても仕様がかわらない基本機能から着手すると良いと思います」
「目的はリグレッションテストの工数削減がメインだと思ってます」
というお話をして納得をいただきました。
---
自動化しやすいテストケースの書き方：
- １つの手順に１つの期待結果を書く
- なるべく粒度を細かくする
リグレッションテスト書き換えはひとまずコレでいってみようと思います。
---
余分なテスト工数を減らすこと、減らして良い根拠と説得材料をもつこと。
炎は自動的に耳目を集める
私の場合、「みんなが見てない方向をみるようにする」というやり方でやってます。
自分的に「逆張り」と呼んでます。
大きな障害が起こったときがわかりやすいんですけど、
大きな障害が起こると大体の人の目と気持ちは一斉にそこに向けられるのでむしろ安心で、
「じゃあそれによってないがしろにされる部分は何か？」
を必死に考えます。
（レビューも同じですね）
---
同じ誤字脱字でも軽く看過できるものと
ちょっと違うだけで大問題になる誤字脱字がある。
IR系数字や桁数、スケジュール調整時の日付曜日違いとか。
誤字脱字をあなどってはいけない。
---
クリティカルな事象ではないのでそこまで丁寧にやるのかというのは常にコストバランスとの戦いですが、品質管理担当としては
「で、いつします？ コードレビュー（にっこり）」
というスタンスでいるのが正だと思う。
品質という観点から何を目的にしたいのか
- できるだけバグをたくさん発見して修正したいのか。 ⇒であれば探索的テスト＆エラー推測
- 正常系が問題ないことを担保した状態でリリースしたいのか。 ⇒正常系のテスト仕様つくって実施
- 仕様書に記載された内容が実装されていることを確認したいのか。 ⇒仕様書から起こしたテストケース通りに実施
---
今自分が持っている常識が通用しない世界では最低限守ることは守るけど、
常識を変えていかなくちゃいけないんだなーと感じる。
そういうのがアジャイルテスティングではないか、と。
---
（きちんと計画はたてていたけど予定していたテストを中断し他のテスト方法を模索することにして）
「そもそも予定していたテストをすべてやり切ることが品質をあげる方法（目的）だとは既に思っていないんです（キリッ）」
と言い切りました。
決められたことを決められた通りに実行するのではなく、
状況に合わせて実行内容を考え変えていくものである。
---
航空会社のサイトはどうして乗り方を説明してないのか
続・航空会社のサイトはどうして乗り方を説明してないのか
やっぱり思ったことは、「システムって大概傲慢だよなぁ」ということ。
これ、飛行機の話ではないですよね。
「システム」はIT技術をつかったシステムのみならず、まさに組織・体制という部分のシステムも含みます。
（傲慢な部分も必要ですけどね。ターゲティングとか。）
日常的に接している（扱っている）システムというやつは
根本的にはそんな傲慢なやつなんだよということを
うすーくでも意識しているかしていないかで
目指す方向とか解決すべき課題が変わってくると思います。
---
普段から障害対応（「まだ正常系完璧にできてないから異常系本気で見なくて良し」など）をやや意識的にトリアージして優先事項と後回し事項を勝手に脳内で決めているけど、最初から出し切るようにした方が良いのだろうか。
---
本質的には我々「品質をあげる」ことが大命題なので、
迷ったらそこに立ち返ることが肝ではないかなと。
---
細かいミスはね、どうでも良いと思うんですよ...
誰でもミスをするものだから、ミスをしない仕組みにしましょうというのが
品質管理者の仕事だと思うので。
もっとも大事なことはミスしないことではなくて（それも大事だけど）
ミスった後のリカバリーだと思ってます。
（早く・正確に・フォローアップ）
---
テキストマイニングツールつかってNGワードチェッカーみたいのできないかなぁ。
---
私は銀の弾丸ではない。
というか銀の弾丸というものは、ない。
ホワイトボックステストとブラックボックステスト どっちが良いか？
「テストスケジュールが明らかに逼迫している場合、開発者目線で
ホワイトボックステストとブラックボックステストどっちをやる？」と聞いたら
「要件をチェックできるのはブラックボックスだからブラックボックスやる。
コードの正しさを証明しても要件がそもそも間違ってたら（サービスとして）意味ない」というお返事でした。
うん、要件が落ちてくるときに間違えてたら確かにコードカバレッジをいくらあげてもダメですよねー。
私は「結果で示す」は、たくさんバグをあげることじゃないかと思ってます。
これここで見つかってなかったらこのまま市場にでちゃいますよ！？
をどれだけ真摯にわかってもらえるか、かなぁ。
この前、どこの記事で見たのか忘れたけど、
「開発者は状況的に追い込まれている場合、バグが見つかると凹む」という記事。
本来は
「ここで見つかって良かったー！」
「このままリリースしてたら超ヤバかったよ！（復旧作業も）」
と喜ぶところ、リリース寸前までがんばってきた開発者にはただの追い打ちにしかならない、と。
まーそれもそうだね。
もっと自分たちの「気持ち」として、現場の話をみんなとするのも楽しいでしょうねー。
---
何かをモノにする（習熟する）ためには結局、質もあるけど、かけた時間の総量というのがすごく大きな意味をもつということが実感としてあって、その場合「何をやるか」より、「何をやらないか」に余程気をつかわないと時間が足りないという状況になる。
私の思うWモデル
私の考えるWモデルは「上流工程に寄り添って協調して品質向上に寄与する」です。
テストの他にもやることあるだろと。
---
リグレッションテストのスコープについてディレクターと見解の相違。
「今まで慣習的に全部実施」→「それいらないっす」と言ったので議論が進みそう。今回分から改善の流れにできるかも。
誰かが「王様は裸じゃないか」って言わないと、（by THE BLUE HEARTS）
やること増えていくだけですからね。
「いらない」というのは勇気と責任が伴うけど
ロジカルに考えてバランスとれば良いだけだよねぇ、と思います。
---
効果がないならやめる勇気。
---
レビューアが不在とのことですが、テスト計画書の目的は
・客先と自分たち（ステークホルダー）が納得できる共通認識をもつこと
なので、レビュー承認されているのであればひとまずOKかと思います。
大事なことは
「このテストでこれをやる/やらないを明確にしてお互いのビジネスリスクを避けること」
---
10年くらい前は、「人心掌握術が欲しい」と、切に願っていました。
特に何かをした（セミナー受けるとか）わけではないけれど、
今となっては望んでいたスキルはなんとなく身についたような気がします。
「人心掌握」ではなく、別の形でとらえることができたんだと思います。
クローズしたバグチケをReOpenすること
表面上の事象は2件あるバグチケットについて、「こういうデータだったから問題なし」という調査結果がでていったん納得して数日前にクローズしていたのだけど
昨日やっぱり1件の事象について整合性とれてないのではと思い直し、
ReOpenして再調査を依頼したら、システム側不備だった。
食いついてよかった。
そう思ったのは自分でもテストしたからなので、マネジメントだけでなく
やっぱり自分でもテストすること大事。
---
担当PJ外のチケットを読んで「あーこんなバグ出てるのか。気をつけよ」とか
「このPJとあのPJで同じバグ出てるじゃん。横展開システムつくりたいな」とか
妄想してる時間は何に相当するのだろう。
（遠まわしに）「テスト設計」（の一部）？
---
（ほら、DevOpsにQAがはいっていない。）
プロジェクト ◯
何が言いたいかと言うと、
一見無駄にみえる長期目線の取り組みに対して拙速な期待を求められたくないし
あらゆるものに費用対効果とか言われたくない
合理的であれば良いってもんじゃない
BGMはもちろん中島みゆき『地上の星』です
脳内ナレーションは田口トモロヲでお願いします。
---
いうまでもなくコーディング中のスペルミス（タイポ）はバグの温床となり得る。
今仮に正常に動作していたとしても外部APIの呼び出しや他モジュールとの結合時
正しいスペルでなく誤ったスペルでないと動かないことになり影響度大。
もちろん判明した場合は指摘の対象。
---
「一歩遅れどころか、周回遅れ」
先日のAgileJapanでも聞いたせりふ。
どのように追いつき、追い越すことができるのか、私も考える。
肩叩き券のつかいかた
ソニックガーデンの『納品しない受託開発』が大好きな私ですが、
満足いくテストをするために予定時間ばっつんで切るのがイヤで
（探索的テストをしているテスターを途中で無理にとめてはいけない。
満足するまで実施させなければならない。という格言もあります）
他のプロジェクト対応がないときは限界まで検討して良いと思う。
肩叩き券は10分たったら終わり。
ではなくて、相手が気持ちよくなってなんぼだろう？
---
障害分析をするにもロジックツリーをまず明確にすることなんだけど、
話しているうちにこれSaPIDでやった方が良いのかな...
と浮気したくなる。
ドラえもんがポケットの中から適切（？）な道具をだすように、
その場（状況）にあったツールの選択をしたいです。
---
組み合わせテストの「組み合せ」は技法を良い感じに適当に組み合わせれば良いらしいです。
やったー。
で欠陥ベーステストは別建てて考えるとスッキリする。
そうか。
私は組み合わせをリスクベースで考えていたんだ。
分離すれば良いんだ。
なんでデザイナーさんって大体さわやかイケメンなんでしょうか
担当中アプリのデザイナーさんが物腰やわらかな爽やかイケメンなのですが、
デザインだしたLPに対して企画側が「もっとこう」とか大して根拠なさそうな
好みを押し付けてくるのを傍からみていて私は
「何それ？！ 思いつきで言ってない？」
と勝手に憤慨しているのに対し（見てるだけで口ださないけど）そのイケメンは
理論的に、かといって冷たい感じでもなく
「来期の目標ってあります？」
「考慮した上で設計した方が良い気がしてきました」
「とはいえご希望に沿える形で検討してみますね」
と大層イケメンっぷりで応答していてすげーイケメンだと思った。
---
今日はさわやかイケメンの真似がちょっとできた
（と思う）
---
これテストで見つけるのはすごく難しいなぁと思うけど、
エージングテストとかやりようはあるし、チームでいろんなリスクを共有して
潰しながら進めていくスタイルにすればかなり共有知になるんじゃないかなぁと思ってます。
SECIモデル重要。
どんなやりようでもリスクを100％潰すことは不可能さ。
向かうべきはフェイルセーフの考え方じゃないかな。
---
めんどくさい ＝ 非効率、手間がかかる ＝ 高コスト
⇒なんとかしてめんどくさくないようにしようと工夫する
なので、めんどくさいと思う気持ち、大事。
webのQA とは
ここ数か月くらいでずっと考えていることだけど、組み込みに比べてwebは必要な開発工程・テスト工程をはしょることが多いから、どこをとってどれをやらないかのバランスが超重要。
と今までは思っていたのが、（組み込みとの比較ではなく）
「webはwebなりの開発モデル・テストモデルで進めることが最適なのではないか」と最近は思うようになりました。
webの最適なテストモデルを体系化することが私のミッションだと思うようになった。
---
「人手が足りないなら人を増やせばイイじゃない」（マリーアントワネット風味）
みたいな発言を聞くたびに
「じゃあ優秀なエンジニア100人集めたら1日で終わると思ってるんですかっ！？？」
と叫びたい私の気持ちは「ブルックスの法則」っていうのか。覚えとこ。
---
どんなに小さな話題であっても、MTG時に話すための土台として資料を作成していくということは、
「この資料を説明している間は自分に話の主導権がある」という意思表示でもあるのだなと突然悟った。
資料見せながら話している間は大抵口は挟まれないので。
---
マニュアルって事務的であるよりも、情緒的につくった方が良いんだろうか。
このルールなのはこうしたいため…！ みたいな熱いパッション、みたいな。
---
今乗っている機はゼロ戦ではない。
ボタン１回押すだけだが
マイクロソフトのエバンジェリスト牛尾さんのTwitterで
「失敗したら責任をとるという考え方はなくて失敗したら何をするかをチームで考えれば良いだけじゃん」（意訳）という発言を猛烈にリツイートしました。
フェイルセーフの考え方をチームビルディングにも適用、と理解しました。
---
誤字脱字系やタスク漏れのミスが多いのは人間のうっかりミスなので、
ソフトウェアにおける「ポカヨケ」の方法を調べました。
…ソフトウェアの事例はあまりたくさんありませんが、根底となるヒントを得ました。たぶん。
---
なんとなく知っていたけど、ソフトウェア開発って、ソフトウェアテストって、
本当にエンジニアリングそのものでない問題が多いことよ。
政治とかネゴとかヒューマンエラーとかさ…
セキュリティサムライ
世の中には「脆弱性診断士」なる職種のシラバスとスキルマップが定義されているのですね。
「士」ってカッコいいなー。サムライじゃないか！
…と、ウキウキしているだけでなく、脆弱性診断で保証している内容は総合テストのスコープ外にして良いんだなとか、それでセキュリティ要件として総合テストで狙うバグって何だっけ？ とか考慮すべき点があるので自分も理解しないといけないです。
---
「できない」って言って自分の限界を決めるのよくない
そうしたら「現時点の自分ができること」しか一生できない人生になっちゃいますよね。
---
無事リリースしたと伝えられたサイトにあとから検証スコープ外で事故が起こったことを知らされると胸が痛みます。
---
おらにみんなの力を貸してください。
---
サービスを成熟させるって難しい。
でもこの「走りながらつくっていく」感は好き。
「にほんごって難しいですよね」とは言いたくない
最近、「ご確認ください」がだいぶマジックワードだなーと気がつき始めた。
いろいろな意味を含んでいて、
「わかる人にはわかるけど別の文化圏ではわかりづらい」ことになる。
きっかけは、先日の本番チェック時普段接していないディレクターへ
ツールのリンクチェック結果を「ご確認ください」と投げたときに
「確認って何を確認すれば良いっすか？？」と返答がきた件。
普段は「自明でしょ？」「全部言わせんな恥ずかしい///」みたいなことが
具体的に何をして欲しいのか、きちんと伝えることが必要なんだなーと思いました。
なので最近は「ご対応を検討ください」とか「対応要否を判断ください」とかで
「ご確認ください」以外の言い方で表現するように努めています。
---
情報セキュリティ研修だけではなくて、人へのメッセージってそれぞれの立場で気をつかわないといけないし、中庸な立場を意識し過ぎると玉虫色な内容になって意味をなさなくなるし立場ごとの具体例を書き過ぎるとイレギュラーケースの処理がしにくいしで難しいけど、憲法と法律みたいなものだと思ってがんばります。
全裸過ぎる
本日の私のありのまま過ぎる発言について、苦笑いされながら窘められました。
「あれは、全裸！ 風呂あがりの全裸」
「わかりました〜 葉っぱくらいつけろってことですね〜」
→ほんとにわかったのか？ 自分。
---
慣れてないから時間がかかるという理由でやらないでいるとずっと慣れないから
時間がかかる状態から一向に抜け出せないということはわかっているのです。
やれば良いだけ。
私 とは
（何も整っていない状況なので）「こういうの好きでしょ？」
と言われその通りなんだけど、性癖バレたみたいな恥ずかしさが若干あります。
---
「仕組み化」というのは「標準化」というオーソドックスな名前がついてたなと。
細かいレベルでも「標準化」と呼べば周りを納得させやすいと思いました。
---
やさしくわかりやすくタイミングよく正論を伝えるのって難しいぞ。
オブラート力 たのむ
オブラート力を発揮するには「とりあえず丁寧語に置き換えて丁寧に説明する」こと。
でも私がやるとフリーザみたいになりそうだナー。
---
QAのスコープって、開発側で何をやるのかを知った上でのバランス感覚なんだと思っていたけど、別のアプローチがありそうだ。
（答えはまだない。）
---
「別のアプローチ」がわかった気がしました。
「コンテキストスイッチをしやすくするための業務フロー」なだけな気がしてきました。
スコープを分担するのは、品質を下げるリスクがあるので危険。
---
「正していく」というより、その中で適切な検証を行うにはどうすれば良いか？
を模索することが最適解の方向だと思う。
おしまい
ここまでお読みくださり、ありがとうございました。10年の間に考えもいろいろ変わっているので「コレ違うのでは？」とか思われるところもあるかもしれませんがご容赦ください。（成長とは進化です！）
QA以外のひとが「QAってこんなふうに考えてるんだな」とか感じられたりこれからQAを目指すひとの参考になれば幸いです。
この記事が気に入ったらサポートをしてみませんか？