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

blog

前回のブログでは、上半期の振り返りを行いました。 半年経ったので、振り返ります。

ふりかえり - 仕事

総括

現状の整理・モデリングを通じて、品質改善のための議論の土壌を整えた。 また、コミュニケーションを重視することで、現場のメンバーにとって役に立つ、また効果を感じるようなQA施策を少しずつ提案できるようになってきた。 「データを用いて仮説検証する能力」、「具体的で効果の出る施策を提案する能力」が不足しているため、仕事に向き合うと同時に知識を獲得していく姿勢を強める必要がある。(永遠のテーマな気もする)

Q2(7~9月) - コミュニケーション重視型のQAへ

開発チームの改善を加速させるQAをキーワードに、開発チームとのコミュニケーションを重視して以下を行いました。

  • 上半期から継続して行ったこと
    • 品質特性を通して要件を捉え、各要件の品質目標を立てる取り組み
    • チーム横断的な要件定義レビュー
    • 各種チケットのテンプレート改善
    • 市場障害分析
    • QAポータルを通したQA活動の周知、テスト技術の発信
  • 下半期から新たに始めたこと
    • 各開発チームとの週2回のミーティング
    • バグチケット分析
    • レビュー記録表の作成~集計分析
    • レビュープロセスの整理・拡充

下半期から新たに始めたことの中で特に効果を感じたのが、各開発チームとの週2回のミーティングでした。QA施策の是非の相談から、チームがそのとき困っていることのヒアリングまで行うことができ、同じ目線を保ちながら品質改善活動を行う推進力となりました。 QAから質問するだけじゃなく、ある話題について "QAとしてはどう考えるか" を逆に聞いてもらえたりして、「問題 vs 私たち」という構図を色んな場面で作れたのは良かったなと思います。

バグチケット分析やレビュー記録表の分析は正直上手くいっておらず、メトリクスの導出に壁を感じています。

Q3(10~12月) - 可視化するQA

現状の可視化をキーワードに、特に開発プロセスの整理に挑みました。 …というのも、9月末に山本くにおさんにQA業務の相談をさせていただける機会をいただき、そこで"現状を正しく知ることが重要"ということを教わったためです。 今もTwitterから相談に乗っていただけるようなので、QA全般困りごとを抱えている方はぜひ。(くにおさん、時間を割いていただき本当にありがとうございました。)

現状の可視化として具体的に行えたことは、主に以下になります。

  • 各プロセスのI / Oをヒアリング
  • チームで検討するときの考え方、判断基準などをヒアリング
  • 各チームからのヒアリング内容を踏まえて、現状のPFDを作成
  • 開発チームも作成に関わる、対外的に出しているドキュメントについて、ドキュメントの作成フローを明文化

PFDやドキュメントの作成フローは開発メンバーにもとても喜んでもらえ、身近なメンバーの役に立てていることを実感できて嬉しく思いました。

"効果を実感" という部分でいうと、「施策を通して事業にどのように貢献したか」を示すことは上手くできませんでした。"データが大事ということを身をもって知ることができた" とも言えるので、来年の課題として向き合っていきます。

->2022 - 成果を出せるQAを目指して

大きすぎる課題、広すぎる領域に手を出そうとする癖は直せたのかなと思いつつ、まだまだ成果を出す力が弱いなと感じています。 成果は「数字・データとして見えるもの」と「組織の文化・人の雰囲気から感じ取れるもの」があるのかなと思うので、どちらか一方に執着せず、どちらも視野に入れて動いていけるエンジニアになりたいです。

現時点では、「仕事の取り組み方」より「知識量や考える力」に課題を感じているので、もうとにかく勉強していこうと思います。一生そうだろうけど、今は特に。

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

ふりかえり - 個人的な勉強、そのほか

そのほか

JaSST Tokyo実行委員に参画させていただきました。若輩者ですが、コミュニティに貢献できるように頑張ります。

個人的な勉強

読んだ本や読み始めた本をまとめます。カテゴリは割と適当です。

