この記事は Product Manager Advent Calendar 2016 の13日目の記事です。
ちょうど今日で折り返しです！
サイボウズ株式会社でプロダクトマネージャーをしています。@machiko0616です。
中小企業向けのグループウェア「サイボウズ Office」のプロダクトマネージャーを
2009年から担当しています。
正確には、2年間はアシスタントPM的な立場をしていて、
2011年から独り立ちしてプロダクトマネージャーをしています。
開発チームは、プロダクトマネージャー、エンジニア、QA、デザイナー、Docで構成されています。
プロダクトマネージャー、デザイナーが東京、エンジニアは東京、大阪、愛媛の松山、
QA、Docは松山、とリモート開発をしています。3拠点開発！
私たちが作っている「サイボウズ Office」は1997年にサイボウズが創業したときに
スタートしたプロダクトで今年20年目、来年で20歳になる割とご長寿なプロダクトです。
人間なら成人する年齢のプロダクトだけあって利用しているユーザーは多岐にわたり、
膨大な不具合、技術的負債、ちょっとした機能強化でも想定以上の開発工数がかかる。
など思うようにいかないことが多々あります。
開発チームでは重い鎖を付けて走ってるような感じだねなんて
表現したりもします。
そんな中、一つ強く意識してプロダクトマネージメントをしています。
それは「やらないこと」を決めるです。
プロダクトとしてやるべきことに集中できるように、判断に迷わないように
これは「やらないこと」と決めている、日頃から心がけていることを3つ紹介します。
1.不具合を全部直すことをやらない
20年の歴史を重ねてきたプロダクト。
継続的に改修・改善はしていても蓄積された不具合の数も膨大です。
そこでまず諦めたのは、「不具合0」を目指すこと。
その代わりに多くのユーザーに影響を与える、現象として重篤など
本当に直すべき不具合に迅速に対処するようにしています。
エンジニアは新バージョンの開発を行っている一方で、利用中のユーザーからの
問い合わせでサポートからのエスカレーションの調査・対応も行っていました。
エンジニアが調査の実施するのと新機能の実装が並行になってしまうと
スイッチコストが発生するということがチームとして問題に感じていました。
チームで話し合い、現在は開発チームをサステインチームと新規開発チームの
2つに分けています。
（かれこれ、このチーム編成にして2,3年近く経ちます。）
サステインチームは先ほど書いた問い合わせでの調査、緊急性のある不具合改修など
製品のメンテナンス中心に、新規開発チームは新機能を担当しています。
製品全体でみると膨大な不具合がありますが、全件トリアージがされている状態になっています。
チームでの運用ルールはまた別の機会があればお話したいと思います。
2.新しい機能でいきなり完成形を求めることをやらない
要件を決めて、開発チームとこういう機能にしよう！
と決まるとそこで必ずといっていいほど出てくるのが
各アプリケーションへのばらまきが大変問題です。
チームのテンションがわーっと上がってがくっと下がる瞬間です・・。
そもそもばらまかないといけない内部仕様がイケテないのですが、
それを直すパターンと直すのがしんどすぎるパターンがあります。
20年積み重ねてしまった故の負債ですね・・。
ただ、これを理由にユーザーにとって価値があるであろう対応をしないのは
プロダクトの成長を否定することになります。
開発チームとしてばらまかざるを得ないという判断になった場合
次に起きるのが、対象となる全アプリに対して開発スケジュール内で実装するには
工数が足りない問題です。
ちょうど私がプロダクトマネージャーになった時期に、プロダクトがクラウドサービス化しました。
（今はクラウド版、パッケージ版の両方の形態があります。）
クラウド版ができたことで、自社でリリースが可能になったこともあり
最初から完全な機能の完成形まで仕上げてリリースするのではなく
段階を追って仕上げていくという方法に転換しました。
地道ではありますが、製品を着実に前進させて継続的に成長させることが
よりやりやすくなりました。
3.コンセプトに合わない問題を扱うことはやらない
サポートからプロダクトを利用中のユーザーからもらう要望
営業が提案中にユーザーからもらう要望など
日々、社内外から要望が寄せらます。20年もやっていると要望が多岐にわたります。
中にはプロダクトのターゲット、コンセプトで大切にしていることに
明らかに合わない要望が入っていたり、強く要求されるケースがあります。
とてもわかりやすい例だと
中小企業向けのプロダクトであるのに数百人の会社で管理しやすくしたいであるとか
シンプルで情報をなるべく共有して見せることを大切にしていうのに見えなくする制御を細かくできるようにしたい
といったものです。
これらは背景としてどういう問題がというを考えることはしますが
考えたうえでやはりプロダクトとして大切にしているコンセプトに合ってないな
と判断したものは解決すべき問題ではないと判断するようにしています。
逆に要望をもとに解決したい問題を定義して、
それがコンセプトに合っていれば要件として採用する候補として扱います。
#結局何がしたいか
やらないことを決めるで何をしているかというと
・捨てるものを決めることによって、フォーカスすることを明確にする
・捨てるターゲット、シナリオを決めることによって、解決したい問題を決める軸をはっきりさせる
ということをしています。
「やらないこと」を決める、つまり自分の中で捨てる勇気と理解していますが
案外これって難しいことなんですよね。
プロダクトが長寿で大きくなったゆえにその必要性も高いですが
プロダクトのフェーズにかかわらず、どのフェーズでも必要なことだと思います。
捨てる勇気を持つことで、本当に注力すべきことにプロダクトマネージャーとして、開発チームとして
パワーを注げるようになるのではないでしょうか。
さいごに
サイボウズでは、プロダクトマネージャーを募集しています。
チームワークで世界をよくしたい、そんなプロダクトを作ってみたいとご興味のある方は
ぜひエントリーしてください！
サイボウズで働く特典？として実家がみかん農家の社員から
めちゃうまみかんを直接購入できます。
これ、市販で買うと一個数百円はする高級みかん、紅まどんなです。