「心構え」を策定して組織の分断に立ち向かった話

簡単な自己紹介

こんにちは。現在、合同会社EXNOA所属でフロントエンドエンジニアをしている坂本です。今でこそフロントエンドエンジニアをやっていますが、これまで下記のようなことをやってきました。
・スマホアプリの開発ディレクション
・合同会社DMM.comの横断組織でUXデザイン導入支援
・ブロックチェーン関連の新規事業のプロダクトオーナー
・職能組織のリーダー業務（スクラムマスター的なロール兼務）
noteにはこれまでやってきたことを振り返りつつ、良かった点や反省点をアウトプットしていこうと思います...!
というわけで本題です。

背景

現在主に国内向けに「DMM GAMES」というプラットフォームがあるのですが、グローバルなプラットフォームを新しく構築しようという意欲的なプロジェクトが発足しました。まずは職能ごとにリーダーが集まり、これまでの課題感を踏まえて、Spotifyのスケーリングアジャイルを参考に「ドメインによって分割された複数の機能横断的なチームによる開発」を指向して開発体制を検討することになります（いろいろあって途中で残念な結果になってしまいましたが、個人的にも組織的にも学びがありました）

私もフロントエンドエンジニアのリーダーとして開発体制の検討に参加し、ドメイン別の機能横断チームにそれぞれフロントエンドエンジニアが数名ずつ所属するという形を採用しました。フロントエンド領域の課題はギルド的な職能軸の繋がりで解決していく形になります。

さて、プロジェクト当初からわかっていたことですが、フロントエンドエンジニアの数が全く足りない...!（チームを固定して専任にしたかったため）
そこで、急遽追加で10数人の増員をすることになりました。

プロジェクト発足当初の課題感

まず最初に「いきなりこんな増員してうまくやれるかなあ...」という心配はありました。複数の機能横断チームに分割した組織体制, 様々なバックボーンを持ったメンバーの増員....たぶんコミュニケーションバグが発生するだろうな。どうしたもんかなと。
※ タックマンモデルの形成期から機能期に至るまでに価値観がぶつかりあう過程は当然必要だと思うのですが、ある程度方向性を揃えることでチームビルディングをサポートしたいと思っていたのですね

「心構え」を策定し、メンバーに共有

そんな時、同僚の@inoinoさんが「デザイナーの心構え」なるものを策定していました。また、ほぼ同じタイミングで松本CTOが心理的安全性とコミュニケーションに関するポエムを共有してくれていました。
※ そんな@inoinoさんは合同会社DMM.comにかつて存在したUX部の元上司で、エモい記事に定評があります。是非ご一読ください。
※ DMM Tech Visionには重要なValueとしてMotivativeを掲げています。

両方を参考に個人的な思いも踏まえつつ策定したのが下記の「フロントエンドエンジニアの心構え」になります。

フロントエンドエンジニアの心構え

1. 仕事に対して主体的な姿勢を持つ
・やるべきことを自分で見つけようとする
・わからないところはメンバーに相談する
・メンバーが困っていたら助ける
・議題に対して自分の意見を伝える
・批評だけではなく、率先して行動する

2.相手を尊敬し、信頼し、謙虚な姿勢を持つ
・相手のコンテキストを確認してから意見を伝える
・相手の失敗や思い通りにやってくれないことに対して、必要以上に悪意を見出さない
・人によっては萎縮したり不快に感じるので、不必要に強い言葉を使わない

3.決定事項について同意できなくてもコミットしよう
・自分の意見を伝えたうえで、議論して決まったことについては同意できなくても全力でコミットしよう（コミットしないと組織として目標を達成できなくなるので）

リーダーとしての個人的な思い

>1. 仕事に対して主体的な姿勢を持つ
上記に関してはほとんど心配していませんでしたが、新規メンバーがチームメンバーに質問しやすくなったり、チームの自己管理を促すことを意図して記載しました。

>2.相手を尊敬し、信頼し、謙虚な姿勢を持つ
コミュニケーションバグの発生は「相手のコンテキストを理解していない状態で悪意を見出してしまう」というトラップに起因することが多いなと思っています。複数の機能横断チームに分かれた開発体制では相手のコンテキストが見えづらくなってしまうことが予想されたためトラップに引っかからないように具体例（長いので割愛）と共に記載しました。
また、理解していたとしても「伝え方がキツイ」と、心理的安全性が失われてしまいます。「チームの生産性」を重視して欲しかったため伝え方にも配慮しようという項目を記載しました。

3.決定事項について同意できなくてもコミットしよう
これが一番伝えたいことでした。組織が分割され、プロジェクトに関わるメンバーが多くなると、相対的に自身の意見が採用される可能性が低くなってしまうと思います。ただ、意見が異なって納得できないから従えませんでは組織としては何も達成できなくなってしまいます。リーダーとしてプロジェクトの全体方針に関する意思決定プロセスに現場のフィードバックをいれる機会は設けます、と。その上で議論して納得できなかったとしても組織としてのゴールを達成するために決定事項にはコミットするという姿勢を持って欲しいという思いを記載しました。

振り返り

メンバーからの反応
既存メンバーに共有した際の反応はそれなりに良いものでした。複数のメンバーからポジティブなフィードバックをもらえて正直ホッとしたのを覚えていますw 

必要なタイミングで引用するという使い方
とはいえ、こういった類いのものは「ほぼ確実に伝わらないし、すぐに忘れる」ものですよね。個人的には「必要なタイミングで引用する」という使い方が良いのではと思っていました。実際にコミュニケーションバグの匂いを感じたときに心構えを引用することで、フロントエンジニアとしてどうあるべきかという観点からブレない話し合いができたかなと。

メンバーを巻き込むバランス感覚が大事
一方で、完全に浸透していたかというとそうではなかったなという感覚もあります。定期的に内容について各チームメンバーと振り返ってもよかったかもしれません。また、今回は急遽増員前の立ち上げ期だったということもあり、自分が一人で叩きを作成しましたが、自分に余裕があればもう少しメンバーを巻き込む度合いを高めるというのも良さそうです（そのほうが自分ごとになりますしね）

職能軸ではなくプロジェクト全体として策定してもよかった
「フロントエンドエンジニアの心構え」の内容は別にフロントエンドエンジニアという職能に依存したものではありません。よく言えば「自身がコントロールできる範囲に絞った」、悪く言えば「職能に引っ張られた」という感じでスコープを絞って策定しました。他職能のリーダー層とプロジェクトの開発体制や全体方針について検討する過程で、フロントエンドエンジニア内で足元が固まってからそういった話も提案できたなと改めて思いました。

まとめ

複数の機能横断チームに分かれた組織で「心構え」を策定して分断に立ち向かったよという話でした。策定することで分断に起因するコミュニケーションバグを少しは減らせたかなと思います（自分も気を抜くとトラップに引っかかるのでよく見返して反省していました汗）