nDiki : プレゼンテーション

プレゼンテーション - presentation

2018年3月10日 (土)

今日のさえずり: 久しぶり。学びにきた。

2018年03月10日

[ 3月10日全て ]

2018年10月11日 (木)

mixi日記風スライドにしてみた

昨日は部署で、今日は本部で、上半期ふりかりと下半期キックオフのミーティングを行った。今回は SNS の事業部らしくということでmixi日記風スライドでプレゼンテーションしてみた。

PC 版 mixi のスタイルシートを見ながら色やフォントサイズ比をピックアップして Google スライド上に図形を使ってそこそこmixi日記風にできてちょっと自己満足(実際にプレゼンテーション資料を作る段階では見やすさを考慮して適宜本文テキストを大きくしたりした)。

半期を日記形式で時系列にふりかえるの割といいんじゃないかと思っちゃうの、どんだけ自分日記好きなんだろと。

[ 10月11日全て ]

2018年11月7日 (水)

プロダクトマネージャー・カンファレンス 2018 2日目 #pmconfjp

image:/nDiki/2018/11/07/2018-11-07-092414-nDiki-800x1200.jpg

プロダクトマネージャー・カンファレンス 2018 2日目。

以下メモ。

10:00 - 10:15 [07-01] Welcome Talk

プロダクトマネージャー・カンファレンス 実行委員長 関満徳氏

今日もタイムテーブルから遅れて 10:10 スタート。

10:15 - 10:45 [07-02] 巨大なFinTech事業開発におけるプロダクトマネジメント

▲株式会社FOLIO 代表取締役 CEO 甲斐真一郎(@folio_kai)氏

経営者という立場でのセッション。金融サービスは一般のネットサービスとは異なる要求がある。また今まで枯れた業界であった。3カ月でできると思ったが2年かかったとのこと。 リリース後に単一プロダクトから異なるビジネス/KPIの複数のプロダクトに事業展開していく中で、個別のアプリケーション部分と共用されるバックエンドという構成になっていきマネジメントが複雑化し始めたとのことだった。

今は全プロダクトを単一の巨大なプロダクトバックログで管理しているのだそうで、今後どうしていくのかぜひ知りたいところ。単一の方が事業全体での優先度が明確になるもののリファインメント含めバックログの管理コストが大きいという問題があり、これはいつも悩ましい判断である。

その他の紹介されていた課題ははエッセンシャル スクラムでも取り上げられているテーマのものが多く、あるあるだなーと。

「愛されるプロダクト」

(まだ FOLIO 社にはいないが)プロダクトマネージャーには「プロダクトへの尊敬」を求めたいとのこと。プロダクトへの尊敬とは何だろう。愛じゃ駄目なのかな。

11:00 - 11:30 [07-03] C向けアプリのPM経験者から見た、B2B SaaSのプロダクトマネジメント

▲株式会社マネーフォワード MFクラウド経費本部 本部長 プロダクトオーナー 今井義人

短期的にはプロダクト改善が最適な改善ではない。人力で頑張るという局面も確かにあるよね。

B2C と B2B の違いはそうだよねで終わりがち。これから B2C から B2B に移ろうとしている人には参考になるかもという感じ。

「愛されるプロダクト」

「愛をお金に変えよう」で築いたエンゲージメントをベースに、より高いプランを作って移ってもらう施策などを紹介。

11:45 - 12:15 [07-04] 気がついたらプロダクトマネージャーになっていた

Nature株式会社 代表取締役 CEO 塩出晴海氏 新規事業での製造まわりのトラブルあるある談を含めた、プロダクトリリースまでのストーリー。プロダクトマネージャーというよりは起業家としての話。あきらめずにやり切る態度は凄いな。

「愛されるプロダクト」

特に話題なし。

12:25 - 12:40 [07-05] リクルートの横断組織で考えるプロダクトマネジメント

▲株式会社リクルートコミュニケーションズ ICTソリューション局 アドバンスドプロダクト開発部 部長 宮里裕樹氏、▲株式会社リクルートコミュニケーションズ ICTソリューション局 戦略企画グループ マネジャー/シニアプロデューサー/シニアプロダクトオーナー 金田將吾氏

