ポートフォリオの作品すべてを、詳しいケーススタディにする必要はない

ポートフォリオにスクリーンショット、デモ、技術タグがいくつかあれば、作品を知ってもらう入口にはなる。ただ、詳しいケーススタディにするには、別の問いにも答える必要がある。なぜ作ったのか、どのような制約のもとで選択したのか、そして確認できる結果として何が残っているのか。

どの作品にも、その材料がそろっているわけではない。足りない部分を調べ直すことも、記事の範囲を狭めることもできる。ケーススタディのひな型に「課題」と「成果」の欄があるからといって、記録のない物語で埋めてはいけない。

このサイトの作品とノートを整理するときは、まず素材がどの種類の内容を支えられるかを考え、そのあとで記事にするかを決めている。プロダクト開発の物語が一通りそろわなくても、作品は展示しておける。

作品カードとケーススタディでは、答える問いが違う

このサイトの開発作品カードには、タイトル、日付、サムネイル、技術タグ、デモへのリンクがあり、一部にはソースコードへのリンクもある。デザイン作品とAIGC画像はギャラリー形式で見せている。これらは現在のページが提供している展示方法であって、すべての作品に要件のヒアリング、意思決定の過程、公開後の効果が整理されているという意味ではない。

カードは、読者が作品をすばやく把握し、開いてみるかを決めるのに向いている。ケーススタディでは、そこから一歩進んで、ある選択を説明する必要がある。当時どんな問題があり、どの条件を考慮し、なぜその方法を取ったのか。

同じ画面をどちらにも載せられるが、役割は異なる。カードでは作品を見分けるために使い、ケーススタディでは情報の順序や操作の違いを説明するために使うことがある。カードのタグを長い文章に言い換えただけでは、記事は長くなっても根拠は増えない。

まず、手元の素材でどこまで説明できるかを見る

このサイトの作品データには、1ページ構成のテンプレートや、名前にUIテンプレートと明記された作品が含まれている。そうした名称と展示内容は、実装範囲を紹介する出発点にはなる。ただし、実際のクライアント、運用中のデータ、完成したバックエンドサービスが存在すると、そのまま推定することはできない。

たとえば管理画面の画像があれば、情報の見せ方については議論できる。ログイン、保存、複数ページにまたがる操作を完了できるかは、実装と実際の動作を別に確認する必要がある。デモを開けたとしても、その入口があるだけで、全機能をテスト済みとは言えない。

画像作品も同じだ。既存の画像から構図や表現は見てもらえるが、デザインのケーススタディを書くには、根拠のある用途、制約、取捨選択が必要になる。完成画像から記録のない提案過程を推し量ることはできず、生成画像を、裏付けのないままクライアントへの納品物として説明してもいけない。

ここではすべてのデモを一件ずつ審査しておらず、未確認の外部プロジェクトについて機能の判定もしていない。展示用の情報で説明できる上限が分かれば、次にどのような根拠を補うべきかが見えてくる。

題材を選ぶときは、説明できる決定を一つ探す

詳しいケーススタディでも、プロダクト全体を扱う必要はない。残っている資料で一つの問題しか説明できないなら、その問題に絞ればよい。

以下は素材を選ぶための提案であり、このサイトの作品に開発の経緯を付け足すものではない。

手元にある素材	検討できる内容	そのままでは主張できないこと
画面と、確認できるレイアウトの実装	特定のUI構造に関する実装ノート	ユーザーの操作効率が向上したこと
変更前後のバージョンと、記録された取捨選択	フローや情報の順序を変えた理由	リニューアルによる事業上の成果
実際の入力、変換ルール、出力	一連のデータ処理を扱うケーススタディ	あらゆるデータ形式への対応
完成画像のみで、過程の資料はない	作品展示と素材の説明	調査、提案、反復改善が一通り行われたこと

私はまず「この記事はどの決定を説明するのか」を一文にし、それを支える素材を探す。その一文が書けないときは、背景、課題、解決策、成果という固定の章立てに急いで当てはめない。

最終的に適しているのは、プロダクトのケーススタディではなく、範囲を絞った技術ノートかもしれない。作品に明確な説明を一段落添えるだけでよい場合もある。内容の形式は小さくしてよく、主張の範囲もそれに合わせて狭める必要がある。

成果の欄には、無理に数字を探さず観察できる結果を書く

効果を示す数値がないからといって、何も書けないわけではない。実際の記録があれば、どのような出力が得られたか、どの操作経路を完了できたか、どんな制約が残っているかを説明できる。

ただし、出力と影響は区別しなければならない。サイトが静的ページを生成できても、検索順位が改善したことにはならない。ツールが一組のデータ変換を完了できても、日常業務で何時間節約できるかは分からない。UIがグラフを表示できても、そのデータソースを検証済みとは限らない。

これらは判断のための例であり、このサイトの作品を新たに計測した結果ではない。確認できる数字がないときは、もっともらしいパーセンテージを補うより、実際に確かめた結果をそのまま書くほうが役に立つ。

結果そのものさえ再確認できていないなら、展示のままにしておくか、記事では実装の一部分だけを扱うと明記できる。ケーススタディのひな型に合わせるために、手元の根拠を超えた内容にする必要はない。

公開できるかどうかは、別に確認する

資料がそろっていても、そのまま公開に適しているとは限らない。整理を始める前に、画面、データ、人物、協業に関する内容が、書いてよい範囲に収まっているかを改めて確認する必要がある。

記事の中心となる判断を理解するために、公開できない内部記録が欠かせないなら、その詳細に触れずに済む狭い問題へと書き換えるか、記事化を見送る。私的な会話や内部の引き継ぎ内容を、読者がすでに知っている背景として扱ってはいけない。

名前を削除すれば何でも公開できるわけではない。説明用のデータを作り直す場合は、そのことを明記し、説明用の画面が実際の成果に見えないようにする。ここで行うのは執筆前の範囲確認であり、特定の作品について許諾、契約、法的権利を判断するものではない。

長いケーススタディに向かなくても、よい展示は残せる

素材を選ぶ際は、候補となる作品ごとに四つの問いへの答えを残すとよい。説明したい決定は何か、公開できる根拠は何か、読者が持ち帰れる判断は何か、そして何の資料がまだ足りないのか。

完成品しかないなら、まず展示の説明を正確にする。明確に説明できる実装の一部分があれば、その部分を書く。要件、過程、結果をすべて確認できるようになってから、詳しいケーススタディに適しているかを考えればよい。これは編集の順序であり、作品の良し悪しの順位ではない。

作品カードとノートについての記事では、それぞれの入口が何を提供するかを扱い、開発記録を方法に変える記事では、記事の組み立て方を扱っている。この記事で補うのは、その前の選別だ。すべての作品を同じ語りの形式に収める必要はない。

新しいインタビュー、ユーザー調査、効果測定がないときに、展示を維持することはケーススタディの失敗ではない。いま書かない理由は、資料が足りないことや公開範囲が未確認であることでよい。完成した物語を使って、その空白を隠すべきではない。