助成金の対象になるか診断するページをホームページに作る — 要件表を条件に落とす

募集要項に並んでいる要件は、たいてい箇条書きのAND条件です。従業員の規模がこの範囲にあること、事業所がこの区域にあること、対象の取り組みを実施していること。ひとつでも外れれば対象にならない、という形をしています。この構造は、診断の分岐とほぼそのまま重なります。

だから助成金・補助金の対象チェックは、診断コンテンツいくつかの質問に答えると結果が返る形式のコンテンツ。おすすめ商品の提案やタイプ分けなど、読者が自分に当てはめた結果を持ち帰れる。の中では設計が素直に決まるほうです。手こずるのは仕組みより線引きで、どこまでを画面で判定し、どこから先を個別相談に渡すか。ここを曖昧にしたまま設問から作ると、画面の側で答えを出しきろうとして設問が増え、増えたぶんだけ最後まで答える人が減ります。

この記事は、社労士事務所や補助金の支援会社が自社サイトに「うちは対象になりそうか」のチェックを置く場面を想定して、要件表を設問へ割る手順と、制度が変わったときに何が壊れるかまでを書きます。個別の制度の要件そのものは扱いません。年度ごとに変わるものを記事に書き写しても、読まれる頃には古くなっているので。

画面が引き受けるのは、足切りと事前整理まで

先に範囲を決めます。このチェックが返せるのは「対象になりそうか」の目安であって、受給できるかどうかの判定ではありません。 可否は申請と審査の側にあり、サイトに置いた診断が肩代わりできる部分ではない。入口の文言をここで曖昧にすると、そのあとの相談が認識のずれの訂正から始まります。

そのうえで、画面に任せられる仕事は2つ。ひとつは足切りで、明らかに要件から外れている人に問い合わせる前に気づいてもらうこと。もうひとつは事前整理で、相談の前に自分の条件を言葉にしておいてもらうことです。

仕組みの側の線も引いておきます。診断シミュレーションProは、回答に点数を付けて合計で判定する作りではありません。設定した条件に一致した結果を出す、それだけです。要件は点数ではなく条件の塊なので、スコア採点でないことはこの用途ではむしろ好都合。受給額をその場で計算する機能も持っていません。金額に触れたいなら、概算のレンジを書いた結果コンテンツを数本用意して、条件で出し分けるところまでです。

要件表の1行が、そのまま1設問になるとは限らない

要項の要件を上から順に設問へ写していくと、書いている側もどこかで手が止まります。答える側は、もっと手前で止まる。割り振りには判断が要ります。

この4つで削ると、残るのは片手で数えられるくらいの数です。設問を減らすと精度が落ちる気がしますが、精度を上げる場所はここではない。相談に来てほしい人を画面の側で絞り込みすぎないほうが、取りこぼしは減ります。

「かつ」と「いずれか」を、条件表のチェックで書き分ける

分岐の持ち方が、要件表と相性がいい。選択肢から結果へ線を引くのではなく、制度の案内のほうが「どの回答の組み合わせなら自分を出していいか」を抱えます（回答マトリクス）。制度ごとに結果コンテンツを1本ずつ作れば、その1本が自分の要件を持って立っている形になる。機構そのものと、複数の結果が同時に出るときの見せ方は複数の結果を同時に出す方法にまとめてあるので、ここでは要件表を写す手つきのほうに絞ります。

効いてくるのは、条件を設定する画面の作りです。設問ごとに選択肢のチェック欄が並ぶ表になっていて、同じ設問の中で複数チェックすればそのどれかで一致、設問をまたいでチェックすればすべて満たしたときだけ一致。チェックを1つも付けなかった設問は不問になります。つまりチェックの付け方が、要件の「かつ」「いずれか」にそのまま対応する。

要項を読みながらこの表を埋めていくと、要件表が条件表に変わります。逆に言えば、要項の側で「かつ」なのか「いずれか」なのかを読み切れていないと、ここで詰まる。設問を作り始める前に、要件表の各行へ「かつ／いずれか／不問」を振っておくほうが速いです。

案内したい制度が複数あるときも、この形なら足すだけで済みます。2件当てはまれば2件並び、順番は結果ごとの表示順の値で決まる。「本命の制度を先頭に、併用できる制度をその下に」も、その値で指定します。

「対象外」も、ひとつの結果として作る

要件が厳しい制度ほど、いちばん多く返ることになるのは「今回は対象になりません」のほうです。ここを作り込まないまま公開すると、答えてくれた人の多くに何も返していない診断になります。

