ブロックチェーンエンジニアのスキルシートの書き方｜面談で評価される実績の見せ方

ブロックチェーンエンジニアのスキルシートは、チェーンに関わる実務期間を他の経験と分けて書き、どの領域で、どのチェーンと言語を使い、権限の設計や検証、公開と運用にどう関わったかを示すのが基本です。読み手は、コードを書けるかより、資産や記録を扱う仕組みを慎重に進められる人かを見ようとします。

全体の構成はスキルシートの基本で解説しています。この記事では、ブロックチェーンのエンジニアが書くときに押さえたい点に絞って説明します。

チェーンの期間と、土台の経験を分けて書く

よく見るのが「Web開発8年（ブロックチェーン含む）」のように経験をまとめる書き方です。これでは、チェーンに関わった期間も、どの領域の経験かも分かりません。

スキル一覧の冒頭には、「公開型チェーンのスマートコントラクト」「Web3サービスの周辺開発」「企業向けの分散台帳」「監査・レビュー」のどれの経験かを書いておきます。領域によって読み手が見たい経験が違うためです。

使ったチェーン、言語、版を書く

チェーンの種類（公開型か許可型か、どの基盤か）、言語、主なライブラリを書きます。Solidityの公式ドキュメントでは、Solidityは0.y.zの形で版を付けており、破壊的な変更が定期的に入ること、公開時には最新の公式リリースを使うべきことが説明されています。Solidityの公式ブログによると、2026年10月時点の最新は0.8.38（2026年10月22日公開）です。シートには、担当したプロジェクトで使っていた版の範囲を書いておくと、どの時期の書き方に慣れているかが伝わります。版の更新を担当した場合は、その旨も添えます。

「なぜチェーンを使ったか」と「何を担ったか」を書く

プロジェクト欄には、チェーンを使った理由を一行で書くと、経験の意味が伝わりやすくなります。

• 使った理由：複数の会社で記録を共有するため、改ざんを検知するため、利用者が資産を自分で管理できるようにするため など
• 担ったもの：コントラクト、周辺のAPI、データの集計、管理画面、検証環境、監視 など
• チェーンの外の部分：既存のシステムの言語や基盤と、自分がどこまで触ったか

チェーンに載せるデータと載せないデータを分けた判断に関わった場合は、その理由も一言添えます。個人情報を載せない設計や、手数料を抑えるために記録をまとめた工夫などは、設計を任せられる人かどうかを読み手が判断する材料になります。

権限・検証・公開への関わり方を正確に書く

ブロックチェーンのシートで、読み手が特に注意して見るのが、権限の設計、検証、本番への公開の行です。関わり方の深さを書き分けます。

1. 方針を決めた：権限の分け方、アップグレードの方式、検証の計画を決めた
2. 実装した：決まった方針に沿って、権限の確認やテストを書いた
3. レビューした：他のメンバーの変更や、外部監査の指摘への修正を点検した
4. 手順に沿って操作した：決められた手順と承認のもとで公開や設定の変更を行った

どの深さでも経験として書いてかまいません。チームで決めたことを自分が決めたように読める書き方は、面談で判断の理由を聞かれたときに説明できず、他の記載まで疑われる原因になります。

監査やレビューの指摘への対応

外部監査や内部レビューの指摘に対応した経験は、書き方次第で強みになります。指摘の中身を細かく書く必要はありません。OWASPのSmart Contract Top 10（2025年版）にあるアクセス制御、入力値の検証、再入といった分類の言葉を使って「どの種類の指摘に、どう対応し、再発をどう防いだか」を書くと、守秘義務に触れずに経験の深さを伝えられます。

監査を担当した場合

監査やレビューを仕事として担った場合は、対象の規模（コントラクトの数や行数のおおよそ）、使った手法、報告書のどこまでを書いたか、開発者への説明に関わったかを書きます。対象のサービス名や見つけた脆弱性の詳細は、公開されている場合でも、書いてよい範囲を確かめてから扱いましょう。

運用と更新の経験も行として書く