細かいところはエンジニアがどんどん進められる組織なので、プロダクトマネージャーは HOW ではなく WHAT に注力しているとのことだった。開発チームのスキルや成熟度によって千差万別なところだ。

プランナーと呼ばれていた人がやっていた役割を

  • ビジネスプロデュース
  • プロダクトマネジメント
  • ITディレクション
  • プロダクトリード

に分けて定義しチーム体制を構築、得意な役割を任せたり不得意な役割を成長させたりしているらしい。しっかりピープルマネジメントに取り組んでいるなあと感じた。

「愛されるプロダクト」

特に話題なし。

12:40 - 12:55 [07-06] 顧客、会社、チームをHappyにするプロダクトマネジメント 〜観点・プロセス・レバレッジ〜

▲楽天株式会社 顧客戦略統括部 Vice Senior Manager 山下徹朗氏

顧客・会社・チームを Happy にする」ことをプロダクトを作る目的として事業を進めている。全能なプロダクトマネージャーは(ほとんど)いないので、ビジネス・UX・マーケティングについてそれぞれ担当を割り当てそれぞれ問いを立て答え続けていくことで結果を出すプロダクトを生み出すという体制を全てのプロジェクトで採用しているとのことだ。

「愛されるプロダクト」

冒頭で「高すぎる目標の」「自己満足な」「誰のためのかわからない」プロダクトという偏った愛あるあるという話を取り上げていた。

12:55 - 13:10 [07-07] Build Narrative in Product

▲株式会社ドワンゴ サービス開発本部 副本部長 池田明啓氏、株式会社ドワンゴ セクションマネージャー 宮城良征氏

前半は、様々な手法を利用・開発してプロダクトマネジメントに取り組んでいるという紹介でとても研究されているなと感じた。知らない手法が紹介されていたので、それぞれちょっと調べてみたいな。

後半は実際のプロダクト開発事例の紹介。

「愛されるプロダクト」

特に話題なし。

13:40 - 14:10 [07-09] The mindset of building the product that user will love

▲株式会社メルカリ UX consultant Jasper WU 氏

Design Thinking についての非常に洗練された圧倒的なプレゼンテーションだった。ベストスピーカー賞があれば絶対 Jasper WU 氏だったと思う。

自己紹介や会社紹介などに時間は割かずセッションのメインテーマに絞ってきちんと語られた。直メルカリのプロダクトについて直接アピールしていないのだが Design Thinking についての取り組みのみの中で出てくる感じなのだが、結果的に組織・プロダクトについて好印象を受けてしまうというマジック。

デザインスプリントで駄目な案だったということがわかったことは失敗ではなく学びだということがきちんと根付いているのが素晴らしいなあ。

デザイン思考についてもきちんと学びたくなった。

「愛されるプロダクト」

一過性のキャンペーンを繰り返すのではなく、継続的な取り組みをしていくことが愛されるプロダクトにつながると言っていた。

14:25 - 14:55 [07-10] 北米・アジア・欧州のプロダクトマネジメントとスマートニュースのプロダクトマネジメント

▲スマートニュース株式会社 プロダクトマネージャ 宮田善孝氏

海外のカンファレンス紹介は、カンファレンスセッションとして知見を広める良いコンテンツだった。

スマートニュースではファンクショナルな組織のもと、プロジェクト毎に人が集まりチームを作るという体制とのことだった。プロジェクト毎にチームビルディングが必要そうだなというのと、機能開発プロジェクト終了後のその保守についてどうなっていくのかが気になった点。ファンクショナルな組織の方で保守していけるのかな。

「愛されるプロダクト」

特に話題なし。

15:10 - 15:40 [07-11] 中国のプロダクトマネジメントのリアル

Baidu, Inc. Product Manager 陈兆伟 (Chen Zhaowei)氏

日本語入力アプリ Simeji のプロダクトマネージャーの方のセッション。

コンピュータサイエンスやビジネススキルの高いスキルが求められる米国とは違い、中国のプロダクトマネージャーはニーズを掴みイノベーションを生み出す能力の方が求められているという話だった。またプロダクトマネージメントが階層化されていて、プロダクトマネージャーの下にプロダクトマネージャーがいる体制らしい。Baidu ではプロダクトマネージャーの役割/スキルについてのテーブルがあり、育成にも力を入れているようだった。

