テスト観点とは？具体例・一覧と洗い出し方　テストケースとの違いも解説

ソフトウェアテストを設計していると、

「テストの抜け漏れを減らしたい」
「テストケースを作り始めると、似たような項目ばかりになってしまう」
「経験豊富なテスターと同じように、多角的な視点でテストを考えたい」

と悩むことはないでしょうか。

そこで重要になるのが、テスト観点です。

テスト観点とは、簡単にいえば、テスト対象を「何に着目して」「どのような切り口から」検証するかを表したものです。

例えばログイン機能であれば、「正しくログインできるか」だけでなく、「入力値の境界」「認証エラー」「権限」「セキュリティ」「性能」「ユーザビリティ」など、さまざまな観点から検証できます。

適切なテスト観点を洗い出せるようになると、テストケースの抜け漏れや偏りを防ぎやすくなり、限られた工数の中でも重要な箇所へ重点的にテストを実施できるようになります。

この記事では、

• テスト観点とは何か
• テスト観点の具体例・一覧
• テストケースとの違い
• テスト観点を構成する4つの要素
• テスト観点を洗い出す方法
• テスト観点の適切な粒度
• 観点の網羅性を高めるフレームワーク・テスト設計技法
• 単体・結合・システムテストにおける観点の違い
• 実務で使えるテスト観点リストのテンプレート

まで、具体例を交えながら解説します。

これからテスト設計を学びたい方はもちろん、経験則に頼っていたテスト観点の洗い出し方を整理したい方も、ぜひ参考にしてください。

▼テスト効率化の方法についてはこちら▼

テスト観点とは？

テスト観点とは、テスト対象のソフトウェアやシステムを、どのような視点・切り口から評価するかを示したものです。

よりシンプルにいえば、

「このソフトウェアの何を確かめるべきか？」

を整理したものがテスト観点です。

例えばログイン機能をテストするとします。

「正しいIDとパスワードならログインできるか」という確認だけでは、十分なテストとはいえません。

ほかにも、

• IDやパスワードが未入力だったらどうなるか
• パスワードの文字数が上限・下限の場合はどうなるか
• 間違ったパスワードを繰り返し入力したらどうなるか
• ログイン処理中に通信が切れたらどうなるか
• 多数のユーザーが同時にログインした場合も問題ないか
• スマートフォンでも操作しやすいか
• 一般ユーザーが管理者向け画面へアクセスできないか

など、さまざまな切り口が考えられます。

このように、同じ機能であっても、見る角度を変えることで発見できる不具合は変わります。

そのため、テストケースをいきなり作成するのではなく、まず「どのような観点からテストする必要があるか」を整理することが重要です。

テスト観点の具体例・一覧

「テスト観点といわれても、具体的に何を考えればいいのかわからない」という方も多いでしょう。

代表的なテスト観点には、次のようなものがあります。

もちろん、すべてのシステムでこれらを同じ深さまで確認する必要があるわけではありません。

重要なのは、テスト対象の特性やリスクに応じて必要な観点を選択することです。

例えば社内向けの簡易ツールと、多くのユーザーが利用する金融サービスでは、重点的に確認すべき観点は大きく異なります。

テスト観点の一覧は「すべて確認するためのチェックリスト」ではなく、観点の抜け漏れを防ぐためのヒント集として利用するとよいでしょう。

テスト観点とテストケースの違い

テスト観点とテストケースは密接に関係していますが、役割が異なります。

端的に整理すると、

• テスト観点：何を確認するか
• テストケース：その観点をどのような条件・手順で確認するか

という違いがあります。

例えば、ログイン機能について「パスワードの入力値」というテスト観点を設定したとします。

そこから、

• パスワードが未入力の場合
• 最小文字数未満の場合
• 最小文字数ちょうどの場合
• 最大文字数ちょうどの場合
• 最大文字数を超えた場合
• 使用できない文字が含まれている場合

など、複数のテストケースを作成できます。

つまり、基本的には1つのテスト観点から複数のテストケースが派生する関係です。

テスト項目との違い

「テスト項目」という言葉も、現場によってはテスト観点やテストケースと近い意味で使われます。

ただし、用語の定義は組織やプロジェクトによって異なるため注意が必要です。

一般的には、テスト項目を「確認する内容」、テストケースを「前提条件・入力・操作・期待結果まで具体化したもの」として使い分けることがあります。

