はじめに

本記事はDevelopers Summit 2020 Summerで聴講した講演のメモをアウトプットする目的で作成しています。
Developers Summit 2020 Summerの詳細はこちらを参照ください。

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

心理的安全性とは

リスクのある行動をした結果に対する個人の認知の仕方
4行動：無知・批判・無能・横槍
リスクある行動＝挑戦
困難に立ち向かい目標達成を目指す状態を挑戦モード、明らかな困難がない状態で目標達成を目指す状態を通常モードと呼ぶ
挑戦して成功するには協力が必要
- 妨害された失敗して当たり前
心理的安全性は挑戦をしている時の催促・協力行動に関係している
挑戦者は相手の批判や横槍を受け入れる
協力者は挑戦者を尊敬し、積極的に協力する状態が、心理的安全性が高い状態
挑戦していない時の催促・協力には信頼が必要

信頼とは

心理的安全性が必要となる挑戦モードではなく、通常モードでの催促・協力関係を構築するために必要なもの
信頼には親和が必要
挑戦モードでは、心理的安全性と信頼が両方とも必要
信頼には尊重も必要
批判を受け入れるには、意見の尊重と批判がクリティカルシンキングで述べられる必要がある
アサーション持って、批判に対しての応答をする必要有→でないと批判合戦になる

心理的安全性の実践方法

基本設計

安全装置作成
- 禁止ルールを明確化する
  - 誹謗中傷
  - 暴言
- 制約
  - ルールを守らない場合の罰を決める
- 砂場
  - パーソナルチャンネルをメンバ全員分用意
  - 分報とは大きく異なる
  - 特に否定的感情の自己開示を行う
  - 個人の作業メモを目立たないようにするルールとしている
  - 感情を自己開示している
- 補助
  - マネージャーがパーソナルチャンネルを徘徊し、フィードバックする
4行動誘発、妨害除去
- Bad News Fast
  - 悪い情報であればある程すぐに報告する習慣
    - 挑戦行動した場合に対しては正のフィードバックをしないとBad News Fastがされない
  - 専用チャンネルを用意
    - 報告に対しては起こらず、感謝する
    - 報告しない場合は処罰
    - 早期に奉公することで発生した悪影響範囲を最小化できる
    - 弱みを見せれる風土が極めて重要
- 会社批判
  - 経営のモットーと実業務の相違などを打ち上げ
  - CEOが理想的な批判を吸い上げ、全体に共有
  - 批判はプルリクのような形式でレビュー後に反映するかを決めるプロセスとしている
- カオスエンジニアリング
  - 組織内で対処できる範囲の問題を起こす
  - 健全な無茶ぶり
  - フェイク(敢えて教えない、ミスリードさせる、嘘をつく)
    - フェイクによって、批判する可能性が上がるため、それをフィードバック対象とする
  - シャドー
    - 自分の見たくない側面
    - 上記の見たくない側面を見た場合への免疫を向上させる

所感

パーソナルチャンネルは自チームにも用意すべきであると感じました。心理的安全性についての理解があいまいだったことを痛感しました。

フルリモートで事業にコミットするエンジニア組織とは

リモート組織の特徴

時間と場所が自由
- ただし、セキュリティには注意が必要
- 世間的にもリモートワークでは、セキュリティが重視され、問題も生じている

リモート組織をやってきて感じること

一般的メリット

QOLの増加
コストの低下
- 交通時間の時間コスト
- オフィス賃金
経済面
- 副業をしやすくなるため、経済的プラスを得やすい
採用
- 場所の制約なく、採用可能

一般的デメリット

時間配分
- 仕事のOn/Offの境目が曖昧になりがち
情報量
- 地方にいると、取得できる情報量が少ない、都会と比べてエンジニア勉強会が少ない
自律性
- 自分で自分を律する必要がある
仕組み面
- リモートワークを前提とした際に、仕組みを変えるもしくは新たに仕組みを作る必要がある
コミュニケーション
- 認識のズレが発生しやすい

会社を運営するうえで感じること

対面で話すからこと伝わる熱意や気持ちが伝わりづらい
- →アイデアが生まれづらくなる
リモートワークに向く人と向かない人がいる
- →ハイブリッド型が主流になる
無駄なノイズが少なくなる

リモート組織ならではのルール

各人が利用するツールを統一化する
- 統一されていないと参照すべきツールが無駄に増える
- モブはSlackで実施
ワークスタイルの明文化
- ルールやノウハウを明文化
コミュニケーション
- 伝える相手や表現を考慮して、提案や議論などのコミュニケーションをする必要有
- メンバに注意する場合は、できる限りDMでの個別注意がベター(チャンネル全体で見えるようにはしない)
- Zoom飲みなどで議論→人間関係構築
マネジメント
- 誰かにマネジメントを任せきることがないようにする
- 日報も重視
- チームとして目指すべき共通認識の統一が重要
- リモート不向きなタイプ
  - アウトプットが不明瞭
  - オフィス人と会いたい人
  - 報連相が漏れる人
