プロダクトの成長のため「全員がプロダクトマネージャー」

弊社が運営するサービス「Hike」は、配信先の媒体のデザインに最適化されたネイティブ広告を提供するシステムです。手持ちの広告素材が少ない広告主さんであっても、自動的に様々なメディアのデザインにフィットした広告を配信することが可能になります。

またメディアさん側から見ても、1、2分の簡単な作業で収益獲得のためのシステムを導入できるというメリットがあります。

弊社では、「全員がプロダクトマネージャー」です。実際に名刺にも、各自の役職や役割に加えてプロダクトマネージャーと入れるようにしています。その理由は、弊社が展開しているWeb広告というビジネス領域にあります。

この世界では、ひとつの広告がある一定数を越えてユーザーと接触してしまうと、無意味どころか嫌悪の対象になるんですよね。

そのような事態を防ぐためには、できるだけWeb上に多種多様な広告が流れている状態が望ましいということになります。営業が新規広告主さんの案件を受注し、広告の多様性を高めることが結果的にプロダクト自体の価値の向上につながるんです。

すべての情報を共有し、目線を合わせることから始まる

このような理由から、弊社では「プロダクトの提供価値に関して責任を持つ」ことを実行している人が偉いし、リスペクトされるという組織づくりをしています。そして全員がプロダクトマネジャーであるために、営業も含めたビジネスサイドのメンバーも全員GitHubを活用し、プロダクトの改善を進めています。

一般的なIT企業のように、コードレビューやIssueベースでのプロジェクト管理をするといった使い方もしていますが、そのプロセスの中に自然にビジネスサイドの人が組み込まれる仕組みを作りたいと考えています。

最初から全員でGitHubを使っていたわけではなく、プロダクト改善のフェーズに入ったタイミングで、このような体制をつくりました。プロダクトの立ち上げ期って、1人2人で無理やり創り上げるような、非論理的な世界だと思います。そのフェーズでは、スクラムのような開発手法は向いていないんですよね。

一方で、作ったものがお客さんに使ってもらえる状況が作れたタイミングからは、細かい改善アイデアを全員で出し合って累積改善数を増やすことが必須です。そのアイデアを出し合う場として、GitHubが向いていると考えました。

ただ、そもそも改善アイデアを出すためには、全員が現状を理解していることが重要です。情報の非対称性がある中でアイデアを出し、結果出てくるアイデアがしょぼかったり、既に検討済のものだと無意味ですよね。

また、「それはマネージャーミーティングで話している内容です」と言われてしまうと、せっかくアイデアを出した人もテンションが下がりますし、二度とアイデアを出さなくなってしまうかもしれません。

そこでまずは情報を透明化する必要があり、そのためにQiita:Teamを使っていました。プロダクトについて、マーケットについて、お客様について。すべての情報をQiita:Team上で透明化し、全員の理解度を合わせた上で、実際にプロダクトを改善していくフェーズに入っていった訳です。

▼情報共通ツール「Qiita:Team」ですべての情報を可視化（※内容はイメージです）

ディスカッションは「実際に困っていること」をベースに行う

実際にプロダクト改善を進めていくためのアイデアは、GitHubのIssueに上げるようにしています。上がってくるものは、「〇〇という問題があります」という課題をベースにしたものが多く、実際にそのような形で書くようにも言っています。

「〇〇という機能が欲しい」という形でビジネスサイドから仕様を提示するのは、極めてナンセンスです。やりたいことは何で、その理由が何なのか、それさえ分かっていればエンジニアの方が適切な仕様を導き出せます。

当然ビジネスサイドも仕様に関しての議論はしますが、どの仕様が技術的に相応しいのか、技術的負債を生まないようにするにはどうすべきかといった、ビジネスサイドにはカバーできない論点があるので。機能を提案するより実際に起きている問題を上げる方が良いんです。

お客さんと話していてぶち当たった問題や、運用上の違和感のようなものを単純にIssueに上げていくだけなので、非エンジニアにも難しいことはなにもありません。むしろ「クライアントが困っている！」とか、「売上のためにこれが重要なんだ！」とか、気持ちを込めて書けるので（笑）。

▼GitHubの「Issue」に、実際起きている問題を上げる（※内容はイメージです）

実際に困っていることがベースになるので、センスの無いIssueはほとんど出てきません。上がってきたIssueは、基本的に全て実装しています。結果は定量的な数値に現れるので、それを元に何が悪かったのか話をして、「じゃあこの機能は止めようか」という話になるだけのことです。