プロジェクト開始時に用語の意味をチーム内で揃えておくと、認識のずれを防げます。

テストマトリクスとの違い

テストマトリクスは、複数のテスト観点や条件を縦軸・横軸に配置し、組み合わせを可視化した表です。

例えば、

• 縦軸：ユーザー権限
• 横軸：利用できる機能

として整理すれば、「どの権限でどの機能を確認する必要があるか」を一覧できます。

テスト観点そのものとは異なり、観点同士の組み合わせや網羅状況を整理するための手段と考えるとわかりやすいでしょう。

なぜテスト観点が重要なのか？

テスト観点を整理することには、大きく4つのメリットがあります。

テストの抜け漏れを減らせる

テストケースを思いついた順番に作成すると、テスターが得意な領域や仕様書に書かれている内容へテストが偏りがちです。

先にテスト観点を整理しておけば、

「異常系は確認したか」
「権限に関する観点はあるか」
「性能面は考慮したか」

といった確認ができるため、抜け漏れを発見しやすくなります。

重複したテストを減らせる

観点を整理せずにテストケースを作成すると、目的がほぼ同じテストケースが重複する場合があります。

観点ごとにテストケースを整理することで、「何のためのテストなのか」が見えるようになり、不要な重複を減らせます。

チームでテスト設計をレビューしやすくなる

完成した大量のテストケースだけを見て、抜け漏れを確認するのは簡単ではありません。

一方、テスト観点の段階であれば、

「セキュリティの観点が不足している」
「この機能は障害時の復旧も確認した方がよい」

など、テストの全体像についてレビューできます。

経験豊富なメンバーの知見も取り込みやすくなるでしょう。

リスクに応じてテストへ強弱をつけられる

すべての機能を同じ密度でテストすることが、必ずしも最適とは限りません。

利用頻度が高い機能、障害時の影響が大きい機能、過去に不具合が多かった機能などは、より多くの観点から確認する必要があります。

テスト観点を整理しておけば、リスクに応じて優先順位をつけやすくなります。

テスト観点を構成する4つの要素

テスト観点の整理方法にはさまざまな考え方があります。

本記事では、実務で整理しやすいように、テスト観点を次の4つの要素に分けて考えます。

1. 機能要素
2. 検証アングル
3. テストパラメータ
4. 確認ポイント

この4つを順番に考えることで、「何となく思いついたテストケースを並べる」状態から脱却しやすくなります。

① 機能要素

機能要素とは、テスト対象の「何について」確認するのかを表します。

ECサイトであれば、

• ユーザー登録
• ログイン
• 商品検索
• 商品詳細
• カート
• 注文
• 決済
• 注文履歴

などが機能要素にあたります。

さらに「ユーザー登録」を、

• メールアドレス入力
• パスワード入力
• 利用規約への同意
• 確認メール送信
• 本登録

のように細分化することもできます。

重要なのは、機能を細かくすればよいわけではなく、テスト設計しやすい粒度まで分解することです。

仕様書や画面一覧だけでなく、業務フロー、API、データ、外部システムとの連携なども対象として検討しましょう。

② 検証アングル

検証アングルとは、機能要素を「どのような側面から確認するか」という切り口です。

例えばユーザー登録機能であれば、

• 正常に登録できるか
• 不正な入力を適切に処理できるか
• 入力フォームが使いやすいか
• 個人情報を安全に扱えるか
• 多数のユーザーが登録しても性能に問題がないか
• 通信障害が発生したときにデータ不整合が起きないか

などが考えられます。

機能が「仕様どおり動くか」だけに集中すると、非機能面やユーザー視点の問題を見落としやすくなります。

品質モデルや過去の不具合、ユーザーの利用シナリオなども参考にして、複数の方向から考えることが重要です。

③ テストパラメータ

テストパラメータとは、テスト条件を変化させる具体的な変動要素です。

例えばパスワード入力であれば、

• 文字数
• 文字種
• 使用可能な記号
• 大文字・小文字
• 空文字
• 過去に利用したパスワード

などがパラメータになります。

メールアドレスであれば、

• 形式
• 文字数
• ドメイン
• 登録済みか未登録か

といった要素が考えられるでしょう。

パラメータを明確にすると、同値分割や境界値分析などのテスト設計技法を適用しやすくなります。

④ 確認ポイント

