k2f-case-study

K2F ケーススタディ — AI ネイティブな美的デザイン

目的

レイアウトを始める前に、エージェントがケーススタディの設計図を作成できるようにします。履歴書の内容を繰り返すのではなく、仕事がどのように、そしてなぜ行われたのかを示し、誠実な範囲設定、根拠に裏付けられた成果、流し読みする読者を惹きつけ、じっくり読む読者にも応える階層構造を実現します。

K2F を基盤とする

このスキルでは、.K2F パッケージとしてケーススタディを作成します。作成時は k2f スキルに従ってください。ワークスペースを展開または初期化し、セマンティックツリーを編集して、pack/verify を実行した後、エクスポートします。K2F により、エージェントはピクセル座標ではなく、意味（セクションの役割、ストーリーの展開、ビジュアルのプレースホルダー）に集中できます。その一方で、エンジンがレイアウト、タイポグラフィ、テーマをコンパイルし、PDF、PPTX、DOCX などの各形式で一貫した出力を生成します。

作成を始める前に、コアスキルをインストールします。npx skills add suzheng/k2f --skill k2f。

使用する場面

• 箇条書きやスライド資料を、ポートフォリオや面接で使えるプロジェクトストーリーに発展させるとき。
• 営業、マーケティング、経営層向けに、クライアントや社内での成功事例を記録するとき。
• 一から書き直すことなく、PM、デザイン、エンジニアリング、マーケティングの各観点に合わせて、同じプロジェクトの強調点を調整するとき。

ワークフロー

ステップ 1. content_and_design.md を作成する

セマンティックなコンテンツと美的な意図をまとめた設計図を作成します。ラベル付きブロックを使用すると、後で k2f スキルによってセクションやビジュアルに対応付けられます。

サブステップ

1. ストーリーの基本方針 — 主な読者（採用担当者の流し読み、採用マネージャー、クライアント候補）、目標とする読了時間（重要な情報に絞った 3〜5 分の経路と、任意の詳細を含む 10〜15 分の経路）、そして関心を引く成果を 1 つ決めます。ユーザーから提供された情報を列挙し、指標、引用、成果物は捏造せず、不足箇所として明示します。

2. 役割の明確化 — 自分の肩書き、チームの人数、期間、担当範囲、自分の貢献とチーム全体の成果を整理します。貢献に関する主張は一人称で書き、チームが担った領域は明確に示します。

3. 情報設計 — 標準的な構成（流し読みだけを想定する読者には短縮します）：

   • ヒーロー／要点：プロジェクト名、関心を引く指標や成果、役割、期間、チームを、ひと目で把握できるメタデータ欄にまとめます。
   • 概要：何を実現し、なぜ重要だったのかを 2〜3 文で説明します。
   • 問題／課題：ビジネスの背景、ユーザーや顧客の悩み、目標、制約を説明し、なぜ取り組む価値があったのかを示します。
   • プロセス：調査と発見、検討した選択肢（幅広さ）、意思決定とその根拠（深さ）、フィードバックやテストに基づく反復を説明します。すべての会議を日記のように記録するのではなく、方向転換や洞察を際立たせます。
   • ソリューション：リリースしたものを順を追って説明します。主要な機能や成果物を、明示した課題と結び付けます。ビジュアルがストーリーを伝える箇所（ビフォー／アフター、フロー、アーキテクチャ図）も示します。
   • 成果／インパクト：期間と基準値を添えた定量的な成果、定性的な兆候、ビジネスへの影響を示します。任意で「今なら違うやり方をする点」も記載します。
   • 振り返り（ポートフォリオでは任意）：得た学び、伸ばしたスキル、その後の仕事への影響を記します。
   • ビジュアル素材一覧：予定している画像ごとに、キャプションの意図、機微情報を隠す加工、必須か、あるとよいものかを記載します。

