{{item.title}}
{{item.text}}
{{item.text}}
近年、企業におけるアプリケーション開発の担い手は、専門的な開発スキルを持つ特定の部門や外部ベンダーにとどまらなくなっています。ローコード/ノーコード開発基盤の普及により、各部門が自分たちの業務課題を解決するアプリケーションやワークフローを自ら作成する「市民開発」が広がりつつあります。
さらに、生成AIの活用により自然言語で業務要件や実現したい処理を入力できるようになったことで、ユーザーがアプリケーション開発に関与するハードルはさらに下がり、この流れは一段と加速しています。これにより市民開発はより広範な業務領域へと拡大し、企業内で作成・利用されるアプリケーションの母数も大幅に増加しつつあります。
市民開発における問題は、一般のユーザーがアプリケーションを作成すること自体ではありません。問題は、専門的な知見を持つ部門の関与を経ずに開発・利用が進み、さらに生成AIによって実現できる処理の範囲が広がることで、セキュリティ部門が拡大するリスクを把握しにくい点にあります。
従来のアプリケーション開発では、リリース判定などを通じてIT部門やセキュリティ部門が一定程度関与できる接点がありました。
一方で、市民開発ではローコード/ノーコード基盤の開発環境が業務部門の日常的なツールの中に組み込まれつつあり、ユーザーは専門的な開発環境を準備しなくても業務ツールの操作の延長でアプリケーションやワークフローを作成できます。
また、市民開発は小規模な業務改善として始まることが多く、現場側でも「正式なシステム開発」とは認識されにくい場合があります。その結果、IT部門やセキュリティ部門に開発案件として持ち込まれないまま、業務内での利用が始まることも少なくないのです。
従来の市民開発では、開発できる内容はユーザー本人のITリテラシーやツール理解により一定程度制限されていました。しかし、冒頭でも伝えたとおり、生成AIの台頭によってユーザーが自然言語で実現したい業務要件を入力するだけで開発を進められるようになったことで、この前提は変わりつつあります。
第1に、開発のハードルが下がったことで企業内での開発の母数が大きく増加している点です。開発数が増えれば、その中にセキュリティ部門が存在を把握していないアプリケーションや、作成後に十分な管理が行われないアプリケーションが含まれる可能性も高まります。
第2に、生成AIによって本来であれば現場担当者が自力では設計・実装できなかった処理までを実現しやすくなった点です。例えば、外部サービス連携、権限設定の変更、情報共有範囲の拡張などは業務上の利便性を高める一方で大きなリスクを伴いますが、生成AIによってユーザーがこれらのリスクを十分に理解しないまま機能が実装されてしまう恐れがあります。
これらは適切に管理されれば業務改善に寄与しますが、開発の事実や責任者などが見えないまま利用が進めば、企業として管理すべきリスクとなります。市民開発で拡大するリスクを管理するには、まず開発実態を認知し、必要な範囲で関与できる状態を整える必要があります。
セキュリティ部門として市民開発によるリスクを管理しようとする際、まず考えられるのは利用する開発基盤やツールを標準化し、一元的に管理する方法です。
しかし、市民開発は部門ごとの業務特性や現場の業務プロセス、データ活用ニーズなどと密接に結び付いているため、市民開発の全てを標準基盤へ集約することは容易ではありません。
また、市民開発の価値はユーザーが自ら業務課題を発見し、素早く改善できる点にあります。標準化を過度に進めると開発基盤やツールの選択肢が狭まり、現場のスピードや柔軟性を損なうおそれがあります。
したがって標準基盤への集約は市民開発統制における有効な打ち手でありつつ、それだけでは全ての市民開発リスクを捉えきれないと考えるほうが現実的です。
標準基盤に集約しきれない市民開発が残る以上、それらを単に「標準外」として放置することは適切ではありません。
最も避けるべきなのは、標準基盤に乗らない開発が存在しているにもかかわらず、その存在をセキュリティ部門が把握しないまま現場で利用が進む状態です。
そのため、標準基盤に乗らない開発や事業部門側で利用が進むツールをセキュリティ部門がどのように認知・関与するかを設計することが重要になります。
標準化しきれない市民開発について認知・関与する仕組みを整えるうえで中心的な論点となるのは、現場主導のDXを後押しする「アクセル」の役割を担うDX推進部門と、「安全装置」としてのセキュリティ部門、それを使うユーザー部門の三者が、それぞれの役割をつなぎながらどのように統制を機能させるかという点です。
近年、多くの企業では、ローコード/ノーコード基盤などを整備するとともに、ユーザー部門による業務改善を推進するDX推進部門が設置・強化されています。セキュリティ部門がセキュリティ観点の要件を提示することは共通ですが、標準基盤ではDX推進部門が管理オーナーとして、その要求を基盤の設定や運用施策に具体化し、基盤を管理・運用します。
一方、非標準基盤では、基盤を利用するユーザー部門が管理オーナーとなり、自部門で管理・運用する責任を負います。ただし、ユーザー部門だけに管理を委ねるのではなく、DX推進部門が標準基盤の管理運用を通じて蓄積した知見をもとに、必要な管理施策の設計や運用をアドバイザーとして支援します。
このように市民開発の統制では、まずセキュリティ部門が共通のセキュリティ要件を示す必要があります。そのうえで、標準基盤はDX推進部門、非標準基盤はユーザー部門が管理オーナーとなり、DX推進部門が非標準基盤の管理を補助するという責任分担を明確にすることが重要です。こうした役割分担を前提に、三者が連携して統制を機能させることが求められます(図表1)。
図表1:三者体制を前提とした統制設計
体制はあくまでも統制に関与する主体を定める枠組みであり、それだけでは市民開発の統制は機能しません。三者がそれぞれの役割を果たせるよう、セキュリティ部門が示す要求をDX推進部門が利用基盤や運用の仕組みに落とし込み、ユーザー部門がその範囲内で開発・相談できるよう、三者の関係性を具体化する必要があります。
したがって、ここでは三者がそれぞれ具体的にどう関与するかをルール、プロセス、教育の三つの観点から落とし込みます(図表2)。
セキュリティ部門は、利用データや外部サービス連携など、市民開発に対して求める共通のセキュリティ要件を定め、DX推進部門とユーザー部門に示します。
DX推進部門はその要件を踏まえ、技術的に制限できるものは標準基盤上の管理施策に落とし込み、開発権限を基盤側であらかじめ制限します。また、非標準基盤については利用開始前にセキュリティ要件への適合性を確認し、利用条件や必要な管理策をユーザー部門に提示します。
開発内容や利用データなどを考慮し、一定以上のリスクが見込まれる場合にはユーザー部門からセキュリティ部門への相談・レビュー依頼を必須とします。
セキュリティ部門は、連携された高リスク案件について利用条件、継続利用の可否などを判断し、DX推進部門とユーザー部門へ対応を求めます。
こうしたプロセスは新規開発だけを対象とせず、すでに開発・利用されているアプリについても棚卸しを行ったうえで、リスクの高いものについてはセキュリティ部門のレビューにつなげる仕組みとして運用する必要があります。
セキュリティ部門は、情報管理上のリスクを踏まえて市民開発者が最低限理解すべき知識の要件を定めます。
DX推進部門は、それらを利用基盤の操作や具体的な開発場面に即した教育・認定制度としてユーザー部門へ提供し、開発前に参照できる状態を整えます。
ユーザー部門は、必要な教育・認定を受けたうえで、自らの開発がルールの範囲内にあるか、専門部門への相談が必要ないかを確認しながら開発を行います。
図表2:三者構造の実効化(ルール・プロセス・教育)
市民開発は、現場の創意工夫を活かして業務改善のスピードを高める取り組みです。生成AIやローコード/ノーコード基盤の活用が進む中で、ユーザーが自らアプリケーションを作成する流れは今後も広がっていきます。その流れを止めることは企業のDX推進にとって必ずしも望ましい選択ではありません。
一方で、市民開発がセキュリティ部門の関与しないところで広がり、開発の事実、利用データ、共有範囲、責任者が把握されないまま利用が進めば、それは企業にとって見えないリスクとなります。
生成AIによって市民開発の総量が急速に増加する今こそ、市民開発を例外的な現場活動としてではなく、企業として管理すべきアプリケーションセキュリティ統制の対象として捉え直すべきタイミングではないでしょうか。
市民開発に対するこうしたセキュリティ統制は、そのリスクの大きさに反して、多くの企業でまだ十分に実施されていないのが現状です。まずは社内ですでに開発・利用されているアプリケーションを棚卸しして実態を把握することが、市民開発を「見えないリスク」にしないための第一歩となります。
{{item.text}}
{{item.text}}
{{item.text}}
{{item.text}}