「ポートフォリオをもう一度作り直すならどこを変える？」の答え方【IT就活一問一答】

Q.技術面接で「もしこのプロダクトをもう一度作り直すなら、どこを変えますか？」と聞かれ、上手く答えられませんでした。どのように返すのが正解だったのでしょうか。

先日受けたサマーインターンの技術面接の終盤で、面接官から「もし最初から作り直せるなら、どの設計や技術スタックを変更するか」と質問されました。

せっかく作ったプロダクトの欠点や弱点を自ら白状するような気がしてしまい、「特に変えたいところはありません」と答えてしまったところ、あまり面接官の反応が良くなく落ち込んでいます。

自分の作ったコードのどこをどう変えればいいなんてパッと浮かびませんでしたし、そもそも面接官に納得してもらえるような返し方が何か分からず悩んでいます。

面接官はどのような意図でこの質問をしているのでしょうか？また、その際の正しい答え方を教えてください。

A.現在のプロダクトの課題点を素直に認めつつ、「今のスキルや知識があれば、どう具体的に改善するか」を過去との差分として論理的に伝えましょう。

自分がこだわり抜いて作った成果物だからこそ、面接で変えたいところを聞かれると、まるで自分の技術力を否定されたかのように感じて身構えてしまいますよね。

ですが、面接官はあなたのプロダクトの粗探しをして、落とそうとしているのではありません。むしろ逆で、あなたの「客観的な自己分析力」と「技術に対する飽くなき探究心（伸び代）」を見ようとしています。

現在の成果物をあえて未完成なものとして捉え、エンジニアとして常にブラッシュアップの余地を模索できるスタンスを示せれば、技術選考において非常に高い評価に繋がります。

面接官を納得させ、自身の視座の高さを正しくアピールするために、まずは質問の裏にある彼らの本当の本音を紐解いていきましょう。

面接官が質問する本当の意図

面接官が作り直したい部分を尋ねる際、注目しているのは現在のプロダクトの完成度そのものではありません。

彼らが本当に見極めようとしているのは、開発が終わった後も技術的なアップデートを継続しているかというエンジニアとしての「学習姿勢」です。具体的には、以下の2つの観点から実力を測ろうとしています。

現状に満足しないスタンスの確認

プロダクトを「作って終わり」にせず、常にリファクタリングや非機能要件の改善の余地を模索するエンジニア気質があるかを見ています。運用や保守の視点を持ち、プロダクトをより良くするための課題発見力があるかを確認しています。

技術的な視座の高さ

開発当時と比べて、現在の自分がどれだけ技術的に成長し、自身のコードを客観視できているかを確認しています。当時の自分の限界をメタ認知し、現在の知識水準との差分を論理的に語れるかどうかが問われます。

「もう一度作り直すなら」の答え方

面接官の意図を汲み取り、自身のスキルアップを強く印象付けるためには、ただ弱点をリストアップするだけでは不十分です。当時と現在のインプットの差分を意識して、以下の2つのポイントからロードマップを具体的に語りましょう。

技術選定と設計のアップデート

「当時は〇〇のフレームワークで作ったが、今ならパフォーマンスや保守性を考慮して△△に置き換える」「データベースの正規化が甘くクエリ速度に課題があるため、〇〇のように設計し直す」など、改善への具体的なロードマップを伝えます。これにより、実務を見据えた高度な設計判断力をアピールできます。

過去の判断と現在の判断の差分の言語化

自分のコードを客観的に見つめ直し、当時は手が回らなかった、あるいは知らなかった設計・非機能要件の弱点を伝えます。その上で「当時は〇〇という知識がなかったためこの実装にしたが、その後〇〇を学んだため、今なら△△というパターンで解決する」というように、当時から今日までの間に引き上がった「技術的な視座の高さ」をアピールしましょう。

回答例文

実際の面接の場で、これらのポイントがどのように評価に影響するのか、具体的なOK例文とNG例文で比較してみましょう。

NG例文

「自分なりに今持てる全ての力を注いで作ったので、現状は特に大きく作り直したいと感じる部分はありません。機能的にも今のままで満足しています。」

「全体的にまだコードが汚い部分が残っているので、もっと綺麗なコードにリファクタリングしたいです。あとは、テストのカバレッジを通すことだけを意識して書いてしまっていたので、今後はもっとテストの質を意識して、テストコードをしっかり書き直したいと考えています。 」