確認ポイントとは、テストを行った結果、何を確認して合否を判断するのかを明確にしたものです。

例えば「不正なメールアドレスでユーザー登録を試みる」という条件なら、

• 適切なエラーメッセージが表示される
• 登録処理が実行されない
• 不正なユーザーデータが保存されない
• 入力済みのほかの項目が不必要に消えない

などが確認ポイントになります。

確認ポイントまで明確にすると、テスターごとの判断のばらつきを抑えやすくなり、具体的なテストケースへ落とし込めます。

テスト観点を洗い出す6ステップ

ここからは、実際にテスト観点を作成する方法を6つのステップに分けて解説します。

STEP1：テストの目的を明確にする

最初に、「今回のテストで何を確認したいのか」を明確にします。

例えば、

• 新機能が仕様どおり動くことを確認する
• リリース前に重大な不具合がないことを確認する
• 既存機能への影響がないことを確認する
• 大量アクセスにも耐えられることを確認する

では、必要なテスト観点が異なります。

目的が曖昧なまま観点を大量に出しても、重要度を判断できません。

STEP2：テスト対象を分解する

続いて、テスト対象を機能や構成要素ごとに分解します。

例えばログイン画面なら、

• ID入力欄
• パスワード入力欄
• ログインボタン
• パスワード再設定
• 認証処理
• セッション
• ログイン後の画面遷移

などに分解できます。

大きすぎる単位では具体的な観点を考えにくく、細かすぎると管理コストが増えます。

「この単位なら複数の観点を考えられる」という程度を目安にしましょう。

STEP3：テストベースから情報を集める

テスト観点は仕様書だけから考えるものではありません。

代表的なテストベースには、

• 要件定義書
• 仕様書
• 設計書
• ユーザーストーリー
• 業務フロー
• 画面設計
• API仕様
• 過去の不具合
• ユーザーからの問い合わせ
• 開発者から得た技術情報
• 類似機能のテスト結果

などがあります。

特に過去の不具合や問い合わせは、実際に問題が起こりやすい場所を示す重要な情報です。

STEP4：複数の視点から観点を洗い出す

続いて、それぞれの機能要素について「何を確認すべきか」を考えます。

例えば、

• ユーザーはどのように使うか
• 仕様どおり動くか
• どんな入力値があり得るか
• どんな操作ミスがあり得るか
• どこで障害が起きそうか
• 悪意のある操作をされたらどうなるか
• データ量が増えたらどうなるか
• 権限が違うとどうなるか
• 通信が切れたらどうなるか

と問いかけることで、多角的に観点を出せます。

マインドマップやホワイトボードを使い、チームでブレインストーミングするのも有効です。

STEP5：粒度を揃え、重複を整理する

観点を出し終えたら、同じレベルの粒度になっているか確認します。

例えば、

• セキュリティ
• パスワード
• パスワード7文字の場合

が同列に並んでいたら、抽象度が大きく異なります。

「セキュリティ ＞ 認証 ＞ パスワード」のように階層化し、詳細な入力条件はテストケースへ落とし込むと整理しやすくなります。

STEP6：リスクに応じて優先順位をつける

最後に、すべての観点を同じ優先度で扱うのではなく、

• 不具合が起こる可能性
• 発生した場合の影響
• 利用頻度
• 過去の障害実績
• 機能の複雑さ
• 変更範囲

などを踏まえて優先順位をつけます。

例えば「発生確率」と「影響度」をそれぞれ高・中・低で評価するだけでも、テスト工数をどこへ重点配分すべきか判断しやすくなります。

【実例】ログイン機能からテスト観点を洗い出してみよう

ここまでの内容を、ログイン機能を例に具体化してみましょう。

仮に次のような仕様があるとします。

• メールアドレスとパスワードでログインする
• パスワードは8〜32文字
• 認証成功後はマイページへ遷移する
• 認証に失敗した場合はエラーメッセージを表示する
• 一定回数連続して認証に失敗した場合はアカウントをロックする

ここから観点を考えます。

このように、

機能を分解する → 観点を出す → 条件を考える → 確認ポイントを決める

という順番で整理すると、テストケースをいきなり考えるよりも全体像を把握しやすくなります。

テスト観点の「粒度」はどの程度が適切？

テスト観点を作成する際に、多くのテスターが悩むのが「どこまで細かく書けばよいのか」という問題です。

