”開発をしない部署・情シス”がAIネイティブなシステム開発に挑戦

はじめに

こんにちは。技術部 情報システムグループの石川です。

先日、社内の技術勉強会「Livesense Engineering Talk（通称: LET）」が開かれました。 テーマは「開発経験関係なく情シス全員がいつの間にかAIネイティブなシステム開発してた件」で、情報システムグループ（以下情シス）のメンバー5人が登壇しました。

情シスの主なミッションは、全社のアカウント管理、SaaSの導入と運用、ヘルプデスク、ITデバイスの管理などです。いわゆる「システム開発」を主務とする部署ではありません。 実際、登壇した5人のうち3人は、ソフトウェア開発の経験がないまま情シスでキャリアを積んできたメンバーです。私（石川）もその1人です。

そんな「開発をしない部署」が、今年の2月から8月までのわずか半年間で、なんと1007件のプルリクエストをマージし、約58万行のコードを追加するチームになっていました。

今年Claude Codeが全社導入されたのをきっかけに、情シス内で何が起き、そして開発経験のなかった私たちがどう変化したのか。今回の勉強会の内容を通して、そのリアルな過程をお話します。

開発経験ゼロの私が書いた最初のコード

情シスへ異動して数年の私は、開発経験がないどころか、GitHubに触れることすら怖いと感じていました。 かつてEngineering Handbookに情シスの取り組みを数行追記した際、ドキュメントの修正だけでマージまでに17日もかかった苦い経験があったからです。

そんな私が、Claude Codeを導入したその日に、157行のコード追加を含むプルリクエストをたった4時間で出すことができました。

その後も、ITデバイス管理で利用することになったkintoneの検索プラグインを自作するという挑戦をしました。 かつて所属していた総務もkintoneを利用するようになり、検索プラグインの横展開も実現しています。

もちろん、私は生成されたコードのすべてを理解できているわけではありません。 例えば、ある検索処理に230秒かかると分かった時、私はClaudeに「大学生にも分かるように解説して」と頼みました。するとClaudeは、「開店準備中のレストランで、一品だけ提供に時間がかかると発覚した状態。看板に『お時間いただきます』と張り紙をするか、開店を延期して厨房を改装するかです」と例えてくれました。 技術的な仕組みは分からなくても、この例えなら「どちらを選ぶべきか」という判断を下すことができます。

一方で、やらかしも経験しました。プラグインの署名用秘密鍵を、無意識のうちにリポジトリにコミットしてしまっていたのです。それに気づいてくれたのは私ではなく、後述するインフラ環境に組み込まれていたセキュリティツール「GitLeaks」でした。

開発未経験メンバーたちの奮闘：AIを疑い、手綱を握る

私と同じく、開発の経験がないままこの仕事をしてきたメンバーたちも、それぞれAIと格闘しながらシステムを作り上げていました。

逆瀬川さんは、コードを1行も書かずにバーチャルオフィス上で動く5人対戦のミニゲームを作り上げました。Claudeとの54往復のやり取りで2298行のコードを生成しましたが、動かしてみると「キャラクターが巻き戻る」「見えている状況が人によって違う」という、通信の遅れに典型的な問題が出ました。これらはAIではなく逆瀬川さんが実際に遊んで、自分の目で見て気づいたものです。異常に気づき、どう直してほしいかを決めるのは人間の仕事でした。

同じく開発未経験の黒木さんは、社内に蓄積されていた過去の業務データを、適切な権限管理のもとで検索・閲覧できるアプリケーションの開発に挑戦しました。「まずはAIに教わる」というスタンスで、選択肢と理由を噛み砕いて説明させながら進めましたが、それでもトラブルは起きました。AIの提案どおりに作りを変えたら、速くなるはずが、測ってみると前より遅くなっていました。別のときには、エラーも出ないまま、集計の件数が実際より多く数えられていたこともあります。 AIは「これで直ります」と提案してきましたが、それが確かめた結果なのかは文面からは見分けがつきませんでした。 黒木さんはこれを「検証していないものが、検証済みの顔をして通る」と表現しました。動いているように見えても、AI自身は間違いに気づきません。黒木さんはこの反省から、「AIに提案とリスクを挙げさせ、人間が選び、影響の大きい変更は人間がOKを出すまで先に進めない」という手順を自ら組み込みました。

開発のサイクルが、いつの間にか「技術の解像度」を上げていた

そして勉強会では、エンジニアとしてインフラ周りを支える高谷さんから、「多様なバックグラウンドを持つメンバーが、安心してAI開発できる基盤整備」についての発表がありました。

私たちがAIを使って好き勝手にコードを生成し、PRを乱発できる裏には、高谷さんが構築した強固なインフラがありました。 漏れて困るクレデンシャルをAIに読ませないために「IAMユーザーを一切作らない」設計にし、認証はSSOやGitHub ActionsのOIDCフェデレーションに寄せる。万が一の機密情報の混入を防ぐために「GitLeaks」を導入する。AIの生産量に人間が追いつかないため、コードレビュー自体も一次対応はAIに任せ、最終判断のみを人間が行う仕組みにする……。

私は高谷さんのこの発表を聞きながら、あることに気がつきました。 「AWSやCI/CDといった専門的なインフラの話が、AIの翻訳なしで理解できている」と。

以前の私なら、IAM、OIDC、フェデレーションといった技術用語はちんぷんかんぷんで、それこそClaudeに「大学生にも分かるように解説して」と頼まなければ、発表の意図すら掴めなかったはずです。 しかし、自分でAIと壁打ちしながら開発の手を動かし、デプロイのサイクルを回してきました。 いまなら、高谷さんが「何を解決するために、どんな基盤を作ってくれたのか」が痛いほど理解できます。

「AIを使って開発をしていたら、いつの間にか技術の解像度自体が上がっていた」。 開発未経験だった私が、今回最も自分自身の成長を感じた瞬間でした。

「開発をしない部署」がAIネイティブになれた3つの条件

勉強会の最後、エンジニアとしての知見を持ち、今回のLET登壇を企画したマネージャーの佐藤さんの資料には、情シスにClaude Codeが根づいた3つの条件が書かれていました。

• 業務に余白があった（技術に投資する文化があった）
• 失敗コストがゼロの練習台があった
• 隣に作れる人がいた

開発経験のなかった私たち3人は、最初から作れたわけではありません。高谷さんや佐藤さんといった経験豊富なエンジニア陣が「失敗しても大丈夫な土台」を作り、そこに乗っかってAIという強力な道具を振り回した結果、いつの間にか技術を理解し、システムを生み出せるチームになっていました。

まだ課題はあります。「AIに解説させて理解する」というプロセスを個人の心がけで終わらせないよう、チームでは週1回の開発共有会を始めています。自分の言葉でコードの意図を説明し、疑問をチームで解消し合うことで、作って終わりではなく「人間が責任と理解を持つ」ための仕組みを揃えていっているところです。

それでも「開発をしない部署」が、環境と道具と少しの挑戦だけで、たった半年でここまで変われました。 この事実を、開発を主業務としない組織へのひとつの可能性として提示できたのではないかと思っています。

技術部 情報システムグループでは、これからもAIと協働しながら、チームとしての開発手法を模索し続けていきます。