CodeZine(コードジン)

特集ページ一覧

プロダクトマネージャーはいつから必要? Chatworkに学ぶPMの設置と採用で意識すべきこと

Chatworkのプロダクトマネジメントに学ぼう 第1回

  • ブックマーク
  • LINEで送る
  • このエントリーをはてなブックマークに追加

 現在「プロダクトマネジメント部」を置き、7名のプロダクトマネージャーが活躍しているChatwork。同社ではゼロからプロダクトマネジメント組織を立ち上げ、未経験者を採用育成しながら、プロダクトと組織を洗練してきました。本連載では同社のプロダクトマネジメントおよびその育成のノウハウを、リレー形式で紹介いただきます。第1回は、初代プロダクトマネージャー(PM)ともいえる代表取締役CEOの山本正喜さん。いわゆる「一人PM」から、専任のプロダクトマネージャーを設置するに至った経緯は、どのようなものだったのでしょうか。また、プロダクトのスケールに合わせてプロダクトマネージャーを組織化していく際の採用のポイントなどを解説いただきました。(編集部)

目次

はじめに

 はじめまして、Chatworkで代表取締役CEOをしている山本正喜と申します。この度、ProductZineにてChatworkを支えるPMチームによる連載がスタートすることになりました!

 記念すべき第1回ということで、CEOの私が筆を執ることとなりました。「なんでプロダクトマネージャーの連載でCEOが?」と思われるかもしれませんが、私はもともとChatworkを開発した最初のエンジニアであり、初代のプロダクトマネージャーでもあります。

 この第1回では、これから始まる連載のイントロダクションも兼ねて、「そもそもプロダクトマネージャーっていつから必要なの? どうやって組織化していくの?」といったポイントについて、当社のプロダクトマネジメントの変遷を例に解説したいと思います。

 プロダクトマネージャーという役割が明確には存在しなかった立ち上げ期から、プロダクトの成長とともにプロダクトマネージャーが生まれ、組織としてどのような変遷をたどっていったのか、その役割や責任がどのように変化していったのかをご紹介します。1つの例ではありますが、当社の事例がご参考になればと思います。

Chatworkのはじまり――たった1人での開発スタート

 Chatworkの開発が始まったのは2010年ごろ。当時CTOだった私が新規事業の提案としてChatworkを企画したのですが、その時は会社のメイン事業がうまくいっておらず、手がかかりそうなビジネスチャットの開発なんて無理と、却下されてしまいました(当初は株式会社EC studioとして企業ホームページの集客支援事業などを行っていました。その後2012年から、Chatwork株式会社に社名変更)。

 どうしても諦めきれずに食い下がったところ、社内システムであればとOKをもらうことができました。しかし、「好きなことをやるんだから、1人でやって」と当時の社長から言われてしまい、やむなくたった1人での開発がスタート……。

 開発着手から約3か月かけて、社内向けのプロトタイプをつくったことを覚えています。

 これが、表には出ていないChatworkの幻の社内向けファーストバージョン。シンプルなチャット機能のみで、Chatworkの大きな特徴であるタスク機能や、ファイルアップロード機能などもなし。

 ここからそれまで社内の標準チャットツールであったSkypeを強引に置き換え、スタッフからブーブー文句を言われながらもバグを必死に直して、バージョンアップを繰り返しながら社内定着を頑張りました。

 開発着手から約6か月。社内でもようやくChatwork便利だねとみんなに言われるようになり、ついに事業化へのOKが出ることになりました。

 この当時はプロダクトマネージャーも何もあったものではなく、うまくいくかわからない難易度の高いプロダクト企画を通すために、“動く企画書”としてプロトタイプを社内向けにつくっていた、と言えるかもしれません。

正式に事業化、Chatwork事業チームの誕生

 正式に事業化が決定したことで、社内にChatwork事業チームが組成されることとなりました。最初期のチームは私の他にディレクター1名、エンジニアが2名、デザイナーが2名(WebデザイナーとUIデザイナー)の計6名。

 私はプロダクトマネージャー兼リードエンジニア、という役割。ディレクターには私の業務補佐と、サポートやら事業運営上のオペレーションやらのハンドリングをお願いしていました。

 新規事業の立ち上げフェーズの段階では、とにかくスピードが最優先。当時は会社が経営的に苦しいタイミングだったので、早期に結果を見せなければいつ撤退の判断が下されてもおかしくない状況だったこともあります。幸い(?)社内からもあまり期待されていない事業だったので、かなり自由にさせてもらいました。

 自分自身がプロダクトマネージャーであり開発責任者だったので、プロダクトに関わるほぼすべての意思決定と実装までを自己完結できました。極端な話、コードを書きながら仕様を考えて、実装が終わったらすぐリリースするようなスタイルで突っ走っていました。

 Twitterのリアルタイム検索で「Chatwork」のキーワードを常にチェックしていて、ちょっと不満を漏らしていたユーザーを見たら速攻で反応。30分ですぐ修正して「修正しました!」とメンションを送った時にはとても驚かれたことを覚えています。

 プロダクトをリリースした初期はPSF(Problem Solution Fit)もままならない状態なので、ニュースリリースを見てさわってみたユーザーから「これは使えないなぁ」という評判が広がらないうちに、ユーザーの反応を見ながら高速でプロダクトを修正していかなければいけません。

 リリース初期は、なるべく小さなチームで、可能な限り1人が複数の役割を兼務しながら、スピード最優先でリリースや対応をしていくのが良いと思います。


  • ブックマーク
  • LINEで送る
  • このエントリーをはてなブックマークに追加

あなたにオススメ

著者プロフィール

  • 山本 正喜(Chatwork株式会社)(ヤマモト マサキ)

     Chatwork株式会社 代表取締役CEO。 電気通信大学情報工学科卒業。大学在学中に兄と共に、EC studio(現Chatwork株式会社)を2000年に創業。以来、CTOとして多数のサービス開発に携わり、Chatworkを開発。2011年3月にクラウド型ビジネスチャット「Chatwork」の...

バックナンバー

連載:Chatworkのプロダクトマネジメントに学ぼう
All contents copyright © 2005-2021 Shoeisha Co., Ltd. All rights reserved. ver.1.5