「今見返すと本当にコードがひどい状態なので、今の自分なら正直すべて一から書き直したいです。当時はとにかく実装を急いでいたため、全体的に設計が崩壊してしまっています。」

【解説】

プロダクトを守るために「変えるところはない」と突っぱねるのはもちろんNGですが、「もっと綺麗なコードに」という中身のない抽象的な反省や、「全部やり直したい」という感情的な全否定も評価されません。

2つ目の例文は、「テストの質」という言葉を使っていますが、「具体的にどのコンポーネントの、どういうテスト戦略に問題があり、今ならどう設計し直すのか」という技術的なロードマップが見えません。テストやリファクタリングという観点そのものは悪くなく、むしろ運用視点として自然な第一声です。NGなのは「綺麗にしたい」「テストの質を意識したい」で止まり、具体的に踏み込めていない点です。

いずれのパターンも、面接官が求めている「当時と現在の判断の具体的な差分（技術的な振り返り）」を言語化できていないため、客観的な自己分析力や成長意欲が疑われてしまいます。 

OK例文

「フロントエンドの状態管理の設計について、今なら『状態遷移の複雑化に耐えられる保守性』を根拠に、構造をアップデートしたいと考えています。

開発当時は、とりあえず動くものを作るスピードを最優先にしており、個別のコンポーネントに複数のuseStateを配置し、それらをuseEffectで同期させる実装を選択しました。

しかし機能が増えるにつれ、状態の更新ロジックが画面全体に散らばってしまい、どの操作がどの状態変化を引き起こしているのかが追いにくく、バグの温床になるという課題を抱えることになりました。

当時は『動かすこと』が要件だったためその設計で十分でしたが、開発後に複雑な状態管理の設計パターンをインプットした現在の視点で見ると、コードの見通しや状態の予測可能性など、保守性を大きく損なっています。

そのため今作り直すのであれば、状態の更新窓口を一元化できるuseReducerを採用します。コンポーネントから状態更新のビジネスロジックを綺麗に分離・集約することで、コードの予測可能性を高め、今後の機能拡張にも耐えられるアーキテクチャへと変更します。」

【解説】

「当時はスピード最優先という要件があったからあの設計にした」という過去の判断基準を冷静に言語化した上で、「現在は保守性や機能拡張という非機能要件を重視し、その解決策としてuseReducerという設計パターンを選択する」という技術的なトレードオフ（根拠）に繋がっています。当時と現在の判断の差分が明確であり、面接官が求める視座の高さを十分に満たした回答です。 

上記の例はフロントエンドの状態管理ですが、「過去の判断 → 当時の制約 → 顕在化した課題 → 学び → 今の解決策」という型はどの領域でも同じです。たとえばバックエンドなら「同期処理で書いていた重い処理を、学習後はジョブキューで非同期化する」、DBなら「正規化やインデックス設計を見直す」、モバイルなら「画面遷移とローカルキャッシュの設計を変える」など、自分のポートフォリオの領域に置き換えて語れます。

課題と改善策を言語化し、技術的な伸び代をアピールする

技術面接において、プロダクトの課題や反省点を口にすることは決してマイナス評価にはなりません。むしろ、明確な「課題と改善策のセット」と「開発当時からの成長」さえ示せれば、過去の自分を客観視して次の開発に活かせる、自走力の高いエンジニアであることが証明できます。

面接前には必ず、自分のポートフォリオを客観的に見つめ直し、今ならどうアプローチするかをロジカルに伝える準備をしてみましょう。

ツールやフレームワークをただ使うだけでなく、自身の技術知識のアップデートに伴ってプロダクトを主体的に進化させ続けられるその姿勢こそが、面接官に対してあなたの実力を納得させるための確かなアピール材料となります。

この質問の回答者

ITエンジニアを目指す新卒学生向け就活エージェントならレバテックルーキー

レバテックルーキーは、レバテックが運営するITエンジニア専門の就活エージェントです。多数のITエンジニアのキャリア支援経験のあるアドバイザーが、あなたのスキルと希望に合わせた企業の紹介から、人事目線での面接対策など、就職までを一貫してサポートします。ES添削、面接対策、ポートフォリオ作成サポートなども実施していますので、まずは一度カウンセリングにお越しください。

就活アドバイザーに相談してみる