第7章　内製化の成果と、保守業務へAIを広げられた条件を振り返る

内製化と期間短縮は、保守工程をつないだ結果だった

今回の変更では、異常条件と停止位置、再インストールの案内、OS側の問題との責務分界を整理し、正常系への変更を限定した。コード上の事実、処理構造、Excel仕様書を合わせ、承認済み仕様に基づく修正と単体テストまで実施した。

外部委託を不要にし、従来想定していた工期に対して約7割の期間短縮となった。委託時に必要となる見積・日程調整・受入確認・意図の伝達も、内製で進めることで省けた。

約7割という値は今回の想定工期との比較であり、各AIの効果を分離して測定した値ではない。

保守の調査から実装までを、人間の責任でつなぐ

＋の付いた項目を選ぶと、詳しい説明が下に表示されます。

気になる項目を選ぶと、その役割や判断理由を確認できます。

人が正常系への影響、安全性、工数、保守性、責務の範囲を前提として整理しました。GPTで選択肢や論点を検討し、コードや過去資料も必要に応じて確認しました。

GitHub Copilotで関連コードと呼出し関係、変更影響の候補を調べました。人が前後の処理や運用条件を照合し、今回必要な変更箇所と実現方法を絞りました。

コード上の事実、処理構造、Excel仕様書の整合を人がレビューしました。表が整っていることだけで正しいとは扱わず、承認した方針と正常動作への影響を確認しました。

コード・処理構造・仕様書の認識差分を確認しました。差分があれば調査と文書反映をやり直し、人の仕様レビューへ戻しました。差分がなければ承認済み仕様を前提に実装へ進みました。

GitHub Copilotで関数単位の修正案を生成し、人がレビュー・ビルド・単体テストを行いました。正常動作と変更範囲を確認し、問題があれば修正と再確認を行いました。

組織の審議・承認を経た仕様を、レビューと実装の前提として参照しました。AI間で情報を整理・受け渡す工程とは別に、組織として仕様を確定する工程を置きました。

既存動作と処理全体、関数間の関係を実装時の確認材料にしました。関数単体の生成に閉じず、入力の前提と後続処理への影響も人が確認しました。

コード調査と実装だけでなく、仕様検討、変更影響分析、過去背景の確認、文書化までAIを使える範囲が広がった。

AIの数を増やしたことより、異なるContextへアクセスできることと、確認した成果物を次の工程へ渡せたことが成立条件だった。

仕様検討には必要に応じて複数AIを用い、回答が食い違えば、その問いに適したContextへ戻った。情報を統合して採否を決める役割は人間に残した。

すべての出力を同じ深さで確認したわけではない。次工程でコードと照合できるプロンプトは、確認して修正不要ならそのまま使った。

一方、仕様案、処理構造、Excel、実装案、試験観点は設計へ影響するため、内容の確認を行った。最終コードのレビューと試験も省かなかった。

自然言語、コード、処理構造の図、Excelは、それぞれ問い・実装・順序と分岐・判断理由や試験項目を伝える媒体として使い分けた。形式の変換自体を成果とせず、人間が確認できる情報を次の作業へつなぐために利用した。

今回は変更範囲を限定できる異常系対応だった。

複数モジュールの大規模変更、アーキテクチャや業務フローの変更、多数の関係者との調整、コードと資料の大きな乖離では、同じ進め方で済むとは限らない。AIの情報アクセスが制約される場合や、高可用性・自動復旧を求める場合も、前提が変わる。

適用条件を見極め、必要なContextとレビューの境界を設計することが、今回の保守から他の仕事へ持ち出せる考え方である。