myoanと申します。
この記事はミクシィグループ Advent Calendar 2018 - Qiita 13日目の記事となります。
私が現在在籍しているチームで行った、エンジニアとそうでない役職(企画・デザイナ)間の関係性の向上に向けた取り組みを紹介したいと思います。
技術的知見はありませんしポエミーな記事ですが、ご了承ください。
初めに
今年の年明けくらいからサーバとデータのつなぎ込みが出来始め、「そろそろデータ作成を本格可動していこう」という話になりました。
そこで私は事故防止をするためにレビュー体制を組みたく、Github flowを導入ようと画策しました。
しかし、ただGithub flowを敷いただけでは変わらず事故が発生するという懸念もありました。
それはレビューによるミスの防止という目的が伝わらず、単に儀式的な行為になってしまうことを恐れたためです。
また、意味不明なルールを制定するエンジニア(私)、よくわからないけど運用する企画・デザイナという溝を作りたくなかった事もあります。
そこで企画・デザイナの心理的安全性を高めるためにもエンジニアに相談しやすい空間を設けるために企画・デザイナに向けた勉強会を運営をしました。
(そして勉強会での最初の目標を「Github flowを理解してもらう」としました)
心理的安全性
googleのre:Workでは心理的安全性に関して下記のような説明をしております。
「チームの心理的安全性」という概念を最初に提唱したのは、ハーバード大学で組織行動学を研究するエイミー エドモンソン氏です。
同氏は、この概念を「対人関係においてリスクのある行動をしてもこのチームでは安全であるという、チームメンバーによって共有された考え」と定義しています。
また、書籍 エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリングでは心理的安全性が高いことで発生する影響を下記のように述べています
| 影響 | 解説 |
|---|---|
| 率直に話すようになる | 課題について他の人がどう思うかをそれほど気にしないでも発言することが出来る |
| 考えが明晰になる | 不安が少ないため、認知の歪みが少なく、考えを明晰に表現できる |
| 意義ある対立が後押しされる | 関係性の悪化に伴った対立ではなく、より本質的な対立を健全に議論できる |
| 失敗が緩和される | 失敗を報告しやすくなり、ミスについて話し合う機会が増え、学習を行える |
| イノベーションが促される | 今までの前提を取り払って、思考することが出来るようになり、創造的な意見が出る |
| 組織内の障害でなく目標に就留できるようになる | 目標に対して、ストレートに向き合えている。組織内の理不尽を取り除くことに力をかけないでも済む状態にある |
| 責任感が向上する | 対人リスクをとっても、目標に対して自立的に行動できるようになる |
企画・デザイナの心理的安全性
チームの様々な人と話していて、企画・デザイナの抱える心理的不安が見えてきました。
企画・デザイナの心理的不安
- なぜこれを使っているのか、なぜこれでいいのかわからない
- 例: なぜバージョン管理を行うのか？
- エンジニアが怖い
- 質問がし辛い
- 「こんな当たり前のことを聞いて申し訳ないんですけど...」と始める人
- 「エンジニアに相談に行くときは、"要求を通すための戦い"だと思っています」と比喩する人
- 質問がし辛い
目標とした心理的安全性の高い状況
「どんなことでも質問できる環境になっている(どんなことでも提案できる環境になっていると理想)」を目標としました。
ゆるふわ勉強会
勉強会の名前は畏まってほしくないため「ゆるふわ勉強会」としました。
毎週1時間の開催としました。
勉強会は就業時間中に行い、任意参加としています。
(定時後だと予定が合わないということで段々とダレていく事を恐れたためです)
この後の章ではゆるふわ勉強会が1年間でどの様に変わっていたのか書いて行きたい思います
第1フェーズ: Github flowの習得
最初のフェーズでは発表側も聞く側も慣れていないため、どうなるかと不安でした。
(最悪自分が全部発表する気でいました)
しかし、エンジニアでも発表したい方が多く、ほぼ全員がまんべんなく発表した形となりました。
(うちのチームには何度も助けられています。本当にありがとうございます。)
最後に簡単なハンズオンを行い、Github flowは実戦投入となりました。
このときの変化としては、ゆるふわ勉強会前と異なり、相談内容が明確になってきました。
「SourceTreeを操作したらよくわからないエラーが起こった」> 「同名のブランチを複数作ってしまった」
(用語が使われるだけでどれだけ助かることか...!!)
勉強会のプレゼン資料を引用して再説明するなど、アフターフォローも楽に行えていました。
第2フェーズ: エンジニアから企画・デザイナへの勉強会
Github flowが開始されたため、ゆるふわ勉強会では企画・デザイナが聞きたい内容をエンジニアが話す場と変化しました。
それに合わせて運用も下記の様に変化していきました。
- 第一週で議題と発表者(エンジニア)を決定
- 第二週で発表者が発表し、質疑応答
話した内容としては、git/githubに関連した内容やUnityの質問が多かったです。
その他に「(コンピュータ関連の)怖い単語」や「一問一答」など様々なコンテンツを出して、勉強会を行いました。
このとき、企画の方から「ゆるふわでは相談がしやすい。エンジニアが優しい」などの評価をいただけるようになりました。
無事、目標が達成されました！
第3フェーズ: 知見を持つ人から持たない人への勉強会
始まりは、Unityのprefabをデザイナが発表したことから始まりました。
エンジニア以外でも議題に答えられる人間ならば発表するという流れが生まれました。
ここで私はこの流れを止めないように、なにかしゃべる場がある度にわざとらしく「ゆるふわ勉強会が進化した」と触れ回りました。
それが功を奏したのかわかりませんが、発表内容が多様化していきました。
- 企画の作り方
- 物語の作り方
- キャラの作り方
- デザイナの仕事紹介
この頃には、私からなにかコンテンツを提案することはなくし、流れに身を任せていました。
第4フェーズ: さらに進化するゆるふわ勉強会
10月頃から、ゆるふわが「ラフになにかを紹介する場」という認識が生まれていました。
また、別チームの方が社内勉強会の運用の参考に、と参加されることが出てきました。
この頃には本当に様々なコンテンツが自発的に生まれてきました。
- インターン生の成果発表
- 他のチームを褒める会
- 運用フロー変更の説明会
常に変化するコンテンツと見て、少しは自己組織化されたチームに近づいたのではないかと思っています。
まとめ
ゆるふわ勉強会で気をつけたのは以下のポイントです。
- 発表テーマを企画・デザイナが決める
- 就業時間内に開催することで、参加者を確保する
- 任意参加することで敷居を下げる
しかし、まだまだ不足してる部分もあります。
- 任意参加のため、参加しない人も当然いる
- リリース間際になると就業時間で開催することに弊害がでる
終わりに
途中も書きましたが、ゆるふわ勉強会が成功したのはチーム全員の成果であって私一人では決して成しえないものでした。
逆に、正しい方針をもって仲間を見つけることが出来れば、自分では成しえないものも生まれるという良い経験が出来ました。
任意参加で参加されていない人がいる現状、心理的安全性が完全になったとは言えません(そんな状態あるのか？)。
今後もチームが安心してプロダクトに集中できる環境を作っていきたいと思います。
技術に関係のない話で申し訳ありませんでした。
明日14日は@akkumaさんです！
皆さんお楽しみに！