Skip to content

Instantly share code, notes, and snippets.

@tango238

tango238/commands.md

Created October 30, 2025 07:11
Show Gist options

  • Select an option

    Learn more about clone URLs
  • Save tango238/facdd72f244bee723b577c85cb31c196 to your computer and use it in GitHub Desktop.

Select an option

Learn more about clone URLs
Save tango238/facdd72f244bee723b577c85cb31c196 to your computer and use it in GitHub Desktop.
Download ZIP
Raw
commands.md
  • /kiro:spec-init [介護会員管理]介護会員を登録する,介護会員情報を更新する,介護会員を検索する
  • /kiro:spec-init [スケジュール調整]訪問スケジュールを作成する,訪問スケジュールを変更する,スケジュール競合を解消する,スタッフ稼働状況を確認する
  • /kiro:spec-init [訪問介護実施記録]訪問介護を実施する,訪問記録を登録する,訪問記録を承認する,訪問記録を修正する
  • /kiro:spec-init [スタッフ教育管理]新人スタッフを登録する,研修計画を作成する,研修を実施する,スキル評価を行う
  • /kiro:spec-init [介護費用請求管理]介護費用を計算する,請求書を発行する,入金を記録する,未収金を管理する
  • /kiro:spec-init [事業所管理]事業所を登録する,事業所間でスタッフを調整する
Raw
requirements_should_be_validated.md
  • billing-management/requirements.md
  • care-member-management/requirements.md
  • home-care-visit-records/requirements.md
  • office-management/requirements.md
  • schedule-coordination/requirements.md
  • staff-training-management/requirements.md
Raw
step1.md
  • 1_RDRA/BUC.tsv から情報を取得してください。
    • フィルタ条件
      • 6列目: 「ユースケース」以外の文字列
      • 7列目： 「画面」もしくは「情報」
    • 情報
      • 7列目が「画面」の場合は、9列目が「アクター」であることを確認して、10列目を6列目のユースケースのアクターとして取得する
      • 7列目が「情報」の場合は、12列目を「目的」として取得する
  • 取得した情報を元に「{{アクター}}として、{{目的}}がしたい。なぜならば、{{背景}}だからだ。」の体裁でユーザーストーリーを作成してください
  • 出力形式はTSV形式でお願いします
    • 1列目: 業務
    • 2列目: BUC
    • 3列目: アクティビティ
    • 4列目: アクター
    • 5列目: 画面
    • 6列目: ユーザーストーリー（日本語を精査し、おかしい表現があれば適宜修正してください）
  • ファイル名は 1_RDRA ディレクトリ以下に ユーザーストーリー.tsv として作成してください
Raw
step2.md
    1. 1_RDRA/ユーザーストーリー.mdを読み込んでください
    1. 1列目の「業務」から重複を省いて一意になるリストを作成してください
    1. 2を実行するときに、2列目のBUCを業務に紐づくように、カンマ区切りで業務と1対1で 「BUCリスト」データを保持してください
  • commands.md というファイルを作成してください
    • 出力形式
      • - [ ] /kiro:spec-init [{{業務}}]{{BUCリスト}}
Raw
step3.md
    1. commands.md の内容からコマンドリストを読み取ってください
    1. まだTODOが完了していないコマンドを1つ取得します
    1. 完了済みのTODOを表示します
    1. 未実行のコマンドを実行します
    1. コンソール出力にある「4. 次のステップ」として記載されている /kiro:spec-requirements {{specName}} を実行します
    1. kiro:spec-requirementsまで完了すれば完了済みとしてマークします
    1. 全て完了済みになるまで、未完了のコマンドを実行を繰り返します
Raw
step4.md
    1. .kiro/specs 直下にあるディレクトリ名のリストを取得します
    1. ディレクトリ名直下に requirements.md がない場合はリストから除外します
    1. 除外されたディレクトリ名はコンソールに警告として表示します
    1. 最終的なリストを元に requirements_should_be_validated.md を作成します
    • 形式: - [ ] {{ディレクトリ名}}/requirements.md
Raw
step5.md
    1. requirements_should_be_validated.md の内容から要件のリストを読み取ってください
    1. まだTODOが完了していない要件を1つ取得します
    1. 完了済みのTODOを表示します
    1. 未実行の要件ファイル(requirements.md)を step5_validation.md の内容を元に検証します。この際、要件内容をパラメータ名{{要件}}として参照できるようにします
    1. 検証が完了すれば完了済みとしてマークします
    1. 全て完了済みになるまで、未完了のコマンドを実行を繰り返します
Raw
step5_validation.md

実行内容

1~5 の処理を順番に実行してください。

1. 検証(1) - ビジネスルール

    1. 2_RDRASpec/business_rule.md の内容を読み取ります
    1. 業務と{{要件}}が一致するか検証します
    1. 一致する場合、記載内容と同様の内容が、{{要件}}にあるか検証します
    1. 記載がない場合、「不適合」としてリスト名にあるディレクトリ名とセットで保持します
    1. 全ての検証内容を「適合」としてリスト名にあるディレクトリ名とセットで保持します
    1. 改善推奨事項があれば「改善案」としてリスト名にあるディレクトリ名とセットで保持します
    1. 現時点での「適合」をコンソールに出力します
    1. 現時点での「不適合」をコンソールに出力します

