Skill.md検索

運用フェーズの全体像（構築→配置→ドキュメント更新）を理解し、アプリケーション開発環境→開発環境→ステージング環境→本番環境の段階的構築を体系的に進められます 環境構築（セットアップ）・プロビジョニング（IaC）・CI/CD構築・デプロイ設定・運用スクリプト作成の5つの活動を順序立てて実行し、各段階で対応するテンプレート手順書を参照できます Terraform・CloudFormation等のインフラコード、ローリング/Blue-Greenデプロイなどの戦略、環境別の自動化スクリプト作成をガイドします 長時間セッションでコンテキストリミットに達した場合は/compact実行タイミング（環境1つ完了時・プロビジョニング完了時など）を自動提示します 環境構築・プロビジョニング・CI/CD・デプロイの全体フローを一度把握できるため、やり忘れや順序ミスを防げます アプリケーション開発後に、運用フェーズの環境構築・インフラ整備を始める開発チーム ローカル開発環境から本番環境まで、複数環境の構築手順を統一・自動化したい組織 インフラコード（Terraform）・CI/CDパイプライン（GitHub Actions等）・デプロイ戦略を体系的に学びながら構築したい 長時間の運用作業でAIとの会話コンテキストが満杯になる問題を回避したい 運用フェーズは「構築」と「配置」の2活動で構成。構築：(1)環境構築=各環境のセットアップ、(2)プロビジョニング=Terraform/CloudFormationでインフラ定義・状態管理・モジュール化・テスト、(3)CI/CD構築=パイプライン設計・OIDC認証、(4)運用スクリプト作成=タスクランナー・自動化スクリプト。配置：(1)デプロイ設定=ローリング/Blue-Green等の戦略。段階的フロー：アプリケーション開発環境→開発環境→ステージング環境→本番環境の順序。各環境セットアップ時にテンプレート手順書（アプリケーション開発環境セットアップ手順書.md等）を参照。運用スクリプト作成は各環境セットアップ完了時に、@docs/reference/運用スクリプト作成ガイド.mdに従い環境構築・ビルド・デプロイ・ステータス確認・バックアップリストア・クリーンアップスクリプトを作成。実行手順：現状確認→環境計画→手順書作成→環境構築→CI/CD構築→運用スクリプト→ドキュメント更新。長時間セッションでは環境1つ完了時・プロビジョニング完了時に/compactを実施してコンテキスト圧縮。

エンティティ・値オブジェクト・集約・ドメインサービスをDDD（ドメイン駆動設計）の戦術的設計パターンに基づいて体系的に設計できます。 ユビキタス言語（ドメインエキスパートと開発者が共通で使う言葉）を整理し、業務の専門家と開発チームが「同じことば」で会話できる状態を実現できます。 設計結果をPlantUML クラス図・オブジェクト図として可視化し、バージョン管理下に置いて設計変更を追跡できます。 要件定義・ユースケース・アーキテクチャ設計の成果から、「仕様と実装の乖離」を根本的に解消するドメインモデルを導出できます。 DDD を適用してシステム設計をしたい アーキテクト・シニア開発者 エンティティと値オブジェクト、集約の境界を正確に識別・定義したい 業務ロジックが実装コードに正しく反映されるようにしたい開発チーム ドメインエキスパートと開発者の認識ズレを最小化したい 4つのドメインオブジェクト定義ステップ： 1. エンティティ定義：ライフサイクル（作成・更新・削除）と識別子を持つオブジェクトを抽出。「同じ属性値でも別のもの」として扱う必要があるものが対象。識別子は自然キーまたはサロゲートキーを選択 2. 値オブジェクト定義：不変かつ識別子を持たないオブジェクトを識別。属性値が同じなら同じもの。金額・メールアドレス・住所など業務概念をプリミティブ型の代わりに値オブジェクト化し、バリデーションとドメイン知識をカプセル化 3. 集約の設計：トランザクション整合性の境界を定義。集約ルート（外部アクセスポイント）を決定し、境界を最小限に。集約内の不変条件（常に満たすべきビジネスルール）を明確化 4. ドメインサービス定義：エンティティ・値オブジェクトに属さないビジネスロジックをステートレスで動詞命名 実装フロー：入力ドキュメント（要件定義・ユースケース・アーキテクチャ）確認→参照ガイド読込→ユビキタス言語用語集作成→順序立てて設計→docs/design/domain-model.md 出力。既存設計がある場合は差分確認・修正。

