Webサイトを作ったのに、制作内容を説明しようとすると言葉に詰まる。そんなときは作品の見た目を増やすより、何を作り、どの部分を自分で理解しているかを整理してみましょう。この記事では、未経験からエンジニアを目指す人が、学習用Webサイトを5枚の説明資料にまとめる練習を紹介します。
ポートフォリオ説明資料は作品の「説明書」
ポートフォリオは制作物や学習成果を示すためのものです。説明資料はその補足として、作品を見ただけでは分からない制作意図、担当範囲、動作確認を相手に伝えます。すべての面接でスライド提出が必要という意味ではありません。
先に作品の公開URL、ソースコード、README、動作確認メモを揃えます。READMEはGitHubなどのリポジトリで「何を作ったか」「どう使うか」を説明する文書です。資料とREADMEに書いた機能が食い違わないようにすることが出発点です。
(READMEの基本的な役割については『GitHub公式|About the repository README file』をご参照ください)
準備:説明に使う事実を4つだけ集める
- 作品の目的:誰のどんな不便を、学習用に解決しようとしたか。
- 自分が書いた部分:HTML、CSS、JavaScriptなどの担当範囲。
- 再現できる操作:入力やボタン操作で何が起きるか。
- 確認した結果:正常動作に加え、未対応の問題が残っていないか。
制作中に調べた資料をすべて載せる必要はありません。一方、実装していないログイン機能やデータベースを、見栄えのために実装済みと書くのは避けてください。自分で確かめた範囲を資料にするほうが、質問にも答えやすくなります。
実践用の題材:学習時間を合計するミニページ
以下は説明資料の練習に使う架空の学習用作品です。エディターで`index.html`を新規作成し、コードを保存してブラウザで開きます。外部サービスへの登録は不要です。
<!doctype html>
<html lang="ja">
<meta charset="utf-8">
<title>学習時間メモ</title>
<h1>学習時間メモ</h1>
<p id="total">集計前</p>
<script>
const studyMinutes = [20, 35, 15];
const sum = studyMinutes.reduce((total, min) => total + min, 0);
document.querySelector('#total').textContent = `合計 ${sum} 分`;
</script>
</html>
開いた画面に「合計 70 分」と表示されれば、この例の集計処理は動いています。`studyMinutes`の配列に`10`を追加したとき「合計 80
分」になるかも確認してください。表示の確認は自分のブラウザで行い、未確認なら資料に「動作確認済み」と記載しません。
このサンプルは入力フォーム、保存機能、ログイン機能を持ちません。合計を表示するだけの小さなWebページとして、できることとできないことを区別します。
5枚の資料に何を書くか:例と確認ポイント
| 枚数 | 載せる内容 | 学習時間メモの例 | 裏付け |
|---|---|---|---|
| 1 | 誰のための作品か | 学習時間の合計を素早く見たい | 目的を1文で説明できる |
| 2 | どの操作ができるか | ページを開くと合計分数を表示 | 実際の画面で70分を確認 |
| 3 | どう実装したか | 配列をreduceで合計しDOMへ表示 | 自分のコードで説明できる |
| 4 | どう確かめたか | 20+35+15=70、10追加なら80 | 手順・期待結果・実結果を照合 |
| 5 | 次に改善したいこと | 入力フォームや履歴保存を検討 | 未実装であることを明記 |
5枚に必ず固定する必要はありません。ここでは、技術に慣れていない読者が「作品の説明」をひと通り練習するための最小構成として使います。
「工夫しました」で終わらせない伝え方
例えば3枚目に「JavaScriptを工夫しました」とだけ書いても、相手は具体的な処理を想像しにくいでしょう。値の入力元・計算・表示先まで説明すると、何を理解しているかが見えやすくなります。
| 曖昧な説明 | 確認できる説明 |
|---|---|
| JavaScriptを使いました | 3つの学習時間を配列で持ち、reduceで合計しました |
| エラーなく動きます | 70分と80分の2つの入力例をブラウザで確認しました(確認した場合のみ) |
| 便利なアプリです | 現状は合計表示のみ。記録の保存は未対応です |
改善点を正直に書くと、次に何を学びたいかも伝わります。実際に試していない性能向上率や、架空の利用者からの高評価を付け加える必要はありません。
AIには下書きの整理を任せ、事実は自分で確認する
文章をまとめるのが難しいときは、AIに箇条書きから説明文の草稿を作ってもらう方法があります。次の依頼例は、この練習用作品の情報だけを扱う独自の例です。
次の事実だけを使い、未経験エンジニアが作品を説明する文章を作成してください。
作品:学習時間を合計して画面表示する学習用ページ
自分で実装:配列の合計計算と表示の更新
確認内容:20、35、15の合計が70になること(確認後に採用)
未実装:入力フォーム、データ保存、ユーザー認証
制約:事実にない開発経験・改善率・利用者評価を作らない。
出力:目的、仕組み、動作確認、課題をそれぞれ短い文章にする。
AIの出力をそのまま採用せず、作品の実装と資料の文章を一つずつ突き合わせます。別の人が作った画像、企業の機密コード、個人情報などを不用意に入力しない点も大切です。
提出前に確認する4つのこと
- 各ページの文章がREADMEと実際の画面に一致している。
- 使用した技術を、自分のコードの位置を示しながら説明できる。
- 実測していない結果や未実装機能を「実績」として書いていない。
- 小さな文字を詰め込みすぎず、図や画面キャプチャには何を伝えるかの説明がある。
図解は複雑にするほど良いわけではありません。Googleの技術文書向けガイドでも、図に載せる情報を絞り、伝えたい内容が分かるキャプションを付けることが説明されています。
(技術図の整理とキャプションの考え方については『Google Technical Writing|Illustrating』をご参照ください)
よくある質問
実務経験がなくても説明資料を作れますか?
作れます。学習用作品について、何を自分で作ったか、どこまで動くか、何が未実装かを正確に説明しましょう。選考での評価は企業や職種によって異なります。
スライドを豪華にしたほうがよいですか?
見た目の統一や読みやすさは重要ですが、動作しない機能を良く見せることより、実装と説明が一致していることを優先してください。
コードを全部資料に貼るべきですか?
原則として不要です。重要な数行だけ示し、完全なコードはREADMEやリポジトリから確認できるようにすると説明が整理しやすくなります。
次の学習へ:構成図でも作品を説明する
説明資料を作れたら、ブラウザで動く部分と、サーバーが必要になる部分を区別してみてください。自分の作品に存在しない仕組みを図へ描き足さないことが、技術的な理解の第一歩です。
(ポートフォリオ全体の考え方については『SESポートフォリオ完全ガイド|キャリア戦略と作り方』をご参照ください)