おじさん Product Manager サバイバル戦記 2017 (ShanonAdventCalendar2017・15日目)

このエントリーをはてなブックマークに追加
皆様こんにちは。シャノンでプロダクトマネージャーを担当している gacky です。
おじさんプロダクトマネージャーの皆さん、今年も無事生き残れてますか?
この記事は、Shanon Advent Calendar 2017 の15日目と Product Manager Advent Calendar 2017 の15日目を兼ねた投稿です。

昨年は「おじさん Product Manager サバイバルガイド」と題して、アラフォー世代のおじさんプロダクトマネージャーの戦い方について考えてみました。
今年はケーススタディとして、実際の製品開発におけるおじさんプロダクトマネージャーの奮闘ぶりを検証していきたいと思います。果たして、プロダクト開発の現場において、おじさんの貫禄を見せることができたのでしょうか?
なお、一部「それってプロダクトマネージャーの仕事じゃなくね?」とツッコミが入りそうな内容も含んでいますが、そこはご容赦ください。


今回のお題:シナリオ機能

今回取り挙げる事例は、2017年10月にリリースされたばかりの新しい「シナリオ機能」です。
シナリオ機能とは、あらかじめ決めたルールや設定に基づき、様々な処理を自動的に実行できる機能です。マーケティングオートメーション製品における基幹機能の1つで、定期的に行う定型処理を自動化したり、登録したシナリオに基づいて見込客とのコミュニケーション (メール送信など) を自動実行するといったことができます。

シャノンにはプロダクトマネージャーが4名在籍しており、SHANON MARKETING PLATFORM という大きなプロダクトを、機能群単位で分担しています。私が担当する機能群の中で、今年最も規模が大きかった取り組みが、このシナリオ機能のリニューアルです。

今回のミッションは、 「オートメーション機能を半年間で全面刷新し、製品の魅力を向上させる」 こと。
SHANON MARKETING PLATFORM は、国内の統合型マーケティング支援 SaaS 市場において7年連続でシェア1位 (*) を獲得している製品ではありますが、さらに多くのお客様にご利用いただくためには、現状に甘んじることなく製品を磨き続け、魅力を高めていく努力が欠かせません。
さて、わずか半年間で、どこまで魅力的な機能に仕上げることができるか。プロダクトマネージャーの腕の見せ所です。
(*) 出典:ITR「ITR Market View:マーケティング管理市場2013~2017」売上金額ベースでの2010年度~2016年度 (予測値)シェア


立ちはだかる様々な問題

オートメーション機能の刷新にあたって、最初は既存機能の改修も検討しましたが、機能的に中途半端なうえ、何よりもインパクトに欠けます。結局、「シナリオ機能」の呼称のもと、ほぼ新製することとなりました。
しかし、様々な問題が立ちはだかります。
  • そもそも機能が難解
    • 新しいシナリオ機能は、基本概念からして既存機能とは全く異なるので、まず作り手が要求仕様を理解するだけでも大変です。
  • 開発期間が半年しかない
    • 企画から正式リリースまでを、わずか半年で終わらせる必要があります。
      お披露目は11月14日のカンファレンス。リリースの遅延は許されません。
  • 既存機能との横断的な連携が必要
    • シナリオ機能は、たくさんの既存機能と連携しながら動作するのが特徴です。
      機能別の開発チームと、シナリオ開発チームの間で、たくさんの調整が発生します。
  • エンジニアが東京と上海に分散
    • 一部の開発メンバーは中国・上海にいます。東京と上海のエンジニアが協力して開発を進めなければなりません。

さらに、シナリオ機能の新製においては、いくつかの新しいチャレンジにも取り組むことになりました。
  • 新しいシステム基盤の採用
    • かねてより構築中だった、マイクロサービスと非同期処理から構成される新システム基盤を採用することに。しかし、エンジニアたちはまだ慣れていません。
  • SPA ライクなアプリに初挑戦
    • シナリオ作成のフロントエンドを担うシナリオエディタは SPA (Single Page Web Application) ライクな形態をとることに。しかし社内に本格的な SPA の開発経験者はいません。

こうした数多くの問題とチャレンジを乗り越え、製品開発を成功させるために、プロダクトマネージャーにはいったい何ができるでしょうか?

プロダクトマネージャーが、なすべきこと

とはいえ、プロダクトマネージャーがなすべきことは、極めてシンプルです。
以下の4点に対して、ただひたすら愚直に取り組むのみです。
  • 要求 (=作るべきもの) を明確に示す
  • 要求と成果物 (=作られたもの) をできるだけ一致させる
  • 限られたリソースから、最大限のアウトプットを引き出す
  • 製品に「勢い」をつけ、社内外の興味・関心を惹きつける

