GENZ, Inc.

第三者テスト 案件管理ツールの導入と更改を第三者テストで検証

案件管理ツールの導入・更改で、受け入れ確認の範囲を決めるところから、範囲の決定と記録の作成まで引き受けます。

支援事例

支援実績5,000件以上

支援実績を示す企業ロゴ 01
支援実績を示す企業ロゴ 02
支援実績を示す企業ロゴ 03
支援実績を示す企業ロゴ 04
支援実績を示す企業ロゴ 05
支援実績を示す企業ロゴ 06
支援実績を示す企業ロゴ 07
支援実績を示す企業ロゴ 08
支援実績を示す企業ロゴ 09
支援実績を示す企業ロゴ 10
支援実績を示す企業ロゴ 11
支援実績を示す企業ロゴ 12
支援実績を示す企業ロゴ 13

この記事はソフトウェアテストの専門家が監修しています

監修枡井 愼治株式会社GENZ 代表取締役

GENZは創業以来、5,000件以上のソフトウェアテスト・第三者検証を手がけてきたプロフェッショナルです。品質に関する課題やお悩みに、真摯に寄り添います。

代表取締役 枡井 愼治 株式会社GENZ 〒101-0062 東京都千代田区神田駿河台2-3-11 ヒューリック御茶ノ水ビル3F TEL:03-5244-4711
01 ISSUES

案件管理ツールの切り替えで見落とされやすい箇所

案件管理ツールの切り替えでは、設定や移行の小さな見落としが稼働後に表面化します。受け入れ確認で見逃されやすい主な箇所を、法務部門の業務に即して整理しました。

案件のステータスが設計どおりに切り替わらない

承認や差し戻しの分岐を確認しないまま稼働すると、案件が途中のステータスで止まり、担当者の画面で完了にできない事象が起きます。

ステータス遷移

権限の設定を越えて他部門の案件が見えてしまう

部門・案件・役職の組み合わせを一部しか確かめていないと、閲覧を限るべき案件が他部門の一覧に表示され、情報の取り扱い規程に抵触します。

権限の組み合わせ

移行した案件データの項目が欠けたまま稼働する

件数の一致だけで移行を終えると、項目単位の欠落や文字の置き換わりが残り、稼働後に「案件が見当たらない」という問合せが発生します。

案件データの移行

案件の期限を知らせる通知が担当者に届かない

通知の宛先や条件を実際の利用者で確かめていないと、期限の通知が担当者へ届かず、回答期限を過ぎてから気づく事態になります。

期限通知の配信

集計した案件の内訳が登録した内容と合わない

集計の条件を登録データと突き合わせていないと、報告用の集計結果と案件の登録内容が合わず、合議に出す数値を説明できなくなります。

集計結果の整合
02 RISK

確かめないまま稼働させたときに残るもの

確認の手順が決まらないまま稼働に進むと、見つかるはずの不備が利用者の操作のなかに埋もれます。見落としは稼働後の遅れや費用として表面に出ます。

業務上の問題対応を行う担当者の様子を写した写真。
03 REVIEW

第三者の視点でテストの範囲を組み立てる観点

案件管理ツールの受け入れ確認は、社内で設定を決めた側がそのまま確かめる形になりがちです。確認の範囲に偏りが出やすい構造を踏まえ、発注側とは別の立場でテストの範囲を組み立てる観点を五つに整理します。

要件と実操作のずれが残り、業務の途中で使えない設定のまま稼働するおそれがあります

業務の流れとテストの項目をひとつずつ突き合わせる

要件整理で決めた案件の区分・ステータス・承認の流れを、業務手順に並べ直します。各段とテスト項目を突き合わせ、設定は反映されたのに業務で使われない項目や、操作順とずれた承認の段を見つけます。

確認する資料
  • 業務手順書
  • 設定一覧
  • テスト項目表
閲覧範囲を限る案件が想定外の利用者に開かれ、情報の取り扱い規程に抵触するおそれがあります

部門と役職ごとの権限と閲覧範囲の組み合わせを洗い出す

