【27卒エンジニア就活】4STEPで自己分析したプロセス

はじめに

就活の時になると自分が何をしたいのかがわからなくなることが多いと思います。しかも、厄介なのは志望動機を言語化するためには「自分のやりたいこと」と「志望企業がやりたいこと」をリンクさせなければなりません。

私もまさにこの壁にぶつかりました。「なぜその会社なのか？」と理由はあるはずなのに言語化できない。そんな状態から、自己分析を通じてどうやって自分の軸を見つけたのかを、プロセスとして紹介します。

STEP 1：抽象的なゴールから逆算する

まず「漠然としたやりたいこと」を言葉にする

理想は自分の経験から楽しいとか、やりがいを感じたことは何かを振り返るのが良いと思います。私の場合は「使っていて楽しいソフトウェアを作る」と言語化しました。ここでの「楽しい」とは、単なるデザインや遊び心に留まらない、**「ユーザーが本来の目的にストレスなく到達できる、心地よい体験」**のことを指しています。高速なレスポンスや高い信頼性、安心してデータを預けられるセキュリティが、その体験を支える土台になると考えています。

それすらなく、方向性も定まらない場合はどうするか

ですが、これまでの経験からも漠然としたやりたいことすらない場合どうするかわからないという場合もあると思います。そこで、さらに抽象的に考えると良いと思います。 例えば、「生活を便利にしたい」、「健康で長生きできる社会にしたい」とかそういう感じです。

業界・業種はこのやりたいことを解決する手段でしかないので、まずはここから考えると良いかもしれません。とにかくどの方向を向くかが決まれば迷いづらくなります。

抽象から具体へ

漠然とやりたいことが決まったら、これを実現するための手段を考えました。 具体的な例(エンジニア以外向け)と実例(エンジニア向け)を示します。

例）「生活を便利にしたい」を叶えるために何が必要か

1. 生活を便利にするって具体的にどこが不便なんだろう（問題を考える）
   1. 買い物に行くのが面倒、届くまで時間がかかる
   2. 役所の手続きが複雑で何度も足を運ぶ必要がある
2. その不便さを解消する手段は何だろう（解決策を考える）
   1. ECやネットスーパーのように、欲しいものがすぐ届く仕組み
   2. 行政手続きをオンラインで完結できるサービス
3. じゃあ自分はどの立場で関わりたいんだろう（自分の役割を考える）
   1. サービスを作る側？運用する側？企画する側？
   2. 作るのはエンジニアリングスキルがないから無理だ
   3. 発想力はある気がするから企画をしてみたいかも

実例）「使っていて楽しいソフトウェア」を開発するには何が必要か

これは私が実際にやった例になります。

まず思いつくのは、使いやすいUIアプリに実装するということが挙げられます。ただ、これまでエンジニアをしてきてこれだけで実現できるわけではないと感じました。そこで、「UIのようなユーザが直接触る部分だけではない」と仮定し、「利用者からは見えない裏側も重要なのでは」と仮の問いを立てました。 そして、次の順序で考えました。

以下は私の思考の流れです。技術的な内容が含まれますが、この後STEP 3で整理するので、今は流れだけ追ってください

1. サーバサイド が複雑な実装になっている
2. UIも複雑になり、結果的に利用者は混乱する
3. サーバサイドを複雑にしないためには何が必要か？
   1. 利用者が何を求めているか、適切に要件を分析できる必要がある
      1. 利用者視点に立つには実際に利用者の立場で体験しないといけないな
   2. ドメインモデリング を適切に行い、単一の責任を持つモジュールを設計できる必要がある
   3. データ構造も工夫しないと将来的に膨大なデータを抱えた際に動作が遅くなったり、拡張しづらくなって結果的に遠回りすることになりそうだな
4. サーバサイドが複雑だとテストもしづらくなって、バグの温床になりそう
   1. テストしやすくするためにも設計技術は重要だな
