Skill.md検索

ビジネス目標・要件・設計・実装・テストの全段階を一つの表で追跡し、漏れなく対応関係を確認できます。 各要件がビジネス目標に対応しているか、テストで検証されているかを一目で把握できます。 要件の進捗状況（未定義→設計中→実装中→テスト済）を更新・管理し、プロジェクト全体の見える化を実現します。 Markdown 形式で自動生成・保存されるため、バージョン管理や共有が容易です。 PMBOK第8版のスコープ管理・価値実現の追跡に準拠した正式なドキュメントとなります。 要件定義から納品までの対応関係を管理したいプロジェクトマネージャー 要件漏れやテスト漏れを防ぎたい QA・テストチーム PMBOK準拠のドキュメント作成が必要な組織 スコープクリープ（要件の無制限拡大）を防ぐため、全要件を可視化したい開発リーダー 要件トレーサビリティマトリクス（RTM）を作成。入力：要件文書・ビジネスケース・プロジェクトスコープ記述書（未作成時はユーザー確認）、設計成果物との対応（画面仕様書・API仕様書・DB設計書等）、テストケース・実装モジュール情報。出力先：vibeProjectManagement/docs/requirements/requirements-traceability-matrix_[プロジェクト名].md、テンプレートは assets/template.md に定義され必ず参照。作成指針：（1）要件文書全要件を網羅、（2）双方向トレーサビリティ確保（ビジネス目標→要件→設計→実装→テスト→逆方向），（3）ステータス常時更新，（4）未実施段階は「未定義」と記載。保存後、ユーザーに保存パス通知・修正確認を案内。

プロジェクトに関わるステークホルダー（経営層・ユーザー・技術者など）を網羅的に洗い出し、一覧表として整理できます。 各ステークホルダーの関与度・影響力・関心事などを明記することで、「誰の声を聞くべきか」が一目瞭然になります。 関与度と影響力を軸としたマトリクス図を作成し、優先度の高い関係者にいつ・どのようにコミュニケーションすべきかが判断できます。 PMBOK第8版の国際基準に準拠した形式で作成するため、大規模プロジェクトやクライアント報告でも通用する品質を確保できます。 要件漏れを防ぎ、プロジェクト開始前に「聞き落とした関係者がいた」というトラブルを事前に回避できます。 プロジェクトマネージャーやスクラムマスターで、利害関係者との調整が多い職種の人 要件定義の上流工程を担当し、漏れなく関係者から意見を集めたい人 クライアント案件で体系的に関係者管理をしたい受託企業の担当者 経営層・運用チーム・法務など、多様なステークホルダーを巻き込むプロジェクトの推進者 ステークホルダー登録簿（Stakeholder Register）をMarkdownで作成し、vibeProjectManagement/docs/requirements/内に保存します。ファイル名は「stakeholder-register_[プロジェクト名].md」となります。テンプレートはassets/template.mdで定義されているため、必ずこれに従います。各ステークホルダーについて氏名・役職・所属組織、関与度（高・中・低）、プロジェクト意思決定への影響力、関心事、要件収集における役割（インタビュー対象・承認者・情報提供者等）、コミュニケーション方法（会議・メール・報告書等）、コミュニケーション頻度を記載します。情報が不足していればユーザーに一度にまとめて確認します。網羅的洗い出し、関与度×影響力マトリクス活用、エンゲージメント計画の基礎化、PMBOK第8版のステークホルダー・パフォーマンスドメインに基づく評価（抵抗・中立・支持・リード）を指針とします。

