このブログは私のチラシの裏なので何を書いても良いのであった（枕詞）
そもそもなんで参加しようと思ったか。
ここ1年以上、知識を得るモチベーションが下がっているを通り越して、関わるのが怖いまでいっていて
うげーとなってしまうことが増えていたので、それを払拭したかったから。
こんな動機は書かない方が良いのではという気持ちをひしひし感じつつ
私が抱えている劣等感と、知識を得ることは切り離していきたいので書いておきます。
私はQAではなく、テスト計画を立てる人間でも、プロジェクトマネージャでもない。
たまにテストを設計しつつテストを実行する第三者検証の人間です。
品質に横断的な知識が「実際の業務で」「これから必要になるか」と考えた場合NOになってしまうこともあると思う。
でも、このQAではなく、テスト設計者としても特化しておらず、ただしテストには関わっている
という自分の状態を認識しないといつまでたってもイイハナシダナ～（けど関係ないよね）みたいなモヤモヤを払拭できない気がしました。
自分の視座を許容しつつ粛々と知識を得られれば、それが一番いいかなと。
テスト実行者やチェッカーは打鍵してれば品質の知識いらないよね！と言われる日がきたらそれが私が知識いらないよねって腑に落ちるタイミングかなと思います。
立場によって聞かなくていいよねがない（と思いたい）
全然劣等感と知識がどうこうを切り離すことができていなかった。
1年間テスト系の勉強会など全くのぞいてなかったのですが、それでも業務がテストの端くれなので無縁でいられないんだなあ…と思ったのが今年です。
無縁でいられないなら、自分のできる範囲でできることをのほほんとした方がいいよねと。
いつも通りとりとめもなくなってきました。
せっかくの機会なのでテーマの「シフトレフト」について雑感をかいておこうと思います。
テスト7原則のうちの「早期テストで時間とコストを節約」に言われるようにソフト開発の早いうちに欠陥を取り除くといいですよね（まんまや）
私は関わっているプロセス上、テストを作っているときに仕様の「？」なところを見つけられれば、実行の時に見つかるより楽だなあ
（というか、実行者の時間や原因究明の時間を使わなくて済むなあ）と思います。
もっと前、それこそ要件定義をするとき、仕様のさらに前の段階で、こういう作りこみをしたら将来どのようなリスクがあるか？を想定して
作れると、後でしみじみと良かったなあと思うこともありますよね。
でも、それをするには、ドメイン知識や「こんな仕様にしたらこれがやばかった」の知識がないと難しく、つまり可能性を広げて考える視野が必要なんだろうなあと思います。
多分、今度の話は、品質の知識をもってソフトを作りこむ前にリスクを取り除いてく的な話なのかなと思いますが多分ちがいます。
初めてJaSST Reviewを聞いてから4年の月日が経ち、加速もなんもしなければ文章のやばさもレポートの書けなさも全然変わりませんが、とりあえずいってきます。
