技術顧問・CTO代行のスキルシートの書き方｜面談で評価される実績の見せ方

技術顧問・CTO代行のスキルシートは、案件ごとに会社の段階と規模、関わり方の型、自分が決めたこと、その後の結果をそろえて書くと伝わります。読み手の発注側は、「うちと同じ段階の会社で、同じ困りごとに対して、どんな判断をしてきた人か」を見て判断するからです。

技術顧問の仕事は形に残る成果物が少なく、使った技術を並べるだけでは働きが伝わりません。この記事では、成果が見えにくい仕事を書くときの型と、架空の記入例を紹介します。基本の構成はフリーランスのスキルシートの書き方をご覧ください。

案件ごとに書く項目をそろえる

技術顧問の経歴は、案件ごとに次の項目をそろえると、読み手が比べやすくなります。

最も大切なのは「決めたこと」と「その後」です。技術顧問を依頼する会社は、判断の質を買っています。決めた中身と結果が書かれていると、面談で深く聞いてもらえる材料にもなります。

肩書きではなく役割で書く

「CTO」「技術顧問」「VPoE」などの肩書きは、会社によって中身が違います。肩書きだけを書くと、読み手は担っていた範囲を推測するしかありません。「開発チーム12名の技術方針と採用の責任者」のように、範囲と人数で書き添えましょう。

肩書きがCTOでなくても、技術の責任者に近い判断を担っていたなら、その判断を書けば伝わります。逆に、肩書きがCTOでも、実際には実装が中心だった場合は、その実態を書いたほうが、合わない案件に入るのを防げます。

記入例（架空）

以下は説明のために作った架空の例です。実在の会社や人物とは関係ありません。

記入例1（架空）：成長期の会社での実務型

• 期間・関わり方：1年2か月、週3日の実務型（業務委託）
• 会社の段階・規模：成長期のWebサービス会社、従業員約80名、開発チーム約15名
• 困りごと：開発チームが一つの大きな塊になっており、リリースの遅れと障害が増えていた
• 担った領域：開発体制、リリースの仕組み、採用
• 決めたこと：
• 開発チームを事業の機能ごとに3つに分け、それぞれに技術の判断を担う担当者を置いた
• リリースの手順を自動化し、レビューの基準を文書にまとめて全チームでそろえた
• 採用の評価基準を作り、面接官どうしで評価をすり合わせる場を設けた
• その後：リリースの回数が増え、障害の振り返りを毎回行う運用が定着した。一方、チーム間で共通部品の持ち主があいまいになったため、半年後に共通部品を担うチームを追加した

記入例2（架空）：創業期の会社での助言型

• 期間・関わり方：8か月、月2回の定例と、チャットでの相談（平日日中のみ）
• 会社の段階・規模：創業期、従業員約10名、エンジニア2名
• 困りごと：最初の開発を外部の会社に任せていたが、社内で開発を続ける体制に移りたい
• 担った領域：技術選定、採用、外部の開発会社からの引き継ぎ
• 決めたこと：
• 社内で扱いやすい構成に移す範囲と、当面は既存のまま使う範囲を分けて経営陣に提案した
• 1人目の正社員エンジニアの求人票の技術要件を書き、技術面接を担当した
• その後：引き継ぎを終え、社内のエンジニアが開発を続ける体制になった。採用の技術面接は、社内のエンジニアに引き継いだ

記入例2のように、助言型の案件では、会議の回数と応答の範囲を書いておくと、どの程度の関わり方で何ができたかが伝わります。

成果が見えにくい仕事を書くコツ

数字は出せる範囲で、出せないときは状態で書く

リリースの回数、障害の件数、採用した人数など、数字で示せるものは示すと伝わります。ただし、発注側の内部の数字は、守秘の対象になっていることがあります。出せないときは、「障害の振り返りが毎回行われるようになった」のように、変わった状態で書きましょう。

「自分が決めた」と「提案して採用された」を分ける

技術顧問は助言の立場であることが多く、最終的に決めたのは経営陣ということもあります。自分で決めたのか、提案して採用されたのか、提案したが採用されなかったのかを分けて書くと、正直で読みやすい経歴になります。

使った技術は別の欄にまとめる

技術顧問の経歴でも、使った言語・クラウド・道具は見られます。ただし、経歴の本文に並べると「決めたこと」が埋もれます。技術の一覧は別の欄にまとめ、本文では選んだ理由に絞りましょう。

要約は「段階 × 領域 × 関わり方」で書く

スキルシートの冒頭の要約は、「成長期の会社で、開発体制の立て直しと採用を、週数日の実務型で担ってきた」のように、段階・領域・関わり方の三つで書くと、読み手がすぐに合う案件を想像できます。扱える領域が多い場合も、要約では強みを一つか二つに絞りましょう。強みの整理の仕方はキャリアの棚卸しの方法が参考になります。

応募する案件に合わせて並べ方を変える

技術顧問の経歴は、同じ内容でも、応募する案件によって前に出す部分を変えると伝わりやすくなります。

経歴を書き換えるのではなく、並べる順番と、要約で触れる案件を変えるだけで十分です。応募のたびに一から作り直すと内容がぶれやすいため、全部の経歴を書いた元の版を一つ持ち、そこから選んで並べる形にしておくと管理しやすくなります。

スキル一覧に入れたい項目

• 技術：主な言語、クラウド、データベース、開発の道具
• 設計：扱ったシステムの規模、構成の特徴
• 組織：見てきたチームの人数と数、採用で担った役割（面接、評価基準づくりなど）
• プロセス：導入した開発の進め方、リリースやレビューの仕組み
• ルール：セキュリティの方針、AI活用のルールづくりの経験
• 説明：経営会議、投資家向けの説明、社員向けの方針説明の経験

テックリードやアーキテクトとしての経歴も持っている場合は、テックリードとして参画するにはやアーキテクトとして参画するにはの示し方も参考にして、技術の判断の深さが伝わるようにしましょう。

よくある質問

副業で受けた技術顧問の経験もスキルシートに書いてよいですか？

書いてかまいません。副業でも、関わり方（月の回数など）、担った領域、決めたこと、その後を同じ型で書くと、本業の経歴と並べて読めます。勤務先との関係で書けない事情がある場合は、会社の情報を伏せて書きましょう。

1社に長く在籍していて、案件の数が少ない場合はどう書けばよいですか？

在籍した期間の中で、会社の段階が変わったときごとに区切って書くと伝わります。たとえば「エンジニアが数名の時期」「数十名に増えた時期」で、決めたことと困りごとは違うはずです。区切りごとに判断を書くと、複数の段階を経験したことが示せます。

失敗した判断はスキルシートに書くべきですか？

書くかどうかは選べますが、判断を見直した経験は、技術顧問の経歴では評価の材料になります。失敗だけを書くのではなく、何が合わなかったのか、どう直したのかまでを一文で添えると、前向きな経歴として読まれます。面談での話し方は業務委託の面談でよく聞かれる質問をご覧ください。