LEAN UXを読んだメモ
ブログを引っ越ししましたので，5秒後に移動します
ジェフ・ゴーセルフ著「LEAN UX」を読んだメモです．
Lean UX 第2版 ―アジャイルなチームによるプロダクト開発 (THE LEAN SERIES)
- 作者: ジェフ・ゴーセルフ,ジョシュ・セイデン,坂田一倫,エリック・リース,児島修
- 出版社/メーカー: オライリージャパン
- 発売日: 2017/07/04
- メディア: 単行本（ソフトカバー）
- この商品を含むブログを見る
ざっくり言うと， エリック・リースによる"前書き"にあるように，「局所的にLeanを実践しているが，組織全体として最適化されていない」問題はよくある話で，それを解決する方法論としてUXに視点を置いて組織改革を行う，という手法です．
読む前に知りたいと思った質問
- リーンスタートアップや他のLEANシリーズとLEAN UXとの違いや関係
- アジャイル開発とLEAN UXをどう結合させるか
- 組織にリーンのマインドを定着させるためにはどのような戦術があるか
全体所感
- LEAN UX＝デザイン思考＋アジャイル開発＋リーンスタートアップ
- リーンスタートアップとUXベースのデザインを組み合わせ，共生的に共存させるもの
- デザイナ以外の人もデザインプロセスに関与する
- 重要なマインドセット
- 透明性の維持
- コラボレーティブ（全員参加）
- イテレーティブ
- BMLループを回すことや，小さく失敗し早く成功する価値観はリーンスタートアップと同様に感じた
- ユーザ価値やビジネスゴールと実現方法（機能）を紐つけて，ビジョンから顧客へ提供するものまでを一貫するという点でIMPACT MAPPINGとの共通点を強く感じた
- デザイナ以外の人もデザインプロセスに関与するための方法論が途中まで読んでもイメージが沸かなかったが，デザインスタジオの説明を読んで少し理解できた
- アジャイル開発との共存については具体例があるものの，あまりうまくイメージできなかったので実務の中で試行してみる必要性があると感じた
- デザイナが活動をリードするのが望ましいが，現実的にチームの中でデザイナがその立場で動けるかどうかは組織の文化が強く障壁になりそうだし，難しい組織が多いように感じた．アジャイル開発と同様，いきなりプロセスを適用するのが難しい場合は，LEAN UXのプラクティスを組織課題の解決として小さく適用するところから始めるのが良さそうに感じた．
1章 かつてないほどに高まるLean UXの重要性
- Amazonは平均して11.6秒に一度の割合で本番環境に新たなコードを追加している
- 継続的にデリバリし学習するのがよい
- 機能やドキュメントではなく顧客価値や"効果"（outcome, not output）に焦点を合わせる
- チーム全員がコラボレートし続ける継続的エンゲージメントでは情報伝達のための膨大な資料は不要（アジャイル開発の価値観と同じ）
2章 Lean UXの原則
- LEAN UX
- ＝デザイン思考＋アジャイル開発＋リーンスタートアップ
- デザイン思考：人間を直接的に観察することを原動力とするイノベーション手法
- コラボレーティブかつ部門横断的
- チームの共通理解
- デリバリよりも学習
- ＝デザイン思考＋アジャイル開発＋リーンスタートアップ
- 原則の要約
- チームが一体となり，情報が透明性をもって共有され，共通理解されている状況を作る
- 機能ではなくユーザ中心とした課題解決・顧客価値・アウトカムに焦点を当てる
- 早く多く失敗し，未検証で顧客価値の無い中間成果物といった無駄を最小限にする
- 繰り返し形にし，学習を続ける
3章 ビジョン、フレーミング、アウトカム（成果）
- 検証すべき仮説を効果的に正しく設計する方法の話
- 成果に焦点を当てるために，検証ステートメントとして宣言する
- 仮説の分類して考える（ビジネスの成果，ユーザ，ユーザの成果，機能）
- ペルソナ作成はイテレーティブに行う（一回作って終わりではない）
- ペルソナの効果
- 共通理解（「犬」と聞いて誰もが同じ概念を想像しないのと同じ）
- 自分たちがユーザであるという錯覚の排除
- ビジネスゴールを達成するために起こさせるユーザの行動と，そのために提供する機能，という考え方がIMPACT MAPPINGと共通項が多いように感じた
4章 コラボレーティブ・デザイン
- 仮説定義における実際のプラクティスの話
- コラボレーティブ
- ≠ヒーローベース
- 共通理解と当事者意識を促進
- ドキュメントの量は減る
- デザインスタジオ
- デザインシステム
5章 MVPとプロトタイプ
- 実際のMVP構築における留意点の話
- 行動を測定できるMVPを作る
- 学習目標と，そのために必要な計測を意識する（BMLのLから思考する）
- MVP構築と学習効果のROIを考慮する
- 嘘の機能（つながらないボタン）の手法は，必要な際に思い出せるようにしておきたい（ユーザの印象が悪くなることもあるので，用法用量は守る必要あり）
6章 フィードバックとリサーチ
- MVPを評価する話
- コラボレーティブにイテレーティブにリサーチする
- 「一口サイズ」のリサーチを繰り返す
- リサーチを専門家に丸投げしない
- 矛盾するフィードバックの対処
- 異常値は一旦置いておき，次回以降のイテレーションでパターンに沿うかどうか見てゆく
- 他のソースを使って検証する
7章 Lean UXとアジャイル開発の共存
- 全員が参加し，デザインプロセスをチームメンバ全員で共有する
- プロセス
- デザイナはアジャイル開発プロセスのすべての活動に参加すべきである
- なんとなくわかるが，実際の活動がどうなるのかイメージがつきにくいので，実務で試す必要がありそう
8章 Lean UXの実践に際して組織に求められる変革
- 結果より成果を重視する
- 役割を超える
- 部門横断的
- ワークスペースの設置（同じ場所，中間成果物の掲示）
- BDUP(Big Design Up Front)，アジャイルフォールを避ける
- speed first, aesthetics second
- 継続的改善，UXの負債の追跡
9章 ケーススタディ
- LEAN UXやその適用系による成功事例の話
- コラボレーティブなデザインプロセスへの変革
- ペルソナとユーザインタビューと共感マップによる認識の補正イテーレーション
- サービスデザインの適用
「エンジニアの知的生産術」を読んだメモ
ブログを引っ越ししましたので，5秒後に移動します
西尾 泰和著「エンジニアの知的生産術」を読んだメモです．
エンジニアの知的生産術 ──効率的に学び、整理し、アウトプットする (WEB+DB PRESS plusシリーズ)
- 作者: 西尾泰和
- 出版社/メーカー: 技術評論社
- 発売日: 2018/08/10
- メディア: 単行本（ソフトカバー）
- この商品を含むブログ (2件) を見る
全体
- 経験のあるKJ法や，好きな外山滋比古氏の理論がよく引き合いに出されていて，全体的に理解しやすかった
- 第6章「アイデアを思い付くには」が自分にとっては一番理解が難しかったが，フレームワーク依存問題など陥りやすい罠や持つべきマインドが解説されていたのが良かった
- 著者の理論モデルが多くの過去のモデルから成り立ってきたのが読んでいてよくわかり，出典が逐次提示されているので，理論のトレースがしやすい本だと感じた
- 折に触れて読みたい本だった
第1章 新しいことを学ぶには
- 学びのサイクルは情報収集，モデル化，検証
- インプットしたもののまとめや他者への説明などのアウトプットは検証の有効手段
- 自身のインプットのやり方に欠陥があることを思い知った
- 他人が確立したモデルをそのまま自身に取り入れようとして，理解した気になってうまく活用できていなかった（p43 パターン本から学ぶ）
- 読むのが遅く，遅すぎて全体像が掴めない悩みがあったが，全部を読もうとするのではなくつまみ食いをすることが大事
- そのために目標を明確し，全体像を把握する
- 時間は貴重なのだから，遅延評価的勉強法を考慮したインプットを心がけたい
- やる気を維持するために「ゴールを明確にする・近くする」は普段よく考えていて共感できた
- やる気に関する問題は，最近読み直した「モチベーション2.0」の自律性・卓越・目標の3点に共通していると感じた
第2章 やる気を出すには
- 7つの習慣の「重要事項を優先する」における緊急・重要マトリクスおける「重要かつ緊急」を減らし，「緊急ではないが重要」を増やす（緊急性分解理論）
- GTDでは，価値観はボトムアップで言語化する
- 優先順位付けは比較軸や不確定性から比較が難しく，日々の具体的なタスクを観察（計測）しながら事後的にできるようになる
- ポモドーロテクニックはタイムボックスで終わりを設定することでやる気を持続させるが，スクラム等の手法も同様に感じた
- 通知や割り込みを緊急性の高さと勘違いしてしまうのは陥りやすい罠なので，マインドセットや仕組み化が大事に感じた
- 7つの習慣の「終わりを描く事から始める」はとても共感しており，仕事において必ず意識するようにしているので，本書でも取り扱っていて良かった（終了条件や目的を置かずに仕事をする人のなんと多いことか！）
第3章 記憶を鍛えるには
- 反復的にアウトプットするのが長期記憶化のコツ
- 認知的に高度な作業をした方が記憶にとどまる
- 不適切な難易度によるモチベーションの低下は経験が多々あり，Ankiの自動保留の仕組みはよいアプローチに感じた
第4章 効率的に読むには
- 開いている本・閉じている本（筆者の結論の有無），登山型の本・ハイキング型の本（概念の積み上げの有無）という捉え方は初めてだったので新鮮だった
- 準備の大事さ，段階的詳細化，繰り返し読むこと，のコンセプトは今後の読書で意識していきたい
- Whole Mind System試してみる
- フォーカス・リーディングとあなたもいままでの10倍速く本が読めるは読んでみようと思う
- 遅読家で，理解が悪いことと認識しながら読書法の改善を図っていなかった
- おそらく1度通して読んでおわりと考えているから，読み漏らすのが怖くて時間をかけ過ぎて読んでしまっているのだと思う
- そこで次回の読書からやりたいこと
- アウトプットを前提として読むこと
- 1ページ目から通して読まないこと
- 具体的な方法（仮）
- 目次と導入から読むところを絞りつまみ食いする
- 章ごとに感じたことや意見や疑問をまとめる
- 目次に戻り全体マップでの位置を把握する
- 以下ループ
第5章 考えをまとめるには
- KJ法のA型図解化/B型文書化のステップは知らなかったので実践してみたい
- 新しい構造を生むために，分類を先に決めてトップダウンする（KJ法をやる意味がなくなる）のではなく，ボトムアップで分類する
- 手法のチューニングは確かに大事だが，いきなりチューニングするのではなく，まずは守破離の守のステップとして原則に倣うのが良さそうに感じた
第6章 アイデアを思い付くには
- U理論の谷を下りるために，他人の視点を大事にすることや，SECIモデルを意識することや，フレームワークにしがみつかないことが肝要（自分の枠を壊す必要がある．KJ法において分類を先に付けないことと似ている）
- 他人の視点を理解するために，クリーンな質問（Clean Language）や絵に描くことやNM法などで，抽象概念やメタファから身体的感覚の（具体的な）イメージに解凍する
- なかなか理解が難しい章だった
- アイデアが生まれるのは管理できるものではないという考えは外山滋比古氏から学んでいて違和感がなかったが，アイデアを検証するという考えは自分にとって斬新だった（普段業務で触れているリーンスタートアップの考えなのに，個人のアイデア発想にそれを適用する考えを持っていなかった）
第7章 何を学ぶかを決めるには
- 数学と科学では，正しいということの捉え方が異なり，個人の意思決定はそれらとも異なる
- Steve JobsのConnecting Dotsは事後的にしかわからないので，戦略をベースに学ぶしかない
- かけ合わせ（ふたこぶの知識）や連続スペシャリストによる差別化戦略はよく意識していて，意図的に学ぶものを選択することがあったのでとても共感できた
- いままで社内でひとつの部署に留まらず色々な部署を転々としてきていて，そのことにデメリットを感じていたが，戦略として有効に考えるきっかけになった（人や組織，コミュニティを横断する知識・役割を基盤に成長する）
「これからのマーケティングに役立つサービス・デザイン入門」を読んだメモ
ブログを引っ越ししましたので，5秒後に移動します
「これからのマーケティングに役立つサービス・デザイン入門」を読んだメモです．
これからのマーケティングに役立つ、サービス・デザイン入門 -商品開発・サービスに革新を巻き起こす、顧客目線のビジネス戦略
- 作者: J.Margus Klaar,長谷川敦士,郷司陽子
- 出版社/メーカー: ビー・エヌ・エヌ新社
- 発売日: 2015/10/22
- メディア: 単行本（ソフトカバー）
- この商品を含むブログを見る
読む前に設定した「知りたいこと」
- サービスデザインとはなにか，を言語化できるようになる
- カスタマージャーニーの概念と具体的手法を知る
全体
- サービスデザインにおける思考や精神が身につく本で，手法やフレームワークの具体的手法の解説は少ない
- 「解説：日本のサービスデザインの現場」の章で述べられていたが，カスタマージャーニー（に限らず，あらゆるフレームワークや方法論）を使えば問題が解決すると誤解されている例が多いが，なぜそれをするのか（Why）の理論と精神を身に着けないと効果はないと感じた
- その意味でも，具体的手法を実践する前に読むと良い本だった
序章
なぜ（why）？
- ほとんどのことが決めつけや仮説のままシステム化されてしまっている（お役所仕事）
- 「なぜ」（それが必要なのか，その方法なのか，使いづらいのか）を考えることが必要
サービス・デザインとは何か
- ビジネスを顧客目線で体系的に編成する取り組み
- UX（顧客付加価値）を提供することを目的とする
- 購入時点のみならず製品・サービスのライフサイクル全体をデザインする
- 情報を常に正しく提示しないと満足度は下がる
- Whatが衛生要因になったいま，Howが価値を生む
- ここではHowを思考せよとあったが，もっというとStart With Whyが重要なのだろうと感じた
なぜこのプロセスをデザインと呼ぶのか？
- デザインとは価値観やアイデアに形を与えること（無形→有形）
- 理解しやすく，使いやすく，識別しやすく，美しくあることが良いデザイン
- 問題定義のためにカスタマージャーニーマップ，仮説検証，タッチポイントを考える
カスタマー・ジャーニー
要求は決して「もの」ではない
- 顧客の目線で世界を見る
- リアルで意味のある世界にするために対象グループ，ペルソナを規定する
- 購入のタイミングだけでなく，前後・背景を含めライフサイクル全体を考える
- ペルソナから見る世界をモデル化するためにカスタマージャーニーマップ，共感マップを利用する
- 顧客の大半は苦情を訴える行動を取らない（立ち去る方がコストが安い）ので，苦情の発生はその背後に潜在的な苦情が10倍程度あると認識する
- 疑問：ペルソナは考えようと思えば無数に考えられる．必要なペルソナを設定・選定する指針は？
- 同僚のデザイナの人に教えてもらった
- 例えば
- 対象のサービスの特性から考えられるユーザグループを，相反するユーザ特性を考慮して軸で分ける
- 例えば，2軸でユーザグループを分け，各象限ごとに代表的なペルソナを作る
- 単に設定したペルソナだけではなく，上記ユーザグループの全体像があると，ペルソナの妥当性（そのペルソナが対象ユーザに当てはまること，例外的でないこと）を他者へ説明する際も，論拠がしっかりする
仮説の検証
- 量的データ・ビッグデータには過去の購入した情報だけしかなく，背景・カスタマージャーニー・Whyが含まれていないので，トレンドを把握するには役立つが，思考や感情を洞察するには役立たない
- インタビュー，グループディスカッション，ワークショップを正しく行い洞察を得るためには，注意深い設計とファシリテーションが必要（対話法，観察法の習得が必要）
顧客接点（タッチポイント）
- 事業体が提供する価値と顧客が受け取る価値が食い違っていないかに注意する（機能や性能がすでに衛生要因になっていないか，など）
- テクノロジの進化と現実世界の課題・変化により，顧客は不満を表明し公にする強い力を得た
- カスタマージャーニーの中で，顧客が受け取る価値が最も高い顧客接点を考察し，その場面のUXを高める
この種の課題への組織的な取り組み
- 責任者の不在，組織のサイロ化は耳の痛い話で，サービスや製品の改革以前に組織改革が重要という主張は素直に同意できた
「IMPACT MAPPING」を読んだメモ
ブログを引っ越ししましたので，5秒後に移動します
ゴイコ・アジッチ著「IMPACT MAPPING」を読んだメモです．
ここでは，デリバリ＝成果物，デリバリチーム＝開発チームと読み替えています．
IMPACT MAPPING インパクトのあるソフトウェアを作る
- 作者: Gojko Adzic,ゴイコ・アジッチ,平鍋健児,上馬里美
- 出版社/メーカー: 翔泳社
- 発売日: 2013/12/19
- メディア: 単行本（ソフトカバー）
- この商品を含むブログ (6件) を見る
インパクトマップとはなにか
- ゴールを中心に，スコープと仮説を視覚化したツリーマップ
- Why(ゴール)を中心に，Who(アクタ)/How(インパクト)/What(成果物・機能)を枝葉が広がるようにデザインする
- 誰(Who)が何をもって(What)，どんなインパクト（プラスもマイナスも）(How)をゴール(Why)に与えるかを表現する
- GitHubで公開されているワークショップ用のチャートシートが良いリファレンス
インパクトマップの役割と効果
ゴールと仮設の明確化
- ビジネスゴールと機能・スコープ・ロードマップを紐付ける
- アジャイル開発が「予算がなくなるまで間違いを直し続ける」ことにならぬよう，仮説（成果物とインパクトの検証，インパクトとゴールの検証）の認識を共有できる
- 開発チームには良いロードマップを，ビジネススポンサには全体像を与える
- 検証する仮説の選択と優先度設定が的確にできる
- 不完全なアジャイルが及ぼす悪影響を改善する
- ビジネスと開発が分断された"ウォーター・スクラム・フォール"
- これはBIG PICTUREの不在が原因
多くのチームはすばやい変更を優先するあまりBIG PICTUREを犠牲にして、プロジェクトを導いている。これはまるで暗いトンネルの中で、どこに向かっているかはわからないまま、落ちないように一歩一歩小さく進んでいるようだ。
無駄を排除し価値を速く生む
- ストーリカード地獄（プロジェクトの開始時点で，成果物に必要な膨大な数のユーザストーリを作成してしまうこと）防ぎ，現状に適切な量・表現のユーザストーリを導出できる
- インパクトマップのWho/How/Whatがそのままユーザストーリになるので，ユーザストーリの必要性がインパクトマップから判断できる
- リーンのWIPを最小化する原則を実現する
導入しやすい
- 記法が単純で，ステークホルダ全員が理解しやすく書きやすい
副次的効果（インパクトマップを書くだけではなくて，マインドセットも必要だと思う）
- 効果的な会議
- ビジュアル化による理解力・思考力・創造力の向上
- インセプションデッキのような，立ち位置や目指す先の共有による議論の軸の確立
- コストから投資への議論
- 成果物のコストではなく，それがもたらす成果や利益への焦点の移動
インパクトマップのつくりかたのコツ
- 「顧客に満足感を与える」ことだけを測るメトリクスは無価値なので，「行動につながる」メトリクスに焦点を当てること
- 打ち合わせは2部制がよい
- ビジネスゴールとメトリクスを設定する会
- インパクトマップを作成する会
- ビジネスマネージャは機能ではなくビジネスゴールを語るべし
- 機能要求から始まった場合は，なぜなぜを繰り返しゴールを問う
- ビジネスゴールは計測可能にする
- SMARTを満たすこと
- Measure
- scale: 測定するものはなにか
- meter: どう計測するか
- benchmark: 現状はどうか
- constraint: 許容値，損益分岐点
- target: 求められる価値
- メトリクスは追跡しやすさではなく価値あるものを選ぶ
- メトリクスを測定し，継続やピボットの判断を行うタイミングを定期的に作る
- 複数の測定値を持つものはマイルストーンを分けて考えてみる
所感
- かなりコンパクトにまとまっていて（100ページ未満）で短時間で読めるため，本の全体感を認識しながら読み切れた
- それぞれの項目ごとにポイントが記述されているので，実際にインパクトマッピングをする際にリファレンスとして活用しやすい
- 考え方はゴール志向要求分析や匠Methodに通じる部分が多いなと感じた
- ビジネスと開発の分断を防ぐ方法論
- What/Howだけだと失敗する
- Start from Why
- サイモン・シネックのゴールデンサークルに則っている考え方
- システム開発だけアジャイルでも，ゴールやステークホルダと結びつかないので，ビジネスを含めアジャイルであるようにするための方法論
- アジャイルであっても，知識体系のどの領域をカバーする議論なのかを意識することが有用に感じたのでPMBOKとかちゃんと勉強しようと思った
- 「成果物の目的は，アクターの行動変化だということへの合意」という部分が，先日のYahoo! JAPAN Tech Conference 2019でCTO藤門さんが言っていた「ユーザの行動を変える」に通じるものを感じた
- 本の最後の方にある「典型的な会議づくりに関する誤り」「典型的なファシリテーションの誤り」はインパクトマップ関係なく，仕事をする上でとても重要で参考になった
DevLOVE 価値観ババ抜き大体験会 に参加しました
ブログを引っ越ししましたので，5秒後に移動します
ちょっと前ですが，1/21(月)にDevLOVE主催の価値観ババ抜き大体験会に参加してきました． イベントのページはこちら．
価値観ババ抜きとは
こちらの公式ページの説明が詳しいです． 価値を表す単語が書かれたカードをババ抜き風に回したり捨てたり（＋新たに取ったり）し，自分や他人の価値観を認識できるワークです． カードには「楽しさ」「コントロール」「成長」「チームワーク」などが書かれています． 一通りカードのやり取りが終わったあとで，手元に残ったカードを体系化したり，そこから考えられる価値観についての記述を行います．
進め方
当日のイベントは次のような感じで進められました．
- 新井さん（@araratakeshi）からDevLOVEの説明
- 山田さんから価値観についての話
- 強み＝得意なこと＝他人に聞けばわかる
- 興味・関心＝好きなこと＝自分に問いかければわかる
- 価値観＝大切なこと＝こういったワークで認識する
- マザーテレサの戒めでいう「思考」は価値観が左右する
- 加藤さん（@acnaman_dev）ファシリテーションで価値観ババ抜きの実施
- 蜂須賀さん（@PassionateHachi）によるふりかえり
- 新井さんによるクロージング
価値観ババ抜きワークの様子
- カードを切るのにすごい迷ってしまって，我々のテーブルが一番最後まで時間がかかった
- カードを切る時に「私は○○を手放します」と宣言するのだけど，「宇宙」というカードがパワーワード過ぎて，「私は宇宙を手放します」になっちゃうから爆笑だった
- でも途中から「宇宙」という言葉に感じた感覚が，意外に自分の中でフィットしてきて，結局最後まで残った
- ババ抜きが終わったあとの体系化と言語化の時間がちょっと少なかったので，もう少し時間を取ってしっかりまとめたかった
- 最後に一緒にやったテーブルのメンバに，どのような人と感じたか，仕事でどのように一緒になりたいか，などをちょっとした手紙としてまとめるのだけど，これが実に恥ずかしい(^^;
↑2枚目の右下が自分の最後まで残ったカード
感じたこと
- 価値観ババ抜き前に行った山田さんのアイスブレークが効果的で，ワークを一緒にやった人たちは全員はじめましてだったけど，スムーズにワークが実施できたのが良かった
- お題に対して超高速で回答を回していったり
- 全員立ち上がって部屋中に散らばって感覚の共有をしたり
- きっとこのワークは，一緒にやる人によって結果が全く変わるなと感じた
- 初めましての人とだと自己の内面との対峙という面が強いけど，すでに利害関係がある人たちとやると，嫌でも外から見た自分を意識すると思うので
- チームビルディングなどを行う際に，キックオフミーティングや飲み会だけではなく，こういった互いの価値観を認識できるワークをするのがとても有用そうに感じた
- まとめると，価値観ババ抜きワークとても良かった！
先月読んだ本と今月の読書予定（2019年2月）
ブログを引っ越ししましたので，5秒後に移動します
先月の読書実績
漫画，雑誌は除いています．
| 実績 | Fav | 本 |
|---|---|---|
| ⏸ | 数学ガール | |
| ⏸ | 新装版 リファクタリング―既存のコードを安全に改善する | |
| ▶ | エンジニアの知的生産術 | |
| ✅ | ⭐ | Newton別冊『飛行機のテクノロジー』 |
| ✅ | IMPACT MAPPING インパクトのあるソフトウェアを作る |
- 数学ガールがずっと止まってるから読み切りたい
今月の読書予定
| 新規・継続 | 本 |
|---|---|
| ▶ | 数学ガール |
| ▶ | エンジニアの知的生産術 |
| 🆕 | 思考・論理・分析―「正しく考え、正しく分かること」の理論と実践 |
Yahoo! JAPAN Tech Conference 2019に参加しました
ブログを引っ越ししましたので，5秒後に移動します
1/26(土)に開催されたYahoo! JAPAN Tech Conference 2019に参加してきたので，聞いたセッションについて簡単にメモします．
イベント概要
全体
- 今回始めてYahoo! JAPAN Tech Conferenceに参加したが，普段聞けないYahooの取り組みや中の人の話が聞けてとても良いイベントだった
- やはり大企業だけあって，社内の体制やプロセスが合理的でしっかりしていて，スタートアップ系企業の発表では味わえない"強さ"のようなものを感じた
- 会場の場所がちょっとわかりにくかったけど，六本木駅から来くるとスタバの横の階段を降りて地下1Fに行き，しばらく真っ直ぐ歩くとミッドタウンホールの入り口があった
- 予定があったので17時以降のセッションは聞けなかった😢
セッション
13:00-13:45 Keynote
藤門 千明さん（執行役員、CTO）
- Yahooのねらいはインターネットでユーザがよりアクションすること
- スライドの表現から，Search/Know/Buy/Payに特に主眼をおいているように感じた
- キーノートの最後に流された動画でも，購入や支払いのイメージが強かった
- Data/AIに関する取り組みはそれこそ10年前からやっているが，コンピューティングリソースが足りない点が弱点だったので，kukaiというスーパコンピュータを構築した
- kukaiは水冷で，環境への配慮やエネルギー効率を考慮している
- エネルギー効率（GFlops/watts）を上昇させるためのパフォーマンスチューニング自体をMLで行っている
- kukaiの適用例
- Yahooともなるとそのデータ量は膨大になる中，自社でAIへのアプローチを工夫しているのが印象的だった
仲原 英之さん（執行役員、CISO）
- セキュリティへの取り組みの話
- 2018の全サービスTLS1.2移行
- 事前調査で非TLS1.2の通信は3%だった（母数多いから数は多い）が，売上より安全を優先して全サービスTLS1.2に踏み切った
- 事前の告知や移行サポートにより9月には1.3%までに減った
- 今年はOpenSSL1.0.2がEOLになるので，OpenSSL1.1移行が大きな動きになる
- OSSの安全な活用とCI/CDの重要性が学びだった
- ビルドパイルプラインに脆弱性検出を入れてる
- DevOpsからDevSecOpsへ
- YahooのTLS1.2完全移行は話題になったけど，他の企業からすると，「Yahooがやってるんだからうちもいいよね」と言いやすく，すごい助かった印象（実際IEを切る口実に使ったりした）
- ユーザ数が多い中，決断は難しかっただろうけど，英断だったと思う
14:00-14:45 B-1
パスワードレス普及への取り組み by 三原 一樹さん
- Yahoo IDの数は2018年9月時点で4,587万
- これまではパスワードの安全性を高めるためにログイン履歴・ログインアラート・MFA・スマートログイン（ソフバンユーザ向け）などを対応してきた
- 独自アンケートによるとパスワード忘れ（96%），使い回し（73%）などパスワードがあること自体による問題が浮き彫りになった
- そこでSMSを使った解決策を提供してきたが，これも十分とは言えなかった
- そこでFIDOを使って，生体認証によるセキュリティとユーザビリティの両立を図っている
- サーバは認証情報を保持しない
- FIDO2でブラウザでも使えるようになる
- FIDO認証採用はYahoo! JAPANが世界初
- 現在はAndroidのみ
- SMSはWhat you haveに近い認証だと思うので，パスワードよりユーザビリティは上がるが安全性は下がりそうな印象があったので，FIDOを使うのは良いなと感じた
- TLS1.2の例と同様に，「Yahooがやってるから」と説得しやすい例を先行して確立してくれるのは，すごいありがたいと感じた
ヤフーのデータ戦略を支えるID連携 by 本間 洋光さん
- Yahoo IDをベースにデータの提供，蓄積，活用するために同じIDでサービス利用してもらう工夫
- ユーザにカスタマイズされたコンテンツ
- ログインの簡便化（セッションの引き継ぎ）
- ブラウザでのログイン情報をアプリに引き継ぐ
- YahooID連携
- 単に認証基盤を提供するだけではなく，他のサービスとシナジーを創出する取り組みをしている点が印象的だった
15:00-15:45 A-2
ライブクイズ「ワイキュー」を生み出した"内因的モチベーションドリブン" by 善積 正伍さん
- 会社にとってのサービスの目的や理由が，チームメンバのモチベーションの理由になるかというとそうでもないので，内因的動機づけの必要性にアプローチした話
- 課題解決型のサービスは課題と解決策が紐ついて明文化しやすいし共感は得やすいが，新価値想像型のサービスは課題に相当するものは無い
- リーンキャバスが描けないので，MLP(Minimum Lovable Product)で仮説検証した
- 1st MLPはSlack Botのアンケート機能でMLPを作って，賞金をかけたイベントが盛り上がるのかどうかの検証をやった（開発ほぼゼロ）
- 小さな成功体験が発生し，メンバの内因的モチベーションをドライブさせた
- 「みんなでワイワイする」というUVPが生まれた
- 2nd MLP
- 1st MLPのモーメントが実際のUIでできるか検証した→成功
- 技術的なパフォーマンス実現に難しさ（25億PVレベル）があり，リリース見直しがあり，ライフチャートは低減した
- 成功体験の因数分解によるモチベーションの維持もPMの仕事
- やらなくてもわかること，やらないとわからないことは事前に分解してMLPを組み立てる
- MLPは仮説検証でありチーム育成でもある
- どうメンバのモチベーションが上がるかを含めて設計する
- 大企業は多くの人が関わるからこそ，誰のモチベーションをくすぐるかまで設計する
- 仮説検証 x MLP x チーム育成
- リーンキャンバス描けない問題や検証のスパンが長かったり成功体験が無かったりすることによるモチベーションの低下は自分の組織でも経験があるので，非常に参考になったし同意できた
ワイキューが目指した"楽しい時間を作るデザイン" by 染矢 沙織さん
- 「惰性的な日常にドキドキする瞬間を」→パーティをコンセプトに据えた
- パーティ会場の擬似的な再現
- UIは単純にYahooのガイドラインに単に従うのではなく，サービスの特性やコンセプトに準じて決めていった
- スライドのデザインもちゃんとワイキューのデザインを適用しているっぽいくて流石感あった
16:00-16:20 B-3 ライブ動画配信サービス「ワイキュー」の作り方 〜優れた社内技術で実現する、少人数のサービス開発〜 by 石井 直矢さん
- Yahooのトップページは昔はYUI（米Yahooのライブラリ）だったが，Reactに変更された
- Yahoo社内に動画，コンピューティング，DB，NGワード等の各プラットフォームチームがあるので，サービスのコアバリューに集中でき，すばやく開発ができる（ワイキューのメンバは3人で，開発からリリースまで6ヶ月ほどだった）
- 配信動画はHLS(HTTP Live Streaming)というフォーマットで，動画にメタ情報が付加でき，フロントエンドでメタデータを取り出して処理している
- Yahoo全社として役割分担とフォーカスするべきものが確立されているので，それぞれが無駄なことをせずにモチベーションを保ちながらサービス開発できている感覚が垣間見れて良いなあと感じた
16:25-16:45 A-4 LEAN XPを活用したユーザーの声を聞くものづくり 〜Yahoo! JAPAN タブレットアプリのリニューアル〜 by 馬場 敬寛さん
- リソース不足と技術のレガシー化の問題を抱えながら，LEAN XPを活用してゴールを達成していった話
- LEAL XP
- Pivotal Labsで学んだ
- LEAN+UCD+XP
- チームとしてはPM+Designer+Developer
- 以下の3つのステップからなるデザインプロセスを実施した
- STEP1: ターゲットユーザの理解（Generative Research）
- STEP2: 課題の解決策の探索（Evaluative Research）
- STEP3: 解決策をより使いやすくする方法の探索（Usability Research）
- 自分の組織でもペルソナやシナリオをデザインすることはあるけど，それを検証してアップデートするというサイクルがうまく回っていないことがあるので，具体的なプロセスの説明をしてもらって参考になった
