エンジニアリング統括室が担当する業務の分類

エンジニアリング統括室が担当する業務の分類

Clock Icon2022.06.02

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちわ。従業員体験( EX ) の向上がミッションのエンジニアリング統括室に所属しているてぃーびーです。
エンジニアリング統括室は6月に新メンバーを迎えました。新メンバー向けに私達がどんな種類の業務をしているか伝えつつ、全社・社外にも情報を共有してしまおう、と思い立ちました。

業務の分類

問題発見

どのような問題があるか発見する活動です。問題を発見するためのインプットとなる情報としては
  • マネージャーからの情報
  • 個別ヒアリングからの情報
  • 社内資料
  • 各種サーベイ
などがあります。将来的なところを考えると社員DBに紐づく定量、定性的な情報が増えるとそこもインプットになってくる想定です。

問題選定

発見した問題の中から、今優先して取り組むべき問題がどれなのかを判断する活動です。
判断は私達のチームだけでやるわけではなく、取り組む対象によって経営・人事・マネージャーなど必要な方々と連携しつつ行います。
ただ、すべての内容を毎回広い範囲で確認しているとスピードがでないので、部門内だけで問題ないと判断できる対象については部門内で完結します。部門長が全社の温度感を把握しているのもあって、その範囲で確認する必要があるかないかを判断してもらえる感じです。

問題定義

解決策を検討する前に、問題を定義する活動です。必要に応じてアンケートや、社員インタビューの実施などによって追加リサーチをします。ただ、調べてもすべてが明らかになるケースばかりではないと思うので、可能な範囲で前提が整ったらこの問題はどのようなものであるかを定義します。
このあたりは前回のエントリに問題定義の重要性をまとめました。

解決策の検討

問題を解決するための施策を検討する活動です。
この際にめぼしい解決施が思い当たらなければ、書籍・ウェブ・人などからのインプットも並行して実施します。

解決策の実施

解決策を実施する活動です。短期・単独で実施できるものから、長期で多数のステークホルダーを巻き込みプロジェクトマネージャーのような立ち位置で推進するものまで有りえます。

モニタリング

問題発見の材料として、解決施策の効果確認の基準として、組織の状態をモニタリングできるようにする活動です。
その他に追加する可能性があるものとしては、各従業員体験の質を確認する個別タイミングにおけるサーベイです。例えばオンボーディング・異動・評価制度などの質を確認するサーベイなどになります。

活動報告

エンジニアリング統括室の活動を伝える活動です。個別のインタビューやサーベイなど、エンジニアリング統括室の活動において各所の協力は欠かせません。協力を得続けるためにも、いただいた情報や協力をもとにどのような活動をして、どのような影響を与えているかを全社に知らせていきます。

オペレーション

エンジニアリング統括室で実施する施策は改善に向けて単発で実施するものもあれば、継続的に質を高めるための定期タスクがあります。
定期タスクは定期オペレーションを伴います。モニタリングも同様です。ある程度型化したあと、社内でオペレーション業務を委譲するケースもあります。
例えば、現在ラフに技術について話せる場として DevelopersLT という社内 LT 会を継続実施していますが、この実施にまつわるオペレーション業務があります。現状、エンジニアリング統括室以外にこの運用をお手伝いしてくださっている DevelopersLT スタッフの方々の協力を得て運営しています。いつもありがとうございます!

まとめ

開発関係者向けの従業員体験向上がミッションのエンジニアリング統括室において、どのような種類の業務が存在するかをまとめました。
全体として必要な項目としては、プロダクト開発で必要となるものに似ている気がします。
ちなみに、業務全体に関するふりかえりからの改善もありますが、業務分類とは毛色が違うかなと思って含めていません。

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.