実装工程において生成AIを活用できる箇所をフロー図にまとめています。
- このページの見方と利用方法
- 製造チケット受領からチケット完了までの全体像
- 各工程の詳細
- 00. 作業前準備
- 01. コーディング
- 02. ユニットテスト
- 03. 打鍵テスト
- 04. 作業後後処理
このページの見方と利用方法
実装工程において、作業者が製造チケットを受領してからチケット完了までの作業を可視化したものです。
生成AIを活用することができる項目については、クリック可能になっており、当サイトのカタログに遷移します。
※クリック可能な項目は随時拡充予定
実際のプロジェクトの状況と以下のフローを照らし合わせながら、生成AIを活用可能であれば有効活用してみてください。
製造チケット受領からチケット完了までの全体像
各工程の詳細
00. 作業前準備
- 不明点/確認事項の洗い出し: 初期段階で、プロジェクトやタスクに関する不明点や必要な確認事項をリストアップします。これはプロジェクトを進行する上での疑問点を明確にし、後の段階での障害を回避するためのステップです。
- サブタスク分割: プロジェクトの主要なタスクをより小さく、管理しやすいサブタスクに分割します。これにより作業の優先順位付け、割り当て、追跡が容易になります。
- 有識者への確認: プロジェクトに関する専門的な知識や技術的な詳細について、チーム内外の有識者に確認します。技術的な課題の事前理解や、計画の妥当性を確認するために重要です。
- ライブラリ等の依存関係の確認: 使用しているライブラリやフレームワークの依存関係を確認し、互換性やセキュリティの問題がないことを確かめます。
- ルーティングの確認: アプリケーション内でのデータの流れやページ間の遷移を定義するルーティング設定を確認します。
- 関連処理等の影響範囲の確認: 開発中の機能が他の機能にどのような影響を与えるかを確認し、必要に応じて調整を行います。これにより、システム全体の安定性を維持します。
- 既存コードの解説: 既存のソースコードについて、その機能や構造などを理解するための解説を行います。
- 既存設計書の参照: プロジェクトの設計に関する既存の文書、例えば画面遷移図、機能設計書、API一覧、コンポーネント設計書、外部インターフェース設計書、DB設計書などを参照します。これにより、プロジェクトの設計理解を深め、作業の基盤を固めます。
- ディレクトリ構造の理解: プロジェクトのディレクトリ構造を理解し、ファイルやコードがどのように整理されているかを把握します。新たなコードの追加や既存コードの修正において、適切な場所を見つけやすくするために重要です。
- サブタスクの見積もり: 分割したサブタスクごとに、必要な作業量や期間を見積もります。これにより、プロジェクト全体のスケジュール計画を立てるための基礎情報を提供します。
- コーディングのための技術調査: 実装を始める前に、必要な技術やツールに関する調査を行います。これには、新しいライブラリの学習、フレームワークの特性の理解、または特定の問題を解決するための最良のアプローチの探求が含まれます。
01. コーディング
- ファイル設置箇所、ファイル名を生成: 新しく追加するコードファイルの適切なディレクトリとファイル名を決定します。これは、プロジェクトの整理と可読性を保つために重要です。
- クラス、メソッドの生成: 新しい機能や修正に必要なクラスやメソッドを定義し、基本的な枠組みを作成します。この段階では、実装の詳細よりも構造に焦点を当てます。
- 要件からクラス、メソッドのベース処理を生成: 具体的な要件に基づいて、クラスやメソッドのベース処理を実装します。
- 自然言語で実装内容を伝えコードを生成: 設計や要件をコードに変換する際に、実装する機能やアルゴリズムを自然言語で記述し、それをもとにコードを生成します。
- 静的解析によるエラーの修正: コードをコンパイルまたは実行する前に、静的解析ツールを使用して潜在的なエラーやコーディング規約の違反を検出し、修正します。
- 単体テスト仕様書作成: 実装した機能が仕様通りに動作することを確認するために、単体テストケース、ユニットテスト・打鍵テストの仕様書を作成します。
- 責務配置の変更エスカレーション: コードの責務配置について疑問や変更が必要な場合、それを上位の決定権者やチームにエスカレーションします。
- セルフレビュー: セルフレビューを通じて、コーディング規約の遵守、ロジックの正確性、不要なコードの削除などを確認します。
- コミットメッセージを書く: 変更内容を明確に伝えるための適切なコミットメッセージを書きます。これにより、プロジェクトの履歴がわかりやすくなります。
- 有識者コードレビュー: チーム内外の有識者にコードをレビューしてもらい、改善点やバグを特定します。これにより、コードの品質とプロジェクトの整合性が保たれます。
02. ユニットテスト
- テストデータ準備 (ユニットテスト用): ユニットテストを実行するために必要な入力データや条件を準備します。
- ユニットテスト作成: テストケースに基づいてユニットテストを作成し、コードの正確性を検証します。
- セルフレビュー (ユニットテスト用): 作成したユニットテストが適切であるかを自己評価し、テストのカバレッジやロジックに問題がないかを確認します。これにより、テストの信頼性と効率性を高めます。
- ユニットテスト実行: 実装したユニットテストを実行し、コードが予定通りに動作するかを検証します。失敗したテストはコードの潜在的な問題を示しているため、特に注意が必要です。
- バグ修正: ユニットテストの結果をもとに、失敗したテストに対応するコードのバグを特定し、修正します。このプロセスは、品質を確保するために不可欠です。
- 有識者コードレビュー(ユニットテスト用): チーム内外の有識者にコードをレビューしてもらい、改善点やバグを特定します。これにより、コードの品質とプロジェクトの整合性が保たれます。
03. 打鍵テスト
- テストデータ準備 (打鍵テスト用): 打鍵テストを実行するために必要なデータや条件を準備します。
- 打鍵テスト実施: テストケース通りに打鍵テストを実施します。システムが仕様通りに機能するかを検証します。画面キャプチャ、DBダンプを取得します。
- 有識者レビュー (打鍵テスト用): 打鍵テストの結果をレビューし、実際のテスト仕様書の内容を満たしているかを確認します。不適合があれば、テストの修正や追加が必要になります。
- 不具合管理表へ起票: テスト中に発見された問題やバグは、不具合管理表に記録し、追跡および修正が行われます。これにより、問題の解決状況を明確にし、プロジェクト全体の品質管理を効率的に行います。
04. 作業後後処理
- コードコメントを整形: コード内のコメントを見直し、必要に応じて追加や更新を行います。これは、後からコードを読む人が理解しやすくするために重要です。
- リファクタリング: コードの構造やデザインを改善するために、リファクタリングを行います。これにより、コードの可読性、保守性、拡張性が向上します。リファクタリングでコードの修正がある場合はユニットテストを再実行します。
- ドキュメント整形: プロジェクトのドキュメントを最終確認し、必要な情報の追加や更新を行います。これにより、ドキュメントの正確性と有用性を保証します。
- 可読性・保守性を確認: コードとドキュメントの両方に対して、可読性や保守性の最終チェックを行います。問題があれば、変更管理チケットを作成する。
- 変更管理チケット作成: プロジェクトの変更点や改善点を明確に記録し、将来の参照やアクションのために変更管理チケットを作成します。担当者で修正はせず、チケットを作成する。
- 完了条件チェック: 完了条件チェックリストを元にチェックをします。完了条件を満たしていない場合は、修正対応をする。
- 受け入れ確認: クライアントやプロジェクトのステークホルダーに成果物を提示し、受け入れテストや最終確認を行います。ここでのフィードバックに基づき、さらなる改善が必要な場合は対応します。
- 修正対応: 完了条件チェック、受け入れ確認の過程で見つかった問題や不備に対して、必要な修正を行います。このプロセスは、プロジェクトを最終的な完成状態に導くために重要です。
- チケット完了: チケットのタスク(サブタスク含)が完了し、受け入れ確認が成功したら、チケットを完了とします。