GENZ, Inc.

第三者検証で守る 賃貸管理ソフトの入金消込と送金を第三者が検証

入金消込・送金精算・更新請求の金額差異は、改修のたびに口頭で範囲を決める検証では見逃されます。GENZが範囲の根拠と記録を残しながら検証します。

支援事例

支援実績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

提供するテストの内容と進め方

スプリントへの伴走、大規模機能の網羅的な検証、第三者としての実施、証跡の引き渡しまで、テストを一貫して担います。

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

ご相談から報告までの流れ

ご相談からテスト結果のご報告まで、範囲と記録の形を確認しながら進め、社内説明に使える形で残します。

フォームまたはお電話でお問合せいただく

対象のソフトウェアと改修の予定をお知らせください。日程を調整します。

現状をうかがい検証の範囲を相談する

開発の進め方と回帰が必要な範囲をうかがい、観点の線引きを一緒に決めます。

お見積とテスト計画をご提示する

範囲・期間・金額の対応を示したお見積とテスト計画をご提示します。

テストを実施し、結果をご報告する

計画に沿ってテストを実施し、確認済みの範囲と残課題を報告書にまとめます。

金銭処理の検証、第三者の視点で

賃貸管理ソフトのテスト体制について、ご相談ください

ご相談いただくと、入金消込や送金精算を含む改修について、テスト範囲の切り分け、確認の優先順位、回帰テストの要否を整理してお渡しします。稟議の材料にそのままご利用いただけます。