「愛されるプロダクト」

特に話題なし。

15:55 - 16:25 [07-12] Anycaにおけるプロダクトマネジメント

▲株式会社ディー・エヌ・エー オートモーティブ事業本部 Anyca事業責任者 馬場光氏

DeNA もプロダクトマネジメントの定義をしっかりともたれていた。 DeNA でも「全部できる人はいない」という前提で体制化しているようだ。

やはりある程度の規模になるとプロダクトマネジメントの定義・体制化・育成の仕組みが必要だなあ。

「愛されるプロダクト」

特に話題なし。

16:40 - 17:40 [07-13] [ワークショップ] 日本のプロダクトマネージャーは今何をすべきか

東京大学 本郷テックガレージ ディレクター 馬田隆明(@tumada)氏、プロダクトマネージャー・カンファレンス 実行委員長 関満徳氏、プロダクトマネージャー・カンファレンス 実行委員 本登史文氏、プロダクトマネージャー・カンファレンス 実行委員 横道稔氏

馬田氏は「逆説のスタートアップ思考の人」の方。

「なぜ愛されるプロダクトにしていく必要があるのか」また「そのために自分の Next Action は何か?」をカンファレンスの最後にワークショップ形式で考えましょうという枠。聞きっぱなしにさせず、きちんとリフレクションまでカンファレンス内で完結させるという仕組みを入れるところに運営のセンスを感じた。

まわりの人と自分の考えを披露しあってその言語化を相手にさせるというフォーマット、1つめのワークで sli.do というサービスで anonymous で入力させて気持ち的な投稿障壁を下げたあとに2つ目のワークで自社製品名まで書かせるテンプレートで Tweet させるというマーケティング戦術にも恐れ入った。

ちなみに1つ目のワークで自分が考えた愛されるプロダクトについては

わたしは愛されるプロダクトがだいじだとおもっている。なぜなら「チームメンバの士気とパフォーマンスが向上し、さらに良いプロダクトへと導ける」から。

で Next Action については

わたしは「製品名」をもっと愛されるプロダクトにしたい。そのためにわたしは「プロダクトマネージャーを組織化する」。

としてみた。

17:40 - 17:50 [07-14] クロージング

プロダクトマネージャー・カンファレンス 実行委員長 関満徳氏

2日間合計の来場者数速報値は563名との発表。1ホールでのカンファレンスでは結構な人数だ。

[ 11月7日全て ]

2019年2月14日 (木)

Developers Summit 2019 1日目 #devsumi

image:/nDiki/2019/02/14/2019-02-14-145351-nDiki-800x1200.jpg

2015年2016年2017年以来、2年ぶり4回目の Developers Summit 参加。一昨年には無かった Wi-Fi のスポンサー提供があってとても快適になった。素晴らしー。

朝1番のセッションの冒頭で今回の事前登録が4000人超という話があった。大盛況。会場の混み具合からするともうキャパオーバーも近いのではと思えてくる。各セッション会場でのバーコードチェックがステージ近くで、まだセッションが終わる前に次のセッションの人が誘導されて入ってきたりして、待機列の問題からだろうけれど、ちょっと発表者に失礼なんじゃないかなーとは思ってみてた。

以下セッションタイトルは2月13日時点の公式サイトより。

10:00〜10:45 【14-D-1】 Scrum@Scale入門

株式会社アトラクタ 原田騎郎(@haradakiro)氏

メモ
  • スケール
    • 全く同じチームを複製してくことはできない。違いのあるチームを増やしていく。まずうまく行っているスクラムチームを2つ育ててから、スケールさせる(そうでないと悪いものがスケールする)。
  • Scrum @ Scale フレームワーク
    • スクラムだけでもスケールする。
    • スクラムマスター(SM)
    • プロダクトオーナー (PO)
      • チームに1 PO。PO チーフ PO。チーフチーフ PO。
      • PO は上位のオーナーが絶対。
    • 各チームに常に PO と SM がいる。そうするとチーム単位で動かせる。ニーズの変化でチームごと動かせる。チームを立ち上げる時間よりも、チームが新しい担当を覚える方が早い。チームを壊さない。
  • PO
    • 「調査してから…」ではなく「今間違えろ」(辛いけど……)