業務領域とデータ構造の複雑さに基づき、適切なアーキテクチャパターン（レイヤード、ヘキサゴナル、クリーン等）を選択してドキュメント化できます。 バックエンドでCQRS（コマンド・クエリ責任分離）やイベントソーシングの導入判断を、過剰適用を避けながら検討できます。 REST、GraphQL、gRPCなどのAPI設計方針を、プロジェクト要件に合わせて決定できます。 フロントエンドフレームワークの選定から状態管理パターン、コンポーネント設計指針までを、チームスキルとUXを考慮して整理できます。 クラウド・オンプレミス選定、コンテナ化戦略、CI/CDパイプラインなどのインフラ構成を、運用コストを踏まえて設計できます。 新規プロジェクトの技術構想をまとめる企画・PMの人 プロジェクト初期段階で設計判断を記録したいアーキテクト・リードエンジニアの人 複雑なドメインに対応するアーキテクチャの選定に悩むチームリーダーの人 既存アーキテクチャの見直しや拡張を検討する開発チームの人 業務ロジックの複雑さに応じてバックエンドアーキテクチャパターン（レイヤード、ヘキサゴナル、クリーンなど）を選択します。単純なCRUD操作ならレイヤード構造で十分ですが、ドメインが複雑な場合は より高度なパターンを採用します。CQRS/イベントソーシングは読み書きの特性が大きく異なる場合に限定的に検討し、過剰適用による複雑性増加を回避します。フロントエンドはユーザー体験とチームスキルを考慮し、フレームワーク選定理由を設計決定記録（ADR）で残します。インフラは非機能要件（可用性・スケーラビリティ）を満たしつつ、運用コストとセキュリティを総合判断します。要件定義、ユースケース、ユーザーストーリーを入力として、バックエンド→フロントエンド→インフラの順で各アーキテクチャを設計し、重要な判断は必ずADRで記録します。既存アーキテクチャがある場合は、不足領域や更新箇所のみ修正します。

変更内容を自動確認し、意味のある変更単位ごとに段階的にステージング・コミットできます。 Conventional Commits ルールに従った統一形式のコミットメッセージを生成し、コード履歴の品質を保つことができます。 コミットメッセージに type（feat・fix・docs・style・refactor・test・chore）と scope を自動付与し、変更内容を一目瞭然にできます。 コミット前に変更内容を確認し、テスト通過後に確実にコミットすることで、壊れたコードのコミットを防げます。 コミット履歴を可視化し、将来の変更を追跡・検索しやすくできます。 開発者：コミットメッセージのばらつきを統一し、履歴を読みやすくしたい方 チームリーダー：チーム全体のコミット品質を向上させたい方 CI/CD 推進者：自動ツールがコミット履歴から自動で Change Log を生成できるようにしたい方 このスキルは 4 つのステップで安全かつ統一的なコミット作成プロセスを定義しています。Step 1 では git status でワーキングディレクトリの変更を確認。Step 2 では git add で意味のある変更単位ごとにファイルをステージング（無条件のすべての追加は禁止）。Step 3 では Conventional Commits フォーマット「(): 」に従ってコミットメッセージを作成。type の種類は feat（新機能）・fix（バグ修正）・docs（ドキュメント変更）・style（コード意味に影響なし）・refactor（バグ修正や機能追加でないコード変更）・test（テスト追加・修正）・chore（ビルドツール変更）。step 4 では git log --oneline でコミット確認。ベストプラクティスは「1 コミット 1 目的」「小さく頻繁に」「テスト通過後にコミット」「明確なメッセージ」です。

