はじめに

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

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

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

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

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

やったこと

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

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

具体的にやったこと

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

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

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

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

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

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

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

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

その他

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

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

できなかったこと

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

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

チームメンバーの固定化

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

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

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

心がけていたこと

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

終わりに

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