システム開発で思うところ

Javaで主にシステム開発をしながら思うところをツラツラを綴る。主に自分向けのメモ。EE関連の情報が少なく自分自身がそういう情報があったら良いなぁということで他の人の参考になれば幸い

pmconf 2019

pmconf 2019 へ行ってきました。

2019.pmconf.jp

はじめに

ざざっと、手元のメモを多少修正しつつ列挙。
その場の感想があったら、それも一旦 そのまま転記。
気まぐれに、感想も追記。
あと、PMもしくはPDMという表記は Product Managerで、PJMは Project Managerです。

ブログなど

無駄に長い私の駄文よりも、ちゃんとまとまっているブログ。
私が聞いていないものもあり、私自身が後で見るための資料集でもあります。

「普通の人、特別な結果」 byプロダクトマネージャーカンファレンス2019_議事録|TSUYOSHI(デザインマネージャー)|note

pmconf2019 - Sakapun's project

Product Manager Conference 2019 Day1ハイライト|kota_sasaki@SmartHR|note

Product Manager Conference 2019 Day2ハイライト|shige@SmartHR|note

10xのための逆説 #pmconfjp | by 矢本 真丈 (@yamotty3)

Pmconf 2019 11/12 まとめ|おかちゃん / 岡部千幸 Chiyuki Okabe|note

Pmconf 2019 11/13 まとめ|おかちゃん / 岡部千幸 Chiyuki Okabe|note

pmconf2019 一日目メモ - nickotaのあうとぷっと。

pmconf2019 二日目メモ - nickotaのあうとぷっと。

マーティ・ケイガン推薦書籍の日本語版を探してみた。 #pmconfjp - satoryuの日記

#pmconfjp で感じたプロダクトマネージャーの現在

Product Manager Conference 2019スライドまとめ

1Day

Keynote:ORDINARY PEOPLE, EXTRAORDINARY RESULTS

Marty Cagan

「INSPIRED」の著者

  • 今日は深圳から来たよ
  • PMで大事なことは Product Discovery
  • ビジネスの発見
  • valuable usable feasible viable
  • Feature teamよりも Product Team に
  • もしくはfeatureを実装する*1
  • to serve the business(not value)
  • valueをつくるのは 例えばコンサル的なところ
  • to serve the customers
  • Empowered teamsのためには
  • おすすめの本 stand up nation
  • いままで見た中で良かったチームはイスラエルのチームだったよ。
  • 出来ない理由は チームを信頼していないから
  • トップが決めないといけないと思ってしまっている。トップダウンに。
  • ほしいのは傭兵?それとも伝道師
  • 伝道師が 有効だけれど、実際に選択しているのは前者では?
  • PMがやるべき事をするのが大事。
  • amazon apple googleの創業者をコーチしたのは Bill Campbell
  • the role of leadership
  • チームがチャレンジするように導く役割
  • 北極星的なものが伝道師。
  • アメリカ人が会社をやめるのはマネージャーが嫌だったから、というのが理由
  • roduct vision
  • strategy principles priorities evangelism
  • PMは個々人のマネージメントをするのではない。
  • The role of management/ staffing, coaching(能力を引き上げる), objectives
  • Competence Caracter の2つが大切
  • 革新はエンジニアから生まれる
  • エンジニアは今何をするべきか一番知っている人たち。なのできちんとコラボをしよう

感想

Product Discovery。
「Discovery」かぁ、なかなか面白い言い回しだなぁと。

Keynote:Special Session(Kaarel Kuddu)

  • Autonomous Teamsであることで速度を保つ。
  • 意思決定はチームがする。信頼して適切な意思決定を「してもらう」。
  • 結果、失敗からも適切に学びにも繋がる。生かす。これが自主的なチームということ
  • Will that cause chaos?
  • price speed(処理速度) convenience coverage(扱えるサービス範囲)
  • freedom to make decisions?
  • 顧客への影響。データを用いて根拠を積み上げることで決定をする。
    つまり自分でプランを作るということ。発注されたものを作るではない。
    そして結果にも責任をもつ
  • PMが出来る人は 独立して意思決定も出来る人=企業経営が出来る人。
    それに加えて「企業文化への理解」もあること。
    政治ゲームをせず伝道師になる人(チームとして仕事が出来る人)。
  • 6~9ヶ月、時間をかけてPMを立ち上げるようにしている。
  • freedomはPMが顧客に必要なことや、伝道師としてチームを導くという軸があってこそ、ということ。
  • 3か月毎に宣言をして責任を明確にする(これはこれでキツイ世界だな)

感想

製品紹介の時間が長いの辛かったです。
でも、その中でもPMの育成のスパンや、裁量の委譲について具体的な話も合ったので それなりに面白かったです。

