PMの責任は「これさえ解ければビジネスが成長する」問題の定義

2015年の6月に、サーバーサイドエンジニアとしてスマートニュースに入社しました。1年半ほど前からはアド（広告）のチームに入り、現在はプロダクトマネージャー（以下、PM）をしています。

スマートニュースのアドは、今、全体で年2〜3倍のスピードで成長していて。他社のIR情報などをみる限り、おそらく国内ではトップクラスの水準にあると思います。

僕の職務であるPMは、よく「ミニCEO」と呼ばれたりしますね。役割としては、プロダクトの意思決定はもちろん、チーム作りができていなければチームビルディングをしますし、人が足りなければ採用もします。

ただ、最も大きな責任は、「問題を定義できるかどうか」にあると思っていて。逆に「問題を解くこと」がPMの仕事だとは、僕はあまり思っていないんです。

正しく問題を定義して、チームのみんなが「それを解くことが素晴らしいことだ」と信じられる状態さえ作れれば、良いスパイラルが回っていくんですね。

我々は、「インパクトはそこそこだけど、解くのは比較的簡単な10個の問題」を解くのではなく、「すごく難しいが解いたら大きな意味がある1個の問題」を解いて、ビジネスを大きくしています。

このような志向を持っていると、優秀なエンジニアが平凡なエンジニアの10倍、100倍の成果を出せる環境が実現できます。すると、彼らが活躍することで、ビジネスを大きくするサイクルが回り、エンジニアに高い給料を払うことができるんです。

テクノロジーが進んでいる会社は、おそらくこういったやり方をしていると思うので、「社内の半分が科学者」みたいな状態も正当化できます。

逆にこういった開発スタイルができていないと、優秀な人も来ませんし、テクノロジーイノベーションも起こせないと思っています。

リリースサイクルに沿った3ヶ月ごとの仮説検証では、遅い

これを言い換えると、ちゃんと「スケールする」問題の定義をする、ということがPMの仕事の中に含まれると考えていて。

そのためにはまず、PM自身の中で仮説検証や問題定義の精度がしっかり上がっている必要がありますよね。

そのために重視しているのが、「歴史を振り返って学ぶ」ということです。

特にPMの場合、リリースサイクルってどれだけ早くても3ヶ月ほどの期間になるんですね。そうすると次の学びは3ヶ月後という話になって、それでは時間がもったいないし、全然間に合わないと思います。

そこで、歴史の中で仮説検証をするんですね。例えば2008年の広告業界の状態から、その3ヶ月後に何がどう変わっているか、の仮説を立てるんです。

「こういうものが作ってあるんじゃないか」「こういうサービスが流行ってるんじゃないか」という感じで仮説を立てて、実際に3ヶ月後の状態を見てみる。そうすると実際にそうであることもあるし、そうではないこともあって。

この仮説検証は、10分でできるわけです。そしてこれを繰り返すことで、感覚的には自分でリリースするよりも試行回数を10倍、20倍にできると思います。

大きなジャンプを生むためには、リスクを取り、目標設定は逆算で

また、大きなジャンプを生むために、目標は逆算で設定しています。

「1年後にユーザーあたり収益を3倍にする」といった厳しい目標を立てて、そこから逆算して考えるということを日々行う。これは、非常に重要な状況設定だと思います。

また、リスクを取ることも大事ですね。人間ってリスクを取れない生き物で、確度が高くて小さく成功するものを選びがちです。

成功するかわからない大きな変更というのは、上手くいくときはすごく上手くいくし、失敗したらすごく失敗する。みんな基本的には失敗を恐れるので、そういったものを避けがちなんですね。

なので敢えてそれを意識して、リスクを取った開発をかなり取り入れるようにしています。そうしないと絶対に、「倍の成長」といった規模感の大きなジャンプはできないんです。

例えば、今すでに行っている最適化処理をより精度高く行うことも重要ですが、これだけだと大きく成長できません。

そこで、今は全く存在してない最適化軸を取り入れるなど、既存の仕組みを大きく変えるような機能の開発を意識的に取り入れています。

ビジョンに沿った開発を行うための、日々のコミュニケーション

また、開発ロードマップを引くにあたっては、クライアントの要望1つひとつに順に対応していくのではなく、僕らが1年後、2年後に到達したいところから逆算して決めています。

このような開発方針は、大きな成長のためには重要だと考えていますね。特に広告の場合、プロダクトの特性上、「この広告主はこう言っているから、こういう機能を作りましょう」といったことも起こりやすいので。

また、何かを伝える際には必ず「Why / How / What」の順番でコミュニケーションするようにしています。

この順番が重要で、多くの場合はWhyだけを伝えれば、あとはエンジニアが最適な技術を選定して、その課題を解決してくれます。

なので、ビジネスメンバーがエンジニアに対してコミュニケーションをする際も、同様の考え方を求めます。

時には「この機能を作ってください」というWhatだけを伝えるコミュニケーションを見かけますが、そうではなく、Whyの部分から話してもらうように伝えています。

更に、社内のコミュニケーションは徹底的にオープンにしています。

その文化に慣れないメンバーからDMで質問が来ることもありますが、その場合、その場では回答せずに、同じ質問をオープンな場所で改めて出してもらい、そちらで返答するようにしています。

今スマートニュースが解きたい「難しい問題」とは…

広告配信の領域でもずいぶん自動化が進みましたが、まだまだ労働集約的な仕事がたくさんあります。このようなものを、どんどん機械で代替していきたいと考えています。

そして、広告に限らずスマートニュース全体としては、我々独自のデータ分析技術と機械学習によって、人の「興味を広げる」コンテンツの配信を機械でできるか、という問題に取り組んでいます。

と言うのも、短期的なユーザーの反応を使ってパーソナライズを行うと、知らず知らずのうちに偏った情報しか摂取していないという状態に陥ってしまうんですね。

有名な例で言えば、検索エンジンに全く同じクエリ（検索ワード）を入力しても、その結果は人によって異なります。

これはいわゆる「フィルターバブル」と呼ばれる状態です。スマートニュースはこのようなやり方ではなく、人の知識や興味の幅が広がるような発見がある「パーソナライズド・ディスカバリー」を実現したいと考えています。

これが今、僕らが技術でなんとかしたいと思っている問題のひとつです。まだまだ難しいですが、どんどん良くしていきたいと考えています。

僕がスマートニュースの広告部門に入った理由のひとつに、エンジニアとして、技術がボトルネックになっている業界で働きたいと考えたことがあります。

技術がボトルネックになっているからこそ、そこに世界中の人が投資していて、競争も激しい。こういう世界で働くことは、本当に面白いと思いますね。（了）