ポートフォリオ開発に向けて

ポートフォリオは、採用担当者や営業先が「あなたに何ができるか」を把握し、あなたの提案を採用するかどうかの判断材料として役に立つ。

企業があなたの提案を採用するかどうかは、投入コストに対して得られる利益が大きいかどうかに尽きる。しかし企業ごとに課題も求められる技術レベルも異なるため、本来はそれらを踏まえた題材決め、言語とフレームワークの選定、最適な設計を行う必要がある。既存サービスのクローンを安易に流用しても高い評価は得られない。

そこで、まずは自分や周囲の人の悩みを解決したり、好きなことを深堀りしたりするサービスを作ることから始めるのがおすすめである。目の前の課題解決を目的としてプロダクトを開発し改善していくプロセスはどんな企業でも求められ、試行錯誤を繰り返して課題解決に取り組んだ経験はアピールポイントになる。

企業の採用面接などでは、「なぜ」や「その結果どうなったのか」がよく問われる。

このような問いに対して、要件につなげた回答を用意しておけると良い。

ポートフォリオ開発（開発系）は以下の流れで進めていく。

まず、誰のどんな課題を解決しようとしているのか、どのようなサービスによってその課題を解決できるのかを整理する。具体的には以下の質問に対して回答して、サービス内容を明確にしておこう。

あくまで、ユーザー視点で価値のあるサービスが作れるように意識しよう。

サービスの内容について整理できたら、次に要件（何を実現するか）を決定する。ユーザーストーリー（テンプレート：【何】を目的として、【誰】が【何】をできるようにする）を列挙した後、グループ別に整理していくと簡単に要件を整理できる。簡単な読書管理アプリの要件の例を以下に示す。

要件が決まったら、必要な画面を洗い出して画面遷移図を作成する。ここで、画面デザインの詳細を決めてもよいが、課題を解決する上でデザインの詳細はそれほど重要でないことも多い。そのため、今回はシンプルに四角と文字だけで画面遷移図を以下のように表現する。

画面遷移図を作成するときは、ユーザーの課題を解決できるか、ユーザーにとって使いやすい導線になっているか、無駄な画面が含まれていないか、ルーティングの設計がおかしくないかなどを意識しておくと良い。

続いて、データベース設計を実施する。ここでは、データベースに保存するテーブル同士の関係をER図で表現する。

データベース設計を実施するときは、適切に正規化されているか、アソシエーション設定に過不足がないかなどを意識しておくと良い。

画面遷移図とテーブル設計が完了したら、要件をタスクに分割して開発作業を進めていく。

開発が一通り完了したら、要件を満たしているかテストする。思わぬ箇所で実装漏れしていたり、後半での変更の影響で最初の方に作った機能にバグが生じていたり、ローカル環境では動くが本番環境では想定通り動作しなかったりといったことがよくあるので、サービスの品質を担保するためには開発完了後のテストが重要になる。

テストが完了したら、サービスを実際にユーザーに使ってもらって、サービスに対するフィードバックをもらい、どんどん改善していく。このような改善を何度か繰り返すことで、サービスの質がさらに向上する。

ポートフォリオ開発（データ分析系）では、機械学習を用いたサービスの開発、分析レポートの作成、データ収集・加工のパイプライン構築などといったデータ分析に関わるアウトプットを作成する。

開発プロセスより、課題をどう解決するかのアプローチ方法を重視し、以下の流れで進めていく。

まず、誰のどんな課題を解決しようとしているのか、どのようなサービスによってその課題を解決できるのかを整理する。具体的には以下の質問に対して回答して、サービス内容を明確にしておこう。

あくまで、ユーザー視点で価値のあるサービスが作れるように意識しよう。

選択したアプローチ方法で課題を解決するための分析・開発を進めていく。

分析、開発が一通り完了したら、実際に選択したアプローチ方法で課題を解決できるのかを検証する。

検証結果を参考にアプローチを修正し、サービスをどんどん改善していく。このような改善を何度か繰り返すことで、サービスの質がさらに向上する。

ポートフォリオの作成前にどんな点に気をつけておけば評価されるポートフォリオが作れるのか確認しておこう。以下に評価されるポートフォリオの特徴をいくつか示す。

どこかで見たことのあるようなサービスだと、興味を抱かれず、評価もされにくい。独自の視点から、日々の問題意識が伝わってくるようなテーマが選択されていると評価が高くなりやすい。

習得したばかりの技術を詰め込んだ独りよがりなサービスではなく、ユーザー視点で、よりサービスが理解しやすく使いやすくなるように設計されていると評価が高くなりやすい。

しっかりテストが実施されていて、サービスが安定して動作すると評価が高くなりやすい。自動テストなどバグが混入しないような仕組みがあるとなお良い。

動けば良いという感覚で汚いコードを書いていると、サービスを運用し、機能追加していくコストは大きくなる。エンジニアはそれを身にしみて理解しているので、コードが汚いと一緒に働きたくないと思われる。

コードをバージョン管理でき、簡単に変更箇所の確認や変更前の状態に戻すことのできるGitとGitHubはほぼ必須の技術。

他のポートフォリオと一番差をつけやすい部分。実際にサービスを運用していくことで、サービスは洗練され、より良いものになっていく。