非エンジニア研修、3日で8アプリを生んだ設計の3段階

「これ、1日中手作業でやっていて、マジでストレスだったんです」。発表会の会場で、ある受講者がそう漏らした。作ったのは、毎月領収書集めを担当していた経理担当者だ。研修前まで、コードどころか開発ツールに触れたことすらなかったという。

その人が3日後には、ボタン1つで領収書を自動収集するシステムを完成させていた。宮城県の株式会社レニクスという会社で、株式会社アウトバーンが実施したClaude Code研修の話だ。使われたツール自体の細かな変更点はClaude Code 2.1.200 Manual modeデフォルト化で以前追いかけた。半数以上がプログラミング未経験のメンバーが、3日間で8つの実務アプリを作り上げている。この成果を、アウトバーンが2026年9月2日にPR TIMESで正式発表した。

私はかつてエンジニアを名乗っていたのに、大規模案件で挫折してカスタマーサクセスへ逃げた側の人間だ。だからこそ、この話には他人事とは思えないものがある。プログラミングに一度挫折した人間が、AIを介してもう一度手を動かせるようになる瞬間を、私は身をもって味わってきた。Cursorの補完が初めて意図通りに動いた夜は、体が震えるほど嬉しかった記憶がある。

ただ今回の主役は、経理担当者を含む非エンジニアの集団だ。個人の再挑戦ではなく、組織としての再現性がある研修として成立している点に興味を持った。この記事では成果の華やかさよりも、3日間という時間をどう設計したかを分解したい。自社でAI駆動開発研修を企画したい人事・DX担当者が、そのまま判断材料に使える形にまとめる。

経理担当者が3日で領収書を自動化した現場で起きたこと

レニクス社は2026年4月に経営が本格始動したばかりの、まだできたての会社だ。ところが驚くことに、全員が非エンジニアでありながら、取締役自身がすでにClaude Codeで日常業務の自動化や社内システム開発を進めていた。いわば超AI先進企業と呼べる状態から研修が始まっている。

その先にあったのが「作れるけど、分からない」という壁だという。経営陣はインタビューでこう振り返っていた。「それぞれがバラバラに開発していたので、経営メンバーの間でもいろいろごちゃついていて、こんな状態でチーム開発なんて無理という感じが一番大きかったです」。コードを見ずにマージし、不具合が起きたらその時に解決する。セキュリティはAIに任せられる範囲のみで、仕様書なしの開発ゆえコンテキスト管理もできていない。非エンジニアが業務アプリを量産して運用しているからこそ、将来の技術的負債が怖いというのが率直な課題感だったという。

そこで「開発の流れを知っていて、かつ教えられる人」として、アウトバーン代表の森山氏に白羽の矢が立った。4月末に相談を受けてから約3週間でカリキュラムをすり合わせ、5月21日には仙台で初回講義というスピード感で始動している。受講者の受講前の状態も率直だ。「ChatGPTやGeminiのチャット機能は結構使っていましたが、コードはまったく。不安しかなくて」。別の受講者は「プログラム自体一度も触ったことがなくて、英語で何が書いてあるかも分からない状態」と語っていた。この2つの発言が、研修開始時点の出発点をそのまま表している。

3日間の終わりに開かれた発表会では、8つのプロダクトが生まれた。社内教育ポータル、売上分析グラフ、競合の少ないキーワードの検索ツール、領収書自動収集システムの4つ。そしてAPI連携した在庫管理システム、日次の競合調査ダッシュボード、案件の収集・受け入れ判定ツール、海外EC向けのキーワード変換システムの4つだ。アンケート結果は満足度・内容・説明のわかりやすさ・質問対応のすべての項目で全員が5点満点をつけている。私はこの数字よりも、なぜここまで到達できたのかという設計の中身に興味を持った。次の章から、その裏側を見ていく。

研修直後、レニクス社長の山崎氏はSNSにこう投稿していた。「昨日受けた1回だけで、開発のフローが整い、すでにチームでシステム改修も進んでおります」。「Claude CodeやCodexはとても便利なのですが、やはりエンジニアしか上手く使えてないのも事実です」。「システムの概要や仕組みくらいは知っておく必要があるなと再認識しました」。さらにこう続けている。「新会社始まってまだ2ヶ月ですが、各々が開発したシステムが混在してぐちゃぐちゃになる前のこのタイミングで研修を実施して本当に良かったな」。技術的負債が積み上がる前の時期を見極めて動いたことが、成果の速さにつながったのだと思う。

