プロジェクト経験を「表面的なもの」から「価値のあるもの」に変える方法

多くの人のプロジェクト経験の履歴書は長くて内容が豊富ですが、内容が欠けています。この記事では、プロジェクトの難易度が低い、思考の深さが不十分など、プロジェクト経験の記述でよくある問題を分析し、プロジェクトの困難さと課題を反映することと、プロジェクトの目的と設計のアイデアを詳しく説明することという 2 つの改善戦略を示します。履歴書を調整する必要のあるあらゆる分野の人々におすすめです。

多くの人の履歴書には共通点が 1 つあります。それは、履歴書が日記であるということです。

特にプロジェクト経験の部分では、多くの内容が書かれているように見えますが、よく見ると、最初に何をしたか、次に何をしたか、といった内容ばかりです。基本的には、自分がやってきたことを時系列順に話しただけです。

この状況は非常に一般的です。このような履歴書をどのように修正すればよいでしょうか?

1. 問題の顕在化

経験が 1 ～ 2 年しかないデータアナリストにとって、本格的なプロジェクトに参加する機会を得ることは確かに困難です。

日常業務の時間の 70 ～ 80 パーセントは、要件の達成、基礎となるコードの作成、データの取得に費やされます。ニーズを分析しても、それをいわゆる「プロジェクト」と結びつけるのは難しいようです。

しかし、履歴書のテンプレートには別のプロジェクト経験も求められているため、自分が行ったことを順番に書くことしかできません。

データレポートの作成を例にとると、通常は次のように記述されます。

ビジネスの監視とパフォーマンスの測定という企業のニーズを満たすために、データレポートを構築するプロジェクトが開始されました。プロジェクトでは、会社の業務に適したデータレポートツールを調査・推奨し、データレポートの構造とレイアウトを設計し、最終的にデータレポートを自動的に生成するレポートコードを作成しました。

データレポートの確立は、データアナリストの基本的な仕事です。仕事内容は比較的定型化されており、上手に書くのは確かに難しいです。

ハイライトを抽出するにはどうすればいいですか?

2. 反映された状況

プロジェクトの経験は進行中の記録として記述されており、次の 2 つの問題を反映しています。

プロジェクトは難しくありません: プロジェクトは難しくなく、困難は発生しませんでした。
深く考えないこと：仕事内容は割り当てられ、プロジェクト自体について深く考えない。

2.1 プロジェクトは難しくない

プロジェクトでは、最初にやりたいこと、次にやりたいことを時系列順に実行し、最終的なプロジェクトが完了するまで段階的に進めることができます。これは、これまでの計画がすべて実現されたことを示しています。プロセス中に予期せぬ出来事は発生せず、プロジェクト自体は難しくないことがわかります。

したがって、あなたの履歴書にあるこのプロジェクトが最終的に完了したとしても、それは単にあなたが幸運で、あらゆる面で豊富なリソースを備えたプロジェクトの背景に遭遇したからかもしれません。プロジェクトのリソースが不足すると、問題が発生する可能性があります。

したがって、このプロジェクト経験は、以前にそれを実行したことがあるということだけを意味し、再度実行するという意味ではありません。

2.2 思考の深さの欠如

プロジェクトについて十分に深く考えなければ、何をしたかは言えても、なぜそれをしたかは言えません。

あなたは何をすべきかしか知りません。これは、上司があなたに割り当てたタスクが比較的妥当なものであったため、このプロジェクトの成功に対する最大の功績は実際にはあなたの上司にあることを示しています。

あなたはこのプロジェクトの実行者にすぎません。別のシナリオで新しいレポートを作成するように求められた場合、それを完了できない可能性があります。

こんな話があります。大きな工場にとても重要な機械があります。ある日、機械が故障してしまい、正常に動作しなくなってしまいました。多くの修理業者を呼んだにもかかわらず、問題は解決できませんでした。ついに彼らは国内で最も有名な整備士を見つけた。整備士は辺りを見回し、ようやく位置を見つけてノックすると、機械は正常に動きました。上司は非常に嬉しくなり、興奮して尋ねました。「問題を解決するのにハンマーを1本しか使わなかったのに、いくらかかったのですか? すぐに支払いますよ。」修理工は「10,000元かかります」と答えた。上司は非常に驚いてこう言いました。「一度打っただけで1万ドルもかかるのか？」修理工はこう説明した。「ハンマーで一回叩くこと自体は1ドルの価値しかないが、どこを叩くかを知ることは9,999ドルの価値がある。」

思考が深くなければ、仕事はただハンマーを叩くことだけになってしまいますが、本当に価値があるのは、なぜそのように叩くのかを知ることです。

したがって、詳細なプロジェクト経験が不足しているということは、単にそれを実行したということであり、それを実行する方法を知っているということではありません。

3. 問題の解決策

シンプルな体験をより効果的にしたい場合は、2 つの側面を強化する必要があります。

解決策1: 問題点を指摘する

