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

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

使用しているのに未使用と言われてしまったimport

NetBeans

はじめに

解決

事象

移行前

f:id:vermeer-1977:20200903212833p:plain

移行後

f:id:vermeer-1977:20200903214205p:plain

対処

f:id:vermeer-1977:20200904090903p:plain

ユーザーがインストールしたプラグインのところに「nb-javac」というものがありました。 非アクティブだと解決しなかったのですが、アンインストールして立ち上げなおすと、事象は解消しました！

ただ、日本語化プラグインは欲しいので 改めて日本語化プラグインを入れなおすと、再び nb-javacが復活を繰り返して 再発。。
立ち上げなおしたり、nb-javacを自分で入れなおしたり、なんやかんやしてたら上記の状態に！

f:id:vermeer-1977:20200904091257p:plain

通知にnb-javac インストールしてください的なものが見えるのですが当面は保留にしておきます。

謝辞

twitterで助けていただきました。
ありがとうございました。

さいごに

ユーザーがインストールしたプラグインを個別にアンインストールする方法がわからず。。 「ダウンロード済み」リストに並ぶものかな？と思っていたりもしましたが空っぽ。
今回のようなこともあると思うので、ダウンロードして適用したプラグインは 一か所にまとめておこうと思った次第です。

【雑記】新しいPCを購入（OMEN）

はじめに

数年ぶりに新しくPCを購入。 少額固定資産（30万）以下にしようと思って見つけたのが こちら

OMEN Laptop - 15-dh1004tx

キャンペーン価格で30万以下（税込）でした。
ゲーミングPCです。
機械学習試したくなったら（今は無いけど）、GPUとかも気になるだろうし、持ち歩きしないけど ノートパソコンしておきたいなぁなど考えたら ここに落ち着きました。

再セットアップをするときに必要な情報リンク集的な感じでの まとめ*1

使い心地

当然、サクサク動いてくれます。

やったこと（やっていること）

VirtualBoxでLubuntuを使う

なぜ？Linux

開発環境をUbuntuベースにしようと思ったから。
今の仕事で初めてMacを仕事で使いました。
これまでWindowsでの開発で困ったことがなかったので、いずれやろうかなぁと思っていたLinuxへの開発環境の移行を先送りしていたのですが「それなりにできそうかも」と思えるキッカケになりました。
Macよりも、キー割り当てが近いのでUbuntuに。

なぜ？Lubuntu

以前から、軽量Ubuntuとして少し触ったことがあったから。

なぜ？VMで開発

今回のPC移行をするにあたって、開発環境の移行がなんやかんや言っても地味に面倒さを感じたから。
環境が壊れた時を見越してバックアップするにしてもVMにしておくのは良いだろうと。

VirtualBoxデビュー

厳密には、多少は使ったことはあるけれど、手順書作成でローカルにLubuntu入れて画面キャプチャとったりとかピンポイントな利用。
PCスペック的に厳しくて、サクサクとまでもいかず、最低限の活用で終わってました。

図解！ Oracle VirtualBoxが重い/遅いときの対処方法 | 仮想マシンソフト
VirtualBoxのVDIサイズを縮小する - Ragnite Blue
VirtualBoxの共有フォルダの自動マウント | K'zlog

Java11デビュー

とりあえず思考停止で「AdoptOpenJdk」の 8 と 11 を入れました。
https://adoptopenjdk.net/

JVMも思考停止で、HotSpot

ubuntu — UbuntuでJava環境のパスを設定する方法

Netbeans12デビュー

NetBeans8系を使っていましたが、ようやくバージョンアップ。

Downloading Apache NetBeans 12.0

日本語化は、こちらから
NetBeans 11.1のリリースと日本語化 | junichi11.com

新機能は日本語化されないとのことですが、そもそも基本機能くらいしか使っていないので全く問題なくイイ感じです。

Eclipseの導入（断念）

EclipseはAmaterasERDのために使っています*2。

導入で参考にさせていただいたページ
Eclipse（2019年12月版）のインストール，日本語化，基本操作（Ubuntu 上）

AmaterasERD
AmaterasERD - Project Amateras

とりあえず起動するところまでは確認。 以前作成したものの編集などの確認はこれからという感じ

表示されない（Windows版ではできたと聞いたけど、Linux版ではうまくいかず。。断念）

Payara5の導入

Back to Basics - Payara ServerをUbuntuにインストールする

よかったこと

やりなおしがやりやすい