QA
  • SQuBOK Guide V3
    • 一通り読んで、JCSQE初級を受験しました。受かってると良いな～
    • Body of Knowledgeという言葉通り、頭にソフトウェア品質の知識体系を描くのにとても良いなと思いました。初手でこれに手を出せるとその後の勉強がより定着しやすそうです。
  • ソフトウェア品質会計
    • 読みました。"書いてあること全部頑張る" というよりは "取り入れられる部分を取り入れる" という使い方をしています。そういう意味では参考書っぽいなと感じています。
  • 間違いだらけの設計レビュー
    • 読みました。シナリオを用いたレビューの仕方、レビューの準備～当日進め方～フォローの一連の流れが解説されています。とても読みやすかったし、実践に活かしやすい内容でした。"レビュー改善したいけど、どこから手を付ければ良いか分からない" という方におススメです。
  • テストから見えてくるグーグルのソフトウェア開発
    • 読みました。これ読んで、やっぱりコーディングできるようになりたいなって思いました。
  • ソフトウェアプロセス改善手法SaPID入門
    • 読み始めました。組織を対象とするQA活動は、気づいたらトップダウン的な動きになりがちなので、ちゃんと読み込んで自律的な改善活動にしていきたいです。
仕事全般
  • イシューからはじめよ
    • 読みました。1度読んで "なるほどな" ってなるんですが、意識して実践するのを繰り返さないと身につかないなと感じています。特に何度も読み返す系。
  • SOFT SKILLS　ソフトウェア開発者の人生マニュアル
    • 読みました。読んだはずです。エンジニアとして自分を売り込めるようになろう、その他の生活も勿論大事だよ、という本だったと思います。もう1回読もう。
  • コンサル一年目が学ぶこと
    • 読み始めました。先頭のほうに書いてあったPREP法は、次の日から役立ちました。他の勉強の合間に少しずつ読み進めます。
  • 知識創造企業(新装版)
    • 読み始めました。ナレッジマネジメントはQA活動で避けて通れないと思い、読んでいます。第2章まで読み終わったくらいなので、ここからが本論という感じです。期待。

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

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
    • 読みました。

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

#ここアジャに沢山の勇気と感謝をもらった話。~"ここはウォーターフォール市、アジャイル町"を読んでの感想~

blog

年明けから、数少ない通勤時間で少しずつ読み進めていた ここアジャ を読み終えたので、感想を書きます。

www.shoeisha.co.jp

本の概要

本書は、物語形式のページと、その物語で出てきた概念や手法の具体的な説明のページが章ごとにあります。 とある企業の情シス部門の運用チームが主役で、「無力感が蔓延しているチーム」から「自己組織化されたチーム」にセイチョウしていく物語を通じて、アジャイルな組織の作り方を学ぶことができます。

開発スタイルとしてウォーターフォール型を採用しているチームがアジャイルの手法を実践することでどうセイチョウできるのか、にフォーカスを当てており、ウォーターフォールからスクラムへの移行はテーマではありません。

著者である沢渡あまねさんの「チームを改善しようとした結果、アジャイルな手法を取り入れていた」という体験を、まさに追体験できる物語だなと思いました。

具体的な内容としては、タスク管理手法としてのチケット管理や、ふりかえりのススメ、ホワイトボードやオープンスペースを取り入れてみることや、顧客価値創造のためのワンチーム、などなど……。 単なる手法の紹介だけでなく、手法を取り入れる際の上司やチームメンバーとのコミュニケーションの取り方も交えて解説されているため、「これなら自分のチームでも小さく試していけそう」という実感を持ちながら読み進めることができました。

Be Agileに向けて確信と勇気をくれる一冊

私が所属しているチームでもウォーターフォールが採用されていますが、本書で紹介されているチケット管理やslack、KPTやFun Done Learnなどの振り返り手法は既に実践していました。 そのため、「アジャイルな手法とは何か」というより「アジャイルな手法の何が嬉しいのか」を知りたくて本書を手に取りました。

読んでみてまず、「今いる環境はめちゃくちゃありがたいんだな」と思いました。 プラクティスの導入前後の物語や、具体的なノウハウについての解説を読み進めていくと「確かにこの手法を通じてこういうメリットを享受しているな」と思う部分が沢山あり、 章を追ってどんどん良くなっていく運用チームの様子を見て、 「こういう過程を経て良くなっていった結果今のチームがあって、そんなチームで働かせて貰えているんだ」 と、運用チームへの思い入れが強くなっていくごとに、自分の環境のありがたさ、チームの先輩方の偉大さを強く実感しました。

また、チームのセイチョウ過程を追うことで、Be Agileとはどういうことなのかを具体的に知ることができました。 8章以降ずっと胸熱展開が続くのですが、特に印象的だったのは、エピローグの相良 真希乃の下記の一節でした。

