リスクを5段階で制御する「システム開発ガイドライン」
──策定されたシステム開発ガイドラインの具体的な内容と、リスクを判断するための基準について教えてください。
ガイドラインでは、作成手段を問わずWebアプリやAPI、Bot、スクリプトなどすべてのソフトウェアを「システム」と定義しています。その上で、システムの機能、具体的にはデータベースやログイン機能の有無、個人情報や商取引の有無と、個人利用や社内利用、クライアントや一般向けといった提供対象の掛け合わせによって、リスクを「レベル0」から「レベル4」までの段階に分類しています。
運用上の大前提として、メンバーが作成したシステムがどのレベルに該当するかを自己確認し、技術統括部門であるCTO室へレビュー依頼を出す仕組みにしています。もし判断に迷った場合は、安全のために「1段上のレベル」に設定することをルール化しています。また、実証段階のプロトタイプなど、クライアントとの間で「バグや表示崩れがあっても問題ない」という合意が明確に握れている場合に限り、レベルを1段階下げて調整することを許容しています。
──実際のレビューはどのように行われているのでしょうか。
レビュー自体はCTO室のエンジニアが担当しています。ただ、エンジニアと非エンジニアでは、要求される仕様の粒度感や言語の共通認識が異なるため、そのままコミュニケーションをとると確認の往復が発生してコストが膨らんでしまいます。
そこで、「Claude Code」のSkillsを整備するとともに、要件定義の記述に「EARS（Easy Approach to Requirements Syntax）記法」を取り入れました。EARSとは、要件の齟齬をなくすために「どのような条件下で、システムはどう動作しなければならないか」を定型パターンにあてはめて簡潔に記述するフレームワークです。
非エンジニアがこのプロトコルに沿って仕様やモックを提示することで、エンジニア側も「何をトリガーに、どういう状態へ遷移させたいのか」を正確に把握でき、スムーズなレビューが可能となります。
エンジニアからは懸念の声も──いかにしてガイドラインを浸透させていったのか
──このガイドラインを社内に浸透させるにあたって、非エンジニアの方々からはどのような反応がありましたか。
意外に思われるかもしれませんが、非エンジニアのメンバーからの反発はほとんどありませんでした。皆、AIを使って見よう見まねでシステムを作ってはいるものの、「本当にこれで世に出して大丈夫だろうか」という強い不安を抱えていたからです。そこに対して、専門家であるエンジニアが「私たちがきちんとコードを見ますよ」というスタンスを示したことは、むしろ心強いサポートとしてポジティブに受け止められました。
一方、実はエンジニアサイドでは、少ないながらも一部で懐疑的な声や困惑がありました。理由は大きく2つあります。1つは「純粋に自分たちのレビュー工数が増えて大変になるのではないか」という現実的な負担への懸念です。そしてもう1つは、エンジニアとしてのアイデンティティに関わる部分です。「専門的な教育や訓練を受けていない非エンジニアがコーディングを行うこと自体、品質や保守性の観点から許容すべきではないのではないか」という、技術者ならではの反応や懸念の声が挙がったのも事実です。
──エンジニアの方々のそうした懸念に対して、CTOとしてどのようにアプローチされたのでしょうか。
先ほどお話しした、リリース直前のインシデントが発覚した際、現場のエンジニアの間には「それ見たことか、やはり非エンジニアの開発は全面禁止にすべきだ」という規制強化の空気が流れかけました。しかし私は、その全面禁止という選択だけは避けるべきだと考えていました。
なぜなら、ビジネス職のメンバーがAIの力を借りて自ら価値を生み出せるようになることは、Relicが掲げる「イノベーションの民主化」という方針に深く合致するからです。エンジニアだけが技術やコードを独占し、新しい可能性の芽を摘んでしまうようなことはしたくありませんでした。
だからこそ、「野放しにできないリスクがあるなら、全面禁止にするのではなく、どこまでが安全で、どこからを専門家が見るべきなのかという『適切な線引き』を敷くことこそが、専門家であるエンジニアの果たすべき役割だ」と伝えてきました。AIによる変化を無理に止めるのではなく、プロとしてその変化を正しくコントロールし、サポートする側に回ろうというマインドセットへの転換を促したのです。
