Go to Qiita Advent Calendar Top
LoginSignup
0
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@nogataka

AI駆動開発時代のDevExについて考えてみた

Posted at

はじめに

昨年読んで印象に残っていた記事を、ふと読み返してみました。Michael J. Leverによる「UX is ignoring developer experience」です。UXデザイナーが開発者体験（DevEx）を軽視しているという指摘なのですが、改めて読み直してみると、この1年で状況が大きく変わっていることに気づきました。

**DevEx（Developer Experience：開発者体験）**とは、開発者がプロダクトやサービスを構築・統合・拡張する際に感じる体験の総称です。API設計、ドキュメント、SDK、開発ツール、エラーメッセージ、サポート体制など、開発者が触れるあらゆる接点が対象となります。優れたDevExは開発者の生産性を向上させ、プロダクトの採用率を高める重要な要素となっています。

しかし、AIツールが開発現場に急速に浸透している今、DevExの定義そのものが変わりつつあるのではないでしょうか？

本記事では、従来のDevExの課題を振り返りながら、AI駆動開発時代における新しいDevExの在り方について考えていきたいと思います。

従来のDevExが抱えていた課題

Leverの研究では、開発者のニーズを4つのカテゴリに分類しています：

1. 付加価値を可能にする（Enable added value）

  • APIから最大限のデータ・機能を取得できること
  • ソート・フィルタなどのレスポンス変形機能の提供
  • 権限管理やバージョン管理をセルフサービスで行える仕組み

2. 成功への障害を取り除く（Remove obstacles to success）

  • テストデータや環境を簡単に用意できること
  • タスクが原子的に設計されていることによる失敗リスクの低減
  • システムの"裏側"の体験設計への配慮

3. 価値のある発見可能なガイダンスを提供する（Provide valuable, discoverable guidance）

  • 「Getting Started」ドキュメントが複数のユースケースに対応していること
  • 変更ログやリリースノートの正確・定期的・対象別の提供
  • ドキュメントの情報設計（IA）におけるユーザー行動の考慮
  • インタラクティブツール（クエリビルダー、スニペットコピー機能など）による開発体験の向上

4. 作業方法を強化する（Enhance ways of working）

  • 定期的で予測可能なコミュニケーションリズムの確立
  • ドキュメント更新を優先する組織文化の醸成
  • サービス提供者と開発者を「パートナー」として扱う関係性

これらの課題は、API設計やドキュメント整備、プラットフォーム設計において長年指摘されてきたものです。しかし、AIツールの登場によって、これらの課題の性質が変わりつつあります。

AI時代の開発体験：何が変わったのか

開発者とAIの協働関係

従来の開発フローは「開発者 → ドキュメント → API → 実装」という流れでした。しかし、AI駆動開発では「開発者 ⇄ AI ⇄ API/コード」という双方向のループが生まれています。

例えば、以下のような変化が見られます：

  • ドキュメントを読む代わりに、AIに質問する

    • 「このAPIのレスポンスをフィルタリングする方法を教えてください」
    • 「この関数の引数の意味を説明してください」

  • 実装例を探す代わりに、AIに生成させる

    • 「GraphQLでソート機能を実装してください」
    • 「このエンドポイントのテストケースを作成してください」

これは、ドキュメントの重要性が下がったという意味ではありません。 むしろ、AIが参照できる質の高いドキュメントの重要性が増していると言えるでしょう。

新しいDevExの要件

AI時代のDevExには、従来の4つの要件に加えて、新たな視点が必要になってきています：

5. AIフレンドリーなドキュメント設計

人間が読みやすい ≠ AIが理解しやすい

  • 構造化されたスキーマ定義（OpenAPI, GraphQL Schema）
  • 一貫性のある命名規則
  • コンテキストを含んだサンプルコード
  • エラーケースの明確な記述

例えば、以下のような記述の違いがあります：

❌ 改善の余地がある例：
「レスポンスをフィルタリングできます」

✅ より良い例：
「`filter` パラメータを使用してレスポンスをフィルタリングできます。
例: `GET /api/users?filter=active:true,role:admin`
複数条件はカンマ区切りで指定し、コロンで key:value を表現します。」

AIは後者の方がより正確に理解し、適切なコードを生成できます。

6. AI生成コードの検証可能性

AIが生成したコードは必ずしも正しいとは限りません。そのため、開発者が素早く検証できる環境が重要になります：

  • インタラクティブなAPI Explorer（Google API Explorer, Swagger UIなど）
  • Sandboxテスト環境への即座のアクセス
  • 生成されたコードの妥当性を確認できるリント・型チェック
  • AIが生成したコードと実際のAPI仕様の差分を検出する仕組み

7. AIとの対話を前提としたエラー設計

エラーメッセージは、もはや人間だけが読むものではなくなっています：

// 従来のエラーメッセージ
{
  "error": "Invalid request"
}

// AI時代のエラーメッセージ
{
  "error": {
    "code": "INVALID_FILTER_SYNTAX",
    "message": "フィルタ構文が正しくありません",
    "details": "filter パラメータは 'key:value' の形式で指定してください",
    "example": "filter=active:true",
    "documentation": "https://api.example.com/docs/filtering"
  }
}

AIはこの構造化されたエラー情報を使って、より適切な修正案を提示できます。

DevExとUXの境界が曖昧になる

