スキルシートで基本設計経験を書く方法①｜スキルログで整理する上流工程の伝え方
skilllogスキルシートで基本設計の経験を書くとき、「何を書けば評価されるのか分からない」と悩む人は多いです。
なんとなく
- 画面設計を担当
- DB設計を実施
と書いてしまうと、経験の深さが伝わらず、評価につながりにくくなります。
基本設計で重要なのは、どの領域を設計し、どのような判断をしたのかです。
この記事では、スキルログを活用しながら、基本設計の経験を実務レベルで伝わる形に整理する方法を解説します。
- スキルシートはすでに持っててブラッシュアップしたいな
- スキルログ使ってみたいけど、Excelのスキルシート写すのめんどさくいな
- フリーランス挑戦してたい、単価あげたい
- 転職して年収あげたい、違う領域にいきたい など
少しで気になる方！ぜひスキルログ運営局にご相談ください！
基本設計をカテゴリーごとに整理できる
スキルログでは、基本設計の経験を以下のように分類できます。
- システムアーキテクチャの設計
- 主要機能の設計
- データベース設計
- インターフェース設計
- モジュール設計
- 非機能要件の設計
- セキュリティ設計
- データフロー設計
- 通信設計
- エラーハンドリング設計
- ユーザビリティ設計
- システムの制約条件の確認
- 設計文書の作成
- プロトタイプの作成
- その他
このように分解することで、
「基本設計をやった」ではなく「どこまでできるか」が明確になります。
では、それぞれに何を書けばよいのか見ていきましょう。
要件定義については以下をチェック⇓
スキルシートで要件定義経験を書く方法①｜スキルログで整理する上流工程の伝え方
スキルシートで要件定義経験を書く方法②｜スキルログで整理する上流工程の伝え方
スキルシートで要件定義経験を書く方法③｜スキルログで整理する上流工程の伝え方
スキルシート 基本設計 書き方｜システムアーキテクチャの設計
ここは、
👉 上流工程に関われるか・技術選定レベルを判断される重要な項目です。
何を書けばいいのか
- システム全体の構成（フロント / バック / インフラ）
- 技術選定の理由
- 可用性・拡張性の考慮
- 既存システムとの連携方針 など
| NG例 |
| ・アーキテクチャ設計を担当 ・システム構成を検討 ❌ 抽象的で「何をしたか」が伝わらない |
| OK例 |
| 業務システムのリプレイスに伴い、システムアーキテクチャ設計を担当。 フロントエンドにReact、バックエンドにRuby on Railsを採用し、API連携による疎結合な構成を設計。 将来的なユーザー増加を見据え、AWS上でのスケーラブルな構成（ALB + ECS）を採用し、可用性と拡張性を考慮した設計を実施。 既存システムとのデータ連携についてはバッチ処理からAPI連携へ移行する方針を整理し、関係者と合意形成を行った。 |
書き方のポイント
✅「構成 → 理由 → 将来性」まで書く
✅ 技術選定の背景を書くと評価が上がる
✅ 「決めた」だけでなく合意形成も入れる
スキルシート 基本設計 書き方｜主要機能の設計
ここは、
👉 業務理解・要件具体化の力を判断される重要な項目です。
何を書けばいいのか
- 対象となる機能（どの業務か）
- ユースケース・業務フロー
- 機能の整理・優先度付け
- 関係者との認識合わせ など
| NG例 |
| ・機能設計を担当 ・画面や機能を設計 ❌ 何の機能か・どこまでやったかが不明 |
| OK例 |
| 受発注管理システムにおける主要機能の設計を担当。 営業部門および業務担当者へのヒアリングを基に、受注登録・在庫連携・請求処理のユースケースを整理。 現行業務フローをもとに機能ごとの処理内容および画面遷移を設計し、業務効率化を目的とした機能構成を定義。 機能優先度を整理した上で関係部署と認識合わせを行い、開発スコープを確定。 |
書き方のポイント
✅「業務 → 機能 → 設計 → 合意」の流れで書く
✅ 具体的な機能名を必ず入れる
✅ ユースケースやフローを扱ったことを書く
スキルシート 基本設計 書き方｜データベース設計
ここは、
👉 設計力・データ構造理解を判断される重要な項目です。
何を書けばいいのか
- 対象データ（何を管理するか）
- テーブル設計・ER図
- 正規化やデータ整合性の考慮
- パフォーマンスや拡張性 など
| NG例 |
| ・DB設計を担当 ・テーブル設計を実施 ❌ 内容が浅く、レベル感が伝わらない |
| OK例 |
| 受発注管理システムにおけるデータベース設計を担当。 ユーザー、商品、注文、在庫管理に関するテーブル設計およびER図を作成。 データの正規化を行い、冗長性を排除するとともに、注文処理のパフォーマンスを考慮したインデックス設計を実施。 既存データとの整合性を確保するための移行方針を整理し、関係者と合意形成を行った。 |
書き方のポイント
✅「対象データ → 設計内容 → 工夫」まで書く
✅ 正規化・インデックスなどを書くと一気に評価UP
✅ パフォーマンスや整合性に触れると上級者感が出る
まとめ
基本設計の経験は、「担当したかどうか」ではなく、どの領域を設計し、どのような判断をしたかで評価が変わります。
アーキテクチャ・機能設計・データ設計といった観点で分解し、具体的な設計内容や意思決定まで落とし込むことで、「設計を任せられるエンジニア」として伝わります。
もし、
- 自分の基本設計の経験をどう書けばいいか分からない
- スキルシートを見直したい
- 上流工程の経験をうまく伝えたい
と感じている方は、スキルログを使って整理してみてください。
また、より具体的に整理したい方は、Web面談も可能です。
✉️ お問い合わせフォームよりお気軽にご相談ください。
なお、次の記事では
インターフェース設計 非機能要件 セキュリティ設計について、さらに評価に差がつくカテゴリの書き方を解説します。
「設計力」をしっかり伝えたい方は、ぜひ続けてご覧ください。