思ったこと

やはり適切な人数の自己組織化されたチームで構成される体制を作っていきたいな。エッセンシャル スクラムだとプロダクトバックログは唯一なものと書かれていたと思うんだけれど*1、現実的なところ抽象度の違う階層化されたバックログとチーム毎にそれぞれあるバックログという感じでいいんだな多分(エッセンシャル スクラムでも階層化バックログ自体は紹介されている)。

*1 どんなプロダクトバックログをいくつ用意すべきかを考えるにあたっては、基本原則がある。プロダクトごとに、プロダクトバックログをひとつ用意するというルールだ。-- エッセンシャル スクラム 6.7

11:05〜11:50 【14-A-2】 GitHub Actionsはどのような未来を描くのか : コンテナ技術が開くワークフローOSS

GitHub 池田尚史(@ikeike443)氏

GitHub Actions で Docker イメージを作成して、デプロイまで実行できるようになるという話。デプロイ以外にも GitHub 内での様々な処理も。

12:10〜12:40 【14-A-3】 GCPに恋してHashiCorpを愛して起業したエンジニアのお話

株式会社grasys 長谷川祐介氏

サンドイッチ。HashiCorp 製品と Google Cloud の紹介。それから企業の話についての自分語りを伺えた。

13:05〜13:50 【14-D-4】 大学におけるイマドキのエンジニア教育

ワイクル株式会社 角征典(@kdmsnr)氏 株式会社アトラクタ 永瀬美穂(@miholovesq)氏

前半永瀬氏による enPiT 事例紹介。

後半角征典氏のエンジニアリングデザインプロジェクト(EDP)を通じた知見紹介。参加者の多様性とモチベーションのばらつきを意識した取り組みが素晴らしい。

こちらでもやはり最適なチームについて(人数・多様性)が取り上げられていた。メンバの多様性によるデメリット(ここではモノづくり工程ではデザイナーができることが少ない)もきちんと示されていて、その上でそうしているという話で説得力があった。

ただ「やってみているという話」ではなく、裏打ちされた方法論を押さえた上での取り組みで学びのある話だった。

東工大生イジりが嫌味がないのも素敵。

14:10〜14:55 【14-D-5】 新技術導入を成功させる組織のつくりかた 〜spanner、GKE導入の実体験から得たこと〜

株式会社コロプラ 廣本洋一氏

  • コロプラでのマネージメント事例。2年前に事業部制から機能別組織に。
  • コピーベースで新しいアプリケーションを作ることによる課題があった。
  • ノーメンテナンス時間というポリシーを前提とした技術選択。
  • オーバーエンジニアリングとの戦い。

機能別組織だからこそ、事業部とは別のロードマップで優先度判断ができる部分があるのだなと感じた。

15:15〜16:00 【14-A-6】 レガシーとのいい感じの付き合い方 〜15年続くウェブサービスのシステム改善パターン〜

株式会社VOYAGE GROUP 福田剛広氏 小林徹也氏 駒崎大輔氏

ECナビについて2年弱かけて AWS 移行した話。

サービスの長期運用で技術が古くなり、エンジニアから見た魅力がなくなり新規採用で苦戦したり、在籍エンジニアのモチベーションがダウンしたりというのはあるある話だ。

別だったインフラとアプリの管轄を分けないようにする・オンプレから AWS に移行する・いったんそのままの構成で移すなどは、そうだよねというかそうするよねというかそうしているよねとかそういう感じ。現実的・保守的な判断かなと。

発表者の1人が年末退職済みということで、嗚呼となった。

16:20〜17:05 【14-A-7】 ZOZOTOWNのDWHをRedshiftからBigQueryにお引越しした話

株式会社ZOZOテクノロジーズ 塩崎健弘氏

BigQuery 移行事例についての、味わいのある発表。

今日はシャッター音少なめだなと思っていたのだけれど、このセッションは賑やか。聴講者の層が違うのかな。

