IN-HOUSE DEVELOPMENT SUPPORT

内製化支援

作って終わりにせず、判断できる状態を社内に残す。

IN-HOUSE・OVERVIEW

サービス概要

内製化支援は、システム開発の内製化（開発内製化）を進めたい企業に向けて、開発の判断基準や品質ゲート、進め方を文書にして社内に残し、契約が終わったあとも自分たちで開発を回せる状態を作る支援です。当社が代わりに作り続ける形は取りません。最終的に当社の担当欄が空になるところをゴールに置いています。独学で開発を始めた方や、これから開発に関わる方には、一般的な開発ライフサイクルを最初にひと通りお伝えします。要求整理 → 要件定義 → 設計 → 実装 → テスト → 受入 → リリース → 運用、という流れです。なぜこの工程があるのか、どこで何を判断するのか。ここが共有されないままAIツールだけ配っても、品質は安定しません。 AI時代に価値が出るのは、業務を深く知っているドメイン知識だと考えています。コードを書く手数はAIで補えるようになりましたが、「何を作るべきか」「この数値は業務上正しいか」を判断できるのは業務を知る人だけです。だから当社は、ドメイン知識を持つ社員の方が、AIを使って自分で開発を進められるようにする支援を得意にしています。

APPROACH

3つの支援領域

入口はAI駆動開発と開発標準の整備です。その標準をペアプロと実演で現場に移し、これから開発に関わる非エンジニアの方は育成の型で立ち上げます。3つは別々のメニューというより、「判断できる状態を残す」という一本の線でつながっています。

AI駆動開発・開発標準の整備

AI開発ツールの主軸を1つに決め、コーディング規約をルールファイルに書き出します。設計書をAIで生成してAI自身にレビューさせる反復、テストの自動生成、受入シナリオの書式統一まで、当社がチーム標準として回している型をお客様の環境に載せ替えます。工程ごとに「AIが主体」か「人が主体」かを決め切り、人が読む前に機械で落とす品質ゲートを先に作ります。

ペアプロ・実演型の知識移転

1対1のペアプロ、画面共有での進捗デモ、プロトタイプの先渡し、技術相談役の常設。この組み合わせで型を現場に移します。渡すものはコードというより、設計判断を説明できる状態、AIに任せたものの検証観点、AIへの指示の粒度、作業状態の残し方の4つです。会議記録のテンプレート、領域別の前提書（AI用の指示文書）、AIレビュー観点、中断・再開の記録など、「何を残すか」の型も実物でお渡しします。

ドメイン知識を持つ非エンジニアの育成

業務を知る社員の方を、AIを使って開発できる人材に育てます。章ごとに到達目標、扱う範囲（ここまでやる／ここから先はやらない）、確認手段を決めた育成の型があり、これをお客様の実システムと実業務に載せ替えます。入口では「今のAIで何ができて、何ができないのか」を揃える座学と、開発ライフサイクルの基礎講義を先に置きます。ここが揃っていないままツールを配ると、期待値がずれたまま進んでしまうからです。学習中のAI利用は禁止せず、使いこなす方向で設計しています。

STANDARD

工程ごとに「AIが主体」「人が主体」を決め切る

要求ヒアリングと受入・リリースは人が主体、要件整理からテストまではAIが主体。人に残るのは判断です。スコープの確定、アーキテクチャの決定、仕様の整合、受入の承認。この4つは人が担い、それ以外はAIに任せて機械で検証する、という線を最初に引きます。品質ゲートは5段にしています。ドキュメント → 静的検査（Lint・型） → テスト → 人のレビュー → 受入承認。AIの生成量が人のレビュー容量を超えると「全部読んで判断する」は破綻するので、人が読む前に機械で落とす層を先に作り、人のレビューは判断が必要な箇所に絞ります。順番が逆だと回りません。

工程	主体	人が担う判断
要求ヒアリング	人	何を解決したいのか、スコープの確定
要件整理・設計	AI（人が確認）	アーキテクチャの決定、仕様の整合
実装・テスト	AI（機械で検証）	ルールファイルと品質ゲートの設計
レビュー	機械 → 人	チェックリストに基づく観点の判断
受入・リリース	人	受入の承認（AIによる自動承認・自動マージは行わない）

MERIT

導入のメリット

契約終了後も、自走できる

判断基準、レビュー観点、品質ゲート、作業の残し方が、担当者の頭の中に留まらず文書として社内に残ります。当社が離れたあとに入った新しいメンバーも、同じ基準で開発を進められます。

ドメイン知識が、そのまま開発力になる

業務を深く知る人が、AIを使って要件整理から実装まで進められるようになります。「業務を知る人」と「作れる人」の間で起きていた翻訳のロスが消え、現場の判断がそのままシステムに反映されます。

AIを入れても、品質が崩れない型が手に入る

工程ごとのAI主体・人主体の線引き、5段の品質ゲート、ルールファイルによる規約の明文化。当社が実地で運用し、失敗も踏んだうえで整えた型を、お客様の環境に合わせて載せ替えます。

