アジャイル開発 ~その先の生成AI~ 【初学者向け】【アジャイルラーニングウィーク】

アジャイル開発 ~その先の生成AI~ アジャイルラーニングウィーク 株式会社レッドジャーニー 田中基淳

自己紹介 田中基淳(たなかもとあき) 普段やっていること • プロダクト開発 • スクラムマスター フォローいただけると嬉しいです！ 2

今日の目的 • アジャイル開発の目的を理解してもらえること • アジャイル開発のイメージを持ってもらえること • 生成AIの登場により、開発がどう変わっていくかが分かること • そのために何をするべきか分かること

アジャイル開発の目的

変化に適応する

車の運転の比喩

「運転というのはね、車を正しい方向に走らせることじゃない の。常に注意を払って、こっちに行ったら少し戻して、あっち に行ったら少し戻して、そうやって軌道修正していくものよ」 Kent Beck, Cynthia Andres. エクストリームプログラミング. オーム社, 2015, 9p

VUCA Volatility（変動性）、Uncertainty（不確実性）、Complexity（複雑性）、Ambiguity（曖昧性）の頭文字をとった言葉で、 将来の予測が困難な現代社会やビジネス環境を表す概念

1. 有効そうな仮説を立てる。 2. それに基づく価値を提供する。 3. 価値があったかを検証する。 その繰り返しで正しさに漸近していく、ということが求められる。

そのアプローチに必要なのが アジャイル開発

• 仮説立案→実装・価値提供→検証の サイクルを繰り返す上で、頻繁にソ フトウェアをいじれる必要がある。 • 重厚長大なテストをやったり、一年 に一回のリリースでは、サイクルが 長すぎて、適応が適切に回らない。 ➡ なので頻繁にいじるためにも、安全 に修正出来る必要がある。

“安全な” アジャイル開発に必要なモノ

三種の神器

三種の神器 • バージョン管理 • テスティング • 自動化 和田卓人, 動作するきれいなコード, https://speakerdeck.com/twada/clean-code-that-works-seleniumconf-tokyo-2019

• https://speakerdeck.com/twada/clean-code-that-works-seleniumconf-tokyo-2019

1. バージョン管理 • いつ、誰が、どのような目的 で、どのような変更したのかを 管理できる。 • いつ、どこからでも安全に過去 のバージョンに戻れる。 • 複数人での同時編集に強い。

2. テスティング • プログラムが想定したとおりに 動いていることを確認するテス トをするためのプログラム • 簡単に再実行可能 • 変更した内容がリグレッション していることに早期に気がつけ る。安心できる。

3. 自動化 • 開発プロセスにおける作業を機 械化 • テスト・修正の反映作業など • ヒューマンエラーの減少 • 安心を担保する作業を自動化

デモ 三種の神器

アジャイル開発のイメージ

スプリントのゴールと計画を策定 日々の進捗確認と障害の共有 成果物の検査とフィードバック プロセスとチームの改善

日々のスプリントの開発の流れ

ここまででおおよその アジャイル開発のイメージ

ここからは 生成AIと開発について

※注 • 日進月歩すぎるので方針変わるかもしれません。 • 細かいAIの使い方・プロンプト、みたいなお話には触れません。もし聞いて みたいことがあればぜひご質問ください。

大前提

生成AIは使ったほうがいい • 悩まなくていい。 • 採用しないと競争優位性にほぼ 確実に負けると言っていい。

デモ 生成AI

生成AIで変わったこと

生成AIで変わったこと • 作りごとのハードルは下がった ➡ アーキテクチャ検討とかも • ペアプロ・モブプロの変化 ➡ AIがペアに、ドライバーに

生成AIを利用するときのポイント

AIを従属させるべき。 人間が従属してはいけない。 • プログラムを書く、というプロセス は高速化された。 • ただし、「どのようなプログラムを 生成するのか」は自分で考える必要 がある。 • モデリングと構造化、具体/抽象を 使って、価値を生み出す/課題を解決 するコードに変換する。 ➡ 前提となる知識が必要となる。

意思決定とアカウンタビリティー の重要性 • コードや動くものを生み出すことは出来るが、できた ものがベストな選択なのかはわからない。 • ノンエンジニアで開発に入って来ている人もいる。 • コードが書ける価値が相対的に減っている。 • つまり、「生成AIがコード書いてくれました。以 上。」にはほとんど価値がない。あなたじゃなくても 出来る。 • バグが起きたときに「AIが書いたんで、私のせい じゃありません」は通用しない。 • 個人開発ならそれでいい。でもおそらくあなたの会 社ではそうはいかない。 • レビューが大事。コードの1行1行に責任を持つ。 39

ではアカウンタビリティを持つためには？

知識が必要

ただ生成AIに書いてもらうだけでは知識はつかない • プログラムの生成を依頼→出力されたプログラムを受領/利用するだけ、では 自身の知識にならない。 • 学習する仕組みが必要。 ➡ 特に新人

アジャイルの中に”個人のスキル”を上げるための明確な仕組みはない • もちろん門戸を開くしくみはある。 • もちろん日々の活動の中で身につくものはあるし、改善はしていく。 • だが基本的には不十分になる。 • 学習する仕組みが必要。

例えば新人をチームに入れる時、OJTだけではなく、学習の仕組みが必要 • OJTだけで上手くいくケースはある。 ➡ それはその新人がデキるヤツで、勝手に自己学習することができる場合 • 要するに運になる。 • キチンとコストをかけよう。 ※これは新人に限らない。

どうする？

じゃあ勉強会だ！

勉強会だ！ • うまく行かない、、 ➡ そもそも来ない • キチンと運用するには相応のコ ストが必要 ※もちろん勉強会もいいですよ！

トライしてみていること

1. 小クイズ • 今日書いたコードの差分から実 装した内容に関するクイズを1問 出題 • 出題・答え合わせには生成AIを 活用

2. プロダクト部 • 作りごとのハードルが下がった。ので、一人で サービス作れるはず。→ひとりで作りたいプロ ダクトを独力で作る・運営する。 • 全てを自分一人でやることで、包括的な学びに つながる • これは開発ごとだけではなく、仮説検証やプ ロダクトマネジメントの視点の実践にもなる • 全体像（フルスタックな視点）を知っている エンジニアが集まるからこそ、チームでのア ジャイル（軌道修正）がスムーズになる。 • なにより、エンジニアが参加したがる。継続で きる。興味があるはず。

まとめ

まとめ • アジャイル開発は変化に適応するため、プロダクトを頻繁に・安全にいじれるよ うにする。 • アジャイル開発に必要な三種の神器や、開発の流れのイメージをつける。 • 生成AIを使った開発の加速は乗り遅れてはいけない。 • が、生成AIに言いなりになってはいけない。従わせられるように自分の知識をつ けよう。 • (アジャイルと関係なく)自分の知識を高めていく営みは仕組みを持って運用しよ う。

自身の成長とともに、 エンジニアリングをエンハンスしていこう！