ログラスのxOpsを支えたい経営自動化部の今まで

この記事は弊社エンジニア加賀谷が投稿した記事になります。

目次

1. はじめに
2. 経営自動化部とは
3. 経営自動化部で推進したいこと
4. 経営自動化部としての心構え
5. 1. とりあえず早く行きたいので一人で進む
   2. YAGNI(You Aren't Gonna Need It)
   3. DRY(Don't Repeat Yourself)
   4. Write Automate Every Day
   5. 不満の閾値を下げる
5. 具体的な事例
6. 1. Notion DBを活用したリリース内容通知
   2. Zendeskへの問い合わせ集約
   3. 社内問い合わせワークフロー
6. まとめ

はじめに

ログラスでソフトウェアエンジニアをしている加賀谷です。
新卒で入社したヤフー株式会社でID連携システムの開発に携わり、その後2022年4月に株式会社ログラスに入社。現在は開発組織の横断課題解決に取り組むチームに所属しています。

たまにTwitterで名前が登場していますが、ログラスには経営自動化部なる部活が存在します。

今まで社内でもしれっと活動始めていましたが、本格的に活動を始めてから2ヶ月経過したこともあり、自分自身の振り返りも兼ねて経営自動化部について書いてみます。

経営自動化部とは

当時のミッションである「テクノロジーで、経営をアップデートする。」に合わせて、社内の業務を自動化する部活として2022年8月に誕生しました。

ただこのタイミングでは、特に活動は進みませんでした。
自動車部と勘違いする社員も出る始末です。

経営自動化部の活動はなくても、業務の中での必要な自動化は普通に行われていました。
しかし個人的な観測範囲・認識ですが、多くの場合エンジニア組織に閉じていたり、エンジニア組織の中でも細かな所も含めて自動化したい箇所が色々ある印象でした。

そして昨年の11月に、新設された開発組織の横断課題の解決をミッションとするチームに移り、特に生産性改善について考える中で、開発組織以外のソフトウェアエンジニアリングのアプローチで生産性を上げられる領域の存在を意識することが多くなりました。
トイル(サービスの提供に欠かせない作業の中で、自動化が可能であるにも関わらず手作業で行われているもの)に苦しむのはエンジニアに限らず、社員比率と自動化スキルを持っているのは比較的エンジニアの方が多い事実を考えても、むしろプロダクト開発周辺に閉じず、様々な組織・領域の運用に対してアプローチする方が適用範囲が広がります。

経営自動化部で推進したいこと

経営自動化部を通じて推進したいと思っているのはxOpsです。
xOps自体の紹介は簡素にしますが、個人的な認識を書くと以下の通りです。

• プロダクト開発だけでなく、あらゆるオペレーションにおいてDevOpsのアプローチで業務プロセスの効率化を図る
  DevOps, DesignOps, ProductOps, MLOps, SalesOps, CSOps、MarkeOps, HROpsなどなど
• 目的は様々な組織・部門における運用領域に向き合い組織全体のスループットを向上させる、優れた組織を作る

xOpsに関してはぜひ以下のスライドを参照ください。
参照：xOps: エンジニアがスタートアップの成長の原動力となる日｜Takaaki Umada

このような課題感と気分転換に趣味で自動化したい思いが上手く混ざりあった結果、昨年の12月、4か月越しに経営自動化部に真面目に取り組み始めました。

経営自動化部としての心構え

経営自動化部の活動を行うにあたって、意識していたことがいくつかあります。

とりあえず早く行きたいので一人で進む

有名な「早く行きたければ一人で行け、遠くへ行きたければみんなで行け」です。
大抵は遠くに行くためにはチームが必要。という文脈で引用されることが多い印象ですが、今回は逆です。
大した話ではないですが、まずはシンプルに自分がひたすら手を動かして「とりあえず色々自動化してる人」の認知を取りに行きました。
xOpsを志向する上で、プロダクト・エンジニア組織に留まらず、いたる所でボトムアップで改善が行われて欲しいのですが、自分一人が思いつく、手を出せる領域は限られます。
自動化ネタを集めるためにも、相談先・窓口として認知を獲得するために、事例自体は小さくてもとにかく自動化の数を重ねることを優先しました。

YAGNI(You Aren't Gonna Need It)

You ain't gonna need it、省略してYAGNIとは、実際に必要となるまでは追加しないというエンジニアには馴染みのある有名な原則です。
まずは数を重ねると決めたこともあり、一人で自動化できる範囲を過大評価せず、作り込みすぎないことを大事にしました。
例えば、問い合わせ内容に応じて自動でタグを付与し分析に使いたいという要件に対しても、いきなりテキストマイニングやら自然言語処理やらしなくてもただのキーワードマッチで十分だったりします。
基本的には最小効率で十分な改善を達成できるかを最優先にしました。

またYAGNIを実践するためにも、簡単に自動化するための自動化howを沢山持っておくことの大事さを実感しました。
エンジニアだけが自動化する世界はスケーラビリティに欠けますし、SlackやZapier、Makeなどのノーコードでワークフローを組めるツールを組み合わせるだけでも思ってた以上に多くのことができます。
コード書くのは最終手段と決めて、全力でZapier、Make等に頼る事にしました。

DRY(Don't Repeat Yourself)

YAGNIと同様にエンジニアの中で著名な原則で、「繰り返しを避けること」という意味です。
経営自動化部におけるDRYは、できるだけ自動化方法をドキュメント化することを意味します。
数をこなすと言いましたが、それでもできるだけドキュメントを残すことは意識しました。
現在の経営自動化部では、自動化にあたってSlackやZapier、Makeなどのツールの組み合わせを多用しているため、ドキュメント化することで、次からは同じような自動化を他の誰かが展開でき、横展開も期待できます。上手く回れば勝手に自動化が広がっていきます。

Write Automate Every Day

Write Code Every Day（毎日コードを書く習慣のこと）のオマージュです。 本家Write Code Every Dayの説明は省略しますが、要するに少しでも良いので毎日何らかの自動化活動に取り組むことを心がけました。
経営自動化部は、あくまで部活、隙間時間で行う活動ではあったので自然とやらなくなるのを恐れました。
そこでカレンダーで毎日30分だけ作業時間を抑えるなど、Write Automate Every Dayを行っていました。
途中までは達成した日をメモしていました。ある時から辞めてしまいましたがなんだかんだ毎日多少はやっていた気がします。

不満の閾値を下げる

自動化やプロセス改善、生産性改善を行う上で大事だと思うマインドです。
参照：ISUCONの第一人者・藤原俊一郎さんが語る攻略と学び ― 大切なのは「不満のしきい値」を下げること - エンジニアHub｜Webエンジニアのキャリアを考える！

面倒や無駄に意識的に目を向けて、どうすれば改善できるかを考えることで、たくさんの改善点が見つけられます。それを繰り返し潰すことが生産性や満足度に寄与します。
どなたの言葉か失念してしまったのですが、「面倒をプログラミング対象に」という言葉もお気に入りです。
手動で行うような面倒な作業に対して蓋をするのではなく、プログラミング対象にする、面倒自体を興味ある対象、自動化対象にして向き合うことを推奨するということです。
おそらくエンジニアに向けた言葉だったはずですが、趣味で自動化を嗜む経営自動化部にはぴったりの言葉です。

具体的な事例

今回は概要だけです。詳細は別で書きます、書きたい。
他にもZoom背景作るチャンネルだったり、経営自動化部の毎週の成果を通知するBotだったりと色々作った気がしますが、パッと出てきた3つを取り上げます。

Notion DBを活用したリリース内容通知

新機能や仕様変更を伴うようなリリースは、主にCSを中心としたエンジニア以外のメンバーもキャッチアップ可能にするために、専用のNotion DBに登録するフローとなっています。
主に概要説明やリリース日、影響範囲やリリース区分(新機能 or 不具合修正, etc…)等の情報をエンジニアが記入していますが、このDBの情報を最大限に活用するためにいくつかの自動化を行いました。

具体的には、入力された影響範囲やリリース区分の内容を参考に、お客様事前案内の有無、リリースノート作成対象の判定を自動で行うほか、リリース日にリリース内容を通知することで、リリース内容のキャッチアップをより容易にする工夫を行なっています。

Zendeskへの問い合わせ集約

当時、社内外問わず、複数ルート(Slack, フォーム, etc…)から問い合わせが行われるが、1箇所に集約出来ておらず分析もままならないという課題を抱えていました。
そこで問い合わせフローの整備をミニマムにスタートするためにも、Slackスタンプを押したらZendeskに起票されるようにすることで簡易的に1箇所に集約するための自動化を行いました。

スタンプを押すことで、Zendeskに起票され、Slackチャンネルに通知されます

分析を行うためのタグ付与にも、スプシで管理したキーワードをベースに対応しました。
原始的ではありますが、スタートとしては十分だったと考えていて、前述の通りYAGNIを実践できました。
次はZendeskで返信を行えば、Slackに対しても返信される仕組みを作ることで、Zendeskでお客様問い合わせが完結する世界を作ろうとしています。

社内問い合わせワークフロー

社内でエンジニアに仕様の問い合わせや作業依頼をするためのワークフローを作りました。
以前は質問内容や希望解答期日に応じて、エンジニアへの問い合わせを管理するNotion DBの新規作成か、問い合わせ担当メンバーへメンション行うのか、質問者側が判断してる状況でした。
社員数がどんどん増える中で、上記ルールの徹底は難しい！ということでそこは自動化してしまえば良いのではということで自動化しました。

進化余地として、そもそもの問い合わせフローのアップデートはもちろんですが、該当機能に応じて担当チームに自動アサインする、期日に近い問い合わせはリマインドするなどなど、質問者から見た体験・クオリティを担保しつつも、エンジニアの負荷やコンテキストスイッチも低くするための効率化余地があると思っているので、引き続き改善していく所存です。

まとめ

2ヶ月ほど経営自動化部として自動化活動を行ってきました。
当初目指していた、一定の自動化事例を積み重ねる事はできたと言っても許されそうです。

とはいえxOpsの実践はもちろん、部活名の由来である経営自動化への道は遠いです。
ここまで壮大な話でなくても、シンプルに自動化で面倒や手間を潰していくのはテトリスでまとめて消す時かパズドラで大量コンボを決めた時並に爽快感があって楽しいですし、なのに業務も楽になる不思議な部活が経営自動化部です。

組織のフェーズが変わるたびにいくらでも改善する領域は生まれていくので、今後も自動化部を盛り上げていきたいと思います。