本文へスキップ

ZPL-0084 会社員 実測 23/25

成果物をWBSと実行可能なWork Packageへ分解するPrompt

タスク分解を「考え始める」状態から「次の行動が決まる」状態へ。

承認済みScope、成果物、受入基準、期限、リソースを入力すると、WBS、Definition of Done、依存関係、担当、Milestoneまで設計します。

  • SAVE VALUE 5
  • 中級
  • 5〜20分
  • ChatGPT / Claude / Gemini

このPromptでできること

  • 計画開始時に、成果物ベースで全Scopeを過不足なく分解し、見積・割当・進捗管理できるWork Packageへ変換する。

必要なもの(入力項目)

  • Outcome・受入基準
  • Scope・除外範囲
  • Deliverables
  • 期限・Milestone
  • Resources
  • Dependencies
  • 品質条件
  • 既存タスク

解決できる悩み

  • タスク分解で何を決めるべきか分からない
  • 一般論しか出ず、自分のケースに使えない
  • 重要な前提やリスクを見落とす
  • 結果を実行可能な形へ落とし込めない

こんな人向け

  • 会社員の初心者
  • 実務を時短したい担当者
  • AIの出力を判断材料として使いたい人

使うタイミング

タスク分解に着手する直前、既存案を見直すとき、または公開・実行前に抜け漏れを確認するとき。

プロンプト本文

{{ }} の部分を自分の情報に置き換えてから使ってください。

PROMPT
承認済みの成果物とスコープを、担当者が見積もり・割当・進捗確認できるWork Breakdownへ分解してください。

入力:
達成するOutcomeと受入基準:{{Outcome_Acceptance}}
承認済みScope / Out of Scope:{{Scope}}
主要Deliverables:{{Deliverables}}
期限・Milestone:{{Schedule}}
担当可能な人/チームと稼働制約:{{Resources}}
既知の依存関係・外部承認:{{Dependencies}}
品質・法務・セキュリティ条件:{{QualityConstraints}}
既存タスク:{{ExistingTasks}}

まずDeliverable指向のWBSを作り、100% Rule(必要作業を過不足なく含む)と重複を確認します。最下位Work Packageは、単一Ownerを割り当てられ、完了条件と成果物があり、見積可能な粒度にします。その後で依存関係、順序、Milestone、リスクを設定してください。

出力:
1. Scope確認と不明点
2. 階層WBS(ID付き)
3. WBS Dictionary(成果物、含む/含まない、Definition of Done)
4. 実行タスク表(動詞、Owner、Estimate、Dependency、期限)
5. Critical/Blocking Dependency
6. Milestoneとレビューゲート
7. リスク・Assumption・未割当
8. 既存タスクとの重複/漏れ監査

要件が未承認なら詳細日程を捏造せず、Planning PackageまたはTBDとして残してください。

使い方

返ってくるもの

  • Scope確認、階層WBS、WBS Dictionary、Work Package、依存関係、Milestone/Review、Risk/Assumption、漏れ重複

調整のしかた

「相手・参加者」を変更すると対象が変わり、「社内ルール」を具体化すると提案精度が上がります。

追加で投げると効く指示

  • 初心者向けに手順を細かくしてください
  • 上位3案を比較表にしてください
  • 不足情報だけ質問してください
  • リスクの高い順に並べてください

推奨モデル

高推論モデル推奨

実測の入力と出力

下は実際にAIへ通したときの入力と、そのとき返ってきた出力です(モデル: gpt-5.1-thinking / 2026-09-16)。作例ではありません。

このとき入力した内容を見る
承認済みの成果物とスコープを、担当者が見積もり・割当・進捗確認できるWork Breakdownへ分解してください。

