資格を取らずに知識を証明できないか

資格を取らずに、知識を固められないか。

最近ずっと考えている。特に、プログラミングの基礎と言われる OS、メモリ、ネットワーク、アルゴリズム、数学。20年後も枯れにくい技術。応用可能性の高い領域。

取りたい資格はいくつかある。Kubestronaut、ネットワークスペシャリスト、情報処理安全確保支援士。

ただ、よく考えると、資格そのものが欲しいというより、「この人はその周辺知識を知っている」「実践もできますよ」と短時間で伝わる証明が欲しいのだと思う。資格は説明コストを下げる。初対面で自分の知識範囲を毎回説明するより、一枚の合格証や称号の方が早い。

だから問いは、資格を取るべきかではない。

資格が担っている説明コストの削減を、資格以外で作れないか。

その問いで、12本のdocを書いた。

資格は能力そのものではなくシグナル

資格は能力そのものではない。資格を持っていても実務で弱い人はいるし、資格を持っていなくても強い人はいる。

それでも資格が強いのは、能力が外から見えにくいからだ。

Michael Spence のシグナリング理論では、能力のように直接見えないものを、観測可能な信号で伝える構造が扱われる。資格はまさにそれに近い。受験料、勉強時間、試験日程、失敗リスクを払っているので、「少なくともこの範囲に取り組んだ」という信号になる。

資格が便利なのは、次の機能をまとめて持っているからだ。

機能	意味
範囲の定義	何を学ぶべきかが決まる
到達基準	どこまでできればよいかが決まる
第三者性	自称ではない
検索性	採用や相談で見つけやすい
説明圧縮	長い説明を短くできる

資格なしで知識を証明したいなら、この機能を別の形で作る必要がある。

信頼されるには、知識量だけでは足りない

専門家として信頼されるには、知識量だけでは足りない。

「詳しい人」と「信じてよい人」は違う。技術的な能力、誠実さ、利害の透明性が揃って初めて信頼になる。

たとえば、Kubernetesを使うべきかどうかを相談された時に、「Kubernetes最高です」と言う人より、「今の規模と運用体制ならCloud Runでよく、こういう条件が揃ったらKubernetesを検討する」と言える人の方が信頼できる。

専門性は、答えを知っていることだけではない。

前提を分ける
代替案を比較する
制約を言う
リスクを説明する
分からないことを分からないと言う

資格なしで信頼されるには、この判断の過程を成果物に残す必要がある。

20年後も枯れにくい基礎

資格の周辺知識を調べていくと、結局は基礎に戻る。

Kubernetesは、Linuxのプロセス、namespace、cgroup、ネットワーク、ストレージ、権限管理の上にある。ネットワークスペシャリストは、TCP/IP、DNS、TLS、ルーティング、可用性、運用設計に戻る。情報処理安全確保支援士は、脅威、信頼境界、認証認可、暗号、ログ、監査、リスク管理に戻る。

ツール名は変わるが、下の層は残りやすい。

OS
メモリ
ネットワーク
アルゴリズム
数学
セキュリティ原理

ここを押さえていると、新しい技術を見た時に「これは何の組み合わせか」を考えられる。20年後も枯れにくいのは、特定のコマンドではなく、この分解力だと思う。

3領域でどう証明するか

具体的に、取りたい資格の周辺知識を資格なしで証明するならどうするか。

Kubestronaut

Kubestronautは、CNCFのKubernetes関連認定である CKA、CKAD、CKS、KCNA、KCSA をすべて取得した人に関わる称号として扱われている。

資格なしで補完するなら、Kubernetes lab が必要だと思う。

kindやk3dで複数ノードクラスタを作る
Deployment、Service、Ingress、RBAC、NetworkPolicyを構成する
CrashLoopBackOff、ImagePullBackOff、DNS障害、RBAC不足を再現して直す
kubectl describe、kubectl logs、events、metricsで切り分ける
なぜKubernetesを選ぶか、または選ばないかの設計レビューを書く

「動かした」では弱い。「壊して直した」まで残す。

ネットワークスペシャリスト

ネットワークスペシャリスト周辺知識は、パケットと構成図で証明したい。

DNS名前解決を dig で追う
TCP/TLS/HTTPを tcpdump や openssl s_client で見る
proxy、load balancer、firewall、NATの構成図を描く
通信断を再現し、切り分け順を書く
正常系と異常系のログを残す

「ネットワーク分かります」ではなく、「この通信がなぜ失敗したかをここまで追えます」と見せる。

情報処理安全確保支援士

セキュリティは、攻撃手法の名前を知っているだけでは足りない。

ログイン機能の脅威モデリング
ファイルアップロードの設計レビュー
JWT実装レビュー
Docker image scan
Kubernetes RBACレビュー
インシデント初動runbook
残余リスクの説明

セキュリティでは、「危険です」と言うだけでは弱い。何が、なぜ、どれくらい危険で、どう直すかを書く。

自分の暫定解

現時点の答えはこうだ。

資格は強い。特に初対面では強い。採用、営業、社内異動、技術相談では、資格が説明コストを下げるのは間違いない。

ただし、自分が本当に欲しいのは「資格」ではなく「知識が実践に接続している証明」だと思う。

ならば、やるべきことは資格を否定することではない。資格が持っている機能を分解して、別の証拠で補うことだ。

学習マップ
  何を学ぶか、どこまで学ぶか

実践lab
  壊す、見る、直す、説明する

設計レビュー
  選択肢、制約、リスク、判断を書く

第三者レビュー
  自称から外部評価へ移す

総括記事
  読む人の説明コストを下げる

資格を取るなら、この成果物は合格を実務に接続する補助線になる。資格を取らないなら、この成果物自体が証明になる。

たぶん必要なのは、資格かポートフォリオかの二択ではない。

資格が担っている信頼シグナルを理解したうえで、自分の学習と実践の証拠を、相手が評価しやすい形に整えることだ。

その意味で、資格なしで知識を証明することは可能だと思う。

ただし、資格より楽な道ではない。むしろ、自分で範囲を決め、課題を作り、失敗を残し、レビューを受け、説明可能な形にまとめる必要がある。

資格はショートカットではなく、よく設計された証明システム。

資格なしで行くなら、その証明システムを自分で設計しなければならない。

🐙資格を取らずに知識を証明できないか