プロジェクトの「なぜやるのか」「どんなビジョンか」「スコープはどこまでか」など10の重要な問いに体系的に答えられます ビジネスアーキテクチャ分析書をもとに、チーム全員が同じ方向を向くためのドキュメント（インセプションデッキ）を作成できます 概念アーキテクチャ図やマイルストーンのGanttチャートを自動生成して、複雑な情報を視覚化できます 既存のインセプションデッキを新しい条件に合わせて更新・修正することもできます 作成したドキュメントからPowerPointスライドを生成してステークホルダーへプレゼン準備もできます プロジェクトを立ち上げる際にチーム全体の認識を揃えたいプロジェクトマネージャー・プロダクトマネージャー ビジネス要件と技術要件の落としどころを整理したい設計者・アーキテクト プロジェクトの中盤で「実は認識がズレていた」という手戻りを減らしたい企画・開発チーム 不明な点が残ったままプロジェクトを進めたくない、仮定を明記して進めたい方 ビジネスアーキテクチャ分析書（業務分析の成果物）をもとに、10の問い形式でインセプションデッキを作成。情報源：ケイパビリティヒートマップ（問い1）、ビジネスプリンシプル（問い2・9）、価値提案（問い3）、バリューストリーム・ケイパビリティマップ（問い4）、組織マップ（問い5・8）、ガイディングプリンシプル（問い6）、リスク環境（問い7）、フェーズ分割マイルストーン（問い10）。新規作成時はテンプレート（@docs/template/インセプションデッキ.md）をコピーして使用。概念アーキテクチャ図（問い6）とマイルストーンGanttチャート（問い10）はPlantUMLで作成。既存デッキの更新時は該当する問いのみを修正。完成後は generating-slides スキルでPowerPoint化可能。テンプレートは編集禁止。

テンプレートに沿ったヒアリングで事例文を自動生成：経営戦略・マーケティング・生産管理・財務会計の4パターンから選択し、体系的な質問に答えるだけで論理的整合性のある与件文が完成します。 論理の抜け漏れを防止：事前に固定されたテンプレート構造に従うため、重要な要素の漏れや矛盾が起こりません。 短時間で質の高い事例文を作成：診断士試験対策や経営コンサルティングの事例分析に必要な「よい与件文」を効率的に仕上げられます。 複数テーマの自然な統合：経営課題が複数領域にまたがる場合も、パターン間で要素を補完し、自然な文章に仕上げます。 中小企業診断士試験の受験者：事例問題を自作したい人、出題パターンを理解したい人 経営コンサルタント・企業研修講師：リアルな企業事例をテキストや研修教材として作成したい人 事業承継や組織改革に携わる担当者：企業の課題を整理し、外部専門家に適切に説明するための事例文が必要な人 起業家・事業計画立案者：仮想企業の事例を通じた分析フレームワークを学びたい人 本スキルは、4つのビジネス分析パターン（経営戦略、マーケティング、生産管理、財務会計）に対応したテンプレートを備えています。ユーザーはまずテーマに合わせてパターンを選択し、段落ごとに体系的なヒアリング質問に回答します。共通項目（企業名、業種、資本金、従業員数、売上高など）を最初にまとめ、その後パターン固有の詳細情報を段落単位で集めていきます。プレースホルダ置換方式により、回答内容が自動的に与件文に組み込まれます。選択パターンにない情報は他パターンから補完ルールに従い最も近い段落に織り込み、新しい見出しを追加せずテンプレート構造を保ちます。完成前に時系列の矛盾、因果関係の整合性などをチェックし、論理的で読みやすい事例文を出力します。

