スキルシートで基本設計経験を書く方法⑤｜スキルログで整理する上流工程の伝え方
skilllog設計文書の作成・プロトタイプの作成・その他の基本設計。
これらは、スキルシートの中でも「設計をどこまで整理・具体化できるか」を判断されやすい項目です。
実際のスキルシートを見ると、
- 設計書を作成
- 画面モックを作成
- 基本設計を担当
といった表現でまとめられているケースがほとんどです。
しかし、この書き方では、
- 何を整理したのか
- 何を目的に作成したのか
- どんな課題を解決したのか
が伝わりません。
また、これらの領域では、
- 関係者との認識合わせ
- 実装前の課題整理
- 開発・運用を見据えた設計
といった、“設計を形にする力”が重要になります。
つまり、
👉 「設計内容を整理し、周囲へ伝えられるか」
を判断されやすいポイントでもあります。
一方で、実務では当たり前に行っている内容ほど、自分では“書くほどではない”と感じてしまいがちです。
しかし、設計観点を具体的に言語化できるだけで、スキルシートの印象は大きく変わります。
そこで本記事では、スキルログの考え方をベースに、
- 設計文書の作成
- プロトタイプの作成
- その他の基本設計
この3つについて、実務レベルで伝わる書き方を具体例とともに解説していきます。
また、「この書き方で伝わっているのか不安…」という方には、スキルシートを見ながらのフィードバックも行っています。お気軽にご相談ください。
基本設計をカテゴリーごとに整理できる
スキルログでは、基本設計の経験を以下のように分類できます。
- システムアーキテクチャの設計
- 主要機能の設計
- データベース設計
- インターフェース設計
- モジュール設計
- 非機能要件の設計
- セキュリティ設計
- データフロー設計
- 通信設計
- エラーハンドリング設計
- ユーザビリティ設計
- システムの制約条件の確認
- 設計文書の作成
- プロトタイプの作成
- その他
このように基本設計を分解することで、
「基本設計をやった」ではなく、「どこまで設計できるか」が明確になります。
また、設計観点ごとに整理することで、自分の強みや経験範囲も伝えやすくなります。
なお、要件定義については以下の記事も参考にしてください⇓
スキルシートで要件定義経験を書く方法①｜スキルログで整理する上流工程の伝え方
スキルシートで要件定義経験を書く方法②｜スキルログで整理する上流工程の伝え方
スキルシートで要件定義経験を書く方法③｜スキルログで整理する上流工程の伝え方
スキルシート 基本設計 書き方｜設計文書の作成
ここは、
👉 「設計内容を整理し、関係者へ正しく共有できるエンジニアか」を判断される項目です。
何を書けばいいのか
まず、どの設計書を作成したのかを書きます。
- 基本設計書
- 画面設計書
- API仕様書
- テーブル定義書
- 遷移図
- シーケンス図
などを整理すると、担当範囲が伝わりやすくなります。
また、設計書で何を整理したのかも重要です。。
- 業務フロー
- 画面遷移
- データ構造
- API連携仕様
- バリデーション仕様
などを書くことで、設計観点が伝わります。
さらに、
- レビュー対応
- 関係者との認識合わせ
- 保守運用を考慮したドキュメント整理
なども重要な観点です。
| NG例 |
| ・設計書を作成 ・仕様書を作成 ❌ どの設計書を作成し、何を整理したのか不明 |
| OK例 |
| 受発注管理システムにおける設計文書の作成を担当。 まず、画面設計書・API仕様書・テーブル定義書を作成し、業務フローおよびシステム間連携仕様を整理。 また、画面遷移図やシーケンス図を用いて、申請・承認・通知処理の流れを可視化した。 さらに、APIごとのリクエスト・レスポンス形式やバリデーション仕様を設計書へ明記し、開発メンバー間の認識差異を防止。 そのほか、レビュー指摘内容を反映しながら設計書を更新し、保守運用時にも参照しやすいドキュメント構成を整備した。 |
書き方のポイント
✅「エラー種別・ユーザー表示・例外処理・ログ・復旧」をセットで書く
✅「何の設計書を作成したか」を具体的に書く
✅ 画面設計書 / API仕様書 / テーブル定義書 など具体ワードを入れる
✅ “何を整理・共有したのか”を書く
✅ 関係者との認識合わせやレビュー対応も含める
✅ 保守運用を考慮したドキュメント整備まで書く
スキルシート 基本設計 書き方｜プロトタイプの作成
ここは、
👉 「実装前に課題やUIイメージを整理できるエンジニアか」を判断される項目です。
何を書けばいいのか
まず、何のプロトタイプを作成したのかを書きます。
- 画面モック
- ワイヤーフレーム
- UI試作
- 操作フロー確認
などを整理すると、目的が伝わりやすくなります。
また、プロトタイプで何を検証したのかも重要です。
- 操作性
- 画面遷移
- 入力フロー
- レスポンス表示
- ユーザー導線
などを書くことで、設計意図が伝わります。
さらに、
- レスポンシブ対応
- 要件整理
- 実装前の課題抽出
なども重要な観点です。
| NG例 |
| ・画面モックを作成 ・試作品を作成 ❌ 何を確認するためのプロトタイプだったのか不明 |
| OK例 |
| 受発注管理システムにおけるプロトタイプ作成を担当。 まず、申請画面・承認画面・検索画面のワイヤーフレームを作成し、業務フローに沿った画面遷移を整理。 また、入力フォームや操作ボタンの配置を検証し、利用者が迷わず操作できるUI構成を確認した。 さらに、ユーザー部門へのレビューを実施し、入力項目の並び順や検索条件の改善要望を反映。 そのほか、実装前に画面導線や操作性の課題を洗い出すことで、開発後の仕様変更リスクを低減した。 |
書き方のポイント
✅「何のプロトタイプを作成したか」を具体的に書く
✅ ワイヤーフレーム / モック / UI試作 など具体ワードを入れる
✅ “何を確認・検証したのか”を書く
✅ ユーザーフィードバックや改善内容も含める
✅ 実装前の課題整理まで書く
スキルシート 基本設計 書き方｜その他
ここは、
👉 「分類しきれない基本設計経験をどう整理できるか」を判断される項目です。
何を書けばいいのか
その他には、
- システムアーキテクチャ設計
- 主要機能設計
- DB設計
- セキュリティ設計
などに直接当てはまらない基本設計経験を書きます。
たとえば、
- 業務フロー整理
- 運用設計
- 権限運用ルール策定
- マスタ設計
- 命名規則整理
- 開発標準化
などが該当します。
また、
- チーム内ルール整備
- 保守性向上
- 運用負荷軽減
なども重要な観点です。
| NG例 |
| ・基本設計を担当 ・運用を考慮 ❌ 何を設計し、どう改善したのか不明 |
| OK例 |
| 受受発注管理システムにおける運用設計および設計標準化を担当。 まず、マスタデータ管理ルールおよび命名規則を整理し、開発メンバー間で統一した設計基準を策定。 また、権限申請フローや運用手順を整理し、保守運用時の対応工数を削減できる運用設計を実施した。 さらに、障害発生時の問い合わせフローやエスカレーション手順を整備し、運用担当者が迅速に対応できる仕組みを構築。 そのほか、既存システムとの運用差異を整理し、業務変更時の影響範囲を把握しやすい設計ルールを整備した。 |
書き方のポイント
✅「何を整理・標準化したのか」を具体的に書く
✅ 命名規則 / 運用ルール / マスタ設計 など具体ワードを入れる
✅ “どんな課題を改善したのか”を書く
✅ 保守運用やチーム開発への影響も含める
✅ 他カテゴリに当てはまらない設計経験を整理して書く
まとめ
設計文書の作成・プロトタイプの作成・その他の基本設計は、どれも「やっている人は多いのに、書けている人が少ない」領域です。
だからこそ、
- 何を整理したのか
- 何を共有したのか
- どんな課題を改善したのか
まで具体的に言語化できるだけで、スキルシートの評価は大きく変わります。
特にこの3つは、
👉 “設計内容を形にし、周囲へ伝えられるか”
が伝わりやすいポイントです。
もし今、
- なんとなく書いている
- 他の人と差がつかない
- 上流経験があるのに評価されない
と感じている場合は、一度この3つの観点で自分の経験を整理してみてください。
見え方が大きく変わります。
また、より具体的に整理したい方は、Web面談でのご相談も可能です。