技術・設計・運用の重要判断を構造化記録: アーキテクチャ選択、ライブラリ・フレームワーク決定、運用方針など、プロジェクトの根拠ある決定をADR（建築決定記録）として残します。 なぜその判断をしたかを自動ドキュメント化: 背景・課題・検討した選択肢・採用理由を標準フォーマットで整理し、後任者も文脈を理解できるようにします。 却下選肢の評価も記録: 採用しなかった案についても、なぜ選ばなかったかをメリット・デメリットと共に残すことで、将来の方針変更時の判断材料になります。 複数の情報源から効率的に作成: 口頭説明、議事録、チャットログなど、どんな形式の入力でもADRに整形できます。 決定履歴の一元管理: 時系列でADRが蓄積され、プロジェクトの進化过程と意思決定の軌跡を可視化できます。 テック・アーキテクト・CTO: 技術的な大きな判断を記録し、チーム内の認識ズレを防ぎたい方 プロジェクトリード: 設計判断の根拠を文書化し、将来の保守・拡張時に判断軸を共有したい場合 プロジェクト成熟度を高めたい組織: 「なぜこの設計？」という質問への回答を常に用意でき、新しいメンバーのオンボーディングを加速できます 技術的負債の管理: 過去の判断コンテキストを残すことで、負債解消時に適切なタイミングと方法を判断しやすくなります

会議音声・文字起こしから議事録を自動作成: 録音データや文字起こしテキストを受け取り、構造化された日本語議事録Markdownに自動変換します。 要点・決定事項・宿題を自動抽出: 発言の逐語録ではなく、議論の要点、下された決定、誰が何をいつまでにやるかを正確に整理します。 複数ファイル・メモ形式に対応: テキスト直貼り、複数ファイル指定、メモ形式など、どんな入力形式でも統一された議事録に整形できます。 日時・場所・参加者を標準化: ミーティング情報を統一フォーマットで整理し、後から検索・参照しやすいドキュメント構造を提供します。 期限・担当者を明確にした宿題リスト: 「誰が・何を・いつまでに」の3点を抽出し、フォローアップを確実にする宿題管理を実現します。 プロジェクトマネージャー・スクラムマスター: 毎回のミーティング記録を効率的に作成・管理し、チームの進捗を可視化したい方 リモートワーク・分散チーム: 録音・文字起こしから自動的に議事録を生成し、不参加者への情報共有を迅速にしたい場合 意思決定の履歴管理: ミーティングで何が決定されたか、どの宿題が進行中かを一元管理し、フォローアップ漏れを防ぎたい組織 会議の質向上: 議事録作成の手間を削減し、ファシリテーターがミーティング運営に集中できる環境を作りたい方

WBSの進捗を数値で自動集計：タスク管理ファイルから完了状況を読み込み、達成率を「5/8タスク完了（63%）」のように具体的に表示します。 課題・リスクを構造化して整理：問題が何か、影響範囲、対処方法、担当者、期限を一つの表にまとめて記載できます。 品質情報をテスト結果から自動抽出：バグ件数、テスト実施数などの計測データをもとに品質状況を報告に含めます。 プロジェクト全体の健全性を一目で表示：「正常」「要注意」「危機」の3段階で現況を先頭に示し、マネジメント層の判断を支援します。 毎週の報告書を統一フォーマットで自動生成：同じ構成で継続的に記録されるため、週ごとの傾向把握が容易になります。 プロジェクトマネージャー・スクラムマスター：毎週の進捗報告資料作成の手間を削減し、重要な課題分析に時間をかけられます。 プロジェクト管理ツール（Jira、Asanaなど）を運用している組織：既存のタスク管理データをそのまま活用できるため、二重入力が不要になります。 ステークホルダーへの定期報告が必要な案件：統一された見た目で信頼性の高い報告書を短時間で作成できます。

前提条件をリスク化して記録：「この前提が成立しなかったら、プロジェクトはどうなるか」を明記することで、リスク管理と一体化した管理が実現します。 技術・ビジネス・リソース・法規制の制約を網羅的にリスト化：要件定義時点で見落としやすい外部依存や技術的制限を事前に明文化できます。 PMBOK第8版の「不確実性対応」ドメインに準拠：国際的な標準に沿った形式で記録するため、プロジェクト運営の透明性が向上します。 後から要件が変わった際の影響判定が迅速に：「この要件変更は、どの前提条件に抵触するか」が即座に判断でき、変更対応が効率的になります。 定期的な見直しプロセスを組み込み：前提は時間とともに変わるため、見直し頻度と責任者を明記し、継続的な管理が可能になります。 要件定義者・ビジネスアナリスト：曖昧な前提を明文化することで、後からの要件争点を減らせます。 リスク管理を担当するPM：前提と制約を体系的に記録することで、リスク管理の下地ができます。 複数ステークホルダーがいるプロジェクト：前提条件を共有ドキュメントとして共通認識化でき、認識ズレを防ぎます。