ユーザーが実際に操作する画面から開発を始め、不要な機能を作らずに済む。テスト駆動開発（TDD）により、UI の振る舞いを自動テストで保証できる Red-Green-Refactor サイクル（テスト失敗→最小コード実装→整理）を 10-15 分で繰り返し、品質を保ちながら高速に開発できる アウトサイドイン（UI 層→ロジック層→データ層）のアプローチにより、実装の詳細に左右されないテストを書き、安全なリファクタリング（コードの整理・改善）を実現できる 自動テストでコンポーネントの動作を保証するため、本番デプロイ後の予期しないバグを防げる フロントエンド開発者で、品質と開発スピードの両立を目指す人 UI/UX を重視し、実装の詳細より使い方の正確さを優先したい開発者 既存コードの修正・リファクタリング時に、動作を壊さないか不安な人 テストコード を書きながら開発を進めたい開発チーム Red-Green-Refactor サイクルとアウトサイドインアプローチを組み合わせてフロントエンド開発を行う。アウトサイドイン（UI 層→ロジック層→データ層）で、ユーザー視点から内側へ段階的に構築することで、ユーザーが実際に操作する画面から始めるため不要な機能を作らずに済み、テストがユーザーの振る舞いに基づくため実装の詳細に依存しにくい。1 サイクルは 10-15 分で完了させ、長引く場合はタスク粒度を見直す。Red（失敗するテスト作成）→ Green（最小限のコード実装）→ Refactor（重複除去・設計改善）のステップを踏む。アプローチはアウトサイドイン（推奨）またはインサイドアウトから選択可能。テストコマンドは npm run test（全テスト）、npm run test:watch（ウォッチ）、npm run test:coverage（カバレッジ）、npm run test:e2e（E2E テスト）。コミット前には、全テストパス、ESLint 警告ゼロ、カバレッジ達成、単一作業単位の表現、明確なコミットメッセージを確認する品質チェックリストを実施する。途中再開時は現在のテスト状態を確認してから進める。TDD の三原則を厳密に守り、テストなしでプロダクションコードを書かない。

「分析を始めたい」という相談時に、4段階（戦略→要件定義→機能要件→非機能要件）の全体構成と進め方を提示できます。 現在のプロジェクトの進捗を把握し、「次は何をすべきか」を明確に指示できます。既に完了した工程はスキップし、未着手・更新必要な工程から再開できます。 各分析工程に対応した専門スキル（analyzing-* シリーズ）を段階別に紹介し、どのスキルを使うべきか迷わないようにサポートします。 後工程の検討で前工程の見直しが必要になった場合、「どこに戻るべきか」を判断できます。 プロジェクト全体の設計・要件定義を統括するプロジェクトマネージャー・プロダクトマネージャー 分析フェーズをゼロから進める必要がある、新規プロジェクトの推進者 既存プロジェクトの途中から参画し、「どこまで分析できているか」を把握して次を進めたい人 分析のアウトプット（ドキュメント・図面等）を一通り揃えたいが、順序に迷っている人 分析フェーズは戦略→要件定義→機能要件→非機能要件の4段階で、各段階のアウトプットが次の入力になるため順序が重要です。 段階1（戦略）: ビジネスアーキテクチャ分析（analyzing-business-architecture → ビジネスモデルキャンバス・バリューストリーム・ケイパビリティマップ）、インセプションデッキ作成（analyzing-inception-deck → 10の問い回答・概念アーキテクチャ・マイルストーン）。 段階2（要件定義）: RDRA 2.0準拠でシステムコンテキスト→外部環境→境界の順。要件定義（analyzing-requirements → システムコンテキスト・要求モデル・業務フロー）、ユースケース・ユーザーストーリー（analyzing-usecases → ビジネス/システムユースケース・ユーザーストーリー）。 段階3（機能要件）: アーキテクチャが先（analyzing-architecture → バックエンド・フロントエンド・インフラ設計）、その後データ（analyzing-data-model → ER図・テーブル定義）、ドメイン（analyzing-domain-model → エンティティ・値オブジェクト・集約）、UI設計（analyzing-ui-design → 画面遷移図・画面イメージ）。 段階4（非機能要件）: テスト戦略（analyzing-test-strategy → テストピラミッド・種別・カバレッジ目標）、非機能要件（analyzing-non-functional → 性能・セキュリティ・可用性・保守性）、運用要件（analyzing-operation → フロー・監視・障害対応）。 横断工程: 技術スタック選定・ADR作成は随時実施。分析開始前に既存ドキュメント（docs/・docs/design/）を確認し、未着手工程を特定。長時間セッションではコンテキスト圧縮（/compact）を活用。

