SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

CodeZine(コードジン) DeveloperZine(デベロッパージン)- エンジニアの意思決定を支える技術情報メディア ProductZine

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

ProductZineウェビナーレポート

現在のプロダクト開発に立ちふさがる“3つの分断”を乗り越える方法とは

ProductZineウェビナー「プロダクト作りのトランスフォーメーション」レポート

プロダクトを畳むとき、リモートの壁、MVPが見えない…現場の悩みが率直にぶつけられたQ&Aセッション

 最後はウェビナー前半に登壇したはてなの粕谷大輔氏、門脇恒平氏も加わり、参加者からの質問に回答。市谷氏が進行を務めた。

Q.プロダクトを作る際、上位職から「俺の言うように作れ」と言われることがありますが、市場のニーズに合致していないと思われます。どう説得すればよいでしょう。

粕谷 上司の意見が市場ニーズと合致していないと判断したのであれば、その逆をやればよい。なんらかの根拠があって合致していないと判断したので、合致している市場ニーズは何なのか、それを掘り下げてコミュニケーションをとればよいと思う。

門脇 同じ意見になってしまうが、コミュニケーションで解決するか、泣き寝入りをするかどっちかだと思う。前者はパワーが必要で、しかも置かれている立場やキャリアにとってリスクがある。議論のきっかけはあると思うので、その辺を整理してぶつけてみるとよいのでは。

Q.プロダクトを畳むことになった経験はありますか。もしあった場合、畳み方で気をつけたことは何でしょうか。

門脇 プロダクトではないが、機能単位で閉じるということはいくつか経験がある。畳む際ではなくプロダクトの設計段階で、畳むことになったことを考慮に入れておくことが重要だと思う。

粕谷 僕自身、経験はないが、会社としてプロダクトを閉じたことがある。考えるべきことはそのプロダクトが持っている社会的意義や価値について。例えばブログサービスを閉じる場合であれば、そのブログの情報を他のブログサービスに移せるように準備する。プロダクトが社会にもたらしていた価値を失わないように可能な範囲で考えることを大事にしている。

市谷 私も経験があるが、プロダクトを畳むことで人がやめる可能性があることを知っておくこと。そのためにやっておくべきことをやることだと思う。

Q.今回のコロナ禍のようなユーザーの周囲の環境や価値観が大きく変わったと思われる場合、どこまで遡ってプロダクトの提供価値を見直せばよいでしょうか。

粕谷 遡ることはしていない。よりスピーディーな変化が求められるので、今までのやり方だと少しのんびりしすぎているので、そこを見直す必要性を感じた。

門脇 遡って考えると、これまでの議論や作ってきたものの進化になりがちなので、ゼロベースで考えることが大事だと思う。

Q.リモートになり今まで以上に雑談の必要性を感じているが、そういう時間を設けようと思っても、必要性を感じない、苦手という意見が出てくる。特にリモートだと敷居が高いように感じる。

粕谷 本来は任意に参加にしてもらう場を設けて、そこでなるべく必要性を感じてもらうようにするのが理想。それは難しいので、昼会など限られた強制的な場を使ってなんとか試みるのがよいのでは。

門脇 最適なアプローチはない。あらゆる打ち手、施策は、パフォーマンスを上げる、いいものを作ることが目的。パフォーマンスのためということで議論し、参加を各自に判断してもらう。もちろんパフォーマンスにも責任を持ってもらうように話を進めるのがよいのでは。

Q.ゆるやかにつながっていることを目指したコミュニケーション手段として、分報チャンネルを設けようと思っているが、どう思われますか。

門脇 メリットだけではなく、デメリットもあると考えている。発言しやすい場所を作るのは否定しないが、たまにのぞくと、大事なことを言っているがアクションにつながっていかないことが多い。アクションにつながることを阻害することになるのが、ポジティブに捉えられない理由。

粕谷 うちにも分報チャンネルはある。門脇さんと同じで情報を細分化するのはよくないと思う。個人の「こんなご飯を食べておいしかった」というのを書くのはよいが、仕事の話をそこでするのはお勧めしない。

Q.私は開発チームなのですが、新しいことに取り組む際に、MVPが見えないことがある。現場からのヒアリングはある程度されており、PMからざっくりとした機能のイメージは共有されますが、いざスプリントを始めると、開発チームはどう進行すればよいか、どこまでUXを突き詰めればよいか、分からないこともある。見積もりも漠然としている。開発チームはデザインチームに対して、少し及び腰になったりもする。漠然とした質問ですが、どうすればよいでしょう。

粕谷 やることが分からないのであれば、バックログリファインメントなどで分かるようにすること。またイメージがざっくりしているのであれば、ざっくりをなくす方法を考えること。

市谷 PMとUXチームの人によく分からないとはっきり言えばよいと思う。それが言えない場合は別の問題を抱えていると思う。

門脇 見積もりが漠然としているのであれば、スタートのための準備がちゃんとできていないということ。またデザインチームに対して及び腰になるのであれば、そこに大きな隔たりがあるということ。このような状況で仕事を進めるのは難しいので、上の方に話をして組織として改善してもらうことが必要になるのでは。

Q.雑談を設定する際の考え方を教えてください。

門脇 意図的に設定するのは雑談ではない。そこまで難しく考えず、雑談を目的化してもよいのではないか。

市谷 雑談という言葉に抵抗があるのであれば、例えば振り返りの場で、本来のテーマに収まらないものも含めて会話してみる。

粕谷 振り返りの場を使うのは名案かと。例えばKPTツールに「昨日、食べたプリンがおいしかった」と書くと、それに対してみんなが雑談になる、そういう場作りはできるのでは。

Q.新しいことの推進方法で悩みがある。新しいことについて、2~3人の間では熱く語れるが、大勢の前に出ると萎縮してしまう。どうすればよいか。

粕谷 前に出る人を捕まえて言ってもらうのがよいのでは。

門脇 僕も同意見。アイデアはみんなもの。サッカーのフォーメーションのように、必要な役割を複数人で担保する。自分の苦手な部分を補完してもらう人を見つけて進めるのがよいのでは。

市谷 口頭での発表が難しければ、社内で書き物ができる場所に書いて表現するというのも1つの手だと思う。

次回ウェビナー情報

 開催日時:11月18日(水)19時~20時10分

 登壇者:丹野瑞紀氏(プロダクトマネージャー・カンファレンス実行委員)

 申し込み:

この記事は参考になりましたか?

連載通知を行うには会員登録(無料)が必要です。
既に会員の方はを行ってください。
ProductZineウェビナーレポート連載記事一覧

もっと読む

この記事の著者

中村 仁美(ナカムラ ヒトミ)

 大阪府出身。教育大学卒。大学時代は臨床心理学を専攻。大手化学メーカー、日経BP社、ITに特化したコンテンツサービス&プロモーション会社を経て、2002年、フリーランス編集&ライターとして独立。現在はIT、キャリアというテーマを中心に活動中。IT記者会所属。趣味は読書、ドライブ、城探訪(日本の城)。...

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

この記事は参考になりましたか?

この記事をシェア

CodeZine(コードジン)
https://codezine.jp/article/detail/13007 2020/10/16 11:00

おすすめ

イベント

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー