はじめまして、昨年4月に新卒で入社した上田と申します。今日は一年目の業務の振り返りを兼ねて、働く中でプロダクトやチームについて考えたことをまとめようと思います。
先輩社会人のみなさまからすれば何を当たり前なことをと思われるかもしれませんが、最近まで学生だった自分にとっていろいろな驚きや発見があった一年目だったので、新卒時代を思い出しながら温かい目で見ていただければ幸いです。一方もうすぐ社会人、あるいは就活中などで社会人になるのが不安という方にとっては何か参考になることがあるかもしれません。ぜひ目を通していただければと思います。
記事の構成は以下のようになっています。まず、一年目の業務内容を簡単に振り返り、その中で難しいと感じたことや意識して取り組んだことについて紹介します。その後、タイトルにもあるように「プロダクト」や「チーム」というものについて、自分の考えたことを書こうと思います。
ポエム的な内容なので文字ばかりになりますが、ご容赦ください。
一年目の業務内容
まず、一年目の業務内容を簡単に紹介します。
入社後2か月程度の研修を終えて配属されたチームの目標 (当時) は、AppDriverという自社サービスの「データ最適化」を行うことで売り上げをアップさせよう、というものでした。
AppDriverではオファーウォール (以下、OW) というリワード広告の運用面をメディアに提供しています (OWのイメージもサービスページに載っています)。一口に「データ最適化」と言っても様々なアプローチが考えられますが、基本的にはユーザーや案件の属性に応じて表示される順番をコントロールしたり、あるいは表示の有無を制御したりすることになります。
チームでは以下の2軸を試していました。
- 機械学習を用い、ユーザーごと (あるいはユーザー属性ごと) に適切と思われる案件を表示する
- いままで営業担当が手動で設定していた内容から要素を抽出し、自動化する
機械学習にしても自動化ロジックにしても (以下、単に「モデル」と呼ぶことにします)、もちろん一度で完璧なものができるわけではないので、以下のサイクルで仮説検証を回すことになります。
- 売り上げが上がるような仮説を立てる
- 仮説を実証するためのモデルを作成、シミュレーションする
- モデルを本番環境に適用し、A/Bテストを行う
- 結果の分析を行い、モデルの性能を評価する
- モデルの欠点やさらに伸ばせそうな箇所を特定し、次の仮説を立てる
たとえば以下のようになります (仮説やモデルの中身は一例です)。
- 単価の高い案件が目につく場所に表示されていれば、売り上げが上がるのではないか？ という仮説を立てる
- システムを改修し、OWに表示する案件を単価の高い順番に並べられるようにする
- 一部のユーザー (A) に対して2.のモデルを適用し、適用しなかったユーザー (B) と売り上げを比較する
- 売り上げが上がったかを確認する
- 上がった場合、それが本当にモデルの影響だったのかを調べる。この場合は単価の高い案件の売り上げが上がることを期待しているので、単価ごとの分析を行う
- 上がらなかった場合、原因を調べる。単純に仮説が間違っていた (≒ モデルの性能が悪かった) のか、別の要因があったのかを確認する
- 4.の結果に応じて次の仮説や動きを考える
運用案件も担当することもあったものの、一年目は基本的に上記の仮説検証を回すことがメインの業務でした。初めは2.の機械学習モデル作成からキャッチアップを始めましたが、チームのフォロー体制も整っており、一年目の間に1〜5の全工程に関わることができました。
難しかったこと
業務の中で難しいと感じることが数多くありました。
モデル構築において
まず何よりも「プロダクト特性に合った仮説を立てること」「プロダクト特性に合った評価をすること」が難しいと感じました。機械学習であれば定番の指標としてf1 scoreやRMSEが使われますが、その成果指標を用いてOW上での並び替えを行えばいいわけではありません*1。
自動化ロジックでも、何を目指すのかによって結果が大きく変わってきます。単価の高い案件でコンバージョン (CV) を減らしてでも売り上げを稼ぐか、逆に単価を下げて多数のCVを獲得することで結果的に売り上げに繋げるか。営業やメディア、クライアントの意向も取り入れる必要があります。
作ったモデルを実際にデプロイするときも、考えることが多くあることに気づきました。代表的なのは処理速度やメモリ使用量の問題で、特に処理速度の問題が解決せずリリースが遅れたことがありました。
またこれはデータ最適化というプロジェクト特有の問題かもしれませんが、テスト環境と本番環境で違うデータを用いているのも問題になりました。テスト環境で本物の案件をCVするわけにはいかないので、基本的にテスト環境用の案件というものが用意されています。モデルの実装が終わった後テスト環境で実際に学習させ動作確認をすることになりますが、このとき案件の特性やデータ量が本番と違うため正確な確認が難しい、という状況がよくありました。
データ分析において
データ分析においても、難しいことは多くありました。代表的なのは、A/Bテストの結果を検定したものの有意差が出ないといった状況です。理由は様々なものが考えられますが、
- データ量が少ない
- 新規施策はどうしても売り上げ低下等のリスクを伴うので、検証の対象にするユーザーの割合を絞って行うことが多いです。
- 外的要因を強く受ける。よくある要因としては、
- 案件の制御はエンジニアだけでなく、同時に営業の判断あるいはメディアの意向を反映して調整がされることもある
- 案件ごとの人気の偏りが大きいため、一部の人気案件にCVの大部分が取られ、それ以外の部分でA/Bの差が出ない
等々がありました。
意識したこと
前節で「難しいと感じたこと」を長々と書きましたが、これは必ずしもネガティブなことではないと思っています。
業務内容において
最初のうちは、「難しいということを理解する」というのを意識してやっていました。「理解する」と書いた通り、ただ難しいと感じて諦めるのではなく、なぜ難しいのか？ 簡単にできることとできないことの違いは何か？ を考えるようにしていました。
特に、自分の得意だったり経験のある領域と比較することで、何が違うのか、あるいは何が同じなのかが見えてきます。自分の場合は学生時代に物理学を専攻して研究をしていたり、競技プログラミングやKaggleに触れたことがあったりので、それらと比較することになります。たとえば
- 評価指標を最適化するのではなくて、その後の売り上げを最適化しなければならない
- 売り上げはモデルの性能以外だけでなく、数多くの外的要因に左右される
- ロジックを実装するだけではなくて、処理速度やメモリ使用量を現実的な範囲に抑える必要がある
- これは競技プログラミングでも考慮しなければいけない内容ですね。
- 開発リソースには限りがある
- 研究や趣味の開発、競プロ等のゲームもそうですが。
- 研究とは違いあくまでもビジネスでやっているので、コストとリターンを考える必要がある
等々。多くは当たり前の内容であり前節で書いた内容と重なりますが、これらを明確に意識するだけで、単に「業務でやる機械学習/データ分析は難しい」という状態から「難しいが、その理由がわかっている」という状態に遷移することができました。解決策がわかるのが次の段階ですが、新卒にそこまでは求められていません (と勝手に思っています)。
新卒としての働き方において
上述の比較を通して、「自分の得意な領域」「苦手、あるいは経験の浅い領域」というのを改めて認識しました。自分の場合、得意な領域は
- 数学や理論的な内容
- 定量データの認識
苦手 (経験の浅い) 領域は
- 開発、特に設計
- インフラ
- システムや言語ごとのアーキテクチャの理解
等です。
様々な考え方があると思いますが、自分はまずは得意な領域を伸ばすことを意識してやっていました。弊チームはデータ最適化を推進しているとはいえ、設立から日が浅く大多数のメンバーはこれから機械学習や統計の勉強をしていくという段階でした。その中で、自分の数学や理論的な能力はチームに足りていない部分をうまく埋められると思い*2、特に最初のうちは「自分はその領域が得意である」ことを意識して伝えるようにしていました。
具体的には、配属直後という早めのタイミングでメンバーに混ざって実際のモデル構築を試してみたり、モデルの比較・検討の会議では「機械学習でできることとできないことをしっかり見極める必要がある」という俯瞰的な視点に立って積極的に意見を出したり、等です。
一方で開発やインフラ、アーキテクチャなど実際のシステムに関わる部分はほとんど経験がなかったため、積極的にヘルプを求めながらやっていました。頻繁に質問するのは当たり前なので遠慮せずにとよく言われますが、「ここは自分の苦手な (経験の浅い) 領域」というのがしっかり認識できていたので、「質問するのは当たり前」という意識をより強く持つことで変に気が引けずに質問しにいくことができました。
プロダクトについて考えたこと
入社一年目は、研修期間を除けば基本的にAppDriverというひとつのサービスに関わっていました。学生のときにあまりなかった視点として、「ひとつのプロダクトとして考える」というものが生まれました。
うまくいかなかったとき
たとえばA/Bテストの結果、「モデルの性能がよかったかどうかは何とも言えない」という結論で終わってしまった場合。統計的には有意差が出なかった以上は何も言えないので、ひとつの施策としてはこれで終わりになってしまいます。このとき、次の動きへどう繋げるか？ という考え方が大事になってくることを学びました。
- 改めて別の期間でA/Bテストを実施する
- 有意差が出なかった要因を推定し、それが外的要因であれば取り除いて再度A/Bテストを行う
あたりが理想的ですが、時には諦めるという選択肢も必要になってきます。ビジネスでやっている以上無限にリソースがあるわけではありませんし、悪くこそないもののいまいち効果の出ない施策に固執して無駄に人的リソースや開発コストを割き続けるのは、プロダクト全体の売り上げに対してはマイナスに働いてしまいます。
この点は考えてみれば当たり前ですが、学生のうちはなかなか意識していない点でした。ひとつのモデルや施策のことだけを考えるのではなく、この取り組みは長い目で見たときにプロダクトにとってプラスになるか？ という視点で考えることが重要です。もちろん、すべてをその場で判断できるわけではありませんが。
ステークホルダーとの関わり
また、プロダクトに関して「ステークホルダーが多い」という点も業務を通して実感しました (あくまで自分の主観であり、世間一般の組織やプロダクトと比較してどうかという話ではありません)。AppDriverの場合は社内のエンジニアや営業、マネージャーに加え、広告プラットフォームというサービスの特性上、社外の関係者もメディア、クライアント、そしてユーザー... と多岐に渡ります。
ステークホルダーが多いことは、意思決定に時間がかかったり検証における外的要因が増えたりという点でデメリットになることもありますが、AppDriverのデータ最適化においてはメリットにもつながっていると感じています。主にエンジニアと営業の関わりという話に絞っても
- スプリントレビュー等で定期的に意見交換することで、エンジニアだけでは気づけなかった問題点に気づくことができる
- 逆にエンジニアからもビジネス的な視点での提案ができる
等があります。上のようなメリットを享受するためには単にステークホルダーが多いだけではだめで、しっかり連携ができていることが必要だと感じました。たとえばAppDriverをはじめとする自社サービスでは「プロダクト目標」のようなものが策定されており、エンジニアと営業が同じ目標を見据えて動けるようになっています。
営業との関わりが強く「エンジニアからもビジネス的な視点での提案ができる」という点は強みだと思っています。単に風通しがいいというだけではなく、分析の上でもビジネス的な視点が重要になってくることは多かったです。A/Bテストに悪影響を及ぼすような外的要因を把握できたり、時には定量データだけでは思いつかないような、定性データに基づいたモデルの案が出てきたりすることもありました。
チームについて考えたこと
前節で営業との関わりについて書きましたが、とはいえ普段の業務は4人程度のチーム単位で動くことがほとんどでした。最初は不安も多くありましたが、チームメンバーとして業務をこなしていく中でいろいろなことを感じました。
さまざまな人がいる。それぞれ得意な分野が違う
言語やフロントエンド・バックエンドのようなジャンルにおけるスペシャリストがいるのは想像していました。たとえばAppDriverでは主要な言語 (フレームワーク) としてVue.jsとScalaを利用しており、それぞれのスペシャリストと呼ばれるような社員も存在します。
ただ、「それぞれ得意な分野が違う」というのはもっと広い話でした。言語に限らず「プロダクト思考で考えるのが得意な人」「チーム外との調整が得意な人」等々、メンバーそれぞれが様々な分野で活躍できる能力を持っていると改めて実感しました。
自分の強みを見つけること
その中で、うまく自分の強みを見つけることができたと思います。自分の場合は前述した通り「数学や理論的な内容」「定量データの認識」等でした。
ここで自分の強みというのは単なる自己分析の結果ではなくて、チームにおいてそれが求められているか？ という観点も含めてのものです。早い段階でそれを見つけチームに主張することで、メンバーから信頼されて素早くチームに溶け込むことができると感じています。一度信頼されれば、多少無茶な提案をしても任せてもらえるようになります。
もちろん、自分の強みを自分だけで見つけるのは難しいです。ただ、弊チームの場合 (そして世間の一般的なチームはそうだと思います) はマネージャーとの定期的な1on1やメンバー間評価などを通して、周囲の人の意見を聞く機会が多くありました。その中で自分の長所・短所を客観的な目で見つめることができ、さらに「チームにおいて自分に求められていること」の認識を合わせることができました。
一年目はついていくのが精一杯かと思っていましたが、思ったよりうまく動けたと感じています。
自分の得意な分野をチームに広げていく
自分の得意な分野とチームでの立ち位置を認識したら、次はチームにその分野を広げていくことが重要だと思っています。各メンバーの得意な領域があまりにも離れていると属人化が進み、チームとしての対応能力が下がってしまうためです。
自分の場合はチームの状態をよりよくするために、以下のような動きをしていました。
- 施策の結果分析は行なっているが、メンバーが独自に行なってまとめて共有するだけで終わってしまう。
- → スプリント途中のレビュー機会を増やしたい。早めにメンバーの意見を取り入れ、限られた時間でより効率よく分析を進めたい
- エンジニアリングは得意なメンバーがほとんどだが、機械学習や統計等の理論について体系的に勉強したメンバーが少ない
- → チーム内勉強会の実施、推進
勉強会といっても分厚い教科書をメンバーそれぞれで読み込んでくるような時間はないし、求められてもいません。そこでこの資料のような簡潔にまとまっているものを用いました。もちろん知識のない状態でこれだけを読んでもすべてを理解できるわけではないですが、そういうときは自分を始め、すでにある程度理解しているメンバーが議論の穴を埋めることで、効率よく知識のキャッチアップを進めることができました。
終わりに
振り返りなのかポエムなのか自慢なのかよくわからない内容になってしまいましたが、以上のようなことを考えながら一年目の業務をこなしていました。エンジニアに限定しても個人のスタイルやプロダクト・チームの状態によって業務内容は当然大きく変わってきますが、一年目の業務の雰囲気や新卒が普段どんなことを考えているのかについて、少しでも参考になることがあれば幸いです。
偉そうなことを長々と書いてしまいましたが、自分の強みを活かして楽しく働けているのはまず第一にメンバーやマネージャーのおかげです。そこの感謝は忘れないように今後も頑張ろうと思います。
