知識証明ポートフォリオの設計

ポートフォリオは作品集では足りない

資格の代わりにポートフォリオを作る、という発想は自然だ。

ただし、作品を並べるだけでは資格の代替になりにくい。読む側は「何を見れば何が分かるのか」を判断しなければならない。これでは説明コストが下がらない。

知識証明ポートフォリオは、作品集ではなく証拠の束として設計する。

トップREADME

トップREADMEの役割は、読む人の時間を節約すること。

入れるもの:

自分が証明したい能力
対象領域
主要成果物へのリンク
それぞれが示す能力
第三者レビューの有無
未検証領域

例:

領域	成果物	示す能力
Kubernetes	k8s failure labs	運用・障害切り分け
Network	packet debugging notes	DNS/TLS/LBの切り分け
Security	threat modeling reports	設計段階のリスク分析
Foundation	OS/memory notes	現象を基礎から説明する力

読む側が3分で全体像を掴めるようにする。

各成果物の型

成果物ごとに、同じ型を使う。

# Title

## What this proves
この成果物が示す能力

## Scenario
実務に近い問題設定

## Constraints
制約、前提、対象外

## Evidence
コード、構成図、ログ、スクリーンショット

## Decisions
判断と代替案

## Review
受けたレビュー、修正履歴

## Limits
まだ証明できていないこと

型が揃っていると、資格のように比較しやすくなる。

証拠の種類

強い証拠は一種類ではない。

証拠	示すもの
コード	実装力
設定ファイル	インフラ理解
構成図	全体設計
実行ログ	再現性
障害メモ	切り分け力
設計ADR	判断力
レビューコメント	第三者性
登壇資料	圧縮して伝える力

資格なし証明では、特に実行ログとレビューコメントが効く。完成物だけではAI生成物と区別しにくいが、時系列の試行錯誤は本人の理解を示しやすい。

第三者レビューを入れる

自分一人で作った証明は、どうしても自称に近い。

第三者性を入れる方法:

GitHub PRレビュー
Issueでの質問回答
勉強会での発表
メンターや同僚のレビュー
OSSへの小さな貢献
ブログコメントへの追記

レビューを受けたら、指摘への対応も残す。間違いを直せることは、信頼の証拠になる。

更新と期限

資格には更新がある。ポートフォリオにも更新ルールが必要だ。

Kubernetes lab: 半年ごとにバージョン確認
Security report: OWASPやCVE動向に応じて更新
Network lab: 利用ツールとクラウド構成を更新
基礎知識: 新しい記事から既存ノートへリンク

古い成果物でも、古いと明記されていれば信頼を損ねにくい。危険なのは、いつの知識か分からないことだ。

この知識はどう証明できるか

最終成果物として、次を作る。

proof-of-skill リポジトリ
トップREADME
kubernetes/, network/, security/, foundation/ の4領域
各領域にlab、設計レビュー、検証ログを置く
ブログ総括記事から全体にリンクする
レビューを受けたPRを残す

資格を一枚の証明書とするなら、これは「監査可能な証拠ファイル」になる。