市場の課題を見つけ、解決までの過程を商品化するCase Study構想

My Portfolioのコンテンツがある程度整ってきたので、次に取り組むものとしてCase Studyの構想を進めている。

My Portfolioは、これまでに作ったもの、書いた技術記事、職務経歴、学習記録などを、事実として時系列で蓄積する場所として作った。

一方、Case Studyは過去を整理する場所ではない。

市場に存在する課題を自分で見つけ、その課題に対してどのような解決策を考え、設計し、実装し、テストしたのかを見せる場所にしたい。

最初から作るものを決めない

以前は、飲食店の売上データを可視化するダッシュボードをCase Studyとして作る案を考えていた。

しかし、最初から「飲食店向けのダッシュボードを作る」と決めてしまうと、自分が作りたいものを先に作り、その後から課題を当てはめる形になってしまう。

Case Studyで重視したいのは、作ることそのものではなく、課題を見つけるところから始めることだ。

IT LeadersなどのITメディアや、クラウドワークスに掲載されている実際の案件を見ながら、企業や個人が何に困り、どのような作業にお金を払おうとしているのかを観察する。

例えば、次のような依頼が複数見つかるかもしれない。

• 複数のExcelファイルを毎月集計している
• CSVの形式がバラバラで、手作業で修正している
• 請求書や帳票の作成に時間がかかっている
• データはあるが、意思決定に活用できていない
• 問い合わせ内容を人が毎回分類している
• 複数のシステム間でデータを転記している

こうした具体的な依頼や記事から、共通して存在する課題を探していく。

表面的な依頼から、本質的な課題を考える

クラウドワークスに「Excelのデータを集計してほしい」という依頼があったとしても、その依頼をそのまま再現するだけでは弱い。

なぜその集計作業が発生しているのかを一段深く考える必要がある。

例えば、表面的な依頼は次のようなものだとする。

毎月、複数のExcelファイルを一つにまとめて集計したい。

その背景には、次のような業務が存在しているかもしれない。

各部署からExcelファイルが送られてきて、担当者がファイルを開き、列名や日付形式を確認し、不足している項目を修正してから、一つのファイルにまとめている。

この場合、本質的な課題は単なる集計ではない。

データ形式が統一されていないことや、集計前の確認と修正に時間がかかっていることが問題になる。

そこで、次のような解決策を考えられる。

• ファイル形式を自動で確認する
• 不足項目や入力ミスを表示する
• 複数ファイルを一つに統合する
• 集計結果を自動で出力する
• 処理結果を画面で確認できるようにする

Case Studyでは、完成した画面だけでなく、このように課題を掘り下げる過程も見せたい。

Case Studyは仕事の進め方を見せる場所

Case Studyでは、次の一連の流れをコンテンツにする。

1. 市場を観察する
2. 課題の兆候を見つける
3. 誰がどのように困っているのかを整理する
4. 本質的な課題を仮説として定義する
5. 解決策を構想する
6. 要件と設計をまとめる
7. 実装する
8. テストする
9. 結果と投入時間を振り返る

一般的なポートフォリオでは、完成したWebアプリやソースコードが中心になる。

Case Studyでは、完成物だけでなく、どのように課題を理解し、どのような判断を経て形にしたのかを見せる。

技術力だけでなく、仕事の進め方そのものを伝える場所にしたい。

各工程にかけた時間を計測する

Case Studyでは、構想、設計、実装、テストなど、各工程にどれだけ時間を使ったのかも計測する。

例えば、次のような形で記録する。

工程	予定時間	実績時間
市場調査・課題発見	2時間	2時間20分
構想	2時間	1時間45分
要件整理	2時間	2時間30分
設計	4時間	5時間10分
実装	10時間	12時間40分
テスト	3時間	2時間50分
記録・公開	2時間	1時間30分

完成までにかかった合計時間だけでなく、工程ごとに時間を記録する。

これにより、次のようなことが分かる。

• 構想や設計にどれだけ時間を使ったか
• 実装だけに偏っていないか
• 予定と実績にどれだけ差があったか
• どの工程で時間を使いすぎたか
• 次回どこを改善できるか
• 同じ規模の仕事をどれくらいの時間で進められるか

Case Studyを増やしていけば、開発速度だけでなく、見積もり精度の変化も確認できる。

これは自分自身の成長記録にもなる。

時間計測のルール

時間を公開するなら、計測ルールも統一しておく必要がある。

現時点では、次のようなルールを考えている。

• 実際に作業している時間だけを計測する
• 食事、休憩、移動時間は含めない
• ChatGPTと構想や設計を相談した時間も含める
• 技術調査は、設計または実装時間に含める
• 作り直しや修正時間も実績として含める
• 制作期間と実作業時間は分けて表示する

例えば、9日間かけて制作したとしても、実際の作業時間が18時間35分であれば、両方を記録する。

制作期間：2026年7月20日〜7月28日
実作業時間：18時間35分

時間計測のためのアプリを先に作ることも考えられるが、まずはスプレッドシートやCSVで記録する。

時間計測アプリの開発に集中して、Case Study本体が進まなくなることは避けたい。