独学や動画教材で非エンジニアが挫折する本当の理由

研修後のインタビューで、アウトバーンは「YouTubeや独学と何が違ったか」を率直に聞いている。返ってきた答えが、非エンジニア研修を企画する上での核心を突いていた。「YouTubeでClaude Codeを触ろうとした時期はあったんですけど、まじで何を言っているか分からなすぎて。そもそもセットアップの段階から、まず何を開くのかが丁寧じゃない」と、ある受講者は振り返る。

別の受講者はさらにこう続けた。「独学だと1回詰まると2、3時間平気で溶けるじゃないですか。詰まった時に、もう嫌だとなるところを一緒にクリアできるのは、めちゃめちゃ大きいです」。さらにもう一人はオンデマンド教材の弱点をこう表現した。「オンデマンドだと、どこまで理解していなきゃいけないのかが分からないんです」。そのうえで「ここは後で分かるので、とりあえず動くところまでやってみましょうと力の入れ具合を示してくれたのが、大きな違いだと思います」と付け加えている。

この3つの声は、それぞれ別の壁を指していた。セットアップ段階の丁寧さ不足、詰まった瞬間の孤独、理解度の基準が示されないことの3つだ。どれも「教材の情報量」の問題とは言い切れない。「今の自分にどこまで力を入れればいいか」を、その場で調整してくれる存在の有無こそが分かれ目になっている。

学習の最大の敵は挫折らしい。最初に少しできるようになった後、思い通りにいかず自信を失って辞めてしまう現象がある。心理学ではこれをダニング=クルーガー効果の谷と呼ぶそうだ。最初の高揚感の後にやってくる、能力の限界を思い知らされる落ち込みの時期を指す。その谷を越えるサポートをするのが教育の役目であり、リアルタイムの伴走にこだわる理由だとアウトバーンは説明していた。

私自身、Cursorを触り始めた頃を思い出す。補完が動いた瞬間の高揚感の後には、思い通りに動かないコードに何時間も向き合う時期が必ずやってくる。あの谷を1人で越えようとすると、心が折れる確率は高い。ハマったエラーメッセージをひたすら検索し続け、気づけば深夜になっていた夜を何度も経験した。非エンジニア組織の研修を企画するなら、教材の充実度よりも先に、この谷を越える伴走の設計を考えるべきだ。それが、この研修が示している最初の教訓だと私は受け止めている。

研修3日間の設計、地図作りから始まりゼロイチで終わる理由

Day1、Claude Codeのコマンドからは入らなかったという。ホワイトボードを使い、そもそもシステムとは何で、どう繋がっているのかという話から始めた。遠回りに見えるかもしれないが、ここが一番重要だとアウトバーンは強調する。全体像という地図を持って初めて、AIの提案に「それは違う」と言えるようになるからだという。地図を手に入れた直後、全員が自己紹介サイトを作る実践に移った。プロンプトを書いてサイトが立ち上がった瞬間、会場から歓声が上がったそうだ。さらにAnthropic公式スキルの「frontend-design」でデザインをブラッシュアップする流れも用意されていた。スキルとは、よく使う処理をまとめて呼び出せるようにしたものを指す。想定をはるかに超えて凝ったデザインを作り始める受講者が続出し、初日にしてHTMLでゲームを作ってしまった人もいたという。

Day2のテーマはチーム開発で、鍵になったのがgitだ。gitとは変更の履歴を管理する仕組みで、いつ誰が何をなぜ変えたのかをすべて記録できる。共同ファイルにつきまとう「誰かが消してしまうのでは」という不安から解放される仕組みだ。何かが壊れても元に戻せるとわかれば、安心して挑戦できる土台になる。レニクス社の要望の1つが「既存のコードをチームで修正できるようになりたい」だった。ただ、いきなり本番コードを全員で触るのは怖い。そこでgitのfork機能で既存コードをコピーし、そのコピーに対してチーム開発を行っている。全員がmainブランチへ向けてプルリクエストを作成すると、案の定コンフリクトが起きまくったらしい。ところが現場は阿鼻叫喚ではなく、機能が足されるたびに笑いが起きたという。「壊してもいい」という空気は意図的に作られたものだった。受講者は「独学だともう怖くて触れないと思うんですけど、何をやってもいいんだという安心感があって、そこでチャレンジができました」と振り返る。2日目が終わった時点で、レニクス社ではすでにチームでのシステム改修が実際に動き始めていた。研修が終わる前から、現場は変わり始めていたことになる。

