161
139

More than 5 years have passed since last update.

自立自走型チームの構築と心理的安全性を高める施策

Last updated at Posted at 2018-03-15

はじめに

※大層なタイトル書いてるけどただの日記みたいなもんです
※あくまで個人の見解であり、所属する団体・組織の見解ではありません

 現在自分は客先常駐型でエンジニアの派遣を行う事業をメインとする会社で、小規模ながら社内で受託開発を行う部署に在籍している。その組織の仕組みは「プロジェクトマネージャー」と「組織の管理職という肩書としてのマネージャー」が兼任になることが(自分も含め)ほとんどだった。なんでもできるマネージャーがタスクを分解、できそうなメンバーにアサインし、メンバーはタスクをこなすのみに注力という構図で、以下のような問題が起こっていた。

  • マネージャーが非常に多忙でSPOFになるケースが多々。とてもじゃないが休めない
  • できる人のみにタスクが集中し、できない人は本当に何もしてない
  • メンバー間での責任の押し付け合い
  • マネージャーからメンバーに対する高い圧力
  • やる気があるメンバーのモチベーションがどんどん低下し、人が育たない、育てる余裕がなくなる
  • プロダクト、プロジェクトに発生した問題責任がマネージャーのみに存在

 今の組織ではこの現状が風土・文化として既に当たり前の状態となっていて、入社した当初はかなり驚いた。
 元々アジャイルチームを作りたい・日本に浸透させたいって想いが自分にはあるのだが、入社早々にマネージャーの立場になり、この先生きのこるためにもなんとかこの状況を変えないといけないと思った。それでも既存の文化を変えていくのは難しいのが実情で、せめて自分が見ている範疇だけでも自立自走できるチームを作りたいと思い、日々試行を重ねてきた。結果としてなんとかいい感じに回ってきたなと思ったので、どんなことをやったのか書き連ねてみようかと。

心理的安全性とは?
https://bizhint.jp/keyword/101187

やったこと

プロダクト、プロジェクトのビジョンの共有

 メンバーがなぜこのタスクをする必要があるのか知らない状態に慣れてしまっていた。非常に差込が多い環境なのでタスクに集中しやすくなるという意味ではそれもいいのかもしれないが、顧客が抱えている問題を解決するという大前提が伝わっておらず、ゴミを作って納めているような状態だった。まずは全員の目的を統一し、下記のような構図となるところからスタートした。

Untitled.png

具体的にやったこと

  • 顧客の抱えている問題・悩みに(多少大げさでも)共感してもらう
  • このプロジェクトがどのようにして顧客の悩みを解決するか伝える
  • 最終的にプロダクトがリリースされた後、どうなるかを理解してもらう
  • 一緒に顧客の問題を解決していこうということを伝える

 幸い若手のメンバーが多く、そういう人達は元々そうあるべきだよねっていう感触だったが、在席期間が長くずっとその状況下で働いてきた人からは、「自分に何のメリットがあるのか」「失敗したときの責任が自分に来る」といったような形でかなり反発を受けた。何度も話し合いを重ねたが、組織の評価制度上確かにメリットを提示するのが難しく、完全に納得してもらえないままプロジェクトに参画という形になってしまった。すると他のメンバーとのぶつかり合いや責任の押しつけが多くなり、しばらく経った後に結果としてプロジェクトから外れてもらうという形になった。悪手を選んでしまった形だったが、結果として目的に対して一丸となって進めるチームが結成されたと思う。

すべての情報をお互いに開示し、何でも言える関係性を作る

 プロジェクトのゴールに向かうマインドは統一化することはできたものの、実際にそれに向かって進めていくということが非常にしづらい状況だった。というのもメンバーが別にプロジェクトを2~3持っていたり、その他プロジェクトに関係がない差込が多い環境だった。そのため、ほとんどコミットできていないメンバーはコミットしているメンバーに対して、申し訳ないという感情が働いてしまったり、自分に説明の時間を割いてもらってもまたすぐに追いつけなくなってしまうのではないかという不安が顕在していた。そこで以下のような行動を取った。

  • メンバーと 1on1 を不定期に実施、雑談ベースで信頼関係を築く
  • 悩みや問題を打ち明けてもらい、とにかく共感する
  • 他のメンバーにその事実を話して、みんなで解決方法考えてみないか促す
  • 全員で一同に集まって問題を共有し、問題をどう解決するか一緒に考える

一番気をつけたのは4つ目で、「問題を抱えたメンバー vs 他」ではなく、徹底的に「問題 vs 全員」となるように促し、ただ問題を見える化するだけでなく、チームが安全であるという感覚を互いに持ってもらった。

参考)「賢い大人」たちが発するメッセージは「一緒に考えよう」だけでいいじゃないか
https://qiita.com/inouetakuya/items/58e5fc12a8015882cfad

この取り組みをしばらく行っていたのだが非常に効果が高く、割り込みが入った際は即共有し全員でどうするか決めるようになった。それだけではなく、プロジェクトを進める上での技術的課題も自発的に共有をし、集合知によって解決できるような体制が形成できた。

