はじめに
この記事では、過去に私が新規開発でのテストで直面した問題と、その解決方法について記載しています。
内容としては、検証工数が十分でない中での、スプレッドシートを利用したスキル系の説明文の検証で補助ツールを作成して、検証時間と工数を効率化した話です。
システムの仕組みの違いや、資料の管理方法の違いなどありますが、考え方の参考になれば良いなと思い記載しましたので、よろしければ最後までご覧になってください。
読了時間
約5分
作成に経った経緯
新規のスキル開発というのは、どれだけ準備していても思い通りに進行しないことが多いものだと個人的に思ってます。
私が担当していたプロジェクトでも、スケジュール通りに検証が完了し、間もなくリリースというところで
「検証終わってますがギリギリまでスキルの微調整を入れたい」
という変更作業が入りました。
リリース直前まで調整が入るスキルの検証はスケジュールに余裕がなくなることが多くありました。
このように更新頻度が高い、ギリギリまで調整が入るデータのテストに対して都度対応を行うと費用も工数もかかります。
さらに、「スキルの各数値を変更したが、スキルの説明文を変え忘れてしまう」
という障害リスクの要因にもなります。
であれば、マスタの数値から自動で説明文を作ってしまえば、自動で毎日チェックできるんじゃないかという考えに至り作成することになりました。
前提
導入できる前提として下記が挙げられます。
・マスタがスプレッドシート上で管理されている
・ある程度文章構成に規則性がある
└ユニークすぎるものだと導入が困難です
・説明文が手入力の仕組みになっている
どのようなものだったか
実際はもっとカラムが多くなりますが、説明のためわかりやすくしています。
画像の①
③の「参考にするマスタ」からVlookup関数やIndexとMatch関数を混ぜた関数を使用して、値を参照させてください。
個人的には、参考にするマスタのカラムが増えた時にも対応できるように、IndexとMatch関数を使用するほうが、メンテナンスが楽かと思います。
画像の②
実際に①で入力されている値からF列で文字として自動で出すようにしています。
今回のものだと下記のように記載しています。
=ArrayFormula(If($A$2:$A$10="","",
if($D$2:$D$10=1,"自分の",
if($D$2:$D$10=2,"敵の","Error"))
&
if($C$2:$C$10=1,"体力が",
if($C$2:$C$10=2,"パワーが","Error"))
&
if($E$2:$E$10="","",
if($E$2:$E$10>=0,$E$2:$E$10&"アップする",
if($E$2:$E$10<0,$E$2:$E$10&"ダウンする","Error")))))
各カラムに新しい法則が入った時に検知できるようにError処理を行うと良いかと思います。
そして、出力した説明文をG列で比較しています。
画像の③
チェックシートとは別にシートを作成して、「参考にするマスタ(名前はなんでも良いです)」シート上で、Importrange関数を使用して自動でマスタの数値を参照できるようにしてください。
参考にしたいマスタが複数の場合は、シートを分けて作成してください。
効果
効果としては以下のように、効率化と品質向上の2点ありました。
効率化
【工数の約80%を削減することができた】
このチェックのシートを作成して、最低限の挙動やデータの反映を実機で確認することによって予定していた工数の約80%を削減することができました。
品質向上
例えば
この画像の水色の部分では「自身の」になっていて、自動で作成される規則では「自分の」なので判定ではFALSEとなります。
実際に人の目でこの説明文単体をチェックした時、効果と意味的には問題がないので特に違和感が感じられない可能性があります。
このように、規則と外れていることを報告し、合わせたほうがいいという提案も容易にできるようになりました。
作成のポイント
実際マスタの作りは様々ではあるので、決まった作成方法を提示するのは難しいですが、作成時のポイントを挙げたいと思います。
まずはマスタの仕組みを理解する
時間はかかるかもしれませんが、各カラムの仕組みを理解するのが大切です。
・どのような数値なのか
・どのような数値の種類があるのか
・どのように使用されるのか
・カラム同士で紐付いているものはないか
を意識して紐解いていきましょう。
作成する関数はできるだけ複雑にならないようにする
他の人がメンテナンスできるように、できるだけ基本的な関数を使用するのもポイントです。
シート自体が重くなりすぎるものも極力使わない
ある程度動作が重くなってしまうので、
・条件付き書式
・query
この辺りは、極力使わないのが効果的でした。
さいごに
あくまで補助ツールではあるので、挙動などの担保は基本的には実機上でするべきと考えます。
また
・リリース後はパターンが増えてくるので、メンテナンスは大変である
・作成者以外でもメンテナンスの容易性を上げたほうがいい
など、課題は多いと思います。
とはいえ、マスタの知識がないテスターにも文章として可視化して、検証の補助ができて非常に有効なものになりました。
今回の記事が少しでも参考になれば良いし、もし他にもこんな方法、仕組みが効果的だったなどありましたら教えてもらえると嬉しいです!
最後まで読んでいただきありがとうございました!