皆様こんにちは。ソラコムでプロダクトマネージャー兼プロジェクトマネージャーをやっております江木と申します。みんなからは nori と呼ばれています。
はじめに
ソラコムでは昨年プロダクトマネジメントチームを立ち上げました。文字通り、プロダクトマネジメントをチームでやっていこうということです。そして私もプロダクトマネジメントをやることになりましたので、
- プロダクトマネジメントチームを立ち上げることになった経緯
- まず、なにをやったか。
を書きたいなと思っております。
正直、思いつくまま勢いで書いているので冗長な部分などもありますが、特にこれからプロダクトマネジメントをやることになった方の参考になれば、あと、これまでのソラコムの様子も伝わればいいなと思っています。内容は完全に私個人の考えだったり、記憶によるので、そこのところはよろしくお願いします。
そして私が最もお伝えしたいことは「ソラコムではプロダクトマネジャーとプロジェクトマネージャーを募集しています！」ということを先にお伝えしておきます(笑)
プロダクトマネジメントチームを立ち上げることになった経緯
サービス立ち上げ初期（エンジニア 10名以下）
私は2015年、ソラコムがサービスをローンチする少し前に入社しました。
私は10番目の社員で当時エンジニアは6名でした。スタートアップのシードステージとかアーリーステージとか呼ばれているフェーズで、誰がなにをやっているか、進捗や困りごとも特に意識しなくてもわかるし、メンバーの体調とかも顔をみればわかるし、なんなら家族構成や趣味、笑いのツボとかもわかっていました。小規模チームなのでコミュニケーション観点では、いわば「あうん」の呼吸で大概の物事が進んでいくようなフェーズでした。
当時からエンジニアチームは、2週間のイテレーション（開発サイクル）で開発していました。SORACOMは、AWSのサービスをとてもうまく使いこなしたマイクロサービスアーキテクチャで、イテレーションプランニングで各コンポーネント間のインターフェースを相談して、2週間後のイテレーションが終わる金曜日にインテグレーションテストして、うまくいったらお祝いにみんなでお寿司をつまんでいたのをよく覚えています。(うまくいかなくても食べてましたが 笑)
エンジニアに限らないかもしれませんが、この初期の頃は「なんでも屋」であることがとても大事でした。エンジニアは開発だけでなく、マーケティングだったり、Webサイトをつくったり、セールスに同行してお客様と話したり、とにかくやることは山ほどあるので、なんでもやるぞ、むしろやれることは全部やるぞ、というバイタリティでやりとげることが大事です。自分が立ち止まることは、すなわち大好きなソラコムがそれだけ遅れてしまうような気がして、とにかくなんでもやっていました。
私が心から尊敬する ソラコムCTO 安川(kenta) は、当時最も多くのコードを書き、イノベーションの先頭を猛スピードで突っ走り、それだけでなく、お客様とも会話し、その会話の翌日には機能追加するなど、まさに「スーパーなんでも屋」でした。
開発チームの拡大（エンジニア 20−30名）
2018年頃には、アーリースタートアップな時期を経て、プロダクトマーケットフィットもみえてきて、エンジニアも20名を超えるようになってきました。
一般的には7~10名を超えるとチームを分けるのがプラクティスですが、私達は20名を超えても1チームでイテレーションプランニングとイテレーションレビューを行っていました。ただ、想像できると思いますが、さすがに20人を超えてプランニングをすると、少し深い話になると全員がディスカッションには関われないことが多く、「別でやりましょう」ということが多くなってきました。
ちなみに私は、プロジェクトマネージャーとして、2週間のイテレーションを運営することをとても大事にしていて、これをきちんと回すことは私のライフワークの一つでした。開発チームに限った話ではないかもしれませんが、Sustainabilityとチームの集中力を両立させるにはリズムが必要で、スタンドアップミーティングは日々のリズム、Iterationは2週間のリズムを生み出す根源だと考えています。
この頃、イテレーションのリズムは維持しつつも、コミュニケーションの課題を解決するために、エンジニアを1チーム3名から最大で6名くらいのチームに分けました。Scrum of Scrums や SAFe といったフレームワークを参考にしましたが、どれも「大規模でいかに効率よくコミュニケーションするか」に主眼が置かれている気がします。私達の目指したのは、そもそもコミュニケーションがなくとも運営できるような体制で、スモールなチームが独立して運営して、クイックに意思決定できて、開発できる体制を目指しました。
プロダクトマネジメントチームの立ち上げ（エンジニア 30名以上）
スモールなチームはうまくいきました。イテレーションプランニング、イテレーションレビューは確実に効率的に、効果的になりました。ただ、一方でチームをまたがる要求や課題はやはり残るし、各チームで意思決定するためには全体で一つではなく、各チームにプロダクトマネジメントが必要でした。
という経緯から、Agilityを維持したまま、今後もチームを大きくできる体制を目指して、プラットフォーム全体でも、スモールなチームでもプロダクトマネジメントをみる必要性を感じ、プロダクトマネジメントチームを立ち上げることにしました。
Agilityというのは開発速度や変化への対応ということよりも、「素早く意思決定できるか」が鍵だと考えています。エンジニアだけでなく、ビジネス側も含めてスモールチームを維持することが、素早く意思決定するための良いアプローチな気がしています。
まず、なにをやったか。
プロダクトマネジメントチームを立ち上げるにあたって、最初に直面した課題はプロダクトマネジメントとは一体何をすべきなのか、について社内で共通の認識を得ることでした。そして、チームはどのような体制にすべきで、プロジェクトマネジメント、ビジネス開発やマーケティングとの違い、それらのチームとどのように関わるのか、を考えました。
いくつかの本を読み漁りましたが、もっとも有用だったのは本ではなくオンライントレーニング Udemy の「プロダクトマネジメント講座」でした。質問にも応えてくださり、講師の曽根原さんには感謝の言葉が見つかりません。(いつかお会いしてお礼を言いたい！)
上記のトレーニングでシリコンバレー企業でのやり方はだいたいわかった気持ちになったので、これをもとにソラコムではどうするか、を考え、チームの Role and responsibility としてまとめました。
この「Role and responsibility を定義しまとめる」という作業は少し感慨深いものでした。なぜなら前述のとおり、これまで「なんでも屋」であることを良しとして、私も心がけていましたが、Role and responsibility を定義するということは、ある程度守備範囲を明確にすることです。
会社のフェーズはすでにグロース期に変わってきており、組織での運営が求められていました。もし誰かキーマンがいなくなっても会社は運営されなければならず、業務プロセスの策定や開発プロセスの標準化といった作業も必要になってきています。
プロダクトマネジメントチームの立ち上げからすでに半年以上経過していて、うまくいったこと、もどかしかったこといろいろありますが、それはまた別の機会に。それはもうエキサイティングな半年でした。(きっとこれからも。)
ここまでのふりかえりと私の学び
2015年のサービスローンチ以降、私たちは着実にかつものすごく成長していて、そして着実に成長痛にもぶつかりました。
私の学びとしては、そのときどきでチームの状況は変わるので、リスクを見ながら(=許容できる失敗をコントロールするような)、継続的に改善を回すことのできる状態をつくることが大切なんだろうと思います。ソラコムの場合、3ヶ月に1度のふりかえりレビューがその状態を作っています(前述の日々のスタンドアップミーティングのリズム、2週間のIterationのリズムに加えて、3ヶ月毎の振り返りのリズムですね。)
今回はプロダクトチームの立ち上げの話でしたが、例えば10人のときに、かっちりしたチームやルールを頑張って作ってもたぶん絵に書いた餅で終わったはずです。適切なタイミングと適切な体制というのがあるので、その時々で改善できるようにすることが最も重要で、改善においては、意思決定とアクションをしやすくなるようなチーム体制と仕組みをまず考えることが近道のような気がしています。
というわけで、ソラコムはグローバルな IoT プラットフォームを本気で目指していて、よいプラットフォームを提供することはもちろん、そのためにはどんなチーム体制がいいのかを考えて実行していくことはとってもエキサイティングです。
そして、私が最もお伝えしたいのは「ソラコムではプロダクトマネジャーとプロジェクトマネージャーを募集しています！」ということです！ぜひこちらから詳細をご覧ください！
― ソラコム 江木(nori)
投稿 ソラコムのプロダクトマネジメント 成長する組織と役割の変化 は SORACOM公式ブログ に最初に表示されました。
ソラコムのプロダクトマネジメント 成長する組織と役割の変化 - ASCII.jp
Read More
No comments:
Post a Comment