粒度が粗すぎる例として、

• 性能
• セキュリティ
• ユーザビリティ

だけを並べても、具体的に何を確認すればよいのかわかりません。

反対に、

• パスワード7文字を入力する
• パスワード8文字を入力する
• パスワード9文字を入力する

まで細かくすると、すでにテストケースに近い状態です。

一つの目安として、1つのテスト観点から複数のテストケースを作れる程度の粒度を意識すると整理しやすくなります。

例えば、

「パスワードの文字数」

という観点であれば、

• 最小値未満
• 最小値
• 最小値超
• 最大値未満
• 最大値
• 最大値超

などのテストケースを派生させられます。

また、チーム内で粒度が揃っていることも重要です。

観点の一覧をレビューするときは、

「同じ階層に並んでいる観点の抽象度が揃っているか」

を確認しましょう。

テスト観点の網羅性を高めるフレームワーク・テスト設計技法

テスト観点をゼロからすべて思いつくのは簡単ではありません。

そこで、既存の品質モデルやテスト設計技法を「観点を考えるための引き出し」として活用します。

ISO/IEC 25010などの品質モデル

ソフトウェアの品質を多面的に考える際に参考になるのが、ISO/IEC 25010などの品質モデルです。

「機能が動くか」だけでなく、

• 性能
• 信頼性
• セキュリティ
• 利用しやすさ
• 保守や変更への対応
• ほかの環境との共存・連携

など、幅広い品質面へ意識を向けるきっかけになります。

ただし、品質モデルの項目をそのままテストケースへ変換するのではなく、自社のシステムや利用シーンに合わせて具体化することが大切です。

Ostrandの4つのビュー

テスト観点を一方向に偏らせないための考え方として、Ostrandの4つのビューも参考になります。

主に、

• ユーザーの視点
• 仕様の視点
• 設計・実装の視点
• 欠陥・バグの視点

という異なる方向からテスト対象を考えます。

例えばログイン機能でも、ユーザー視点なら「実際の利用シナリオ」、仕様視点なら「仕様への適合」、設計・実装視点なら「内部構造や処理」、バグ視点なら「問題が起こりそうな条件」と、異なる観点が見えてきます。

ユーザーシナリオ

ユーザーが実際にどのような目的で、どのような順番で機能を利用するかを考える方法です。

個々の画面や機能が正しくても、一連の操作として組み合わせると問題が起きることがあります。

特にシステムテストや受け入れテストで有効な考え方です。

リスクベース

発生した場合の影響が大きい箇所や、不具合の発生可能性が高い箇所へ重点的にテストを割り当てます。

限られた時間ですべてを同じ密度で確認できない場合に重要です。

CRUD

データを扱う機能であれば、

• Create：作成
• Read：参照
• Update：更新
• Delete：削除

という視点で整理すると、操作の抜け漏れを発見しやすくなります。

同値分割

入力値を同じような結果になるグループへ分け、それぞれの代表値をテストする方法です。

すべての値を試さなくても、効率的に入力条件を確認できます。

境界値分析

不具合が発生しやすい上限・下限などの境界付近を重点的に確認する方法です。

文字数、金額、件数、日付、年齢など、範囲を持つ値のテストで特に役立ちます。

状態遷移テスト

システムの「状態」と、それを変化させる操作に注目する方法です。

例えば会員アカウントなら、

「未登録 → 仮登録 → 登録済み → ロック → 解除」

などの状態を整理し、正しい遷移だけでなく禁止されている遷移も確認します。

重要なのは、1つの手法だけですべての観点を網羅しようとしないことです。

複数のフレームワークやテスト設計技法を組み合わせることで、観点の偏りを減らせます。

単体テスト・結合テスト・システムテストで観点はどう変わる？

テスト工程によっても、重視すべき観点は変わります。

単体テストの観点

単体テストでは、関数やクラス、モジュールなど比較的小さな単位の正しさを確認します。

代表的な観点には、

• 入力値
• 境界値
• 分岐
• 戻り値
• 例外処理
• 内部状態
• データ変換

などがあります。

結合テストの観点

結合テストでは、複数の機能やコンポーネントを接続したときに正しく動くかを確認します。

例えば、

• データの受け渡し
• API連携
• 画面間の遷移
• DBとの連携
• 外部サービスとの接続
• エラーの伝播
• トランザクション

