ポートフォリオの作り方

制作中に「詰まった」時の効果的な問題解決プロセス

生田 陸人
監修
LuaGate エンジニア / 現役エンジニア
編集 LuaGate編集部

このレッスンで分かること

  • この記事では「制作中に「詰まった」時の効果的な問題解決プロセス」を ポートフォリオ作成 の現場で使える形で整理します
  • ポートフォリオ制作で詰まった時こそが最大のチャンスである理由 をおさえれば、現場で迷ったときに立ち戻れる
  • 1. エラーを特定する → 感情を切り離し、事実を整理する をおさえれば、現場で迷ったときに立ち戻れる
  • 現象を正しく把握する をおさえれば、現場で迷ったときに立ち戻れる
  • エラーメッセージを読む をおさえれば、現場で迷ったときに立ち戻れる

制作中に「詰まった」時の効果的な問題解決プロセス とは

ポートフォリオ制作中にエラーで詰まった際の、論理的な問題解決プロセスを解説。エラーの特定方法、切り分け、効率的なリサーチ術から、解決過程を評価に繋げるドキュメント作成法まで、現役エンジニアの視点で伝授します。

ポートフォリオ制作で「詰まった」時こそが最大のチャンスである理由

結論先出し — エラーは 隠すもの ではなく アピール素材 です。「詰まり方」を記録する習慣が、そのまま採用担当者を唸らせるストーリーになります。

ポートフォリオを制作していると、必ずと言っていいほど「原因不明のエラー」や「実装が思い通りに進まない」といった壁にぶつかります。何時間も同じ画面の前で悩み、手が止まってしまうと、焦りや挫折感を感じることもあるでしょう。

しかし、現役のエンジニアや採用担当者は、あなたが「どれだけスムーズに完成させたか」よりも、問題解決のプロセスを非常に重視しています。なぜなら、実務の世界は「詰まること」の連続だからです。

このレッスンでは、制作中に詰まった時の効果的な 問題解決プロセス を学び、それをポートフォリオの評価に繋げるための具体的な手法を解説します。このスキルを身につければ、エラーは「怖いもの」ではなく、自分の実力をアピールするための「絶好の素材」へと変わります。

diagram (will load when visible)

1. エラーを特定する → 感情を切り離し、事実を整理する

「動かない！」というパニックに陥ると、闇雲にコードを書き換えてしまいがちですが、これは解決を遠ざける一番の原因です。まずは冷静に、以下のステップで「事実」を整理しましょう。

現象を正しく把握する

まずは「何が起きているか」を言語化します。

  • 期待していた動作は本来、システムはどう動くべきだったのか？
  • 実際の動作は現実には何が起きているのか？（エラーメッセージが出る、画面が真っ白になる、データが保存されない等）

エラーメッセージを「読む」

多くの初心者はエラーメッセージを「警告」として怖がりますが、エンジニアにとってエラーメッセージは「解決への地図」です。特に以下の3点に注目してください。

  1. エラーの種類（Error Type）はSyntaxError（構文ミス）、ReferenceError（定義なし）、TypeError（型の間違い）など。
  2. エラーの内容（Message）は具体的に何が悪いのかを説明しています。
  3. 発生場所（Stack Trace）はどのファイルの、何行目でエラーが起きているのか。

これらをメモ帳やGitHubの Issue に書き出すだけでも、思考が整理され、解決の糸口が見えてくることがよくあります。

2. 問題の切り分け（アイソレーション） → 原因の所在を突き止める

エンジニアリングにおける問題解決の基本は、「原因の切り分け」です。巨大なシステム全体を疑うのではなく、問題を小さく分解して、どこに原因があるのかを特定します。

境界線を見極める

例えば、「ボタンを押してもデータが保存されない」という問題が発生した場合、原因は多岐にわたります。

  • フロントエンドはJavaScriptのイベントが発火していない？
  • ネットワークはAPIリクエストが正しく送信されていない？
  • バックエンドはコントローラーで バリデーションエラー が起きている？
  • データベースはカラム名が間違っていて保存に失敗している？