入力:
達成するOutcomeと受入基準:社内の経費精算を紙からクラウド(導入済みの SaaS「ケイヒクラウド」)へ移行し、2027年1月の精算分から全社員 180名が紙を使わずに申請・承認できる状態にする。
受入基準:①全部署の承認フローが設定されている ②経理が仕訳データを会計システムに取り込める ③社員向けマニュアルと問い合わせ窓口がある ④12月にテスト部署(営業2課・12名)で1か月分を並行運用し、差異0件
承認済みScope / Out of Scope:承認済みScope(2026-09-01 管理本部長承認):経費精算(交通費・出張費・立替経費)の申請〜承認〜仕訳連携、社員教育、旧紙フローの廃止告知。
Out of Scope:請求書の受領処理、法人カードの導入、給与システムとの連携。
※「法人カードも同時に入れたい」という経理部の要望があるが、承認されていない。
主要Deliverables:承認フロー設定、勘定科目と仕訳連携の設定、社員マニュアル(PDF・動画)、問い合わせ窓口の運用ルール、並行運用の結果レポート、旧フロー廃止の社内告知
期限・Milestone:10月末:設定完了/11月中旬:マニュアル完成/12月1日〜31日:テスト部署で並行運用/2027年1月4日:全社展開
担当可能な人/チームと稼働制約:・経理部 主任 石田(プロジェクトリーダー、週3日)
・経理部 担当 前田(週2日)
・情シス 担当 加藤(会計システム連携、10月は他案件で週1日のみ)
・総務部 広報担当 小松(社内告知、11月以降に週1日)
・SaaS 側のカスタマーサクセス担当(オンライン相談 月2回まで)
既知の依存関係・外部承認:・会計システムの取込形式の確認は、会計システムのベンダーの回答待ち(9/12問い合わせ済み、回答期限なし)
・承認フローは各部署の部長が承認者を確定する必要がある(まだ未依頼)
・動画マニュアルは SaaS 側の画面が11月にアップデート予定のため、それ以降に撮る方がよい
品質・法務・セキュリティ条件:・電子帳簿保存法の要件(タイムスタンプまたは訂正削除履歴)を満たす設定にする
・個人の口座情報は経理部の2名以外が見られない権限にする
・並行運用中の差異は1件でもあれば原因を記録する
既存タスク:既存タスク表(石田が作成中):
1. ケイヒクラウドの初期設定(石田)
2. 承認フロー設定(石田)
3. マニュアル作成(前田)
4. 社内告知(小松)
5. 法人カード会社の比較(前田)
6. テスト

まずDeliverable指向のWBSを作り、100% Rule(必要作業を過不足なく含む)と重複を確認します。最下位Work Packageは、単一Ownerを割り当てられ、完了条件と成果物があり、見積可能な粒度にします。その後で依存関係、順序、Milestone、リスクを設定してください。

出力:
1. Scope確認と不明点
2. 階層WBS(ID付き)
3. WBS Dictionary(成果物、含む/含まない、Definition of Done)
4. 実行タスク表(動詞、Owner、Estimate、Dependency、期限)
5. Critical/Blocking Dependency
6. Milestoneとレビューゲート
7. リスク・Assumption・未割当
8. 既存タスクとの重複/漏れ監査

要件が未承認なら詳細日程を捏造せず、Planning PackageまたはTBDとして残してください。
返ってきた出力を見る
表示を増やす

以下は、承認済みScopeだけを対象にしたDeliverable指向WBSです。既存タスクの「法人カード会社の比較」はOut of ScopeなのでWBSから除外し、未確定事項はPlanning Package / TBDとして残しています。

1. Scope確認と不明点

Outcomeは、2027年1月精算分から全社員180名が「ケイヒクラウド」で交通費・出張費・立替経費を申請し、承認後に経理が仕訳データを会計システムへ連携でき、紙を使用しない状態です。

Scope境界は明確です。対象は「経費申請→承認→仕訳連携」「社員教育」「問い合わせ対応」「旧紙フロー廃止」であり、請求書処理、法人カード、給与システム連携は含めません。したがって、経理部から出ている法人カード同時導入要望はChange Request候補であり、本WBSには入れません。

現時点で計画上残る不明点は次のとおりです。