実際にやったこと

今回のプロジェクトの最大の特徴は、開発にたくさんのメンバーが関わること。チームをまたぎ、機能をまたぎ、国境をまたぐ開発プロジェクトです。それはまるで、複数の建設会社が JV (Joint Venture) を組んで大規模な建設工事に取り組むかのようです。
よって、開発メンバー間のコミュニケーションをいかに円滑にするかが、製品開発の成否を大きく左右します。

1. 開発コンセプトの言語化と機能の絞り込み

競合製品のいくつかは、とても充実したオートメーション機能を擁しています。しかし多くの場合、いわゆる「2:8 の法則」が働き、よく使われる機能は一部に偏ります。利用頻度の低い機能を増やしても、多くのお客様をハッピーにすることはできませんし、むしろ製品の分かりやすさや使いやすさを損なうこともあります。
そこで "Simple, Easy, but Powerful" をキーワードに、誰でも簡単に使いこなせるシンプルなシナリオ機能の実現を目指すことにしました。本当に必要な機能を厳選して絞り込み、開発期間を短縮する一方で、コンセプト実現に欠かせない機能は決して妥協しない姿勢を貫きました。
製品仕様の判断に迷ったとき、最後の拠り所となるのはコンセプトです。できるだけ早い段階から、コンセプトを分かりやすく言語化しておくことが重要です。

2. ゴールイメージの徹底的な共有

開発メンバーに対しては、開発コンセプトとともに「何を作るのか」「なぜ作るのか」を明確に示し、ゴールイメージ (製品仕様や、製品化したときの利用イメージなどの総称) を大量のドキュメントに吐き出して、徹底的に共有しました。
プロダクトが出来上がったときに「思ってたのと違う」という感想が出るのは、当事者間でゴールイメージがずれているからです。特に、製品開発に関わる人数が多い場合や、既存製品に類似機能が存在しない場合、実際の製品利用シーンがイメージしにくい (特に B to B 向け製品) 場合などは、ゴールイメージの共有の重要性は増していきます。プロダクトマネージャーが考えていた通りの製品を一発で作ることができれば、無駄な手戻りを減らせ、開発期間も節減できます。
プロダクトマネージャーからの大量のドキュメントに加え、UI デザイン担当者と協力して画面モックを早めに作り、プロダクトマネージャーの意図を「絵」にして開発メンバーとシェアする努力をしました。文字でいくら語っても「絵」の説得力にはかないません。

3. 用語の明確化と定義の統一

シナリオ機能は、グラフ構造を持ったシナリオに対して逐次処理を行うため、既存機能とは処理の概念が全く異なります。このため、「ステップ」「始点・終点」「適用開始・終了」「稼働・停止」など、オブジェクトや処理に対して用語を定めたうえで、ドキュメントでは徹底的に用語を統一しました。開発メンバー全員が共通言語を使って話せる状態を早期に作り、誤った仕様の解釈に起因する不具合や開発遅延を予防することが目的です。
ここで定義された「ステップ」「トリガー」「フィルタ」「アクション」などの用語は、多くが製品版にそのまま採用されています。
また、上海の開発メンバーにとってはカタカナ表記の用語が難解らしいということが分かったので、日本語ではニュアンスが伝わりにくい場合は英語表記も併用しました。
用語を解説するときは「ウォータースライダーのように...」とか「流しそうめんのように...」といったメタファを多用し、難解さの緩和にも努めました。

ちょうど先月開催された PM Conference 2017 の2日目、CAMPFIRE 小久保氏の講演「PMがUXするために必要なのはおそらくIA」の中で、名前をつけることの重要性に言及されていました。これには激しく同意します。名前重要

4. チームどうしの関係性の明確化

複数の開発チームをまたぐプロジェクトでは、全体における自チームの位置や役割、他のチームとの関係性を見失いがちです。こうした情報を分かりやすく供給して、開発チーム間での「お見合い」や「勘違い」による開発遅延の抑制を狙いました。
具体的には、以下のような工夫を行いましたが、やはり建設業界の JV に似てます。
  • 大規模な建設工事で用いられる「工区分け」を行い、第1工区~第10工区に分割。初回リリース時点で必須ではない一部工区は、方針だけを立てて2期工事に先送り
  • 工区同士の関係を表現するイメージ図を作り、開発者全員で共有する
  • 全チームの想定タスクを洗い出し、チームをまたいだタスク間の依存関係を明らかにするとともに、すべてのタスクに共通尺度に基づく優先度を設定する