テスト駆動開発（TDD）の Red-Green-Refactor サイクルに従い、品質の高いバックエンドコードを段階的に実装できます。 インサイドアウトアプローチ（データ層→ドメイン層→API層）で、内側から外側へ構築するため、ドメインロジックのテストが外部依存なしで書け、テスト実行が高速で安定します。 10～15 分で 1 サイクル完了するよう、タスク粒度を自動調整し、フィードバックループを短く保ちながら開発を加速できます。 テスト・ビルド・レビューの品質チェックリスト（コンパイル、テストカバレッジ、コード規約等）を自動実行し、コミット前の品質保証を支援します。 API やサーバーサイド機能を実装しており、後々の変更や拡張に強いコードを書きたい方 テスト駆動開発を導入したいが、進め方や粒度調整が難しいと感じている開発者 Java/Gradle プロジェクトでバックエンド開発を行っており、TDD サイクルを自動化したい方

release_plan.md の内容を GitHub Project・Issue・Milestone に自動反映し、プロジェクト管理を GitHub 上で一元化できます。 カスタムフィールド（リリース、イテレーション、優先度、SP、カテゴリ、Status）を自動設定し、ユーザーストーリーを体系的に管理できます。 ユーザーストーリーから GitHub Issue を自動生成し、受け入れ基準・見積もり情報を含めて管理できます。 release_plan.md と GitHub の差異を検出・同期し、ドキュメント と プロジェクト管理の齟齬を防止できます。 初回の完全同期から、差異検出同期、現在状態確認まで、複数のオプションで柔軟に運用できます。 リリース計画をドキュメントと GitHub で二重管理している開発チーム ストーリーポイント・優先度・イテレーション等の進捗管理を自動化したい PM・スクラムマスター 複数リリースを並行管理し、Issue と Milestone の関連づけを正確に保ちたいプロジェクト GitHub を単一の情報源（SSOT）としたい大規模開発組織 release_plan.md に基づいて GitHub Project・Issue・Milestone を作成・同期。オプション：--project（Project のみ作成）、--issues（Issue のみ作成）、--fields（Issue フィールド値を個別設定）、--milestones（Milestone 作成・Issue 割り当て）、--sync（差異検出・同期実行）、--status（現在状態表示）。Project カスタムフィールド：リリース（Single Select: 1.0 MVP/2.0/3.0）、イテレーション（Iteration: IT-1～IT-6）、優先度（Single Select: 必須/重要）、SP（Number: 2～5）、カテゴリ（Single Select: 認証・マスタ・仕訳等）、Status（Single Select: Todo/In Progress/Done）。Issue 構成：タイトル=[ストーリーID] ストーリー名、本文=ユーザーストーリー・受け入れ基準・見積もり、Project 自動紐付け。フィールド設定手順：フィールド ID・オプション ID 取得→Project Item ID 取得→gh project item-edit で Single Select/Number フィールド値を設定。

複数起動している Node.js 開発サーバーをコマンド一つで一括停止でき、プロセスリセット時間を削減できます。 特定のポート（例：3000番）のみを指定して終了し、他のプロセスへの影響を最小化できます。 --check オプションで現在の起動状況を安全に確認してから終了でき、誤終了を防げます。 ポート競合のエラー（「Port 3000 is already in use」）を素早く解決できます。 ブランチ切り替えやエラー修正後の開発環境クリーンアップを効率化できます。 Windows環境で複数の開発サーバーを運用しているフロントエンド・フルスタック開発者 開発中に「Port already in use」エラーが頻発する環境にいる方 開発環境をリセットしながら作業を進めたい方 プロセス管理を自動化してコマンドライン操作を減らしたい方 Windows環境での開発プロセス強制終了スキル。オプション：なし（全Node.js開発プロセス終了），--port （特定ポートのみ），--check（確認のみ）。一括プロセス終了は netstat -ano | findstr ":300[0-9]" | findstr LISTENING で該当ポート検索，taskkill //F //PID で強制終了。個別ポート指定終了で安全性・精密性・確認機能を備える。出力例：現在ポート3000-3002で起動中のプロセス一覧表示→終了処理→完了通知。連携シナリオ：エラー修正後のリセット、ポート競合解決、ブランチ切り替え前のクリーンアップに対応。ベストプラクティス：作業中のファイル事前保存→--checkで確認→段階的終了→ポート指定で最小限停止→再起動準備。管理者権限が必要な場合あり、Windows環境が前提条件。