5. 複雑さを解消するための保守に時間を割くと、ビジネス的にインパクトがある新機能開発に時間が割けないかもしれない
   1. これを説得するにはビジネスの視点で他業種の人に説明できるスキルが必要だ

というように、実現する手段をどんどん掘り下げていきました。つまり、今列挙したことが必要なことだと言うことができます。

原体験を振り返り、なぜそう思ったのかの説得力を持たせる

この抽象的なビジョンに説得力を持たせるために、自分の過去を振り返りました。

もともとプログラミングは好きでしたが、最初は完全に自分用のツールを作っているだけでした。転機になったのは高校3年生の時です。

この経験が、「使っていて楽しいソフトウェアを作る」というビジョンの裏付けになりました。それにこのような経験の積み重ねから必要な手段が思いついたのだと思います。面接でも原体験を交えて話すことで、ただの綺麗事ではなく自分の言葉として伝えられるようになりました。

STEP 2：自分の課題意識を深掘りする

これまで、「個人」の経験をベースに考えてきました。しかし、企業で働く場合は他者と協働する必要があります。企業が求めているベースはここにあるので、「個人」と「他者」でどのように動くかという部分にも注目します。

私の場合ここで役立ったのは「実務経験」でした。なぜかというと、他者と協力して開発をした経験だからです。実務経験がなくとも、バイトやサークルなども可能です。

コミュニケーションコスト

テキストでのやりとりに時間がかかる、口頭での情報共有をメモに残すだけでは細かいニュアンスが失われる。チームで開発していると、コミュニケーション自体がボトルネックになる場面を何度も目にしました。

おそらくこれはサークルでもバイトでも共感できる人は多いと思います。

データの管理コスト

Slack、Confluence、Google Driveなど、情報があちこちに散逸して探すだけで膨大な時間がかかる。実は、先ほど触れた学習管理アプリ「FrogNote」も、このようなデータ管理コストに課題を感じて作り始めたものでした。

こうして振り返ると、ビジョン（楽しいソフトウェアを作る）→ 具体的な要件（ストレスなく目的に到達できる）→ 課題意識（コミュニケーション・データ管理のコスト） という一本の線が見えてきました。

STEP 3：他の人が理解しやすいように構造化する

これまで私の例で説明してきました。かなり専門的な内容で、一部のエンジニア以外は理解できない内容が多かったと思います。

これが問題です。この状態では、どんなに考えても相手は理解してくれません。 面接では技術職でない人事担当者が同席することが多いです。全員に伝わる話し方をするために、内容を3つの視点に分けて整理しました。具体例を挙げます。先述した内容では、「顧客に提供する価値」のこと、「技術的」なこと、他職種との連携など「経営的」なことの３つに分けられると考えました。このように分けることで、技術的な内容がわからなくても、他の顧客、経営の話が頭に入りやすくなります。エンジニア面接の都合上、技術的な話はどうしても必要なので「技術」と「それ以外」で分ける対応をしたことになります。

この時、先述した手順で考えた「何をすべきか」と「なぜそう思ったのかの原体験」を紐づけます。また、より具体化したり、願望に変えます。

① 顧客視点

• 何をすべきか
  利用者が何を求めているか適切に要件を分析できる必要がある。そのためには、実際に利用者の立場で体験しないといけない。お客様の生の声を日常的にインプットし、仕様書に書かれていることの「一歩先」を考え、ユーザーの真の課題解決に繋がる改善案を提案できるようになりたい。
• 原体験
  FrogNoteを開発した際、自分が「便利だろう」と思って作った機能と、実際に利用者が求めていた機能にズレがあった。利用者から「便利だ」と言われた機能は、自分が想定していなかった使い方をされていたものだった。

② 技術者視点

ここにエンジニア特有の難しい内容を入れ、他の内容を理解しやすくします。

