はじめに
過去に担当していたデータ連携処理を、あらためて見直すことになりました。
きっかけは、連携先の仕様変更に備えて、既存の処理が問題なく動くかを確認したくなったことです。
コードもドキュメントも検証に必要な情報も残っていましたが、「どの条件で正常になるのか」「何を確認すればよいのか」はすぐには出てきませんでした。
そこで今回は、AI にコードとドキュメントを読んでもらいながら、仕様の整理、テストデータ作成、評価の進め方の整理を一緒に進めました。
今回やりたかったことは、次の 3 つです。
- 連携先の仕様が変わっても、既存の仕組みで正しく取り込めるか見立てること
- その確認に使えるテストデータを、仕様に沿って作ること
- 加工後のデータがどこへ渡り、次に誰が処理するのかを把握すること
この記事で書きたいのは、結果そのものよりも次の点です。
- AI に仕様理解を進めてもらうには、どんなインプットが効くのか
先に結論
最初に次の 4 つを渡すと、かなり進みやすかったです。
- 何を評価したいか
- 最初に見るファイル
- 実行してよい範囲
- 何をもって OK とするか
完璧な仕様書を最初から渡すというより、AI が探索を始めるための足場を渡すイメージです。
どんなことがやれるシステムか
今回対象にしたのは、入力データを受け取り、加工し、連携先へ引き渡す仕組みです。
登場するシステムをざっくりまとめると、次のようになります。
- 入力データを受け取る保管領域
- データを整形、振り分けする処理基盤
- 加工後データを受け取る連携先
- 次の処理へつなぐ通知や連携トリガー
- コードとドキュメントを読みながら、仕様整理やテスト観点の洗い出しを進める AI
全体としては、ファイルを置くと加工処理が走り、その結果が次のシステムへ引き渡される構成です。今回はこの流れを前提に、仕様理解とテストデータ作成をどこから進めるとやりやすいかを確認しました。
今回やってもらったこと
今回 AI にやってもらったのは、ざっくり次の内容です。
- 処理の入口と変換条件を読む
- 条件に合うテストデータを作る
- 検証環境で処理を実行する
- 設定済みの通知や連携トリガーを確認する
- その先の連携経路を整理する
実際には、データ加工処理の入口を起点にして変換条件を追い、最終的に連携先へ引き渡される流れだと確認できました。
途中で効いた具体例もありました。変換ロジックを追うと、特定条件を満たすデータは処理対象として残ることが分かりました。これが分かったことで、今回の目的に対して妥当なテストデータの条件を判断しやすくなりました。
どういうインプットが効いたか
1. 「仕様を教えて」ではなく「何を評価したいか」を渡す
最初に効いたのは、依頼を「このコードの仕様を教えて」ではなく、「連携先の仕様が変わっても正しく処理できるか評価したい」と置いたことでした。
これだけで、AI の探索がかなり絞れます。
- どの入力が処理対象か
- どの行が正常データとして残るか
- 成功時にどこへ出るか
- 失敗時にどこへ落ちるか
- 連携先へは誰が引き継ぐか
2. 最初に見るファイルを 1 つ渡す
コードベース全体を自由に読ませるより、入口を 1 つ渡した方が早いです。
今回は次の 3 つが効きました。
- 処理の入口ファイル
- 変換ロジックの本体
- 既存の単体テスト
特にテストファイルがあると、AI が想像で仕様を補完しにくくなるので助かります。
3. 実行してよい範囲を先に決める
これもかなり大事でした。
途中で「ローカルにこだわらず、利用可能な検証環境を使ってよい」と切り替えたことで、AI が実運用に近い検証へ進めるようになりました。
この一言があるだけで、AI は次のように動きやすくなります。
- ローカル検証より検証環境の確認を優先する
- 実行対象や保存先を確認する
- 出力ファイルの中身まで見にいく
4. OK 条件は途中で更新してよい
AI を相手にするときは、最初の指示を最後まで固定しなくて大丈夫でした。
今回だと、AI が変換条件を見つけたあとに、「その条件ならこのテストデータで OK」と返せたことで、次へ進みやすくなりました。
つまり、AI に必要なのは最初から完全な正解ではなく、途中で受け入れ条件を更新できる会話です。
実際に投げるならこんな感じ
今回の経験を踏まえると、次のような形で渡すとかなり進めやすいです。
しばらく触っていなかったデータ連携処理の仕様を忘れています。
やりたいこと:
連携先の仕様が変わっても、正しく処理できるか評価したいです。
最初に見てほしいもの:
- 処理の入口ファイル
- 変換ロジック
- 既存テスト
- 関連ドキュメント
やってほしいこと:
1. 正常データになる条件を整理する
2. その条件に合うテストデータを作る
3. 必要なら検証環境で処理を実行する
4. 設定している通知や連携トリガーを確認する
5. 後続の連携経路も分かれば整理する
制約:
- ローカルにこだわらなくてよい
- 利用可能な検証環境を使ってよい
- 分からない仕様は仮説を出しながら進めてよい
完了条件:
- なぜそのテストデータでよいか説明できること
- 出力先が正しいことを確認できること
- その先に誰が処理するか説明できること
ポイントは、全部を細かく書くことではなく、AI が次の一手を決められる材料を渡すことです。
逆に、進みにくかった投げ方
逆に、次のような投げ方だと進みにくいです。
- 「これ調べておいて」だけで目的がない
- 入口ファイルがない
- 実環境を触ってよいか分からない
- 何が分かれば完了なのかがない
AI は便利ですが、探索の優先順位を決める材料がないと、どうしても広く浅くなりやすいです。
まとめ
今回やってみて感じたのは、AI に必要なのは完璧な仕様書よりも、次の 4 点だということでした。
- 評価目的
- 入口ファイル
- 実行範囲
- OK 条件
過去に担当した処理を見直すときほど、この 4 点があるだけでかなり進めやすくなります。
「以前触っていた処理だけど、今は仕様を思い出せない」という場面は普通にあるので、同じような状況の人にはかなり相性のいい進め方だと思います。
注意事項
本ブログに掲載している内容は、私個人の見解であり、所属する組織の立場や戦略、意見を代表するものではありません。あくまでエンジニアとしての経験や考えを発信していますので、ご了承ください。