AI SDLC PLATFORM
レガシーシステムを、 説明できるAI開発でWebへ。
仕様書のないAccess・VBAなどの現行資産から、業務意図を整理。 設計・実装・検証まで、AIの出力を人が工程ごとに確認しながら、 アリコーン株式会社が一貫して再構築を支援します。
- Access→Web案件で活用
- 7工程＋人の承認ゲート
- 成果物を相互に追跡
現行資産から、Webと説明可能な成果物へ
現行資産
画面・テーブル・帳票・VBA
AI-SDLC PLATFORM
- 01
- 02
- 03
- 04
- 05
- 06
- 07
各工程で人が確認・承認
Web＋成果物
仕様・設計・コード・テスト
要件 ↔ 設計 ↔ 実装 ↔ テストの対応関係を保持
CHALLENGE
移行を止めているのは、実装よりも「現行が分からない」こと。
仕様書が存在しない、または現行システムと一致していない
画面・クエリ・VBAに業務ルールが分散し、全体像を説明できない
現行調査だけで大きな工数がかかり、見積りや稟議が進まない
新システムが現行業務を再現できるか、検証の基準を作れない
だからアリコーンは、作り始める前に 現行資産から業務意図と判断基準を再構築します。
WHY ALICORN
アリコーンだからできる、3つのこと。
業務意図を再構築する
画面、テーブル、クエリ、帳票、VBAを棚卸しし、何を入力し、 どの条件で判断し、何を出力しているかを整理します。 コード変換だけでは見えない現行業務を、確認できる仕様へ戻します。
AIに任せきりにしない
AIは分析・文書化・実装・テストを支援しますが、工程の完了は 人が成果物を確認して判断します。承認されていない内容を、 次工程の前提として扱わない仕組みです。
説明できる成果物を残す
要件・設計・コード・テストを個別ファイルで終わらせず、 対応関係を保持します。変更理由と確認結果を追えるため、 引き継ぎ、レビュー、改修時の判断材料として利用できます。
7 CONTROLLED PHASES
7つの工程をつなぎ、工程ごとに人が承認する。
前工程で承認された成果物が、次工程の入力になります。 AIの出力を単発で利用するのではなく、アリコーンが工程全体を管理します。
-
01
要件分析
画面・データ・処理を棚卸しし、現行業務の目的とルールを整理。
成果物：現行仕様・業務ルール -
02
技術分析
構成、依存関係、制約を確認し、移行上の論点を明確化。
成果物：技術評価・論点 -
03
システム設計
承認済み要件をもとに、Web向けの画面・データ・構成を設計。
成果物：各種設計書 -
04
開発計画
作業単位、実施順序、依存関係、未決事項を整理。
成果物：計画・未決事項 -
05
開発実装
承認済み設計に基づいて実装し、変更内容を記録。
成果物：コード・変更記録 -
06
テスト検証
要件に対応するテストを整理し、実装結果を確認。
成果物：テスト仕様・結果 -
07
バグ管理
事象、原因、修正、再検証を関連付けて管理。
成果物：障害・再検証記録
各工程の終了時に、人の承認ゲート。
成果物を確認して承認、または理由を付けて差戻し。
判断前の内容が自動的に次工程へ進まないようにします。
TRACEABILITY
成果物が、次工程の入力になる。
文書を作って終わりではありません。要件からテストまでのつながりを保持し、 「なぜこの設計・実装・テストになったか」を確認できる状態を目指します。
- REQ 業務意図・要件何を実現し、何を守る必要があるか
- DES 設計要件をどの画面・データ・処理で実現するか
- DEV 実装承認済み設計をどこに実装したか
- TST テスト要件と実装をどの確認項目で検証したか
| 比較項目 | 単発の生成AI利用 | アリコーンのAI開発生産ライン |
|---|---|---|
| 工程間の引き継ぎ | 担当者が資料と指示を都度整理 | 承認済み成果物を次工程の入力として管理 |
| 完了判断 | 出力した時点で区切られやすい | 工程単位でレビューし、承認または差戻し |
| 成果物 | 会話・担当者単位に分散しやすい | 仕様・設計・コード・テストを工程別に整理 |
| 変更時の確認 | 影響箇所を人が探し直す | 成果物の対応関係から確認対象をたどる |
IN PRACTICE
AccessからWebへの再構築案件で活用しています。
現在、Access業務システムの画面・テーブル・クエリ・VBAを棚卸しし、 現行仕様を整理してからWeb向けの設計・実装・テストへ引き継ぐ工程で AI開発生産ラインを活用しています。対応可否と進め方は、資産構成を確認した上でご提案します。
SECURITY & DELIVERY
案件ごとの条件を明確にして進めます。
AIの利用条件や成果物の範囲を曖昧にせず、対象データ、利用環境、 確認方法、納品物を案件開始前に整理します。
データ取扱いを事前に合意
対象データ、利用するAIサービス、保存・持出し条件を確認し、 合意した運用ルールに沿って取り扱います。
利用条件を確認してAIを選定
入力データの学習利用条件や保持条件を確認し、 案件の要件に適した契約形態・利用方法を選びます。
人のレビューを工程に組み込む
AI出力をそのまま確定せず、工程ごとの確認・承認・差戻しを 作業手順として組み込みます。
納品範囲を契約で明確化
ソースコード、設計書、テスト記録など、引き渡す成果物と 保守・改修の範囲を案件ごとに明確にします。
START SMALL
まずは対象資産を確認し、判断材料をそろえます。
-
STEP 01
初回相談
現状の課題、対象システム、希望時期、制約条件を確認します。
-
STEP 02
簡易診断
画面、テーブル、処理、外部連携など、資産の構成と複雑度を確認します。
-
STEP 03
移行計画・PoC
必要に応じて対象を限定して検証し、進め方・範囲・成果物を具体化します。
-
STEP 04
本移行
合意した計画と承認条件に沿って、7工程を段階的に進めます。
FAQ
よくあるご質問
仕様書が残っていなくても相談できますか。
はい。画面、テーブル、クエリ、帳票、VBAなどの現行資産を確認し、 業務ルールを整理するところから進めます。資料の有無と資産の状態により、調査範囲をご提案します。
Access以外のシステムも対象になりますか。
現在はAccessからWebへの再構築案件で活用しています。 VB/VBA、Excel業務、クライアントサーバ型などは、構成を確認した上で対応可否を判断します。
移行先の技術や構成は選べますか。
運用体制、既存環境、セキュリティ、保守方針を踏まえて候補を整理します。 技術分析とシステム設計の工程で比較し、合意した構成へ進めます。
AIが生成した成果物の品質を、どのように確認しますか。
工程ごとに人が成果物をレビューし、承認されるまで次工程へ進めません。 また、要件・設計・実装・テストの対応関係を使い、確認対象と不足箇所をたどれるようにします。
データをAIへ入力しても問題ありませんか。
対象データと利用するAIサービスの条件を案件ごとに確認します。 必要に応じてマスキングやサンプルデータを使用し、合意した取扱い条件で進めます。
いきなり全体を移行せず、小さく確認できますか。
はい。簡易診断の後、必要に応じて対象機能を限定したPoCをご提案します。 判断材料をそろえた上で、本移行の範囲と進め方をご検討いただけます。
「現行が分からない」段階から、ご相談ください。
対象資産と課題を確認し、移行可否を判断するために必要な調査、 進め方、成果物をご説明します。
対応範囲、期間、費用、使用するAIサービス、データ取扱い条件は、 対象システムとご要望を確認した上で個別にご提示します。