「勝手に作られると困る」 それでも情シスが市民開発者を受け入れるべき理由：現場主導とガバナンスの両立が鍵

生成AIの普及により、非エンジニアでもアプリ開発が可能となりつつある。一方、課題なのが開発の可視性やガバナンスの確保だ。情シスが「門番」から「支援者」へ転換し、安全に現場の力を引き出すための対策は。

[Kinza Yasar，TechTarget]

　生成AI（AI：人工知能）の台頭により、企業におけるソフトウェア開発の分散化が進んでいる。システム開発の専門知識を持たない「市民開発者」が、ローコード／ノーコード開発ツールやAIの力を借りることで、コードを1行も書かずにアプリケーション構築やワークフローの自動化、ツールの試作を実施できるようになった。

　多くの場合、ユーザーは自然言語のインタフェースを通じて「何を作りたいか」を説明するだけでよい。基礎となるロジックの大部分はAIが処理し、プロンプト入力やドラッグ＆ドロップ操作、AIが生成したワークフローによって開発が完結する。

　その結果、ソフトウェア開発はもはやIT部門だけの専売特許ではなくなった。ビジネス上の課題を誰よりも深く理解している現場の従業員が主導する、組織全体の「分散型機能」へと姿を変えつつある。

　この動きによって、アプリケーション開発のスピードと対応力の向上が期待できる。一方、開発が中央のIT部門を離れていく中、開発過程をどのように可視化し、ガバナンスを強化してリスクを制御するかが情報システム部門（情シス）の新たな課題となっている。

市民開発者の進化に合わせて情シスはどう変われば？

併せて読みたいお薦め記事

バイブコーディングの関連記事

• 情報システム部員のためのClaude Code入門
• コードを書かなくなる“バイブコーディング”時代の「開発者」の役割とは？

　従来の市民開発者は、ローコード／ノーコードツールを使い、人事や財務などの定型業務を支援する比較的シンプルなアプリケーションを構築するビジネスユーザーを指していた。利用できるツールや開発範囲も限定的だった。

　しかし生成AIの登場以降、その前提は大きく変わった。コーディングの知識がなくても、自然言語で目的や成果を説明するだけで、実用的なアプリケーションを生成できるようになった。開発の参入障壁は「コードの書き方」から「課題そのものを理解しているか」へと移り変わっている。

　対話型フォーム作成プラットフォームTypeformの最高製品・技術責任者であるアレクサンダース・バス氏は、この変化を「習熟すべき言語の変容」と表現する。「生成AIによって、求められるスキルのハードルは『コードが書けるか』から『課題について論理的に思考できるか』へと下がった」と同氏は述べる。

　ガバナンス・リスク・コンプライアンス（GRC）ソリューションを提供するLogicGateのCEO兼共同創業者、マット・カンケル氏も、「AIの普及により、あらゆる従業員が標準的な市民開発者になり得る」と指摘する。ソフトウェア開発はもはや技術部門に限定された活動ではなくなりつつある。

なぜ企業は「現場主導の開発」を歓迎するのか

　この変化を後押ししているのは、技術の進歩だけではない。組織が抱える構造的な課題も影響している。

　技術面では、生成AIに加え、Microsoft Power PlatformやServiceNow、Salesforce Flowといった企業向けツールがAIによる開発支援機能を搭載したことで、アプリケーション開発はこれまで以上に身近なものとなった。

　一方で、従来の開発モデルには長年の非効率性が存在していた。「Ubuntu」を提供するCanonicalのプロダクトディレクター、ウー・ファン氏は「従来の開発プロセスは非常に長く、納品時には要件が変わっていることも少なくない」と指摘する。

　さらに、多くの企業はエンジニア不足と開発案件の増加に直面している。その結果、現場の従業員が自らアプリケーションを開発するケースが増加している。

　Solid Software Solutionsのシニアコンサルタントであるソヌ・カプール氏は、「市民開発の拡大は生成AIだけでなく、開発案件を消化し切れない現場の実態にも起因している」と分析する。従来は着手できなかったアイデアも、生成AIによって実現可能になった。

　こうした背景から、市民開発を非公式な活動として放置するのではなく、「企業の能力」として制度化する動きも出ている。Typeformではガードレールと監視体制を整備し、市民開発を支援している。

　バス氏は「非エンジニアがAIツールを使い、限定されたドメイン内で開発を行いながら、エンジニアのレビューを経て安全に本番環境へ反映することが市民開発だ」と定義する。

　このように、ツールのアクセシビリティー向上とビジネス需要の増大が交差することで、企業はIT部門を増員することなく開発能力を拡張し、イノベーションを加速できるようになっている。

分散型AI開発に潜む死角

　開発の分散化は明確な利点を持つ一方で、統治や管理を困難にする新たな複雑さを生み出している。

　第一の問題は可視性の欠如だ。各部門が複数のプラットフォームで独自にアプリケーションを構築すると、IT部門は全体像を把握できなくなる。いわゆる「シャドーAI」が増殖し、ガバナンス外のツールや自動化が広がる。

　第二に、データセキュリティのリスクがある。従業員がデータ分類やアクセス制御を十分に理解しないままシステム連携を進めることで、機密情報の漏えいや過剰な権限付与が発生する恐れがある。

　第三に、生成AIの特性に起因する新たな問題もある。AIが生成したコードの仕組みを十分に理解しないまま導入する「バイブコーディング」は、レビューやテスト、セキュリティ検証といった工程を省略するリスクをはらむ。

　さらに、標準が統一されないまま開発が進むことで、ツールの乱立や重複投資が発生し、最終的には基幹システムとの統合を困難にする技術負債として蓄積される。

「門番」から「支援者」へ：情シスの役割変化

　こうした課題の多くは、市民開発そのものではなく、ガバナンスが導入スピードに追いついていないことに起因している。

　そのため多くの企業は、承認済みのプラットフォームに開発環境を限定し、監視と統制を強化するアプローチを取り始めている。重要なのは、ツールではなくリスクに基づいてガバナンスを設計することだ。

　カプール氏は「境界線はツールではなくリスクで引くべきだ」と指摘する。低リスクの領域は現場に任せ、高リスクの領域はエンジニアの監視下に置くという考え方である。

　Typeformでも同様に、開発をリスクに応じて「緑・黄・赤」に分類し、監視レベルを調整している。非技術職とエンジニアを組み合わせる体制や、アクセス制御などのガードレールも整備している。

　このような取り組みは、IT部門の役割が変化していることを示している。従来のように開発を制御する「門番」ではなく、安全な基盤を提供し、分散した開発環境の可視性と統制を維持する「支援者」へと移行している。

スピードと統制をどう両立するか

　市民開発は現場のニーズに即したツール構築を可能にする一方で、ガバナンスと制御の課題を突きつける。CIOに求められるのは、この流れを止めることではなく、管理することだ。

　そのためには、技術的リスクを経営層にも理解できる言葉に翻訳し、どこまでを許容し、どこからを制御するかを明確にする必要がある。

　スピードと統制は対立するものではない。適切なガバナンスとガードレールを前提に設計すれば、両立できる。

　市民開発で成果を上げている企業は、このバランスを意図的に設計している。スピードと制御はトレードオフではなく、設計によって実現される成果なのである。