環境設定周りは、よく分かっていないとか、Typoとか、viに慣れていないとか、とにかくトラブルが多いものです。
以前*3は物理PCにOSを再インストールを良くしていたものですが、壊しやすい（？）ので気楽なものです。
それなりに構築できたかな？というタイミングでフリーズしてしまった後で「スナップショット」を作ったら良かったという後の祭りもありましたが、その辺りも含めて「色々やってみて気が付く」のは、良いことです。

Lubuntuでも特に違和感は無さそう

少しだけコードを触ってみた感じですが、キー操作がWindowsに類似なので問題なさそうです。
「ctl+space」がNetBeansの入力補完のとmozcの日本語モードで被っていたので変更したくらいでしょうか。
これから、色々と感じることもあるカモですが、とりあえず初見としては問題ないですね。

サクサク

PCスペック様様なのですが、メモリが32Gあるし、CPUもよい感じなので、以前のPCでVMを使った時とは比べ物にならないくらいサクサクです。 *4
自分が操作をしているのがVM側ではないと錯覚するくらいにサクサクです。

Java11への道のり

バージョン上げて、既存のプロジェクトをビルドしたら エラー。
まずはスタートラインへ立ったという感じです。

さいごに

キーボードのLEDはオフにしています

*1:なので、順次追記する想定

*2:へっぽこなのでGUIからDDLを作りたい

*3:20年近く昔

*4:理解していなかっただけで以前のPCでも、それなりに能力を引き出せたのかもしれないのですが

Reactのメモ

React

公式

チュートリアル：React の導入 – React

Redux Toolkit | Redux Toolkit

useEffect完全ガイド — Overreacted

状態管理

比較考察

React ステート管理 比較考察 - uhyo/blog

Recoil

React 新しい状態管理ライブラリ Recoil の紹介

Context API

ベストな手法は？ Reactのステート管理方法まとめ - ICS MEDIA

Redux

TypeScriptでReactをやるときは、小さいアプリでもReduxを最初から使ってもいいかもねというお話 | フューチャー技術ブログ

Redux Toolkit で React.js の状態管理をもっと簡単にする方法[TypeScript版] | webOpixel

HookとRedux ToolkitでReact Reduxに入門する | Hypertext Candy

React-Query

Overview | React Query | TanStack

React Query 101 - DEV Community

ReactQueryでキャッシュを最大限利用する | microCMSブログ

REST API なら React Query がファーストチョイス

React Queryのkey管理について

URL操作

クエリパラメタをReactコンポーネントに渡すときはreact-routerが便利 - Qiita

[React Router] URLクエリストリングを取得する

etc

https://www.learnstorybook.com/intro-to-storybook/react/ja/get-started/

Material-UI を普通に使うと Storyshots がうまく使えない ++ Gaji-Laboブログ

第9回 2020年版 ReactにStoryshotsを導入する - Qiita

reactjs — onKeyDownイベントがReactのdivで機能しない

React今昔物語 - ICS MEDIA

React 触り始め、よく遭遇する問題まとめ（個人的に） - 奇をてらったテクノロジー

React / Redux を実務で使うということは
（画面描画のタイミング制御など効率的なReactでの制御を細かく書いているブログ）

Reactのデザインパターン Compound Components - Qiita

Compound React Components with Hooks + TypeScript | Martin's Blog

[redux] Presentational / Container componentの分離 - react-redux.connect()のつかいかた - Qiita
（Reduxの話ではあるけれど「Provider直下のコンポーネントはPresentational componentであるのがよいらしい」らしい）

TECHSCORE｜React: そのrender()はいつ呼ばれるのか | TECHSCORE BLOG

How to get previous props/state with React Hooks - LogRocket Blog

React.memoをサンプルを使って解説 - エンジニアの本棚

フックに関するよくある質問 – React

React.memo / useCallback / useMemo の使い方、使い所を理解してパフォーマンス最適化をする - Qiita

React の Context の更新による不要な再レンダリングを防ぐ 〜useContext を利用した時に発生する不要な再レンダリングを防ぐ方法に関して〜 - Qiita

React hooksこんな風に使ってみたよ - Qiita

DecoratorsでReactコンポーネントを拡張する - Qiita

React Hooks の useEffect の正しい使い方 - Qiita

React ContextでuseReducerを使ってみる - Qiita

React.ts の状態管理に useContext を使う - Qiita

VSCodeのTypeScriptのバージョンを変更する - 新しいことにはウェルカム

ReactContext用のLoggerを作った - Qiita

知っていると捗るcreate-react-appの設定 - Qiita

Uncontrolled Components でシンプル且つ高パフォーマンスなフォームの実装 - React Hook Form - Qiita

CssInJsPerf/App.tsx at 76b8b0172a4f9b938e099a7c2906d6e63ae8d831 · GiridharKarnik/CssInJsPerf · GitHub