「大切なのは、自分たちの問題や課題を言語化すること、周りの仲間たちと問題意識の景色を合わせること、そしてそれを仕組みや仕掛けで解決することなのだ。その解決方法は、ウォーターフォールの世界のやり方だろうが、アジャイルの世界のやり方だろうが、どちらでもいい。」

まさにこの姿勢こそがBe Agileの体現だなと感じました。どんな手法を実践しているかでプロダクトの価値が決まる訳ではなく、"本当に価値のあること・あるべき姿"のために行動を起こすことが重要で、アジャイルの手法はその助けとなる。 この相良 真希乃の言葉は、一つの羅針盤として、今の自分を奮い立たせてくれると共に、今後歩みを進めていくうえで迷い悩むことがあっても勇気づけてくれると確信しました。

「今所属しているチームの開発プロセスが、どんな意図で出来上がったのか」を知りたくて本書を手に取りましたが、本当に出会えて良かったと思える一冊でした。 自分もチームのメンバーとして良い文化を作っていけるように、また明日から頑張ります。

www.shoeisha.co.jp

「分からないから聞く」から「分かるようになるために聞く」へのスイッチング

blog

何回かリリースを経験した中で、1リリースという単位で「何をするか」と同じように「何を学ぶか」をハッキリさせることが結構大事なのではないか、と思ったのでまとめてみます。

機能実現には自信を持てるが、価値実現にはあまり自信を持てない開発チーム

開発の流れをざっくり説明すると、市場からの改善要望や既知の市場障害に応じて要件が発生しており、期初にそれらの幾つかが棚卸されてリリース単位のロードマップが引かれます。その後、細分化されたプロジェクトによってウォーターフォール的/アジャイル的に開発が進んでいきます。

ロードマップ実現のために要件定義～設計～実装と進めていくと「この仕様は要望を満たすのか」が分からなくなる場面があります。その度に、検証側を含めた開発チームのメンバーで議論したり、企画やテクニカルサポートなど顧客と接しているメンバー(以降、フロントと表記)に相談したりします。
開発チーム内だけで議論するかフロントも巻き込むかの判断は、「開発チームとしての判断のしやすさ」によるのかなと思うのですが、どのケースでも「フロントの意見を聞けるなら聞けるほうがマシ」という意識がありました。
これには幾つか原因があると思うのですが、主な原因は

  • 「お客様が機能をどういう風に使ってどういう部分で困りやすいか」の判断材料が開発チームにないこと
  • 「機能のこの部分を充実させると親切だろうけど、どの程度ビジネスとして価値があるのか」の判断能力が弱いこと

だと思います。

この原因に対処するため、今の開発チームは"チーム内でどう判断すればいいか分からないから意見を欲しい"とフロントに相談したりしなかったりしています。

「分からないから聞く」で残るもの

現状のプロセスでは上記の通り「分からないから聞く」を行っています。「分からないから聞く」を行うと、「聞いたから分かる」となります。ここで「分か」ったことは「分からなかったこと」のみです。

何を言いたいのかと言うと、具体的なケースについて「仕様と要望の一致度」を聞いて明らかにするだけでは、次のリリースで別の要件を対応するときにまた同じことを繰り返してしまうということです。

「分からないから聞く」では、未来の「分からないから聞く」が残ってしまうのです。

その場限りの解決から根本解決へのスイッチング

今回の「分からないから聞く」の目的は、「この仕様は要望を満たすのか」を判断することでした。
言い換えると、"開発チームだけで判断できない状態"から"(フロントの力を借りて)判断できる状態"になることが目的でした。

目的をこのように整理すると、"判断できる状態になる"ために他にできることがないか？と考えることができます。
その上でこれまでの開発プロセスの延長で小さく試せることを考えると、「分からないから聞く」に加えて"今よりちょっとだけ判断できる状態になる"ために何かを得ることはできないか？という発想が浮かびます。

そうすると、「分からないから聞く」という事象解決のための行為を「分かるようになるために聞く」という事象解決+学びを得に行く行為へと発展させることができます。

このような姿勢を持てば、同じ聞くという行為の中でも「今回のようなフロントの知見をどうすれば開発チームも取り込めるか」と踏み込んだ質問も出てくるようになって開発とフロントとで歩み寄ることができます。また、「そういう課題は確かにあるから、じゃあこういうタイミングで相談するようにしよう」と現場レベルでのコラボレーションも実現されるようになります。

「何を学ぶか」を明確にする

