スキルシートで基本設計経験を書く方法②｜スキルログで整理する上流工程の伝え方
skilllogスキルシートで基本設計の経験を書くとき、「何を書けば評価されるのか分からない」と感じたことはありませんか。
実際、多くの人が
「画面設計を担当」「DB設計を実施」といったシンプルな表現でまとめてしまいがちです。
ただ、この書き方ではどこまで関わったのか・どんな判断をしたのかが伝わらず、評価につながりにくくなります。
基本設計で見られているのは、単なる作業経験ではありません。
どの領域を設計し、どのように考え、どんな判断をしたのか。
ここが伝わってはじめて、「上流工程に関われる人材」として評価されます。
とはいえ、いきなりそれを言語化するのは簡単ではありません。
日々の業務の中でやっていることを、そのままスキルシートに落とし込もうとすると、どうしても抽象的になってしまうからです。
そこでこの記事では、スキルログの考え方をベースに、
基本設計の経験を“実務レベルで伝わる形”に整理する方法を解説します。
「なんとなく書く」状態から抜け出し、
評価される書き方に変えるためのポイントを具体例とあわせて紹介していきます。
実際にスキルシートを見ながらのフィードバックも可能です。
気になる方はお気軽にご相談ください。
基本設計をカテゴリーごとに整理できる
スキルログでは、基本設計の経験を以下のように分類できます。
- システムアーキテクチャの設計
- 主要機能の設計
- データベース設計
- インターフェース設計
- モジュール設計
- 非機能要件の設計
- セキュリティ設計
- データフロー設計
- 通信設計
- エラーハンドリング設計
- ユーザビリティ設計
- システムの制約条件の確認
- 設計文書の作成
- プロトタイプの作成
- その他
このように分解することで、
「基本設計をやった」ではなく「どこまでできるか」が明確になります。
今回の記事ではインターフェース設計、モジュール設計、非機能要件の設計について解説します。
要件定義については以下をチェック⇓
スキルシートで要件定義経験を書く方法①｜スキルログで整理する上流工程の伝え方
スキルシートで要件定義経験を書く方法②｜スキルログで整理する上流工程の伝え方
スキルシートで要件定義経験を書く方法③｜スキルログで整理する上流工程の伝え方
スキルシート 基本設計 書き方｜インターフェース設計
ここは、
👉 システム間連携・API設計力を判断される重要な項目です。
何を書けばいいのか
- 外部／内部との連携対象（どのシステムか）
- データのやり取り内容（リクエスト / レスポンス）
- API仕様・I/F仕様の設計
- エラー処理・認証方式
- 連携方式（API / バッチ / ファイル連携 など） など
| NG例 |
| ・インターフェース設計を担当 ・API連携を実施 ❌ 何とどう繋いだか不明 |
| OK例 |
| 受発注管理システムにおけるインターフェース設計を担当。 外部の在庫管理システムおよび請求システムとの連携において、REST APIによるデータ連携方式を設計。 受注データ・在庫更新データのリクエスト/レスポンス仕様を定義し、JSON形式でのデータ構造を設計。 認証にはJWTを採用し、エラー発生時のリトライおよびエラーハンドリング方針を策定。 既存のバッチ連携からリアルタイムAPI連携へ移行する方針について関係部署と合意形成を行った。 |
書き方のポイント
✅「連携対象 → 方式 → データ → 設計内容 → 合意」
✅ API仕様（JSON / REST / 認証）を書くと評価UP
✅ バッチ→API移行などを書くと上流感が出る
スキルシート 基本設計 書き方｜モジュール設計
ここは、
👉 設計の分割力・責務設計（設計センス）を判断される重要な項目です。
何を書けばいいのか
- 機能の分割単位（どのモジュールか）
- 各モジュールの役割（責務）
- モジュール間の関係（依存関係）
- 再利用性・保守性の考慮
- 設計方針（MVC / レイヤード / ドメイン設計など） など
| NG例 |
| ・モジュール設計を担当 ・機能を分割 ❌ どう分けたか不明 |
| OK例 |
| 受発注管理システムにおけるモジュール設計を担当。 注文管理、在庫管理、請求管理の各機能をドメイン単位でモジュール分割し、それぞれの責務を明確化。 バックエンドはRailsのMVC構成をベースに、サービスクラスを導入することでビジネスロジックを分離し、保守性を向上。 モジュール間はAPIおよびインターフェースを通じた疎結合構成とし、将来的な機能追加や改修の影響範囲を最小化。 設計方針についてチーム内でレビューを行い、共通認識を形成した。 |
書き方のポイント
✅「何で分けたか（粒度）」を書く
✅ 責務・依存関係を書くと一気に上級者感
✅ 「疎結合」「再利用」「保守性」はキーワード
スキルシート 基本設計 書き方｜非機能要件の設計
ここは、
👉 上流エンジニアかどうかを判断される最重要項目です。
何を書けばいいのか
- 可用性（落ちない仕組み）
- パフォーマンス（レスポンス・負荷対策）
- セキュリティ（認証・認可）
- 運用・監視
- スケーラビリティ（拡張性）
- バックアップ・障害対応 など
| NG例 |
| ・非機能要件を検討 ・性能を考慮 ❌ 具体性ゼロ |
| OK例 |
| 受発注管理システムにおける非機能要件の設計を担当。 可用性向上のため、AWS上でALBを用いた負荷分散およびECSによる冗長構成を採用。 パフォーマンス面では、注文処理の高頻度アクセスを考慮し、キャッシュ（Redis）およびDBインデックス設計を実施。 セキュリティでは、認証にOAuth2.0を採用し、通信のHTTPS化および権限管理の設計を行った。 また、CloudWatchによる監視およびアラート設計、障害発生時の復旧手順を整理し、運用チームと合意形成を実施。 |
書き方のポイント
✅「観点（可用性など）ごと」に書く
✅ AWS / キャッシュ / 認証など具体技術を入れる
✅ 運用・監視まで書くと一気に評価UP
まとめ
基本設計の経験は、「担当したかどうか」だけでは評価されません。
重要なのは、どの領域を設計し、どのような判断を行ったのかです。
インターフェース設計・モジュール設計・非機能要件の設計といった観点で経験を整理し、
具体的な設計内容や意思決定まで言語化できるかどうかで、スキルシートの評価は大きく変わります。
ここまで落とし込めてはじめて、「設計を任せられるエンジニア」として伝わります。
もし今、
・基本設計の経験をどう書けばいいか分からない
・スキルシートを見直したい
・上流工程の経験をうまく伝えたい
と感じている場合は、日々の業務をスキルログとして整理するところから始めてみてください。
断片的だった経験がつながり、伝わる形に変わっていきます。
また、より具体的に整理したい方は、Web面談も可能です。
