ブロックチェーンエンジニアのフリーランス面談でよく聞かれる質問と答え方
公開 2026-11-04 監修：株式会社エージェントベスト
ブロックチェーンエンジニアのフリーランス面談でよく聞かれるのは、チェーンに関わる部分で何を担ったか、なぜチェーンを使ったか、権限と鍵をどう扱ったか、脆弱性をどこで防ぎ何をテストで確かめたかです。面談官は知識の量より、「この人に取り消せない処理を任せて、慎重に進められるか」を見ています。
答えるときは、模範回答を覚えるより、自分が関わった設計とコードの場面を3〜4つ選び、どの質問にもそこから答えられるようにしておくのが近道です。面談全般の答え方は業務委託の面談でよく聞かれる質問と答え方で解説しているので、この記事ではブロックチェーンの面談に固有の質問に絞ります。
面談官が見ている3つの点
ブロックチェーンの案件の面談に出てくるのは、発注元のテックリードやCTO、監査やセキュリティの担当であることが多く、本人もコードを読める人です。そのため、用語を並べるより、判断の理由と、確かめた範囲の線引きが聞かれます。
- 担った範囲：コントラクトの設計か、実装か、周辺開発か、監査か。チェーン以外の経験はどれだけあるか
- 慎重さ：誤りが取り消せない前提で、権限・テスト・公開の手順をどう扱ってきたか
- 説明の力：なぜ安全と言えるか、何は確かめていないかを、言葉と文章で示せるか
以下の質問は、どれもこの3点のどれかを確かめるためのものです。
よく聞かれる質問と答え方の考え方
答えの例は、組み立て方を示すための架空の例です。ご自身の経験に置き換えて準備してください。
1. 「チェーンに関わる部分で、あなたが担った範囲を教えてください」
面談の最初によく聞かれ、話の土台になります。チェーンの種類、使った言語、コントラクトの設計・実装・テスト・公開・運用のどこを担ったか、チームの人数を短く伝えます。周辺のバックエンドが中心だった場合は、最初にそう分けて話すと、後の掘り下げで食い違いが起きません。
架空の例：「公開型のチェーンで、決済の仕組みのコントラクトの実装とテストを担当しました。設計はリードと二人で決め、公開の操作はリードが行っていました。全体の作業の半分ほどは、周辺のAPIの開発です」
2. 「なぜその仕組みにチェーンを使ったのですか。載せなかったデータは何ですか」
チェーンを使う理由を説明できるかと、載せるもの・載せないものを分けて考えられるかを見る質問です。手数料、処理の速さ、記録が誰でも読めることなどを踏まえ、何をチェーン以外に置いたか、両者の食い違いをどう検知したかを話します。「チェーンでなくてもよかった部分」を自分から挙げられると、設計の目が伝わります。
3. 「管理用の権限や鍵は、どう扱っていましたか」
コードと同じくらい重く見られる点です。管理用の権限を誰が持ち、どこに保管し、本番の操作をどの手順で行ったかを話します。自分が鍵に触れない立場だった場合は、それを正直に伝え、手順のどこに関わったかを説明します。権限を一人に集めない工夫や、開発用の端末に鍵を置かない運用を知っているかも見られます。
4. 「脆弱性を、自分のコードのどこで防ぎましたか」
脆弱性の名前を知っているかではなく、具体的な関数や処理でどう防いだかを確かめる質問です。Solidityの公式ドキュメントは、再入やtx.originの使い方などを落とし穴として挙げ、Checks-Effects-Interactionsの順で書くことなどを推奨しています。OWASPのSmart Contract Top 10（2025年版、2026年10月時点）の上位には、アクセス制御の不備、価格オラクルの操作、ロジックの誤りが並びます。こうした項目のうち、自分のコードで実際に問題になりえた点を1〜2つ選び、どこに何を入れ、どのテストで確かめたかを話します。
5. 「テストと検証で、何を確かめ、何は確かめていませんか」
資産を扱う仕組みで特に重く見られる質問です。単体テスト、ランダムな入力を与える検査、成り立つべき性質を決めて確かめる検査など、使った方法と、その方法で確かめた範囲を話します。確かめていないことを言える人ほど信頼される傾向があります。
6. 「公開後に問題が見つかったら、どう対応しますか」
アップグレードできる設計にしたか、止める手段を用意したか、監視と連絡の流れはどうだったかを確かめる質問です。実際に公開後の不具合を経験していれば、気づいたきっかけ、止めるかどうかの判断、利用者への影響の抑え方を順に話します。経験がなければ、関わったプロジェクトで決めていた対応の手順を説明します。
7. 「監査やレビューの指摘に、どう対応しましたか」
指摘を受けた経験は評価の材料になります。どんな指摘があり、どう直し、直したことをどう確かめたかを話します。受け入れなかった指摘があれば、その理由を説明できると判断の質が伝わります。監査を担う案件の面談では、立場を逆にして「どう指摘を書くか」を聞かれます。
8. 「チェーンの外のシステムとは、どうつないでいましたか」
周辺開発の力を見る質問です。取引の送信と確定の確かめ方、確定を待つ間の画面の表示、失敗したときの再送、データの集計と監視をどう設計したかを話します。チェーンの仕事の多くは周辺開発を含むため、ここで具体的に話せると参画できる案件の幅が広がります。
準備は「判断の場面」を3〜4つに絞る
- 場面を選ぶ：権限の設計、脆弱性への対応、テストの方針、公開や公開後の対応など、性質の違う場面を選ぶ
- 場面ごとにメモをつくる：状況、選択肢、選んだ理由、確かめた方法、確かめていないこと、結果を書き出す
- 規模と版をそろえる：チェーンの種類、言語とその版、チームの人数、期間を、どの場面でも同じ内容で言えるようにする
- コードの説明を一言にまとめる：画面共有を求められても、どの関数で何をしたかを短く話せるようにする
- スキルシートと照らし合わせる：シートに書いた担当範囲と、話の内容が一致しているかを確かめる
シートの書き方はブロックチェーンエンジニアのスキルシートの記事、冒頭の自己紹介は面談の自己紹介の記事で解説しています。
ブロックチェーン案件ならではの逆質問
逆質問は、印象づくりより参画後のずれを防ぐ確認に使います。
- 仕事のうち、コントラクトと周辺開発の割合はどのくらいか
- 管理用の鍵や本番の操作は誰が担い、自分はどこまで関わるか
- 外部の監査を受ける予定と、その時期
- テストと検証の方針、使っている道具
- 公開後の監視と、障害時の連絡や待機の体制
一般的な逆質問の考え方は業務委託の面談で聞いておくべき逆質問にまとめています。聞いた内容は、契約前の確認にもそのまま使えます。確認点はブロックチェーンエンジニアの案件の選び方で整理しています。
よくある質問
ブロックチェーンの実務が短いのですが、面談で何を話せばよいですか？
チェーンの経験とそれ以前の経験を分け、土台になるバックエンドやセキュリティの経験をしっかり話します。チェーンについては、短くても自分で判断した場面を一つ選び、何を確かめたかまで説明できれば十分な材料になります。
面談でコードを書く課題が出ることはありますか？
案件によっては、既存のコードを見せられて問題点を挙げる、短いコントラクトを読んで説明する、といった形で確かめられることがあります。その場で完璧に答えることより、どこを疑い、何を確かめたいかを順に話すことが大切です。
個人で公開したコントラクトの話をしてもよいですか？
補足として話すのはよいことです。ただし、業務の経験と同じ重さでは見られにくいため、テストを整えたか、何を学んだかを添えて短く話しましょう。面談で見送られやすい理由は面談で見送られる理由の記事で解説しています。
参考にした公的情報・資料
記事の内容は公開日時点の情報にもとづきます。制度や税率は変わることがあるため、手続きの前に必ず各機関の最新情報をご確認ください。