Leverの記事では「UXデザイナーがDevExを軽視している」と指摘されていましたが、AI時代ではこの境界がさらに曖昧になっています。

AIがDevExとUXを繋ぐ

例えば、以下のようなシナリオを考えてみましょう：

  1. エンドユーザーがUIで複雑な検索を実行
  2. フロントエンドがその検索条件をAIに渡す
  3. AIが最適なAPIクエリを生成
  4. バックエンドAPIがデータを返す
  5. AIが結果を整形してUIに表示

このフローでは、従来「開発者が書いていたコード」の多くをAIが担います。つまり、APIの使いやすさは、直接的にエンドユーザー体験に影響するようになるのです。

「良いDevEx」の再定義

AI時代の「良いDevEx」とは何でしょうか？いくつかの視点を整理してみます：

視点 従来のDevEx AI時代のDevEx
ドキュメント 人間が読んで理解しやすい AIが解釈しやすく、人間が検証しやすい
API設計 RESTful、一貫性のある設計 スキーマ駆動、コンテキスト情報が豊富
エラー処理 人間が読めるメッセージ 構造化され、修正可能なエラー情報
テスト 手動でテストデータ作成 AIがテストケースを生成、実行環境が即座に利用可能
学習曲線 ドキュメントを読んで学習 AIとの対話で学習、実践的なサンプルが即座に得られる

実践的なアプローチ：何から始めるべきか

では、AI時代のDevExを向上させるために、具体的に何をすべきでしょうか？

1. ドキュメントの構造化を進める

  • OpenAPI（Swagger）やGraphQL Schemaの整備
  • サンプルコードに実行可能なコンテキストを含める
  • エラーコードとその解決方法を体系化する

2. AI-in-the-Loop なテスト環境を提供する

  • AIが生成したコードをすぐに試せるSandbox環境
  • API ExplorerとAIアシスタントの統合
  • 生成されたコードの検証ツール

3. 開発者フィードバックループを再設計する

従来：開発者 → ドキュメント → サポート
AI時代：開発者 ⇄ AI ⇄ ドキュメント ⇄ サポート

AIが中間に入ることで、どこで開発者が詰まっているかがより明確になります：

  • AIが頻繁に間違えるAPIは設計に問題がある可能性があります
  • AIが生成できないパターンはドキュメント不足の可能性があります
  • AIの回答と実際の挙動が異なる場合は情報の不整合が考えられます

4. 「AIと開発者の共創」を前提とした設計

もはや開発者だけがAPIを使用するわけではありません。AIも「ユーザー」として扱う必要があります：

  • Human-readable + Machine-readable（人間とマシンの両方が読める形式）
  • 対話的なドキュメント（例：「〜したい場合はどうすれば良いですか？」という質問形式）
  • 実行例とその結果を含むリファレンス

UXデザイナーへの示唆

Leverの記事では「デザイナーはコンフォートゾーンを離れるべき」と主張されていました。AI時代には、これがさらに重要になってきます。

デザイナーが考えるべき新しい問い

  • AIが介在する体験をどのように設計するか？

    • ユーザーが直接APIを使用するのではなく、AIを介してサービスを利用する場合の体験設計

  • AIの出力品質はDevExに依存する

    • API設計やドキュメントの質が、AIの生成結果に直結します
    • つまり、DevExの向上は間接的にエンドユーザー体験を向上させます

  • 開発者とAIの協働をどのように支援するか？

    • AIが「良い提案」をするために必要な情報は何でしょうか？
    • 開発者がAIの提案を検証するために必要なツールは何でしょうか？

デザインプロセスの変化

従来のデザインプロセス：
ユーザーリサーチ → プロトタイプ → 開発 → リリース

AI時代のデザインプロセス：
ユーザー + 開発者リサーチ → プロトタイプ（AIと協働） → AI検証環境の整備 → リリース → AI品質モニタリング

開発者体験とユーザー体験が、AIを介して密接に結びついています。

まとめ：DevExは新しいステージへ

AI駆動開発の時代において、DevExは単なる「開発者のための体験」を超えて、エンドユーザー体験を左右する重要な要素になりつつあります。

3つの重要なポイント

  1. AIフレンドリーなDevExを設計する

    • 構造化されたドキュメント、一貫性のあるAPI設計、検証可能なエラー設計

  2. 開発者とAIの共創を前提とする

    • AIは開発者のパートナーであり、APIの「もう一つのユーザー」です

  3. DevExとUXの境界を再定義する

    • UXデザイナーもDevExを理解し、開発者もAIとの協働を前提に設計する必要があります

これからのDevEx

Leverの記事で引用されていた言葉を思い出します：

「私たちは統合経済で働いている。人工知能は、私たちがすでに見てきたものを超えて、統合されたシステムの爆発につながる可能性がある」

AI時代のDevExは、もはや開発者だけの問題ではありません。デザイナー、エンジニア、プロダクトマネージャー、そしてAIそのものが関わる、統合的な体験設計の課題なのです。

この新しい時代において、私たちは「開発者体験」を再定義し、AIと人間が協働する新しいワークフローを設計する必要があります。

それは、技術的な挑戦であると同時に、デザインの挑戦でもあるのです。

参考文献

  • Michael J. Lever, "UX is ignoring developer experience", Future UX (2024)
  • Jobs to be Done フレームワーク
  • Data Delivery Checklist
  • OpenAPI Specification
  • GraphQL Schema Design
0
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?