CITIZEN DEVELOPMENT PROGRAM
ソフトウェアエンジニアではないけれど、メカ設計に携わり「業務をもっと良くしたい」という意欲のある人と一緒に、 社内アプリケーションを育てていく市民開発の取り組みです。AIとの壁打ちで要件を固め、プロトタイプを土台に、 最終的には本人が自走できる状態を目指します。
現場の課題を一番よく知っているのは現場の人。でも、それをアプリにする手段がこれまでありませんでした。
メカ設計の現場には「この作業、ツールがあれば楽になるのに」という改善アイデアが眠っています。しかしソフト開発の経験がないため、アイデアは手つかずのまま。IT部門に依頼するほどの規模でもなく、Excelマクロでは限界がある——そんな課題が積み残されていました。
生成AI(Claude・GitHub Copilot)の登場で状況が変わりました。コードを書けなくても、AIとの対話で要件を言語化し、資料を作り変え、プロトタイプを改善できます。この取り組みでは、その環境と最初の土台を用意し、現場の人が「自分の手で改善する」経験を積める仕組みを作っています。
コードを書いてから社内に届くまで、人の手作業はありません。GitHub に push すれば、あとは自動で社内URLが更新されます。
FIG. 1 — システム構成図(コードが社内に届くまで)
ポイント:push した瞬間から先はすべて自動。メンバーは「サーバー設定」や「デプロイ手順」を覚える必要がなく、アイデアを形にすることだけに集中できます。
コーディングの中心。AIエージェントに実装を任せながら、対話ベースで開発を進めます。
→ プロトタイプ開発・改修
ソースコードの管理と、push をトリガーにした自動ビルド・自動デプロイ。参加メンバーにはリポジトリのアクセス権限を付与します。
→ バージョン管理・自動デプロイ
社内に構築した仮想化基盤。アプリケーションのホスティング先として、必要に応じてVMを払い出せます。データが社外に出ない安心感も利点です。
→ アプリ実行基盤
作ったアプリは社内ドメインで公開。ブラウザからURLを開くだけで、誰でもすぐ使える状態で届けます。
→ 社内配信・利用
「main が壊れない仕組み」があるので、初心者でも安心して実験できます。作業は必ずブランチ(枝分かれしたコピー)の上で行い、確認してから合流させます。
FIG. 2 — ブランチ運用と自動デプロイの流れ
安心設計:実験は必ずブランチ上で行うため、途中で失敗しても公開中のアプリ(main)には一切影響しません。「壊すのが怖い」という初心者の最大の不安を、仕組みで取り除いています。
「聞く → 見える化 → 壁打ち → 作る → 渡す」の流れで、少しずつ本人の手に開発を移していきます。
まずは対話から。業務のどこに困りごとがあり、何が改善されると嬉しいのかをじっくり聞き取ります。
ヒアリング内容をもとに、要件定義書・システム構成図・UIモックの3つをHTMLで作成して渡します。「文章だけ」ではなく「見て触れる形」にすることで、認識のズレを早期に発見できます。
受け取った資料を、本人が GitHub Copilot に相談しながら読み込み、疑問点や違和感を洗い出します。AIとの対話を通じて「自分の要望を言語化する」練習にもなります。
壁打ちの結果を反映して、本人自身がAIの力を借りながら資料を修正。「これなら業務で使える」と納得できる形になったら、方向性を確定します。
確定した要件をもとに、私が動くプロトタイプを実装。GitHubにあげてアクセス権限を付与し、GitHub Actions 経由で社内ドメインにデプロイします。
実際に動くアプリを触りながら、AIと壁打ちして改善を続けます。コードもリポジトリも本人の手元にあるので、小さな修正から自分で挑戦でき、開発が「自分ごと」になっていきます。
3点セットにしている理由は、「何を・どう作り・どう見えるか」を一度に確認できるようにするためです。
アプリを1本作ることがゴールではありません。「現場が自分で改善し続けられる状態」を作ることがゴールです。
課題解決のスピードアップ現場の困りごとを、IT部門の順番待ちなしに、数週間単位でアプリとして形にします。
AIと協働できる人材の育成壁打ちを通じて「要望を言語化し、AIに伝え、成果物を評価する」スキルが自然に身につきます。これはツールが変わっても通用する力です。
自走する文化づくりコードとリポジトリを本人に渡し、権限を付与することで、開発が「頼むもの」から「自分でやるもの」に変わります。成功事例が増えるほど、次の挑戦者が生まれます。