2020 年、 React 軸で学ぶべき技術 - mizchi's blog

reactjs - React.js/Redux: setInterval and clearInterval in Reducers - Stack Overflow

Reactで実装したコンポーネントのマウント時に工夫したこと - EatSmartシステム部ブログ

ヌルヌル動くReactコンポーネントの作り方【入門】 - カミナシ開発者ブログ

React Hooks: 子コンポーネントから親の状態をレンダー時に変えたら叱られた ー Warning: Cannot update a component while rendering a different component - Qiita

React Hooksでデータを取得する方法 - Qiita

Build

Create React Appで作成したアプリを任意のサブディレクトリに配置する | NO MORE! 車輪の再発明

Deployment | Create React App

React開発時には、APIサーバーとReactアプリサーバーを別にして、プロキシを使うというベスト・プラクティス

Reactで実装したコンポーネントのマウント時に工夫したこと - EatSmartシステム部ブログ

リポジトリ

yarn workspaceでmonorepo+TypeScript+Lint環境をつくる - Qiita

Multi-root Workspacesで、React monorepoプロジェクトのautoimportをいい感じに動作するようにする - BASEプロダクトチームブログ

yarn workspaceでtsconfig.jsonを共通化したモノレポを作りたい - Qiita

TypsScript

さようなら、TypeScript enum | Kabuku Developers Blog

【TypeScript】 Object[key]() （ブラケット記法）で関数呼び出ししたら Element implicitly has an 'any' type でハマった話 - Qiita

Typescript ブラケット記法(Object[key])でno index signatureエラーをtype safeに解決したい。 - aknow2

https://cloud6.net/so/typescript/1499504

デザイン/Storybook

画面を作る | Storybook Tutorials

rebassのComponentをStorybookのStoryに追加する際のひと手間 - Qiita

Rebass

Solarized

The `sx` Prop – Theme UI

https://microcms.io/blog/storybook-react-use/

React×TypeScriptでStorybookを5.1.9から6.0.26にメジャーアップデートしたハマりどころ

Vue と CSF によるモダンな Storybook 6 のはじめかた

Next.js + TypeScriptにStorybookを導入して遭遇したエラーを全て共有します - パンダのプログラミングブログ

デザイナーがデザインツールを使わずに、Reactを使ってデザインした話 - Medley Developer Blog

Next.js + TypeScriptにStorybookを導入して遭遇したエラーを全て共有します - パンダのプログラミングブログ

@storybook/addon-storyshots - npm

Next.js+TypeScript 環境で Storyshots を使う（Storybook 6 対応） ++ Gaji-Laboブログ

react-icons - npm

javascript - Rerender view on browser resize with React - Stack Overflow

vue.js - How to mock modules in storybook's stories? - Stack Overflow

How to mock api calls in Storybook - DEV Community

Using Storybook and Mock Service Worker for mocked API responses - LogRocket Blog

クリーンなReactプロジェクトの21のベストプラクティス - Qiita

Suspense

React Suspense in Practice | CSS-Tricks

ReactのSuspenseで非同期処理を乗りこなす

React Suspense と Hooks を同時に使う方法について - Qiita

Use React.Suspense to wait for an image to load - Sergio Xalambrí

その他

超楽しくてカッコいい、Reactで始めるThree.js入門 - Qiita

[React Hooks] useAudioなるカスタムフックをつくってみた - Qiita

【React】HTML5のaudio要素で音楽を順番に再生する - Qiita

Custom audio player with React hooks - CodeSandbox

Scrolling with Page Up/Down Keys in React-Window

React DnDでかんばんボードを作ってみる

WEB色見本 原色大辞典 - HTMLカラーコード

Single Element CSS Spinners

ReactでOverlay Spinner Componentを作る - Qiita

JSON Server*1

github.com

フロント開発で使うAPIモック - JSON Server - やのうの記録

【React】フックとjson-serverをFetch APIで連携（Reactライフサイクルの理解） - クモのようにコツコツと

json-serverを使って簡単にAPIをmockする - Qiita

*1:Reactとは違うけど、実装時に関係あったという事で

Developers Summit 2020 に参加してきました

勉強会

event.shoeisha.jp

に参加したので感想などを…
その場で残したメモに多少手直ししたくらいのものなので、登壇者の発言もあれば、自分の感想もある ごった煮です。

資料まとめ

デブサミ2020、講演関連資料まとめ：CodeZine（コードジン）

感想など