などが重要になります。

システムテストの観点

システムテストでは、システム全体が要求を満たしているかを確認します。

そのため、

• 業務シナリオ
• ユーザビリティ
• 性能
• セキュリティ
• 互換性
• 障害・復旧
• 権限
• 外部システム連携

など、より広い観点が必要になります。

同じ「テスト観点」という言葉でも、テストレベルによって適切な粒度や対象範囲が変わる点を意識しましょう。

実務で使えるテスト観点リストのテンプレート

洗い出した観点は、一覧として管理するとレビューや再利用がしやすくなります。

例えば次のような項目で整理できます。

ExcelやGoogleスプレッドシートなどで管理してもよいでしょう。

過去のプロジェクトで作成した観点リストを蓄積していけば、新しいプロジェクトを始める際のチェックリストとしても利用できます。

ただし、過去の観点をそのままコピーするのではなく、必ず今回のシステムの仕様やリスクに合わせて見直してください。

テスト観点を作るときによくある失敗

テスト観点を活用していても、使い方によっては期待した効果を得られません。

代表的な失敗例を紹介します。

仕様書に書いてあることだけを見る

仕様書は重要なテストベースですが、それだけではユーザーの誤操作や障害時、セキュリティ、性能などの観点が不足することがあります。

「仕様どおりか」だけでなく「実際に使ったらどうなるか」「どんな問題が起こりそうか」という視点を持ちましょう。

正常系ばかりになる

正常に使ったときの確認は考えやすい一方で、不正入力や通信障害、権限違反などは漏れやすい部分です。

正常系を作成したら、

「逆の条件だったらどうなるか」
「途中で失敗したらどうなるか」

と考える習慣を持つと効果的です。

観点の粒度がバラバラ

「性能」と「パスワード7文字」が同じ階層に並んでいるような状態では、レビューしにくくなります。

大分類・中分類・詳細観点などに階層化し、粒度を揃えましょう。

観点を増やすこと自体が目的になる

観点は多ければ多いほどよいわけではありません。

重要度の低い観点を大量に増やした結果、本当にリスクの高い箇所へ十分なテスト時間を割けなくなっては本末転倒です。

リスクと工数を考慮し、優先順位をつけることが重要です。

一度作った観点を更新しない

プロジェクトでは仕様変更や追加開発が発生します。

過去には問題にならなかった箇所でも、変更によって新しいリスクが生まれる可能性があります。

テスト観点も仕様やリスクの変化に合わせて更新しましょう。

質の高いテスト観点を作る5つのコツ

最後に、実務で観点を洗い出す際に意識したいポイントを紹介します。

1. ユーザー視点を忘れない

仕様書だけでなく、

「ユーザーは実際にどう使うのか」
「どんな操作を間違えそうか」
「問題が起きたとき、ユーザーはどう感じるか」

まで考えてみましょう。

実際の利用シナリオから考えることで、机上では見つけにくい観点が見えてきます。

2. 開発者・設計者と積極的にコミュニケーションする

テスターだけでは、内部構造や技術上のリスクを把握できないことがあります。

開発者へ、

「今回大きく変更した処理はどこですか？」
「実装が複雑になった部分はありますか？」
「障害が起きると影響の大きい処理はどこですか？」

などと確認すると、よりリスクの高い観点を発見できます。

3. 過去の不具合を活用する

過去の不具合には、そのシステム特有の「弱点」が表れています。

同じ種類の不具合が繰り返されていないか確認し、再発防止の観点として活用しましょう。

4. フレームワークやテスト設計技法を組み合わせる

経験だけに頼ると、人によって観点が偏ります。

品質モデル、Ostrandの4つのビュー、同値分割、境界値分析、状態遷移などを組み合わせることで、思考の抜けを補えます。

5. チームでレビューする

一人で考えたテスト観点には、どうしてもその人の経験や知識による偏りが生じます。

開発者、テスター、プロダクト担当者など、異なる立場のメンバーがレビューすることで、新しい観点を発見しやすくなります。

テスト観点をレビューするときのチェックリスト

作成したテスト観点をレビューする際は、次の項目を確認してみましょう。