ID	不明点	WBS上の扱い
U-01	各部署の承認者が未確定	Blocking Dependency
U-02	会計ベンダーから取込形式の回答時期が未定	Planning Package / Blocking
U-03	SaaSの11月画面更新日が未確定	動画マニュアルをPlanning Package化
U-04	「11月中旬マニュアル完成」に動画まで含むか	要確認。現状はPDF+動画をDeliverableとして維持
U-05	電帳法要件の最終適合確認を誰が承認するか	石田Owner、必要なら管理本部/法務レビューをTBD
U-06	問い合わせ窓口のチャネル・受付時間・担当交代方法	WBS内で設計
U-07	並行運用の「差異0件」の比較単位	テスト計画で定義
U-08	180名のユーザー・部署・権限情報の現状精度	移行前確認タスクで検証
2. 階層WBS(ID付き)
1.0 経費精算クラウド移行

  1.1 システム・統制設定
    1.1.1 基本設定
      1.1.1.1 対象経費種別・申請ルール設定
      1.1.1.2 社員・部署マスタ確認/登録
    1.1.2 承認フロー
      1.1.2.1 各部署の承認者情報収集
      1.1.2.2 承認フロー設計
      1.1.2.3 承認フロー設定
      1.1.2.4 承認フロー設定レビュー
    1.1.3 権限・法令対応
      1.1.3.1 口座情報閲覧権限設定
      1.1.3.2 電帳法対応設定
      1.1.3.3 権限・履歴設定検証

  1.2 会計システム仕訳連携
    1.2.1 取込仕様確定
      1.2.1.1 会計ベンダー回答取得・整理
    1.2.2 仕訳マッピング
      1.2.2.1 勘定科目・税区分・必要項目整理
      1.2.2.2 ケイヒクラウド側仕訳設定
    1.2.3 連携検証
      1.2.3.1 テスト仕訳データ出力
      1.2.3.2 会計システム取込テスト
      1.2.3.3 エラー修正・再取込確認

  1.3 利用者支援
    1.3.1 社員マニュアル
      1.3.1.1 マニュアル構成・操作シナリオ確定
      1.3.1.2 PDFマニュアル作成
      1.3.1.3 PDF操作確認・承認
      1.3.1.4 動画マニュアル作成【Planning Package】
      1.3.1.5 動画レビュー・公開
    1.3.2 問い合わせ窓口
      1.3.2.1 問い合わせチャネル決定
      1.3.2.2 対応責任・エスカレーション設計
      1.3.2.3 FAQ・一次回答ルール作成
      1.3.2.4 窓口運用開始準備

  1.4 並行運用・受入
    1.4.1 テスト設計
      1.4.1.1 対象者12名・対象取引確認
      1.4.1.2 紙/クラウド比較方法定義
      1.4.1.3 差異記録フォーマット作成
      1.4.1.4 テスト開始判定
    1.4.2 12月並行運用
      1.4.2.1 テスト部署運用支援
      1.4.2.2 紙/クラウド結果比較
      1.4.2.3 差異原因記録・是正
    1.4.3 受入判定
      1.4.3.1 1か月分最終照合
      1.4.3.2 並行運用結果レポート作成
      1.4.3.3 全社展開Go/No-Go判定

  1.5 全社展開・旧フロー廃止
    1.5.1 全社展開準備
      1.5.1.1 全社員利用可能状態確認
      1.5.1.2 マニュアル・窓口公開確認
      1.5.1.3 本番開始チェック
    1.5.2 社内告知
      1.5.2.1 告知内容作成
      1.5.2.2 関係者レビュー
      1.5.2.3 全社展開・紙廃止告知
    1.5.3 本番切替
      1.5.3.1 2027年1月運用開始
      1.5.3.2 初期問い合わせ・障害トリアージ

  1.6 プロジェクト統制
    1.6.1 SaaS CS相談管理
    1.6.2 Dependency・Issue管理
    1.6.3 Scope Change管理
    1.6.4 Milestoneレビュー

この構成では、主要Deliverableがそれぞれ1つの枝にだけ所属するため、WBS上の重複を避けています。

3. WBS Dictionary

最下位Work Packageを中心に定義します。

