JaSST'20 Kansai 参加報告(1)

JaSST'20 Kansai*1に初参加しました。

 

今更ながら参加レポートを書けるとこまで書きます。

 

2020/9/26(土)に「テストについての分解・再構築」というテーマでJaSST'20 Kansaiが開催されました。

「テストについての分解・再構築」って聞いた時、正直私は何のこと言ってるかわかりませんでしたが、ざっくりいうとテスト(要求)分析の話ということで、とても楽しく聴講させていただきました。

f:id:usk_ymst_p:20201031183808p:plain

「テスト設計コンテスト'20  U-30クラス チュートリアル」より


基調講演:「テストの視点でシステムを分析する」
望月 信昭様(ウェブレッジ)
(一言で乱暴に要約)テスト設計する人として:「テスト技法で使うモデルで理解する」

堀川 透陽様(ベリサーブ)
(一言で乱暴に要約)テストベンダーとして:「USDMなどで要求から再構築/テストアプローチを土台から変える」

江添 智之様(バルテス)
(一言で乱暴に要約)アジャイルQAとして:「バックログを評価しよう」*2

 

三者検証会社でQA/テストエンジニアとして実際に働いてらっしゃるお三方の講演でした。QA/テストエンジニアとして第三者の立場でプロジェクトに入っていくとなると、「いかに素早くそのプロダクトを理解できるか」が大切な要素になってくるのかなと想像します。

 

望月様の「テスト分析でテスト技法を使う」は、実際にお聞きしている時は「そうだよね〜」と聞き流していました。

しかし、今になってよくよく考えるとテスト技法はカバレッジするために使っていることの方が多い気がするので、実は自分にはない新しい使い方でした。

「ただ立ち尽くすよりかは道具を使え」って意図だと理解しました。

私としては「テスト分析でテスト技法を使って何を導出するんだろう?」と思ってしまうのですが、もしかしたらここではテスト分析以前のまだ定義されていないテスト開発アクティビティを実施しているのかなーと今は思っています。

 

堀川様と江添様の発表は、いわゆる下流工程としてのテストだけでなく、プロダクトの要求にもテストの視点で品質を良くしていこう*3という方向性になっていってるのが面白いなあと感じました。

 

とりあえずここまで参加レポートを書きました。もう最後かもしれない。

*1:JaSST'20 Kansai ってなんて読むんでしょうね?「ジャストニジュウカンサイ」って「ジュウロクビート」感あります。

*2:本当のことを言うと、このセッションはあまり理解できませんでした。。すみません。。

*3:シフトレフトと言うらしいです

営業とエンジニアの業績評価のちがい

エンジニアという職種になってから地味に困っていることがあります。
「業績評価」というやつです。
半年ごとに目標を設定して、立場が上の人が半年ごとに達成度を見てボーナスが決まるってやつ。

 

私の前職は営業だったのですが、当時は実に簡単でした。
部署全体の数字から、自分が受け持つべき数字が妥当であり、
自分が持っている顧客から引っ張れる作戦があれば目標としてはOK。

あとは数字とにらめっこしながら、目標に対する計画を都度変更して達成すればいい。

(この辺は会社によるかも)
半年後に数字だけ確認したらおしまいでした。

 

営業にとっての売上目標は職種に張り付いたミッションで、それ自身は取替ようがありませんでした。どんな手段を取ってでも達成すべきもので、多少のトラブルや失敗、環境や働き方の変化など問題にはなりません。

取れるか取れないかだけ。あとはどうしようが自由。
たとえ1件受注に失敗しても、別の受注でリカバーが取れる。(仕事によっちゃ取れない)
半年に何件受注するにせよ、複数回チャレンジする権利がある。あるいはそうせざるを得ない。

 

エンジニアになってからの目標設定はなかなか難しいです。

資格取得などの定量的であっても1か0でしかないものであったり、残業時間を〇〇減らすなど場合、「失敗した場合」「目標が間違っている場合」「環境の変化」に一切対応できない。

チームのあり方が変わって仕事自体が変わってマネジメントなどの単価が高くなるような仕事に変わっても目標を達成できないなどの不便なこともあります。

 

特にSESのエンジニアは、ミッションに対する裁量が少ないのでやりにくい。

営業って職種が裁量でかいだけかもしれないけど。

 

エンジニアという職種に張り付いたミッションで、
複数回チャレンジできるものとはなんだろう?と考えています。

