制度改定の適用日は動かず、検証期間が開発の遅れを吸収している
報酬改定の適用日は制度で定まっており、動かせません。開発が遅れた分は検証期間が吸収し、確認を削る判断が期限側から強制されます。
GENZ, Inc.
開発・提供側の
障害福祉システムの
開発・提供側の
障害福祉システムの検証を、実装とは別の目で
制度改定の期限が動かないなかで、確認した範囲と確認していない範囲を説明できる状態にするため、GENZが第三者の視点で検証を引き受けます。
支援事例
支援実績5,000件以上
相談支援ソフトの検証範囲が勘で決まる理由
相談支援ソフトのテストでは、確認する範囲を毎回その場で決めています。制度改定の期限が動かないなかで担当者の勘に頼る線引きが続くのは、検証期間の位置づけと体制に構造的な理由があるためです。
制度改定の
実装した担当者がテスト項目を作るため、仕様の読み違いがそのまま写る
品質保証が兼務の体制では、実装した本人がテスト項目を作ります。仕様の読み違いは項目にそのまま写り、検証を通っても本番で落ちます。
計画・記録・請求をまたぐデータの受け渡しが、誰の確認範囲にも入らない
機能ごとに担当が分かれると、計画・記録・請求をまたぐデータの受け渡しは誰の確認範囲にも入りません。連携部分の検証が空白のまま残ります。
仕様が変わらない基盤更新では、回帰の確認範囲を絞る根拠が持てない
仕様変更のない基盤更新では、全部を回帰する余力がありません。絞る根拠がないため、帳票出力や請求データへの影響の有無は属人的な勘で決まります。
請求期間に事象が出ると、原因の特定より暫定の回避が先に進む
月初の請求期間に事象が出ると、業務を止めない暫定回避が先に進みます。原因の特定が積み残され、次のリリース判定で説明できない領域が増えます。
未確認の範囲を示さずにリリースを重ねるリスク
確認範囲の根拠を示せないまま出し続けると、リスクは不具合だけでなく、事業所との関係と社内の判断材料にも残ります。
検証の範囲設計から実行までを第三者が担う
確認できていない範囲を言葉にできない状態は、社内の体制だけでは崩しにくいものです。GENZは第三者の視点から対象の構造を読み、範囲の設計からテストの実行、結果の記録までを担い、判断の材料を形にします。
範囲の線引きをその場で決める状態が続けば、確認の抜けが本番の請求データの誤りとして現れるおそれがあります。
対象の構造を読み、確認する範囲と確認しない範囲を先に決める
計画作成・記録・請求データ作成といった機能と、それらをまたぐデータの受け渡しを洗い出し、確認する範囲と確認しない範囲を根拠付きで宣言します。誰の担当でもない領域を、誰かの確認対象へ変えます。
確認する資料
- テスト計画書
- 対象範囲一覧
- 除外範囲根拠
制度で定まる部分と自社仕様の部分を分けないままでは、改定の影響範囲を見誤り、帳票や請求データの欠落を見逃すおそれがあります。
制度で定まる算定と様式の部分と、自社仕様の部分を分けて設計する
制度で仕様が定まる報酬・加算・様式の部分は改定内容と突き合わせて確認し、自社仕様の部分は既存の動作を壊していないかの観点で確認します。確かめる手順が異なる両者を分けて設計します。
確認する資料
- 算定照合一覧
- 様式照合表
- 仕様差分一覧
圧縮された期間で順序の根拠を持たないままでは、適用日に必要な確認が間に合わず、削った範囲を説明できないおそれがあります。
開発の進行と伴走し、適用日に間に合う順序でテストを進める
適用開始日から逆算し、請求データの生成や算定ロジックのように業務を止められない部分から先に検証します。開発の遅れで期間が圧縮されても、何を優先し何を後回しにしたかの順序が記録に残ります。
確認する資料
- 実行順序表
- 進行状況表
- 残余対応一覧
回帰の確認範囲を勘に頼ると、基盤更新のたびに既存の帳票出力や請求データの生成が壊れていても気づけないおそれがあります。
仕様が変わらない更新にも、回帰の確認範囲を残す
基盤やミドルウェアの更新など仕様が変わらない改修でも、帳票出力と請求データの生成への影響を確かめる範囲を毎回定めます。個人の勘に頼る回帰の確認を、基準のある運用へ置き換えます。
確認する資料
- 回帰範囲表
- 影響確認結果
- 更新確認記録
確認した範囲と結果が形に残らなければ、リリース判定と社内説明が主観に頼り、テスト投資の判断が停滞するおそれがあります。
確認した範囲と結果を、判定と社内説明に使える形で残す
実施した範囲・結果・未実施の範囲を、リリース判定会議や取締役への説明でそのまま使える文書として残します。確認できていない範囲の広さを、件数ではなく範囲として示せる状態にします。
確認する資料
- 結果集約表
- 未実施範囲表
- 判定説明資料
- 説明用根拠表
提供する検証の内容と、進め方の段階
GENZは、相談支援ソフトの開発と制度改定の工程に沿ってテストを設計し、確認した範囲と結果を提示できる形で残します。
STEP 01
対象範囲と前提の確認改定日と請求期間から逆算して範囲を確定
どう確かめるか
制度改定の期日に向け開発と伴走するテストの実施
制度改定の適用日は動かせず、開発の遅れは検証期間を圧縮します。GENZは開発と伴走してテストを進め、限られた期間で確認できる範囲を先に確定させます。
- 01制度改定の適用日と請求締めから逆算し、検証に使える期間を設定します。
- 02計画・記録・請求をまたぐ連携範囲を含め、テストのスコープを宣言します。
- 03複数拠点の設定差や基盤更新の有無を前提条件として固定します。
OUTPUTテスト計画と項目一覧
STEP 02
テスト計画と観点の設計機能横断の受け渡しまで観点へ組み込む
どう確かめるか
大規模な業務システムを対象とした網羅的なテスト設計
計画作成・支援記録・請求データ作成をまたぐデータの受け渡しは、担当が分かれると検証の空白になります。中核機能と連携範囲をスコープとして宣言し、回帰確認まで含めて設計します。
- 01中核機能ごとの観点と、機能を横断するデータ受け渡しの観点を設計します。
- 02帳票出力と請求データ生成の回帰確認をテスト項目へ組み込みます。
- 03確認の優先順位と必要工数の考え方を、期間に応じて示します。
OUTPUT実行結果と事象の記録
STEP 03
テストの実行と事象の報告事象は発生条件と影響範囲を添えて報告
どう確かめるか
実装から独立した第三者の視点でのテスト工程の引き受け
実装者がテスト項目を作る構造では、仕様の読み違いが項目にそのまま写ります。GENZは実装から独立した立場で工程を引き受け、通ることより落ちる条件を起点に項目を組み立てます。
- 01算定ロジックと帳票、請求データの仕様が改定内容と一致するかを検証します。
- 02検出した事象は発生条件と影響範囲を添え、開発側が再確認できる形で報告します。
- 03暫定回避で止める事象と修正が必要な事象を切り分けて記録します。
OUTPUT未実施範囲の明細
STEP 04
結果の整理と次回へ引き継ぐ範囲の整備確認範囲と未実施範囲を次回へ引き継ぐ
どう確かめるか
判定と社内説明に提示できる形でのエビデンスの整備
確認した範囲、実行結果、未実施の範囲とその理由を、リリース判定会議や取締役への説明に使える形で整えます。「どこを確認しなかったか」が説明できる状態を作ります。
- 01確認した範囲と結果を、リリース判定会議で示せる形に整理します。
- 02未実施の範囲とその取捨選択の理由を明細として残します。
- 03次回の改修や次の制度対応へ引き継ぐ観点を整備します。
OUTPUT次回改修への引き継ぎ事項
相談支援ソフトの検証で、はじめに確認する観点
固定費を抱えない人日単位のアサイン、監査にも使える独立した検証の記録、育成期間なしに活かせる専門ノウハウなど、第三者へのアウトソースには複数のメリットがあります。
OUTSOURCING RATIONALE
THIRD-PARTY VERIFICATION
01
必要な時に必要な分だけ
人日単位のアサインで固定費を抱えず、繁忙期に増減できます。
02
独立した視点で品質を底上げ
独立した検証で偏りを排し、監査に使える客観的な記録を残せます。
03
専門ノウハウを即戦力で
JSTQB認定エンジニアが在籍し、対象領域固有の検証知見を育成期間なしに活用できます。
専門知識を持ったテストエンジニアが、第三者の視点でテストするメリット
- 制度改定ごとの改修範囲で、どこまで確認するかの根拠を整理する
- 実装した本人以外の目でテスト項目を作り、見落としを防ぐ
- 確認した範囲と未確認の範囲を、リリース判定の場で示せる形に分ける
- 基盤更新やパッチ適用時に使い回せる回帰確認の範囲を資産として残す
開発体制に合わせた引き受けの形
相談支援ソフトの検証を外部へ依頼するとき、引き受けの形は開発体制によって異なります。兼務の有無、受託開発への委託範囲、制度改定の重なりに合わせ、GENZは範囲の設計から実行と成果物の整備までを担います。
品質保証が開発と兼務になっている場合
テスト項目を実装者以外の目で設計し、確認した範囲と未確認の範囲を分けて報告します。兼務の負担を増やさず、判定会議で使える形に整えます。
社内に品質保証の担当を置いている場合
既存のテスト計画を起点に、制度改定で影響する範囲の抜けを第三者の視点で補います。品質保証担当者様と役割を分け、実行と記録を担います。
開発の一部を受託会社へ委託している場合
受託会社が実装した範囲を、発注者側の立場で検証します。検収の基準となる確認項目と結果を整理し、委託先とは別の目で品質を確かめられます。
制度改定の対応が同じ期間に集中する場合
適用日が動かない改修に対し、開発と伴走して検証を進めます。改修が確定した機能から順に確認し、リリース判定までに結果を間に合わせます。
お問合せから検証の着手までの流れ
お問合せから対象範囲の合意、ご契約、検証着手までの流れと、各工程で必要な情報を示します。
お問合せと検証のご相談の受付
制度改定対応や再発防止など、検証の目的と実施の予定をお伺いします。
対象システムと範囲のお打ち合わせ
相談支援ソフトの構成と、切り出す検証範囲をすり合わせます。
検証範囲のご提案とお見積のご提示
範囲・工数・成果物の形をまとめた見積をご提示します。
ご契約と対象範囲の確定、検証の着手
ご契約後、優先順位を決めたうえで検証に着手します。
テスト範囲に関する無料相談のご案内
確認した範囲を説明できる状態で、次のリリースを迎えるために
ご相談では、検証範囲の切り分け、優先順位、必要工数、請求や基盤更新に絡む関連テストの要否まで整理してお伝えします。社内の判定会議や決裁に使える形でご確認いただけます。