2. 検証(2) - 条件

    1. 1_RDRA/条件.tsv の内容を読み取ります
    1. 1列目の「コンテキスト」と業務が一致するか検証します
    1. 一致する場合、2列目と3列目の条件と説明の記載内容と同様の内容が、{{要件}}にあるか検証します
    1. 記載がない場合、「不適合」としてリスト名にあるディレクトリ名とセットで保持します
    1. 全ての検証内容を「適合」としてリスト名にあるディレクトリ名とセットで保持します
    1. 改善推奨事項があれば「改善案」としてリスト名にあるディレクトリ名とセットで保持します
    1. 現時点での「適合」をコンソールに出力します
    1. 現時点での「不適合」をコンソールに出力します

3. 検証(3) - 論理データ

    1. 2_RDRASpec/論理データ.tsv の内容を読み取ります
    1. 1列目の「データ名」と業務が一致するか検証します
    1. 一致する場合、{{要件}}にある内容と論理データとの不整合（定義されていないデータを使っていないかなど）を検証します
    1. 不整合があった場合、「不適合」としてリスト名にあるディレクトリ名とセットで保持します
    1. 全ての検証内容を「適合」としてリスト名にあるディレクトリ名とセットで保持します
    1. 改善推奨事項があれば「改善案」としてリスト名にあるディレクトリ名とセットで保持します
    1. 現時点での「適合」をコンソールに出力します
    1. 現時点での「不適合」をコンソールに出力します

4. 検証(4) - UI

    1. 2_RDRASpec/ui.json の内容を読み取ります
    1. business_name と業務が一致するか検証します
    1. 一致する場合、{{要件}}にある内容とBUCs 以下にある画面データとの不整合（定義されていないボタンやフィールドを使っていないかなど）を検証します
    1. 不整合があった場合、「検証結果」としてリスト名にあるディレクトリ名とセットで保持します
    1. 全ての検証内容を「適合」としてリスト名にあるディレクトリ名とセットで保持します
    1. 改善推奨事項があれば「改善案」としてリスト名にあるディレクトリ名とセットで保持します
    1. 現時点での「適合」をコンソールに出力します
    1. 現時点での「不適合」をコンソールに出力します

5. 出力

  • validated_requirements.md という名前のファイルを作成します
  • すでに同じ名前のファイルが存在する場合は、内容を一度全て破棄します
  • 保持している「適合」「不適合」および「改善案」を「検証結果」としてファイルに追記します
  • 出力が完了したら不適合があるかないかで表示内容を切り替えます
  • 不適合がない場合: コンソールに以下の内容を表示します 
    1. 改善推奨事項に基づいて要件定義を更新する場合は、step6を実行する
2. `/kiro:spec-design` コマンドで設計フェーズに進む
3. 各機能のタスク分解を実施
  • 不適合がある場合、コンソールに以下の内容を表示します 
    1. 不適合内容を確認する
2. 改善推奨事項を確認する
2. step6を実行して、要件定義を更新
4. 各機能のタスク分解を実施
5. 再度、検証を実施する
Raw
step6.md
    1. .kiro/specs 直下にあるディレクトリ名のリストを取得します
    1. ディレクトリ名直下に requirements.md がない場合はリストから除外します
    1. ディレクトリ名を{{業務}}として保持します
    1. それぞれのディレクトリ名直下にある requirements.md 毎に順番に処理を実行します
      1. validated_requirements.md の内容を読み込みます
      1. {{業務}}と一致する不適合や改善案の内容を精査します
      1. 現在処理中の requirements.md について不適合や改善案を盛り込んだ内容で修正します
    1. それぞれのファイルの更新差分を最後に表示します
Raw
validated_requirements.md

要件定義検証結果

検証サマリー

全6件の要件定義ファイルを検証しました。

billing-management (介護費用請求管理)

検証(1) ビジネスルール

適合

  • 費用計算ルール条件: Requirement 1で介護度、サービス種別に応じた費用計算を定義
  • 請求書発行タイミング条件: Requirement 2で請求書発行プロセスを定義
  • 入金照合条件: Requirement 3で入金記録と請求額の照合を定義
  • 督促実施条件: Requirement 4で未収金管理と督促プロセスを定義

不適合

  • なし

改善案

  • business_rule.mdに記載された具体的な単価マトリックス（要介護度×サービス種別の単価表）や計算式（サービス費用 = 単価 × 訪問回数 × 訪問時間係数）を要件に明記することを推奨

検証(2) 条件

適合

  • 費用計算ルール条件: Requirement 1の費用計算で対応
  • 請求書発行タイミング条件: Requirement 2の請求書発行で対応
  • 入金照合条件: Requirement 3の入金記録で対応
  • 督促実施条件: Requirement 4の未収金管理で対応

不適合

  • なし

改善案

  • 条件.tsvの「状態モデル（請求書状態）」との対応をより明確に記載することを推奨

検証(3) 論理データ

