QAのいらない世界へ向けて（はじめの一歩）

## はじめに
介護ソフト開発を行っているプロダクトに対してQA活動を行っている、発足して１年と少しのNNQA（ナーシングネットQA）での取り組みを発信させていいただきたいと思います。
他のQAがどのようなことをやっているかなどに興味があれば、是非最後まで読んでいただけたらと思います。

※NNQAとは、介護ソフト開発を行っている、ナーシングネットプラスワンソリューソンズのQAチームになります。

## まずは１年間の取り組みを思い出してみる
Step1：リリースに対して、QA確認の文化を作る
Step2：QA仕様書の作成
Step3：品質ストーリーの作成
Step4：要件マトリクスの作成
Step5：QAレポートの作成

その他1：加算減算まとめ
その他2：法改正対応の内容まとめ

:::note alert
LITALICOでの造語もあるので、少し詳しくどんなことを行っているかを説明していきたいと思います。
:::


#### リリースに対しての、QA文化を作る
- NNQAの発足までは、開発者がテストを行い品質を担保していた状態でした。テストチームなども無かったため、開発者以外のメンバーがテストするという文化がありませんでした。まずはリリースフローを安定して行える体制を作るためにQAでのテスト実行を行い、QAという存在を認識してもらう活動を行いました。

:::note info
開発とQAが一緒に歩んでいくイメージ
:::

#### QA仕様書の作成
- QA仕様書とは、機能または画面の仕様書となっていますが、画面仕様書とは少し異なってきます。QA仕様書に記載する内容としては下記になります。

    - 対象、条件など機能を使用するための前提条件
    - 機能の目的や概要
    - 制限事項
    - 関連法令
    - 業務フロー内での機能の役割
    - ユーザー視点での課題点
    - UX要素
    - 各UX要素の目的

:::note info
記載内容が多いため、作成やメンテに工数が取られるところが問題点
ただ、**仕様変更時**に必要な情報のため、とても重要
:::


#### 品質ストーリーの作成
- ユーザーストーリーという言葉は聞いたことがあるかと思いますが、ユーザーストーリーとは対になるような言葉で、ソフトウェアの目的などがストーリーとして起こされているものに対して、ストーリーで考えられる **リスク** をストーリー化したものになります。
- 一言で言うなら、リスクのストーリーになります。
NNQAでの活動の一つで、リスクを明確にしてPdMへ共有し、リスクを基にリリースや今後のプロダクト方針を決めていただいています。

:::note info
ストーリー段階でのリスクを明確にすることによって、**要件定義時点**での**リスク回避**が行える 
:::


#### 要件マトリクスの作成
- 要求～テストケースが一つのファイルにまとまっているものです。自分の経験でよくあるのが、要求、要件、機能仕様書、画面仕様書、テストケースなど、すべて別々のフォルダに配置されていて、ファイル名の頭に番号をつけてトレーサビリティを取っている現場があります。ただ、このような管理されている現場であるあるが、コピーファイルがあったり、新規Noが振られていたりなど、最新のファイルがどれかわからない状態で管理されていたりします。それを解決するのが、要件マトリクスと考えています。

:::note info
QAだけでなく開発者の協力も必要になり、大人数でのファイル操作になるため、共通ルールが必要
:::


#### QAレポートの作成
- テスト管理を行っている方だとイメージしやすいかと思いますが、テストの終了報告に近いものになっています。ただ、テスト結果の報告ではなく、リリース判断を行うPdMに向けてリスクを明確にして、判断材料として使ってもらう資料になります。
- リリース判断だけではなく、プロジェクトリスクの共有も行い、ソフトウェアの品質だけでなく、プロジェクトの品質を上げることによって、結果としてソフトウェアの品質も上げる活動を行っています。

:::note info
定期的なプロダクト、プロジェクトの品質チェックが必要
:::


#### その他
- ざっと行っていることに関して説明させていただきましたが、ここで介護支援ソフトウェアならではの一大イベントが迫ってきています。その名も **「法改正」** ソフトウェアの背景には介護保険があるのですが、その介護保険が３年に１度、大きな改正が入ります。来年に迫ってきた一大イベントに向けての活動もQAでは行っています。

##### 加算減算まとめ
- 介護保険料を自治体に請求するためには、算定構造という計算式があります。その計算式に出てくる内容をまとめ、ソフトウェアのどの機能に影響を及ぼすかをまとめている資料になります。

##### 法改正対応まとめ
- 法改正の情報は徐々に展開されてきます。色々な視点で有識者の方たちが介護をよりよくするために会議を行っているため、決定までに時間がかかります。その情報をできるだけ早めにキャッチアップを行い、ソフトウェアへの影響を最速で検知できる取り組みになります。

:::note warn
来年に迫ってきた法改正、同じ業種の方、一緒に乗り切りましょう
:::


## 目指す姿
NNQAの発足から１年で行ってきたことを記載させていただきました。
LITALOICOの他のプロダクトで行っていることを取り入れたり、開発の方と相談をしながら進めていたりなど、沢山の方の助けによって2年目を歩みだせています。本当にありがとうございます。

では、実際にどこを目指して進んでいるのかというと、
タイトルの通り **「QAのいらない世界」** を目指しています。
具体的に言いますと、PdM / 開発 / デザイナー / QAと分けて考えるのではなく、各々の作業で品質を意識して担保することによって、QAがいなくても品質を担保していける世界を目指しています。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2987894/676f8d37-12d4-6531-c5f7-1cfd88faf83b.png)


## やりたいことは沢山ある
今までの仕事では経験が出来ないような、新しいことを取り組むことが多い1年でしたが、行ってきた仕事での課題や、QAとして行っていきたいことが沢山残っている状態です。
- 最後の砦となるリリース前のテスト強化（自動化含む）
- プロジェクト品質保守
- 利用者品質の保守

など一例ではありますが、ざっくり考えただけでも幅広く、出来ていることの方が少ない状態です。しかも専門的な知識が必要なことも多くQAメンバーだけではカバーできません。
開発の方はじめ、プロダクトに関わるすべての方にご協力をお願いしながら一緒に歩んでいけたら幸せだなと思う今日この頃です。

:::note info
色々な経験を持つメンバーをまっています。
:::


## 最後に簡単な自己紹介
第三者検証の会社から昨年LITALICO-QAになりました。
今はNNQAチームが５名体制になったため、管理的なことと第三者検証では経験が出来なかった、要求段階での品質保証に取り組ませていただいています。

最後に宣伝を…私が書いた記事と後輩が書いた記事が混ざっていますが、第三者検証とQAの違いや、今やりたいことの記事のリンクを置いておきますので、興味があればぜひ読んでいただけたらと思います。

- [第三者検証からQAに転職してみて](https://qiita.com/yamahiro2022/items/cf61fd102c37cafea208)
- [QAエンジニアから見る前職と現職での品質の差異](https://qiita.com/7ko_i/items/b0bc3a9392d373048a19)
- [デザインからUIテストの自動化をやりたい](https://qiita.com/yamahiro2022/private/3c8de5fb9f6db317c4f9)