🧭

Devinによる工数見積:AIが導くバージョンアップのロードマップ

に公開3

はじめに

Rehab for JAPANの真木です。

Rehab for JAPANでは、AIアシスタントDevinの活用を積極的に進めています。これまでの取り組みについては、こちらの記事こちらの記事でもご紹介しています。

今回は、Devinを活用してパッケージのバージョンアップ作業の工数見積もりを行った際の実践的な知見をご紹介したいと思います。Devinがどのように分析し、どれほど詳細な見積もりを提示してくれたのか、そしてその結果から何が見えてきたのかをお伝えします。

ターゲット

  • Devinの具体的な活用事例に興味がある開発者
  • 大規模なパッケージのバージョンアップを控えているエンジニアやプロジェクトマネージャー
  • AIを活用した工数見積もりの可能性を探りたい方

要約

本記事では、既存のフロントエンドリポジトリのパッケージバージョンアップにおける工数見積もりをDevinに依頼したプロセスを詳述します。Devinは現行バージョンと最新バージョンの詳細な差分、特にメジャーバージョンアップの影響範囲、そしてそれに伴うリスクを分析し、最終的に「16〜24人日」という具体的な工数見積もりを提示しました。この経験から、AIがプロジェクト計画や技術的意思決定において強力なサポートツールとなり得る可能性が示唆されます。

工数見積の実践プロセス

以下の順にDevinとの対話を通じて工数見積もりを進めていきました。

パッケージの現状把握と最新バージョンの差分確認

まずは対象リポジトリと現在日付を指定し、最新バージョンとの差分を確認するようDevinに依頼しました。
(※日付指定をしない場合、Devinは過去の情報を参照することがあるため、最新の情報を得るには日付指定が必要でした。)

各ライブラリの細かなバージョンまで網羅し、主要なものについては以下のようにまとめてくれました。

  • React: 18系から19系へ
  • Next.js: 14系から15系へ
  • Chakra UI: 2系から3系へ
  • ESLint: 8系から9系へ
  • Testing Library React: 15系から16系へ
  • Vitest: 2系から3系へ
  • その他、TypeScript関連のツールやLintツールなど

メジャーバージョンアップが多く含まれるため、いくつかの注意点も併記されています。

メジャーバージョンアップ項目についての深掘り分析

メジャーバージョンアップが多いため、Devinに対し、さらに詳細な情報提供を依頼しました。

例えば、「React 19とNext.js 15は同時にアップグレードが必要か?」と尋ねたところ、Devinは「同時にアップグレードする必要はないが、安定性を確保するために両方を同時にテスト環境で検証することを推奨する」と回答しました。

特に懸念されたChakra UIのアップグレード(2系から3系)については、Devinは非常に詳細な分析結果を提示してくれました。

  • パッケージ構成の変更点: ark-ui/reactpandacss/is-valid-propなどの新規パッケージの追加、既存の@chakra-ui/icons@chakra-ui/systemが統合されている可能性など、具体的な変更点を詳細に列挙。
  • アップグレード時の推奨事項: 段階的なアプローチや、特に注意してテストすべき箇所についての指針。
  • コード変更が必要な可能性: コンポーネントのAPI、スタイリングシステム、テーマ設定、カスタムコンポーネントなど、具体的なコード修正が必要となりそうな箇所を列挙。

Chakra UI v3への移行は大きなアーキテクチャ変更を伴うため、学習期間や入念なテストが必要になることを事前に把握できました。

全体アップグレードの工数見積もり

最終段階として、Devinに全ての依存関係をアップデート・アップグレードする場合の作業量の詳細な見積もりを依頼しました。

Devinは、リポジトリのコードベースを分析し、修正が必要なファイル数、各アップグレードの複雑さ、そしてChakra UIのようなアーキテクチャ変更を伴う場合の学習期間まで加味して、詳細な工数を提示してくれました。

結果、以下のような見積もりとなりました。

総合作業見積もり

合計: 16-24人日(約3-5週間)

  • React 19: 4-5人日(高複雑度)
  • Next.js 15: 2-3人日(中〜高複雑度)
  • Chakra UI 3: 7-10人日(非常に高複雑度)
  • ESLint 9 + TypeScript-ESLint 8: 1-2人日(中複雑度)
  • テストライブラリ: 1-2人日(中複雑度)
  • その他の依存関係: 1-2人日(低〜中複雑度)

リスク要因