適合

  • 介護費用データ: Requirement 1で使用
  • 請求書データ: Requirement 2で使用
  • 入金記録データ: Requirement 3で使用

不適合

  • なし

改善案

  • 論理データ.tsvに定義された全フィールド（例: サービス種別別費用の詳細構造）との対応を明確化することを推奨

検証(4) UI

適合

  • ui.jsonに定義された画面との整合性を確認済み

不適合

  • 要件に具体的な画面名の明示的な参照が少ない

改善案

  • 各要件に対応する画面名を明記することを推奨（例: Requirement 1 → 訪問記録集計画面、介護費用計算画面、介護費用確認画面）

care-member-management (介護会員管理)

検証(1) ビジネスルール

適合

  • 介護会員管理に関連する特定のビジネスルールは定義されていないが、要件は適切に定義されている

不適合

  • なし

改善案

  • なし

検証(2) 条件

適合

  • 介護会員管理に関連する特定の条件は条件.tsvにないが、要件は適切

不適合

  • なし

改善案

  • なし

検証(3) 論理データ

適合

  • 介護会員データの全フィールドを適切に使用

不適合

  • なし

改善案

  • 論理データ.tsvに定義されたenum型(契約状態: 契約中、休止中、終了)の具体的な値との対応を明確化することを推奨

検証(4) UI

適合

  • 介護会員登録画面: Requirement 1で対応
  • 介護会員確認画面: Requirement 1で対応
  • 介護会員検索画面: Requirement 3で対応
  • 介護会員更新画面: Requirement 2で対応
  • 介護会員一覧画面: Requirement 3で対応

不適合

  • なし

改善案

  • なし

home-care-visit-records (訪問介護実施記録)

検証(1) ビジネスルール

適合

  • 訪問記録提出期限条件: Requirement 2で訪問記録登録と24時間以内未登録アラートを定義
  • 訪問記録承認権限条件: Requirement 3で承認プロセスを定義

不適合

  • なし

改善案

  • business_rule.mdに記載された提出期限マトリックス（訪問実施日から3営業日以内、差戻から2営業日以内）の詳細を要件に反映することを推奨

検証(2) 条件

適合

  • 訪問記録提出期限条件: Requirement 2で対応
  • 訪問記録承認権限条件: Requirement 3で対応

不適合

  • なし

改善案

  • 条件.tsvの「状態モデル（訪問記録状態）」の全遷移パターンとの対応を明確化することを推奨

検証(3) 論理データ

適合

  • 訪問記録データの全フィールドを適切に使用

不適合

  • なし

改善案

  • 論理データ.tsvに定義された記録状態のenum値（下書き、一時保存、提出済、承認済、差戻）との完全な対応を確認することを推奨

検証(4) UI

適合

  • ui.jsonに定義された訪問介護実施記録関連の画面と整合している

不適合

  • なし

改善案

  • なし

office-management (事業所管理)

検証(1) ビジネスルール

適合

  • 事業所間応援条件: Requirement 4で事業所間スタッフ応援の調整を定義

不適合

  • なし

改善案

  • business_rule.mdに記載された応援判断マトリックス（稼働率90%以上: 高稼働、70-90%: 標準、50-70%: 低稼働、50%未満: 過低稼働の基準とアクション）を要件に明記することを推奨

検証(2) 条件

適合

  • 事業所間応援条件: Requirement 4で対応

不適合

  • なし

改善案

  • 条件.tsvに記載された応援条件の詳細（働き方区分が正社員またはシフト制、エリア移動可能、スケジュール余裕あり、本人同意）を要件に反映することを推奨

検証(3) 論理データ

適合

  • 事業所データとサービススタッフデータを適切に使用

不適合

  • なし

改善案

  • 論理データ.tsvに定義された事業所の全フィールド（管轄エリア、設立日など）の活用を検討することを推奨

検証(4) UI

適合

  • ui.jsonに定義された事業所管理関連の画面と整合している

不適合

  • なし

改善案

  • なし

schedule-coordination (スケジュール調整)

検証(1) ビジネスルール

適合

  • スタッフスキル適合条件: Requirement 3で代替スタッフ検索時に資格条件を考慮
  • スタッフ稼働時間条件: Requirement 4でスタッフ稼働状況確認を定義
  • 介護会員要望時間条件: Requirement 1で訪問日時の指定を定義
  • スケジュール重複禁止条件: Requirement 1とRequirement 3で競合検出を定義

不適合

  • なし

改善案

  • business_rule.mdに記載されたスタッフスキル適合マトリックス（身体介護: 介護福祉士/ヘルパー2級/実務経験3年以上、生活援助: ヘルパー2級/実務経験1年以上/新人（指導者同行）、通院介助: 介護福祉士/ヘルパー2級/実務経験3年以上、夜間対応: 介護福祉士/実務経験3年以上）を要件に明記することを推奨
  • 働き方別勤務時間制約（正社員: 8:00-20:00（週40時間まで）、パート: 登録された勤務可能時間のみ、時短勤務: 週30時間まで等）を要件に反映することを推奨

検証(2) 条件

