EngOps、はじめました。 〜Engineering Operationsという職種について〜

何か月か前から、私の役割が「エンジニアリングマネージャー」みたいな役割に変わりました。
元々はPdM, PjM, プリセールスみたいな役割だったのですが。

ただ、実際に会社から求められていることを、顕在ニーズと潜在ニーズの両方から整理してみると、「これはEMに近いけれど、典型的なEMとは少し違うな」という感覚が強くなっていきました。
私の所属先は、正社員・業務委託を合わせて40人くらいの規模の会社です。この規模感だと、いわゆるEMが担うことの多い評価・育成のような領域は、そこまで強く求められません。人事や経営の目が比較的届きやすいからです。
その一方で、会社として強く必要になっていたのは、属人化した業務を減らし、再現可能な“型”を作っていくことでした。

意思決定のスピードが速いぶん、「何が決まったのか」「なぜそう決まったのか」が暗黙知になりやすい。すると、何のために何を作るのかが十分に整理されないまま開発が始まり、あとから手戻りが起きることもある。さらに、これからはAIを労働力として組織に組み込んでいく前提でも考えないといけない。そうなると、暗黙知に依存したままでは厳しくて、意思決定や運用の流れそのものを、会社として扱える形にしていく必要があります。
しかも、その必要性はエンジニアリング領域だけに閉じません。QAや運用の領域でも同じです。にもかかわらず、そこを横断的に整えていく役割は、これまであまり明確に存在していませんでした。
そう考えていくうちに、「これはEMっぽさはあるけれど、EMそのものではない仕事だな」という認識に至りました。
では、こういう仕事は何と呼べばいいのか。少し調べてみたところ、世の中にはそれに近い概念がすでにありました。Engineering Operations、略して EngOps です。
ただ、この職種、日本ではまだあまり一般的ではないようです。少なくともWeb上では情報がかなり少ない。一方で、海外ではDropboxやAsanaなどで実践例が紹介されています。

とはいえ、見つかる情報の多くは、生成AIがここまで普及する前のものだったり、大規模な企業の事例だったりします。なので、参考にしつつも、そのまま当てはめるのではなく、自分の会社や今の時代に合う形にアレンジしながら進めていくことになるだろうと思っています。
ということで、今後しばらく EngOps に関する投稿を書いていこうと思います。試行錯誤の中で分かってきたことや、やってみて見えてきた課題などを、少しずつ言葉にしていくつもりです。
気が向いたら読んでもらえると嬉しいです！