非エンジニアのAIコーディング向けに開発ガイドラインを策定したRelic──エンジニアの価値をどう発揮する？

　AIコーディングの急速な普及に伴い、非エンジニアであっても手軽にシステムやアプリケーションを構築できるようになった。ビジネス職のメンバーが自ら手を動かし、アイデアを迅速に形にしてPoCを回せる環境が整いつつある一方で、専門知識が不足した状態で構築された本番システムには、セキュリティや保守性の観点から深刻なリスクが潜んでいる。このような状況において、ソフトウェアエンジニアはどのような価値を発揮し、組織のガバナンスとどのように向き合うべきなのか。今回は社内の「非エンジニア向けシステム開発ガイドライン」を策定し、自由なAI開発とリスクヘッジの両立に挑む株式会社Relicの代表取締役CTO／Co-Founderである大庭亮氏にインタビューを実施。具体的なガイドライン運用の仕組みや、これからの時代におけるエンジニアの存在意義について話を伺った。

株式会社Relic 代表取締役CTO／Co-Founder 大庭亮氏

リリース直前で気付いたヒヤリ・ハット事例がきっかけに

──Relicでは非エンジニア向けのシステム開発ガイドラインを策定されたとのことですが、そのきっかけとなった背景や課題意識について教えてください。

　直接的なきっかけは、社内で発生した1件のヒヤリ・ハット事例でした。非エンジニアのメンバーがバイブコーディングによって、ログイン機能や個人情報を扱う本格的なシステムを構築していたのですが、それがリリース直前に発覚したのです。

　それまでも、静的なWebページの作成などにAIを活用していることは認識していました。しかし、「まさかエンジニアを一切介さずに、機密情報や個人情報を扱うようなシステムがリリース直前まで作られてしまうとは」と、当時は思いも寄らないことでした。

　そのソースコードをエンジニアが確認したところ、プロのシステム開発という文脈では避けるべきアンチパターンをいくつか踏んでいる状況でした。例えば、ファイルの保存先であるストレージの設定が不十分だったり、メール送信が不適切な方式で実装されていたりと、到底そのまま世に出せる状態ではなかったのです。このときは一度リリースをストップし、エンジニアが介入して改修を行うことで事なきを得ました。

　この件を機に社内調査を行ったところ、ほかの部署でも同様の「野良開発」が複数行われていることが判明しました。「このまま放置すれば深刻なインシデントにつながりかねない」という危機感から、非エンジニアが「どういうときにエンジニアに声をかけるべきか」を明確にするための基準として、ガイドラインの策定に至りました。

──非エンジニアが自らシステムを開発できるようになることについて、大庭さん自身、CTOの立場としてはチャンスとリスクのどちらを強く感じていましたか。

　結論から言えば両方ですが、どちらかというと大きなチャンスだと捉えていました。Relicには「事業プロデューサー」という、新規事業の企画から実行までを一気通貫で担う職種があります。これまでは事業プロデューサーが企画した仕様をエンジニアに伝え、咀嚼してもらいながら作るというプロセスを踏んでいましたが、AIを活用することで、企画者が頭の中にあるアイデアをそのままダイレクトにアウトプットできるようになったのです。コミュニケーションコストを減らし、圧倒的なスピードでプロダクトを実装できるのはビジネスにおいて大きな強みです。「このメリットを活かさない手はない」と感じていました。

　しかし同時に、エンジニアのバックグラウンドを持つ人間としては、セキュリティや堅牢性といった専門知識がないままシステムが作られる怖さも痛感していました。昨今、サイバー攻撃がますます高度化・巧妙化する中で、無防備なシステムを公開することは企業として極めて高いリスクを伴います。そのため、チャンスを最大化しつつリスクを最小限に抑え込むための対策は絶対に必要だと考えていました。