デブサミ2020聴講メモ

C-1 Outcomes over Output: Productivityの高い組織への変革

Outcomes Over Outputとは

Output(つくったもの)よりOutcome(成果)に目を向けること。

Productivityとは

• 会社のミッションを達成するためにプロダクトを作っている。
  　→ お客様の行動を変える
  　→ 価値が認められ使われる
  　→ KGI(重要目標達成指標)を上げる
  こういったミッションをを達成するための活動度合いのことをいう。

プロダクト開発の不確実性

目的不確実性→何を作ればお客様に受け入れられるか
方法不確実性→どうやって、いつ作ればいいのか
不確実性を下げるにはDesign Thinking/Lean/Agileのサイクルを回す必要がある。

不確実性の中の組織とプロセス

検証のためのOutputを頻度高く出せる組織・プロセスにする。
機能を作ることだけに満足せず、OutputがOutcomeになっているか頻度高く検証・学習する必要がある。

目的不確実性を減らすには

高い頻度でお客さまへの価値を検証する。リリースを刻むことで、お客様に価値があるかないかを確認することができる。
→不確実性を下げて価値を大きくしていく
WIPが続くとお客様から見て価値0になってしまう。
価値があるかもしれない状態をお客様に届けることが大事。

方法不確実性を減らすには

検証のためのOutputを頻度高く出せるような組織づくり
デリバリのパフォーマンス指標を使うとよい

• Lead time
• Deployment frequency
• NTTR(不具合修正にかかる時間)
• Change Fail　Percentage
  上二つは価値創出のために計画された能動的活動であり、下二つは不具合の修正などの受動的な活動である。
  上二つの指標が高いとOutputを生むという意味でのProductibityが高いといえる。

どこから手を付ける？

パレートの法則
効果80％を生む20％の課題を解決
Outcome80％を生むOutput20％を行う

C-2心理的安全ジャーニー ～Slackで安全を実装する5つの手法～

心理的安全性について

• 挑戦モードときに無知・無能・批判・横やりをしても(妨害がなく)大丈夫と信じられる状態のこと

• 挑戦モードとは
  　- リスクある行動(挑戦行動)をとったとき

• 挑戦者が無知無能見せる→協力の催促

• 批判横やり→協力者が正しい方向へ導く

• 挑戦モードのときに協力と催促による相互関係が成り立つと心理的に安全であるといえる。

• 通常モードにおける催促と協力の関係は信頼である

• 相手に頼っても善意で協力してくれると信じられる状態
  信頼を得るためのステップ
  警戒・疑心 → 親和 → 信頼

• 親和を築くには、利他・自損的に動くことが必要。手間を無駄にかけたり、自己開示をすること。
  損をしてでも信頼されたいことが相手につたわると親和が高まる。

親和があれば守備範囲以外の協力を得られる。相互の信頼を作るには時間がかかるので、感謝が重要。
何かあれば感謝をして自分も協力するよと約束することによって信頼が得られる。

心理的安全性ある・ない問題

• 信頼への道のり→尊重。優劣にかかわらず相手の行為を価値あるものとして大切に扱うこと
  クリティカルシンキング
  アサーション(言い方)
  →個人の能力。学習が必要。

心理的安全性の安全は工事現場の安全に近い。くつろげる状態というわけではない。
アサーションがないことをアサーションを持って伝える

心理的安全性5つの実践

Slackでの事例

• 安全装置を作る

• 禁止ルールの明確化(誹謗中傷、暴言の禁止)

• 制約とペナルティ付加特権を失う

• Slackガイドラインは細かく定める。

• 砂場を作る

• ルールを守ったうえでなんでも許される場所→パーソナルチャンネルを用意。

• パーソナルチャンネル

• 分報(スレッドにして見えないように)、否定的な感情の自己開示する。弱みなどなんてもつぶやいて良い場になる。

• 補助輪

• 自己開示の補助をするようなSlackBotを作る。

• 補助

• 挑戦行動をするための障壁を取り除く
  AMAチャンネル。役員が72時間以内に質問に答える。上長がパーソナルチャンネルを見て回り声がけする。

4行動誘発と妨害除去

• BadNewsFast
  悪い情報であればあるほどすぐに報告する。本来は危険行動を消失させる

• BadNewsFastチャンネル
  悪い情報をすぐ共有するチャンネル
  報告があれば怒らず感謝する。報告しないと厳罰処分
  発生した悪影響を最小化できる。
  弱さを見せる風土づくり。
  チームのルールをプルリクで決めてみる

• カオスエンジニアリング
  健全な無茶ぶり
  フェイク：あえて教えない、ミスリードさせること
  他責的傾向がある人をあぶりだす

• シャドー
  無意識的に否定したきた見たくない自分の側面
  シャドーをあえて誘発させる
  人から強制されたときは反抗心を持ちやすくなる。論理的矛盾を0にする。

• 不確実な状況における予測・意思決定をどう行うか
  強い意見を弱く持つ。

C-4週一でリリースし続けるための、フロントエンドにおける不確実性との戦い方

将来的な変更容易性を

• システム用語は抜きにして全員が理解る言葉で会議。
• モブで合意・意思決定する習慣
• 同じものを、同じ目線で、チーム共通の言語で作る。
• 優先度：安全性、将来性、スピード

開発はすべてモブプロで行った。
個人に知識が張り付くことを避ける。
これはあの人しかできないを徹底的に避ける。

リカバリーがきくタイミングで再度ユースケースの確認をし、開発しながら生まれて認識のずれを解消

数値の可視化
売上なども全員で必ず見るようにしている。
夕会で共有。みんなで同じものを追いかけているんだということも大切にしている。

