新型Acsimスタートガイド
新型Acsimを初めて利用するときの基本的な進め方を説明します
新型Acsimスタートガイド
新型Acsimは、AIポータルと目的別エージェントを起点に、要件定義に必要な情報整理、業務フロー作成、要求管理、設計書作成、見積、テスト、開発連携までを一気通貫で進めるための環境です。
このガイドでは、初めて新型Acsimを使う方向けに、最初のプロジェクト作成からAIエージェントの活用までの基本的な流れを説明します。
1. ワークスペースからプロジェクトを作成する
ログイン後、ワークスペース画面で対象のワークスペースを開き、プロジェクト新規作成 からプロジェクトを作成します。
作成時に入力する主な項目は以下です。
プロジェクト名説明プロジェクト言語エージェントフロー
説明 には、対象業務、対象システム、検討目的、現時点で分かっている前提条件を書いておくと、後続のAI依頼や関係者レビューで文脈を共有しやすくなります。
エージェントフロー は、特別な指定がない場合は Acsim標準 のフローを選択してください。Acsim標準フローには、要件定義から開発連携までの代表的なエージェントが含まれています。
2. プロジェクト概要を確認する
プロジェクト作成後は、左サイドバーの プロジェクト概要 で、プロジェクト名、説明、ステータス、プロジェクト言語を確認します。
説明が曖昧なままだと、AIが前提を補いながら回答する場面が増えます。対象範囲、背景、成果物の目的が分かってきたら、プロジェクト概要を更新しておくことをおすすめします。
3. 参照資料を登録する
AIポータルやエージェントに依頼する前に、プロジェクトの前提となる資料を登録します。
資料の置き場所は、用途に応じて使い分けます。
| 登録先 | 主な用途 |
|---|---|
ファイル管理 | RFP、業務マニュアル、議事録、既存設計書、画面仕様書など、プロジェクトで扱うファイルを整理する |
ナレッジベース | SaaS仕様、設計標準、社内ルール、レビュー観点など、AIに継続的に参照させたい知識を登録する |
ホワイトボード | 業務やシステムの構想を図やメモで整理する |
ファイル管理 では、ファイルアップロード、フォルダアップロード、Markdown作成、ホワイトボード追加ができます。
ナレッジベース は、会社内またはプロジェクト内の公開範囲で作成できます。AIに参照させたい業務知識や標準資料は、ナレッジベースとして登録しておくと、エージェントの回答や成果物生成に反映しやすくなります。
4. AIポータルで最初の相談をする
資料を登録したら、左サイドバーの AIポータル を開きます。
AIポータルでは、会話履歴をスレッドとして管理できます。新しい相談を始める場合は 新規 からスレッドを開始します。
最初は、エージェントを細かく選ばずに、目的と参照してほしい資料を自然言語で伝えるのがおすすめです。Acsim標準フローでは、依頼内容に応じてオーケストレーターが適切なエージェントへ振り分けます。
依頼例はそのまま使う必要はありません。対象業務、ヒアリング相手、確認したい観点に合わせて調整してください。
目的が明確な場合は、左側のエージェント一覧から対象のエージェントを選んで依頼することもできます。
5. 初回におすすめの進め方
新型Acsimは、必ずしも決まった順番で使う必要はありません。ただし、初回は以下の流れで進めると、要件定義の全体像をつかみやすくなります。
5-1. 壁打ち・整理
壁打ち・整理 エージェントで、プロジェクトの背景、目的、対象業務、ヒアリングの論点を整理します。
まだ資料が少ない段階でも、何を確認すべきか、どこから着手すべきかを相談できます。
5-2. ヒアリング相談
顧客や現場部門へのヒアリング前には、ヒアリング相談 エージェントで質問リストや確認観点を整理します。
RFP、既存資料、業務マニュアル、議事録などを参照させると、より具体的な質問に落とし込みやすくなります。
現場ヒアリングでは、ゼロから業務内容を聞き始めると、細かい話に入りすぎて全体像が整理しにくくなることがあります。効率よく業務フローを作成したい場合は、ヒアリング前にAIポータルで業務フローの叩き台を作り、その叩き台をもとに深掘り項目やヒアリング項目を考えてもらう進め方がおすすめです。
たとえば、まずAIポータルで対象業務の流れを箇条書きで整理し、AsIs業務フローの叩き台を作成します。その後、作成した叩き台の業務フロー名を明示してAIポータルに依頼すると、実態との差分、例外処理、担当者の判断基準、暗黙知になりやすい箇所を確認する質問に分解してもらえます。
依頼例は一例です。対象業務、作成済みの業務フロー名、ヒアリング相手、確認したい観点に合わせて変更してください。
詳しい進め方は現場ヒアリングを効率化する業務フローの叩き台作成も確認してください。
5-3. AsIs業務フロー作成
現行業務を可視化する場合は、AsIs業務フロー作成 エージェントを使います。
PDF、Word、Excel、テキスト、業務フロー図、議事録などをもとに、AsIs業務フローを作成できます。作成後は 業務分析 > AsIs > 業務フロー で内容を確認します。
既存のAsIs業務フローを修正したい場合は、AsIs業務フロー変更 エージェントで変更提案を作成できます。
5-4. 現状業務の把握
AsIs業務フローができたら、現状業務の把握 エージェントで、複雑度、ボトルネック、自動化可能性などの観点から現状業務を分析します。
分析結果は、ToBe検討や変更方針の材料として使います。
5-5. 変更方針・変更計画
改善の方向性を決める場合は、変更方針 と 変更計画 を使います。
変更方針 では、AsIs業務フロー、現状業務の分析結果、ヒアリング内容、導入予定のSaaSや業務ルールをもとに、どの方向で業務やシステムを変えるかを整理します。
初版からAIポータルに変更方針を提案してもらうこともできますが、まずは対象業務に対してユーザーや関係者が考えている改善アイデア、素案、要望をAIポータルに渡し、変更方針として整理してもらう進め方がおすすめです。
たとえば「承認に時間がかかっているので通知を自動化したい」「Excelで二重入力している作業をなくしたい」「SaaS標準機能に合わせて業務を簡素化したい」といった粒度で構いません。最初は粗いアイデアでも、AIに対象業務、現状課題、変更内容、期待効果、未確定事項へ分解してもらうことで、後続の変更計画やToBe業務フローに使いやすい形へ整えられます。
変更方針は、単なる概要メモではなく、AIが意味のある変更計画へ分解するための設計指示です。以下の観点を含めると、後続のToBe業務フローや要求分析につなげやすくなります。
- 対象業務・対象範囲
- 現状課題と発生箇所
- 作業時間、件数、発生頻度などの定量情報
- 何をやめ、何を追加し、何を自動化・標準化するか
- 利用予定のシステム、SaaS、既存機能
- 人が判断する範囲とシステムが処理する範囲
- 例外対応、承認条件、通知条件などの業務ルール
- 期待効果と確認指標
- 未確定事項や制約
変更計画 では、変更方針をもとに改善計画アイテムを作成し、プロジェクト全体の変更内容を具体化します。たとえば「銀行入金明細を自動取込する」「照合ルールに合わない入金は担当者確認に回す」「消込結果を未入金一覧へ反映する」のように、業務やシステムの変更を実行可能な単位へ分けます。
作成した内容は 業務分析 > ToBe > 変更方針 で確認します。変更計画が具体化できたら、ToBe業務フロー作成やToBe業務フロー変更の入力として使います。
迷った場合は、AIポータルで以下のように依頼します。プロンプトは一例なので、対象業務、改善アイデア、使いたいSaaSやシステム、確認したい観点に合わせて変更してください。
5-6. ToBe業務フロー作成
あるべき業務の流れを整理する場合は、ToBe業務フロー作成 エージェントを使います。
AsIs業務フローがある場合は、その分析結果や変更方針を参照してToBeを作成します。AsIsがない場合でも、資料やテキストから直接ToBe業務フローを作成できます。
既存のToBe業務フローを修正したい場合は、ToBe業務フロー変更 エージェントで変更提案を作成できます。
5-7. 要求分析
AsIsとToBeの差分が見えてきたら、要求分析 エージェントで要求を洗い出します。
要求は 要件設計 > 要求管理 に登録され、対応種別、対応方針、効果、想定工数などを管理できます。
6. 設計書・見積・テストへ展開する
要求や業務フローが整理できたら、目的に応じて設計系エージェントを使います。
設計書作成では、要求、AsIs/ToBe業務フロー、変更方針、変更計画、ナレッジベース、既存設計書が主な入力になります。AIが作成する設計書は初版なので、プロジェクトの前提や顧客固有の制約を人が確認して仕上げます。
初回は、いきなり詳細設計書を作るよりも、以下の順に進めると手戻りを減らしやすくなります。
業務・非機能要件定義書で、業務要件、非機能要件、システム基本設計のたたき台を作る画面・機能一覧で、対象画面、機能、バッチ、通知、帳票などの一覧を作るDB・API設計で、データ構造や外部連携の前提を整理する画面・機能設計で、画面設計書、機能設計書、バッチ設計書、通知設計書などを作るインフラ・セキュリティ設計と運用移行設計で、非機能・運用・移行の観点を補強する見積作成で、実装対象、前提条件、除外事項、リスク、概算工数を整理する結合テスト、システムテスト、受入テストで、要求や設計書に対応するテスト仕様を作る
代表的なエージェントは以下です。
| エージェント | 作成・整理する主な内容 | 事前にあるとよい情報 |
|---|---|---|
業務・非機能要件定義書 | 業務要件定義書、非機能要件定義書、システム基本設計書 | 要求、AsIs/ToBe業務フロー、変更方針 |
画面・機能一覧 | 画面一覧、機能一覧、バッチ一覧、通知一覧、帳票一覧 | ToBe業務フロー、要求一覧、対象システムの範囲 |
DB・API設計 | DB設計書、API設計書、アーキテクチャ設計書 | 機能一覧、外部連携要件、既存システム情報 |
画面・機能設計 | 画面設計書、機能設計書、バッチ設計書、通知設計書、帳票設計書 | 画面一覧、機能一覧、業務ルール |
インフラ・セキュリティ設計 | インフラ設計書、セキュリティ設計書、メッセージリソース定義書 | 非機能要件、利用環境、認証・権限方針 |
運用移行設計 | 移行設計、運用設計、障害対応、性能、バックアップリカバリ関連の設計書 | 現行運用、移行対象、運用体制、制約条件 |
見積作成 | 概算見積書、見積前提、リスク、除外事項 | 要求一覧、設計書、実装範囲、対応方針 |
結合テスト、システムテスト、受入テスト | テスト仕様書、テストケース一覧、確認観点 | 要求、画面・機能設計、業務フロー、受入条件 |
作成した設計書は 仕様設計 > 基本設計書 や関連メニューから確認します。
設計書・見積・テストへ展開するときは、以下を確認しながら進めてください。
- 要求と設計書の対応関係が追えるか
- 見積対象とスコープ外が明確か
- 未確定事項や顧客確認事項が設計書や見積前提に残っているか
- テスト仕様が要求や業務フローの重要な分岐をカバーしているか
- AIが補った前提と、プロジェクトで合意済みの前提が混ざっていないか
作成できる成果物の全体像は成果物一覧も確認してください。
7. プロトタイプを作成する
画面や機能の情報が整理できたら、プロトタイプ > プロトタイプ生成 で画面プロトタイプ作成に必要な情報を準備できます。
プロトタイプ作成には、v0を利用できます。Acsim上でv0のAPIキーを設定すると、Acsimからv0へスムーズにプロトタイプ作成を依頼できます。
一方で、APIキーは漏洩すると第三者に利用される可能性があり、情報管理上のリスクがあります。APIキーの発行や管理に不安がある場合は、効率性は少し落ちますが、Acsimから出力した各種情報をv0に添付して依頼する方法がおすすめです。
添付する情報の例は以下です。
- ToBe業務フロー図のJSON
- 画面一覧のCSV
- 機能一覧のCSV
- デザイン仕様書
- 補足したい業務ルールや画面イメージのメモ
v0にファイルを添付し、「添付したToBe業務フロー、画面一覧、機能一覧、デザイン仕様書をもとに、確認用の画面プロトタイプを作成してください」と依頼します。
APIキーを利用する場合も、手動でファイルを添付する場合も、v0で作成したものは本番実装ではなく、画面イメージや操作感を確認するためのプロトタイプとして扱ってください。
詳しい手順はv0操作ガイドも確認してください。
8. 開発連携へ進める
設計書や要求を開発へつなげる場合は、開発連携 のメニューを使います。
| 目的 | 利用するメニューまたはエージェント |
|---|---|
| 技術仕様を作る | 技術仕様書作成 |
| 開発Epicを作る | Epic作成、または 開発連携 > 開発Epic作成 |
| Issue作成に向けた実行計画を作る | Issue作成 |
| GitHubと連携する | 開発連携 > GitHub連携設定 |
| Devinと連携する | 開発連携 > Devin連携 |
開発連携の詳細は開発連携ガイドも確認してください。
9. AIの出力を確認して仕上げる
新型Acsimでは、AIエージェントが初版作成、選択肢提示、抜け漏れ防止を支援します。一方で、最終的な判断、調整、品質担保は人が行う前提です。
AIが作成した成果物は、以下の観点で確認してください。
- プロジェクトの前提やスコープに合っているか
- 業務の例外や分岐が抜けていないか
- 用語が関係者間で統一されているか
- 顧客や現場部門がレビューできる粒度になっているか
- 後続の設計、見積、開発、テストに必要な情報が足りているか
修正したい場合は、AIポータルや対象画面のチャットで具体的に依頼します。
10. 次に読むページ
新型Acsimの全体像を深く理解したい場合は、以下のページを確認してください。