2021年の振り返り<上半期>

blog

年初、2021年の上半期の目標を立ててみました。 半年経ったので、振り返ってみます。

ふりかえり - 仕事

総括

課題意識を実現可能な行動パターンに落とし込めず、具体的な成果は上げられなかった。 しかし、QAの方向性/歩幅を見定めることはできた。

~Q1(1~3月) - QA立ち上げ

1~3月でMgrと何度も話し合い、4月に、関わっているプロダクトの開発ユニット内にQAチームが立ち上がりました。 主にテストをするメンバーのチーム、というよりは品質向上のために何でもやるチームとして立ち上がりました。 現在自分含めて2名体制で、チーム横断的な要件定義レビューやプロセス改善を進めています。

チームの取り組みについて、JaSST nanoで登壇しました。 speakerdeck.com

Q1(4~6月) - QAの走り出し

期初は、ざっくりとテスト開発改善や開発プロセス改善をスコープに入れていました。"何でもやる"ので、スコープを絞らずにできることを1つずつやっていけばいいと考えていました。

上記スライドにも一部書いていますが、チーム横断的なQAとして以下を行いました。

  • 品質特性を通して要件を捉え、各要件の品質目標を立てる取り組み
  • チーム横断的な要件定義レビュー
  • 他チームを巻き込んだ仕様検討の斡旋
  • テスト開発技法の調査 / 検討
  • 各種チケットのテンプレート改善
  • 市場障害分析
  • QAポータルを通したQA活動の周知、テスト技術の発信

主には、要件定義工程とテスト設計の工程に対してのアクションになりました。

要件定義工程の取り組みについて

開発経験が豊富にあるわけではなかったので、日々開発メンバーに教えてもらいながら、要件定義工程に参画していきました。 要件定義において何か見落としや考慮洩れが発生してしまわないかをレビュアーとして見たり、仕様検討に迷ったときには "開発チームだけで悩むのではなく他チームも巻き込む" ことを実践したりしました。

考慮洩れを防げた場面も幾つかありましたが、それよりも自分のドメイン知識不足を痛感しました。 プロダクトの技術的な背景やビジネスの歴史を知り、年月の中でどのような思想を基に作られてきたのかを理解しないことには、上流工程のレビューでチームに貢献するのは難しいなと感じました。

テスト設計まわりの取り組みについて

テスト設計については、テストドキュメントの作られ方がバラバラという事情があったので、"まずはそこを改善できないか"という意識でVSTePやゆもつよメソッドをはじめとするテスト開発手法の調査/検討を行いました。

Q1では他にもQAで行いたいことが沢山あり、ここに割けた時間はあまり多くありませんでした。結果、大きく何かが変わったという成果はなく、期初の状態を維持したままスポットスポットでテスト設計レビューに入ったり、テスト設計用のテンプレートを少し改修するだけとなりました。

そのほかの取り組みについて

そのほかには、市場障害分析やQA活動/テスト技術の発信を行いました。

市場障害分析では、その月に発見された市場障害のうち原因が明確になったものの埋め込み原因深堀と対策検討を行いました。1件1件にかけられる時間が少ない 且つ QAの体力があまりなかったので、同様の障害を今後拾うためのテスト観点追加やレビュー観点追加といった対策に落ち着きました。

また、QAの取り組みを改善していくにあたりメンバーからのフィードバックが欲しいと思い、QAポータルを作りQA活動の発信を行いました。 ポータルを通して、QAが要件定義レビューのときにどういうことを考えているか、またQAがQAの取り組みに対してどういう課題感を抱いているかなどを発信しました。 ありがたいことに多くのメンバーから反応を頂くことができ、メンバーからの質問や要望を起点にした活動の改善を実現できました。

QAポータルではテスト技術についても発信していて、JSTQB FLシラバスの内容やGoogle Testing Blogの記事の紹介などを行っています。バリバリ開発しているメンバーの中にはテストに興味を示してくださっている方も多く、そういうメンバーの取っ掛かりになるように、草の根活動みたいな意識でやっています。

->Q2(7~9月) - 開発チームの改善を加速させるQAを目指して

上述した通り、Q1では色んなことに手を出しました。色んなことに手を出してみた結果、

  • 手広くやりすぎると具体的な改善に繋がらない
  • 開発ユニット内のQAだからこそできることがある

ことを実感しました。

"品質向上のために何でもやる" とは言っても、"品質向上のために同時に何でもやる" 訳ではないよな、とQ1をふりかえって反省しました。 手を広げすぎて1つ1つのアクションに割くリソースが少なくなれば、当然それぞれのアクションを通したチーム/プロダクトへの貢献度合いも小さくなってしまいます。

また、"QA = テストする" という意識があったのか、上流工程へのQAアクション = レビューと思い込んでいた節がありました。 レビューによっても勿論貢献できると思いますが、それだとレビュアーが増えただけになってしまいます。 つまり、Q1のQAの取り組みは西先生が言うところの"労働のスケールアップ"になっていて、"知のスケールアウト"になっていなかったのです。

ふりかえりから上記の気づきを得たので、Q2からは開発チームの改善を加速させるQAを目指して、以下をテーマに活動することにしました。

  • QAの大きな構想を抱きつつ、フェーズごとに特定領域にスコープする。Q2では上流工程にフォーカスする
  • 開発ユニット内のQAとして、開発メンバーと同じ目線に立って一緒に改善策を考えていく。知と知を持ち寄って、ユニット全体で改善していく

このテーマを基に、Q2では品質保証の知識やテスト技術だけでなくソフトスキルも向上させていきたいです。

(しごとのふりかえりおわり)

ふりかえり - 個人的な勉強

仕事のふりかえりで満足してしまったので、ごく簡単にふりかえります。 目標未達だとやっぱり気分が下がるので、下半期は"これを勉強する！"という目標は特に発信しないで、日々勉強して気づいたことがあればブログで発信していこうと思いました。

対・目標

肝心の、目標に対する進捗ですが…。思っていたより勉強しなかった。。

web
インフラ
  • イラストでわかる DockerとKubernetesgihyo.jp
    • 買いませんでした。
  • コスパのいいシステムの作り方gihyo.jp
    • 3章まで読んで、それっきりでした。
android
  • Androidテスト全書peaks.cc
    • 2章まで読んで、それっきりでした。
QA
  • JSTQB FLjstqb.jp
    • 受験しました。合格しました。
  • SQuBOK Guide V3www.ohmsha.co.jp
    • 2章まで読んで、3章をつまみ食いしました。
エンジニアリング

目標に入れていなくて、勉強したこと

QA
エンジニアリング
  • エンジニアリング組織論への招待gihyo.jp
    • 読みました。

(べんきょうのふりかえりおわり)