属人化しない育成

到達目標・扱う範囲・確認手段を先に決めるので、講師や担当者が変わっても判断がブレません。「教えられる人がいないから育たない」という状態から抜けられます。

STEPS

進め方

STEP 1
現状診断
開発ライフサイクルの理解度、設計書やレビュー体制の有無、AIツールの利用状況、社内にどんなドメイン知識を持つ人がいるか。これらを棚卸しして、「誰が何を判断できる状態か」を最初に見えるようにします。
STEP 2
開発標準と品質ゲートの設計
工程ごとのAI主体・人主体の線引き、AIに委ねない領域、AI生成コードの責任の線引きを決めます。ルールファイル、レビューチェックリスト、受入シナリオの書式を整え、人が読む前に機械で落とすゲートを組みます。
STEP 3
ペアプロ・実演での移転
初期画面やプロトタイプを先渡しし、月次のペアプロと進捗デモで並走しながら、設計判断を説明できるか、AIの出力をどう検証するかを実務の中で身につけていただきます。移していくのは判断の範囲です。
STEP 4
非エンジニア人材の立ち上げ
開発に関わり始める方には、「今のAIで何ができるか」の座学と開発ライフサイクルの基礎で期待値を揃えるところから始めます。そのうえで、到達目標つきの育成プログラムをお客様の実システム・実業務に載せて進めます。質問窓口はAIの一次回答と講師の二段構えです。
STEP 5
段階的な手離れ
各判断の担当欄から当社を段階的に外していきます。レビュー観点・品質ゲート・判断基準が社内文書として残り、お客様だけで回る状態を確認できたら、当社は技術相談役だけに退きます。

CASES

向いているケース・向いていないケース

向いているケース

・業務知識のある社員をシステム部門に異動させ、AIを使いながら開発できるよう育てたい・設計書がない、レビューできる上級者がいない状態でAIツールを入れようとしている・独学で開発を始めたメンバーに、一般的な開発の進め方をひと通り学ばせたい・外注に頼り切らず、契約終了後は自社で判断して開発を回したい

向いていないケース

・開発を丸ごと外注し、社内に判断できる人を残す前提がない・短期スポットの成果物納品だけを求めている・社内ポリシーで生成AIの利用が一切禁止されている

PITFALLS

型がないままAIを入れると、何が起きるか

どれも当社のグループ内で実際に起きたことです。設計書がなく、レビューできる上級者もいない状態でAIエージェントを入れると、品質はこういう形で崩れます。内製化支援では、この6つを最初から防ぐ型を用意します。

検証用に作ったものが、そのまま本番になる

AIだと手早く動くものが作れるので、「試しに作った」ものが検証を経ないまま本番に流れます。検証環境と本番の境界、受入の手順は最初に決めておく必要があります。

AIが品質ゲートそのものを書き換える

Lint検証側のコードをAIが書き換えて、ゲートが無効化されていた実例があります。「テストが通った」の意味が変わってしまうので、ゲートの変更には人の承認を必須にしています。

レビューできる人がいないと、レビューが止まる

生成物の量に対してレビューできる人が足りないと、レビュー待ちで止まるか、読まずに通すかの二択になります。だから機械で落とす層を先に作ります。

同じ指摘の繰り返しは、ルール化できていないサイン

レビューで何度も同じ指摘が出るなら、ルールファイルやチェックリストに落とすべき項目です。人の記憶に頼らず、AIが毎回読む文書に残します。

AIが直してしまうため、失敗から学ぶ経験が積まれない

エラーをAIが即座に直すと、なぜ起きたのかを理解する機会がなくなります。育成の場面では、直す前に原因を説明させる工程をわざと残しています。

表面的な解決で止まり、併せて考えるべき箇所が漏れる

目の前のエラーは消えても、同じ構造の別の箇所や、影響を受ける仕様が見落とされます。「併せて確認する箇所」をレビュー観点として書き出しておきます。

EXAMPLES

導入事例（一部紹介）

※ お客様の都合により、業種・規模・成果のみを匿名で紹介しています。

開発組織 / AI駆動開発の標準化上位エンジニアによる伴走・数ヶ月

AI開発ツール未経験のメンバーが中心のチームに、上位エンジニアが使い方の型（指示の出し方、工程ごとの進め方、出力の確認の仕方）を伝えました。並行して、ツールの主軸統一、ルールファイルによる規約の明文化、テスト自動生成を整備。

成果：メンバーがAI主導での開発を日常的に行うようになりました。レビューで繰り返されていた指摘はルールファイルとチェックリストに落ち、人のレビューは判断が必要な箇所に集中できています。

事業会社 / 新規プロダクトの立ち上げ初期画面の先渡し＋月次ペアプロ

初期画面を先渡しして、月1回のペアプロで担当者と並走。設計判断の説明、AIに任せた部分の検証観点、作業状態の残し方を、実務の中で少しずつ移していきました。

