メリークリスマスイヴ！
この記事は Engineering Manager Advent Calendar 2018 の24日目の記事です。
私 (@dskst9) が3年前、アスクルという会社のエンジニアリングチームにJoinしてから、エンジニアリング組織の文化がどのように作られていったのかというお話です。
これは、私自身のアクションと、エンジニアリングチームの一人ひとりがアクションしたことを織り交ぜて書いています。誰かがアクションし続けることで、会社は変わり続けることができるということを感じてもらえると幸いです。
この記事が伝えたいこと
- どんな会社でも変えることができる
- 組織を変えたいなら自分自身でアクションする
- 組織がアクションを続けると習慣となりそれが文化になる
そもそもどんな会社
むかし
3年前は、全社員比でエンジニアが 1% もいない会社でした。(5年前は0人…!!)
エンジニアリング組織の文化どころか、「エンジニア？何それ、おいしいの？」という状態。「外注すればいいじゃん」「本当に必要なの」というような感じでした。
（吉幾三がエンジニアだったら）こんな歌が聞こえてきそうです。
ハァ Gitも無ェ チャットも無ェ
Macもまったく使って無ェ
Wikiも無ェ ツールが無ェ
Excel毎日ごーりごり
そこへ、エンジニアが20名ほど Join(私も含む) して、組織が大きく変わっていくことになりました。
いま
さきほどの歌のようなことはなくなり、そこそこモダンな環境に変わったと思います。 何よりも組織としてエンジニアの立場が認められて、エンジニア側から組織に対して発信し、受け入れられるようになりました。
そして、エンジニアリング組織の文化というのが少しずつできていることを感じています。
ふりかえる
どのようなフェーズでどんなことをやってきたか、タックマンモデルにはめてふりかえってみます。
タックマンモデル
心理学者 B.W. Tuckman が唱えたチームビルディング(組織進化)モデルです。
チームは形成されただけで機能し始めることはなく、チームは形成後、混乱を経て、期待通り機能するようになります。
各フェーズを「Forming」「Storming」「Norming」「Performing」「Adjourning」と呼び、下図のように表現されています。
Forming（形成期）
メンバーはお互いのことを知らない。また共通の目的等も分からず模索している状態。
3年前、20名ほどのエンジニアが Join した時期です。
当時はIT部門の1チームとしてエンジニアリングチームがありました。
20名程が短期間で入社したので、お互いを知らない、組織からも認知されていないというカオス状態でした。
この頃のエンジニアリングチームは、案件だけで繋がっていたような気がします。
- 社内でのエンジニアの認知度が低い、信頼されていない
- よって、エンジニアから組織への声が通らない
やったこと
社内のたくさんの人にエンジニアリングチームを信頼してもらうにはどうしたらいいのだろう？
まずは、社内の信頼を積むべくエンジニアリングチームとして案件へのコミットに全力を尽くしました。
内製エンジニアの形成期フェーズでは、案件で結果を出すことが一番でした。 目に見えてリリースが早くなることで、「エンジニアってすごいのかも」という認知が広がりました。
また、エンジニアリングチームを認知してもらうために、広報、法務、総務などの部門にも積極的に関わるようにしました。理由を作ってまで、とにかく話してみるということを続けました。
これは、影響の輪を広げて増やすということを考えていました。影響の輪の詳細は記事にまとめています。
dskst9.hatenablog.com
しかし、急に信頼されるということはなく、小さな信頼の積み重ねが次へと繋がっています。活動を1年くらい続けてやっと信頼が少し広がっていきました。
Storming（混乱期）
目的、各自の役割と責任等について意見を発するようになり対立が生まれる。
今から2年前、エンジニアリングチームができて1年が経つ頃です。
小さなエンジニアリングチームは部となり、何個かのチームが存在していました。
組織では少し認知が広がってきたところ、エンジニアリングチームの中は混乱期に突入していました。
- 各エンジニアリングチームが何をしているのかよくわからなかった
- 個人個人が何を思って何を目指しているのかわからなかった
やったこと
1on1 を始めたのはこの頃です。
上司とやり始めたことがきっかけで、そこから半年くらいかけて全エンジニアリングメンバーにまで広がりました。
同時期に Scrum を導入し始めました。
これは、モダンな開発を経験してみようという勢いで始めましたが、チームでの会話が増えたということはとても大きかったです。
1on1, Scrum など、個人個人の会話が増えたことにより、チームが何をしていて、個人が何をしているというのを理解したと思います。会話によって混乱期を乗り越えたのかなと。
また、この年からアイデアソン/ハッカソンを年1回やるようになり、今も恒例行事になっています。
失敗したことももちろんあります。
社内で小さな勉強会を開いたのですが、これが大失敗でした。
自分の想いだけで開催して、誰もついてこれずに1回で終了してしまいました、まさに混乱期（笑）
Norming（統一期）
行動規範が確立。他人の考え方を受容し、目的、役割期待等が一致しチーム内の関係性が安定する。
今から1年前、エンジニアリングチームができて2年が経つ頃です。
エンジニアリングチームとしてはお互いを知ることができて、チームとしてチャレンジしていこう空気になっていました。
- エンジニアリングチームとしてのアクションをやり始めた
- 他部門から信頼されの意見が通るようになった
やったこと
プロダクトともっと向き合うべく、 LeSS の導入がチャレンジングで面白かったです。
コンポーネントチームがフィーチャーチームになることで、エンジニアの技術領域も広がり、新しいコミュニケーションも生まれました。
しかし結果としては、フィーチャーチームを作りきれず、残念ながら LeSS チームは解散しました。
インセプションデッキ、ポストモーテムをして、プロジェクトとしっかり向かい合おうという取り組みもやりました。とくにインセプションデッキはプロジェクトの同じゴールを見ることができて、効果が大きかったように感じています。
個人的に一番嬉しかったことは、社内の勉強会を開催できたことです。（この時期になってリベンジできました）
今度はたくさんのエンジニアが参加してくれて、今では月1回の恒例行事になっています。
この時期から技術ブログを立ち上げる相談を広報などとはじめました。
Performing（機能期）
チームに結束力と一体感が生まれ、チームの力が目標達成に向けられる。
そして、今年です。
1年間いろいろとありましたが、エンジニアリングチームの影響の輪が大きく広がりました。
会社の中でもエンジニアリングチームが一目を置かれるようになっており、社内への技術的な提案や改善を推し進めることができるようになりました。エンジニアも外と交流するようになってきました。
- いろんな人からさまざまなアイデアやアクションが生まれた
- エンジニアリングチームが外へと踏み出した
やったこと/やっていること
びっくりしたことに、月1勉強会から派生して週1勉強会が自然発生しました。
混乱期の失敗を思うと、他のエンジニアから勉強会が生まれた瞬間は感無量でした。
さらにさらに、月1勉強会にエンジニア以外の他部門の人も参加してくれるようになりました…！
勉強会の他にも、会社の技術ブログが開きました。
たかがブログですが、開設し、更新を続けることというのはこの時期だからできたと感じています。
社外勉強会を自社で開催することもでき、とにかくアクションをし続けていました。
そしてこれから、
エンジニアバリューを作りビジョンを浸透しようとしたり、
OKR でプロダクトにフォーカスしようとしたり、
新しい挑戦を始めているところです。
文化を作るということ
「Forming」「Storming」「Norming」「Performing」とフェーズをなぞってきました。 「Forming」では存在しなかった習慣が、いま存在を感じて、この習慣こそが文化だと思っています。
文化は作れるものであり、作るのはそこにいる自分自身含めたみんなです。
アクションしたことがずっと続くことで習慣が生まれ、習慣が続くことでそれは文化になっていくと思っています。
おわり
文化を作っていくということも EM の大事な仕事ではないかと思っています。
これを意識すると、明日起きる誰かの小さなアクションが文化の芽となっていくことに気づくかもしれません。
おまけ
この軌跡をエモいストーリーにまとめて話したことがあるのでリンクしておきます。