• テストの目的が明確になっているか
• 主要な機能が漏れなく分解されているか
• 正常系だけでなく異常系も含まれているか
• 境界値を考慮しているか
• ユーザー視点が含まれているか
• 権限による違いを考慮しているか
• データの登録・更新・削除を考慮しているか
• 性能やセキュリティなどの非機能面を検討したか
• 通信障害や外部連携失敗を考慮したか
• 過去の不具合を反映しているか
• 観点の粒度が揃っているか
• 重複している観点がないか
• リスクに応じて優先順位がついているか
• 各観点から具体的なテストケースを作成できるか

すべてを機械的に満たす必要はありません。

テスト対象に必要な項目を選び、観点の抜け漏れを確認するために活用してください。

テスト観点に関するよくある質問

テスト観点とテストケースはどちらを先に作りますか？

一般的には、テスト観点を先に整理し、その観点を具体化してテストケースを作成します。

先に観点を整理することで、テストケースの抜け漏れや重複を確認しやすくなります。

ただし、実際の開発現場では、既存のテストケースを分析しながら新しい観点を発見することもあります。必ず一方向に進めなければならないわけではありません。

テスト観点は細かいほどよいのでしょうか？

細かければよいわけではありません。

細かくしすぎるとテストケースとの違いがなくなり、観点を整理するメリットが小さくなります。

1つの観点から複数のテストケースが派生する程度を目安にすると整理しやすいでしょう。

テスト観点を漏れなく洗い出すことはできますか？

複雑なソフトウェアについて、考えられるすべての観点を完全に洗い出すことは現実的ではありません。

そのため、品質モデル、テスト設計技法、過去の不具合、ユーザーシナリオなど複数の情報源を活用しながら、重要なリスクに対して十分な観点を持てているかを考えることが大切です。

テスト観点リストは使い回してもよいですか？

過去の観点リストを再利用すること自体は有効です。

特に同じ製品や似たシステムであれば、過去の観点は重要な資産になります。

ただし、仕様・ユーザー・技術構成・リスクはプロジェクトごとに異なるため、そのままコピーするのではなく、必ず今回のテスト対象に合わせて追加・削除・修正しましょう。

テスト観点は誰が作るものですか？

テスト担当者やQA担当者が中心となることが多いものの、テスターだけで作る必要はありません。

開発者は技術的なリスク、プロダクト担当者はユーザーやビジネス上のリスクなど、それぞれ異なる情報を持っています。

複数の立場からレビューすることで、より多角的なテスト観点を作成できます。

まとめ

テスト観点とは、ソフトウェアやシステムを「何に着目して、どのような切り口からテストするのか」を整理したものです。

テストケースをいきなり作成するのではなく、先にテスト観点を整理することで、

• テストの抜け漏れを減らす
• テストケースの重複を減らす
• チームでレビューしやすくする
• リスクに応じてテストへ優先順位をつける

といった効果が期待できます。

テスト観点を洗い出す際は、

テストの目的を確認する → 対象を分解する → テストベースを集める → 複数の視点から観点を出す → 粒度を揃える → 優先順位をつける

という流れで整理するとよいでしょう。

また、ISO/IEC 25010などの品質モデル、Ostrandの4つのビュー、ユーザーシナリオ、リスクベース、同値分割、境界値分析、状態遷移などを組み合わせることで、自分の経験だけでは気づきにくい観点を補えます。

重要なのは、観点をたくさん出すことそのものではありません。

テスト対象にどのようなリスクがあり、そのリスクを発見・評価するためには何を確認する必要があるのか。

この問いを起点にテスト観点を設計することが、質の高いソフトウェアテストにつながります。

一度作ったテスト観点も、仕様変更や不具合、ユーザーからのフィードバックなどをもとに継続的に見直し、自分たちのテスト資産として蓄積していきましょう。

QA業務効率化ならPractiTest

テスト管理の効率化についてお悩みではありませんか？そんなときはテスト資産の一元管理をすることで工数を20%削減できる総合テスト管理ツール「PractiTest」がおすすめです！

この記事の監修

Dr.T。テストエンジニア。
PractiTestエバンジェリスト。
大学卒業後、外車純正Navi開発のテストエンジニアとしてキャリアをスタート。DTVチューナ開発会社、第三者検証会社等、数々のプロダクトの検証業務に従事。
2017年株式会社モンテカンポへ入社し、マネージメント業務の傍ら、自らもテストエンジニアとしテストコンサルやPractiTestの導入サポートなどを担当している。

記事制作：川上サトシ（マーケター、合同会社ぎあはーと代表）