開発・PM・QA

要件定義書、設計書、ソースコード、テスト仕様書、運用手順書、チケット、障害記録を許可された範囲で整理することから始めます。業務単位で処理概要、データの流れ、依存関係、改修時の確認項目、テスト観点の草案を作ると、次の担当者が同じ調査を繰り返さずに済みます。整理する資料の種類と手順は、チームで育てられる開発資産へにまとめています。

設計資料、業務ルール、運用手順、障害記録、承認に関する規程を許可された範囲で参照し、進捗・リスク・体制の整理を共通の情報をもとに行う形にできます。複数案件の管理でも、現行システムの制約、依存関係、切替条件、過去の障害記録を同じ観点で整理できます。再現性を高める運営の作り方は、チームで成功を再現できるプロジェクト運営へで解説しています。

任せられません。Jiteraの出力は報告書や判断資料の草案です。品質判定、出荷可否、リリース可否の最終判断は、品質責任者や担当者が確認して行う必要があります。AIの出力は判断のための材料として扱ってください。人が判断するための材料の整え方は、再発防止に集中できる品質管理へで紹介しています。

報告書の記述ルールをそろえることが必要です。表現が統一されていなかったり、検索キーワードが担当者ごとに異なったりすると類似事例を見つけにくくなり、過去の原因分析や是正処置を再利用できません。品質基準、障害履歴、原因分析・是正処置、手順、設計・仕様、会議・判断履歴をあわせて登録します。登録するコンテキストの一覧は、再発防止に集中できる品質管理へで確認できます。

作れます。ソースコードとDBスキーマをコンテキストとして整理し、プログラム概要・依存関係、基本設計書、画面遷移図、データフロー図、単体テスト観点までを段階的に作成します。生成物は草案であり、コードから確認できない業務ルールや運用上の制約は人が補います。段階ごとの進め方は、レガシーコードから設計書を自動生成するにまとめています。