コントラクトを書いた経験に加えて、公開後にどう見守り、どう更新してきたかも見られます。プロジェクト欄の「環境」に技術名を並べるだけでなく、次のような内容を一行ずつ書き出すと伝わります。

• 異常な取引や処理の止まりを検知する監視を設けていたか、その設定に関わったか
• 言語の版や依存するライブラリの更新を、誰がどの間隔で行っていたか
• 基盤のアップグレードに合わせて、周辺のサービスを見直したことがあるか
• 公開や設定の変更の手順書を作ったり、直したりしたか

資産を扱う仕組みでは、作った人より、安全に動かし続けた人が重く見られる場面があります。運用の経験は短くても書いておきましょう。

成果は「何を防いだか」と一緒に書く

「コントラクト開発を担当」だけではほとんど伝わりません。次の順で書くと、判断の流れが読み取れます。

1. 何が課題だったか：権限の集中、手数料の高さ、集計の遅れ、記録の食い違いなど
2. どう確かめたか：テスト、検証用のネットワーク、レビュー、監査
3. 何を変えたか：権限の分け方、処理の分割、集計の仕組み
4. どう変わったか：前後の比較

社外に出せない数値は、「集計の待ち時間がおおむね数分から数秒に」のように相対的な表現で十分です。書いてよい範囲はスキルシートと守秘義務の記事をご覧ください。

プロジェクト欄の記入例（架空）

次は書き方の型を示すための架空の例です。実在の案件・企業・人物ではありません。業種や規模はぼかしてあります。ご自身の経験に置き換えてください。

期間：○年○月〜○年○月（1年程度）
案件概要：複数の会社の間で取引の記録を共有する仕組みの開発（架空の例）
規模・立場：開発メンバー数名のうち、チェーン部分を担当する2名の1人
チェーンを使った理由：会社ごとに記録が食い違い、突き合わせに手間がかかっていたため
担当工程：要件の整理の一部、設計、実装、テスト、公開後の保守
担ったもの：記録を登録・参照する処理、既存システムから呼び出すAPI、参加組織ごとの権限の設定
権限・検証：権限の設定を実装（参加組織ごとに見られる範囲を分ける方針はチームで決定）。テストの追加と、検証環境での動作確認を担当
環境：許可型の分散台帳、Go、コンテナ、自動テスト
工夫・成果：既存の記録と新しい記録を並べて比べる仕組みを作り、段階的に切り替えた。切り替え後、会社間の突き合わせの作業がおおむね半分以下に

この例では、チェーンを使った理由、担った範囲、権限への関わり方、成果と確かめ方が一度に読み取れる形にしてあります。

公開の成果と、取引の経験の扱い

公開したコントラクトやOSSへの修正は、何を解決するものか、テストが整っているかを添えて補足として載せます。扱い方はポートフォリオやGitHubの記事で解説しています。一方、自分の資金での取引や保有の経験は、開発の実務経験とは別のものです。シートには載せず、開発と運用で担った仕事に絞りましょう。

よくある質問

チェーンの実務が1年未満です。他の経験と混ぜて書いたほうがよいですか？

混ぜずに分けて書くほうが、結果として伝わりやすくなります。チェーンの期間が短くても、土台の経験が長ければ、その強みは別の行で示せます。チェーンで担当した範囲を具体的に書くことで、短い期間でも中身が伝わります。

社内の検証で終わったプロジェクトは書けますか？

書いてかまいません。何のためにチェーンを使おうとし、どこまで進め、なぜ本番に進まなかったかを書けば、技術を選ぶ判断に関わった経験として伝わります。見送りの理由は、守秘義務の範囲で一般化して書きましょう。

面談で聞かれやすい点に、シートでどう備えればよいですか？

権限の設計や検証への関わり方は、面談で掘り下げられることが多い部分です。各行について、なぜそうしたか、何は確かめていないかを一言で説明できるか確かめておきましょう。面談全般の準備は面談でよく聞かれる質問の記事をご覧ください。