スキルシートで基本設計経験を書く方法｜15項目別のOK例・NG例と書き方のポイント
skilllog基本設計の経験はあるのに、スキルシートには「基本設計を担当」としか書けていない。そんなエンジニアは少なくありません。
スキルシートで基本設計経験を伝えるコツは、基本設計をアーキテクチャ・DB・セキュリティなど15の項目に分け、担当した項目ごとに「何を・どう設計したか」を書くことです。この書き方なら、「基本設計をやった」ではなく「どこまでできるか」が伝わります。
この記事では、スキルログで分類できる基本設計の15項目それぞれについて、見られるポイント、書く内容、そのまま参考にできるOK例をまとめました。自分が担当した項目だけ拾い読みしても使えます。
まずは担当した項目を整理するところから始めると、書くべき内容が見えてきます。スキルログに登録すれば、この15項目に沿って経験を入力できます。
「基本設計を担当」の一行では、何ができるのかが伝わりません。担当した項目を特定し、項目ごとに具体的に書くことが基本です。
| 項目 | 見られるポイント |
|---|---|
| システムアーキテクチャの設計 | 上流工程に関われるか・技術選定レベル |
| 主要機能の設計 | 業務理解・要件具体化の力 |
| データベース設計 | 設計力・データ構造理解 |
| インターフェース設計 | システム間連携・API設計力 |
| モジュール設計 | 設計の分割力・責務設計（設計センス） |
| 非機能要件の設計 | 上流エンジニアかどうか |
| セキュリティ設計 | 安心して任せられるエンジニアか |
| データフロー設計 | システム全体を俯瞰できているか |
| 通信設計 | システムのつながり方を理解しているか |
| エラーハンドリング設計 | 安心して任せられるエンジニアか |
| ユーザビリティ設計 | 利用者目線で使いやすいシステムを設計できるエンジニアか |
| システムの制約条件の確認 | 現実的なシステム設計ができるエンジニアか |
| 設計文書の作成 | 設計内容を整理し、関係者へ正しく共有できるエンジニアか |
| プロトタイプの作成 | 実装前に課題やUIイメージを整理できるエンジニアか |
| その他 | 分類しきれない基本設計経験をどう整理できるか |
全項目を埋める必要はありません。担当した項目だけを、プロジェクトごとに書けば十分です。スキルシート全体の書き方は【見本あり】エンジニアのスキルシートの書き方完全ガイド｜項目・記載例・NG例【2026年版】で解説しています。
システム全体の設計（アーキテクチャ・主要機能・データベース）
システムの骨格を決めた経験です。技術選定や業務理解の深さが伝わる部分なので、採用理由まで書くと評価が上がります。
システムアーキテクチャの設計
見られるポイント：上流工程に関われるか・技術選定レベルを判断される項目です。
書く内容：システム全体の構成（フロント / バック / インフラ）、技術選定の理由、可用性・拡張性の考慮、既存システムとの連携方針
OK例
業務システムのリプレイスに伴い、システムアーキテクチャ設計を担当。フロントエンドにReact、バックエンドにRuby on Railsを採用し、API連携による疎結合な構成を設計。将来的なユーザー増加を見据え、AWS上でのスケーラブルな構成（ALB + ECS）を採用し、可用性と拡張性を考慮した設計を実施。既存システムとのデータ連携についてはバッチ処理からAPI連携へ移行する方針を整理し、関係者と合意形成を行った。
- 「構成 → 理由 → 将来性」まで書く
- 技術選定の背景を書くと評価が上がる
- 「決めた」だけでなく合意形成も入れる
主要機能の設計
見られるポイント：業務理解・要件具体化の力を判断される項目です。
書く内容：対象となる機能（どの業務か）、ユースケース・業務フロー、機能の整理・優先度付け、関係者との認識合わせ
OK例
受発注管理システムにおける主要機能の設計を担当。営業部門および業務担当者へのヒアリングを基に、受注登録・在庫連携・請求処理のユースケースを整理。現行業務フローをもとに機能ごとの処理内容および画面遷移を設計し、業務効率化を目的とした機能構成を定義。機能優先度を整理した上で関係部署と認識合わせを行い、開発スコープを確定。
- 「業務 → 機能 → 設計 → 合意」の流れで書く
- 具体的な機能名を必ず入れる
- ユースケースやフローを扱ったことを書く
データベース設計
見られるポイント：設計力・データ構造理解を判断される項目です。
書く内容：対象データ（何を管理するか）、テーブル設計・ER図、正規化やデータ整合性の考慮、パフォーマンスや拡張性
OK例
受発注管理システムにおけるデータベース設計を担当。ユーザー、商品、注文、在庫管理に関するテーブル設計およびER図を作成。データの正規化を行い、冗長性を排除するとともに、注文処理のパフォーマンスを考慮したインデックス設計を実施。既存データとの整合性を確保するための移行方針を整理し、関係者と合意形成を行った。
- 「対象データ → 設計内容 → 工夫」まで書く
- 正規化・インデックスなどを書くと一気に評価UP
- パフォーマンスや整合性に触れると上級者感が出る
さらに詳しい記載例はデータベース詳細設計 スキルシートの書き方で解説しています。
つなぎ方の設計（インターフェース・モジュール・データフロー・通信）
部品の分け方とつなぎ方の経験です。「何と何を、どの方式でつないだか」を具体的に書きます。
インターフェース設計
見られるポイント：システム間連携・API設計力を判断される項目です。
書く内容：外部／内部との連携対象（どのシステムか）、データのやり取り内容（リクエスト / レスポンス）、API仕様・I/F仕様の設計、エラー処理・認証方式、連携方式（API / バッチ / ファイル連携 など）
OK例
受発注管理システムにおけるインターフェース設計を担当。外部の在庫管理システムおよび請求システムとの連携において、REST APIによるデータ連携方式を設計。受注データ・在庫更新データのリクエスト/レスポンス仕様を定義し、JSON形式でのデータ構造を設計。認証にはJWTを採用し、エラー発生時のリトライおよびエラーハンドリング方針を策定。既存のバッチ連携からリアルタイムAPI連携へ移行する方針について関係部署と合意形成を行った。
- 「連携対象 → 方式 → データ → 設計内容 → 合意」
- API仕様（JSON / REST / 認証）を書くと評価UP
- バッチ→API移行などを書くと上流感が出る
さらに詳しい記載例はAPI設計 スキルシートの書き方で解説しています。
モジュール設計
見られるポイント：設計の分割力・責務設計（設計センス）を判断される項目です。
書く内容：機能の分割単位（どのモジュールか）、各モジュールの役割（責務）、モジュール間の関係（依存関係）、再利用性・保守性の考慮、設計方針（MVC / レイヤード / ドメイン設計など）
OK例
受発注管理システムにおけるモジュール設計を担当。注文管理、在庫管理、請求管理の各機能をドメイン単位でモジュール分割し、それぞれの責務を明確化。バックエンドはRailsのMVC構成をベースに、サービスクラスを導入することでビジネスロジックを分離し、保守性を向上。モジュール間はAPIおよびインターフェースを通じた疎結合構成とし、将来的な機能追加や改修の影響範囲を最小化。設計方針についてチーム内でレビューを行い、共通認識を形成した。
- 「何で分けたか（粒度）」を書く
- 責務・依存関係を書くと一気に上級者感
- 「疎結合」「再利用」「保守性」はキーワード
さらに詳しい記載例はモジュール設計 スキルシートの書き方で解説しています。
データフロー設計
見られるポイント：システム全体を俯瞰できているかを見られる項目です。
書く内容：データの流れ（入力→処理→出力）、システム間のデータ連携、データの加工・変換内容、非同期 / 同期処理の設計、データ保持・更新タイミング、障害時のデータ整合性
OK例
受発注管理システムにおけるデータフロー設計を担当。受注データはフロントエンドからAPI経由でバックエンドに送信し、DBに保存後、在庫管理システムへ非同期で連携する構成を設計。在庫更新はメッセージキュー（SQS）を利用し、処理の遅延や失敗時のリトライを考慮。請求データはバッチ処理により日次で集計し、外部の会計システムへ連携。データ整合性を保つため、トランザクション管理およびロールバック処理を設計した。
- データが「どこから来て、どこに流れ、途中で何をしているか」を具体的に書く
- 同期 / 非同期を明確にする
- キュー・バッチなど構成を書くと評価UP
さらに詳しい記載例は処理フロー設計 スキルシートの書き方で解説しています。
通信設計
見られるポイント：システムのつながり方を理解しているかを見られる項目です。
書く内容：通信方式（HTTP / HTTPS / TCP / WebSocket など）、プロトコル・フォーマット（REST / JSON / gRPC など）、通信の頻度・タイミング、タイムアウト・リトライ設計、負荷対策・通信量の最適化、セキュリティ（通信暗号化など）
OK例
受発注管理システムにおける通信設計を担当。フロントエンドとバックエンド間はHTTPSによるREST API通信とし、JSON形式でデータを送受信。外部在庫システムとの連携はAPI通信を採用し、タイムアウトおよびリトライ処理を設計。リアルタイム通知についてはWebSocketを利用し、注文ステータスの即時反映を実現。通信量削減のためレスポンスデータの最適化およびキャッシュ制御を実施した。
- 「通信方式＋用途」をセットで書く
- WebSocket / REST / gRPC など具体技術を書く
- タイムアウト・リトライを書くと上級者感
ここまでの項目で、自分が担当したものは見つかったでしょうか。担当した項目と案件をスキルログに登録しておくと、応募のたびに書き直す手間が省けます。
品質を守る設計（非機能要件・セキュリティ・エラーハンドリング・制約条件）
上流エンジニアかどうかが最も見られる部分です。数値や具体的な対策をセットで書きましょう。
非機能要件の設計
見られるポイント：上流エンジニアかどうかを判断される項目です。
書く内容：可用性（落ちない仕組み）、パフォーマンス（レスポンス・負荷対策）、セキュリティ（認証・認可）、運用・監視、スケーラビリティ（拡張性）、バックアップ・障害対応
OK例
受発注管理システムにおける非機能要件の設計を担当。可用性向上のため、AWS上でALBを用いた負荷分散およびECSによる冗長構成を採用。パフォーマンス面では、注文処理の高頻度アクセスを考慮し、キャッシュ（Redis）およびDBインデックス設計を実施。セキュリティでは、認証にOAuth2.0を採用し、通信のHTTPS化および権限管理の設計を行った。また、CloudWatchによる監視およびアラート設計、障害発生時の復旧手順を整理し、運用チームと合意形成を実施。
- 「観点（可用性など）ごと」に書く
- AWS / キャッシュ / 認証など具体技術を入れる
- 運用・監視まで書くと一気に評価UP
さらに詳しい記載例はパフォーマンス設計 スキルシートの書き方で解説しています。
セキュリティ設計
見られるポイント：安心して任せられるエンジニアかを判断される項目です。
書く内容：認証・認可の方式（JWT / OAuth / セッション管理 など）、通信の安全性（HTTPS / 暗号化）、アクセス制御（ロール・権限設計）、脆弱性対策（SQLインジェクション / XSS など）、ログ管理・監査、セキュリティポリシーへの対応
OK例
受発注管理システムにおけるセキュリティ設計を担当。ユーザー認証にはJWTを採用し、トークンの有効期限およびリフレッシュ処理を設計。認可についてはロールベースのアクセス制御（RBAC）を導入し、管理者・一般ユーザーごとの権限を定義。通信はすべてHTTPS化し、機密情報の暗号化を実施。また、入力値のバリデーションおよびエスケープ処理によりXSS・SQLインジェクション対策を実装。ログイン試行回数制限や監査ログの設計を行い、不正アクセス検知の仕組みを構築した。
- 「認証・認可・通信・対策」をセットで書く
- JWT / OAuth / RBAC など具体ワードを入れる
- “どのリスクに対してどう対策したか”を書く
さらに詳しい記載例はセキュリティ設計 スキルシートの書き方で解説しています。
エラーハンドリング設計
見られるポイント：安心して任せられるエンジニアかを判断される項目です。
書く内容：入力・認証・権限・通信・サーバーなどのエラー種別、原因が分かるメッセージや再入力の案内などのユーザー向け表示、共通例外ハンドラなどの例外処理、トランザクション・ロールバック・リトライ・エラーログ
OK例
受発注管理システムにおけるエラーハンドリング設計を担当。入力エラー・認証エラー・権限エラー・通信エラー・サーバーエラーなど、エラー種別ごとの処理方針を設計。ユーザー向けには、必須項目不足・形式不正・認証期限切れなどの原因が分かるエラーメッセージを表示し、再入力や再ログインなど次の操作が分かるUIを設計。システム側では共通例外ハンドラを導入し、予期しないエラー発生時にはエラーログ・トレースIDを出力して原因調査を容易にした。また、DB更新処理ではトランザクション制御とロールバック処理を設計し、登録失敗時のデータ不整合を防止。さらに、外部API連携時にはタイムアウト・リトライ処理を設計し、通信失敗時でも安全に処理を中断・再実行できる仕組みを構築した。
- 「エラー種別・ユーザー表示・例外処理・ログ・復旧」をセットで書く
- トランザクション / ロールバック / 共通例外ハンドラ / リトライ など具体ワードを入れる
- “どのエラーに対してどう制御したか”を書く
さらに詳しい記載例はエラーハンドリング設計 スキルシートの書き方で解説しています。
システムの制約条件の確認
見られるポイント：現実的なシステム設計ができるエンジニアかを判断される項目です。
書く内容：同時接続数・レスポンス速度・サーバー構成などの性能・インフラの制約、データ量・排他制御・APIのリクエスト制限などのDB・外部APIの制約、セキュリティ・運用・コスト・法令の制約
OK例
受発注管理システムの基本設計にて、システム制約条件の確認および設計方針整理を担当。既存システムとのAPI連携におけるリクエスト上限・レスポンス仕様・通信タイムアウト条件を整理し、リトライ制御および非同期処理を考慮した設計を実施。また、同時アクセス数およびデータ登録件数を踏まえ、DB負荷を考慮した検索条件・インデックス設計を実施した。セキュリティ面では社内ポリシーに基づきHTTPS通信・アクセス権限制御・監査ログ出力を設計。さらに、既存業務への影響を最小限に抑えるため、メンテナンス時間・運用フロー・バックアップ方針を考慮したシステム構成を検討した。
- 「性能・インフラ・DB・外部API・運用」をセットで書く
- API制限 / Timeout / 同時接続数 / インデックス設計 など具体ワードを入れる
- “どの制約に対してどう設計したか”を書く
使いやすさと共有の設計（ユーザビリティ・設計文書・プロトタイプ・その他）
利用者と関係者に向けた設計の経験です。誰に向けて何を整理したかを書くと伝わります。
ユーザビリティ設計
見られるポイント：利用者目線で使いやすいシステムを設計できるエンジニアかを判断される項目です。
書く内容：画面遷移やボタン配置などの操作導線、入力補助やリアルタイムバリデーションなどの入力フォーム設計、レスポンシブ・アクセシビリティ対応、誤操作の防止
OK例
受発注管理システムにおけるユーザビリティ設計を担当。利用者が迷わず操作できるよう、申請・承認・検索・詳細確認までの画面遷移を整理し、業務フローに沿った導線を設計。入力フォームでは必須項目・入力形式・補足説明を明確に表示し、リアルタイムバリデーションにより入力ミスを早期に検知できる仕組みを実装。また、エラー発生時には原因と次に行う操作が分かるメッセージを表示し、ユーザーが自己解決しやすいUIを設計。一覧画面では検索・絞り込み・並び替え機能を配置し、必要な情報に素早くアクセスできるよう改善。さらに、確認画面や削除前の確認ダイアログを設けることで誤操作を防止し、PC・スマートフォン双方で操作しやすいレスポンシブ設計を行った。
- 「導線・入力・表示・エラー・誤操作防止」をセットで書く
- リアルタイムバリデーション / レスポンシブ / 検索・絞り込み など具体ワードを入れる
- “どの使いにくさに対してどう改善したか”を書く
さらに詳しい記載例はUI設計 スキルシートの書き方で解説しています。
設計文書の作成
見られるポイント：設計内容を整理し、関係者へ正しく共有できるエンジニアかを判断される項目です。
書く内容：作成した設計書の種類（基本設計書・画面設計書・API仕様書・テーブル定義書・シーケンス図など）、設計書で整理した内容（業務フロー・画面遷移・データ構造・API連携仕様）、レビュー対応と関係者との認識合わせ
OK例
受発注管理システムにおける設計文書の作成を担当。まず、画面設計書・API仕様書・テーブル定義書を作成し、業務フローおよびシステム間連携仕様を整理。また、画面遷移図やシーケンス図を用いて、申請・承認・通知処理の流れを可視化した。さらに、APIごとのリクエスト・レスポンス形式やバリデーション仕様を設計書へ明記し、開発メンバー間の認識差異を防止。そのほか、レビュー指摘内容を反映しながら設計書を更新し、保守運用時にも参照しやすいドキュメント構成を整備した。
- 「何の設計書を作成したか」を具体的に書く
- 画面設計書 / API仕様書 / テーブル定義書 など具体ワードを入れる
- “何を整理・共有したのか”を書く
さらに詳しい記載例はドキュメント作成 スキルシートの書き方で解説しています。
プロトタイプの作成
見られるポイント：実装前に課題やUIイメージを整理できるエンジニアかを判断される項目です。
書く内容：作成したもの（画面モック・ワイヤーフレーム・UI試作）、検証した内容（操作性・画面遷移・入力フロー・導線）、実装前の課題抽出と要件整理
OK例
受発注管理システムにおけるプロトタイプ作成を担当。まず、申請画面・承認画面・検索画面のワイヤーフレームを作成し、業務フローに沿った画面遷移を整理。また、入力フォームや操作ボタンの配置を検証し、利用者が迷わず操作できるUI構成を確認した。さらに、ユーザー部門へのレビューを実施し、入力項目の並び順や検索条件の改善要望を反映。そのほか、実装前に画面導線や操作性の課題を洗い出すことで、開発後の仕様変更リスクを低減した。
- 「何のプロトタイプを作成したか」を具体的に書く
- ワイヤーフレーム / モック / UI試作 など具体ワードを入れる
- “何を確認・検証したのか”を書く
その他
見られるポイント：分類しきれない基本設計経験をどう整理できるかを判断される項目です。
書く内容：業務フロー整理・運用設計・権限運用ルールの策定、マスタ設計・命名規則の整理・開発標準化、保守性の向上や運用負荷の軽減につながる整理
OK例
受受発注管理システムにおける運用設計および設計標準化を担当。まず、マスタデータ管理ルールおよび命名規則を整理し、開発メンバー間で統一した設計基準を策定。また、権限申請フローや運用手順を整理し、保守運用時の対応工数を削減できる運用設計を実施した。さらに、障害発生時の問い合わせフローやエスカレーション手順を整備し、運用担当者が迅速に対応できる仕組みを構築。そのほか、既存システムとの運用差異を整理し、業務変更時の影響範囲を把握しやすい設計ルールを整備した。
- 「何を整理・標準化したのか」を具体的に書く
- 命名規則 / 運用ルール / マスタ設計 など具体ワードを入れる
- “どんな課題を改善したのか”を書く
基本設計経験の書き方でよくあるNG例
NG例のほとんどは「〇〇を担当」「〇〇を考慮」で終わっていることです。項目名を書いただけでは、何をどう設計したのかが伝わりません。
- 「セキュリティを考慮」→ 認証方式・権限設計・脆弱性対策のどれを、どう設計したかを書く
- 「DB設計を担当」→ 何のテーブルを、どんな意図で設計したかを書く
- 「API通信を実装」→ 通信方式・形式・タイムアウトやリトライの設計まで書く
- 「設計書を作成」→ 何の設計書で、何を整理し、誰とレビューしたかを書く
まとめ
スキルシートで基本設計経験を書くときは、15の項目から担当したものを選び、項目ごとに「何を・どう設計したか」を具体的に書きます。OK例のように、採用した技術・設計の意図・対策をセットで書くと、「実装者」ではなく「設計者」として評価されやすくなります。
スキルシートで基本設計経験を書く際によくある質問
Q1. 基本設計の経験がなくても書ける項目はありますか？
直接担当していなくても、実装や保守を通じて基本設計の内容を理解し、判断の背景を説明できる経験があれば触れる価値があります。関わっていない項目は無理に書かず、実際に携わった範囲を正確に伝えることを優先しましょう。
Q2. 15項目のうち、どれを優先して書くべきですか？
案件で実際に深く関わった項目と、今後アピールしたい技術に近い項目を優先してください。多くの項目を浅く並べるより、2〜3項目を判断理由まで含めて書く方が説得力が増します。
Q3. 複数のプロジェクトで似た設計を担当した場合、まとめて書いてもいいですか？
基本的にはプロジェクトごとに分けて書くことをおすすめします。同じ設計項目でも案件によって規模・難易度・判断の背景が異なるため、まとめてしまうと個々の経験の深さが伝わりにくくなります。
Q4. 要件定義の経験はどう書けばいいですか？
要件定義も同じように項目に分けて書くと伝わります。スキルシートで要件定義経験を書く方法｜9項目別のOK例と書き方のポイントで、項目ごとのOK例をまとめています。
ここまでの内容を踏まえて、まずは自分が担当した基本設計の項目を書き出すところから始めてみましょう。
