背景
株式会社出前館 二宮と申します。
出前館では、Workatoを使った業務自動化を推進しています。
自動化処理の単位を 「レシピ」 と呼ぶ点に、勝手ながら弊社事業との親和性を感じたからです。
……という冗談はさておき、具体的にどう使っているかの一部をお届けできればと思います。
なぜ書こうと思ったか
Workatoを使い始めたとき、
「定義はドキュメントで分かるものの、具体的にどう使っていけばいいんだろう？」
と思う場面がありました。
そのような情報は活用事例にも出てきづらい印象です。
知りたい情報がないなら、まず自分で書いてみようと思い立ちました。
前置き
Workatoには、Workspace、Environment、Projectという概念があります。
このうちEnvironmentだけはあらかじめ決められた単位がありますが、他は分割単位を決められます。
以下、弊社が具体的にどうしているかを書いてみます。
基本思想
リスクの最小化
利用者に気をつけてもらうことはリスク回避になりません。
利用者が誤操作をする前提で、それがクリティカルにならないようにガードすることを考えました。
バランス
厳密にルールを定めれば一貫性を保てますが、開発者が気にするべきことは増えていきます。
逆に、自由すぎると運用保守コストが上がります。そのバランスを考えながらルールを決めていきました。
変化を避けない
ルールを決めて運用していても、状況が変われば変えたくなる部分も出てきます。
変えたほうが今後のためになると考えたことは変えるようにしました。
今もまだ最終版ではないと考えています。
弊社環境
Workspace
個々のワークスペースは、1つの部門、ビジネスレベル、または組織単位を表すために使用します。
（ドキュメントより）
これに関しては後から変えることが難しいので、最初に慎重に検討されることをおすすめします。
部門単位でWorkspaceを分割
部門内のメンバーは全員同じようにWorkspace内（DEV環境）のレシピを閲覧・編集できる状態です。
Project単位で細かくアクセス制御をしなくても済むメリットがあります。
リスクとして、Workspace内のすべてのレシピを触れるようにすると「意図せず他人のレシピを変更・削除してしまう」などの問題が起こり得ます。これらについては以下のように考えています。
- 変更：バージョン履歴から戻せるので大きな問題にはならない
- 削除：削除権限を管理者のみに付与することで事故を防ぐ
デメリット
上記のようなメリットもある一方で、
- SSOをする場合はWorkspace単位で設定が必要になる
- 複数Workspaceで共用したいレシピをWorkspaceごとにデプロイする必要がある
- 他のWorkspaceのメンバーにレシピを共有するときに手間がかかる
などのデメリットもあります。
なるべくWorkspaceをまたいだ動きを発生させないように分割できるとよさそうです。
Environment
あらかじめ3つの環境が用意されています。
| 環境 | 説明 |
|---|---|
| メイン環境 (DEV) | レシピのデプロイメントに使用 PROD を含む他の環境へのプロジェクトのデプロイメントに使用 チームとアカウントの管理に使用 (コラボレータのロール、プロジェクト、フォルダなどを含む) |
| テスト (TEST) | 開発中のレシピのテストに使用 |
| 本番 (PROD) | テスト、レビュー、承認が完了したレシピの実行に使用 |
（ドキュメントより）
各環境の用途
TEST環境の用途について少し迷いました。
ドキュメントのとおりに使うとテスト実施のたびにデプロイをすることになり、手間が増えそうです。
今は以下のようにしています。
- DEV：開発、開発者によるテスト
- TEST：レビューアまたは受け入れ部署によるテスト
ここは後から変えやすい部分なので、運用しながら見直すかもしれません。
各環境の権限
大まかに以下のような権限をつけています。
- DEV：全メンバーが閲覧・編集できる。管理者は全メンバーの権限に加えて削除ができる
- TEST：管理者がデプロイできる。全メンバーが実行できる
- PROD：管理者がデプロイできる。必要なメンバーが閲覧できる
以前はDEV環境の全メンバーに削除権限もつけていたのですが、事故防止のために削除権限を外しました。
ゴミ箱プロジェクトを作り、不要なレシピはそこへ移動する運用にしています。
Project
プロジェクトはワークスペース内で、部門、ユースケース、またはプロジェクト別にまとめます。
（ドキュメントより）
ここが一番迷いましたし、今でも迷っている部分です。
分割単位・命名ともに迷いました。
Projectはクラスと考えることにする
迷走した時期を経て、今は「Projectは（Javaでいう）クラス、Recipeはメソッド」と考えることにしました。
（ここはJavaに限らず、ご自身に知見のある分野で考えると整理しやすいのではないかと思います）
- Projectは操作対象を表す
- Recipeは操作内容を表す
と考えるとおのずと命名も決まってきます。
迷走の時期にリリースした「メソッド名のような名前のプロジェクト」も現存していますが、Project名を変えると別Projectとしてデプロイされることが分かったのでそのままにしています。
Recipeは操作対象のProjectに分類する
たとえば以下のような場合、レシピはどのProjectに属させると分かりやすいでしょうか？
- 「ワークフローシステム kickflowで申請が承認されたら、Slackユーザーの権限を変更する」という用途のレシピを作る
- 弊社環境では、Slackの権限を変更するにはOkta上のグループを変更する必要がある
- Wokato上には、kickflow、Slack、Oktaそれぞれのプロジェクトがある
考え方は3つあると思います。
- 起点となる申請はkickflowからくるから、kickflowにする
- Workatoが操作する先はOktaだから、Oktaにする
- レシピの目的はSlackの状態を変えることだから、Slackにする
弊社は3の考えを取りました。
「Slackの権限を変更したいレシピはSlackプロジェクトに置く」というのが一番シンプルだと考えたからです。
2は「Slackの権限を変えるにはOktaの設定を変える必要がある」という弊社環境固有の知識が必要になり、直感的ではありません。
1は入り口を表していて分かりやすく、迷ったのですが不採用としました。
「どの処理がどんなトリガーで動くか」も弊社環境固有の知識だと感じたからです。
まとめ
このような構成案・運用案に絶対の正解はなく、会社ごとに悩みながら決めていくものだと思います。
この記事が考える際の材料になれば嬉しいです。
出前館ではコーポレートエンジニアを募集中です。
一緒に悩んでくれる方は、カジュアル面談 でお会いしましょう！