FizzBuzz 問題を題材に、Red-Green-Refactor サイクルを 14 言語（Java、Python、TypeScript、Go、Rust など）で実践的に体験できます。 テストを先に書き、その後実装するというテスト駆動開発（TDD）の基本フローを、実際にコードを手で書きながら習得できます。 開発環境の構築から 12 章にわたるチュートリアルまで、完全な教材がすべて用意されており、迷わず進められます。 GitHub Codespaces または WSL を使用した環境で、すぐに開発を始められます。 各言語ごとのプロジェクト構造（ディレクトリ分離）が自動的に整理されるため、複数言語の学習を効率的に進められます。 プログラミング初心者で、TDD の考え方を基礎から学びたい方 特定の言語（Java、Python、TypeScript など）で TDD を実践してみたい開発者 Red-Green-Refactor サイクルの具体的な流れを体験してから本格的なプロジェクトに取り組みたい方 複数の言語でテスト駆動開発を比較学習したい開発チーム 本スキルは docs/article/getting-start-tdd/ に 14 言語 x 12 章の完全な教材を備えており、対話形式でチュートリアルを進行します。チュートリアル開始時は以下の手順に従います：Step 0：開発環境の準備として、ユーザーに環境構築のインストラクションを提示し、合意を得てから進めます（勝手にコマンド実行禁止）。コード配置は apps/{lang}/ ディレクトリ配下に言語ごとに分離し、各言語標準のプロジェクト初期化コマンド（gradle、pip、npm など）をユーザー合意後に実行します。推奨環境は GitHub Codespaces（devcontainer + Nix で言語開発環境即座利用可）です。ローカル環境では、Windows は WSL + Nix、macOS・Linux は Homebrew または Nix での構築が推奨されます。

ビジネスアーキテクチャ分析書の内容から、ビジネスモデルキャンバス（BMC）の SVG 図を自動生成できます。 9つのブロック（顧客セグメント、価値提案、チャネル、顧客関係、コスト構造、収益源、主要活動、主要リソース、主要パートナー）を自動抽出して正確に配置します。 実プロジェクト・企業事例分析の両方のドキュメント形式に対応し、最新の内容を反映した図を更新できます。 テンプレート SVG を基にした統一されたレイアウト（2253 x 1601px）で、プロフェッショナルな図表を生成します。 ビジネス企画・戦略立案を担当している人 ビジネスアーキテクチャ分析が完了し、図で可視化したい人 プレゼンテーション・資料作成で BMC の図が必要な人 ビジネスモデルの全体像を関係者と共有したい人 入力元は 2つ：実プロジェクト向け business_architecture.md または企業事例向け business_strategy.md。セクション見出しは複数パターン対応（「ビジネスモデルキャンバス」「ビジネスモデル」「ビジネスモデル（BMC）」等）。該当セクション内の PlantUML mindmap ブロックから 9ブロックデータを抽出。BMC の 9ブロック（Key Partners・Key Activities・Key Resources・Value Propositions・Customer Relationships・Channels・Customer Segments・Cost Structure・Revenue Streams）と英語名・配置位置を定義したテーブル記載。SVG レイアウト仕様は全体 2253x1601px、上段 5列構成（y=100～1000、列2・4は上下2分割）、下段 2列構成（y=1000～1580、左コスト構造・右収益源）。フォント Helvetica Neue/Arial。