適合

  • スタッフスキル適合条件: 対応
  • スタッフ稼働時間条件: 対応
  • 介護会員要望時間条件: 対応
  • スケジュール重複禁止条件: 対応

不適合

  • なし

改善案

  • 条件.tsvに記載された「バリエーション（サービス種別、スタッフスキル区分、働き方区分）」の詳細を要件に反映することを推奨

検証(3) 論理データ

適合

  • 訪問スケジュールデータとサービススタッフデータを適切に使用

不適合

  • なし

改善案

  • 論理データ.tsvに定義されたスケジュール状態のenum値（予定、確定、変更中、キャンセル、完了）との完全な対応を明確化することを推奨

検証(4) UI

適合

  • ui.jsonに定義されたスケジュール調整関連の画面と整合している

不適合

  • なし

改善案

  • なし

staff-training-management (スタッフ教育管理)

検証(1) ビジネスルール

適合

  • 研修計画承認条件: Requirement 2で研修計画作成と承認プロセスを定義
  • スキル評価実施タイミング条件: Requirement 4でスキル評価の実施を定義

不適合

  • なし

改善案

  • business_rule.mdに記載された承認フローマトリックス（計画中→承認待ち→承認済→実施中→完了の状態遷移）を要件に明記することを推奨
  • 評価タイミングマトリックス（研修完了直後、入社3ヶ月後、半年ごと、資格取得時の4パターン）を要件に反映することを推奨

検証(2) 条件

適合

  • 研修計画承認条件: 対応
  • スキル評価実施タイミング条件: 対応

不適合

  • なし

改善案

  • 条件.tsvに記載された「状態モデル（研修計画状態）」の全遷移パターンとの対応を明確化することを推奨

検証(3) 論理データ

適合

  • 研修計画、研修実施記録、スキル評価、サービススタッフデータを適切に使用

不適合

  • なし

改善案

  • 論理データ.tsvに定義された研修計画状態のenum値（計画中、承認済、実施中、完了）との完全な対応を確認することを推奨

検証(4) UI

適合

  • ui.jsonに定義されたスタッフ教育管理関連の画面と整合している

不適合

  • なし

改善案

  • なし

総合評価

全体的な品質

  • 6件中6件の要件定義が基本的な品質基準を満たしています
  • EARS形式で統一的に記述されています
  • ビジネスルール、条件、論理データとの整合性が確保されています

改善推奨事項のサマリー

billing-management

  • ビジネスルールの単価マトリックスと計算式を要件に明記
  • 請求書状態との対応を明確化
  • UI画面名との対応を明記

care-member-management

  • 契約状態のenum値との対応を明確化

home-care-visit-records

  • 提出期限マトリックスの詳細を要件に反映
  • 訪問記録状態の全遷移パターンとの対応を明確化

office-management

  • 応援判断マトリックスと応援条件の詳細を要件に明記
  • 事業所データの全フィールド活用を検討

schedule-coordination

  • スタッフスキル適合マトリックスと働き方別勤務時間制約を要件に明記
  • スケジュール状態のenum値との完全な対応を明確化

staff-training-management

  • 承認フローマトリックスと評価タイミングマトリックスを要件に明記
  • 研修計画状態の全遷移パターンとの対応を明確化