WP	成果物	含む	含まない	Definition of Done
1.1.1.1	経費ルール設定済みSaaS	交通費、出張費、立替経費	請求書・法人カード	3経費種別が申請可能で設定レビュー済み
1.1.1.2	社員・部署マスタ	対象180名、所属情報	給与マスタ連携	対象180名の利用対象・所属が確認済み
1.1.2.1	承認者一覧	全部署	承認者そのものの人事決定	全部署について部長確認済みの承認者が記録されている
1.1.2.2	承認フロー設計表	部署別承認経路	SaaS設定作業	全部署の経路と例外が定義済み
1.1.2.3	設定済み承認フロー	SaaSへの登録	組織変更対応	全部署設定済み
1.1.2.4	承認フロー検証記録	テスト申請・承認	12月本番テスト	全部署で想定承認者へ到達することを確認
1.1.3.1	権限設定	口座情報閲覧制限	その他システム権限	経理指定2名以外で閲覧できないことを実機確認
1.1.3.2	電帳法対応設定	タイムスタンプまたは訂正削除履歴等	法律意見書	採用方式が設定され証跡を保存
1.1.3.3	統制検証記録	権限、履歴テスト	外部監査	テスト結果・証跡・承認者を記録
1.2.1.1	会計取込仕様書	ベンダー回答整理	給与連携	必須列、形式、制約が明文化済み
1.2.2.1	仕訳マッピング表	勘定科目、税区分等	会計制度変更	対象経費すべてに対応するマッピング完成
1.2.2.2	SaaS仕訳設定	出力設定	API開発等	マッピング表どおり出力可能
1.2.3.1	テスト仕訳ファイル	代表ケース	全社員データ	正常・必要例外ケースを含むファイル生成
1.2.3.2	取込テスト結果	会計システムへの実取込	本番計上	エラーなく取込・内容照合完了
1.2.3.3	修正済み連携	不具合修正	新機能追加	発見エラーが再現せず、再テスト合格
1.3.1.1	マニュアル構成表	申請・承認・問い合わせ	管理者向け詳細運用書	必須操作と対象読者が確定
1.3.1.2	PDFマニュアル	社員操作説明	動画	実画面と手順が一致しレビュー可能
1.3.1.3	承認済みPDF	操作検証	動画承認	第三者が手順通り操作でき、指摘解消
1.3.1.4	動画マニュアル	SaaS更新後画面	更新前画面での確定版制作	更新画面で主要操作を収録・編集完了
1.3.1.5	公開可能動画	内容レビュー	継続的動画更新	誤操作説明なし、社員が閲覧可能
1.3.2.1	問い合わせチャネル定義	メール/Teams等	新規サポートシステム導入	受付方法が1つ以上明確
1.3.2.2	運用責任表	一次対応、経理、情シスへのEscalation	SaaS側SLA変更	問題種類ごとの送付先が明確
1.3.2.3	FAQ・回答ルール	想定質問	全問い合わせ網羅	初期頻出質問への回答が準備済み
1.3.2.4	窓口運用準備完了	公開・担当周知	実運用実績	テスト部署が利用可能
1.4.1.1	テスト対象一覧	営業2課12名	他部署	対象者・対象精算が確定
1.4.1.2	比較手順書	紙とクラウドの照合方法	本番監査制度	差異を客観的に判定可能
1.4.1.3	差異ログ	差異・原因・是正	Issue全般	差異1件でも記録できる形式
1.4.1.4	テスト開始承認	設定・連携・マニュアル・窓口確認	全社Go	前提条件がすべて合格
1.4.2.1	12月運用記録	1か月並行実施	1月本番	対象12名が期間中運用
1.4.2.2	照合結果	紙 vs SaaS	他部署精算	対象全件比較済み
1.4.2.3	差異是正記録	全差異の原因記録	未発生差異の仮説分析	発生差異がすべて記録・是正済み
1.4.3.1	最終照合結果	月次全件	サンプルのみの確認	最終差異0件
1.4.3.2	並行運用結果レポート	結果、問題、是正	投資効果分析	受入基準に対する結果が明記
1.4.3.3	Go/No-Go記録	全社展開判断	Scope追加承認	判断者・条件・未解決事項を記録
1.5.1.1	全社利用確認	180名	外部社員等	180名が利用開始可能
1.5.1.2	サポート公開確認	PDF、動画、窓口	新教育施策	社員からアクセス可能
1.5.1.3	本番チェックリスト	主要受入条件	運用後改善	全項目PASSまたは承認済み例外
1.5.2.1	告知案	開始日、対象、紙廃止、支援先	法人カード	内容完成
1.5.2.2	承認済み告知	関係部署レビュー	未承認変更	指摘反映済み
1.5.2.3	社内告知	全社員向け発信	外部PR	対象社員に配信確認
1.5.3.1	本番開始記録	2027/1/4切替	他システム切替	クラウド運用開始を確認
1.5.3.2	初期対応ログ	問合せ・障害分類	恒久的ヘルプデスク改善	担当・状態・対応先を追跡可能
4. 実行タスク表