プロジェクトの背景、解決する課題、期待される効果（ROI やコスト削減など）をヒアリングし、投資判断用のビジネスケース文書を作成します。 「月間◎◎万円のコスト削減」といった定量的な根拠を含めた説明になるため、経営層が承認判断しやすくなります。 実施しない場合のリスクや機会損失も明記し、なぜこのプロジェクトが必要なのかを明確にします。 複数の代替案を比較した上で、推奨案を示すことで、意思決定プロセスが透明になります。 PMBOK 第 8 版の要件定義フロー（ステップ 1）として標準的に使えるため、後続のプロジェクト計画がスムーズになります。 プロジェクト提案を経営層へ説明し、予算承認を得たい PM やビジネスオーナー ROI や定量的な効果を根拠に、プロジェクトの優先順位をつけたい企画・経営企画部門 要件定義を PMBOK に準拠したプロセスで進めたいプロジェクトマネージャー 複数の実装案の中から最適なアプローチを選定するために、客観的な比較資料が必要な意思決定者

プロジェクト名、目的、スコープ（やることやらないこと）、スケジュール、予算などの情報をヒアリングして、PMBOK 準拠のプロジェクト憲章文書を作成します。 プロジェクトマネージャーの権限範囲を明記することで、PM が予算執行やリスク対応の判断をできるようになります。 SMART 目標（具体的・測定可能・達成可能・関連性・期限がある）の形式で目標を整理するため、成功の基準が明確になります。 ステークホルダー（関係者）の役割と責任を明示し、プロジェクト進行中の意思決定や報告体制が透明になります。 この文書がベースラインとなるため、後から「これってスコープ内？」という議論を最小化できます。 プロジェクトを正式に開始する際に、関係者全員に承認を得たいプロジェクトマネージャー 予算や期限などの制約条件を明記し、ステークホルダーとの期待値を統一したいビジネスオーナー PMBOK のベストプラクティスに沿ったプロジェクト管理を導入したい組織 プロジェクト開始時の各種ドキュメント作成を効率化し、計画フェーズを加速させたい PM

プロジェクトで実施する内容、作成する成果物（システム、ドキュメントなど）、そして意図的に行わない内容を整理した、スコープ記述書を作成します。 「これはスコープ内か外か」という後からの議論を減らすため、スコープの境界を最初から明確に定義します。 プロジェクト完了の定義（本番環境での合格、利用者への説明完了など）を具体的に記載し、何をもって「完了」とするかが一目瞭然になります。 成果物ごとの受け入れ基準を検証可能な形で記述するため、品質確認がスムーズになります。 ビジネスケース、プロジェクト憲章と連携しながら、要件定義の全体フローをサポートします。 要件追加の申し込みが後を絶たず、スコープ管理に悩むプロジェクトマネージャー クライアントとの期待値のズレを最初から防ぎたい SIer やコンサルタント PMBOK に準拠した要件定義プロセスを導入したい組織 プロジェクト完了時の品質合意を事前に取り、受け入れテストをスムーズに進めたい開発チーム

