株式会社メルカリ主催の TOKYO CS JAM #2 に参加してきました。メルカリ主催の CS 系イベント参加は今日が3回目。いつもありがたく参加させていただいております。
CS JAM は
「CS レベルアップのための企業混合 Study Session」をコンセプトにした Customer Support 業界 (Customer Experience, Customer Service, Customer Success なども含む)を盛り上げるための、勉強会、交流会的なコミュニティイベント -- http://csjam.connpass.com/event/33258/
で東京開催は今回が2回目。メルカリは CS に関するイベントを積極的に開催されています。ネットサービス関連のスタートアップ事業/ベンチャー事業界隈での CS 交流については、メルカリが主導してくれているといっても過言じゃないと思います。
今回のテーマは「最高のチーム/組織づくり」。2つのセッションに分かれていて前半は「株式会社メルカリ 山田和弘氏」「ランサーズ株式会社 冨樫謙太郎氏」「freee株式会社 中島伸吾氏」によるパネルディスカッション。去年のスクーの「スタートアップCS担当によるカスタマサポートの極意」というオンライン授業の続編という位置づけで、その時のモデレーターだった大木しのぶさんが進行をされていました。トークと仕切りはさすがの超プロでした(スクーの宣言もうまく織り交ぜてたり)。
そして後半はそのディスカッションを踏まえての各テーブルごとのグループディスカッションです。
グループディスカッションの時間は30分。私たちの7人のテーブルは「組織文化」がお題でした。模造紙に発表内容を書き出すのも含めて30分はあっという間です。ディスカッションでは組織において「大切にしたい考え方」をきちんと共有・浸透させていくことが重要だという切り口で「ロールモデルとなる人を軸に組織に新しく入る人も含めて定期的に共有していく機会を作っていこう」という結論になりました。
30分ではもちろん議論が尽くされたとは言いがたいのですが、ほぼ初対面の方々と集中してまとめていくというワークは良い刺激になりました。
山田氏が締めの言葉で「ネットサービス業界とその CS 部門では、スピードある意思決定と対応が必要」と言われたのを聞き、今日のグループディスカッションの30分の意味をあらためて理解したのでした。
限られた情報と時間の中で不完全な状態でも答えを出して走りだし、フィードバックを得ながら方向修正しつつ進んでいく仮説思考の大切さを思い出させてくれる良い機会になりました。
何度か意見交換させていただいているメルカリの方と久しぶりにお話できたりもして今日は良い刺激を得られるセッションでした。メルカリの方々・登壇者の皆さま・参加者の方々ありがとうございました。
(画像は http://csjam.connpass.com/event/33258/ より。)
Jurgen Appelo 氏の Management 3.0 では「権限の7つのレベル(The Seven Levels of Authority)」として以下を挙げています。
権限が委任/移譲されているレベルが高いほど数字が大きくなります。委任/移譲が段階的であることなどを学ぶデリゲーションポーカーではこの7レベルを使ったり、デリゲーションボードでこの7レベルで共有したりします。
訳語は人によっていろいろあるようです。
http://qiita.com/harakachi/items/d75461402815d76b12c5
http://nuworks.jp/ja/2016/12/09/deligationpoker/
http://www.ryuzee.com/contents/blog/3669
今読んでいるエッセンシャル スクラムでも「7段階の権限」として取り上げられていて以下の訳語があてられています。
好みの範疇なのでどれでも良いといえば良いのですが、単語によって自分の感覚だとこの組み合わせかなというのを考えてみました。
こんな語感かなと。実際にチームで使う時は harakachi 氏が挙げている 1. にしようかなと思っています。
社内で「エッセンシャル スクラム」を読みたい人が集まる勉強会13回目。今日は第13章 マネージャー。
スクラムフレームワークではマネージャーという役割は取り上げられていませんが、組織を回すために必要な役割として1章割かれています。
ファンクショナルマネージャー(あるいはリソースマネージャー。機能エリアごとのマネージャーのこと)の責務として本書では以下を上げています。
マネージャーの役割は「戦略的な方向性を定めること」「戦略目標を達成するための組織的リソースを採算を考慮して揃えること」とのこと(スクラムの環境において)。
チーム編成のところで権限の7つのレベルの話が出てきます。自己組織化されたチームであるためにはメンバが権限(と信頼)が必要で、マネージャーはアクティビティや意思決定の種類ごとに適切なレベルで移譲すべきとしています。
本書ではマネージャーが分野・コミュニティ別にいる組織をメインに説明されていましたが、マネージャーが複数のチームを抱えるような組織についても説明を聞きたいなと思いました。
チーム編成のところは今の自分の立場での大きなトピックとして意識していきたいです。
後半はプロジェクトマネージャーの話。スクラムチーム数が多くて、さらに立場が異なってスクラムオブスクラムでの話し合いでもうまくいかないような場合に、他チームとの調整を効率的にする役割としてのプロジェクトマネージャーを置く場合もあるという説明がされていました。多くの組織ではいらないのかなと感じました。
社内で「エッセンシャル スクラム」を読みたい人が集まる勉強会の14回目。今日は第14章 スクラムのプランニングの原則。
今回は「原則」の章ということで、今日の発表当番だった CSM の人があらためて「原則とは?」という点について掘り下げてくれました。「価値とプラクティスを結ぶ」原則について
「原則なしに上辺だけプラクティスを実行してても意味ないよ」
と CSM の人が語ってくれました。「アジャイルソフトウェア開発宣言」と「アジャイル宣言の背後にある原則」についてその場でみんなで見返しました。
事業体としての価値観と原則、個人としての価値観と原則、そして開発プロセスフレームワークとしての価値観と原則と、この辺り自身でも整理しないとなと最近考えているところです。
プランニングについては出来上がった計画よりも計画のための対話などのプロセスが重要なのだなと最近感じるようになりました。
ということで継続的にプランニングし直していくことが大切なのだなと。
14.4 プランニングの選択肢は、最終責任時点まで変更可能にする
についてはここではかなりあっさりとかかれています。物事を進めるには常に大小様々な意思決定をしていく必要があるので、さらっと読むと気持ちわるい感じがします。ここは 3.3 節にも
重要で後戻りのできない決定をしかるべき最後の瞬間まで行わないのである。
とあるので、方向転換できない状態に早い段階でならないようにするといったところなのだと理解しました。
14.7 早めにリリース、頻繁にリリース
については原則として頭にいれつつ、実際には適切なフィーチャーが揃っているかをきちんと考える必要がありますね。あまりに小さなリリースすぎて早い段階でユーザーに見限られてしまう危険性や、頻繁な変更によってユーザーが負担を感じて満足度が低下してしまう可能性も常に意識すべきかと。
この章でも
この手法には限界もある。まずどんなプロダクトであっても、最低限これだけは揃えないとリリースできないし市場で勝負できないというフィーチャー群がある。
と言った上で
もし部分的にでもよいから少しでも早めに受け取りたいという業界を相手にしているのなら、小さい単位で頻繁にリリースするという原則はとても重要になる。
としていました。
何かを考える時、何かを書く時、何か良い情報はないか頼れる正しい意見はないかと必要以上に情報を探してしばしば時間をかけすぎてしまいがちです。気が付けば内容も他人の意見をまとめたものになってしまうことも。
今年は「自分の頭で考える」をより意識してみることにします。
自分の意見を考える時、情報を探しにいくプロセスをいったん止めてまず自分の頭で考えて書き出してみる時間を作ります。 PC を使っているとついつい調べたくなるので
のどちらかの環境にして情報を遮断して考えるようにしてみます。
きちんと文章化する場合は、考えがまとまった後に初めて用字用語の校閲やハイパーリンク付ければいいかな。
意思決定をするとか意見を出すとかそういった決まったトピックについて考えるのとは別に、毎日考える時間をとって主体的に仕事をし生きていくようにも今年はしていきたい。こちらは1日15分などと時間を区切り、その時間の中で情報を遮断して湧き上がるアイデアや考えをまとめて行動につなげるようにしていきます。
今日から2日間ベルサール秋葉原 2F ホールでプロダクトマネージャー・カンファレンス 2018。
1日目の今日は Wellcome Talk とクロージングをのぞいても12セッションと盛りだくさん! 結構な数だなぁと思っていたけど、30分/15分というセッション時間でさくさくと進んでいるので、それほどハードモードではなかった。
今年のカンファレンスは「愛されるプロダクトを創ろう。」がテーマ。基調講演といくつかのセッションでは愛されるプロダクトについても触れられていたけれど、思ったほどは触れられていなかった印象である。登壇者の事業のプロダクトの紹介(アピール)とその成長に向けた取り組みの話が多かった。領域的には「人」「プロセス」「プロダクト」のうち「プロダクト」についての内容がほとんどだったかな。
一般申込み席はテーブル無しだけれど、前の席との間隔があって足元は快適だった。会場 Wi-Fi は無くテザリングも Wi-Fi 干渉で無理な状態(Bluetooth なら多少いけた)。メモは TaskPaper でとりつつ Twitter はスマートフォンで眺めるという感じで。
以下メモ。
プロダクトマネージャー・カンファレンス 実行委員長 関満徳氏
10:07 からスタート。今年は定員650人とのこと。 今年のテーマは「愛されるプロダクトを創ろう」。
プロダクトマネージャー・カンファレンス 実行委員 丹野瑞紀氏
PM 一年生をターゲットとして想定した講演。
まずはプロダクトマネージャーの役割について。プロダクトマネージャーの役割は事業目標を達成できるプロダクトを作るために機能を(製品要求仕様(PRD)などの形で)定義しエンジニア・デザイナーと共に開発するとした。
「愛されるプロダクトを創る」べき理由として以下が説明された。
プロダクトマネージャーもカスタマーロイヤルティを強く意識していく必要があるね。
「愛されるプロダクトとは何か」ということについては触れられなかった。今回のカンファレンスでそれを定義するセッションはあるのかな?
▲株式会社FiNC Technologies チーフプロダクトオフィサー 犬飼敏貴(@wancky)氏
FiNC Technologies の製品と会社の紹介。ヘルスケアではユーザーの短期解決よりも継続のある成果を提供する必要があるという話。それからゼロベースを怖がらすにプロダクトを定義していこうというのと高効率な PDCA サイクルにしていこうという話であった。
「高速よりも高効率」という論だったが、PDCA サイクルについてはまあ高速に失敗することも大切。考えなしにやってみればいいというものじゃないよという戒めかな。
特に話題なし。
▲楽天株式会社 トラベルプロダクトマネジメント課 マネージャー 熊谷亘太郎氏
楽天なのでスライドは英語。
「20年稼働してきたシステムを刷新し世界展開できるようにする」ことを題材にプロダクトマネジメントサイクルの要素の話をされていた。「製品要求仕様をまとめる」「コミュニケーションをしながら課題を解決していく」「意思決定していく」「バグトリアージ」のことなど。
を宣言できるのは「プロダクトマネージャーだけ」という話はドキッとなった。これはしっかり意識しないとな。
特に話題なし。
株式会社ノンピ 取締役 荒井茂太氏、プロダクトマネージャー・カンファレンス 実行委員 及川卓也氏
カフェテリア運営におけるプロダクトマネジメントもソフトウェアプロダクトマネジメントも多くな共通点があるという話。ユーザーをどう動かすか(とがめることなく食べ残しを減らした取り組みなど)が興味深かった。
ユーザー(カフェテリアを利用する社員)のことをしっかりと意識しているのが感じられて、これは愛されるプロダクトだろうなと感じた。
▲株式会社アイスタイル 代表取締役社長 兼 CEO 吉松徹郎氏
@cosme のビジネスモデルと採用をアピールしていた。スポンサーセッションぽい。
特に話題なし。
▲グロース・アーキテクチャ&チームス株式会社 代表取締役 鈴木雄介(@yusuke_arclamp)氏
新会社をマネタイズするのがこのセッションのゴールとストレートに言ってしまうのは好感。スポンサーセッションぽい。
プロダクトマネージャーが忙しくなることによりコミュニケーションの薄いセクションとの齟齬が発生する。組織としてプロダクトマネジメントいくことで対応していくためには、いろいろ共有してくのが重要だという話であった。
アジャイル/スクラム用語がさらっと出てきていて、それらを前提でザクザクと進めていく感じのトークだった。
特に話題なし。
株式会社エウレカ 執行役員 VP of Pairs Japan 金田悠希氏
「新しい革新的なビジネスモデルは存在しない」 「機能は真似る」「マーケティングで勝つ」というプロダクト戦略はわかりやすいし、成功についてのしっかりとしたポリシーが感じられてよかった。
特に日本のユーザーがマッチングアプリで抱えやすい不安に誠実に向き合いそれを取り除く取り組みをしている点は、愛されるプロダクトにしていく上で大切だなと感じた。
▲株式会社サイバーエージェント 執行役員 長瀬慶重(@lionbaby)氏
「新しいプロダクトが市場で埋もれない」ようにするということについて、AbemaTV の企画・デザイン・PR などの取り組みを紹介。PR で話題を絶やさないように出し続けていく、PR もプロダクトマネージャーの大切な仕事と言っていたのが、自身の立場に照らし合わせてなるほどと感じた。
特に話題なし。
▲ピクシブ株式会社 執行役員 pixiv運営本部長・新技術プロジェクトプロデューサー 清水智雄(@norio)氏
pixiv では「創作」というドメインに絞ってプロダクトを出している。ドメインを絞ることで社会の解決すべき問題の詳細が見えてくる。知見と技術が蓄積され、体制変更が柔軟・高速にできる。という論。
自社だとコミュニケーションがそれにあたるな。
ドメイン理解者であることがユーザーに伝わると、ユーザーが自分たちのためにプロダクトを作ってくれているという感じてくれるようになる。企業レベルでユーザーとエンゲージメントが結ばれるというところが素晴らしい。
株式会社ZOZOテクノロジーズ 代表取締役CINO 金山裕樹(@yukiller)氏
最近読んだ『Hooked ハマるしかけ 使われつづけるサービスを生み出す[心理学]×[デザイン]の新ルール』の翻訳もされている方。行動力というか物事を成し遂げる力というか、フレンドリーな話し方を含めてとても魅力的な方だった。
今日のセッションでは数少なかったピープルマネージメントについての話題が興味深かった。プロダクトマネジャーチーム結成について。リクルーティング(スクリーニング)・オンボーディング(花を持たす)・グロースへをどうやってきたか。人を生かす・パフォーマンスを引き出すという気持ちが、今日一番刺激的に感じた。
スクリーニングについては Joel の考え方に近いなと。
具体的にどの話がという訳ではないのだけれど、この方が創るプロダクトなら好きになりそう、そんな感じがした。
▲LINE株式会社 LINE企画1室 副室長 入江和孝(@kazukomati)氏
みんなが使っている LINE アプリの話。
LINE の規模までくると機能改良しても利用者数は変わらないのがプロダクトマネージャーとして辛いとか、国内王者らしい話がうかがえた。
取り消し機能の製品要求仕様の決定では、さまざまな仕様案と反対意見が出た中、全てのユースケースを解決する仕様が無い中で、機能の目的・原則に立ち返って決定したとおっしゃっていた。 GTD でのナチュラルプランニングを思い出した。
ユーザー・メディアの取り消し機能仕様に対する不満に対して、取り消せなくて困った事例を募集するキャンペーンをやってみたりするのは面白いなと。ユーザーに対する説明をしっかりしようという感じが伝わった。
ラクスル株式会社 取締役CTO 泉雄介氏
リリースしてから失敗することを減らすためにプロトタイピングと検証をという話。
特に話題なし。
プロダクトマネージャー・カンファレンス 実行委員長 関満徳氏
今日から2日間ベルサール渋谷ファーストでプロダクトマネージャーカンファレンス 2019。
去年に引き続きの参加である。
今日のキーワードは「feature team ではなく真の product team を」「プロダクトビジョン」「信頼(trust)」。
以下タイトルは公式サイト掲載のものより。
横道稔氏。
Silicon Valley Product Group Partner and Founder / Inspired 著者 Marty Cagan 氏
与えられた機能を作るだけの feature team ではなく、真の product team を作り信頼し、プロダクトマネージャーは本当のプロダクトマネージャーの仕事をしようという話。
feature team をそのまま product team に成長させて信頼していくことができるのか、それとも優れたメンバで優れた product team を作っているからこそ信頼できるのか。
TransferWise Head of Product Kaarel Kuddu 氏
前のセッションに続きここでも、能力の高いメンバによる顧客のことを理解し考えて決定し実行できる優れたチームに決定権と成果に対する説明責任を与え信頼するという話が印象に残った。
ここでいっている責任をもつというものが何か指しているかが気になるところ。
LINE株式会社執行役員 二木 祥平 氏
「LINE公式アカウント」「LINE Ads Platform」が現在の担当プロダクトの二木氏のセッション。 「LINE(株式会社)では」 PM が何をしているかをふわっとまとめた話。ロジカルな構造や用語使いなどでしっくりこないところがあるけれど、生の声という意味で興味深く聞けた。
freee株式会社 執行役員 プロダクトマネージャー 岡田 悠 氏
バックログの縮小均衡 → プロダクトビジョンが必要 → プロダクトビジョンが機能しなかった → ストーリーテリング。
「静的なビジョンを、動的なストーリーへ深堀ること」
セッション自体がストーリーがあるかのようで惹き込まれて響いててきてさすがだなと感じた。
「シャープに本質だけを抜き出した表現にしようとする」あるいは「そもそも事実を書き並べる以上の文章をなかなか書けない」のでつい端的な文章で済ませがちだけれど、やはり人を動かすにはストーリーも大切だなと思うことができた。
エン・ジャパン株式会社 デジタルプロダクト開発本部 部長 / プロダクトマネージャー 岡田 康豊 氏
スキルを明確化・指標化することで改善が動き出すというのは、プロダクトと同じで PM に馴染みやすいのかも。
今回のセッションの事例ではかなりガッツりやっているので、業務の中でどれだけのウェイトをかけてメンバが取り組んでいるのかが気になるところ。
東京大学 FoundX ディレクター 馬田 隆明 氏
ボリュームある発表で浅く広くエッセンスを列挙したセッション。30分じゃもったいない量だ。実経験ではなく、世の中で論じられているものをまとめた馬田氏らしい内容。ユーザーコミュニティのり活用について整理されていて、概論についての理解のリフレッシュの良い機会になった。
大きくなったコミュニティのサブグループ化は過去やってみたりしてきたけれど、やっぱりいいやり方らしい。
コミュニティのオンボーディングは、企業内でもそのまま使えるのでリストとして見えるところに書き出しておきたい。
コミュニティを育てることでエンゲージメントと継続率を高めるというのは自サービスでも意識している点。優先度がなかなか上げられないけれども継続はしていきたいところだ。
パネルセッション。PM の需要・募集・市場・オンボーディングについて。
Nota Inc.CTO 増井 俊之 氏
増井氏流の発想・発明ベースのプロダクト開発の紹介。自分が使いたいから作り、問題があればすぐ直す。
プロダクトマネジメントはほぼ関係なかったけれどウィットに富んだ参考になるセッションだった。
Zoom Video Communications, Inc Chief Information Officer Harry D. Moseley 氏
30分 Zoom の宣伝。ちょっとだけ PM の話があってまた Zoom の宣伝。
「エッセンシャル スクラム: アジャイル開発に関わるすべての人のための完全攻略ガイド」の中でメチャクチャ好きなところの1つが見積もりついて書かれている以下のくだり。
いちばん大切なことだが、見積もりの最大の目的は、話し合う過程でいろいろな気づきが得られるということだ。 -- 第7章 見積もりとベロシティ
「気づき」は原著「Essential Scrum: A Practical Guide to the Most Popular Agile Process」では「learning」と表現されている。
Finally, and most importantly, one of the primary values of estimation is the learning that happens during the estimation conversations. -- Chapter 7 Estimation and Velocity
これは見積もりというアクティビティに限らない話だよね。
このくだりを読んでから「◯◯の最大の価値は話し合う過程で気付きと学びを得ることだ」と考えることが増えた。ミーティングが意思決定や共有などのゴールを達成する場であることはもちろんとして、チーム・個人が気付きと学びを得る場になるよう常に意識していきたい。
自己組織化されたチームになっていくためには話し合い超重要。
[ opinion ]
Naney (なにい)です。株式会社ミクシィで SNS 事業の部長をしています。
nDiki は1999年1月に始めたコンピュータ日誌を前身とする Naney の Web 日記(兼パーソナルナレッジベース)です。
#nNote タグがついている記事は他の記事に比べて、より断片的・未整理・不完全なちょっとしたノートです。まだ結論に至っていない考えなども含まれます。頻繁/大幅に更新したり削除したりすることがあります。
ナレッジベースアプリケーション Obsidian で書いているノートの一部を notes.naney.org で 公開しています。
※内容は個人的見解であり所属組織とは関係ありません。