- リモート向きなタイプ
  - 家でもダレないタイプの人
  - 報連相が正確な人

リモートでのエンジニア組織の今後

リモートの仕組みがあるかないかで採用力が変わる
- エンジニアはリモートでの仕事に飢えているため
リモート組織が増えると、リモート環境以外の観点が重要となってくる
VPoEが今後はリモート組織運営では重要となると推測

所感

リモート組織においてもコミュニケーション問題を抱えていることを知り、リモート環境においては、コミュニケーション問題に向き合う必要があることを再認識しました。

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

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

開発形態はSaaS開発

チームのパフォーマンス

仮説：在宅勤務になれていない社員が多いので、パフォーマンス低下しているかどうか
- 現状把握のための計測であり、開発状態の良しあしを判断してはいけない
仮説：パフォーマンスが落ちないために頑張りすぎているのでは？
- 結論：チーム全体としてパフォーマンスに大きな影響はない

チームを安定させるための試作

コミュニケーションの低下
- 雑談できない、気楽に質問できない
- Discordの導入
- 夕会という雑談の場で、任意参加
- ワーキングアグリーメント
  - チームの暗黙的な約束事を明文化する
- なぜワーキングアグリーメントが重要か
  - 施策に対しての打ち上げを逃さないようにするために重要
  - チーム運営にはある程度強制力を伴ったルールが必要
  - 新しい施策を試しやすくなる

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

半年での変化

開発チーム
- 取り組むテーマの優先順位
- 個人の生産性・コミュニケーション

変化に対して行ったこと

取り組むテーマの優先順位
- 変化に気づくための自律性・並列性が既に確立していた
開発プロセス：フォーカス
- 2月ごとに注力すべきテーマに合わせてチームを作成し、曖昧な要件をもとに成果を上げる
不確実性の高い世界の中で非連続な成長を生み出すために
- 個人の想像力・発想を最大限生かす
- トライ&エラーを高速で繰り返す
- ルールはできるだけ決めない
- 自分の生産性は自分で上げる
- 常にゼロベースで考える
- プロダクトアウトを大事にする
  - 良いともう物はすぐ作って出す
変化のストレス・機運をチームの成長につなげる
- 元々Why How Whatが誰かにフォーカスしている
- 誰かにWhyが依存していると意思決定スピードが下がる
- やったこと
  - チーム内でWhyについての知見を出せるメンバ以外でWhyを考えてみる
  - Whyを考えられるメンバーは増えるに越したことはない
まとめ
- 課題は尽きないので、常にアクションを続ける必要有

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

プロダクト開発に立ちふさがるもの

不確実性
- 体制があって始まることはない
- シャロウコンセプト：浅いコンセプトのまま開発を進める
- 過剰な意気込み：コンセプトへの理解が薄く、意気込みだけで開発を進める
- ゼロチーム：POが1人だと、そのPOの持つ知見以上のアイデアが生まれない
- 本人にもわからない：コンセプトはあるが具体的なアウトプットがない
- 我々は何を作るべきなのか？：仮説を立て、検証しないと作るが明確にならない
- オーバーエンジニアリング：
逆境
- DXにより制約が増える
- 歴次的な前提負債：既存資産が足かせになる
- ゼロエキスパート：プロダクト開発を進めるために必要な専門知識を有する人が足りない
- 政治的安全性：今までの判断をもとに判断してしまう
- 目の前の最適化：目の前のことを基準に最適化を図る。この視点ではDXは促進しない。
断絶
- 始まらない対話：ある程度考えがないと会話が始められない
- 窮屈な対話：会話開始へのコストが高まり、1会話での情報量を詰め込む→やり取りが煩雑に
- あなたのことが分からない：相手の機微が分からない

越境

イマココの立ち位置から歩み出ること

仮説と約束を置く
- チームに共通認識をそろえる
- タイムボックスを置き、共通認識を改めるタイミングを決める
- 方向性を変える
  - 一つ前のタイムボックスでの学びを反映する
探索と学習
- 不確実性への処置
- 仮説検証型アジャイル開発
段階とむきなおり
- 逆境への処置
- 段階の設計：自分たちがなりたい状態への構想を作る→都度構想を変える
- 理解と意思決定を共有できる
対話と再定義
- 断絶への処置
- 意図的な雑談を仕組みに入れる
- 図解でのコミュニケーションも重要
- 小さく、短く、一巡させる
価値観の分断：価値観を共有する機会が失われている
Transformation = 価値基準の再定義
- 自組織の状況適応に必要な「価値基準」を見つけにいき、アップデートし続ける
価値観をそろえ、統一すればよいわけでない
- それぞれの価値基準から、チームが進むべきための価値基準を考える
- それぞれの価値基準は捨てるわけではない

所感

現在のプロダクト開発は不確実性が高いため、チームメンバ1人1人がどんなものを作るべきかを自発的に考えることが必要であることを理解しました。発表自体は3つあったが、チームで共通の価値観を持つことが総じて重要だと個人的に感じました。

Developers Summit 2020 Summer 聴講メモ