4. 読者に応じた重点調整 — 事実を変えずに説明の深さを調整します。PM／戦略では優先順位、トレードオフ、指標を重視し、デザイン／UX では調査、反復、ユーザビリティを重視し、エンジニアリングではアーキテクチャ、制約、パフォーマンスを重視し、マーケティングではオーディエンス、クリエイティブ、ROI を重視します。ストーリーの基本方針に合わないセクションは削除します。

5. デザインの意図 — エンジンのトーン、階層、密度、配色を文書化します。

   • トーン：信頼感のあるストーリーテラー。根拠が乏しい部分では控えめかつ具体的にし、誇張やありきたりな「情熱」で埋めません。
   • 階層：ヒーローと概要では最も重要な成果を冒頭に示します。プロセスの小見出しでは 判断 と 洞察 を前面に出し、結果では数値を視覚的な基点として使います。
   • 密度：短い段落と箇条書きを使い、1つのブロックにつき1つの考えに絞ります。指標の前後比較には表を使い、長い手法の説明は任意の小見出しにするか、付録に回す前提で扱います。
   • 視覚的なリズム：ストーリーのブロックと図の役割を交互に配置します。洗練されたスクリーンショットを1枚だけ見せるのではなく、変遷（スケッチ → 反復 → 最終版）を重視します。ブループリントでは図のサイズと説明的なキャプションを統一します。
   • 配色：すっきりとしたポートフォリオまたはエディトリアル調にします（本文はニュートラルカラー、指標とコールアウトにはアクセントカラーを1色使用）。WCAG AA に準拠し、ユーザーやステークホルダーの声を伝える引用は控えめに使用します。

ルールと制約

• 成果だけでなく思考を示す：主要な解決策の各ブロックを、明示した問題または洞察に結び付けます。
• エビデンスの段階：事実（ユーザーデータ）、解釈（その読み取り）、予測（期待される影響）を分け、推測を結果として扱わないでください。
• プロセスの比重：判断力を示すのに十分な内容を含めます。判断や学びにつながらない形式的な手順は省きます。
• 貢献の正確さ：面接で使う成果物では「私たち」のような曖昧な表現を避けます。チームで担った成果を個人の手柄として語らないでください。
• 読み飛ばしへの対応：ヒーロー＋問題＋結果を読んだところで止めた読者にも、価値が伝わるようにします。

よくある失敗

• 物語の流れがない履歴書の箇条書きの貼り付け → 問題の重要性と判断の節目を加えます。
• 「それが何を意味するのか」のない解決策の一覧 → 各成果物を課題または指標に結び付けます。
• プロセスの百科事典化 → リサーチから得た洞察、選択肢のトレードオフ、選んだ道筋に絞ります。
• 結果がない、または曖昧 → データがある場合は定量化し、ない場合は NEEDS USER INPUT と明記します。
• チームの物語の中で貢献が区別されていない → 「私は主導した／構築した／検証した」の境界を明確にします。
• 最終版のモックアップしかない → アセット一覧に、変更前後や反復を示す図を含めます。
• 汎用的なケーススタディの長さ → チャーターに応じた深さに調整します。読者が見込み顧客で、1つの成功事例を流し読みしている場合は、振り返りを削ります。

品質チェックリスト

• チャーターに対象読者、読む深さ、成果を引き立てる導入が記載されています。
• ヒーローの事実は概要および結果と一致しており、指標に矛盾がありません。
• 問題に目標と制約が明記され、解決策がそれらに明確に対応しています。
• プロセスに、理由を伴う判断が少なくとも1つと、反復またはテストの兆候が少なくとも1つ含まれています。
• 結果では測定値と推定値が区別され、期間とベースラインが明記されています。
• ビジュアルアセット一覧に、ストーリーの重要な節目がキャプションの意図とともに含まれています。
• デザインの意図に、ヒーロー、結果、図のリズムに関する階層が指定されています。

ステップ 2. content_and_design.md と k2f スキルを使って K2F ファイルを生成し、適切なファイル形式でエクスポートします。

k2f に従い、ブループリントからセクションと図の役割を作成し、デザインの意図を適用して検証したうえで、対象読者向けのケーススタディをエクスポートします。