フィードバックの時間特性
開発者が各外部領域から得るフィードバックには、それぞれ固有の遅延特性がある。この時間特性の違いが認知負荷の性質と開発プロセス設計に深く関わる。
フィードバック経路と遅延
| フィードバック源 | 遅延 | 例 |
|---|---|---|
| コードベース | 即時〜短期(秒〜時間) | ビルドエラー、テスト結果、型チェック |
| 稼働プロダクト | 短期〜中期(時間〜日) | 監視、ログ分析、障害対応 |
| ユーザー | 中期〜長期(週〜月) | フィードバック収集、利用パターン分析 |
| 仮説検証 | 長期(週〜月) | A/Bテスト、機能フラグ |
| 環境 | 不定期 | 法改正、技術の非推奨化、競合の動向 |
抽象化とフィードバックの関係
コードを書く行為 = 抽象的なモデルを具体化するプロセス。具体化の過程でモデルへのフィードバックが発生し、抽象では成立していた設計の矛盾や曖昧さが露呈することがある。
コードを読む行為 = 具体から抽象(プロダクションモデル)を再構築するプロセス。
開発プロセスへの含意
フィードバックが遅延するほど不確実性が大きくなり、コンセプトモデルが誤った方向に進む可能性が高まる。
ウォーターフォール - コンセプトモデルを大きく構築してから実装・デプロイ。この間にフィードバックが得られないため、差分が蓄積し続け、環境やユーザーからの変化に追従できない。
アジャイル - 小さな単位でコンセプトをプロダクションに反映し、フィードバックを得てから次のコンセプトを構築。差分を小さく保ち、不確実性を早期に解消する。
目標設定との関係
遅延の大きい指標(ユーザー価値など)を短期の評価指標とすると、検証を待たずにコンセプトモデルを拡大させるインセンティブが生まれる。
望ましい分離:
- 長期目標 - ユーザー価値、市場成果など(遅延フィードバック)
- 短期目標 - デプロイ頻度、障害復旧時間、テストカバレッジなど(短期フィードバック)
関連
- コンセプトモデル - フィードバックによって更新される「あるべき姿」
- プロダクションモデル - コードベースからのフィードバックで更新される「現状の理解」
- 認知負荷 - フィードバック遅延が認知負荷の不確実性を増大させる
- 継続的インテグレーション - コードベースからのフィードバックを短縮する仕組み
- コンセプトモデルとプロダクションモデル:ソフトウェア開発における認知構造の考察 - フィードバック遅延の詳細な考察