ステークホルダーの要望を体系的にまとめる — 機能要件・非機能要件・ビジネス要件などを漏れなく整理し、プロジェクト関係者全員が同じ認識を持つための「単一の情報源」として機能する文書を作成できます。 測定可能な要件に落とし込む — 「高速であること」ではなく「95パーセンタイルで3秒以内に応答すること」のように、実際に検証・テストできる形で要件を記述できます。 要件の優先度を明確にする — MoSCoW法（Must/Should/Could/Won't）を使って、どの要件が必須で、どれが後回しにできるかを可視化します。 承認と変更の履歴を残す — 誰がいつどの要件を確認・承認したかを記録し、後から「そんな要件は合意していない」といったトラブルを防げます。 要件IDで要件を管理 — 全ての要件に一意のIDを付与し、設計書・テスト計画書との紐付け（トレーサビリティ）を実現します。 プロジェクトマネージャー・PMO — プロジェクト開始時に関係者の要望を正式に文書化し、スコープ管理の基盤を作りたい方 要件定義担当者・ビジネスアナリスト — クライアントや利害関係者から収集した要望を体系的に整理して報告書にしたい方 システム企画・企画担当者 — 新規事業やシステムの構想段階で、要件を明確にして関係者の認識を揃えたい方 受託開発企業の営業・提案担当者 — 提案資料の根拠となる要件文書を作成し、クライアントとの合意を固めたい方

要件の変更管理プロセスを構築する — 「誰が・何を・いつ・どのように」申請・承認するかのルールを明確にし、無意識の要件追加や認識齟齬による後戻りを防ぎます。 要件の承認権限を明確にする — 小さな変更は担当者レベルで、大きな変更は経営層が判断するなど、段階的な承認フローを設定できます。 要件のトレーサビリティ（追跡可能性）を確保 — 要件ID・命名規則・管理ツールを標準化し、どの要件がどの設計・テスト・成果物に反映されているかを追跡できるようにします。 ベースラインを設定する — プロジェクト開始時点での「確定した要件群」を設定し、それ以降の変更を厳密に管理します。 プロジェクト規模に合わせたプロセスを選択できる — ウォーターフォール型・アジャイル型・ハイブリッド型など、開発手法に合ったプロセスを設計します。 プロジェクトマネージャー — プロジェクト開始前に要件管理の「ルール」を決めて、後からの余計な変更申請を減らしたい方 要件定義担当者・品質保証（QA）担当者 — 要件の変更申請から承認までのプロセスを文書化し、関係者に周知したい方 大規模プロジェクト・複数チーム体制のマネージャー — 要件の採番ルール・管理方法を統一し、全チーム間での認識齟齬を防ぎたい方 規制業界の企業（金融・医療・公共） — 要件管理の厳格性が求められる環境で、承認・監査に耐えうるプロセスを構築したい方

成果物から作業パッケージへ落とし込む — 何を作るかの要件・機能から、それを実現するための具体的な作業単位（作業パッケージ）に分解し、スケジュール・予算・人員計画の基盤を作ります。 作業の漏れと重複を防ぐ — 100%ルール（上位の成果物がすべての子要素の合計で100%構成されること）に基づいて分解するため、「やり忘れた作業」や「重複作業」を事前に防げます。 担当者単位での作業単位を明確にする — 最下層の作業パッケージを「1人が数日〜2週間で完了できる粒度」に設定することで、個別の担当者にクリアな指示を出せます。 階層構造で全体像を可視化する — WBS番号（1.0, 1.1, 1.1.1 等）で階層を表現し、プロジェクト全体の構造を一目で理解できるようにします。 開発手法に合わせた分解が可能 — ウォーターフォール型・アジャイル型・ハイブリッド型など、プロジェクトの開発手法に合わせた分解方式を選択できます。 プロジェクトマネージャー・スクラムマスター — 要件をタスク単位に分解し、スケジュール・工数見積もりの基となるWBSを作成したい方 開発チームリード — チームメンバーへの作業指示を明確にするため、WBSで作業を可視化したい方 多工程プロジェクト（企画→設計→開発→テスト→運用）を統括する立場 — 全体の流れを階層的に整理し、各フェーズの成果物と作業を紐付けたい方 複数チーム・複数部門にまたがるプロジェクトのマネージャー — 部門・チーム間の責任範囲を明確にするため、WBSで作業を分割したい方