はじめに
昨今の生成AIの普及は、もう止まることはなく、業務やシステム開発に活用されることは当たり前になっていますね。
かねてより会社から「いろいろ活用してね」という位置付けで利用できるGPTが提供されていましたが、徐々に案件内での活用も進み始めました。
今回、半ば強制でAIを導入し、「生産性向上」を目指した時の、失敗したポイント、反省点をまとめました。
私自身は、プライベートでも様々なAIを使用しており、開発への活用には未来を感じています。そのため、この反省を踏まえて、開発体験の向上を目指していきたいと思っています。
今後、小さくも、大きくも導入を考えている方の参考になれば幸いです。
事の発端
どこでもそうかもしれませんが、社内でも「AIを開発にも活用しよう〜」という取り組みが始まりました。
そして、とある業務システム開発案件にて、マネジメント層から、とことんAIにソースコードを生成させて時間あたり生産性を向上させる、という追加ミッションが発生しました。
筆者はこの案件の担当で、マネジメントとメンバーの間に立っていました。
前提
- 案件で使用すること自体は、ステークホルダー合意済み
- ツールはいろいろありますが、今回はチャットベースのAIサービスのみを導入
方針
- ドキュメントから可能な限りソースコードを自動生成
- 各種ドキュメントに対応するレイヤーのテストを自動生成
- 各段階で、AIによる一次レビュー
まずは結論
今回は急な施策により、一方向の指示と結果の吸い上げによって、現場の疲弊。AI利活用方針の認識齟齬、活用の圧力による現場の心理的安全性の低下。
そして、生産性向上のプレッシャーによる、「動かす」ことを優先した開発となりました。
反省点
一方向の施策となったこと
今回は会社の取り組みとしての、急な施策として行われました。その結果として、各メンバーの目線が合っておらず、様々な問題につながりました。
起こったこと
- AIがソースコードを生成しやすいドキュメントとならないことに対する、マネジメントからの、「これじゃだめ」というやり直しによる混乱
- 「ここは書いた方が早い」という現場と、「なぜコードを手で書くんだ」というマネジメントとの対立
生成AIは完璧ではないことを全員で理解できなかったこと
AIが完璧と思っているメンバーがいることによって、課題が発生することに否定的になり、心理的安全性が低下しました。
起こったこと
- 「なぜAIを使っているのにそんなに時間かかるの？」という言葉による心理的安全性の低下
- 「AIはこう言っているが、なぜそれ？」という言葉による、議論のモチベーション低下
とりあえず動く、になりがちなこと
上記から、少しずつ現場の疲労、心理的安全性が低下した結果、とりあえず動かせ、という状況になりました。
起こったこと
- とりあえず動くコードになりがちで、コードを理解していない
- そこに問題があった場合、それを解決するにもAIに聞くしかない
- 読み直した時にも分からないので、都度聞く必要がある
よかったこと
とはいえ、AIは素晴らしい技術です。良かったポイントもたくさんありました。
課題解消のとっかかり
何かのエラー解消のとっかかりには、ググる前にエラーをAIに聞いてみる、スタックトレースをとりあえず貼ってみる、長文を読解して根本のエラーを抽出してくれたりと、とっかかりにはとても良いですね。
（まあここから、そのままAIに直させるか、根本を理解して解決策を検討するかで対立しますが）
セルフレビュー
ドキュメント、ソースコードの一次AIレビューはとても有効でした。
以下の観点では特に有効でした。
- ドキュメント
- 誤字脱字
- 理論が破綻している部分の検出
- ソースコード
- 単純なバグの検出
- ドキュメントからの実装漏れの検出
単純作業の自動化
（あたりまえですが）単純作業をAIにお任せすることはとても有効でした。
ドキュメントのマークダウン化や、ドキュメントから単体テストケースの作成、そのまま単純な単体テストコードの実装はとても有効でした。
とくに、単純なアサーションを変えるだけのケースにおいては、かなり楽になりました。
今回の学びと今後の展望
さて、今回の経験では、生成AIをフル活用した開発という点でワクワクしていましたが、結果としては、もやもやと疲労でした。
ただし、個人的には、今後避けては通れないAI開発を経験できて、今後必要になる視点や開発組織課題などが明確になりました。
持続可能な開発に向けたAI活用
ソフトウェアは作って終わりではありません。開発後は保守運用、不具合もあるでしょう。追加開発もあるかもしれません。
とにかくAIに生成させて、工数削減も重要だと思います。
ただ、すべてAIが担ってくれるのは、もう少し先になるかと思っています。そのため、ただただ出力させるのではなく、最終的には人間がしっかりと理解して、ソフトウェアを制御できる必要があると再認識しました。
合意形成の重要性
生産性向上による工数削減は、プロジェクトマネジメントにおける重要な目標の一つです。しかし、今回の経験から、新しいツールや手法の導入には、以下のようなプロセスが必要だったのではないかと考えています。
-
ビジョンの共有
- なぜAIを活用するのか
- どのような効果を期待するのか
- チームとしての目標設定
-
理解・合意形成
- AIツールの特性と限界の理解
- 活用範囲の明確化
- チーム内でのベストプラクティスの確立
-
段階的な導入
- 小規模な機能からの試験的導入
- 効果測定と改善点の収集
- チーム全体でのフィードバック共有
上からのお達しとして取り組むのではなく、このようなプロセスを経て納得感を持って取り組むことが重要と考えています。その結果として、健全な施策、取り組み、チャレンジになると思いました。
AIは完璧ではないことの理解
当たり前ですが、この幻想には至りがちです。
「AIは間違える」ことを常に理解することが必要です。
AIを使ってもうまくいかない、AIを使ってもできない、ことがある事実を許容する文化が必要だと思います。
対話
今回は対話が足りていませんでした。
システムを作るのは開発者です。生産性を最終的に上げるのも、下げるのも開発者です。今回はとにかく対話が足りず、一方向のニーズにどう応えるか、となってしまいました。
このようなチャレンジングな施策には、とにかく事実ベースの対話が必要だと思います。
もちろん聞く側にも、受け入れる姿勢を持っていただきたい。そして、より良くするにはどうしたら良いか、をとことん対話していきたいと思います。
まとめ
生成AIを活用した業務システム開発を経験し、その反省点をまとめました。
特に今回のケースでは、組織文化、導入プロセスが発端となる課題がほとんどでした。
今後さらにAIが民主化した際は、活用しない（できない）組織が遅れた存在となると思っています。
そのため、生成AIのある仕事に適応しない、という選択肢を取ることはないと思っています。
AIはエンジニアにとっても強力な味方となります。しかし、今回は「生産性向上」だけにフォーカスしてしまい、エンジニアが幸せになることは少なくなってしまいました。
今回の学びをもとに、組織としては生産性向上による工数削減、エンジニアとしてはより良い開発体験、その両立を図れるように、双方の目線から取り組んでいきたいと思いました。