5. 意思決定のアジリティを向上

開発期間が限られている以上、意思決定に無駄な時間をかけることはできません。Slack などのリアルタイムなコミュニケーションツールを活用するとともに、プロダクトマネージャーはできるだけ即断即決に努め、エンジニアを待たせないようにしました。
また、意思決定に関与する人数を極力減らし、一部を除いてプロダクトマネージャーの権限で仕様決定できるようにしました。特に UI 周りの議論は「パーキンソンの凡俗法則」に陥りやすいので、レビュープロセスの簡略化に努めました。
しかし、単に判断のスピードを上げるだけでは、ドキュメントと指示の乖離が起こりやすく、判断の意図や経緯も見失いがちです。仕様を変えたときは、すみやかにドキュメントに反映するとともに、その意図や仕様検討の過程、決定理由などを併記して「なぜそうなったのか」を残しておくようにしました。

6. 先行 PoC によるリスク低減

失敗が許されない大型プロジェクトでありながら、製品企画と技術の両面で、多数の新しいチャレンジを行いました。そこで、取り組みを複数段階に分けることで、プロジェクトが全コケするリスクを回避しています。
今回の場合、製品の肝ともいえるシナリオエディタの UI が、そもそも技術的に実現可能かどうか分かりませんでした。このため、まず短期の PoC プロジェクトで実現可能性を探ってから本開発に着手しています。
これ自体はよくあるプロジェクトマネジメント手法なのですが、さらに PoC の失敗に備えて "Plan B" の製品プランを練っておくのがプロダクトマネージャーの仕事です。

7. 期待値コントロールによるモメンタムの醸成

製品が与えるインパクトを最大化するためには「勢い」が必要です。この「勢い」を大きく左右するのが、製品に対する社内の期待値です。社内の期待感を少しずつ盛り上げつつ、リリース時点で製品がその期待値を超えられるように調整しました。
初期は社内向けの情報公開を絞り、敢えて「チラ見せ」にとどめていましたが、ある程度リリースが近づいてから、社内向けの説明会を複数回開催し、プロダクトマネージャーが自身の言葉で、製品の意味や価値を直接語る機会を設けました。
また、一部関係者向けのニュースレター「シナリオ通信」を毎月発行し、開発チームの外側から見たときのブラックボックス感の軽減にも努めました。

8. モチベーションの維持と達成感の創出

エンジニアが高いモチベーションを保ちながら、安心して開発に取り組めるような環境を作るうえで、プロダクトマネージャーの果たすべき役割は大きいです。特に、目標達成のためにエンジニアを無理やり誘拐召集したような場合はなおさら大切です。
また、開発メンバーに「やってよかった」「また一緒に仕事したい」と感じてもらうためにも、達成感を得られるような演出を忘れちゃいけません。
具体的には、以下のような工夫を行いました。
  • エンジニアには提案と「ポジティブな手抜き」を促す。開発コンセプトや顧客提供価値を損なわなければ、どんどん採用する。採用できなくてもプロダクトバックログに入れる。
  • いい提案には、笑顔で「イイネ!」と伝える。勢いよく「それだ!」と答える。些細なリアクションの違いでも、周囲に与えるポジティブさはけっこう変わる。
  • メンバーの仕事を妨げない程度に、ゆるい雑談を促す。雑談の中からいい提案が出てくるし、心理的安全性も高まる。
  • お客様や社内から好評価が得られたら、どんどんフィードバックする。開発メンバーにも手応えを感じてもらう。 
  • リリース時にくす玉を割ってお祝いする。実はリリース直前まで準備を忘れていて、台風が接近する中、深夜にドンキまで車を走らせたのはここだけの話。
本当はリリース後に打ち上げ会を開催したかったけど、関係者が多すぎて調整が難しく断念...
小さなくす玉でも、気分をアゲる効果はあります

結果、どうだった?

これだけの工夫を盛り込んだにもかかわらず、チーム間の仕様調整に起因するスケジュールの遅延が発生しました。しかし、開発チームの懸命な努力のおかげもあり、当初予定通り10月25日にプレスリリースで発表を行い、11月14日に開催した SHANON Marketing Conference で無事お披露目となりました。

