😺
【まとめ】ポートフォリオ作成
成果物
（2026-06まで公開）
なんでポートフォリオ作るの？
🙂自分向けの理由
強みや弱みを把握し、今後のキャリア形成のための指針とするため
🏢見てくれる人への理由
採用時のミスマッチを防ぐ
😶🌫️誰に見てもらう？
人事、開発、経営者。エンジニアや非エンジニア。スマホでも見てそう
（💡いずれも仕事しながら片手間に見るぐらいのイメージなので、思考負荷にならず分かりやすくシンプル直感的なものがよいかも）
🧰何を使って作る？
WP＋PHP
（👉HTML/CSS/JSで作る時と比べて、UIから更新可能な点が管理運用を容易にしてくれる...はず）
🗺どこまで作る？
- トップページ プロジェクト自己紹介スキル経歴
- ヘッター 最低限グローバルナビゲーション
- フッター 連絡先SNSリンクへの誘導
- プロジェクト一覧
- 各プロジェクト
- 思考負荷にならない最低限のアニメーション、デザイン
- モバイルファースト、レスポンシブ対応
保留
ログ収集設定、Simple HistoryやGoogle Analyticsで簡易追跡。今後の改善のため。拡張入れて設定するだけでよいならやる
UX/UIを向上させるデザイン、アニメーション。
やらない
ヘッドレスCMS、多言語対応
どうやって作る？
🧭方針
思考負荷の少ないデザイン
- 情報の優先順位を明確に(hero -> works -> skill -> background -> contact)
- 認知負荷の低減（余白・行間・情報密度）
- 一貫性（見出し、配色、比率）
- ナビゲーション
- アクセシビリティ(セマンティックHTML)
（👉 採用者が「この人が何をできるか」を数秒で把握できるようにする）
🗺️構成
front-page（固定ページ）
├─ Hero（ファーストビュー）
├─ 成果物一覧（カスタム投稿アーカイブ）
│ └─ 各成果物（single-work.php）
├─ スキル
├─ 経歴,自己紹介
└─ 連絡先
- Hero（ファーストビュー）
一言で役割と強み（例：Frontend Developer / UI & Performance）
制作物サムネを1〜2個見せる or ごく短い自己紹介(何が得意で、どんな価値を提供できるか) - 成果物
3つぐらい？
技術・背景・成果を書く - スキル
- 経歴や自己紹介
“どうでもいい話”ではなく“価値を提供する背景”を書く - 連絡先
外部SNSリンク（外部サイトへ遷移）
📁想定するフォルダ構成
mytheme/
│
├─ style.css // テーマ情報＋全体CSS(importで集約)
├─ functions.php // テーマの設定、CPT登録など
├─ front-page.php // トップページ(Hero, Works, Skill, 経歴, 連絡先)
├─ index.php // フォールバック用
│
├─ archive-work.php // Work一覧（/work/）
├─ single-work.php // Work個別ページ
│
├─ header.php // ヘッダー
├─ footer.php // フッター
├─ sidebar.php // サイドバー（必要なら）
│
├─ template-parts/ // フロントページ表示用の各セクション
│ ├─ hero-sec.php
│ ├─ work-sec.php
│ ├─ skill-sec.php
│ └─ career-sec.php
│
├─ css/
│ ├─ reset.css
│ ├─ variables.css // テーマ共通変数
│ └─ components // レイアウト、ボタン、カードなど
│
├─ js/
│
└─ assets/
├─ imagas
└─ videos
実際に作ってみた
🧠思考負荷の少ないデザイン
- 情報設計（ファーストビューで自分の価値を伝える、以降はその根拠を列挙）
- 一貫性や統一感（CSS変数を基本としてサイズ、配色、余白や間隔を統一）
- ゆったりとしたアニメーション（急な切り替え＝脳へ「突然の情報」を与えることを避け、心理的な余裕を生む）
🏠変更に強く壊れにくく拡張性のある実装
- 変更に強い(cssの変数利用やPHPコンポーネント化)
- 壊れにくい、もしくは壊れてもすぐ気づける（ダミーデータでデフォルト値の設定）
- 拡張性（メジャーな拡張が持つ関数をチェック）
振り返り
⏲️作業時間の超過
予定:8h
実際:24h
原因は、、、
- 明確な終わりが決まっていない（コア体験は何か、それを実現する最小限の機能やデザインは？）
- 正確な作業時間を見誤っている（設計が浅い、予定する作業時間に対してコア体験を限定できていない）
- コードをきれいにしたい欲求（ファイルの分割、コンポーネント化など）
- 作業を短縮するための施策がない（再利用できるテンプレートやコンポーネント、自動化）
- 問題が発生した際のバッファがない
💔本番環境での表示崩れ
作業中に行ったファイル名の変更により、パスの不一致が出て表示崩れが発生。なぜかローカルでは発生せず本番環境移行時に発生。
本番環境への移行が締め切り直前だと、想定していない問題が発生した時に詰みそう。本番環境へ実装までを作業単位とした方が良い
🎭設計時とのずれ
情報構成の流れとフォルダ構成が異なる。
これは設計者と実装者が同じだから起こりうる？
設計時で決めるべきところと決めてはいけないところがありそう。
今後の改修と改善
- 壊れにくく：拡張を入れても現行の機能に影響がないように
- 壊れたことに気づきやすく：問題のある状態は基本ダミー画像やデータが入るように
- 変更に強く：各フォイルを責任に応じて分割。ロジックやデータと表示機能の分離して、再利用しやすく変更しやすくテストしやすく。何かを追加するときはフォルダのコピペとfunctionsへの登録のみで終わらせるぐらい
- 表記ゆれ修正（work?works?）
- UX改善：思考負荷を減らすデザインやアニメーション
- 文章は読みやすいフォントで、絵文字やサムネイルで直感的に
- キャリアと成果物のカードは共通化
参考
作業ログ
Discussion