Day3は当初テンプレートを用意していたが、各環境でうまく動かないトラブルが発生し、急遽ゼロからのアプリ開発に切り替える決断をした。正直、賭けだったとアウトバーンは振り返る。初期の言語設定やインフラ構成だけ講師が指示し、その先は受講者が3日間の学びをフル活用してそれぞれの手で開発を進めていく形だ。テンプレートという安全網を外した状態で、8つのプロダクトが1日で生まれた。

この3日間の設計に共通する思想は、制約を段階的に外していくことだと言えそうだ。Day1は地図という制約の中で安心させ、Day2は壊してもいい環境という制約の中で挑戦させる。そしてDay3ではテンプレートという制約すら外して自走させていた。最初から自由にさせるのではなく、安全な範囲を少しずつ広げていく順番。この順番そのものが、非エンジニアが挫折しない研修の設計図になっているのだと思う。

独学と何が違うのか、伴走体制に潜む3つの工夫

前の章で挙げた3つの挫折要因は、そのまま裏返すと伴走設計の3つの工夫になる。1つ目は、詰まった瞬間にすぐ聞ける講師の存在だ。独学では詰まった箇所を自分で調べ直すしかなく、そこで2、3時間が溶けてしまう。研修ではその場で講師に聞けるため、詰まりが挫折に発展する前に解消できていた。

2つ目は、理解度に応じて力の入れ具合を示すことだ。「ここは後で分かるので、とりあえず動くところまでやってみましょう」という声かけが、受講者の不安を大きく減らしたと証言されている。何をどこまで理解すべきかの基準が外から示されるだけで、独学特有の「どこまで頑張ればいいか分からない」という不安は薄れていく。

3つ目は、詰まった瞬間を一緒にクリアする伴走そのものだ。独学の孤独は、詰まった瞬間の孤独でもある。研修という場は、その孤独を埋める仕組みとして機能していたのだろう。この3つはどれも教材の質の話ではなく、人による調整の話だと私は捉えている。動画やテキストがどれだけ整っていても、この3つの代替は難しい。

非エンジニア向けの社内研修を検討する人事・DX担当者にとって、ここは投資判断の分かれ目になる。オンデマンド教材を買って終わりにするか、リアルタイムで伴走できる講師を確保するか。今回のレニクス社の事例が示しているのは、後者を選ぶ価値が特に非エンジニア組織では大きいという点だ。プログラミング経験がある層なら独学でも越えられる谷を、経験がない層は1人では越えにくい。非エンジニアがAIコーディングツールを使いこなす動きは、Claude Codeだけの話ではない。Codex非エンジニア189倍、OpenAI公式データで読む使い方で書いたように、他のツールでも同じ流れが起きている。

私自身もCursorやClaude Codeを独学で触ってきた側だが、詰まった時にすぐ聞ける相手がいない孤独感は今でも覚えている。ハマったエラーメッセージを検索し続けて3時間が消えた経験は、一度や二度ではなかった。非エンジニア組織を対象にするなら、その孤独をどう設計で埋めるかが最初の分岐点になると考えている。

発表会を次の開発が始まる号砲に変える設計

最終日の発表会で、印象的だった2つの成果を紹介したい。1つは経理担当者による領収書自動収集システムだ。ボタンを1つ押すと裏側でブラウザが自動で立ち上がり、期間指定で領収書をダウンロードしてくれる。デモでは目の前で領収書が次々と集まっていき、会場がどよめいたそうだ。本人は「みんなが領収書を取らなくていい世界にしたい」と語っていた。

もう1つは在庫管理システムだ。Amazonと連携し、在庫数・販売数・リードタイムを取り込んで発注すべき個数を提案する仕組みになっている。「在庫がなくなるまであと55日」という予測表示まで実装されていたという。こちらもプログラミング経験ゼロからの作品だ。発表中に「これ全体でやってほしい」という声が社内から飛び、その場で機能追加の議論が始まったらしい。

この研修で一番感動したのは完成度そのものではないと、アウトバーンは振り返っている。発表が終わるたびに「それ、社内システムに統合しよう」「リポジトリに招待して」と、その場で次の開発の話が始まっていた。これが一番の収穫だったという。2日目にコンフリクトを経験したからこそ、バラバラに作ったものを安全に統合する大切さが全員の共通認識になっていた。ブランチ保護やCI/CDといった次の一手まで、自然と議論が進んでいったそうだ。