成果：数ヶ月で、担当者がプロダクトオーナーとの打合せ設定、スケジュール調整、役割分担の合意まで自力でこなせるようになりました。移ったのはコードより判断の範囲でした。

教育事業 / 非エンジニアのリスキリング非エンジニア数十名・継続運営中

非エンジニア向けのリスキリング型育成プログラムを、教材、進捗管理、チャットサポート、週次講習、個別面談まで一式で設計・運営しています。各章に到達目標・扱う範囲・確認手段を定め、質問窓口はAIの一次回答と講師の二段構えにしました。

成果：講師が変わっても判断がブレない構造で運営が続いています。つまずきの実データを見ると、停滞の主因はモチベーションより学習環境と設計にあることがわかり、環境構築と質問の言語化を支援する設計に改めました。

RESPONSIBILITY

AI生成コードの責任の線引き

AIが生成したコードの責任をどこで区切るかは、契約の初期に当社から明示します。曖昧なままだと、お客様も当社も判断が止まるからです。

最終的な受入・マージ承認は、お客様の担当者が行う

AIによる自動承認・自動マージはしません。判断の主体がお客様側に残ることが、内製化のゴールそのものです。

当社が提供するのは、レビュー観点と品質ゲートの設計・実行支援

生成されたコードの瑕疵担保を無限に負う構造は取りません。代わりに、瑕疵が本番に届かないゲートの設計と運用を支援します。

「AIに委ねない領域」を初期に線引きする

売上や在庫、棚卸のように数値を確定させる処理は、誤りの影響が大きいので、AIに任せない対象として最初に決めます。

当社の担当欄が空になる状態をゴールに置く

支援の各段階で「この判断は誰が担っているか」を見えるようにし、当社が担う欄を段階的に減らします。最後に残るのは技術相談役だけです。

AREA

東京・大阪で開発内製化の支援先を探している企業様へ

アットマーク・ソリューションは、東京本社（渋谷ヒカリエ）と大阪支社（大阪市中央区）を拠点に、開発内製化・システム内製化の支援を行っています。内製化のコンサルティングだけで終わらず、ペアプロや実演で現場に入り、判断基準と品質ゲートを社内に残すところまで伴走します。 DX推進の一環でシステム内製化を進めたい、業務部門から異動してきた社員をAIを使いながら育てたい、という段階からご相談いただけます。基本はリモートでの並走です。立ち上げ期や重要なフェーズでは、東京・大阪の拠点を活かした対面のペアプロや講習にも対応します。

FAQ

よくあるご質問

Q. エンジニア経験のない社員でも対象になりますか？

A. なります。むしろ業務を深く知っている方こそ対象です。入口で「今のAIで何ができるか」の座学と開発ライフサイクルの基礎を揃え、到達目標・扱う範囲・確認手段を決めた育成の型で立ち上げます。非エンジニア向けの育成プログラムをグループ内で継続運営してきた実績があります。

Q. 開発ライフサイクルをよく知らない、独学のメンバーが中心です。大丈夫ですか？

A. 大丈夫です。要求整理から運用までの一般的な開発ライフサイクルと、各工程で何を判断するのかを最初にひと通りお伝えします。なぜこの工程があるのかが共有されると、AIに任せる範囲と人が確認する範囲の線引きも自然に理解できます。

Q. 成果物として、何が残りますか？

A. コードに加えて、判断の型が残ります。開発標準としては、工程ごとのAI主体・人主体の定義、ルールファイル（コーディング規約）、AIレビュー観点とレビューチェックリスト、品質ゲートの定義。作業の残し方としては、会議記録テンプレート、領域別の前提書（AI用の指示文書）、中断・再開の記録の型です。

Q. 期間の目安はどのくらいですか？

A. 現状診断と開発標準の設計で数週間、ペアプロ・実演による移転は月次で数ヶ月から半年程度が一つの目安です。育成を含む場合は、対象人数と到達目標に応じて組みます。「当社の担当欄が空になる」までを見据えて、最初に段階的な手離れの計画を合意します。

Q. 既存の外注ベンダーがいる状態でも進められますか？

A. 進められます。ベンダーが担っている判断と、社内に移すべき判断を切り分けるところから始めます。目的はベンダーの置き換えより、レビューや受入の判断を社内でできる状態にすることです。

Q. ラボ型開発・AI駆動開発との違いは何ですか？

A. ラボ型開発は当社の専任チームが継続的に開発を担う形式で、AI駆動開発は当社が使っている開発スタイルです。内製化支援は、その開発スタイルと判断基準をお客様の社内に移し、最終的に当社が手を離すことを目的にしています。立ち上げ期はラボ型で並走し、内製化支援へ移行する組み合わせもできます。

Q. AIツールは何を想定していますか？

A. Claude Code や GitHub Copilot などのAIコーディングエージェント・支援ツールを想定していますが、特定のツールには縛りません。お客様のセキュリティポリシーに合わせ、商用契約版（学習に利用されないプラン）を前提に主軸のツールを1つ決め、そのうえで型を整えます。