これらを切り分けるために、ブラウザの「デベロッパーツール」の Networkタブ を確認したり、サーバー側のログを確認したりして、「どこまでは正しく動いているか」を一つずつ確認していきます。

diagram (will load when visible)

最小再現コードを作る

もし特定のライブラリや機能で詰まっているなら、現在制作中のプロジェクトから離れ、最小再現コードを別途作成してみるのも有効です。余計なコードを削ぎ落とすことで、原因が自分のコードにあるのか、ライブラリの仕様にあるのかが明確になります。

3. 効率的なリサーチ術 → GoogleとAIを使い分ける

原因の目星がついたら、解決策を検索します。ここで重要なのは、「検索の質」です。

検索キーワードの選び方

エラーメッセージをそのままコピー＆ペーストするのも手ですが、より精度を高めるには以下の要素を組み合わせます。

  • 言語名 or フレームワーク名（例：React, Rails）
  • ライブラリ名（例：Stripe, Axios）
  • エラーメッセージの核となる部分（変数名などは除外する）
  • やりたいこと（例："image upload fetch error"）

また、日本語の情報だけでは限界があるため、英語で検索する癖をつけましょう。how to resolve [エラー内容] で検索すると、Stack Overflow などの質の高い回答にヒットしやすくなります。

AI（ChatGPT/Claudeなど）の活用

最近では、AIをデバッグパートナーとして使うのが主流です。ただし、単に「エラーを直して」と投げるのではなく、以下のようにコンテキストを伝えると精度が劇的に上がります。

  • 使用している言語・フレームワークのバージョン
  • 実装しようとしている機能の概要
  • 関連するコードの一部
  • 発生しているエラーメッセージ
  • すでに試したこと

AIに「なぜこのエラーが起きるのか、考えられる原因を3つ挙げてください」と質問することで、自分の死角になっていた知識を補完できます。

ここまでの要約 — 検索とAIの両輪は コンテキスト量 で精度が決まります。エラー文だけ投げるのではなく、バージョン・試したこと・期待動作をセットで渡すのが鉄則です。

4. 「詰まったプロセス」をポートフォリオの武器に変える方法

多くの学習者は、解決したらそれで終わりにしてしまいます。しかし、ポートフォリオで評価されるのは、「詰まったプロセス」を武器に変えるストーリーです。

制作ログをドキュメント化する

ポートフォリオの README や技術ブログ（Qiita, Zennなど）に、以下の構成でトラブルシューティングの記録を残しましょう。

  1. 直面した課題はどのような機能実装で、どんな問題が起きたか。
  2. 仮説と検証はどこに原因があると考え、どのような調査（デバッグ）を行ったか。
  3. 解決策は最終的にどうやって解決したか（コードのビフォーアフター）。
  4. 学びはこの経験から何を得たか（新しい知識、デバッグ手法の反省など）。

GitHubのコミットメッセージやIssueを活用する

「エラーを修正しました」というコミット一つよりも、「〇〇のエラーを解消するために、△△の処理を見直した」という詳細な記録がある方が、実務でのコミュニケーション能力が高いと判断されます。

避けたい例

プレーンテキスト

// 悪い例：内容が不明確で何をしたか分からない fix: error

良い例

プレーンテキスト

// 良い例：原因と対処法がひと目で分かる fix: ログイン時にバリデーションエラーが発生する問題を、正規表現の誤りを修正して解消

一人開発であってもGitHubの Issue を作成し、そこで「独り言」のように試行錯誤の過程を記録しておくことは、非常に強力なアピール材料になります。

5. ラバーダック・デバッグ → 誰かに説明するつもりで話す