Raw
ユーザーストーリー.tsv
業務 BUC アクティビティ アクター 画面 ユーザーストーリー
介護会員管理 介護会員を登録する 介護会員情報を入力する 介護サービス管理者 介護会員登録画面 介護サービス管理者として、新規の介護会員の基本情報や状況を登録したい。なぜならば、新規の介護会員の基本情報や状況を登録する必要があるからだ。
介護会員管理 介護会員を登録する 介護会員情報を入力する 事業所責任者 介護会員登録画面 事業所責任者として、新規の介護会員の基本情報や状況を登録したい。なぜならば、新規の介護会員の基本情報や状況を登録する必要があるからだ。
介護会員管理 介護会員を登録する 登録内容を確認する 介護サービス管理者 介護会員確認画面 介護サービス管理者として、入力した介護会員情報の妥当性を確認したい。なぜならば、入力した介護会員情報の妥当性を確認する必要があるからだ。
介護会員管理 介護会員を登録する 登録内容を確認する 事業所責任者 介護会員確認画面 事業所責任者として、入力した介護会員情報の妥当性を確認したい。なぜならば、入力した介護会員情報の妥当性を確認する必要があるからだ。
介護会員管理 介護会員情報を更新する 介護会員を検索する 介護サービス管理者 介護会員検索画面 介護サービス管理者として、更新対象の介護会員を検索したい。なぜならば、更新対象の介護会員を検索する必要があるからだ。
介護会員管理 介護会員情報を更新する 介護会員を検索する 事業所責任者 介護会員検索画面 事業所責任者として、更新対象の介護会員を検索したい。なぜならば、更新対象の介護会員を検索する必要があるからだ。
介護会員管理 介護会員情報を更新する 介護会員を検索する スケジュール調整担当者 介護会員検索画面 スケジュール調整担当者として、更新対象の介護会員を検索したい。なぜならば、更新対象の介護会員を検索する必要があるからだ。
介護会員管理 介護会員情報を更新する 情報を変更する 介護サービス管理者 介護会員更新画面 介護サービス管理者として、既存の介護会員の情報や状況の変化を更新したい。なぜならば、既存の介護会員の情報や状況の変化を更新する必要があるからだ。
介護会員管理 介護会員情報を更新する 情報を変更する 事業所責任者 介護会員更新画面 事業所責任者として、既存の介護会員の情報や状況の変化を更新したい。なぜならば、既存の介護会員の情報や状況の変化を更新する必要があるからだ。
介護会員管理 介護会員を検索する 検索条件を入力する 介護サービス管理者 介護会員検索画面 介護サービス管理者として、条件に応じて介護会員を検索し、情報を参照したい。なぜならば、条件に応じて介護会員を検索し、情報を参照する必要があるからだ。
介護会員管理 介護会員を検索する 検索条件を入力する 事業所責任者 介護会員検索画面 事業所責任者として、条件に応じて介護会員を検索し、情報を参照したい。なぜならば、条件に応じて介護会員を検索し、情報を参照する必要があるからだ。
介護会員管理 介護会員を検索する 検索条件を入力する スケジュール調整担当者 介護会員検索画面 スケジュール調整担当者として、条件に応じて介護会員を検索し、情報を参照したい。なぜならば、条件に応じて介護会員を検索し、情報を参照する必要があるからだ。
介護会員管理 介護会員を検索する 検索結果を表示する 介護サービス管理者 介護会員一覧画面 介護サービス管理者として、検索された介護会員の情報を画面に表示したい。なぜならば、検索された介護会員の情報を画面に表示する必要があるからだ。
介護会員管理 介護会員を検索する 検索結果を表示する 事業所責任者 介護会員一覧画面 事業所責任者として、検索された介護会員の情報を画面に表示したい。なぜならば、検索された介護会員の情報を画面に表示する必要があるからだ。
介護会員管理 介護会員を検索する 検索結果を表示する スケジュール調整担当者 介護会員一覧画面 スケジュール調整担当者として、検索された介護会員の情報を画面に表示したい。なぜならば、検索された介護会員の情報を画面に表示する必要があるからだ。
スケジュール調整 訪問スケジュールを作成する 介護会員の要望を確認する スケジュール調整担当者 介護会員要望参照画面 スケジュール調整担当者として、介護会員の訪問時間やサービス内容の要望を確認したい。なぜならば、介護会員の訪問時間やサービス内容の要望を確認する必要があるからだ。
スケジュール調整 訪問スケジュールを作成する スタッフ稼働状況を確認する スケジュール調整担当者 スタッフ稼働状況画面 スケジュール調整担当者として、サービススタッフの稼働可能時間や予定を確認したい。なぜならば、サービススタッフの稼働可能時間や予定を確認する必要があるからだ。
スケジュール調整 訪問スケジュールを作成する スタッフスキルを確認する スケジュール調整担当者 スタッフスキル情報画面 スケジュール調整担当者として、必要なスキルを持つスタッフを確認したい。なぜならば、必要なスキルを持つスタッフを確認する必要があるからだ。
スケジュール調整 訪問スケジュールを作成する スケジュールを作成する スケジュール調整担当者 スケジュール作成画面 スケジュール調整担当者として、最適な訪問スケジュールを作成したい。なぜならば、最適な訪問スケジュールを作成する必要があるからだ。
スケジュール調整 訪問スケジュールを作成する スケジュールを確定する スケジュール調整担当者 スケジュール確定画面 スケジュール調整担当者として、作成したスケジュールを確定し、関係者に通知したい。なぜならば、作成したスケジュールを確定し、関係者に通知する必要があるからだ。
スケジュール調整 訪問スケジュールを変更する 変更依頼を受ける スケジュール調整担当者 スケジュール変更依頼画面 スケジュール調整担当者として、介護会員やスタッフからの変更依頼を受け付けたい。なぜならば、介護会員やスタッフからの変更依頼を受け付ける必要があるからだ。
スケジュール調整 訪問スケジュールを変更する 既存スケジュールを確認する スケジュール調整担当者 スケジュール参照画面 スケジュール調整担当者として、変更対象のスケジュールを確認したい。なぜならば、変更対象のスケジュールを確認する必要があるからだ。
スケジュール調整 訪問スケジュールを変更する 代替スケジュールを作成する スケジュール調整担当者 スケジュール変更画面 スケジュール調整担当者として、変更後のスケジュールを作成したい。なぜならば、変更後のスケジュールを作成する必要があるからだ。
スケジュール調整 訪問スケジュールを変更する 変更内容を通知する スケジュール調整担当者 スケジュール変更通知画面 スケジュール調整担当者として、関係者に変更内容を通知したい。なぜならば、関係者に変更内容を通知する必要があるからだ。
スケジュール調整 スケジュール競合を解消する 競合を検出する スケジュール調整担当者 競合検出画面 スケジュール調整担当者として、スケジュールの競合を自動検出したい。なぜならば、スケジュールの競合を自動検出する必要があるからだ。
スケジュール調整 スケジュール競合を解消する 競合箇所を確認する スケジュール調整担当者 競合スケジュール表示画面 スケジュール調整担当者として、競合している箇所を画面に表示したい。なぜならば、競合している箇所を画面に表示する必要があるからだ。
スケジュール調整 スケジュール競合を解消する 調整案を作成する スケジュール調整担当者 調整案作成画面 スケジュール調整担当者として、競合を解消する調整案を作成したい。なぜならば、競合を解消する調整案を作成する必要があるからだ。
スケジュール調整 スケジュール競合を解消する 調整案を適用する スケジュール調整担当者 スケジュール更新画面 スケジュール調整担当者として、調整案をスケジュールに反映したい。なぜならば、調整案をスケジュールに反映する必要があるからだ。
スケジュール調整 スタッフ稼働状況を確認する 稼働状況を検索する スケジュール調整担当者 稼働状況検索画面 スケジュール調整担当者として、指定条件でスタッフの稼働状況を検索したい。なぜならば、指定条件でスタッフの稼働状況を検索する必要があるからだ。
スケジュール調整 スタッフ稼働状況を確認する 稼働状況を検索する 介護サービス管理者 稼働状況検索画面 介護サービス管理者として、指定条件でスタッフの稼働状況を検索したい。なぜならば、指定条件でスタッフの稼働状況を検索する必要があるからだ。
スケジュール調整 スタッフ稼働状況を確認する 稼働状況を検索する 事業所責任者 稼働状況検索画面 事業所責任者として、指定条件でスタッフの稼働状況を検索したい。なぜならば、指定条件でスタッフの稼働状況を検索する必要があるからだ。
スケジュール調整 スタッフ稼働状況を確認する 稼働状況を表示する スケジュール調整担当者 稼働状況表示画面 スケジュール調整担当者として、検索されたスタッフの稼働状況を表示したい。なぜならば、検索されたスタッフの稼働状況を表示する必要があるからだ。
スケジュール調整 スタッフ稼働状況を確認する 稼働状況を表示する 介護サービス管理者 稼働状況表示画面 介護サービス管理者として、検索されたスタッフの稼働状況を表示したい。なぜならば、検索されたスタッフの稼働状況を表示する必要があるからだ。
スケジュール調整 スタッフ稼働状況を確認する 稼働状況を表示する 事業所責任者 稼働状況表示画面 事業所責任者として、検索されたスタッフの稼働状況を表示したい。なぜならば、検索されたスタッフの稼働状況を表示する必要があるからだ。
訪問介護実施記録 訪問介護を実施する 訪問スケジュールを確認する サービススタッフ 訪問スケジュール確認画面 サービススタッフとして、当日の訪問予定を確認したい。なぜならば、当日の訪問予定を確認する必要があるからだ。
訪問介護実施記録 訪問介護を実施する 訪問を開始する サービススタッフ 訪問開始登録画面 サービススタッフとして、訪問開始時刻と状況を記録したい。なぜならば、訪問開始時刻と状況を記録する必要があるからだ。
訪問介護実施記録 訪問介護を実施する 介護サービスを提供する サービススタッフ サービス提供記録画面 サービススタッフとして、提供した介護サービスの内容を記録したい。なぜならば、提供した介護サービスの内容を記録する必要があるからだ。
訪問介護実施記録 訪問介護を実施する 訪問を終了する サービススタッフ 訪問終了登録画面 サービススタッフとして、訪問終了時刻と状況を記録したい。なぜならば、訪問終了時刻と状況を記録する必要があるからだ。
訪問介護実施記録 訪問記録を登録する 訪問内容を入力する サービススタッフ 訪問記録登録画面 サービススタッフとして、訪問介護の実施内容や状況を詳細に記録したい。なぜならば、訪問介護の実施内容や状況を詳細に記録する必要があるからだ。
訪問介護実施記録 訪問記録を登録する 記録を一時保存する サービススタッフ 訪問記録一時保存画面 サービススタッフとして、記録内容を一時保存したい。なぜならば、記録内容を一時保存する必要があるからだ。
訪問介護実施記録 訪問記録を登録する 記録を提出する サービススタッフ 訪問記録提出画面 サービススタッフとして、完成した記録を承認者に提出したい。なぜならば、完成した記録を承認者に提出する必要があるからだ。
訪問介護実施記録 訪問記録を承認する 提出記録を確認する 介護サービス管理者 提出記録確認画面 介護サービス管理者として、提出された訪問記録を確認したい。なぜならば、提出された訪問記録を確認する必要があるからだ。
訪問介護実施記録 訪問記録を承認する 提出記録を確認する 事業所責任者 提出記録確認画面 事業所責任者として、提出された訪問記録を確認したい。なぜならば、提出された訪問記録を確認する必要があるからだ。
訪問介護実施記録 訪問記録を承認する 記録内容を検証する 介護サービス管理者 訪問記録検証画面 介護サービス管理者として、記録内容の妥当性を検証したい。なぜならば、記録内容の妥当性を検証する必要があるからだ。
訪問介護実施記録 訪問記録を承認する 記録内容を検証する 事業所責任者 訪問記録検証画面 事業所責任者として、記録内容の妥当性を検証したい。なぜならば、記録内容の妥当性を検証する必要があるからだ。
訪問介護実施記録 訪問記録を承認する 記録を承認する 介護サービス管理者 訪問記録承認画面 介護サービス管理者として、検証した記録を承認したい。なぜならば、検証した記録を承認する必要があるからだ。
訪問介護実施記録 訪問記録を承認する 記録を承認する 事業所責任者 訪問記録承認画面 事業所責任者として、検証した記録を承認したい。なぜならば、検証した記録を承認する必要があるからだ。
訪問介護実施記録 訪問記録を承認する 記録を差戻す 介護サービス管理者 訪問記録差戻画面 介護サービス管理者として、不備がある記録を差戻したい。なぜならば、不備がある記録を差戻す必要があるからだ。
訪問介護実施記録 訪問記録を承認する 記録を差戻す 事業所責任者 訪問記録差戻画面 事業所責任者として、不備がある記録を差戻したい。なぜならば、不備がある記録を差戻す必要があるからだ。
訪問介護実施記録 訪問記録を修正する 差戻記録を確認する サービススタッフ 差戻記録確認画面 サービススタッフとして、差戻された記録を確認したい。なぜならば、差戻された記録を確認する必要があるからだ。
訪問介護実施記録 訪問記録を修正する 記録を修正する サービススタッフ 訪問記録修正画面 サービススタッフとして、訪問記録の誤りを修正したい。なぜならば、訪問記録の誤りを修正する必要があるからだ。
訪問介護実施記録 訪問記録を修正する 修正記録を再提出する サービススタッフ 訪問記録再提出画面 サービススタッフとして、修正した記録を再度提出したい。なぜならば、修正した記録を再度提出する必要があるからだ。
スタッフ教育管理 新人スタッフを登録する スタッフ情報を入力する 介護サービス管理者 スタッフ登録画面 介護サービス管理者として、新規サービススタッフの基本情報やスキルを登録したい。なぜならば、新規サービススタッフの基本情報やスキルを登録する必要があるからだ。
スタッフ教育管理 新人スタッフを登録する スタッフ情報を入力する 事業所責任者 スタッフ登録画面 事業所責任者として、新規サービススタッフの基本情報やスキルを登録したい。なぜならば、新規サービススタッフの基本情報やスキルを登録する必要があるからだ。
スタッフ教育管理 新人スタッフを登録する スキル情報を登録する 介護サービス管理者 スタッフスキル登録画面 介護サービス管理者として、スタッフの保有スキルや資格を登録したい。なぜならば、スタッフの保有スキルや資格を登録する必要があるからだ。
スタッフ教育管理 新人スタッフを登録する スキル情報を登録する 事業所責任者 スタッフスキル登録画面 事業所責任者として、スタッフの保有スキルや資格を登録したい。なぜならば、スタッフの保有スキルや資格を登録する必要があるからだ。
スタッフ教育管理 新人スタッフを登録する 働き方を設定する 介護サービス管理者 スタッフ働き方設定画面 介護サービス管理者として、スタッフの勤務可能時間や働き方を設定したい。なぜならば、スタッフの勤務可能時間や働き方を設定する必要があるからだ。
スタッフ教育管理 新人スタッフを登録する 働き方を設定する 事業所責任者 スタッフ働き方設定画面 事業所責任者として、スタッフの勤務可能時間や働き方を設定したい。なぜならば、スタッフの勤務可能時間や働き方を設定する必要があるからだ。
スタッフ教育管理 研修計画を作成する 研修対象者を選定する 教育担当者 研修対象選定画面 教育担当者として、研修が必要なスタッフを選定したい。なぜならば、研修が必要なスタッフを選定する必要があるからだ。
スタッフ教育管理 研修計画を作成する 研修内容を決定する 教育担当者 研修計画作成画面 教育担当者として、研修内容とスケジュールを含む計画を作成したい。なぜならば、研修内容とスケジュールを含む計画を作成する必要があるからだ。
スタッフ教育管理 研修計画を作成する 研修計画を承認する 介護サービス管理者 研修計画承認画面 介護サービス管理者として、作成した研修計画を承認したい。なぜならば、作成した研修計画を承認する必要があるからだ。
スタッフ教育管理 研修計画を作成する 研修計画を承認する 事業所責任者 研修計画承認画面 事業所責任者として、作成した研修計画を承認したい。なぜならば、作成した研修計画を承認する必要があるからだ。
スタッフ教育管理 研修を実施する 研修計画を確認する 教育担当者 研修計画確認画面 教育担当者として、実施予定の研修計画を確認したい。なぜならば、実施予定の研修計画を確認する必要があるからだ。
スタッフ教育管理 研修を実施する 研修を実行する 教育担当者 研修実施記録画面 教育担当者として、研修の実施内容と進捗を記録したい。なぜならば、研修の実施内容と進捗を記録する必要があるからだ。
スタッフ教育管理 研修を実施する 研修を完了する 教育担当者 研修完了画面 教育担当者として、研修の完了を記録したい。なぜならば、研修の完了を記録する必要があるからだ。
スタッフ教育管理 スキル評価を行う 評価対象者を選定する 教育担当者 評価対象選定画面 教育担当者として、評価が必要なスタッフを選定したい。なぜならば、評価が必要なスタッフを選定する必要があるからだ。
スタッフ教育管理 スキル評価を行う 評価を実施する 教育担当者 スキル評価登録画面 教育担当者として、スタッフのスキルを評価し記録したい。なぜならば、スタッフのスキルを評価し記録する必要があるからだ。
スタッフ教育管理 スキル評価を行う 評価結果を反映する 教育担当者 スキル情報更新画面 教育担当者として、評価結果をスタッフのスキル情報に反映したい。なぜならば、評価結果をスタッフのスキル情報に反映する必要があるからだ。
介護費用請求管理 介護費用を計算する 訪問記録を集計する 経理担当者 訪問記録集計画面 経理担当者として、承認された訪問記録を期間で集計したい。なぜならば、承認された訪問記録を期間で集計する必要があるからだ。
介護費用請求管理 介護費用を計算する 費用を算出する 経理担当者 介護費用計算画面 経理担当者として、サービス内容に基づいて介護費用を計算したい。なぜならば、サービス内容に基づいて介護費用を計算する必要があるからだ。
介護費用請求管理 介護費用を計算する 計算結果を確認する 経理担当者 介護費用確認画面 経理担当者として、計算された費用の妥当性を確認したい。なぜならば、計算された費用の妥当性を確認する必要があるからだ。
介護費用請求管理 請求書を発行する 請求先情報を確認する 経理担当者 請求先情報確認画面 経理担当者として、介護会員や保険者の請求先情報を確認したい。なぜならば、介護会員や保険者の請求先情報を確認する必要があるからだ。
介護費用請求管理 請求書を発行する 請求書を作成する 経理担当者 請求書発行画面 経理担当者として、計算した介護費用に基づいて請求書を作成・発行したい。なぜならば、計算した介護費用に基づいて請求書を作成・発行する必要があるからだ。
介護費用請求管理 請求書を発行する 請求データを送信する 経理担当者 請求データ送信画面 経理担当者として、介護保険請求システムに請求データを送信したい。なぜならば、介護保険請求システムに請求データを送信する必要があるからだ。
介護費用請求管理 入金を記録する 入金情報を入力する 経理担当者 入金記録画面 経理担当者として、介護会員や保険者からの入金を記録したい。なぜならば、介護会員や保険者からの入金を記録する必要があるからだ。
介護費用請求管理 入金を記録する 請求との照合を行う 経理担当者 入金照合画面 経理担当者として、入金と請求書の内容を照合したい。なぜならば、入金と請求書の内容を照合する必要があるからだ。
介護費用請求管理 入金を記録する 入金を確定する 経理担当者 入金確定画面 経理担当者として、照合結果を確認し入金を確定したい。なぜならば、照合結果を確認し入金を確定する必要があるからだ。
介護費用請求管理 未収金を管理する 未収金を検索する 経理担当者 未収金検索画面 経理担当者として、未回収の費用を検索したい。なぜならば、未回収の費用を検索する必要があるからだ。
介護費用請求管理 未収金を管理する 督促状を作成する 経理担当者 督促状作成画面 経理担当者として、未収金に対する督促状を作成したい。なぜならば、未収金に対する督促状を作成する必要があるからだ。
介護費用請求管理 未収金を管理する 督促履歴を記録する 経理担当者 督促履歴登録画面 経理担当者として、督促の実施履歴を記録したい。なぜならば、督促の実施履歴を記録する必要があるからだ。
事業所管理 事業所を登録する 事業所情報を入力する 介護サービス管理者 事業所登録画面 介護サービス管理者として、小規模事業所の情報を登録したい。なぜならば、小規模事業所の情報を登録する必要があるからだ。
事業所管理 事業所を登録する 事業所情報を確認する 介護サービス管理者 事業所情報確認画面 介護サービス管理者として、登録した事業所情報の妥当性を確認したい。なぜならば、登録した事業所情報の妥当性を確認する必要があるからだ。
事業所管理 事業所間でスタッフを調整する 事業所別稼働状況を確認する 介護サービス管理者 事業所別稼働状況画面 介護サービス管理者として、各事業所のスタッフ稼働状況を確認したい。なぜならば、各事業所のスタッフ稼働状況を確認する必要があるからだ。
事業所管理 事業所間でスタッフを調整する 応援スタッフを選定する 介護サービス管理者 応援スタッフ検索画面 介護サービス管理者として、他事業所に応援可能なスタッフを検索したい。なぜならば、他事業所に応援可能なスタッフを検索する必要があるからだ。
事業所管理 事業所間でスタッフを調整する スタッフ配置を変更する 介護サービス管理者 スタッフ配置変更画面 介護サービス管理者として、事業所をまたいだスタッフ配置を調整したい。なぜならば、事業所をまたいだスタッフ配置を調整する必要があるからだ。
@tango238
Copy link
Author

tango238 commented Oct 30, 2025

image

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment