これまで、エンジニア個人としてできることを紹介しました。ここからは、開発チーム/組織としてどのような対応が考えられるかを紹介していきます。
チームメンバー内で、ソース知識や仕様理解、仕様の背景にある業務理解に差異があると、そのまま生成AIのアウトプットの差異として出てきてしまいます。
チーム内の有識者が生成AIのアウトプットについて指摘したとしても、担当メンバーでの前提知識に差がある状態では、生成AIへの要求をどう変えればよいのか分からず、対応できなくなってしまいます。これを解消するためには、「設計」「製造」「試験」の各フェーズで逐次ペアプログラミングやモブプログラミングを活用し、チーム内での作業レベルを統一する取り組みが重要になってきます。生成AIとその利用者で認識を共有できていればよいのではなく、チーム全体で認識を共有していく必要があります。
生成AIの出力結果を人間がチェックすることにも限界があります。規模が大きなプロジェクトになればなるほど、チェックの負担も大きくなります。チェック負荷を軽減するためには、今まで以上に自動テストによるカバー範囲を広げていく必要があります。自動テストのカバー範囲が広がれば、生成AIの誤りを自動で検出できる可能性も高まりますし、生成AIの出力自体のコントロールもやりやすくなります。
生成AIを導入してすぐに運用が固まるわけではありません。チームとして定期的に「今の運用方法でよいか」を振り返る場を設けることをお勧めします。振り返りの観点としては、「生成AIを利用して工数が〇人日削減できた」というような定量的なものよりも「××の作業で生成AIを使ったら簡単に実施できて助かった」のような定性的な観点の方が重要になります(会社全体として見れば定量的な部分ももちろん重要です)。
生成AIを活用して日々の仕事をより楽に、より効率的に実施できるようになるためには、実際に運用した上での改善を続けていくことが何より重要です。
生成AIとソフトウェア開発は恐ろしいほどまでに親和性が高く、まさに日進月歩の世界です。しかし逆に、生成AIによって改めて皆が必要性を認識するようになったこともあります。その中の一つが「1人のエンジニアとしての責任」だと私は考えています。生成AIはミスをします。人間もミスをします。しかし責任を取ることができるのは人間だけです(今のところは)。
そして、エンジニアとしての責任とは、「自分の担当するソースがどんな動きをするのか?」「そのソースは何のために存在するのか?」「このソースでよいと考えた理由は何なのか?」を他人に説明できるようになることだと考えています。
生成AIの出力をそのまま使ってもよいでしょう。既存のソースコードからコピー&ペーストで持ってきてもよいでしょう。ネットで検索して出てきた誰が書いたかも分からないサンプルコードの一部を使うこともあるでしょう。
しかし、どのような手法で作成されたプログラムであっても、自分の担当である以上は、自身で説明できなければ責任を果たしているとはいえないのではないでしょうか?
Copyright © ITmedia, Inc. All Rights Reserved.