portfolio-case-study-writer について
portfolio-case-study-writerは、履歴書の箇条書きをポートフォリオ向けの事例にまとめるライティングスキルです。プロダクト、UX、デザインなどの職種を対象に、課題からプロセス、成果、学びまでの構成と、読者に応じた内容調整を案内します。
主な機能
- 01履歴書の箇条書きを事例化
- 02課題・プロセス・成果の構成
- 03技術面とビジネス背景の両立
- 04読者に応じた事例の深さ調整
- 05ポートフォリオサイト向けの形式
活用シーン
- 01プロジェクト経験を事例としてまとめる
- 02UXやPMの仕事の進め方を採用担当者に示す
- 03技術プロジェクトを事例形式で整理する
インストール
コマンドをコピーしてターミナルで実行します。
$
npx skills add https:/ / github.com/ paramchoudhary/ resumeskills --skill portfolio-case-study-writerインストール後、Claude Code で/portfolio-case-study-writerを入力して読み込まれたか確認します。
詳細
ポートフォリオのケーススタディライター
このスキルを使う場面
ユーザーが次のような場合に、このスキルを使います。
- ポートフォリオのケーススタディを作成したい
- 履歴書の箇条書きを、詳細な文章にまとめたい
- ポートフォリオサイトを作成している
- プロジェクトの実績を詳しく紹介したい
- 「ケーススタディ」「ポートフォリオ」「プロジェクトの執筆記事」「業務サンプル」「ポートフォリオ作品」といった言葉を使っている
主な機能
- 履歴書の箇条書きを、詳細なケーススタディに仕上げます
- インパクトを最大化できるよう、ケーススタディを構成します
- 読み応えのあるプロジェクトのストーリーを作成します
- 技術的な詳細とビジネスの背景をバランスよく盛り込みます
- ポートフォリオサイト向けにフォーマットを整えます
- 読者に応じて内容の深さを調整します
ケーススタディの目的
ケーススタディが重要な理由:
- 履歴書では「何をしたか」を示しますが、ケーススタディでは「どのように、なぜ行ったか」を示します
- 結果だけでなく、思考プロセスを伝えます
- スキルをより深くアピールできます
- 他の候補者との差別化につながります
- 多くの PM、UX、クリエイティブ職で求められます
ケーススタディの構成
標準的な構成
1. Overview (Project summary)
2. Problem (What needed to be solved)
3. Process (How you approached it)
4. Solution (What you created/delivered)
5. Results (The impact)
6. Learnings (What you'd do differently)
読了時間
- 短時間で読む場合: 3~5分(ポートフォリオに必須)
- じっくり読む場合: 10~15分(関心のある読者向け)
セクション別ガイド
1. 概要セクション
目的: 読者の関心を引き、背景を伝えます
含める内容:
- プロジェクト名と会社名
- 担当した役割
- 期間
- チームの人数
- 成果を一文でまとめた説明
例:
# Redesigning the Checkout Flow
**Company:** E-Commerce Inc.
**Role:** Lead Product Designer
**Timeline:** 6 weeks
**Team:** 2 designers, 3 engineers, 1 PM
**Summary:** Reduced cart abandonment by 35% through a streamlined 3-step checkout process, generating $2M in recovered revenue.
2. 課題セクション
目的: この取り組みが重要だった理由を説明します
含める内容:
- ビジネスの背景
- ユーザーの課題
- 主要な指標や目標
- 制約条件
例:
## The Problem
E-Commerce Inc. was experiencing 68% cart abandonment—significantly higher than the industry average of 55%. Exit surveys and user research revealed several issues:
- **Too many steps:** Our checkout had 7 screens
- **Forced account creation:** Users had to register before purchasing
- **Hidden costs:** Shipping wasn't shown until step 5
- **Mobile friction:** Forms weren't optimized for mobile
**Goal:** Reduce cart abandonment to below 50% within 3 months.
**Constraints:**
- No changes to existing payment integrations
- Had to maintain PCI compliance
- 6-week timeline before holiday season
3. プロセスセクション
目的: 思考や手法を示します
含める内容:
- 実施した調査
- 関係者
- 立てた仮説
- 検討した選択肢
- 下した決定(およびその理由)
例:
## Process
### Research
I started by understanding the problem deeply:
- Analyzed Mixpanel funnel data for drop-off points
- Conducted 10 user interviews with recent abandoners
- Reviewed heatmaps and session recordings
- Benchmarked against 5 competitor checkout flows
**Key Insight:** 73% of drop-offs occurred at the account creation screen. Users wanted to purchase, not commit to a relationship.
### Ideation
I explored several approaches:
1. Guest checkout only (simplest)
2. Social login options (lower friction)
3. Progressive profiling (collect info over time)
4. One-page checkout (Amazon-style)
After weighing feasibility, timeline, and impact, we chose a hybrid approach...
### Decisions Made
- **Guest checkout first:** Made registration optional and post-purchase
- **Transparent pricing:** Showed shipping on the first screen
- **Mobile-first design:** Designed for mobile, then adapted for desktop
- **Progress indicator:** Added clear "Step 1 of 3" indicator
4. ソリューションセクション
目的: 実際に作成したものを示します
含める内容:
- ビジュアル資料(モックアップ、スクリーンショット、図)
- 主な機能や変更点
- 技術的な実装(関連する場合)
- 課題にどう対処したか
例:
## Solution
### The New Checkout Flow
**Before:** 7 screens with mandatory registration
**After:** 3 screens with optional guest checkout
[IMAGE: Before/After comparison]
### Key Changes
**1. Transparent Pricing Widget**
[IMAGE: Pricing widget mockup]
Showed order total, shipping, and taxes from the start. No surprises.
**2. Guest Checkout Option**
[IMAGE: Guest checkout screen]
Made account creation optional with clear value proposition for why to register.
**3. Smart Form Design**
[IMAGE: Form design]
- Single-column layout on mobile
- Auto-format for phone/card numbers
- Address autocomplete integration
- Clear error messaging
**4. Trust Signals**
Added security badges, money-back guarantee, and customer service contact throughout the flow.
5. 結果セクション
目的: データでインパクトを証明します
含める内容:
- 定量的な結果(期間も記載)
- 目標との比較
- 影響を受けた副次的な指標
- ビジネスへのインパクト
例:
## Results
### Primary Metrics (90 days post-launch)
| Metric | Before | After | Change |
|--------|--------|-------|--------|
| Cart Abandonment | 68% | 44% | -35% |
| Checkout Completion | 32% | 56% | +75% |
| Mobile Conversion | 18% | 41% | +128% |
| Revenue per Visitor | $2.40 | $3.85 | +60% |
### Business Impact
- **$2M additional revenue** in first quarter
- **15% increase in mobile orders**
- **Customer support tickets about checkout** dropped by 45%
### Secondary Effects
- Account creation actually increased 20% (post-purchase)
- Average order value stayed stable
- Return customer rate improved
6. 学びのセクション
目的: 成長する姿勢と自己認識を示します
含める内容:
- うまくいったこと
- 別の方法で取り組むとしたらどうするか
- 想定外の課題
- 習得したスキル
例:
## Learnings
### What Worked
- **Early user research** prevented us from building the wrong solution
- **Cross-functional alignment** meetings kept everyone on the same page
- **Launching with analytics** let us measure impact immediately
### What I'd Do Differently
- **More A/B testing:** We launched the full redesign at once. Would have preferred to test individual changes to understand what drove results.
- **Earlier mobile focus:** We designed desktop-first then adapted. Starting mobile-first would have been more efficient.
- **Stakeholder education:** Spent too long convincing leadership. Would start stakeholder alignment earlier next time.
### Skills Developed
- Advanced Figma prototyping
- Working with A/B testing frameworks
- Presenting data-driven design decisions to executives
役割別のケーススタディの種類
プロダクトマネージャーのケーススタディ
重点項目:
- 戦略と優先順位付け
- ステークホルダーのマネジメント
- 指標と成果
- 技術的なトレードオフ
UX/プロダクトデザイナーのケーススタディ
重点項目:
- ユーザー調査
- デザインプロセス
- ビジュアル資料
- ユーザビリティの改善
ソフトウェアエンジニアのケーススタディ
重点項目:
- 技術アーキテクチャ
- 問題解決へのアプローチ
- システム設計
- コード品質/パフォーマンス
マーケティングのケーススタディ
重点項目:
- 戦略とターゲティング
- クリエイティブの実行
- チャネルのパフォーマンス
- ROIとアトリビューション
ビジュアル要素
必須のビジュアル
- 変更前/変更後の比較
- 主要な画面や成果物
- プロセス図
- 結果を示すグラフ
あるとよいビジュアル
- ユーザージャーニーマップ
- ワイヤーフレームの変遷
- 調査資料
- チームの写真
ビジュアルに関するヒント
- 画像サイズを統一します
- 各画像の内容を説明するキャプションを付けます
- 必要に応じて機密データをぼかします
- モバイル端末でも見やすい画像サイズにします
出力形式
ケーススタディを作成する場合:
# CASE STUDY: [PROJECT NAME]
## Quick Facts
- **Role:** [Your role]
- **Company:** [Company]
- **Timeline:** [Duration]
- **Team:** [Team composition]
- **Impact:** [One-line result]
---
## Overview
[2-3 sentence summary of the project]
## Problem
[Context and challenges - what needed to be solved]
## Process
### Research
[What you learned]
### Approach
[How you tackled it]
### Key Decisions
[Important choices and rationale]
## Solution
[What you built/created - include visual descriptions]
### Feature 1
[Description]
### Feature 2
[Description]
## Results
[Quantified impact]
| Metric | Before | After | Change |
|--------|--------|-------|--------|
## Learnings
[Reflections and growth]
---
## Visual Asset List
[List of images/screenshots needed]
ケーススタディの品質チェックリスト
- ✅ 課題が明確に説明されている
- ✅ ユーザー/顧客を重視していることが示されている
- ✅ プロセスが明確に説明されている
- ✅ 自分自身の具体的な貢献が明確である
- ✅ 結果が数値化されている
- ✅ ビジュアル資料が含まれている
- ✅ 課題や学びについて率直に記されている
- ✅ 適切な長さである(3~10分で読める)
- ✅ 校正され、仕上がりが整っている
- ✅ 面接で詳しく説明できる
コメント
Markdown 対応