Skill.md検索

曖昧な要求を実行可能な受入基準に変換：口頭説明やドキュメント断片から、Gherkin形式（Given-When-Then）の明確な受入基準を自動生成し、実装チームが何をするべきか一目で理解できるようにします。 3つの手法を状況に応じて使い分け：傾聴（Active Listening）で深掘り、Example Mappingで構造化、Formulationで形式化という3つの手法を、必要に応じて柔軟に行き来しながら、ビジネスルールを整理します。 ステークホルダー間の共通理解を構築：開発チーム・QA・ビジネス側が同じ仕様イメージを持つよう、対話的に誤解を解きながら、未解決の質問を明確にリストアップします。 エッジケース（想定外の事象）を洗い出し：「ログイン失敗時は？」「セキュリティロックは？」といった見落としやすい条件も体系的に発見し、ルール化します。 プロダクトマネージャー・ビジネスアナリスト：ぼんやりした要件を、開発チームが実装できる形に整理したい方 スクラムマスター・アジャイルコーチ：バックログ詳細化やスプリント計画時に、チーム全体の共通理解を素早く作りたい方 開発リード・テストリード：TDD/BDD導入時に、テスト仕様を自動生成する基盤を作りたい方 要件定義に関わる全員：曖昧さを残したまま実装が始まることによる手戻りを防ぎたい方

「○○機能が欲しい」から本当の課題を発見: 表面的なリクエストの奥にある、本当に解決したい問題やビジネス価値を対話を通じて掘り起こす（例：「検索機能」の背景にある「ユーザーが目当ての商品を見つけられない」という問題を発見） ユーザーの立場を具体的に理解:「誰が、どんな場面で、どんな目的で、その機能や施策を使うのか」をペルソナと使用シーン、行動パターンとして言語化 実装範囲をスッキリ定義: 「含めるもの・含めないもの・要検討」を明確に書き出し、スコープを確定させ、後の齟齬や機能追加を防止 隠れた仮定や矛盾を発見: ステークホルダーが無意識に抱いている前提条件や、要求同士の矛盾を丁寧な質問を通じて浮き彫りにして解消 技術に飛びつく前に理解を深める: 「Elasticsearchを入れる」という技術的な解決に飛びつく前に、「そもそも何を解決したいのか」を徹底的に理解し、最適な設計につなげる プロダクトマネージャー・プロダクトオーナー: 営業やクライアント、経営層から曖昧な要望をもらったときに、本当にビジネス価値のある要件に落とし込みたい システムエンジニア・要件定義者: ユーザーへのヒアリング結果がバラバラで、実装仕様として不十分なときに、構造化された要件書に整理したい 起業家・新規事業開発: 顧客インタビューを実施しているが、本当のペインポイントやニーズを見落としていないか確認したい プロジェクトマネージャー: 要件の認識違いで後々もめないよう、プロジェクト開始前にステークホルダー間の理解をすり合わせたい

曖昧なルールを具体例で明確化: 「ユーザーフレンドリーに対応する」「不正を防止する」などの抽象的なルールを、「こういうときはこう動作する」という具体的な例に翻訳 開発・テスト・営業の視点で矛盾を発見: エンジニア（実装できるか）、テスター（テストできるか）、営業（ビジネス価値があるか）の三者の視点で要件をチェックし、落とし穴を事前に発見 テスト項目を自動抽出: ビジネスルールごとに「こういうケースをテストすべき」という テストシナリオが自動的に列挙される エッジケースや境界値を見落とさない: 「最大値は？」「エラー時は？」「空の場合は？」という質問を自動的に投げかけ、見落としやすいテストケースを浮き彫りにする ストーリーが複雑すぎる場合は分割を提案: 7個以上のルールや10個以上の質問が出たら「これは分割したほうがいい」と自動判定し、管理可能なサイズに仕切り直す プロダクトマネージャー・ビジネスアナリスト: ユーザーストーリーをテスト可能な形に落とし込み、開発チームとテストチームが迷わないようにしたい 開発チーム・QAチーム: 実装前に「このルールはこの場合どうなる？」という質問を出し尽くし、実装後の手戻りを最小化したい スタートアップ・アジャイルチーム: スプリント内で「本当にテスト可能なストーリーか」を素早く判定し、スプリント計画を正確にしたい 受入テスト担当者: お客様の意図通りに機能が動いているか判定するための「受入基準」を明確にしたい

ビジネス層と技術層を翻訳: マーケティングや営業が理解する「ビジネス言語」で書かれたルールを、開発・テストチームが実行可能な「Gherkin形式」のテストシナリオに自動翻訳 仕様・テスト・ドキュメントを統一: 同じ.featureファイルが、ステークホルダー向けの仕様書・開発チーム向けのテスト実行指示・自動テスト実装の入力データとして機能し、バラバラな資料管理から解放 具体例でビジネスルールを実行可能化: 「前方部分一致で検索する」→「検索キーワード『Mac』を入力すると『MacBook Pro』『MacBook Air』が表示される」と、具体的なデータを含むシナリオに展開 テスト漏れをシステム的に防止: Given（前提）-When（操作）-Then（結果）という形式で、各シナリオが「何をテストするのか」明確になり、抜け漏れが生じにくくなる 複雑なロジックを表・データで整理: 複数パターンのテストを「データテーブル」や「Scenario Outline」として記述でき、コードの繰り返しを削減し、テストの意図を一目で理解可能に QAエンジニア・テスト設計者: 手で書くテストケースが膨大になるのを避け、ビジネスルールから自動的にテストシナリオを生成し、テスト計画を効率化したい BDD（行動駆動開発）を実践するチーム: Cucumber等のツールを使ってテストを自動実行したいが、仕様書とテストの一元管理がしたい 開発チーム: 要件定義のドキュメントが抽象的で実装方針が定まらないときに、具体的なシナリオベースの仕様書があると、実装イメージが湧きやすい プロダクトマネージャー・ステークホルダー: 仕様書を書いても実装結果がズレることが多いが、共通のテストシナリオ言語を持つことで、要件の認識違いを事前に発見したい