LANGUAGE
  • トップ
  • LOGLYブログ
  • トップダウンからチームドリブンへ ~組織の成長期におけるエンジニアのチームビルディングについて~

LOGLY more!

ログリーのことを、もっと。ログリーとつながるメディア

トップダウンからチームドリブンへ ~組織の成長期におけるエンジニアのチームビルディングについて~

2021年3月19日
和田拓真
CULTURE

こんにちは!
lift事業部 開発グループ 副部長の和田です。

3月9日に私の所属するlift事業部開発グループが、「モチベーションチームアワード2021」を受賞いたしました。今回の記事では、私がテックカンパニーへの原点回帰を体現するために当グループで実践した「チームビルディング」における大事な要素についてご紹介したいと思います。

開発グループはどんな組織?

まずは、lift事業部 開発グループについてご紹介します。

私たちは、メインプロダクトである「LOGLY lift」に関わる広告配信ロジックの改善・新規機能の開発などを担うグループになります。アジャイル開発手法である「スクラム開発」を実践しており、少数精鋭のチームのためフロントエンドからインフラまで一丸となって行っています。

2019年10月結成当初はなんと「ログリー史上、最も組織エンゲージメントが低いチーム」としてスタートし、それが1年半が経った今では「社内で一番エンゲージメントが高いチーム」と、誰も予想できないほどの変化を遂げています。

チームビルディングで悩まれているエンジニアの皆さまにとって、少しでも参考になれば幸いです。

最低だったエンゲージメントから目を背けず向き合おうと決めた訳

少し遡って、開発グループが組織される前段からお話します。

当社のエンジニア組織はもともと、エンジニア全員を一つの部署へ配属して、各プロダクトのタスクへ割り当てる体制をとっていました。当時は、市場での競争優位性を手に入れるため、タスクや研究開発よりも機能開発・改善といったビジネスサイドからの要求が増えていました。メンバーそれぞれのタスクの守備範囲も広く、次から次へと機能を足して肥大化したシステムに対して改修を加えることは、エンジニアたちにとって大きな負荷がかかる環境だったと言えます。

その環境を改善するためには多くのリソースを投じる必要があったことに加えて、組織の成長に伴い人数も増えていたことから、チームのマネジメントが上手く行き届いていない状況でした。そのため「この状況を変えたい」というメンバーの願いもなかなか実現させることは難しかったのです。結果として、組織へのエンゲージメントのランクがDD(一番下のランク)まで下がるに至りました。

2019年10月、それらの課題を解決する抜本的な施策を実施しました。それは、一部のエンジニアメンバーを各事業部門へ社内出向する形でエンジニア組織を複数に分割することでした。そしてlift事業部への出向者で組織したチームが開発グループで、そのチームのマネージャーとして私がアサインされたという流れです。

会社も “エンジニアが働きがいのある環境を整えたい” 、チームメンバーも “世の中に良いプロダクトを発信したい” という想いがありました。会社もチームメンバーも目指すミッションは同じなのです。そこで、アサインされた私の役割として「エンゲージメントが低いチーム状況としっかり向き合い、まずは組織の結節点の機能を正常にしよう。」と決意しました。

実際に取り組んだこと

そのようなチームのモチベーション状況から、私が実際に行ったことををご紹介します。大きく以下の3つを意識して取り組みました。

  1. 小さな成功体験を積み重ねる
  2. チーム全体での意識統一
  3. メンバーの背中を押し続ける

1.小さな成功体験を積み重ねる

チーム内の「何も変わらないのでは?」という組織への思い込みをなくしたいと考え、序盤ではメンバーに「組織は自分たちの力で変えることができる」という体験を積んでもらうことに注力しました。

チーム発足後、間もなく実施したオフサイトミーティングでは、各々が抱えている課題の整理から行ったのですが、切実な悩みや想いを本音で打ち明けてくれた事を覚えています…。それはチームメンバーの全員が “ログリーで良いプロダクトを作りたい!” という気持ちの表れであったとも感じ取れました。

当時のオフサイトMTGの様子

その日は、大量に挙がった課題を自分たちの意見にすべく一日かけてディスカッションをして吟味していきましたが、メンバーの痛みを知ると同時に私も終始お腹が痛かった記憶しかありません…(笑)
最終的には絞った課題からネクストアクションを設定して、その日のオフサイトミーティングを終了しました。

翌日以降はアクションプランを実行に移して、小さいことから実現させていったのですが、その結果、「組織を自分たちで変える」という小さな成功体験とともに「当事者意識」がチームの中で生まれ、徐々に期待と満足の差を埋めていくことができるようになりました。

2.チーム全体での意識統一

小さな成功体験を積むことで、自信が生まれたチームは次のフェーズへ移りました。
それがチーム全体での “意識統一” です。
ここで取り組んだことは「標語の設定」でした。

