この記事は LITALICO Engineers Advent Calendar 2025 シリーズ 4 の 24 日目の記事です。
1. はじめに
はじめまして！2025 年 11 月、株式会社 LITALICO に入社した QA エンジニアの @kmrzk です。所属は、障害児支援事業所向けの SaaS を提供するチームです。
私は元々、6 年半ほど情報システム開発に従事していました。その過程で、特にソフトウェアの品質に興味を持ち、QA エンジニアに挑戦する形で入社しました。また、障害福祉領域に対して、個人的な興味はありましたが、事業所の業務内容や法令などの知識は全くありませんでした。
この記事は、そんな私が最初の 1 か月間で取り組んだ、配属先でのオンボーディング体験記になります。
一般的に、QA エンジニアのオンボーディングと聞くと、以下のような技術的な知識の学習を想像するのではないでしょうか。
- テストドキュメントの書き方
- テスト技法（境界値分析や同値分割など）
- テスト自動化ツールの使い方（Playwright や mabl など）
ですが、まず私が時間を掛けて取り組んだのは、障害福祉領域のドメイン知識（業務知識）習得に特化した、「請求業務オンボーディング」でした。
2. 請求業務オンボーディング体験記
私が取り組んだ請求業務オンボーディングは、課題 1 ～ 8 で構成されていました。また、これは個人的な分類ですが、これらの課題は、以下 3 つのパートに分けられるように思いました。
- 課題 1: 障害福祉業務の概要を知る
- 課題 2 ～ 7: 実際の請求業務の流れに沿って自社プロダクトを操作する
- 課題 8: 自社プロダクトを使用せずに請求明細書を作成する
以降では、これら 3 つのパートについて、順番に説明していきます。
2.1. 課題 1: 障害福祉業務の概要を知る
課題 1 は、障害福祉業務、特に請求業務の概要を知るというものです。具体的には、以下のような内容になります。
- 国民健康保険中央会の請求事務ハンドブックを読む
- 障害福祉業務の研修動画を視聴する
- 児童発達支援・放課後等デイサービスとは
- ご契約・退所の手続き
- 請求業務
- 省令等で定められたルール
- 通所支援計画
- 報酬の構造・減算
- 加算
- 衛生管理
- 応急処置
- 防災・有事対応
冒頭で述べたように、私には事業所の業務内容や法令などの知識は全くありませんでした。そのため、分からない用語が出てくることも多く、その度に調べながら進める必要がありました。その際、役立ったものが、自社メディアである LITALICO発達ナビの記事です。
例えば、私が研修動画を視聴する中で、「インテーク」という用語が出てきました。この用語について調べたところ、LITALICO発達ナビの記事を見つけました。そして、この記事を通して、インテークについて理解することができました。
また、私と同じように、他にもこの用語が分からず、同じ記事に辿り着く方がいるのだろうと想像しました。そして、自身の所属チームが提供する SaaS とは別のプロダクトについても、それがどのように役立っているのかについての解像度を高めることができました。
2.2. 課題 2 ～ 7: 実際の請求業務の流れに沿って自社プロダクトを操作する
課題 2 ～ 7 は、課題 1 で学んだ請求業務の流れに沿って、以下 2 つの自社プロダクトを操作するものです。
LITALICO発達ナビ for BUSINESS の施設運営ソフト（以下、施設運営ソフト）
かんたん請求ソフト
具体的には、以下のような操作を行いました。
- 受給者証情報を登録する
- 日々のサービス提供実績を登録する
- 請求総額を計算する
- 上限額管理を行う
- 国民健康保険団体連合会（国保連）への請求データを作成する
- 保護者への請求を管理する
課題 1 の内容を踏まえて、実際に手を動かしてみることで、請求業務の流れに対する理解を深めることができました。また、施設運営ソフトやかんたん請求ソフトの操作感を掴むことができました。
特に、私が施設運営ソフトを操作していて印象的だったのは、利用者に対して非常に親切な設計になっており、直感的に使いやすかったことです。
例えば、施設運営ソフトでは、請求総額を計算する前に、事業所実績というデータを登録しておく必要があります。このデータが未登録の状態で請求総額を計算しようとすると、警告が表示されて計算を実行できません。ですが、その警告と併せて、以下のスクリーンショットのように、事業所実績を登録するページへのリンクが表示されます。そのおかげで、まだ施設運営ソフトに不慣れな私でも、あまり詰まることなく操作することができました。
ちなみに、私の前職における主な業務は、いわゆる受託開発でした。だからということではないのですが、このような「あれば嬉しいが、必須ではない機能」、あるいは「直接の要求ではない機能」については、あまり検討や実装をしてこなかったように思います。これから、自社製品開発に携わる、特に利用者目線での品質を考える上では、この操作感のような視点も重視する必要があると認識しました。
2.3. 課題 8: 自社プロダクトを使用せずに請求明細書を作成する
課題 8 は、既に課題 2 ～ 7 で実施した請求明細書作成業務を、あえて施設運営ソフトやかんたん請求ソフトは使用せずに、手作業で行うというものです。
まず、必要な情報として以下が与えられます。
- 事業所情報
- 利用者情報
- 利用者の実績
これらを元に、請求明細書を作成し、Excel で用意された請求明細書のフォーマットに入力していきます。用語等の詳細な説明は省きますが、主に以下のような作業が必要になります。
- サービスコード表から、サービスコードを探す
- サービスコードとその単位数を Excel に転記する
- 利用者の実績から、各サービスの回数を計算する
- サービス単位数（= 単位数 * 回数）を計算する
- 事業所情報から、単位数単価を調べる
- 総費用額（= サービス単位数 * 単位数単価）を計算する
- 総費用額と利用者情報から、上限額管理について計算する
これらは、施設運営ソフトやかんたん請求ソフトを使用した場合と比較して、非常に手間のかかる作業でした。
例えば、サービスコード表は、児童発達支援だけでも PDF で 400 ページ以上ある巨大な表です。この中から、事業所種別や障害児種別、事業所定員などの条件が一致するサービスコードを探す必要があります。
また、サービスコードやその単位数を Excel に転記する際、あるいは各種計算の際、ミスしないかという不安を感じていました。
課題 1 で学習した概念として、返戻や過誤というものがあります。
- 返戻: 国保連に提出した請求情報に誤りがあり、支払がされずに差し戻されること
- 過誤: 既に支払が確定した請求情報に誤りがあり、請求を取り下げること
返戻、過誤のいずれも、事業所に入ってくるお金に影響する上に、追加の手続きが必要になるため、できるだけ回避したいものになります。
施設運営ソフトやかんたん請求ソフトの場合、サービスコードの特定や計算は自動で実行できます。それにより、利用者の手間を省くだけでなく、返戻や過誤の可能性を下げることで、事業所の安定的な運営を支援しているのだと理解できました。
この課題 8 を通じて、何が利用者にとっての困りごとであり、それを自社プロダクトがどのように解決しているのかについて、身をもって実感できたように思います。
3. 請求業務オンボーディングの感想
請求業務オンボーディング全体を通した感想についてまとめます。
まず、改めて実感したことは、LITALICO の QA グループが、特にドメインの理解や、それに基づく利用者目線での品質を重視していることです。元々、そのような QA グループの方針については、採用面接の中でも伺っていました。ですが、今回のオンボーディングを通じて、その方針をより詳細に理解することができました。
また、このオンボーディングを始める際、最初の 1 か月ぐらいは時間を掛けて良いと言われていました。そのため、ただ焦って課題をこなすのではなく、疑問点について調査、質問しながら進めることで、より深くドメインについて学ぶことができました。
そして、Slack 等で何か質問した際、様々な資料を引用して詳細にご回答いただけた上に、ポジティブなフィードバックをいただき、質問や相談がしやすい環境であることも実感できました。
現在は、リスク分析のような QA 業務のミーティングに少しずつ参加しています。冒頭でお話しした通り、私は開発から QA エンジニアに職種変更しているため、詳しいリスク分析の方法などはまだ分かりません。ですが、分析対象の機能について、それが誰のために、なぜ必要なのかということは、実感として理解できているように思います。
逆に、QA エンジニアとしての技術的な要素だけ先に学習しても、あまり議論についていけなかったかもしれません。その点でも、まずは時間を掛けてドメイン知識を習得する期間が設けられていることは、合理的でもあるように思いました。
4. おわりに
請求業務オンボーディングは、ドメイン知識の習得に重点が置かれており、私のように知識が全くない状態からでも、必要な知識を身につけられるものでした。ただし、私がこの 1 か月間で習得したのはあくまで、最低限の内容になります。また、当然ですが、ドメイン知識だけでは QA 業務はこなせません。QA の技術的な知識も必要になります。今後は、ドメイン知識と QA の技術的な知識を並行して学びながら、利用者目線での品質を保証できる QA エンジニアを目指していきたいです。