この記事はNTTコムウェア AdventCalendar 2024 25日目の記事です。
はじめに
NTTコムウェアの原島です。
普段ScM兼Devとして手を動かしつつチームの運営サポートを行っております。
本記事はタイトルの通り、PBI（プロダクトバックログアイテム）の検討においてAI活用を試みる思考実験の記事です。
スクラムないしはアジャイル開発経験者かつ以下の言葉に共感する読者向けの記事になりますのでご了承ください。
- 「PBIを検討」この言葉に少しでもネガティブなイメージを持つ
1. 導入
皆様はスクラムを行う上で気が重い場面はどんな時でしょうか？予想外の差し込みタスクが入ってきた時でしょうか？取り掛かっているタスクが明らかに手に負えなさそうと感じた時でしょうか？色々個人であると思いますが、私はプランニング、リファインメントに気を重く感じることがあります。
一方で、チームの風通しやお互いの尊重といった文化には何の不満もなく、「これから行う作業の計画立てや詳細化」と聞くとワクワクしたり、夢が膨らむイメージを持っています。
なぜ相反する気持ちを持っているのかを考えたとき、様々な要因が絡み合ってはいますが、まず一番に思いついた要因が そもそもPBI（プロダクトバックログアイテム）の詳細化が厄介に感じるということでした。
まず、PBIの詳細化 においては、タスクを分解して具体化する作業がその場のメンバの知見に依存した空中戦になりがちです。
メンバーごとに知識や前提が異なる場合、そもそもそのPBIに対しての知見が不足している場合、議論に決着がつかず 「やってみないと分からない」 として大まかに進めるか、スパイクPBIを追加して調査に時間をかけるケースも見受けられます。
しかし、スパイクを多用しすぎると、「少しでも不明な点があればスパイクを実施する」 や 「スパイクはどの程度の規模から実施すべきか」 といった新たな議論が生じる可能性すらあります。
さらに、ストーリーポイントの見積もりも同様に気分が重い作業です。見積もりには「相対的な評価」を使いますが、現実には規模感が「x→2x」と誰もが納得できるシンプルなケースは少なく、似たようなPBIでも細かな差があり、ざっくりと評価にしても難しいことが多いです。
議論は長引き、メンバー間で意見が割れ、最終的に発言力が強いメンバの見積もりに合わせたり、収拾がつかずに仕方なくスパイク・MTGを挟むなどが起きがちです。
こういった背景からPBIの検討に関わる分かりやすいイベントのプランニングとリファインメントが本来は好きであるはずなのにネガティブな気持ちが発生します。
2. AIを使う
以下のことが改善されればプランニングとリファインメントをより好きになれると感じています。
- 10数分調べたら分かるかもしれないことをその場だと時間を取れないのでPBIのタスクとして持ち込む
- 曖昧な相対基準でポイントを付けざるを得ない
- ポイントの正しさを評価できる第三者が居ない
これだけ書くと「これはAI活用で改善できるのでは？」と思った方がいらっしゃるのではないでしょうか。
私もそう思います。 なので以下の組み込みを考えてみました。
AIによるPBI詳細化とポイント付け
ステップ1. 人がやりたいことを書く
チームメンバーはやりたいことをカードに記載します。内容はPBIのタイトル、やりたいこと、備考を簡素に書きます。
ステップ2. タスクの詳細化を行う
AIにこれらのPBIを詳細化してもらいます。その際以下のフォーマットに従い、各PBIの前提条件、完了条件、備考、タスクイメージを確実に書き出してもらいます。
フォーマット
■前提条件
前提条件があれば記載、なければ空欄
■完了条件
受け入れは何もって確認するか記載
■備考
何かタスクイメージ外の備考があれば記載
■タスクイメージ
箇条書きで記載。記号は-
ステップ3. 詳細化したタスクを見てポイント付けを行う
詳細化されたタスクを基にポイント付けをAIに行ってもらいます。今回の実験ではログイン機能を2ptとして他のPBIもその基準に従って見積もりました。
これが出来ればタスク内に概要・方針確認のタスクを入れ込むことなく、相対基準はAIに任せ、AIがポイントは保証する第三者になる。これで私の今の不満が解消されると考え、実際に架空プロダクトを考えて次の項で実験してみます。
※より現実的に考えるとステップ２、３の後にチームが確認して情報の取捨選択・補足・修正するフェーズが必要ですが、今回は省略します。
3. 架空プロジェクトでの実験内容
以下は架空の案件情報と初期で話に出たとするPBIのやりたいこと・備考の一覧です。
プロジェクト概要：cocopa
cocopa(Corporate Online Collaboration and Organizational Platform Access)
cocopaは、企業内での効率的なファイル共有とチームコラボレーションを実現するクラウドベースのファイル共有プラットフォームです。
PBIアイデアの一部
1. ログイン機能の実装
- やりたいこと: ユーザーがアカウントを作成してログインできること
- 備考: パスワードはハッシュ化して保存すること
2. ファイルアップロード機能の実装
- やりたいこと: ユーザーがファイルをcocopaにアップロードできること
- 備考: ファイルストレージとしてAWS S3を使用
3. ファイルダウンロード機能の実装
- やりたいこと: ユーザーがアップロードされたファイルをダウンロードできること
- 備考: ファイルダウンロード時に適切な権限チェックを行うこと
4. ログインのユーザプールをAzureADと連携
- やりたいこと: ログインのユーザプールをAzureADと連携すること
- 備考: 情報を持っている部署とのミーティングを含めた調整が必要
5. シングルサインオン（SSO）統合の実装
- やりたいこと: シングルサインオン（SSO）を導入し、企業内の主要なアイデンティティプロバイダーと統合すること
- 備考: 各アイデンティティプロバイダーのドキュメントを参照し、適切なプロトコルを選定すること
6 ▲▲部署との連携
- やりたいこと: ▲▲部署が持っているファイルがシステムに連携されること
- 備考: ▲▲部署は独自ルールがあり、連携が許可されるまでに何回MTGを含めた調整があるか現在は見通しが立たない
AIによるPBIの詳細化とポイント付け
以下に、ChatGPT-4oを使って詳細化とポイント付けをしてもらった結果を記載します。
1. ログイン機能の実装(2pt 基準)
■前提条件
- データベースとしてAWSのDynamoDBが準備されていること
- UIは開発者が作成し、POに提示しつつ模索する形で進行（ページの機能要件は確認済み）
■完了条件
- 新規ユーザーがアカウントを作成できること
- 既存ユーザーが正しくログインできること
- 不正なログイン試行が適切にブロックされること
- ログインおよびアカウント作成時にエラーメッセージが表示されること
■備考
- パスワードはハッシュ化して保存すること
- セキュリティ強化のため、二段階認証の導入を検討
■タスクイメージ
- ユーザー登録フォームの作成（開発者がUIを設計し、POと調整）
- ログインフォームの作成（開発者がUIを設計し、POと調整）
- バックエンドでのユーザー認証ロジックの実装
- DynamoDBとの連携設定
- エラーメッセージ表示機能の追加
- テストユーザーを用いた動作確認
2. ファイルアップロード機能の実装 (3pt)
■前提条件
- ログイン機能が実装されていること
- ファイルストレージとしてAWS S3が選定されていること
■完了条件
- ユーザーがファイルを選択してアップロードできること
- アップロードされたファイルが正しくAWS S3に保存されること
- アップロード完了後に確認メッセージが表示されること
- ファイルサイズや形式の制限が適用されること
■備考
- アップロード速度を向上させるための最適化
■タスクイメージ
- ファイルアップロード用のUIコンポーネントの作成（開発者がUIを設計し、POと調整）
- バックエンドでのファイル受け取りロジックの実装
- AWS S3との連携設定
- ファイルサイズおよび形式のバリデーションの追加
- アップロード完了メッセージの表示機能の追加
- テストユーザーを用いたアップロード動作確認
3. ファイルダウンロード機能の実装 (3pt)
■前提条件
- ファイルアップロード機能が実装されていること
- ユーザーがログインしていること
■完了条件
- ユーザーがアップロードされたファイル一覧を閲覧できること
- ファイル名やアップロード日時でファイルを選択できること
- 選択したファイルを正常にダウンロードできること
- ダウンロード時に適切な権限チェックが行われること
■備考
- ダウンロード速度の最適化を検討
- ファイルのバージョン管理機能の導入を検討
■タスクイメージ
- ファイル一覧表示用のUIコンポーネントの作成
- ファイル選択およびダウンロードボタンの実装
- バックエンドでのファイル提供ロジックの実装
- ユーザー権限に基づくアクセス制御の追加
- ダウンロード完了後の通知機能の追加
- テストユーザーを用いたダウンロード動作確認
4. ログインのユーザプールをAzureADと連携 (8pt)
■前提条件
- ログイン機能が実装されていること
- AWSのDynamoDBが設定されていること
- AzureADのアカウントおよび必要な権限が準備されていること
■完了条件
- ユーザーがAzureADの認証情報を使用してcocopaにログインできること
- AzureADとの連携により、ユーザー情報が自動的に同期されること
- AzureADログイン時に適切なアクセス権限が適用されること
- ログインおよび連携プロセス中にエラーメッセージが適切に表示されること
- セキュリティテストが完了し、認証フローが安全であることの確認
■備考
- 情報を持っている部署とのミーティングを含めた調整が必要
- AzureADの設定変更やポリシーに対応するための柔軟性を確保
- ユーザー教育やサポート資料の作成を検討
■タスクイメージ
- AzureADとの連携要件の確認
- AzureADのドキュメントを参照し、必要な設定やプロトコル（OAuth2、OpenID Connect）の選定
- 情報を持っている部署とのミーティングを設定し、要件を明確化
- バックエンドでのAzureAD認証ロジックの実装
- AzureADからの認証トークンの受け取りと検証
- DynamoDBとの連携を通じてユーザー情報の同期
- フロントエンドでのログインフローの調整
- AzureADログインボタンの設置と認証フローの設計
- ログイン後のリダイレクト設定とユーザー情報の表示
- アクセス権限の適用
- AzureADから取得したユーザー情報に基づき、適切なアクセス権限を設定
- ロールベースアクセス制御（RBAC）の調整
- エラーハンドリングの実装
- 認証失敗時や連携エラー時のエラーメッセージ表示機能の追加
- ログ記録機能の強化
- セキュリティテストと認証フローの検証
- 認証フローのセキュリティテストの実施
- 脆弱性スキャンとペネトレーションテストの実施
- ドキュメント作成と部署間調整
- AzureAD連携に関する技術ドキュメントの作成
- 情報を持っている部署との継続的なコミュニケーションと調整
- ユーザーフィードバックの収集と改善
- 初期ユーザーによるAzureADログイン機能のテストとフィードバック収集
- フィードバックに基づく改善とバグ修正
- 統合後のモニタリングとメンテナンス
- SSO統合後のログ監視と問題発生時の対応体制の構築
- 定期的なセキュリティレビューと更新
5. シングルサインオン統合の実装 (13pt)
■前提条件
- ログイン機能および基本的なアクセス制御と権限管理が実装されていること
- システムがHTTPSを使用していること
■完了条件
- 主要なアイデンティティプロバイダー（例：Okta、Azure AD、Google Workspace）とのSSO統合が完了していること
- ユーザーが企業の認証情報を使用してcocopaにログインできること
- SSOログイン時にユーザーのアクセス権限が適切に適用されること
- SSOログインおよびログアウトのフローが正常に機能すること
- セキュリティテストと認証フローの検証が完了していること
- ドキュメントが整備され、管理者向けにSSO設定方法が記載されていること
■備考
- 各アイデンティティプロバイダーのドキュメントを参照し、適切なプロトコル（SAML、OAuth2、OpenID Connect）を選定すること
- ユーザーのプロビジョニングとデプロビジョニングを自動化するための設定を検討
- SSO統合に伴うユーザー教育とサポート体制の整備を計画
■タスクイメージ
- アイデンティティプロバイダーの選定と要件定義
- 主要なアイデンティティプロバイダー（Okta、Azure AD、Google Workspaceなど）の調査と選定
- SSOに必要な要件とセキュリティ基準の定義
- SSOプロトコルの選定と設定
- SAML、OAuth2、OpenID Connectなどのプロトコルの選定
- 選定したプロトコルに基づいた設定の実施
- バックエンドでのSSOロジックの実装
- 認証フローの実装（トークンの取得、検証、ユーザー情報の取得）
- アイデンティティプロバイダーとの連携設定
- フロントエンドでのSSOフローの実装
- SSOログインボタンの設置とフローの設計
- ログインおよびログアウト時のリダイレクト設定
- ユーザー権限の適用
- SSOログイン時にユーザーの役割や権限を適切に適用するロジックの実装
- ロールベースアクセス制御（RBAC）の確認と調整
- エラーハンドリングの実装
- 認証失敗時や連携エラー時のエラーメッセージ表示機能の追加
- ログ記録機能の強化
- セキュリティテストと認証フローの検証
- SSO認証フローのセキュリティテストの実施
- 脆弱性スキャンとペネトレーションテストの実施
- ドキュメント作成と管理者向けガイドの整備
- SSO設定方法とトラブルシューティングガイドの作成
- 管理者向けのユーザー教育資料の整備
- ユーザーフィードバックの収集と改善
- 初期ユーザーによるSSO機能のテストとフィードバック収集
- フィードバックに基づく改善とバグ修正
- 統合後のモニタリングとメンテナンス
- SSO統合後のログ監視と問題発生時の対応体制の構築
- 定期的なセキュリティレビューと更新
6 ▲▲部署との連携 (8pt)
■前提条件
- ログイン機能が実装されていること
- ファイルアップロード機能が実装されていること
■完了条件
- ▲▲部署が保有するファイルがcocopaシステムに正常に連携されること
- 連携されたファイルが適切にシステム内で利用可能であること
- ファイル連携プロセス中にエラーメッセージが適切に表示されること
■備考
- ▲▲部署は独自ルールがあり、連携が許可されるまでに何回MTGを含めた調整があるか現在は見通しが立たない
■タスクイメージ
- ▲▲部署との連携要件の確認
- ▲▲部署の担当者とミーティングを設定し、連携要件を明確化
- ▲▲部署の独自ルールに基づく連携プロセスの理解
- システム連携用のAPIの設計と実装
- ファイル連携に必要なAPIエンドポイントの設計
- APIの実装とテスト
- ファイル連携プロセスの自動化
- ▲▲部署からのファイル取得方法の確立
- ファイルの自動アップロードスクリプトの作成
- エラーハンドリングと通知機能の実装
- 連携プロセス中のエラーを検知し、適切に通知する機能の追加
- 連携テストの実施
- テスト用ファイルを用いた連携プロセスの検証
- ▲▲部署との連携確認テストの実施
- ドキュメント作成と共有
- 連携プロセスに関する技術ドキュメントの作成
- ▲▲部署へのドキュメント共有と説明
- 連携後のモニタリングとメンテナンス
- 連携プロセスのモニタリング設定
- 定期的な連携状態の確認とメンテナンス
markdown形式に直したことなど以外はほぼそのまま上記の形で回答が返ってきました。
要件に入れていないので当然ですが、「このPBIが完了すると何が嬉しいのか」 という価値ベースの情報がないとか、ありがちな 「適切って何をもって適切というのか？」 というところは気になるので多少補足を入れるとか手直しするなどサポートはまだまだ必要かなとは思うものの、タスクイメージは細やかすぎるほどですし、敢えて曖昧にした6のケースでもまあ許容範囲かなというptで返ってきていると感じています。
また、実際のケースとして大きすぎるPBIは分割したいという話もあるかもしれません。
やってもらいました。 対象はシングルサインオンのPBI（13pt）です。
シングルサインオン（SSO）プロトコルの設定 (5pt)
■前提条件
- ログイン機能および基本的なアクセス制御と権限管理が実装されていること
- システムがHTTPSを使用していること
■完了条件
- 選定した認証プロトコルがシステムに正しく設定されていること
- プロトコル設定後、テスト環境で認証フローが正常に機能すること
- 設定に関する技術ドキュメントが作成されていること
■備考
- 各プロトコルのセキュリティ要件を満たす必要がある
- プロトコル選定に際して、各アイデンティティプロバイダーの要件も考慮すること
■タスクイメージ
- 認証プロトコル（SAML、OAuth2、OpenID Connect）の調査と比較
- プロジェクト要件に最適なプロトコルの選定
- 選定したプロトコルに基づいた設定の実施
- 設定内容の検証およびテスト環境での動作確認
- プロトコル設定に関する技術ドキュメントの作成
- チームメンバーへの設定内容の共有と説明
シングルサインオン（SSO）統合の実装 (8pt)
■前提条件
- シングルサインオン（SSO）プロトコルの設定が完了していること
- 各アイデンティティプロバイダーの設定情報が揃っていること
■完了条件
- 選定したアイデンティティプロバイダー（Okta、Azure AD、Google Workspaceなど）とのSSO統合が完了していること
- ユーザーが企業の認証情報を使用してcocopaにログインできること
- SSOログイン時にユーザーのアクセス権限が適切に適用されること
- SSOログインおよびログアウトのフローが正常に機能すること
- セキュリティテストと認証フローの検証が完了していること
- ドキュメントが整備され、管理者向けにSSO設定方法が記載されていること
■備考
- ユーザーのプロビジョニングとデプロビジョニングを自動化するための設定を検討
- SSO統合に伴うユーザー教育とサポート体制の整備を計画
■タスクイメージ
- アイデンティティプロバイダーの選定と要件定義
- 主要なアイデンティティプロバイダー（Okta、Azure AD、Google Workspaceなど）の調査と選定
- SSOに必要な要件とセキュリティ基準の定義
- SSOプロトコルの選定と設定
- シングルサインオン用に設定されたプロトコルの確認と最適化
- バックエンドでのSSOロジックの実装
- 認証フローの実装（トークンの取得、検証、ユーザー情報の取得）
-アイデンティティプロバイダーとの連携設定
- フロントエンドでのSSOフローの実装
-SSOログインボタンの設置とフローの設計
-ログインおよびログアウト時のリダイレクト設定
- ユーザー権限の適用
-SSOログイン時にユーザーの役割や権限を適切に適用するロジックの実装
-ロールベースアクセス制御（RBAC）の確認と調整
- セキュリティテストと認証フローの検証
-SSO認証フローのセキュリティテストの実施
-脆弱性スキャンとペネトレーションテストの実施
- ドキュメント作成と管理者向けガイドの整備
-SSO設定方法とトラブルシューティングガイドの作成
-管理者向けのユーザー教育資料の整備
- ユーザーフィードバックの収集と改善
-初期ユーザーによるSSO機能のテストとフィードバック収集
-フィードバックに基づく改善とバグ修正
- 統合後のモニタリングとメンテナンス
- SSO統合後のログ監視と問題発生時の対応体制の構築
- 定期的なセキュリティレビューと更新
それらしく分割してくれたのもそうですが、特に指示していなくてもプロトコルのPBIで実装につなぐためのタスク（チームメンバーへの設定内容の共有と説明）を追加で設けているのが中々やるなあという感じました。ただ、繋ぐためのタスクが発生しているのにそのタスクの労力が闇に葬られているのは気になるところです。
4. 結果と考察
これらの結果を受けて以下のメリットを感じています。
-
作業の効率化
数秒で詳細化→pt付けが終わる。手直しの時間は必要だが、それを考えても一からやるよりは遥かに早いパターンが多そう。 -
一貫性の向上
AIが同じ基準に基づいてタスクを分解し、ポイントを付けるため、チーム全体で一貫した基準が保たれる。これにより、見積もりのばらつきを減らし、プロジェクト全体の予測精度が向上する。また、発足したてのチームで相対基準が安定するまで初期Sprintが「見」のフェーズとして見られたりするがそれもない。 -
客観性の確保
鵜呑みは危険だが、AIに感情はないので客観的な意見を出してくれるという前提で納得感が強い。 -
知識の共有と標準化
技術知見が不足しているメンバーでも、AIのサポートにより詳細なタスク分解が可能となり、チーム全体の知識を共有・標準化することが出来る。新規メンバーのオンボーディングもよりやりやすくなる。 -
継続的な改善
使うサービスにもよるが基本的にモデル学習出来るはずなので「こういったケースは申請長引きがち」とか「このタイプのリリースは半日で終わる」などの情報を付与していくと更に最適な提案が出来る。またAIサービスそのものの進化もダイレクトで恩恵を受けられる。
逆にデメリット、もとい気にすべきと感じた点が以下です。
4.2 気になる点
-
文脈理解の限界
AIはプロジェクトの全体的な文脈やチームの特定のニーズを完全には理解出来ないため、完全に組織依存の特殊な仕様を含むPBIは人間がやるとむしろ話が早いケースも少数ながらあると思います。 -
AIへの依存コントロール
納得感は強いですが、とはいえ鵜呑みはいけません。提案内容が自分と感覚とずれている場合はAIと戦う姿勢を持つ必要はあります。正しく戦ってAIと戦友になりましょう。 -
セキュリティとプライバシーの懸念
AI関連の規則を見ていたとしても、「何かが組織の規則に抵触するのでは…？」と感じて実現させるのが怖いですよね。とはいえ、この記事を見たことを良いきっかけとして規則を再度確認してみましょう。私も確認します。正直二の足を踏んでいる主な理由はこれにあると思っています。
5. まとめ
今回の記事では、スクラムチームにおけるPBIの詳細化とストーリーポイントの見積もりにおいて、AIの活用検討と実験をしてみました。
個人的には気になる点はあったり、実現するとしても人が確認するフェーズは必要と思ったものの、現時点でも十分に組み込みに値する性能と感じましたし、出力結果を鵜呑みにしないことなどを心がければAIをよい隣人として付き合ってチームをより良い形に持っていくことが出来ると感じています。
「スクラムガイドにAI関連のことなど書いていない。」という方もいらっしゃるとは思うのですが、スクラムガイドの最新版は2020年で、ChatGPTの一般公開が2022年なのでそもそもガイドがAIを認識できていないだけと考えています。
スクラムガイドはスクラム開発を行う我々にとって聖書ではありますが、時には聖書を再解釈してより理念に理解を深めるのも大事であり、今はその節目だと感じています。
今調べてみる限りでもMobAIやanycommuなど開発プロセスそのものにAI活用を試みている例はいくつもあります。この流れに乗ったり、流れを強くする一因になれたらよいと考えています。
この記事に少しでも共感を感じる部分がありましたら是非とも開発プロセスのAI活用について思いを馳せていただき、あわよくば記事にコメントや「現場でやってみた！」などいただけると幸いです。
※記載されている会社名、製品名、サービス名は、各社の商標または登録商標です。