今のところ、社内外から概ね好評を頂いております。初めて SHANON MARKETING PLATFORM をご覧になるお客様からは「シナリオが簡単で分かりやすい」「これなら使えそう」といった感想が寄せられました。一方、以前からご利用いただいているお客様からは「ずいぶんシャノンらしくない機能が出てきたな」という感想を頂きましたが、私にとっては最高の褒め言葉です。もう玄人向けとは言わせたくないですから。

こうした「手応え」が伝わってきたのか、社内の空気も少しずつ変わり始めています。新機能に対する社内の関心も高く、プロダクトマネージャーにもあちこちから質問が寄せられています。この社内モメンタムをブチ壊しにしないよう、サービスの安定稼働に努めつつ、引き続き社内外への啓蒙活動に取り組んでいきたいところです。
もちろん、初回は仕方なく開発を見送った機能もたくさんあります。まずは作りかけの機能を矢継ぎ早にリリースしますが、社内外の声に継続的に応えていきたいと考えています。

シナリオ機能の活用が本格化するのはこれからですので、製品としての評価がはっきりするには、もう少し時間がかかります。今のところは、概ね満足できるリリース内容だったと感じています。

おじさん視点での振り返り

では、昨年の記事に書いた「おじさんプロダクトマネージャーらしい戦い方」ができていたか?を振り返ってみます。
  • 回転数よりトルクで勝負する
    • 物量作戦に頼らない仕事ができました。
    • 最初に製品のゴールイメージを熟考し、大量のドキュメントとして一気に吐き出すところで、かなり体力を使いました。瞬発力の維持と、アウトプットの効率化が今後の課題です。
  • B to C より B to B で勝負する
    • この製品はもともと B to B 向けですが、シナリオエディタの作り込みでは、B to C 向けのスマートフォンアプリの経験がかなり役立ちました。
      「B to C の経験を B to B に注ぎ込む」という点では成功だったかもしれません。
  • SoE より SoR で勝負する
    • この製品はもともと SoR 的な製品ですが、シナリオエディタは SPA ライクな形態なので、SoE 的な開発スタイルの経験も役立ちました。
  • 人脈やヒューマンスキルで勝負する
    • エンジニアには達成感を提供できたと思いますし、製品に対する社内の期待感の醸成にもある程度成功したように感じます。
    • プロジェクトを通して、エンジニアとの間で築いた信頼感や安心感は、これから先の仕事で役立ってくるでしょう。
  • 個人よりチームで勝負する
    • 普段の所属チームや担当機能、さらには国境をまたぎ、開発メンバーのポテンシャルを引き出すことができたような気がします。
    • プロダクトマネージャーとしては、まだまだ個人スキルで戦っている状態です。この開発規模なら PM チームを組むべきだったかも?
  • 健康の維持に努める
    • 昨年悩まされた四十肩は治まりましたが、今度は慢性的な腰痛に悩まされてます。ときどきフェイタス5.0のお世話になってます。

プロセスや成果物でそこそこ貫禄を見せることはできたものの、自らプレーヤーとして活躍するのは、体力的に厳しくなってきました。スキルのポータビリティを高めて、若手プロダクトマネージャーを育成し、仕事を任せていくべき時期かもなぁ、というのが率直な感想です。

おわりに

プロダクトマネージャーの仕事において、コミュニケーションは本当に大切です。それが仕事のほぼすべて、と言っていいくらい大切です。
とはいえ、「コミュニケーション大事!」と耳にタコができるほど聞かされていても、「じゃ、具体的にどんなコミュニケーションをすればいいのさ?」という疑問に対する答えは、なかなか得られないものです。
今回のケースで紹介した工夫は、「用語を決める」「ドキュメントを作る」「雑談をする」など、極めて日常的で、ありふれたものばかりです。こうした些細な改善や工夫の積み重ねが、チームのアウトプットの差につながり、プロダクトの差につながっていくのだと思います。

なお、このケースでは、プロダクトマネージャーでありながら、具体的なモノづくりの現場までかなり深く首を突っ込んでいます。これは一般的にはアンチパターンとされていますので、あまりそのまま真似しないほうがいいと思うのですが、エンジニアとのコミュニケーションのあり方の事例としては、何かしらの役に立つかもしれません。
「プロダクトマネージャーは開発現場にどこまで介入すべきか?」については、またどこかで意見を述べたいと思います。

久しぶりの大型プロジェクトは、正直言って疲れましたが、たぶん来年末もプロダクトマネージャーやってるんだろうなぁ。来年もおじさんらしく頑張りたいと思います。

次の記事
« Prev Post
前の記事
Next Post »
Related Posts Plugin for WordPress, Blogger...