実装工程において生成AIを活用できる箇所をフロー図にまとめています。
このページの見方と利用方法
実装工程において、作業者が製造チケットを受領してからチケット完了までの作業を可視化したものです。
生成AIを活用することができる項目については、クリック可能になっており、当サイトのカタログに遷移します。
※クリック可能な項目は随時拡充予定
実際のプロジェクトの状況と以下のフローを照らし合わせながら、生成AIを活用可能であれば有効活用してみてください。
製造チケット受領からチケット完了までの全体像
%%{init:{'theme':'neutral'}}%%
graph TB
A(製造チケット受領) ---> SG00_1
subgraph SG0 [00.作業前準備]
SG00_1 --> SG00_2
SG00_1 <-.-> SG00_3
subgraph SG00 [要件理解]
SG00_1(不明点/確認事項の洗い出し)
SG00_2(サブタスク分割)
SG00_3(有識者への確認)
end
SG00_2 --> SG012
SG00_2 --> SG01_2
subgraph SG01 [既存仕様の確認]
SG01_2(既存ソースコード)
SG01_2 -->|参照| SG011
subgraph SG011 [既存コード確認]
SG011_1(ライブラリ等の依存関係の確認)
SG011_2(ルーティングの確認)
SG011_3(関連処理等の影響範囲の確認)
SG011_4(既存コードの解説)
end
SG01_2 -->|参照| SG012
subgraph SG012 [既存設計書の参照]
SG012_1(画面遷移図):::doc
SG012_2(システム機能設計書):::doc
SG012_3(API一覧):::doc
SG012_4(共通コンポーネント設計書):::doc
SG012_5(外部インターフェース設計書):::doc
SG012_6(DB設計書):::doc
end
SG01_2 --> SG01_3
SG01_3(ディレクトリ構造の理解)
end
SG01 --> SG0_1(サブタスクの見積もり)
SG0_1 --> SG0_2(コーディングのための技術調査)
end
subgraph SG1 [01.コーディング]
SG01_3 -->|+要件| SG11_1
subgraph SG11 [雛形作成]
SG11_1(ファイル設置箇所、ファイル名を生成)
SG11_2(クラス、メソッドの生成)
end
subgraph SG12 [詳細実装]
SG12_1(要件からクラス、メソッドのベース処理を生成)
SG12_2(自然言語で実装内容を伝えコードを生成)
SG12_3(静的解析によるエラーの修正)
SG12_4(単体テスト仕様書作成)
end
SG0_2 --> SG11_2
SG11 --> SG12
SG12 -.-> SG1_2(責務配置の変更エスカレーション)
SG12 --> SG1_1{セルフレビュー}
SG1_1 -.->|レビューNG| SG12
SG1_1 -->|レビューOK| SG1_5(コミットメッセージを書く)
SG1_5 --> SG1_6{有識者コードレビュー}
SG1_6 -.->|レビューNG| SG12
end
SG1_6 -->|レビューOK| SG2_2(テストデータ準備)
subgraph SG2 [02.ユニットテスト]
SG2_2 --> SG2_3(ユニットテスト作成)
SG2_3 --> SG2_4{セルフレビュー}
SG2_4 -.->|レビューNG| SG2_3
SG2_4 -->|レビューOK| SG2_5(ユニットテスト実行)
SG2_5 -->|失敗| SG2_6(バグ修正)
SG2_5 -->|成功| SG2_7{有識者コードレビュー}
SG2_7 -.->|レビューNG| SG2_3
SG2_6 -.->|再実行| SG2_5
end
SG2_7 -->|レビューOK| SG3_1
subgraph SG3 [03.打鍵テスト]
SG3_1(テストデータ準備) --> SG3_2(打鍵テスト実施)
SG3_2 -->|OK| SG3_3{有識者レビュー}
SG3_2 -.->|NG| SG3_5(不具合管理表へ起票)
SG3_3 -.->|レビューNG| SG3_2
end
subgraph SG4 [04.作業後後処理]
SG3_3 -->|レビューOK| SG4_1(コードコメントを整形)
SG4_1 --> SG4_2(リファクタリング)
SG4_2 -.->|再実行| SG2_5
SG4_1 --> SG4_3(ドキュメント整形)
SG4_3 --> SG4_4{可読性・保守性を確認}
SG4_4 -.->|NG| SG4_8(変更管理チケット作成)
SG4_4 -->|OK| SG4_5{完了条件チェック}
SG4_5 -.->|NG| SG4_9(修正対応)
SG4_5 -->|OK| SG4_6{受け入れ確認}
SG4_6 -.->|NG| SG4_9
SG4_6 -->|OK| SG4_7(チケット完了)
end
%% 00.作業前確認
%% 不明点/確認事項の洗い出し
click SG00_1 "https://gen-ai-docs.jp/コンテンツ/カタログ/製造チケットから不明点確認事項を洗い出す"
%% サブタスク分割
click SG00_2 "https://gen-ai-docs.jp/コンテンツ/カタログ/製造チケットからサブタスクに分割する"
%% ディレクトリ構造の理解 座談会内のコンテンツ
click SG01_3 "https://gen-ai-docs.jp/コンテンツ/カタログ/ディレクトリ構造を理解する"
%% ライブラリ等の依存関係の確認
click SG011_1 "https://gen-ai-docs.jp/コンテンツ/カタログ/ライブラリ等の依存関係を教えてもらう"
%% ルーティングの確認 座談会内のコンテンツ
click SG011_2 "https://gen-ai-docs.jp/コンテンツ/カタログ/ルーティングを確認する"
%% 関連処理等の影響反映の確認
click SG011_3 "https://gen-ai-docs.jp/コンテンツ/カタログ/メソッド修正時の影響範囲を調べる"
%% 既存コードの解説
click SG011_4 "https://gen-ai-docs.jp/コンテンツ/カタログ/既存コードについて解説してもらう"
%% 画面遷移図
%%click SG012_1 "XXXX"
%% システム機能設計書
%%click SG012_2 "XXXX"
%% API一覧
%%click SG012_3 "XXXX"
%% 共通コンポーネント設計書
%%click SG012_4 "XXXX"
%% 外部インターフェース設計書
%%click SG012_5 "XXXX"
%% DB設計 データーベースの設計提案
%%%% DB設計 ER図の作成 "https://www.notion.so/gen-ai-doc/ER-ad24689b0d70474bbd93e7d171db54de?pvs=4"
%% click SG012_6 "XXXX"
%% サブタスクの見積もり
click SG0_1 "https://gen-ai-docs.jp/コンテンツ/カタログ/サブタスクの見積もりをする"
%% コーディングのための技術調査
click SG0_2 "https://gen-ai-docs.jp/コンテンツ/カタログ/公式ドキュメントやstack-overflowgithubのissueなどのurlを貼って要約してもらう"
%% 01.コーディング
%% ファイル設置箇所、ファイル名を生成
click SG11_1 "https://gen-ai-docs.jp/コンテンツ/カタログ/ファイル設置箇所ファイル名を提案してもらう"
%% 要件からベースクラス、ベースメソッドを生成
%%click SG11_2 "XXXX"
%% 要件からベースクラス、ベースメソッドを利用し処理を生成 近しいコンテンツ
click SG12_1 "https://gen-ai-docs.jp/コンテンツ/カタログ/要件からソースコードを生成してもらう"
%% 自然言語で実装内容を伝えコードを生成
click SG12_2 "https://gen-ai-docs.jp/%E3%82%B3%E3%83%B3%E3%83%86%E3%83%B3%E3%83%84/%E3%82%AB%E3%82%BF%E3%83%AD%E3%82%B0/%E8%87%AA%E7%84%B6%E8%A8%80%E8%AA%9E%E3%81%A7%E5%AE%9F%E8%A3%85%E5%86%85%E5%AE%B9%E3%82%92%E4%BC%9D%E3%81%88%E3%82%B3%E3%83%BC%E3%83%89%E3%82%92%E7%94%9F%E6%88%90%E3%81%97%E3%81%A6%E3%82%82%E3%82%89%E3%81%86"
%% 静的解析によるエラーの修正
click SG12_3 "https://gen-ai-docs.jp/コンテンツ/カタログ/静的解析のエラー対応方法を聞く"
%% 単体テスト仕様書作成
%%click SG12_4 "XXXX"
%% セルフレビュー
click SG1_1 "https://gen-ai-docs.jp/コンテンツ/カタログ/レビュー観点を定義してコードをレビューしてもらう"
%% コミットメッセージを書く
click SG1_5 "https://gen-ai-docs.jp/コンテンツ/カタログ/コミットメッセージ生成"
%%02.ユニットテスト
%% ユニットテストケース設計
%%click SG2_1 "XXXX"
%% テストデータ準備
click SG2_2 "https://gen-ai-docs.jp/コンテンツ/カタログ/テーブル定義を入力してテストデータ作成用のsqlを出力させる"
%% ユニットテスト作成
click SG2_3 "https://gen-ai-docs.jp/コンテンツ/カタログ/github-copilot-chatでユニットテストを生成する"
%% セルフレビュー
click SG2_4 "https://gen-ai-docs.jp/コンテンツ/カタログ/レビュー観点を定義してコードをレビューしてもらう"
%% ユニットテスト実行
%%click SG2_5 "XXXX"
%% バグ修正
%%click SG2_6 "XXXX"
%% 有識者レビュー
%%click SG2_7 "XXXX"
%%03.打鍵テスト
%% テストデータ準備
click SG3_1 "https://gen-ai-docs.jp/コンテンツ/カタログ/テーブル定義を入力してテストデータ作成用のsqlを出力させる"
%%04.作業後後処理
%% コードコメントを整形
click SG4_1 "https://gen-ai-docs.jp/コンテンツ/カタログ/エラーや問題点のある箇所の修正提案をもらう"
%% リファクタリング
click SG4_2 "https://gen-ai-docs.jp/コンテンツ/カタログ/クラスをリファクタリングしてもらう"
%% ドキュメント整形
click SG4_3 "https://gen-ai-docs.jp/コンテンツ/カタログ/javaクラスにjavadocを書いてもらう"
%% 可読性・保守性を確認
click SG4_4 "https://gen-ai-docs.jp/コンテンツ/カタログ/コードの効率性可読性保守性を採点してもらう"
classDef clickable fill:#e6f9e6,stroke:#333,stroke-width:2px,text-decoration:underline;
classDef doc fill:#f9f9f9,stroke:#333,stroke-width:2px;
%% 00.作業前確認
style SG0 stroke:#808080,stroke-width:4px;
%% 01.コーディング
style SG1 stroke:#0000FF,stroke-width:4px;
%% 02.ユニットテスト
style SG2 stroke:#008000,stroke-width:4px;
%% 03.打鍵テスト
style SG3 stroke:#FFA500,stroke-width:4px;
%% 04.作業ご確認
style SG4 stroke:#800080,stroke-width:4px;
各工程の詳細
00. 作業前準備
- 不明点/確認事項の洗い出し: 初期段階で、プロジェクトやタスクに関する不明点や必要な確認事項をリストアップします。これはプロジェクトを進行する上での疑問点を明確にし、後の段階での障害を回避するためのステップです。
- サブタスク分割: プロジェクトの主要なタスクをより小さく、管理しやすいサブタスクに分割します。これにより作業の優先順位付け、割り当て、追跡が容易になります。
- 有識者への確認: プロジェクトに関する専門的な知識や技術的な詳細について、チーム内外の有識者に確認します。技術的な課題の事前理解や、計画の妥当性を確認するために重要です。
- ライブラリ等の依存関係の確認: 使用しているライブラリやフレームワークの依存関係を確認し、互換性やセキュリティの問題がないことを確かめます。
- ルーティングの確認: アプリケーション内でのデータの流れやページ間の遷移を定義するルーティング設定を確認します。
- 関連処理等の影響範囲の確認: 開発中の機能が他の機能にどのような影響を与えるかを確認し、必要に応じて調整を行います。これにより、システム全体の安定性を維持します。
- 既存コードの解説: 既存のソースコードについて、その機能や構造などを理解するための解説を行います。
- 既存設計書の参照: プロジェクトの設計に関する既存の文書、例えば画面遷移図、機能設計書、API一覧、コンポーネント設計書、外部インターフェース設計書、DB設計書などを参照します。これにより、プロジェクトの設計理解を深め、作業の基盤を固めます。
- ディレクトリ構造の理解: プロジェクトのディレクトリ構造を理解し、ファイルやコードがどのように整理されているかを把握します。新たなコードの追加や既存コードの修正において、適切な場所を見つけやすくするために重要です。
- サブタスクの見積もり: 分割したサブタスクごとに、必要な作業量や期間を見積もります。これにより、プロジェクト全体のスケジュール計画を立てるための基礎情報を提供します。
- コーディングのための技術調査: 実装を始める前に、必要な技術やツールに関する調査を行います。これには、新しいライブラリの学習、フレームワークの特性の理解、または特定の問題を解決するための最良のアプローチの探求が含まれます。
01. コーディング
- ファイル設置箇所、ファイル名を生成: 新しく追加するコードファイルの適切なディレクトリとファイル名を決定します。これは、プロジェクトの整理と可読性を保つために重要です。
- クラス、メソッドの生成: 新しい機能や修正に必要なクラスやメソッドを定義し、基本的な枠組みを作成します。この段階では、実装の詳細よりも構造に焦点を当てます。
- 要件からクラス、メソッドのベース処理を生成: 具体的な要件に基づいて、クラスやメソッドのベース処理を実装します。
- 自然言語で実装内容を伝えコードを生成: 設計や要件をコードに変換する際に、実装する機能やアルゴリズムを自然言語で記述し、それをもとにコードを生成します。
- 静的解析によるエラーの修正: コードをコンパイルまたは実行する前に、静的解析ツールを使用して潜在的なエラーやコーディング規約の違反を検出し、修正します。
- 単体テスト仕様書作成: 実装した機能が仕様通りに動作することを確認するために、単体テストケース、ユニットテスト・打鍵テストの仕様書を作成します。
- 責務配置の変更エスカレーション: コードの責務配置について疑問や変更が必要な場合、それを上位の決定権者やチームにエスカレーションします。
- セルフレビュー: セルフレビューを通じて、コーディング規約の遵守、ロジックの正確性、不要なコードの削除などを確認します。
- コミットメッセージを書く: 変更内容を明確に伝えるための適切なコミットメッセージを書きます。これにより、プロジェクトの履歴がわかりやすくなります。
- 有識者コードレビュー: チーム内外の有識者にコードをレビューしてもらい、改善点やバグを特定します。これにより、コードの品質とプロジェクトの整合性が保たれます。
02. ユニットテスト
- テストデータ準備 (ユニットテスト用): ユニットテストを実行するために必要な入力データや条件を準備します。
- ユニットテスト作成: テストケースに基づいてユニットテストを作成し、コードの正確性を検証します。
- セルフレビュー (ユニットテスト用): 作成したユニットテストが適切であるかを自己評価し、テストのカバレッジやロジックに問題がないかを確認します。これにより、テストの信頼性と効率性を高めます。
- ユニットテスト実行: 実装したユニットテストを実行し、コードが予定通りに動作するかを検証します。失敗したテストはコードの潜在的な問題を示しているため、特に注意が必要です。
- バグ修正: ユニットテストの結果をもとに、失敗したテストに対応するコードのバグを特定し、修正します。このプロセスは、品質を確保するために不可欠です。
- 有識者コードレビュー(ユニットテスト用): チーム内外の有識者にコードをレビューしてもらい、改善点やバグを特定します。これにより、コードの品質とプロジェクトの整合性が保たれます。
03. 打鍵テスト
- テストデータ準備 (打鍵テスト用): 打鍵テストを実行するために必要なデータや条件を準備します。
- 打鍵テスト実施: テストケース通りに打鍵テストを実施します。システムが仕様通りに機能するかを検証します。画面キャプチャ、DBダンプを取得します。
- 有識者レビュー (打鍵テスト用): 打鍵テストの結果をレビューし、実際のテスト仕様書の内容を満たしているかを確認します。不適合があれば、テストの修正や追加が必要になります。
- 不具合管理表へ起票: テスト中に発見された問題やバグは、不具合管理表に記録し、追跡および修正が行われます。これにより、問題の解決状況を明確にし、プロジェクト全体の品質管理を効率的に行います。
04. 作業後後処理
- コードコメントを整形: コード内のコメントを見直し、必要に応じて追加や更新を行います。これは、後からコードを読む人が理解しやすくするために重要です。
- リファクタリング: コードの構造やデザインを改善するために、リファクタリングを行います。これにより、コードの可読性、保守性、拡張性が向上します。リファクタリングでコードの修正がある場合はユニットテストを再実行します。
- ドキュメント整形: プロジェクトのドキュメントを最終確認し、必要な情報の追加や更新を行います。これにより、ドキュメントの正確性と有用性を保証します。
- 可読性・保守性を確認: コードとドキュメントの両方に対して、可読性や保守性の最終チェックを行います。問題があれば、変更管理チケットを作成する。
- 変更管理チケット作成: プロジェクトの変更点や改善点を明確に記録し、将来の参照やアクションのために変更管理チケットを作成します。担当者で修正はせず、チケットを作成する。
- 完了条件チェック: 完了条件チェックリストを元にチェックをします。完了条件を満たしていない場合は、修正対応をする。
- 受け入れ確認: クライアントやプロジェクトのステークホルダーに成果物を提示し、受け入れテストや最終確認を行います。ここでのフィードバックに基づき、さらなる改善が必要な場合は対応します。
- 修正対応: 完了条件チェック、受け入れ確認の過程で見つかった問題や不備に対して、必要な修正を行います。このプロセスは、プロジェクトを最終的な完成状態に導くために重要です。
- チケット完了: チケットのタスク(サブタスク含)が完了し、受け入れ確認が成功したら、チケットを完了とします。