ドライランでCHANGELOG内容とバージョン計算を事前確認できます。 patch / minor / major から選択するだけで、バージョンバンプ・CHANGELOG生成・gitコミット+タグ作成を一括実行できます。 lint・テスト・ビルド・E2Eテストなどのプリフライトチェック（品質ゲート）を自動実行し、全通過時のみリリース可能にします。 Conventional Commits規約に基づいて、コミットメッセージから自動的にCHANGELOGを生成できます。 アプリケーションのリリース作業を確実・高速に進めたい開発チーム セマンティックバージョニングとCHANGELOGを自動管理したい人 リリース前の品質チェックを統一したい組織 npm・Node.jsプロジェクトのリリースフローを標準化したい人 このワークフローは、品質ゲート→バージョンバンプ→CHANGELOG生成→git操作を順序立てて実行します。リリース種別によって semantic versioning（patch=0.1.1, minor=0.2.0, major=1.0.0）を適用します。品質ゲートは「working treeクリーン」「lint確認」「ユニットテスト」「ビルド」「E2Eテスト」を直列実行し、全通過が必須です。CHANGELOG生成は Conventional Commits（feat/fix/docs/refactor等のprefix）に基づいて自動分類し、直近タグからHEADまでのコミットを対象にします。リリース実行は[1/4]バージョン更新→[2/4]CHANGELOG生成→[3/4]git commit + tag（コミットメッセージは「release: vX.X.X」形式）→[4/4]サマリー表示の4ステップで構成されます。オプション（--patch/--minor/--major/--dry-run/--preflight/--deploy）で柔軟に実行範囲を制御できます。

Conventional Commits形式に従い、変更内容を「新機能」「バグ修正」「リファクタリング」などの種類と説明を組み合わせて、意味のあるコミットメッセージが作成できます。 関連するファイルだけを選んでステージングし、1つのコミットに1つの目的を持たせることで、後で変更を追跡しやすくします。 日本語で明確なコミットメッセージを記述するため、将来自分やチームメンバーが「なぜこの変更をしたのか」を素早く理解できます。 コミット履歴が整理されていることで、バグが発生した時に原因となった変更を素早く見つけ出し、ロールバック（取り消し）がしやすくなります。 開発チームでコードを共有しており、他メンバーの変更内容を理解したい人 コミット履歴から変更理由を素早く追跡したい人 ツールの自動化（CI/CDパイプライン）でコミット情報を活用している開発環境にいる人 個人開発でも将来の自分がコード変更の背景を思い出しやすくしたい人 Conventional Commits準拠のGitコミットを作成します。実行手順は、(1)変更確認（git status）、(2)ステージング（git addで対象ファイルを指定）、(3)コミット（git commit -mでメッセージ記述）、(4)確認（git log --oneline）です。Conventional Commitsフォーマットは (): の形式で、typeは feat（新機能）、fix（バグ修正）、docs（ドキュメント変更）、style（空白やフォーマット）、refactor（バグ修正以外のコード変更）、test（テスト追加・修正）、chore（ビルドツール変更）から選択します。注意事項として、コミットメッセージは日本語で記述し、1コミット1目的（構造変更と動作変更を分離）、小さく頻繁にコミット（大きな変更は分割）、テスト通過後にコミット（壊れたコードは含めない）という原則を守ります。

TDD（テスト駆動開発）のサイクルに従い、テスト→実装→リファクタリング→コミットの流れを自動実行するため、コード品質が常に保たれます。 バグ修正や機能追加時に品質チェックを自動で行い、重複コードやマジックナンバーなどの問題を事前に防ぐことができます。 開発タスク完了時に統一されたフォーマットで報告するため、チーム全体で進捗状況や品質基準を共通認識できます。 コンテキスト（情報の背景や状況）を適切に管理し、大規模プロジェクトでも一貫性のある開発を続けられます。 新しいファイル作成やアーキテクチャ変更など重要な判断が必要な場合のみ確認を求めるため、開発がスムーズに進みます。 開発チーム全体で品質基準を統一したい PM やリーダー TDD で体系的にコードを書きたいエンジニア バグの手戻りを減らし、保守性の高いコードを実現したい開発者 大規模プロジェクトで判断基準を明確にしておきたいチーム

