トイルを減らしている話

こんにちは、ダイニーでソフトウェアエンジニアをしている唐澤 karszawa です。 前回の記事から間隔が空いてしまいましたが、これからは採用強化の一環として毎週エンジニアリングブログを投稿していきます。人数が少ないダイニーでは各人の負担が大きく週一投稿なんて実現できないんじゃないかと自分でも心配していますが、色々と工夫してなんとか実現したいです。その話もまた別の機会に紹介できればと思います。

本日はダイニーの開発チームで対応している「トイル」についてお話します。トイルとはエンジニアが手作業で対応しなければならない作業のことで、他の特徴としては

• 繰り返し実行されること

• サービスの成長に比例して実行されること

というものがあります。ダイニーでは主に導入店のデータの更新やデータの出力がトイルとして実行されてきて、開発チームの作業負荷も非常に高いものでした。この記事では約一年をかけてトイルの実行数をほぼゼロにしたことと、それによって開発効率の上昇という自明な効果が得られたことを紹介します。

トイルとは

繰り返しですがトイルとは以下の特徴を持つ作業のことを指します。

• 手作業で繰り返し行われる

• 自動化できる

• 戦術的で長期的な価値を持たない

• サービスの成長に比例して作業量が増えていく

ダイニーでは主に店舗のオンボーディングを担当する CS メンバーから「運用作業リクエスト」という名称で依頼されるタスクのことをトイルと定めています。具体的な依頼内容としては

• 店舗のレコードを作成して欲しい

• 店舗のデータを CSV から流し込んで欲しい

• 店舗のデータを別の店舗へコピーして欲しい

などで、まさに「サービスの成長に比例して作業量が増えていく」内容でした。

運用作業リクエストの運用方法

運用作業リクエストとして対応できるものを事前に定めておき、必要になったタイミングで CS に Notion で依頼を起票してもらっていました。事前に対応できるものを決めておかないと、アプリケーション側で対応できるんじゃないかと機能を探すのに時間を使ってしまったり、そもそも実現が難しい依頼がカジュアルに起票されてしまったりという問題が発生します。

Notion で管理されている運用作業リクエストの一覧

次の画像は実際のタスクの種別です。タグに前提条件を書いておけばすでにアプリケーション側から実行できるようなものが起票されてしまうというミスコミュニケーションも防げます。

運用作業リクエストの作業種別

起票されたタスクを曜日ごとのエンジニアの担当者が確認し対応していました。

ボリューム感としては5分〜15分程度の作業時間がかかるものが多く、一つ一つの作業時間は大したものではなかったのですが、内容的に加盟店の増加に比例して単純増加していくものだったので先手を打って自動化していかないと大変なことになるという認識がありました。

トイルの減らし方

トイルを減らす一番の目的は「エンジニアの作業時間を減らし開発に避ける時間を多くする」ことなので、時間的インパクトの大きいものから自動化に取り組みたいです。幸いなことに各依頼を実施した後に実施にかかった時間を分単位で記録していたので、これまでにそのタスクにどれだけ時間をかけたかということは簡単にわかりました。

一方で、自動化にかかるコストも勘案しなければなりません。例えば、毎日1回1分程度の作業が発生するとして、それを解消するのに100時間かかるのであれば投資に見合う成果が出る前に社会やビジネスモデルといった前提自体が大きく変化してしまっているでしょう。

以上を踏まえて、ダイニーでは次の順序でトイルを自動化していきました。

• 自動化にかかるコストが低いもの

• 実施件数が多いもの

• 作業時間が長いもの

それぞれ微妙なボーダーラインに乗っているタスクもあったのですが、すべて実績値がわかっているものなので適当にスコアリングして優先順位を付けていきました。どちらを先に自動化したら良いかわからないほど絶妙なタスクはどちらを先に自動化しても間違いではないので、とにかく優先順位を付けてみましょう。

また、細かいテクニックではあるのですが、スクリプトを実行して結果を得るような作業はアプリケーションに実装するのではなく GitHub Actions にそのまま載せてしまいました。これによりアプリケーションのインターフェイスを実装する必要がなくなり、実装コストをかなり削減できました。

「CS が GitHub から GitHub Actions を実行しているんですか」って？はい、そのとおりです。社内向けのマニュアルを用意することで快く GitHub Actions を受け入れていくれた CS に感謝です。

また、データの異常値を見つけるような依頼もアプリケーションにページを実装するのではなく Redash でクエリを書いて対応しています。こちらも CS が Redash を見に行く流れを作れています。

まとめ

以上の活動をした結果、運用作業の作業時間と件数はこのように推移していきました。

作業件数・作業時間合計の変化

去年の4月から5月のあたりで一度導入ラッシュがあり、作業時間は減らせているものの件数自体は伸び続けてしまうという現象が発生しました。その段階で満足せず、将来の導入計画に合わせて先んじて手を打ち続けた結果、その次の導入ラッシュの10月頃までには作業の絶対量を減らせています。

そんな感じで「インパクトの大きいものから取り組んだので真っ当な成果が出ました」という至極当たり前な結果が出ました。もし、この記事を読んでくださっている方の中でトイルを削減する機会を得られずに悩んでいたが、こんなにストレートに結果が出るなら気楽にやってみようと思ってくださる方がいれば幸いです。

ちなみに GitHub Actions や Notion, Redash の運用も地味にめちゃくちゃ効果を発揮していますから、そこらへんのオペレーションも参考にしていただけるなら幸いです（そしてそれを当たり前に使ってくれる CS の皆様に感謝！）。

いつもの採用リンクです。

近頃はようやくエンジニアの採用に本腰を入れて取り組むことができるようになったので、まだオープンになっていませんが色々と施策を打っていく予定です。スタートアップなんて何も整理されていなくて働きづらいと思われている方もいらっしゃるかもしれませんが、クローズでなら計画中のことも話せますのでカジュアルに面談を申し込んで頂けましたら嬉しいです！

飲食SaaSで急成長中のdiniiの組織・技術なんでもお話しします！