13-D-1：LINEがプライベートクラウドを選ぶ理由

  • 聴講のモチベーションは 最近プライベートクラウド(k8s)のシステムに少し関わっているから
  • プラットフォームチームからのアプリチームへの関わり方についてのヒントがあれこれ
  • Verda（ベルーダ）っていうのは基盤の名前ってことで良いんだよね？*1
  • 基盤利用の在り方はチームメンバーをリーダーが管理するのと、スクラムによるチームで違いがあって良い
    前者はベンダー集合体のようなチーム編成、後者は同じ会社メンバーであったりエンジニア以外で編成されたチームに、みたいに適材適所がある
    前者は管理者にロールアドミニを持たせて権限管理しっかり（いろんな人がいるからね）、後者はメンバー一人一人に権限付与の権限を渡している（全員で１つの仕事をするからね）
  • 間違いは起きる前提のPFにしている
    たとえばDNS登録時に レビューではなく仕組みでチェックする
  • 「なぜプライベートクラウド？パブリックで良いんじゃないの？」
    Yesではあるけれど、クラウド管理者と開発時点で相談をしてベストアンサーを把握してから開発をする
    プライベートクラウドの場合、新機能への調査をして適用させる
    プライベートだとPFチームは開発するサービスに意識が向く。パブリッククラウドの利用だと「使い方」に意識が向く。
    アドバンテージはPFチームのマインド
  • OSS活動（OpenStack）について
    VM５３０００、ベアメタル３万の規模
    スケールとハイパフォーマンスに関するコミットが多い
    MQはRabbitMQを使っている

13-B-2：モノタロウがGCPで挑戦するデータドリブン・ECプラットフォーム〜持続的成長の舞台裏

  • 購買に関わるコストを下げることが使命
  • 1800SKU
  • データマーケティングが成長の牽引

  • 業界用語での検索も出来る（この辺りの工夫は面白いと思った）
    それを仕組み化している（人力では不可能）

  • データの集約して分析をしやすく

  • データにIDをつけるなどもして一意性を追加で付与
  • データの集約先はBigQueryにした。GCP使っているし協力なスケーラビリティ
  • CDCによる安定したデータ連携
  • 変更イベントをトリガーにしてBigQueyへ。変更から連携完了までは1分を目処に
  • リアーキテクチャリングのポイントはデータのリアルタイム性

  • DBをHUBのように使うとスケーラビリティが悪くなる
    MySQLへのストアを中心としたアーキテクトだから、という前提での話
    （DB中心は 割とあった仕組みだと思うけど、今だったらメッセージ駆動な感じにするんだろうな。顧客価値へ直結しないというと言い過ぎかもしれないけど、多少の欠落があったとしても価値の減損が限定的な場合は結果整合性（もしくは整合性すら多少目をつぶっても）で良いと思う。）

  • マイクロサービス化の目的はデータ活用（再掲）

13-D-3：サーバーレスなPCI DSS対応クレジットカード決済基盤システムを運用しながら、みんなでわいわいDIYの精神で、新しいモバイル決済サービス6gramを作っている話

  • 長いタイトル
  • 決済システム（PCI DSS対応）にはグローバルな「仕様」があって それを守らないといけない
  • パスワードの変更サイクル（９０日）とかも、その範疇（なので 現在では意味が無いと言われている仕様であったも 対応しないといけない。へぇー）
  • コンテナをReadOnlyで使うことでインスタンスを使わないので侵入不可な仕組みしてしまおう（発想が面白い
  • 開発チームはPM、開発、デザイナー含めて10名以下（だったと思う。メモに残せていなかったけど、いずれにしても決済の仕組みと考えると びっくりするレベルの小部隊という印象
  • クレジットカードを共有ウォレットとして使えるサービスも。今は招待制（このあたり、かつてのmixiっぽい？

13-A-4：我々はZOZOTOWNのクラウドジャーニーを通じて何を学んだのか？

  • 川崎さんってMSの人では？と思っていたら やっぱりそうだった
  • ピーク、オフピークの差が激しい
  • スケールへの影響が大きく複雑性の低いバックエンドからリプレース
  • ストアドコールからAPI（AKSベース）に更改、」しかも参照系から
  • 「アプリケーション回復性パターン」
  • クラウドリソースを過信してはいけない。大量リソースが必要なことが予測できている場合は事前にクラウドベンダーに相談をすること
  • キャッシュが100%に張り付いたときにアプリの挙動が想定外にレスポンスが返ってこなかった（対策はとっているつもりだったけど結果としては十分ではなかった）
  • クラウドは安くはない、従量課金モデルは長期的には高い
    だからクラウドはやめましょうではなくて、短期的な課金だけで判断するものではないということ
  • 話は クラウド対応の教科書的な事例と言っても良いことばかりだったけど、それを実体験を通じて得た言葉として意味はあったと思うし、Azureの有識者であろう人が実感として発信していることに意味があると思う。