ある程度開発が続いてきたプロダクトの開発プロセスには、大なり小なり改善すべき問題が生じていると思います。全ての問題を解消する一手など存在しないので、開発スピードを保ったまま改善していくしかありません。
改善のために「xxxxをしよう」というとき、それは"理想の状態"に効率的に向かうための行動提案・様式提案となっているはずです。しかしそれだけだと、行動・様式に沿った結果"理想の状態"に近づくことはできても、同じ行動をずっと繰り返さなくてはいけないかもしれません。

そうではなく、「今その行動をとる目的は何で、じゃあその目的の達成のために何を積み上げていけるか」という「自分たちのレベルを上げるために何を学ぶか」思考で行動提案・様式提案に学びの口を一つでも加えることによって、よりチームにフィットする行動や後に残る学びを得やすくなるのではないでしょうか。

リリース単位で「何をするか」という行動ベースの目標や「どういう状態を目指すか」という状態ベースの目標を立てるのと同時に、「何を学ぶか」という姿勢ベースの目標を立ててみると良いのではないかと漠然と思ったので、考えを整理してみました。

ちょうど次のリリースに向けてまた動き出しているタイミングなので、色々と試しながら次の開発期間を学び多いものにできるよう頑張りたいです。

2021年の振り返り<1月・2月>

blog

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

キャリア観の変化

Q4では上長やチームメンバーに自分の考えていることをどんどん発信していくことを意識的に行い、自分で考えるだけではなく相談しながらリアクションを貰いながらチームで物事を進めていくという姿勢を取れるようになってきました。今のところ良い方向に自分を動かせているのかなと思います。 そんな中で、年初ではふわふわしていたキャリア観が定まってきました。

キャリアの重心をQAへ

Q4の初めに上長と1on1を行い、チームの掲げる目標に対してAndroid開発を軸に貢献するかソフトウェアテストを軸に貢献するかの相談をさせていただきました。いざ相談してみると、自分が考えていたチームの弱み・改善できるスポットと上長の考えていたがある程度一致しており、じゃあそこに力を入れていこうということになりました。 自分がそのとき感じていた課題は、テスト計画が後から振り返りしやすいものとなっていなかったり、上流工程から検証チームが参加するものの品質担保のための観点がメンバーに浸透していなかったり、といったものでした。 そのため、手段としてどのロールを取るか、という話になったとき必然的にQAが浮かびました。

その後も1on1や別の機会を設けていただき、前回のブログでも書いた通り、今はQAチームを立ち上げようというところに全力を注いでいます。

来期以降、少なくとも2年間はキャリアをQAに全振りしようと考えています。

直近の課題

プロダクト開発全体に寄与するためのソフトウェアテスト・品質保証に関する知識が圧倒的に足りず、ソフトウェアテスト技法ドリルやSQuBOKなどを中心にもっともっと足腰を鍛えなきゃいけないと感じています。

進捗

肝心の、年初に立てていた目標の進捗はと言いますと…。

web

  • Real World HTTP 第2版www.oreilly.co.jp
    • まだ買ってもいないです。
  • JavaScript Primerjsprimer.net
    • 第1部のプロトタイプオブジェクトまでと、第2部のAjax通信とCLIアプリの部分を勉強しました。動的型付けにようやく慣れてきたかなというところです。

インフラ

  • イラストでわかる DockerとKubernetesgihyo.jp
    • まだ買ってもいないです。
  • コスパのいいシステムの作り方gihyo.jp
    • 3章の「開発費を削減するための工夫」まで読んで、25%くらいの進捗です。プロダクト開発というよりはプロジェクトの視点を学べて、業務をする上で持っておきたい視点を一つ増やせているのは良いなと捉えています。

android

  • Androidテスト全書peaks.cc
    • 2章まで終わり、モックとかスタブとかスパイの概念の使い分けを認識しました。SETのスキルを強化していくなら必須の知識と思いますので、引き続き取り組んでいきたいです。

QA

  • JSTQB FLjstqb.jp
    • 受験しました。合格できたらいいな。。
  • SQuBOK Guide V3www.ohmsha.co.jp
    • 1章を最低限読み終えて、2章を読み進めています。いざ本腰入れて読んでみたら読み物としても面白く、QAとしての視野が広がっている実感もあるので、引き続き頑張りたいです。

エンジニアリング

  • 事業をエンジニアリングする技術者たちtechlog.voyagegroup.com
    • 先輩に借りていた本、緊急事態宣言のタイミングで返却しました。自分にはまだ早かったので、半年後くらいに買ってまた読もうと思います。
  • ここはウォーターフォール市、アジャイル町www.shoeisha.co.jp
    • 数少ない出社日の電車の中でゆっくり読み進めています。チームで物事に取り組むためのヒントが沢山あるので、早いところ読み切りたいです。