ビジネスモデルキャンバスを使い、顧客・価値提案・収益源などをひとつの図で整理できるため、ビジネスの全体構造が一目瞭然になります。 バリューストリーム（価値の流れ）を可視化することで、顧客に価値が届くまでのプロセスを理解し、ボトルネックを特定できます。 ケイパビリティマップ（組織の能力を体系的に整理）を作成し、どの機能に投資すべきかを判断できるようになります。 ビジネスシナリオを策定することで、実際のビジネス課題と期待される結果を具体的に定義でき、その後のシステム要件に正確に反映させられます。 これら分析を通じて「なぜこのシステムが必要か」を明確にするため、本当に価値のある機能だけを開発できます。 新規事業やシステム企画の段階から、ビジネスの構造を整理したい企画・PO データドリブンに組織の能力を見える化し、経営判断に活かしたい経営層・マネージャー ビジネス要件を正確にシステム要件に落とし込みたい要件定義者 投資判断の根拠となる事業構造分析を作成したい経営企画やコンサルタント

概念データモデル→論理データモデルの段階的設計により、ビジネスの言葉で定義したデータ構造を正確にテーブル設計に変換できます。 PlantUML の ER 図（エンティティ・リレーション図）を使い、テーブル間の関係を視覚化するため、設計ミスを事前に発見できます。 正規化（データの重複を排除する技法）を第 3 正規形まで適用し、必要に応じて非正規化を検討するため、パフォーマンスと保守性のバランスが取れたテーブル設計になります。 主キー・外部キーの戦略的な設計により、データの整合性を保ちながら、クエリ効率を最適化できます。 要件定義や業務ロジックに基づいた設計のため、実装時の大幅な設計変更を防ぐことができます。 データベース設計の初期段階から確実に進めたい DB 設計者・アーキテクト ER 図を使い、チーム全体でテーブル構造を可視化したい開発リーダー 正規化とパフォーマンスのトレードオフを戦略的に判断したい DBA・バックエンドエンジニア 実装後の大幅な設計変更を避けたいプロジェクトマネージャー

DDD（ドメイン駆動設計）の戦術的パターンに基づき、エンティティ（ライフサイクルを持つオブジェクト）と値オブジェクト（不変で識別子を持たないオブジェクト）を適切に識別・設計できます。 集約（トランザクション整合性の単位）の境界を最適に定義するため、データベース更新時の競合を減らしながら、ビジネスルールの整合性を保証できます。 ドメインサービス（複数のエンティティにまたがるビジネスロジック）を明確に定義するため、複雑な業務ルールをコードで正確に表現できます。 ユビキタス言語（業務専門家と開発者が使う共通言葉）を整理・可視化するため、「仕様と実装のズレ」を根本から解消できます。 PlantUML を用いたクラス図・オブジェクト図により、ドメインモデルをバージョン管理し、設計変更を追跡可能にできます。 複雑な業務ロジックを「仕様と実装が一致する形」で設計したいアーキテクト・シニアエンジニア DDD の知識を実プロジェクトに適用したい開発チーム エンティティと値オブジェクトの使い分けを学びながら実践したい設計者 ビジネス専門家と開発者の認識を一致させ、品質の高い設計を実現したい PO・要件定義者

10 の問い（なぜやるのか、ビジョン、価値、スコープ、ステークホルダー、解決策、リスク、作業量・費用、トレードオフ、マイルストーン）に回答することで、プロジェクトの全体像をわかりやすく整理できます。 ビジネスアーキテクチャ分析の成果物を活用して、根拠のある意思決定ができるため、プロジェクトの方向性がブレません。 概念アーキテクチャ図と Gantt チャートを PlantUML で作成するため、チーム全体が同じイメージを持って進められます。 スコープやリスク、トレードオフを事前に明確にするため、後工程での計画変更や予算超過を大幅に削減できます。 完成したドキュメントから PowerPoint スライドを自動生成できるため、ステークホルダーへのプレゼンテーションが効率的に進みます。 プロジェクト立ち上げ時に、チーム全体の認識を一度に揃えたい PM・プロジェクトリーダー ビジネス目標と技術的アプローチを同時に整理したい CTO・技術責任者 ステークホルダーに対して、プロジェクト計画を説得力を持って説明したい営業・経営企画 スコープクリープ（計画外の要件追加）を防ぎながら、効率的にプロジェクトを進めたい開発チーム