Estimateは現時点の作業量の初期見積りです。カレンダー日数ではなく人日なので、未確定Dependencyによる架空の日程は作っていません。

WP	動詞で表したタスク	Owner	Estimate	Dependency	期限
1.1.1.1	対象経費ルールを設定する	石田	1.0人日	なし	10月末
1.1.1.2	社員・部署マスタを確認し登録する	前田	1.5人日	なし	10月末
1.1.2.1	部長へ承認者確定を依頼し回収する	石田	1.5人日	各部長	早期実施
1.1.2.2	部署別承認フローを設計する	石田	2.0人日	1.1.2.1	10月末
1.1.2.3	承認フローをSaaSへ設定する	石田	2.0人日	1.1.2.2	10月末
1.1.2.4	全部署の承認フローを検証する	前田	1.5人日	1.1.2.3	10月末
1.1.3.1	口座閲覧権限を2名に制限する	石田	0.5人日	マスタ設定	10月末
1.1.3.2	電帳法対応設定を有効化する	石田	0.5人日	SaaS仕様確認	10月末
1.1.3.3	権限と履歴をテストする	前田	1.0人日	1.1.3.1-2	10月末
1.2.1.1	ベンダー回答を取得し仕様化する	加藤	0.5人日	外部回答待ち	TBD
1.2.2.1	勘定科目・税区分をマッピングする	石田	1.5人日	1.2.1.1	10月末目標
1.2.2.2	SaaSの仕訳出力を設定する	石田	1.0人日	1.2.2.1	10月末目標
1.2.3.1	テスト仕訳データを出力する	前田	0.5人日	1.2.2.2	10月末目標
1.2.3.2	会計システムへテスト取込する	加藤	1.0人日	1.2.3.1	10月末目標
1.2.3.3	取込エラーを修正・再検証する	加藤	1.0人日予備	1.2.3.2	10月末目標
1.3.1.1	マニュアル構成を確定する	前田	0.5人日	主要設定	11月中旬
1.3.1.2	PDFマニュアルを作成する	前田	2.5人日	1.3.1.1	11月中旬
1.3.1.3	PDFの手順を実機検証する	石田	1.0人日	1.3.1.2	11月中旬
1.3.1.4	更新後画面で動画を制作する	前田	TBD	SaaS画面更新	Planning Package
1.3.1.5	動画をレビュー・公開する	石田	TBD	1.3.1.4	TBD
1.3.2.1	問い合わせ受付チャネルを決める	石田	0.5人日	なし	11月中
1.3.2.2	対応・Escalationルールを定める	石田	0.5人日	1.3.2.1	11月中
1.3.2.3	FAQを作成する	前田	1.0人日	PDF作成	11月中
1.3.2.4	テスト用窓口を利用可能にする	石田	0.5人日	1.3.2.1-3	11月末まで
1.4.1.1	テスト12名を確定する	石田	0.25人日	営業2課	11月中
1.4.1.2	並行比較方法を定義する	石田	0.75人日	会計連携確定	11月中
1.4.1.3	差異ログを作成する	前田	0.5人日	1.4.1.2	11月中
1.4.1.4	テスト開始条件をレビューする	石田	0.5人日	設定・連携・支援	12/1前
1.4.2.1	12名の並行運用を支援する	前田	3.0人日程度	1.4.1.4	12/1–31
1.4.2.2	紙とクラウドを照合する	前田	2.0人日	各精算	12/31まで
1.4.2.3	発生差異の原因を記録・是正する	石田	予備2.0人日	差異発生時	12/31まで
1.4.3.1	1か月分を最終照合する	前田	1.0人日	12月運用終了	1/4前
1.4.3.2	結果レポートをまとめる	石田	1.0人日	1.4.3.1	1/4前
1.4.3.3	全社Go/No-Goを判定する	石田※	0.25人日	1.4.3.2	1/4前
1.5.1.1	180名の利用可能状態を確認する	前田	1.0人日	設定完了	1/4前
1.5.1.2	マニュアルと窓口を公開確認する	前田	0.5人日	1.3	1/4前
1.5.1.3	本番開始チェックを完了する	石田	0.5人日	全受入条件	1/4前
1.5.2.1	紙廃止を含む社内告知を作成する	小松	1.0人日	運用方針確定	11月以降
1.5.2.2	告知案をレビューする	石田	0.5人日	1.5.2.1	12月
1.5.2.3	全社員へ切替を告知する	小松	0.5人日	Go条件確認	1/4前
1.5.3.1	クラウド本番運用へ切り替える	石田	0.5人日	Go判定	2027/1/4
1.5.3.2	初期問い合わせを分類・振り分ける	前田	TBD	本番開始	1月初期

