「初めましてのプロジェクト」どうやって進めればいいの？
QAの立場から２つの新規プロジェクトに関わってみて
これはウイングアーク Agile and DevOps Stories のAdvent Calendar 2021（2021年12月17日）の投稿です！
ご無沙汰しております。ウイングアーク１ｓｔでSVF Cloudの検証を担当している今宿（いましく）です。私だけかもしれませんが、12/1からはじまり、毎日のメンバーの投稿を見ていると、自分の内容がこれでいいのか、最後まで書くことができるのかなど、アドベントカレンダー独特なのかもしれませんが、緊張感を感じながらブログを書いています。
そろそろ12月も後半になりクリスマス関連イベントも後半戦で盛り上がってきています！今年のクリスマスはいろいろな体験ができればいいなあと思っている今日この頃です。
はじめに
早速ですが本題に入りたいと思います。
今回は新サービス・新製品をリリースするための新しいプロジェクト（以降「初めましてのプロジェクト」と呼びます）に対して、現在進行形のものを含めて、経験談を皆様にシェアさせていただきたいと思っています。
「初めましてのプロジェクト」では、新製品をリリースできる品質にするために、QAとしてさまざまな準備や用意する必要が出てくることが多いと思います。それに加えてどのようにプロセスを進めていけばいいのかという戦略を検討することが重要になってきます。
私が過去に経験した新規プロジェクトとして、弊社が提供する帳票クラウド「SVF Cloud」と連携する「SVF Cloud for ServiceNow」の新リリースに携わったことがあります。また、現在携わっている新しいプロジェクトとしては、新規開発予定の製品があります。
それぞれ特色が異なるこの２つのプロジェクトで、私を含めたQAメンバーがどんなふうに対応しているのか、説明していきたいと思います。
Aプロジェクト
このプロジェクトは既存のサービスである「SVF Cloud」を、SaaSプラットフォームである「ServiceNow」に初めてリリースするというものでした。
弊社のSVF Cloud開発チームがServiceNow社のサービスと連携するアプリケーションを開発し、私は実際にテストを実行する立場として関わりました。その際に実施したJMeterを使ったソフトウエアテストについては、過去のこちらのブログに記しています。
この「初めましてのプロジェクト」は、以下２つの特色がありました。
１．既存の「SVF Cloud」という製品を利用していることから、ベースとなる品質はそこで担保されている
２．SaaSプラットフォームにインストールするアプリケーション開発プロジェクトであったため、SaaSベンダーのServiceNow社が定めている基準に準拠する必要がある
１については、ベースとなるSVF Cloudの品質はすでに担保されていることから、評価する範囲を絞りServiceNowとの連携部分に着目しました。
また、ServiceNowからの接続先は既存のSVF Cloudであることから、そのテスト資産を活かすことができることが分かっていました。さらに、インシデント管理などのツールはSVF Cloudと同じものを流用し、テストを進めることができました。
２については、弊社としてのリリース基準と合わせて、ServiceNowのリリース基準を満たすことを考えました。ServiceNowのリリース基準についてはServiceNow社の担当者と相談した結果、その基準を満たすためのテンプレートがあるとのことで、参照しながら必要なテスト項目を作成しました。
まとめると、この「初めましてのプロジェクト」では社内の既存資産を活かしながら、リリースの判断はServiceNowが定める基準とウイングアーク１ｓｔの基準を併用して評価しました。
SaaSベンダーの基準を満たしながら、更に今まで社内で利用してきた基準や資産を活かすことができた「初めましてのプロジェクト」でした。
Bプロジェクト
続いて、最近アサインされた現在進行形のプロジェクトについてです。前のプロジェクトで「初めましてのプロジェクト」に関わっていたとはいうものの、一からテストについて考えることは初めてであることに気付かされました。
このプロジェクトで開発しているサービスは、ウイングアーク１ｓｔが開発し提供している他のサービスに組み込まれることが前提になっているものです。将来、私が担当しているSVF Cloudにも組み込まれる可能性はありますが、今はその対象から外れています。
このプロジェクトのテスト実行は開発メンバーが行います。開発責任者（以降はPO）と開発メンバーはテストの経験がないということで、手伝ってほしいとの依頼がありました。過去の経験や今まで学んできたことを活かして、このプロジェクトのチームが開発とテストについて自走できるように支援していきたいと考え、参加することにしました。
テストは開発メンバーが行うため、今回の役割はテストの方法を一緒に考えたり、アドバイスを行ったりする立場です。手を動かしてテストを実行する立場ではなく、支援者として参加するのは初めてです。テストに慣れているQAメンバーではなく、開発メンバー自身にテストのことを理解してもらい進めていく必要があります。
まずはPOにテストの状況と、どこから手をつける必要があるのか、どのような支援を求めているかの確認を行いました。
— — — — その時の会話
PO『私も昔はテストをやっていたことがあるんです。サポートの立場でですけどね。その時はお客さんが求めていることができればいいという考えで、そこだけをテストして、問題なかったらお客さんに渡すという感じでした。』
私『なるほどです！私も最初はサポートをやっていたので、わかります。体系立ててテストをするのは初めてなんですね。』
PO『そうなんです。何をしたらいいのかわからないからアドバイスがほしいんです。今、流行りのやり方というかよくやられているやり方でテストしてリリースしたいと思っています。やっぱり、QAの人は、お客様に重要な問題が流出しないようにバグを見つけるのが得意じゃないですか。』
私『あー、、、最近は開発の段階でいかにバグがでないようにするかということを考えたりするんです。例えば製品設計レビューを行ったり、お客様の目的を満たすためにユーザーシナリオを考えたりするんです。今回は初めてのプロジェクトなので、ユーザーの利用シーンを一から考慮する必要がありますが、何か考えられたりしていますか？』
PO『イメージは大まかに考えてはいますが、具体的にどのように利用されるかまでは考えられてないです。開発メンバーの頭の中にはあると思いますが・・・・・』
— — — —
POと会話した結果、これからテストについて考え始めている状況であることが分かりました。また、初めてのプロジェクトかつ開発の初期段階であるために、ユーザーにどのように利用されるかが明確になっていないことが分かりました。
ユーザーの利用シーンの全体像を明確にして、共通認識をもてる一つの方法として、ユーザーストーリーマッピングがあります。2020年度のASTER-テスト設計コンテストの時に、このユーザーストーリーマッピングを用いて実際にユーザーストーリーを考え、初回のリリース時に必要なストーリーを検討し、各ストーリー毎にテスト観点に落とし込んだことを思い出しました。
※テスト設計コンテストへの参加は下記のブログに記載しています。
この方法だとユーザーの利用シーンが視覚的に分かりやすくなります。
テスト未経験の開発メンバーでも機能の利用目的が、シナリオとして共通認識をもった上でイメージしやすくなります。開発メンバー自身が「誰が、どういうユースケースで、何をしたいか」という明確なイメージをもって、必要なテストが行えるようになると思ったため、この方法を利用しようと考えました。以下のようなイメージです。
開発メンバーと相談した結果、先にユーザーストーリーを考えられるように画面遷移図を作成するとのことでした。そのため、今後はそれをもとにユーザー利用の全体像を把握し、ユーザーストーリーからどんなテストをしていけばいいのか、ストーリー毎に落としこむことを検討しています。
まだまだ序盤ではありますが、今まで得た知識や考えてきたことを、試行錯誤しながら少しでも良い方向に向かうように実行していきたい思っています。あとは、POがとても協力的であり、このことは私にとって救われたなあと思っています。
２つのプロジェクトに関わってみて
２つのプロジェクトに関わった際に工夫したことや思ったこと、学んだこと、現在考えていることをここに書きます。
Aプロジェクトでは、ServiceNowの基準とウイングアーク１ｓｔ基準の両方を利用し、テストを進めることができました。
ServiceNowの基準はありましたが、アプリケーション毎に特徴があるはずで、リリースしようとしているアプリケーションでは、どのようなテストが必要であるかを考え、ServiceNowと認識を一致させることは必要でした。
また、ウイングアーク１ｓｔ基準やテスト資産を利用するとはいえ、どのように利用していくのか、どこまで利用するのかを検討することも必要でした。
ただ、テンプレートや社内のノウハウがあってこそスムーズに進められたので、改めてすごいなあと感じています！
Bプロジェクトでは、Aプロジェクトとは違い、テストを実行する立場ではなく、テストについて支援する立場で入っています。当初は、せっかく呼んでもらったので、今までの知識や経験を活かしてアドバイスできればと思っていました。
しかし実際にPOと会話して、開発メンバーの思いを聞いていく中で「初めましてのプロジェクト」だからこそ、今までの知見を活かすだけでなく、私自身も学びながらよりよい部分を取り入れることができるように協力したいという考えに変わってきました。
自分だけで考えていると自身が知っている範囲で進めてしまいがちですが、そうならないように現在は他のプロジェクトに参加しているQAメンバーの知識も借りて、タスク管理やインシデント管理をどのようにするのかについても考えている最中です。
開発チームのメンバーが自分達が良いなという仕組みを選択し、取り入れることで彼ら自身が動きやすくなり、より良いものを作れればと思っています。それがアドバイスできるように協力していきたいです。
このような状況でして、いよいよユーザーストーリーを考えたり、テスト観点を考えたりいろいろ大変そうではありますがワクワクもしています。
今回お伝えした内容が少しでもお役に立てれば幸いです。現在進行形のプロジェクトについては、まだTryしている部分が多いので、知見がある方や同じ境遇の方などコメントなどでアドバイスいただけると嬉しいです！
Bプロジェクトのその後の状況など、次回にでもご報告できればと思っています！それでは、またお会いできるまでアディオス！