経営陣への投資対効果に関する発言も率直だった。「受ける前の状態で効率化しようと思ったら、外注で1個システムを作るだけで数百万円とか余裕で使うんですよ」。「それが自社で、しかもビジネス感度を持った自分たちで作れる」とも続けている。この発言は特定の会計データに基づく数値ではなく、経営陣本人の実感として受け止めるべきものだろう。それでも、非エンジニアが自分の業務課題を自分で解決できるようになる価値は、外注コストの多寡にかかわらず大きいはずだ。

導入の決め手を聞くと、経営陣からはこんな言葉が返ってきている。「森山さんは1人でサービスを立ち上げて、インフラもチーム開発も全部やってきた。最新のAIも分かって、開発も一通り全部わかっている。これはもう森山さんしか日本にいないなと。2人で即決でした」。社内の懸念はゼロだったが、唯一の心配は「みんなついてこれるかな」だったという。結果は「いい意味で裏切られました。みんな、できる」という一言に集約されている。

この発表会を、単なる成果報告で終わらせない設計だったと私は思う。次の開発のキックオフに変える仕掛けが、随所に仕込まれていた。学んで終わりにせず、翌日から現場が変わっていく設計は投資対効果を最大化する。それがアウトバーンの研修が一番大切にしている価値なのだろう。

自社で研修を企画するなら今週動かす3つのこと

ここまでの設計を、自社研修を企画する際の判断軸に変換しておきたい。1つ目は、研修の目的を業務課題ベースで決められているかという点だ。レニクス社の8つのプロダクトはすべて「自分の業務の困りごと」から生まれている。抽象的な「AIを学ぶ」という目的設定では、この解像度には届かないだろう。まず社内のどの業務が一番の困りごとかを、今週中に書き出してみてほしい。

2つ目は、壊してもいい環境を用意できるかという点だ。本番コードやチームの基幹システムをいきなり触らせるのではなく、forkのようなコピー環境を用意できるかを確認しておく。この環境設計を怠ると、Day2で起きたような「壊してもいい」という心理的安全性は生まれにくい。

3つ目は、詰まった瞬間に聞ける伴走役を確保できているかという点だ。社内に「開発の流れを知っていて、かつ教えられる人」がいなければ、外部の講師を検討する必要が出てくる。オンデマンド教材だけで済ませようとする判断は、非エンジニア組織では特に裏目に出やすい。前の章までで見てきた通りだ。

この3つの軸は、どれも高額な設備投資を必要としない。必要なのは、業務課題の棚卸しと、壊してもいい環境の設計と、伴走できる人の確保という3点に尽きる。今週、社内の困りごとを1つ書き出すところから始めてみてほしい。私自身も、業務ツールを1つ作るたびに「誰の何の困りごとか」を最初に書き出すようにしている。この順番を飛ばすと、作った本人しか喜ばないツールになりやすいと実感しているからだ。

まとめ

半数以上がプログラミング未経験だったレニクス社のメンバーが、3日間で8つの実務アプリを完成させた。その成果を支えていたのは派手な機能や高価なツールではない。地図作りから始まり安心して壊せる場を経て、最後にテンプレートすら外して自走させるという設計の3段階だ。

• Day1で全体像という地図を教え、Day2でgitのforkを使い壊してもいい環境を作り、Day3でテンプレートを外してゼロから開発させた。制約を段階的に外していく順番が挫折を防いでいる。
• 独学や動画教材で非エンジニアがつまずくのは、詰まった瞬間の孤独と理解度の基準が示されないことが原因だった。伴走型研修はこの2つを人による調整で埋めている。
• 自社研修を企画するなら、判断軸は業務課題ベースの目的設定、壊してもいい環境の用意、伴走できる人の確保の3つだ。

かつてエンジニアを挫折した私にとって、この話は他人事ではない。AIが来れば、挫折した人間も、一度も触ったことがない人間も、もう一度手を動かせるようになる。今回の主役は個人ではなく組織だったが、越えている谷は私が越えてきた谷と同じものだと感じた。自社で研修を企画する立場にいる人には、まず身近な業務の困りごとを1つ選ぶところから始めてみてほしい。動き出した現場は、思っているより早く変わっていく。