海外の現場を訪問してわかったコード中心ビジネスの時代におけるプロダクトオーナーシップ

  • 川口 恭伸
  • 経歴:ユーザーストーリーマッピングの翻訳など
  • (私が受講したアジャイル研修のサポートもされていました)
  • 海外にいく理由:一次ソースに会う&肌感を知るため
  • スイスでは3年前くらいから内製化(エンジニアを自分達で準備するかなぁ)
  • 経営者自身が入れ替わることなく、自らアジャイルを取り組むように。3年前くらいからなってきている肌感
  • なぜ、経営層はエンジニアを信用しないのか
    「俺に分かるように説明してくれ」が原因。
    説明を受けている間にビジネスのスピードが追い付かない(はげちゃびん)
  • 教育心理学概論「学校で学ぶ原理原則(抽象度高い)と経験則」
  • 分かりやすい説明が裏目になる(分かったつもりになるけど、帰ったら どういうことだったか分からない)
  • 事業部門(予算、デザイン(企画、開発(作る は「綺麗なウォーターフォール」。これはアジャイルではない。
  • パネルのように開発をしていたらそれはアジャイルではない。
  • アジャイルあるある
    やりやすいことからやってしまう。
    はじめは価値があることをやるけど、次第に価値がないものをやるように。。
    どこかでシフトチェンジが必要
    POが解決する(難しい仕事を分割したりして

感想

CSM研修とPO研修を思い出しつつ拝聴。
時間をかけてじっくり学びたいという方は、アギレルゴの研修を受けるのが良いと思います。日本の経営者も変わっていくのかな?
(歴史の長い)中小企業の経営者が そのように変化するとは なかなか想像できないけれど、寿命も含めて企業承継も含めて数年後には変わっていく可能性は十分ありそうな気もしました。

PMにおけるストーリーテリング

  • 岡田悠
  • チームにとってもPMにとっても ストーリーは大事
  • Freeeは中小企業向け(スモールビジネス向け)
  • Faxは今だ現役の世界。そういう人達を楽にしたいというモチベーション
  • 5年もたったらクラウドでのサービスは当たり前になった
    → 機能が足りない
    → (当時はマーケッターだったけど)PMとしてプロダクトを自ら良くしたい
    → backlogをつくって、それを消化する
    → 消化することが目的となって。テンションが下がる
    → ビジョンを掲げよう
    → 無風(絵にかいた餅(苦い経験
    ストーリーテリングをしよう
  • ファクトをつなげてストーリーに
    誰かの視点をもって ビジョンを普及させるためにはストーリーが大事
  • ストーリーは「話したくなる」「記憶に残る」
  • 静的なビジョンを動的なストーリーへ深堀をする
    → メンバーがストーリーを元にビジョンを語るようになった。ボトムアップ。驚くほど変わった。
  • イソップの3人の煉瓦職人
    最後の職人の「俺たちは、歴史に残る偉大な大聖堂を造っているんだ」な人がイイよねと言う話。
  • 物語の法則
    主人公が 問題を 解決する
  • 主人公は、自分に近い方が説得力が増す。当事者ゲー
  • 問題
    あるある:ストーリーに厚みができる
    そうなんだ:意外な内容で聞き手を引き付ける
  • 解決
    解決された世界には何が待っているのか。つまりは オチ大事
    主人公は必ず変化していることを明確にして鮮明な印象にする
  • ストーリーをどうやって伝えるの?
    手段を問わず叫び続ける
    PMは手段を選んではいけない
    バズれば良い
  • ストーリーを計測し続ける/オチは達成すべき目標
  • KPIは利益だけじゃなくてストーリーとしての達成度も計測すること(ストーリーを大切に扱う
  • もっとも大切なのは自分が夢中になれる物語を描くこと(by ピクサー

感想

現場の方からも推薦された岡田さんの講演。
とても面白かったし、スルスルと引き込む不思議な語り口でした。
BackLogの消化をするだけのモチベーションの低い状態は、特にベンチャーだと危険なことという嗅覚は正しいと思います。良くも悪くも ゼロから1の世界には勢いがあるけれど、それを継続する仕組みにもっていくためには どこかでシフトチェンジすることは大事だと思うからです。
Keynoteでもあった、優秀なPMは伝道師だというのであれば、チームのメンバーが自分の言葉で教義(ここだと製品の訴求力や価値)について自らの言葉で話せるように導くことが大切だということになります。だとすると、ストーリーの力は大きいと思いました。

PMにおけるストーリーテリング(Q&A)

  • 岡田悠
  • (講演を聞いていなかった人のために ざっくり講演のあらすじを

  • Q:プロダクトと事業のKPIを分けて考えるのは難しいと思う。そのおとしどころは?
    A:物語を浸透させること。そういう物語を練り上げること。 ある種の共犯者意識を持ち合うような組織にする

  • Q:マーケティングからPMになったということだけれど、エンジニアリング(ドキュメント)を作るのか?
    A:GodドキュメントをPMとして作成をして、それを全員に浸透させる。
    デザイン(What)は作ったり作らなかったり
    設計(How)はエンジニア

  • Q:バックログはつくるの?
    A:作る。ユーザーストーリーマッピング
    ドキュメントとストーリを紐付けて話をする

  • Q:事業とプロダクトのKPIは?
    A:OKRをベースに

  • Q:心に響くストーリーと経営層に向けた要約の案配は?(経営層には長い話を聞いてもらえる時間が取ってもらえない
    A:ストーリーは長いので、そういうものをして経営層に理解してもらう。
    あとは色々な機会をもうけてプレゼン以外の手段も活用する

感想

聴講者への配慮がきめ細かいと感じました。
ひょうひょうとしていているが この方の視野や見られる側として、見る側への想像力は どうやったら出来るようになるのか想像もできないです。
雑に言うと、飲みに行って色々な話を聞きたい人。

経営層へのストーリーの話を聞いていた時に個人的に思ったのは、freeeのような創業して 何十年も経っていない組織の経営層であれば、ビジョン(静的)な情報で理解出来る、というか理解出来ないのなら 多分経営からは離れた方が良いとすら思います。経営層にとっては、ビジョンで分かって当然で、ストーリーはあくまでチームの指針や製品のメッセージとして「対外的に伝わるもの」であるかどうかという手段であり、それが有効か判断するものだと思いました。
先の川口さんの講演ではないけれど、はげちゃびん な経営層であれば そもそもは その場所にいること自体が間違っているんじゃないだろうか?とすら乱暴に思ったりもします*2
先の質問をされた方の悩みは もちろん理解できるし 正直共感もします。ただ本当の問題は長いストーリーを聞いてもらえる時間が無いというよりも、ストーリーをお膳立てしてもらわないと企業の課題が呑み込めない勘の悪い給料泥棒が経営層に…(もうやめておく

教育事業におけるプロダクト・マネジメントとは

(この辺りから、少し私自身の集中力が散漫になり始めてます

  • Classi
  • BenesseSoftBankのジョイントベンチャー
  • 約半分の高校に導入されている
  • EDUCOM(こちらは小中)と協業して両面をカバーする事を目指している
  • 文科省:生きる力の育成
  • これまで入試で問われていたのは、知識と技能
    2020年からは思考力、判断力や学びに向かう力や人間性 を伸ばす
  • 先生側に管理と評価への課題
  • 生徒側も どう学ぶのかという課題
    (結局、合格するための手段にばかり目が向くよね、という話)
  • ビジネスとしてはユーザーである生徒と先生だけでなく、支払い者である保護者にも理解を獲る必要がある 難易度の高さ
  • 年一回の大規模開発サイクル
    ABテストも容易にできない。(仮説検証のサイクルが回しにくい

感想

教育分野ということだけで聴講。
一応、間接部門的な関わり方とはいえ 私も教育には関わっていなくも無いので。
教育現場の課題や、製品の導入側として考えるキーワードを知ることが出来たのは良かったのですが、なかなか没入は出来ませんでした。
おそらく、変に私の方に「意見」があることで、聞き方も良くなかったように思います。

データ/AIを活用したプロダクトの作り方と磨き方

  • 萩原 静厳
  • データ AIを活用したプロダクト
  • 東大松尾研究室
  • スタディサプリにも関わった人
  • ディープラーニング実践編」(本)
  • データホルダーとデータサイエンティストの間にdirectorが入ることで推進をすることが必要
  • 外からあれこれ言われたくないという技術者をいかにプロダクトに歩み寄らせるのかが大切
  • データAIをどこに使うのか
    有名なのはNetfixとかAmazon
  • ある事業で集めた情報からほかの業態へつなげる
    例、OYOのホテル事業(個人)から地域情報を活用して、レンタルオフィス(企業)を展開
    土地の特性などは業態とは関係なく使える。つまり応用が効くということ。
  • KOMATSU:利用率から故障予測。
    すべての重機にセンサーをつけて最終的に全体をコントロールすることをデザインする
  • データを活用して課題を解決する から データを活用できる課題を設定する
  • AI活用の4象限(軸は省略というかメモ忘れ)
市場浸透
(着手はしやすいがインパクトは小さい)
新製品開発
(ニーズは見いだしやすいが
新市場開拓
(--メモなし--)
多角化
(ハイリスクハイリターン
  • 日本のAIは画像解析とコストカットがメイン
  • 海外は戦略(ビジネスレバレッジ)を効かせるところに使っている

感想

KOMATSUのIT戦略は、10年以上前に読んだ日経SYSTEMS(か そのあたりの雑誌)でも見ました。重機メーカーの社長が ここまで戦略的にITのことを理解し推進しているのかぁ、と その当時も印象深かったことを覚えています。私自身も「俺、良く分かんないけど AIで(ITで、でも良いし インターネットで、でも良い)ビジネス立ち上げて~」というような経営者では意味が無いという話をする際に、KIMATSUの施策を話題に良く出します。一般的に重機とITは距離が遠いという印象を持たれていることもあり、興味深く話を聞いてもらえるネタです。

日本のITは 先の岡田さんのQAのところでもあったように、経営層へ現場から お伺いを立てる(?)ケースが多いため、数値に測りやすいコストカットや効率化というアプローチが多いのかもしれないと思いました。現場にある一定の裁量を与えて口を出さないか、トップダウンで推進しないと(出来る人がいないと)、ビジネスレバレッジを効かせる所に使うのは難しいのではないかぁと思ったり。。

発明、ドッグフーディングプロダクトマネジメント

  • 増井 俊之
  • 慶応SFCの教授
  • POBoxを作った人
  • Appleフリック入力
  • Gyazo
  • 増井ラボノート
  • Scrapbox(!)
  • ニーズがあるからつくるのではなく自分が使いたいから作る
  • ユーザーインターフェース研究は論文を書いたら終わりなので実際に作るところまで至らないことが多い(せっかく良い問題を解決するような論文を書いていても実際には作るところまで至っていない)。
  • 発明家兼PMは少ない
  • 発想フェーズと運用フェーズは別物

感想

Scrapboxを作られたのは、この方だったのか!という驚きが一番。
とにかく熱っぽく早口に話す様子が好感しか持てなかった。
自前のIMEで文字入力をしているので、バグがあったら全てが止まるので必死で修正するとか もはやそれはドッグフーディングというよりも セルフバイティングじゃないか?とすら思いました。

Keynote Session(Harry D. Moseley)

  • Zoom VideoのCIO
  • (声が役者のように良い)
  • 年々倍々で動画時間が増えている
  • PMに必要なもの、、情熱
  • ボックスの中で価値を最大化する
  • ユーザーのneedを、wantではなく(ここはちゃんと聞けた自信ない)
  • (低音ボイスの美声)

感想

Zoomって自動翻訳もできるみたいです。凄いですね。精度の話まではしませんでしたが、本プレゼンを Zoomを介して自動翻訳しながらの講演だったら そのインパクトは凄いものだと思った次第です。
Zoomが成功した理由とのことでしたが、成功しているZoomの紹介では?と思ったり思わなかったり。

確実に言えることは、声が良すぎて情報が入ってこない(私の集中力が枯渇していただけという話もある)

ネットワーキング

本カンファレンスを教えてくださった方からの紹介で Agilewareの方*3と 少しお話させていただきました。名刺を見て「ん??どこかで見た製品群(Lychee、GIJI)??」と思い、記憶を手繰り寄せて「あっ、デブサミ?」と思い出すに至りました。確認させていただいたら その通りでした。滅多にありませんが、こういうこともあるのがカンファレンスや勉強会の面白さかもしれません。
ちなみにGIJIについては、スマートスピーカーを使って 多言語対応(同じミーティングで日本語と英語の話者がいても議事録が作成できる)もあるとのこと。面白いですね。

またPO研修で 同じグループだった方にも偶然お会いしました。正直、かなりビックリしました。また、その方が PO研修だけでなく、色々なカンファレンスに参加されているというのも伺って、行動的で勉強熱心なところに刺激を受けました。その方には 終わったばかりではあるけれど、EOFというカンファレンスが面白かったということで次回機会が合えば行ってみたいと思いました。

2Day

今からはじめるデザインスプリント

  • 佐藤伸哉
  • 翻訳本もあります
  • お勧め書籍:SPRINT最速仕事術
  • 読むとできそうだけど、卓越した人向け。実際は難しい。
  • 調査に2~2ヶ月かける。例えばここをデザインシンキングは5日でやるとか。
  • プロダクトの予測でも使う
  • 正確はなく、色々な組織で様々な形で導入
  • デザインスプリントは平野レミ
    決められた時間内で結果を出す。その場で全部作る。
  • Map
  • 全体と詳細の理解
  • まずはチームメンバーで知っていることを全部共有する (なので厳密な調査をしていうわけでもない)
    その後、有識者からしっかりと情報を聞く。
    「全員が」メモをとる。
  • 5~15くらいのステップに
  • ターゲットの選定(あとから変えず、ここで一旦フォーカスを絞る)
  • Sketch
  • 個人で考える。
  • 全員でディスカッションはしない。理由は声が大きい人が引っ張って終わるから
  • 慣れるまでは文字でも良い
    なれたら絵をつかって抽象度を高くしておくと良い。
  • まずはアイディアを出すという行為をプロセスに入れる
  • Decide
  • 個人の主観でアイデアを即決する
  • プレゼンや説明するとユーザー目線が無くなり、上下関係や政治に流されることが多いため。
  • サイレント投票(禅投票)
    決定権が強い人には多めにチケットを渡して投票行為のバランスをとる
  • ProtoType
  • 実際に使える形で検証したいアイデアを形にする
  • でも、実際の現場ではprototypingをするのは稀
  • Test
  • 大きな問題のパターンをみつけるにはユーザーインタビュー5人で85%の課題は見つかる
  • やるときは1on1で
  • 短く早く、作った人がやるのが良い
  • 他メンバーは各自が別室でメモをとる(メモは全員でとる
  • 気づきは違うし、課題が明確になるのでアクションプランがたてやすい
  • 重要なのは次のアクションが見えることが大事
  • プロトタイプを修正して再びテストを行うことも
  • ただし、デザインスプリントは同じ課題にたいして、リテレーション前提にしない。
  • 真剣さを保つ
  • Google流 desighsprintkit.withgoogle.com
  • こちらは 6つ
  • DEFINE が追加
  • UNDERSTANDの次に、ちゃんと問題を定義する
  • ライトニングトーク(各自5分、25分
  • 発表者以外はメモをとる
  • 状況理解
  • エクストリームユーザを考える
  • リフレーム:状況を違う環境に置き換える
  • ペインポイント:障害弊害を考える
  • 問題定義
  • スケッチ(アイディアの芽を箇条書きで
  • 決定
  • イデア売り込みするケースもないケースも
  • プロトタイプ
  • 検証(ほぼほぼやる時間がないのが実情
  • Voice Action Sprint Frameworkもある
  • あるある
  • ポストイットが足りない問題
  • アイディアは 山ほど絞り出してようやく出てくる
  • ポストイットは写真でとったら捨ててしまった方が良い
    覚えていないアイディアはそもそも価値はないし、読み返すこともない
  • スプリントマスターがいればアイディアがでる?→NO
  • アジェンダ通りには進まない
  • フレームワーク軽視 or 依存
  • 日米の違い
  • VPや事業部長が出てこない。→ゆえに(日本は)決まらない。
  • デザインスプリントは「その場で」決めることが重要。
  • やってみたけど、うまくいかないあるある。
  • チームでやると言いづらい。
  • 意見が攻撃ととられる。これは組織の体質

感想

デザインスプリントというもの自体を知りませんでした。
思った以上に短時間でアイディアの方向付けを確定していく印象でした。
全員がメモを取るというのをルール化しておくことは とても良いと思いました。誰一人お客さん状態にならないのは大切。
良かれと思って言われている意見も なんだかんだいって言われた後に凹むことは沢山ある。逆に相手にも そういう思いを与えることも。分かっているけど なかなか難しい。
忘れる力が欲しい*4
同じくらい聞く力も欲しい*5

愛と解釈のコンダクター

  • 広野萌
  • 指揮者は解釈を与えて(提示して)
  • 演奏者は その解釈を それぞれの個人が解釈を表現する
  • 解釈が一体感を生む
  • PMで大事なのは「解釈(自分としての)」と「提示(メンバーへの)」
  • 今後、サービスはブランドになるだろう。それがデザインだと思う
  • チームをプロダクトの犠牲にするのはNG
  • マネジメントはしないけどコントロールをする
  • 時に感情のコントロールも必要
  • 愛が大きすぎて熱狂してはいけない。
    指揮棒を足にぶつけて死んだ指揮者の話
  • スタートアップあるある
  • がむしゃらに働けば日の目を見るのではなく、考えて行動も
  • 恋は盲目、愛は瞠目(だから愛が大事
  • プロダクトと人だったら、私は一緒に働く人を重視する

感想

「恋は盲目、愛は瞠目」は 凄く良い表現。
ついつい、気持ちが入りすぎて(恋)になって 攻撃的になることも。思い入れや真剣さは大切ではあるけれど、やはり どこかで一歩引いた感覚も大切。少なくとも人と一緒に何かを作るのであれば、そんな風に思いました。
逆に どこかで誰にも気にしないで盲目になれるような人でもありたいなぁとも。

打席に立ち続けられるプロダクトチームを作ろう

  • DeNA(黒澤 隆由
  • タクシー配車(MOV)
  • チームの在り方は フェーズで異なる
  • 常に成功をさせるのは難しい。打率を上げることが大事
  • 営業やマーケッタの意見は、それぞれに於いては正しいが、それらをむやみに取り入れられない。
  • 指標が打率
  • 柔軟であること=専門性+多様性
  • 何でも出来る人があつまる?
    80点の人を集めて80点のものを作るのではなく、スペシャリストを集めることも。
  • その逆に専門家だけだと多様性が足りない
  • PDMとPJMを役割を分けた体制を作る
  • PDM:何を、なぜ 作るのか。プロジェクトへの妥協はNG
  • PJM;いつまでに、どのようにつくるのか。リリーススケジュールへの妥協はNG
  • PDMは足りない。。
  • PDMに求められるものを定義
    →事業目標を達成する人
  • プロジェクトの価値を明確にする
  • 価値をともなったプロダクトを作る
  • コミュニケーション力 大事
  • PDMがいない ものづくりは存在しない
  • PDMを専門職として強化する
    評価と育成
  • 育成?
    デザイナとエンジニアと会話ができるとか
    UXがわかっているとかわかっている人をどう育成するのか?
    スペシャリストと協同することで学び成長し合える場を提供する
  • 壁打ちをする場をもうける
  • 個々の強みを伸ばすことでパフォーマンスできる機会を提供する
    (全部が出来る人はいない)
  • 失敗できる環境を提供する
    (プロトタイプを通じて、メンバーからのフィードバック、ブラッシュアップ)
  • PDMリーダーズミーティング
    執行役員を交えて芽のあるメンバーをバイネームで共有する場を設けている。
  • Hiring(外部からの採用)も大事

感想

開発者や管理者という体制ではなく、プロダクト責任者を作るためには役員も含めて名指しで共有する必要があるというのは納得。
川口さんの話でもあったけれど、執行役員がプロダクトのビジョンなり方向性なりを きちんと共有する(しようとする)主体になる変化は実際に起きつつあるという感じ?(といっても、いわゆる社歴の長い中小企業とは違うけれども。。)

UXの視点から見るプロダクトマネジメントの倫理と社会的責任

  • SNSやブログはNG

感想

NGということなので、感想も含めて止めておいた方が良いのかな?

PMはどのようにバリューを出していくのか

  • プレイド
  • PMが入るところは新規事業やビジネス要件が強めのところ
  • ただしプレイドには役割としてPMというものはない
  • あえていえば フォーカスを充てる主体の具体的な一人の人のこと
  • すぐにissueにする
  • 週に一回棚卸し。閉じるのも大事。
  • 重要だったらまた上がる
  • 作るべきものを見つけるためのアプローチ
  • 少し先を考える
  • 自社のアセットや強みがいきるもの(強豪がいないのが理想
  • ペインは、やりたいことと現状の差分。でそれを課題として解決を図る
  • マーケット規模や動き
  • 三者レポートと外の繋がりや一次情報に触れる
  • 強豪プロダクトの動き
  • ユースケースベースで気にするけど、あんまり気にしない
  • クライアントの課題
  • CSとも話そう
  • 自社の強みをきちんと振り替えると気がついていないことが沢山ある
  • 事業に関わらず「会社としての強み」がある
  • 価値あるものを見つけて作る
  • アイディアは組み合わせ
  • パターンを作れることが大事
  • 深い知見が必要になったら、そこで持っている人を巻き込んでいけばいい
  • PMは営業やエンジニアのHUBであり、そこを担う責任があるのは大事
  • 無理矢理長期的なことを営業やカスタマーとエンジニア全員で話し合って、共有するのは価値があった
  • 強いメンバー(リーダーシップ&高いスキル
  • 役割が決まっていない中での人事評価だが、少人数なので今のところ評価制度はない。試行錯誤中。
  • あえていえば、給与にフォーカスが向かわないものがベストかな?
  • つまり給与は自分がきめて企業はそれに ちょいプラスくらい
  • 大事なのは優秀な人に囲まれ続けるような環境が優先すべきかも
  • フォーカスの見直し頻度は3ヶ月くらい
  • 長ければ6ヶ月くらいのこともある(短いことも
  • 可視化もしており、2Wくらいに共有する場も設けている
  • 合理的に考えるならヒエラルキーが良いし分かりやすい。(評価もしやすい。
  • でもそのような統制はよくなくて、思考と意思決定をする文化を持った組織でありたいとして大事にしたいと思っている。
  • なので人が増えたときは そういうことを共有するためのキャンプをしたりしている
  • コトにフォーカスするのが大事
  • ヒットの裏付けを求められることへの対処はない。
  • 例えそれらしいロジックがあったとしても そんな答えに意味はない
  • むしろもっと定性的な判断と行動から振り返りをした方が価値があると思っている

感想

企業規模と創立からの期間を鑑みても、これから どうやって その文化を育て続けられるか?というのが次のテーマになりそう。
ベンチャーあるあるにならないための土壌もありそう(定性的な判断と行動から振り返りをした方が価値があると思っている)。
人事評価については、、うーん 確かに難しいところ。
「優秀な人」が求めているのは、裁量か 収入か(もちろん両方なんだろうけど、あえて言うとしたらという意味で)。
いずれにしても、あるタイミングで離脱することを前提にして常に振り返りなどでプロダクトに知見が集まるように仕組みは ある程度あるような印象を持ちました。

CTOやVPoEとプロダクトマネージャーとの理想の関係

  • パネルディスカッション
  • 松岡剛志@レクター
  • 組織構造は、1チームで始まり、職能別チームをつくり、事業部制を経る
  • 結果、リードタイムが長くなる
  • その中では意思決定を自らするチーム(プロダクトチーム)をつくるのが今の流れかも
  • 組織構造による対立はある
  • 職能別だと、自部門の成功が中心となってユーザー目線がない対立
  • 事業部制は職能対立は小さくなるけど事業部間の対立は起きる
  • 組織における理想の関係のベースにはアジリティが重要
  • 意思決定がブレずに早いのがベスト(全部一人がやるのが最短)
  • でもそうはいかないので分割するとして、CPOとCTO
  • 現実的には自分のロールを達成しつつ横の領域へ前向きに侵食するような取り組みをするのが良いのでは?
  • まずはJD(job decisions)をつくるところから
  • 役割を決めたとしても、それを振り替えって見直しはするべき(計画をたてる)
  • ロールを決めたら、ロールを守ることに注力する人もいるでしょう。それだけに終わらないようにするには文化形成かと。
  • 「それが良い!」となった時に推進するはCEO(もしくは偉い人)
  • なんだけど、それをするためにボトムアップで情報を提供することも大切
  • 議論がKPIとかユーザーに向かっていれば良いだろう。
  • それが「自分が(我々は)」ということでなければ
  • PDMからのアプローチとして粘り強さがほしい。 「できない」で終わってほしくない
  • CTOを上回る情熱をぶつけるPDMの意見は通る(通さざるをえないでしょう

感想

「このセッションがパネルディスカッションだったと知っていた人?」と言われたが、はい、知りませんでした(笑)
このセッションはEOFに参加された方が松岡さんの話は聞くと面白いですよ、ということで聴講しました。

綺麗事だけをいうのではないのが印象的でした。
(「まぁ、実際きついよね」とか そういう感じの語り口)
CTOを上回る情熱の話はキーエンスの話を思い出しました。
自己主張だけでは駄目ですが、なんやかんや言っても そのプロダクトへの熱量に対してCTOは投資してしまうもの。

『突破するプロダクトマネジメント ~ 実践編』

  • 必要な素養みたいなものを話します
  • クラシルの会社のCxO
  • 一秒でも早く正確に市場評価できる体制構築
  • 起業時:Product Market Fit
  • グロース期:収穫するのが大事
  • ユーザーは自分のほしいものがわからない
    =ユーザーインタビューのまま作っても使われないは「あるある」
  • 壁:突破すべきコト
  • ロードマップで可視化
  • 基盤系やDAU積み上げが後回しにならないように
    =重要度が高いことを取りこぼさないようになる
  • 毎月アップデート
  • 価値を作るという意思をチームで持たせる
  • 100点の基準を合わせる
  • 締め切り=品質基準がすりあった成果物の納品
  • 週1から2の頻度でプロダクトレビュー。NGな理由を言語化ことが大事
  • 品質を求めるとリソースほしい問題が生まれる。
  • リソースの壁を突破する
  • その際に環境の見直しや制度の導入を行う
  • 人が増えてくると権限委譲
  • 100人の壁の超え方
  • 社長と週1の1on1をしたものを全員に言語化して共有
  • ストックではなく、フローでカルチャーを作る(Slack
  • UX課題のほとんどは、アイディア問題ではなく問いの適切さと壁を乗り越えた実現への執着
  • それがPDMの役割だと思う

感想

ストックではなくフローでカルチャーをつくるというのは、言われてみると確かに大事なことのように思います。
例えば まとめてブログやWikiに書くというのも大事ですが、Twitterで思ったこと 気が付いた事を その時に ささっと書くというのを比べたときに 継続させやすさだとTwitterの方かもしれないという感じで。
実際、ブログの更新は止まっていても、Twitterでの発言は止まっていないケースは多いという感覚はあります。

UX課題はアイディアではなく問いの適切さと実現への執着というのは、クリエイティビティの低い私には心強いアドバイスに聞こえました*6

面白いプロダクトの作り方と魅せ方(B-Side)

  • 軸がユーザーやメンバーにとって面白い、ワクワクするということをおけば大体うまくいく
  • 魅せ方大事
  • リアルタイムデータの可視化
  • 嫁の行動の可視化でキャッチーに(朝のゴミ捨て行動を可視化
  • デモは自分で作る

感想

講演中に電話で呼び出される奥様。
嫌な顔せず対応するの素敵です。 データ活用の可視化というと、とかく高尚で難しく考えてしまいがちですが、力を抜けた面白さを目にすることで思考が柔軟になるような気がしました。
とはいえ「面白いことをまじめに考える」のは難しいんだよなぁ。。

プロダクトマネージャが陥るカスタマーサポートの盲点

  • 豊川 弘樹
  • それって自信がありますか?を仮説検証する
  • 全部やらなくていい。
  • 重要度と優先度
  • 大事なのは繰り返し

感想

立ち見だったのでメモ少な目。
CSにメンテナンスができる開発者を数名置くだけでも、サービス品質へのアプローチは かなり良くなるという話。

「何をつくらないか」を考えるリーンプロダクトマネジメント

  • (立ち見だった&疲労のピークでメモなし

感想

「何を作らないか」と「何を作るのか」を小さく早く確認する、というアジャイル開発の話。
(力尽きる。。)

さいごに

自分に向けた、もしくは私を知っている方に向けたメモと思っていただけたら幸い。

はじめに に書くべきだったかもしれませんが、参加の切欠はCSM研修で同じグループだった方から教えていただいたからです。
私とは全く違うキャリアでソフトウェア開発に関わっている方で、具体的には その方は企画やPOといった いわゆるプログラマーとは違う経歴で、SIer経歴の私は出会ったことのないタイプ。私としては現地で再会して研修の場とは違う形で お話できたら学べることが必ずあるし きっと面白そうという思いもあって、語弊を恐れずに言うならば pmconfそのものが そこそこでも、そこに価値はあり と判断したというところもありました。結果、両方とも学びがあり面白かったです。

そもそも、SES的な契約形態のフリーランスである私*7にとって、pmconfに参加する意義(モチベーション)は、どこにあるのか(あったのか)というところですが「私が関わる人にとっては必要となるであろう」と思ったからです。私自身が 例えばPMとかPOとかCSMとかの主体になるか?というと実際のところ、多分無いでしょうし、今のところ そうなることを熱烈に求めてもいないというのが本音です。でも、これからの開発において その構成員として「普通に満たしてほしい期待値」には応えたいというくらいには負けず嫌いな私としては、相手が求める「普通」について無知であるのは嫌だなぁと。かつて、私は立場としてPLであった期間があり(それなりに長く)、当然 チームには様々なメンバーがいました。かつてのPLであった自分からみて、欠かせない人になれるほどの力はなくとも、せめて、自律的に期待値を満たす人ではありたいなぁというのが基準です。

モチベーションというには、あまりにもレベルが低いかもしれませんが、そんな感じでも 実際に参加することで スピーカーの熱に当てられるのも悪くはないものです。
あえて今回のカンファレンスの きつかった事を挙げるとしたら、技術がメインのカンファレンスでは 基本的にはない「隣の人と3分間 話してみましょう!」は、コミュ障な私にとっては かなりシンドイというのは隠さざる本音です。*8

おまけ

ウォーリーを探せ*9

*1:これ自分でもどういう意図のメモか不明

*2:とはいえ、現実は というのは重々分かってはいますが…

*3:講演者ではないので 名前は控えます

*4:いや、成長しろよってね。。

*5:いや、だから聞けよってね

*6:執着心(負けず嫌い)は、人並みにはあるつもり

*7:個人開発をする発想力もなく、SIer企業に所属していないだけで やっていることは全く同じ。昭和なブラック耐性が備わっただけで そこそこの結果しか出せないモブ(笑)

*8:私は 色々なスイッチを上げ下げしないと初見の人に限らず 人と話すのが難しいのです。それが取っ払われるのは 強い好奇心を感じた時と 仕事という共通の課題が双方の間にある時と あとは謎の気まぐれが発動した時。我ながら面倒くさい。

*9:晒せではないので悪しからず

DDDへの距離感

最近、仕事場で 「DDDって分かります?」 と聞かれて、うーん と思いながら

「仕組み(アーキテクト)と、設計デザイン(思想)の両面があって、仕組みの話はクリーンアーキテクチャのそれに類似だと思います。設計の方はユースケース駆動みたいなフローではなくて、1つ1つのクラスの責務をボトムアップで積み上げていくみたいな感じでしょうか」

ドメインの実装に外部依存を無くして業務の関心事をまとめる、みたいなのも設計側のポイントみたいな気もします」
と答えた(つもり)。
ちゃんと伝わったか、正直自信もないし、それが正しいか?と言われると、、「うーん」と言う感じ。*1

私自身の最近感想として、私はユースケースとかフローとか 流れを中心にしか システムの全体像を把握できないから イマイチ「DDD」を口にするのを避けていたりも。

結局のところ、私が興味を持っていたのは POJOを如何に独立させるのか とか、どうやったらコードで意図を表現できるのかってことであって「ドメインで駆動する」こと自体ではないんだよなぁって。

「VOとか型をつかって実装しよう」「Repositoryと使ってDIP」っていうのは 好みだけど、それをもって「ドメインで駆動している」とは言えないよねぇって。それは あくまで構造の話であって、デザインとは違うっていうか。
もしくは、言葉通りに ドメイン駆動 というのであれば、レイヤー、BC、VO、集約って周辺の話(駆動を支えるもの)であって、あくまでコアは ドメインで駆動するだとすると、それは私には馴染みが悪いというか。

レイヤーや構造の話は設計デザインを支えたり、実現するためのアイディアではあるけど コアではないよねって。

なので、DDDっていうのは避けがちで、関心事(ドメイン)と外部要因を疎結合にする仕組み というようにしていたり、厳密ではないけれど 構造の話をしているという意図で「クリーンアーキテクチャみたいな」という感じで*2、雰囲気を共有する感じで逃げている。

まぁそんな感じ。

多分、TDDが自分に馴染みが悪いと思ったのと近い感じ。
逆にいえば TDDがしっくりくる人は DDDは実質出来ていると思う。

ブログのタグ DDD だけど、これは 構造のアイディアをもらっただけで、駆動はしてないから どうしたものか 迷いつつ残しておこう。*3


*1:最終的には、DDDが出てきた文脈を聞いて、その文脈に合うであろう回答はしたと思うので、おそらく 必要な回答はできたんだと思う

*2:厳密なクリーンアーキテクチャとも違うし、本読んでないし

*3:自分が検索しやすいから

Node.jsのメモ

書籍:Node.jsデザインパターン

github.com

JavaScriptの配列風オブジェクトと「[].slice.call()」による配列変換について - このすみろぐ

コールバック関数地獄を軽減

Node.jsでファイルの読み込みreadFileとreadFileSync

Express

2017年はNode.jsの達人になる!いま知っておきたいベストプラクティス10 - WPJ

express実践入門 · GitHub

Best practices for Express app structure

Express の動作環境を切り替える(NODE_ENV 変数) | まくまくNode.jsノート

[Node.js]Express4で環境ごとの設定をつくる - Qiita

読み込むために参照した情報

実行しているコードが保存されているファイルの名前を取得する | 情報アイランド

What does callback && callback() mean in javascript - Stack Overflow

その他

Node.js の起動オプション、環境変数、npm start の話 - Block Rockin’ Codes

https://maku77.github.io/nodejs/express/switch-env.html

ログ関連のメモ

ログ設計指針 - Qiita

ネットワークのメモ

JavaScriptのメモ

ES2015(ES6) 入門 - Qiita

おじさんが若い時はね$.ajax()のオプションでsuccessとかerrorとか指定していたんだよ(追憶) - Qiita

VueをSSRに乗せると容易にXSSを生み出す場合がある件について - Qiita