この見積もりにおける潜在的なリスク要因も明確に提示してくれました。

  1. Chakra UI 3の公式移行ドキュメントの不足: 移行プロセスが予想以上に複雑になる可能性。
  2. 複数のメジャーバージョンアップグレードの相互作用: 予期しない問題の発生可能性。
  3. テスト範囲: 回帰バグの見逃しや、テストコードの更新の必要性。

推奨アプローチ

これらのリスクを踏まえて、推奨のアプローチを提示してくれました。

  1. 段階的なアップグレード: 一度に全ての依存関係をアップグレードするのではなく、ESLint/TypeScript → テストライブラリ → React → Next.js → その他 → Chakra UI の順で段階的に実施。
  2. テスト環境での検証: 各アップグレード後に徹底的なテストを行い、問題を早期に発見することが重要です。自動テストと手動テストの両方を実施することを推奨します。
  3. チーム体制: 少なくとも2人の開発者がアップグレードプロセスに関与し、品質確保のため役割分担を推奨します。

まとめ

Devinによる今回の工数見積もりは、単にバージョン差分を提示するだけでなく、各アップグレードの複雑性、影響範囲、そしてそれに伴うリスクまで詳細に分析されており、非常に実践的な内容でした。特に、複雑性の高いChakra UIのアップグレードにおける注意点や、ReactとNext.jsの同時アップグレードに関する考察は、実際の開発現場で非常に有用な情報です。

AIによる工数見積もりは、初期段階での概算や、特定の作業におけるリスク特定に非常に有効であると感じました。もちろん、実際の工数はコードベースの具体的な実装、開発者の経験、予期せぬ問題の発生によって変動する可能性はありますし、提示された内容が全て正しいかは常に検証が必要です。

今回のDevinとのやり取りは、AIがプロジェクトマネジメントや技術選定の意思決定において、強力なサポートツールとなり得る可能性を示唆しています。大規模な技術スタックのアップデートを検討されている方は、DevinのようなAIアシスタントの活用も視野に入れてみてはいかがでしょうか?

Rehab Tech Blog

Discussion

kake2kake2

素晴らしいレポートですね!AIを使ってリスクを早い段階で洗い出すアプローチ、本当に時間の有効活用につながりますよね。日本全国の利用者さんが安心してサービスを使えるよう、縁の下の力持ちとして頑張られている姿勢に感動しました。

一つ気になったのは、UI・ユーザー操作まわりのことです。プラグインのアップグレードやダウングレードって、技術者からすると「ちょっとした差分更新で数分の作業」に見えても、利用者さんにとっては使い勝手が変わる大きな変化になることがありますよね。この辺りはAIの事前チェックでも見落としがちな盲点かもしれません。

「なんかすごく使いやすくなった!」っていう人間の感覚が、結局は商品の評判を左右するところだと思うので、その視点も大切にしていただけたらと思います。

あと、バージョンアップ計画と合わせて切り戻し計画の見積もりも重要ですよね(もう計画済みかもしれませんが)。作業者2名体制でのダブルチェック、手順書準備、リハーサル環境での実施など、実務経験に基づいた判断がさすがだなと感じました。

AIツールを使いこなしながらも、最終的にはユーザー目線を忘れない洞察力、本当に素晴らしいと思います。応援しています!でも頑張りすぎないでくださいね😊
m(_ _)m

Atsuko MakiAtsuko Maki

コメントいただき、ありがとうございます!

おっしゃる通り、特にフロントエンドのプラグインのアップグレードは思わぬところでUIやユーザー操作まわりで影響が出ることがあるため、完全にAI任せにはできないかな?と思っています。
一方、スケジュールを組む上での概算見積もりとしては便利に使えそうだなと感じています。

これからもユーザー目線を忘れずに効率的な開発を目指していきたいと思います!

kake2kake2

考察**

フロントエンドのプラグインアップグレードは、予期しない箇所でUIやユーザー操作に影響を及ぼす可能性があるため、完全にAIに任せることは難しいと考えています。

→ テスト環境でのバージョンアップ後の操作性検証が必要ということですね。

調査・見積もり段階でアップグレードによる影響度を可視化する方法はないでしょうか?

例えば、以下のようなアプローチが考えられます。

  • プラグインのソースコードをAIに分析させ、状態遷移図を作成する
  • UI画面を部分的に描画して変更箇所を可視化する
  • プラグインの動作を模擬的にシミュレーションする

これらの手法により、技術的な内容をプロダクトマネージャーやエンドユーザーが理解しやすい形でドキュメント化できれば、技術用語から利用者向けの分かりやすい説明資料へと変換できる可能性があります。このような取り組みは、要件定義段階での認識の乖離を防ぐことにもつながるのでは?