Devin Enterpriseのプロビジョニング自動化から学ぶ、運用設計の進め方
DeNAエンジニアがDevin Enterpriseのプロビジョニング自動化事例を通じて、運用設計の初期段階で役立つ方法論と設計思想を共有している。
キーポイント
運用設計の学習リソース不足
実装やコードに関する資料は豊富だが、運用設計をゼロから学ぶための体系的な参考記事が不足している現状を指摘。
自動化を通じた運用設計の具体化
Devin Enterpriseのプロビジョニング自動化プロジェクトを事例として、運用設計の進め方を体系化して提示。
初学者向けの設計方法论の共有
運用設計を初めて行うエンジニア向けに、考え方や手順を整理し、実践的なガイドラインを提供する目的。
影響分析・編集コメントを表示
影響分析
本記事は特定のAI技術の進展ではなく、DevOps/SRE領域における運用設計のベストプラクティスを体系化する試みである。DeNAのような大規模開発組織が内部プロジェクトの運用設計を公開することで、業界全体のインフラ運用標準化や新人エンジニアの育成コスト削減に寄与する可能性がある。ただし、技術的な革新性よりも組織知の共有という側面が強く、即座に業界構造を変えるものではない。
編集コメント
技術ブログとして実用性は高いが、AI/LLM分野の最新動向とは直接関係ない運用設計の基礎論である。初学者向けのインフラ運用ガイドラインとして、社内ナレッジの外部公開という点で評価できる。
はじめに
こんにちは、IT戦略部 滝です。
この記事では、最近対応したDevin Enterpriseの運用自動化を通して、運用設計の考え方や方法論について共有します。
プログラムの実装やコードの書き方については色んな記事や書籍がありますが、運用設計を初めて行う際には、どの記事や書籍を読めば良いかわからなかった。という個人的な経験があります。
運用設計を進める上での考え方や方法論について本記事を通して共有することで、運用設計をこれから初めて行う方の参考になればと思います。
この記事では、まず「運用設計の流れ」を方法論としてまとめたあと、Devin Enterpriseの案件を通じてそれを実践した話を書きます。方法論パートと実践パートを分けることで、実践パートでは「ここでこう判断した」「ここで詰まった」というエピソードを腰を据えて書けるようにしました。
最初に注意しておくと、AIの話は出てきません。
Devin Enterpriseと聞いてAIの話を期待された方には恐縮ですが、今回は運用設計の話に焦点を当てています。
運用設計の流れ
運用設計は、大きく以下の流れで進めます。
目的やゴールに関する認識を合わせる
現在の運用を把握する
全体像を可視化する
担当を決める（責任分界・運用一覧）
運用の構築をする（実装・手順・合意）
目的やゴールに関する認識を合わせる
最初に行うことであり、運用を設計する上で1番大切なことです。ここでの認識のズレは後々大きな手戻りの原因になるので、時間をかけてでもしっかりと認識を合わせることが重要です。
まずは、現在運用を担っている部門がどのような世界観を実現したいか？そのために解決したい課題は何か？をヒアリングし、文章などで合意を取っていきます。
「言葉では合意したつもりが後から認識がズレていた」ということがあります。口頭で確認したと思っていても、文章に落とすことで曖昧だった部分が表面化することがあります。面倒に感じても、合意を文章で残すことを習慣にすることを推奨します。
現在の運用を把握する
ヒアリングおよび対象システムの調査結果から、自分の言葉に置き換えて説明できるようにします。
説明できなければまだ自分が理解できていないことになるので、どのような情報が足りないかを埋めていきます。
気をつけることは、ヒアリング先の担当者が前提知識として持っている情報を、こちらが知らないまま話を進めてしまうことです。わからない言葉はその場で確認しながら進めると良いです。
全体像を可視化する
文章や口頭の説明だけでは、複雑なシステムの全体像を正確に頭に入れることは難しいです。図を起こすことで、情報の抜け漏れや誤解に気づきやすくなります。
図に何を含めるかも重要です。目的に応じて情報を絞ることで、伝えたいことが明確になります。たとえば「なにがどこへ行くか」に絞りたいなら、「誰が」という情報は別の図に譲ると良いです。
担当を決める
運用を誰が担うかを明確にします。担当が曖昧なままだと、問い合わせや障害が発生した場合に対応が遅れる原因になります。
責任分界をまとめたうえで、実際にどのような運用が必要になるかを洗い出し、運用一覧にまとめます。担当の全体像が見えている状態で洗い出すと、当初想定していなかった運用項目が見えやすくなります。
運用の構築をする
担当と運用一覧が決まったら、実際に運用の構築を行います。運用の構築は以下の3つのステップで行います。
自動化処理の実装を行う
運用手順を記載する
成果物の合意を取る
自動化処理の実装では、優先度の高い機能から実装することと、エラー発生時の復旧手順をセットで考えることを意識します。エラーメッセージを書く際は、「どこへ誰が何をすれば良いか」をセットで考える必要があります。ログに「400 bad request」とだけ出力されても、運用者は何をすれば良いかわからないですよね。
運用手順は、開発者が忘れがちなものです。システムだけ作っても業務は回りません。特に複数部署が関わる運用項目は、何を起点として誰がどのような運用を行うかを明記する必要があります。
成果物の合意は、可能であれば少しずつ取ることが結果的に早くなることが多いです。機能が多ければ一度の打ち合わせで確認することは難しくなり、また言葉や図で説明するよりも実際に動くものを見せる方が圧倒的に認識を合わせやすいからです。
題材: Devin Enterpriseのプロビジョニング自動化
ここからは、上の流れを実際のDevin Enterpriseの案件で実践した話を書きます。
目的やゴールに関する認識を合わせる
Devin Enterpriseをメインで運用しているIT基盤部1に要件をヒアリングしたところ、実現したい世界観を要約すると以下でした。
GoogleGroupのメンバーとDevin EnterpriseのSub-Organization内のユーザを同期し、GoogleGroup毎にDevin Enterprise上のロールを分けたい
GoogleGroupのメンバーとSlack上のDevin Enterprise用ワークスペース及びチャンネル内のメンバーを同期したい
2の機能は、既存の内製システムのサンゴ2とHERB3で実現できるため、今回は1の機能を実装することになりました。
現在の運用を把握する
1を掘り下げていくと、Devin Enterpriseの実装と現在の運用はこのようになっていました。
(後の図を見てから読むことを推奨します)
Devin Enterpriseでは2階層までOrganizationを作成できる
2階層目のOrganizationは、Sub-Organizationと呼ばれている
Devin Enterpriseへのユーザアカウントの招待は1階層目のOrganizationに対して行い、Sub-Organizationへは所属という形で表現される
Devin Enterpriseを利用するユーザアカウントが1つのGoogleGroup(以下root_google_groupと記載)の配下に入っている
Sub-Organizationのユーザ・ロール別にroot_google_groupの配下にGoogleGroupが作成されている
1つのSub-Organizationに対して、ロールの数だけGoogleGroupが作成されている
ユーザの追加・削除は、root_google_groupの配下のGoogleGroupに対して行われている
Initially, upon hearing "provisioning automation," we assumed the IT Strategy Department would automate both user account invitations and Sub-Organization creation/management. However, through repeated interviews, it became clear that designing and managing Sub-Organizations relates to the overall usage policy of Devin Enterprise, making it the responsibility of the IT Infrastructure Department. We subsequently reconsidered how to divide responsibilities.
Visualizing the Overall Picture
As mentioned in the previous section, I noted that one should be able to explain it in their own words. But if the bullet points above were presented as text or spoken, would they really sink in? I don't think so, so I created a diagram. The conceptual image for user data integration in Devin Enterprise looks like this:
Coral and HERB systems, which handle the integration, are not included in this diagram. This is because the focus here is solely on which data ultimately integrates where, not on who handles it. At this stage, we considered "who" less important than "what goes where," so they were omitted from the figure.
Determining Responsibilities
Summarizing Responsibility Boundaries
Until this provisioning automation was implemented, the IT Infrastructure Department handled all operations for Devin Enterprise. However, with the IT Strategy Department now involved in provisioning automation, it became necessary to define who is responsible for what.
You might wonder, "Why divide responsibilities within the same company?" But this is a lesson that leads to painful consequences if debated after operations begin. At a past company, when additional operations were required after a service went live, ambiguous responsibilities led to arguments like "Why should we have to do this?" Debating responsibilities after launch not only delays responses but also tends to strain relationships among stakeholders. Therefore, it is crucial to clarify responsibilities before operations begin.
In this discussion, the key point was which department would handle Sub-Organization creation. Since designing and managing Sub-Organizations relates to the overall usage policy of Devin Enterprise, it was deemed appropriate for the IT Infrastructure Department to take charge. As a result, the responsibility boundary between the IT Infrastructure and IT Strategy Departments was defined as follows:
IT Infrastructure Department
Creation and management of Sub-Organizations in Devin Enterprise
Operation of GoogleGroups for integration with Devin Enterprise
IT Strategy Department
Invitation of user accounts to the Organization in Devin Enterprise
Linking user accounts and roles to Sub-Organizations in Devin Enterprise
Creating an Operations List
With the responsibility boundaries decided, we identified what actual operations would be required.
Again, having a diagram like the one above makes it easier to visualize what operations are needed.
| No. | Operational Content | Responsible Department |
|---|---|---|
| 1 | Creation of GoogleGroups | IT Infrastructure Department |
| 2 | Adding/Removing users from GoogleGroups | -(End Users) |
| 3 | Creation/Deletion of Sub-Organizations | IT Infrastructure Department |
| 4 | Inviting user accounts to Devin Enterprise | IT Strategy Department |
| 5 | Assigning Sub-Organization roles to user accounts | IT Strategy Department |
| 6 | Handling new Role creation | IT Infrastructure/IT Strategy Departments |
| 7 | Adding system accounts to Devin Enterprise | IT Infrastructure/IT Strategy Departments |
Items No. 6 and No. 7 were not initially within the scope of provisioning automation. As we approached the service launch, we realized gaps in addressing "what happens when new Roles are added" and "how to handle system accounts," so we urgently added them.
These two operational items were considered low-frequency, so they were excluded from automation targets and limited to procedure documentation. One criterion for deciding "what to automate" is the balance between change frequency and automation cost. High-frequency operations yield higher ROI for automation, while rare occurrences are often more practical to handle via procedure manuals.
Building Operations
Implementing Automated Processes
The operational items implemented through automation are No. 4 and No. 5.
This time, we released all automation features at once. Ideally, releasing higher-priority functions first would reduce the operational burden earlier and allow for faster feedback. However, due to stakeholder coordination and schedule constraints, we decided on a batch release. Looking back, this was not the ideal approach.
During implementation, what I paid particular attention to was considering recovery procedures alongside error handling. The most challenging aspect of automating processes is responding to errors. Automated processes can fail for various reasons, such as WebAPI issues or data inconsistencies.
So, how should error messages be handled? If a log only outputs "400 bad request," operators won't know what to do.
When writing error messages, you must consider who needs to do what and where, as a set.
Documenting Operational Procedures
Developers often forget this, but building a system alone does not make business operations run smoothly.
In this case, items No. 6 and No. 7 were considered low-frequency and thus excluded from automation targets.
Furthermore, since these operational items involve both the IT Infrastructure and IT Strategy Departments, it is necessary to clearly specify what serves as the trigger and which department performs which operation.
Additionally, while we did not create it this time, if three or more departments are involved in operations, it is better to document an operational flowchart.
成果物の合意を取る
運用の構築ができたら、成果物の合意を取ります。自動化した処理の内容と、運用手順に記載した内容で実際に業務が回るかを確認します。
この確認をするための環境は、テスト用の環境でも本番の環境でも構いませんが、本番の環境で確認する場合は、業務に支障が出ないように注意する必要があります。
今回のDevin Enterpriseのプロビジョニング自動化では、No.4とNo.5をそれぞれ本番環境で確認しました。
No.4のユーザの招待は、まずDry-Runで意図しないユーザが招待されないことを確認しました。このDry-RunでいくつかのSub-Organizationで既に招待されているユーザが、対応するGoogleGroupには存在していないケースがあり、同期処理の結果としてそのユーザがSub-Organizationから削除される対象になりかけていたのです。確認の結果、当該ユーザはSub-Organizationから外れていて問題ないことが分かりました。本番での確認前に必ずDry-Runを行うことの大切さを改めて実感した場面でした。
No.5のユーザアカウントへのSub-Organizationのロール付与は、IT基盤部の方が利用しているSub-Organizationに対してのみ自動化処理を有効にすることで、既に利用しているエンドユーザに影響が出ないように段階的に確認を行いました。
自動化した処理結果および運用手順の内容について、IT基盤部とIT戦略部で読み合わせを実施し、最終合意をとることができました。
可能であれば、少しずつ成果物の合意を取ることが結果的に早くなることが多いです。機能が多くなれば一度の打ち合わせで確認することは難しくなり、また言葉や図で説明するよりも実際に動くものを見せる方が圧倒的に認識を合わせやすいからです。
まとめ
今回の内容は私が運用設計を進める上で大切にしていることなどを、Devin Enterpriseの運用設計を通して紹介しました。
最後に、システムを動かし続けていくうえで大切なのは、以下の２点と考えてます。
初期運用の担当者がいなくなったとしても、運用が回り続けるようにすること
どのような考えで運用設計を行ったかを残すこと
運用設計がいい加減でも、初期運用の担当者がいると、その方は業務を理解しているため、案外運用は回ってしまいます。しかし、数年経って担当者が変わった途端に運用が回らなくなってしまうことはよくある話です。
そして、数年後に業務が運用と乖離し、運用を見直す際に、どのような考えで運用設計を行ったかがわからないと、見直すことも難しくなります。
個人的な経験からですが、運用設計は続けやすく変えやすい設計にすることが大切だと考えています。
運用設計に正解はありませんが、読んだ方にとって運用設計を進める上での考え方や方法の参考になれば幸いです。
IT基盤部が行ったDevin Enterpriseの導入の経緯については
DeNA 的 Devin Enterprise 導入 ~8つの課題とアプローチ~
で紹介されています。 ↩︎
サンゴはGoogleGroupからSlackのGroupとChannelのメンバーを同期するDeNA内製システム。
参考
↩︎
HERBはDeNA内製のID管理システム。
参考
↩︎
原文を表示
はじめに
こんにちは、IT戦略部 滝です。
この記事では、最近対応したDevin Enterpriseの運用自動化を通して、運用設計の考え方や方法論について共有します。
プログラムの実装やコードの書き方については色んな記事や書籍がありますが、運用設計を初めて行う際には、どの記事や書籍を読めば良いかわからなかった。という個人的な経験があります。
運用設計を進める上での考え方や方法論について本記事を通して共有することで、運用設計をこれから初めて行う方の参考になればと思います。
この記事では、まず「運用設計の流れ」を方法論としてまとめたあと、Devin Enterpriseの案件を通じてそれを実践した話を書きます。方法論パートと実践パートを分けることで、実践パートでは「ここでこう判断した」「ここで詰まった」というエピソードを腰を据えて書けるようにしました。
最初に注意しておくと、AIの話は出てきません。
Devin Enterpriseと聞いてAIの話を期待された方には恐縮ですが、今回は運用設計の話に焦点を当てています。
運用設計の流れ
運用設計は、大きく以下の流れで進めます。
目的やゴールに関する認識を合わせる
現在の運用を把握する
全体像を可視化する
担当を決める（責任分界・運用一覧）
運用の構築をする（実装・手順・合意）
目的やゴールに関する認識を合わせる
最初に行うことであり、運用を設計する上で1番大切なことです。ここでの認識のズレは後々大きな手戻りの原因になるので、時間をかけてでもしっかりと認識を合わせることが重要です。
まずは、現在運用を担っている部門がどのような世界観を実現したいか？そのために解決したい課題は何か？をヒアリングし、文章などで合意を取っていきます。
「言葉では合意したつもりが後から認識がズレていた」ということがあります。口頭で確認したと思っていても、文章に落とすことで曖昧だった部分が表面化することがあります。面倒に感じても、合意を文章で残すことを習慣にすることを推奨します。
現在の運用を把握する
ヒアリングおよび対象システムの調査結果から、自分の言葉に置き換えて説明できるようにします。
説明できなければまだ自分が理解できていないことになるので、どのような情報が足りないかを埋めていきます。
気をつけることは、ヒアリング先の担当者が前提知識として持っている情報を、こちらが知らないまま話を進めてしまうことです。わからない言葉はその場で確認しながら進めると良いです。
全体像を可視化する
文章や口頭の説明だけでは、複雑なシステムの全体像を正確に頭に入れることは難しいです。図を起こすことで、情報の抜け漏れや誤解に気づきやすくなります。
図に何を含めるかも重要です。目的に応じて情報を絞ることで、伝えたいことが明確になります。たとえば「なにがどこへ行くか」に絞りたいなら、「誰が」という情報は別の図に譲ると良いです。
担当を決める
運用を誰が担うかを明確にします。担当が曖昧なままだと、問い合わせや障害が発生した場合に対応が遅れる原因になります。
責任分界をまとめたうえで、実際にどのような運用が必要になるかを洗い出し、運用一覧にまとめます。担当の全体像が見えている状態で洗い出すと、当初想定していなかった運用項目が見えやすくなります。
運用の構築をする
担当と運用一覧が決まったら、実際に運用の構築を行います。運用の構築は以下の3つのステップで行います。
自動化処理の実装を行う
運用手順を記載する
成果物の合意を取る
自動化処理の実装では、優先度の高い機能から実装することと、エラー発生時の復旧手順をセットで考えることを意識します。エラーメッセージを書く際は、「どこへ誰が何をすれば良いか」をセットで考える必要があります。ログに「400 bad request」とだけ出力されても、運用者は何をすれば良いかわからないですよね。
運用手順は、開発者が忘れがちなものです。システムだけ作っても業務は回りません。特に複数部署が関わる運用項目は、何を起点として誰がどのような運用を行うかを明記する必要があります。
成果物の合意は、可能であれば少しずつ取ることが結果的に早くなることが多いです。機能が多くなれば一度の打ち合わせで確認することは難しくなり、また言葉や図で説明するよりも実際に動くものを見せる方が圧倒的に認識を合わせやすいからです。
題材: Devin Enterpriseのプロビジョニング自動化
ここからは、上の流れを実際のDevin Enterpriseの案件で実践した話を書きます。
目的やゴールに関する認識を合わせる
Devin Enterpriseをメインで運用しているIT基盤部1に要件をヒアリングしたところ、実現したい世界観を要約すると以下でした。
GoogleGroupのメンバーとDevin EnterpriseのSub-Organization内のユーザを同期し、GoogleGroup毎にDevin Enterprise上のロールを分けたい
GoogleGroupのメンバーとSlack上のDevin Enterprise用ワークスペース及びチャンネル内のメンバーを同期したい
2の機能は、既存の内製システムのサンゴ2とHERB3で実現できるため、今回は1の機能を実装することになりました。
現在の運用を把握する
1を掘り下げていくと、Devin Enterpriseの実装と現在の運用はこのようになっていました。
(後の図を見てから読むことを推奨します)
Devin Enterpriseでは2階層までOrganizationを作成できる
2階層目のOrganizationは、Sub-Organizationと呼ばれている
Devin Enterpriseへのユーザアカウントの招待は1階層目のOrganizationに対して行い、Sub-Organizationへは所属という形で表現される
Devin Enterpriseを利用するユーザアカウントが1つのGoogleGroup(以下root_google_groupと記載)の配下に入っている
Sub-Organizationのユーザ・ロール別にroot_google_groupの配下にGoogleGroupが作成されている
1つのSub-Organizationに対して、ロールの数だけGoogleGroupが作成されている
ユーザの追加・削除は、root_google_groupの配下のGoogleGroupに対して行われている
当初、「プロビジョニングの自動化」と聞いていたため、IT戦略部側でユーザアカウントの招待とSub-Organizationの作成・管理の両方を自動化することを想定していました。しかしヒアリングを重ねるうちに、Sub-Organizationの設計・管理はDevin Enterprise全体の利用方針に関わるためIT基盤部が担当するものであることが明確になり、担当の引き方を再検討することになりました。
全体像を可視化する
さて、前段で自分の言葉で説明できるようにする、と記載しましたが、先ほどの箇条書きを文字か口頭で説明されて頭に入っていくでしょうか？
私は入らないので図を起こします。
今回のDevin Enterpriseのユーザデータの連携イメージはこのような感じになります。
連携を担うサンゴとHERBのシステムが含まれていないのは、この図ではあくまで最終的にどのデータがどこへ連携するかに焦点を当てたいためです。
現時点では、誰がという情報は重要ではなく、あくまでなにがどこへ行くかという情報に注目したいと考えたため、図には入れていません。
担当を決める
責任分界をまとめる
Devin Enterpriseの運用は、このプロビジョニング自動化を行うまで、IT基盤部が全て行っていました。しかしプロビジョニングの自動化にあたってIT戦略部が関わることになり、誰がどこに対して責任を持つかを決める必要がありました。
「同じ会社なのに担当を分ける必要があるの？」と思われるかもしれません。しかしこれは、運用が始まってから議論すると痛い目を見る話です。過去にいた会社で、サービスが稼働し始めてから追加の運用が必要になった際、担当が曖昧だったせいで「なぜ自分たちがやらなければいけないのか」という議論になったことがありました。稼働後に担当を議論することになると、対応が遅れるだけでなく関係者間の関係も悪化しやすいです。だからこそ、運用が始まる前に担当を明確にしておくことが大切です。
今回の議論では、Sub-Organizationの作成をどちらの部署が担うかが論点になりました。Sub-Organizationの設計・管理はDevin Enterprise全体の利用方針に関わることから、IT基盤部が担当することが適切と判断しました。結果として、IT基盤部とIT戦略部間での責任分界は以下となりました。
IT基盤部
Devin EnterpriseのSub-Organizationの作成と管理
Devin Enterpriseと連携するためのGoogleGroupの運用
IT戦略部
Devin EnterpriseのOrganizationへのユーザアカウントの招待
Devin EnterpriseのSub-Organizationに対するユーザアカウントとロール紐付け
運用一覧を作成する
責任分界が決まったので、実際にどのような運用が必要になるかを洗い出します。
ここでも、上に書いたような図があるとどのような運用があるか想像しやすくなります。
No.
運用内容
担当部署
1
GoogleGroupの作成
IT基盤部
2
GoogleGroupのユーザの追加・削除
-(エンドユーザ)
3
Sub-Organizationの作成・削除
IT基盤部
4
Devin Enterpriseへユーザアカウント招待
IT戦略部
5
ユーザアカウントへのSub-Organizationのロール付与
IT戦略部
6
新しいRoleの作成時の対応
IT基盤部/IT戦略部
7
システムアカウントをDevin Enterpriseに追加する場合の対応
IT基盤部/IT戦略部
No.6とNo.7は、当初のプロビジョニング自動化のスコープには入っていませんでした。サービス開始直前になって、「新しいRoleが追加されたときはどうするか」「システムアカウントはどう扱うか」という観点が抜けていることに気づき、急いで追加しました。
この2つの運用項目は変更頻度が低いと考えたため、自動化の対象外として手順書の整備のみに留めました。「どれを自動化するか」を判断する際の一つの基準は、変更頻度と自動化コストのバランスです。頻繁に発生する運用ほど自動化の費用対効果が高く、稀にしか発生しないものは手順書で対応する方が現実的な場合もあります。
運用の構築をする
自動化処理の実装を行う
自動化処理で実装することは、運用項目のNo.4とNo.5です。
今回は全ての自動化機能をまとめて一度にリリースしました。本来であれば、優先度の高い機能からリリースすることで運用者の負荷を早期に下げたり、フィードバックを早く得たりできます。ただ今回は、関係者間の調整やスケジュールの都合から、まとめてリリースするという判断になりました。理想的な進め方ではなかったと振り返っています。
実装において特に意識したのは、エラーが発生した場合に復旧手順は何をすれば良いかをセットで考えることです。処理を自動化する際に1番悩ましいのが、エラーが発生した場合の対応です。自動化処理を実装していると、WebAPIや、データの不整合など様々な理由でエラーが発生する可能性があります。
さて、その場合にエラーメッセージはどのようにするのが良いでしょうか？ ログに「400 bad request」とだけ出力されても、運用者は何をすれば良いかわからないですよね。
エラーメッセージを書く際は、どこへ誰が何をすれば良いかをセットで考える必要があります。
運用手順を記載する
開発者は忘れがちなことですが、システムだけ作っても業務が回るわけではありません。
今回のケースでいえば、No.6,No.7の運用項目は、頻度が少ないものと考え、運用自動化の対象外としています。
そのうえ、IT基盤部とIT戦略部の両方が関わる運用項目になっているため、何を起点として、誰がどのような運用を行うかを明記する必要があります。
また、今回は作成しませんでしたが、運用に関わる部署が3つ以上になるなら運用フローを記述した方が良いです。
成果物の合意を取る
運用の構築ができたら、成果物の合意を取ります。自動化した処理の内容と、運用手順に記載した内容で実際に業務が回るかを確認します。
この確認をするための環境は、テスト用の環境でも本番の環境でも構いませんが、本番の環境で確認する場合は、業務に支障が出ないように注意する必要があります。
今回のDevin Enterpriseのプロビジョニング自動化では、No.4とNo.5をそれぞれ本番環境で確認しました。
No.4のユーザの招待は、まずDry-Runで意図しないユーザが招待されないことを確認しました。このDry-RunでいくつかのSub-Organizationで既に招待されているユーザが、対応するGoogleGroupには存在していないケースがあり、同期処理の結果としてそのユーザがSub-Organizationから削除される対象になりかけていたのです。確認の結果、当該ユーザはSub-Organizationから外れていて問題ないことが分かりました。本番での確認前に必ずDry-Runを行うことの大切さを改めて実感した場面でした。
No.5のユーザアカウントへのSub-Organizationのロール付与は、IT基盤部の方が利用しているSub-Organizationに対してのみ自動化処理を有効にすることで、既に利用しているエンドユーザに影響が出ないように段階的に確認を行いました。
自動化した処理結果および運用手順の内容について、IT基盤部とIT戦略部で読み合わせを実施し、最終合意をとることができました。
可能であれば、少しずつ成果物の合意を取ることが結果的に早くなることが多いです。機能が多くなれば一度の打ち合わせで確認することは難しくなり、また言葉や図で説明するよりも実際に動くものを見せる方が圧倒的に認識を合わせやすいからです。
まとめ
今回の内容は私が運用設計を進める上で大切にしていることなどを、Devin Enterpriseの運用設計を通して紹介しました。
最後に、システムを動かし続けていくうえで大切なのは、以下の２点と考えてます。
初期運用の担当者がいなくなったとしても、運用が回り続けるようにすること
どのような考えで運用設計を行ったかを残すこと
運用設計がいい加減でも、初期運用の担当者がいると、その方は業務を理解しているため、案外運用は回ってしまいます。しかし、数年経って担当者が変わった途端に運用が回らなくなってしまうことはよくある話です。
そして、数年後に業務が運用と乖離し、運用を見直す際に、どのような考えで運用設計を行ったかがわからないと、見直すことも難しくなります。
個人的な経験からですが、運用設計は続けやすく変えやすい設計にすることが大切だと考えています。
運用設計に正解はありませんが、読んだ方にとって運用設計を進める上での考え方や方法の参考になれば幸いです。
IT基盤部が行ったDevin Enterpriseの導入の経緯については
DeNA 的 Devin Enterprise 導入 ~8つの課題とアプローチ~
で紹介されています。 ↩︎
サンゴはGoogleGroupからSlackのGroupとChannelのメンバーを同期するDeNA内製システム。
参考
↩︎
HERBはDeNA内製のID管理システム。
参考
↩︎