17:25〜18:45 【14-A-8】 「ITエンジニアに読んでほしい!技術書・ビジネス書大賞 2019」プレゼン大会

高柳謙氏 株式会社丸善ジュンク堂書店 平木啓太氏 株式会社スマートニュース 瀬尾傑氏 株式会社アトラクタ 永瀬美穂(@miholovesq)氏

技術書・ビジネス書のそれぞれトップ3人の著者(や関係者)によるプレゼンテーション投票・発表のセッション。

[ 2月14日全て ]

2020年10月27日 (火)

声に出して発表練習【日記】

明日の本部の下半期キックオフミーティングで10分ほど発表する。発表慣れしていないので、声に出して2時間以上練習してみた。

先週の金曜日にえいやと作ったスライド、ストーリーはまあまあかなとして声に出してみるとこれがぜんぜんスムーズに喋れない。詰まったページを修正しては最初から練習を繰り返して、下手なりに形にはなったかなと。

オンラインでのプレゼンテーションだと「後ろの席から見えにくい問題」への配慮が不要になるので、今までよりも情報を詰め込んでもいいんじゃないか。と言い訳して喋りやすいようにポイントをどんどん書き込んじゃった。

[ 10月27日全て ]

2021年7月3日 (土)

『イシューからはじめよ』

イシューからはじめよ (単行本)

問題に取り組む前に「今本当に答えを出す価値のある問題(イシュー)」かどうかを見極める。そしてスタンスをとり、イシューに対して「問い」ではなくいきなり「答え(仮説)」を出す。

という考え方を紹介しているのが『イシューからはじめよ』だ。いかにして意味のある仕事を選択し成果を出していくかかが説明されている。

「問題を見極める」重要性をここまで明確にしているのを読んだのは本書が初めてだ。仮説思考の徹底ぶりもすごい。この2点を常に意識できるようになれれば本書を読んだ価値があるだろう。

第1章から「イシューからはじめる」アプローチ

  1. イシュードリブン 今本当に答えを出すべき問題=「イシュー」を見極める。
  2. 仮説ドリブン イシューを解けるところまで小さく砕き、それに基づいてストーリーの流れを整理する
  3. 仮説ドリブン ストーリーを検証するためのに必要なアウトプットのイメージを描き、分析を設計する
  4. アウトプットドリブン ストーリーの骨格を踏まえつつ、段取りよく検証する
  5. メッセージドリブン 論拠と構造を磨きつつ、報告書や論文をまとめる

について各章でポイントを解説している。ソリューションを考え出してプレゼンテーションをまとめる際に何度も読み返したい。

個人的に刺さったのは「イシューと仮説は紙や電子ファイルに言葉として表現することを徹底する。」というくだり。やはり「文章で書く」こと大切だよね。

本書を知ったのは Developers Summit 2019 の「ITエンジニアに読んでほしい!技術書・ビジネス書大賞 2019」プレゼン大会。同年のビジネス書部門大賞となっている。その後2020年5月に思い出して読んだ。読書ノートをまとめてなかったので、読み直してみたのが今日だ。

本書では問題設定から問題解決案/論文のアウトプットまでが主なスコープで、読んだ多くの人がコンサルティング的な仕事を思い浮かべるのではないだろうか。

ネットサービスのプロダクトマネジメントでは、承認を得るのがゴールではなくユーザーに価値を届けて成果を出すのがゴールである。仮説検証の段階でプロダクトをリリースしてできるだけ早くフィードバックを得て、検査と適応を繰り返していく。ライトウェイトなループの中にうまく本書の考え方を取り込んでいきたい。

[ 読書ノート ] [ お薦めの本 ]

[ 7月3日全て ]

2021年7月6日 (火)

今日のさえずり: ランバダ聞いてる

[ 7月6日全て ]

2021年12月18日 (土)

今日のさえずり: 「Web3」ふわふわしてるし、どうもわくわくしないな

[ 12月18日全て ]

2023年1月13日 (金)