その他

 先述した2つで大分プロジェクトを進める上で自走できる体制が整っていたと思う。
その他プロジェクトの進行中に以下のようなことをやってきた。

  • 極力みんなで意思決定をし、失敗しても大丈夫という土壌を作る
  • ゴールに向かって進んでいる感を持ってタスクを行ってもらう
  • 短いサイクルで「何」を「いつまで」に「どこまで」できるか宣言してもらう
  • 短いサイクルで振り返り学習する

できなかったこと

プロジェクトに関係ない余計なタスクを剥がす

 徹底的にWIPを制限してオーバーヘッドをなくしたかった。ただこればっかりは組織の都合上という感じになってしまったが、悪いことばかりだったわけではなく余計なタスクすらもチーム間で共有し、問題解決できるようなチームの形成を促進するのに一役買っていた感じがする。

チームメンバーの固定化

 というかプロジェクトが終わると解散になる大きな波には勝てなかった・・・

自身の心理的安全性の確保

今までの当たり前だったことから違うこと始めちゃったからしょうがないよね\(^o^)/
ただ一緒に悩んでくれる仲間ができたことはサイコーでした!

心がけていたこと

  • お互いのリスペクト、共感
  • ゴールの共通認識
  • 多様性を尊重、否定しない
  • サーバントリーダーシップ
  • 孤独を感じさせない、一体感
  • ミーティングの際の安全な場づくり、ファシリテート
  • とにかく楽しむ

終わりに

 みんながモチベーション高くイキイキと働いていて最後のあたりはほったらかしだったが、それでもプロジェクト成功させていた。色々と試行錯誤の毎日だったが、幾つか成功事例を残せたことはとても良かったし自信にもなった。組織文化を変えていくのはとっても大変だししんどいけど何より同じ志を持って一緒にやっていける仲間ができたことはとても嬉しかった。
 同じプロジェクトというのは二度とないし、顧客や市場の要望も技術自体もどんどん複雑に変化していく。そこを柔軟に、高速に変化に学習できることこそエンジニアリングで一番大事なことだと思っている。願わくばこういった文化が少しずつ浸透すればなーということで戦いの日々は続く。


追記(2018/03/18)

なんか伸びてたのではてブのコメント拾ってみようかと。

全員の能力が平準でないと成り立たないのでは。

どういうケースで成り立たないと想定しているか分からなかったのですが、
チームメンバーはスキルセット等含めてバラバラでした。
「この領域はAさんがやる」というのが今までのスタイルだったのですが、今回はそれをしてないです。
開発チームの流れは以下のような感じでした。

  1. ユーザーに届ける価値(ユーザーストーリー)を全員でタスクに落とし込む
  2. 全員でタスクにかかる時間を見積もる
  3. プロジェクトに関係ない、それぞれの差込がどれだけ発生しそうか共有
  4. 何を誰がいつどこまでやるか決める
  5. 開発着手

1の段階で大まかな設計方針は共有できているものの、2の段階でスキルレベルに差があるので見積もりの時間も当然変わります。で、どのようにタスクを振り分けるかもチームで合意してもらいました。大体以下の3パターンの方針だったと思います。

  • スキルレベルが高い人が実施し、代わりに他のタスクをスキルレベルが低い人がやる
  • スキルレベルが低い人がチャレンジしてみる
  • (余裕があるときは)できる人とできない人で組んでペアプロをする

「ビジョンを共有」=>「失敗したときの責任が自分に来る」の流れがよくわからない。たぶんゆるふわな共感ではなく、ビジョンに貢献しない成果は評価しない等の話をしたのでは。そこをもっと詳しく書いてほしい

「失敗したときの責任が自分に来る」と言っていたメンバーに関しては実はビジョンの共感自体はすんなり行っていました。但し在席期間が長く歴史的な背景から以下のような主張でした。

  • 言いたいことは分かるけど俺にメリットがない
  • プロジェクトを成功させることに対して責任持っちゃうと失敗したときに(自分が)責任問われてろくなことにならない。そういうやついっぱい見てきた
  • プロジェクトの成功失敗ではなく、ただタスクををこなす事だけが俺の仕事だし、それで評価されてきた
  • プロジェクトがうまくいくかどうかはマネージャーの仕事でしょ?俺関係ないし

 正直なところこう言い出してる段階で他のメンバーのモチベーションを下げるのが明白だったので外れてもらいたかったんですが、自分は人事評価に対する決定権やプロジェクトメンバーの決定権がなく、やむなく続行という形になってしまいました。

同じような状況なんだけど、メンバーの雇用形態は皆同じ(正社員)? 雇用形態違うとどこかで軋轢出ないかな?と思った

 雇用形態はバラバラでしたが、派遣で来ていただいているメンバーに恵まれていたので特にそこは問題ありませんでした。但し、軋轢という意味では先述した通りモチベーション高いメンバーと長くからいるメンバー間で発生していたので雇用形態というよりもそれぞれの内面に関わってくるのではないかと思っています(確率は高そうですが・・・)。

161
139
4

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
161
139