🗓️

共用のQA環境の利用状況を Notion でノーコードで可視化する

2023/12/19に公開

はじめに

こんにちは、 syucream です。 Ubie でソフトウェアエンジニアをやっています。
ここでは表題の通り、筆者が関わっている Ubie の toC サービス開発の現場において、共用の QA 環境の利用状況をサクッと可視化したエピソードについて触れます。

課題

Ubie の toC サービス開発の現場では、現在ソフトウェアエンジニアや QAE が動作確認をする時に共用の QA 環境を用いています。
この運用は今までは十分に回っており、共用 QA 環境を用いた動作確認を行う前提でデプロイパイプラインやツールは最適化されてきました。
しかしサービスの成長に合わせて開発に関わるメンバーやチームの増加して、この環境が足枷となってきています。

この QA 環境はシンプルに共用であるがゆえ利用待ちが発生する可能性があります。機能リリースまでのリードタイムの増加や開発者体験毀損が発生してきています。
そんなボトルネックになりやすい QA 環境ですが、利用状況も上手く管理されていませんでした。どこかで明示的に管理されている訳ではなく、 "慣習的に使い始める・使い終わる時に Slack で連絡する" ような素朴な運用をしてきました。それゆえ、誰かが利用中であることを見落として誰かに QA 環境を意図せず更新されたり、前回利用者が使い終わった宣言を忘れているために今使えるのかが分からず無駄に待ち合わせるといった問題が発生していました。


QA環境の利用状況は素朴な管理がされており、人に聞かないと状況を把握できない

Ubie ではより水平スケール可能な QA に用いることができる環境 "dev-n" が存在するのですが、 toC サービス開発の現場においてソフトウェアエンジニアや QAE が活用可能な状態にはなっていません。
https://zenn.dev/ubie_dev/articles/4c02baa037c5aa

理想的にはこの dev-n をちゃんと運用可能にしたいところですが、それにも準備が必要です。まずはカオスな QA 環境運用をしていることによる、今すでに発生しているペインを少し取り除きたくもあります。

Notion による利用状況可視化

QA 環境を取り巻くペインは様々紹介しましたが、初手で dev-n のようなソリューションをもってこれを完璧に取り除くのではなく、短期的なペインを低インベストで取り除いて少し延命し、それがワークしている間により理想的なソリューションを用意することにしました。
そこで表題の、 Notion による QA 環境利用状況可視化に至ります。

具体的には Notion のデータベース上で、いくつかのマイクロサービスの QA 環境に対する利用状況を管理するようにします。
各利用状況データは利用開始・終了日時や使っているユーザ名など管理に必要なプロパティを持たせます。


利用状況データのイメージ


タイムラインビューでの利用状況確認

Notion のデータベースではデータベースの特定のプロパティが変更された場合に Slack 通知を投げることが可能です。従来の QA 環境の利用状況を Slack で把握していた運用との延長で、この通知を行うことで自然に新しい運用に乗れるかと考えました。

なお、 QA 環境のこれまでの利用パターンは分解すると以下のような整理ができました。これらの利用パターンを吸収できる工夫もしています。

  • アドホックに利用する
    • 短時間だけ使って終わったら利用終了できる
    • 動作確認に時間がかかり、短時間で利用終了できない
  • 計画的にまとめて利用する

Notion のデータベースでできることにも限界はあります。今回の文脈だと、入力時に高度な変換やバリデーションを行えないのが困るポイントです。 Formula 型プロパティで、他プロパティの値を参照して変換した結果を出したりフィルタは用意できるのでそれで出来る範囲での作り込みを行なっています。これにより

  • アドホックに短時間利用する場合はデフォルト使用時間を補完して利用終了見込み時間を埋める
  • 使い終わったフラグを持たせて、即時利用終了を宣言できるようにする。
  • 「期間」や「使い終わったフラグ」、現在時刻を交えて、書く利用情報から今利用されているかどうかのステータスを可視化する。ステータスを利用終了している分を非表示にするフィルタを組む

という作りにすることでノーコード(厳密にはローコードか?)で一定使い物になる実装ができました。


Formula型プロパティでいい感じに利用状況を表現する(必要以上に複雑にしていそうなので直したい...)

おわりに

Notion の機能を使い倒すことで、以外とコードを書かずとも解決できる問題がありそうですね。今回のような限定的な課題に、一定の制約がありながらも対処したい時には便利だなと感じました。
ソフトウェアエンジニアとしてはモノを作って解決という方針が思いつきやすいですが、何らかの仕組みを実装・運用するコストもかかるものです。
ここでは Notion のデータベースでしたが、一定の諦めを交えつつ既にあるものを有効活用してなるべく開発・運用コストを減らす選択肢もあるかと考えています。

残念ながらこのソリューションでは本記事で触れた QA 環境が共用であるがゆえのスケーラビリティ問題は解消されていません。
これに対して、今回の工夫で生まれた猶予が残っている間に解決を図りたいところです。(一時的な緩和策が、実は長期間に渡って運用されちゃった、なんてことがないようにしたい!)

Ubie テックブログ

Discussion