共通テンプレートを用意する

Case Studyは一つだけ作って終わりではない。

共通のテンプレートを用意し、同じ構成でコンテンツを増やしていく。

テンプレートは、次のような構成を想定している。

課題の発見

• 課題を発見した日
• 情報源
• 観測した事実
• 複数の情報源で共通していたこと
• なぜその課題に注目したのか

課題の定義

• 誰が困っているのか
• 現在どのような作業をしているのか
• どこに時間やミスが発生しているのか
• 表面的な依頼
• 本質的な課題
• 自分が立てた仮説

解決策の構想

• 提案する仕組み
• 想定利用者
• 利用する場面
• 導入前と導入後
• 期待する効果
• 今回は作らない機能

設計

• 業務フロー
• 画面構成
• データ構造
• API
• システム構成
• 技術を選んだ理由
• テスト方針

実装

• 実装した機能
• 工夫した点
• 発生した問題
• 途中で変更した設計
• GitHub
• 公開URL

テスト

• テスト項目
• 正常系
• 異常系
• 境界値
• テスト結果
• 未解決事項

時間と振り返り

• 予定時間
• 実績時間
• 差が発生した理由
• 次回短縮できる工程
• 商品として提供できる範囲
• 今後の改善案

この型を使えば、Case Studyが増えても内容を比較しやすい。

商品メニューを増やすイメージ

Case Studyは、飲食店の商品メニューを増やしていくようなイメージで考えている。

最初から一つの大きなシステムだけを作るのではなく、小規模、中規模、大規模のCase Studyを少しずつ増やしていく。

例えば、次のようなものが考えられる。

• 複数CSVの形式確認と統合
• Excel集計作業の自動化
• 問い合わせ履歴の分類と可視化
• 売上データのダッシュボード
• 勤怠データの異常検出
• 外部APIとのデータ連携
• 請求書や帳票の自動作成

小さなCase Studyであれば、5時間から10時間程度で完成させる。

複数画面やデータベースを含むものは、15時間から30時間程度を想定する。

より実務に近い業務システムは、40時間以上かける。

すべてを大作にしようとすると、コンテンツを増やせない。

小さな課題を短時間で解決することも、十分に価値のある能力だと思う。

お客さんにすべての商品を見せない

Case Studyが増えても、トップページにすべてを同じ大きさで並べるつもりはない。

飲食店のメニューが多すぎると、客は何を注文すればいいのか分からなくなる。

Case Studyも同じだ。

裏側には複数のコンテンツを持ちながら、トップページでは売れ筋の商品だけを尖らせて見せる。

トップページに掲載するのは、基本的に次の3件程度にする。

• 最も自分の強みを表す看板商品
• 市場需要が高い売れ筋商品
• 自分の経験と技術を生かせる商品

その他のCase Studyは、一覧ページから確認できるようにする。

トップページは作品一覧ではなく、「自分がどのような課題を解決できる人なのか」を短時間で理解してもらう場所にする。

技術ではなく、解決する課題を見せる

お客さんが欲しいのは、FastAPIやReactそのものではない。

欲しいのは、次のような結果だ。

• 毎月の集計時間を減らしたい
• 手入力によるミスを減らしたい
• バラバラなデータを一つにまとめたい
• 売上や業務状況を見えるようにしたい
• 問い合わせ対応を整理したい
• 複数システム間の転記作業をなくしたい

そのため、Case Studyのタイトルも技術中心にはしない。

例えば、

FastAPIとReactによる売上ダッシュボード

ではなく、

複数ファイルに分散した売上データを統合し、毎月の集計作業を減らす

というように、解決する課題が伝わる名前にする。

使用技術は詳細ページの中で説明すればよい。

売れ筋は市場の反応から決める

どのCase Studyをトップページに掲載するかは、自分の好みだけで決めない。

次のような基準で評価する。

• 類似する案件や記事が複数存在するか
• 自分の職務経験や技術を生かせるか
• 非エンジニアにも価値が伝わるか
• 他の業界にも応用できるか
• 閲覧数や問い合わせなどの反応があるか
• 面接や商談で話題になるか

反応が良いCase Studyは、トップページで目立たせる。

反応が弱いものは削除せず、一覧ページへ移動する。

そして、反応が良かったテーマの改良版や、別業界向けの展開を作る。

飲食店と同じように、商品を作り、店頭に置き、反応を見て、売れ筋を育てていく。

My PortfolioとCase Studyの役割

My PortfolioとCase Studyは、それぞれ次の役割を持つ。

My Portfolio

これまで何を作り、何を学び、どのような仕事をしてきたのかを、事実として蓄積する場所。

Case Study

市場で見つけた課題に対して、今の自分がどのような価値を提供できるのかを示す場所。

My Portfolioが過去の事実のデータベースなら、Case Studyは市場との接続実験になる。

Case Studyを増やしていくことで、課題発見力、構想力、設計力、実装力、テスト力だけでなく、見積もり精度や開発速度も記録として蓄積される。

完成したアプリを並べるだけではなく、価値を形にするまでの過程そのものを商品にしていきたい。