ノーコード・ローコード開発者のスキルシートの書き方｜面談で評価される実績の見せ方
公開 2026-10-29 監修：株式会社エージェントベスト
ノーコード・ローコード開発者のスキルシートは、取り組みごとに「どの種類のツールで」「どんな業務を」「どの工程まで」担ったかをそろえ、標準の機能で済ませた部分と拡張した部分、作った後にどう使われているかまで書くと伝わります。ツールの名前と年数だけでは、社内の業務アプリを作った人なのか、社外向けのサービスを作った人なのかすら読み手に伝わらないからです。
この記事では、ノーコード・ローコードならではの書き方のポイントを、架空の記入例とあわせて紹介します。全体の構成はスキルシートの書き方の基本、求められるスキルはノーコード・ローコード開発者のスキルの記事で解説しています。
「kintone経験◯年」だけでは伝わらない理由
ノーコード・ローコードの経験は、同じツールでも中身の差が大きい分野です。たとえば同じ年数でも、次の二人では任せられる仕事がまったく違います。
- 決まった仕様で、画面と項目を設定してきた人
- 業務を聞き取り、アプリの分け方と権限を決め、社内の作り手のルールまで整えてきた人
読み手は、ツール名を見たあと、すぐに「何を作り、どこまで担ったか」を探します。冒頭の要約では、次の三つを一文ずつで書くと、読み手が案件と照らし合わせやすくなります。
| 書くこと | 例（記入例・架空） |
|---|---|
| ツールの種類と主なツール | 業務アプリ型（kintone）を中心に、データベース型の改修経験あり |
| 主な業務の領域 | 営業の案件管理、申請・承認、作業日報 |
| 担える工程 | 業務の聞き取りから設計、構築、運用の定着まで |
1件ごとにそろえる項目
取り組みごとの欄は、次の項目をそろえて書くと比べやすくなります。
- 期間と立場：社員としての社内開発か、受託か、業務委託か
- ツールの種類と使った機能：ツール名に加え、使ったプラグイン、連携の方法、コードによる拡張の有無
- 対象の業務と規模：どの部署の何の業務か、アプリの数、利用者の数（丸めた数で）
- 担った工程：聞き取り・設計・構築・拡張・展開・運用のうち、どこを担ったか
- 判断したこと：標準で済ませた部分、拡張した部分、作らなかった部分とその理由
- その後の使われ方：今も使われているか、利用が広がったか、社内で誰が保守しているか
特に6は、ノーコード・ローコードのスキルシートで差がつく項目です。発注側は、作ったアプリが現場に定着するかを最も気にしているためです。
記入例（架空）：判断と定着が伝わる書き方
以下は書き方を示すための架空の例です。業種、規模、ツール、判断の内容は、ご自身の経験に置き換えてください。
期間：2年（社員として社内開発）
ツール：業務アプリ型（kintone）。プラグイン2種、JavaScript による入力チェックの拡張、REST API による会計システムへの連携
対象業務：営業部門の案件管理と見積の承認。アプリ約10個、利用者約80名
担った工程：業務の聞き取り、アプリとデータの設計、構築、拡張、利用者への説明、運用ルールの整備
判断したこと：見積の様式は紙と同じ形を求められたが、承認に必要な項目に絞って入力を減らした。承認の分岐は拡張せず、標準の機能で組める形に業務の手順を見直してもらった。入力の誤りが多かった金額の項目だけ、JavaScript でチェックを加えた
その後：営業部門から他の2部署に利用が広がった。社内の担当者向けに設計の記録と変更の手順を残し、改修は社内の担当者が行っている
この例のように、「なぜそうしたか」と「その後どうなったか」が入ると、設計と定着を任せられる人だと読み手に伝わります。
記入例（架空）：Webアプリ型の書き方
こちらも書き方を示すための架空の例です。
期間：8か月（業務委託・準委任）
ツール：Webアプリ型（Bubble）。外部の決済サービスとメール配信サービスとの連携
対象：社外の会員向けの予約サービス。公開後の会員数は数百名規模
担った工程：要件の聞き取り、画面とデータの設計、構築、連携の設定、公開後の改善
判断したこと：会員の種類ごとに見せる情報を分け、データを読み書きできる範囲を権限の設定で絞った。予約の変更は自由にできる形にせず、締め切りを設けて運営側の確認の手間を減らした
その後：公開後の問い合わせを分類し、多かった操作の迷いを画面の改善で減らした。運営側が文言や予約枠を自分で変えられるよう、管理画面と手順書を用意した
社外向けのサービスでは、利用者の規模、権限の考え方、公開後の改善まで書くと、一通り任せられる人だと伝わります。
ツールの種類ごとに書き足したいこと
| ツールの種類 | 書き足したいこと |
|---|---|
| 業務アプリ型 | アプリどうしの関連づけ、権限の分け方、承認や進み具合の管理の設定、使ったプラグインと連携 |
| データベース型 | テーブルとリレーションの設計、スクリプトで自動化した処理、運用環境（社内のサーバーかクラウドか）、バックアップの扱い |
| Webアプリ型 | 利用者が社外か社内か、ログインと権限、決済や外部APIとの連携、公開後の改善と不具合対応 |
複数の種類を経験している場合は、軸にする種類を先に書き、ほかは「補助的な経験」として短くまとめると、読み手が迷いません。Power Platform や RPA の経験もある場合は、それぞれの職種の記事の書き方を参考に、別の欄に分けて書くと整理しやすくなります。
規模と成果は、丸めた数と変化の方向で示す
規模は、アプリの数、利用者の数、部署の数などを丸めた数で書きます。正確な数は、発注側の社内の情報にあたることがあるためです。
成果は、作業時間の削減などの数字がはっきりしていれば書いてかまいませんが、測っていない数字を作るのは避けましょう。数字がない場合は、次のように変化の方向で伝えられます。
- 紙で回していた承認がアプリの中で完結するようになった
- 月末の集計のための転記がなくなった
- 部署ごとに別々だった管理表が一つのアプリにまとまった
書かないほうがよいこと
ノーコード・ローコードの経験は、画面そのものが見せやすいため、つい画面の画像を添えたくなります。しかし、画面には顧客名、社内の組織名、業務の数字などが映り込みやすく、守秘の約束に触れるおそれがあります。
- 勤務先や発注側の環境で作ったアプリの画面の画像
- 顧客名や取引先名、社内のシステム名
- 社内の業務の数字（売上、件数など）をそのまま書いたもの
書いてよいことの線引きはスキルシートに書いてよいこと・いけないことで解説しています。画面を見せたい場合は、自分で用意した架空のデータで作った見本を使うのが安全です。
契約の形に合わせた書き方の工夫
この分野の案件には、アプリを作って納める請負の形と、稼働時間で報酬が決まる準委任の形があります。請負の経験が多い場合は、要件を固めて完成させた経験として、準委任の経験が多い場合は、継続的な改善や運用の支援の経験として、それぞれ書き方の重心を変えると、応募する案件に合わせやすくなります。違いは準委任契約と請負契約の違いをご覧ください。
よくある質問
社内の情報システム部門での経験しかありません。どう書けばよいですか？
社員として社内のアプリを作ってきた経験も、業務委託の案件で評価されます。「社内開発」と立場を明記したうえで、どの部署の業務を、どの工程まで担い、どう定着させたかを書いてください。社内の作り手からの質問に答えてきた経験や、ルールづくりの経験も、運用と定着の実績として書けます。
個人で作ったアプリは実績として書けますか？
書いてかまいませんが、業務で使われた経験とは分けて書きましょう。個人の制作物は、ツールの扱いや拡張の力を示す材料になります。誰が使っているか、どんな課題を解決するものかを添えると、読み手が評価しやすくなります。
ツールのバージョンや機能の名前は細かく書くべきですか？
使った機能のうち、案件の判断に関わるもの（連携の方法、拡張の手段、権限の設定など）は具体的に書くと伝わります。一方、すべての機能を並べると要点がぼやけます。面談で聞かれたときに説明できる範囲にとどめるのがおすすめです。