ましてや私の仕事は第三者検証のソフトウェアテストで、軽々しく失敗できるものではない。
どうすればこの先生きのこれるのだろうか。。



実際は現時点(2020/3/29)でそれに対する仮説として、
ジャーニーでやる業績評価を考えてやろうとしています。
そのうち気が向いたら書きます。

記事の下書き(本番はないかもしれない)

この記事の目的

  • 表立った目的
    • まるで何も書いてないので何か書く
  • 邪な目的
    • 自分が生きていた痕跡を何かしらの形で残すので見てほしい
    • 他のチームで似たような意識の人がいたらDIFFを取りたい

前提

2018年度テスト設計コンテストの反省 (そのうち文章でまとめたい)

  • 学びたいという気持ちは共通していたけど、いまいち学べなかった
    • 手を動かさないと学べないことがあることはわかった
    • 一方で何を学んだらいいかわからないことがあることもわかった
  • 成果物を作り上げること(=終わらせること)に必死だった
    • その結果、ふりかえりもむきなおりもできなかった
  • 仮説が生まれたこともある
    • チームでやるテスト開発はテスト設計技術だけやっときゃいいってものでもない
    • ソフトウェアとちがって基本的には動かないはず。だからこそきめ細やかな調整が必要になる

2019年度に社内でやった「勝手にやる勉強会」の総括

  • 「一人プレイSESの孤独」=>「同じ課題を共有するエンジニア(仮)の集まり」になった (そのうち文章でまとめたい)
  • 思いつきで2時間程度の勉強会を単発でやっって手を動かして学んでも、実は次に繋がらない。
    • だからといって、自分が決めたことが自分自身の制約になることは本気でいやだった。
  • 「次は何するか」が出発になってしまう。

次の展望

  • 「プロダクト」と「チーム」の両方を成長させることを学ぶ
  • 「目標」を立てて成果物を作る
    • ふりかえりと目的地の変更をしやすくすることが目的
  • 仕組み作り
    • 「自分が何をしているのか」を常に確認できる仕組み。
    • 「自分はどうしたいのか」をいつでも問い直せるような仕組み。
  • PDCAではなく、OODAでやることを決める
    • 観察、必要な方向性を決める、意思決定、行動

JCSQE初級受けてきた。

JCSQE初級受けてきた。

  • [日時]2019/11/16
  • [場所] 大阪

    問題について

規格とかはよく勉強しといたほうがよかったかなー。
個々の語句やSQuBOKガイドの記載を熟読して知っているか否かって感じです。  

私はさっさと終えて20分問題、15分見直し、残り瞑想って感じでしたが、
周りは結構50分くらいまでやってる感じでした。

学習方法について

どうやって勉強したらいいか?

レベル1

  • 基本はSQuBOK熟読
  • 問題集は問題回答覚えるまでやって質問形式に慣れる

レベル2

  • シラバスに記載してある用語、概念について知識レベルに到達しているかセルフチェック。到達していなければSQuBOK再熟読。
  • 規格の場合、もともとのPDFを会社などで所有していたら、確認するといいかもしれない。試しにググってみてもいいかもしれない。しらんけど。

学習する意義は?

勝手にリンク貼ってますが、 suhahideさんのnote を見たらいいと思います。

んで、テストやってる人にとっての意義について個人的な見解を書くと、
今どきのテストやってるひと(=QAって名乗ってる人たち)コミュニティでは、
そこそこ当たり前にあるべき知識体系なんじゃないかなって思っています。

"上流工程で欠陥の作り込みを予防"って言ったりしていますが、
何でもウォーターフォールのサケの滝のぼりみたいな感じで語るよりも、
開発とQAが一体となって品質を高める取り組みについて真面目に考えることが、
特に東京では普通のことなんだろうな、と思っています。

資格がキャリアアップに役に立つかといえば微妙。。。
初級でなにかできるってわけでもないしなあ。。

SQuBOKを読んでみてよかったところ

SQuBOKを読んでみてよかったところ

三者検証会社のQAとして

  • 品質保証として行き詰まった時に、「何ができるか」「何を調べたらいいのか」というインデックスとして利用できる。
  • 問題としている分野、得意としている分野が品質保証の知識体系としてどの部分に位置するか知ることができる。
  • JSTQB FLと同時に取るといいかなって思ったりもしました。