Tech Blog

グローバルな家族アプリFammを運営するTimers inc (タイマーズ) の公式Tech Blogです。弊社のエンジニアリングを支える記事を随時公開。エンジニア絶賛採用中!→ https://timers-inc.com/engineering

プロダクトマネージャー、組織というプロダクトとも向き合う

Timersでプロダクトマネージャーしてます わた と申します。メガネとウイスキーとコーヒーを愛するメガネです。年末年始を見越して親族から「何か良いウイスキーを見繕ってくれ」と、まるでワインでいうソムリエのような依頼が来るまでになりました。

今回は「より良いものづくりのために、プロダクトマネージャーとして組織改善に立ち向かってます!」という仕事をしていたら、「もはや組織もプロダクトだよね」と思うようになったという話です。このブログの主な読者はエンジニアの方々かもしれませんが、開発するプロダクトの話でもあり、開発現場の組織の話でもあるので、実は身近な話だと思います。

なお、この記事は「Product Manager #pdmAC Advent Calendar 2017 - Qiita」の12/11担当分にもなってます。

プロダクトをプロジェクト制で開発する

2017年12月現在、Timersではプロジェクト制でのfeature開発を行なっています。

プロダクトマネージャーは「何をするか?」を決める仕事なので、「何をプロジェクトとして開発するか?」「プロジェクトの中で決める粒度のものでも、何をしたいか?」を意思表示し、それをプランニングし、開発可能なプロダクトバックログアイテム(主にユーザーストーリー)に落とし込んでいきます。一方、開発チームでは、プロダクトマネージャーが提示している課題を理解し、その課題解決のために最も優れたデザインやシステムがどのようなものであるか、どのように作るのか?を日々、考えています。

プロジェクト制の問題点

プロジェクトには納期があり、そして、必ず一定の条件を満たすと完了し、終了するという仕組みなので、皆、それぞれの立場で責任感を持ってプロジェクトにフォーカスし、仕事をしています。全てがうまく行っているとは言いませんが、学びを積み上げ、プロダクトは良くなってきています。

一方で、プロジェクト制は良いことばかりではありません。極端な解釈だとは思うのですが、プロジェクトにフォーカスし過ぎてしまうのです。

  • 納期が迫っている中、過去に関わったfeatureで障害が起きた。誰が対応する?
  • 残念なコードを見かけたが、開発スコープ内とは言い難い部位だった。リファクタする?
  • featureの機能的な独立性が高い。そのfeature内のデザインにローカルルールを作っちゃう?

ケーススタディ的に意地悪なシーンを書いてみましたが、誰もが経験があったり、少なからず想像できてしまう困ったシーンだと思います。納期があるし、ましてそれがプロジェクトの目標なのだから、まずそれを達成したいですし、プロジェクトとしてはそうすべきです。しかし、プロダクトとしては、常に一定の品質、トーン&マナーを満たし、また将来の効率的な開発効率を担保していかねばなりません。

Timersの場合は、開発プロジェクトにおいても、プロダクトマネージャー職のメンバーが全体の調整だけではなく、ディレクションの仕事を行うので、本人の中ではプロダクトの全体像とプロジェクトのゴールのギャップに苦しむことになります。

目の前の解決策による一時の平穏

具体的には、Timersでは、運用のための稼働を確保しないとまずいという問題が起きました。開発チームのほとんどのメンバーが何かしらのプロジェクトに参画しているので、プロジェクト以外の仕事に取り組むインセンティブが誰のところにもなくなってしまったのです。例えば、お客様からの問い合わせ等を起因として、プログラムやデータの調査を行わないといけないというケースが、置き去りになりがちでした。

結果、サービス運営のために、お客様とのコミュニケーションを担当するプロダクトマネージャーが、比較的状況に余裕のあるエンジニアを探して、対応をお願いしないといけない、なんて時期がありました。本来、お客様が使ってもらうためのサービスを行なっているのに、お客様がお困りになっている状況や潜在的な問題を発見するための機会が二の次になっていたのです。お願いに回るプロダクトマネージャーにとっても、基本的に厄介なお願いに回ることになるので、やりづらくて仕方ありません。

そこで経営陣との相談、議論を経て、TaskDayという制度を作り、この問題に対応をしました。具体的には、1日単位の当番制で運用対応業務の窓口となるエンジニアを設定しています。各プロジェクトのスプリントごとの開発計画の場では、各エンジニアは週に1日、TaskDayがやってくる(=プロジェクトの仕事ができない)前提で稼働量を想定し、現実的な開発ボリュームを考慮した計画立てを行う仕組みになっています。

これにより、目の前の問題は沈静化しました。そして、時間的に余裕があるから、軽微なバグを回収するなどの改善が一部進み、平静を得たように見えました。しかし、これは一時の平穏でしか、ありませんでした。