部門・案件・役職で組み合わされる権限設定を一覧に起こし、見える側と見えない側の両方から操作します。社外へ共有される案件も条件に含め、閲覧を限るべき記録が想定外へ広がっていないかを確かめます。

確認する資料
  • 権限設計書
  • 組織体制図
  • 権限マトリクス
項目単位の欠落が残り、稼働直後に案件が見当たらない申告として表面化するおそれがあります

移行した案件データを項目の単位で突き合わせる

旧システムや表計算ファイルから移した案件データを、件数だけでなく項目の単位で突き合わせます。担当名や期限の欠落は件数では現れないため、移行前後で同じ画面を開いて比べる手順を決めます。

確認する資料
  • 移行仕様書
  • 移行元データ
  • 突合結果表
原因の帰属が切り分けられず、調査が複数の担当の間で滞留するおそれがあります

連携する社内システムとの境目で原因を切り分ける

認証・権限の基盤や文書管理など、案件管理ツールが接続する社内外のサービスを洗い出し、不具合がどちら側に起因するかを切り分けられる状態にします。境目を確かめないと、調査が担当の間で滞ります。

確認する資料
  • 連携構成図
  • 接続仕様書
  • 切り分け手順
確認範囲の根拠が残らず、稼働可否の合議で判断材料を示せないおそれがあります

確かめた範囲と確かめていない範囲を書き分ける

確かめた条件と結果を記録に残し、確かめていない範囲を理由とともに書き分けます。絞った場合も線引きの根拠が残れば、稼働可否の合議で確認の範囲を問われたときに判断の材料として示せます。

確認する資料
  • テスト計画書
  • 実施記録
  • 不具合一覧
  • 範囲線引き表
04 TEST DESIGN

案件管理ツールのテストとして引き受ける範囲

案件管理ツールの受け入れに向けて、GENZが引き受ける検証の範囲を、計画から記録の引き渡しまでの各段で示します。

STEP 01 対象の範囲と体制を確かめる設定値の根拠資料と体制を棚卸しします
どう確かめるか

案件管理ツールのテスト計画と確かめる観点の設計

案件の区分・ステータス・権限の設定意図を確認し、機能・データ・連携先のそれぞれの範囲で何を確かめるかを計画に落とします。確認範囲の根拠が記録として残る形にします。

  • 01案件区分・ステータス・権限の設定値とその意図を確認します
  • 02機能・データ・連携先のうち検証する範囲を取り決めます
  • 03社内の担当とベンダー側の作業の境目を取り決めます
OUTPUTテスト計画書と観点表
STEP 02 テストを設計する業務手順に沿った観点と項目にします
どう確かめるか

法務の業務手順に沿ったテスト項目づくりと実行

法務担当者やパラリーガルの実際の操作手順に沿って項目を作り、登録から完了までの流れで実行します。期限の通知や権限による表示の差も手順どおりに検証します。

  • 01案件の登録から完了までの業務手順を観点へ展開します
  • 02期限の通知と権限ごとの表示の違いの観点を立てます
  • 03テストの実行に必要な前提データと検証環境を揃えます
OUTPUTテストケースと実行記録
STEP 03 テストを実行し、不具合を追う発生条件を絞り、原因の所在を追います
どう確かめるか

移行した案件データを項目の単位で確かめる検証

表計算ファイルや旧システムから移した案件データを、件数だけでなく項目単位で突き合わせます。文字の置き換わりや関連文書の参照欠落を特定し、一覧に出ます。

  • 01法務の業務手順どおりに操作し、実行の結果を記録します
  • 02見つかった不具合を発生の条件まで絞って追跡します
  • 03修正後の動作を同じ手順でもう一度実行して確かめます
OUTPUT移行データの突合結果表
STEP 04 結果を報告し、記録を引き渡す合議で説明できる記録の形で渡します
どう確かめるか

見つかった不具合の記録と原因の切り分け報告