※正式なGo/No-Go決裁者は入力上明示されていないため、石田は判定資料Owner、最終承認AuthorityはTBDとするのが安全です。

5. Critical / Blocking Dependency

最も重要なのは、作業量よりも外部回答と意思決定待ちです。

Blocking 1:会計ベンダーの取込仕様
会計ベンダー回答
↓
取込仕様確定
↓
仕訳マッピング
↓
SaaS出力設定
↓
テストファイル
↓
会計取込テスト
↓
12月並行運用
↓
全社Go

9月12日に問い合わせ済みですが回答期限がないため、現在もっとも明確な外部Blocking Dependencyです。

推奨管理: 回答期限を勝手に設定するのではなく、石田/加藤がベンダーへ「必要回答日」を提示してEscalationするタスクをIssue管理に登録。

Blocking 2:各部署の承認者確定
各部長へ依頼
↓
承認者確定
↓
承認フロー設計
↓
SaaS設定
↓
設定検証
↓
10月末設定完了

こちらはまだ依頼すら開始していないため、即時着手対象です。

Blocking 3:SaaS画面アップデート

これはシステム本体ではなく動画マニュアルをBlockingします。

SaaS画面更新
↓
動画収録
↓
動画レビュー
↓
社員公開

画面更新日が不明なので、動画作成の詳細日程は設定しません。

6. Milestoneとレビューゲート
Gate	Milestone	判定条件
G0	Scope Freeze	法人カード等の未承認要望を本プロジェクトから分離
G1	10月末 設定完了	承認フロー全設定、権限設定、電帳法対応設定、仕訳連携テストPASS
G2	11月中旬 マニュアルレビュー	PDF完成・操作検証済み。動画はSaaS更新状況を明示
G3	12月テスト開始判定	営業2課12名、連携、マニュアル、窓口、差異ログが使用可能
G4	12月並行運用完了	1か月分比較完了、すべての差異原因記録済み
G5	Production Go/No-Go	最終差異0件、受入基準①〜④をすべて確認
G6	2027/1/4 全社展開	180名利用可能、支援窓口公開、紙廃止告知済み

重要なのは、「12月中に一度でも差異があったら失敗」ではありません。 条件は「差異が1件でもあれば原因を記録」であり、最終的な受入基準が「1か月分の並行運用結果として差異0件」です。したがって、途中差異→原因記録→是正→再確認という管理にします。

