OutSystemsは、複数のアプリケーションが共存する開発プラットフォームです。OutSystemsの利用拡大が進むにつれて、様々な領域でOutSystemsの開発者＝「ITユーザー」が増え、アプリケーションの数も膨大になっていきます。しかし、運用方針が十分に定まっていないと、アプリケーションの関係性や責任者が不明確になり、リリースサイクルを滞らせるといったリスクが生じてしまいます。これを防ぐためには「ITユーザー」の権限を制御することが非常に効果的です。

本ブログ記事では、OutSystemsの開発者＝「ITユーザー」を適切に管理するための方法と考え方をわかりやすく解説します。

OutSystemsにおいてITユーザー（開発者）の管理が必要な理由

まず、OutSystems環境を初期設定のまま利用した場合に発生しうる具体的な問題をいくつかご紹介します。

初期設定では、すべての権限を持つAdministratorと権限を自由に設定できるDeveloperの2つしか存在しません。
そのため、Developerのアプリケーション編集権限を大きくしてしまいがちですが、その場合、一部の開発者のみが参照できるようにしたいアプリケーションへ誰でもアクセスできてしまう、アプリケーションを勝手に更新されてしまうといったリスクが生じます。

また、依存関係を自由に追加できてしまうことも問題と成り得ます。
特定のアプリケーション用に開発していた機能が想定外のアプリケーションから呼び出され、意図していなかった使われ方をされてしまい、両方のアプリケーションに思わぬ影響が発生する可能性があります。

その他、誰でもデプロイできるよう権限を付与してしまうと、リリースにまつわる準備が出来ていないアプリケーションが、事情を知らない開発者によってデプロイされてしまうといった問題が発生する恐れがあります。特に、本番環境へのデプロイは慎重に行うべきです。

上述のような問題の発生を防ぐために、ITユーザーに不必要に大きな権限を与えることは避ける必要があります。一方で、権限を絞りすぎて他のアプリケーションの機能が参照できない状態にまでしてしまうと、OutSystemsの利点である共通プラットフォームとしての利便性が損なわれてしまいます。
それでは、バランスの取れた適切な権限をITユーザーに反映するにはどうすれば良いでしょうか？
それは、アプリケーションごとにITユーザーの権限を設定することで解決できます。
そこで次章では、ITユーザーに対して設定できる権限管理の機能について解説します。

OutSystemsにおけるITユーザー（開発者）の権限を制御する方法

前章の通り、バランスの取れた適切な権限をITユーザーに反映するには、ITユーザーの持つべき権限をアプリケーションごとに設定できるような機能が必要となります。
これは、OutSystemsの2つの機能を活用することで実現することができます。

1. ロール
   ひとつ目の機能は「ロール」です。ここで述べる「ロール」とは、Service Studioの中で定義できるロールではなく、LifeTimeコンソール上でITユーザーに対して設定できるロールのことを指します。
   環境ごとに設定できる3種類の権限とインフラ全体に影響する2種類の権限をまとめて定義したものとなっており、通常の3環境（開発/検証/本番）構成であれば、1つのロールで11個の権限をセットにして定義できます。

   【環境ごとに設定可能な3種類の権限】
   ・システム参照追加権限（ON/OFF）
   ・アプリケーション作成権限（ON/OFF）
   ・アプリケーション編集権限（7段階）
   　- フルコントロール
   　- アプリケーションの変更とデプロイ
   　- アプリケーションの起動とデバッグ
   　- 監視と依存関係の追加
   　- アプリケーションの表示
   　- アクセス権限あり
   　-アクセス権限なし

   【インフラ全体に影響する2種類の権限】
   ・インフラとユーザーの管理権限（ON/OFF）
   ・チームとアプリケーションロールの管理権限（ON/OFF）

   ロールは複数作成することが出来ます。ITユーザーはデフォルトのロールを一つしか持つことができませんが、2つ目の機能「チーム」を活用することでロールの階層を構成することが出来ます。

2. チーム
   「チーム」は、ITユーザーに対して特定のアプリケーション群への権限をデフォルトロールから上書きするために活用できるグループです。この機能を活用する場合は、チームとアプリケーションを一対多の関係で紐づけます。ITユーザーは複数のチームに所属することができ、チームごとに新たなロールを付与されます。
   チームロールで上書きされる権限は11種類すべてではありませんが、チーム内のアプリケーションを開発する権限は変更できるため、アプリケーション別の様々な権限制御を実現することが可能です。

＊ITユーザーがアプリケーションごとに個別のロールを持つことも可能ですが、利用場面が限られるため、本ブログ記事では割愛します。
＊ご参考：ITユーザーの権限モデルを理解する

OutSystemsにおけるITユーザー（開発者）のロール/チーム構成 例

ここからは、ロールとチームの機能を適切に構成するための考え方をご紹介します。

1. 「ロール」の構成
   まずは、「ロール」の構成を考えましょう。
   デフォルトロールは必要最低限とし、チームロールで必要な権限を開放する構成がおすすめです。

   
   ITユーザーのロールの階層は、権限を“上書き”するのが特徴です。これはつまり、デフォルトロールで有効な権限を、チームロールで無効にできることを意味します。そのような階層ではロールの関係が複雑になってしまうので、一般的なソリューションでも採用されている開放型の構成の方がスムーズに運用できるでしょう。

   

2. 「チーム」の構成
   次に、「チーム」の構成を考えましょう。
   チームはアプリケーションが関わる業務領域ごとに分割する方針を基本とし、必要に応じてアプリケーションの機能や利用目的に応じて細分化するのがおすすめです。ITユーザーは複数のチームに所属できますが、アプリケーションは1つのチームにしか所属できないため、アプリケーションの特性を優先することで拡張性を高めることが出来ます。

必ずしもこれがあらゆる環境で通用するロール/チーム構成とは限りませんが、本章で述べた構成の考え方を参考にすれば、自社に最適な構成を検討することができるはずです。

まとめ

さてここまで、ITユーザーを適切に管理するための方法（権限管理機能）と考え方（ロール/チーム構成）について解説して参りました。
セキュリティや監査の観点からもITユーザーを適切に管理することは重要ですが、OutSystemsは基本機能だけで十分に細やかな権限管理が可能であることをご理解いただけたかと思います。

OutSystemsは、効率的な開発だけではなく、運用も含めた全体の効率化を実現できる機能を兼ね備えたプラットフォームですが、その機能を有効活用するには、OutSystems環境全体を俯瞰して利用することが重要となります。そのような観点を持った組織として、弊社はCoEチームを組成することを推奨しております。CoEチームの有用性や組成方法についてご興味のある方は、是非、弊社までお問い合わせください。

弊社電通総研は、ローコード開発プラットフォーム：OutSystemsの導入/活用を支援する様々なサービスメニューをご用意しております。
ローコード開発のはじめの一歩を、電通総研と一緒に踏み出してみませんか？

電通総研のOutSystems関連サービスページ：
・サービストップページ：https://itsol.dentsusoken.com/outsystems/service/
・CoE支援サービス：https://itsol.dentsusoken.com/outsystems/service/coe/

本ブログは、2023年6月15日時点の情報をもとに作成しています。
OutSystemsに関する詳しいお問い合わせは、弊社Webサイトからお問い合わせください。
https://itsol.dentsusoken.com/outsystems/inquiry/