エンジニアが働きやすく成果に繋がる環境を作るための取り組み

こんにちは、CTO室の立花です。 DeNA は様々な事業を展開しており、各事業部にエンジニアが所属しています。エンジニアリングに関する部門固有の課題に対して部門状況にあわせて各部門で対応しています。一方、部門をまたいだ全社に影響するような課題や要望も存在します。これらに対して全社横断チームであるCTO室がどんな取り組みを行ったかを紹介します。

チームの紹介

CTO室は”エンジニアが働きやすく成果につながる環境づくり”をミッションとした組織で、エンジニア出身のメンバーで構成されたチームです。DeNAのエンジニアが大切にしたい価値観であるDeNA Engineer Quality(DEQ)の浸透、エンジニアリングマネージャーの支援、エンジニアリングに関連する研修の実施、対外的な技術ブランディング、エンジニア採用の支援など、部門固有というより全社横断的な取り組みを中心に活動しています。

何の話？

エンジニア向けのアンケートやヒアリングを実施する中で、各種申請フローが煩雑でなんとかしてほしい、PCや開発ツールで問題があってなんとかしてほしいなど、とりあえず今困っている目の前の個別課題に対応してほしいというニーズが一定存在することがわかりました。横断的で中長期的な取り組みだけではなく、短期的な個別課題に対応することで、エンジニアリングに集中できる環境を作ることも重要と考えました。

これらの課題に対応するため、全社のエンジニアリングにまつわる課題や要望を管理するご意見箱 (誰でも登録/閲覧可能な Github Issues)と、エンジニアと会話しながらともに解決するための コミュニケーションチャンネル (public な slackチャンネル)を用意しました。これらを活用しながら、どのような点に工夫しながら課題解決を進めたのかについて紹介します。

想定読者

この記事は、

全社横断的な立ち位置であったり部内の複数のエンジニアリング部門を管理する立ち位置で
エンジニアから上がってくる課題や要望に取り組んでいるものの課題がうまく吸い上げられなかったり、課題解決に協力がえられなかったり、成果物が受け入れられなかったり活用されなかったといったことで悩んでいる
システム部門の上位者やその担当者の方

を想定読者として書きました。

案件例

具体的に取り組んだ、もしくは取り組んでいる案件をいくつか紹介します。

対外的なアウトプット活動を改善するもの
- OSS 公開時の煩雑なルールの見直し
- 離職後も OSS のメンテナを引き継ぎたい
技術的な学びや相談のしやすさを改善するもの
- 特定の技術領域に精通した人に気軽に相談したい
- 全社の技術知見を他部門で活用したい
- 各部門の勉強会の参加ハードルが高い
- 他の事業部やチームの人とのつながりが欲しい
社内ツールの利用申請を改善するもの
- ソフトウェアの利用時の煩雑なルールの見直し
- SaaS や有償ソフトの利用申請における負担を減らしたい
社内ツールの品質を改善するもの
- 全社横断で利用しているツールのバージョンを上げたい
- リースPCの品質を上げたい
- ある開発者向けツールが macOS Big Sur で動かない
社内制度を改善するもの
- 電子書籍の経費精算対応

これ以外にもご意見箱にはたくさんの課題や要望が登録されています。いろんな種類のものがありますが、それぞれを見ていくと以下のことがわかります。

サクッとできそうなものから重そうなものまで大小様々。なかには声を上げるのも面倒で、それだったらしかたなく我慢して現状を受け入れるしかないというものもあります。これらの課題は、塵も積もれば山となり結果として”エンジニアを働きにくく成果につながらない環境”にしてしまうものです。

ご意見箱に登録されたものは、そもそも何がどの程度問題なのか？解決すべき課題は何なのか？どういった解決法が望ましいのか？が明確ではないことが多く判断が難しいです。より多くのエンジニアから多面的に情報をあつめることができれば、うまく進められそうです。声が集まりやすい、共感する人が能動的に関われる環境づくりが重要だと考えました。

我々のチーム単体では解決することが難しく、情報システムチーム、法務やセキュリティチームなどの他部門にまたがる課題や要望が多い。これらの部門へ現場の声を届け課題感を共有して共に課題解決に取り組めるよう、他部門との協力体制の構築が重要となります。

対応

声が集まりやすい、共感する人が能動的に関われる環境をつくるために、全社のエンジニアリングにまつわる課題や要望を可視化してみんなで良くしてく場として GitHub Issues をつかったご意見箱を用意しました。誰でも簡単に起票することができます。また、課題解決のプロセスにおいて、エンジニアと会話しながら共に課題解決を進めるためのコミュニケーションチャンネル(public な slack チャンネル)を用意しました。参加者は気軽に提案や相談をすることができます。ご意見箱とコミュニケーションチャンネルを土台として、何を大切にしながら課題解決を進めたかを紹介します。

声が集まり、協力的に解決できる

初期はアウトプットを重視する

最初から勝手に課題が集まってくることはありません。以前、ご意見箱に登録しておいたものが解決された、ここに投げておけばまた解決してくれるかもしれない、と思ってもらうことで、課題や要望が自然と集まってくる状況を作っていきます。そのために短期的には、課題や要望を集めること、それに対してクイックにアウトプットしていくことが大切と考えました。

初期は自らの足で課題や要望を積極的に集めに行きました。例えば、全社エンジニア向けのアンケートを実施して、課題や要望を直接的に吸い上げて、ご意見箱に登録していきました。記載内容だけでは十分に判断がつかないものは、課題解決のスピードを上げるために、個別のヒアリングを実施して、課題解決の解像度を上げていきました。ヒアリングの最後に、共に解決する場としてのご意見箱やコミュニケーションチャンネルを紹介するなどして、地道に認知を広げてもらえるよう活動を積み重ねました。