大切なのはアイデアが無視されない状況をつくることで、それによってまた次のアイデアを出そうという気持ちになることができます。このように、たとえ1%であっても改善を多く積み重ねていくことで、結果的に競争優位性を築くことにつながると考えています。

そこからエンジニアが仕様を決めていくのですが、ビジネスサイドの人間も「たとえ理解できなくても一応読む」ということが凄く大事ですね。自分が起票したIssueくらいは分からないなりに読んでいく中で、何となく話が見えてくるようになりますから。

また、実装後の結果までをひとつのIssueにまとめて管理をしています。自分のした仕事がお客様の役に立っているのかをしっかりと知らせることが、エンジニアの働く動機としては重要だと思うんですよ。営業メンバーも同じGitHubの中にいれば、解決された問題のフィードバックも自然と同じ場所で起こるので、結果をすべて見ることができます。

▼GitHubの「Issue」内で議論を行う（※内容はイメージです）

プロダクトへのフィードバックをエンジニアのモチベーションに

実際にGitHubの運用を始めてから解決した例のひとつは、 本来もっと配信量が増えても良いような広告案件の配信量がどうも少ない、という営業担当者の違和感に端を発しました。この違和感が GitHubに起票されました。

このIssueを確認したエンジニアが、早速調査に取り掛かります。明らかな不具合を確認できなかったことから、当該Issueのコメント欄で、営業担当者との連携が始まります。

他にも同様事象が見受けられるような案件がないかなどを確認し、プロダクトの不具合ではなかったものの、新規広告案件の品質を確認するために実装されていた「テスト配信機能」の仕様が、急激に成長する Hike ネットワークに合わなくなってしまっていたことを突き止めました。

そこですぐさまGitHub上でのコメントのやり取りと共に修正が行われ、意図する挙動になったばかりか、現状、そして今後の成長を見込んだ形でテスト配信機能が大幅アップデートされました。改善後、広告効果の高い案件の配信ボリュームが伸び、お客様にも喜んでもらえた結果、予算が増額しました、といった内容がコメント欄に投稿されています。

この事例では、結果的に「仕様が現状にあわなくなってしまっている」という本来発見されづらい問題が解決されるに至りました。それができたのは、営業が「実際に声を上げられる」レベルまで情報を共有されていたからです。

また開発側に伝えたら終わり、ではなく、問題解決まで営業側も責任を持つんだという意識があったことで、開発チームも理解を持って作業に取り組むことができました。

営業が「プロダクトが悪い」とは言えない組織に！

テスト配信機能の例は本当に細かい話ですが、このようなことが、僕たちの目指している方向性の神髄だと思います。営業目線で考えたときの問題点を、しっかりとプロダクトにフィードバックして解決させる。

営業って、営業的手法で顧客課題を解決することだけを考えてしまうケースも多いので。特に弊社のようなプロダクト主導の企業だとその傾向は非常に強いと思います。

でも自分もプロダクトマネージャーであるならば「プロダクトが悪いから売れない」とは言えなくなります。起こっている問題を自分でフィードバックしていく義務がある、という状態を作らなければダメですね。

GitHubをビジネスサイドを含めて運用していくことで、エンジニアにとってもメリットがあります。ビジネスサイドからすると、エンジニアの働き方って全然分からないんですよ。自分が上げた要望が全然消化されていないと「エンジニアはサボってないか」と疑心暗鬼になってしまう。

それがGitHubで要件定義から開発までのプロセスを可視化するだけで、ひとつの機能を実装するためにもこんなに厳密に調査していて、データもこんなに取っている、といったことが伝わります。エンジニアが主体的に発信をせずとも、いつもと同じ仕事をしているだけでそれが可視化されるので、ベストですよね。

既にプロダクトができていて、改善フェーズに入っている組織ならどこでも弊社のような仕組みが実現できると思います。重要なのは、最初に情報の非対称性をなくすこと。そして目指す組織像に必要なメンバーの行動が、正当に評価される仕組みを作り上げることです。

弊社ではGitHubを中心にして、コミュニケーションと人材の評価の部分はかなり汎用的にできるようになってきました。今後はこのプラットフォームを社外の方も含めて活用していくことで、組織としての多様性を実現していくことを考えています。（了）

※Qiita:Teamを活用した情報共有文化の作り方についてお伺いした記事「情報共有する奴が偉い！『役割分担＋日々発信』のエンジニア文化が組織全体を強くする」はこちらです。