第4章　分散した検討結果を、レビュー可能な仕様書へ集約する

分散した検討結果を、同じ項目で確認できる形にする

設計方針、GPTとの検討、コード調査、人間が確認した事実は、別々の場所にあった。実装前に、現行仕様と変更後仕様、異常条件、処理内容、影響範囲を同じ基準でレビューできるようにする必要があった。

そこで、保守の前提、承認済みの方針、調査結果、採用する実現方法をMicrosoft 365 Copilotへ渡し、Excel仕様書へ集約した。

操作＋の付いた項目を選ぶと、詳しい説明が下に表示されます。

詳しい説明

気になる項目を選ぶと、その役割や判断理由を確認できます。

確認した調査結果

保守の前提、GPTとの検討、承認した方針、コード調査、人が確認した事実を集めました。別々の場所にある情報を、同じ項目でレビューできる形にするためです。

文書に整理

Microsoft 365 Copilotへ確認した材料と採用する実現方法を渡し、Excel仕様書へ集約しました。AIに整形させても、その表が正しい仕様であるとは扱いませんでした。

Excel仕様書

現行・変更後の正常系と異常系、停止条件、変更範囲、判断理由、試験観点を整理しました。処理順序や読出し・復号のタイミングも確認できる形にし、認識の違いを見つける材料にしました。

人がレビュー

コード上の事実、設計方針、承認した内容との整合を人が確認しました。認識違いがあれば表の一行だけを直すのではなく、現行コードと処理全体へ戻って確認しました。

仕様書には、動作だけでなく判断の根拠も残す

現行・変更後の正常系と異常系、停止条件、利用者の復旧方法、変更範囲、判断理由、試験観点を整理した。処理順序、呼出し関係、読出し・復号のタイミング、外部連携へ進む条件も確認対象にした。

Excelへ並べたことで、検討時には見えにくかった認識の違いも確認できた。

ただし、表に整っていることは、仕様が正しいことを意味しない。コード上の事実、設計方針、承認した内容との整合を人間がレビューした。

誤りを見つけたら、表の修正より先に現行仕様へ戻る

確認では、正常動作を変えていないか、異常時の対応に過不足がないか、影響範囲と試験観点が対応しているかを見た。Excelの認識が現行コードと違う箇所は、その行だけを直すのではなく、処理全体の関係を確認し直す対象とした。

次の工程では、コードを参照できるAIから情報を取り出し、処理構造として確認した内容を文書を扱うAIへ渡して、仕様書へ反映する。