改善を望むなら目的を渡す

「この手順を厳守してください」「良い結果を出してください」
この状況で出来ることは手順実行の速度と精度をひたすら上げるだけ.

目的 <- 活動s
構造が認識された活動の型: 手順
直感的な活動もあれば、手順に従う活動もある.

型の認識は底上げ・理解・改善・伝播などなど様々な利点があるけど、それに縛られるリスクもある.

手順の改変・無視が許されるなら幅が広がる
あらゆる活動ができるので、何をもって"いい活動"とするのかが重要.
それは当然、活動の目的に貢献するか否か
なので改善を望むなら目的を渡すのがマスト

OKRには評価可能なKeyResultが必須

マネジメント方法

1. 「この作業やって」
2. 「この成果実現して」

Aなら作業手順をやったか作業を確認すればいい

Bだと方法を一任しているので、作業を見ただけではそれを評価できない (遊んでるのか成果だせる作業してるのかわからない. 遊んでるように成果だすならそれが正解の方法).
成果だけが確認・評価の対象.
もし評価できない成果を出せってなると、成否を全く評価できなくなっちゃう.
正しく進んでるのかがわからなくなるので、くじ引きで進む道を決めて突き進んでるようなもん.
この「評価可能な目標成果」がKey Result

権限と責任が不一致なときの反応

権限がないのに成果責任がある場合

死ぬほど確認する
「パターンθもあり得るんじゃないの？」「コスパとかいうけど、不明点が一切無くなるまでやるべきでしょ」「やるのは私なんですよ、納得するまで動きません」

権限がないので、一度受け入れたらそれで成功させる以外の選択肢がない。なので受け入れ段で極限まで精度をあげなきゃいけない。
プロトタイピングしたり、初期検証の後に方針転換すべきなんだけど、その権限がないのでこうなる.

権限がないのに出力責任がある場合

失敗するとわかってても黙々と作業する
「作業Aですね、では来月までに」「部長の言い出したコレ、絶対失敗するよな、まぁやるけど」

outputに責務を負うので、実作業をすれば責務を果たせる.
責任感や自分事感とかのモチベーションがあればoutcome/成果に目を向けるけど、権限が無いのでモチベ上がるわけもない.
仕事は仕事なので無駄に抵抗せず責務を果たしましょ、になる.

権限あるのに責任がない場合

客観的な実現可能性を無視する
「これが私のビジョンなんだ、これが作りたい」「私の旧知の顧客もこう言ってる、間違いない」「これまで上手くいったんですからこれで決まりです」

失敗のリスクを無視した行動に出始める.
失敗しても責任に伴うリスクが0なので真っ当な狂い方.
独善的になるとも言える.

問題と価値とユーザビリティ

価値のない問題 (もはや問題じゃない問題) を仮定するとユーザビリティはわかりやすい.

無でいられていない、という問題に対する最適解は、何もしないこと.
期待した成果が完全に、しかも超効率で得られるのでユーザビリティは非常に高い.
ただ、無でいられたとして、それに価値を感じない人はたくさんいる.
無の問題を解いても、無なのだ

悪い状態・不満アリ・充実してない → (システム利用) → 良い状態・不満ナシ・充実
システム利用を介した変化体験 -> UX
ユーザーが好まないシステムをぶつけても利用してくれないので「気づきもしない/気づいたけど使わなかった」UXが発生.
無の問題を解いたUXは満足感がとても低い.

検証と仮定と妄想

• マッチョモデル: 無作為に端から検証し採用
• 実務家モデル: 経験に基づき優先度を設定、上から検証し採用
• ガリ勉モデル: 経験に基づき優先度を設定、上から無検証で採用

無限にリソースがあるからマッチョモデルで良いが、現実にはリソース制限があるので実務家モデル.
ガリ勉モデルは妄想と大して変わらないので論外 (自分を過信し過ぎ).

サービス指揮/ディレクション

サービスの指揮/ディレクション

.1. 一貫した核心的UX
.2. 持続的提供 (ロジスティクス)
. . a. ビジネス
. . b. dev

を実現する施策の選定
サービス=ユーザーが一体と認識するシステムの範囲
なので施策はPR~マーケ~開発~運用まで全範囲

マーケ・テックリード・デザイナーと連携して施策を決める
Whatを決めるのが仕事、Howは完全移譲

「顧客のため！顧客のため！」といってUX向上施策を打ちまくるのもダメ.
Leanなのが大前提.
筋肉質な施策を一貫して核心的UXへ向けるのが仕事.
ユーザーは必ずしも複雑さを求めてないし、多機能はほぼ間違いなく高額になり、UXに影響する

ユーザは一貫性を持っていないが、一貫性には敏感.
日によって要望があちこちいくけど、実際のUXが一貫性してないと満足度低い.
ユーザの要望をただ聞いてるとフラフラしたサービスになっちゃう.
一貫した核心的UXを持ち、それをユーザ検証で修正しつつも貫くのが大事.

いずれチーム分割して担当が分かれることになる
"サービス"というより"サブサービス"になるけど、名前は"サービスディレクション"?
あるいは上にチーフってつけるとか

UXの一貫性

一貫したUXを提供するために、core UXを定めてそこから全てを派生させる.
Q. そもそもUXを一貫させる利点は？

一貫したUXの和というよりは積のような感覚もある.

一貫性のないUX / inconsistent UX

濁る、裏切られる

一貫性のない新機能

UX-A 10個、UX-B 新機能1個
marketing:「新機能によりBを実現！」
app: UX-A機能メインで新たにUX-B機能を追加

既存ユーザー: 良いUX-Aを期待
. => 使わない機能は無意味
. . =>marketingを見て「使わない機能増やすんならバグ取りしてくれよ…」
. . . =>負のUX
. . =>appを見てなんもなし（新機能無関係やしなぁ）
. . . =>UX無し
新規ユーザー: 良いUX-Bを期待
. => 充実したUX-Bを期待
. . => marketingを見て「これは良い！」
. . . => 正の予期的UX
. . => appを見て「いらん機能だらけ…良くわからん…宣伝詐欺…」
. . . => 強い負の累積的UX

一貫性のないマーケティング

値段に注目したマーケティングをしすぎて「安い」UXに反応するユーザーしか残らない.
core UXに反応せず安さにしか反応しないのでオワリ.