• 何をすべきか
  ドメインモデリングを行い、単一の責任を持つモジュールを設計できる必要がある。データ構造も工夫しないと将来的にパフォーマンスや拡張性の問題が起きる。テストしやすい設計も重要。また、実装に着手する段階から「なぜこの技術選定なのか」を自ら深掘りする習慣をつけることで、将来的にアーキテクトとして大規模システムの意思決定に携われるようになりたい。
• 原体験
  インターン中、データベースアクセス処理で同期/非同期メソッドが混在している箇所があり、実装中に疑問を感じていたのに質問しなかった。コードレビュー時に初めてその理由を知り、「なぜこうなっているのか」を自ら深掘りする習慣の重要性を痛感した。また、FrogNoteではパフォーマンスの課題でユーザーに不便をかけた経験があり、設計段階での技術的な意思決定の重要性を学んだ。さらに、インターン先では多くのCIが高速に動作したり、テスト環境を自動で立ち上げる仕組みが整備されていたことに驚いた。このような開発基盤があるからこそプロダクトの価値を高める活動に注力できるのだと実感し、開発時に抱えている問題は慣れると気づくことが難しいため、常に現状を疑うことが大事だと再確認した。

③ 経営者視点

• 何をすべきか
  サーバサイドが複雑になるとUIも複雑になり、結果的に利用者は混乱する。つまり、技術的な負債はそのままユーザー体験の悪化とビジネス上の損失に繋がる。「この施策を行うことでどのくらい開発が効率化され、どのくらいユーザへ価値が届けられ、どのくらい効果が得られるか」を常に意識して問題提起・解決を行う必要がある。
• 原体験
  個人開発でFrogNoteを運用する中で、機能を増やすほど保守コストが増え、本当に必要な改善に手が回らなくなる経験をした。限られたリソースの中で何を優先すべきかを考える視点が身についた。このような経験から、個人サービスを商用化まで実践し、コスト意識と事業を俯瞰する視点を培いたいと考えている。

STEP 4：実際に企業に当てはめてみる

ここまでで「自分がやりたいこと」を深掘りしてきました。これは志望理由書だけでなく面接の時にも役立つので、後から見れるように文章化してまとめると良いと思います。面接時の深掘りを想定して木構造にして管理するのもおすすめです。

例）業務効率化SaaSを開発している企業の場合

企業がやりたいことを調べる

企業が何をやりたいかは公式のホームページを見ればわかるはずです。 具体的に何を見るかを列挙します。

• 会社説明会資料（以下に書かれている全てが網羅的にわかります。企業が伝えたいことは全て詰まっています）
• 企業理念(STEP 1で作ったような抽象的な企業のやりたいことがわかります)
• 採用方針・募集要項（どういう人が来てほしいかの要望がわかります）
• IR情報（企業が力を入れたいことや財務状況など現実的な話がわかります）

例

この企業は、組織内の情報共有やコミュニケーションを円滑にしつつ、伝統的な業界の複雑な業務フローをエンドツーエンドでソフトウェアに置き換えている。ユーザーが細かい仕組みを知らなくても目的を達成できるサービスを提供しており、自分が課題に感じていた「コミュニケーションコスト」「データ管理コスト」の削減に正面から取り組んでいる事業である。

これまでのステップで考えた内容と関連付ける

自分がやりたいことと企業がやりたいことを関連づけましょう。

「私が課題に感じているコミュニケーション・データ管理のコスト削減に取り組みつつ、業務の仕組みごとソフトウェアで改善してユーザーが本来の目的に集中できる体験を作っている点が、自分の目指すソフトウェア像と一致した」

このように、自己分析で見つけた課題意識と企業の事業内容をリンクさせることで、「なぜこの会社なのか」に対する答えが自然と出てくるようになります。

まとめ

私が実践した自己分析のプロセスを振り返ると、こんな流れでした。

完璧な答えが一発で出ることはないと思います。私もこの過程を何度も行ったり来たりしながら、少しずつ言語化していきました。大事なのは、抽象から具体へ逆算するプロセスを回し続けることです。

この記事が、「自分は何をしたいんだ」と悩んでいる方の参考になれば嬉しいです。