7. リスク・Assumption・未割当
種別	項目	影響	対応
Risk	会計ベンダー回答遅延	10月設定完了を阻害	早期Follow-up / Escalation
Risk	部長から承認者回答が遅れる	承認フロー設定遅延	全部署一括依頼・未回答一覧管理
Risk	加藤が10月週1日のみ	連携テスト枠不足	加藤作業を仕様確認・実取込に集中
Risk	11月SaaS更新が遅れる	動画完成遅延	PDFを先行確定、動画はPlanning Package
Risk	SaaS更新でPDFも画面差異発生	再作業	更新後に最終画面レビュー
Risk	並行運用中に差異発生	1月Goに影響	1件単位で原因・修正・再検証
Risk	180名の所属情報不備	承認先誤り	マスタ事前照合
Assumption	SaaS自体は既に契約・導入済み	導入契約作業不要	現Scope維持
Assumption	会計システムはファイル取込可能	連携成立条件	ベンダー回答で確認
Assumption	SaaSが電帳法対応機能を備える	設定で対応可能	機能証跡確認
未割当	本番Go/No-Go最終決裁者	Gate G5	Authorityを確定
未割当	電帳法設定の最終適合承認者	G1	管理本部等で確定
未割当	問い合わせ窓口のバックアップ担当	本番運用	11月に決定
未割当	SaaS更新日の確定	動画	SaaS CS確認

SaaS CSは月2回までなので、随時質問ではなくレビューGateに合わせて使う方が効率的です。特に、①10月の設定・法令対応レビュー、②11月の画面更新・マニュアルレビューに枠を寄せる構成が妥当です。

8. 既存タスクとの重複/漏れ監査

既存表はそのままでは100% Ruleを満たしていません。

既存タスク	判定	WBS上の扱い
1. ケイヒクラウドの初期設定	粒度が粗すぎる	1.1.1 / 1.1.3等へ分解
2. 承認フロー設定	前工程不足	承認者収集→設計→設定→検証に分解
3. マニュアル作成	粒度が粗い	PDF/動画/検証/公開に分解
4. 社内告知	妥当だが前後工程不足	作成→レビュー→配信に分解
5. 法人カード会社の比較	Scope違反	WBSから削除。Change Request候補
6. テスト	粒度不十分	計画→並行運用→差異管理→最終照合→結果レポートに分解

既存表で特に漏れていたのは、会計システム連携、電帳法設定、口座情報の権限制御、承認者の確定、問い合わせ窓口、差異記録、受入判定、180名の利用可能確認、Go/No-Go Gateです。

逆に、明確な過剰Scopeは**「法人カード会社の比較」**です。これを前田の週2日の稼働に残すと、本来Scopeのマニュアル・テスト準備を圧迫します。そのためプロジェクトWBSから切り離すべきです。

100% Rule監査結果

承認済みScopeとの対応は次のとおりです。

交通費・出張費・立替経費の申請 → 1.1

承認 → 1.1.2

仕訳連携 → 1.2

社員教育 → 1.3.1

問い合わせ窓口 → 1.3.2

12月並行運用 → 1.4

差異0件の受入確認 → 1.4.3

旧紙フロー廃止 → 1.5.2〜1.5.3

全社員180名で利用 → 1.5.1

法令・セキュリティ条件 → 1.1.3

Scope/依存関係管理 → 1.6

したがって、現時点では承認済みScopeに対する大きな漏れ・二重計上はありません。 一方で、会計ベンダー回答・承認者確定・SaaS画面更新という3つの外部依存が未確定なので、そこだけは「細かい日付を置いた工程表」に変換せず、Blocking / Planning Packageとして管理するのが適切です。

この出力になっていれば成功

  • Deliverable指向
  • 100% Rule
  • 各PackageにOwner・DoD・Estimate
  • 依存関係が妥当
  • Scope外を混入しない

使うときの注意

重要な判断は担当者が一次情報と照合してください。

Scope未承認・受入基準不足はPlanning Package/TBD。細分化し過ぎ、活動だけの羅列、Owner複数、隠れ作業を避ける。

参考にした一次情報: OpenAI Prompting Guide

ZEN PROMPT LIBRARY

やりたいことから、
次のPromptを探す。