どうしても解決の糸口が見えない時におすすめなのが、ラバーダック・デバッグです。これは、机の上に置いたアヒルのおもちゃ（ラバーダック）に対して、自分のコードを一行ずつ説明していく手法です。

「ここで変数Aを定義して、次にこの関数に渡して……あれ、この関数に渡す前にAの型が変わっているな？」というように、他人に説明しようとすることで、自分自身の論理の矛盾に気づくことができます。相手は人間である必要はありません。AIに対して「今から自分のコードの論理を説明するので、矛盾がないか聞いていてください」と伝えるのも一つの現代的な方法です。

プロのエンジニアでも、詰まった時に一人で抱え込まず、同僚に説明している途中で「あ、自己解決しました！」となることは日常茶飯事です。まずは声に出して、自分の思考を言語化してみましょう！

まとめ → 問題解決プロセスこそがエンジニアの核心

ポートフォリオ制作中に「詰まる」ことは、あなたが自分の限界を超えようとしている証拠です。エラーに遭遇した際は、以下のステップを思い出してください。

  1. エラーメッセージを冷静に読み、事実を整理する
  2. 問題を最小単位に切り分ける
  3. 検索とAIを駆使して、根拠のある解決策を探る
  4. そのプロセスを言語化し、記録に残す

これらの習慣を身につけることで、ポートフォリオの質が上がるだけでなく、エンジニアとして採用された後も通用する「自走力」を証明できるようになります。エラーを楽しみ、それを自らの成長の記録として積み上げていきましょう！

現場でよくある具体例

  1. Aさん (受託企業内定) は GitHub の README 冒頭に「誰の何を解決するか」を 3 行で書き、デプロイ URL を最上段に置いた。それだけで書類通過率が 2 倍に
  2. Bさん (自社開発内定) は技術選定理由を README の「Why this stack?」セクションに明記。面接が「決定根拠の深掘り」中心になり、暗記質問が消えた
  3. Cさん (落選続き → 内定) はテーブルを切ってコミット履歴を整理。「feat: 機能追加」のような Conventional Commits に変えた途端、レビュー観点での評価が上がった

次にとるべきアクション

  1. 今のポートフォリオを採用視点で 30 秒見直す — README・デプロイ URL・スクショの 3 点が即座に伝わるか確認する
  2. 改善ポイントを GitHub Issue 化する — 「制作中に「詰まった」時の効果的な問題解決プロセス」で得た観点を、自分のリポジトリの Issue として 3 件登録する
  3. 実装/修正を次の 1 週間で完了させる — Issue を Pull Request に落とし込み、コミットメッセージにも改善理由を残す

次のレッスン

次は チーム開発経験がない場合の「疑似チーム開発」の作り方 で、チーム開発経験がない場合の「疑似チーム開発」の作り方 を学びます。

事前確認 — 進む前に次の 3 つができることを確認しましょう。

  1. 問題解決プロセス の要点を自分の言葉で説明できる
  2. このレッスンの最小コード (または操作手順) を見ずに書ける
  3. 練習問題やクイズで間違えた箇所を読み直して理解した

理解度チェック (30 秒)

Q. 問題解決プロセス とは何か、1 文で説明してください。

この章のポイント

A. 本文の「このレッスンで分かること」または冒頭の説明文を見直し、自分の言葉で要約できれば OK。詰まったら本レッスンの最初の H2 セクションを読み返してみましょう。

関連レッスン

参考にした出典

学習を加速したい方へ

未経験エンジニア向けポートフォリオ作成ガイドを体系的にマスターするなら、chotdekiru の無料学習ポータル で実際に手を動かして学習を始めるのがおすすめです。質問・つまずきも現役エンジニアが伴走します。

復習ミニクイズ

ポートフォリオ制作中に「ボタンを押してもデータが保存されない」という不明なエラーが発生しました。解決に向けて、まず最初に行うべき「原因の切り分け（アイソレーション）」として最も適切なアプローチはどれですか？

参考リンク