社内構築基盤のすすめ

Transcript

1. 社内提案 社内環境基盤構築のすすめ 大規模開発の現場で実践した開発環境と AI 活用を、 リポジトリの clone 1 回で社内へ 2026 年 10 月 ／ 真矢昇陽
2. 提案の要点 現場で動いていた仕組みを、そのまま社内の標準に 何を なぜ どうやって 開発環境・AI 活用・ レビュー・教材の一式 環境づくりと品質を、 人に依存させない clone してセットアッ プを実行するだけ 用途別の 13 リポジトリとして、 すでに作って公開済み 大規模開発の現場で回ってい た進め方を、案件をまたいで まず 1 チームで試し、効果を 数字で確かめてから広げる 使える形にする 社内環境基盤構築のすすめ | 2
3. 背景と課題 開発の現場で、毎回同じところでつまずいている 1 環境づくりに時間がかかる 新しく参加した人が動く環境を作るまでに日数がかかる。手順 が人の頭の中にある 2 品質が人に依存する レビューの観点が人ごとに違う。表記や好みの指摘が、欠陥を探 す時間を奪う 3 AI の使い方がバラバラ 使い方の差が大きく、AI の出力を確かめる仕組みもない 社内環境基盤構築のすすめ | 3
4. 現場での実践 大規模システムの開発現場で、こう回していた 領域 やっていたこと 開発環境 ローカルはコンテナで DB とストレージを再現。クラウドは構成をコードで管理 開発プロセス 設計書から AI と計画 → 実装 → 単体テスト → レビュー。機械のゲートで裏付けを確認 レビュー 観点のチェックリストでレビューし、指摘を分類・蓄積して観点を育てる 進捗・会議 課題管理ツールから進捗レポートを作り、定例の議題を集める 教育 実際のソースを読む教材と演習で、新しく参加した人を立ち上げる 現場固有の名前・データは含めず、どの案件でも使える形に作り直しています 社内環境基盤構築のすすめ | 4
5. 提案する基盤 用途別の 13 リポジトリで、開発の流れを一通り支える 開発の土台 設計書を読む・比べる レビューと品質 dev-environment ai-coding doc-to-markdown design-diff office-review quality-analytics 資料づくり チームの運営 共通 slide-tool office-replace backlog-report slack-agenda-bot devtools-workspace devtools-common learning-materials 社内環境基盤構築のすすめ | 5 | すべて GitHub で公開済み・MIT ライセンス・CI で動作確認済み
6. 開発プロセス AI の出力は下書き。3 層で確かめてから進める 1 計画 2 実装 3 テスト 4 レビュー 5 PR 設計書から要 件の一覧 規約に沿って書く 要件ごとに確かめる AI と人の 2 段階 根拠を添えて出す 層 確かめること 誰が 機械のゲート ビルド・静的解析・カバレッジ・要件と実装／テストの対応 CI AI のレビュー 設計との整合・例外処理・規約 レビュー役の AI 人のレビュー 計画・設計判断・リリースの可否 担当者 社内環境基盤構築のすすめ | 6 | 自動修正は 3 回まで。ゲートを甘くして通す変更は禁止（ai-coding）
7. 品質の改善ループ 指摘を数字にして、レビューの観点を育てる 読む 比べる レビューする 分析する Office・PDF の設計書 を Markdown に 新旧の差分、設計書 と API 仕様のずれ 観点のチェックリス トと複数の役割 欠陥・ノイズ・確認 に分類、真因の偏り doc-to-markdown design-diff office-review quality-analytics  多い真因・観点を、チェックリスト・設計書のテンプレート・教材に戻す 社内環境基盤構築のすすめ | 7
8. 導入の手間 導入は clone とセットアップだけ 1 リポジトリ（devtools-workspace）を clone する 2 setup.cmd を実行する（全リポジトリの取得とツー ルのインストール） 前提として必要なもの Git・Python 3.12・JDK 17・Node.js・Rancher Desktop（すべて無料） 社内ネットワークから GitHub に接続でき ること（プロキシ・証明書） 3 VS Code で開き、Copilot Chat から呼び出す GitHub Copilot のライセンス 新しく参加した人は、教材サイトの「環境構築」の章をそのまま進めればよい 社内環境基盤構築のすすめ | 8
9. 費用 基本は無料。有料のものは、選んだときだけ 項目 費用 補足 ツールと環境（13 リポジト リ） 無料 MIT ライセンス。使うソフトもすべて無料 GitHub Copilot 既存のライセンス 業務文書を扱ってよい範囲を確認する 指摘の自動分類（LLM API） 任意：1,000 件で約 $0.4〜1.6 使わなくても、ルールと Copilot で無料で分類できる クラウド（AWS） 任意：使った分だけ ローカル環境だけでも開発できる Slack・Backlog 連携 既存の契約 Slack の Canvas 出力は有料プランが必要 社内環境基盤構築のすすめ | 9 | LLM API の費用は 2026-10-02 時点の公式料金表で試算
10. 効果と測り方 効果は、試行チームで測ってから約束する 期待する効果 測り方 目標 環境構築の短縮 新しく参加した人がサンプルアプリを動かすまでの時間 [__ 日 → __ 時間] レビューの効率化 指摘のうち表記・好み（ノイズ）の割合 [__% 以下] 欠陥の早期発見 成果物 1 ページあたりの欠陥指摘、真因の偏り [前回比 __%] 立ち上がりの短縮 教材の到達目標を満たすまでの期間 [__ 週間] 進捗報告の自動化 週次の進捗レポートにかかる手作業の時間 [__ 時間／週 → 0] 指摘の割合・密度は quality-analytics、進捗は backlog-report で自動で出せる 社内環境基盤構築のすすめ | 10
11. リスクと対策 情報の扱いと AI の誤りを、仕組みで抑える リスク 対策 業務・客先の情報の流出 客先固有の情報は基盤に入れない。実データと秘密情報はコミットしない。外部への送信 は明示したときだけ AI の出力の誤り 出力は下書き扱い。機械・AI・人の 3 層で確かめる 社内ネットワークで動かない 試行で詰まりどころを洗い出し、手順書と教材に反映する 使われずに終わる 試行で効果を数字にし、教材と勉強会で広げる 保守する人がいない 1 リポジトリ 1 役割で小さく保つ。壊れたら CI ですぐ分かる 社内環境基盤構築のすすめ | 11
12. 進め方 小さく試して、数字で広げるかを決める 1 か月目 2 か月目 3 か月目以降 試行 振り返り 展開 1 チームで環境とツールを使 い、作業時間と指摘を記録する 効果を測り、つまずいた手 順を直す。展開するかを判断 社内の GitHub に置き、教材 と勉強会で広げる 社内環境基盤構築のすすめ | 12
13. お願いしたいこと まず 1 チームで試させてください 1 試行チームの選定（[チーム名]・[人数]） 2 社内ネットワークから GitHub への接続の許可 3 Copilot で業務文書を扱ってよい範囲の確認 4 [__] 月の振り返り会の時間 社内環境基盤構築のすすめ | 13 | リポジトリ一覧と教材サイト: github.com/shoyo-maya-bot