一般的に、プロジェクトの実施には何らかの困難が伴いますが、履歴書にその困難を書かなかったり、面接の過程で反映されなかったりする人もいます。

プロジェクトの実施中によくある困難には次のようなものがあります。

時間が限られており、タスクを計画通りに完了できない
人材、技術、資金などの必要なリソースが不足している。
プロジェクトの目標は不明確であり、要件は頻繁に変更されます。
プロジェクトメンバー間のコミュニケーションと連携に問題がある
新しい解決策の研究と実験を必要とする技術的な問題

あなた自身のプロジェクトの経験を振り返って、そのような問題があるかどうか確認できますか?次に、履歴書に一文を記載します。

たとえば、プロジェクトのスケジュールが厳しかったため、レポートシステム全体の構築は 3 つのステップで実行されました。第 1 フェーズではコア運用指標監視ダッシュボードが完成し、第 2 フェーズではトラフィック関連の詳細レポートが完成し、第 3 フェーズではその他の詳細レポートが完成しました。このように書くと、面接官は当然「なぜこの3つのフェーズに分けたのか」と質問するでしょう。トラフィックが他のスケジュールよりも優先されるのはなぜですか?この答えは必ず事前に準備しておくことができます。このインタビューの質は、あなたの最初の平凡な説明よりも深い印象を残すでしょう。

解決策2: 奥行きを加える

一般的なプロジェクト経験はログです。深みを加えるには、結果とその背後にある理由の両方を知る必要があります。

レポート作成のようなプロジェクトの深さについて話したい場合は、通常、次の質問について知っておく必要があります。

なぜこれらの指標なのでしょうか?
なぜこのような報告があるのでしょうか?
なぜこの順番になっているのでしょうか？
なぜこのようなチャートなのでしょうか?

（１）なぜこれらの指標なのか？

なぜこれらの指標なのかという質問に関して。多くの人はそれについて深く考えたことがありません。現在、インターネット上には成熟した指標システムが数多く存在します。直接塗布することに慣れている人もいます。この方法は確かに非常に効率的ですが、面接では必ずしも最良の回答とは言えません。

指標の設計は、まず自社の事業特性を踏まえて行う必要があります。どの企業の事業も全く同じということはありません。

売上変換ビジネスでもあります。仮想商品では供給指標システムを構築する必要はありませんが、物理的な電子商取引では供給側の指標が必要です。 APP 操作の場合、高頻度 APP のユーザースケールを見るときに dau が一般的に使用されます。しかし、比較的使用頻度の低いアプリでは、主に wau または mau が使用されます。

指標は空から降ってくるものではありません。自社の事業特性に応じて必要な指標を整理する必要があります。

（２）なぜこのような報告があるのか？

この質問に対する答えは、レポートを設計する際の目的によって異なります。たとえば、最初の表は上級管理職が閲覧するためのもので、中核となる営業実績のみが含まれています。このレポートでは、コア指標を洗練させ、上級管理職がコアビジネスの進捗に集中する際に、指標が多すぎて気を散らされることがないようにしています。

5 つのテーブルは、それぞれトラフィック、マーケティング、および供給の目的を表します。レポートには、各ビジネスラインマネージャーの KPI の進捗状況とディメンション別の詳細データが含まれています。最後に、特定の運用アクションを毎日監視するための 3 つのテーブルがあり、現時点で最も重要な 3 つのビジネス戦略を監視します。これらは主に、具体的な実行を担当する運用スタッフを対象としています。こうすることで、レポートのロジックが非常に明確になります。

（３）なぜこの順番になっているのでしょうか？

レポートのデザインは単純な積み重ねではありません。多くのレポートシステムの構築で最終的に発生する問題は、レポートは非常に完全であるにもかかわらず、それを使用する人がそれをまったく見つけることができないということです。適切に設計されていれば、表から多くの情報を明らかにすることができます。

たとえば、これは交通関係の同僚に見せるレポートだと言うことができます。上部にはトラフィックエンドの KPI 進捗状況、中央にはさまざまなチャネルのトラフィック傾向、下部にはトラフィックの各プロセス指標の詳細データを配置します。

このように設計されている理由は、運用担当者がこの表を見るとき、通常は最初に最初の表を見て、目標の進捗状況を追跡するからです。最初の表の KPI の進捗が期待どおりであれば、それ以上下を見る必要はありません。 KPI の進捗が遅れている場合は、2 番目の表を見て、どのチャネルが遅れているかを確認します。どのチャネルであるかを確認した後、3 番目の表を見て、このチャネルのどのプロセスインジケータに問題があるかを確認します。

レポートが設計される順序は分析の順序を反映し、ビジネスに対する理解も反映します。

（４）なぜこのようなグラフになるのでしょうか？

この質問はもう少し詳細です。

一般的な BI ツールは、折れ線グラフ、棒グラフ、円グラフ、詳細な表など、複数のグラフの表示をサポートしています。では、レポートにはどの形式を選択すればよいのでしょうか?これもあなたの深い思考の一部です。この部分については詳しく説明しません。