前述した組織課題の中には「ビジネスサイドとの距離感」がありました。
例として、「コミュニケーション量の少なさ」が挙げられます。これまでは組織が分かれていたため、ビジネスサイドからの開発要望がエンジニアの手元に届くまでに両部門長の承認を経ており、直接コミュニケーションをとる機会は多くありませんでした。
その結果、”本来解決したい課題が欠落した機能開発” の要望だけが開発現場へ到達。さらに、リリース後もその機能のフィードバックを得るコミュニケーション設計もないので、結局課題が解決されたのかは多くの場合において不明だったのです。

四半期ごとに開催されるようになったオフサイトMTGで、私たちはこの「ビジネスサイドとの距離感」にフォーカスして、アクションプランの設定だけでなく、以下の標語も設定しました。

「我々もビジネス側である」

各々が意識の中でもっていた課題を、標語という見える状態にすることで、単にエンジニアリング視点だけの課題を考えるのではなく、事業部の一員としてビジネスサイドで生じている課題にも当事者意識を持って解決していくというマインドに見事に切り替わりました。

実際の行動としても、ビジネスサイドのMTGにも欠かさず参加して現場の課題をヒアリングすることで、ユーザー目線で気の利いた修正を行ったり、そうやってリリースした機能のフィードバックをもらって改善を重ねていたりと良い循環が生まれています。


事業部の全体会議にて実際に共有したスライド

3.メンバーの背中を押し続ける

チームの行動面以外でも、マネージャーの立場として意識していたことがあります。それは「メンバーの背中を押し続ける」ことでした。

先述した「小さな成功体験を積み重ねる」と「チームで意識を統一する」という行動は、実はそれほどすんなりと進んだわけではありません。これまでは自分たちが置かれていた環境のため行動を控えていたメンバーたち。そんなメンバーたちが、自発的に行動を起こすようになるには、”自分たちの手で変えることができる” という手応えを掴んでもらう必要がありました。その小さな成功体験を積み重ねるために、私は一人ひとりに可能な限り向き合って話をすることから始めました。

話していく中で、課題や実現したいことの種が見えてきたら一緒に具体化をする。そして、アクションに移せるように根回ししたり機会をつくったりと、その行動が成功するためにとにかくサポートしていました。

しばらくすると、私からヒアリングする “単一方向の関係” から、メンバーからやりたいことを相談してもらえる “双方向の関係” に変化していて、当時とても嬉しかったことを覚えています。

改めて自分の行動を思い返すと、リーダーである人は「まず相手に奉仕し、その後相手を導くものである」というリーダーシップ哲学であるサーバント・リーダーシップを意識した行動をとっていました。

私はこの意識こそが「チームビルディングを成功させる」最も大事な要素だと思っています。

いくつもの失敗の果に…

実はいくつも失敗したこともあるのですが、特に失敗してしまったことに「個別案件への介入」が挙げられます。

就任当初、エンジニアリングについて他ビジネスメンバーよりも多少理解しているという思い込みと、私自身もビジネスサイドの人間として事業についても深く理解している自負がありました。そういった思い込みから、現場に入ってエンジニアサイドとビジネスサイドの両者にとって良き通訳者になることで、垣根を取り払おうと張り切っていました。

実際に入ってみた案件では、ついつい口を挟む形となってしまい最終的にコミュニケーションを阻害する結果に…。 両者の距離を近づけるべきところを、自分が挟まることでワンクション入ってしまい本来の目的から外れてしまっていてもうダメダメでした。こうして勘違いから始まった「良き通訳者作戦」は早々に頓挫したのです。

この失敗から自分に求められている役割を考え直し、自分をプレイヤーとして考えるのは止めて、前述のサーバント・リーダーシップを意識した「メンバー主体のチーム作り」に舵を切ることにしました。失敗から学びを得て、行動を修正した結果が今の状態に繋がっていると思えば良い経験だったと思います(笑)

最後に

いかがでしたでしょうか?

実践したことはどれも単純なことで、突飛なことや高いテクニックが求められることはありません。それでも愚直に泥臭く繰り返すことで、少しずつチームの雰囲気を変えていくことを証明した1年半でした。

最後に、重要な話を1つ付け加えます。それは、組織の問題はその “仕組み”にあったということです。

当社エンジニアメンバーは、元々会社や自身の成長に意欲的で責任感も強いメンバーが集まっています。それが組織の中で見えづらくなっていただけで、今は各メンバーが主体的にその資質を発揮しています。

これについては、高度な技術力を有していることに加え、HRTT「謙虚(Humility)」「尊敬(Respect)」「信頼(Trust)」「Thanks(感謝)」を軸にした採用活動を行っていることが組織のベースとしてあるためです。

組織は生き物と同じく、刻々と変化してきます。これからまた、良い時期も悪い時期も訪れることでしょう。そしてこの記事で挙げた方法だけでは対応できない場面もあると思います。その時はまたチーム一丸となって乗り越えてられるよう、努力を惜しまむことなくチャレンジしていきたいと思います。

今後もこのような形で社内外にマネジメントでの知見を共有させていただきますので、その際も最後まで読んでいただけますと幸いです。

著者紹介
和田拓真
入社当初は営業職での採用だったものの、数年が経って気がつけばエンジニアチームのマネジメント担当に。最近は趣味のよさこいが出来ず、お家で美味しいコーヒーを淹れることが細やかな幸せ。