13-A-5：楽天がモノリス→マイクロサービス & オンプレ→クラウドで経験した光と闇

  • 元の構成：Iaasベースで永続化は物理ディスク
  • Azureベースにリプレース
  • CDNをAzureの外に出したのは課金が問題だったから（確かにクラウドの中に配置するとコンテンツ配信都度 従量課金される
  • AzureMySQLはHW障害により予告無しに中断する
    ミッションクリティカルには使えないが、７２時間前にメンテナンス通知を送るように対応中
  • DBの可用性を考えるならMessagingの活用も視野に入れると良いだろう
  • マイクロサービスにした理由は利用するメソッド（GET）以外はリクエストが少ないということがあった
  • URL単位でデプロイする仕組みにしたら対応範囲が局所化できる（ので、メソッド単位でPodを作っている
  • コンパクトなので起動が早い
  • Helm2を使っている
  • Kiali、ネットワーク監視で繋がりが分かる
  • Jeager、ElasticAPMで観察
  • Vitessは MySQLのCNCF
  • Natsは メッセージングKafkaより楽
  • OpenTelemetory(+Jeager
  • Chaos Toolkit（でも殺すAPIがなかなかいい感じに選定できないところもある）

14-E-1：AWS障害で考えさせられた、アプリケーションインフラ構成の注意ポイント

  • サーバーワークスはAWS専業
  • 登壇者は元万引きGメン、今AWSに関わって２年くらい
  • 20190823 東京リージョンが障害で発生したアレコレ
  • 複数アベイラビリティゾーン冗長化はしていた
  • サービスについては影響はほぼなかった
  • 設定ミス：DBインスタンスのエンドポイントがミス
    アプリを変えずにDNSの設定で宛先を変えて対処
  • 設定ミス：ディスクマウントがされなかった（これは構成ミスの話）
  • ここまでは早急に対応できた。逆に言うと次は重い
  • プレイスメントグループ
  • 気がついたこと
    バックアップがとれる仕組みを考えるべきだった（書き込みのないタイミングで取得しておくなど）
  • 今後どうすれば良いのか
    基本を大事に（ビジネス要件の確認）
    重要度が低いのに過度な構成はとらないように（逆は逆）
    Snapshotをとるべし
  • EC2へのスクリプトの置場所はEC2以外へ（同じレイヤーだと同じことが起きるかもしれない）
  • 接続先にIPアドレス指定はNG。エンドポイントを指定しましょう。
  • テストとしても切り替え試験の実施をすること
  • 言われてみれば当たり前のことかもしれないけど、実際のところ ちゃんとやるのは別もの。私はアプリケーション側なので「やってもらっている領域」なので こういうのは知っておくだけでも大事だと改めて思った。

14-D-2：エンプラアジャイル導入の守破離

  • チームの規模と何を作るのかはtradeoffになる
  • 教育をしているとものが作れないというジレンマであり難しさ
  • イテレーションでやっているけどスコープの決まっているものをやっているだけ
  • チームがうまくできるイメージができない範囲には適用しない（トップダウンで決めるとうまくいかなくなる）
  • 価値を産み出すまでのリードタイムを短くすることを優先する（成果物よりも）
  • 「おとなりさんと」で集中力が切れた。運よく会話をさせていただいた方からは良い視点を得られるところはあったけれど、それを目的とするのであれば それをメインとしたワークショップでやって欲しいというのが個人的な意見。ここまでの話は面白かったし興味深く聞いていただけに非常に残念な気持ちになった。
  • （以降、偏った意見になりそうなので割愛*2）

14-B-3：K8S使ってますか？リテールテック（小売・決済等）でのコンテナ活用例と「2025年の崖」克服に向けたコンテナ導入のススメ！

  • RANCHERの話
  • natadeCOCOの話
    その場でしか接続できないWifiに繋げてサービスを提供するアプリ（QRコードで情報を渡す）
    面白い仕組みだとは思ったけれど 勝手にWifiにつながることの安全性とか 気になったりもした。
  • 「2025年の崖」への言及は？

14-D-4：日本にJoy,Incを創る！どん底からスタートしたぼくらのジョイインクジャーニー7年間の軌跡

  • 「あなたのチームは機能していますか」
  • ２０１３年：３０人しかいないのにいがみ合っていた、プロジェクトは大炎上（夜中1時に顧客と打ち合わせ）
    原因：経営者（自分）目先の売り上げしか見えていなかった
    メンバーも何が正しいのか分からない状態
  • 毎月最終金曜日に社内懇親会（１７時から１９時）マンネリ化して終わる
    →目的を明確化しないと伝わらない
  • 月曜日、進捗会議。目的は情報共有のつもりだった。でも、月曜日からしんどい場になっただけだった。ので、社長として訴えかける場に変えた。でも、から滑り。でも続けた。徐々にメンバーの中で響く人も出てきた。そこでくじけず続けるのが大事だと学んだ
  • ヴァル研究所へ見学。巻き込み方が大事。ときには強引でも その場につれていく（僕が客に謝って時間を作るから、みたいな）
  • 「強いチームの作り方」ワークショップ
  • ペアワーク１週間でローテーション（これはJOY.incの話）
  • 語弊を恐れずに言うならば、エモい系の話だろうと思ったので一番期待していなかった*3。
    たしかに「良くあるエモい系」な感じはあったけれど、なんだろう そういうのも ひっくるめて 面白かった。他人が勝手に言うことではないけれど、会社を大きくするよりも 自分の手に余る範囲でのJOY Incの実践に留めて、拡張するのではなく 他の組織へのJOY.Inc に波及、連携するのが良いように思う*4。

14-D-5：マルチクラウドに向けてNGINX活用促進する為に知っておいてほしいこと

  • 直近でNode.jsでProxyをアレコレというのをやっていたので、NGINXに興味を持ったので聴講
  • 「分散システムデザインパターン」を丁度 読んでいるところだったので 色々とリンクができて面白かった
  • 具体的な記述例の話もあったので、スライド公開を強く期待（2020.2.15時点では

14-A-6：世界最高の靴売場をシューカウンセラーとともにデジタル変革してみた

  • JJUG 元会長の鈴木さんの最近の活動を具体的に聞ける場ということで聴講
  • アイムデジタルラボ　三越の子会社（といっていいんだよね？）
  • YourFIT365
  • 新宿伊勢丹の婦人靴
  • 立ち上げまでに２年かけた
  • POは現場メンバーにする「べき」
  • 今回だと「売り場」の人
  • 直接やり取りをさせてもらうことが条件
  • リリース日は決まっていた
  • １ヶ月 ワークショップでリーンキャンバスとカスタマージャーニーをつくった
  • はじめは７社が木型を提供してくれた（これは これまでの信用力）
  • 「何を作りたいか」を全員が共有するために費やした
  • サービスブループリント を使った
  • 業務フローとシステム構成を平行して考えて検証
  • 計測からリコメンドのタイムラグをどのように埋めるのかというところまで「業務設計」をした
  • メンバーはアジャイルを知らない人も。２ヶ月トレーニング、開発３ヶ月
  • リリース後はフィードバックとの戦い
  • 接客には１名に1～２時間かかる
  • 木型をベースにしたから再来客への訴求力が強く具体的である
  • 立ち上げ期のあとに意図的に安定期を作り込んで振り替えりをする余裕ももうけた
  • 当事者にならない人は不要＝企画部門問題（アイディアだけの人はいらない）
  • 出島型：適度な自治権 が大事
    距離感：既存に影響されてスピードが出ない
    孤島型：既存から切り離されて過ぎて成果が出ない
  • デジタルで新しいことはみんなやりたいけど、組織が枠組みとなって難しいことがある＝組織を別にもうけてそこで実践する
  • 統制から学習がIT部門に必要
  • 結局のところ、きちんとしたモノづくりには 全員が当事者になることが大事だという当たり前といえば当たり前の話だと実感。アジャイルとかWF（といわれている かつての開発）とか、そういうことじゃないと個人的には思った。
  • 泥臭く 土方仕事な感じのシステム開発かもしれないけれど、ユーザー総出で開発していた時代があって*5、そこで培った成功のプロセスがあったとして 結局 その「型」だけを採用すればイイ感じになると思って波及したんだけど、そこに本質はなくて 一番大事なのは「そんなアナログ」な部分だったというだけの気がしてならない。

14-B-7：エッジコンピューティングの時代にサーバーはどこにいくのか、自社製品をハッキングしてもらった話

  • 巨大メモリサーバーで何をする？ なにかやってみたいことがあったら教えて欲しい
  • データの７０％はデータセンターの外側にいる
  • ハードウェアアタックが増えるでしょう（by FBI 2017）
  • パンツダウン：センター監視サーバーを暴いて丸裸にすること
  • サプライチェーンへのリスクが増大
  • IPAの報告でも４位
  • 元は防衛設備で話題になっていたところ
  • 昔はメーカーの孫請がなくなることのリスクをいっていたけれど、今は部品に仕組まれたステルス攻撃のこと
  • サイバーディフェンス（手島裕太）に依頼
    ソフトはダメでもハードから攻撃はできるかもということで受けてくれた
  • ファームウェアを攻撃対象としてもらった
  • 改竄されることは想定内
  • アンチウィルスソフトはOS上のソフトを見るだけなのでファームウェアは対象外
  • エアバスのエンジニアにホワイトハッカーがいる（GitHUBにも公開）
  • 一番始めに攻撃されたのはHDDのファームウェアで、隠した領域に情報をためておいて廃棄時に回収するという仕組み
  • ハードウェアにもゼロトラストの構想が必要になってきた（チェーンオブトラスト、RootOfTrust）
  • 電源のファームすら危険性があるという世界（電源を止められたらセンター停止）
  • HPEマイクロサーバーからマイクロサーバー新作が出る（本当は登壇日にリリースされる予定だったけど、ずれてしまった
  • ハードの話は「すげー」とバカみたいな感想しか言えないけど、やっぱり「すげー」と思うし 実際「すげー」と思う。

14-F-8：家族型ロボット「LOVOT」から考えるテクノロジーの裏側とその未来

  • 100億投資、100人の会社
  • 人間の力を引き出すことが目標
  • 愛されるよりも、愛した方が力が出るという想定（信念）
  • 監視カメラか 信頼関係のあるロボットの視線か
  • 存在感のある か 存在感が価値 になるか どちらかに振り切らないと難しい。中間はない（冷蔵庫に愛情を感じるとかいうのは難しい）
  • LOVOTはROBOTに対するカテゴリーという思想も含めた名前
  • 目指すところは ドラえもん
  • 先輩は犬、猫、イルカのような存在
  • 話せることと癒しは直結しない
  • むしろ話せないことが、想像力で補完している自分の言葉に癒されているとも言える
  • ではペットを飼えば良い？
    でも実際には飼いたくても飼えないというのが実態
  • でもロボットペット開発はすぐには廃れてしまったのがこれまで。
    それは「飽き」が原因では？
    ドーパミン（好奇心）が失くなった？Noでは？オキシトシン（愛着）が必要なのでは？
  • いるのが自然な状態ということ
  • 次に「ロボットネイティブ」な時代になると考えている
  • 人と人のコミュニケーションの延長としての存在
  • 広い意味での生物の境界はなく、生物と無生物の差がなくなると想像する
  • 「Detroit: Become Human」は 林さんのいう 中間 になる話なのかなと思ったりも。そして その中間 を求めて出来るのは 都合の良い奴隷であって 愛情を共有することに葛藤のある世界（出来る人もいれば、嫌悪を感じたり、隷属を求める ことになるとか）になるのかも、と思ったりも。そのためのセーフティーとして きちんと振り切ることは大切なことなのかもしれないと思った。

さいごに

去年も参加したけど、今年の方が 私には面白かった。
なんでだろう？

*1:調べてみたら、そのようでした。LINE Engineer Insights vol.4「OpenStackベースのPrivate cloud "Verda" の野望」 - LINE ENGINEERING

*2:今 思い出しても イライラしてしまう。。自分の狭量さも含めて

*3:多分、他が満員だったから みたいな理由で選んだ気がする

*4:自分の言葉でツラツラと説明はできるけど、ブログの範疇ではないと思うので割愛

*5:例えばJRのマルスの話（by プロジェクトX）とかね

Jakarta EEのメモ

Jakarta EE

www.slideshare.net

www.slideshare.net

エンタープライズJavaの未来に注目集まる！JJUGナイトセミナー「Jakarta EE特集」に参加しました - Seeing is believing

補足

Jave EEのメモ vermeer.hatenablog.jp

JJUG x JJBUG共催ナイトセミナー「cloud native business automation for Java」に参加してきました

勉強会

jjug.doorkeeper.jp

スライド

speakerdeck.com

感想

どういう 話が聞けたというのは 英語だったこともあって＆雰囲気で理解した感じなので 聞きながら思ったことなどをツラツラと。

  • Drools はルールエンジンで Ruleって「何をするか」ということ
  • 大事なのは利用者と開発者のコミュニケーションロスを失くすこと
  • Business and infrastructural code have very difficult life cycles
  • jBPM こっちは「プロセス」を描く
  • RuleとBPMを まとめて提供するのが Kogito
  • Kogitoの読み方は「こじと」（こぎと ではない）
  • （感想）ファンクショナルなアプリでいけるんだったら、ルールを書き換えて動的に反映するというのの価値ってどこくらい見いだせるのだろう？
  • （感想）逆にみいだせるとしたらOpenJDKでしっかり動くアプリこそ強いのでは？
  • とはいえ Kogito自体は Quarkus と SpringBoot を対象としたマイクロサービス向けなもので EEは対象外
  • （感想）ルールエンジンを適用するとユースケース駆動になるから ビジネスルールのロジック部分は部品に出来るけどできるけど、データ部分は外に出ているからクラスではないんだよね。
  • （感想）「判断」の見える化に止めるか ステートパターンの生成器としての役割まで担えるか？

懇親会で得られたプラスアルファ

  • BPMの拡張がVS Codeにあるから、BPMを業務フローの整理として使うだけでも使えそう
  • 少ない条件分岐だったらプログラムで実装した方が速いこともあるけど、大量の条件分岐を扱うのであれば 最適化が図られたDroolsに軍配ある*1
  • ビジネスルールの見える化は表面的なルールエンジンの能力で、大量のパターンマッチングがルールエンジンの強み
  • DroolsはGUIのフローでロジックを書くことも出来るし、Excelでも書ける。結局 それをDRL(Drools Rule Language)に変換してルールエンジンが実行する
  • DRLから作られたエクセルへの可逆性は無いので、フローで作ったものをDRLに変換してからExcelのベースに使うというのは出来ない
  • ルールエンジンの需要はあるとのこと（自分の周りでは聞かないけど、決して「懐かしい」ものではなくて十分現役）
  • 機械学習（パターンマッチング）まで含めると、むしろ需要は 増える？
  • 機械学習（画像解析）と違うので必要なのはCPU

さいごに

ルールエンジンには Excelで書いた設計からXMLを変換するツール作成に関わったこともあって その面白さというか 業務の見える化みたいなところは興味深いと改めて思った。所謂 自動生成的なところがあるので かつてあれこれ考えたように*2、その付き合い方みたいなところの落としどころに検討の余地ありとは思っているけれど。とはいえ、今 自分手元にある開発資産は マスタメンテレベルのCRUD的なものなので DDDとかの文脈に出てくる「ドメイン知識」的な要素はないんですよね。何かしらの業務アプリ的なもののOSSを自分の思ったようにリプレイスしたりしながら アレコレやっていくと 何か良さげな整理が出来るかもしれないとは思いつつ、他に作りたいものとかあったりで 結局 後回しにしてしまうんだろうな。。

*1:私がかつて関わったルールエンジンはXMLで定義されていてパスで見るから そういった最適化はされていなかったんじゃなかろうか？

*2:http://vermeer.hatenablog.jp/entry/2018/07/07/102839

pmconf 2019

勉強会

pmconf 2019 へ行ってきました。

2019.pmconf.jp

はじめに

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

ブログなど

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

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

pmconf2019 - Sakapun's project

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

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

https://yamotty.tokyo/post/20191112_pmconf/

Pmconf 2019 11/12 まとめ｜おかちゃん｜note

Pmconf 2019 11/13 まとめ｜おかちゃん｜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 の２つが大切
  • 革新はエンジニアから生まれる
  • エンジニアは今何をするべきか一番知っている人たち。なのできちんとコラボをしよう

感想

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

Keynote:Special Session(Kaarel Kuddu)

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

感想

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

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

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

感想

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

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

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

感想

現場の方からも推薦された岡田さんの講演。
とても面白かったし、スルスルと引き込む不思議な語り口でした。
BackLogの消化をするだけのモチベーションの低い状態は、特にベンチャーだと危険なことという嗅覚は正しいと思います。良くも悪くも ゼロから１の世界には勢いがあるけれど、それを継続する仕組みにもっていくためには どこかでシフトチェンジすることは大事だと思うからです。
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
  • BenesseとSoftBankのジョイントベンチャー
  • 約半分の高校に導入されている
  • EDUCOM（こちらは小中）と協業して両面をカバーする事を目指している
  • 文科省：生きる力の育成
  • これまで入試で問われていたのは、知識と技能
    2020年からは思考力、判断力や学びに向かう力や人間性 を伸ばす
  • 先生側に管理と評価への課題
  • 生徒側も どう学ぶのかという課題
    （結局、合格するための手段にばかり目が向くよね、という話）
  • ビジネスとしてはユーザーである生徒と先生だけでなく、支払い者である保護者にも理解を獲る必要がある 難易度の高さ
  • 年一回の大規模開発サイクル
    ABテストも容易にできない。（仮説検証のサイクルが回しにくい

感想

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

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

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

感想

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

感想

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

愛と解釈のコンダクター

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

感想

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

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

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

感想

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

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

  • SNSやブログはNG

感想

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

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

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

感想

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

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

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

感想

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

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

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

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

感想

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

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

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

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

感想

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

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

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

感想

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

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

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

感想

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

さいごに

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

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

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

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

おまけ

ウォーリーを探せ*9

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

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

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

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

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

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

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

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

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