ご意見ボックスに集まった課題に対して、時間をかけて大きな課題を解決するのではなく、短期間でクイックに解決できるものとして、他部門の協力がなくとも単独で課題解決できるものを選別して優先的に対応しました。例えば以下の案件は、CTO室単独で調整してクイックに対応することができました。

特定の技術領域に精通した人に気軽に相談したい
全社の技術知見を他部門で活用したい
各部門の勉強会の参加ハードルが高い
他の事業部やチームの人とのつながりが欲しい

プロセスで関係を構築する

声が集まりやすい、共感する人が能動的に関われる環境を作るために、社内のエンジニアが相談しやすく信頼してくれるような関係を構築することが大切です。課題解決のプロセスで関係を構築できると考え、以下のようなチームの行動指針を定めました。

エンジニアの声に真摯に耳を傾け、爆速返信を目指す
- 思い込みで行動するのではなく、傾聴することで、また相談しようと思ってもらえます。時間をかけずに、まずは反応を示す。最優先で対応してくれるという安心感をあたえられます。
課題を解決できるときもできないときも、理由を包み隠さず公開する
- やり取りはすべてオープンな場で行います。テーマに興味があるメンバーの参加を促します。要望を聞いておいて、放置したり曖昧にしてしまうと信頼を損ねます。要望に答えられなくとも理由を公開します。
サポートしてくれる人への感謝を忘れず、成果を周りに示す
- 成果を示すことで、何かあったときにまた相談してくれます。ご意見箱に声を届けた人がいて、課題解決に協力してくれた人がいることを忘れず、独りよがりにならず感謝を示すことで、また協力しようと思ってもらえます。

ハブとなる

案件例でみたように、課題や要望は単独で対応できるものは少なく、複数部門で協力的に解決すべきものが多いです。

例えば、これらは法的な観点を含むため法務チームとの協力が必要で

OSS 公開時の煩雑なルールの見直し
離職後も OSS のメンテナを引き継ぎたい

これらはセキュリティの観点を含むためセキュリティチームとの協力が必要で

ソフトウェアの利用時の煩雑なルールの見直し
SaaS や有償ソフトの利用申請における負担を減らしたい

これらは社内ツールや端末を管理する社内情報システムチームとの協力が必要で

全社横断で利用しているツールのバージョンを上げたい
リースPCの品質を上げたい
ある開発者向けツールが macOS Big Sur で動かない

これは社内制度や経費精算に関わるもので、HRや経理チームとの協力が必要です。

電子書籍の経費精算対応

エンジニアにとっては、そもそもどの部門に相談すればよいのか切り分けは難しく、また複数部門にまたがって調整していくのは至難の業です。そんなところに時間を使ってほしいわけではありません。我々の役割としては、現場エンジニアの代表として課題や要望を十分に理解して声を届けること、最適な解決策をコーディネートしていくことです。

また、協力部門からすると、課題や要望が集約されることで対応の優先度が判断しやすくなったり、エンジニ観点で客観的なアドバイスがえられるので、協力体制を構築することにメリットを感じてもらいやすいです。

協力体制を構築するための取り組みとしては、それぞれの部門と

定期的に課題や要望を確認したり対応を相談する場として、定例会の実施
タイムリーに相談できるslackチャンネルの活用

を行いました。現在は、社内情報システム、人事、法務、セキュリティのチームとアジェンダベースで実施しています。協力体制を構築することで、課題解決がスピーディーに進められる様になったと感じています。今後は状況を見ながら、他部門とも新たな取り組みを開始したいと考えています。

認知を広げる

声が集まりやすい、共感する人が能動的に関われる環境を作るために、社内のエンジニアに我々の活動を知ってもらう必要があります。

半期に一度、エンジニア向けのアンケートを実施しています。その中で我々の取り組みの認知度に関する設問があります。初回のアンケート結果から、一部の層には取り組みを知ってもらえているが、大多数のエンジニアは認知していなということがわかりました。定性コメントでは、何をしているのかわからない、活動が見えないといった声がありました。

まずはコミュニケーションチャンネルを使って、週毎の活動サマリーを届けることからはじめました。小さなネタから大き目のトピックまで、出せるものは出すというスタンスで発信しました。発信に対して徐々にイイねが増えたりコメントがもらえるようになっていきました。

また、ストック情報として Quarter 単位の活動サマリーを社内 Wiki に蓄積していく取り組みもはじめました。取り組みをまとめて網羅的に整理しておくことで、普段発信しにくいことも紹介することができ、なるほどそんな事もやっているのかと、活動に対する理解の促進につながりました。

第二回目のアンケート結果から、我々の活動の認知度スコアは初回から改善したことが確認できました。それでも大多数が認知しているとは言えず、次の手が必要だと考えています。

まとめ

エンジニアが働きやすく成果につながる環境づくりを行うためには、横断的で中長期的な取り組みだけではなく、短期的な個別課題に対応する必要があること、そのために、全社のエンジニアリングにまつわる課題や要望を集め管理するご意見箱と、エンジニアと会話しながら共に課題解決を進めるためのコミュニケーションチャンネルを用意した上で、何を大切にしながら課題解決を進めたかを紹介しました。

振り返ると、まあそりゃそうだよねと思えることであり、課題に向き合って実直に進めることが重要だと再認識しました。同様の活動をされている方にとって何か参考になることがあれば幸いです。今後も定期的にCTO室の取り組みを発信していきたいと思います。

この記事を読んで「面白かった」「学びがあった」と思っていただけた方、よろしければ Twitter や facebook、はてなブックマークにてコメントをお願いします！

また DeNA 公式 Twitter アカウント @DeNAxTech では、 Blog記事だけでなく色々な勉強会での登壇資料も発信してます。ぜひフォローして下さい！

Follow @DeNAxTech