次の2か月のアクション

キャリアの中心にQAを据える決意を固めたため、SQuBOKを中心にソフトウェアテスト・品質保証の知識をもっともっと付けていこうと思います。 キャリアはQAに全振りするとはいえ、いつでも全方向に飛び移れるようにWebやクライアント開発などの勉強も細く長く続けていこうと思います。なので、年初に立てた最低限の目標は変えず、頑張ります。

ダメだったら下期の取り組み方を変えれば良いのかなと思うので、特に細かい数値目標は立てずに、実直に取り組んでいきます。

ソフトウェアテストジャーニーへの船出 (JSTQB FLを受験したハナシ)

blog

気付けば2021年も1か月と半分が過ぎ、本日はJSTQB FLの受験日でした。

受けた直後の今は、試験の手ごたえがどうとかより、やっと一区切りついたという感想が強いです。
本記事では、新卒1年目のひよこエンジニアである自分がなぜ試験を受けたのか、今後どうしていきたいのか、などをつらつら書いてみようと思います。

※JSTQBとは何か、については公式のHPをご覧ください。jstqb.jp

ソフトウェアテストとの出会い

僕は2020年4月に、あるソフトウェア開発会社に新卒入社しました。なので1年前は大学生でしたし、それもプログラミングの経験が多少ある、くらいの平凡な学生でした。

入社後はAndroid開発チームに配属され、社会人生活もチーム開発もAndroid開発も初めて、という状況の中で「教わったことを覚えていく」のに必死、という日々を過ごしていました。
6月の半ばまでAndroidの開発を行い、VIPERアーキテクチャで疎結合なコンポーネントを組み、コンポーネント同士のテストコードもしっかり書いていく、という経験をすることができました。
この時点でソフトウェアテスト自体に触れてはいたのですが、より強くテストを意識するようになったのは、そのあとの工程であるシステムテストに参加する機会をいただいたときでした。

僕が所属している開発チームのシステムテストは、いわゆるテスト担当者がテストの観点を作成し、観点に基づいてテストを実装し、そして実行していくというベーシックな流れを採用しています。
最初の機会ではテストケースが既に用意されていたので、テスト実行を担当しました。
最初は書かれている通りにテストを実行して期待値と比較して…とやっていたのですが、テスト手順や期待値への疑問点をテスト作成者に質問したり、テストで見つかったバグへの対応についてマネージャーから指摘をいただいたりする中で、テストケースの効率的な組み方であったり、そもそもテストを実装する前段階で議論するべきことがあるなと思ったり、プロダクト開発におけるソフトウェアテスト、という命題についてよくよく考えるようになっていきました。

今思えば、テスト工程での反省を開発プロセスの反省、と捉えられたのは、Android開発者として実装タスクを行っていたからなのかもしれないですね。
自分の実装したものをテスト担当者としてテストし、その中でソフトウェアテストと向き合っていった。
これが僕のソフトウェアテストとの出会いでした。

JSTQBとの出会い

6月からの3ヶ月をテストとバグ修正に捧げる中で、ソフトウェアテストそのものを体系的に勉強する必要性を感じていました。
そんな中、あまり深く考えずに"ソフトウェアテスト 資格試験"で検索してみたとき、JSTQBの存在を知りました。

ホームページを見て、今の自分にぴったりで良さそう！と思い、
シラバスを見て、凄すぎる！！これをまさに勉強するべき！！と思い、
FL試験の開催日程を見て、次の2月！丁度良すぎる！！！と思いました。

テス友アプリがあったのも、とてもありがたかったです。

テスト実行を担当する中でソフトウェアテストを体系的に勉強したいと思い、何となく資格試験を調べてみたらJSTQBの存在を知った。
これが僕のJSTQBとの出会いでした。

そうこうしているうちに、無事10月にメジャーバージョンアップリリースを迎えることができました。

テスト担当としての日々、飛躍

ソフトウェアテストの勉強を熱心にしていることを評価され、次のメジャーバージョンアップリリース向けの要件には、テスト主担当として参加することになりました。

2月現在、これからリリースを迎えるフェーズなのですが、今日までに実例マッピングを実践してみたり、テスト設計時に品質特性との対応を整理してみたりしていました。もちろんテスト設計〜実装までも一丁前に頑張っています。