構造的な悪循環、遅れてやってくる悪循環を発見する

プロダクトマネージャーとして、組織を俯瞰して見たり、気になり始めたメンバーと会話をしていると次のようなサイクルが発生していることがわかってきました。

  • 調査やデータパッチ対応が発生
  • 自分にとっては初めての対応だったので都度学習コストをかけて実施
  • 本人だけでは再現性がわからない、調査を仕組み化するところまでできず1日が終わる
  • 調査担当者は、依頼者から感謝され、担当者としては嫌な気がしない
  • 似たようなことを他の人が、また学習コストをかけて対応

構造的に悪いサイクルです。原因を考察してみると、あかん要素がもりもりです。

  • 次に同じ問題に当たる頻度が、1Day交代ゆえに確率が低い
  • 個人単位に見ると、結果的にある問題の再現頻度が低いので、改善提案されない
  • 当番は1日で終わるので、時間さえ過ぎれば、流れていってしまいがち
  • 対応に追われると、1日の中で提案に至る余裕がない
  • 改善しようとしても時間的に大きな改善の仕組みづくりがしづらい

依頼者はお客様対応が円滑になり、満足する傾向にあるので、組織全体としては問題が減ったような気がします。しかしながら、エンジニアリングの効率においては、気がつくと一度あたりの学習コストが高いもので溢れかえっているではありませんか。

お客様対応の円滑化という課題が解決しても、プロダクトにとってよくないサイクルが生まれている。そして、それは開発効率やモチベーションといった短期で影響がわかりにくいが、中長期で壊滅的な影響を出しうる問題を抱えているのです。

より本質的な課題を設定する

上記の話は、例えるならば、ユーザー獲得では目標を達成したが、LTVで見ると、短期では問題は発覚しないものの、実はライフタイムが短い傾向のユーザーを大量獲得しており、最終的なLTVが、時間的に遅延して下がってくる。結果、プロダクトとしては期待通りの成長ができていないといった関係と同じだと思います。

プロダクトにありがちな関係性に例えると、途端に理解が進みます。勇気あるプロダクトマネージャーとしては、ここのような問題をスルーするわけにはいきません。課題を設定すると、次のようなものがあると思いました。

  • 仕組みへの改善意思をもつ機能サイクルに転換する
  • 「何回も起きること」を「個々人の一回きりと思われがちな作業」から発見する

具体的な課題の解決では、次のようなことがありえそうです。

  1. TaskDayの内容を集計したり、共有する会議体を設け、問題点をあぶり出す
  2. 運用専門のチームを作り、その中で効率性を追い求める
  3. チームがサービス領域に責任をもち、プロジェクトと運用を両立するようにする

個人的には、1は結局、プロジェクトでの稼働と利益背反してしまうので効果的ではない。2は会社的に投資が大きく見えるのと、運用だけっていうのはメンバーにとっては、一般的にはモチベーションが湧きにくいテーマ設定になることが難点です。3は、短期的にプロジェクトの生産性・納期達成度が下がる可能性があるものの、中長期的には、効率改善やサービス領域知識の共有のインセンティブにもなるので、悪くないのでは?と思います。

組織というプロダクト

上記の話は、まさに現在進行形の話です。組織における、とある課題を解決したら、次に問題が移り変わり、その問題分析を経て、新たな課題を定義する。時間的に短期で効くものもあれば、中長期でくるものもあるし、トレーオフになるものもある。

僕は、確信しました、「組織もプロダクト」だ。

まして、プロダクトを提供・開発していく母体となる組織であるがゆえに、本当に良いプロダクトを作ろうと思ったら、良い組織でなければいけないのです。そして、評価されるプロダクトが時間や環境の影響を受け、常に同じでないことと同じように、良い組織も常に移りゆくものなのだろうなと想像できます。

組織の問題と向き合い、経営陣やメンバーたちと対話し、議論をする時間を増やすと、直接的にプロダクトマネジメントする時間が減る。企画やディレクションをやる余裕がないという問題が起き、個人的には虚しさを感じることもあるのですが、、、より高度かつ本質的なプロダクトマネジメントのスキル・経験値として「プロダクトマネジメントする組織とも向き合う」ということが大事だと信じ、メンバーとの対話、問題発見と課題解決を進めていこうと思います。

問題と向き合い変わり続けていく、そういうプロダクトであり、そういうプロダクトをつくる組織であろう。

積極採用中!!

子育て家族アプリFamm、カップル専用アプリPairyを運営するTimers inc. では、現在エンジニアを積極採用中! 急成長中のサービスの技術の話を少しでも聞いてみたい方、スタートアップで働きたい方など、是非お気軽にご連絡ください! 採用HP : http://timers-inc.com/engineerings

Timersでは各職種を積極採用中!

急成長スタートアップで、最高のものづくりをしよう。

募集の詳細をみる