今日のさえずり: Twitter Blue のサブスクリプションマーク (青いチェックマーク) ついた

  • 08:39 Yokohama #photography RICOH GR III #GR #GRIII #GR3 https://t.co/NMnxWW3WsF
  • 08:40 13日の金曜日始まった。
  • 12:50 Twitter Blue のサブスクリプションマーク (青いチェックマーク) ついた。
  • 12:52 1週間から10日ぐらいかかるんじゃないかと思っていたけれど2日でついた。 https://twitter.com/...
  • 12:59 話題の記事 (Top Articles) 機能が文字通り話題をざっと把握するのに結構良くてたまにチェックしている。 なお「フォローしているアカウント」の話題の記事は良いけど、「フォローしているユーザーがフォローしているアカウント」の話題の記事はダメ。
  • 13:21 NG: Tweetbot 3 for Mac NG: twitcle plus for Android OK: twitcle plus for iOS
  • 15:44 おやつハンティングしにコンビニに行ってくる。
  • 15:53 ハッシュドポテトをハントした。
  • 20:41 あれっ、雨降ったのか。
  • 20:46 降ってる。
  • 21:38 Deckset for Mac ちょっと飽きてきたので、何か別のプレゼンテーションツール使いたいな。 「ビデオ会議時代のプレゼンテーションツール!」みたいなのないかな。
  • 24:33 サイトの画像ファイルサイズを減らすのに、手始めに1つ WebP に変更してみた。 Lightroom Classic からは直接書き出せないので Photoshop に渡して WebP で保存。 結構小さくなった。
  • 24:36 WebP って「ウェッピー」だと初めて知った。今まで心の中で「ウェブピー」とよんでた。
  • 25:34 2023年1月13日 (金) したこと - サイトの画像を1つ WebP にする
[ 1月13日全て ]

2023年5月19日 (金)

iA Presenter Preview for Mac をダウンロードして触ってみた

Markdown で書けるプレゼンテーションツール iA Presenter のプレビュー版をダウンローとして触ってみた。

Deckset より洗練されている感じ。

Deckset と違ってエディタが含まれているのやはり扱いやすい。 「Markdown で書くプレゼンテーションツールは好きなエディタが使える」といっても文法・解釈の違いが微妙なストレスが残るので、専用のエディタもあった方がいいんだよね。

iA Presenter は430円/月か4,300円/年、あるいは8,600円で買い切りという価格設定になった。

プレゼンテーションツールを使うのは年4〜5回ぐらい。買い切り後2年でメジャーアップデートになると予想すると、1回860円か。ちょっと躊躇する値段だね。iA Writer ぐらいの価格だったらすぐ手が出るんだけれど (とこの文章を iA Writer で仕上げながら)。

今日のさえずり: 寒いけど寒くないことにする

  • 07:15 今年も街角で咲きはじめました。 #photography RICOH GR III #GR3 https://t.co/nZUDTAGcvl
  • 11:45 sample #photography RICOH GR III #GR3 https://t.co/VHkuyquF45
  • 14:54 Google Meet のビジュアル エフェクトにフィルタが追加されていたので一通り試してみた。まばたきが連動する「ロボット」がいちばん好き。
  • 20:01 半袖 T シャツで来たけど、もしかして帰り寒い?
  • 20:48 寒いけど寒くないことにする。
  • 21:44 朝に選定したヘアードライヤーを購入しようとしたら売り切れてた。
  • 22:25 iA Presenter Preview for Mac をダウンロードして触ってみた。 Markdown で書けるプレゼンテーションツール。 Deckset より洗練されている感じ。Deckset と違ってエディタが含まれているのやはり扱いやすい。価格はちょっと悩ましい。
  • 22:45 iA Presenter は買っても使うのは年4〜5回ぐらい。買い切りでメジャーアップデートまで2年10回使うと見積もると躊躇する価格である。 iA Writer ぐらいの価格だったら悩まなかったんだけれどね。
  • 25:28 2023年5月19日 (金) したこと - Google Meet のフィルタ エフェクトを全て試す - iA Presenter Preview for Mac を試す
[ 5月19日全て ]

About

Naney Naneymx

Naney (なにい) です。株式会社MIXIで SNS 事業の部長をしています。

※本サイトの内容は個人的見解であり所属組織とは関係ありません。

Process Time: 0.027063s / load averages: 0.40, 0.39, 0.32