勉強したことを開発プロセスに取り入れていく日々の中、僕自身の志向が「品質改善にミッションを持ったロール=QAチームを作りたい」 というチームの状況ともリンクし、今は要件対応に加えて、新たにQAチームを立ち上げようというところに参画させていただいています。

FL試験の受験、そしてソフトウェアテストジャーニーへの船出

今回のJSTQB FL試験の受験は、
QAを立ち上げるにあたり、品質目標をどうするべきか、テスト戦略はどうあるべきか、という議論を直近でしている中での受験となりました。
そのため、個人的には

社会人1年目の集大成 且つ 来期以降の大きな前進への第一歩
=>
ソフトウェアテストジャーニーへの船出

という意識を強く持って挑んだJSTQB FL試験でした。

シラバスを見ていただくとよく分かるのですが、JSTQB FLの試験範囲はまさにソフトウェアテスト全般であり、この領域でプロダクト開発に貢献していくためには通らざるを得ない登竜門といっても過言ではないです。

ソフトウェアテストとは何か、その意義の解説から、テストプロセスの仔細について、また具体的なテスト技法についても勉強できるので、
ソフトウェアテストを真剣にやっていきたい人には本当におすすめしたいです。

今後の展望については、上述した通りこれからQAチームを立ち上げていき、今接しているプロダクトの品質を未来にわたって改善していくべく、ソフトウェアテストを武器に日々邁進していこうと考えています。

JSTQB FL試験が終わってまずはひと段落というところですが、ソフトウェアテストジャーニーは始まったばかりですので、FLシラバスで学んだことを糧に、さらにソフトウェアテストの勉強をしていこうと思います。
具体的には、SQuBoKに齧り付いていったり、テスト自動化についてもっと勉強したり、さらにスキルを伸ばしていきたいです。また、Androidやwebの開発についても勉強して、実装者とうまくコミュニケーションを取れるQAエンジニアになっていきたいです。

受かれば良いな…と思うのですが、もしFL試験に落ちていたら、また勉強し直して再挑戦したいと思います。

2021年(1月～6月)の目標

blog

目標到達度という観点で2021年の日々の振り返りをしやすくするため、一つの記事にまとめてみます。

1月～6月にかけて読みたい本・サイト

web

インフラ

  • イラストでわかる DockerとKubernetesgihyo.jp
  • コスパのいいシステムの作り方gihyo.jp
    • "機能を実現すること"で手一杯で、あらゆる面でコスパという観点が抜けていることを2020年度Q3の中で痛感しました。DevOpsにおけるコスパ、という視点を習得したいです。

android

  • Androidテスト全書peaks.cc
    • 昨年の配属当初、VIPERアーキテクチャを用いてアプリケーション開発を行ったため、開発と並走してテストも書くという行為は実践できています。しかし、Android自体の理解が浅くテストにおけるベストプラクティスをまだ知りません。"テスト"と銘打っているこの書籍を通して、テストを書けるAndroidエンジニアとして一歩進みたいです。下記の記事も、この本を読もうというきっかけになりました。

QA

  • JSTQB FLjstqb.jp
    • 読みたいというより、JSTQBのFL試験を2月13日に受験します。テス友アプリも使ってしっかり合格したいです。
  • SQuBOK Guide V3www.ohmsha.co.jp
    • 上半期で目を通せるとは到底思えませんが、ストレッチ目標として掲げます。用語や方法論を一つ一つ追っていったらキリがないので、まずは読み切ることをゴールとします。

エンジニアリング

  • 事業をエンジニアリングする技術者たちtechlog.voyagegroup.com
    • 先月から先輩に借りている本。新米過ぎて雰囲気でしか理解できない部分もありますが、読むと場数を稼げるような感覚でいます。これも読み切ることをゴールとして早く返却したいです。(先輩すいません、、、)
  • ここはウォーターフォール市、アジャイル町www.shoeisha.co.jp
    • 所属しているチームは10年選手のプロダクトを抱える、いわゆる成熟したチームです。ので、この本に書かれていることは大なり小なり実践されているように思えますが、今やっていることにどういう意味・メリットがあるのかを改めて理解したいです。

ピックアップしやすいので本やサイトを挙げましたが、日々Androidのデベロッパーガイドをチェックしたり、色んなテックブログを見る癖は継続して意識していきたいです。また、個人開発の中で学んだことや業務で行っていることも、このブログや弊社のテックブログで発信していきたいです。

2021年さらに飛躍して、携わるプロダクトの質の向上に努めていきたいです。