見つかった不具合は、再現手順・発生条件・影響範囲を添えて記録します。ツールの設定・移行元データ・権限基盤のどこに起因するかを切り分け、報告にまとめます。

  • 01テストを実施した範囲と確認の結果を報告書にまとめます
  • 02確認していない範囲と稼働後に残る条件を明示します
  • 03稼働後の問合せの切り分けに使える記録を引き渡します
OUTPUT不具合報告書と対応履歴
05 RATIONALE

稟議に載せる前に整理しておきたいこと

固定費を抱えない人日単位のアサイン、監査にも使える独立した検証の記録、育成期間なしに活かせる専門ノウハウなど、第三者へのアウトソースには複数のメリットがあります。

OUTSOURCING RATIONALE THIRD-PARTY VERIFICATION

必要な時に必要な分だけ

人日単位のアサインで固定費を抱えず、繁忙期に増減できます。

独立した視点で品質を底上げ

独立した検証で偏りを排し、監査に使える客観的な記録を残せます。

専門ノウハウを即戦力で

JSTQB認定エンジニアが在籍し、対象領域固有の検証知見を育成期間なしに活用できます。

ノートPCを前に担当者同士が相談しているオフィスの写真。

専門知識を持ったテストエンジニアが、第三者の視点でテストするメリット

  • 確認した範囲と絞った理由を、稟議で説明できる形に整理できます
  • ベンダー側と発注側の確認の境目を、更改後も使える基準にできます
  • 外注費と手戻りの復旧費を並べた、投資判断の材料を用意できます
  • 稼働可否の合議へそのまま出せる記録様式が手元に残ります
06 SERVICE

テストの支援として用意しているもの

テストの支援では、計画の設計から実行、報告までの各段で、受け入れ確認の範囲の決定と記録の様式をあわせて引き受けます。ご相談の段階で、確認すべき範囲と優先順位、必要な工数の見立てを整理してお示しします。

SVC 01

短い開発サイクルに並行して進めるテスト

開発の区切りごとにテスト計画と観点を合わせ直し、設定変更のたびに確認範囲を更新します。変更の入った部分から順に確かめられます。

リスク要因と優先順位を示す無文字の図解。
SVC 02

規模の大きいシステムの検証範囲を受け持つ

移行した案件データを項目単位で突き合わせ、権限と閲覧範囲の組み合わせを一覧で確認します。確認済みと未確認の組み合わせを分けて管理します。

複数のシステムや連携先にまたがる確認範囲を示す無文字の図解。
SVC 03

発注側とも構築側とも別の立場で進める

発注側でもベンダー側でもない第三者として検証を担います。構築側の動作確認と受け入れ確認の境目を整理し、双方が判断できる記録を残します。

計画から報告までの流れを示す無文字の図解。
SVC 04

社内で示す証跡を整理して残す

テスト計画、実行結果、不具合の記録を、合議や稟議に出せる様式で整理します。確認した範囲と未確認の範囲の線引きがわかる形で残します。

確認対象の領域を区分して示す無文字の図解。
07 FLOW

相談から着手までの進め方

受け入れ確認を外注する場合の、相談から着手までの流れを説明します。起案に使える範囲の記載も確かめます。

問合せと現在の進み具合の共有

構築の進み具合と確認を回す人手の状況をお聞きします。起案の有無も伺います。

検証する対象の範囲のすり合わせ

ベンダー側の作業範囲との境目を確かめ、外へ出せる作業の区分を整理します。

見積書の提示と契約の取り交わし

範囲に応じた工数と費用を示し、稟議資料へ転記できる見積書をお渡しします。

着手と定例会議での進捗の報告

稼働予定日から逆算した日程で着手し、週次の会議で記録と課題を報告します。

受け入れ確認の範囲設計から相談できます

案件管理ツールの受け入れ確認について、範囲の決定から相談できます

確認すべき範囲の切り分けから進められます。ご相談いただくと、テスト範囲と優先順位の整理、必要工数の見立て、移行データの突合や権限の検証の要否まで、起案に使える粒度でお示しします。