対象外の結果に書けることは、思っているより多い。どの種類の要件で外れたか（規模なのか、時期なのか、取り組みの内容なのか）、次の募集や翌年度に向けていまから準備できること、別の制度の相談窓口への導線。「対象外です」の一行で打ち切ればページはそこで終わりますが、準備の話まで書いてあれば相談の入口としては生き残ります。

条件の組み方としては、対象になる結果の裏返しを1件ずつ用意していくと、組み合わせの数だけ結果が増えて破綻します。外れ方の種類ごとに数本置いて、最後にどれにも当たらなかった人の受け皿を1本。

その受け皿だけ、作り方に手順がひとつ増えます。条件欄を空にすると無条件で全員に出るのではなく、判定そのものから外れる仕様なので、どれか1つの設問で選択肢を全部チェックして「必ず当たる」条件にしておく。どの結果にも一致しなかったときの文言も差し替えられますが、そちらは受け皿の作り忘れに備えた最後の砦です。

制度が変わったとき、壊れるのは条件のほう

要件は年度で変わります。診断も直すことになりますが、直し方は2通りあって、先に決めておいたほうがいい。いまの設問セットを直接書き換えるか、今年度版として複製してから直すか。過去の案内を残す必要があるなら複製、そうでないなら直接。複製の段取りとJSON設定やデータを受け渡すためのテキスト形式。メモ帳でも開けるが、Excelで表として開くものではなく、主にツール同士のやり取りやバックアップに使う。での持ち出しは似た診断を複製して量産するに書きました。

書き換えで注意が要るのは、設問より条件の側です。選択肢の並べ替えや設問の追加では条件は壊れません。選択肢には保存のたびに安定したIDが振られていて、条件はそのIDを見ているからです。壊れるのは、選択肢を削除したとき。

そこには備えを入れてあります。選択肢を消して保存すると、管理画面に「◯件の選択肢が削除され、◯件のコンテンツの回答条件に影響があります。該当コンテンツの回答条件を確認してください。」という注意が出ます。影響を受けた結果の編集画面を開けば、その設問の欄にも「◯件の参照先が見つかりません。選択肢が削除された可能性があります。」と表示される。

ただし、どちらも消したあとに出る通知です。この仕様にしたのは、条件が黙って壊れて誰も気づかないほうが後で高くつくと踏んだからで、消す手前で止める作りにはしていません。要件が変わって選択肢を削ると決めたら、その選択肢を条件に使っている結果を先に開いて、置き換え先を決めてから消す。順番はそちらです。

着地は個別相談。フォームは結果の中に置く

この診断の出口は問い合わせです。結果コンテンツは通常のブロックエディタで作るので、必要書類のリスト、相談の予約ボタン、Contact Form 7の相談フォームまで結果の中へ直接組み込めます（フォームを使うならContact Form 7は6.0以上。CF7側が要求するWordPressは版で変わり、6.0系は6.6以上、6.1系は6.7以上）。最後の設問に答えたその場に結果が出る（AJAX。ページは切り替わりません）ので、条件を確かめた勢いのまま相談まで進んでもらえます。

フォームのhidden項目にどの結果から来たかを入れておくと、返信で条件を聞き直さずに済みます。結果ごとにボタンの文言や置くものを変える設計は診断結果から問い合わせにつなげるのほうが具体的です。

公開後に見るのは完了率と設問別離脱率途中でやめて最後まで進まなかった人の割合。診断やフォームでは設問ごとに見ると、どこで止まっているかがわかる。詳しく見る。要件の設問のうちどこで抜けられているかが分かります。なお、どの事業者がどう答えたかの明細は残りません。数えているのはセッション単位の動きだけで、氏名も連絡先も列そのものがない。何がどこまで見えるかは個人情報を保存しないまま診断の効果を測るにあります。相談の手前に置く画面としては、持たないほうが説明も軽い。

要件表を条件表に写す。対象外にも返す言葉を用意する。変わったときの直し方を決めておく。この3つが済んでいれば、残りは設置だけです。診断シミュレーションProの設問セットにはIDが自動で振られるので、固定ページに置くものはこの1行に収まります。

[mqs_simulator id="設問セットID"]

id に入れるのは、作った設問セットのIDです。条件の設定画面まわりと動作環境（WordPress 6.0以上／PHP 7.4以上）は、診断シミュレーションProの製品ページに一覧があります。