◼️経緯
- ウェブシステムのリプレイス（OSの入れ替え）の対応を行なった。
- ウェブはApache+Laravelで稼働しており、バックエンドもLaravelにてバッチが稼働している。
- ミッションクリティカル性としては、バックエンドのデータ連携に失敗した場合に、かなりの大規模障害に発展することから、バッチが正常に稼働することは見届ける必要がある。
- しかし、このシステムの担当者はすでに退職しており、引き継ぎもわりと適当だったので、私の知らない仕様が色々と存在するシステムである。
- 会社としてはクライアントにリプレイス費用を請求しない判断をしており、そのため極力コスト（社内工数）をかけずに、その分品質は下げて対応したいとのこと。
◼️私の解釈
- 会社としては現場に対して無理難題を申し付けている。
- 無理難題を対応するためには、AIを駆使して工数削減するしかない。
◼️対応内容
- AIはaws Kiroを全面的に使用した。
- 基本全部AIに丸投げして、システムを全部分析させ、要件定義署、外部設計書、内部設計書、テスト仕様書、リリース手順書の一切を作らせた。
- 完成した手順書は、上司のエンジニアにそのまま丸投げしてレビューを受けた。
- レビューを通過したので、それをそのまま実行にうつした。
◼️結果
- ５件のトラブルが発生した。いずれも軽微なものだが、一部は顧客にバレた為に、インシデントの発生となった。
- バックエンド系でもバッチ処理が失敗した。手動でリカバリして事なきを得た。
- 原因は、旧環境→新環境にフォルダやファイルをコピーした際に、フォルダやファイルの権限を付与する必要があるのだが、書き込み権限は運用を考慮したものとなっておらず、書き込み権限不足が原因で５件のトラブルが発生した。
◼️結論
- インシデントは発生したものの、リリースそのものは正常に成功した。コストを発生させないかわりに品質を下げるという、会社が求めた要求水準で対応ができた。
- 仮に私が、フォルダやファイルへの権限回りにまで目が届く状態になっていれば、私が気づいてAIにテスト仕様書を書き直させるような事もできたと思うが、そこが私のエンジニアとしてのダサい部分であり、このダサさはAIにまで伝播して、ダサさを拡張する結果となった。
◼️まとめ
- 会社側が次もまた同じような無理難題を現場に突きつける事があれば、同じ手段で対応できることがわかった（ヒヤヒヤ綱渡の品質になりますが）。
- AIを業務で使用した場合に、AIを使用するエンジニアのダサさ（エンジニア個人のヌケモレダブリなどダサいところ）もAIが拡張してしまうので、エンジニアはAIになにもかもを丸投げして自己研鑽を甘んじるのではなく、自分自身をダサくない状態に常日頃から己を鍛錬して鍛え上げ、AIを最高のマテリアルとして活用できるように己を保つことが、AIと共生共創する社会へ重要なエンジニアとしての所作や心得であると思う。