はじめに
システム屋の仕事はドキュメントを作ることだ、と言われてきました。AI が文書を書けるようになると、この仕事のどこが減って、どこが残るのでしょうか。
オンプレミスから AWS へのクラウドリフト案件（システムの動きをほぼ変えずに、そのままクラウドへ移すこと）の要件定義を例に考えました。まだ試していないことが多いので、以下は現時点の見立てです。
誤字・表記の指摘は事前に減らせる
要件定義書のレビューでは、誤字、表記ゆれ（「サーバ」と「サーバー」など）、用語の不統一の指摘が一定数出ます。
これは AI の事前チェックで減らせると思います。減った分、レビューの時間を中身の確認に使えます。
ただし、そうなると指摘件数で文書の品質を見ることが難しくなります。これまでは件数が少なすぎるとレビュー不足、多すぎると品質不足、という見方をしていました。誤字の指摘が減れば、件数の基準そのものを見直す必要があります。件数より、認識違いや記載漏れといった中身の指摘がどれだけ出たかを見るほうが合っていると思います。
項目の抜けは機械的に見つけられる
非機能要件（性能・可用性・セキュリティ・運用など）は、チェックリストと突き合わせて抜けを探す作業になります。AI に向いています。
ただ、見つかるのは「書かれていない項目」までで、その項目に何を書くかは別の話です。たとえば障害時の目標復旧時間や、許容できるデータ消失の範囲は、AI が一般的な値を示すことはできても、決めるのは顧客になります。顧客側もすぐには決められないことが多く、ここに時間がかかります。
このため、抜けを見つける作業が速くなっても、要件定義全体の期間はあまり変わらない可能性があります。時間がかかっているのは、見つけた後の「決めてもらう」部分だからです。
「現行どおり」の中身が資料にない
クラウドリフト案件の要件定義書では、「現行どおり」と書く箇所が多くなります。レビューで「現行どおりとは具体的に何か」と聞かれて、すぐに答えられないことがあります。
ソースコード、ジョブの設定、ログ、運用手順書があれば、AI に読ませて「実際の動き」の下書きを作ることはできると思います。現行の調査にかかる時間は短くなる可能性があります。
一方で、AI が読み取れるのは処理の内容までで、その運用をしている理由は分かりません。たとえば月末だけ手作業でファイルを置き直している場合、その理由はコードにもログにも残っていません。担当者に聞く必要があります。そのうえで、AWS 移行後もその運用を続けるかどうかを顧客に決めてもらう必要があります。
このため、現行の動きを文書にする作業は AI で減らせるとしても、理由を確認して、続けるかやめるかを決めてもらう作業は残ります。クラウドリフト案件の要件定義では、この作業の比重が上がると考えています。
AWS にすると変わる点の洗い出し
動きを変えない移行でも、基盤が変わることで変わる点があります。たとえば次のようなものです。
- バッチの起動の仕組み（サーバーの cron から AWS のサービスへ、など）
- 接続先システムのファイアウォールへの、新しい IP アドレスの申請
- ファイル共有の置き場所とアクセス方法
現行の設定ファイルを AI に読ませれば、こうした候補を一覧にすることはできると思います。人が一から洗い出すより漏れは減るかもしれません。
ただ、候補のうちどれが業務に影響するかは、一覧からは分かりません。接続先の申請に何週間かかるか、バッチの開始時刻が数分ずれて困る業務があるか、といったことは、現行の運用や関係部署の事情を知っていないと判断できません。
候補を出す作業は AI に任せ、影響の判断と関係者への確認に時間を使う、という分担になると思います。
まとめ
上の4つに共通するのは、AI で減るのは「材料を集めて文書にまとめる」作業で、残るのは「理由を確認する」「顧客に決めてもらう」「影響を判断する」作業だということです。
要件定義で時間がかかっているのが後者であれば、AI を使っても期間は大きく縮まりません。一方で、文書作成の負担が減る分、後者に時間を回せるようになります。
気になる点が一つあります。これまでは、文書を書く過程で現行システムや業務を覚えていました。書く作業が減ると、その機会も減ります。影響を判断するための知識を、経験の浅い人がどこで身につけるかは、別に考える必要があります。
今後試すこと
- 社内レビューの前に、AI で誤字・表記・項目の抜けをチェックし、人のレビュー指摘の内容がどう変わるかを見る
- 現行の設定ファイルを AI に読ませて「AWS にすると変わる点」の候補を出させ、自分で洗い出したものと比べる
結果が出たら、あらためて書きます。
コメント