まとめ

誰かの決定＜チームの合意
アーキテクチャ一般論＜チーム共通言語のアーキテクチャ(一般論はエッセンスのみ)
機能の提供＜機能と価値の提供

所感

全てをモブプロで開発することを徹底しているところが自分のチームとは違うと感じた。(手戻りが発生しそうな箇所、意思決定が必要な箇所だけモブプロという形なので)
仕事が一人の人が持つ知識だけに頼りきりならない、成果物にいろんな人の目が入るという点がいいなと思った。
チーム全員の合意・意思決定を大切にしているというこを何度も述べられていた。

#A-9プロダクト作りのトランスフォーメーション

この半年で変わったものと変わらないもの

在宅勤務に慣れない人がいるのでパフォーマンスに影響があるのでは？

• パフォーマンスが低下していたらどうするか→開発計画を作りなおす。おしりをたたくために行っていない。
• パフォーマンス計測
  開発タイムのリードタイムを計測したところ、在宅勤務にシフトしてから2週間、2か月後パフォーマンスが変わっていないように見える。

メンバが頑張りすぎていた？

持続可能なペースで仕事をするべきと告知したが、それでもパフォーマンスに大きな影響がない。

その他の計測ツールとしてジローを使ったがそれでもパフォーマンスに変化がないという結論になった。

パフォーマンスを安定させるための施策

コミュニケーション(雑談)の低下が起きたので

• Discordボイスチャットツールの導入

• 夕会で雑談の場を設ける(任意参加)

• ワーキングアグリーメント
  チームの暗黙的な約束事を明文化する

• 当番

• レビューフロー

などをスプリントごとに見直す。
なぜ必要？
新しいことやったことに対するよくない感情を吸い上げるために必要。
また、在宅ワークはより成果主義的。裁量がある分ある程度強制力を伴ったルールが必要。
それを明文化し、改善できるような仕組みを作る。
最悪1スプリント我慢すればいいので新しい施策を取り入れやすい。

まとめ

変わらない→パフォーマンス
変わった→取り組み方
変わりやすいルールを設けたことで、新しいチャレンジを取り入れやすくなった。

---

不確実性の高い世界の中で非連続な成長を生み出す

どんな不確実性に直面、なぜ非連続な成長が必要？

不確実性：正解がない中でプロダクトを作る。
非連続な成長：積み上げの成長では到達が難しい

開発チームの取り組み

• コロナ禍により取り組むテーマの優先順位の変化

• チームでは変化に気づくための自立性が養われていた。

• 個人の生産性・コミュニケーション

• それぞれ個人が直面した問題に対してボトムアップで解決できた。

なぜ変化に柔軟に対応できたのか

• 個人の創造力や、発想を最大限に生かす。誰も正解を知らない中でトライエラーを高速で繰り返すことをしていた
• そのために大事にすること

• ルールを決めない。一度決めたらやめずらくなるから。
• 自分の生産性は自分で上げる。
• 前提にとらわれず、ゼロベースで考える。

環境変化によってチームの成長へ

開発チームの自立性・並列性の強化を行った。プロダクトに関するWhu・How・Whatを意思決定できる人を増やす。
どうやって増やすか？
以前はCPO中心に行っていた。
チームが生まれてスケール
チームのリーダーに責任を委譲していくようになった。

CPOにあえて頼らない状況を作り、Whyを主体的に考えられる人を増やした。
全体・長期はCPOそれ以外はチームメンバがWhyの責任を取ることに

---

トランスフォーメーションジャーニー

プロダクト開発の課題

• 不確実性
• 逆境
• 断絶

13の問題

• 整っている状態から始まることはない。
• わからない、曖昧、何したらいいかわからない。
  浅いコンセプトのまま進めてしまう
  現状の理解が進んでいないまま意気込みで進めてしまう。「やってみないとわかんない」それは本当？

ゼロチーム
企画者が一人しかない。プロダクトづくり日一人の知見に偏るから、それ以上にいいものはできない。
企画者本人も迷走

何を作るべきか基準をを決めなければいけない。
想像で開発しないといけない。
どう実現するかの手段・方針が立てられない。→やってみたいベース

歴史的な前提負債
既存のシステムを扱うと時間がかかってしまう。

政治的安全性
これまでこうしてきた、こういうルールだからを第一において判断してしまう

目の前の最適化
不敵な目的が偉大な手段を殺し続けることになる。これまでを継続させようとし、新たな意思決定することはない。

はじまらない対話
必要な会話でなさそうあれば、会話を始められない

窮屈な対話
会話のコストが高い。会話の数が限られるため、一回の会話の情報量を高めようとする。→すべて受け取れない

あなたのことがわからない
相手の感情の変化をつかめない

以上13の問題が絡み合い、強め合ってより複雑な問題になっている。→分断の三角形

最初に取り組むこと

チーム活動の共通の認識をそろえることが前提。一時的にでも仮の方向性を設定し、方向性を変える場を約束する。

分断による問題に向き合うすべ

不確実性→探索・学習
仮説検証型アジャイル開発

逆境→段階・向き直り
自分たちが到達したい地点を見立てて、構想する。構想の結果から構想自体を変化させる。その時点で何を大事にすべきかが全員が理解して取り組むことができる。

断絶→対話・再定義
対話→作為的に、意図的に行う
モデル・図解なので相手に伝わりやすい情報にする

3つの分断によって価値観の分断が起きるが、すり合わせる機会が失われる。
トランスフォーメーション→自組織の状況に適応した価値基準を見つけに行く、自分たちのものにしていく、アップデートし続ける力が組織に宿せるかどうか