# フィードバック駆動開発 ## 定義 フィードバック駆動開発(Feedback-Driven Development, FDD)は、本番 SaaS アプリケーションのランタイムモニタリングデータを開発者が使う IDE(統合開発環境)に統合し、より緊密なフィードバックループを実現するソフトウェア開発パラダイムである。[[Jürgen Cito]]・[[Philipp Leitner]]・[[Harald C. Gall]] (University of Zurich) らが 2015 年の Onward! ビジョンペーパーで提唱した([[@2015__Onward!__Runtime Metric Meets Developer - Building Better Cloud Applications using Feedback]])。 FDD は抽象的な概念であり、複数の方法で具体化される: - **分析的 FDD(Analytic FDD)**: 本番フィードバックを事後的に可視化する。運用データを依存グラフ上でコードアーティファクトに紐づけ、IDE の該当箇所に性能情報を表示する - **予測的 FDD(Predictive FDD)**: コード変更を行う前に性能・コストへの影響を予測する。静的解析と本番フィードバックを組み合わせ、デプロイ前に開発者へ警告を与える FDD は DevOps・継続的デリバリー・クラウドコンピューティング・ライブプログラミングの論理的延長線上に位置づけられる。APM ツールの代替ではなく、APM データを**開発者の視点から再利用する**延長として機能する。 ## コア概念 **フィードバックコントロール**は 5 段階のパイプラインで構成される: 1. データ収集 — APM ツール・クラウド監視 API 経由でランタイムデータを収集 2. データフィルタリング — ユースケースに応じた種別・解像度の選択 3. データ集約 — 最小値・最大値・平均等の基本統計、またはより細粒度な集計 4. データ統合 — 異なる種別のデータ(VM コスト × リクエスト数)を結合 5. フィードバックマッピング — 集約・統合済みデータをソースコードアーティファクトに紐づける **フィードバック鮮度管理**: 変化点(チェンジポイント)解析により統計的分布変化を検出し、古いフィードバックを自動的に無効化する。継続的デリバリー環境での頻繁なデプロイに対応するため、単純なデプロイ前リセットよりも適切。 **運用データの類型**: | カテゴリ | 具体例 | |---|---| | 実行パフォーマンスデータ | サービス応答時間・DB クエリ時間 | | 負荷データ | リクエストレート・サーバー稼働率 | | コストデータ | VM の時間あたりクラウドコスト | | ユーザー行動データ | クリックストリーム | | 本番データ | 発注件数・顧客情報などアプリ実データ | ## 概念実証実装(2015 年) 1. **Performance Spotter** — SAP HANA Cloud Platform 上の分析的 FDD ツール。関数パフォーマンス概要・コールグラフベース根本原因特定・DB 性能概要の 3 機能 2. **PerformanceHat** — Eclipse IDE プラグイン。ホットスポット検知とクリティカルループ予測の 2 機能。NewRelic 等の APM ツールをバックエンドとして利用可能 3. **コスト予測ツール** — 新サービス追加・サービス置換のコストインパクト予測(初期段階のモックアップ) ## 横断的知見 - **FDD は「監視データのコンテキストスイッチ問題」の解決策として提唱された**: APM ツールが収集した運用データが開発者の日常ワークフローに統合されていないという 2015 年の問題提起は、2020 年代の GitHub Copilot・AI コーディングアシスタントが「IDE 内で本番メトリクスを参照しながらコード変更を提案する」ユースケースとして再浮上している。FDD の概念的骨格が 10 年を経て LLM 統合開発環境という形で実現しつつある点は注目に値する。(Source: [[@2015__Onward!__Runtime Metric Meets Developer - Building Better Cloud Applications using Feedback]]) - **「本番フィードバックの開発統合」という方向性は[[オブザーバビリティ]]の発展と並走した**: FDD が 2015 年に提唱された時点では APM ツールが主要な本番データ源だったが、その後 OpenTelemetry・分散トレーシング・継続的プロファイリングが標準化された。結果として FDD が「フィードバックマッピング」で想定したメソッドレベルの運用データ紐づけは、2020 年代では OpenTelemetry の Span 属性・コード属性として実現可能になっている。この「技術基盤の充実がビジョンの実現可能性を高めた」関係は、ビジョンペーパーが先行して問題を定義したケースとして参照できる。(Source: [[@2015__Onward!__Runtime Metric Meets Developer - Building Better Cloud Applications using Feedback]], [[オブザーバビリティ]]) ## 未解決の問い - FDD が想定した「フィードバックマッピング」(運用データ → ソースコードアーティファクト)は、2020 年代の OpenTelemetry コード属性・継続的プロファイリング製品(Polar Signals, Pyroscope 等)でどの程度実現されたか - 予測的 FDD の「コード変更前の性能インパクト予測」は LLM コーディングアシスタントの登場でどう変化したか。LLM が過去の性能パターンを学習して変更インパクトを推定する形態は FDD の予測ユースケースとどう接続するか - データアクセスとプライバシーの課題: 2015 年に識別された「本番データ(ユーザー情報)が開発者に開示できない」問題は、差分プライバシー・プライバシー保護データマイニングの発展でどこまで解消されたか - クラウドインフラの性能予測不可能性(Leitner & Cito 2014 の「交絡因子」問題)は 2020 年代のクラウド環境でどの程度改善されたか。eBPF・連続プロファイリングによる細粒度計測はノイズ低減に寄与したか ## 関連 - 概念: [[オブザーバビリティ]]・[[継続的デリバリー]]・[[DevOps]]・[[AIOps]] - エンティティ: [[Jürgen Cito]]・[[Philipp Leitner]]・[[Harald C. Gall]]・[[University of Zurich]] - ソース: [[@2015__Onward!__Runtime Metric Meets Developer - Building Better Cloud Applications using Feedback]] ## 出典 - [[@2015__Onward!__Runtime Metric Meets Developer - Building Better Cloud Applications using Feedback]] — Cito ら(University of Zurich / SAP SE), Onward! 2015。FDD 概念の一次出典